Start a Conversation

Unsolved

This post is more than 5 years old

2394

December 9th, 2014 12:00

Strange nmap output of SmartConnect IP or Node IP Address

When I nmap my SmartConnect IP or an individual node IP  - I see ONLY the following ports:


nmap X.X.X.X - SmartConnect IP Address
Starting Nmap 5.00 ( http://nmap.org ) at 2014-12-09 13:49 EST
Interesting ports on X.X.X.X:
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
8080/tcp open http-proxy

nmap X.X.X.X - Node IP Address

Starting Nmap 5.00 ( http://nmap.org ) at 2014-12-09 13:53 EST

Interesting ports on X.X.X.X:

Not shown: 997 closed ports

PORT     STATE SERVICE

22/tcp   open  ssh

80/tcp   open  http

8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds

nmap X.X.X.X -sU

Starting Nmap 5.00 ( http://nmap.org ) at 2014-12-09 15:04 EST

Interesting ports on X.X.X.X:

Not shown: 997 closed ports

PORT    STATE         SERVICE

53/udp  open|filtered domain

123/udp open|filtered ntp

161/udp open|filtered snmp

Nmap done: 1 IP address (1 host up) scanned in 2.13 seconds

But my research shows that the Isilon platform utilizes the following ports:

OneFS uses the following ports:

PORT    PROCESS
----         -------
20         FTP Data: ftpd, vsftpd
21         FTP Control: ftpd, vsftpd
22         SSH:  sshd
23         Telnet:  telnetd
53         DNS:  isi_dnsiq_d
80         HTTP:  httpd
111       RPC:  rpcbind
123       NTP:  ntpd
137       NETBIOS NS:  nmbd
138       NETBIOS Data:  nmbd
139       NETBIOS Session:  smbd
161       SNMP:  snmpd
300       nfsmountd
302       nfsstatd
304       nfslockd
389       LDAP:  lsassd
443       HTTPS:  httpd
445       Microsoft DS:  smbd
464       Kerberos: change/set password
514       Syslog:  syslogd
623       Dummy IPMI Server:  isi_ipmi_d
664       Dummy IPMI Server:  isi_ipmi_d
2049     NFS:  nfsd
2097     SyncIQ:  isi_repl_pworker
2098     SyncIQ:  isi_migr_pworker (deprecated)
3147     SyncIQ:  isi_repl_bandwidth
3148     SyncIQ:  isi_migr_bandwidth (deprecated)
5019     IFS:  ifsd
5038     ibootd:  isi_boot_d
5042     ibootd:  isi_boot_d
5666     SyncIQ:  isi_repl_sworker
5667     SyncIQ:  isi_migr_sworker (deprecated)
6116     Stats:  isi_stats_d
6557     PH:  isi_ph_rpcd
8080     HTTP:  httpd (Isilon WebUI)
8081     HTTP:  httpd (Isilon WebUI)
8086     WebUI:  isi_webui_d
8470     SyncIQ:  isi_replicate
9443     InsightIQ
9999     iSCSI:  isi_iscsi_d
10000   NDMP:  isi_ndmp_d
15100   Upgrade:  isi_upgrade_d

Does anyone have an explanation for why NMAP doesn't enumerate all these ports?

TIA,

Amir

106 Posts

December 9th, 2014 15:00

Amir,

  This to me is more a question about the functionality of NMAP then about the Isilon cluster.  In a brief look over the information on the NMAP web site about what entails a 'scan' of these ports - you are looking for ports that would accept an incoming request over TCP or UDP on these ports.  By default, it is scanning 1000 ports, and in fact there are over 65000 possible port numbers that could be used.

I expect that NMAP is looking for specific known ports such as 22 and 80 that normally accept such things, but ignoring the majority of the 65000 possible ports out there.  You can adjust the scan to include a larger range, though I imagine this may greatly increase the time needed for the scan.

Also, many of the ports you listed may in fact be 'closed' per the description from NMAP.  Taking SNMP for example on port 161 - by default SNMP services are disabled, therefore there won't be an open port there waiting to accept queries until you go into the Web Administration Interface and enable the feature. 

Others such as port 15100 isi_upgrade_d or 9999 SyncIQ - might be closed at the time of scan, and only open at the point in time that an upgrade is performed, or a replication job is initiated.  So a scan won't find them because they don't remain open.

31 Posts

December 10th, 2014 07:00

Hi,

Regarding your comment about SNMP - from the output associated from one of my nodes - you'll see SNMP is actually open.  FYI - the SmartConnect Cluster IP doesn't support SNMP - so only the node IP addresses will show that port open - assuming it is enabled to begin with.

nmap X.X.X.X -sU

Starting Nmap 5.00 ( http://nmap.org ) at 2014-12-09 15:04 EST

Interesting ports on X.X.X.X:

Not shown: 997 closed ports

PORT    STATE        SERVICE

53/udp  open|filtered domain

123/udp open|filtered ntp

161/udp open|filtered snmp <<<<<<<<<<<<<<<<<<<<<<


Also - this is a port scan of a wide range (1-63000) of TCP and UDP ports - still shows basically NOTHING open:

TCP Port Scan Range 1 - 63000
# nmap X.X.X.X  -p 1-63000

Starting Nmap 5.00 ( http://nmap.org ) at 2014-12-10 10:39 EST

Interesting ports on X.X.X.X

Not shown: 62997 closed ports

PORT    STATE SERVICE

22/tcp  open  ssh

80/tcp  open  http

8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 6.53 seconds


UDP Port Scan Range 1 - 63000

# nmap X.X.X.X -p 1-63000 -u

Starting Nmap 5.00 ( http://nmap.org ) at 2014-12-10 10:39 EST

Interesting ports on X.X.X.X

Not shown: 62997 closed ports

PORT    STATE SERVICE

22/tcp  open  ssh

80/tcp  open  http

8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 8.09 seconds


I don't get it. 

106 Posts

December 10th, 2014 08:00

Ah, you are correct about the SNMP port, I missed that.  So bad example, but the thought is still valid. 

The next test I would do, is to try and target a single port with the scanner to better understand what is happening.  For instance, doing a scan specifically for port 443 - httpd.  Ensuring first that the httpd service is running, I'd run this test:

1. Start up a cluster side packet capture with tcpdump - possibly limiting the capture to just the client IP you are using if this is an active cluster.

2. Run nmap scan directly for port 443 only.

3. Stop the packet capture and open it up in wireshark. 

4. Isolate the communication happening between nmap and the node. 

Then see is it a ping type scan for that port, and what is the cluster's response? 

In essence, I do find the scan results to be a positive thing, as it seems to indicate that while Isilon does utilize a good number of network ports for various functions, these ports are not left open for incoming requests.  On the other hand, this might just be an issue with the methods used by nmap to query these ports.   I would be curious if you get the same results when scanning a standard FreeBSD installation. 

31 Posts

December 18th, 2014 09:00

Thanks again for your input on this.  I have to move onto another task at the moment.

Amir

No Events found!

Top