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?"
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.
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!
[...] 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