In the book, Inside Firewalls by Robert Ziegler (New Riders), I commented that I continue to be astounded by the security provided by Network Address Translation (NAT). My most important files are on a vmware version of Linux 7.2 on my Windows laptop, and the Linux system is behind a NAT. So, if attackers can get through my home perimeter defenses, which also include a NAT, and break into my XP laptop, they still have another NAT to go through. With appliance firewalls available as cheap as $300, you can afford a number of NATs in your organization, which will foil most of this scanning. There is also a strong argument that nothing penetrates a well-configured, proxy-based firewall (although we will dispute this in a moment). None of the deception tools will elude a well-trained analyst with an IDS that collects all the traffic and has a supporting database. If your site has chosen a lesser path, you may be in for a wild ride.

As we get ready to launch into some traces of stealth techniques, take a minute to read the opening comment from the original 1997 jackal.c source code. /* Jackal -Stealth/FireWall scanner. With the use of halfopen ports and sending SYNC (sometimes additional flags like FIN) one can scan behind a firewall. And it shouldnt let the site feel we're scanning by not doing a 3- way-handshake we hope to avoid any tcp-logging. Credits: Halflife, Jeff (Phiji) Fay, Abdullah Marafie. Alpha Tester: Walter Kopecky. Results: Some firewalls did allow SYN | FIN to pass through. No Site has been able to log the connections though during alpha testing. ShadowS [e-mail] Copyleft (hack it i realy dont care). */

It was a brilliant idea! If the filtering router tests for SYN, feed it a SYN/FIN. However, the statement that jackal had never been logged by any site misses the mark. In Appendix A, "Exploits and Scans to Apply Exploits," you saw the IMAP traces with the SYN/FIN set, which were detected by the Shadow system. Competent intrusion-detection systems were able to log and analyze anything sent by jackal (or hping or nmap). In fact, today when attackers set SYN/FIN, they make our job easy.

Explicit Stealth Mapping Techniques

The two well-known explicit mapping techniques are the SYN/ACK and the FIN scan. Both of these generate a RESET, if they hit an active host. They also get an ICMP error message back if the host is unreachable. Explicit stealth mapping is more efficient than inverse mapping (described later), but is possibly more obvious.

FIN Scan

I have never detected a FIN scan in the wild and have chosen not to simulate one. In the case of a FIN scan, one would detect a large number of packets with the FIN flag set where there was no three-way handshake ever established. We have already discussed using a database to find FTP bounce. A good intrusion-analysis system should provide the capability to look for spurious traffic such as FINs, to connections that were never established. I have seen ACKs only and have seen them penetrate a Check Point firewall.

Inverse Mapping

Inverse mapping techniques can compile a list of networks, or hosts, that are not reachable and then use the converse of that map to determine where things probably are. We will also show a DNS example of all replies and no queries. Before we go on, though, if you absolutely cannot do NAT and must use public IP addresses, make sure you do not allow ICMP unreachables out of your network. That will not stop all inverse mapping techniques, but it will quench a large number of them. As you look at the trace that follows, keep this in mind: the answers by router.mynet.net are doing all the harm:

02:58:05.490 stealth.mappem.com.25984 > 172.30.69.23.2271: R 0:0(0) ack 674719802 win 0

02:59:11.208 stealth.mappem.com.50620 > 172.16.7.158.1050: R 0:0(0) ack 674719802 win 0

02:59:20.670 stealth.mappem.com.19801 > 192.168.184.174.1478: R 0:0(0) ack 674719802 win 0

02:59:31.056 stealth.mappem.com.7960 > 192.168.242.139.1728: R 0:0(0) ack 674719802 win 0

02:59:42.792 stealth.mappem.com.16106 > 172.16.102.105.1008: R 0:0(0) ack 674719802 win 0

03:00:50.308 stealth.mappem.com.8986 > 172.16.98.61.1456: R 0:0(0) ack 674719802 win 0

03:00:58.939 stealth.mappem.com.35124 > 192.168.182.171.1626: R 0:0(0) ack 674719802 win 0

03:00:58.940 router.mynet.net > stealth.mappem.com: icmp: host 192.168.182.171 unreachable

Answers to Domain Queries

Another variation of inverse mapping is shown here. The probing computer sends answers to domain questions that were never asked. The goal is to stumble across a subnet or host that doesn't exist, which will generate an ICMP unreachable message. As stated earlier, this pattern tends to evade detection. It can be found with scan detect code if the attacker gets greedy and probes too many hosts too quickly. It can also be detected by retrospective analysis scripts or database searches for application state violations. Here is the example of inverse mapping:

05:55:36.515566 stealth.com.domain > 172.29.63.63.20479: udp 06:46:18.542999 stealth.com.domain > 192.168.160.240.12793: udp 07:36:32.713298 stealth.com.domain > 172.29.185.48.54358: udp 07:57:01.634613 stealth.com.domain > 254.242.221.165.13043: udp 09:55:28.728984 stealth.com.domain > 192.168.203.163.15253: udp 10:38:53.862779 stealth.com.domain > 192.168.126.131.39915: udp 10:40:37.513176 stealth.com.domain > 192.168.151.126.19038: udp 10:44:28.462431 stealth.com.domain > 172.29.96.220.8479: udp 11:35:40.489103 stealth.com.domain > 192.168.7.246.44451: udp

11:35:40.489103 stealth.com.domain > 192.168.7.246.44451: udp 11:35:40.489523 router.mynet.net > stealth.com:

icmp: host 192.168.7.246 unreachable

Because IP spoofing, usually part of a denial-of-service attack, is so common, you may be asking, "Why isn't the explanation for this IP spoofing of the 172.29, 192.168, and so forth addresses and directing them to stealth.com?" Couldn't this just be seeing the echoes of this activity directed back to our network? The problem is that this doesn't resemble normal DNS responses. It doesn't have any indications that some kind of DNS query was issued.

To investigate this further, you might try to find out whether stealth.com is really a DNS server. You use the nslookup command and change servers to stealth.com and try to resolve any address. If it works, you know that stealth.com is a true DNS server and the mystery intensifies. (Tragically, nslookup, at least on UNIX, is being deprecated by the more obscure dig program.) If it doesn't respond, chances are it is not a DNS server, and it really is the aggressor. It is also possible that it is a DNS server, but you might not have access to it.

Answers to Domain Queries, Part 2

The following activity is similar to what you just saw because both use source port of 53 or domain. This output is TCP and came from multiple different sources, however, unlike the preceding activity. Any guesses about what is going on here?

11:19:30.885069 host1.corecomm.net.53 > myhost1.com.21: S 7936:7936(0) win 1024

11:17:29.375069 host1.corecomm.net.53 > myhost1.com.139: S 7936:7936(0) win 1024

11:15:32.115069 host1.corecomm.net.53 > myhost1.com.23: S 7936:7936(0) win 1024

11:11:17.485069 host1.corecomm.net.53 > myhost1.com.43981: S 7936:7936(0) win 1024

11:09:12.945069 host1.corecomm.net.53 > myhost1.com.880: S 7936:7936(0) win 1024

12:01:05.060000 host70.corecomm.net.53 > pc112.com.880: S 1738:1738(0) win 1024

12:03:24.820000 host70.corecomm.net.53 > pc112.com.139: S 1738:1738(0) win 1024

12:06:12.620000 host70.corecomm.net.53 > pc112.com.21: S 1738:1738(0) win 1024

12:09:09.940000 host70.corecomm.net.53 > pc112.com.43981: S 1738:1738(0) win 1024

12:09:57.960000 host70.corecomm.net.53 > pc112.com.23: S 1738:1738(0) win 1024

This appears to be a scan of myhost1.com, pc112.com, and many other hosts not shown in this abbreviated output of some common destination ports such as 21 (FTP), 23 (telnet), and 139 (NetBIOS Session Manager). But, there are some funky destination ports along with those common ones that aren't readily identifiable, such as 43981 and 880. You can round up all the usual suspect explanations for the unconventional ports, but in this case, your analysis should concentrate more on the source port used.

TCP source port 53 might be allowed into many networks because this can be indicative of activity from a long DNS response. Remember from Chapter 6, "DNS," that UDP DNS responses of more than 512 bytes are reissued to the DNS server to destination port TCP 53. When the response returns to your network, the source port will be 53 and you need to allow that back in to receive that response. A smart network administrator qualifies this so that it is allowed back in only if it was established inside the network of origin, and only if the destination port is greater than 1023 (indicative of an ephemeral port), which is the case in the long DNS responses.

That is not the case in the preceding scan, but the scanner is banking on the packet-filtering device being open on source port 53 without any further qualification. This way, the scanner might circumvent a normally protective packet-filtering device.

It is interesting to note that the TCP sequence numbers you see in the scan are repeated for each of the same source-to-destination port scans. These should change for each new TCP segment created. Another forensics tidbit about this scan that is not obvious unless you look at many more records than are shown, gives some insight into the nature of the TCP sequence number crafting. The preceding scan shows two TCP sequence numbers: 7936 and 1738.