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
To verify all else, the machine is behind the firewall and uses rfc1918 fixed IP addresses.And it goes away by stopping/
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
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.
1024 for nlockmgr
The dynamic model has changed. This makes it a fingerprint to determine if they
an RH7 box, is this supposed to be an improvement? This explains the presence of
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
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.