1.35 Terabits Per Second — What the GitHub DDoS Teaches Everyone Else

Last Wednesday, February 28th, GitHub absorbed the largest DDoS attack ever publicly recorded — traffic peaking at 1.35 terabits per second, roughly double the infamous 2016 Mirai botnet attack on Dyn. And here's the remarkable part: GitHub was back within about ten minutes. No botnet of hacked cameras this time, no army of compromised machines — just a few spoofed UDP packets and thousands of innocent, misconfigured servers doing the attacker's work for them.

The record is already under threat — reports this week describe an even larger attack, north of 1.7 Tbps, against a US service provider using the same technique. This one is worth understanding even if you'll never see a terabit of traffic, because the lessons scale all the way down.

How memcached amplification works

The weapon is amplification — an old idea executed against a newly discovered, spectacularly effective target: memcached.

Memcached is an in-memory cache that backends use to speed up databases. It was designed for trusted internal networks, so it ships with no authentication — and until very recently, many builds listened on UDP port 11211 by default. Thousands of servers ended up exposing that port to the public internet, mostly without their operators ever knowing.

The attack chains two properties:

• UDP doesn't verify the sender. Unlike TCP, there's no handshake — a packet claims a source address and the receiver believes it. An attacker sends memcached a small request with the victim's IP forged as the source, and memcached obligingly sends its response to the victim.
• The response dwarfs the request. First the attacker stuffs a large value into the open cache, then requests it repeatedly with ~15-byte packets. Reported amplification factors run as high as ~51,000x — the largest of any amplification vector seen to date, an order of magnitude beyond DNS or NTP reflection.

Multiply across thousands of exposed servers and a modest botnet becomes a terabit firehose. Against GitHub, the flood arrived from over a thousand distinct autonomous systems across tens of thousands of endpoints — none of them malicious, all of them misconfigured.

Why GitHub survived in ten minutes

GitHub's own postmortem is admirably transparent, and the timeline is the lesson:

1. 17:21 UTC — inbound traffic explodes; network monitoring flags the anomaly within seconds.
2. 17:26 UTC — GitHub reroutes its traffic to its DDoS mitigation provider, which scrubs the flood and passes clean traffic through.
3. ~17:30 UTC — service substantially restored. Total user-visible impact: roughly ten minutes.

Nothing about that response was improvised. The mitigation contract existed, the rerouting procedure was rehearsed, the monitoring caught the attack the moment it started, and the decision to fail over took minutes because nobody was debating options mid-incident. A 1.35 Tbps attack ended up as a footnote-length outage — that's what preparation buys.

Lesson one: never expose UDP services you didn't mean to

The supply side of this attack is pure negligence — thousands of memcached servers that should never have been reachable from the internet. The fix costs nothing:

# Is your memcached listening on a public interface?
netstat -ulnp | grep 11211

# In /etc/memcached.conf: bind to localhost and disable UDP entirely
# -l 127.0.0.1
# -U 0

And firewall it regardless — defense in depth:

iptables -A INPUT -p udp --dport 11211 -j DROP
iptables -A INPUT -p tcp --dport 11211 -s 10.0.0.0/8 -j ACCEPT

The same audit applies to every internal service: Redis, Elasticsearch, MongoDB, NTP, SSDP. If it was designed for a trusted network, it must never face the internet. Scan your own address space before someone else does — from outside your network, since that's the vantage point that matters.

Lesson two: know your mitigation path before the attack

The uncomfortable truth about volumetric DDoS: once the flood is saturating your pipe, you cannot fix it from inside. Dropping packets at your own firewall doesn't help when the link upstream of you is full. Mitigation means someone with far more capacity — a scrubbing service, a CDN, your upstream provider — absorbing the traffic in front of you.

Which means the preparation is entirely front-loaded:

• Have the relationship in place. Whether it's a CDN with DDoS protection, a scrubbing service, or your host's built-in mitigation — know what you have, what it covers, and what triggers it. Discovering your options during an attack adds hours to a fight measured in minutes.
• Know the failover procedure cold. GitHub's reroute was a practiced motion. If your equivalent involves a support ticket and a DNS change with a 24-hour TTL, you've already lost — audit your TTLs now.
• Know who decides. Mid-attack is no time to figure out who has authority to swing traffic. Write the runbook, name the people.
• Right-size it. A small business doesn't need GitHub's setup — sitting behind any reputable CDN with basic DDoS absorption covers the overwhelming majority of what a small site will ever face. What's inexcusable is having nothing and no plan.

Lesson three: monitoring is how you know absorption is working

Notice what bookends GitHub's timeline: detection at the start, verification at the end. Monitoring told them the attack had begun within seconds, and monitoring told them the mitigation was actually passing clean traffic afterward.

During a DDoS, external monitoring answers the only questions that matter, minute by minute: Are we reachable? From where? How degraded? Scrubbing isn't binary — mitigation can absorb 95% of the flood while real users still see timeouts, and internal dashboards showing healthy servers won't reveal that your upstream link is saturated. Only a check from out on the public internet sees what your users see. It's the same reason patch-driven slowdowns need external baselines — we made that case last month with Meltdown and Spectre: the view from outside is the ground truth.

Be the ten-minute story

The GitHub attack is the rare security story with a happy ending, and the ending was written weeks earlier — in a mitigation contract, a rehearsed runbook and a monitoring setup that flagged the flood in seconds. The record will keep falling; whether the next attack on you is a ten-minute story or a ten-hour one is decided now.

CompleteStatus gives you the outside-in view: uptime checks from the public internet, failure confirmation before alerting, response-time history to see degradation — not just downtime — and alerts by email, Slack or webhook the moment reachability changes. Create a free account and make sure that when something big hits, you're watching from the vantage point that counts.