Hide Forgot
As a security test I ran nmap -O against a fresh server install + updates of RH7 The first scan showed 1024 kdm active. A restart then showed 1031 iad2 active. A stop/start made things normal. ???? WTF? A reboot brings kdm active again. <scratches head in very puzzled manner but reports it anyway>
Ports in that range are dynamically assigned. Same 'problem' exists with gnome- panel which also opens a dynamically assigned listening socket (so you can't filter it). nmap by default scans only "usual" ports (found in /etc/services and some others IIRC). By restarting the services they get other ports assigned by the kernel. This is what you are experiencing. After reboot kdm is obviously the first process in the bootup execution sequence which acquires a dynamic socket so it gets 1024 (the first in the 1024-4999 range) again. After all: NOTABUG (but a security problem IMHO). Perhaps changing the component to the KDE package containing kdm is a good idea if you want to raise the security question (I don't know any reason why kdm needs a dynamic listening socket by default at all) and change severity to "security".
I am sorry but I am going to have to disagree with this line of reasoning, I did a server install, no GNOME, no KDE, just XFS server and libs and XFS is turned off. Whatever is hanging off that socket may be reported as kdm but it isnt. And I do not have iad2 installed running on port 1031 either. So either nmap is on the fritz or something is grabbing sockets that it shouldnt. To verify all else, the machine is behind the firewall and uses rfc1918 fixed IP addresses.And it goes away by stopping/ starting nfslock.
Additional information: Using ntsysv I disabled nfslock, problem goes away When I re-enable, reboot, problem returns two initscript restarts 1.) shows kdm 1024 2.) shows iad2 1031 and then the problem goes away. I run nmap between each step. I rebooted and ran rpcinfo [root@kesrith /root]# rpcinfo -p cave program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100021 1 udp 1024 nlockmgr 100021 3 udp 1024 nlockmgr 100024 1 udp 1025 status 100024 1 tcp 1024 status 100001 3 udp 669 rstatd 100001 2 udp 669 rstatd 100001 1 udp 669 rstatd you will note the 1024 port showing nlockmgr holding the socket and 1025 status (something that nmap didnt catch).
Sorry, but this is how NFS&RPC works. RPC services use dynamically assigned ports, for which portmap acts as a broker. rpcinfo -p shows the registered RPC services and the ports they listen to. nlockmgr and status (rpc.statd) listen on dynamically assigned ports (default range is 1024-4999). Your restarts have the consequence, that rpc.statd etc. gets restarted and gets a new port (1031 e.g.). Verify this with rpcinfo -p after you restarted the nfslock package. You can see the services "moving" up the dynport range after restarts.
Really? And why doesnt it exhibit this behavior under RH6.2? Repeated restarts under RH6.2 show the same ports re-used over and over again. nfs-utils-0.1.9.1-1 1024 for nlockmgr 957 status 959 status The dynamic model has changed. This makes it a fingerprint to determine if they are scanning an RH7 box, is this supposed to be an improvement? This explains the presence of kdm in my security logs when I counter-scan an intrusion attempts. And nmap only shows the last two as unkown. And doesnt see 1024 at all. Now I dont want to step on any feet but I assume that either droesen works for RedHat or is on the beta team as I am. If you dont work for RedHat why not let the assigned to person tell me I am barking up the wrong tree?
will do so now.
Firewall should block by TCP SYN flag, not by port number, and have defaults set to reject. Running NFS over the Internet is not a sane idea. If nmap can detect open ports, a firewall is misconfigured.