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?
I don't know if the carriers are implementing anything, which is really where this would have to happen.
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)
1. Hunt down and destroy botnets. (Fix bugs that cause PCs to be infected. Teach people about security.)
2. Make cloud services liable for the traffic they carry. (Make them know their customers and analyze traffic patterns.)
Okay, maybe more than two but the foundation of DDOS are based on these.
Send some sort of ICMP message upstream that indicates your maximum capacity for handling traffic. It's a DOS vector in itself, but you could minimize it.
Religion is what happens when nature strikes and groupthink goes wrong.
Clearly this problem cannot be solved at end user level, because a lot of end users are happy to use old compromized operating systems such as Windows XP and clicking "Yes" on random popups on the internet. The only plausible way of fighting DDoS attacks seems to be filtering malware traffic close to the source, i.e. by the ISPs at a router close to the subscriber, where the amount of traffic is still manageable. You need to have an incentive for the ISPs all over the world to invest in the required hardware though. How do you create that incentive? Through priority classes in the internet core, where compliant operators get access to priority bandwidth. Goodbye net neutrality - thanks a lot Lizard Squad and other angry script kiddies.
Eliminate malware. No bots, no more DoS attacks with enough size to matter.
How? Change the access paradigm to the Internet. Similar to work, go towards whitelisting and accessing only well-known sites, then block the rest. If home routers would integrate a reputation proxy service, 99% of the problem would simply fall off. No more c2 and no more malware binary downloads. Basically, we could spend our time worrying about a large number of known things vs. infinite unknown.
Google "one day wonders."
Yes, the idea is to stop making money on fake solutions and patches and deal with the root of the problem. Like dealing with why people / groups have the need to do DDoS attacks. Of course the solution will not arrive from within the system. I'm talking about changing the entire social / economic system from the ground. So destructive / abusive actions shouldn't be necessary. Of course we are years, maybe decades away. But hey, you asked about solutions, real solutions, not patches or firewall rules that will get outdated in the short term. So there you go. There are hundreds of ideas out there.
If ISP's stopped allowing outgoing syn packets with spoofed IP addresses the problem fixes itself NO?
IMHO, fixing the DDOS vulnerability would require re-engineering the way the Internet works from the ground up. Not impossible, but just costly and time consuming. I think as long as the cost to implement a new protocol is greater than the aggregate cost of dealing with DDOS exploits, we will not see substantive action on this issue as businesses and governments (none of whom have unlimited amounts of money or time) will be the key drivers on this front.
Internet Kill Switch
Political correctness is really just herd psychology pushed by insecure people who desperately seek social conformity.
They treat it the same, because it is indistinguishable. How do you tell if a computer is controlled by a person and trying to view your website to buy something, or by a bot and trying to view your website so that it can take it down? There are ways to tell at the ISP level, but that would involve an ISP scanning for suspicious behavior and kicking off users. There is no way to do this on a packet level, such that the Internet can just filter out DDOS packets. Maube we should redesign the packet such that they all have DDOS tags, and require all DDOS botnets to set the DDOS tag on all packets involved in DDOSing.
Troll is not a replacement for I disagree.
No more slapping the wrists of criminals caught engaging in this behavior, execute them and the problem will quickly go away.
Im a full-time computer science researcher and its not mentioned often, but the only real way to stop a DDoS is toET$)##515E@[NO CARRIER]
Good people go to bed earlier.
And the response is: nothing.
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.
It's the only way to be sure.
If I were an attacker looking to design the next generation of sophisticated DDoS attacks, the first thing I'd do is post a question to SlashDot asking about the next generation of defenses.
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.
ISPs need to have the ability to shut these compromised customers off at their first route. ISPs are already sniffing every packet so they should know when something is up. The victim need only send a list of attacking IPs to each ISP.
Once each customer is severed from the network, they will only be allowed back on once their machines have been verified as clean by a certified technician.[A+/Network+...something easy to find.]
I like to think of it as a car analogy. The internet is a highway and cars which use the highway must be inspected before they are allowed to use it. The inspection is only made compulsory when hard evidence that they are broken is reported.[they are clearly part of botnet].
How about a capability limit? Should be pretty obvious when suddenly an IP address starts getting hit with a lot of traffic. I would think that you could use the data of what the regular traffic is, and when it suddenly spikes by 1000x then you know an attack is on the way. So why couldn't an ISP, who is sending the packets to the server, slow it down when suddenly your getting a way higher number of packets to this server?
Be seeing you...
Reduce bandwidth by 95% by deleting all the HTML and JS cruft from your web pages, So pages can be served much faster. As long as you can replay to most HTTP requests, the normal viewers will eventually receive the page they where looking for.
Keep a small list of pending requests, and drop any requests from IP's that are already N times in that list.
Any solution would violate net neutrality.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
They can't DDOS you if you remove them from your HOSTS file.
Scientifically proven fact.
1) The IP receiving the data doesn't have to be the one requesting it.
2) Normal users have wildly varying bandwidth usage, while bonnets could generate almost perfectly constant bandwidth usage.
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.
The problem is that the Internet is Distributed, but websites are Centralized. The brilliant folks who designed the Internet accidently let morons design the web atop it. The way the web is currently hosted is a stupid idea, and that's the real problem: Storage is not decentralized.
The solution has been dubbed Disruption Tolerant Networking. There's no reason my neighbor shouldn't be pulling the cute cat video I linked them to from my own damn browser cache. When you think about it, caching services and co-location is a form of distributed data storage, so let's cut out the middle man and do this shit right: Every node needs to be a cache too, including the endpoints.
Essentially, to fix the problem you can just run HTTP over a distributed system like Bittorrent, but with better higherarchical caching to maintain locality where applicable. The more traffic, the more availability you get. Yes, you can leach, but in a properly system a ton of requests for the same resource
The problem is that if we do this then the NSA will not be able to spy on our traffic: There's no way to know that the resource I'm downloading is for me, it could be for my neighbor. You'd have to put snoopers between every single endpoint, at every switch. Currently they take data at places like Room 641A (which was around before 9/11, so the warrantless spying wasn't a response to that).
If the Internet gets a proper distributed data store system built atop it, then mesh networking will happen. The powers that be REALLY don't want that to happen, that's why the FCC is so strict about limiting packet radio's use. HAM radio folks have been using store and forward for decades, and that's basically what we need. Hint: A single RF antenna has a natural one-to-many broadcast property that a single CAT6 cable does not.
So, the answer is: YES, there is a solution, but NO you can not have it...yet. I've had nothing but some pretty scary blowback from my own attempts to fix this fucking obvious problem: Hurrr, let's put centralized data silohs atop a distributed network, Durr. Fucking idiots!
If we want to progress as a species and have nice things like DDoS free networks for off-planet colonies' Space Internet (DTN takes into account problems caused by lightspeed limitations) then we'll have to get over the fear of the populace being able to control its government and just roll out something like HTTP/BT.
There are things like Freenet, but they're not built for speed they're built for anonymity, which was a dumb move. If only they would have built that network for speed and had an anonymity option, then it would actually be worth a damn.
Treat it like cancer. If you can identify a single IP address, then the affected ISP should notify the ISP that owns the IP address to disable the connection of whatever computer was using it at the time. If the ISP refuses to comply in a timely manner then cut off all routing to and from that ISP network. Basically like what has been done to and from North Korea. And keep that network unreachable until a human negotiated settlement is reached. ISPs have the knowledge, resources and power to deal with botnets, that they would choose not to manage the problem effectively is a business decision and not a technical one.
Someone said, just fix all the flaws in the software... Good Luck! LMAO... That's a lot of code to perfect, simply not going to happen...
Look, its 2014, if the best your machine can handle is DOS its just time to upgrade, the hardware. If it is already newer hardware than say 1996, then upgrade to linux.
I know we all loved doctor dos back in the day but its time to give it up already, but by the same token, anyone still using it has to qualify as a senior citizen themselves....they are not a problem just leave them alone ffs!
"I opened my eyes, and everything went dark again"
1- Ban Address spoofing. Every packet from your address will have your IP address overwritten (with correct number) by your ISP. Just being able to find the source of the problem would be huge. Would also stop most spam. 2- Require ISP's to investigate reports of abuse/spam. Not sure how you'd keep the recording companies from abusing this to take down The Pirate Bay. 3- Every ISP would have a banned IP address list. Hopefully there would be a method to get your address removed after you purge the botnet off your home pc.
and they will go away
Currently, DDoS attacks use spoofed addresses etc. because they work and they're an easy way of amplifying traffic levels. But if you fixed those issues at the network level, DDoSes would still be possible by expanding the scope of the botnets generating them. The actual problem that would need to be solved in this case is "how do we tell the difference between a legitimate request from an arbitrary address vs. one pellet of a DDoS shotgun attack".
The only real solution to the botnet problem is to employ technological measures in every operating system to prevent running code that isn't signed by a trusted authority. Nobody wants to live in a world that draconian (well, except Apple users, but that's a different psychosis).
So when you slow it down, you slow down the good packets with the bad packets. You (the generic upstream ISP) can't tell the difference. Only that target X.X.X.X says we're sending too much to him and we need to throttle it down. So, we throttle down all that we are sending to target X.X.X.X. And all of our customers and downstreams and those transiting to destination X.X.X.X through us suddenly loose the ability to effectively use the target service. Not helpful.
Businesses likely to be targets of attacks can contract with their ISP to sort traffic into "likely BAD, PRESUMED BAD, likely GOOD, and BLOCKED BY CUSTOMER".
Traffic from an IP that has been BLOCKED BY CUSTOMER or PRESUMED BAD doesn't get through until the block expires. Depending on the customer's needs this may result in a silent block, a "busy, try again later" protocol-level error message, or a human-readable error message such as an ISP-displayed web page saying "the site you are reaching is not accepting connections from you now, try again after 15 minutes."
Likely BAD traffic gets blocked AND the sending IP gets added to a "PRESUMED BAD" list for the next few minutes (pick an arbitrary time).
Good traffic gets through, but if the customer recognizes it as bad, it can tell the ISP that this IP address (or range) is BLOCKED BY CUSTOMER for a period of time.
This isn't cheap for the customer or his ISP, but it won't require changes by anyone else. Because it isn't cheap, it won't help the "little guy" who can't afford such protection.
As an add-on, ISPs can report "bad" sites to a central "reputation clearinghouse" and once the "bad-ness" of a particular IP gets high enough (which will happen if a botnet member is attacking multiple victims), the clearinghouse can fire off a letter to the IP's ISP. If an IP is "chronically very bad" the IP address can be added to a blacklist made available to all ISPs.
Of course, this won't work as well if the IP is spoofed, so it may only work in conjunction with anti-IP-spoofing measures already talked about in this thread.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
"Or just kill the connection of infected machines at the ISP. It might ever increase awareness." - Anonymous Coward on Wednesday December 31, 2014 @06:41AM (#48703609) FROM -> http://mobile.slashdot.org/com...
See subject-line: That's one of the BEST (& most sensible + practical) approaches suggested here on /. (since the recent wave of DDoS attacks, e.g. SONY), imo...
NOW: As to what you CAN do vs. MANY TYPES of DDoS/DoS? Right here, listed (for Microsoft servers mostly, though there ARE some measures that'd apply to *NIX boxes also) -> http://games.slashdot.org/comm...
(I.E.-> It shows the parameters to use vs. "1/2 open connections" that aren't responding, or rather, CAPABLE of responding due to IP address spoofs etc., & turns them off as you see fit based on the parameters you set).
I agree with the AC poster I quoted above TOTALLY!
(Great idea: Cut the infected/infested boxes off, the owners WILL call the ISP once their service is interrupted, & they can be cleaned up @ that point, removing infestation that makes them DDoS "zombies"...)
APK
P.S.=> Of course there's ALSO DNS DDoS - & until DNS itself is fixed vs. it, the ONLY way I could think of (+ create a tool that protects you vs. bushwhacked DNS by avoiding it for your favorite sites you spend MOST of your time @ online) was this -> APK Hosts File Engine 9.0++ 32/64-bit http://start64.com/index.php?o... which a NICE part of "hardcoding" your fav sites not only protects you vs. DNS being downed or redirect poisoned (which 99.999% of ISP dns are NOT patched vs. the kaminsky flaw), but, also speeds you up, by resolving host-domain names to their IP address locally, cached in memory, faster than remote DNS resolutions too (double-bonus) - enjoy (it works, & to quote Howard Stark from the film "Captain America"? Well, hey: "It's stronger than steel, & a third the weight" of other "so-called 'solutions'"...)
... apk
I don't know if the carriers are implementing anything, which is really where this would have to happen.
Mmmm... just spitballing, there are two things that come to mind: (1) create a more asymmetric internet or (2) significantly reduce anonymity.
If you route machines with major penalties for any connections outside of machines they have connected to in the past week or month, for example, or if you require ISP-level configuration for peer-to-peer (at least logging into your ISP's web site to enable it), you could begin to reduce the usefulness of DDoS. On the anonymity side, you can strongly prefer authenticated and digitally signed connections, until at some point you perhaps only allow them.
It would add significant overhead, but if every packet, or at least connection, were signed by every piece of hardware it goes through, you could send (and sign) "compromised upstream" messages. When a large enough portion of traffic from any route becomes "compromised upstream," you bandwidth-limit (or even cut off) the route, with some intelligent rules for preferred traffic from that connection. (E.g. signed by a regular customer of the destination site.) End-users get messages once a day if they are generating compromised upstream errors.
The problem is it adds a *lot* of overhead.
You could also use the same system to *stop* junk phone calls.
Hosts absolutely work vs. DNS amp attacks & protect YOU the end user vs. downed &/or redirect poisoned DNS!
* To do MORE vs. DDoS/DoS? See here http://ask.slashdot.org/commen...
APK
P.S.=> The ac poster I replied to per the quote & link above had perhaps the MOST sensible measure that'd occur from the ISP level - cut off the "Zombies" used in DDoS/DoS of ALL types... apk
And, it's a cheap check; it doesn't take a lot of the router to check to ensure that, at the ISP level, outgoing packets belong. This is not cosmic; IIRC (it's been 2 decades) a single command to a cisco router will do this.
We need the global equivalent of a police force. We no longer live in a world divided by borders. We need an elected (not appointed) global government, with global laws, and with a world police force that can go after people whose crimes cross international boundaries.
OK.. now tell me one reason why this is a really bad idea. And then tell me how you would address that specific problem.
the growth in cynicism and rebellion has not been without cause
>. The penalties exacted for actually being the party behind a massive DDoS (when it can be proven objectively and conclusively) are not currently nearly severe enough.
What are the penalties now, and what do you think they should be?
I've seen some proprietary implementation of encoding multiple domains into a single url. Otehr have had a static home page with a list of alternate domains. That way you not restricted to a external CDN traffic control.
You say things that offend me and I can deal with it. Can you?
If the services being attacked are distributed then the distributed attacks are less likely to be effective as there are fewer choke-points.
From a Viewdata Corp of America proprietary white paper: "Rational and Overview of Requirements for a Videotex Local Programming Capability" by Jim Bowery circa 1982, section "The Primary Discipline":
Seastead this.
Why would anyone want to fix the problem?
DDOS mitigation services make money. DDOS attack services make money. The people who are targets are not going to do anything other than pay someone to help them stay on the air.
There is not even enough interest to take even reasonable and relatively trivial steps to fix DNS (draft-eastlake-dnsext-cookies-05) instead full steam ahead with DNSSEC we don't care about consequences.
BCP38 adds little additional value should the few broken protocols deployed in sufficient quantity to be useful for DDOS are fixed. The chance of that happening over time in the same way SYN cookies happened is in my view more realistic than expecting operators to implement BCP38 with enough coverage and granularity to be useful.
About those botnet armies of millions of unfortunate souls owned by viruses and malware... who wants to fix that? Security companies would go out of business right and left if millions of PCs ceased to get owned on a regular basis overwhelmingly not by exploiting vulnerabilities or viral propagation but by simple social engineering tricking people to run an attachment or download something from a website.
The perverse thread through all of this is total lack of market based incentive to fix anything. The more dysfunctional the network is to use the more people get paid to deal with the consequences and the more institutional pressure exists to retard progress.
It seems to me if you really cared to move the needle following would be necessary.
1. Replace SMTP.
2. Compel advertising networks to stop being complicit in propagation of malware.
3. Add n00b 1337 options when installing operating systems to give users rope commensurate with their needs and abilities.
Separate jails for browsers and downloads by default would help a lot. What isn't helpful is crap like UAC which does nothing to protect users data/environment or prevent system from being coopted for DDOS.
Isolated application model of mobile devices could also be helpful when architected to support rather than exploit end users.
The job of my marketing department is to make sure that our incoming orders increases by 1000x. I don't want that traffic to be ignored.
You could say, "attacks are sudden... customers increase throughout a day/hour... shut off attacks if they grow 1000x too quickly". But if a solution helps humanity by becoming sufficiently wide-spread, then attackers will adapt by having their botnets scale up attacks over a period of a few hours or whatever it takes.
The problem with DDoS is that we have false negatives. Any checking we do, to test for problems, indicates a negative: there is no problem, so the attack traffic is let through. Before proceeding with any solution, we must consider whether we will be reducing false negatives by introducing false positives, which many may view as being worse. (If the incoming legitimate traffic is actually crucial, then a false positive is likely worse.) And I don't just mean "proceeding" by actually implementing the idea. I mean proceeding to spend resources on the idea, including much further time/thought.
I'm glad you're thinking. Unfortunately, that idea seems like a non-starter. Please continue to come up with new ideas. Hopefully one of those will be so useful that the history books will widely cite your name, right next to other "household names" that we all know like that of Michael J. Muuss. Good luck.
...can only be defeated by distributed service. If your service comes from everywhere, then it's a zero sum game, and the attackers will give up.
Other acceptable answers include:
Take away the incentive... why are DDos's happening in the first place? Fame? Money? LOLz? Maybe you can't take away that third one.
Which has more power: the hammer, or the anvil?
I like the idea of turning the tables on them by consuming all the resources on the bots and causing the tcp stack of the system to crash.
Stopping IP spoofing by configuring routers to block traffic that says its coming from your network but is coming from the wrong interface (outside) would help.
But if a hacker has control of a few hundred + systems (botnet) they can consume all the resources on your servers just by making normal access request. So if your system is getting hammered by an attack like this you give that ip address to a system configured as labrea tarpit. A sticky honeypot. They flood it with syn the server now responds with 0 window acks. This causes the attacking bot to hold that tcp connection open waiting for the send window to open. They try to close the connection with RST the server says wait I have data to send you. The system can't cleanly drop the connection..... no big deal for a normal user to have a few hung connections. They get no response and think the site is down and come back later.
But the attacker who is flooding your site with connection request quickly consumes crashes its tcp stack because the system has allocated all available cache space in the tcp driver to these hung tcp sessions (it only takes a few thousand open sockets to cause the tcp driver to crash). The tcp stack cannot manage all these open sessions and dies. No TCP drivers, the bot falls off the internet, and needs user intervention to come back, the bot herder starts losing bots panics and runs away.... or keeps attacking leaving their herd decimated.
The system that is running the tarpit does not need any much for resources because its not actually creating sessions just sending packets that imitate a session.
Last I checked labrea is still part of the apt repository on Ubuntu.... But using it does change the shade of the hat you are wearing, and is dangerous if misconfigured.
Well Duh, that's been figured out already, thanks to McAfee.
McAfee says he can make internet hack-proof
If you're a home user not much you can do aside from releasing and renewing your IP. I work for supporting a fast growing SaaS product and I've had to do my homework on this.
Two things:
1. Make sure your edge firewall / router has a high Packets Per Second capability. A DDoS attack may not involve a lot of bandwidth but rather send a boatload of packets at you. Your edge network will need to process it all, and if it can't you start dropping packets for things you want and don't want.
2. Out bandwidth 'em. I've not tried it, but I'm interested in Akamai PLXrouted service. In a nutshell if you get a bandwidth attack you adjust your BGP routes to push traffic though Akamai, who can provide Terabits of shitfilter for you. DDoS zero, you win. Or cloud it, using Amazon EC2 as a filter with a bunch of proxy instances that self heal if they get knocked out.
There are related packet-protraction proposals that would help.
Require TCP and drop all other protocols. Yes, everything in /etc/protocols except TCP. Yes, I do mean everything. This is a 30+ year solution.
Develop some reasonable TCP flag rate limiting models and incorporate that stateful logic into next gen budget ethernet ASICs.
We all need a massive CDNs and "check for human" built in to our systems. When Google got hammered beyond anything sane, they mostly just absorbed it and tacked on a front end check. Google, Amazon and Microsoft should go into the business of selling DDOS insurance. They already have the CDNs and load balancers and would just need an API into their "check for human" interface.
This is not a problem that can be solved with a protocol or technical trick because the internet will never work that way (SMTP anyone?) until we outgrow the need. This is a problem that can only be really solved by making it an industry standard to develop for cloud based systems with insurance from the giants who can weather the storm and who have the influence to get corrective action out of ISPs in a timely manner.
So what would that look like? When you buy or renew your domain, you'd get an advertisement to "Add DSOS insurance" for a reasonable fee. Bigger companies would get better rates where they made agreements among themselves or negotiated with other CDNs but it would be unusual for any serious website to get knocked down because MS/Google/Amazon and others would also make agreements so that even the worst of the worst attacks would be absorbed.
That and maybe bring back the guillotine.
There are best current practices (BCPs) from network infrastructure up through application and service design which must be implemented in order to maximize resilience and minimize the potential for abuse.
There's some good information about how to deal with DDoS attacks here.
CloudFlare? (Or using the same techniques in other networks, CDNs, DNS providers, etc.)
https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/
http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack/
https://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet/
https://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho/
http://blog.cloudflare.com/65gbps-ddos-no-problem/
http://blog.cloudflare.com/when-the-bad-guys-name-malware-after-you-you/
If I were an attacker looking to design the next generation of sophisticated DDoS attacks, the first thing I'd do is post a question to SlashDot asking about the next generation of defenses.
Too much noise. Not enough signal.
First of all, you can't trust CPE, because an evil user might have their own, and an innocent users' CPE might have been cracked; you have to actually detect at the carrier's end of the access line. Having the CPE try to also implement it is nice, because it sometimes protects against compromised computers, which are more common.
But it's actually semi-ok if the Bad Guy spoofs a nearby address, just not a distant one. I'm going to change your numbers here, but if your home address is 1.1.1.1, and you send out a lot of spoofed traffic pretending to be from 1.1.1.3, you might annoy somebody on your block, but your bandwidth and theirs are probably similar, and your upstream is probably a lot smaller than their downstream.
The problem is that if you're faking UDP traffic from your target or another large site, so you start pretending to be from 8.8.8.8 (trying to swamp victim.com's DNS queries with fake ones), or start sending queries from v.v.v.v to 8.8.8.8, especially if Google still allows any UDP DNS traffic that has bigger responses than queries. And it's a much worse problem when you're a Bad Guy getting a whole lot of infected home computers to do that, so they all gang up on v.v.v.v.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It's important that the internet be open and equal to all, but at the same time 99.98% of the time Aunt Betty's XP box in Nebraska has no legitimate reason to interact with any computer in Vietnam, Russia, China, Latin America, Europe, Africa, or anywhere outside the US. We could prevent a lot of boxes from getting owned if people had an easy way to set their communications to Domestic only. I'm not just being a dick, but watching my logs I see more SSH attempts from overseas than stateside by maybe 10 to 1. The other big issue for DDOS is the cloud, where there are too many hosted servers that nobody is truly monitoring at all.
Sure, that'll stop some kinds of attacks. But the bots may not be sending TCP at all - they may be sending UDP, or faking UDP source addresses on DNS or NTP queries that generate big responses. Or they may not be doing full TCP, just sending the packets and ignoring the responses.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Sure, it's that simple, just tell your customers not to do Bad Things! And tell all those cable modem users not to click on the attachments in their email that might infect their machines, that'll keep them all from doing it, just like it keeps them from buying spamvertised products, and like telling corporate users who have seriously funded IT departments not to be a victim of phishing attacks. Just because you customers are using third-party webmail instead of ISP mail services, that doesn't mean you can't protect them, does it?
This stuff is REALLY ####ING HARD. 3-4 years ago, a big DDOS attack might be 1 Gbps, and ISP backbones were mostly 10 Gbps circuits, so an ISP running a bit cleaner box from Arbor or whoever had enough bandwidth to address the attack. Now we're looking at attacks at multiples of 100 Gbps, and if you want to clean that stuff you basically need those expensive boxes at every peering point, and you need to worry a lot more about false positives when you do.
If you're an eyeball-handling ISP, you can detect some problems, and you'd certainly better be running BCP38. But how do you tell if your customers who are all sending https queries to the same site at the same time are an infected botnet, vs. just all trying to download some popular web page they read about on Slashdot?
If you're a cloud provider, it's even tougher, because the technology and market are changing so fast that nobody knows what "normal" really looks like, and it's possible for somebody to spin up a botnet using a bunch of stolen-but-not-yet-blocked credit cards, attack, and run away before you've hit the $50 limit on each of them.
And remember how much abuse Carrier X got when they got into a peering fight with Carrier Y? Think what happens when they do it suddenly because Carrier Y seems to be hosting a lot of botnets. And then think about what happens if Carrier Y is Amazon (see previous paragraph) or $CABLE-COMPANY or China.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Too many lawmakers are doing well to understand that the Internet is a Series of Tubes with cat pictures and pirated music on it, and too many of the ones who have some technical clue understand it deeply enough to make meaningful, implementable laws. Remember the CAN-SPAM law a few years ago, that was going to save us from spam? We can't even get the NSA to find Rachel from Cardholder Services.
Nobody in the comments you're replying to was defending the people launching DDOS attacks from their PC. A DDOS attack is a Distributed Denial of Service; typically it has thousands or millions of infected machines each doing a bit of the attack, and you're not going to detect them all without doing Deep Packet Inspection on all the traffic, which isn't economically or technically feasible and would cause huge political controversy if it were.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It won't get much love, but... There's always Chromebooks.
Sure, it's that simple, just tell your customers not to do Bad Things! And tell all those cable modem users not to click on the attachments in their email that might infect their machines, that'll keep them all from doing it, just like it keeps them from buying spamvertised products, and like telling corporate users who have seriously funded IT departments not to be a victim of phishing attacks. Just because you customers are using third-party webmail instead of ISP mail services, that doesn't mean you can't protect them, does it?
Yup. You tell them when they buy the car not to speed. Then, if they do speed, you ignore them. Oh wait, if they speed, the police pull them over. That's the point. The person with the compromised computer is breaking the law. So lets start treating them like the hackers they are.
Learn to love Alaska
Individual addresses don't matter much at this level, except for communications that weren't going to be spoofed anyway (such as bot-to-controller traffic, which mostly hides behind moving DNS addresses.) And I don't know which router you're thinking about the botnets hijacking - BCP38 gets implemented by the ISP's edge routers, not the end customer's cheap vulnerable home hardware, and if somebody's hacking ISPs' routers (which I'm sure they are), there are lots more serious problems.
BCP38 spoof-dropping stops forged UDP connections, which blocks a lot of kinds of attacks from infected PCs, such as queries to DNS or NTP servers that send back bigger responses. It also stops some more subtle TCP attacks, like SYN floods or forged resets.
Dropping spoofed traffic also reduces some more interesting attacks (such as overwhelming the target's firewall or IDS with CPU-burning alarms - no need to break their web server if you can make their firewall crash by sending it too many obviously malicious packets that break its management connection.)
And sure, some of these attacks are old-school and boring, but they're still out there.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Have your traffic directed somewhere (probably outside the US) where data is cheap, filter out the malicious traffic, and route the good traffic through to your server(s).
Most linux users don't know this, but the man pages were named after Chuck Norris. Chuck Norris fsck'ing hates noobs!
The kinds of ISPs that are going to lie about it are either small enough that you can check their information (e.g. do good filtering on their BGP announcements, which you were going to do anyway just for reliability reasons), or big enough you can't do much about it (e.g. China's big providers.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
google POW.
The default setting on just about any SOHO router out there is that it does NAT from the LAN side (192.168.x.x) to the WAN (which gets one IP address from the ISP, either by DHCP or configured.) And of course, lots of people have more than one layer of NAT involved, because there's an ISP router (wired) and their own wireless one. But the defaults on SOHO routers generally also support UPNP, so it's easy to reset them.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Sure, Windows is wretched hive of scum and villainy, but a lot of that's not just the OS, it's Word and Excel and Powerpoint (which think every document should be a Turing-complete programming language that autoexecutes) and Outlook (which makes it so easy to click on HTML links, opens images by default, and can be tricked into running things) and Internet Explod\it\\rer.
But then there's Mozilla, which defaults to executing Javascript and which is almost always set to run Flash as well.
And then there are the more popular operating systems, like Android and IOS, which have applications that are written by all sorts of people, and which deliberately do all kinds of things nobody in their right mind would want them doing (like Angry Birds reporting your location), much less the things they do by accident or can be maliciously tricked into doing.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
So you Issue a Decree (you're king today, right?) that says ISPs have to immediately disconnect any botnets and terminate their service.
And Evil Botnet Dude modifies his botnet to spoof $TARGET1 attacking $TARGET2. And $TARGET1's ISP immediately takes them offline.
PROFIT!!
Tracing botnets is hard - it's a moving target, and the bad guys have access to as much crypto and security technology as the good guys do, and so much of the internet technology wasn't made to deal with clever malicious attackers, and much of it was designed to allow really private, relatively anonymous communications.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
MinimalT allows servers to require the solution of puzzles to defend against certain types of DoS attacks.
For brute force bandwidth flooding, we'll just need bigger pipes. Practically speaking, Cloudflare seems decent.
Sure, it's a cool-looking street-legal airplane, but if you want to get it into the air, you still need to drive to a runway, unfold the wings, and barrel down the runway at high speeds to take off, and then you need another runway to land it on, at which point you can drive away. It would have been really useful for my commute from Silicon Valley to Pleasanton (using airports in Palo Alto and Livermore), except for the parts about needing a pilot's license and a big pile of spare cash. But it's not going to replace cars and streets.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It certainly helps, and BTW you not only have to block spoofed-source packets with TCP SYN, but also UDP, and ICMP, and TCP RST, and a few others, but since you typically implement BCP38 by doing uRPF at the IP layer, all that happens together. And ISPs also have to be really careful with filtering BGP announcements they accept (which is harder than you'd think) so the uRPF works (because otherwise the Bad Guys can just announce that they really own IP block x.y.z.0/24 and spoof away, as long as they've hijacked some company's internet connection and not just a consumer who gets a single dynamic IP or a small static-routed block.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The person driving gets in trouble, not the owner. Intent is a big player in how court will handle this.
Yes, it has to be done at the source, but even then it's harder than it looks. If you've got a consumer IP connection, or a small business that's statically routed, you've assigned them an IP address or block of addresses, and you can filter strictly on that.
But consider a small-to-medium business that has two ISPs for reliability reasons. If you're Carrier A, it's perfectly legitimate for it to send out traffic with source address a.a.a.a or b.b.b.b, because maybe its connection to Carrier B is down or busy right now. Or if they're a medium-to-large business with their own routable IP address block, they might be sending you BGP announcements claiming to own address block c.c.c.c/x (which they do) or d.d.d.d/y (which they don't, so you'd better be filtering.)
And if your customer is an ISP themselves (or a hosting provider, or a cloud service provider, or some other complex thing), they might very well be sending you all kinds of traffic, and at best you're going to loose-RPF them and trust them to do the BCP38.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Hi, AC - You're talking about a different kind of IP spoofing. You're trying to make sure that website foo.com doesn't see that your traffic is always coming from IP address x.y.z.w (or at least x.y.z.*) and deciding to send a SWAT team to your house or tell you that there are lots of sexy women in [some town near you] who'd like to webcam with you. You get around that by going through proxy servers that send traffic to foo.com from their own IP addresses and relay the responses back to you.
This is about spoofing IP addresses of TCP or UDP packets so that the responses go back to the spoofed address instead of your internet connection, because you're doing DDOS or something else malicious.
For instance, you send a DNS query, source = $VICTIM's address, destination = $BIG_DNS_SERVER, query-type = SomethingBig, and the destination receives it, assumes it's from $VICTIM, and sends them a 600-byte response to your 64-byte query, and so they're getting hit with 10x as much traffic as you're actually able to send them (which is something you'd do if you're one of thousands of zombie bots in this DDOS attack.)
Or you're sending them a DNS response, claiming to be from Source 8.8.8.8, Destination $VICTIM, saying that YourBank.com is now located at 257.3.4.5 (which is really evil-site.ru), with the checksum forged cleverly (thanks, Dan Kaminsky!) so they'll think it was a response to a query they'd sent.
Or stuff like that.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Ah, you aren't aware of the car owner sent to prison for murder, who wasn't using his car at the time. A "friend" asked to borrow the car. While borrowing the car, he killed someone (not by driving, but robbing someone), so the owner was sent to prison for murder. http://en.wikipedia.org/wiki/R...
Murder conviction for letting someone else use your car seems to indicate that liability for letting someone use your computer is such a weird idea.
Learn to love Alaska
Hey, there's Slashdotting. Not a deliberate DDOS, because all the requests are legitimate, but it feels a lot like it.
A long, long time ago, in an internet environment far, far away, the Artists Against 419 project (or maybe it was 419eater?) had a website that would keep reloading lots of images from websites used by scammers in Nigeria, to burn up the limited bandwidth they had. Most of them were fake websites for banks, or Nigerian Ministry of Stolen Funds and Corrupt Officials, etc., and were usually on satellite links with limited bandwidth quotas. A few hundred people running the aa419 website could knock one off the air for a month. Bad guys in the better-connected world could also use techniques like that, but websites here can handle a lot more bandwidth, buy it at cheap wholesale prices, and afford protection like detecting too many queries from a given site.
But attacks don't always look quite the same as real traffic. Another classic DDOS technique is to send lots of TCP connection requests and then abandon them, either leaving the connection half-open (prompting the development of SYN Cookies and similar defenses), or going a bit farther into the interaction, with enough bots sending connections to make it hard for the website to answer the similar requests from real users. Does your web server track how many connections per second it'll accept from each IP address? If not, you can get DDOS'd. But if you do, you can hit false positives if, for instance, $BIG_COMPANY's employees are all trying to look at a website that their Engineering VP said they should look at, and the queries all come from the same firewall.
Or less subtly, you can get pounded with gigabits of packets being sent to your IP address, and you have to work with your ISP to deal with the problem, because you've only got a 10 Mbps pipe so it doesn't matter how smart your firewall is. If your ISP is dumb, you'll lose a lot of real traffic; if they're smart, they're using really expensive equipment and will charge you lots of money. Have fun.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It's been a few product cycles since I've really known how Cisco routers implemented things, and the balance between what gets done with ASICs vs. CPU has been changing constantly as CPUs (and ASICs) get cheaper, but simple spoof-proofing doesn't burn significant resources, because it can piggyback off the mechanisms that get used for routing. Basically, you look up the source IP address in the routing table, and if it's there (loose case) and points to the source Ethernet port (strict case) you allow it, otherwise you drop it, then you look up the destination address, and if it's there, you send the packet to the destination port, otherwise you drop it (optionally with some ICMP rejection message.)
The harder part is for endpoints that have BGP connections; you have to decide what policies to use to filter the announcements from the endpoint. In some cases it's easy (they've only got a few IP address blocks, and you enter them into some provisioning database that configures your router to only allow those), but in some cases your customer's network is more complex, and requires an actual human to do the configuration, or your connection was with another ISP or a big corporate customer, in which case filtering's a lot more complex because you're doing traffic load-balancing as well as trying to allow anything non-stupid to happen automatically and blocking anything stupid, and if your router had green paint on it there was a hard limit on how many routes it could accept and how much CPU it could use thinking about them, while if it had blue paint the CPU wasn't usually the problem but other things were (especially if you and the people you were peering with had different-colored routers.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Yep. Default behaviour is to block that stuff, if your ISP is any good. Depending on how cheap the cheaper ISP was, you might or might not be able to get your connection set to allow it, and your costs might get a lot higher. (If BGP was an option, you could often just announce the routes; if it was a consumer cable modem, or probably even a business cable modem, you can't fix it, but you can still play load-balancing games with your DNS, or do redirects from your webserver so that http://www.example.com/stuff redirects to http://www-cablemodem.example...., etc.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
That trick never works; basically nobody permits it.
There are legitimate reasons for you to have a source IP address that's different from your primary one, e.g. you have two internet connections and you're load-balancing across them, or you're a business with a small reliable connection and a big cheap cable modem, or you've got a satellite connection and a terrestrial one, etc. But usually if you're doing that, it's because you're a business, and you can either arrange with your ISP to permit it, or run BGP to announce the routes to your ISP so that the uRPF will accept them, or some other option which often costs money.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
For 1
Iptables tar and feather to glue the bots ipstack
a ton of work, but it can be done
Most of those actually successful DDos attacks being carried lately are most likely using the so called NTP/DNS amplification attack, where the botnets use the power of the NTP/DNS servers to carry the actual attack by flooding those servers with small requests that return an immense amount of data while faking the ip address of the victim.
If you put a limit of how many of those specific requests can be done by an specific IP per second, you stop the whole thing on its tracks, and those people will have to go back into creating absolutely monstrously huge botnets to put any dent on a modern server.
Read your own link, he was arrested for first degree murder due to his involvement with planning and providing material aid to commit a crime that turned into a murder. He thought that because he didn't directly do the killing that he somehow wasn't guilty of it when he helped plan and execute crime, he was a dumbass.
This is nothing like the scenarios where someone has their property stolen and then used in a crime which is what a hacked / compromised computer is like.
(I am never quite sure how to post on Slashdot to assure my post is part of the thread associated with a Slashdot headline. I am trying the "Post" action).
My friend Don Cohen designed PEIP, an extenstion to IP. PEIP stands for Path Enhanced Internet Protocol.
A somewhat dated but accurate explanation and demo can be seen here:
http://www.cs3-inc.com/MANAnet...
(Watch the Flash Demo at the bottom of the page that illustrates several scenarios.).
Last I checked, CS3, where Don works, was not successful in convincing Cisco to pay attention to this solution.
The basic idea is to modify routers to use PEIP, enabling routers to provide "Fair Service". In other words, since it is impossible to determine which packets are part of DDOS attacks, the PEIP solution instead assures that all paths routing to a target victim receive equal bandwidth. In this way, an attacker (based on the path, not on the source IP) will only receive a fraction of the bandwidth to the target.
Dennis Allard
http://oceanpark.com/
http://wiki.debian.org/iptables
Casteism
Charge a one billionth unit of currency per outgoing packet. That should stop both torrent seeding and DDoS :) Well, at least botnets will have to get a lot wider and thinner.
Make ISPs want to put their customer's behind NATed firewalls in order to avoid this tax. This would cut down on the botnet infection rate and make these infections more visible to the ISPs themselves. Grandma's computer does not need and really should not have an internet routable address. The 'service' ISPs are providing their customers has not evolved since the 1990's but the nature of the internet has drastically changed.
For this and many other reasons, our devices need to inform us about what they're doing. Sure, pick your favorite brain-dead scheme for presenting a confusing morass of activity information to grandmothers as affirmation that such an idea would never pan out, but until we understand what the heck our devices are doing, this will never end. We're trusting devices when the devices themselves are inherently untrustworthy. They do what they're told, and most users don't even know what they're telling their devices to do. They can't know.
My friend Don Cohen designed PEIP, an extenstion to IP. PEIP stands for Path Enhanced Internet Protocol.
A somewhat dated but accurate explanation and demo can be seen here:
http://www.cs3-inc.com/MANAnet... [cs3-inc.com]
(Watch the Flash Demo at the bottom of the page that illustrates several scenarios.).
Last I checked, CS3, where Don works, was not successful in convincing Cisco to pay attention to this solution.
The basic idea is to modify routers to use PEIP, enabling routers to provide "Fair Service". In other words, since it is impossible to determine which packets are part of DDOS attacks, the PEIP solution instead assures that all paths routing to a target victim receive equal bandwidth. In this way, an attacker (based on the path, not on the source IP) will only receive a fraction of the bandwidth to the target.
Dennis Allard
http://oceanpark.com/ [oceanpark.com]