This article is more than 1 year old

DDoS attacks: For the hell of it or targeted – how do you see them off?

Cloud-based DDoS defences introduce delays

Distributed Denial of Service (DDoS) attacks can be painful and debilitating. How can you defend against them? Originally, out-of-band or scrubbing-centre DDoS protection was the only show in town, but another approach, inline mitigation, provides a viable and automatic alternative.

DDoS attacks can be massive, in some cases reaching hundreds of Gbits/sec, but those mammoths are relatively rare. For the most part, attackers will flood companies with around 1 Gbit/sec of traffic or less. They’re also relatively short affairs, with most attacks lasting 30 minutes or less. This enables attackers to slow down computing resources or take them offline altogether while flying under the radar, making it especially difficult for companies to detect and stop them.

This shows up in industry statistics. In May 2015 the Ponemon Institute published a report on cyberthreats in the financial industry that found it took an average of 27 days for financial institutions to detect a denial of service attack. Then, it took 13 days to mitigate it.

These attacks are often highly costly. Another Ponemon report showed an average cost of $1.5m in DDoS costs, almost a third of which was down to the cessation of customer-facing services. Yet a DDoS attack costs about $38 per hour (PDF) to mount on average. Time to get some protection, then.

Inline vs out-of-band

The industry initially evolved with out-of-band DDoS protection. In this model, the appliance sits on the network independently of the router that is passing through traffic from the Internet. The router will send samples of metadata describing that traffic to the appliance, which then raises the alert if it detects suspicious packets that point to an emerging DDoS attack.

Conversely, in-band DDoS protection puts itself in front of the firehose, sitting directly in the stream of traffic, analysing it, processing it, and determining whether to drop the attack traffic or pass the good user traffic along.

Inline systems see the traffic on its way from one point on the network to another, enabling them to filter and process traffic in real time. Conversely, out-of-band appliances are seeing sparse samples of traffic that is already being passed to its destination.

“Out-of-band analysis allows for more complex analysis of traffic without impacting traffic flow, however there is a delay between the detection of an attack and the application of rules to defend against it,” explained Nick LeMesurier, security consultant at consulting firm MWR Infosecurity. For this reason, out-of-band solutions tend to react more slowly to DDoS patterns. They also aren’t in a position to do anything about it themselves, but must alert another system to take action.

Dave Larson, COO and CTO at Corero Network Security, explains: “Deploying an in-line, automatic DDoS mitigation solution allows security teams to stay one step ahead of attackers. By the time traffic is swung over to an out-of-band DDoS mitigation service, usually after at least 30 minutes of downtime, the damage has already been done. To keep up with the growing problem of increasingly sophisticated and damaging DDoS attacks, effective solutions need to automatically remove the threats as they occur and provide real-time visibility into the network.”

Commercial issues

Redirection is a key feature in out-of-band systems, said Nathan Dornbrook, chief technology officer at IT and security consulting firm ECS.

Traffic must be redirected from the router to the DDoS appliance so that it can conduct a deep-dive packet analysis, he explains. If you’re a big company and you have two ISPs instead of one for load balancing purposes, that redirection entails one service provider letting the other one inject routes into its core, he warned, calling it a “big no-no”.

“It can cause instability to let one of your competitors screw with your routing tables,” he warned. “In addition you’re talking about carrying a lot of bad traffic across your core.” All that creates headaches for the service providers and the customer, who just wants to secure their traffic.

Handling sophisticated attacks

Inline mitigation has developed as a worthy alternative, but this too can be implemented in different ways, points out Dornbrook. “There are other guys that do DDoS protection where they have a content distribution network and some kind of filtering capability and they filter the traffic and pass it on to you and they do it inline,” he said. “Those services definitely have a role to play but they’re better for smaller customers.”

In its paper on withstanding DDoS attacks, the SANS Institute points out that cloud-based services may not protect companies as readily from "low and slow" DDoS attacks, in which incoming packets are consume server resources as a way to starve out legitimate traffic without heavily flooding the network.

These attacks, typified by attack tools like RUDY and Slowloris, focus on bringing a target down quietly by creating a relatively low number of connections over time. They will often operate at at the application level of the network stack, which is layer seven in the OSI model.

“The layer seven attacks are the ones that are the trickiest to pick up on because they tend to exploit weaknesses that are architected into systems when the site is developed,” said Andy Shoemaker, CEO at DDoS research and simulation consulting firm Nimbus DDoS.

“It may not use up the network resources but it uses the compute resources. It hits the database, authentication services and so on.”

These attacks can be particularly troublesome, as attackers can bring down a web server unobtrusively, sometimes with a single machine, making these attacks easily mountable and difficult to detect.

In addition, to these concerns, Cloud-based DDoS services, which are by definition out-of-band, can also introduce delays in protection, which can result in service outages, the SANS paper warns.

If you’re planning an inline solution, you’ll want to be sure that you can scale it to suit your traffic needs. Performance is critical as any inline solution with performance limitations could itself be exploited and become a traffic bottleneck. Right-sizing your traffic flow is a must-have skill here. Choose a line-rate solution that you can cluster to increase performance.

And hopefully, some jerk won’t be able to take your company down for profit – or just for the hell of it.

More about

More about

More about


Send us news

Other stories you might like