Advanced Mitigation Techniques to Stop DDoS Attacks in their Tracks

In our last blog post, we learned what the Distributed Denial of Service (DDoS) attack is, and examined the DDoS picture globally. As we walked through some recent and well-known cases, we also surveyed a range of attack types and drilled down to specific examples. In this article, we’ll study the DDoS mitigation strategiestechniques you’ll need to resist these attacks. You’ll learn: 1. How to avoid becoming a bot; 2. How to prepare your own network for the possibility of an attack and finally; 3. What to do if your network is under attack; 4. What resources and tactics exist for cloud DDoS protection.

How to Avoid Becoming a Bot

Educate Users Not to Be Exploited—and to Be Vigilant

Stopping DDoS attacks—or mitigating them—is a multifaceted process. There are aspects of DDoS mitigation that affect end-users as well as system admins and DevOps roles. Why is this? Because of the way DDoS attacks are orchestrated. As we saw in our previous blog on the topic, a DDoS attack typically relies on a botnet—a network of distributed, compromised, end-user machines that coordinate instructions from a script kiddie to launch an amplified attack on a specific target.

Although it’s indirectly related to your network, there are steps most computer end-users can do to implement bot mitigation—i.e., avoid becoming a bot in a botnet. Do you serve an IT function for a corporate staff? Make sure your users are not using default passwords for anything. Have your users install and manage a personal firewall and learn how to configure it. They should close ports on their own computers that they don’t specifically need—for either uplink or downlink—and make sure their firewall rules are up to date.

Users should also have anti-virus and anti-malware installed, with the latest updates. Educate them to make periodic hard drive scans, and encourage them to use the real-time and and/or on-access file scan setting.

Keep users off the TOR network. Tor is no longer considered completely anonymous, for one thing. While it does obfuscate connections, TOR users agree to let their computer be taken under control, which makes them perfect candidates for botnets. Even without that it’s possible, while on the TOR network, to download a file or click a link which can install a bot in the background.

Users should also never pirate software  for the same reason! Free stuff comes in executables that appear to be archives, installers, or key generators, but they actually install bots that wait and listen to the network for remote commands.

Of course, users should be knowledgeable and vigilant about the usual vectors of attack. If users, for whatever reason, do need to download stuff, access email attachments, click dodgy links, or surf risky websites, they should make sure they have real-time scanning enabled on their anti-virus and anti-malware. More critically, they should do all of the above from a virtual machine that can be wiped clean and restored at the first sign of trouble.

If a user thinks they might be on a risky website or a phishing site, use the appropriate key commands to close the browser (Option-Command-W on Mac; Alt-f4 on Windows). NEVER click an “X” or a “Close” button directly on the page—any controls on the page could be a ruse to install something or run some other malicious process in the background.

If users suspect they have a bot or some other malware installed, have them install a personal firewall and network monitor like Glasswire and configure your network router to keep a log. Make a note of what you’re connecting to throughout the day.

If You’ve Been Infected—and Become a Bot:

• Reinstall your machine or restore your VM from a safe snapshot. Make sure to reinstall your anti-virus and anti-malware and do a full scan.
  
• Change your passwords.
• Change your habits. Be wary of all the possible vectors for malware, including:
  • dodgy email attachments;
  • risky websites;
  • download sites and networks like TOR—to name a few.
    
• If you must browse to a download site, or something with content that could be risky, install a virtual machine—and browse from there.
• If you’re downloading something from even “reputable” sites like CNet or Downloads.com, don’t trust anything implicitly. Make sure you scan everything you download.

How to Prepare Your Own Network

So what can you do to prepare your network for the possibility of a DDoS attack?

Patch Systems to Prevent DoS (and Other) Exploits

These include software updates and security patches for routers and other network hardware, firewalls, servers, PCs, or other workstations and all connected devices. Of course, make sure to change the default password on routers and all connected devices. In some jurisdictions, you are now required to change these passwords, while manufacturers are forbidden from using “standard” ones like “password”, “admin” or “123456” out of the box.

Stay current with the latest security news, and update promptly when necessary.

If there’s an auto-update mechanism, consider enabling it.

Separate and Distribute Assets

Separate and distribute assets in a network to make them harder to attack. Here are a few ways to do so:

Use a Content Delivery Network (CDN) for all Content—to Distribute It—Wherever One Can Be Used Conveniently.

DDoS attackers will typically target your content where it usually resides, and this means an external IP address (as opposed to an internal one). It’s why, for example ipconfig /release && ipconfig /renew won’t actually help you much during an attack; your commands in this case work on all adapters to release and renew the IP address internally, but not externally. You would have a particularly difficult situation to remedy if your web content was hosted at a single external IP during an attack.

A content delivery network (CDN) distributes your content and boosts performance in part by minimizing the distance between your websites visitors and the content. CDNs store cached versions of content in multiple locations (points of presence or PoPs); each PoP may contain many caching servers that deliver content to nearby visitors.

CDNs subsequently mitigate the impact of a DDoS attack by avoiding a single point of congestion, when the attacker is trying to focus on a single target.

Image courtesy of Wikipedia

Popular CDNs include Cloudflare, Rackspace, and Amazon CloudFront, but there are many others as well.

Make Sure that Either Your CDN or Other (Outer) Layer Has Traffic-Scrubbing Capabilities to Identify and Filter Out Resource Consumption Attacks

In DDoS mitigation, one good activity to get out of the way (before you actually have an attack) is identifying “normal” traffic patterns.

Usually, a Security Information and Event Management (SIEM) or Security Analytics system such as Logz.io Security Analytics, is used for this work, to develop rules for the filters by allowing users to study aspects like payload, signatures, origin IP addresses, cookies, HTTP headers, and Javascript footprints.

CDNs can then be configured with these scrubbing filters to prevent huge amounts of fake traffic from causing more than a momentary blip.

Conserve Resources in Use, While Maximizing Available Ones

During an attack, these filters work by passing traffic intended for a target through high-capacity servers and networks to filter out the “bad” traffic.

Types of filtering that support DDoS mitigation include:

• connection tracking;
• IP reputation lists;
• deep packet inspection;
• blacklisting/whitelisting; and
• rate limiting.

Separate the firewall from the router, so there is no single point of attack. Beef up firewalls and routers with compute power and memory where possible also helps. You can turn off logging (for example, on consumer routers and equipment) so that log writes do not eat up resources when traffic accelerates during an attack. As mentioned before, setting up a Response Rate Limiter (RRL) will limit how many responses servers will send to requests. RRLs will also stop/block zombie computers that keep requesting data without acknowledgment requests. This functionality is particularly useful during spoofing attacks.

Another step involves placing an on-premise filtering device in front of the network. However, it’s recommended that DDoS mitigation not rely on on-premise solutions alone, precisely because these limit capacity. Homespun and on-premise anti-DDoS measures work best alongside anti-DDoS emergency response providers like Arbor Networks, Akamai, CloudFlare, or Radware and/or services from cloud providers like Verisign and Voxility.

Ramp Up the Defenses

Finally, there are some general steps you can take to be ready for an attack before it happens. We’ll summarize below.

• Configure your data center to shut a connection and reboot after an attack.
• “Change the “TTL” or “Time to Live” to 1 hour. You’ll need to redirect your site once it comes under attack; (the default is three days).
• Make sure you’ve got backups, and where possible, a means to create offline copies.
  
• Stay up to date on security and software updates with any Content Management System (CMS) you may be using.
  
• Monitor your site’s availability with a service like UptimeRobot, Pingdom, or Monitis to check your it periodically and alert you (via SMS or email) if your site goes down.

How to Troubleshoot a Possible Attack

You should continually monitor the health of your network as well as your uplink and downlink traffic patterns. You can use the ELK Stack with the Logz.io Cloud SIEM Threat Intelligence system for this purpose.

Below are a few examples of the types of alerts you can configure into your SIEM solution to monitor your network:

In this example below, we’re using Logz.io to monitor for the frequency of specific messages (http 200) and errors:

Of course, there’s a lot more you can do with Logz.io Security Analytics, including log aggregation, incident detection and forensic analysis of logs, but alerting is an essential tool in DDoS mitigation.

If you are experiencing traffic issues or a site outage, and think you might be experiencing a DDoS attack, refer to this guide first to rule out other possibilities.

Steps to Take if Your Network Is Under Attack

If you’re troubleshooting passes muster, and your continue to have performance issues, you may be experiencing a DDOS attack. Here’s how to respond:

1. If you haven’t already, go to your domain hosting service (for example, EasyDNS, Network Solutions, GoDaddy) and change the “Time to Live” or TTL to 1 hour. You can now redirect your site (to a new external IP) within an hour, instead of the default 3 days.
   (You may, in the future, consider the Icelandic hosting service 1984.is, for example, or hover.com for additional security).
   
2. Once you are able, consider moving your site to a DDoS mitigation service, like Google’s Project Shield, CloudFlare, CF/Project Gallileo, VirtualRoad, Deflect, and Greenhost.
3. After you’ve recovered control, decide whether to continue with your DDoS mitigation service, or simply switch to a secure hosting provider.

Also refer to our tutorial on the export of Palo Alto logs to Logz.io for an example of Cloud SIEM integrations.

Summing Up

DDoS mitigation is a complex endeavor with wide-ranging implications. Mitigation is similarly multi-faceted and with many areas to consider, including user education, making your own network attack-resilient, troubleshooting problems that might be the result of an attack, and dealing with an attack in progress.

There’s no one single vector of attack, nor is there a single weakness that makes mitigation for DDoS attacks a one-and-done effort. However, with the guidelines we’ve outlined above, we hope you can address most of them, deal with attacks as they happen, and, most importantly, begin to adopt the mindset necessary to be ready for the challenge when it comes.

Monitoring and alerting is just one tool in your belt for managing the health and security of your network. In addition to the general techniques we’ve covered, which other ones can you think of? Please feel free to leave a comment.