Pushback against DDOS Attacks 159
Huusker writes "Steven Bellovin and others at ATT Research Labs and ICIR have come up with mechanism to stop DDOS attacks. The idea is called Pushback. When the routers get flooded they consult a Unix daemon (/etc/pushbackd) to determine if they are being DDOS'ed. The routers propagate the quench packets back to the sources. The policy and propagation are separate, allowing hardware vendors to concentrate on the quench protocol while the white hats invent ever more clever DDOS detection filters for /etc/pushbackd. The authors of the paper have an initial implementation
on FreeBSD."
Re:hey (Score:4, Informative)
Re:hey (Score:4, Informative)
It would shut off the source of the flood, not the destination as the original poster implied...
"quench" ? (Score:2, Informative)
Sounds like the name of a sports drink targeted at uh....interior decorators.
Shouldn't it be "squelch" ?
Cheers,
Re:sure (Score:4, Informative)
If every network provider ran this type of a system on their edge routers. Have all the edge routers communicate to distributed servers. Then, when you are being attacked you simply announce the offending IPs involved in the attack. That announcement gets propogated around all the servers which tell the edge devices to filter the traffic. It isn't a reverse flood. It is a way of telling the router closest to the source to start dropping packets.
Forged source IP's should be dropped at the edge already.
What we need is a protocol for sending dynamic filters to cisco routers. I would like to have input/output lists put on an interface that I can later build dynamically. I do it now with my Linux firewalls but it would be nice if I could drop the packets on the far side of my expensive link.
Old Idea (Score:5, Informative)
The basic implementation has already been done.
What is novel and new about this paper is the suggestion that upstream routers are going to allow any tom, dick and mary to tell them what packets to throttle.
Always ass-uming that the larger switches can actually do this on the scale that is hinted at in the paper.
While issue 1 is specificly a political issue between carriers and customers, one could always point to the ease of which BGP routes are exchanged as an example of how easy this would be to do. Unfortunatly, since we are now talking about something that could effectivly put a transit provider out of business, there is no way issue number 1 will be overcome, unless the router manufactures give me the same kind of filter and ruleset technology I have for BGP. This would allow me to ignore anything I want from anyone, and would have the net affect of the feature being disabled!
as for 2, I'm sure some router manufacture has been touting this type of 'feature' on thier new multi-gig-a-bit MPLS/IP-does-everything-at-once switch. Don't believe it until it's out of the lab, guys. As many times as carriers have been screwed over by these new startups and their 'awsume powerful technology', I'm supprised anyone believes thier line of crap anymore.
It's too bad DDOS attacks don't go on for weeks, then we could use something like RBL to deal with it. Since they are so transitory, blackholing on the fly, (which is basicly what this paper is advocating) would require a lot more thinking about than has been put into this work.
Perhaps, instead of trying to complicate our lives with Yet Another New Protocol, you could simply come up with and IDS concatonation system, that puts together 'lists' of known DDOS sources at the current moment, and put it into a BGP feed... What a concept! Taking 2 technolgies that are known to work, and available to ANYONE that does BGP on the internet, and making it work!
Thank You, Come Again.
Criticism, improvement and easy testing! (Score:2, Informative)
Criticism: By giving smaller routers the power to command the behaviour of larger routers upstream, you are dangerously opening up a loophole that could allow someone in control of a router to maliciously affect upstream behaviour (potentially a huge scope!).
Improvement: Only allow routers to pushback/command up one or two hops to limit the scope of potential reverse-DoS attacks.
Easy testing: This doesn't refer to the above issue, but still... have AT&T set up a test site running their BSD implementation and then post a story to slashdot to have us test it out :)
Re:My take (Score:4, Informative)
Juniper routers do this sort of filtering and policing in hardware, and can also generate traffic stats efficiently. Other vendors have similar features - Cisco 7500 routers can have multiple VIP processors, distributing the work down to the interface cards.
The main constraint is that you need new software written, installed and debugged in these routers, which will take time and require an agreed standard across router vendors. In the short term, it's easier to use existing features such as NetFlow/cflowd for traffic stats, feeding into an existing DDoS analysis tool (e.g. the Arbor Networks ones), which then tells a router provisioning tool to reconfigure the routers. This would not be as slick or dynamic as the proposed scheme, but could be done today. It would also make it possible to have a human in the loop initially, reviewing suggested changes. This would work OK as long as management and routing traffic are assigned a separate queue on each router interface, guaranteeing enough bandwidth to make these changes in the face of a DDoS attack (something that the ACC approach would also need).
Re:blocking packets with forged return addresses (Score:5, Informative)
As for router capacity - Junipers don't have this problem, and if the ISP manages the CPE router on the customer site they can just push it down to that device. On a Cisco, where you have symmetric routing (probably the case for most smaller customers i.e. not dual-homed), you can just set the IP reverse-path forwarding option, which is very efficient - on each packet, the router does a routing lookup on the *source* address, as if it was trying to send a packet back to its origin. If the routing table doesn't have an entry for that source address that points out via the interface the packet was received on, the source address has been forged. This is not much overhead at all - just one more routing lookup.
For dual-homed customers, the provider has to use ACLs or perhaps a managed CPE, but ideally this would be a selling point for the ISP helping to generate cash to pay for router upgrades if needed - it safeguards the customer's network from being used to generate DDoS attacks with forged source addresses, which could save the customer from a lawsuit.
Papers about the problem... (Score:2, Informative)
I wrote a paper in a similar vein last spring about stopping ddos attacks, it's the second section of this paper [uci.edu]. It seeks to fix the underlying problem, not create a band-aid.
Nah, this isn't gonna work (Score:4, Informative)
Sending quench packets back to the routers feeding you DDoS packets, and eventually back to the host in question, is a good idea in theory. Kinda like communism. But in practice it won't work. First of all, there are the CPU strain resources on the routers and hosts. With DDoS, you have thousands if not more hosts all banging on your router, and your router is going to get a cardio workout going through its tables and deciding what gets throttled. Secondly, the return addresses on DDoS zombie packets are forged a good 80% of the time, meaning that you'll probably only hit 2 or 3 routers upstream with your quench packets.
A better solution? Null routes come to mind, but there are the CPU issues again. I'd like to see some "technology" similar to this where a customer of a commercial ISP could modify firewall rules on the _ISP's_ router to control traffic coming into their netblock. Perhaps a few routers upstream too. This really appears to be the only logical "quick fix" at the network level for DDoS.
A better fix would be to keep those zombies from ever coming into play by nuking everyone's NT/XP boxes, but that'll have to wait until penguins or daemons rule the planet.
Re:Couldnt pushback be a Dos tool in itslf? (Score:1, Informative)
and as the flood stop makes it,s way up the network to the source more and more bandwith is avalibale to the network untill hopefully even the ofending machines will ack and stop sending.
But even if the ofending machine wont the routers
in between the target and the source will.
CCNA
Re:Problem? (Score:1, Informative)
Here is a Cisco IOS policy that will identify and throttle all ICMP echo traffic that consumes greater than 256K.
policy class-map match-all DOS
match access-group 189
policy-map killicmp
class DOS
police 256000 8000 8000 conform-action transmit exceed-action drop
access-list 189 permit icmp any any echo
access-list 189 permit icmp any any echo-reply