Slashdot Mirror
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.
Poorly-designed firewalls make DDoS attacks worse.
FTFY
I've abandoned my search for truth; now I'm just looking for some useful delusions.
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!
STATEFUL firewalls are the problem. It makes no sense to put stateful firewalls in front of server farms. Any mechanism that tracks state is a DDoS intensifier. If you're running services on ports 80 and 443, put stateless ACLs on the edge routers, running in hardware, that are capable of line rate. That protects you against traffic on inappropriate ports without creating a stateful DDoS vector. If you need to mitigate application-layer attacks, do it on the servers with something like mod_security. That way you can distribute the attack across the server farm instead of running a stateful choke point that risks bringing your whole site down.
I found that I had someone from .br looking at my desktop. I have a local net set to share and the stupid linksys router shipped with the firewall turned off. Fortunately my linux local net is setup to see and report any access calls from non registered users. They can see or share public folders but cannot do squat without a pass key. You would think that routers would ship with the outside firewall turned on by default. But I guess that would really stump some home users that want to access their stuff remotely.
How a so called security expert can state that hardware firewalls are bad is beyond belief. I sure as hell do not want some goof ass from Brazil sitting there pinging away at my open ports all the time. Block em at the front end and they will give up and try someone else with some Windows cheese. Also it would make sense if you get in the habit of renewing your IP address, even with dhcp your current primary at the router can get stale and vulnerable to bot attack sniffers, mine did. You would think that a moving target is much less likely to be hit than one that sits there and looks like a static.
Stateful firewalls are usually bottlenecks when a DDOS-attack happends, because they do what they are supposed to do± keep a lot of state
But during DDOS-attacks there is just to much state for the firewall to handle.
New things are always on the horizon
Wow, POORLY designed system have issues under pressure. I can't believe it?!
This guy must be a highly paid consultant.
News Flash!!!!
Stop manufacturing castles that expose right angles and sharp corners to would be army's bringing siege engines with them!
Solution #1: Just open the freakin' gates and let down the ramp over the moat (solution provided by this article
Solution #2: Build your castles with all exposed surfaces along your walls and towers with curves and rounded facings - it's harder for the rocks to chunk away at you, and you're not bringing the battle to the inside of the castle like you are with Solution #1.
wtf is this article supposed to suggest?
What-Ev!
So foul a sky clears not without a storm - Shakespeare -
The article's conclusion is correct in a large scale environment, but it does not show any of the steps that get you there, or alternatives to putting everything behind a stateful firewall. Really, the thesis statement should have been "External facing servers should not be behind stateful firewalls".
In any large scale customer facing deployment, you have to leave a piece of the application facing the customers. However, you are best off limiting what is on that host (or hosts, as you are probably talking a load balanced solution) to just static content and calls to the application/database servers - which can and in many cases should be behind stateful firewalls. Protecting the customer facing box becomes an exercise in limiting attack scope - stateless router ACLs, hardening the box, and the like - things that protect against packet/session floods that may not fully saturate your actual bandwidth but could still cause a firewall to collapse under the number of new sessions that are being created/denied.
In short, make your external facing application be multi-tiered (preferably with redundancy) to achieve higher uptime and better resiliency against external threats. In my experience this model does seem to cause internal incompetency threats to break your application more often, however...
Don't put your web servers behind load balancers either, after all, the load balancer is another single point of failure.
Fire.
See it burning in the skies.
A deadly flame that nullifies.
Will the city stand or fall?
Fire.
See it burning in his eyes.
It's the flame that never dies.
Burning brighter than them all.
Like a fireball.
Which fate is his master?
Which path will he choose?
Success or disaster?
To win or to lose?
Guardian.
He's a hero to the end.
His code to mend and defend.
When evil stands to conquer all.
His only hope, a firewall.
A firewall.
A firewall.
A firewall!
Sorry, that doesn't work for everyone's business model. You say "avoid this setup at all costs" avoiding this setup could cost me my job... Not sure thats a cost I'm willing to risk!
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!
i'd rather have my firewall / NAT die -BEFORE- they get inside ...
it's like pulling up the bridge that goes over the moat, in front of the castle.
"don't want other people to reach me? sure you do reach me either"
I remember back in the day firewalls were about *logging* more than they were about security.
I guess I have trouble understanding the point of firewalls for public facing systems. If you can't configure the server to only expose the required services to the public a firewall is great but nowadays there really is no credible reason such configuration is not possible either directly in the server configuration file or with local firewalling rules.
IDS and various layer n scanning and proxy filters and the operating systems they run on top of are not immune to attack themselves. There have been a number of attacks specifically targeting IDS systems. By deploying unecessary systems you are growing additional branches on your systems threat tree.
At the end of the day the *application* you expose has to stand on its own. Systems without a brain don't have the capability to meaningfully understand higher layer interactions. A firewall will happily forward all non-cheesy app layer attack vectors. The only thing you gain is independant logging!! If you compromise a host you can compromise its logs but if there is a middle box doing the logging it is isolated from compromise.
For example many systems advertise protection against injection attack however nothing but the app can block an injection attack with 100% coverage and no false alarms (which can have adverse effects on legitimate use of a system) By definition there is no informational basis to obtain such knowledge.
The kicker is few seem to care much about their firewall logs these days..They keep them but don't really spend any time and energy reviewing them. All PPL are doing is checking the firewall box on their security checklists and moving on.
In my view the act of thinking that one is safe because they use a firewall is worse than not having a firewall.
I'm surprised at the level of ignorance displayed here on slashdot, well no I'm not but, still.
I'm perfectly willing to believe that best solution is unfirewalled webheads sporting two network cards, one internal for database and maintenance traffic, and one external with all ports blocked save http. Sure, why not?
I'm slightly more dubious when you claim it's worth all the extra man hours required for double cabling, insuring the iptables are configured correctly, etc.
Amazon E3 has thus far proved themselves DDoS proof. I'd spend the money on building the infrastructure for an emergency Amazon E3 scale up instead of worrying about firewalls.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
I think you're probably right about that, because the issue of stateful vs. stateless firewalls in front of servers is the kind of thing Roland Dobbins often talks about. There are lots of resources a DDOS attack can exploit, and if it's easier to flood the firewall than the servers or the pipe, then that's the target to hit - and stateful firewalls are really designed to protect clients, not servers. It's generally better to use stateless firewalls to take out most of the noise, and leave stateful checking to the servers which need to maintain state anyway.
On the other hand, the reporter did appear to understand the problem of "good guys make their systems tougher, bad guys make their attacks bigger, and botnets are really cheap these days so we're seeing a few 100Gbps attacks." (100 Gbps!! Wasn't that long ago that 1Gbps was big.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
to handle a fairly large DDoS attack. If a company has an enterprise-class router, they could just blackhole or nullroute the traffic. Blackhole routing is something alot of router guys know little to nothing about since they never really see the router as a security tool beyond ACLs.
I've seen blackhole routing do wonders against DDoS attacks.
Right cause all firewalls are configured to allow devices in the DMZ to initiate traffic to the net DOH! DOH DOH DOh DOh DOh Doh Doh Next thing, your going to say is that admins on your LAN which remote desktop to devices in the DMZ should be allowed to browse the internet from devices in the DMZ. If this doesnt strike YOU the reader as profane and wrong, you need to JUST PUT THE KEYBOARD DOWN and walk away, Doubble DOH!
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 a firewall can't handle the throughput of the Internet connection it is not the correct firewall for the job.
for computers that deliberately offer a server to the public. Do what you want to do with network topology, instead. If your computer offers a web server, why is it listening for anything other than HTTP requests on its public-facing interface? If its not listening for anything other than HTTP requests on its public-facing interface, what does the firewall do?
All's true that is mistrusted
If you've paid half a million for a firewall, you don't want to be told that your (essentially port-forwarding) loadbalancer behind it protects you at least as much as the firewall does, and also happens to eliminate the SPOF that your firewall itself actually is.
Yes, folks, you've just bought a 500k boondoggle because you were too stupid to understand how webservers and loadbalancers work. Well done, you win a cookie, you're now "upper management" stuff.
Eliminating the firewall in such cases WILL lead to better traffic throughput and stability, at the expense of not having "deep packet inspection" capabilities, which nobody in their right mind actually ever attempts to make sense of anyway.
If you have a single web server with no remote administration capabilities or logs then you don't need a firewall.
I surf the 'web from my Ubuntu box without a firewall.
But using a firewall means that you split the functionality between 2 devices. Each, ideally, customized to be better at its specific task.
Do I want remote admin capabilities but only from my private network? A firewall with a DMZ makes that easy.
Do I want to log all access but not risk those logs should the web server be cracked? A firewall makes that easy.
And even the "cheap" Cisco firewalls can easily handle any inbound traffic that the average user is likely to face.
I don't agree with the "expert" in that story. I'd say that using a firewall is a good idea. But ONLY using a firewall (bad server admin or not defense in depth) is the problem.
TLDR, etc - but let's just say you follow the advice to not use firewalls in front of your web servers. Those web servers aren't going to load balance themselves (at least, not short of old "www1"..."www16" DNS entries), so the next bottleneck becomes your load balancers. Admittedly, these do tend to perform MUCH better than firewalls, as their routing and inspection tends to be much simpler.
However, the common conception of lots of traffic hitting a bunch of web servers directly is not the right way to think about the problem.
I don't know what kind of crack I was on, but I suspect it was decaf.
Of course a firewall needs to be more powerful with regard to maximum traffic load as the servers it protects. But if it is, before the servers is exactly where it belongs.
IPS is a different story. Doing IPS right is very, very difficult. I would say it is an unsolved problem today. People making DDoS worse with IPS or even DoSin themselves is not unherad of.
But these two mechanisms need to be very carefully separated. They are fundamentally different.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Most brute force attacks are from a manageble number of addresses and/or subnets. Firewalls are a convenient place to ignore traffic from specific addresses. Obviously if you are dealing with highly distributed attacks, this won't entirely help and you're probably screwed no matter what. Having to configure many servers to ignore attacks from specific addresses is time consuming and difficult. You should always select a firewall that can handle as much traffic as your internet connection. Only ancient firewalls are a lot slower than typical internet connections. Finally, firewalls are really routers. The internet is made out of routers. Should we eliminate routers and therefore the internet? I say this is misleading nonsense, and I would be embarassed if someone from my company betrayed their ignorance this way. If brakes slow cars down, should we get rid of brakes?
Greed is the root of all evil.
I'm not really a huge security buff, but for many general purpose "web servers" a firewall is unnecessary. I don't run anything serious like "ecommerce" or a site like Slashdot that millions of people rely on, but my simple philosophy is to just not run (or expose to the internet interface) services that aren't needed. Filtering ports that nothing is listening on is pointless.
Speaking of security facilitating DOS attacks to cripple, I once helped a friend with his web server that was being DOS'd, slowed by extra i/o and having the hard drive filled up with logs. He had installed Port Sentry (1.x back then) to thwart and block port scanning hosts, and in its default configuration of "-sTCP -UDP" it doesn't take a full connect to trigger an action. Any knock on the door with Syn/Ack, or UDP to one of the trigger ports would add a rule to block that IP (ipchains) for a period of time and enable logging of future connection attempts.
Well... all it took was a spoofed SYN flood, that looked like it was coming from random IP addresses. The flood would have done zero harm had it not been for Port Sentry adding firewall rules and logging targets for every IP address that every packet appeared to come from.
His fault for not understanding how Port Sentry worked, but what a retarded "security" situation that was. Completely pointless, because there were no ports listening that we didn't want anyway. I laugh every time I think about that night. I figured out what was going on in a couple of minutes over a SSH session, but what made it even funnier was that even after I shut down Port Sentry the log entries kept coming seemingly forever because sysklogd was still writing them from buffers. Anyway, I killed syslogd, deleted the huge log files and touched new ones, edited port sentry to react only to full tcp connects (-tcp), disabled the creation of the logging rules, and sent the server down for a reboot and all was well. The SYN attack wasn't really enough to flood the link on its own.
Who says firewalls are a single point of failure? Ever heard of redundant firewalling?
Provides a possible minor annoyance to spyware, Trojans, etc that might try to start listening on a different port?
Not that a smart one wouldn't use some kind of outgoing connection to a proxy.
Perhaps the firewall is protecting, if only minorly, from accidental port openings during config changes or the occasional price of software that doesn't tell you it listens on a port. (idiot protection?)
ERROR: SIG NOT FOUND (A)bort, (R)etry, (F)ail?:
Do you trust the people who have access to the server?
Yes? Then they don't be doing anything stupid like browsing from the servers...
No? Are the people who run the servers also the same people who run the firewalls? If so, FAIL.
A server being able to connect out doesn't become a problem until that server gets compromised, which is not something you want to happen... Minimising what the attacker can do is one thing, but its only a minor gain in a niche case. Better to spend more effort on making sure the server doesn't get owned in the first place.
Also if you rely too much on the firewall (which MANY places do), sure your owned servers might not be able to connect out but can they connect to each other? A hacker might have a lot more fun owning all your other servers.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Put your firewalls and load balancers behind web server.
Or at least on the shelf below.
That is all.
What happened to the days when people stopped a DDoS at a router? You know, before it gets to your firewall?
The limited address space in IPv4 may affect a few kinds of attacks, but not many. This paper was pointing out 100 Gbps botnet attacks, and if you've got an ISP that allows outbound UDP packets that aren't from your IP address space, which too many sloppy ISPs still do, you can use a few billion IP addresses times ~60K ports, so it's not going to stop any practical-sized attacks that care about that. If your botnet attacks come from ISPs that don't let you impersonate other users, then you'll encounter defenses that block your /64 and probably your /56 or /48 (so you could get some of your neighbors blacklisted, I suppose.)
The main IPv6 vs. IPv4 DDOS attack is the boring one - some user in Asia can't get an IPv4 address when APNIC runs out this year, so he'll only be able to reach you through NAT, unless you've got your IPv6 working.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
for computers that deliberately offer a server to the public.
Do what you want to do with network topology, instead. If your computer offers a web server, why is it listening for anything other than HTTP requests on its public-facing interface?
If its not listening for anything other than HTTP requests on its public-facing interface, what does the firewall do?
It keeps your interface from being bombarded with useless data that fouls up the interface-facing network. This is or isn't a problem, depending on your deployment and configuration.
FTA:
They [firewalls] should not be placed in front of servers... In many cases, these devices became immediate bottlenecks in the face of DDoS.
In any computer system, some subsystem always acts as a performance bottleneck. If that bottleneck is removed, then the next slowest subsystem becomes the bottleneck.
In the case of TFA, this guy suggests that a firewall in front of a webserver might well be crushed under the load of a DDoS attack. If the firewall were not there, however, then the webserver itself would get crushed, or the load balancer, or whatever else was next in line to bear the brunt of the attack. When you're talking about attacks up to 100Gbps, something is going to clobbered.
The only defense is to drop packets like mad if, for example, too many are originating from one source, or are deliberately malformed, or look suspicious for some other reason. You know what's really good at that kind of job? Firewalls.
I don't know about you, but my outbound proxy requires authentication and uses content group based filtering. But anyway, among other things, a firewall filters outbound traffic. It also can be used to create a screened subnet that makes compromising hosts on a private network VASTLY more difficult. These days they also provide other features like vpn tunnel end points and intrusion detection.
That only applies if you have a single locked down box on the connection with nothing that can get through it.
If you have a gateway with a pile of stuff behind it you want to make sure that all the traffic passing through it does not cause trouble - for instance an infected machine sending out spam from inside your network can be blocked and you don't end up on spam block lists.
Not understanding how to use the tool does not make the tool bad. A setup of allow this, allow that, block the rest and who cares about logging after testing would not have run into the problem above.
Filtering ports is NOT pointless if somebody else will some day have the ability to log onto the thing and turn on stuff that should not be listening. I've seen people turn on telnet on internet facing machines because they didn't understand the difference between that and ssh.
If you want to see a really silly DOS try swatch to mail out everything unusual in log files and do something to the MTA that doesn't stop it but generates errors in the log every time it sends mail. It was amusing to see the aftermath of that. Once again it was not the tool but the way it was misused that caused the problem - simple excessive logging. I think it was my first year of University when I was warned of that by a guy that had been at the first C5 Galaxy flight tests and they had too much data to sift through to make any real time decisions as to whether it was safe to proceed.
Okay, fine; I'll put an IIS or apache webserver directly on the internet. Are you joking?
Seriously, a firewall can do much more than just limit the number of connections. They can block based on the number of connections per second or minute and add to an abusive-hosts list for further prevention. They can be configured with a reverse Squid proxy and block based on HTTP-REFERER or whatever else the attacker is dumb enough to leave as an identifier common to all packets. DDOS is loosely defined; whatever denies service is a denial-of-service attack, not just flooding a pipe with raw bandwidth.
I work at a webhosting company and we have all kinds of success with (properly) configured firewalls.
You're right that the article doesn't delve into the technical specifics - but the report the article is describing, available via this link provides more details.
The essence of the issue is that DDoS attacks are attacks against capacity and/or state. Even the largest firewalls commercially available or that one can build have limited state-table sizes.
Placing stateful firewalls in front of client access networks makes sense - when your Web browser requests the TCP/IP stack on your client device to set up a three-way TCP handshake with example.com, there's an outgoing SYN request which traverses the stateful firewall, and the stateful firewall makes a note of this in its state table. When the SYN-ACK response comes back from the example.com server, the stateful firewall checks to see if there's a corresponding outbound request and that the incoming response conforms with the firewall policies - if the answers to both questions is 'yes', then the firewall passes the server response packets. If the answer to either question is 'no', the stateful firewall drops the inappropriate server response.
When we're talking about Web servers, DNS servers, et. al., however, basically every incoming request is unsolicited - therefore, there is no state to inspect. This is why it makes zero sense to put a stateful firewall in front of servers.
Instead, the server OS and apps (Apache, BIND, sendmail, whatever) should be hardened, tcpwrappers should be deployed on the server to provide onboard stateless policy filtering, and stateless Access Control Lists (ACLs) should be implemented on your hardware-based routers and/or layer-3 switches in order to enforce network access policy - e.g., allow TCP/80 and TCP/443 for a standard SSL-enabled Web server, allow UDP/53 and TCP/53 for a DNS server, etc., and then disallow anything else from the outside.
Here's a .pdf presentation from a recent NANOG conference which makes the same point.
When stateful firewalls are used to enforce these polices which ought to be enforced by stateless ACLs per the above, the state-table limitations of even the largest firewalls form a significant DDoS chokepoint. Attackers can craft well-formed attack traffic which will conform to the firewall rules, but which will 'crowd out' legitimate requests from users, and which in many cases causes an error condition on the stateful firewall which causes it to stop forwarding packets altogether. This leads to a DoS of the firewall itself and all the servers behind it.
I've seen this over and over and over again, even with very large firewalls. It's far easier to DoS the largest firewall in existence than it is to DoS well-tuned, hardened server TCP/IP stacks.
Servers should be protected from DDoS attacks via source-based remotely-triggered blackholes (S/RTBH), flowspec, and/or intelligent DDoS mitigation systems (IDMS) specifically designed for this application.
Load-balancers are also a DDoS state vector, but in many environments are a necessary evil. When they must be used (note that there are many ways to achieve clustering/load-balancing without making use of single-point load-balancers), they must be protected by the same stateless ACLs in terms of enforcing network access policy, and must furthermore be protected from DDoS by S/RTBH, flowspec, and/or IDMS.
'Application-layer firewalls', with their 'protocol inspectors', and so-called 'IPSes' are even worse. They carry even more state, and the protocol inspectors offer a broadened attack surface for exploitation and device compromise (you can find numerous examples of publicly-acknowledge buffer overflows, etc. which comprise security vulnerabilities in the inspectors of both commercial and open-source firewalls and 'IPSes'). Consequently, they fall over during even a moderate DDoS attack even more qui
If you run Microsoft Products, there are numerous ports enabled by default, some of which (445 for example) which can not ever be disabled.
ROFL. The CAPTCHA was "herded". I swear to god these CAPTCHAs are prescient.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
I hope you realize amazon is a very strange protection against DDOS. Since on amazon you pay for the traffic you generate (/receive= $0.10 Gigagbyte). Your service keeps running, but the traffic that is generated makes easy a expensive exercise.
What tha? Normally... you often have an edge-router or switch before your firewall anyway, that connects to the physical layer (often fibre or gig copper). These will often get impacted first in terms of CPU under something like a typical SYN attack, trying to move packets, most firewalls are overspecced for that, and can amplify the problem by responding, but basically the damage is already done when the traffic arrives.
One company I worked at was the victim of a large-scale DDoS attack (not my doing, I promise!). There is simply nothing you can do in most cases except contact your up-link to drop traffic going to the specific IP. They chose a non-responsive (in this case unused IP) in the address range. They can hold you down for hours.
You can however sort out your net-block so that ranges of un-used IP's will not have traffic routed beforehand. Ok, you ask what is the possible advantage of this? Well you will then be able to detect the attack more easily as an active (monitored) IP will be hopefully involved rather than all this just being observed at a network level. You should also have an IDS in the mix somewhere. These simply enable you to identify that you are under attack, and allow you to respond quicker.
Carriers are finally getting a bit more serious about protecting their customers from attack and implementing upstream traffic analysis tools that will immediately show weird stuff like a billion SYN packets heading their way and help the network operator shut the route down. Due to the insidious nature of a DDoS of a massive bunch of zombie PCs out there on fat network links, there is not much else that can be done. (Although it would be nice if ISPs had to cut those off the wire until they fixed their spyware/trojan infection issues). Carriers are probably not going to act anyway, though until you tell them to.
In short DDoS's suck, and there is not much that can be done, particularly at an end user level. They can be commercially very damaging and are the scourge of the Internet.
"an old Pentium could easily handle enough traffic to saturate the link"
An old Pentium barely has the PCI bus bandwidth to saturate a 1Gig link, let alone do layer 4 analysis, firewalling, connection tracking, etc. And just how much memory do you have on that old Pentium for state tables?
Well, I don't deal with the networking or hardware very often, but I can recall meetings with the server admins and network talking about the setup of applications I manage/program. The firewall did many things beyond ACL-like duties.
For one, it is set to stop responding to IP's that send too many requests per second. It also has packet inspection that looks for known packet tricks that ddos'ers and other black hats use and will reject those. I don't remember everything, but I seem to recall it was a pretty long list of benefits. I suppose one could argue that that list of benefits isn't "firewalling", and I suppose you'd be correct. But most modern expensive firewalls come with all those features, and should probably be classified as 'network security devices' over the old name 'firewall'.