extra open ports in rkhunter

[Carl Johnson]

Carl Johnson <carlj at peak.org> writes:

> I am running rkhunter and it keeps reporting a port inconsistency
> between sockstat and netstat -a.  Netstat shows an extra 5 ports open,
> but netstat doesn't show what is holding ports open, so I don't know
> what they are.  Does anybody know how to determine what is holding open
> a port?  I have been looking around but none of my ideas show anything.
> This is a full desktop system with KDE4 and VirtualBox running, so it
> has a lot of things running.  The following are the ports if anybody has
> any ideas, but I would also like to know how to trace them down myself:
> tcp4       0      0 *.876                  *.*                    LISTEN
> tcp6       0      0 *.921                  *.*                    LISTEN
> udp4       0      0 *.608                  *.*
> udp6       0      0 *.952                  *.*
> udp6       0      0 *.804                  *.*

I did some further testing after getting some prompting from an off-list
email.  It turns out that all of those come from rpc.lockd, and that
they are not fixed but change after every restart of rpc.lockd.  I
confirmed this with a fresh install from
FreeBSD-8.1-RELEASE-amd64-dvd1.iso into VirtualBox with networking
disabled.  I also verified the checksums of the .iso to be sure that
nothing had been tampered with.  I had just been trying out nfs but
didn't find anything that I couldn't handle with ssh, so I have since
disabled NFS and all rpc daemons.

Unlisted ports should be useless, so something else must handle those
addresses, probably rpcbind or maybe rpc.statd.  It does seem odd that
rpc.statd has port addresses that show up in sockstat and others, but
rpc.lockd does not.  I never did find anthing that will show many of
those hidden ports.  Nmap will show open ports for tcp4 and tcp6, but
it is too slow for upd4 and doesn't handle udp6 at all.  Nmap also
doesn't identify who has opened ports except by standard addresses, so
that can't identify daemons that dynamically assign their addresses.

Thanks for all of the suggestions.
-- 
Carl Johnson		carlj at peak.org