menu
FlowTraq > Blog > DDoS Mitigation Tips > Implementing DDoS Mitigation Management: Part 2

Implementing DDoS Mitigation Management: Part 2

Gurdev Sethi
By | October 11, 2017


Facebooktwitterlinkedin

In part one of this article, we discussed that DDoS mitigation management framework is very similar to standard incident handling procedures. We discussed at length the importance of preparation and performing a risk assessment. In part two of this series, I’ll cover identification and containment. These are our initial reaction steps once a DDoS attack has taken place.

Identify Attack

In order to mitigate a DDoS attack, we first need to be able to identify when one is taking place. While this sounds pretty straightforward, it can actually be fairly nuanced. I’ve seen a few situations where what was thought to be a DDoS attack turned out to be an extremely successful marketing campaign.

Our first step in identification is being able to determine when something abnormal is occurring.

 

Identifying What is Normal

In order to identify abnormal traffic patterns, you need to first understand what is normal for your network. I see this mistake quite frequently. No one looks at traffic until there is a problem. However when the traffic is analyzed, it is difficult to determine which traffic patterns are perfectly normal and which are contributing to the issue at hand. So we need to start by creating a baseline of normal traffic patterns for our network. There are many tools on the market that can help you monitor your network. Which tools are best will depend on your configuration. So rather than focusing on tools, I’ll focus on the metrics you should be monitoring regardless of which tools you decide to use.

Metrics to Evaluate When Detecting DDoS Attacks

Monitoring should take place at any junction points between your systems and potential attack sources. For most organizations, this will be our Internet connection(s). However, for some environments, it may include internal systems as well. Examples would be computers located in unsecured areas, permitting public access to our wireless network, permitting individuals to connect their personal systems or having few protections in place to prevent internal systems from becoming compromised. For critical servers, we will also want to be able to monitor performance on the host itself. Remember that some in-protocol attacks can cause only a slight increase in network bandwidth, while still taking a server offline.

Critical metrics to monitor include:

  • Utilization of backbone networks (like your connection(s) to the Internet)
  • Breakdown of protocol utilization (TCP vs. UDP vs. ICMP vs. other)
  • Top inbound services and their percentage of utilization
  • Top external IP addresses sending traffic
  • Top internal systems receiving traffic
  • Network interface errors (frames ignored due to a busy queue)

All of these metrics can be plotted over time.

Identify a Baseline

Once you start collecting metrics, leverage predictable patterns to identify your baseline. You can turn these into alerts to prove out your assumptions. For example, if you determine that normal traffic for your Web server does not exceed 20 Mb/s, configure an alert to trigger at 25 Mb/s. If the alert does not trigger under normal traffic patterns, you’ve proved out your theory. If there are specific periods where your Web server traffic triggers the alert, but investigation shows the traffic is still normal, bump up your alert threshold. Note that networks are an evolving entity. As requirements on your network change over time, expect to revisit your alert thresholds.

Decoding an Attack

Once we have an established baseline, we can sit back and wait for our alerts to trigger. When they do, a deeper analysis must be performed. Again, there are many tools available to help you deep dive into the packets. A trained analyst should be able to spot the attack vector being used. The idea is to extract as many traits about the attack pattern that distinguishes it from normal traffic. This could be the source IP address, the protocol being used or even data contained within the payload. The more unique properties that can be identified, the easier it will be to mitigate the attack.

Contain Attack

Once we have identified the impact the attack is having on our network, as well as the properties that make the attack vector unique versus regular traffic, we can move towards containing the effect of the attack. What is being affected will impact where we can try and contain the attack. Is it a single server or our entire link to the Internet? If it is just a single server, we may be able to contain the attack locally. If it is our Internet link, we will need to implement containment somewhere on the Internet side of our link.
Where we implement containment will also drive what options are available to us.

DDoS Containment Options

Luckily, there are a number of options available to minimize the impact of a DDoS attacks. Each has their strengths and weaknesses. There is no “one size fits all” here, as different attack vectors will require different mitigation techniques in order to reduce their impact.

Packet Filtering or Null Routing at Your Perimeter

If the impact is localized, meaning that your Internet link is okay but specific servers are being impacted, you may be able to leverage your border router or firewall to minimize the attack. This may only be possible if the attack has distinct characteristics such as a small defined group of source IP addresses.  

Connection limiting by IP and/or protocol

If the attack is localized but not from a small group of source IP addresses, you may be able to resolve the problem using rate limiting. Many firewalls give you the ability to restrict traffic to certain throughput levels. While the attack will still get through, this may reduce the load on your servers enough that they can respond to legitimate data requests.

Proxies or Content Delivery Networks (CDNs)

If the target of the attack is your Web server, you may be able to mitigate the attack by deploying multiple proxies or a CDN. This is actually a good idea anyway, as a good CDN will make your Web site more responsive from all corners of the globe. So even when an attack is not taking place, you gain the benefit of improved performance. There are many third parties and public cloud providers that offer CDN services.

Packet Filtering or Scrubbing at Your ISP

If your link has become saturated, you will need to resolve the problem on the Internet side of your link. Many business class ISPs offer DDoS mitigation services. Your traffic is run through dedicated hardware that removes the attack traffic prior to reaching your Internet link. When this works properly, you should immediately see traffic levels return to normal.

Third Party BGP Scrubbing

There are a number of companies that offer traffic scrubbing services. These work by modifying DNS or BGP so that all traffic is routed through a scrubbing center prior to reaching your network. This way your traffic is cleaned up prior to being routed to your network. The BGP implementation tends to be far more effective than DNS. This is because it covers all of your IP address space, not just systems with a DNS entry.

Clearly, you need to consider containment during the preparation phase of DDoS mitigation management. The worst time to go looking for a mitigation solution is when an attack is already taking place.. Consider all of the attack vectors that represent an unacceptable business risk and implement processes to contain them accordingly.

Summary

You should now have a better understanding of how to implement the identification and containment steps in the DDoS mitigation management framework. In part three of this series, we will discuss what to do once the attack has been mitigated and how to ensure we are continually improving our processes.

Call to action