1

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:

  1. Should I be worried about a compromised box, or is this indeed an nfs-kernel-server issue?
  2. 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

2 Answers 2

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.

1
  • Not on this server, it does not mount any NFS-shares itself. It has directories which are served with NFS, but none of those are a home directory for a user on other servers.
    – Wrikken
    Feb 1, 2012 at 13:21
1

Port 2049 is definitely associated with the in-kernel nfs service. On my system, I have nfsd running.

:;  sudo netstat -anp | grep LIST
tcp        0      0 0.0.0.0:2049                0.0.0.0:*                   LISTEN      -                   

So, let's see if I'm running the kmod for this:

:;    lsmod | grep nfs
nfsd                  287337  17 
exportfs               38849  1 nfsd
auth_rpcgss            81889  1 nfsd
nfs                   298541  1 
lockd                 101297  3 nfsd,nfs
fscache                52385  1 nfs
nfs_acl                36673  2 nfsd,nfs
sunrpc                200073  19 nfsd,auth_rpcgss,nfs,lockd,nfs_acl

Yup! And now we'll check to see if the kernel threads are up:

:;  ps -aefd | grep nfs
root      3648   171  0  2011 ?        11:46:48 [nfsiod]
root      3882   171  0  2011 ?        00:00:00 [nfsd4]
root      3883     1  0  2011 ?        00:00:00 [nfsd]
root      3884     1  0  2011 ?        00:00:00 [nfsd]
root      3885     1  0  2011 ?        00:00:00 [nfsd]
root      3886     1  0  2011 ?        00:00:00 [nfsd]
root      3887     1  0  2011 ?        00:00:00 [nfsd]
root      3888     1  0  2011 ?        00:00:00 [nfsd]
root      3889     1  0  2011 ?        00:00:00 [nfsd]
root      3890     1  0  2011 ?        00:00:00 [nfsd]

Yup!

So at the very least, you can confirm this way that 2049 is actually NFS.

I don't know what 2030 is.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .