Using Emulation and More to Analyze Network Security - Low-Level IP Assessment

(Page 4 of 4 )

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:

1. Uptime of target hosts (by analyzing the TCP timestamp option)
   
2. TCP services that are permitted through the firewall (by analyzing responses to TCP and ICMP probes)
   
3. TCP sequence and IP ID incrementation (by running predictability tests)
   
4. 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.

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 an RST/ACK packet is received, the probe packet was rejected by either 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.

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 responsive 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. By analyzing responses at a low level, it is often possible to gain insight into the filter configuration at the network level. The tool is complex to use and has many possible options. Table 4-1 lists the most useful flags for performing low-level TCP assessment.

Table 4-1. 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 use of 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 on192.168.0.1using 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 216.239.39.99): S set, 40 headers + 0 data
  ip=216.239.39.99 ttl=128 id=289 sport=80 flags=SAP seq=0 win=64240
  ip=216.239.39.99 ttl=128 id=290 sport=80 flags=SAP seq=1 win=64240
  ip=216.239.39.99 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

Please check back next week for the conclusion to this article.

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

Comments On: Using Emulation and More to Analyze Network Security

· This article is an excerpt from the book "Network Security Assessment, Second...   >>> Post your comment now!

Buy this book...

This article is excerpted from chapter four of Network Security Assessment, Second Edition, written by Chris McNab (O'Reilly, 2007; ISBN: 0596510306). Check it out today at your favorite bookstore. Buy this book now.