Firewalls Make DDoS Attacks Worse
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."
Short on specifics.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
The article says that poorly deployed firewalls and IPS systems create a single point of failure.
Hacker says that firewalls are bad, so don't use them.
"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.
Arbor Networks, the people who did this "study", sell DDoS solutions. Of course they're going to say that anything you do other than pay them to provide your solution is a bad idea.
Yeah, poorly configured and managed firewalls can't handle a big DDoS attack. Duh, neither could a poorly configured server of any kind (eg. web server or whatever).
Nothing to see here.
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.
I am literally 3000 tokens away from the chaotic crossbow --Stephen
We're forced to deploy "legacy" network firewalls by standards (such as the PCI DSS) or regulations (such as MA 201CMR1700). If you are confronted with an auditor without imagination your compensating controls are misunderstood and findings ensue.
be taken offline by a DDOS or have your web server compromised by an exploit that has unfettered access to it? A DDOS will only cost me revenue while I'm not available. Having my server hacked will cost me downtime AND recovery costs. A real security person would take a risk based approach. In this case, the risk to other damages (i.e. server compromise, theft of credit cards, loss of customer confidence) is much higher than the risk of being down due to DDOS. I think Arbor are now making it onto my list of companies to avoid.
Do really dense people warp space more than others?
Also don't build taller walls, because it just encourages attackers to bring taller ladders.
Firewalls are a waste of time. I just disabled mine and am ready for some smoo
What's lacking here is a really good idea to cope with DDOS attacks. D.J. Bernstein, whose technical expertise cannot be doubted as much as his sanity can, suggested simply replying with an 'ack' in a dos attack. Effectively you have some daemon there who realizes "We can't handle this" and says "Plan B: just send an ack and forget it" As you work through the backlog of requests, sanity can be restored, and people can then access until plan B is needed again. It is temporarily conceding DOS, But if you don't, the system will go under. It's like the lines from 'Slattery's Mounted Fut' (by Percy French) You prefer the soldier's maxim when desisting from the strife, Best be a coward for 5 minutes than a dead man all your life!
I believe that an underspec'd firewall is most likely what they are referring to. Many people purchase firewalls based off of their raw bandwidth capacity. If you have an OC-12 ATM uplink to your ISP, basic logic used to suggest that you made sure that your firewall has at least an OC-12 or GigE port on the untrusted side.
But how many TCP SYN init packets can it parse per second? How many TCP connections can it handle before it runs out of memory? Does it treat embryonic connections different from a reaping standpoint than established connections? How many HTTP commands can it parse per second? All of a sudden, you have a lot more to worry about than bps throughput. You need to know the peak numbers of each in case you get slapped with a DoS attack.
Suddenly, that inexpensive 1Gbps firewall may not be enough. You might need to get a higher-end model, or you might need to bring in a Citrix or F5 load-balancer and spread the load.
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 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.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
4096R/EF7BAFA6 79E1 DF98 D09D 898F 9A11 F6F0 DDDC 23FA EF7B AFA6
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.
Not a typewriter