Methods of IP Network Scanning - Stealth TCP Scanning Methods
(Page 4 of 4 )
Stealth scanning methods take advantage of idiosyncrasies in certain TCP/IP stack implementations. Such techniques aren’t effective at accurately mapping the open ports of some operating systems, but they do provide a degree of stealth when susceptible platforms are found.
Inverse TCP flag scanning
Security mechanisms such as firewalls and IDS usually detect SYN packets being sent to sensitive ports of target hosts. To avoid this detection, we can send probe packets with different TCP flags set.
Using malformed TCP flags to probe a target is known as an inverted technique because responses are sent back only by closed ports. RFC 793 states that if a port is closed on a host, an RST/ACK packet should be sent to reset the connection. To take advantage of this feature, attackers send TCP probe packets with various TCP flags set.
A TCP probe packet is sent to each port of the target host. Three types of probe packet flag configurations are normally used:
- A FIN probe with the FIN TCP flag set
- An XMAS probe with the FIN, URG, and PUSH TCP flags set
- A NULL probe with no TCP flags set
Figures 4-6 and 4-7 depict the probe packets and responses generated by the target host if the target port is found to be open or closed.
Figure 4-6. An inverse TCP scan result when a port is open
Figure 4-7. An inverse TCP scan result when a port is closed
The RFC standard states that if no response is seen from the target port, either the port is open or the server is down. This scanning method isn’t necessarily the most accurate, but it is stealthy; it sends garbage that usually won’t be picked up to each port.
For all closed ports on the target host, RST/ACK packets are received. However, some operating platforms (such as those in the Microsoft Windows family) disregard the RFC 793 standard, so no RST/ACK response is seen when an attempt is made to connect to a closed port. Hence, this technique is effective against some Unix-based platforms.
Tools that perform inverse TCP flag scanning. Nmap can perform an inverse TCP flag port scan, using the following flags:-sF(FIN probe),-sX(XMAS probe), or
-sN(NULL probe).
Vscan is another Windows tool you can use to perform inverse TCP flag scanning. The utility doesn’t require installation of WinPcap network drivers; instead it uses raw sockets within Winsock 2 (present in Windows itself). Vscan is available from http://examples.oreilly.com/networksa/tools/vscan.zip.
ACK flag probe scanning
A stealthy technique documented by Uriel Maimon in Phrack Magazine, issue 49, is that of identifying open TCP ports by sending ACK probe packets and analyzing the header information of the RST packets received from the target host. This technique exploits vulnerabilities within the BSD-derived TCP/IP stack and is therefore only effective against certain operating systems and platforms. There are two main ACK scanning techniques:
- Analysis of the time-to-live (TTL) field of received packets
- Analysis of the WINDOW field of received packets
These techniques can also check filtering systems and complicated networks to understand the processes packets go through on the target network. For example, the TTL value can be used as a marker of how many systems the packet has hopped through. The Firewalk filter assessment tool works in a similar fashion, available from http://www.packetfactory.net/projects/firewalk.
Analysis of the TTL field of received packets. To analyze the TTL field data of received RST packets, an attacker first sends thousands of crafted ACK packets to different TCP ports, as shown in Figure 4-8.
Figure 4-8. ACK probe packets are sent to various ports
Here is a log of the first four RST packets received using Hping2:
1: host 192.168.0.12 port 20: F:RST -> ttl: 70 win: 0
2: host 192.168.0.12 port 21: F:RST -> ttl: 70 win: 0
3: host 192.168.0.12 port 22: F:RST -> ttl: 40 win: 0
4: host 192.168.0.12 port 23: F:RST -> ttl: 70 win: 0
By analyzing the TTL value of each packet, an attacker can easily see that the value returned by port 22 is 40, whereas the other ports return a value of 70. This suggests that port 22 is open on the target host because the TTL value returned is smaller than the TTL boundary value of 64.
Analysis of the WINDOW field of received packets. To analyze the WINDOW field data of received RST packets, an attacker sends thousands of the same crafted ACK packets to different TCP ports (as shown in Figure 4-8). Here is a log of the first four RST packets received, again using Hping2:
1: host 192.168.0.20 port 20: F:RST -> ttl: 64 win: 0
2: host 192.168.0.20 port 21: F:RST -> ttl: 64 win: 0
3: host 192.168.0.20 port 22: F:RST -> ttl: 64 win: 512
4: host 192.168.0.20 port 23: F:RST -> ttl: 64 win: 0
Notice that the TTL value for each packet is 64, meaning that TTL analysis of the packets isn’t effective in identifying open ports on this host. However, by analyzing the WINDOW values, the attacker finds that the third packet has a nonzero value, indicating an open port.
The advantage of using ACK flag probe scanning is that detection is difficult (for both IDS and host-based systems, such as personal firewalls). The disadvantage is that this scanning type relies on TCP/IP stack implementation bugs, which are prominent in BSD-derived systems but not in many other modern platforms.
Tools that perform ACK flag probe scanning. Nmap supports ACK flag probe scanning, with the–sAand
-sWflags to analyze the TTL and WINDOW values, respectively. See the Nmap manual page for more detailed information.
Hping2 can also sample TTL and WINDOW values, but this can prove highly time-consuming in most cases. The tool is more useful for analyzing low-level responses, as opposed to port scanning in this fashion. Hping2 is available from http://www.hping.org.
Please check back next week for the continuation of 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. |
|
 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.
|
|
