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."
As email viruses expanded from an original concept, their authors began to adapt to the strategies used both to catch them and to deal with their creations. As a result, newer viruses have been more damaging. The October attacks showed a greater level of sophistication solely because the people behind these types of attacks are aware of what's going on and pay attention in order to make them more successful. The scary part is that the longer people like this are able to elude law enforcement, the larger their attacks will eventually become. Each one is, in essence, a trial run for the next larger attack. Watching attacks like the ones that have plagued dal.net for a long time, it's easy to see how these attacks could end up causing serious problems (beyond the minor inconvenience of not being able to get to your favorite sites) in the near future.
Unfortunatley, the theives didn't wait for law enforcement officials to show up, making it much harder to identify them.
0110100100100000011000010110110100100000011000100
The Dalnet IRC network has been crippled for months due to continuing DDOS attacks. Now Dalnet is based on a small number of central IRC servers (20-30 I believe) so it isn't too far removed from the core DNS infrastructure (i.e. the root DNS servers).
Why don't Dalnet and the FBI (or whoever) get together to solve a mutual problem ?
Dalnet could get some much-needed help, and the FBI could get some much-needed experience into investigating this sort of attack. They would also be dealing with someone (or some people) who could move on to attacking bigger things.
Also if they caught the attackers, they would get some useful publicity, some justification for an increased spend on cyber-deterrence, and the deterrent effect of having the perpetrators suitably punished - as well as putting a genuine menace behind bars.
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...)
I'm not an expert, but as I understand it, DNS attacks are relatively benign, since DNS info is cached all over the place and doesn't change much anyway (this is essentially what the article says). Now, the author seems much more worried about attackts against Top Level Domains, because of reasons related to the nature of the information that TLD servers have, and he suggests a few techniques that they could use. What he doesn't say is what techniques the TLD's are using currently, and how secure they are.
/. know?
Does anyone out there on
"...the October strike on the root servers stopped abruptly after about an hour, probably to make it harder for law enforcement to trace."
Hrrrrmmm. That makes it look deliberate. Hrrrrmmm.
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.
Also, I wonder if switching the default permissions on ping so that only root (or some other privileged user -- I don't know how/if Windows implements this these days) wouldn't be a good idea.
Windows has only the most vague concept of a "root" user, and rooting a Windows box takes about 40 lines of code (basically, the problem comes from the GUI - any program running with administrator privelage, such as a virus scanner, can spawn additional processes also running as the administrator. Making them do so requires nothing more than getting a handle to a text edit control, pasting in the desired malicious code, and using the address of the edit's buffer as a start-of-execution point. All of which *any* user can do.
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.
Start the antivirus UI process as part of an isolated job with limited UI privs. It'll be in a separate windowing namespace, and the shatter attack will no longer work.
Tell me, do you run *all* your programs in a private UI context? The antivirus program just makes the "classic" example. How about your usually-hidden-but-always-instantiated NVidia setup panel? Any services you run that have a control panel for configuring them (Tardis, for example)? A local web server? One of those annoying (but often necessary for proper functioning of the related device) printer or scanner control panels?
Aside from not trusting the so-called "privacy" of running something on a private desktop, you don't even need to bother breaking that layer of security. Just look for something else running as administrator... or backup... or power user... or replicator... or even "guest", which by default has an obscenely high level of privelage (relative to a Unix box, which doesn't even usually *have* an account as conceptually insecure as Window's guest account). If you've managed to configure a Windows box to have *everything* run as a specific, seperate user, in its own UI context, I tip my hat to you. I also do not envy the hell of making even trivial config changes to such systems, nor do I envy the frustration your users must feel at trying to use such a system productively. Put simply, Windows lacks the *design level* security to make it generally useable yet reasonably safe against its own users.
Finally, even if you change the default permissions on "ping" as the parent suggested, under Windows that doesn't do a damned thing to stop a trojan that *includes* its own ping program from working just fine. Remember that, in dealing with a DDoS problem, it doesn't matter if a security expert *can* lock down a given box - It only matters that 99% of the people out there won't bother to fix (or even *know about*) a given exploit allowing raw network access.