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

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

[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

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

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.

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

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.

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.

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.

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

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.

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.

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

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.