Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Firewalls Make DDoS Attacks Worse

CmdrTaco posted more than 3 years ago | from the it-burns-me dept.

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

Sorry! There are no comments related to the filter you selected.

Long on Rhetoric (5, Insightful)

hduff (570443) | more than 3 years ago | (#35070154)

Short on specifics.

Re:Long on Rhetoric (2)

suso (153703) | more than 3 years ago | (#35070178)

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

Re:Long on Rhetoric (3, Funny)

Suki I (1546431) | more than 3 years ago | (#35070220)

Short on specifics.

So I did not miss anything by not RTFA?

Re:Long on Rhetoric (5, Insightful)

Svartalf (2997) | more than 3 years ago | (#35070336)

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:Long on Rhetoric (0)

Toe, The (545098) | more than 3 years ago | (#35070914)

Seems like a firewall could then help minimize a DDoS. A well-configured one will have traffic limiters on some ports in order to allow others to have some wiggle room.

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.

Even if you allocate 90% to the http ports, that still leaves 10% for SMTP, SSH, etc. And note how important that is... if SSH is still easily passed, then you as an admin can log in and tweak (and respond) without leaving the comfort of your couch.

Re:Long on Rhetoric (0, Insightful)

Anonymous Coward | more than 3 years ago | (#35071092)

So basically what you're saying is that you have not the slightest clue how the internet, firewalls or networks in general work. And you seem to think that a port is somehow a physical thing.

Re:Long on Rhetoric (0)

Anonymous Coward | more than 3 years ago | (#35071720)

Are you retarded?

Re:Long on Rhetoric (2)

petermgreen (876956) | more than 3 years ago | (#35071906)

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 worth it to be able to control the prioritisation. However that only works IF those sending you traffic are playing nice (by playing nice I mean using protocols like TCP that backoff when they see congestion). If your ISP receives traffic for you at say 10 times the rate of your link and the senders don't back off then your ISP will have to drop nine tenths of it. The only way to fight such an attack is from the ISP side either by buying a bigger link or by getting the ISP to filter/shape the traffic before it hits the bottleneck. Your traffic shaper/firewall is powerless because nine tenths of your legitimate traffic is gone before it hits your shaper/firewall..

Re:Long on Rhetoric (1)

hey! (33014) | more than 3 years ago | (#35070656)

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 attract DDOS attacks other than putting them behind the same firewall as everything else. It's been years since I've done that kind of planning, but I'd guess only mom and pop businesses would do it that way these days.

Re:Long on Rhetoric (1)

t1n0m3n (966914) | more than 3 years ago | (#35071214)

"Stateful firewalls are likely to fail under a DDOS attack because they keep track of connection requests until the table is full."

Is there a firewall that initiates an SPI entry from the outside to the inside (besides CBAC of course)? What would be the point of such a firewall?

Sounds right (1)

billstewart (78916) | more than 3 years ago | (#35071302)

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

Re:Long on Rhetoric (2)

Lumpy (12016) | more than 3 years ago | (#35070940)

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:Long on Rhetoric (1)

GameboyRMH (1153867) | more than 3 years ago | (#35071470)

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

umm, okay (2)

Weezul (52464) | more than 3 years ago | (#35071184)

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.

Re:umm, okay (1)

certain death (947081) | more than 3 years ago | (#35071406)

Yeah, that's it...dual home that sucker so I can get in the front and eat your network for lunch from the back. 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. Firewalls do ingress and egress filtering for a reason. If you can't mitigate a DDoS attack, you shouldn't be working in a position that would require you to.

Re:Long on Rhetoric (3, Insightful)

passthecrackpipe (598773) | more than 3 years ago | (#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.

Bad headline, too vague (4, Interesting)

Mr_eX9 (800448) | more than 3 years ago | (#35070182)

The article says that poorly deployed firewalls and IPS systems create a single point of failure.

Re:Bad headline, too vague (5, Insightful)

RobertM1968 (951074) | more than 3 years ago | (#35070988)

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.

Translation (2)

Locke2005 (849178) | more than 3 years ago | (#35070198)

Poorly-designed firewalls make DDoS attacks worse.

FTFY

Re:Translation (4, Interesting)

toejam13 (958243) | more than 3 years ago | (#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 (3, Informative)

hardburn (141468) | more than 3 years ago | (#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 (5, Funny)

bhcompy (1877290) | more than 3 years ago | (#35070236)

Hacker says that firewalls are bad, so don't use them.

Re:Hacker says (0)

Anonymous Coward | more than 3 years ago | (#35070818)

Security expert says that firewalls are required, you must use them.

(both hacker and security expert stand to bennefit from their statements - fud)

What a useless article (4, Informative)

zn0k (1082797) | more than 3 years ago | (#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.

Re:What a useless article (2)

SnarfQuest (469614) | more than 3 years ago | (#35070320)

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

actually he has a point (0)

Anonymous Coward | more than 3 years ago | (#35071682)

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.

Arbor Networks (5, Insightful)

Anonymous Coward | more than 3 years ago | (#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 (4, Interesting)

icebike (68054) | more than 3 years ago | (#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.

Re:Arbor Networks (1)

sexconker (1179573) | more than 3 years ago | (#35070542)

Nothing you can afford can handle a "Big DDOS attack".

No need to pick nits about how it is managed or configured.

Nothing anyone but Bill, Steve, or Oprah can afford can handle a "Big DDOS attack".
The very nature of the internet makes this so.

Re:Arbor Networks (1)

Jake Griffin (1153451) | more than 3 years ago | (#35070660)

or Mark... I just saw the Social Network :)

Re:Arbor Networks (1)

sexconker (1179573) | more than 3 years ago | (#35071278)

or Mark... I just saw the Social Network :)

Oh please. Like Zuckerborg would filter away a single bit.

Re:Arbor Networks (2)

qw(name) (718245) | more than 3 years ago | (#35071322)

or Mark... I just saw the Social Network :)

My condolences.

Re:Arbor Networks (1)

froggymana (1896008) | more than 3 years ago | (#35070748)

Amazon seems to handle "Big DDoS attack"s rather well. They had one all throughout December, plus the smaller one done by "Anonymous" .

Re:Arbor Networks (2)

icebike (68054) | more than 3 years ago | (#35071026)

YOU != Amazon

Re:Arbor Networks (1)

divisionbyzero (300681) | more than 3 years ago | (#35070792)

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:Arbor Networks (1)

icebike (68054) | more than 3 years ago | (#35071130)

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

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

Re:Arbor Networks (0)

Anonymous Coward | more than 3 years ago | (#35070816)

Nothing you can afford can handle a "Big DDOS attack".

No need to pick nits about how it is managed or configured.

Actually my server is impervious to any and all DDoS, and I haven't spent a dime. You could throw 100Gbps sustained at it and it would never flinch. I'll post my iptables, hold on, let me just turn it on first.

Re:Arbor Networks (1)

TubeSteak (669689) | more than 3 years ago | (#35071294)

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:Arbor Networks (1)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#35071836)

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 notification system so the admin is notified of what is going on and can request particular kinds of mitigation from the ISP in a fairly automated fashion.

Doesn't take that much... (1)

Anonymous Coward | more than 3 years ago | (#35071312)

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.

Re:Doesn't take that much... (2)

icebike (68054) | more than 3 years ago | (#35071396)

When DDOS attacks look like legitimate web hits, blackhole routing can only be used on networks that do not include web servers.

Re:Doesn't take that much... (0)

Anonymous Coward | more than 3 years ago | (#35071710)

You are indeed correct on your point. No one wants to block port 80 (or 443 for that matter).

Re:Doesn't take that much... (1)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#35071784)

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 sometimes mean dropping legitimate traffic that looks too much like the attack, but it basically keeps vital services and most normal traffic working fine during the attack.

Re:Arbor Networks (3, Informative)

nine-times (778537) | more than 3 years ago | (#35071316)

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:Arbor Networks (0)

Anonymous Coward | more than 3 years ago | (#35070746)

What's worse, is when your specific mac address is directly targeted, in a big way. It is a well known fact that the preponderance of these attacks originate from within the McDonalds corporation.

Re:Arbor Networks (1)

GameboyRMH (1153867) | more than 3 years ago | (#35071590)

Having your MAC address targeted is only problem if you're sitting in the same McDonalds that the attack is coming from.

Re:Arbor Networks (0)

Anonymous Coward | more than 3 years ago | (#35072018)

I guess I was being a little too cryptic with my humour...

Re:Arbor Networks (1)

cinderellamanson (1850702) | more than 3 years ago | (#35070820)

So, I found the source material, the article is poorly written - maybe plagiarized.

Start on page 7-9, mitigation
http://www.arbornetworks.com/dmdocuments/Arbor_Worldwide_ISP_Security_Report.pdf [arbornetworks.com]

They have a point considering that the goal of DDOS is to bring the network down, the article stinks, because it does not offer an alternative to ripping your firewall out.

The conclusion from the pdf says:

"Inter-domain traceback and attack mitigation mechanisms need to be deployed ubiquitously across the Internet, and primary option mitigation solutions must provide more capabilities than simply completing an attack for an attacker."

Which, is a great deal more sensible than "shut your firewalls off"

Re:Arbor Networks (1)

bsDaemon (87307) | more than 3 years ago | (#35071390)

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 running, what rules are in place, etc, your mileage may vary. However, I would say, as a general rule of thumb, that the fewer bottlenecks you place in-line, the harder it will be to choke the pipe.

useless article (5, Informative)

clarkn0va (807617) | more than 3 years ago | (#35070282)

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 (5, Informative)

Svartalf (2997) | more than 3 years ago | (#35070448)

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:useless article (2, Interesting)

Anonymous Coward | more than 3 years ago | (#35071250)

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 table and then match each packet against the table.

DDOS attacks will often attack the state table in the firewall, by filling it with useless connections and thereby making it match every packet against a huge list of nonsense, every step that a firewall vendor takes to try and mitigate these attacks actually make the DDOS more successful. Most firewalls can be rendered useless with only a few thousand packets per second on an ongoing basis.

Large web server farms will have static non-stateful ACLs in hardware on a switch or router which filter most of the rubbish out, but the web server is on it's own as far as dealing with SYN floods and half set up connections etc.

Re:useless article (1)

Tekfactory (937086) | more than 3 years ago | (#35070638)

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 your Router instead. In this case the router would just be another door or gate further away from the 'resources'.

So the article could have been named "Better Router security key to DDoS defense." but that's not as likely to draw hits as something provocative saying Firewalls are not only not stopping the problem, they are making the problem worse.

Well way back when folks mumbled something about rate limiting DoS attacks from your ISP, which would help you keep your head above water. Certainly defense in depth is having multiple layers of security, the router should be the first layer, maybe the firewall is the second, or maybe a load balancer with firewalls behind them, and then lots of servers to handle the traffic.

Maybe instead of what isn't working, we should look at DDoS attack that fail, like the recent one on Amazon whose distributed architecture was not brought down by the Distributed attack.

Re:useless article (1)

operagost (62405) | more than 3 years ago | (#35070910)

Clearly, then, my firewall needs a 50" LCD and more guacamole.

Re:useless article (1)

DavidTC (10147) | more than 3 years ago | (#35071140)

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 the walls fall over, your house is unreachable for the legit guests.

And, yes, like the article says, having a chockpoint that can handle less traffic than the actual house can is stupid, but it's a pretty dumb assumption that a firewall would be able to handle less traffic than a web server. Internal firewalls aren't very helpful in a DDoS, but they aren't making things worse, unless they're a lot crappier than your server hardware.

Re:useless article (0)

Anonymous Coward | more than 3 years ago | (#35071688)

It's not about the amount of bandwidth that the firewall can move, it is how many new connection setups can it do per second.

Even if some magical new firewall appeared that was not succeptible to state table exhaustion attacks, think about the following.

You are operating a web server, where _every_ connection to port 80 should be accepted with out question, why go through the hassle of putting a thing in front of it that checks if that connection is allowed and builds a list of connections in progress and tests all the packets against it. You will never choose to not allow the connection anyway, so why bother?

A bunch of static non-stateful ACL's on a platform that can do them in hardware ( fancy switch or router line card ) that drops anything not destined for port 80 will do everything you want to get done at line rate on huge interfaces without putting the additional attack vector of a firewall inline.

Re:useless article (1)

swb (14022) | more than 3 years ago | (#35070930)

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 for a high profile, DDoS-likely website is like race-prepping a car, and that because you can't race a car off the showroom floor doesn't make the car poorly designed.

Re:useless article (1)

CyprusBlue113 (1294000) | more than 3 years ago | (#35071850)

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:useless article (1)

Runaway1956 (1322357) | more than 3 years ago | (#35070984)

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.

Re:useless article (0)

Anonymous Coward | more than 3 years ago | (#35071154)

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.

Not necessarily. For example, if you mainly distribute large files (videos, ISOs, whatever) to customers with large bandwidth you could fill up your pipe with relatively few connections. You could set up some fairly heavy processing on new connections (say, port knocking, logging, etc) and still be able to fill up your pipe pretty easily, as the extra processing only happens on new connections.

But, if suddenly that setup is hit with a SYN flood, that heavy processing will bring that firewall to its knees. Even simple things like reverse NAT might be a problem during DDoS, even without saturating your pipe, and I'd bet that's common in DMZ-style setups.

Yes, the article is crap, but I would bet surviving a DDoS requires some fine tuning all over your infrastructure. The hard part is finding out what the best practices are, as accepted by the security community.

We're not always programmed... (4, Insightful)

Anonymous Coward | more than 3 years ago | (#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.

Best be a Coward for 5 minutes........ (3, Interesting)

business_kid (973043) | more than 3 years ago | (#35070598)

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!

Would you rather (5, Insightful)

D3 (31029) | more than 3 years ago | (#35070314)

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.

Re:Would you rather (0)

Anonymous Coward | more than 3 years ago | (#35070472)

From TFA: "But according to Arbor, service providers and corporate could significantly reduce their DDoS vulnerability by designing their security infrastructure to better locate policy-based security devices such as firewalls".

Re:Would you rather (1)

MightyMartian (840721) | more than 3 years ago | (#35070684)

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 important clients and explained the situation and took a little heat. The same applies for me today, we're small potatoes and throwing a dozen servers peered on different networks just isn't worth the money. The whole point of the firewall, which you are going to have, either as a separate box, or if you do want to run a server balls-to-the-wall, on the server itself, is to prevent intrusion. I'd much rather put up with being down for a while than having my whole system hacked because my first priority was to make sure that, no matter what, I had maximum uptime.

Re:Would you rather (1)

Bert64 (520050) | more than 3 years ago | (#35071122)

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 avenue of exploitation... But if you do that, the web server will no longer work so your firewall has to be configured to allow port 80.

So you have a choice:

Firewalled:
Port 80 open

Unfirewalled:
Port 80 open

The only place a firewall provides any benefit is either:

If you do get hacked, a firewall can hinder the hacker by preventing them from binding additional ports or establishing outbound connections, or detect them by providing an additional point of logging.
Your web server is grossly misconfigured and has all kinds of non web related services listening on its external interface, and you choose to block these services at the network level with a firewall instead of turning them off like you should have.

On the other hand, a firewall might have vulnerabilities of its own and someone could exploit that instead of the web server behind it. By adding the firewall, you have increased the network latency, increased your cost (power, hardware), and increased the potential intrusion points (since you now have 2 machines for hackers to attack instead of one).

The only real security benefit to be had is if you have application specific firewalls, and even there the benefits are questionable... Risk of the firewall being exploited (since it does very complex processing of the traffic) vs the risk of your services being exploited. Your still adding another point of exploitation, and basically assuming that the service behind the firewall cant stand on its own.

Re:Would you rather, Double DOh! (0)

Anonymous Coward | more than 3 years ago | (#35071328)

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!

Re:Would you rather (1)

DavidTC (10147) | more than 3 years ago | (#35071404)

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 to 'bind' ports anymore. It used to be that's how they did their control interfaces, but now they just set up some IRC server somewhere, and a program on the owned machine connects to it to get orders. Or it fetches a web page, or whatever.

It's so trivially easy to poke holes in outgoing firewalls it's not even worth considering them as 'protection' at all.

Unless your server doesn't contact anywhere at all. But if it does that, set up some iptable rules so it can't.

Of course, if they have root on your server, they can change that...but if they have root on your server you need to stop worrying about the server contacting other people and, you know, actually solve the damn problem you have. ;)

Seriously, we're getting a little goofy here. The problem isn't hackers inside the server contacting people...if they're inside the server, the problem is that they are inside the server.

It's nice to slightly consider damage they might do to other people, but, to use an analogy I used last time, it's essentially considering boarding up the windows, or even building a big wall around your house, in case snipers have taken over your house and start attacking people. Um, no. That is not the actual problem. The problem there is that attackers are inside your house.

or detect them by providing an additional point of logging.

Yeah, good luck finding anyone who checks router logs and compares them to what 'should' be happening. :)

Re:Would you rather (1)

certain death (947081) | more than 3 years ago | (#35071570)

First, you do not need a vulnerability to initiate a DDoS attack, second, filter port 80, don't block it, third, go back to school...you obviously weren't listening on the day they taught attack and deflect.

Re:Would you rather (1)

LordLimecat (1103839) | more than 3 years ago | (#35072024)

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

Flawed logic (4, Insightful)

Smallpond (221300) | more than 3 years ago | (#35070326)

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

Re:Flawed logic (-1)

Anonymous Coward | more than 3 years ago | (#35070526)

In another context...
Give up your nuclear weapons and defense infrastructure, it just antagonizes your enemies.

Sold! (4, Funny)

Beelzebud (1361137) | more than 3 years ago | (#35070402)

Firewalls are a waste of time. I just disabled mine and am ready for some smoo

Re:Sold! (1)

caluml (551744) | more than 3 years ago | (#35070618)

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.

Re:Sold! (1, Funny)

froggymana (1896008) | more than 3 years ago | (#35070788)

Why both with firewalls when you can just use NAT? Its more secure anyway..

Re:Sold! (1)

GameboyRMH (1153867) | more than 3 years ago | (#35071652)

Yeah, and why bother with a horse when you can just use an eggbeater? It's smaller anyway...

Re:Sold! (1)

Bert64 (520050) | more than 3 years ago | (#35071152)

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:Sold! (1)

julesh (229690) | more than 3 years ago | (#35071610)

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:Sold! (0)

Anonymous Coward | more than 3 years ago | (#35072004)

And why exactly do you not want to filter outbound traffic?

Re:Sold! (1)

GameboyRMH (1153867) | more than 3 years ago | (#35071712)

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:Sold! (1)

operagost (62405) | more than 3 years ago | (#35071064)

I don't need a firewall, because I use a mode$&%$BJKjk54
NO CARRIER

STATEFUL firewalls (2)

josephSevern (591076) | more than 3 years ago | (#35070616)

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.

Re:STATEFUL firewalls (1)

t1n0m3n (966914) | more than 3 years ago | (#35070986)

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.

Or just configure the STATEFUL firewall correctly to be in front of a web server and you achieve the same.

A misconfigured STATEFUL firewall is still just a misconfigured firewall.

Re:STATEFUL firewalls (1)

josephSevern (591076) | more than 3 years ago | (#35071972)

Even if one could magically configure a stateful firewall to be invulnerable to state table exhaustion attacks, it still serves no purpose. When you're fronting a server farm, the point is to allow access to the site on the correct ports. Stateless ACLs in hardware do that, and function at millions of packets per second. Stateful firewalls start dying at a fraction of theoretical throughput when faced with an attack that specifically targets the state table. There are no network state attacks against web services that aren't better handled on the servers. The place for stateful firewalls is in front of clients, where you want to disallow packets that aren't part of a conversation started from the inside.

Firewall is a target? (0)

Anonymous Coward | more than 3 years ago | (#35070624)

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.

Actually a good reason for it (2)

Lennie (16154) | more than 3 years ago | (#35070668)

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.

Poorly Designed Things Cause Problems (1)

y86 (111726) | more than 3 years ago | (#35070688)

Wow, POORLY designed system have issues under pressure. I can't believe it?!

This guy must be a highly paid consultant.

Architecture is not just for networks... (1)

tallship (115891) | more than 3 years ago | (#35070692)

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!

Poorly worded article (1)

Mezoth (555557) | more than 3 years ago | (#35070710)

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

By that same faulty logic (1)

Iphtashu Fitz (263795) | more than 3 years ago | (#35070734)

Don't put your web servers behind load balancers either, after all, the load balancer is another single point of failure.

Obligatory Reboot (0)

Anonymous Coward | more than 3 years ago | (#35070832)

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!

One shoe fits all? (0)

Anonymous Coward | more than 3 years ago | (#35070840)

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!

Programmed to do it... (4, Informative)

Bert64 (520050) | more than 3 years ago | (#35070954)

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

khasim (1285) | more than 3 years ago | (#35071848)

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.

not so bad ... (0)

Anonymous Coward | more than 3 years ago | (#35070962)

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"

What is the purpose of a firewall anyway? (1, Interesting)

WaffleMonster (969671) | more than 3 years ago | (#35070972)

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.

What they mean (4, Informative)

Nigel Stepp (446) | more than 3 years ago | (#35071378)

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.

Elementary my dear Watson (0)

Anonymous Coward | more than 3 years ago | (#35071424)

If a firewall can't handle the throughput of the Internet connection it is not the correct firewall for the job.

I'm a heretic on this, but firewalls are pointless (2)

Theatetus (521747) | more than 3 years ago | (#35071596)

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?

And then load balancers... (1)

diamondsw (685967) | more than 3 years ago | (#35071956)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?