What to do when lsof fails....
 

So, we had a penetration test done recently, and the server was found
to be ... lacking. It's been tightened up and will soon have another
test done on it, but in the meantime I've got a suspect service running
on the machine - and I can't find out what's providing the service...

If I do:
netstat -tunap | grep LISTEN

I get two services with no pid/program:

tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -

tcp 0 0 0.0.0.0:26959 0.0.0.0:* LISTEN -

Now, 2049 is the NFS daemon's port, so I'm assuming the reason there's
nothing reporting for that is that it's the kernel nfsd. The one that
has me concerned is the 26959 one...

Doing lsof on it (using a binary from another machine) returns me
nothing either
# ./lsof -i TCP:26959
#

For the time-being I've firewalled the port (INPUT/OUTPUT/FORWARD) but
was wondering if there was any other way to determine which process has
the socket open.

Any thoughts ? (Apart from 'reinstall the system' - that's going to
happen soon anyway)

Cheers,
Simon.

[added in case it helps anyone else]

So, it turns out to be benign - it was a sun-rpc service running on the port, and once I'd done an 'rpcinfo -p', I could see that a standard service (locking) was running on that port. RPC ports are arbitrary (hence the portmapper process) so the odd port number is reasonable...

Simon

Re: What to do when lsof fails....
 

Did you run netstat and lsof as user or as root ?
If you run them as user then you can't get the pids

Run them as root and they should work.
Also you can also run "fuser 26959/tcp"

Re: Re: What to do when lsof fails....
 

Well, I get the same response back with fuser (that is to say, not very much :-) and I am running as root. I guess it's just that they're being looked after by the kernel...

# fuser ssh/tcp
here: ssh
ssh/tcp: 6633

# fuser 26959/tcp
here: 26959


Cheers,
Simon.