Improving Robustness of Distributed Services (Re: DDoS attacks)
Hello, I've been involved in running part of another IRC network and I've been trying to find reasonable ways to immunize networks to DoS attacks. The reasoning behind this quest is that if there is no way to deny the service, then the attacker shouldn't have a reason to even try. I think this is relevant content for this mailing list because: * Most of DoS attacks are against IRC networks. Hence, if we can get rid of those, the health of the Internet as a whole should improve. * Experience gathered with this approach should be useful to developers and administrators of other distributed services and protocols. (e.g. usenet news, web cache heirarchies, DNS, BGP, ... YMMV) Protecting the network can be divided into two parts: Protecting network links and protecting client servers. There are a lot of well known ways to protect client servers and someone else can write about that. But apart from myself, I haven't observed anyone trying to protect network links. This I find surprising since it is often the links that the abusers are specifically trying to attack. The way I feel major inter server links should be protected is that they should be moved "out of band." They could for example be moved into permanent virtual circuits with a few megabits of guaranteed bandwidth per second. Since this protocol does not use a fully meshed network, but only an acyclic subset of it, most of the reserved bandwidth would be available for use by other services. In essence, using this dedication wouldn't use up any more bandwidth in the backbones than the current way of running links over the public Internet. It would just make sure that these critical links couldn't be caused to flap by denying their bandwidth. If resources exist and are readily available, the inter server links could maybe even be assigned a real dedicated circuit. Wrt. the applicability of this approach to other distributed services and protocols: It was just yesterday that I was talking with a friend about BGP transit and peering practises (in general) and one of the things I mentioned was that I would like to see the practise of separating the BGP transit session on its own circuit apart from the transit circuit being deployed more widely. This would not be such a bad idea at exchanges either. In some cases it might have very apparent uses for purposes other than DoS resistance as well: With the emergence of exchanges for multiple different "Internet Commodities" (IPv4, IPv4 MBone, IPv6, ...) many of the exchanges have a separate shared medium (often just a VLAN) for each of the exchanged protocols. I don't find debating about the reasons of separating them or not at this stage of hardware, software and protocol maturity useful. I'm just stating that this is one of the current practises. Now, what operators - that are capable of carrying all the protocols over a single infrastructure - could do at these exchanges is that they could run peering their sessions for all the protocols in one and work similar magic with the next-hop addresses etc. as in the transit session case above. The exchange point could provide a separate out of band shared medium over which the operators could run these peering sessions. This would simultaneously increase network stability by making the BGP sessions themselves impervious to attacks. These approaches of course require more complex configuration, more thought, more clue when debugging, and generally more everything, but I find that nothing new. Kindest regards, -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting http://www.axu.tm/ PS. Of the people that flamed the original poster, tell me which were ones that didn't have any kind of affiliation with the provider that the original poster had trouble with? There was a time when they weren't the ones to effectively say "We are the phone company. We don't care. We don't have to."
On Thu, Jul 12, 2001 at 12:13:17PM +0300, Aleksi Suhonen wrote:
Hello,
I've been involved in running part of another IRC network and I've been trying to find reasonable ways to immunize networks to DoS attacks. The reasoning behind this quest is that if there is no way to deny the service, then the attacker shouldn't have a reason to even try.
I think this is relevant content for this mailing list because:
* Most of DoS attacks are against IRC networks. Hence, if we can get rid of those, the health of the Internet as a whole should improve. * Experience gathered with this approach should be useful to developers and administrators of other distributed services and protocols. (e.g. usenet news, web cache heirarchies, DNS, BGP, ... YMMV)
[...] I've seen a few suggestions bounced around about way to protect the inter server links. Most of the suggestions brought forward revolve around hiding the server to server links, to make them difficult targets to attack - running server-to-server links over IPv6 (which is allegedly now as easy to DoS as IPv4, unfortunately), running them over IPSec w/ private IP addresses et al. Unfortunately, finding private peering and such for IRC servers would be a very costly way to go - and not one that's attractive to many of the educationals/ISPs/private parties that run for the most part, non-revenue generating IRC services. There are a few other ways to protect your client servers semi-simply - move them into a seperate block - which you can easily stop announcing globally - or even just announce to only those peers with whom you peer IRC, or those peers whose customers you allow to use your IRC server. The latter of these would work well for large IRC networks with many servers, as it controls exactly which servers people can use. Unfortunately though, I've still not found an elegant solution to these problems that doesn't also remove the service, or still rely on shipping the traffic across your borders. To a certain extent, contacting your transits works to get attacks stopped. I've certainly had good experiences with at least Cable and Wireless, Teleglobe, and Genuity. But even then, the time from attack starting to getting traffic filtered can be in the region of 30 minutes to an hour, and this only stops the traffic coming through your transits. Peers are another matter entirely, and since even one or two IXPs can result in the order of 400-500 peers, there's generally no possible way to call all of them in a short timeframe. Question for the list: Does anyone have good or bad experiences with mailing lists containing all of your transits, and peers NOC addresses, and using these kinds of lists to contact / request filtering on mass? How do people on the relevant NOC lists feel about this kind of situation? Cheers, Chris.
Hello, On Thu, Jul 12, 2001 at 12:13:17PM +0300, I wrote:
I've been involved in running part of another IRC network and I've been trying to find reasonable ways to immunize networks to DoS attacks. [...]
Quote from Chris Roberts: } I've seen a few suggestions bounced around about way to protect the } inter server links. [...] } There are a few other ways to protect your client servers semi-simply - } move them into a seperate block - which you can easily stop announcing } globally - or even just announce to only those peers with whom you peer } IRC, or those peers whose customers you allow to use your IRC server. } The latter of these would work well for large IRC networks with many } servers, as it controls exactly which servers people can use. While I find the idea of having the IRC server sit in a prefix of its own with limited visibility very lucrative, it would seem to be very hard to actually acquire an unaggregated prefix for this purpose. Would there happen to be someone on the list with an unused B-class (for example,) that would be willing to give out sub-C's (for example) for such a purpose? ;-) } Unfortunately though, I've still not found an elegant solution to } these problems that doesn't also remove the service, or still rely } on shipping the traffic across your borders. Well ... I of course feel the solution I presented would be elegant wrt that, but I won't deny that provisioning the (virtual or real) circuits required is very hard, especially if on a zero budjet. } Question for the list: } Does anyone have good or bad experiences with mailing lists containing } all of your transits, and peers NOC addresses, and using these kinds } of lists to contact / request filtering on mass? How do people } on the relevant NOC lists feel about this kind of situation? I haven't done exactly that, but from my experience I would imagine that using something like that may get your filter installed faster, but removed slower if at all. It will probably have very little impact on the number of peers that are willing to install a filter just for you. Also: asking for a null host route will more often result in getting the desired effect than asking for a filter, for various technical reasons. Kindest regards, -- Person: Aleksi Suhonen nic-hdl: AXU-RIPE
participants (2)
-
Aleksi Suhonen -
Chris Roberts