Tools such as nmap, hping2, and firewalk perform low-level IP assessment. Sometimes holes exist to allow certain TCP services through the firewall, but the expected service isn't running on the target host. Such low-level network details are useful to know, especially in sensitive environments (e.g., online banking environments), because very small holes in network integrity can sometimes be abused along with larger problems to gain or retain access to target hosts.
Insight into the following areas of a network can be gleaned through low-level IP assessment:
Uptime of target hosts (by analyzing the TCP timestamp option)
TCP services that are permitted through the firewall (by analyzing responses to TCP and ICMP probes)
TCP sequence and IP ID incrementation (by running predictability tests)
The operating system of the target host (using IP fingerprinting)
nmap automatically attempts to calculate target host uptime information by analyzing the TCP timestamp option values of packets received. The TCP timestamp option is defined in RFC 1323; however, many platforms don't adhere to RFC 1323. This feature often gives accurate results against Linux operating systems and others such as FreeBSD, but your mileage may vary.
A TCP probe always results in one of four responses. These responses potentially allow an analyst to identify where a connection was accepted, or why and where it was rejected, dropped, or lost:
If a SYN/ACK packet is received, the port is considered open.
If a RST/ACK packet is received, the probe packet was either rejected by the target host or an upstream security device (e.g., a firewall with a reject rule in its policy).
If an ICMP type 3 code 13 message is received, the host (or a device such as a firewall) has administratively prohibited the connection according to an access control list (ACL) rule set.
If no packet is received, an intermediary security device silently dropped it.
nmap returns details of ports that are open, closed, filtered, and unfiltered in line with this list. The unfiltered state is reported by nmap from time to time, depending on the number of filtered ports found. If some ports don't respond, but others respond with RST/ACK, the unresponsive ports are considered unfiltered (because the packet is allowed through the filter but the associated service isn't running on the target host).
hping2 can be used on a port-by-port basis to perform low-level analysis of responses to crafted TCP packets that are sent to destination network ports of remote hosts. Another useful tool is firewalk, which performs filter analysis by sending UDP or TCP packets with specific TTL values. These unique features of hping2 and firewalk are discussed next.
hping2 allows you to craft and send TCP packets to remote hosts with specific flags and options set. From analyzing responses at a low level, it is often possible to gain insight into the filter configuration at network level. The tool is complex to use, and it has many possible options. Table 4-3 lists the most useful flags for performing low-level TCP assessment.
Send a specific number of probe packets
Source TCP port (random by default)
Destination TCP port
Set the TCP SYN flag
Set the TCP FIN flag
Set the TCP ACK flag
Here's a best practice way to use hping2 to assess a specific TCP port:
# hping2 -c 3 -s 53 -p 139 -S 192.168.0.1 HPING 192.168.0.1 (eth0 192.168.0.1): S set, 40 headers + 0 data ip=192.168.0.1 ttl=128 id=275 sport=139 flags=SAP seq=0 win=64240 ip=192.168.0.1 ttl=128 id=276 sport=139 flags=SAP seq=1 win=64240 ip=192.168.0.1 ttl=128 id=277 sport=139 flags=SAP seq=2 win=64240
In this example, a total of three TCP SYN packets are sent to port 139 on 192.168.0.1 using the source port 53 of the host (some firewalls ship with a configuration that allows DNS traffic through the filter with an any-any rule, so it is sometimes fruitful to use a source port of 53).
Following are four examples of hping2 that generate responses in line with the four states discussed previously (open, closed, blocked, or dropped).
TCP port 80 is open:
# hping2 -c 3 -s 53 -p 80 -S google.com HPING google.com (eth0 22.214.171.124): S set, 40 headers + 0 data ip=126.96.36.199 ttl=128 id=289 sport=80 flags=SAP seq=0 win=64240 ip=188.8.131.52 ttl=128 id=290 sport=80 flags=SAP seq=1 win=64240 ip=184.108.40.206 ttl=128 id=291 sport=80 flags=SAP seq=2 win=64240
TCP port 139 is closed or access to the port is rejected by a firewall:
# hping2 -c 3 -s 53 -p 139 -S 192.168.0.1 HPING 192.168.0.1 (eth0 192.168.0.1): S set, 40 headers + 0 data ip=192.168.0.1 ttl=128 id=283 sport=139 flags=R seq=0 win=64240 ip=192.168.0.1 ttl=128 id=284 sport=139 flags=R seq=1 win=64240 ip=192.168.0.1 ttl=128 id=285 sport=139 flags=R seq=2 win=64240
TCP port 23 is blocked by a router ACL:
# hping2 -c 3 -s 53 -p 23 -S gw.example.org HPING gw (eth0 192.168.0.254): S set, 40 headers + 0 data ICMP unreachable type 13 from 192.168.0.254 ICMP unreachable type 13 from 192.168.0.254 ICMP unreachable type 13 from 192.168.0.254
TCP probe packets are dropped in transit:
# hping2 -c 3 -s 53 -p 80 -S 192.168.10.10 HPING 192.168.10.10 (eth0 192.168.10.10): S set, 40 headers + 0 data
Mike Schiffman and Dave Goldsmith's firewalk utility (Version 5.0 at the time of writing) allows assessment of firewalls and packet filters by sending IP packets with TTL values set to expire one hop past a given gateway. Three simple states allow you to determine if a packet has passed through the firewall or not:
If an ICMP type 11 code 0 (TTL exceeded in transit) message is received, the packet passed through the filter, and a response was later generated.
If the packet is dropped without comment, it was probably done at the gateway.
If an ICMP type 3 code 13 (communication administratively prohibited) message is received, a simple filter such as a router ACL is being used.
If the packet is dropped without comment, this doesn't necessarily mean that traffic to the target host and port is filtered. Some firewalls know that the packet is due to expire and send the expired message whether the policy allows the packet or not.
firewalk works effectively against hosts in true IP routed environments, as opposed to hosts behind firewalls using network address translation (NAT). I recommend reading the firewalk white paper written by Mike Schiffman and Dave Goldsmith, available from http://www.packetfactory.net/projects/firewalk/firewalk-final.pdf.
Example 4-10 shows firewalk being run against a host to assess filters in place for a selection of TCP ports (21, 22, 23, 25, 53, and 80). The utility requires two IP addresses: the gateway (gw.test.org in this example) and the target (www.test.org in this example) that is behind the gateway.
# firewalk -n -S21,22,23,25,53,80 -pTCP gw.test.org www.test.org Firewalk 5.0 [gateway ACL scanner] Firewalk state initialization completed successfully. TCP-based scan. Ramping phase source port: 53, destination port: 33434 Hotfoot through 220.127.116.11 using 18.104.22.168 as a metric. Ramping Phase: 1 (TTL 1): expired [192.168.102.254] 2 (TTL 2): expired [22.214.171.124] 3 (TTL 3): expired [126.96.36.199] Binding host reached. Scan bound at 4 hops. Scanning Phase: port 21: A! open (port listen) [188.8.131.52] port 22: A! open (port not listen) [184.108.40.206] port 23: A! open (port listen) [220.127.116.11] port 25: A! open (port not listen) [18.104.22.168] port 53: A! open (port not listen) [22.214.171.124] port 80: A! open (port not listen) [126.96.36.199] Scan completed successfully.
The tool first performs an effective traceroute to the target host in order to calculate the number of hops involved. Upon completing this initial reconnaissance, crafted TCP packets are sent with specific IP TTL values. By analyzing the responses from the target network and looking for ICMP type 11 code 0 messages, an attacker can reverse-engineer the filter policy of gw.test.org.
As port scans and network probes are launched, you can passively monitor all traffic using ethereal or tcpdump. Often, you will see ICMP responses from border routers and firewalls, including:
ICMP TTL exceeded (type 11 code 0) messages, indicating a routing loop
ICMP administratively prohibited (type 3 code 13) messages, indicating a firewall or router that rejects certain packets in line with an ACL
These ICMP response messages give insight into the target network's setup and configuration. It is also possible to determine IP alias relationships in terms of firewalls performing NAT and other functions to forward traffic to other hosts and devices (for example, if you are probing a public Internet address but see responses from a private address in your sniffer logs).
Various operating platforms have their own interpretations of IP-related standards when receiving certain types of packets and responding to them. By analyzing responses from Internet-based hosts carefully, attackers often can guess the operating platform of the target host via IP fingerprinting, usually by assessing and sampling the following IP responses:
TCP FIN probes and bogus flag probes
TCP sequence number sampling
TCP WINDOW sampling
TCP ACK value sampling
ICMP message quoting
ICMP ECHO integrity
Responses to IP fragmentation
IP TOS (type of service) sampling
Originally, tools such as cheops and queso were developed specifically to guess target system operating platforms; however, the first publicly available tool to perform this was sirc3, which simply detected the difference between BSD-derived, Windows, and Linux TCP stacks.
Today, nmap performs a large number of IP fingerprinting tests to guess the remote operating platform. To enable IP fingerprinting when running nmap, simply use the -O flag in combination with a scan type flag such as -sS, as shown in Example 4-11.
# nmap -O -sS 192.168.0.65 Starting nmap 3.45 ( www.insecure.org/nmap/ ) Interesting ports on 192.168.0.65: (The 1585 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 88/tcp open kerberos-sec 110/tcp open pop-3 135/tcp open loc-srv 139/tcp open netbios-ssn 143/tcp open imap2 389/tcp open ldap 445/tcp open microsoft-ds 464/tcp open kpasswd5 593/tcp open http-rpc-epmap 636/tcp open ldapssl 1026/tcp open LSA-or-nterm 1029/tcp open ms-lsa 1352/tcp open lotusnotes 3268/tcp open globalcatLDAP 3269/tcp open globalcatLDAPssl 3372/tcp open msdtc Remote OS guesses: Windows 2000 or WinXP Nmap run completed -- 1 IP address (1 host up)
If TCP sequence numbers are generated in a predictable way by the target host, then blind spoofing and hijacking can occur (although this is usually limited to internal network spaces). Older Windows operating platforms suffer from this because the sequence numbers are simply incremented instead of randomly generated.
If the IP ID value is incremental, the host can be used as a third party to perform IP ID header scanning as discussed in Section 188.8.131.52. IP ID header scanning requires the ID values returned from the third party to be incremental so that accurate scan results can be gathered.
Example 4-12 shows nmap being run in verbose mode (-v) with TCP/IP fingerprinting (-O). Setting both options shows the results of both TCP and IP ID sequence number predictability tests.
# nmap -v -sS -O 192.168.102.251 Starting nmap 3.45 ( www.insecure.org/nmap/ ) Interesting ports on cartman (192.168.102.251): (The 1524 ports scanned but not shown below are in state: closed) Port State Service 25/tcp open smtp 53/tcp open domain 8080/tcp open http-proxy Remote OS guesses: Windows 2000 RC1 through final release TCP Sequence Prediction: Class=random positive increments Difficulty=15269 (Worthy challenge) IPID Sequence Generation: Incremental Nmap run completed -- 1 IP address (1 host up) scanned in 1 second