Tear Down the Firewall

lousyd writes "'What's the best firewall for servers?' asked one Slashdot poster. 'Give up the firewall' answers Security Pipeline columnist Stuart Berman. Through creatively separating server functions into different, isolated servers, and assigning them to a three tiered system of security levels, his company has almost completely eliminated the need for (and headache of) network firewalls. "Taking that crutch away has forced us to rethink our security model," Berman says. The cost of the added servers is greatly minimized by making them virtual servers on the same machine, using Xen. With the new security-enhanced XenSE, this might become easier and more possible. What has you chained to your firewall?"

Comments

Band-aid

[egoriot]

Firewalls are such a band-aid solution to the problem of unknown processes running on your own computers. The right way to solve the problem of rejecting incoming and outgoing requests is to make it easy to see which processes are accepting and making connections on which port.s

Re:Band-aid

[Badanov]

Firewalls are such a band-aid solution to the problem of unknown processes running on your own computers. The right way to solve the problem of rejecting incoming and outgoing requests is to make it easy to see which processes are accepting and making connections on which port.s

Which is what netstat -at and firewalls do...

Re:Band-aid

[matth]

Ummm yeah I know what services are running.. some (like SSH) I only want me to be able to get to from certain IP addresses. Some (like on Windows) are needed for the machine to talk to Domain Controllers (but you certainly don't want joe-smith talking to your machine on port 139).. so yeah there are a lot of reasons to use firewalls!

Re:Band-aid

[Ingolfke]

You're looking at this from a server perspective. It's quite possible you don't want certain traffic on your NETWORK. I don't want people scanning my networks.

Re:Band-aid

[Golden_Eternity]

Firewalls have nothing to do with processes running on computers. They are for filtering network packets. What the poster is referring to is blocking off network traffic to those unknown processes. As an example, ZoneAlarm on a windows desktop... You may not realize the software that is running in the background trying to make outbound connections, but the firewall will catch those connections.

Or on the unix world, if you set up a default deny policy and only allow traffic to specific daemons, then if a new process starts unexpectedly, then you don't have to worry about unwanted connections to it.

If all you're doing is running a couple services that you want the world to be able to access, then yes, a firewall is just a bandaid against the potential for unknown processes running on the system.

Nice logic, but

[gcnaddict]

obviously, if you can rethink your security model AND keep up a well-maintained firewall, you will likely be better off :) How hard can it be to do BOTH, not one or the other?

Re:Nice logic, but

[m50d]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

Re:Nice logic, but

[Master of Transhuman]

Yeah, but the problem is this: what if it's your firewall admin who screws up? Granted, it's better to leave a port open on ONE device than on twenty different ones, but it's still the same problem.

I admit I'm not impressed with their notion that the workstations should just be kept patched and users authenticated before allowing access to the servers.

Still, there is something to be said for this sentence from TFA:

"By accepting that our internal network isn't much safer than a hostile external network, we've created a more realistic security architecture."

And they also do this:

"We assign each user a central identity, which is authenticated and validated before accessing the internal DMZ. We use central directories to manage identity privileges and PKI certificates. Existing systems, such as Active Directory, allow for low-cost private certificate authorities where PKI isn't well-established. We also log and monitor the activity and enforce acceptable application behavior."

In other words, if the end users have to use PKI to get into the internal network, they're basically being treated like potential intruders themselves - which is how it should be, given that much hacking is done from INSIDE the network. If your end-users are treated the same as any script kiddie, you don't have any problems separating the two except via authentication. Although I still wonder if this layout would protect from a clever hacker who does manage to penetrate and fully compromise a workstation.

Still, it should be sufficient to keep the ordinary worms and viruses off the servers - as long the worm or virus can't take advantage of a flaw in the basic network infrastructure.

And if you really ARE monitoring your network servers for bad behavior - with real human eyes instead of an IDS - instead of just paying lip service to the idea - you have the equivalent of a fully monitored system which is probably the best way to prevent intrusion. In other words, human guards AND electronics are the best security, not either one alone.

Re:Nice logic, but

[ScrewMaster]

Yeah ... this does seem like a solution looking for a problem, doesn't it? Kind of like deciding that, well, if I just start eating right and exercising regularly, I won't need my health insurance anymore.

Re:Nice logic, but

[ScrewMaster]

Human eyes are fine but human reaction time is not. A breach can occur and be over with in a very short time, given the speed at which processing and communication occur nowadays. By the time your human eyes are even aware that there's a problem, the organization could be severely compromised.

Besides, good security is layered, because each layer exponentially reduces the risk of a successful breach. Assuming that an operating system is safe from attack on a given port just because the system claims the port is "closed" or that there are no active services monitoring that port is foolish. These guys seem like they're trying to make a statement rather than good security. I know, conventional wisdom says that conventional wisdom is often wrong ... but sometimes it's right. I'm sticking with my firewalls, thank you very much.

Re:Nice logic, but

[timeOday]

Not always - one strong defense might be better than the same defense plus a weak one. There's a diluting effect, both technical (because defenses can create more vulnerabilities) but more importantly the human factor, because people only have so much time and attention to devote to these things, to learning them and keeping them up to date.

Working in a bureaucracy, I've found that new rules are either ignored, or obeyed at the expense of attention to old ones. Time, attention, and willingness to comply are limited.

Re:Nice logic, but

[Hatta]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

Well you could control who the processes can listen to. There's no reason an internal web server should be visible to the entire internet. Or even for publicly accessible sites, if all your customers are in the US it may make good sense to deny connections from say, romania.

Re:Nice logic, but

[Anonymous Coward]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

A properly configured firewall will prevent the escalation of an expoit to own your whole network. It will prevent server A from talking to server B in the event that server A is compromised. Sure a router would do some of this, but there are ways around routes. Author and poster seem to misunderstand the reason for having firewalls.

From Wikipedia:
The ultimate goal is to provide controlled connectivity between zones of differing trust levels through the enforcement of a security policy and connectivity model based on the least privilege principle.
http://en.wikipedia.org/wiki/Firewall_(networking)

Re:Nice logic, but

[Anonymous Coward]

Nice when a customer usually in US is on vacation or business travel in say, Romania. Non-customer-friendly obscurity.

Re:Nice logic, but

[Anonymous Coward]

If you have a good security model, the only processes listening will be the ones that need to be accessible. At that point, what good would a firewall do?

Plenty. I have apache servers in their own DMZ, mail servers in their own DMZ, a security R&D free-for-all DMZ and of course the safe office internal network.

The external internet facing interface on the perimiter firewall port forwards web and https to the apache-DMZ and smtp to the mail-DMZ. This firewall is configured such that none of the DMZ's can contact the other or the "internal" network and vice-versa plus the traffic to and from each network is only allowed on their appropriate ports. This firewall also performs flawless prioritisation, bandwidth limiting and spamd blacklisting.

If an apache server is compromised, that server cannot in any way exploit any machine on the other networks, etc. However if I had set these machine up like the story, the apache machines would be running local firewall processes which would likely get MODIFIED by the successful attacker, who would then move on to exploting other machines or even just performing DoS, flooding, etc.

That is the beauty of the perimiter firewall. It is dedicated and has "the final say". This guy thinks fancy network layout with local firewalls on each serving host or DMZ is enough. He is nuts. That may well be doable at a high level of security, but that is no reason to give up the absolute power of the perimiter firewall. I've beeb doing like he has for years, but with the perimiter firewall as the ultimate enforcer.

Security is about layers. This guy thinks it's a good idea to remove the strongest layer, which he considers a crutch. After 10 years on the job, maybe he has gone nuts and needs to retire.

Re:Nice logic, but

[SquadBoy]

Security is like ogres, onions, cake, and parafait.

It's all about layers. Far too often people do perimeter security and call it a day and far too often people argue that if your hosts are hard that you don't need to worry about the perimeter. You need both.

Now granted I didn't rtfa but the summary makes sense in some situations that we have where I work. I maintain 5 firewalls with up to 16 ports each. Most of those are internal and a great many of those firewalls/interfaces could be safely done away with using a model similar to this one. But you would be insane to rip out the perimeter. You would also be insane to ignore your middle. Far too many places do just that. So it's all about balance young grasshopper.

Re:Nice logic, but

[Desert Raven]

insightful?

OK, first issue. If you run any *significant* services, you have ports that need to be accessible by your machines, but nobody else's. The best example is database servers. My database runs on a separate machine. My webservers need to access it, but NOBODY else does. The database's access control is not enough, I don't even want anyone outside my network to see those ports, let alone try to muck with them.

Second issue. There are always new exploits coming up for the software you *do* have to expose (http, smtp, etc.) Firewalling unneeded ports (both directions) can prevent the exploit from becoming fully realized. Once upon a time, I had a machine get compromised through a web app. The trick is, the next step in it's script was to "phone home", which it could not do, because I don't allow outbound traffic for anything except what I *have* to, and them only on the exact ports and IPs necessary. I got alerted when suspicious outbound traffic was seen on the firewall.

Should you secure your apps? Hell yes. Firewalls can't help you if your allowed apps are insecure.

Should you be foolish enough to think this is as good as or better than a firewall? Um, what were your addresses again?

Re:Nice logic, but

[Dwonis]

The strongest principle in computer security is simplicity. When you get rid of a firewall, you get rid of a level of complexity and a potential vulnerability.

Re:Nice logic, but

[pipacs]

The strongest principle in computer security is simplicity.

True, but read the article. Firewalls are much simpler concept than what the author proposes: three layer architecture, ACLs, tickets, virtualization, strong clients, smart admins etc. etc.

Sigh...

[EQ]

Let me try selling THIS to my boss, with the Cisco guys whispering sweet nothings in his ear about PiX Firewalls and all this wonderful "solution in a box".

Or is this another Flavor of the Month event?

Nothing - not using one

[maxrate]

For my servers (mostly W2K & RedHat) I do not have them on a physical firewall. I restrict what can be done by blocking ports that aren't needed. I keep the boxes up-to-date.

Realistically, I'm not sure there is much more I can really do other than logging in a checking things out when ever I can (which is often).

It's worked well for me (so far), and I've had server directly on the internet since 1999. I got hit with code-red on a server once.

"Simple" ACLS

[wcdw]

By defining simple ACLs, we further isolate our backend servers.

Personally, I've never found ACLs as easy (or as flexible) as other firewall solutions. But in any event, ACLs are firewalls, call them what you will....

Firewalls aren't totally expendable

[cerberus4696]

It's one thing to give up the firewall if all you have behind it is servers. It's quite another to give it up if you're protecting user workstations. While it's certainly possible to carefully arrange your external services such that they are secure, it's really only possible if you have absolute control over every single device behind the firewall.

Re:Firewalls aren't totally expendable

[Master of Transhuman]

The point is they INTEND for the workstations to be more exposed to the Net. This reflects the reality that perimeter security isn't working well. If you treat the workstations as if they're NOT secure, your security actually gets better because now you're dealing with the reality that most hacking is done from INSIDE the network - whether from internal users or compromised workstations doesn't matter.

Their security is reserved for the server tiers. The workstations are protected as well as possible using the usual means, but they are NO LONGER TRUSTED.

What is XenSE?

[Lemming Mark]

I was present at the XenSE meeting (that's me at the bottom of the list ;-) I'd like to clarify exactly what XenSE is and what it isn't:

What XenSE isn't:
* it's not Xen's "security issues team". It's not for patching exploits, etc.

What XenSE is:
* the "virtual machine monitor" equivalent of SELinux
* mandatory access control for virtual machines
- e.g. you might enforce some sort of information flow between virtual machines (e.g. "Top Secret" only talks to other "Top Secret")
* enforced from the very lowest levels of the system, so should be very trustworthy

The goal is that the complete XenSE system achieve a higher security rating than currently possible with SELinux alone. The initial prototype of the mandatory access controls has been supplied by IBM and is in the 3.0-testing tree right now. Fully achieving the project's security goals will take considerably longer (Xen 4.0 timeframe).

Re:What is XenSE?

[Lemming Mark]

Yes but not on your existing hardware: running Windows XP will require hardware virtualisation support. Intel and AMD will be releasing this shortly (Q2 this year for Intel, Next year for AMD).

You won't need to wait for XenSE to achieve this, though - one of the Xen 3.x series will probably be able to do everything you want. A number of people are running a firewall in a separate virtual machine using Xen 2.0 (which can't run Windows). You're able to assign the network device directly to the firewall domain for better performance: no need to "double virtualise" the network card :-)

OpenBSD, whilst doable, probably wouldn't be the best choice for the firewall virtual machine: a native Xen-aware OS such as Linux, NetBSD or FreeBSD would be better[*].

[*] assuming there isn't a port of OpenBSD by that stage.

Firewalls are needed only for leaky systems

[KiloByte]

In general, firewalls can be compared to a tarpaulin stretched on four sticks above a house. It has an effect only if:

• the roof is leaky
• you want to make your yard free of rain
• you own a number of houses, and want to ensure they will be free of rain even if the houses' caretakers are idiots

In other words, firewalls are of any use only if:

• you're defending a grossly insecure system (Windows?)
• you have unprotected communication on a network
• you want to enforce a policy

The tarp does nothing for a sturdy roof. There is no way to attack bare kernel (ok, ping of death), and firewalls do nothing to protect services which are already visible to the network. And if you want to use the firewall to block off unneeded services, why in the hell are you running them in the first place?

Re:Firewalls are needed only for leaky systems

[That's Unpossible!]

There is no way to attack bare kernel (ok, ping of death)

OK, so then why did you mention that point if you are going to subsequently shoot it down with one example?

firewalls do nothing to protect services which are already visible to the network

Yes, higher-end firewalls can also scan the traffic on those open ports looking for exploits (ala IDS firewalls).

And if you want to use the firewall to block off unneeded services, why in the hell are you running them in the first place?

Are you serious? I have tons of services running on various servers that I do not want made available to the public, yet need to be available to (a) the other servers behind the firewall, and (b) trusted users that connect over our VPN... which, incidentally, is another function of a good firewall.

The article and your post are pure lunacy. It is not that hard to maintain a firewall, and as long as you plan your internal networking with the assumption that the firewall will not stop a really good hacker, it is just one more layer of security.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

Apparently the problem for some admins is that firewalls become a security hazard in themselves because they have to be constantly adminned by opening and closing ports for special end user purposes, which tends to introduce configuration errors and security holes. And if they don't do this, they get endless complaints from the end users that they can't access things they need (or think they need) on the Net.

And this also applies to the problem of connecting with business partners, contractors, etc., as well as supporting new apps like Skype.

By dumping the end users on the Net themselves and protecting the servers only, the admins eliminate this problem.

I'd say it remains to be seen if completely dumping the firewall is feasible, since the article doesn't address whether they've survived SIGNIFICANT hacker attacks using this model. THAT is the real test.

Re:Firewalls are needed only for leaky systems

[Master of Transhuman]

"higher-end firewalls can also scan the traffic on those open ports looking for exploits"

And why? So you know there are exploits being run against you? And this helps how? Your goal is to prevent exploits from being SUCCESSFUL, not from being run against you, since they will be run anyway. Check your firewall logs long enough for a big enough company, you'll see every exploit there is. So what?

"I have tons of services running on various servers that I do not want made available to the public, yet need to be available to (a) the other servers behind the firewall, and (b) trusted users that connect over our VPN... which, incidentally, is another function of a good firewall."

You didn't read TFA, right? They deal with this as follows:

"This begins with separating our servers from our clients. We can do that now, thanks to layer-3 data center switches that allow for the low-cost creation of subnets. By defining simple ACLs, we further isolate our backend servers.

The servers and their respective applications sit in their own DMZ, protected by an Application-layer firewall. We organize servers into three tiers: The first tier consists of presentation servers such as Web and e-mail servers--these are the only servers accessible to end users. The second tier, made up of application and middleware servers, is in turn only accessible to the presentation servers. Finally, the third tier, consisting of the database servers, is only accessible to the application and middleware servers."

They also specifically took this approach because it allows them to connect with business partners and also allow their end users, visitors and contractors to use their laptops more freely without compromising security by treating EVERYBODY as if they were a potential script kiddie - which is how security should be since most hacks occur from INSIDE the network.

That deals with your issues. The only issues I have with the concept is that I don't see where it has been TESTED against a significant hacker attack where workstations have been thoroughly compromised and used to attack the servers in an island-hopping attack. I'd like to see these people do a high-quality pen-test from some pros.

Why not have both?

[ravenspear]

I agree that firewalls should not be implemented as a crutch in lieu of a good security model for your servers, but why not have that and a firewall. TFA makes a good point but most sysadmins who have any experience with good security already know it. Only run the services needed on the servers dedicated to those services.

But it seems to me that rejecting all other traffic with a firewall is a good added measure of security that can only improve the overall security of your setup. It also makes you less visible to attackers and wastes there time.

Re:Why not have both?

[Master of Transhuman]

The article makes the point that it costs money and time to "reject all other traffic" because the end users often need to access things outside the system, new applications such as Skype also need to have new ports opened, and outside visitors need to connect to the network internally which leads to security risks as firewalls are administered.

By treating EVERYBODY outside the server ring as a potential risk, you eliminate these problems and take a more proactive, paranoid approach to the security of the internal network rather than relying on perimeter security which is hard and expensive to do. At the same time, you make the network outside the server ring more useful to end users.

I can see the point - I'd just like to see it TESTED against a good-quality pen-test using compromised workstations against the server ring to see if Layer-Three switches with ACLs and PKI authentication and application firewalls are sufficient to protect the servers against island-hopping attacks by a good hacker.

Re:Of course but

[NeoThermic]

And for windows:

netstat -v -o -n -b -a

(you can ommit -v for a quicker display)

NeoThermic

He's only giving up the border firewall...

[stefanlasiewski]

It's a rather sensationalist headline. He's not really ditching his firewall, he's replacing the one border firewall with multiple firewalls in the internal network, and is keeping the production environment isolated from the non-production (Office & Development) networks.

He removed the firewall between the Production Environment and the Internel, and is replacing it with several firewalls on the internal network. I count 4 firewalls-- One between the Webservers & Application server, a second firewall between the Application server and DB server, a third firewall between the production environment and non-production environments; and he discusses using ACLs to isolate subnets -- that's conceptually the same thing as a firewall.

But that's not a very new concept, and even with his plan, it still seems like you'd be more secure if you have an external firewall on the added network.

What's the harm in adding one more firewall and only allowing traffic on the HTTP port, HTTPS port and possibly VPN? It's cheap insurance just in case someone made a mistake and left some services running on one of the machines.

Re:He's only giving up the border firewall...

[Master of Transhuman]

The "harm" is described in the article:

"Perimeter security was originally intended to allow us to operate with the confidence that our information and content wouldn't be stolen or otherwise abused. Instead, the firewall has slowed down application deployment, limiting our choice of applications and increasing our stress.

To make matters worse, we constantly heard that something was safe because it was inside our network. Who thinks that the bad guys are outside the firewall and the good guys are in? A myriad of applications, from Web-based mail to IM to VoIP, can now tunnel through or bypass the firewall. At the same time, new organizational models embrace a variety of visitors, including contractors and partners, into our networks. Nevertheless, the perimeter is still seen as a defense that keeps out bad behavior. Taking that crutch away has forced us to rethink our security model."

I can see the point. However, as always,YMMV. If you can't devote the resources to doing decent monitoring of your applications and servers, and keeping the workstations patched, then you might need a perimeter firewall.

The point of the article is that a perimeter firewall - a "moat mentality" - leads to lax security on the internal network. And it's NOT "cheap insurance" because it requires much more maintenance to secure an entire perimeter of thousands of workstations AND still provide Net access to those systems (and visitors) than it does to secure an inner ring of a few hundred servers and to treat EVERYBODY outside that ring as a threat - including your own users.

I use a firewall to isolate networks

[StupidKatz]

I'm running all kinds of crud on the intranet that I don't want exposed to the Internet, such as NetBIOS on Windows and some permissive SAMBA shares on assorted servers.

So, the services are running so that I can use them from the inside (with any device on the inside, without mucking with ACLs, additional equipment aside from a switch, etc.) without having the services exposed to the outside.

Now, if you're running services which aren't being used by legitimage users at all... ;)

part of a larger security solution

[eth00]

Firewalls are still important in the entire security model. I do a lot of working on shared servers that host websites and have found a firewall can stop a lot of headaches. When some users script gets compromised and a script kiddies goes to send out a DOS of some sort the firewall can block it. I have found that the firewall is more important for exgress monitoring for this type of market but it is very valuable.

While it is true people have the wrong image of a firewall they are still very useful when used correctly. Security is not just a single thing you do to a system but many different layers and the firewall plays into that field. It is also a lot easier to just block some script kiddie at a firewall if they keep trying to brute force a server. I think I am going to keep my firewall for a little longer :)

Summary

[Zarhan]

This article shows that the guy is now realizing that you also need network design besides only putting a firewall at the border and hoping it magically makes everything ok. He's quoting "innovative" networking desings, like

- Segmenting your network to
- Workstations
- Internal servers
- Internal databases etc (accessed by servers)
- DMZ
- Setting up stringent ACLs to only permit specific traffic between segments.

C'mon, this is pretty much elementary stuff. Any network adming should know to design his network like this even in small companies where you have 2 workstations and a single server.

Then he makes a claim that you don't need firewall because only things accessible to Internet (Workstations and stuff in DMZ, like your public website) are running secure OSs patched constantly. I guess they are running OpenBSD with default config then... ...except there are mentions of "Active Directory", so I guess not.

Only real "innovation" comes at the end: The article states that they are running some sort of IDS/IDP system in their network, presumbaly monitoring for any wormlike packets. This is nothing too interesting, anybody can set up Snort and have it running at your switch's monitor port. Only thing is that if it is running only as a logger, it cannot really react fast enough if one of your boxes gets infected with the latest worm from the completely unsecured Internet connection.

If it is running in some sort of transparent bridging mode, where it blocks those packets too on detection, it is pretty much like any...you guessed it...FIREWALL.

He DOES have a point on the fact that numerous applications require intelligent firewalls, the most basic case of course being active FTP. However, almost any commercial firewall (and Linux kernel iptables) supports numerous protocols. Most recent additions are SIP. P2P protocols are prominently missing so far, but I'm guessing that at least Bittorrent will be added soon (at least to Cisco IOS/PIX and Checkpoint).

Still, I wouldn't give too much credit for this article until he provides us with a detailed network diagram and more specifically states what are the exact benefits.

Seems overkill...

[MrDomino]

The post proposes a pretty novel solution---maintain separate hosts for each server---but it seems really inefficient. I mean, Xen as I understand it will run full operating systems in each of its virtual domains, including separate kernels and whatever else the system needs running.

Why not just work with chroot jails? They accomplish the same thing---keeping things isolated from dangerous interaction with the rest of the system---but without the ridiculous performance overhead of running entire and discrete systems for each service provided.

Defense in depth.

[!ramirez]

This concept can largely be summed up as 'defense in depth'. You use multiple layers to defend that which you value the most.

Saying 'I have secured my OS, I no longer need a firewall' is like saying 'I have an airbag, thus I do not need this seatbelt'. One complements the other.

Its always a risk/reward analysis

[Danathar]

As always the amount of security you deploy depends on the risk level you are willing take and the amount of work/money you are willing to spend.

At the organization I have we have NO firewall because it is designed as an environment for the deployment of services (videoconferencing, ect..) and users who need unrestricted network access to the outside world. The security policy is written so that the user is completely in charge of their system. If it becomes comprimised and we find out about it...it's disconnected.

Networks rarely are compromised but the edge devices ARE. With the exception of some vulnerabilities in routers of late, networks do what they are supposed to do.

It's NOT nework security....it should NOT be the job of the network to protect hosts from themselves. It's HOST security and the people in charge of the HOSTS are responsible. "Not my fault" you say? Windows is insecure? It's precisely this mindset which has isolated MS for so long and pushed the responsibility back on the network admins that have kept microsoft (and OS vendors in general) and application developers from being serious about securing their systems and applications.

Weve been tricked...

[j_kenpo]

"Your not Stuart Berman, your really social engineering expert Kevin Mitnick, and you almost tricked everyone into taking down their firewalls".

"And I would have gotten away with it if it wasn't for you nosey Slashdotters!"

At the risk of being redundant

[davidwr]

As others have already said, "why not do both"?

Without a firewall to block incoming-random-port traffic, client machines are still vulnerable to day-zero open-port vulnerabilities. Granted, a software firewall SHOULD prevent this but a second, independent firewall helps.

What this guy is doing is A Very Good Thing, but there's no need to turn off those external firewalls completely.

My rating of the original article:
Informative, but overstated.

Too smart for their own good

[lheal]

As a previous poster said, why not do both?

They've taken a nugget of insight, that the reliance on a firewall can make you sloppy, and built a whole mountain of security policy on it. Trouble is, that's upside down architecture.

Good security is about building up as many layers as you can that are easier on you than on your attacker. The goal isn't to be impenetrable, it's to look like too much work so the attacker goes away.

We have a firewall so that we CAN be a little sloppy inside if needed. It's the balance between security and usability. It doesn't mean you rely solely on the firewall. It means that the "firewall", which you should treat more like a window screen, is just another layer of defense.

And when everyone else has a firewall, your unfirewalled network stands out like a house with no window screens.

There is another big picture here, too. If everyone has a firewall, having one doesn't make you look like you've got something to hide. If only 1% of networks were protected, then your firewall makes you look suspicious.

So thanks, but quit telling people they shouldn't use a firewall. Some of them might take your advice.

This is better?

[Transcendent]

Meanwhile, the clients sit in the clear. We protect them by boosting their immunity levels so that they can exist in harsher conditions. They run secure OSs, fully patched with current anti-virus protection. We assign each user a central identity, which is authenticated and validated before accessing the internal DMZ. We use central directories to manage identity privileges and PKI certificates. Existing systems, such as Active Directory, allow for low-cost private certificate authorities where PKI isn't well-established. We also log and monitor the activity and enforce acceptable application behavior.

Sounds like a pain in the ass to me...

Frankly, there's too many damn buzzwords.

Why Choose?

[Doc Ruby]

Do both. Eliminating their firewall was just the motivation to do more comprehensive security work. That motivation should come from IT management, and self-interest in preparing a manageable system, rather than fighting fires. Every insecure part of a system should be secured. A firewall has a unique role in providing a good amount of cover for an entire organization for its cost. Especially valuable when making changes to security configurations, which might temporarily expose resources in the transition.

Multiple layers

[Digital Pizza]

OK, I haven't read the article (I'm on Slashdot, after all), so maybe I misunderstood the article post (they are often misleading). What the hell is wrong with having multiple layers of security? That's what's been preached for years now, and it makes sense,

Of course one should strive for having one's servers secure enough to stand on their own in case someone breaks through the firewall, and also because attacks can come from within. You don't need to remove your firewall to do that, however; use your imagination! What happenes if there's a flaw in the server's built in security? Bugs have been known to happen. Paranoia becomes a wonderful trait when you're dealing with network securiity.

So a firewall is that much extra work; boo hoo!

IP address wastage

[whoever57]

Unless we all move to IPv6, his proposal cannot be widely implemented, since it appears to do away with NAT and hence all "clients" must have their own routable IP address.

Re:I don't run a firewall

[ravenspear]

That is a rather bold statement. Have any evidence to back it up?

I can think of a few instances where you would still be vulnerable without a firewall, like if there was an exploit discovered in the network stack of the OS.

security wants redundancy

[wotevah]

Before everyone starts posting "I've been doing that for ten years" and "of course, firewalls are teh suk", let me say that while TFA does make some good points (about "perceived safety" of firewalls), I still do not see any way that its conclusion would be correct.

First off, redundancy in security is good. You want multiple layers of security. It does not make sense to remove a layer just because you installed a different (non-overlapping) mechanism in place.

Second, firewalls are a policy enforcement mechanism, and a single point of control. Under stress it is much easier to control access from a firewall than the eclectic mix of machines behind it. The point needs to be made that while securing each machine is a good idea, that should not be done to replace the firewall.

Visible services can't be assumed to be bulletproof. Compromising the frontend machines can result in them becoming rogue agents (DDOS and whatnot). Firewalls attempt to mitigate this risk by blocking outgoing access and thus rendering the network less useful to the attacker. Without a firewall, well...

The network of machines is secure today, after a lot of careful design work. Is it stable ? Will it still be secure after the next site upgrade ?

While more complex systems can occasionally be more secure by their inherent obfuscation, verifying such systems from the inside is also difficult, but manageable given the manpower. When the security components are mutable though (they are OS services and custom software which are upgraded often), the complexity of the system works against us, making it that much harder to verify that all the combinations still result in a secure system. Not to mention that the machine verification involves application-level checking which is either laborious or impossible for the network admin to do.

From TFA: Meanwhile, the clients sit in the clear. We protect them by boosting their immunity levels so that they can exist in harsher conditions. They run secure OSs, fully patched with current anti-virus protection.

So our definition of a secure OS is Windows (what other OS needs to have "current anti-virus protection"). That sure explains a lot. I suppose those machines wouldn't happen to have the firewall enabled, would they ?

What has you chained to your firewall?

[the_quark]

Two words: Regulatory Compliance. Thanks to standards like CISP (the Visa security standard) and SAS-70 (the accounting standard), HIPPA (the medical privacy standard), firewalls are mandated for many US businesses, even small ones.

At my last company, we didn't have a firewall on the website, because my philosophy was "I'm running port scanning to make sure 22, 80 and 443 are the only ports listening on the boxes - why should I put a firewall in front of it to only let those ports through?"

Unfortunately, now, if you don't have a firewall, you're not in compliance. It's simply a cost of doing business - the security concerns are completely irellevent.

Obviously, you should be building your networks so they would work without firewalls - that's a lot more secure. But, unfortunately, you can't just throw the firewalls out even if you don't need them.

Does SANE support the Scanmaker 4850 yet?

[tepples]

And if you have processes running and listening on ports that you don't want or need, why are you running them?

Because the operating system that you run is incapable of turning them off, and no other operating system is compatible with a mission-critical application or hardware device?

Re:Does SANE support the Scanmaker 4850 yet?

[jacksonj04]

Oh for mod points.

Also, firewalls are good for if you have networks which need to do a lot of internal talking on potentially hazardous ports, but don't want the rest of the world to talk on those ports. Think big application platforms.

Re:no firewall?

[Master of Transhuman]

What part of TFA didn't you read? This one?

"The first tier consists of presentation servers such as Web and e-mail servers--these are the only servers accessible to end users."

What part of "presentation" didn't you understand? The clients access their apps via these servers. Everything else is in a (two tier)protected server ring accessible only from the presentation servers themselves. Thus, clients do NOT need to access the critical application, and especially the database (where the corporate data hacking targets actually are), servers.

Now I'd still like to see that the presentation apps can't be compromised, but that's what the Application firewalls and application monitoring referenced in TFA is supposed to accomplish.

Re:Address translation

[JamesTRexx]

Not only that, the firewall I use doesn't only do NAT for the machines inside, but it seperates my network into the regular internal network, DMZ, and the wireless network, making sure traffic like http, smtp, ftp goes from the outside to the right server inside, but also keeps unwanted traffic going from one internal network to the other.
If you only have one public ip address but more than one (virtual) server, you need a firewall or router.

Firewalls offload the servers and save big bux.

[Ungrounded Lightning]

[...] firewalls are of any use only if: [your server farm has one of this set of problems]

Beg to differ.

Firewalls unload the server from spending cycles on filtering rules and memory on surviving DDoS attacks, just to name two functions.

If the servers must do their own filtering, and you have enough load that you need more than one to get everything done, offloading the filtering to a separate machine means that you need less servers. The gain is not linear, too: Keeping multiple servers synchronized (espeically those changing database state due to the transactions they serve) is an extra load, which becomes a lower fraction of the transaction cost when the server count is smaller.

Separating the functions also means that the machines can be specialized for their work - with, for instance, hardware accelleration for attack detection on the firewall - drastically cutting the box count. Putting all the eggs in a single basket means accelleartors get less usage, since they're used only for a fraction of the machines' load. Meanwhile you need more accellerators to put one on each machine - or you're stuck with using a GP machine to do the work, at much lower efficiency and a much higher box count.

Accellerators may only be available for appliance firewall solutions, not for upgrading a machine optimized for database handling or other server tasks.

If you have a license fee for the server software, having more servers means more licenses to buy. Another cost savings from specialization - this time a big one. If both the server and firewall software is licensed you have to have licenses for BOTH on ALL machines, rather than one or the other on each machine.

If you need content filtering against specific identified attacks, you need a service from a specialist organization, to track new attacks as they arise and upgrade the filtering functions. You don't want an outside house tweaking the machines which contain your own proprietary data.

Separate machines also means separate software. The firewall software can be written by people focusing JUST on secure and efficient firewalling, the server software by people focusing on efficient transaction service. Do a combined box and your firewalling functinality is just one of a bundle of functions being handled by a software team - in the server and/or the supporting system. (You only have to look at Microsoft to see the level of security produced by the latter approach.)

I could go on. But any one of the above points, by itself, shows an advantage for the separate firewall/server approach in a commercial scale, commercial grade, service. Combine them all (and others I haven't mentined) and the argument is compelling.

Not an Innovator; Just a Contrarian

[sabat]

I have heard this guy propose his nonsense in person. This is a classic case of throwing the baby out of the bathwater; his proposition summarizes as "firewalls aren't a silver bullet, so they're worthless."

He proposes that we secure all individual boxes, which is umpteen times more difficult, more time-consuming, and less secure.

He's not an innovator; he's a contrarian.

Re:How exactly are ACLs on a switch different?

[gambler2073]

This is how I see the difference...Where a router ACL filters ip address and ports, a firewall can do much more i.e. they inspect application layers for RFC compliance/attack patterns, authenticate users, and log permitted & denied traffic (its nice to know who's trying to screw your systems after all...) Find a router that can do all this across more than 100 ACL entries and then maintain a decent level of performance then your laughing, but only the modern high kit is starting to get close. If ACL's in routers were efficient then surely Cisco wouldn't produce a firewall blade for their high end routers.

I've been working in the network security field for most of my career and advocate the layered/defence in depth approach, but I suggest anyone relying on router ACL's consider their requirements first. Personally I prefer firewalls on the edge of the network with lots of application layer filtering (i.e. proxies, SMTP scanning etc) to keep all the nasty stuff away, and simple (to keep maintenance easy and processing overhead low)ACL's for any internal segregation. Naturally I look at host based security as well, but that's for another post in the future.

Re:What has you chained to your firewall?

[Shanep]

...my philosophy was "I'm running port scanning to make sure 22, 80 and 443 are the only ports listening on the boxes - why should I put a firewall in front of it to only let those ports through? ... But, unfortunately, you can't just throw the firewalls out even if you don't need them.

But you do need them. You should assume that your servers will get rooted, in which case they may soon be listening on any other ports and initiating connections to anywhere also on any port, or even DoS'ing the rest of your internal machines or worse still machines external to your network.

The power of a dedicated firewall, is that since it may be dedicated to tasks such as segmenting networks, packet filtering, prioritization and bandwidth shaping, but with no accessible service, it is highly unlikely to become rooted and thus is perfect for enforcement of rules or even damage control should a machine become rooted.

You can do so much with a dedicated firewall and whatever you do, it will not just get disabled once an externally reachable service gets rooted.