Firewalls Make DDoS Attacks Worse 217
jfruhlinger writes "Firewalls are an important part of any network setup — but if you put them in front of your Web servers, they become a single point of failure in the event of a DDoS attack. "Folks do it because they have been programmed to do it," says one security expert, but he urges you to avoid this setup at all costs."
What a useless article (Score:5, Informative)
"People are deploying firewalls wrong", some company says. "We're not going to say anything other than that", some journalist adds. "Particularly we're not going to mention where and how said company thinks firewalls should be deployed. We're just going to refer to some report they published a few times, but we won't link to it". When asked what the hell kind of point they were trying to make the journalist hummed and hawed a few times before admitting that he wasn't entirely sure. "Firewalls can be bottlenecks when experiencing DDoS attacks", the company's solutions architect insisted, making a rather obvious point.
useless article (Score:5, Informative)
I'm somewhere between novice and expert with firewalls on large networks, and this article says absolutely nothing that makes sense to me. The author posits that a firewall in front of a server is just a new bottleneck. Really? In what way?
General consensus on security-oriented forums seems to be that a DDOS is effective because it fills your internet pipe. If my firewall is a bottleneck, then it's either too weak for the pipe it's deployed on, or it's trying to do something stupid with packets that arrive there, and drowning as a result.
That, or this is all way over my head, in which case the author of the article has failed to reach a reasonably savvy audience.
Re:useless article (Score:5, Informative)
No, it's not way over your head. Your simplistic explanations of things are right on the money there. If a firewall was a chokepoint, you're doing the wrong type of filtering, you've got not enough muscle for the pipe you're serving the firewall for, or similar. It's not a "new" chokepoint for DDoSes- the goal's to choke off the pipe however you can. Putting it on the outside of a firewall's stupid for other reasons and doesn't keep the webserver from being an attack point or the pipe really being the choke point that's attacked by a DDoS. If your firewall's a problem, it's because it's not sized correctly or you've misconfigured it.
Programmed to do it... (Score:5, Informative)
Misconfigured IPS systems are often easily abused to launch a DoS, for instance many will block an IP address which appears to be doing a syn scan, yet such scans are trivially spoofed - spoof the scans from other addresses and the IPS will dutifully block them.
As for firewalls, people are generally conditioned that a firewall is required, and in many cases end up relying entirely on the firewall (eg a device will have lots of listening ports open which dont need to be, and which are only inaccessible from the internet because of a firewall. It's extremely common to find a network with little apparently open from the outside because of a firewall, but once you get inside everything is wide open and trivially exploitable. All you need is one hole in a service which is permitted through the firewall, and the rest of the network falls easily.
A firewall should only be a SMALL component in a defence in depth strategy, your web servers should only have the services they need open, everything else closed and then the firewall should be a second line of defence which allows the same ports (since you need them), it shouldn't actually be blocking anything under normal circumstances but rather is there to provide a second barrier and point of logging incase someone does compromise the server and tries to open up additional ports or send traffic out. If the servers are only listening on the services they need (and which by definition the firewall must allow anyway) then being behind the firewall doesn't really provide you much benefit as a hacker.
In terms of DDoS, well it depends on the type of attack.
A raw packet attack, where you seek to swamp the target with more traffic than it can handle is often much easier if a firewall is involved, especially a stateful one. For each packet thats received, the firewall must process the interrupt on the outside network card, read the packet headers and process them against its ruleset, and then if the packet is allowed (which it probably will be, since most ddos attacks will focus on actual service ports) relate it to an existing state table or create a new entry, perform any necessary packet mangling such as nat translation and finally forward the packet on through the internal interface. All of this uses CPU, memory and bus bandwidth before it even hits the actual server.
Then look at the hardware that goes in to firewalls, take Cisco as an example... Their current firewalls are linux based (most commercial firewalls are linux or bsd based), and run on generic x86 hardware... According to http://en.wikipedia.org/wiki/Cisco_ASA [wikipedia.org] even the most modern ASA firewalls are of a relatively modest spec, meaning that their ability to handle traffic is likely to be less than the servers behind it before even taking into account the additional load of having to do ruleset, state lookups, nat and forward the traffic back out again.
If you won't put a server on the internet without a firewall, what is the firewall itself? Most firewalls are just relatively lowend servers, running linux or bsd... What makes a cisco asa safer than a normal linux box? You allow the services you need through the firewall anyway, so the additional risk of not having a firewall and a properly configured server is very low, no extra services are really exposed but you are increasing performance and decreasing costs.
Re:Arbor Networks (Score:4, Informative)
Nothing you can afford can handle a "Big DDOS attack".
And most of us don't remotely need our servers to withstand a "big DDOS attack". It's like saying, "The security in your home can't keep out a world-class catburglar." Well that's true. It's true that we can't afford that kind of security, and it's also true that we don't need that kind of security.
Your security really only needs to be able to withstand the kind of attacks that you're likely to encounter. For most of us, that's only the most casual of attacks. Many sites are more likely to be taken offline by being slashdotted than being purposefully attacked.
What they mean (Score:5, Informative)
The problem with *stateful* firewalls in front of servers is that you can DoS the link without coming *close* to using all of the bandwidth. The state table has a finite size, and it doesn't take many packets per second to fill it up, depending on how long it takes for state entries to expire.
Additionally, since a server is there to handle unsolicited requests, there's not much point in tracking state anyway.
Stateless ACLs are what you want in front of a server, not a stateful firewall.
Re:Translation (Score:4, Informative)
If it's limited to no higher than layer 4 stateful firewalling, then its not going to get overloaded. Assuming there's no bugs being exploited by attackers (if there is, you're probably screwed anyway), then an old Pentium could easily handle enough traffic to saturate the link.
If it's going to higher layers, then things get interesting. I'm also skeptical of the utility of doing that for public-facing web sites.