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

Comments

Problem?

[prichardson]

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.

Couldnt pushback be a Dos tool in itslf?

[Anonymous Coward]

If pushback is subverted, couldnt it function like an inverse DOD tool?

Re:Couldnt pushback be a Dos tool in itslf?

[xenocide2]

What he means is that pushback is a form of muting a computer. Pushback just sends the filters upstream to stop the saturation of the line. If this mechanism is vulnerable in some form that is universal or at least common then you could subjugate the filtering mechanism to mute a target upstream. Don't like GRC? Hack a pushback capable router and tell it to drop all send packets from GRC.

sure

[bicho]

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.

Re:sure

[garcia]

educate people who are getting infected? Come on. Your not serious...

These people think that when they install virus scan software they are safe. I recently re-installed Windows on my gf's computer. She had V-Shield on there from 1999. She had no idea that she would need to update it.

At least my roommate, my parents, and my gf know (from me) not to open attachments. But educate a WIDE group of people? That's just not going to happen and you know it.

Re:sure

[Anonymous Coward]

that has to be one of the least constructive, head in the sand arguments I've ever read. Did you read the article ?

The technique is about making the internet move the point of dropping the flood packets, BACK closer to the source. That is, remove the flood from the internet itself, and contain it into the localised areas.

Instead of expecting the impossible as you suggest, (which is joe-average running a secure system), finally someone is thinking about securing the internet in general from unsecured systems, which is a pragmatic approach which may well protect the internet in general from many unforeseen DDOS attacks, as well as the ones we know about.

Re:sure

[Doug Neal]

How is this design proposing to saturate the Internet?

It involves sending a short message back to the routers that are routing the packets to you asking them to "quench" - i.e. filter out and don't route - the offending upstream sources.

The message could propagate as far back as the individual ISPs from which the packets are originating from so that each participant in the attack is cut off.

At least that's what I'm getting from the summary of the story, I could be completely wrong.

Re:sure

[irc.goatse.cx troll]

Not all denial of service is saturation.
What happens when i spoof that you just DoSed your favorite website? You get cut off from it, and denied service.

Although as far as taking advantage of this sort of thing goes, I'd much rather be able to use an ICMP Redirect to make a DoSnet packet its owner.

Re:sure

[Anonymous Coward]

So what kind of authentication is taking place between routers and the pushback daemon? Why couldn't I just create a denial of service by claiming that someone is denying me, therefore causing them to get shut down?

Re:sure

[irc.goatse.cx troll]

Yes, because no one is so unethical that they would specify your ip address as the source instead of theirs.

The only thing to slow this down is checking routes, but even that can be gotten around (they just have to be on your network, thats not hard for colo's, shells, and most other providers)

Re:Manual RegEx?

[Bill Wong]

DDoS is usually bandwitdh consumption...
Even if you drop 100% of the evil packets...
Your pipe is still filled...

And for the amount of traffic needed to actually DDoS a large-enough site like Yahoo (4 gbps last time around?), RegExs wouldn't be helpful
since, the sheer amount of cpu required to process *every*single*packet*that*passes*through* is wayy too much...

not all DDoS attacks..

[Anonymous Coward]

Not all DDoS attacks are bandwidth based, they could be application level and targeted at all sorts of other resources.

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 .. it would be nice if these actions could be initiated in other situations also.

Never the less, this is a promising initiative.

--Iain

Question....

[jwilcox154]

How does it prevent a Server from being Slashdotted?

This is worse

[greenrom]

What the paper suggests is that if a router is getting way too many packets to a specific destination address, it will tell the routers upstream to throttle packets to that destination address (drop a certain percentage of them).

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.

Re:This is worse

[Anonymous Coward]

If you read the post it is clearly pointed out that the objective is to prevent the DoS from affecting other services carried on the same network link.

There is no clear way to differentiate some forms of DDoS attacks from legitimate traffic or a traffic spike .. so you have to concede that the attacker has won that battle and interrupted their targetted service, the next step needs to be harm minimisation.

The pushback idea provides a generic method for notifying/instructing upstream carriers to drop a certain aggregate traffic flow and notify the destination of what affect that limiting is having so they can determine when to resume normal operation.

In the mean time though, you have prevented a DDoS that may be targeted at a single machine from affecting the entire network.

--Iain

Re:This is worse

[dubious9]

If you root a webserver chances are that you want people to see the changes that you make to it. Once you have control of the machine you can do much worse things than DOS it.

Besides it is much harder to break into a well protected machine, than to break into a couple of thousand nearly unprotected ones.

I have a simpler solution

[Anonymous Coward]

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.

blocking packets with forged return addresses

[wfmcwalter]

Perhaps someone more network-literate than I can answer this DDoS question, which has bothered me for some time.

I believe most DDoS attacks have the following in common:

1. 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.
2. 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?

Re:blocking packets with forged return addresses

[swb]

"Good" networks prevent forged packets by doing what you suggest, dropping packets with bogus source addresses at the edge of the network or at appropriate ingress points.

I think the argument that is made for not doing this at a lot of ISPs is that with most Cisco routers its expensive as a lot of their routers can't fast switch with ACLs applied, they process switch, turning an adequate router into an inadequate packet-dropper.

It can also be a PITA to maintain -- if you put it at the very edge, like on an ISPs peering router with their upstream, it doesn't prevent in-block spoofing (eg, spoofing packets within the ISPs block). If you try to beat that on all the aggregation routers, you have a lot of ACLs to maintain; customer churn could put address blocks all over the place.

I'd argue that ISPs should make it a term of service that *their* customers ACL their edge routers; we-catch-spoofing-we-cut-you-off language.

You're talking about DoS attacks

[Subcarrier]

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.

A perfect tool for doing DDoS....

[wuchang]

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.

Re:Old Idea

[Cato]

A BGP feed will only help if you want to drop ALL traffic to a given IP prefix - the ACC proposal actually lets you limit traffic by port number as well.

Also, a BGP-only solution would only let you drop traffic, so it's not very useful for flash crowds, where the traffic is legitimate but excessive. It's also not useful where the port / prefix etc can't precisely identify only DDoS traffic - rate limiting allows some good traffic to get through while also limiting the DDoS. Blackholing != limiting (did you read the paper at all?)

I agree that this can be prototyped using existing technology (see my post elsewhere), but if this approach proves useful, a dedicated protocol would be helpful - though this could perhaps be piggybacked onto BGP using additional attributes to carry the filter and rate limit information.

Flaws in this proposal

[Animats]

This is a promising idea, but not totally effective. It protects the network, not the destination. The current implementation effectively blocks all inbound traffic for a given IP address. This kicks the target IP address off the net, which in itself is a denial of service. This approach could even make an attack against a host more effective, by shutting off all its incoming traffic. It just limits the collateral damage of denial of service attacks. This makes sense from the telco perspective (note that it's from AT&T), but not from the hosting service perspective.

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.

Ugh

[richard_willey]

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