Bug 21270 - nmap reports weird open ports that is "fixed" by killing/restarting nfslock
Summary: nmap reports weird open ports that is "fixed" by killing/restarting nfslock
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils   
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: David Lawrence
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2000-11-22 23:49 UTC by Henri Schlereth
Modified: 2007-04-18 16:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-12-19 16:15:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Henri Schlereth 2000-11-22 23:49:01 UTC
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>

Comment 1 Daniel Roesen 2000-11-23 01:08:00 UTC
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".

Comment 2 Henri Schlereth 2000-11-23 01:49:03 UTC
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/
starting nfslock.

Comment 3 Henri Schlereth 2000-11-23 02:39:14 UTC
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).

Comment 4 Daniel Roesen 2000-11-23 03:00:26 UTC
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 

Comment 5 Henri Schlereth 2000-11-23 03:55:54 UTC
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
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
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?

Comment 6 Daniel Roesen 2000-11-23 13:43:44 UTC
will do so now.

Comment 7 Pete Zaitcev 2002-10-08 23:57:31 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.