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:
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 ProbesA 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:
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 hping2hping2 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.
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 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 4.5.1.2 firewalkMike 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 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 217.41.132.201 using 217.41.132.161 as a metric. Ramping Phase: 1 (TTL 1): expired [192.168.102.254] 2 (TTL 2): expired [212.38.177.41] 3 (TTL 3): expired [217.41.132.201] Binding host reached. Scan bound at 4 hops. Scanning Phase: port 21: A! open (port listen) [217.41.132.161] port 22: A! open (port not listen) [217.41.132.161] port 23: A! open (port listen) [217.41.132.161] port 25: A! open (port not listen) [217.41.132.161] port 53: A! open (port not listen) [217.41.132.161] port 80: A! open (port not listen) [217.41.132.161] 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 ResponsesAs 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:
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 FingerprintingVarious 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:
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 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) 4.5.4 TCP Sequence and IP ID IncrementationIf 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. Example 4-12. Using nmap to test TCP and IP ID sequences# 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 |
EAN: 2147483647
Pages: 166