Slashdot Mirror
Pushback against DDOS Attacks
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."
even better idea!
shut off the computer if its getting DoS'd
(FP?)
Unfortunately the DDOS'ers will simply find a new way to flood a system. The best way to defend against this is to have a backup plan for when your servers get hosed.
Help I'm a rock.
If pushback is subverted, couldnt it function like an inverse DOD tool?
You could at least vary the numbers in this, so as to make it APPEAR to be a valid report, different from the one you swiped it from (which also was bullshit)
If a large-enough site was getting DDoS'd (Yahoo!, Microsoft, universities, etc.), wouldn't there be someone on call 24/7 who could in a matter of minutes sort out what the similarities in the DDoS are and then manually get a RegEx to sort them all out?
I don't have much knowledge of the subject, but that seems like an easy want to deal with it.
We do not live in the 21st century. We live in the 20 second century.
the best defense is the attack, so if they saturate your A/B/C network, then saturating the Internet is the obvious right solution.
Of course its not, it would do much more harm to many more innocent people.
The right solution is to educate people so that their PC's doesnt get inffected with worms and the like so they dont unknowingly contribute to DDOS.
Of course, the right is almost always the hard way and most people doesnt want to care about ignorant people so... we're in a vicious cycle here, just as in anything else.
errera hunamum ets
Sounds like a pretty v1.0 idea at this stage, but I'm psyched people are spending brain cycles working on DDoS and flash-flood solutions, since they're both problems that are only going to get worse.
;-)
(Gotta love the Slashdot effect getting named explicitly, eh? Nice to be part of the problem for a change... hehe.)
Seems to me the tricky part here is defining the aggregates. After reading the article, it isn't *really* a way to save your site from going down due to overload, more a way to prevent others sharing your pipe/routers from going down with you.
Which is a good goal in itself. It seems like a real tough thing to determine which of the millions of hits to www.yahoo.com (for ex.) are valid users, and which are DDoS bots. So both get restricted (net result: bots win), but the guy in the cage next to yahoo stays up.
Looking for a Rails developer in Chapel Hill?
Not all DDoS attacks are bandwidth based, they could be application level and targeted at all sorts of other resources.
.. it would be nice if these actions could be initiated in other situations also.
Some examples:
SYN floods can exhaust incoming connection queues.
DNS floods (asking a recursive nameserver a million questions, or even asking an authoritative nameserver a million questions).
Too many HTTP requests to processor intensive dynamic content pages could deny service well before you are serving at your bw limit.
The paper kept referring to the aggregate detection algorithm only coming into effect when the bandwidth limit is being exceeded
Never the less, this is a promising initiative.
--Iain
Sounds like the name of a sports drink targeted at uh....interior decorators.
Shouldn't it be "squelch" ?
Cheers,
Bowie J. Poag
How does it prevent a Server from being Slashdotted?
stated in the paper "The Slashdot effect" often leads to flash crowds.
:)./
I think that deserves some props to the boys running slashdot since they got themselves noted in the paper.
As well as some credit to every one that reads the pages
How does this really help a DOS attack? The idea behind a DOS attack is to flood a server with so many packets that the server can't keep up and ends up dropping most of the packets. This paper does not provide a solution to this problem. It simply shifts where the packets are being dropped... at a router upstream instead of at the server or router at the edge of the network. The only advantage here is that other servers hanging off the router that aren't being DOSed will be unaffected.
The suggested solution also opens up a potential security hole. If you gained access to a server, it might be possible to send a packet to routers upstream and tell them to throttle bandwidth. This could be a much more effecient way of doing a DOS attack. Now instead of multiple machines on fast connections, all you really need to DOS your favorite website is a 268 and a 300 baud modem.
I just heard some sad news on talk radio - An Anonymous Coward was found dead in his Maine home this morning. There wasn't any more details, but athorities think he was hacked to death with a blunt spoon by author Stephen King. I'm sure everyone in the Slashdot community will be willing to provide an alibi for Stephen - even if you didn't enjoy his work, there's no denying his contributions to popular culture by killing this annoying f&#k. Truly a World icon.
I've dirtied my hands writing poetry, for the sake of seduction; that is, for the sake of a useful cause. --Dostoevsky
Back down to earth, it's mega-wicked when good ideas are developed in FreeBSD (or Linux). Developments like these come the closest to the original intents and purposes of open sourced OSes.
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
what in the heck am i saying? lets say you get a syn with spoofed ip's (ask any ircop how much fun that is) you could then trace back through every router that spoofed ip came from. i realize this would tax machines quite a bit in logging and what not.
i dont think there will ever be a way to prevent any type of attack. i do think its important to have a proper response plan.
-- botsex is {grep;touch;strip;unzip;head;mount}
Make ISPs liable for machines that they allow to connect that are periodically engaged in attempting to abuse other machines for longer than, say, 10 days.
Give ISPs an incentive to detect forged packets, portscanning, and other common signs of compromised machines at the source. Get rid of zombies at the source. Then there wouldn't be the raw material for DDoS.
In short keep machines from swinging their fists, rather than try to make the recipients more resistant to being hurt.
I believe most DDoS attacks have the following in common:
- DDoS zombies generally send packets with forged return addresses, as
doing so greatly complicates attempts both to block packets and to track
down individual zombies.
-
Machines used for DDoS attacks are almost always either corporate PCs
or home PCs connected by DSL/cable. These nodes are single-homed, and
as such packets emanating from them have only one initial route to the
internet.
My question is this - why can't corporate IT people or their counterparts at ISPs reprogram their front-line routers (those that directly connect to individual end-user PCs) to block packets with forged return addresses? Forged addresses typically are either totally illegal or indicate a totally different net or subnet from the actual sender.I can't see any reason why this wouldn't be a good idea - there really isn't any reason for the type of machines mentioned to ever act as true IP routers (as opposed to NATs), and it doesn't seem like this would be either hard or burdensome for the first-line routers to do.
Employing this would mean that DDoSers would be confined to forging return addresses within the zombies' own subnet, which would make both blocking and back-tracking much easier.
It's plain that this isn't done, so there must be a good reason why people much more network savvy than I haven't implemented it - what is it?
## W.Finlay McWalter ## http://www.mcwalter.org ##
Wow, more newsworthy than Tablet PC!
This idea has been hashed to death for years.
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.
It's Sunday morning! Don't be so serious over *everything*!
People like you give knee-jerk-reactionaries a bad name.
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
While Pushback technology can help the servers to stay online, they literally push the network load off to another branch of the network where it can congest normal networkconnections. For important servers like the nameservers that have been attacked last week - where they (btw) used a similar technique of pushing requests e.g. network data off to another part of the network - this is a good method. But you run the risk of creating congestion somewhere else on the network. So people working upstream from the attacked server will probably suffer from poor accesibility. It's just a choice what you want to sacrifice, either the targetted servers or the people upstream. But i agree this technology is a step forward towards an appropriate security answer to DDOS attacks.
Yes, the typical arms race situation applies, but the defenders now have some good weapons at their disposal. If the methods that implement the quench feature is robust and hard to subvert, then it is just the server that needs to be updated. Many techniques could be used to identify the sources of the attacks, including some manual help from the system operators. Over time, the demon could get very good at recognizing attacks bases on heuristics, so changes to the flooding packets or patterns might not help get around the filtering.
You don't generally need all that many machines to do SYN flooding or overload a DNS server.
DDoS attacks are brute force by nature, designed to take down sections of the network by saturating the links.
"I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
The paper talks about pushback filters based on destination-IP based address filters. Consider a DDoS attack on a popular site such as slashdot. Pushback will affect EVERYBODY, not just the unpatched zombies. If exploited correctly, this makes for a perfect tool for the hacker to obtain a 100% denial. This is an arms race, we can't afford to give hackers our nukes, unless we make sure they can't be used against us.
"no operating system has ever come back from the grave" :)
I wasn't aware of that, but that's a good thing to hear. That means Windoze won't come back from the grave either. It died nearly a year ago.
Luke-Jr
Come on, kids. It's not the 80s anymore (though, I'm willing to bet the guys at AT&T Research labs aren't kids, and they actually might remember when /etc was the best place to put those things... but it's not anymore... especially not on freebsd!
Bellovin came out with this a while ago. It's an interesting concept, but has the following practical drawbacks:
1. All the various vendors would have to implement it.
2. False positives. A new form of DoS would be to generate enough spoofed traffic to trigger this sort of thing -aimed at someone else-. Imagine your outrage when your l33t IRC buddies spoof your IP address block whilst attacking www.slashdot.com - no more imbecilic, outdated "Gee, whiz!" types of posts for you to read.
3. Oftentimes, rate-limiting via CAR, traffic shaping, or other methods consumes more CPU cycles on the routers than simply blocking the offending traffic (assuming this is possible, which depends upon the attack methodology).
The best way to combat DoS attacks generally is use strong platforms which process ACLs and other features in hardware (ensuring that your config allows those features to be processed in hardware; logging ACLs like a 'deny ip any any log' just won't cut it, these days), ensure you have the ability to 'draw off the poison' by sinkholing traffic headed for the destination by advertising a null route for it on a sinkhole router (this isn't always possible, it depends upon the target of the attck; you may not want to sinkhole all requests to your Web server, for example), ensure you have as good a traffic sniffing/IDS-type capability as possible, make use of Netflow tools like CAIDA cflowd/OSU flow-tools/Flowscan/Panoptiis/FLAVIO/Arbor Networks' Peakflow DoS, and know how to get in touch with the folks at your ISP(s) who can help with identifying the (even spoofed, via Netflow tracing) sources and blocking the offending traffic upstream of you.
If you're a commercial site, strongly consider a distributed Web site, hosted at different locations and using some sort of Global Server Load Balancing technology (GSLB; Cisco's Distributed Director and 4480 are two examples of this) to send people to different sites depending up their location, network topology-wise.
I wonder when the LinPushbackd, GNU Pushbackd and PHPMyPushbackd projects will appear on SF.
excuse me if I'm wrong, but my understanding of the matter was, that source address spoofing etc. would be gone, once ipv6 is widely used. asfaik, ipv6 would prevent lots of techniques in this context, so why waste lots of emergy/work on this, instead of actually getting people to switch to ipv6.
ipv6 has been around for some time now and is implemented in every major os (both client and server). I know that the switch to ipv6 is a big task, but the way I understand it, it would also deal with a lot of problems (including to a certain extent ddos) in context with ipv4.
please correct me if I'm wrong.
If they forge the send from info wouldnt that make this idea sort of useless?
Might even reverseDOS innocent people.. id be pretty upset if that happened to me.. I might even sue if i lost revenue..
---- Booth was a patriot ----
in a press release by the Office of Homeland Defense, it was announced that an insidious plot by hacker terrorists had been thwarted. It seems that this subversive web site, www.slashdot.org, would trigger random DDOS attacks on targets identified on their web site. It has yet to be ascertained what their intent was, as no logical pattern has been detected. The investigation continues.
Welcome to the Twilight Zone.
I certainly hope the filters used to detect true DDOS attacks are effective enough to prevent this scenario.
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 :)
Underpants is where it's at
My firewall blocks all incoming ICMP except a few select types. Quench is not one of them. It could conceivably be used against you, so I block it. Why wouldn't the guys who write the scripts for the kiddies make changes to their code so that zombie machines ignore source quench ICMP?
I'm not sure how effective source quench is against routers in the path of a zombie host.
What if the script kiddies attacked their targets with loads of source quench packets? Can you source quench a source quench attack? :)
A DDoS attack usually involves unwilling or unknowing participants. This technology will do little more than knock out a few innocent computers and cause havoc at the ISP's when people are demanding to know why their "internet broke"
... Governments are instituted among Men, deriving their just Powers from the Consent of the Governed...
An effective solution has to identify the source nodes causing the trouble and block them, not the target. This is hard, but not impossible. The big problem is doing it for fake source IP addresses.
It may be necessary to view routing the way we now have to view mail forwarding - open relays get blocked. If a router isn't sure of the IP addresses of its input, it shouldn't be forwarding those packets. Routers that continue to do so may find themselves blocked.
Well the guy's doing the DOS have a 'tracer'...now the 'good guys' have jus come up with a trace busta...so now when the 'good guys' are tracing your shit, you need a trace busta busta...
In a DDoS the flood is coming from helpless slobs all over the net who didn't start it and are unaware. You're going to roundtrip that garbage traffic across the net a second time for even more congestion, and then push it at the client sending it?
If they do it right it may help a small amount in awareness, but the real answer to DDoS is that there's no good answer in the current Internet. Just like Curious Yellow, the only good answer is that OS vendors change their ways very soon and get security together, so that breakins are infrequent and require intelligent effort, as opposed to todays world of a 3-month old script off the net easily seizing 100,000 machines.
11*43+456^2
If the aggregate is "All TCP traffic from all sources directed at random addresses in a subnet" such as a smart DDOS program could easily generate, you would be fucked ... you can quench it anywhere you want, but you would just be DOSing yourself.
Until they put in a mechanism to traceback spoofed packets upstream and block them at the source nothing will help.
That or make egress filtering and a given level of security mandatory for the right to route traffic onto the internet. Those few people with their exotic spoofing VPN style network accesses are not enough of a reason to put up with spoofing IMO. The majority of spoofed traffic is used for DOS attacks.
who else thought this was hilarious? why the heck doesnt it have a million replies? *shrug*
-- touched by an angel....'s dinger
This reminds me of Gibson's 'Black Ice'... :)
:-)
I wonder when we will start seeing automated retaliatory attacks on DDos'ers and other hacking attempts... Just think: An automated scan of the remote hostile system(s) and then sending pre-programmed attacks to those computers determined by those port scans.
If the RIAA can get away with attacking servers who are sharing copyrighted content, then couldn't a company retaliate in the same way against machines who are attacking their servers?
Could make for some interesting wars
-- 7 string electric violin + live loop samplers
This sounds like Steve Gibson's suggestion from gibson research.
I wrote a paper in a similar vein last spring about stopping ddos attacks, it's the second section of this paper. It seeks to fix the underlying problem, not create a band-aid.
A properly DDOS'd router or network doesn't have the queue space to deal with control packets. Most likely they will be dropped just like the DOS'ing packets. I don't think RED ( common queueing algorithm ) differenciates between types of packets. Some sort of QOS based algorithm would be needed to ensure that control packets get highest queueing priority. But then that QOS algorithm has to be installed and working in the entire network which isn't likely.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
Most of the reasons why have been said before but to sum it up...
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.
"I am root. Bow before me." To this I say, "You are root, and you bear the sins of the world upon your shoulders."
How would this deal against spoofed ip's?
The script kiddy would just have to send spoofed ip packets to the server with Pushback installed with an ip address of a server they want to hack. Spread this out over a number of large number compromised zombie machines, against a large number of high-bandwidthed Pushback servers, and know that their actual target is being DDOS'd by Amazon, Yahoo, Microsoft etc. etc. etc.
-- 7 string electric violin + live loop samplers
Call me simple or old fashioned, however, I have an intrinsic distaste for technical solutions that require intermediate system to do real time monitoring of packet flows. Even if you are using some type of stochastic sampling, this type of implementation is still going to have a significant effect on forwarding performance. Its worth noting that 99% of all the routers out there do NOT support basic IP options. For all intents and purposes, options such as "Source Quench" or "Source Route" or "Record Route" are theoretical constructs. They are not enabled or supported in the control/management plane.
I've always been a proponent of big dumb pipes and inteligent end nodes. I probably always will be. The overhead associated with supporting intelligent intermediate nodes is simply too high.
Richard
Why not just introduce some "hard" method of trace routing? Instead of an after-the-fact hack (like the current traceroute), why not design it so you can connect to a router and ask it which router data destined for you is coming from? Do it for each one and follow the chain right up to the doorstop on the other computer.
Doesn't stop DoS itself, but makes only Distributed DoS keep you "anonymous", and even then allows the infected machines to be identified and the owners notified...
There is no protocol in place to find the true originator of packets.
This is simple to fix. DDoS works because there are so many packets sent that they cannot be responded to. I say just have the router blackhole the packets. This /etc/pushbackd is nothing more than a glorified ACL. The more ACls on the router cards the more the router has to work to check. A router could be programmed to sense too many SYNs and if it canot ACK responsibly, then it just blackholes the traffic for a specified period of time... kind of like the password gone wrong. Some apps, if you fat-finger your password more than a certain amount of times, simply forbid you to attempt to login again for a specified amount of time. The logs would show the attempting IP address(es) and you could simply investigate. This goes to show that you have to have humans at most points along the way in IT. We cannot automate everything, try as we might.
I know of one great way to stop DDOS kiddies and spammers : make it a capital offence. When we start shooting their brains out on national TV, I think they'll seriously think about a career change.
-Billco, Fnarg.com
That is incorrect.
DDOSers must be shovebackd.
They must go down the stairs.
XXXVI: ... gets eaten.
The thickness of the proposal required to win a multimillion dollar
contract is about one millimeter per million dollars. If all the
proposals conforming to this standard were piled on top of each other
at the bottom of the Grand Canyon it would probably be a good idea.
XXXVII:
Ninety percent of the time things will turn out worse than you expect.
The other 10 percent of the time you had no right to expect so much.
XXXVIII:
The early bird gets the worm.
The early worm
XXXIX:
Never promise to complete any project within six months of the end of
the year -- in either direction.
XL:
Most projects start out slowly -- and then sort of taper off.
-- Norman Augustine
- this post brought to you by the Automated Last Post Generator...