Fighting a 25 million packets-per-second DDoS attack

happygeek 0 Tallied Votes 449 Views Share

An unnamed Asian company operating within what has been described as a 'high risk e-commerce industry' has been targeted by a botnet which launched a DDoS attack of unprecedented magnitude. According to Distributed Denial of Service mitigation experts Prolexic, which claims to have successfully combated the attack, the volume of this particular attack was nothing short of extraordinary.

How so? Well, consider that most high-end border routers employed by your average ISP are capable of forwarding around 70,000 packets per second typically. Now consider that the volume of this DDoS attack using TCP SYN Floods and ICMP Floods reached 25 million packets per second at its peak.

Prolexic were able to determine that the botnet being used by the attacker consisted of no less than 176,000 zombie computers. This in itself should be enough to raise eyebrows within the security industry seeing as the previous five attacks that Prolexic successfully mitigated featured no more than 5,000 to 10,000 bots being deployed for each.

Paul Sop, chief technology officer at Prolexic, explains that the Asian company being targeted had unsuccessfully attempted to stop the attacks for "many months" with the help of both the ISP and carrier concerned. However, the sheer volume of the packet flooding proved too much. Prolexic was able to mitigate the threat by distributing the traffic between a number of global Tier 1 carriers and 'scrubbing' network centers. Sop warns that this massive attack in Asia could be "an early warning beacon of the increasing magnitude of DDoS attacks that may be on the horizon for Europe and North America in the next 6 to 8 months" adding "high risk clients, such as those extremely large companies in the gaming and gambling industries in Asia, are usually the first targets of these huge botnets just to see how successful they can be."

Dani AI

Generated

Useful, practical add-on to the thread that expands on the technical and operational side without re-stating the original incident details.

This type of packet-rate attack (where sheer packets-per-second, not just raw bits, trips devices) stresses routing/forwarding and mitigation stacks differently than classic bandwidth-only floods. Measure packet-rate anomalies early (pps is a first-class metric for mitigations) and treat SYN/ICMP floods as problems of state and CPU on devices, not only link saturation. (rfc-editor.org)

Short triage checklist (do these in parallel, coordinate with ISPs): enable telemetry, capture samples, harden the TCP stack, and apply conservative edge policing. Quick, safe commands to gather evidence and reduce SYN pressure:

# sample SYN-only packets (short capture to avoid filling disk)
sudo tcpdump -i eth0 -s 96 -c 200000 -w syn-sample.pcap 'tcp[13] & 2 != 0 and tcp[13] & 16 == 0'

# check/enable Linux SYN cookies
sysctl -n net.ipv4.tcp_syncookies
sudo sysctl -w net.ipv4.tcp_syncookies=1

# simple per-interface SYN rate policer (iptables example, test carefully)
sudo iptables -N SYN_LIMIT
sudo iptables -A INPUT -p tcp --syn -j SYN_LIMIT
sudo iptables -A SYN_LIMIT -m limit --limit 100/s --limit-burst 200 -j ACCEPT
sudo iptables -A SYN_LIMIT -j DROP

SYN cookies and kernel tuning are useful stopgaps but not a silver bullet; they trade functionality for survivability in heavy SYN floods. Use captures for post-event forensics and to feed upstream parties. (documentation.ubuntu.com)

Network-level actions that typically reduce time-to-mitigate: request upstream RTBH/Flowspec installs or traffic diversion to a scrubbing/Anycast network (these are provider-side operations and must be coordinated to avoid broad collateral damage). Remote-triggered black-holing and engineered scrubbing are standard options, and long-term fixes include source-address validation (ingress filtering) and always-on CDN/Anycast front-ends for high-risk services. Coordinate legal/abuse channels early — attribution is hard and requires preserved logs, NetFlow/sFlow and PCAPs before asking law enforcement or takedown partners to act. (datatracker.ietf.org)

Notes tied to the thread: ’s skepticism about quick attribution is warranted — avoid public finger-pointing without evidence. was right about the need to identify sources; collecting flow/pcap and working with ISPs and CERT/law-enforcement preserves options. ’s point about client risk underscores why recurring exercises, capacity planning, and baking mitigation into architecture (CDN/Anycast, per-service rate limits, and upstream contracts) matter. (cisa.gov)

pseudorandom21 166 Practically a Posting Shark

Meh didn't LulzSec say something about an FBI botnet?

happygeek 2,411 Most Valuable Poster Team Colleague Featured Poster

Seriously, there's nothing meh about 25 million packets per second...

swebsitedesign -2 Newbie Poster

in this case no doubt risk for the clients will me much greater

ownstlucia 0 Newbie Poster

Unless the source of the bonets can be identified "victory" can only be temporary; they are simply chasing ghosts.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.