HostedDB - Dedicated UNIX Servers

ICMP_Scanning_18
ICMP Usage in Scanning 18 Copyright Ó Ofir Arkin, 2000 http://www.sys-security.com 3.2.1.1.1 Detecting if a Filtering Device is present   A packet sent with a protocol value, which does not represent a valid protocol number, should elicit an ICMP Destination Unreachable – Protocol Unreachable from the probed machine. Since this value is not used (and not valid) all hosts probed, unless filtered or are AIX, HP-UX, Digital UNIX machines, should send this reply. If a reply is not received we can assume that a filtering device prevents our packet from reaching our destination or from the reply to reach us back. 3.2.1.2 Using all combination of the IP protocol filed values The difference with this variant is that we use all of the combinations available for the IP protocol field – since the IP protocol field has only 8 bits in length, there could be 256 combinations available.   NMAP 2.54 Beta 1 has integrated this variant and Fyodor have named it - IP Protocol scan. NMAP sends raw IP packets without any further protocol header to each specified protocol on the target machine. If an ICMP Protocol Unreachable error message is received, the protocol is not in use. Otherwise it is assumed it is opened (or a filtering device is dropping our packets).   If our goal was Host Detection only, than using the NMAP implementation would be just fine. But if we wish to use this scan type for other purposes, such as ACL detection, than we would need the protocol header as well. We can determine if a filtering device is present quite easily using this scan method. If a large number of protocols (non valid values could be among those) seems to be “opened”/used (not receiving any reply – ICMP Protocol Unreachable) than we can assume a filtering device is blocking our probes (if using a packet with the protocol headers as well). If the filtering device is blocking the ICMP Protocol Unreachable error messages initiated from the protected network towards the Internet than all of the 256 possible protocol values would be seemed “opened”/used.   With the current implementation with NMAP the 256 possible protocol values should be “opened” when a scan is performed against a machine inside a protected network, because a packet filter firewall (or other kind of firewall) should block the probe since it lacks information to validate the traffic against its rule base (information in the protocol headers such as ports for example). In the next example I have used NMAP 2.54 Beta 1 in order to scan a Microsoft Windows 2000 Professional machine:   [root@catman /root]# nmap -vv -sO 192.168.1.1 Starting nmap V. 2.54BETA1 by fyodor@insecure.org ( www.insecure.org/nmap/ ) Host   (192.168.1.1) appears to be up ... good. Initiating FIN,NULL, UDP, or Xmas stealth scan against   (192.168.1.1) The UDP or stealth FIN/NULL/XMAS scan took 4 seconds to scan 254 ports. Interesting protocols on   (192.168.1.1): (The 250 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 4 seconds