DDoS (Distributed Denial of Service) attacks are getting larger, more sophisticated, and more pervasive. Just today (October 21, 2016), DDoS attacks against Dyn, Inc have impacted the availability of sites such as Twitter, Netflix, Github, and Spotify.

Typical DDoS mitigation strategies rely on defending the victim (destination) as close to the destination as possible. This can happen in a number of ways.

One defense strategy is to redirect traffic, destined to the victim, through an alternative network that is designed to identify malicious traffic, drop the malicious traffic, before sending the legitimate traffic to the victim. This generally works well for volumetric or protocol based attacks. However, this requires that a network with a vast amount of capacity be available and sitting idle, except in times of attacks.

Another defense strategy is to utilize network and application firewalls, sitting in front of the destination, to identify the malicious traffic and drop it before sending the legitimate traffic to the destination. This generally works fine for some protocol and application based attacks.

Then, in some cases, volumetric attacks are so large, that they completely overwhelm the destination network. In this case, they use a BGP community, known as Remote Triggered Black Holes (RTBH) to tell their upstream service providers to drop traffic destined to the victim before it even reaches the destination network. In this case, the victim is sacrificed for the availability of rest of the network. This is typically the worst case scenario, as the victim still goes offline, conceding a victory to the attacker.

These countermeasures obviously are not going to scale with ever growing attacks. This is why we need the architects and builders of the Internet to come together to standardize on a new method of defending against the these attacks. We need a global community of real time analytics that identify malicious sources and use RTBH techniques to automatically take the offending sources off the Internet, instead of the victims. This technique will require that every Internet provider agree on a standard, and abide by it.

Share on FacebookTweet about this on TwitterShare on LinkedInShare on RedditEmail this to someone

I’ve been playing with docker off and on for about a year or so now. One of my ideas, with Docker, is to use it for my network lab. These days, I’ve mostly virtualized my lab. Lately, been doing a lot of it in VIRL, but this hasn’t stopped me from tinkering.

For a while, I’ve had a base docker container that sets up Open vSwitch and KVM. Once the docker container is started, you can access the container and spin up VM’s or play with Open vSwitch. The Dockerfile to set this container up can be found on my github.

The next iteration of this was to actually have the VM in the container and have it boot up directly. I did this with IOS-XRv. It’s a pretty straight forward set up. The Dockerfile uses centos:6 as its base, installs a couple yum repositories, installs needed packages, and adds the associated files. When it’s all done, you have a docker container that will run the IOS-XRv. You can spin this container up and down at will. It’s pretty nifty.

My next goal in this set up is to have the container generate dynamic mac addresses for IOS-XRv when it boots up. Currently the mac addresses are hard coded. The reasoning for this is that I eventually want Open vSwitch to connect to a ‘controller’ Open vSwitch via VXLAN or GRE. The purpose of this is to spin up multiple containers and have them all connect to each other. This will make the lab environment much more flexible and scalable.

Anyways, check out the docker-ios-xrv github for the README, Dockerfile, and associated files. I’ll post more when I have updates.

Share on FacebookTweet about this on TwitterShare on LinkedInShare on RedditEmail this to someone