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
# ./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)
[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...
Last edited by SpacedCowboy; 10-29-2005 at 02:53 AM.