Responding to denial-of-service attacks: detection, mitigation and preparation

What a denial-of-service attack is

A denial-of-service (DoS) attack tries to stop legitimate users from reaching a service. When the traffic comes from many machines at once, often thousands of hijacked devices in a botnet, it is a distributed denial-of-service (DDoS) attack. Motives include extortion ("pay or we keep going"), protest, rivalry and distraction while another attack happens elsewhere.

Main types

A sudden surge in genuine visitors, for example during a sale or exam results day, can look similar. That is why knowing your normal traffic matters.

The first steps during an attack

1. Confirm: check monitoring for unusual traffic volume, source spread, request patterns and error rates. Rule out a failed change or a genuine traffic spike.
2. Declare an incident and open a log of actions and times.
3. Escalate early to your ISP, hosting provider or DDoS protection service. A volumetric attack fills the link before traffic reaches your firewall, so only someone upstream can filter it.
4. Mitigate: switch on scrubbing or "under attack" modes, apply rate limits, block clearly malicious patterns, and serve static content from a CDN.
5. Watch for a second attack: check whether the noise is hiding a break-in, such as unusual sign-ins or data transfers.
6. Communicate: tell staff and customers what is affected and how to reach you another way.

Tip: if you receive a ransom demand threatening a DDoS, do not pay. Report it to the police through your national cyber crime reporting service (and, in the UK, to the National Cyber Security Centre for serious incidents) and alert your protection provider.

Preparing before it happens

• Record baseline traffic levels for your key services.
• Know whether your ISP or cloud provider includes DDoS protection, and how to request help, including out of hours.
• Put public websites behind a CDN or protection service, and hide the origin server's real address.
• Avoid single points of failure: separate DNS providers or anycast DNS, and more than one internet link for critical sites.
• Write a one-page DDoS runbook with contacts and decision owners, and test it in a tabletop exercise.

Real-world example: an online exam portal under pressure

On results morning, a fictional exam board's portal slows to a crawl. The on-call engineer first checks whether it is simply demand, but sees huge numbers of identical search requests from addresses all over the world, with no session cookies, while real student traffic is normal. Following the runbook, she calls the CDN provider's emergency line, turns on its challenge mode for the search page and adds a rate limit. Within 20 minutes real users are back. The communications team posts a short status update. Afterwards the board caches the results page and runs a yearly DDoS exercise before results day.