Tracing Denial of Service attacks

With the Internet gaining importance as a business infrastructure, the number of attacks on it have also greatly increased. Denial-of-Service attacks like packet flooding attacks are quite frequent. Denial-of-Service or DoS attacks consume the resources of a remote host or network, thereby, denying or degrading service to legitimate users. Such attacks are among the hardest security problems to address because they are simple to implement, difficult to prevent, and hard to trace. While there are several ad hoc traceback techniques in use, they all have significant drawbacks that limit their practical utility.

What is it?

A DoS attack is a stream of information sent to a targeted server with the intention of flooding it until it crashes or can no longer take legitimate traffic. Unlike most other “hacks,” it does not involve the attacker gaining access or entry into the targeted server. For example, if a malicious attacker sends numerous IP packets to a Web Server, it gets into a busy state processing the IP traffic from the hacker. In the mean time, if a genuine user requests for a service from that particular Web Server, the service will be denied to him. A DoS attack can be carried out in many ways. Attackers may “flood” a network with large volumes of data or deliberately consume a scarce or limited resource, such as process control blocks or pending network connections.

Distributed Denial-of-Service (DDoS) attacks are all network-based. Instead of an attacker running a single attack tool, the attacker communicates with many remote attack servers, and these attack servers actually send the packets. In other words, one attacker remotely controls hundreds of attack servers, multiplying the effect of the
DoS.

In the last several years, Internet DoS attacks have increased in frequency, severity and sophistication. Determining the source generating attack traffic is surprisingly difficult due to the stateless nature of Internet routing. Attackers routinely disguise their location using incorrect or spoofed IP source addresses (See separate article on IP spoofing in this issue) and as these packets traverse the Internet their true origin is lost.

In real world crime, the hypothesis that the criminal always leaves something at the crime scene and takes something of the crime scene away with him is the basis for modern forensics. In contrast, network attacks leave no trace evidence as hackers carry out these attacks using electronic packets that have no identifying characteristics except those voluntarily supplied by the sender. But all is not lost. Efforts have been made to trace anonymous packet flooding attacks in the Internet back to their source. Some of them are discussed below. 

Ingress filtering

One way to address the problem of anonymous attacks is to eliminate the ability to forge source addresses. One such approach, called ingress filtering, is to configure routers to block packets that arrive with illegitimate source addresses. This requires a router with sufficient power to examine the source address of every packet, and sufficient knowledge to distinguish between legitimate and illegitimate addresses. Consequently, ingress filtering is the most feasible in customer networks or at the border of ISPs where address ownership is relatively unambiguous and traffic load is low. As traffic is aggregated from multiple ISPs into transit networks, there is no longer enough information to unambiguously deter- mine if a packet arriving on a particular interface has a “legal” source address.

The principal problem with ingress filtering is that its effectiveness depends on widespread, if not universal, deployment. Unfortunately, a majority of ISPs do not implement this service either because they are uninformed or have been discouraged by the administrative burden, potential router overhead and complications with existing services that depend on source address spoofing. A secondary problem is that even if ingress filtering were universally deployed at the customer-to-ISP level, attackers could still forge addresses from the hundreds or thousands of hosts within a valid customer network.

Link testing

Most existing traceback techniques start from the router closest to the victim and interactively test its upstream links until they determine which one is used to carry the attacker’s traffic. Ideally, this procedure is repeated recursively on the upstream router until the source is reached. This technique assumes that an attack remains active until
the completion of a trace. Therefore, this technique is inappropriate for attacks that occur intermittently or modulate their behavior in response to a traceback (it is prudent to assume the attacker is fully informed). There are two common varieties of link testing schemes: input debugging and controlled flooding.

Input debugging

Many routers include a feature called input debugging that allows an operator to filter particular packets on some egress port and determine which ingress port they arrived on. This capability is used to implement a trace as follows: First, the victim must recognize that it is being attacked and develop an “attack signature” that describes a common feature contained in all the attack packets. The victim communicates this signature to a network operator, often via telephone, who then installs a corresponding input debugging filter on the victim’s upstream egress port. This filter reveals the associated input port and, hence, which upstream router originated the traffic. The process is then repeated recursively on the upstream router, until the originating site is reached or the trace leaves the ISP’s border (and hence its administrative control over the routers). In the later case, the upstream ISP must be contacted and the procedure repeated. While such tracing is frequently performed manually, several ISPs have developed tools to automatically trace attacks across their own networks.

The most obvious problem with the input debugging approach, even with automated tools, is the considerable management overhead. Communicating and coordinating with network operators at multiple ISPs requires time, attention and commitment from both the victim and the remote personnel — many of whom have no direct economic incentive to provide aid. If the appropriate network operators are not available, if they are unwilling to assist, or if they do not have the appropriate technical skills and capabilities, then a traceback may be slow or impossible to complete.

Controlled flooding

Burch and Cheswick have developed a link testing a traceback technique that does not require any support from network operators. This technique is called controlled flooding because it tests links by flooding them with large bursts of traffic and observing how this perturbs traffic from the attacker. Using a pre-generated “map” of the Internet, the victim coerces selected hosts along the upstream route into iteratively flooding each incoming link on the router closest to the victim. Since router buffers are shared, packets traveling across the loaded link, including any sent by the attacker, have an increased probability of being dropped. By observing changes in the rate of packets received from the attacker, the victim can infer which link they arrived from. As with other link testing schemes, the basic procedure is then applied recursively on the next upstream router until the source is reached.

While the scheme is both ingenious and pragmatic, it has several drawbacks and limitations. Most problematic among these is that controlled flooding is itself a DoS attack — exploiting vulnerabilities in unsuspecting hosts to achieve its ends. This drawback alone makes it unsuitable for routine use. Also, controlled flooding requires the victim to have a good topological map of large sections of the Internet in addition to an associated list of “willing” flooding hosts. 

Logging

This approach logs packets at key routers and then uses data mining techniques to determine the path that the packets traversed. A useful property of this scheme is that it can trace an attack long after it has completed. 

However, it also has obvious drawbacks, including potentially enormous resource requirements (possibly addressed by sampling) and a large scale inter-provider database integration problem. 

ICMP Traceback

A new traceback proposal has emerged based on the use of explicit router-generated ICMP traceback messages. The principle idea in this scheme is for every router to sample, with low probability (for example, 1/20,000), one of the packets it is forwarding and copy the contents into a special ICMP traceback message including information about the adjacent routers along the path to the destination. During a flooding-style attack, the victim host can use these messages to reconstruct a path back to the attacker. While this scheme has many benefits, there are several disadvantages in the current design that complicate its use. Among these: ICMP traffic is increasingly differentiated and may be filtered or rate limited differently from normal traffic, the ICMP Traceback message relies on an input debugging capability (i.e. the ability to associate a packet with the input port and/or MAC address on which it arrived) that is not available in some router architectures. Finally, it requires a key distribution infrastructure to deal with the problem of attackers sending false ICMP traceback messages. 

Packet marking schemes

Burch and Cheswick mention the possibility of tracing flooding attacks by “marking” packets, either probabilistically or deterministically, with the addresses of the routers they traverse. The victim uses the information in the marked packets to trace an attack back to its source. A router “marks” one or more packets by augmenting them with additional information about the path they are traveling. The victim attempts to reconstruct the attack path using only the information in these marked packets. 

J. Suresh Kumar