Protocol scan with nmap

[Gerhard Rieger - privat <rieger () iue tuwien ac at>]

Hi nmap-hackers,

I have found nmap to be a very useful program for getting IP information about
hosts and networks.
What I sometimes need is a "protocol scanner" that probes for different values
of the IP portocol field, as used for selecting ICMP, TCP, UDP etc. For a year
now I had a perl "proof of concept" implementation; recently I decided to build
this feature into nmap. The result is now finished; I am sending the patch to
Fyodor in the hope that he will accept it for nmap.

I think that this feature is an important addition to IP level scanners.
BTW, I do not know if this type of scan has already been implemented somewhere.

The basic technic is the same as used for nmaps UDP scan: for each
interesting number a raw IP header packet is sent. If this number is supported
by the target IP stack, it does not respond; if no handler for that protocol is
integrated, the IP stack returns a "protocol unreachable" message (ICMP 3/2).

This is theory; in practice not all systems generate these "protocol
unreachable" messages.
At the first glance the following do not:
  AIX, HP-UX, HP Laserjet, Digital-Unix
Some that do:
  Solaris, Linux, Routers, *D0S

For example I tested the two IP addresses that result from www.insecure.org:

  # ./nmap -sI 216.218.218.233
  Starting nmap V. 2.53 by fyodor () insecure org ( www.insecure.org/nmap/ )
  Interesting protocols on one233.area.com (216.218.218.233):
  (The 251 protocols scanned but not shown below are in state: closed)
  Protocol   State       Name
  1          open        icmp                    
  2          open        igmp                    
  6          open        tcp                     
  17         open        udp                     
  Nmap run completed -- 1 IP address (1 host up) scanned in 169 seconds

The support of ICMP, TCP, and UDP will not be surprising :-)
Scanning the other www.insecure.org address (207.69.138.68) reports "all open"
which is obviously wrong; Fyodor, nmap does not seem to recognize both
OS fingerprints :-(

More of interest is a scan of some router on the internet:

  (The 239 protocols scanned but not shown below are in state: closed)
  Protocol   State       Name
  1          open        icmp                    
  2          filtered    igmp                    
  4          filtered    ip                        
  6          open        tcp                     
  8          open        egp                        
  9          filtered    igp                        
  17         open        udp                     
  47         open        gre                        
  53         open        swipe                        
  54         open        narp                        
  55         open        mobile                        
  77         open        sun-nd                        
  88         filtered    eigrp                        
  89         filtered    ospfigp                        
  94         filtered    ipip                        
  103        open        pim                        

Only a tcpdump shows that "filtered" is caused by a more outside router.
Remember: "open" means "no answer", "closed" means "protocol unreachable", and
"filtered" is caused by some "administratively forbidden".

Best regards
Gerhard Rieger
--
Always speaking for myself.