self made firewall specs

[groovin]

With all the solid state firewalls like sonic charging license fees for device usage, I think I am going to build a firewall using IPtables and linux. I already know the pros and cons of solid state vs in-house built, but now I was wondering if anyone else has built something similar for a network of 100-150 users. Traffic going in and out of our network is very light, a mail server, and a web server that serves maybe 10-20 requests per day. Our connection is a T1.

What I am thinking is:
PIII 450 w/ Intel chipset board
10-20 GB HD
512MB-1GB RAM PC100
2 Intel NICs

I will have some kind of failover set up as well with a system of comparable specs.

Do you think this would suffice?

thanks

 

[Poontos]

That will suffice hardware-wise. Software-wise, IPTables I do not recommend unless you are already familar with IPTables and Linux, otherwise I would highly recommend:

FreeBSD w/ IPFW
]http://www.onlamp.com/pub/a/bsd/2001/04/25/FreeBSD_Basics.html


OpenBSD w/ IPFilter or PF
http://www.onlamp.com/pub/a/bsd/2000/07/05/OpenBSD.html
http://www.onlamp.com/pub/a/bsd/2002/02/28/openbsd.html

These are some excellent tutorials, with many more on the site.

Good luck!

 

[chsh1ca]

Well, I'm running one here, and let's just put it this way, I was paranoid to the point of going overboard on the hardware.
I put together an Athlon MP 1800+ on a Tyan Thunder board, with 512MB DDR333 SDRAM, and a cheap 20GB HDD, with 6 NICs + 1 onboard (explain that if you really want me to).

CPU states: 0.0% user, 0.2% system, 0.0% nice, 99.8% idle

Needless to say, it's a bit overkill. We only have some 25 users here though, however we do service ~1600 salespeople outside the main office here who use an in-house application that generates a bit of traffic through this machine.

The Nics are mostly for DMZ purposes. We've got one DMZ for the webservers, one for the DB servers, one for our PA machines, etc..

The PIII/450 should be enough to handle it, but hey, if it's not, you can always pump it up to a 1GHz PIII, right? 🙂

Poontos, outta curiosity, why would you not recommend Iptables? For pf, I understand it has english-word rules (big help), but at the same time, functionally it doesn't provide anything that iptables doesn't, right?

 

[skyking]

A p200, and 64 mb of ram is sufficient. Passing traffic and running a set of firewall rules is not processor intensive. Think reliablity, rather than raw computing power, when you think of a firewall hardware specs. For instance, a passively cooled cpu has 1 less thing that can fail. My setup is a p120 and 32 mb of ram, with a webserver and up to 8 users ( LAN Party ). Throughput was never an issue, up to the limits of my 1Mbit cable connection.
I'm running freebsd's firewall, IPFW.

 

[groovin]

thanks for the replies...

I like IPPF on openBSD the best... its easy to use, powerful, and runs on a secure OS. OpenBSD is a pain to install though sometimes and I cant get lots of software to work on it (I guess I dont know enough about openBSD yet).

I want to use linux because iptables is pretty powerful if you understand it (i dont yet, but i have a good rule set ready to go) and I want to put other things on this box like squid... and that might be easier to upkeep on linux than openBSD.

 

[skyking]

A basic tenet of firewall usage is never put anything else on a firewall box. It is kinda like having your gatekeeper sell Avon and Tupperware on the side, bound to be some security hole or conflict of interest. My box is doing DHCP at the moment, but i should really move that over to another server.

 

[groovin]

"A basic tenet of firewall usage is never put anything else on a firewall box. It is kinda like having your gatekeeper sell Avon and Tupperware on the side, bound to be some security hole or conflict of interest. My box is doing DHCP at the moment, but i should really move that over to another server. "

im running short of boxes! =)

i know, i know... firewalls should do just that and only that

 

[skyking]

I can stick DHCP on my webserver, but laziness is kicking in........I already have that thing running samba and bind, so I know your pain😉

 

[chsh1ca]

Processor usage is a big deal if you're doing a lot of stateful inspection, but still, as I wrote, the system we have is overkill. It probably easily saturates the PCI bus on the system with data, but the processor only has 0.2% usage, and it is the DHCP server as well.

From an organization standpoint, DHCP on the firewall kinda makes sense. If I did have another box, I'd move DHCP over to it, but then, with the amount of spare processing power on that machine I'd feel like I have to run seti@home on it or something. 😀

 

[Nothinman]

I've got OpenBSD on a 167Mhz Ultra1 with 128M memory and it's 99% idle all the time. Even doing statefull inspection, logging all dropped packets, running altq (which btw doesn't work as I wanted, I need to work on that) and snort it's still mostly idle. Before this I had a P60 doing that and more and it was still adequate for me.

I may put a distributed.net client on it if I get bored and they have one done for OpenBSD on sparc64.

 

[skyking]

I've got OpenBSD on a 167Mhz Ultra1 with 128M memory and it's 99% idle all the time

No wonder, with that Sun mega- machine!
If I were really worried about capacity, I'd look at one of those 500 or 600 cyrix procs that can be passively cooled. I forget which model , but they don't put out much heat. As Nothinman, and everyone else has said, it is just not processor intensive, though. It is the perfect place for those outdated boxes, the 133's and 166's, or a nice old sparqstation.

 

[dzeanah]

A p200, and 64 mb of ram is sufficient.

Yep. Had a P-90/64M box running IPCop for a while that passed traffic surprisingly fast (2 Mbit down). The kid down the block is using it now -- he's getting lower ping times than all his friends in CS so he's happy with it. 😉

Think reliablity, rather than raw computing power, when you think of a firewall hardware specs.

Yep.

When I was using that box as a firewall I started to get intermittent connection problems that I blamed on Bellsouth; turned out my hard drive was failing.

What you're getting when you're paying for a firewall appliance is convenience, reliability, a well-tested solution (depending on who you buy from), simple management (not talking about Pix boxes!), and easy upgrades. That comes at a cost.

But then, it's nice to do things like set up your clients firewalls to open a vpn tunnel to your box so you can admin from home, and allow Windows users to VPN in without a whole lot of headaches, etc. It's all doable on a Linux box, and the Linux box is arguably a better solution, but it's (in many cases) more expensive that way.

A Sonicwall Pro 200 is pretty chintzy if you're just looking at the specs -- 233MHz processor, 16M RAM, 4M flash (these are approximate) -- and it's expensive with $1,500 being about the best price you'll find on the web. But if you're going to be implementing VPN's that need to be reliable, and you want something a client or assistant can't accidentally screw up, and you want to set it up as part of a failover pair, it starts to look pretty nice. If you add in the time you're going to need to put in to set up and admin the box (esp if something fails), it starts to look a whole lot nicer. If you're working in a field where you might need the defensability of saying "we did everything we could -- that firewall had ICSA Lab's stamp of approval!," then it starts to look really cheap.

Let's just say there's a reason most businesses choose to go with expensive "router appliances" when a Linux box with a couple of interfaces would do the job just as well. 😉

If you're going to use Linux, I'd say grab one of the firewall-based distros (Smoothwall, IP Cop, Mandrake Multi Network Firewall) because you know they're going to work, and they'll offer an interface that anyone at your company can use to admin the box. I'd also set it up on a hardware RAID of some kind -- your hard drive is the most likely thing to fail, and it sucks when your firewall craps out on you.

 

[skyking]

Yes indeed, I had a drive failure knock mine out also, using very old small drives. I do not have a raid setup, but I did ghost my latest config onto another drive, and parked it in the box, ready to hook up.
That will work for me, since 99.9999995% of the time I am not remoting into here, and I can fix the problem myself.
On the other hand, it is unacceptable for a real business network to go down for a two-bit hard drive.

 

[Nothinman]

My old setup was a P60, the drive started failing but it didn't interrupt my connection.

I wouldn't worry about RAID personally, because the only thing changing day to day on the box will be the logs and you can use syslog to put them on another box. I would just get 1 full backup and only setup a mirror if you need 100% uptime incase one drive fails at night. Even Linux software RAID can do that and would save cash on a hardware RAID card.

 

[kt]

Originally posted by: chsh1ca
Well, I'm running one here, and let's just put it this way, I was paranoid to the point of going overboard on the hardware.
I put together an Athlon MP 1800+ on a Tyan Thunder board, with 512MB DDR333 SDRAM, and a cheap 20GB HDD, with 6 NICs + 1 onboard (explain that if you really want me to).

CPU states: 0.0% user, 0.2% system, 0.0% nice, 99.8% idle

Needless to say, it's a bit overkill. We only have some 25 users here though, however we do service ~1600 salespeople outside the main office here who use an in-house application that generates a bit of traffic through this machine.

The Nics are mostly for DMZ purposes. We've got one DMZ for the webservers, one for the DB servers, one for our PA machines, etc..

The PIII/450 should be enough to handle it, but hey, if it's not, you can always pump it up to a 1GHz PIII, right? 🙂

Poontos, outta curiosity, why would you not recommend Iptables? For pf, I understand it has english-word rules (big help), but at the same time, functionally it doesn't provide anything that iptables doesn't, right?

Out of curiousity, why do you need so many DMZ?

 

[n0cmonkey]

Originally posted by: chsh1ca

Poontos, outta curiosity, why would you not recommend Iptables? For pf, I understand it has english-word rules (big help), but at the same time, functionally it doesn't provide anything that iptables doesn't, right?

Some of PF's features (I know almost nothing about IPTables, someone else can compare it's features to these):
You can use variables in the easy to read config file.
Normalization of packets (fixes packet defrag problems).
Scrubbing (some OSes have crappy random ISNs and whatnot, this fixes that).
Proper stateful inspection (as of the last time I checked, IPTables did not have this).
PF appears to perform better for stateful filtering.
spamd (spam stopping software built into the firewall).

 

[Nothinman]

You can use variables in the easy to read config file.

iptables config file would just be a shell script, so any thing you can do in sh you can do in the iptables config including variables, external commands, etc.

Proper stateful inspection (as of the last time I checked, IPTables did not have this).

IPTable and IPChains do statefull inspection. Add to that special protocol kernel modules for things like irc (dcc), ftp, etc and it makes something 'just work' that need extra setup with pf.

spamd (spam stopping software built into the firewall).

IMHO that just seems like bloat, that should be done at the MTA or MUA level.

 

[n0cmonkey]

Originally posted by: Nothinman

You can use variables in the easy to read config file.

iptables config file would just be a shell script, so any thing you can do in sh you can do in the iptables config including variables, external commands, etc.

Proper stateful inspection (as of the last time I checked, IPTables did not have this).

IPTable and IPChains do statefull inspection.

Do IPTables and IPChains now check the sequence numbers of all packets and not just the sequence numbers of the TCP handshake?

Add to that special protocol kernel modules for things like irc (dcc), ftp, etc and it makes something 'just work' that need extra setup with pf.

Doesn't PF have an ftp proxy or something that makes ftp easier? I have never had any problems with this stuff, but I don't DCC.

spamd (spam stopping software built into the firewall).

IMHO that just seems like bloat, that should be done at the MTA or MUA level.

Maybe, but I love the idea.

 

[Nothinman]

Do IPTables and IPChains now check the sequence numbers of all packets and not just the sequence numbers of the TCP handshake?

I'm not sure about IPChains but IPTables is pretty thorough. I havn't gone through the code so I'm not sure, but it's smart enough to be able to discern 'related' packets, infact to apply rules to the rest of a stream you use the --related switch.

Doesn't PF have an ftp proxy or something that makes ftp easier? I have never had any problems with this stuff, but I don't DCC.

A proxy doesn't count. Linux has a kernel module that changes the packets without any intervention, any PORT command gets the internal IP changed to the firewall's external address and the firewall associates that port with the internal host so when the ftp server connects it forwards the connection and noone knows anything is going on.

Maybe, but I love the idea.

I don't. I'd rather just have sendmail or procmail kill the msg.

 

[n0cmonkey]

Originally posted by: Nothinman

Do IPTables and IPChains now check the sequence numbers of all packets and not just the sequence numbers of the TCP handshake?

I'm not sure about IPChains but IPTables is pretty thorough. I havn't gone through the code so I'm not sure, but it's smart enough to be able to discern 'related' packets, infact to apply rules to the rest of a stream you use the --related switch.

Ok, everything I have read about IPTables says it does not check the sequence numbers thoroughly enough.

Doesn't PF have an ftp proxy or something that makes ftp easier? I have never had any problems with this stuff, but I don't DCC.

A proxy doesn't count. Linux has a kernel module that changes the packets without any intervention, any PORT command gets the internal IP changed to the firewall's external address and the firewall associates that port with the internal host so when the ftp server connects it forwards the connection and noone knows anything is going on.

Ok, I guess that is a plus for IPTables.

Maybe, but I love the idea.

I don't. I'd rather just have sendmail or procmail kill the msg.

I would rather my firewall, which is not very busy, kill those connections before they get to the mail server, and eat up some resources on the spammer's side. But, like many problems in the Internet age, there are many solutions. 🙂

 

[Nothinman]

Ok, everything I have read about IPTables says it does not check the sequence numbers thoroughly enough.

I'm sure it doesn't do OpenBSD's ISN randomization, but one of the major features over IPChains was real statefull inspection.

Ok, I guess that is a plus for IPTables.

FTP isn't the only module available too, theres even one for q3 so that more than one person can play on the same server at the same time. Usually since q3 uses udp and the same port you can only have 1 client NAT'd to the server at the same time. I even saw a module for NAT of AH/ESP packets so that VPN tunnels can be initiated behind the NAT.

I would rather my firewall, which is not very busy, kill those connections before they get to the mail server, and eat up some resources on the spammer's side. But, like many problems in the Internet age, there are many solutions

But how does it discern without parsing the mail headers and I really wouldn't want something like that in the kernel.

 

[n0cmonkey]

Originally posted by: Nothinman

Ok, everything I have read about IPTables says it does not check the sequence numbers thoroughly enough.

I'm sure it doesn't do OpenBSD's ISN randomization, but one of the major features over IPChains was real statefull inspection.

Paper mentioning IPTables not inspecting sequence numbers thoroughly (near the bottom).

I would rather my firewall, which is not very busy, kill those connections before they get to the mail server, and eat up some resources on the spammer's side. But, like many problems in the Internet age, there are many solutions

But how does it discern without parsing the mail headers and I really wouldn't want something like that in the kernel.

spamd is not actually part of the firewall. I'm not sure why I thought it was... Oops.

 

[chsh1ca]

Originally posted by: kt
Out of curiousity, why do you need so many DMZ?

Well for one, we get a lot of foot traffic and have some rather unsecured areas. The network is broken down into five separate networks, plus our two external networks (one being the internet), which aren't on a DMZ.

1. Main workstations network. Allowed to surf the net, IRC, etc., etc.. Cannot connect to any of the other six networks (excepting the 'net) apart from the webservers, wherein they can only connect on TCP/80 and TCP/443.

2. Webservers network. Allowed to serve TCP/80, TCP/443, but not allowed to generate its own outbound connections on any port other than TCP/1433 (SQL) bound for our DB server network. Meaning it is sort of in reply-only mode.

3. DB server network. Allowed to serve TCP/1433, but not allowed to generate its own outbound connections at all.

4. Public Access PC network. Allowed to surf the 'net (80/443 only) and to our internal webservers (80/443 only). All other access is denied.

5. Roaming network. Unused at the moment, we're planning some testing for wireless APs + mobile laptops.

6. Untrustable friendly network. Just a WAN connection to another network which provides us with a business service in the form of electronic data feeds.

7. Internet.

Essentially, I don't want any of the machines in each segment talking to one another at all. It was easier and more secure to simply physically separate them. That, and the two that should most definitely have been DMZed had separate requirements from the rest of the network. For instance, we need a guaranteed 1Gbps bandwidth from the webserver network to the DB server network, whereas the other networks we really don't care about.

Originally posted by: n0cmonkey
Some of PF's features (I know almost nothing about IPTables, someone else can compare it's features to these):
You can use variables in the easy to read config file.

- Iptables is much stronger then, since you can (and most do) use a script for your firewall. Many use bash, but you really have the strength of any interpretable script language (perl even) at your disposal.

Normalization of packets (fixes packet defrag problems).
Scrubbing (some OSes have crappy random ISNs and whatnot, this fixes that).

Scrubbing/normalization are both covered, I think. Could be wrong.

Proper stateful inspection (as of the last time I checked, IPTables did not have this).

On your SN comment, it is possible to create rules based on info about an SN , however, it requires an additional module, as I recall. Again, working from memory here. 🙂

PF appears to perform better for stateful filtering.

Never benched either of them, so I can't comment. Either way, stateful filtering doesn't appear to be draining on any system. 🙂

spamd (spam stopping software built into the firewall).

This is a bad idea IMHO for numerous reasons. It represents a separation of layers, and is generally a bad idea. As many others have commented, it's definitely best to have a firewall only do firewalling. 🙂 That being said, I'm quite certain that pf can bet configured to not use it, so it's really irrelevant.
2.

 

[n0cmonkey]

Originally posted by: chsh1ca

spamd (spam stopping software built into the firewall).

This is a bad idea IMHO for numerous reasons. It represents a separation of layers, and is generally a bad idea. As many others have commented, it's definitely best to have a firewall only do firewalling. 🙂 That being said, I'm quite certain that pf can bet configured to not use it, so it's really irrelevant.
2.

I mentioned that I was misunderstanding spamd.

 

[Nothinman]

Paper mentioning IPTables not inspecting sequence numbers thoroughly (near the bottom).

It says that, but I don't know if it's true. If I get some time I'll see if I can find the connection tracking code in netfilter and see if it's really true.

spamd is not actually part of the firewall. I'm not sure why I thought it was... Oops.

I guess I just don't get enough spam to care. I only looked real quick but it appeared to be host based, which seems pretty limiting to me.