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."

My take

[bobetov]

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.

Re:Problem?

[thefalconer]

Yes, but this would also stop most typical script kiddies. Those are the most malicious ones. Lack of maturity combined with lots of "god complex" tend to cause them to do far more damage than a typical hacker/ddos'er. So if you shut them down or reverse dos them, then they get a taste of their own medicine and you get to laugh while they're trying to figure out why their system just took a dive. :)

Can this be right?

[rocjoe71]

This sounds like innovation and that just can't happen on non-M$ operating systems, can it?

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.

Re:Question....

[Big Mark]

Pushback will ensure that when the /. effect happens, the server isn't overloaded by dropping connections enroute to the server rather than at the server itself.

I wonder what impact the pushback overhead will have when a server gets slashdotted, though. What if the pushback message gets dropped due to swamped routers?

Re:My take

[Subcarrier]

Sounds like a pretty v1.0 idea at this stage

I have to agree. They leave a lot of issues for further study. One big problem seems to be that gigabit backbone routers don't really have time to do any of this stuff. It's not much use if the back plate packet rate drops to one quarter because of having to detect and deal with flow aggregates.

Re:another idea...

[Shishak]

There is a perfect, 100% sure way of stopping spoofed IP's. It is very easy, non-resource intensive and not being used by lazy network admins.

On every edge router you simply need to put an access-list to drop all packets not coming from your netblocks.

Edge routers going to customers you drop incoming packets not coming from your customer assigned IP. Amost EVERY edge device supports this, most support dynamic filters with RADIUS resquests. If you only allow your customers to send you data from their IP address it is impossible for them to be part of a spoofed attack.

Pushback simply moves the problem

[The Moving Shadow]

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.

Um, this isn't new.

[Mordant]

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.

Re:not all DDoS attacks..

[smallfries]

These tend to all follow the pattern that you are exhausting the cpu of the target rather than its network pipe. Newer network protocols already have protection for this by making it more expensive for the client initiating the connection rather than the server receiving it. SCTP has this in place already with a crypto-based cookie puzzle to prevent SYN bombs (similar approach would work for dns too). The other question is when (or rather if) newer protocols like these will eventually replace TCP with all of its inherent problems or if the inertia (but everybody knows TCP...) of the current protocols will kill them off first.

Re:This is worse

[Anonymous Coward]

No, it throttles packets based on whatever is common to a majority of the packets. So, if a website suddenly gets a huge number of requests for /index.html, it can throttle those and let requests for another page through unhindered. If a web server gets a huge number of identically formed packets, it can throttle those and let differently formed packets through unhindered.

You are correct when you say it shifts the site where the packets are dropped. However, you miss the whole point. The site's router determines a pattern common to an attack, and tells the routers upstream the pattern. Those routers tell their upstream routers the pattern, etc. Alone, the site's router might be overloaded. The routers two levels upstream might all be just about overloaded, but still able to let through all non-attacking traffic. If these routers all begin throttling, the site's router will no longer be overloaded. All nonattacking packets will be let through unhindered. All attacking packets will be throttled severely. If the attack picks up and the second-level-upstream routers can't handle it, they will pushback to the third-level-upstream routers, etc.

At least, that's how I understood it.

Heh heh

[tuxlove]

What if the script kiddies attacked their targets with loads of source quench packets? Can you source quench a source quench attack? :)

try this

[trybywrench]

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.

Re:finally... a cure for Slashdotting...

[AJWM]

The term "flash crowd" goes back waaay before Slashdot ever existed (1973). It was coined by Larry Niven in a short story of that name (concerning *actual* crowds in an era where teleport booths are as ubiquitous as phone booths).

Re:Couldnt pushback be a Dos tool in itslf?

[swillden]

No because it means stop sending. To the network this stops the flood of packets.

Yes but if the system can be fooled into quenching legitimate requests then service has still been denied. I mean, to a user, does it matter if you can't get to the server because it's overloaded, or you can't get to the server because the routers are telling your machine to stop sending? Either way, all you know is that the blasted server is down.

Re:hey

[Anonymous Coward]

I just had a crazy idea. Lets say some enterprising script kiddie wants to shut off the internet. All he would need to do, after this daemon was implemented, is unleash his latest VB virus that spoofs a range of IP's. One day these infected computers would communicate among themselves to determine which blocks to spoof. Then, like the Michaelangelo virus, strike on the same day, spoofing every IP in existence and some that aren't in a dos attack from a couple million computers. After all the IP's are spoffed, those that have been attacked retaliate, only making the DOS worse. By the time it is all done, every router has blocked every IP in existence, effectively shutting off the internet. One big off switch, that is what this is. :-)

This sounds like the Tim Allen sort of way to do it. "Why don't we just throw it against the wall and save you the trouble?"

Food for thought.