Slashdot Asks: How Can We Prevent Packet-Flooding DDOS Attacks? (oceanpark.com)

Just last month Brian Krebs wrote "What appears to be missing is any sense of urgency to address the DDoS threat on a coordinated, global scale," warning that countless ISPs still weren't implementing the BCP38 security standard, which was released "more than a dozen years ago" to filter spoofed traffic. That's one possible solution, but Slashdot reader dgallard suggests the PEIP and Fair Service proposals by Don Cohen: PEIP (Path Enhanced IP) extends the IP protocol to enable determining the router path of packets sent to a target host. Currently, there is no information to indicate which routers a packet traversed on its way to a destination (DDOS target), enabling use of forged source IP addresses to attack the target via packet flooding... Rather than attempting to prevent attack packets, instead PEIP provides a way to rate-limit all packets based on their router path to a destination.
I've also heard people suggest "just unplug everything," but on Friday the Wall Street Journal's Christopher Mim suggested another point of leverage, tweeting "We need laws that allow civil and/or criminal penalties for companies that sell systems this insecure." Is the best solution technical or legislative -- and does it involve hardware or software? Leave your best thoughts in the comments. How can we prevent packet-flooding DDOS attacks?

Comments

Technical OR legislative?

[Calydor]

Why not both?

Why is it so hard to grasp the concept that both a problem and a solution can be more than ONE THING?

Re:Technical OR legislative?

[Spazmania]

PEIP is a technical non-starter for several reasons:

1. Not enough room in the IP header to record the path.

2. Changing the packet size in flight would greatly exacerbate the impact of the PMTUD design error in normal operations.

3. The router data plane is a poor location for any kind of complex programming.

4. The same people who have failed to implement BCP38 would have to implement the much more difficult PEIP.

5. It's whack-a-mole. The nature of the attacks is evolving from spoofed source addresses to distributed botnets with each bot performing a complete IP transaction with its own IP address. If everybody implemented BCP38 tomorrow, theses newer kinds of DDOS attacks would continue unabated.

Ineffective

[DeathToBill]

Technical measures that prevent address spoofing are quickly becoming obsolete anyway; AFAICT, the recent attacks on Krebbs and Dyn, the two biggest DDoS attacks ever, didn't use spoofed source addresses. A spoofed address is only useful in an amplification attack, where you send a small request which provokes a much larger response; then if you don't spoof the source address, you get a huge firehose of responses coming at you and it's you that gets DDoSed, not the target.

In this case, the attackers didn't bother spoofing source addresses, because they didn't use an amplification attack; they just used a huge botnet all making ostensibly-valid requests and each device dealing with the response individually. It looks like the only way we have of preventing this sort of attack is to make the devices secure - easier said than done.

Re:Make ISPs at the source responsible

[ledow]

They are.

No source addresses were faked here.

Just millions of "genuine", unfaked connections.

That's the "new" part of this attack. It's not trying to pretend it's anything that it isn't. It's literally just millions of devices requested advertised services and responding to their responses in the correct manner.

Imagine a DDoS of just asking for Wikipedia pages. It's hard to combat because you have no way to distinguish it from just a sudden surge of genuine traffic.

Secure the gateways

[squiggleslash]

Reading this is fairly eye opening as it explains the different methods attackers use to gain access to your NAT-"firewalled" IoT device. It was also a useful reminder that IoT items aren't just "IP cameras", but routers, printers, and other stuff that most people have had for years.

You can skip to page 34 for the most important problem with most of the headline devices though (which also explains why owned cameras is a big thing, but less so owned routers): insecure "cloud" servers that provide connectivity to your IoT devices when you're off network. For example, it provides the connectivity that allows an app on your phone to access your baby camera remotely.

The servers typically provide way too much information, and often provide access to the entire camera, not just the video stream. As a result, hackers can, by scanning a range of camera IDs using the server at minimum find out what the public and NAT IPs are. They may be able to send arbitrary packets, including those to backdoor debugging ports, depending on the server, without even needing passwords.

Outside of using that server, hackers become more dependent upon heavy, probably noticeable, scanning, making it increasingly difficult if you don't already have compromised hardware.

My takeaway? Go after the manufacturers. There's stuff they can do right now by patching just two things: the gateway servers they are running right now, and the apps that use them. Yes, in this case, it's worth doing - those here saying "Oh they're all fly by night, you can't reach them" forget that if that were truly the case, there wouldn't be a problem, because the gateways they're running wouldn't be up.

Someone is running the gateways. Those people can fix them right now, and need to.