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)
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.
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.
this wouldn't stop infecting computers acting as botnets, but there's no single solution to fix it all, so egress filtering like this would help massively.
So - how do we persuade ISPs to stop allowing spoofed packets leaving their networks? What can we do to either hurt their marketing or force them to implement this?
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.
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.
Most network providers (about 80% of the Internet) do this on the other end, doing ingress filtering. There should be little functional difference between an ISP refusing to let spoofed packets leave their network, versus an ISP refusing to let spoofed packets enter it, if the two ISPs in question were directly connected.
So you think we could change human nature in a couple decades? I don't think we could do it in centuries. Kids love to draw on the wall, even when you tell them not to and they grow out of that phase if given the right environment, but I defy you to find any city of more than a 500 people which has never had any graffiti. It is a basic human impulse to try to make an impact on your surroundings and so long as there is an internet, someone will want to make an impact on it in ways that are not that different from a three year old.
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.
My understanding is that most major ISPs in the U.S. (or at least those with sane network engineers) already do this by dropping spoofed packets on the ingress side of their routers for sources they don't own (https://tools.ietf.org/html/bcp38). Hurting market share or forcing implementation is easy domestically, but with the global nature of the Internet and entire nations not implementing this, perhaps for political reasons, it becomes a much more difficult proposition.
Also, any ISP that charges people for bandwidth has an internal conflict of interest when asked to resolve this problem. They want to ride the line of charging you as much as possible, while not coming up with a solution that completely prevents the attacks that use bandwidth the customer is paying for.
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.
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...
When SDN matures fully then carriers will get on board. Then they'll be in a better position to mitigate these attacks through better/faster detection and analysis. This will come as a premium service with a price mark-up obviously.
Any solution would violate net neutrality.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
It's not a matter of cost, it's a matter of coming up with a design that would actually eliminate DDOS. I'm fairly convinced it can't be done. Fundamentally, a DDOS looks like a bunch of legitimate service requests made to a server whose purpose is to answer the requests. Essentially, a DDOS is the death by a thousand cuts. No particular source of the DDOS packets individually looks like a problem.
Consider a web server. How can you decide that this page request is from a legitimate user viewing the page but that one was generated by a bot and won't actually be read?
I WISH it was a technically solvable problem because those get solved sooner or later. Alas, this problem requires a social solution. Find the botnets, tear them down, then track down the people who run them and prosecute them.
Wrong target. Hunt down and kill the people that run the botnets. Publicly. Grotesquely.
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.
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"
Honestly, I agree. 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.
Whether or not it's any part of the aggravating party's intent, DDoS's, on a broad scale, almost certainly do KILL PEOPLE.
Were there no middle-aged Xbox Live or PSN users, with already too-high unmanaged blood pressure that experienced a massive (fatal) stroke at the frustrations they experienced with their technology products over the Christmas holidays?
Of course, it IS those peoples' faults as well, in not managing their blood pressure. I'm betting, however, that more than once in DDoS history, has an impacted party's life been cut short (in the straw that broke the camel's back sense) by frustrations arising from the DDoS.
Still, how many depressed kids whose Twitter contacts are their social safety-net had a bad day and in the midst of a Twitter outage committed a suicide that might have been avoided if the service had worked? We can't really know.
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.
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.
Wrong answer. What can the carrier do to block the sending of DDoS, not keep up customers being DDoS'd? Customers participating in DDoS attacks should be disconnected. Anything else is negligence by the carriers. But ISPs make more money leaving them on and defending from attacks, rather than stopping the attacks. It's criminal, and should be treated as such.
Learn to love Alaska
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.
Your post should be bookmarked by all of Slashdot to use as an actual example of a slippery slope.
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.
Customers participating in DDoS attacks should be disconnected.
Agreed, DDoSers who get too caught up in their work make mistakes. A dispassionate sense of disengagement from the situation helps to maintain control.
Unsecured http probably can't be saved because of it's design. But persistent connections should be easier to protect because the legitimate connections are distinguishable.
Presumably xbox and playstation use some kind of persistent connection. If not, they should.
Wrong answer. What can the carrier do to block the sending of DDoS, not keep up customers being DDoS'd? Customers participating in DDoS attacks should be disconnected. Anything else is negligence by the carriers. But ISPs make more money leaving them on and defending from attacks, rather than stopping the attacks. It's criminal, and should be treated as such.
If only it were as easy. DDoS attacks come from botnets. Botnets don't come from somewhere, they come from *everywhere*. If they played the "cut off the offenders" game they would need one hell of a huge IP-level blacklist, or they would cut off literally every link they had since compromised hosts are everywhere. If you are going to say "just force the end ISP to disconnect them" then again it's amazingly complicated since an ISP in Georgia (the country) isn't going to listen to some twat in the UK or US complain about a certain group of hosts that are participating in a DDoS, just like ISPs in those countries wouldn't listen to some ahole in Georgia complain about a DDoS host since he might just want to take it offline for political reasons and there isn't nearly enough international cooperation to keep up good relationships between all the concerned parties. Moving up a tier, there is too much good traffic coming from any given ISP to simply write it off as blocking the whole thing.
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
Rather than all-or-nothing, how about making or keeping a list of "suspect" clients. Let's call this the "grey list". When there is a flood of activity, resources are given first to clients not on the grey list. Grey list clients either have to wait longer, or are rejected with a "Server Overburdened" message, depending on the load.
This way ISP's don't risk rejecting legit clients under normal circumstances.
Table-ized A.I.
If you want to find the source, you need to find the profit center. This stuff isn't being done for free. A real investigation will lead to a place that most people will find most unappealing.
And jail? Please! This fetish with imprisonment needs to stop.
And we don't want ISPs filtering anything. It only provides pretext for filtering everything. They are supposed to be a dumb pipe. Let the end points do the filtering.
“He’s not deformed, he’s just drunk!”
That's great! Why don't you go convince every single carrier in the world to do this!
Meanwhile we will use real world solutions. Let us know when you are done, then we can stop using those services.
>. 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?
ISPs can cut off offenders trivially. Upstream providers can cut off offending ISPs trivially.
Learn to love Alaska
I've already convinced them all to use BGP. ISPs world-wide use standards, and adopt new ones all the time. It's not hard. You just don't want to stop DDoS. Why?
Learn to love Alaska
Great! Then it shouldn't be no problem for you. If you read my post you would know I support you and applaud your effort!
Why don't you switch them all over to IPv6 while you're at it?
And they are not going to. A sizable percentage of an ISPs customers have some kind of bot on it. Since almost everyone these days has a NAT router if one computer out of ten has a bot on it, the entire network goes down. Customers get pissed. Bills don't get paid. Long arguments with tech support over who's problem it is. Some of these bots are wireless clients that move around too.
Or, they can do what they are doing now and neglect the problem. My money is on the continued neglect except in the worst of cases.
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.
It doesn't much matter if your odds of connecting in the first place are thousands to one against.
If you do something like penalizing packets with the syn flag set, the ddos guys will just flood with RST packets or data packets that look like they're part of a stream, or switch to UDP.
Remember, by the time the packets get to a router you control to tailor the rules, it's too late. Your uplink is flooded. So, any rules that might be applied have to work well for everyone out there.
Yeah the tech is there - an ASIC designed for identifying and dropping suspect traffic (or already marked traffic) on carrier networks is the obvious part. Whats needed is a protocol that can be implemented at layer 3/4 to allow global distribution networks to notify each other and perform wire-speed inspections/drops. Heck, an existing protocol like QoS marking at layer 2 or 3 could be partially leveraged to avoid changes to (already) standardized headers but im sure im about to be told why thats impossible or unsuitable. Someone makes this stuff lavaboy is talking about (or companies like Prolexic just clean your crap for you in real time) but all charge through the roof for it and THATS why we dont have the solution. Freakin a.
will work for dragon quest localization
...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?
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.
What it sounds like you're saying is that ISP's could cut off individual customers who are sending DDoS traffic thereby killing the DDoS attack. If (I say that lightly) they are already monitoring our upstream traffic why couldn't they do that?
The answer lies in your earlier post, because they can make money selling mitigation to the attackee. When a place I worked was being attacked AT&T (their ISP) was completely disinterested in helping at all. It was even more sickening than them asking for money to help.
I refuse to sign
I meant to add that one reason the ISP might not want to cut off DDoS senders is that they don't want to annoy their customers. Though you would think that they could call the customer at the same time alerting them to an infection, notifying that their internet will be down for 15 minutes (or whatever). Of course it's difficult for joe customer to try to remove the infection without an internet connection. Though it's possible that they're not even home at the time and wouldn't notice or care if it bumped off for a while.
I refuse to sign
yup, attacking someone else is illegal hacking. The ISP should be required by law to prevent them from being on the Internet until clean.
What I can't understand is all the people defending the people launching DDoS attacks from their PC. Knowingly or negligently doesn't matter to me.
Learn to love Alaska
But how can the target ISP tell if the packets are valid? The easiest way is simply not to allow any packet to leave your network that doesn't originate with one of that ISPs IP addresses.
Surely its easier if the source ISP does this, as they know which IPs were allocated to them.
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.
Maybe I should be shamed for replying to myself, but I thought of another issue.
If I'm running some software to stress test a web server (such as jmeter) am I going to auto-blocked by the software? And if so, am I going to have a means to dispute the blockage?
Also, in reference to "when it does block" it could just block you leaving their network. That way they could point you toward antivirus software or other cleaning utilities hosted on their network.
I refuse to sign
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.
But persistent connections should be easier to protect because the legitimate connections are distinguishable.
How can you distinguish one thing from another thing if you can't look at either of the things?
The only way to prevent "10000 packets in a second were sent, but my connection can only transfer 1000 packets in a second" (aka a DoS attack) is to not have those extra 9000 packets sent in that particular second.
If they aren't sent, you can't see them (they aren't there to see!), so you have exactly Zero variables to use for decision making upon.
If they are sent so you can make a choice based on some characteristic of the packet, then the packet must be sent, and you have failed in your goal of not having the packet sent.
Worse in a typical DDoS, any characteristic of 1 packet will not match the same characteristic of the other 8999 packets.
So not only is your choice of "do I want to receive this packet" too late after it has already been sent and received, but any choice you might decide to make will also not apply towards helping the problem in the future.
A single customer calling in costs an ISP about $1 per minute on average. If another network calls in and provides a list of 10,000 customers to disconnect, that can quickly turn into $100k cost to the ISP. No ISP will agree to that. So do you make the other network foot the bill? Well, that bill will probably cost more than just getting DDOS protection.
There is no easy way to disconnect users. Just wait until ISPs get fed up with getting sent large lists of IP addresses and instead of manually entering the data in, they stream line the process to be entirely automated, and some script kiddies figure out how to abuse this system.
Upstream providers can cut off offending ISPs trivially.
Not if it causes a breach of contract. Then the upstream can get sued for all losses.
That list would be too large for most system. Every time a new connection is attempted, your system would need to check that list. To give you an idea what is being talked about, DDOS can be millions of IP addresses and firewall rules are in the thousands for large lists. The list would increase processing overhead enough to create a new bottleneck.
The type of attack you're talking about is an asymmetric attack where the attacker can cause high load with a relatively few connections, which is why you "deprioritize" or reject "suspect" clients. But there are DDOS attacks that a symmetric attacks. Your best case is you will use as much resources as the attacker, primarily bandwidth, but the attack has a botnet of millions of computers. You just can't compete.
Most contracts will allow termination of service for malicious activity.
Learn to love Alaska
Arrest the CEO of the edge ISP for hacking, aiding hacking, conspiracy to commit hacking, and see if they decide to cut off criminal users.
Learn to love Alaska
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
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
They try to close the connection with RST the server says wait I have data to send you.
There is no "wait" for RST. RST packets are immediate, no questions asked, no stopping it. If the client sends an RST, it will send the packet, then kill the state without waiting.
Most bots doing SYN floods don't use the OS, but instead use raw sockets to quickly generate lots of SYNs, which does not consume any state overhead in the OS network stack. When doing RAW sockets, it's up to the caller to handle all state.
ISPs can cut off offenders trivially. Upstream providers can cut off offending ISPs trivially.
The problem here is that compromised systems are pretty much everywhere. I take care of a number of SOHO networks and have had to clean up mess after mess over the years. Drive-by exploits, phishing, worms, etc. are all vectors of infiltrating a network. DDoS and spam are widespread. It's trivial to cut off service, yes, but if an ISP and upstream providers to cut off all offending networks from access, the internet would pretty much go silent.
Short answer: It ain't gonna happen. Local administrators have the task of keeping their own backyard clean. Beyond that, good luck educating the average home user not to click on that supposed love letter from an admirer, not install that free software from some random web site they found on Google, not give out their password to tech support contacting them via e-mail, etc., etc.
It won't get much love, but... There's always Chromebooks.
An ASIC that tracks state at line rate? What are you smoking, I want some. You do realize that state exhaustion is a form of DOS, yes? There is no way an ASIC could handle the number of states required. We're already having issues with ASIC trying to handle a few hundred thousand routes, yet alone millions or billions of states.
Or just figure out their mailing address and sign them up for some Harriet Carter catalogs
Don't blame me, I voted for Kodos
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
Because crime is common, it would be cheaper and easier to abolish the police and stop trying to fix things.
Nope, that's fucked up logic I'll never buy into.
Learn to love Alaska
A compromised system that is operating without the knowledge of its owner does not constitute malicious activity. Malicious activity, by its very definition, is intentional.
So the Botnet owner isn't doing anything malicious when they perform a DDoS? Again, I think your logic is contrived and quite stupid, trying to defend negligent users who are financing attacks.
I said that the DDoS is malicious activity, and the connection is linked to that, and thus can be shut down. You are disagreeing. That makes you dumb or a liar. Which is it?
It amazes me how many people defend compromised computers and those performing DDoSs.
Learn to love Alaska
Because crime is common, it would be cheaper and easier to abolish the police and stop trying to fix things.
Nope, that's fucked up logic I'll never buy into.
That's not a logical rejoinder to my comment. I did not state that nobody should try to fix things, I merely stated that cutting off traffic is unlikely to happen for a number of reasons. The cutting off traffic only masks the symptoms, it does not deal with the cause of the DDoS. A holistic approach is required, not an allopathic one, IMO.
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
A compromised system that is operating without the knowledge of its owner does not constitute malicious activity. Malicious activity, by its very definition, is intentional.
So the Botnet owner isn't doing anything malicious when they perform a DDoS? Again, I think your logic is contrived and quite stupid, trying to defend negligent users who are financing attacks.
I said that the DDoS is malicious activity, and the connection is linked to that, and thus can be shut down. You are disagreeing. That makes you dumb or a liar. Which is it?
It amazes me how many people defend compromised computers and those performing DDoSs.
It occurs to me that reading comprehension may not be your strong suit. I have yet to see a single comment here that defends compromised computers or DDoS. Please, try not to pretend to be so dense. The issue of malicious intent has nothing whatsoever to do with the botnet operator and everything to do with the owner of the compromised computer(s)/network. You seem to be confusing the legality and morality of the perp with that of an ignorant owner/operator. Yes, the DDoS is malicious activity. Nobody that I have seen is arguing that point. Being on the wrong end of a DDoS is damaging and disruptive. That said, there ARE ramifications of simply turning off the tap that are not so simply dealt with as you seem to wish were the case. Were it so easy and legally simple, it already would not be an issue, IMO.
I think that's exactly why it's necessary. Most ISPs take very little notice of an obviously infected customer's machine, unless of course it's trying to pour its spam through their SMTP server. Then they immediately get their panties in a twist and pull your plug until you clean up your machine.
The difference here of course being who is the victim. You or me? Not gonna bother. US? Red Alert Ban Hammer Time!
So, your upstream pulling (or threatening to pull) your plug is precisely what's needed to motivate those ISPs. Some are lazy. Most are just too cheap to invest in fixing the problem and would rather bank the dollars than spend them to fix "someone else's problem". Make it their problem. Light a fire under their seat and watch them redirect a processes they already have in place, to fix the problem.
I work for the Department of Redundancy Department.
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
I think that's exactly why it's necessary. Most ISPs take very little notice of an obviously infected customer's machine, unless of course it's trying to pour its spam through their SMTP server. Then they immediately get their panties in a twist and pull your plug until you clean up your machine.
The difference here of course being who is the victim. You or me? Not gonna bother. US? Red Alert Ban Hammer Time!
So, your upstream pulling (or threatening to pull) your plug is precisely what's needed to motivate those ISPs. Some are lazy. Most are just too cheap to invest in fixing the problem and would rather bank the dollars than spend them to fix "someone else's problem". Make it their problem. Light a fire under their seat and watch them redirect a processes they already have in place, to fix the problem.
I think we're all in agreement that something needs to be done, but the ethics of disrupting a business's capacity for staying in business is shaky ground. In all of this, I'm certainly not defending the problem, merely discussing the complications associated with cleaning up the problem. In my case, I'm very proactive about making sure the SOHO networks and servers (including multi-tenant web servers) stay clean and patched such that they don't create problems. It's a never-ending story, too.
A typical problem scenario for a hosting provider, for example, is somebody's CMS gets hacked for whatever reason and the server becomes a malware distributor or starts sending out truckloads of spam. It's mindlessly trivial to cut off that customer's account until such time as they get their house in order. Do that in certain jurisdictions, however, and you risk a law suit in case the customer can prove that their capacity to operate their business was damaged by YOUR actions.
It just IS NOT as simple as you and AK Mark would like to see it. One doesn't just walk into Mordor . Oops. Wrong metaphor. :)
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
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
There would need to be a court order, not a civil complaint. So get a court order, per IP address, and request that customer be disconnected. In a few months time, you may have a few tens of those bot net nodes knocked offline.
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
It occurs to me that reading comprehension may not be your strong suit. I have yet to see a single comment here that defends compromised computers or DDoS.
You said that the connection participating in a DDoS isn't engaged in a malicious activity. I count that as defense of the compromised computers.The issue of malicious intent has nothing whatsoever to do with the botnet operator and everything to do with the owner of the compromised computer(s)/network.
Ah, it's you who can't read. I said "malicious activity" not "malicious intent" The computer is doing something malicious, even if the user didn't explicitly perform the act.
That said, there ARE ramifications of simply turning off the tap that are not so simply dealt with as you seem to wish were the case. Were it so easy and legally simple, it already would not be an issue, IMO.
It's already a violation of ToS, so shut them off. If that's a problem, change a law to make it no longer a problem.
Learn to love Alaska
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
No, a court order isn't necessary for the ISP to cut off someone, just for someone to force them to do it.
If you don't know the difference, you are too dumb to discuss this with. If you do know the difference, then you are just trolling me.
Learn to love Alaska
This is getting to become a circular argument, and I'm in no mood to argue. I cannot be more clear: One cannot simply 'pull the plug' on a network that provides service without opening up a complex can of legal worms. There's absolutely _zero_ doubt that DDoS activity is malicious by nature and intent by the botnet operator. There's absolutely _zero_ doubt that pulling the plug would help mitigate the damage to systems on the receiving end of attacks from such compromised systems/network. The fundamental problem, however, is that one does not merrily obstruct a business's capacity to DO business without incurring legal ramifications (dependent upon the jurisdiction in which the service is being hosted/operated).
It is what it is, Mark. It's a simple problem with a veritable rat's nest of legal implications to solve.
Happy New Year to you, sire. :)
canada is a weird place. in US if your business relies on the internet to function then you better be really good at doing internets, otherwise you'll be SOL when your shizz goes down. nobody holds your hand.
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
Yep. Canada has some weird rules. For example, if you have servers in a rack and the feds want to do a search and seizure a la US style, not gonna happen. If the servers are essential for the running of your business, the most the feds can do is to copy all the relevant data. They can't actually seize the servers lest it causes your business damage.
It's actually a pretty good law in that it respects the ideal of innocent until proven guilty beyond reasonable doubt. In other countries, they can just take your crap and if you go out of business because of it - even if you're totally innocent - well, that's just tough luck, innit?
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
So you don't mind pulling the plug on a residential connection, but pulling one on a business connection is the line? The business should have more care in their networks than an average user. So they should be pulled much less than grandma. So I wouldn't think it that huge of an issue. Most are residential connections, aren't they?
Learn to love Alaska
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
So you don't mind pulling the plug on a residential connection, but pulling one on a business connection is the line? The business should have more care in their networks than an average user. So they should be pulled much less than grandma. So I wouldn't think it that huge of an issue. Most are residential connections, aren't they?
Oh, I have just as much of an issue with pulling the plug on a residential connection because of the possibility of negatively impacting business. For example, I do the vast majority of my work from home on a non-commercial connection. Were my ISP to simply pull the plug on my connection because one of the systems began, say, sending out thousands of spam per hour, it would create a huge problem for me. (Finding/cleaning the system not itself being The Problem.)
For any long-term success, we need to find ways to take down the botnets and patch the compromised systems. ISPs disconnecting problem systems/networks does nothing to deal with the malware that creates the zombies for the botnets, nor does it take out the command and control centre that inevitably tells the zombies to attack a particular target. To me, that's the more pressing issue. As long as the botnet lives, more zombies will be recruited.
P.S. - I noticed that I spelled your name 'Mark' before. Apologies for that!
Nope. LOL
The common carrier laws don't cover Internet now. And even under them, utilities have the right to disconnect people acting badly. You obviously don't understand how common carriers or laws work.
Learn to love Alaska
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.
Not to sound like a shill, but this is exactly that: http://www.arbornetworks.com/products/arbor-cloud . Again, most ISPs worth their salt already implement PeakFlow in their backbone IP networks to catch and control large scale DDoS events, but at multi-gigabit levels - setting the threshold just low enough to ensure that DDoS attacks don't wipe-out their backbones, a level that is much higher than any single customer link bandwidth. Today, they (we) are beginning to offer these services (based on BGP, threat intelligence shared between ISPs and Security Consultancies, and "live" feedback from CPE-Probes like Pravail at customer sites) and they do work for the most part. The only downside (other than pricing - which is kinda steep) is the fact that it is a defensive mitigation approach - you BGP-blackhole the bad traffic in the customer-side ISP backbone, not the source. It's not going to eliminate the ever-growing and extremely long list of asshats (including sovereign state actor-asshats) that initiate these kinds of attacks, but it can and does, currently, mitigate the vast majority of them. So, yay-ish.
Steve -- If you have to call it a system, you don't know what it is.
Imagine... a large car rental place in your city rents out cars on the cheap. They're all identical, impossible to tell apart visually. They have very lax security on them, a basic door lock that's easily broken into without damage, no car alarm.
A criminal gang in the city has started targeting these cars, they're being stolen frequently, used as getaway cars for store robberies and even an occasional bank heist. Security foortage is worthless because all the cars look alike. The thieves apparently have realized if they just dump the cars off where they stole them after they're done without really damaging them, nobody cares. Not the rental place, not the customers. The criminals are impossible to identify or prossicute.
The mayer however is getting pissed off that the rental company is refusing to take any action. The rental co simply does not care, because it's not hurting them or upsetting their customers. Why should they spend money to fix someone else's problem?
What does the mayer do about it? What can he do about it?
This is the botnet problem. So, approach it from that perspective.
The rental co already has a few policies in place. They have monitoring software in the car that is used exclusively to watch for road-rage or dangerous driving. If a customer is driving recklessly and risks damaging the car, they may get a warning from the rental co, or even have their rental remotely disabled for a few days. (copyright DMCA letter anyone?)
So.... since they already have this monitoring system in place, and should already be able to tell when a car is stolen and being used in a robbery.... the mayer forces the rental company to use this information to help curb the problem of their cars being used for public harm.
This is how it would work in any other arena. So why does no one take action against the botnets? Does the rental company's right to run their business like they want to outweigh the serious problem they are facillitating? Of course not.
I work for the Department of Redundancy Department.
The solution will eventually be User Usage Visualization. Meaningful action cannot be taken against a ignorant user's system unless a result of user negligence. If feed back can be provided that makes the user overtly aware of their participation in a bot-net, then I think the problem will resolve it's self. Users would implement bot removal, or be considered negligent.
So, if someone is running an Internet hunting business, and their gun is hacked, and it's shooting into a crowd of people, the police should try to figure out who is controlling the gun without stopping the gun from firing into a crowd.
I see a crime in progress, and an easy way to stop that crime. You are more worried about the rights of the business owner to make a profit than the crowd's right to not be harmed by a negligent business owner.
Learn to love Alaska
(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/
Nah. I'm just cognizant that cutting the pipe can put businesses out of existence is all. I don't think it helps anybody to put a business out of business. Cutting the pipe should be, IMO, the last resort to the business not getting its ducks in a row.
Obviously, the owner of compromised systems is responsible for those systems. Period, full stop. In my line of work, I'm often the hapless slouch who has to find the root kits and whatnot, cleanse the system, determine (if possible) the vector of entry, etc. Usually, the system was owned by some undetermined means and all I can do is just cleanse and lock down as much as possible. Clients, however, being the meat sacks they are, always manage to encounter PEBKAC events.
I don't think we're actually all that far apart in our line of thinking, Marc. I just am reluctant to pull the pin on their network connection until such time as the company has proven itself either unable or unwilling to address its issues. This approach is fair, I think, when dealing with individual residential and corporate connections. When you threaten upstream disconnection at the ISP level to downstream ISPs, then the collateral damage is too great for such shenanigans. Putting hundreds of companies out of business simply because they chose an ISP who allows botnet traffic to pass its borders would penalize those who are not a part of the problem. That, IMO, is unethical.
http://wiki.debian.org/iptables
Casteism
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.
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]
Change to an ISP that's attack friendly. Then when they have enough of a botnet on their network, the upstream carriers cut them off. Problem solved.
Grandma will get a letter from her ISP. She follows the instructions, or she gets disconnected. It's that simple.
Learn to love Alaska