Slashdot Mirror
More Info on the October 2002 DNS Attacks
MondoMor writes "One of the guys who invented DNS, Paul Mockapetris, has written an article at ZDnet about the October '02 DNS attacks. Quoting the article: "Unlike most DDoS attacks, which fade away gradually, the October strike on the root servers stopped abruptly after about an hour, probably to make it harder for law enforcement to trace." Interesting stuff."
Well then, isn't it logical to try and rate limit/filter as close to the source as possible then? Of course this shifts responsibility...
If all ISPs were proactive in dealing with customers machines being used as zombies to launch attacks, then internet users as a whole would have less problems trying to deal with being the target of an attack.
A few logical steps:
Some ISPs may do this, I don't know, but from the articles I read about DDoS attacks it appears that most don't.
What one *should* do is to configure backbone routers to not allow more than a cerain amount of ping per second...
Noone has a legitimate need for streaming several hundereds or thousands pings per second...
Or at least put a lid on it when someone starts sending lots of pings for more than a couple of seconds...
/.Mattsson - My native language is not English, so please don't whine over linguistic errors. (That's lame anyway...)
It's virtually impossible to trace it back to the originator. First off, they are using slave machines, machines belonging to common people not aware their WinBlows system got infected with a trojan, just because they haven't paid attention to the latest security hole.
M$ is just as much a part of the problem as well. With more and more cable, DSL and other "always on" connectivity available, more and more of these machines are vulnerable.
Scanners out there can easily identify and infect 1000 home user's machines, and these attacks come from them. The actual perpetrator is long gone. All they do is momentarily log in and "fire it off", then they immediately log out, and they are gone.
Tracing IPs back to the attacker is just going to identify the innocent machines or owners who are totally unaware of their activity until they either power down their machines or somehow discover it.
Or at least put a lid on it when someone starts sending lots of pings for more than a couple of seconds...
Doing so would require remembering who pinged, and when, for the last few seconds. Under normal conditions, that sounds trivial, but pings don't cause any problems under "normal" conditions. In a DDoS, you might have a million machines all pinging. How do you propose to store, look up, and update the last ping time for 100 million pings per second? A quick off-the-cuff calculation shows that *just the storage* for 10 seconds of such recording would take around 8Gb (32b IP and 32b timestamp). That doesn't include the CPU time to find matches (not that bad, since you can use the IP as an array index, but you can almost guarantee a continually invalid CPU cache) or update the list. And, that assumes you *always* dedicate that 8Gb to each server running on the machine, since otherwise the search you propose requires adding new pings to a dynamic list, making the lookup time become very very non-trivial.
More importantly, even if you *do* manage such a feat (or even get rid of ping altogether), attackers can still use other services (like, for example, DNS lookups, which I'd like to see a DNS server try to stop supporting).
Actually, it surprises me that no DDoS clients use SSH yet... Although not every machine (ie, Windows) runs an attackable server, a well-planned attack could suck up significant bandwidth, memory, *and* CPU power, all in one tidy packet.
Implementation of simple egress filtering rules at border routers or at firewalls (regardless of who owns them) would dramatically decrease the efficacy of DDoS attacks.
If my organization owns the A.B.C network, there is no reason why any packets bearing a source address of anything other than A.B.C.* should be permitted to leave my network.
NAT environments can implement this by dropping packets with source addresses that do not belong to the internal network.
Of course, for this to be effective it would have be used on a broad scale, i.e. around the world...
I want to drag this out as long as possible. Bring me my protractor.
End users don't need root or TLD servers; they just need to have DNS queries answered. That's why normally, they are configured to query the ISP or corporate DNS servers, which in turn do the recursive query to root, TLD, and remote DNS servers. Given that, consider the possibility of the ISP or corporate data center intercepting any queries done (as if the end user were running a recursive DNS server instead of a basic resolver) and handle them through a local cache (within the ISP or corporate data center). It won't break normal use. It won't break even if someone is running their own DNS (although they will get a cached response instead of an authoritative one). It will prevent a coordinate attack-load from the network that does this.
They talk about root and TLD servers located at major points where lots of ISPs meet, which poses a potential risk of a lot of bandwidth that can hit a DNS server. So my first thought was why not have multiple separate servers with the same IP address, each serving part of the bandwidth, much like load balancing. And then, you don't even have to have them at the exchange point, either; they can be in the ISP data center. They could be run as mimic authoritative servers if getting zone data is possible, or just intercepting and caching.
now we need to go OSS in diesel cars