Slashdot Mirror
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?"
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
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.
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).
And for windows:
netstat -v -o -n -b -a
(you can ommit -v for a quicker display)
NeoThermic
Use my link above, or to view my server, NeoThermic.com
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.
"Can of worms? The can is open... the worms are everywhere."
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.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
"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.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
[...] 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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.
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