What is the Best Firewall for Servers?
Sushant Bhatia asks: "I maintain a bunch of servers (Win 2003/XP Pro) at our labs in the university. Of late, the number of attacks on the computers has been more noticeable. The university provides firewall software (Kerio) but that doesn't work with Win 2003 (works with XP). And so we keep getting hit by zombie machines taken over in the Education Department or from Liberal Arts :-). So what does the Slashdot crowd use when they need to secure their Linux and Windows servers? Does it cost less than US$100?"
Ummm, OpenBSD of course! www.openbsd.org
http://www.smoothwall.org/
We use FreeBSD with IPF, IPFW and some home-brewn tools in our main hosting centre. We have chosen name-brand hardware and free software - already having in-depth knowledge in-house, we had no need to buy a complete black-box solution.
Of course - investing in "fresh" knowledge on FreeBSD or whichever other platform you wish to roll your own firewall/ids solution on top of - is going to be expensive. Thus this solution might not work for all...
Love over Gold.
Use OpenBSD for your firewall. It has an integrated Packet Filter that works better then most comercial products. The OS itself is secure by default, and it's free! Can't beat that!
Just use iptables on a cheap old pentium or something. Two network cards, one inside and one outside. Even a modest Pentium or Pentium II could keep up with good amounts of traffic.
IP Cop. ;)
http://www.ipcop.org/
The firewall bundled with the service pack upgrade to Server 2003 isn't too bad, but it only does incoming connections. You can exempt ports or executables.
Also, it's free.*
*Well, you know what I mean.
You are approaching the problem from a wrong direction.
There are different types of firewalls and they can be divided into these types using different criteria. However, I will use the most simple one. There are host-based and network-based firewalls. Host-based firewalls, are not very cost-effective (or even effective at all) for protecting large, medium or even small server "farms". They work fine on single-server or home machines.
The proper way to protect server farms in campus is to have secure network. Firewalls are like city walls. They offer protection, but if breached, you're doomed. Secure network consists of firewalls, segmented network (separate VLAN's, switching blocks, etc.). Excellent reference for secure network design is Cisco's SAFE Blueprint for Enterprise Networks. I would recommend reading it, even though you're not using Cisco gear.
Marko.
running OpenBSD and pf. Include another cheap box and CARP if you need redundancy/failover.
Let's get drunk and delete production data!
I don't think you'll get flamed too bad. Its what I was going to suggest. I run iptables as I'm sure many others here do. Its simple, there's lots of open source tools to make management of those rules easier, and a basic install of Linux will run on some pretty lightweight machines. Heck, there's always the distros on a CD to make things even more secure, and by putting the rules on a floppy set to read_only makes for relatively simple updates to the rules if/when needed.
It's free.
Only port forward what ports you absolutely need and keep your servers out in the DMZ. IPcop will easily allow you to seperate your network into zones with multiple nics and will likely only take a 486 or Pentium class machine to keep up with your bandwith. Hey, you asked for cheap. Doesn't get much cheaper than that.
You can also keep detailed logs and it also features a good SNORT setup for NIDS. It sets up convieniently with a web browser.
There is also Smoothwall. Both are really Linux based software firewalls. The difference is that IPCop is totally free and supports a wide variety of features that you would likely have to pay for in Smoothwall. Updating NIDS signatures automatically comes to mind.
I would personally avoid Windows software firewalls like the plague, as they run at escalated priveledges and can potentially put your system at even more risk as they add to the number of possible vulnerabilities, but that is just me.
If you can't afford a PIX or something in hardware, FreeBSD and Linux software firewalls are always the best way to go IMHO.
Happy hacking!
zosxavius photography
I'd suggest ditching a software firewall and investing in a proper hardware firewall such as Checkpoint FW1 and put all the servers behind that firewall.
Put another firewall ideally of a different type (break one you've still got another to break) and use that to isolate all the departmental computers...
Ensure the policies are locked down tight and that any changes are approved by someone who knows what they're about before being implemented.
--- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
Kerio *does* make an excellent firewall product for Windows servers (Kerio Server Firewall). It is pricey, however, and for the same or less money you could install a Smoothwall box.
Download W2K3 Service Pack 1 from Microsoft, they have the same firewall as XPSP2 plus some bonus features.
There's a "Security Configuration Wizard" that will help you config the firewall and services at a more advanced level than in XPSP2
Add wwo network cards
Add free Linux 2.4 distribution or higher
Activate netfilter and iptable
See: ttp://www.netfilter.org/
Deploy firewall using instructions in the netfilter how-tos:
See: http://www.netfilter.org/documentation/
Or, if that's too much for you, just get the equipment and add one of the pre-configured firewall Linuxes like SmoothWall (http://www.smoothwall.org/), Devil-Linux (http://www.devil-linux.org/home/index.php) or Coyote Linux (http://www.coyotelinux.com/).
No fuss, no muss.
Steven
I use ClarkConnect http://clarkconnect.org/>, which is a simple, stripped down Linux distro that makes an old PC into a server appliance.
It's really easy to install or administer, and includes a number of useful features like a proxy server (Squid), Content Filter (Dan's Guardian), etc.
If I didn't want or need the power and flexibility of a Linux server, I would be running a cheap router with NAT firewall built in.
In any case, I agree with the parent that a separate firewall is the way to go!
I second IPCop. I use it for a group of about 50 users, and I've got an uptime of almost a year. The things I like about IPCop: - It works. Well. - Free! - Lean. It doesn't have a whole lot of nonsense that you don't need. - Comes with a nice web interface. - Handles aliasing fine. That way you can have more than one IP address per physical interface. - Has a healthy support community. - Runs on a lot of hardware. I've actually got two ipcop boxes, identically configured. That way if one ever dies, I just turn the other one on and in two minutes I'm up and running again. Of course, this would add yet another single point of failure for your servers, but there's only so much you can do with $100...
It's generally considered a Good Thing to keep a firewall box separate from the actual server - that way, if your network is taking a beating, the firewall absorbs the impact, thusly not killing your server boxen.
This sig no verb.
I've used smoothwall for a while and I was very satisfied with it. But at some moment, it stopped working. The ADSL connection couldn't be established anymore.
While I think it was rather a hard disk crash and not a direct smoothwall problem, it made me feel like replacing my smoothwall with ipcop, another firewall dedicated linux distro (forked from smoothwall).
I'm very happy with ipcop at the moment, it's a bit more "customizable" than smoothwall. I know both are GPL'ed so they can both be customized to fit any purpose, but as ipcop is a 100% community-based distro, it is a bit more designed to be tweaked than smoothwall.
Check out IPCOP site
For anybody that's wondering what the answer is, assuming your proliant has 256mb then this is what you need :
mem=exactmap mem=640k@0M mem=255M@1M
For Windows? A seamless, 3' thick rebar-reinforced cement vault is preferential. It's easiest to add the machine prior to pouring the cement, I've found.
But with zombies in general, I prefer a more proactive approach: a 12 gauge shotgun loaded with 00 buck does nicely.
Seriously though. Every Windows machine should be behind an entirely seperate firewall, protecting it from everything and everything from it. A Windows machine on a public network that isn't being agressively administered is about as safe as a polish handgun.
By the description of your environment and problem, it sounds like you basically want to quarantine the humanities from the rest of campus so they don't wreak their plague of stupidity upon everyone else (this is good policy in general, I've found - humanities aren't fond of reasoned, concrete thought).
Probably the best way to do that would be to set up an IDS gateway between their networks and the rest of campus. Something from CISCO would probably be best, but I'm fairly certain you could do it with linux/BSD or another COTS solution for decreased price. Have the IDS set up to basically drop all trafic from zombied machines. When they complain to you that "their" network isn't working and that it's your fault, give them the ISP treatment: fix your machine and we'll let you back on.
Really, allowing humanities types to manage their own hardware is just a receipe for disaster. Would you let your accountant work on your car? It's not adviseable, and would likely cost you more than not having repair done at all and waiting for further problems.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Joking aside, I remember reading that pf's performance actually increases with stateful filtering vs. stateless filtering because looking up an entry in a state table is much faster than walking the ruleset for each packet. I also read that there is virtually no performance loss even with thousands of states.
Does anyone else remember the warez newbies crying that their off-the-shelf blackbox router crashes if their P2P app opens too many connections? Now you may laugh.
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
PS: that was the link I missed: http://kerneltrap.org/node/477
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
I can't speak for the linux side of things, but here's my comments for Windows.
Note that while this is easier to manage with Group Policy via Active Directory, you can use the local group policy settings and migrate them across your lab. My thoughts on this are valid for XP and 2003.
The internal firewall is your first defense, blocking all non permitted inbound random/unimportant information from reaching your machines. Tell the firewall the applications you will be using, and it will dynamically open required ports as the program needs them. This way you don't need to deal with local port management. You want this setup to prevent traffic from reaching IPsec, and for any logging purposes you may have. IPsec's current version doesn't really do packet logging, and is in no way a firewall (Although, I used it for years as a firewall with Windows 2000 and never had any ill-received problems, but they were not on critical systems either).
Use IPsec in pure authentication mode without encryption (unless you have encryption offload cards). You can use it in several ways.
All communication requires authentication:
No computer can talk to yours that is not setup properly. Period.
All inbound communication requires authentication:
All inbound traffic must authenticate or be dropped.
If you lock inbound, but not outbound, your clients can still access web resources and any other computer without issue, but you have completely prevented anyone else from initiating communication with your systems.
IPsec works like this: Generic rules (require authentication from everyone) are over-ridden by a more explicit rule (do not require authentication from whatever.system.local). Generic all IP rules are over-ridden by port rules, port rules are over-ridden by explicit IP address rules or subnet rules. Etc.
For your purpose, I would at least require all inbound traffic to require authentication by String, however this is not secure and anyone with administrator access can rip the password out of the registry. To do it securely, you need to do it by certificate or Kerberos. The kerberos implementation will require active directory, the certificate method will require a full IKE/PKI configured for your area. You do not need to buy a certificate from a place like verisign, you can do it all yourself through your own self-signed certificates. This entire process with IPsec can be automated through Active Directory, but if you don't have active directory, I believe any generic IKE/PKI server can generate valid certificates for your use. It's a lot less work on your part doing it through active directory.
IPsec policies will work between Windows 2000, XP, and 2003, however your key strength is limited based on the oldest OS you use. 2000 will only function with low keys, XP with both low and medium, and 2003 with strong keys and the two weaker keys. Also, you can set it up from strongest key generation to weakest, so 2003 will always talk to 2003 in strong, 2003 to XP in medium, 2003 to 2000 in weak. It may be possible to make IPsec work side-by-side with Linux using Freeswan, or whatever project replaced it, however I never used that program.
One last thing, if your systems are used by untrusted users, considers how possible it is to use the software restrictions built into Windows. Once that is activated and configured well, it becomes very difficult for a local user to run non-authorized software without sitting at the machine and taking it over first. Refer to rules regarding Software Restriction Policies for this.
K.
One exception to this is Coyote Linux. Not only does it not have the usual services enabled by default, nearly all of them have been stripped out. It includes just the components (such as iptables) that serve the central function of safely connecting a LAN to the Internet. And because it's so minimal, it fits on a floppy and runs on a 386 with 12MB RAM. It's no substitute for a full-featured Cisco Pix (for that you'd have to look at Coyote's big brother Wolverine), but it's worked great for me for years, both at home and in a couple offices I've worked at.
http://alternatives.rzero.com/
Trivium: logic, rhetoric, and grammar
Quadrivium: arithmetic, astronomy, geometry, and music.
So math has two of the liberal arts.
With multiple boxes, having an external facing firewall only helps so much. If one of the "protected" boxes gets infected by student activity, it'll run all over the LAN. That's part of why so many places got hit hard by the last couple Windows worms - they had firewalls and let down their internal guard and got pounded by infected internal machines, particularly when users brought in laptops that had gotten infected at home.
There's a few things to do to limit the problem:
1. As you said, have an external facing firewall.
2. Have firewalls on each individual computer.
3. Configure services to only connect to systems they actually need to talk to. (And obviously, turn off unneeded services)
4. If feasible, you can have switch level security that prevents unauthorized machines from making connections. (IE block port 135 TCP from desktop to desktop if they're only ever supposed to connect to a server.)
It is unattackable with packets addressed to it (because it has no address). It is still attackable by malformed packets traversing it. To work as filter it has to scan the packets, and if this packet scan can malfunction on special packets, there is a possible attack to the packet filter.