Slashdot Mirror
OVH Hosting Suffers From Record 1Tbps DDoS Attack Driven By 150K Devices (hothardware.com)
MojoKid writes: If you thought that the massive DDoS attack earlier this month on Brian Krebs' security blog was record-breaking, take a look at what just happened to France-based hosting provider OVH. OVH was the victim of a wide-scale DDoS attack that was carried via a network of over 152,000 IoT devices. According to OVH founder and CTO Octave Klaba, the DDoS attack reached nearly 1 Tbps at its peak. Of those IoT devices participating in the DDoS attack, they were primarily comprised of CCTV cameras and DVRs. Many of these devices have improperly configured network settings, which leaves them ripe for the picking for hackers that would love to use them to carry out destructive attacks.The DDoS peaked at 990 Gbps on September 20th thanks to two concurrent attacks, and according to Klaba, the original botnet was capable of a 1.5 Tbps DDoS attack if each IP topped out at 30 Mbps. This massive DDoS campaign was directed at Minecraft servers that OHV was hosting. Octave Klaba / Oles tweeted: "Last days, we got lot of huge DDoS. Here, the list of 'bigger that 100Gbps' only. You can the simultaneous DDoS are close to 1Tbps!"
The sad part is that it was too late before the devices were even built. This is really no different than any other zombie botnet.
What is needed, IMO, is a standardized system for being able to report problems upstream—an ICMP response that says, in effect, "Suppress all traffic from x.x.x.x to y.y.y.y for five minutes" that propagates upstream. Ideally, it should use a three-step handshake to prevent forged block requests from being viable, where the recipient of that message waits until it sees a packet directed to y.y.y.y, (to avoid amplification attacks), then sends a packet that says, "confirm block id xxxx" and it responds "yes xxxx" after which it drops the traffic. If it gets no response, it should try three pings (with exponential backoff), and if they fail, it should assume that the server is saturated and it should block the traffic as requested. If they succeed and a subsequent confirmation fails, it should assume that the server doesn't actually support blocking requests, and that the blocking request was spoofed. If the response is "no xxxx", then the blocking request was spoofed, and the packet passes through with only that small extra bit of latency, and the blocking request is discarded.
If such a scheme were in place, then each botnet member joining in a DDoS attack would get blocked by their closest router, or at a bare minimum, by the router at their ISP, and would basically be unable to do any real harm.
Check out my sci-fi/humor trilogy at PatriotsBooks.
On the plus side it might finally lead to home routers getting some more interesting IP accounting features. That is one thing that has always annoyed me ever since I stopped having a Linux gateway - the home routers typically have no useful feedback as to what device is responsible for traffic.
Even a simple counter table would be incredibly useful, but I don't really see any reason why it would be hard to have good real-time graphs showing the current and total data usage from each IP on the network.
One interesting challenge though - what happens if you have an IoT device that is thoroughly pwned and keeps changing IP addresses (and/or MAC addresses!) specifically to make identifying it internally even more complicated?!