Slashdot Mirror
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?
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?
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?
-=This sig has nothing to do with my comment. Move along now=-
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.
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.
Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
If a manufacturer made a device that connected to the public phone system, that could be compromised and made to call thousands of people at random, they'd soon find themselves facing product recalls, fines, import bans, and liability for the disruption caused.
Why should IoT devices be any different?
Some shitty noname Chinese remote webcam manufacturer hardcoded 'admin' as the password and tunnels through routers using uPnP to listen on the internet? Import ban that shit. Slap on a fine. Seize any of their American assets or property to pay it. They'll soon get the message that security can't be neglected. It's not hard to fix this stuff given the will.
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.
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.
There is a reason send/return pathes are not included.
Go look at how many bytes addresses for 10 hops would take. Now scale that up to the maximum of 255 (most routers TTL-kill connections over 40-60 hops to avoid routing loops. Lack of connectivity to remote sites when key routers go down is often due to this limitation even if alternate paths are available. Good for reducing traffic, bad for 'worst case connectivity' reliability/redundancy.) The real solution long term would be a 'push back' anti-DDOS system where ips/ranges considered to be spamming the host can be 'pushed' back to routers, which in turn could push IP blacklist information to the next router back when incoming packet floods are recieved, and pass the block to the next router back until it is blocked at the originating ISP. As with the 'include all hops' idea it requires a *LOT* of overhead, which backbone switches/routers cannot afford and which most edge routers are not specced to handle.
However, were this to be done it would provide the least strain on the network for the most bandwidth savings, since it would over time reduce the bandwidth pressure on all but one participating link (since the border link between participating and non-participating ISPs would still be DDoSed) and lower the packet load on all other hops which in turn would have more resources available to provide normal traffic and analysis for said pushback service.
Maybe someone could mock it up for us on OpenWRT with a few 100M/1G routers that could handle the header analysis load so that it remains an unpatented idea (if someone has not already patented it.) And if not, write a royalty free RFC for future implementation. The basic idea could be applied to every other internetworking protocol, given sufficient cpu/memory. It should also ensure all well behaving programs would not be filtered since the threshold to blockage would require saturating a link beyond an acceptable percentage of throughput, which existing mechanisms should deter via voluntary rate limiting.
There already is a solution to this. We've done it already with email and with the increasing compromised accounts/junk message spam on iMessage getting throttled.
If someone is part of a botnet, then when someone reports being DDoS'd, they report it and the higher level ISP's should be notified. Cut them off temporarily, give them the same message that violators of MPAA/RIAA are given on their ISP's where they get a standard message that they are a shithead instead of loading normal pages and have to call in to an ISP to get the ban lifted.
"Your computer is running outdated software, is actively infected. We'll lift the ban for a few hours, but if you're still part of the botnet after 3 hours, you're banned again until you call us again."
Something along those lines. If you're running an infected system and get reported, then fuck off and either call a family member that knows computers or take it to a shop and have it cleaned.
"Well kids, you tried your best, and you failed. The lesson is, never try." -Homer Simpson
It's been said before here, so allow me to offer a "how" for the obvious and already mentioned "secure the damn crap people hook up to the net".
This will only work with legislature. Sorry to all my libertarian friends here, but yes, there are times when the only way to sort out a problem is government intervention. These times are when you have to force people to do something for the "greater good" when they themselves would have a (smaller) profit from not giving a shit. And if there has ever been a good example, it's this. People don't give a shit about their IoT devices being insecure, because it does not affect them directly, but these insecure devices threaten the usability of the internet for all of us.
This is one of the reasons organizations like the FCC were created. Remember that sticker? Few people notice it nowadays because, well, it's a given that devices don't create harmful interference and that they don't go bananas if they are subject to any, but this was anything but certain in the early days of electronics. And no, that sticker itself doesn't do jack, of course, but it is a promise that the manufacturer has to live up to or face a heavy fine and ban of his device.
We need something like this for the IoT devices. "This device will not cause trouble on the internet and cannot be hijacked from there". Live up to it or see your device recalled. It pains me to ask for this, but it's time to create a government entity that deals with this. Or maybe hand it to the FCC so they start doing something useful again.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
You could start by not giving IP addresses to kettles and toasters.
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.
You are not alone. This is not normal. None of this is normal.
I was 100% unaffrected by the DDOS attack on DNS because I run a cacheing DNS server that I set to break the rules of DNS. I cache DNS until I get an update.
a DNS request is passed through to the main servers, if I get no response in 100ms I fall back to cached information. cached information does not expire for 30 days
so unless some obscure site that changes it's IP constantly decides to hop IP's during the DDOS attack I have zero issues.
Do not look at laser with remaining good eye.