Network and Perimeter Hacking · Topic 6 of 9
DDoS Case Study, Countermeasures and Protection Tools
A memcached amplification DDoS case study, then DoS and DDoS countermeasures such as SYN cookies, filtering and sinkholing, plus protection tools.
- 4 min
- The GitHub attack used memcached amplification with spoofed source addresses.
- No single control stops DDoS. Layer edge filtering, host hardening, capacity and a scrubbing provider.
- SYN cookies help hosts survive SYN floods without storing half open state.
What it is
A case study shows how a DDoS attack unfolds and what stopped it. The exam uses such cases to test whether you can name the technique and the right defense.
This page uses the 2018 memcached amplification attack on GitHub, then lists the countermeasures and protection tools. DDoS defense combines preparation, filtering close to the source of traffic, and capacity from a provider.
How it works
Case study: the GitHub memcached attack
In February 2018 the code hosting site GitHub received what was reported as a record attack of about 1.35 terabits per second. The attackers did not need a large botnet. They sent small requests with GitHub's address spoofed as the source to memcached servers that were exposed to the internet over UDP, and the servers sent very large replies to GitHub.
The key lessons are:
- Amplification: the response was tens of thousands of times larger than the request in the worst cases reported.
- Spoofing: servers replied to the victim because source addresses were not checked.
- Exposed services: memcached should never be open to the internet. Disabling UDP support and filtering the port closes the hole.
- Mitigation: GitHub routed traffic through its DDoS protection provider, which filtered the attack traffic in a scrubbing center. The service was disrupted for only a few minutes.
The same pattern appears in other attacks that used DNS or NTP servers as reflectors, and in the Mirai botnet attack on the DNS provider Dyn in 2016, which used infected IoT devices.
Countermeasures
| Layer | Measure |
|---|---|
| Network edge | Ingress and egress filtering, unicast reverse path forwarding, rate limiting, access lists |
| Host | SYN cookies, shorter connection timeouts, connection limits per client, patching and hardening |
| Application | Web application firewall, caching and content delivery network, CAPTCHA and bot detection |
| Capacity | Over provisioned bandwidth, load balancing, autoscaling, anycast spreading traffic across sites |
| Upstream | Blackhole routing (drops all traffic to the victim address, which also stops legitimate users), sinkholing, scrubbing services |
| Preparation | A DDoS response plan, contacts at the ISP, baselines of normal traffic, monitoring and alerts |
| Hygiene | Do not run open resolvers or amplifying services, change default credentials on devices so they cannot join botnets |
Blackhole routing is a last resort because the attacker achieves the goal of making the target unreachable. Scrubbing is preferred because it removes the bad traffic and forwards the good.
Protection tools and services
These categories are the useful ones to know.
| Type | Role | Examples |
|---|---|---|
| Cloud DDoS mitigation | Diverts traffic through large networks that filter it | Cloudflare, Akamai, Imperva, AWS Shield |
| On premises appliances | Detect and block attacks at the edge | Radware, Arbor (NETSCOUT), F5 |
| Web application firewalls | Block application layer floods and abusive clients | Cloud and appliance WAFs |
| Detection tools | Spot unusual traffic and malformed packets | Flow analyzers, intrusion detection systems, Wireshark |
An organization commonly combines a cloud scrubbing service for volumetric attacks with a WAF and rate limits for application layer attacks. Always-on mode filters constantly, while on demand mode diverts traffic when an attack starts and takes minutes to engage.
A worked example
A company's online shop is flooded with requests from thousands of addresses and its bandwidth is saturated. Rate limiting on its own router cannot help because the link itself is full. The right action is to divert traffic to a cloud scrubbing provider by changing routing or DNS, because only upstream capacity absorbs a volumetric attack.
How the exam asks about this
- "Which server setting prevents a SYN flood from filling the connection table?" -> SYN cookies.
- "Which action drops all traffic to the target address, including legitimate traffic?" -> Blackhole routing.
- "What was the key technique in the 2018 GitHub attack?" -> UDP amplification through exposed memcached servers.
What to remember for the exam
- The GitHub attack used memcached amplification with spoofed source addresses.
- No single control stops DDoS. Layer edge filtering, host hardening, capacity and a scrubbing provider.
- SYN cookies help hosts survive SYN floods without storing half open state.
- Blackholing sacrifices legitimate traffic. Sinkholing redirects bad traffic to a controlled system.
- Preparation matters: baselines, response plan and ISP contacts.
Rate limiting at the target cannot fix a saturated internet link. Volumetric attacks need upstream filtering or scrubbing.
Common mistakes
Confusing blackholing and sinkholing. Blackholing discards traffic. Sinkholing redirects it for analysis.
Believing bigger servers solve everything. Capacity helps, but filtering and architecture matter.
Leaving amplifying services exposed. Open resolvers and exposed memcached servers turn you into an attacker's tool.
Check yourself
Why were memcached servers useful to the attackers?
Small spoofed requests produced very large replies sent to the victim.
What does a scrubbing center do?
It receives diverted traffic, removes attack traffic and forwards clean traffic.
Which measure stops your own devices joining a botnet?
Change default credentials, patch, and do not expose unnecessary services.
Topic 6 of 9 in Network and Perimeter Hacking
Test yourself on Network and Perimeter Hacking
The full EC-Council 312-50 question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by EC-Council. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.