The Art of Unspoofing Introduction The amount and frequency of denial of service attacks are escalating. It's becoming harder to track down the source who initiates them due to trace-evasion techniques. A raw interface to the networking stack allows anyone to send spoofed packets to a target host, eliminating the ability of its administrator to determine the origin of the attack. In today's world of e-commerce and globalization, the attacks and the inability to determine their source can be devastating. It gives small companies a bad name, and destroys the good reputations of larger companies. The ability to track down the source that uses spoofing techniques will certainly increase the chance to catch those attacking, and will force people to think of more intricate ways to attack servers on the net. This paper describes a few ways to track down these types of attacks up to the last link in the chain (the attacker himself), or at least his ISP. The Resolution Theory The idea is simple. Usually, when a denial of service attack is initiated against a target host, it's something like: # ./attack target.com In order to send the spoofed packets to target.com, the attackers nameserver has to resolve its domain name to an IP address, and only then can it inject the malicious packets. In theory, the nameservers for target.com will receive packets originating from the true source host of the attack or their nameserver. If we keep a log of these DNS queries, we could later cross-reference logs of the attack and the queries, look for equal or very small differences in the timestamps, and in most cases we'll have a certain match. We must also be careful in what we do log; too much data can be just as useless as not enough. If we just log all external hosts attempting to resolve an internal host, this should cut down the amount of possibilities considerably. How does this help us trace the attacker? Assuming the attacker uses his ISPs nameservers, we can tell his ISP from our logs, contact them, and have them do the cross-referencing. In fact, once we have a source host, we can contact its owners, and have them look at logs and do the crossreferencing for the respective times of the attack. In short: The host we have in our logs is either the attacker himself doing the DNS query, or a nameserver he used to perform the query. In either case, assuming proper logging is in place, we have the true source of the attack. The Connectivity and Routing Request Theory Many attackers will check connectivity and routing of their target before or after launching an attack. Most of the time this is done with traceroute and ping. All we have to do is log incoming UDP packets on ports 33434 to 33524, and ICMP echo packets. We can later use this data along with the Bind resolution requests to cross reference and find the source of the attack. Little Black Dots We figured out this simple way of tracing spoofed packets after looking at code of several of the most popular denial of service programs. Almost all of the programs contain host resolving code. Here are a few examples to where gethostbyname() is used to query the nameservers defined in /etc/resolv.conf to resolve the target host: smurf.c: if ((he = gethostbyname(argv[1])) == NULL) { bonk.c: res = gethostbyname (host_name); land.c: if ((hoste = gethostbyname (land_host)) != NULL) pepsi.c: hp = gethostbyname(cp); Even though this method is pretty effective, it might be a little difficult to grep through the querying hosts on busy servers. There could be hundreds of requests in just a few seconds, hence making it difficult to decide which host is associated with the attacker. To bypass, or at least avoid, this obstacle, we could take advantage of the TTL field in the IP header. As you know, on every hop a packet passes, its TTL is decreased by one. Most denial of service programs use an initial TTL of 255, which is also the default value of the TTL field for outgoing packets on many IP stack implementations. Now let's say we have received spoofed packets with TTL of 248, and 10 resolution requests at the same time the attack started. We could traceroute to each of the hosts that queried us, and count hops. It's very likely that there will be at least one host that is located 7 hops from us (255 - 248), and is related to the attack. Either way (IE: even if we get more than one host that is 7 hops away) this technique narrows down our search for the attacker. This method is, as denial of service programs are becoming more sophisticated over time, becoming less accurate -- for example, in a case of a random TTL for each spoofed packet. A Quick Note on Unspoofing and Nameserver Caching ISC's BIND nameserver, like all nameservers, will cache data. Caching is required for recursion, and is a great help in both DNS performance and bandwidth savings. Unfortunately, this can potentially break unspoofing, as the perpetrator of the denial of service attack may be using a nameserver that has a cached record. For example, if the attacker was using Earthlink, and wanted to attack www.cnn.com, it would be unlikely that Earthlinks nameservers would query CNN's nameservers as CNN is a popular site that many people visit. While you cannot disable caching as it is needed for recursion, you can limit it with the following options (Bind 9 only): max-cache-ttl (Bind 9.X) and max-cache-size (Bind 9.2 and up). Please consult the Bind Administrators manual for the proper usage of these options. Who Needs It? Implementing this idea could be very useful in some places, but also pretty useless in others. * ISPs -- ISPs who'd like to keep out of lawsuits against them and their clients after a malicious user performed a denial of service attack. Also, ISPs with little bandwidth who would like to make sure the available bandwidth is put to good use, and not abused. * Public DNS providers -- Today there are many public DNS services providers. If malicious users would use their servers to initiate a denial of service attack, they might be in danger of being shut down. It could be for the best that they will know about the attackers as well. * Companies -- Many companies today have their own nameservers for their websites. They could use this technique to be able to track down attacks, if any, that are performed on their networks and servers. * Home users (1) -- Most, or pretty much all, of the home users don't need to implement this technique. It's highly unlikely that their computers will be used to resolve a target host. 1. It's important to say that many different variations of UNIX (including Linux, several BSD distributions, and others) come with a nameserver that is working out-of-the-box. In these cases, a malicious attacker could use the nameserver of an innocent victim as a bouncing point for his DNS query -- making it contact the targets nameservers itself, thus avoiding of being logged. If that's the case, the home user might want to either shut down the DNS server or implement this method. Proof of Concept To implement this idea we've created patches for the most popular freely available DNS server software -- ISC Bind. Diffs, installation instructions, etc., are available at http://www.innu.org/~sean/patches/. Versions exist for 8.3.3 and 4.9.9 as of the writing of this article. -- Sean Trifero sean@innu.org http://www.innu.org/~sean Brian Knox brian@innu.org http://www.innu.org/~brian