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)

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:

TCP SYN/ACK

If a SYN/ACK packet is received, the port is
considered open.

TCP RST/ACK

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.

Nothing

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.

4.5.1.1 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

Option

Description

-c <number>

Send a specific number of probe packets

-s <port>

Source TCP port (random by default)

-d <port>

Destination TCP port

-S

Set the TCP SYN flag

-F

Set the TCP FIN flag

-A

Set the TCP ACK flag

Here's a best practice way to use
hping2 to assess a specific TCP port:

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

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

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

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