From fpscha@NS1.VIA-NET-WORKS.NET.AR Thu Feb 24 09:25:39 2000 Date: Sun, 20 Feb 2000 14:33:44 -0300 Subject: A DDOS defeating technique based on routing From: Fernando Schapachnik To: BUGTRAQ@SECURITYFOCUS.COM Distributed Deniel Of Service attacks. A proposal based on routing. ------------------------------------------------------------------- (version 1.0) Disclaimer ---------- The opinions expressed here are mine only. My current employer does not hold any responsability over them. This is only a proposal that must be considered as _draft_ or _work in progress_. It is made available to the Internet community as a contribution to fight the DDOS threat. It is published as and 'thinking starting point' rather than as closed solution. Please be aware that assesments made here could be wrong. I'd love to here corrections and refutals. Abstract -------- This paper describes a technique that -hopefully- can be used to defeat the recent DDOS attacks. The solution presented here is bases on routing. It requires a certain amount of extra network infrastructure. Introduction ------------ Recent attacks to big Internet sites such as Yahoo and CNN has possed a threat on Internet security. The problem with these DDOS is that packets come from spoofed addresses and tracking the source becomes a very complex task involving cross-AS cooperation and a huge amount of time. Some measures have been proposed, but they are based on filtering forged packets at the origin, and this means action by an -a priori- uniterested party. Furthermore little has been proposed to stop attacks as they are being produced. This paper introduces a method that can be used in some situations to avoid this kind of attacks in a short time fraim. It's efectivy increases if it is combined with origin-analysis techniques. Description ----------- We will introduce the proposed technique by means of an example. Let's suppose example.com has an important web site. During the scope of this paper we will asume we are not interested on any other service than www, although this method can be applied to protect another services (but not all of them). Another simplification will be to assume that example.com has only one link to the Internet. We can draw example.com current infrastructure like this: +--------+ -a--| | +---------------+ | | | | +-----------------+ -b--| ISP +-----d------+ example.com's +-----+ www.example.com | | | | border router | +-----------------+ -c--| | +---------------+ \ +--------+ \ 10.0.0.2 10.0.0.1 Being: a, b and c the ISP links to the Internet, and d a link between the ISP and example.com. Let 10.0.0.1 be the IP assigned to the internal interface of the border router and 10.0.0.2 the IP assigned to www.example.com public web server. It can be argued that there must be a firewall in between, but this is not relevant to the proposal. The proposed technique is about changing the IP addresses of the hosts being attacked and diverting the IP block under attack to a stub network where traffic can be analyzed to track it down, or just dropped. In order to be ready to a massive DDOS attack, example.com should change its network structure to something like: +--------------+ +----e-----+ stub network | | +--------------+ +--------+ | -a--| | | +---------------+ | | | | | +-----------------+ -b--| ISP +-+---d------+ example.com's +-----+ www.example.com | | | | border router | +-----------------+ -c--| | +---------------+ \ +--------+ \ 10.0.0.2 and 10.0.1.2 10.0.0.1 and 10.0.1.1 +---------------+ | example.com's | | DNS server | | where | | www=10.0.0.2 | +---------------+ In case a DDOS attack against example.com is detected, the following actions should be carried on: 1- dial up connection to example.com's externally located DNS server (possible many of them in order to complicate DDOSing both www and DNS servers) to make www.example.com point to 10.0.1.2. 2- phone call to ISP to route traffic to 10.0.0.x to the stub network and start routing the 10.0.1 network. These simple steps would divert the attack to a place where it doesn't disrupts example.com functionality and where it can be tracked down. Of course the attacker can notice the change, and: a) attack also the new network. In this case his 'firing power' against each network would be halfed. This opens the chance to example.com to have many networks to be used for such cases. Hopefully, a sufficient number of networks would make the amount of traffic received by each one large enough to be handled by undelying infraestructure. b) attack _only_ the new network. example.com can switch back to the old one, or even a new one. Maybe this is the best move the attacker can made, but if he does the comprised machines would create a pattern of traffic very easily identified by a distributed network scanner that can consult a central site for patterns and can _hopefully_ be run on periodic bases by ISPs concerned about Internet safety. Conclusion ---------- A method for defeating DDOS attacks on real time has been depicted. This method is not bullet proof and requires a certain amount of extra network infrastructure. Publishing it in its actual form main purposed is having it enhanced by the Internet community. Fernando P. Schapachnik Administración de la red VIA NET.WORKS ARGENTINA S.A. fernando@via-net-works.net.ar (54-11) 4323-3333 From fpscha@NS1.VIA-NET-WORKS.NET.AR Thu Apr 6 12:00:11 2000 Date: Tue, 22 Feb 2000 14:32:56 -0300 Subject: Re: A DDOS defeating technique based on routing From: Fernando Schapachnik To: BUGTRAQ@SECURITYFOCUS.COM I'll summarize many responses my proposal has have and give my thoughts about each one. Sorry for not been able to answer each one individually. Not enought time ;-) Let me first state that this was never meant to be a cure for every situation. I think is only feasible in particular cases. I do agree with most posts stating that to really solve DDOS we must attack the problem at its roots: egress filtering. My proposal aimes to help the ones that are being attacked. Renaud Deraison said: > In order to be ready to a massive DDOS attack, example.com should > change its network structure to something like: > > +--------------+ > +----e-----+ stub network | > | +--------------+ > +--------+ | > -a--| | | +---------------+ > | | | | | +-----------------+ > -b--| ISP +f+---d------+ example.com's +-----+ www.example.com | > | | | border router | +-----------------+ > -c--| | +---------------+ \ > +--------+ \ 10.0.0.2 and 10.0.1.2 > 10.0.0.1 and 10.0.1.1 If example.com is flooded with bogus network traffic (say, lots of TCP RST) , then the link "f" that I added on your map will be flooded anyway. So neither the stub network or example.com's border router will receive all the data they should receive. So the attack is still active. ---> Answer: it was just a graphic mistake. E and d should be absolutely independent links. ======================================================= Andreas Bogk said: > The proposed technique is about changing the IP addresses of the hosts > being attacked and diverting the IP block under attack to a stub network > where traffic can be analyzed to track it down, or just dropped. This will not help, as the ISPs border router is still flooded. You could drop the BGP route for that network, but that is highly undesirable: you would end up needing one BGP advertisement per "important" server. ---> Answer: this solution is intendeed to site's whose ISP has multiple links. Hopefully, the ISP total bandwidth is several times the bandwidth it sells to its customer, and it uses some kind of traffic shaping for each customer at the other end of its links, so he could survive the attack. If the ISP can't survive the attack, neither can its customers. And BGP routes are a scarce resource, since they cost RAM in everybody's border router: usually ASen try hard to announce as few of them as possible, some aggregate all of their space to a single announcement. ---> Answer: you would have to spend some resources in order to get protection. ISP can aggregate routes at its borders, so nobody knows that the route has been dropped (this is usefull is the ISP can survive the attack) or can advertise each involved network separatedly. The last option has the disadvantage you pointed out, but the advantage of traffic being dispersed nearer its origin. ============================================ Many pointed out thinks like: DNS records aren't instantly propogated to everyone (because of the TTL). How do you make sure that clients are diverted to the proper website? ---> Answer: Of course you have to use 0 (or very small) TTL DNS records. Remember RFC 1034: "[...] a zero TTL prohibits caching [...]". =========================================== David Brumley said: If the DDOS attack was targeted at the router one hop before the web server, you would have to move the whole subnet. ---> Answer: Yes, you are right. A solution might be for this router no to respond to ICMP or traceroutes, so its IP does not become publicly available. =========================================== Many pointed out: The attacker can switch its attack to the new network. ---> Answer: in this case he is creating a very particular traffic pattern. He will be consulting DNS servers very often. The clients can do it automatically, so surfing logs will show them, or even the 'evil master' behind the attack could make a mistake and consult them often enough. If his software must attack and IP address (not a FQDN) and he has some experience, he will consult DNS from one of the comprised machines, but then again you can track him down from there, as he must use real IPs to get to that machine. =========================================================== Felix von Leitner said: DDOS attacks normally saturate a, b and c as well, so this change will only help dial-up users from ISP in general. The DDOS attacks that struck Germany so far have always taken the whole ISP with them. ---> Answer: I'd really like to know if during these attacks ISP was appling bandwidth limiting to the customer being flooded on the other side of each of its Internet links. Fernando P. Schapachnik Administración de la red VIA NET.WORKS ARGENTINA S.A. fernando@via-net-works.net.ar (54-11) 4323-3333