How to Prepare for a DDoS Attack

0
101

Our 2015-2016 Global Network & Application Security Report documented that 51% of businesses suffered a DDoS attack in 2015.  Further, 90% of businesses suffered some sort of cyber attack during that same period.  This is an astonishing number and as network operators, we need to be prepared.  DDoS attacks can be a debilitating event to your business, but they don’t have to be.  If you’re prepared, you can help control the outcome.

While Radware does offer an industry leading solution for DDoS mitigation, there are plenty of other things you can be doing to be prepared.  With some planning and practice, you can be ready.  Let’s go through some ideas.

Visibility

Visibility is critical when preparing for issues in your network.  SNMP graphing platforms will tell you an extraordinary amount of information on volumetric attacks.  You’ll be able to see and (depending on the platform) sometimes even alert on anomalous bandwidth events.  You’ll be able to track at which port it entered your network, if it’s saturating any links, and even where the attack is headed.  It’s surprising how many companies I’ve worked with over the years that  do not deploy this because it’s such an easy and basic thing to implement.  Primarily, you need devices that can speak SNMP, such as managed switches, routers, etc., and then you need a platform to query them.

For querying/graphing, there are plenty of good platforms out there, including free, SaaS, and traditional licensed software.  I personally like Observium, which is free and does a great job.  The good folks at Turnkey Linux have developed a self-contained distribution of it (among plenty of other cool things!).  Other tools include LibreNMS, Cacti, MRTG, and the like.  I’ve also used a SaaS platform called LogicMonitor, which is feature rich and includes anomaly alerting, but is not free.

[You might also like: At Risk for DDoS Outages? If You Answer Yes to the First Five Questions…WATCH OUT!]

Details

SNMP certainly won’t catch everything, even when the attack is volumetric.  Wait, what?  Yes, it’s true, they’re good at monitoring traffic levels, but the downside is that they only poll devices on preconfigured intervals.  The most recent Global Network & Application Security Report found that 57% of cyber attacks lasted less than one hour.  Some of that is attributed to burst attacks, which are very short but devastating bursts of traffic designed to disrupt traffic but not be detected.  When your SNMP platform polls at 5-minute intervals and you receive a 1-minute volumetric burst attack, you have a low probability of actually catching that attack with SNMP during your polling cycle.  More likely, you’ll experience a disruption and not know what the problem is because everything looks normal.  You can shorten the polling interval, but that increases load on the device you’re polling and overly aggressive polling can be problematic.  Another issue with SNMP is that you have to have to be able to poll and respond.  If you’re under attack and the monitoring happens somewhere in that forwarding path of a volumetric attack, you might see blank spots/dropouts in your graphs.

However, if your network supports flow (netflow, ipfix, sflow, etc) you can ship this data to a flow collector and start to gain even more insight to traffic in your network.  Flow data is different from SNMP reporting in that the router or switch will send UDP traffic out to a flow collector at preconfigured sample rates.  If you’re sampling at 1 in 8192 packets, you’re going to catch those pesky burst attacks that evaded your SNMP polling interval.  Flow data also shows you terrific details like source IP, destination IP, source/dest ports, etc.  Here’s an example:

As you can see, this information can be very helpful when identifying and blocking an attack.  There are several good tools out there for flow data. Our friends at Kentik have a great SaaS option that I have always liked, and NFDump/NFSen is a popular open source option that I’ve also used extensively. One tip here is that many devices can only send flow to a few limited targets, so to overcome this in the past, I have used tools like Samplicator to fork the flows to different targets and to manipulate them as needed.

Capacity

Network capacity is another thing that you often have in your control.  The obvious first thing that comes to mind is having enough capacity to absorb a volumetric attack.  Our 2015-2016-Global Network & Application Security Report showed that 36% of attacks that we observed had saturated the internet link of that network.  In other words, even if those networks had the absolute best equipment that money could buy, 36% of the time, the attack filled their internet link before they could even help!

Capacity is a tricky one, though, because how do you plan for enough capacity for a volumetric attack?  Do you buy another 1G link?  More 10G links?  There’s a point where that doesn’t become cost effective, and I’ll discuss Radware’s solutions for that at the end, but capacity is a tool that you can use to help alleviate bottlenecks.

[You might also like: Network as a Sensor: A New Approach to the DDoS Problem]

If you have diverse capacity from diverse providers and can run BGP with them, you can influence what comes into your network where.  You might only announce the prefix that is being attacked out of one provider and the rest of your traffic out the other.  You can even do a similar technique with two links from the same provider.  In fact, check with your providers because many will allow you to announce smaller than a /24 for this specific reason – traffic engineering over separate links in their network.  In this example, you could announce all prefixes out one link and just the /32 being attacked out the second link.  When you do this, the more specific route in BGP will be preferred and you can take the attack traffic on separate capacity to ensure that it doesn’t harm your remaining traffic.

Capacity is not limited to internet pipe size.  Another technique you can use is to add compute capacity and spread the traffic load with an ADC/load balancer.  By distributing the load of an attack, you’re lessening the load on any given server.

Mitigation Tools

Arguably the most important aspect of an attack is how you will handle and mitigate it.  If you’ve done the prep work, you have a plan on how to handle an event.  Using the methods above, fingerprinting an attack and then attempting to block it with policy somewhere in the network is an option, albeit a reactive measure.  It requires a human to make an accurate assessment of the situation and then formulate the correct policy to implement somewhere in the network.  What if it’s a multi-vector attack?  What if the attack changes after you implement a particular measure?  This absolutely happens and without the proper tools, you’re entering a cat-and-mouse game with your attacker.  How long can one person or even an entire team keep this up?  Can you block an application-layer attack the same way that you can a network-based flood?

You need a tool that can detect and mitigate instantly.  Traditional firewalls can’t do this and they can even cause an outage, as I’ve shown in a previous post.  To truly have complete coverage, you need a purpose-built DDoS mitigation appliance that can handle these complex attacks and can begin mitigating instantly.  Our award-winning DefensePro product can help you do just that.

Plan Your Event

What is important to you if you receive an attack?  When I was a network operator, my goals were to:

  1. Have enough capacity to absorb an attack
  2. Have the tools to find and fingerprint an attack
  3. Have the tools to contain and mitigate an attack
  4. Have the tools to monitor my application and network performance, and alert on anomalies such as high latency or availability issues
  5. Have a method of notifying the internal stakeholders at my organization if something happened
  6. Have a method of notifying my customers if there was impact to them
  7. Have the tools available for forensic reporting and post attack analysis

Document what is important to you and how you will handle an event.  Who needs to know?  Who will help?  Will social media need to be involved?  If you plan this ahead of time, things will be less chaotic when an attack comes.

[You might also like: The Top 5 DDoS Attack Types We Saw in 2015]

Testing and Dry Run

There are several ways to test your network and the attack vector doesn’t necessarily matter for this.  Essentially, you want to go through the steps of a mock attack to see how your plan works.  For testing tools, the common ones are widely available on the internet and there are companies who can do this kind of testing for you.  Our 2015-2016-Global Network & Application Security Report even has a chapter that explains how to simulate an attack on your network, and if you need more ideas, you can contact us to get in touch with me.  The purpose of this exercise is to familiarize yourself with the steps you need to take during an attack.  Perhaps you even write a runbook.  If you test yourself and become familiar with what you need to do for your own organization’s goals, you’ll be ready if the time comes.

Best Practices

Personally, I believe that the best approach is to begin with detection and mitigation at the perimeter of the network.  DDoS mitigation at the entire perimeter isn’t always practical, so sometimes people build scrubbing centers inside of the network to handle specific incidents, but still detect at the edge.  The mitigation appliance can be paired with a Web Application Firewall (WAF), where the WAF can detect and block application layer attacks and either block them locally or signal to the edge to block them there.  I’d also pair that with a central management and reporting platform that acts as a single pane of glass for configuration, maintenance and operation, as well deep forensics and reporting for incident reporting and postmortem analysis.  If volumetric attacks are a concern for your organization, you might consider adding a cloud-based scrubbing partner to divert your traffic to when under attack.  Radware has a complete DDoS protection solution for all of this.

Conclusion

Preparing for DDoS attacks comes down to identifying the risks in your network, identifying the tools that you can use to defend your network, and having a plan for how you will engage when it happens.  This comes with planning and exploring options that work for your organization.  Radware’s strength in this area comes with a long standing history in defending networks against cyberattacks, combined with innovative ideas on how to protect a network.  I’d be happy to have an objective conversation about your plan if you’re interested.  Just contact us or your local account team to get started.

DDoS_Handbook_glow

Download Radware’s DDoS Handbook to get expert advice, actionable tools and tips to help detect and stop DDoS attacks.

Download Now

LEAVE A REPLY

Please enter your comment!
Please enter your name here