During a standard security sweep we found out a something was listening on a port unknown to us, 2030, and we are having trouble determining the source.
# netstat -anp | grep LIST
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
....
tcp 0 0 0.0.0.0:2030 0.0.0.0:* LISTEN -
Both without a 'process'. Connecting to it yielded no information (disconnects after input, most likely because an expected protocol isn't followed), lsof -i :2030
also nothing. Just to make sure I copied over a new lsof
binary, but I am not sure what extra, possibly compromised, libs it calls. The 2049
I know, which is from the nfs-kernel-server, which behaves the same way (no process information from netstat or lsof). Lo and behold, after restarting the nfs-kernel-server on the debian box, the process listening to 2030 disappeared....
So, my questions:
- Should I be worried about a compromised box, or is this indeed an nfs-kernel-server issue?
- If this is a nfs-kernel-server issue, what is happening exactly, why can't
lsof
show this information?
.
Linux 2.6.39-2-686-pae
nfs-kernel-server 1:1.2.3-3
lsof 4.81.dfsg.1-1
Do you have for e.g. automounted NFS home directories? If yes, these listening ports will disappear some seconds/minutes after every user has logged out.
Port 2049 is definitely associated with the in-kernel nfs service. On my system, I have nfsd running.
So, let's see if I'm running the kmod for this:
Yup! And now we'll check to see if the kernel threads are up:
Yup!
So at the very least, you can confirm this way that 2049 is actually NFS.
I don't know what 2030 is.