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."
Long on Rhetoric (Score:5, Insightful)
Short on specifics.
Re: (Score:3)
Exactly, there is no hard evidence that would convince anyone technical in that article. Waste.
Re:Long on Rhetoric (Score:4, Funny)
Short on specifics.
So I did not miss anything by not RTFA?
Re:Long on Rhetoric (Score:5, Insightful)
Looks like it. Single point of failure in a DDoS? If they choke your inbound pipe (the very definition of a DDoS...) having it on a DMZ or unprotected will not help prevent things from crushing your connectivitiy. In many cases, the Firewall can actually handle higher transaction traffic than the webserver can. If you're doing a load-balanced setup, he might be right, but that's not the premise he apparenly lead with.
Re: (Score:2)
Agreed... this article doesn't really say anything that is interesting and the article summary may just be making much about a quote taken out of context or that is incomplete...
Re: (Score:2)
Depends, many (commercial) firewalls (Barracuda, SonicWall, CheckPoint, low-end Cisco...) are basically Linux/BSD with IPTables/IPFW on very cheap hardware (think Celeron, Atom even ARM) in order to reduce it's heat signature in the datacenter. When you put a single one of those in front of a rack of 2.66GHz 8-core Xeon's it's not surprising that with a lot of open connections, the firewall goes out of resources first especially when you're only serving static or cached content.
So why should you put one of
Re: (Score:2)
It depends on what you're doing. Our firewalls run on a hardened BSD platform, are application proxy firewalls (rejecting anything that doesn't match the protocol), and can handle 5Gbps or more. Our external pipe isn't that big, peaking at 1Gbps for bursts (subscribed is well below that), so we run out of pipe before we cap the firewall's raw throughput.
Placing the servers behind the firewall, though, gives you other aspects of security, including logging (some better than others), single-point alerts, an
Re: (Score:3)
I'm a little curious what enterprise level firewalls you've dealt with if you're saying that firewalls are built on low end hardware. I know the E-Class Sonicwalls can handle a million simultaneous connections individually and you can load balance them to achieve higher workloads. There is nothing low end about the hardware inside as the E6500 at least is running 16 cores which is about the same resources as a typical server these days only they are dedicated to the job at hand. The Sonicwalls at least also
Re: (Score:3)
So if ports 80 and 443 have less than 100% of the allocation, the firewall should pass the other ports on the remainder allocation without a hiccup.
A traffic shaper/firewall can only prioritise packets it sees. It can't do anything about packets that were already lost before they reached it.
In a typical setup you would have an external link coming in to your traffic shaper. In order for the traffic shaper to effectively shape incoming traffic it must be the bottleneck, You acheive that by deliberately setting the bandwidth out o your traffic shaper marginally lower than the bandwidth of the incoming link. You waste a little bandwidth that way but it's
Re: (Score:2)
Yes. You missed the Ads!
Re: (Score:2)
Well, a firewall is a single point of control, so it pretty much can't avoid being a single point of failure.
There doesn't seem to be anything surprising about what this guy is saying. Stateful firewalls are likely to fail under a DDOS attack because they keep track of connection requests until the table is full. Then everything behind the firewall is cut off. It's been years since I've done this kind of planning, but it certainly makes sense to make other security provisions for services that might attrac
Sounds right (Score:2)
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 checki
There are many kinds of attacks - ipv4/v6 is minor (Score:2)
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 de
Re: (Score:2)
Well, modern firewalls, and perhaps firewalls from the past, can generally count concurrent connections from a single source do some number crunching magic with the speed or rate of connections and simply drop packets from that source as an attack. Even the elcheapo sub $500 zywall's will do this automatically in a separate process if you have the item set.
I think a problem with some firewall setups might be where there is an actual reply like when rejecting a packet or returning a response of something. A
Re: (Score:3)
Short of specifics and common sense.
I dont care how you set it up, even if you set your webserver on another network you STILL firewall it. I think the article writer does not know what a firewall is.
I'm betting he is a CIO that thinks a firewall is a red box from Watchguard they pay too much for to get little in return (pfsense in a cheapie 1u dell server is better than ANY product they sell at Watchguard.)
Re: (Score:2)
I'm betting he is a CIO that thinks a firewall is a red box from Watchguard they pay too much for to get little in return (pfsense in a cheapie 1u dell server is better than ANY product they sell at Watchguard.)
I'd send my boss a link to your post but I already know it won't do any good :-(
Re: (Score:2)
I'm betting he is a CIO that thinks a firewall is a red box from Watchguard they pay too much for to get little in return (pfsense in a cheapie 1u dell server is better than ANY product they sell at Watchguard.)
What nonsense you foul mountebank! Every good CIO knows that a firewall is a wall of fire (hence the name you dolt) that keeps burglars and other brigands away from the server of datas!
Re: (Score:2)
Excuse me, I just dropped my token.. Can you check to see if it's under your desk?
Not laughing at you, laughing with you. Yes, CIO's can be more imaginative then a 3 year old.
Re: (Score:2)
Re: (Score:2)
If you put in non-stateful ACL's on a router or switch that does them in a hardware path in front of your web farm to filter anything other than port 80 then you can eliminate most of the cruft at line rate without giving the attacker a nice juicy state table to destroy.
This is common sense... Who then is installing stateful firewalls in front of a webserver farm? That's just amateur hour stuff.
umm, okay (Score:3)
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 themselv
Re: (Score:3)
Amazon E3 is probably fairly safe from DDoS because of redundancy and having multiple data centers each with their own internet connection. For a DDoS attack to work you need to have the targeted service existing at one point, so when you disable their only point of presence. When the service is actually spread across locations then you reduce the risk.
I wouldn't be surprised if the sites that are likely to come down first are either single location sites or stateful transactional servers, which are harder
Re: (Score:2)
Databases which take one wrong query will spew all of your data out like a teenager who drank too much rum and I will own whatever is there.
If you have web servers writing their own queries to run on your database servers then you deserve all the pain you're inevitably going to get.
Re:Long on Rhetoric (Score:4, Insightful)
Bad headline, too vague (Score:5, Interesting)
Re:Bad headline, too vague (Score:5, Insightful)
The article says that poorly deployed firewalls and IPS systems create a single point of failure.
So do poorly deployed network cables, or poorly deployed almost anything that hosts rely on to handle all their traffic (power solutions, switches, etc). By the definition of what a firewall is supposed to accomplish, a poorly deployed one obviously creates a lot of problems or provides little protection.
Also, water is wet.
Re: (Score:2)
Translation (Score:3)
FTFY
Comment removed (Score:5, Interesting)
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.
Hacker says (Score:5, Funny)
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.
Re: (Score:2)
Later, the journalist was heard asking a coworker, "What's a firewall? Do I also need a Fire Extinguisher if I already have a firewall?"
Re: (Score:2)
In this case would it not make more sense to have the firewalls behind the load balancer protecting each individual server? I am not a network expert.
Arbor Networks (Score:5, Insightful)
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.
Re:Arbor Networks (Score:5, Interesting)
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.
Nothing you can afford can handle a "Big DDOS attack".
No need to pick nits about how it is managed or configured.
Re: (Score:2)
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.
Nothing you can afford can handle a "Big DDOS attack".
No need to pick nits about how it is managed or configured.
Unless you use a CDN.
Re: (Score:2)
There's still that "you can afford" bit.....
You start getting DDosed and the bill from your CDN will send you into hiding.
Re: (Score:2)
Nothing you can afford can handle a "Big DDOS attack".
No need to pick nits about how it is managed or configured.
Which is why handling DDOS attacks should be left to those with the money and resources to handle it:
Your upstream provider
Re: (Score:2)
Nothing you can afford can handle a "Big DDOS attack". No need to pick nits about how it is managed or configured.
Which is why handling DDOS attacks should be left to those with the money and resources to handle it: Your upstream provider
Assuming the traffic is clogging the routes to your servers, yeah there's not a lot you can do about it if you have centralized servers instead of distributed server capabilities through Akamai or someone. Arbor makes products that can be used to mitigate attacks that don't saturate your bandwidth. They also make the products the upstream ISP uses to mitigate the attacks and prevent such saturation, if you buy a premium service from the ISP with DDoS protection. Last I saw they had a nice Web interface and
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.
Re: (Score:3)
YOU != Amazon
Re: (Score:3)
My condolences.
Re: (Score:3)
When DDOS attacks look like legitimate web hits, blackhole routing can only be used on networks that do not include web servers.
Re: (Score:2)
When DDOS attacks look like legitimate web hits, blackhole routing can only be used on networks that do not include web servers.
The company that was making comments quoted in the article makes security products that profile your normal network traffic and then use the routers to blackhole DDoS traffic while keeping normal traffic fairly untouched. They make a relational database of what IPs you normally talk to, when on what ports, with what types of TCP headers etc. They likewise profile incoming traffic and then can manually or automatically blackhole all the fairly identical looking requests that make up a DDoS attack. This can s
Re: (Score:2)
I'm not sure that's fair. For instance, having your upstream provider set a null route on a core router and just send the traffic to the bit bucket, if under a massive attack, is going to be more efficient than attempting to do packet inspection, stream reassembly, etc, to know whether or not traffic is safe to pass. This is even more true for IPS than for a "normal" firewall, since the processing overhead of the application is a lot greater.
Of course, depending on the device you have, the software you're
Re: (Score:2)
Having your MAC address targeted is only problem if you're sitting in the same McDonalds that the attack is coming from.
Re: (Score:2)
Aw damn I just got it. I guess that's the downside of not eating fast food, you don't get all the fast food humor :P
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.
Re: (Score:2, Interesting)
Unless you have actually operated a massive web server farm and been involved in mitigating large DDOS attacks, please don't try and speak authoritively.
For very large server networks ( multiple 10GE pipes feeding in etc. ) any firewall that you can buy will fail under attack way before the pipes will fill up. A web server farm with no stateful firewall is better equipped to deal with a flood of new transactions than a stateful firewall can process a new connection, add the state entry in the connection tab
Re: (Score:2)
Your firewall is a bottleneck in the way that the front door to your house is a bottleneck, in a DDoS situation, it's like someone said there was a SuperBowl party at your house and lots of people start coming over, flooding through the door and using up all of your resources.
What the article doesn't say is if you didn't have a front door or wall on your house protecting the resources, people would still come in and take them. The Security researcher goes on to say that you should put better security on you
Re: (Score:2)
To use your party analogy, the only thing that's going to keep your house reachable for 'correct' traffic in those circumstances is to have traffic control much further out and before the traffic narrows. Like a ten lane wide toll booth on your subdivision entrance that, instead of a toll, checks IDs of incoming cars.
That's something people can't really do, ISPs have to do.
It doesn't matter what you do, if you check their ID on the sidewalk, at the front door, or just let all six thousand people in until
Re: (Score:3)
That's not how DDoSes work at all.
No one runs a DDoS against ports that aren't open. All DDoSes are designed to look like totally legit connections to, in this case, port 80. This is quite simply because bogus packets cannot cause a DDoS, period. The server either rejects them, or ignores them, and they have almost no effect beyond a split second of CPU.
Whereas 'legitimate' connections that show up, and the server ACKs...and then gets no response from...those tie up server resources. And, incidentally, us
Re: (Score:2)
I agree with you almost completely, but to take the devil's advocate position, I have seen firewalls, deployed generally correctly, that did have hard-to-configure "default security settings" that, if triggered cleverly, could aid or add to a DDoS attack.
And it's not that the admin was brain dead, the box was weak or even a bad product, either -- the default settings make sense for a sort of general network deployment but probably not for a site likely for a DDoS attack.
My sense is that network engineering
Re: (Score:2)
I'll even name names here, a certian class of high end WatchGuard response to certian kinds of DDoS is to stop forwarding all traffic. This is designed behavior. They even sent a second free firewall of the same class to sit in front of the targeted host as a "solution" to the issue.
Re: (Score:2)
We're not always programmed... (Score:4, Insightful)
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.
Best be a Coward for 5 minutes........ (Score:3, Interesting)
Re: (Score:2)
Would you rather (Score:5, Insightful)
Re: (Score:2)
Lets assume for a moment that your web server is configured correctly, that is the only service listening on it is port 80 (HTTP) because as you say, its a web server.
Now in order to exploit that server, you would need to find a vulnerability on the HTTP service, wether its a bug in the web server software or a vulnerable script running on top of the web server... Obviously you can only exploit this while port 80 is open...
So if you add a firewall, you could use it to block port 80 and thus prevent this ave
Re: (Score:2)
I'm of 'The 99% of the time, public servers should not be behind firewalls' school of thought.
Or, rather, they should be their own firewall.
I mean, you have to set up that stuff anyway. If you have a mail server, you'll need to set it up to deny connections from spammer-owned machines. If you have ssh, you'll want to set it to block logins. Etc, etc.
So if you're keeping track of all that, just put it in the damn firewall to start with. Which only works if it's the same computer.
If you do get hacked, a firewall can hinder the hacker by preventing them from binding additional ports or establishing outbound connections,
Hackers don't really need
Re: (Score:2)
Yeah, good luck finding anyone who checks router logs and compares them to what 'should' be happening. :)
It's called an IDS and you can set rules for it. It should warn you.
The question is not _if_ they can own your privileges. The question is when, for how long and how much damage they do to your assets.
Re: (Score:2)
IDS systems, when poorly configured, will either generate floods of false positives (so the staff just ignore them) or miss important events. I have pentested countless customers who had IDS systems and many of them simply didn't notice my attacks, even successful ones.
Many places have an IDS as a tick in the box, and the logs will never be read.
When they own a system that system is gone, you can consider any data on it gone... The question is how quickly you can detect and remove them, and contain them to
Re: (Score:2)
Many places have an IDS as a tick in the box, and the logs will never be read.
Well, strictly speaking, most placed don't have IDS at all. ;)
Most places that do have IDS will never check the logs, or they have six hundred lines of stupid warnings and three lines of an attacker getting in won't be noticed.
However, an IDS and an external firewall are not actually the same thing anyway. You can run an IDS on the computer itself, and you can even run an IDS that just watches and doesn't do anything.
You can even buy an external firewall with IDS and open up everything on the firewall t
Re: (Score:2)
Re: (Score:2)
And have fun managing the firewall on each individual box vs. a centralized firewall.
If you have multiple internet facing boxes with the same access requirements, what I said doesn't really apply.
However, almost no one does.
Even when people think they are, they aren't. Round-robin proxies do not make multiple servers internet facing. The proxy faces the internet. That needs a firewall and can be its own.
Slashdot has one public facing server. Amazon and Facebook have, according to DNS, three, but they're all on different networks, so obviously can't be managed via a single firewall. CDN
Re: (Score:2)
You could also have the firewall monitor traffic for known exploits; this type of functionality is built into many firewalls, from opensource pfsense (snort, etc), to sonicwall to cisco asa.
Its not an all or nothing; if it were, people wouldnt pay big bucks for cisco or even smaller SoHo firewalls (sonicwall et all).
Re: (Score:2)
Which is exactly the problem the article discussed...
You put a lowend server to forward all the traffic to your highend server, and then you make it do all kinds of processing on that traffic, thus creating yourself a significant bottleneck.
Re: (Score:2)
Re: (Score:2)
It's easy to get multi gigabit connections in a carrier neutral data centre... Most big carriers will supply you with 10GB, and major datacentres will have multiple carriers available, look at telecity/redbus/telehouse in london for instance.
My web servers have 2 interfaces, the back interface connects to a non routable interface which i connect to using a VPN and SSH and lights out boards are running in there.
I have no issue running SSH on the internet, and you also need to manage a firewall from somewhere
Re: (Score:2)
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 ser
Re: (Score:2)
The whole fucking article is bizarre. The only real solution to DDoS attacks is some form of clustering/peering with fail-over capabilities. That is how, I gather, guys like Amazon do it. You don't have one server, you have several, separated either in space and/or segment. For the rest of us small-fry, it just isn't worth it. The last time I had any kind of a denial of service attack (it was actually an insanely huge Joe Job attack on my mail server), I just pulled the plug for an hour, phoned importa
Flawed logic (Score:5, Insightful)
Also don't build taller walls, because it just encourages attackers to bring taller ladders.
Sold! (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Indeed i have several servers on the internet with no firewalls...
Firewalls would simply introduce additional cost and additional failure points, any benefit in security would be pretty negligible. The external footprint of the servers (ie if you scanned them) would be exactly the same because only services that need to be open to the world (http, smtp, dns etc) are actually open.
Re: (Score:2)
Well, assuming no firewalls anywhere, that is not correct.
A firewalled response drops the packet, (i.e. stealth). A port closed response returns a rejection to the requester. That at least tells them a server is running at this location.
In terms of open ports, yes the behavior is the same, but not the behavior on all ports.
For example, if a script is just scanning for a netbios vulnerability on port 139 or something, it would not detect a server at your IP with a firewall in place, where it would if it gets
Re: (Score:2)
Servers can be configured to stealth, they don't need to return port closed responses.
The value of doing so is quite limited however, a determined attacker can just scan every port until they find your open ones...
Scanning large ipranges is going to become a lot less useful with ipv6.
Re: (Score:2)
Well I still think a firewall is good to have as part of a layered defense strategy.
It's good to only start services you need, but accidents happen. Let's say an erroneous service is accidentally started that opens a port in an insecure way. WIth a firewall policy only allowing traffic on the ports you expect, this would not be a problem, but without one it could open up a new attack vector.
Also, while they won't really help that much against DDOS, firewalls can reject other kinds of invalid traffic that ca
Re: (Score:2)
Well hopefully you aren't going to be consulting on anything important that gets deployed.
A stateless ACL on a switch or router that does it in a hardware path will do just fine dropping packets destined for unintended services, and it won't act as an additional attack vector.
A firewall in front of a server farm is a 'layer' that only does harm, and does not do any good.
Re: (Score:2)
Well I'll just have to disagree.
There should at least be a firewall on each host that has public facing ports for any admin services (ssh etc).
That allows you to easily configure flexible rules to disallow people that send invalid traffic to those ports.
Re: (Score:2)
You mock, but if you are careful (only bind services that require public access to eth0, use tcp wrappers, harden things, etc), a firewall is mostly unnecessary.
Exactly. I have a firewall on my web server, but only because I'm required to contractually. The firewall passes traffic on ports 80 & 443 inbound and anything outbound. But as ports 80 and 443 are the only ones bound to services at the OS level (admin is through a virtual console accessed via an entirely different network, not publicly addressable) the firewall actually has no effect at all on the behaviour of the system. I could switch it off and be just as secure.
Re: (Score:2)
And why exactly do you not want to filter outbound traffic?
1. Because outbound filtering achieves nothing that I would consider useful. Once an attacker has compromised your system, there are trivial ways of getting around an outbound filter in order to download data, etc. My system needs to be able to make http requests, so outbound filtering isn't going to prevent an httpd worm from spreading (the only kind I'm vulnerable to).
2. Because it would require stateful inspection of connections to know which outbound packets are in reply to incoming connections that h
Re: (Score:2)
Yep I'd be perfectly comfortable taking the firewall off my laptop (nothing to attack). On a good day I'd be OK doing the same on my Win7 gaming machine (same deal). My phone runs with no firewall (you can try your luck at attacking the dnsmasq daemon it's running, but that's about it). I could take the firewall off the VoIP server at work too if not for an unsecured power control protocol that requires an IP-specific rule to keep random jackoffs all around the world from shutting the box down.
Re: (Score:2)
Yeah, and why bother with a horse when you can just use an eggbeater? It's smaller anyway...
STATEFUL firewalls (Score:2)
Actually a good reason for it (Score:3)
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.
Re: (Score:3)
Sorry, this is wrong for all except maybe the most stupid firewalls out there.
A decent firewall will not only handle a lot more connections (or attempted connections) than any server can, it can also use a range of mitigation strategies should things start to get hairy, such as weeding out states selectively/faster, outright dropping anything unusual or matching any known-bad behavior, falling back to SYN-cookies (which don't requ
By that same faulty logic (Score:2)
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.
That depends upon the situation. (Score:2)
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
Re: (Score:2)
I'm sure you're right for certain scenarios. But as per some of the other comments, if your firewall isn't good enough to handle data coming down your pipe, you're doing it wrong.
Now, as to having to process the packets and forward them on, your server's NIC would have to do the same, and then waste server resources trying to process whatever the packet's requesting. Your NIC handling your poor flooded pipe would be nothing compared to what your server would be trying to do.
But there's a difference between
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.
I'm a heretic on this, but firewalls are pointless (Score:3)
Re:I'm a heretic on this, but firewalls are pointl (Score:2)
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?)
And then load balancers... (Score:2)
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 thi
Nonsense (Score:2)
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.
makes sense to me (Score:2)
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