Slashdot Mirror
Ask Slashdot: What Should We Do About the DDoS Problem?
An anonymous reader writes: Distributed denial of service attacks have become a big problem. The internet protocol is designed to treat unlimited amounts of unsolicited traffic identically to important traffic from real users. While it's true DDoS attacks can be made harder by fixing traffic amplification exploits (including botnets), and smarter service front ends, there really doesn't seem to be any long term solution in the works. Does anyone know of any plans to actually try and fix the problem?
https://tools.ietf.org/html/bcp38
DDoS attacks are only possible because of the ready availability of huge networks of compromised computers. Fix that, and the world becomes a better place.
Also, this peace on earth thing has been a while coming, you might want to take a look at that. too.
And flying cars.
It's supposed to be completely automatic, but actually you have to press this button.
Widespread adoption of the security flag should help quite a bit.
The internet protocol is designed to treat unlimited amounts of unsolicited traffic identically to important traffic from real users
It's a packet-switched network, so for anything else to be true, somebody along the line somewhere has to make that decision. But only you can make that decision when it hits your gear (and you could prioritize there, at your expense).
What the Internet lacks is a reliable social scheme for managing problems. One could imagine a guild of operators and paths of trust where a member could send a signed shutdown message through the network to known-offenders, putting his reputation on the line with every such action, per the review of the end-connection provider.
But network engineers tend to not want to socialize with each other or extend trust. Protecting the downside at the expense of the upside is a very common human foible - it kept our ancestors from being eaten.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
So I attended a local security talk a couple of months back and there I asked a security expert from my ISP (Telenor - Norway) if they blocked outgoing packets with source IP address differing from the real sender address.
"No" he said.
WTF? I am sure there is some legitimate reason for being able to send such a packet, but I can't think of any, and the contract should be amended to say "no spoofed source address unless agreed upon".
Sending spoof packets should make the ISP auto-throttle them if not just black-hole.
I've actually thought about this and come up with the following TCP extension:
Routers all maintain a reasonably sized set of source/destination/timer triplets. If a packet comes in from 'source' and is headed to 'destination', drop it. When 'timer' expires, drop that rule.
A special new "Add rule 'source,destination,timer'' packet is added, to be sent to a router. This causes the router to initiate a 3-way handshake with 'destination' to confirm that they requested the new rule, and if so, they add the rule to their table and set the expiration timer.
The idea is simple: If you're being DDoS'd, you don't have much bandwidth, but you always have bandwidth available between you and the first router, so you can always send them special packets telling the first hop router to drop all packets that you suppose are malicious, with a small timer so that you can renew it. After that's done, you should have eased the traffic enough to send more table-update packets to the second hop routers, and then to the third hop routers, and so on, until you've pushed the 'timed reject rule' right back up the traceroute chain until its at the source's doorstep and can go no further. At that point, not only are you free from the DDoS, the routers themselves no longer have to handle the traffic, either, as you've cut it off very near to the source.
The rule expiration timer makes it so that you need to actively maintain the rules or they'll disappear, and furthermore, it makes it so that when the DDoS stops, normal traffic can resume just fine. You can always 'peek' to see if the DDoS is ongoing by letting a few timers expire and watching to see if the malicious traffic is still coming through. If it is, update the rules and block it for some more time.
I work for a carrier. Together with companies like Arbor Networks, we already have systems in place that can mitigate most volumetric attacks, and many more intelligent attacks. Unfortunately, it's not cheap. Customers have to be willing to implement (and pay for) the protection services that most serious ISPs already offer as options on their IP traffic products. Keywords for your search are Pravail and PeakFlow.
Steve -- If you have to call it a system, you don't know what it is.
ET$)##515E@[NO CARRIER]
For the younger /. readers out there: this is an old joke that dates back to the days when we used to have to use actual telephone modems to connect to the Internet.
Noise on a phone line could produce garbage characters, and if you weren't using an error-correcting protocol the garbage could show up as if you had typed it. If you were using a "dumb terminal" directly with a modem, whatever the modem received would be printed. And, a modem might actually return the string [NO CARRIER] to your terminal when a connection dropped. (If you were using a computer and an Internet routing protocol like SLIP or PPP, the checksums would be unlikely to be correct in the face of the garbage. Neither the "line noise" garbage characters nor the [NO CARRIER] string would appear in that case.)
So, this joke implies a catastrophic event that first causes noise on the line and then disconnects the line. Now you know, and knowing is half the battle!
P.S. Any resemblance of the "line noise" string to Perl code is purely a coincidence.