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?
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.
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.
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.
Civil or criminal solutions are intrinsically Local, with varying measures of corruption involved.
No, I disagree. Governmental authorities are not equal, and that's helpful in this potential area of regulation.
If the United States and European Union were to introduce common IT security fitness requirements then they would likely be more than enough to form a "critical mass." A fairly straightforward legislative remedy, at least conceptually, would be to require Internet connected device and software vendors to provide complementary, opt-out, timely security updates for a minimum of X years after product withdrawal from sale (where X varies by product category, never less than 5) or, if failing in their obligations, to be barred from selling any new devices and to owe per device per month financial penalties to a consumer restitution fund. The penalty amount would be based on the product's market price but also subject to an inflation-adjusted minimum. Vendors might also be required to post performance bonds before first sale so that these security obligations (and restitution) survive their corporate demise. Then, even if Uganda, for example, does not enact the same legislation (or does not enact "proxy" legislation which simply says "the product can only be sold in Uganda if also legally offered for sale in the U.S. or E.U."), the combined might of the world's two largest economies would be enough to establish a global standard in vendor security maintenance practices.
Government product fitness regulation could work quite well in this instance.
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
isn't that what's sometimes referred to as "the Slashdot effect"?
That's not a great argument. Companies, big or small, that ship security defective products, and that do not repair security defects in timely and convenient fashion, probably shouldn't be making Internet connected products at all. If your company ships crap, and if your crap stays crappy, causing material external harm to others, why should your company expect government acquiescence in your crappiness? You shouldn't.
Besides, it's not a "big" versus "small" issue, not in this instance. There are some excellent, security savvy companies that happen to be small, and there are some truly awful ones that happen to be big. What would be helpful to small businesses, if there is new regulation (probably), is for the industry to get ahead of that regulation and to promote a common, industry wide approach so that the U.S., E.U., and other regulatory "zones" are as uniform as possible. Frankly I'm surprised regulators have had as much patience as they've had. That patience won't last.
You talk like keeping stupid people off the internet is a bad thing.
What a strange position.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Then small companies can no longer make any IoT product.
Not necessarily. It depends on what your standards and rules are.
Sure, you could write the rules in such a way that only big companies can afford to comply with them. It doesn't mean you have to. What's more rules could actually ensure small companies could remain competitive by creating safe harbors if you do certain things. Believe me there are lawsuits coming in the future, whether there is legislative or regulatory action or no. It would go a long way toward keeping the little guy competitive if he could point to rules that he was supposed to follow and did. This would socialize the cost novel attack vectors evenly rather than distribute the costs stochastically.
Eliminating the low-hanging fruit could make IoT devices reasonably safe, and "reasonable" is a much more attainable goal than "absolutely". Everyone fails at "absolutely", but only big companies can afford to bear the cost of that failure.
As for stuff getting designed in China, it's the low prices, period. I actually evaluated some Chinese radio linked flow meters a few years ago -- they were intended for metering liquor being poured in casinos (where the "free drinks" paid for by the casinos are acdtually paid for by a subcontractor and poured by a bartender who lives on tips). We wanted to adapt them for pesticide flow metering. The guy we were working with was selling these gizmos at $200, but they arrived on his US loading dock from China all boxed and ready to ship out to customers at a wholesale price of about $3. I was astonished. That's why stuff like that doesn't get made in the first world anymore, it's the jaw-droppingly low wholesale prices. Quality wasn't great, but with a $197 margin you can afford to ship replacements out for free.
Adding regulatory compliance costs to a device like that actually favors domestic producers.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.