but at that point, the only thing anycast would buy you is ddos resistance and the ability to have more than 13 physical servers... which is all the
Is that true? I'm failing to see how anycast helps expand a network's DDoS survivability. At best a dumb attacker would attack the IP address of the server and it would be distributed to all the participating anycast nodes.
as it turns out, some attackers really are idiots, and it's considered socially acceptable to pander to them even while also attempting to guard against real attacks coming from experts.
What prevents the attacker to hit just a few nodes from the anycast network to hurt percentages of the dns queries?
nothing, of course. but we like that the percentage isn't always 100% (as it would be in the non-anycast case.)
Obviously health checking would prevent some of the problems but then the attacker can just shift from site to site as the health checks happen.
there are some million-bot drone armies out there. with enough attackers you can just attack everything the defenders might try to use -- no need to shift from site to site in response to anything.
With that thought process, an anycast network is only as it's most beefed up node. As the smaller nodes fail the one left standing will be what prevents the attack, not anycast.
i admit that this appears true on the surface... but if you dig into it you'll see that even a root name server with 10,000 direct 10GigE connections (one for every autonomous system in the internet) would still be vulnerable to congestion based attacks, since a congestion based attack is against OPN's (other people's networks) where even infinite point-source provisioning cannot help you.
For an example, let's look at f.root: f.root-servers.org is 204.152.187.7
that's .org not .net. f.-.org is just a web server. you want f.-.net.
If an attacker wanted to be violent and have complete disregard for the anycast design, he/she would hit either each node independently and at the same time hit the upstream routes of both nodes. That would isolate each node from the anycast primary "VIP" of 204.152.187.7 and introduce problems into the design. Then, as those sites were failed out, he/she would shift the attack to the current operating sites.
an effective attack doesn't need to be nearly that subtle.
Eventually this cat and mouse would cause such a problem that the saving grace of the anycast design would be the strongest node in the cluster and the operators would have to fail each site in and out as the attack shifted around.
i suppose that you could do it that way, if you wanted to be more artful.
If they were really violent they would include a randomized valid query attack in the mix.
you mean they aren't?
Can you explain to me how anycast would prevent this?
i knew, at the time i wrote the words "ddos resistant" in this thread, that at least one person would think i meant "ddos proof". in wristwatches, "water resistant" means you can shower or bathe while wearing the device, but only "water proof" means you can scuba dive with it. anycast makes a dns service more ddos resistant. nothing can make a dns service ddos proof.
With that thought process, an anycast network is only as it's most beefed up node. As the smaller nodes fail the one left standing will be what prevents the attack, not anycast.
i admit that this appears true on the surface... but if you dig into it you'll see that even a root name server with 10,000 direct 10GigE connections (one for every autonomous system in the internet) would still be vulnerable to congestion based attacks, since a congestion based attack is against OPN's (other people's networks) where even infinite point-source provisioning cannot help you.
well, thats practically true, but not theoretically true. the DNS is running just fine thank you. ddos attacks against OPNs is not an attack on the DNS per se, its on the clients in the OPN. trying to ensure that every client has reachability to a given server set - FROM the SERVER side - is ultimately an exercise in futility. Servers/operators can only take reasonable and prudent steps to try and ensure the service is generally available -- micro managing DNS availablity to a specific server set is the way to madness. Anycast is a way to make the service generally available to as many end-systems as want/need the service. So is multi-homing. ... long term, what is important is the view that there is a common namespace, not that there are special servers.
Can you explain to me how anycast would prevent this?
i knew, at the time i wrote the words "ddos resistant" in this thread, that at least one person would think i meant "ddos proof". in wristwatches, "water resistant" means you can shower or bathe while wearing the device, but only "water proof" means you can scuba dive with it. anycast makes a dns service more ddos resistant. nothing can make a dns service ddos proof.
little, in practice, can make a DNS service ddos proof. it can be done, but the side effects are worse than the cure. --bill (ducking back into the background)
... be vulnerable to congestion based attacks, since a congestion based attack is against OPN's (other people's networks) where even infinite point-source provisioning cannot help you.
well, thats practically true, but not theoretically true. the DNS is running just fine thank you. ddos attacks against OPNs is not an attack on the DNS per se, its on the clients in the OPN. trying to ensure that every client has reachability to a given server set - FROM the SERVER side - is ultimately an exercise in futility.
i'm glad you said "every client" rather than "most clients". in october 2002 there was a ddos against all 13 root server addresses, and several of them were unicast (that's as in "not anycasted") behind DS3 links, and these "failed" in that they became unreachable by "most clients". of course, as you also point out, it's the reachability of the "server set" and not any particular server that matters. "long live diversity!"
Servers/operators can only take reasonable and prudent steps to try and ensure the service is generally available -- micro managing DNS availablity to a specific server set is the way to madness.
i'm really not sure i agree. about the madness, that is. i've heard of plans to do inside-AS anycasting of dns content, such that interested network operators could ddos-proof their view of a given server or server-set as long as the ddos did not emanate from within that AS, and i'm not sure that this is a bad business model given that BCP38 is still "madness" to many of you reading this.
Anycast is a way to make the service generally available to as many end-systems as want/need the service. So is multi-homing. ... long term, what is important is the view that there is a common namespace, not that there are special servers.
sorry, that's just too deep for me today.
little, in practice, can make a DNS service ddos proof. it can be done, but the side effects are worse than the cure.
being "worse" begs the question "worse for whom?", and for many, the things that can be done to ddos-proof a service are not worse than the ddos problem. so i'll consider that you mean "worse for you" and i'll wait to hear why that's true in your situation. (it's not true in mine.)
Anycast is a way to make the service generally available to as many end-systems as want/need the service. So is multi-homing. ... long term, what is important is the view that there is a common namespace, not that there are special servers.
sorry, that's just too deep for me today.
more eggnog. if the client can ensure that the data asked for came from an authentic source and arrived intact, does it really matter the path or intermediate nodes taken to get the data?
little, in practice, can make a DNS service ddos proof. it can be done, but the side effects are worse than the cure.
being "worse" begs the question "worse for whom?", and for many, the things that can be done to ddos-proof a service are not worse than the ddos problem. so i'll consider that you mean "worse for you" and i'll wait to hear why that's true in your situation. (it's not true in mine.)
ddos proof DNS service can be had in one way - don't run DNS. - moving up from there, air-gaps, running the service on non-networked interfaces, e.g. ::1, augmenting the DNS service with "bodyguard" support services, e.g. ACLs, firewalls, router filters ad.nasusa, use of strong crypto (signed data, transaction signatures) et.al. ... everyone invites attacks by disaffected or bored, the students trying to pass Dr. JBs classes, the vaguely curious, the helpful, the application developers who optimise locally at the expense of others, and the down-right hostile. if you run DNS - they WILL come. ddos resistant is a moving target. the techniques you use are based on the deployment choices you make. they will not n'cssly be the same as i, or anyone else, might use. as usual, YMMV, --bill
On Mon, 20 Dec 2004 17:18:30 +0000 Paul Vixie <paul@vix.com> wrote:
there are some million-bot drone armies out there. with enough attackers
I've heard that claim before, but I've yet to be convinced that those making it were doing more than speculating. It is not unreasonable to believe there are millions of bot drones, but that is not the same as an army under a single or even coordinated control structure. It is entirely possible to build armies of that size, but maintaining them over any length of time is probably quite difficult. I'd of course be interested to hear about any evidence to the contrary on or off list. John
there are some million-bot drone armies out there. with enough attackers
I've heard that claim before, but I've yet to be convinced that those making it were doing more than speculating. It is not unreasonable to believe there are millions of bot drones, but that is not the same as an army under a single or even coordinated control structure. It is entirely possible to build armies of that size, but maintaining them over any length of time is probably quite difficult. I'd of course be interested to hear about any evidence to the contrary on or off list.
John
Not that it is really relevant to the original discussion, but here goes... The biggest drone armies out there are at around 200K, currently. The bigger controllers/runners usually have drone armies of 50K - 80K size botnets. Most botnets are between a hundred and 10K drones. Today, in the Quakenet IRC network we see: There are 66360 users and 153169 invisible on 42 servers About a year ago that was about 50K users. Back then about 20K - 30K of those users were zombies. IRC growth is a known thing, but it doesn't grow exponentially. People come and go, while other chat medias slowly eat at the IRC. With such a growth, not taking into consideration hard facts (that I do have about several IRC networks, as there are a few big ones), and 1000 or so new malware a month (950 of which being Trojan horses that can be used for botnets, most of which are agobots, ircbots, spybots, etc. - IRC bots) one could assume, under the MOST restrictive terms that at least 80K users are drones. Again - this is hardly the only IRC network out there. Not all drone armies are run via IRC. And finally, there are many drone armies running on *private* IRC servers much like anonymous FTP's are being used to hold warez. Also note (although this is rather shaky as "fact"), that most IRC clients set the user's mode to +i (invisible) by default. Draw your own conclusions from the numbers above. As to actual facts.. off list if you will be interested, and once I know you better. Gadi.
participants (4)
-
bmanning＠vacation.karoshi.com -
Gadi Evron -
John Kristoff -
Paul Vixie