Forgot your password?
typodupeerror

Firewalls Make DDoS Attacks Worse 217

Posted by CmdrTaco
from the it-burns-me dept.
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."
This discussion has been archived. No new comments can be posted.

Firewalls Make DDoS Attacks Worse

Comments Filter:
  • Long on Rhetoric (Score:5, Insightful)

    by hduff (570443) <hoytduff AT gmail DOT com> on Tuesday February 01, 2011 @02:13PM (#35070154) Homepage Journal

    Short on specifics.

    • by suso (153703) *

      Exactly, there is no hard evidence that would convince anyone technical in that article. Waste.

    • by Suki I (1546431) on Tuesday February 01, 2011 @02:16PM (#35070220) Homepage Journal

      Short on specifics.

      So I did not miss anything by not RTFA?

      • by Svartalf (2997) on Tuesday February 01, 2011 @02:23PM (#35070336) Homepage

        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.

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

        • by guruevi (827432)

          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

          • 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

      • by ArcadeNut (85398)

        Yes. You missed the Ads!

    • by hey! (33014)

      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

      • 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

      • by sumdumass (711423)

        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

    • by Lumpy (12016)

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

      • 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 :-(

      • by Rewind (138843)

        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!

        • by sumdumass (711423)

          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.

      • by DeadBeef (15)
        The article writer is just a clueless journalist but the guy he is getting the technical content from knows what he is talking about. Look up the NANOG archives for Roland Dobbins if you want to read through the flame wars along these lines before. Any firewall that does stateful filtering is just another attack vector in a big web server deployment. Most firewalls can be either crashed or will start refusing new connections with only a few thousand packets per second of the right stuff. Either way your si
        • by Lumpy (12016)

          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.

    • 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

      • 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

    • by passthecrackpipe (598773) <passthecrackpipe ... m minus language> on Tuesday February 01, 2011 @04:29PM (#35072038)
      In a surprise revelation, a vendor of anti-DDOS equipment claimed that everybody else is doing it wrong, and leaves several subtle hints that their own equipment and services are the only true defence against a concerted DDOS attack. In a further shocking comment, the article disclosed that almost everybody else is constantly under some form of DDOS attack, hinting that you might be next. As a final nail in the coffin of your amateurish "Network Security" the experts reveal that there is nothing you can do - the better you protect your systems, and the more traffic your current systems will be designed to handle, the more aggressive attackers will become.
  • by Mr_eX9 (800448) on Tuesday February 01, 2011 @02:14PM (#35070182) Homepage
    The article says that poorly deployed firewalls and IPS systems create a single point of failure.
    • by RobertM1968 (951074) on Tuesday February 01, 2011 @03:03PM (#35070988) Homepage Journal

      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.

      • by Mr_eX9 (800448)
        You're right, a better subject would have been "Bad article, too obvious." :)
  • by Locke2005 (849178) on Tuesday February 01, 2011 @02:15PM (#35070198)
    Poorly-designed firewalls make DDoS attacks worse.

    FTFY
    • Re:Translation (Score:5, Interesting)

      by toejam13 (958243) on Tuesday February 01, 2011 @02:43PM (#35070672)

      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.

      • Re:Translation (Score:4, Informative)

        by hardburn (141468) <hardburn AT wumpus-cave DOT net> on Tuesday February 01, 2011 @03:47PM (#35071500)

        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)

    by bhcompy (1877290) on Tuesday February 01, 2011 @02:17PM (#35070236)
    Hacker says that firewalls are bad, so don't use them.
  • by zn0k (1082797) on Tuesday February 01, 2011 @02:17PM (#35070240)

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

    • 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?"

  • Arbor Networks (Score:5, Insightful)

    by Anonymous Coward on Tuesday February 01, 2011 @02:18PM (#35070254)

    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)

      by icebike (68054) on Tuesday February 01, 2011 @02:31PM (#35070486)

      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.

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

        • by icebike (68054)

          There's still that "you can afford" bit.....

          You start getting DDosed and the bill from your CDN will send you into hiding.

      • by TubeSteak (669689)

        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

        • 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)

        by nine-times (778537) <nine.times@gmail.com> on Tuesday February 01, 2011 @03:30PM (#35071316) Homepage

        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.

    • by bsDaemon (87307)

      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

  • useless article (Score:5, Informative)

    by clarkn0va (807617) <apt.get@gm[ ].com ['ail' in gap]> on Tuesday February 01, 2011 @02:20PM (#35070282) Homepage

    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)

      by Svartalf (2997) on Tuesday February 01, 2011 @02:30PM (#35070448) Homepage

      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)

        by Anonymous Coward

        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

    • 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

      • by DavidTC (10147)

        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

    • by swb (14022)

      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

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

    • I'll have to disagree with Svartalf here. You're obviously not savvy, because you lack tons of money. The target audience, ie, the wealthy, are savvy enough to understand this marketing ploy. "If you throw enough money at ANY problem, the problem will go away!" And, the ploy works! Witness how many people purchase AV and firewall software from the "security" companies! I'm not really cynical - just a Linux guy.
  • by Anonymous Coward on Tuesday February 01, 2011 @02:20PM (#35070288)

    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.

    • 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 do
      • by fwr (69372)
        A successful DDOS attack makes actual, valid, requests to the victim host. If it is a web browser, then it makes actual HTTP requests, possibly to the home page, possibly taking a random URL off that home page, in the same domain, and crawling the web site. Simply replying with an Ack isn't going to do squat. There are services out there that can scrub the requests for you. I'm not going to mention the name of the company, but you can research it if you want. Basically, once you sign up traffic normall
  • Would you rather (Score:5, Insightful)

    by D3 (31029) <daviddhenning AT gmail DOT com> on Tuesday February 01, 2011 @02:22PM (#35070314) Journal
    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.
    • by Bert64 (520050)

      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

      • by DavidTC (10147)

        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

        • by CBravo (35450)

          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.

          • by Bert64 (520050)

            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

            • by DavidTC (10147)

              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

        • by D3 (31029)
          And have fun managing the firewall on each individual box vs. a centralized firewall. If you are a big enough target to get DDOSed at 100Gbps, you aren't running free tools.
          • by DavidTC (10147)

            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

      • 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).

        • by Bert64 (520050)

          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.

      • by D3 (31029)
        So how do you manage said web server if port 22 or 23 are not open? How do you do your backups or network storage connections? There will always be other services available on the server. The firewall stops the outside world getting to port 22 while you on the inside still can. Typical firewalls these days can sling packets at speeds of over 1Gbps. But the DDOS is running at 100Gbps. A DS3 only gives you 45Mbps. But they want to blame the firewall as being a bottleneck? How many businesses have pipe
        • by Bert64 (520050)

          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

  • Flawed logic (Score:5, Insightful)

    by Smallpond (221300) on Tuesday February 01, 2011 @02:22PM (#35070326) Homepage Journal

    Also don't build taller walls, because it just encourages attackers to bring taller ladders.

  • Sold! (Score:5, Funny)

    by Beelzebud (1361137) on Tuesday February 01, 2011 @02:27PM (#35070402)
    Firewalls are a waste of time. I just disabled mine and am ready for some smoo
    • by caluml (551744)
      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.
      • by Bert64 (520050)

        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.

        • 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

          • by Bert64 (520050)

            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.

            • 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

              • by DeadBeef (15)

                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.

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

      • by julesh (229690)

        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.

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

  • 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 w
  • by Lennie (16154) on Tuesday February 01, 2011 @02:43PM (#35070668) Homepage

    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.

    • by olden (772043)

      during DDOS-attacks there is just to much state for the firewall to handle.

      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

  • Don't put your web servers behind load balancers either, after all, the load balancer is another single point of failure.
  • by Bert64 (520050) <bert AT slashdot DOT firenzee DOT com> on Tuesday February 01, 2011 @03:01PM (#35070954) Homepage

    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.

    • 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

    • by steelfood (895457)

      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)

    by Nigel Stepp (446) on Tuesday February 01, 2011 @03:35PM (#35071378) Homepage

    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.

  • by Theatetus (521747) on Tuesday February 01, 2011 @03:53PM (#35071596) Journal
    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?
    • 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?)
  • 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

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

  • 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

It is better to give than to lend, and it costs about the same.

Working...