Mirror Magazine

One of the most fundamental problems faced when responding to DoS attacks is to differentiate between legitimate service requests and attack traffic, and to service legitimate requests and drop attack packets. A failure to distinguish between the two could lead to legitimate requests not being served thus leading the ‘denial of (legitimate) services’ either as a result of the attack or as a consequence of a response to the attack.

Identifying a DoS attack is also a challenge as it could be difficult to distinguish between a DoS attack and a sudden increase in legitimate traffic. This task is further complicated by IP spoofing, which makes it very difficult to differentiate between attack traffic and legitimate traffic. The difference between heavy network traffic and a DoS attack can be ambiguous at the best of times.

Detection of a DoS attack is complicated, given the above two reasons. A DoS attack may not be detected until services or service quality actually breaks down. Furthermore, the exact point at which legitimate service requests are not met as a result of an ‘attack’ on the system or network is difficult to predict or determine. An increase in legitimate traffic may cause DoS. However, there is no way of avoiding the degradation of quality of service under such circumstances other than by increasing bandwidth.

Short-term and long-term responses to DoS attacks are differentiated not by an absolute time-frame, but by the type of action taken and its objective. The objective of a short-term response is to prevent damages to the victim, shield the victim from the attack, and make critical services available to legitimate users. Short-term responses are targeted towards averting damages caused by the DoS attack to the victim network or system, shielding the victim from the attack and ideally – making critical services available to at least a fraction of legitimate users until the attack is neutralised.

Presently, the victim has limited protection from a DoS attack. Some filtering techniques such as History-based filtering can be effective as short-term responses to DoS attacks. History-based IP filtering assumes that DoS attackers randomly ‘spoof’ IP addresses in attack packets. It has been found that more than 86% of traffic in a code-red DoS attack have never appeared before the attack, and therefore assumed to be attack traffic. During a DoS attack, therefore, packets are filtered, based on whether their source addresses have been logged at the site before.

If the attack is unsophisticated, there might be a specific signature to the traffic. A careful examination of captured packets may reveal a trait on which some rules can be based in router access control lists or firewalls, in order to filter out attack traffic. Additionally, a large amount of traffic may originate from a specific origin point, which could be temporarily blocked, allowing a portion of legitimate traffic through. This could block legitimate packets as well, but this may be an unavoidable sacrifice. However, depending on the method of attack, this option may be unavailable, if for example, the participants' IP addresses are spoofed.

An alternative option, one which might be available to larger companies and networks, is to increase hardware power or bandwidth at the flood, and wait out the attack. This, however, is neither the best solution, nor the least expensive one, but it may provide a temporary solution nevertheless. The victim could also attempt to identify a type of attack, and take action if possible, to shield the attack, for example by disabling ICMP responses during a ping-flood.

The easiest way to survive an attack is to have planned for the attack. Having a separate emergency block of IP addresses for critical servers with a separate route can be invaluable for larger companies with critical network needs. A separate route such as a DSL connection may not be too extravagant for a larger corporation, and it can be used for load balancing or sharing under normal circumstances and switched to emergency mode in the event of an attack.

Next week, we will discuss other types of short-term responses against DoS attacks that can be made by the Host network or ISP. You too can be a part of this discussion about DoS attacks by writing into technopage@gmail.com