A Distributed Denial of Service (DDoS) attack is no laughing matter; they flood your network with malicious traffic, bringing your applications down and preventing legitimate users from accessing your service. DDoS attacks frequently result in lost sales, abandoned shopping carts, damage to reputation, and unhappy users.
The first part of this blog series discussed some of the steps you should take to prepare for a Distributed Denial of Service (DDoS) attack before it happens. This post will discuss what to do now that you are under an attack.
Although you can’t control when you might come under attack, following the steps outlined below may help you minimize the impact of the attack, get you on your way to recovery, and help you prevent this from happening again.
Alert Key Stakeholders
It is often said that the first step in fixing a problem is recognizing that you have one. To that end, you need to alert key stakeholder within the organization explaining that you are under attack, and what steps are being taken to mitigate it.
Examples of key stakeholders include the organization’s CISO, security operations center (SOC), network IT director, operations managers, business managers of affected services, and so on.
Since you will probably have your hands full in combating the attack, it is probably best to keep this alert short and to-the-point.
Key information–to the extent that you have it– should include:
- What is happening
- When the attack started
- Which assets (applications, services, servers, etc.) are impacted
- Impact to users and customers
- What steps are being taken to mitigate the attack
Keep stakeholders informed as the event develops, and/or new information becomes available. Keeping key stakeholders informed on an ongoing basis will help prevent confusion, uncertainty, and panic, and help coordinate efforts to stop the attack.
Notify Your Security Provider
In tandem with notifying stakeholders within your organization, you will also want to alert your security provider, and initiate any steps on their end to help you deal with the attack.
Your security provider may be your internet service provider (ISP), web hosting provider, or a dedicated security service.
Each vendor type has different capabilities and scope of service. Your ISP might help minimize the amount of malicious network traffic reaching your network, whereas your web hosting provider might help you minimize application impact and scale up your service. Likewise, security services will usually have dedicated tools specifically for dealing with DDoS attacks.
Even if you don’t already have a predefined agreement for service, or are not subscribed to their DDoS protection offering, you should nonetheless reach out to see how they can help.
If you have any countermeasures in place, now is the time to activate them.
One approach is to implement IP-based Access Control Lists (ACLs) to block all traffic coming from attack sources. This is done at the network router level, and can usually be handled either by your network team or your ISP. It’s a useful approach if the attack is coming from a single source, or a small number of attack sources. However, if the attack is coming from a large pool of IP addresses, then this approach might not help.
If the target of the attack is an application or a web-based service, then you might also try to limit the number of concurrent application connections. This approach is known as rate-limiting, and is frequently the favored approach by web hosting providers and CDNs. Note, however, that this approach is prone to high degrees of false-positives, as it cannot distinguish between malicious and legitimate user traffic.
Dedicated DDoS protection tools will give you the widest coverage against DDoS attacks. DDoS protection measures can be deployed either as an appliance in your data center, as a cloud-based scrubbing service, or as a hybrid solution combining a hardware device and a cloud service.
Ideally, these countermeasures will kick-in immediately once an attack is detected. However, in some cases, such tools – such as out-of-path hardware devices or manually-activated on-demand mitigation services – might require the customer to actively initiate them.
As mentioned above, even if you don’t have a dedicated security solution in place, most security services allow for emergency on-boarding during an attack. Such on-boarding frequently carries a hefty fee along with it, or an obligation to subscribe to the service later on. However, this might be necessary if you have no other option.
Monitor Attack Progression
Throughout the attack, you should monitor its progression to see how it develops over time.
Some of the key questions to try and asses during this time:
- What type of DDoS attack is it? Is it a network-level flood, or is it an application-layer attack?
- What are the attack characteristics? How large is the attack (both in terms of bits-per-second and of packets-per-second)?
- Is the attack coming from a single IP source, or multiple sources? Can you identify them?
- How does the attack pattern look like? Is it a single sustained flood, or is it a burst attack? Does it involve a single protocol, or does it involve multiple attack vectors?
- Are the targets of the attack staying the same, or are attackers changing their targets over time?
Tracking attack progression will also help you tune your defenses.
Assess Defense Performance
Finally, as the attack is developing, and your countermeasures are being deployed, you need to measure their ongoing effectiveness.
The question here is simple: Are defenses working, or is attack traffic getting through?
Your security vendor should provide you with a Service Level Agreement (SLA) document which commits their service obligations. Two of the most important metrics in this document are Time-to-Mitigate (TTM) and Consistency-of-Mitigation.
- Time-to-Mitigate measures how fast your vendor commits to stopping the attack.
- The Consistency-of-Mitigation metric, on the other hand, measures how well it is stopping the attack. This metric is usually defined as the ratio of malicious traffic that is allowed to make it through to your network.
If you find that your security is not meeting their SLA obligation – or worse – is not able to stop the attack at all, now is also the time to assess whether you need to make a change.