the battle against DDoS attacks: our experience (part 1)

Aside from a few altered dates, locations, and names of various parties involved, all the information presented here is fact.

I would like to extend a special thanks to Emmanuel Besson and Pierre Ansel from Orange Labs for all of the information they provided: without them, we wouldn’t have this blog post!

Now let’s dive right into the heart of the matter. It all started in May 2008.

late May 2008: the attack begins

Operations teams at an Orange subsidiary outside France alert the Group’s security teams: several distributed denial-of-service (DDoS) attacks have struck the corporate website of one of the subsidiary’s major customers, causing repeated unavailability of services hosted for legitimate users. At the same time, two other attacks target infrastructure services, notably the local DNS service.

The Group’s security experts quickly assemble a crisis team. First, it gathers as much information as possible on the origin, nature, and targets of the attack. Next, it prepares and quickly enacts measures that limit the damage caused by the cyber-attack, or even possibly eliminate the threat.

The crisis team sets the following two priorities:

1. completely identify the attack: this means tracing the attack to try to find its origin, or at least the peering points where it entered the infrastructure to target the customer
2. evaluate the means available to stop the attack. Three solutions are taken into consideration:
   • work with the Internet service providers (ISPs) conveying the attack (black hole filtering technique) to block traffic previously identified as located closest to sources
   • strengthen local defenses by changing the parameters of some firewalls or tightening attacked server configurations
   • provide the local subsidiary with complementary active probes to analyze and block the attack

a week later: first countermeasures

Thanks to detection resources placed on the international networks, the three IP addresses targeted by the attack are identified, along with no fewer than 16 core routers relaying the traffic involved in the attack, seven peering points and as many partner operators.

The team immediately contacts the partner operators, asks them to trace the origins of the attack and apply their blocking mechanisms, if available.

At the same time, operations teams launch a black hole for one of the addresses targeted by the attack. In short, this technique consists of modifying the network infrastructure’s routing configurations so that every router trashes all incoming traffic intended for a given IP address. This seems to eliminate the first element of the attack.

Meanwhile, with the help of Group security experts, local teams reconfigure the firewalls protecting their DNS infrastructure and managing to block the second element of the attack.

However, the last element of the DDoS attack targeting the end customer remains, since the previous two solutions aren’t applicable in this case. Experts suggest using a traffic Cleaning Center solution developed through their work and that specifically counters DDoS attacks.

flashback: the decisive solution

The proposed solution makes it possible to manipulate traffic so as to clean it in real-time using intelligent filtering functions.

The fundamental difficulty with DDoS attacks lies in their apparent legitimacy, as malicious requests use “authorized” ports and produce packets that appear “well-formed”. For this reason, firewalls and other Intrusion Prevention Systems (IPS) prove ineffective against the majority of DDoS attacks.

The experts’ model optimizes the use of “selective sorting” algorithms for traffic (so it can run at several Gbps). Positioned so as to cut off the influx directed toward the victim, it only admits the purified and legitimate portion to the machine.

With this system, it’s possible to protect several critical services that are simultaneously attacked. In fact, the definition of a protected service can be very broad (a whole section of traffic) or more targeted, and even very specific (certain types of requests directed to a given machine). Of course, the module comes equipped with an interface for real-time monitoring and rapid changes in protection settings.

For these reasons, the subsidiary requests this technology to protect its customers under attack.

early June 2008: the attack stops

Once the attack has ended, the crisis team approves the experimental launch of the Cleaning Center, which goes into effect in mid-July. It’s positioned in “monitoring” mode at the subsidiary’s peering points and receives the traffic intended for all the local operator’s customers who had requested protection.

Local teams receive training so they can activate the “protection” mode in case of a new attack.

Have the attackers stopped? No. As you’ll soon see, they attack again!

Jean-François

photo credit: © photobank.kiev.ua - Fotolia.com

This blog post was originally published in French here.