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."
Didn't even notice the outage, none of my customers or people browing my sites indicated that they noticed either. In the nature of multiple providers and the way the DNS structure works, it would take an awfully long time for a large number of people to notice anything.
DNS info is cached and times out in about a week, so if you had updated just before the attack, you wouldnt notice for a week.
Have you ever actually programmed to the DNS protocol? If so, and you don't like the current clients (?), write your own. I've done it, it's not the easiest piece of code I've written, but it sure wasn't the most difficult either. If you've never written to the protocol, how do you know it's bad?
If things were as bad as you seem to think they are, the whole Internet system would have crumbled to rubble long ago. In reality, it has scaled amazingly well, and has been unbelievably robust.
Perhaps you should go purchase a clue, you obviously don't have one of your own.
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.
I have a question... Why does a cache have to expire?
Why not allow the admin to specify the maximum diskspace that the cache can use up, and then only prun the records when that (possibly huge) database grows too large? In addition, DNS records should not just arbitrarily expire...
If a record has not reached it "expire" date, the cache is just fine. If a record HAS reached it's "expire", it should still remail valid UNTIL the DNS server has been able to get a valid update. Now, that would allow large DNS servers to maintain quite a bit of functionality even if all other DNS servers go down, and would do so while requiring only the most popular queries are saved on the server (so not everyone has to become a full root DNS server).
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
He basically got his hands on one of the "zombie" trojans the DDoS'ers use, reverse engineered it to find out how it works (and which IRC servers it talks to to receive its commands), wrote his own to connect to said server and waited until the attackers personally logged in. It really is a good read.
- 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.
Easier said than done... that may be true for smaller networks, but isn't the case for larger ISPs. The IP address structure is no longer strictly heirarchical anymore (e.g. CIDR and multihomed networks) and peering relationships between different AS's make this extremely difficult to implement.There are basically two kinds of attacks...prevent the system from working (such as with a DDoS attack), or corrupt the data they serve by inserting replacing or making unauthorized changes. The former is a pretty well understood networking problem for all kinds of protocols, although DNS by its design of being heavily distributed and mirrored has some natural immunity.
.org domain a while back. Diversity is the other protection, different TLD servers use different hardware and software as well as being locating in different geopolitical regions.
However the protection of the data that the TLD (or subdomain) servers hold is perhaps the most important. That data is after all what our beloved TLS/SSL web browsers use to verify the sites that we visit. All TLDs run with the DNSSEC extensions which includes all the crypto stuff which signs and protects the zone data, along with many other standard computer security techniques. There are even minimal requirements that all TLD servers must adhere to RFC2870, which contains some very interesting clues as to what they do. Also the Internet Software Consortium which runs the F root server sometimes provides information about their operations on their site; especially when they were bidding to take over the
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.
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.
Actually, there is at least one very good reason. If company A has 2 internet connections through provider A and B, and wishes to do load balancing, but for one reason or another can not announce a single subnet through both providers, they can at least do outbound load balancing and change the source address on a per packet basis, so incoming traffic for connections initiated by someone local are evenly distributed through both connections. Obviously any connections that originate from the outside world (i.e. someone on the internet trying to view this company's website) have to be answered with the same IP that the request originally went to as the source address (or stuff will break(tm)), so this wont work in that situation, but any request that originated on the company's network, and goes out to the internet, can have the outbound traffic load balanced on a per packet basis over their multiple internet connections, even if they can't announce the same block through both providers. This however requires that some packets have a source address in the subnet of for instance provider A, when they go out through the circuit with provider B, to evenly load balance packets.
The other option, which does not require sending packets with a source address for one provider when it goes through another, is to do it on a per connection basis, and not a per packet basis, however depending on your traffic, etc.. this may not work nearly as well.
While obviously, the number of people implimenting something like this is few, and the benefits are many to implement anti-spoof measures, to the few people doing something like the above, it sucks. However, there is an answer, that will satisfy both causes.
To the few people that do load balance in the method mentioned above, a simple ACL allowing only packets with either subnet as the source (for either line A or B's block), and deny all other sources, will both allow them to load balance outbound traffic, and it will protect your network (and others) (since they can't spoof any other address, other than their block with the other provider through you, as the ACL will drop it).
For everyone else, you can use the following command on a Cisco with CEF enabled, which drops all traffic that does not have a source address that is routed through the interface the packet was received on:
"ip verify unicast reverse-path"
>So my first thought was why not have multiple
>separate servers with the same IP address
there is a recently announced plan to provide
several copies of the F root nameserver in the
asia-pacific region. See
http://www.isc.org/ISC/news/pr-11172002.html
http://www.apnic.net/services/rootserver/
presumably this will be extended to other root
nameservers