4.5 Low-Level IP Assessment

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.

4.5.1 Analyzing Responses to TCP Probes

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).

ICMP type 3 code 13

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

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.

Table 4-3. hping2 options



-c <number>

Send a specific number of probe packets

-s <port>

Source TCP port (random by default)

-d <port>

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

HPING (eth0 S set, 40 headers + 0 data

ip= ttl=128 id=275 sport=139 flags=SAP seq=0 win=64240

ip= ttl=128 id=276 sport=139 flags=SAP seq=1 win=64240

ip= 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 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 S set, 40 headers + 0 data

ip= ttl=128 id=289 sport=80 flags=SAP seq=0 win=64240

ip= ttl=128 id=290 sport=80 flags=SAP seq=1 win=64240

ip= 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

HPING (eth0 S set, 40 headers + 0 data

ip= ttl=128 id=283 sport=139 flags=R seq=0 win=64240

ip= ttl=128 id=284 sport=139 flags=R seq=1 win=64240

ip= 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 S set, 40 headers + 0 data

ICMP unreachable type 13 from

ICMP unreachable type 13 from

ICMP unreachable type 13 from

TCP probe packets are dropped in transit:

# hping2 -c 3 -s 53 -p 80 -S

HPING (eth0 S set, 40 headers + 0 data firewalk

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.

Example 4-10. Using firewalk to assess network filtering
# 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 using as a metric.

Ramping Phase:

 1 (TTL  1): expired []

 2 (TTL  2): expired []

 3 (TTL  3): expired []

Binding host reached.

Scan bound at 4 hops.

Scanning Phase:

port  21: A! open (port listen) []

port  22: A! open (port not listen) []

port  23: A! open (port listen) []

port  25: A! open (port not listen) []

port  53: A! open (port not listen) []

port  80: A! open (port not listen) []

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.

4.5.2 Passively Monitoring ICMP Responses

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).

4.5.3 IP Fingerprinting

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.

Example 4-11. Using nmap to perform IP fingerprinting
# nmap -O -sS

Starting nmap 3.45 ( www.insecure.org/nmap/ )

Interesting ports on

(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)

4.5.4 TCP Sequence and IP ID Incrementation

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 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.

Example 4-12. Using nmap to test TCP and IP ID sequences
# nmap -v -sS -O

Starting nmap 3.45 ( www.insecure.org/nmap/ )

Interesting ports on cartman (

(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