Mitigating DDoS

By Russ White
Russ White

Your first line of defense to any DDoS, at least on the network side, should be to disperse the traffic across as many resources as you can. Basic math implies that if you have fifteen entry points, and each entry point is capable of supporting 10g of traffic, then you should be able to simply absorb a 100g DDoS attack while still leaving 50g of overhead for real traffic (assuming perfect efficiency, of course — YMMV). Dispersing a DDoS in this way may impact performance — but taking bandwidth and resources down is almost always the wrong way to react to a DDoS attack.

But what if you cannot, for some reason, disperse the attack? Maybe you only have two edge connections, or if the size of the DDoS is larger than your total edge bandwidth combined? It is typically difficult to mitigate a DDoS attack, but there is an escalating chain of actions you can take that often prove useful. Let's deal with local mitigation techniques first, and then consider some fancier methods.

There are, of course, other techniques you can deploy against DDoS attacks — but at some point, you are just not going to have the expertise or time to implement every possible counter. This is where appliance and service (cloud) based services come into play. There are a number of appliance based solutions out there to scrub traffic coming across your links, such as those made by Arbor. The main drawback to these solutions is they scrub the traffic after it has passed over the link into your network. This problem can often be resolved by placing the appliance in a colocation facility and directing your traffic through the colo before it reaches your inbound network link.

There is one open source DDoS scrubbing option in this realm, as well, which uses a combination of FastNetMon, InfluxDB, Grefana, Redis, Morgoth, and Bird to create a solution you can run locally on a spun VM, or even bare metal on a self built appliance wired in between your edge router and the rest of the network (in the DMZ). This option is well worth looking at, if not to deploy, but to better understand how the kind of dynamic filtering performed by commercially available appliances works.

If the DDoS must be stopped before it reached your edge link, and you simply cannot handle the volume of the attacks, then the best solution might be a cloud based filtering solution. These tend to be expensive, and they also tend to increase latency for your "normal" user traffic in some way. The way these normally work is the DDoS provider advertises your routes, or redirects your DNS address to their servers. This draws all your inbound traffic into their network, which it is scrubbed using advanced techniques. Once the traffic is scrubbed, it is either tunneled or routed back to your network (depending on how it was captured in the first place). Most large providers offer scrubbing services, and there are several public offerings available independent of any upstream you might choose (such as Verisign's line of services).

A front line defense against DDoS is to place your DNS name, and potentially your entire site, behind a DDoS detection and mitigation DNS service and/or content distribution network. For instance, CloudFlare is a widely used service that not only proxies and caches your web site, it also protect you against DDoS attacks.

By Russ White, Infrastructure Architect at Juniper Networks

Related topics: Cyberattack, Cybersecurity, DDoS Attack, Networks


There's one more thing... Marco Gioanola  –  Feb 10, 2017 5:43 AM PST

I think it's important to stress that this article focuses on the protection of web-facing (or, more generally, Internet-facing) content and services, but there is another side of the problem that many companies tend to overlook, which is the protection of the Internet connectivity of the corporate network.
"Cloud" services are more and more pervasive and seamlessly integrating in all modern companies' workflows. In layman's terms this means that if "the Internet is down" at the office(s), all company's activities just stop. This article is an excellent example: “No one could work this afternoon, since the internet was gone twice, for several hours”.
So, a combination of on-premise devices and "cloud" services is also necessary for protecting corporate networks. And in my opinion it's important to clarify that CDNs can't take care of this part of the problem.

Protecting the Link -- Russ White  –  Feb 10, 2017 5:54 AM PST

I have another part coming to this series that will consider link protection, as well…