Slashdot Mirror
Stopping Distributed Denial Of Service
Anonymous Coward writes: "Fernando Schapachnik has updated his proposal for defeating Distributed Denial of Service Attacks based on changing network routes.
His paper describes a technique that can be used to defeat the recent DDOS attacks in real time. The solution presented here is based on routing and it requires a certain amount of extra network infrastructure.
"
Not to sound rude, but both of you are ignorant... but at leasty you have a better grasp of reality ;-)
My understanding of routers is that for best performance you want the 'best' routes. What consitutes best is determined by the algorithm, but generally speaking it's the route with the lowest latency (OSPF, for example, uses this metric). So by changing the routes you'd be making things less optimal. The other problem is convergence, or how quickly routers adapt the new routes. Routers have special protocols to make sure that when a route goes down (or a new one comes up) that change propagates through the router 'network' and each router updates it's router table to keep track of which packets go where. Any change in routing on a network requires a finite period of time to propagate through the router network. Changing routes too often can severely impact performance - router loops come to mind as one possible Bad Thing. So, short of redesigning all existing router protocols or creating a new one which very rapidly updates all routers on a large network, I don't see changing routes as a solution - the cure is worse than the disease. Lastly, even assuming all these issues were worked out, TCP/IP is designed to be fault tolerant - if your packet gets eaten it will be regenerated. If the routes change, the packet will be re-routed to get to it's destination. In short, if you DDoS over a TCP/IP connection.. or generate packets which require the remote end to maintain state (which TCP needs!), you're going to kill the remote host regardless of how the packet got there.
Ok, lets comment on this:
First of all, best performance IS NOT EQUAL to fastest. It means that it does whatever it is supposed to do betst, which can be fastest, but in my defenition it always means 'in the most correct manner possible with as little as possible overhead', AND ONLY IN THAT ORDER!!. ANyway, before you talk about performance,m define what you mean with it.
Asssuming better performance means faster here, latency is only one measure for this, and a measure that is rather unreliable for that matter. If you want to look at this kind of performance you always use bandwidth + latency. One without the other makes really no sense whatsoever for measuring performance. I can create a very low latency on a router with simply ensuring that my measurement is very small (uses very little bandwidth) and that there is no other trafic on the router.
Anyway, besides those performance issues, you make another mistake:
First of all, most DDOS attacks count on a few things:
- Fill up a servers state table with half open requests for tcp connections.
- Flood the servers network connection with more trafic then it can handle.
- Use any cpu, memory and other resources that the server has.
In order to fill the state table, connections are usually created, and never used. As a result you can't count on tcp connections to carry on your ddos, but thats not really important, the dns is going to tell you where your target moved, all you have to do is watch the dnses closely, and you can ddos without being hindered by this plan at all. Simply put, proposed plan does not work because it is very easy to circumvent, it takes less efford to circumvent it then it takes to implement this proposal. The best solution at this time is to impliment packet filtering on the router. This has it's own set of problems, and is hardly a pancea. And how can you derive whether a DDoS is really occurring? The slashdot effect comes to mind as a good example. -o Question authority! Yeah, says who? o-
These recent DOS attacks have been lanuched from third party systems that were subverted. Most of these systems suffered from poor system management and disregard for basic security.
This isn't rocket science! Basic well known measures would likely keep out most of these script kiddies. The problem is the owners and operators of thee subverted systems aren't being held even partially responsible for the DOS attack launched from their systems right under their noise.
It is well known in international law that a sovereign nation state is responsible not only for its own actions but it must try to prevent third parties from launching attacks on neighbouring states from its territory. Standing by and doing little or nothing to prevent these attacks is paramount to having participated in the aggression.
I think the same principle should be applies to systems connected to the internet. The owners of such systems must meet a certain level of due diligence in ensuring that its systems are not subverted and used to launch attacks on others. If it can be shown that they were negligent in maintaining a minimum competent level of security they should be held liable to some degree for the losses suffered by the attacked company or institution.
I am certainly not in favour of solutions that could possibly divert even more of our economy into the unproductive and parasitic hands of the legal profession but it wouldn't take too many well publicized examples to shake up the entire computer community and cause security to be taken a lot more seriously than it is today.
Technical solutions are appealing to the lazy. Why change the way thing are done when someone can just come up with a magic bullet to fix it. But these solutions are usually just a mirage that often cause more problems than they fix. We see that with low tar cigarettes, airbags, fat and sugar substitutes, and a endless list of other techno-whizzy but wrong-headed solutions to largely self-inflicted problems.
When are we gonna stop the Slashdot Effect?
Changing routes is actually a bad way of putting it. What the author is suggesting is really just changing the address of the server. When there's too much traffic to the server's IP address, you have it pick another one. But because it's in the same network (e.g. 10.0.0.0/16), the change doesn't need to propagate to the whole internet. The only routing change that needs to occur is that the ISP routes the old address to null. I'm not in network operations, so I don't know if ISPs would have objections to something like that. (You would want to make sure, for example, that you didn't create a DoS against the ISPs router by filling its routing table with entries of the traffic you are discarding.)
I'm not sure what you mean when you say "if you packet gets eaten it will be regenerated". Yes, TCP is fault-tolerant. But it doesn't make packets out of thin air! When a sending host doesn't receive an acknowledgement for the data it sent, the host resends the packet. Presumably, however, folks originating DoS attacks aren't going to bother with this. Even if they did, the packets they resend will be directed to the old IP address. But since traffic to that address is being discarded, it's not an issue. [1]
The separation of legitimate traffic from the attack traffic is done using the DNS. The idea is that if I'm trying to get to Yahoo, and the original address is disabled, then I'll just hit reload, check with DNS again, and get the new address. The assumption is that either the attacker only checks with DNS once (and hence his traffic is discarded), or that if he checks with DNS frequently, then you can see his many queries in the DNS logs. Given the hierarchical nature of DNS, I'm not sure I buy that.
[1] Depending on what it is that you're trying to protect. Although you've freed up resources on the server, you may be saturating your ISPs links, because the attack traffic has to make it to your ISP before it is discarded.
--
Packetstorm had a contest for papers regarding defense against DDOS attacks. These papers covered the territory fairly well, I think.
I don't think the technique will work very well. It did get me thinking about what an attacker might try next, once (or if) this form of defence became common.
There's a long-standing problem with the way the DNS service operates, which lends itself scarily well to a DDoS-style attack. The problem is that it should be possible (especially with a congested network) to masquerade as a site's DNS server and effectively own the DNS info (and change it to point to a compromised host) from that point on.
Worse, the attack can be continued up to site responsible for top level domain information.
The best defences seem to be, in order:
* protect yourself from IP spoofing by
configuring your firewall
* hold off on honouring changes to DNS info
(so you can check whether they're legit
"manually").
* and of course: keep installing those
security patches!
dec
Ah, but look at what I presented above. There is no need to spoof the originating IP when you are hitting it from thousands of nodes across the net (and you don't own any of them)! No one can shut down thousands of machines at the same time.
Robert Morris Jr. did it.
I tried giving him a call. About the third sentence in I hung up. Of course, the sentence "the police are on their way over" might have made that happen quicker...
Screwing with IP stuff is a serious case of locking the gate after the horse has bolted.
OK, if something like Trinoo or TFN is producing a DDOS, how can we tell the attacking boxen apart from the legitimate ones? If I'm a customer on the same subnet as a rooted client which may or may not report the same IP address through a firewall, I'm not coming back to your site if I get a message suggesting I am involved in a DDOS.
Most home users will need a new OS. Microsoft Research have a preliminary version of a IPv6 implementation available, but it's early days yet, and unlikely to end up in any consumer OS for a while.
Additionally, a translation layer such as this is not likely to help much as there will have to be legacy support, and this may well be exploitable.
Its pretty obvious that you don't understand what a DDoS attack is all about. A firewall can do NOTHING about it. A DDoS attacks makes your connection 100% busy (or your cpu, or you run out of memory...)
A firewall can't do ANYTHING to kill it.
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
"Rune Kristian Viken" - http://www.nwo.no - arca
Assuming that the attacker isn't too smart, the attacking host would be discovered - if he queries the DNS every two seconds. All they would need to do, would be to dig through the dns-server-log, to find out who queried the DNS server plenty of times. Then that host would be tracked down, and at least ONE of the servers that was used in the attack, could be blacklisted. They could simply throw in a 'deny' rule in their routers, and block DNS lookups from the host in question...
Also, your proposal says that the attackers script would re-query a dns server every few seconds -- something I don't think any of the current tools does. They do a one-time-lookup against DNS, and after that, attack the associated IP address(es).
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
"Rune Kristian Viken" - http://www.nwo.no - arca
Look at the two things DDoS attacks target: Bandwidth and the remote host(s). Network bandwidth is becoming a non-issue (in the 5-10 year range), so ignore that for now.
No. Its the bandwidth-DDOS'es that will continue to be the problem. As long as there is compromizeable hosts and the possibility of IP-spoffing, it will be "no problem" to exhaust a hosts bandwidth..
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
"Rune Kristian Viken" - http://www.nwo.no - arca
You're saying that like the 80's was a bad time.
:-)
A time without spam.
A good time.
Let's go back in time.
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
"Rune Kristian Viken" - http://www.nwo.no - arca
I do NOT think slow propagation of DNS will be the major problem. TTL = 0 would "solve" it, but then - a lot of people scream, you would have DoS attack against the DNS servers instead. Personally I think that argument is moot - as you can have several DNS servers, and preferably on different backbones.
The problem is that EVEN if you set TTL to 0, the attacker can discover this, and since we're talking about a distributed attack -- which may be updated to attack a new address pretty quickly -- we are still talking about a devastating attack. Perhaps one could reduce the attack from 100% to 30%, but it would still be devastating.
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
"Rune Kristian Viken" - http://www.nwo.no - arca
IP-spoofing is useless for cracking in a machine unless you do something very clever.
With IP spoofing you never get an answer back (unless you sit on a router where between the target and the spoofed host, but someone who "ownez" a router could have more fun then stupid DOS-attacks).
The usual tactic is going through a chain of already cracked hosts where you can manipulate the logs.
Spoofing could come into play when you send the command to the DDOS clients sitting on the cracked hosts. There you don't need an answer. But you could also simply use a cracked host.
Perhaps spoofing can help to make the DDOS more effectiv by ie. using non-existant hosts or hosts on the same subnet as the spoofed addresses. IE. you could ping www.example.com with large packets spoofed to come from www2.example.com, also hitting www2.example.com with the echo-replies.
The main use for spoofing in the DDOS-attacks lies in simulating "real-world traffic" and making it harder to track the sources. The victim is unable to stop your DDOS attack at its border routers if it cannot find a common characteristic in it. If you spoof with random ip-adresses you eliminate a big common denominator.
That doesn't fly, do the statistics. Either your 1000 boxes create a much higher traffic than the 100000 real people hitting in the same time span or you won't bring my server into trouble.
But if your 1000 do make enough "noise", it's not hard to seperate the worst offenders. Statistically on of your boxes generates 100 times the traffic of a human user. So if I just single out the 100 most "active" IP-adresses, chances are high that I'll never hit a real human.
And I wouldn't give a fuck if I hit altavista's crawler which just wanted to index my page in the moment of such a DDOS-attack (chances for such coincidence are pretty low).
Ok, I should have the infrastructure to be able to
(a)do the statistics and
(b)drop packets from certain IP-adresses.
If I don't have that, I'll not be able to stop the attack in 30 minutes. But if I have, I'll stop the attack easily.
As I said above, the spoofed source adresses are the real key to "success" of a DDOS-attack if the victim's infrastructure is mature.
Oh yeah, I forgot, the "Open" in open source and the "Free" in free software only apply to uber geeks. The internet is ours and we don't want companies and housewives and other "idiots" (to quote some other posts) on our precious internet. It's an exclusive club, after all, and if you can't boot into Linux and configure a firewall, you have no business using it.
Grow up. If your grown up, get a real job an get out of the university. If you have a real job and aren't in some ivory tower at a University, get a life.
The web and the internet are for everyone. Period. The net and the Web belong to know-one. Period. It was designed for the free flow of information - ANY INFORMATION (no-one care wherether you think its useful or not, they find it useful). And no amount of legislation, DDoS or whining by the "internet Amish" (BTW, This is you)is going to make it go back to 80's.
If you don't want to see java applets or pretty pictures, turn them off in your browser...or use Lynx.
Never by hatred has hatred been appeased, only by kindness - the Buddha
rely on having root access on bunches of machines also try to spoof the originating address of the command packets so that tracing the attack becomes a much more difficult propisition.
Well, there is a big difference between making a DDOS impossible and making it easier to catch the people behind it.
But even that aside, if you have root access on bunch of machines, it's trivial to route your command packets through some of these machines, arranging at the same time for them to forget that they ever saw anything resembling a command packet. If a couple of these machines are public servers, you do get very high security -- again, without using any spoofed packets.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
better ideas and info can be found here:
http://packetstorm.securify.com/distri buted/
http://packetstorm.securify.com/pap ers/contest/
Make sure to check out the papers by Mixter, RFP, and Simple Nomad.
-- ken williams
The net would be far better off without all these idiots and the companies that pander to them.
:).
Unfortunately, this elitest, arrogant attitude is the wrong thing for the internet. The internet and the web are about the freedom to exchange ideas. To say whatever you want and top have it possibly be heard. Just because it's grown beyond it's original intention doesn;t make it bad or that we should go back. I think the web has become something greater than the sum of it's parts.
Yes it is not 100% reliable, but realisticly it is really only just starting to "grow up". We have come to expect all services to be like the phone company in terms of qos, telephones have been around for 100 years, that is a bit of time to get most of the kinks out.
It makes me retch when I see people get that "the web should be all text" or that "The average user is too stupid and shouldn't use the web" idea. What we need is everyone to be able to get there, hell it helps pay my salary so I have a stake in this
My point is simple, the web and the internet are about information and access to it. YEs companies are commercializing it, but you can still get the info you want. Be discerning, be picky, but never assume that because somone doesn't meet your standards for some things that they should not be allowed to use it. That is close-minded and has no place online.
this space for rent
>But, alas,that would require more political muscle than I have!
;-)
We could always give our governor a call... he's got the muscle... though how much of it is political muscule is another story....
Maybe we could start the new Jesse V. site - whomping-ass-in-MN.com
"It's tough to be bilingual when you get hit in the head."
There is no need to spoof the originating IP when you are hitting it from thousands of nodes across the net (and you don't own any of them)!
But there still is a need for IP spoofing...
To crack the machines that are going to participate in a DDOS attack the cracker must spoof his IP address to avoid being cought. Stopping IP spoofing at the router level would stop crackers from getting into the machines that they need to use for a DDOS attack. This wouldn't stop them from cracking the machines but it would make it more difficult for all cracking in general.
If at first you don't succeed, skydiving is not for you.
You had me going for a while there. I actually thought you knew what you were talking about until you uttered this:
The *best* solution, IMO, would be to use that Millenium computer center in DC to monitor backbone traffic in realtime and give those people access to the network to shut down these things dynamically and in real time.
ummm...first, who's backbone are you suggesting the government monitor? (there is more than one backbone provider after all) And this wildly assumes that ALL of an ISPs traffic actually traverses their backbone. But let's play along anyway...
How about some quick math.
OC192 = 4,478,850 MB/hr
that's just ONE OC192! What? Don't believe in the magic of OC192 yet? ok.
OC48 = 1,119,600 MB/hr
Hey, that's better. Where are you going to put that data while you're analyzing it...and what are you going to analyze it with?
And what security professional in their right mind would ever choose to fight potential hacker activity by giving "someone else" the ability to make changes to their network???
IMHFO the *BEST* solution to the problem is to get system administrators to lock down their stupid boxes or get them off the net so they can't be used in one of these attacks, but then I probably don't understand the issues as well as you do.
RE: your routing questions... yes, routers create their routing tables based on some algorithm (which depends on which protocol you are using) to find the best route to a host. In this case, there would be only one route to get to the host (assuming that the customer is single-homed, which the guy who wrote this proposal did), so no best-match decision has to be made. There is just one route to the customer's network. You can, however, manually change the routing to improve the situation. In the case of a simple DOS attack (not DDoS), say from 123.123.123.1, you can just route packets with that source to null0 (just a bit-bucket address all routers have), so the router throws the packets away. In the case of a DDos attack, that won't work since there are several sources.. so you can route packets that have a protocol equal to ICMP and a dest. equal to the cst's server to null0.
The reason to do this is that access lists, packet filters, take up MUCH more router CPU than ip routes, so often if you put up an access list on a huge DoS attack, it will kill the router, and you'll be no better off.
//Phizzy
"Most European technology just isn't worth our stealing," -- Former CIA chief James Woolsey, referring to Echelon
Yeah.. I had originally thought to use hotname instead of IP, as that would be pretty easy, but wasn't sure if the kind of packet-spoofing they would have to use would be able to handle hostname resolution.
I think this guy is a prospective DDoser himself, because this 'solution' would make things worse rather than better.
//Phizzy
"Most European technology just isn't worth our stealing," -- Former CIA chief James Woolsey, referring to Echelon
Spoofing is pretty essential for the SYN-flood attack, which is really devastating when you haven't fixed your system to prevent it and you've got 1000 smurves pounding you with it.
But even non-forged machines can send web requests 100 times faster than regular users - not only is there no think time required, the client can request very big files, and drop them when they arrive rather than displaying them. 1000 smurfs on 56kbps dialups are 56Mbps, bigger than a T3. 1000 smurfs on cable modems can be much bigger - their upstream bandwidth is limited (but requests are small), and their downstream bandwidth is enormous, if they're not all on the same segment - figure 5-10Mbps per segment, though there'll be a good bit of clustering of smurfs (and if you can get away with spoofing anywhere, it's probably cable modems.) 1000 smurfs at 100 T3-connected universities can suck down 4.5Gbps, which is still large in today's Internet.
Transparent Caching at ISPs helps a lot. They're installing it anyway, just to manage their own bandwidths, but in the process it means that smurfs repeatedly requesting big static pages get turned into cache hits and stop bothering the target and the net. On the other hand, requests for big uncacheable dynamic pages are a problem - especially if the pages are real CPU-burners to calculate. So attacks on search engines can be moderately nasty, and slashdot-like conferencing system, and other things that try to be really dynamic.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
*casts don't map well to dynamic HTML, and don't map well to secure connections; you probably won't be able to fix those, so they're still a DDOS target.
Broadcasts go to everybody. You simply can't broadcast everything on the web to everybody - that would be reinventing Usenet, very badly, and wouldn't scale, would have broadcast storms, and would simply be blocked outright.
Multicasts go to people who ask to join a multicast group, which would need to be sparse-mode for the web to have a chance of scaling. (There are 2**28 (2**27?) valid Class D addresses, and more web pages than that, so you've also got a conservation problem...) This means that instead of sending a packet with a request to foo.bar.com for a web page, you send a send a request to foo.bar.com to find out what Class D address it broadcasts foo.bar.com/user42/bazz/page.html on, then send a
request to some collection of routers to join you as a receiver of that Class D multicast group, and then send a request to foo.bar.com saying you're ready now and could they please multicast that page (and if you're lucky, related pages), and later, somehow decide you're done with that address and deregister yourself from the multicast group. If you did this, you'd need to re-invent the mechanisms for caching servers (which are what keep the web alive today), though that's certainly a doable thing, and you'd have to worry about how to prevent DDOS attacks in your new complex environment.
For instance, suppose you own a smurf at BigCableModem.net, and everybody who requests home.netscape.com/index.html (the Net's most popular web page) gets put in group D.D.D.D. So you join the group, and start requesting that page as fast as you can. Either BigCableModem.net, or CachingCompany.Net, or worst-case Netscape.com, starts blasting away as fast as it can, and everybody still in that multicast group starts receiving copies of that page as fast as the routers can deliver them, until they deregister themselves from the group. Of course, you can receive them much faster than they can, because you've actually told your LAN card not to listen to those mcast addresses even though you've told the ISP's router you want them (or you've at least told your card to
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Lots of broadcast techniques are possible.
IRC is one choice. Writing to some free-web-server web page is another. Building a server that (ab)uses a free web page service or web-based email account is another. IP Multicast is fun if you can do it.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Breaking your DNS caching is bad enough, and makes retrieving your pages slower and less reliable when you're not under attack, but changing your address also doesn't work well. Too many things cache DNS. Some DNS servers have minimum lifetimes on the values in their caches, so they won't respond to your attempt to escape the attack, and many browsers cache DNS results, so anybody who was using your site at the time of the attack also loses.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The few DDOSes I've seen that rely on having root access on bunches of machines also try to spoof the originating address of the command packets so that tracing the attack becomes a much more difficult propisition. Now it's true that your average script kiddie doesn't take precautions outside what the script he downloaded provides, but the average script kiddie is also easily caught.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
B) What's to stop the haxx0rs from writing a small script that polls the dns servers every
5..10..30 seconds and changes all of the DDos boxen to the new IP instantly
Actually, they wouldn't have to do this. If you set the TTL for a DNS etry very low, then I am assuming
that the expire time on the record as a whole is very low, probably not more than a minute.
With this being true, if the attacker uses the hostname rather than IP, he won't have any problems.
His internal cahce will expire quickly, as well as whatever servers he is using for resolution.
This will result in a flooding of the target's DNS servers as well as a DDOS attack.
In looking this over, this "solution" will never work.
When the day o DDoS hit a while back, there were articles on this sort of DDoS attack. Essentially, this is NOT a DDoS. It's many very small, ineffective DOS attacks. In order to shut down a web site running on anything bigger than, say, a dialup connection, everyone who received the email would have to open it at the same time.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
And just what is a propperly launched DDoS? One in which a multitude of machines make legitimate requests of the server so as to overwhelm its capabilities and deny legitimate users access.
In other words, an induced slashdot effect.
Or, to look at it another way, how would you filter a clever DDoS without filtering slashdot users? The two can be made identical.
Please forgive my spelling. I'm an American so English is only my second language.
Yes, that's what I also noticed. There are long delays before DNS servers will update their entries. This scheme works fine on a small site where there aren't thousands of copies of DNS entries cached on major ISPs around the world. It fails for any large site where the ISPs will continue to provide DNS entries which use the old IP addresses...for hours or days.
That's why the proposal specifies the Time To Live value for the DNS entry as zero. This means that EVERY request for the domain name will cause the authoritative DNS server to be hit. That sounds a bit silly to me. If implemented as suggested, the DNS servers would fall down instead.
In this plan the TTL is the limiting factor for switching over the server address. If it were more than about five minutes, you'd just end up DoS-ing yourself. One or two minutes would be better in terms of latency, but since people often take more than a couple of minutes to actually read a web page before going on to the next one, there would still be a lot of load on the DNS servers.
As long as most of the "eyeballs" are querying their ISP's domain name servers, a TTL of a minute or two will reduce the DNS load... assuming the web page is really popular, like Yahoo or Ebay, or the ISP has a lot of subscribers, like AOL.
But really, as long as too many border routers allow packets with forged source addresses to get out, this will continue to be a problem. Not that even that would stop DoS attacks entirely, because one could always forge a valid "inside" address, or one could just run an automated DDoS with unforged packets that look like normal web traffic.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
We are currently expiriencing a distributed denial of service attack. Please authenticate yourself as a human by clicking on not this link, or this link either, but this link, and not this one.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
The solution presented here only works if the number of offending computers is small.
If for instance the DDOS attack was a virus which spread via email (thus affecting thousands of machines as "Happy '99" virus easily did), and it opened a connection to the target site like www.yahoo.com and simply hit it with large packets without the need for masking the originial IP; the plan presented here would fail.
How are you going to deny access to thousands of IPs or identify thousands of machines that are attacking your site, contact their owners and get them to disinfect their machines?? It is unfeasable. Thus, the target site would be easily screwed.
I assume that because of your elitist attitude about how the Internet should be that you've been around for a while. I've been on the internet for about six years and was using my C64 to connect to local BBS', so I'm not a newbie by a long shot.
I would bet that if the government made a proposal to censor "morally offensive material" (i.e. CDA) on the web you'd be all up in arms (as would I), yet here I see you saying that you believe that the Web should exactly the way you want it. You even go so far as to say that it is OK for idiots with basic computer skills to illegally crash corporate web sites.
"All these contribute to is bandwidth probelms, and we need to go back to when they weren't part of the web."
That's got to be one of the lamest excuses I've ever seen. Bandwidth problems? If you are referring to your own bandwidth, turn off your Java and Flash plug-in, simple as that. If you are referring to the internet in general you have a very weak point there also; the companies that run flash and java apps are going to purchase the amount of bandwidth they need. The internet would have less bandwidth (no real change in free bandwidth obviously) if the companies didn't have those things.
I think your real problem is that you got on the internet early and now you're upset that you are no longer one of the elite few. You just want the computer-illiterates off the net and you can only do this by removing the corporations.
My final point is this: IF YOU DON'T LIKE CORPORATE WEB SITES YOU DON'T NEED TO VISIT THEM!
IPv4, in general, has already been extended like crazy... why not just work towards developing and migrating to IPv6 instead?
the internet is whatever you want it to be. if you want it to be your shopping mall, then so be it. it can also be your newspaper, your television, your comic book, your bulletin board, or your game room for playing Quake II. the internet is a living, breathing thing.
.com. then perhaps certain regulation could be placed on those wishing to be a "dot com." i'm getting off-topic here,,
agreed. the problem is that with the overpowering interest of big business comes government intervention. it's no secret that the corporate world turns the dials of the US legislation. in effect, i am afraid that those who wish the net to be their shopping mall are keeping it from being a living, breathing thing.
DDOS attacks certainly aren't the answer. it'd be nice to have better top-level domain naming, instead of everyone being
<3x, kevin
For the remote hosts, we need protocols that do not allocate resources unless they are absolutely necessary. Look at upcoming protocols like SCTP. The protocol mandates that the initial connection sequence be stateless on the server side. So at levels below the application, DDoS attacks become much, much harder. This is essentially the SYN cookie hack, but made official.
So what about the application level? Well, applications need written to allocate state only when absolutely necessary. This doesn't necessarily imply pushing all state to the client side, however. Mainframe folks have been doing some this for a long time. It'd be interesting to see just how much carries over to a networked system.
And NI / bus bandwidth on the receiving host? This one's a cool problem. How much processing can be done in the NI to reduce host bus traffic? And how can one reserve resources in the NI to statistically guarantee that proper sessions work during a bombardment with bogus sessions? (Extra credit: How does one move some of the app-level down to the NI to help? Or out to the routers?)
These are the interesting areas for server-side DoS defenses, not DNS and router games. Then things like CIDF and/or the idwg work for detecting and squelching DDoS attacks... Imagine if every Gnutella, SETI@home, and distributed.net client and server also helped with DDoS detection... Much more interesting and practical than DNS and router tricks.
And then there's the boost in performance SETI and distributed.net would get from the new IMPS protocol...
The *best* solution, IMO, would be to use that Millenium computer center in DC to monitor backbone traffic in realtime and give those people access to the network to shut down these things dynamically and in real time. But, alas, that would require more political muscle than I have!
Once address spoofing is eliminated, all DDOSes that I know of will be eliminated.
You don't know of many DDOSes, do you?
First of all, non-smurf-type attacks are not going to be affected. Let's say I have control over 10,000 machines (worm, virus, whatever). If I tell all of them to start demanding something big (preferably, a fat dynamic page) from web server couple of times a second, that web server will be dead in very short order. No spoofing anywhere here.
Second, even smurf-type attacks use local subnet broadcast address, and in many cases the spoofed ICMP packet will never go through a router (it was generated already on the inside).
So, yes, rejecting spoofed packets will help. No, it will not stop DDOS attacks completely.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
I haven't read through the nitty gritty of the linked article here yet, but the March edition of Sysadmin magazine had an article, Router-Based Network Defense by Gilbert Held "Held discusses the use of router access lists (using Cisco routers as an example) to minimize certain types of network attacks." It's not online at www.sysadminmag.com yet, but it explores some of the basic concepts involved in configuring CISCO routers to stop such attacks. Worth the read if you are interested. You can still get it at your local newsstand.
My understanding of routers is that for best performance you want the 'best' routes. What consitutes best is determined by the algorithm, but generally speaking it's the route with the lowest latency (OSPF, for example, uses this metric). So by changing the routes you'd be making things less optimal. The other problem is convergence, or how quickly routers adapt the new routes. Routers have special protocols to make sure that when a route goes down (or a new one comes up) that change propagates through the router 'network' and each router updates it's router table to keep track of which packets go where. Any change in routing on a network requires a finite period of time to propagate through the router network. Changing routes too often can severely impact performance - router loops come to mind as one possible Bad Thing. So, short of redesigning all existing router protocols or creating a new one which very rapidly updates all routers on a large network, I don't see changing routes as a solution - the cure is worse than the disease.
Lastly, even assuming all these issues were worked out, TCP/IP is designed to be fault tolerant - if your packet gets eaten it will be regenerated. If the routes change, the packet will be re-routed to get to it's destination. In short, if you DDoS over a TCP/IP connection.. or generate packets which require the remote end to maintain state (which TCP needs!), you're going to kill the remote host regardless of how the packet got there.
The best solution at this time is to impliment packet filtering on the router. This has it's own set of problems, and is hardly a pancea. And how can you derive whether a DDoS is really occurring? The slashdot effect comes to mind as a good example.
Sorry, this won't work.
.. I do a new nslookup .. ah, nice. new ip/new network. Then I initiate a new attack on this ip/network. Ah, good, no more bandwidth there neither. new nslookup .. ah! A third IP! new attack. maybe a forth or fifth ip .. no problem, attack them and kill'em.
.. but if it won't fool me, then my guess is - it won't fool the dedicated attacker.
I've already seen some critic of the approach here on slashdot, and I see several points myself. My points may not be the best against it - but here they are.
First, yes, this proposal will absolutely make it a tad more difficult to attack the victim. But not difficult enough. Increasing the difficulty only increases the skill level needed by the cracker, and is security throuh obscurity.
Say i want to attack yahoo.com. The first thing I do, is to scan a couple of million IP addresses for vulnerable hosts. I crack into the 0.1% (probably more..) that is vulnerable, which gives me , say, 1000 compromized hosts to play around with. Heck, lets say its only 0.01% thats vulnerable. Still leaves me with 100 machines that I've got full access to. (That's a very, VERY modest number).
Ok, now I do an nslookup against my target. Ah, nice IP. Ok, i let, say 10, of the machines I've rooted - start attacking the victim. Making it switch to the new IPs
If the attacker is reasonable smart, he does a lot of bouncing via Wingates, making it impossible to track him down. One or two bounces, and he's pretty safe. We can forget about tracking him down. Its irrelevant if its possible -- the DDos has already been executed. It could be done as a terrorist act, by someone who isn't located in a 'specific' place. Therefore depending on tracking down the culprit isn't good enough.
OK, say that the customer has enough bandwidth, to sustain an attack from a divided attack. That it takes all 100 hosts to kill its bandwidth. Ohwell, then he does attack with every single host. The victim goes down for 5 seconds, switches to new ip, the new route take [unknown time, I guess a couple of minutes, I don't know that stuff] to spread out netwide. The attacker notices this after, say, 1 minute, and takes attacks the victims new IP - full force. The victim switches back.
This would still disrupt trafic to the site. If a site if down for abour 30% of its requests - it is down for to many people. 30% of the people accessing the page will get an error message about the host beeing unreachable. That's unacceptable. The rest would find the service disrupted after getting the front page, and having 70% chance (probably less) of getting to the next page - due to the new ip address.. dns lookup, and so forth. remember, it takes time to propragate DNS too. Far too long time.
So, the suggested approach doesn't work. It may, perhaps, slow down the attack, or STOP the unskilled attacker -- but it wouldn't fool - for example - me. Now, luckily I'm not a smurfpuppy
However, there is a way to prevent, or at least slow down / make it easier to track DOS attacks (not DDOS..or it would take some more time). If ISP's there came new router software, making it possible to grep the packet stream for certain packets (ICMP for example), and giving access to this - to other ISP's... then it would be possible to speed up the tracking. This, however, has severe privacy issues. As well as the load probably would be far to much for the router to handle. I'm not skilled enough in router-related things, to know if it would be possible (load-ways) to apply -- but I think it would be a possible solution, if implemented in all core-routers. possibly with limited information (only what router the packetstream is coming from)
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
"Rune Kristian Viken" - http://www.nwo.no - arca
Fernando seems to have a rather limited understanding of the internet, routing, and DNS, and a little knowledge is a dangerous thing. But he has taken the right step by publishing and requesting the internet community to enhance it.
:-)
:-(
/dev/null for a while.
Here are a few points that make this proposal too simple for actually defeating Multi Sourced Denial of Service attacks, and puts an even greater strain on the internet. I also don't see any difference between an MSDoS and the slashdot effect.
DNS TTL=0
This defeats the purpose of caching, and would require all resolvers to pick up the A record from the authoritative DNS server of example.com for every new connection to the web site. Since no other DNS servers on the internet will cache a TTL=0, example.com's DNS machine had better be very beefy and have a huge pipe to the internet to handle the requests. Also, every client's resolver will cache the IP address for the duration of the connection, even TTL=0, so if the route changes then the connection breaks.
Imagine if all customers of eBay or CNN had to reconnect every time some script-kiddy triggered the MSDoS protection mechanism. Meta DoS!
Don't tweak with the DNS system, it works pretty well as it is (ignoring TLD politics)
The ISP may also stop publishing the route to 10.0.0. This probably has a cost on BGP disaggregation and routing updates
No, BGP route damping will kill this for all but route updates from adjacent ASes. It also means that every ISP has to keep two ranges of IPv4 addresses to drop one and switch to the other. Route aggregation will make this effect almost negligible more than 2 ASes away.
The internet runs on BGP, because it hides all the complexity of the internet from routers. So route flapping gets killed before it can be seen by neighbors.
For this technique to be effective, the ISP total bandwidth must be several times the bandwidth it sells to its customer
ROTFL! This kills the proposal dead. Just try telling an ISP to keep their upstream bw several X what they re-sell to their customers. No, DoS attacks happen pretty rarely given the amount of use on the internet, so better and cheaper to let the FBI go out and bust a few script kiddies every once in a while.
example.com should change its network structure to
Here the stub network is coming off of the ISP's main router, not example.com. So unless example has a good buddy relationship with its ISP to change router configurations on the fly, this won't work. I don't trust more than 2% of my customers to have the knowledge to set their own config on my kit. If they want a change, they come into my office and we sit down together and hash it out on test machines before committing anything. At the most, I might accept limited routing updates from them, but they would never be propagated into my BGP tables.
Perhaps you could show the stub coming off the border network. Cisco routers have a null device to drop packets into rather than wasting extra time trying to figure output routing. This is where the route to etoys.com used to go before they got smart
Its identity can be hidden by making it unresponsive to ICMP
This is done in many places, it still shows up as * * * in traceroutes, and the addresses can be pretty easy to figure out. Routers not implementing ICMP break the fundamentals of IP routing, which is a no-no but accepted as a deterrent to the stupidest skiddies on the net. Anyone with a little knowledge can figure out several ways to stealth ping a network device or to query adjacent devices. This has nothing to do with shunting MSDoS attacks.
Some slightly better solutions, generally recommended but not always followed
Anti-spoofing
The key characteristic of skiddy attacks is to hide the origins of the MSDoS attack. It is recommended in RFC2267 that access points be secured from source address spoofing.
Really, this level of checking should be done at every access router. But thats another layer of complex commands the ISP net admin's sometimes don't support. Convincing them to do it will require an ISP to be held responsible in court (and pay damages) for not properly configuring a router behind a modem bank and allowing a skiddy to run a DoS from one of their dial in lines. I've already consulted for lawyers who were looking into doing just that, but they realised most ISPs and universities are so low-profit they couldn't make a ton of money from the case.
Customer and university routers should be checking anti-spoofing in both directions, for security and to make DoS from your own networks less likely. Most places only do anti-spoofing on packets coming from the internet, but leave the outgoing packets unfiltered.
Even BGP border routers should verify the source address of a packet actually belongs in their domain. This can be done for stub BGP regions but it can't reasonably be implemented at tier 1 and 2 level with transit BGP regions.
If it were truly an MSDoS attack from rooted hosts all over the internet, then the attack could just use the real IP addresses and routing happens normally. This is what has been seen lately with TTFN and Trinoo, and makes detection that much harder.
Anti-smurf
Pretty much every router should not allow directed broadcasts to create a smurf flood, but many still do
Route control and choke routers
Any large customer along the lines of a Yahoo or CNN should be able to negotiate the purchase of an upstream choke router and an authenticated routing update mechanism for it. This would allow them to switch floods from their saturated link to a null device for a minute. They could then start to analyze what had just hit them, and create some quick-fix access lists for a special choke router.
Even smaller customers with some technical knowhow could be allowed to update their upstream router to shunt traffic to
The latest attacks don't rely on spoofed source addresses, SYN attacks, or any other filterable packets, making it easy to create filters for the rooted hosts IP address.
Routing updates would go through a separate link dedicated to management and routing, and wouldn't carry regular traffic. If example.com is big enough to attract an MSDoS, they could afford an extra 64k link to their network managers office.
There is a lot of work going on behind the scenes to make the internet a little more secure so our quake match^H^H^H^H^H^H^H^H^He-commerce isn't interrupted.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
alright.. let's begin with my problems with this.
A) You don't need the stub network. You can route 10.0.0.x to the bit bucket on the ISP's aggregate router, which would be better for the router's CPU utilization anyways
B) What's to stop the haxx0rs from writing a small script that polls the dns servers every 5..10..30 seconds and changes all of the DDos boxen to the new IP instantly
C) You don't have to call your ISP to reroute traffic, you can do that in a BGP advertisment, which customers control.
D) Besides, if you're going to call your ISP, there are MUCH better ways to releive a DDos attack. Cisco is releasing/has released a slew of new tools such as reverse-path TCP acknowledgement (to deny spoofed return-path IPs automatically) and CAR (Committed Access Rate, which allows you to rate-limit certain TCP protocols much more easily, and to drop packets that are flooding without overutilizing a router. Note that you need a big scary Cisco box with 128meg of ram on each VIP slot to take care of this, but any real ISP should have that)
The point is that this should be taken care of at the ISP level, not at the customer level, as ISPs have the experience and infrastructure to deal with it. These little customer tricks to try to deal with DDos are easily defeatable.
//Phizzy
"Most European technology just isn't worth our stealing," -- Former CIA chief James Woolsey, referring to Echelon
That's not easy for you or me, but a company like Cisco should be able to set their routers to do this by default. They could probably even cause current routers to start this behavior with a microcode patch.
Once address spoofing is eliminated, all DDOSes that I know of will be eliminated.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?