Strategies on Surviving DDoS Attacks


Posted on by RSAC Contributor

By Amol Sarwate

Recap on DDoS attack strategies at RSA Conference USA 2017 peer-to-peer session

At RSA Conference this year I had the opportunity to host a peer-to-peer session on how to survive IoT botnet-based DDoS attacks, and exchange ideas with some of the brightest minds in the security world. In this blog I am sharing some of the ideas that surfaced during that discussion.

We kicked off the session by looking at two real world DDoS attacks that were carried out using IoT botnets. The first example, from the Verizon data breach report preview 2017, showcased a university that was attacked primarily by vending machines and other IOT devices, which were present on the university campus. The second example was the well-known attack on the blog Krebs on Security, where the famous blogger was attacked my Mirai – an IoT botnet which was initially based on IP cameras and later added a host of devices to its profile.  Both attacks were similar in some sense because both were carried out by an IoT botnet. But they were also different because in the case of the university attack the IoT devices were on university premises, while in case of Krebs on Security the IoT devices were distributed globally around the world. And as far as defense is concerned it makes a big difference if the attack is coming from random globally distributed machines or from within one network.

It’s important to keep three different timelines of what to do before, during and after a DDoS attack. Since the consensus was that pre-attack or prevention strategies were most important, I will focus on that here. In discussing prevention strategies, we started with some fundamental groundwork like having a clear and documented DDoS process. First of all, make a list of the resources that are vulnerable and should be protected from DDoS on a priority 1 basis. This list could contain a web server, mail server or any other critical components. There should also be a document with phone numbers and contact numbers of the IT, security and other relevant staff within your organization, in addition to contact information of your internet service provider and other relevant vendors. Remember VPN services or internal servers where these documents are located may not be accessible during a DDoS attack and that needs to be planned for. Knowing if you have a cyber insurance policy and if DDoS is included in your coverage is also important.

On the technical front, the most important action to take before an attack is to study your network traffic and netflows in depth to create a baseline. Good understanding of your baseline, which includes what type of traffic is normal, where does it originate, any time-based pattern and many such identifiers will help you in detecting the attack early, and could also help in some cases to mitigate it. Many anti-DDoS products work with the same premise as they learn what normal traffic patterns are, and then help to detect or stop anomalies.

If you manage your infrastructure yourself then it is prudent to make sure that it’s hardened for DDoS so that you’re not making it a low hanging target for attackers. Hardening against common volume-based attacks like UDP floods, ICMP floods and other spoofed-packet floods is essential.  Protocol attacks such as SYN floods, ping of death and other similar attacks — where attackers consume resources of the target or any intermediate communication such as firewalls or load balancers — is taken into consideration. Application layer attacks like GET/POST floods, low-and-slow attacks that target resources on the webserver are also important.

To conclude, the most important consideration for self-managed or outsourced DDoS prevention is to understand your traffic patterns in depth so that such understanding can be used for early detection as well as for traffic scrubbing during the attack mitigation phase.

Contributors
Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community

Related Blogs