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

Set up correct secondary DNS servers

[tlambert]

Set up correct secondary DNS servers.

If the secondaries had not been hosted at the same company, but instead at various companies around the world, the attack would have had no effect on anything but traffic.

This is, by the way, how multiply connected networks are supposed to work.

This could be easily accomplished at no additional cost by having a peering-pool arrangement between all the host registrars, so that we ended up with a multiply connected redundant network.

Kind of how we designed the thing to work in the 1960's and 1970's, and DNS itself in the 1980's.

But a lot harder for law enforcement to issue DNS-based takedowns on, of course. Since it would route around the damage and keep functioning. As designed.

DoS

[ledow]

As most of this traffic was "genuine", i.e. not spoofed, not faked, not bouncebacks, not violation of the protocol, etc. it's hard to do much about it. Even if you were running protocols where each packet had to be part of an authenticated stream, you would still have the same problem.

The only technical solution I can think of is a protocol with which you can communicate with an upstream host and have them implement a filter of your choice to the traffic they send you before it comes down your line.

Quite literally "please block anything from these IP's or traffic that matches this pattern".

But I cannot imagine such a thing ever be implemented as it pushes the burden further and further upstream and the top-layer will be overwhelmed with traffic and their filters running hot all day long, especially if they have millions of customers all specifying complex rules.

There's no way I can see to stop something like this, where millions of random devices starting genuine full connections and responding as any other client, without just rate-limiting (which rate-limits your other genuine clients) or engaging in the packet conversation as you normally would (which would be enough to cause a DoS in itself).

Even if you can spot a pattern, it'll be changed in the next iteration, or dynamically and randomly generated in time. It's like spam-filtering at packet-speeds, and as stupendously unreliable.

Previously, it was faking source IPs, which can be solved by ISPs being required to only allow their announced ranges. Now, with just millions of valid connections, a DoS is indistinguishable from a service just suddenly becoming incredibly popular with real users.

Any method, protocol, or setup where they have to connect to you like that and you perform some kind of check or measure against their connection (even, say, setting up a TLS session) can be replicated by the botnet just as easily.

There's no solution to what is effectively "junk mail" inside a TCP/UDP packet.