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?"
But it is still more expensive than a software firewall in terms of resources. Do I really need that expense for my webserver? Not if I'm someone who's not collecting money or other personal data.
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?
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
Which is what netstat -at and firewalls do...
Dawn of the Dead
- 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?The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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
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.
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.
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.
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.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
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.
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.
--
make install -not war
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!
We apologize for the inconvenience.
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.
The real "Libtards" are the Libertarians!
And if you think I'm kidding, that's what our company does with SQLServer. Microsoft's a wonderful business partner, introducing us to most of our larger customers; so we ship our "sql server based" version of our product to them. However SQLServer merely contains a practically unused copy of the working set of data in our postgresql database that the application runs off of. (posting as AC, because I very very much appreciate their customer introductions, and wouldn't want to get them mad)
when i first heard about firewalls a decade ago i thought "heh, thats a cool name for a lazy hack". the need for firewalls comes from the crazy overdesign of operating systems. seriously, how many people use the rpc or dcom functions of windows? or use linux rpc for much more than nfs?
for me, a gentoo box that hasn't been around or played with long enough to have servers i don't remember running on it is easily safe enough to put up naked on the net. true, i will echo icmp and a few other in-kernel protocols, but how many script kiddies (and really thats what most of us are hiding from, maybe enterprises have targetted attacks, or that geek whose sister you hit on) will go any farther than "sh apache_vuln_109123_kit.sh" and sit back?
btw, if you are being cased by people who targetted you, this strategy won't cover you that well, but neither will a half-assed firewall.
the word "firewall" really sounds cool if you don't know what it means, but it's a lot smarter to just not bind insecure servers to your outbound interface. a firewall is basically saying "i have no clue whats running on this box, so ill just stop everything", which is fine, but for a serious production server thats not the right attitude to have.
for windows, or a specialized application that's hard to secure and/or uses a few ports, yeah it's the right solution. theoretically you could probably disable all the stupid services in windows to make a bulletproof box, but you'd still have patches and 0-day vulns to deal with.
do have to give this guy credit for the xenSE angle. someday when lizards rule the earth from their giant underground caves, and the mach kernel is usable natively for an os (i know osx, but thats more a hack), maybe we can have that kind of security in all computers without having to partition it into 5 different run-time images. i tend to say things like that about every 5 years, before i give up and get drunk instead.
ps. someone should make a process audit call that allows you to restrict userspace processes to given interfaces or bind addresses, so those little apps that are written to bind to ANY_ADDRESS are forced to a programmed one instead. even a post-fork, pre-exec type call would be nice, so all shell children are restricted. you could even have outbound servers running on one intf, and other people using firefox or other clients on another interface with different routing.
The first rule of USENET is you do not talk about USENET.
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.
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.
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?
ACLs DO NOT compare to what any modern firewall does. Using TCP as an example (since that's what most traffic is), an ACL lets you check the source and destination IP, and a source/destination TCP port. If a packet matches what's allowed, the packet is allowed through.
What an ACL doesn't do that any reasonable "stateful" firewall does is keep track of what sessions are active and then ensure that incoming traffic is part of an existing session, contains valid TCP headers, and is not just a rogue user trying to do a DoS attack. Firewalls will track sequence numbers, look for SYN attacks, sometimes do reverse-path checking to give some level of automatic anti-spoofing prevention.
That being said, a firewall is only ONE level of security, and sometimes gives companies and users a false sense of security. A firewall does no good if you allow a connection to port 80 on an unpatched IIS-Windows NT 4.0 box (unless the firewall is looking for attack signatures, but even then you're not 100% protected).
Any good security solution requires disciplened design of a network and maintenance of hosts, with multiple levels of protection (anti-virus, firewalling, shutting down unnecessary services, patching, etc.)
Also, security is very different for different applications - Google will have different security needs from the DoD's private systems, so please remember this before all you network administrators out there go and remove your firewalls.
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.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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.
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.
home
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
No. That requires user knowledge and attention, the failure case is that the human will make a mistake, and the failure case is likely to happen frequently.
Typical security mistake - you've ignored the human aspect of security and come up with a design that is less secure.
The correct model is one that prevents infections, not one that detects infections. An ounce of prevention...