Attacks based on the distributed denial of service (DDoS) model are, unfortunately, common practice, often used to extort protection money or sweep unwanted services off the web. Currently, such attacks can reach bandwidths of 300GBps or more. Admins usually defend themselves by securing the external borders of their own networks and listening for unusual traffic signatures on the gateways, but sometimes they fight attacks even farther outside the network – on the Internet provider's site – by diverting or blocking the attack before it overloads the line and paralyzes the victim's services.

In the case of cloud solutions and traditional hosting providers, the attackers and their victims often reside on the same network. Thanks to virtualization, they could even share the same computer core. In this article, I show you how to identify such scenarios and fight them off with software-defined networking (SDN) technologies.

Detecting Space Invaders

To detect DoS attacks, you can evaluate network usage data by collecting the data of routers that act as gateways via SNMP with analysis platforms such as Arbor's Peakflow [1] or Flowmon's Collector [2] or by having the information sent to you via the NetFlow or IP flow information export (IPFIX) protocol. The second choice works more precisely, because it delivers data for each individual connection, including the source and destination IP addresses, ports, and IP protocol information, so you can detect variations in the connection patterns. SNMP-only counters do not necessarily offer such options, depending on the management information base (MIB) used [3]. Figure 1 shows a typical setup that you could use to identify malicious connections. Note that collecting and providing data on the routers produces CPU load.

Figure 1: The analysis platform retrieves data from the routers in the network and on the network edge to detect possible DDoS attacks.

In most cases, the Internet connection depends on the day of the week, time of day, and role of the company using it, making it difficult to establish static detection rules. Limits are set either too narrow or too wide and thus can let an attack through. A better approach is to perform static analysis on normal traffic over a longer period of time and under normal operating conditions. The resulting rules will handle the usual performance peaks but ideally also detect attacks.

Countermeasures

The easiest defense against a DoS attack would be to block the source IP of the incoming traffic. In the case of a DDoS attack, this is not so easy. Because the first D stands for "distributed," the attacks come from many different source IPs. Two more blocking options remain: One is to block the destination IPs, and the other is to filter on the destination ports, although the attack needs to be structured appropriately for this to work.

If the attacks are only aimed at clogging the pipe, attackers often use reflection attacks, which misuse services such as DNS or NTP on the rebound by sending small requests that the services respond to with overly long responses. In their requests, the attackers enter the IP address of the victim as the sending IP address; the long responses then flood the victim's connections.

If the victim uses the services leveraged for the attack (e.g., NTP or DNS) exclusively externally or exclusively internally, a filter can block the unwanted packets. In the case of flooding via NTP, you could, for example, enter Any as the source address for the filter and the IP address of the victim as the destination using a source port of 123 and the UDP protocol. That would weed out unwanted packages without interfering with the victim's services, such as web servers.

The Thick End

Thus the theory. In practice, it is typically a hopeless cause to try to fend off an attack with 100GBps bandwidth on a 1 or 10GBps link. Until a corresponding filter protects the internal infrastructure, the line is already overloaded. Although the attack does not affect the internal servers, you will not reach anyone on the Internet.

For effective defense you need to take up a position at the thick end of the line, and you have a choice of several approaches. Cloud mitigation means the Internet provider uses the Border Gateway Protocol (BGP) to redirect all traffic through a kind of Internet washing machine before it reaches the attack victim's server.

The washing machine cleans the traffic with the help of special appliances, which are optimized for DDoS defense – in contrast to traditional firewalls – and then forwards the safe traffic through a tunnel to the victim's server. This adds some latency, but users will hardly notice it in most cases. Individual providers offer this protection directly to their customers so that a redirect is not necessary.

For larger connections that also use BGP internally, it is possible to configure a null route on the loopback device on the router for the attacked targets and to propagate this to the outside (i.e., to providers) [4]. The disadvantages are that the ISPs need to agree to this plan; the approach knocks the complete IP address off the web and all services provided through it. Usually, you also need to act on far larger network blocks, because BGP filters do not accept small routing table entries.