The best way to utilize flexibility of Firewall Builder and minimize risk is to run it on a dedicated management workstation. This workstation is going to have the near-full installation of Linux or FreeBSD, complete with X11 and Gnome or KDE.
It is not a good idea to run X11 and Gnome or KDE on the firewall machine because they are very complex services using complex protocols. Another advantage of running fwbuilder on a dedicated management workstation is that you can then manage multiple firewalls from it. This may not be so important for someone who uses it to configure a firewall on their DSL or cable connection at home, but people who use fwbuilder in an enterprise environment may appreciate that.
The reason we do not recommend running X11 and GUI environment on the firewall is actually rather simple. It is well known that complex programs are more prone to errors than simple and short ones. X11 and GUI environments are very complex programs, in size rivaling the Linux kernel or exceeding it. Granted, you may be safe even if you run these on the firewall provided you install all latest patches and keep your software up-to-date. This, however, means a lot of effort and time should be spent on maintaining software which is not essential to the operation of the firewall and is being used only once in a while. You may add protection using firewall rules to block all access to the firewall itself from outside (a very good idea regardless whether you run X11 on it), but then you need to carefully watch your policy to make sure you won't drop these rules accidentally. The rules may get more complex if you ever need to manage your firewall remotely, making verification difficult. All this adds up to the risk factor, so it is just a lot simpler to not have X11 and GUI on the firewall at all.
In other words, run X11 and GUI environment on the firewall machine only when you know what you are doing, and keep an open eye on it.
We will look at configuration of the dedicated firewall machine and then at configuration of the management workstation.
The choice of the hardware for the firewall depends on how much bandwidth the network it protects needs. In my experience, Pentium-II or Celeron machine running at 233 MHz or above is more than enough for a group of 2-5 people doing regular web surfing, sending and receiving email and doing some other not very demanding tasks. I ran firewalls like that at various times using Linux/iptables, FreeBSD/ipfilter and OpenBSD/pf combinations and can't say that any particular platform has better performance. They all just work. Firewall like this won't slow down file transfer on a DSL or a cable network, easily supporting download speeds of 1.5 - 2 Mbit/sec. Since hardware like this is very obsolete and can be had for almost nothing, I never saw a need to investigate which OS and firewall performs better on a slower CPU. People had good results using old notebooks as their firewalls, too. The advantage of the notebook is that is has a monitor which makes troubleshooting easier in case you make a mistake in the policy rules and block your own access to the firewall over the network.
For a larger installation (more people or long policy) faster CPU is needed.
The OS installed on the firewall machine should be minimal. Basically, all you need is the kernel, basic tools usually found in /bin and ssh. This is true regardless of what OS you choose, so just follow installation instructions appropriate for it. Do not install development tools, X11, editors, graphics software etc and you are going to be fine. Make sure you get ssh though, also in some cases you may need perl.
Once you install the firewall machine, check if ssh daemon is running. It usually is, but some OS have different installation options and if you choose “workstation” install, they may not start ssh daemon automatically. Use command “ps -ax | grep sshd” to check if the daemon is running, and if it is not, activate it.
Several projects came up with a decent distributions intended for a small diskless router/firewall. I personally have experience with floppyfw and Devil Linux, consequently Firewall Builder has policy install scripts for these. The advantage of using either one of these is that you won't have to install OS and software on the firewall machine; you just pop floppy or a CDrom in it and boot from it. This is as close as it comes to the firewall appliance, yet you get a modern Linux kernel and iptables with both. The whole OS is stored on the write-protected media and can be easily replaced or upgraded simply by changing the disk. Floppy FW comes on a single floppy, these guys managed to pack kernel, a busybox application and bunch of other programs on a single compressed ram disk. You don't get ssh with floppyfw though. The firewall configuration is located in a text file that can be edited off-line and then written to the floppy. Firewall Builder's install script also writes firewall policy to this floppy when you call main menu item “Rules/Install”. Once configuration is written to the floppy, you insert it in the firewall and reboot. That's it.
Devil Linux comes on the CDrom and obviously has lot more stuff on it. They also keep configuration on a floppy disk. Firewall Builder's install script writes firewall policy on this floppy, which you then need to insert in the firewall. See detailed documentation on using Devil Linux on their web site here.
The management workstation runs fwbuilder, so it needs X11 and all other libraries fwbuilder depends upon. Follow Installation instructions to install fwbuilder on the machine. Try to start fwbuilder by typing “fwbuilder” in a shell prompt to test it.
The management station uses ssh to communicate with the firewall, so first thing to do is to make sure it works. Try to ssh from the workstation to the firewall as user root:
$ ssh -l root firewall_machine_name
Since this is going to be the very first time you use ssh to connect to the firewall from the new workstation, it should ask you whether you want to accept firewall's host key. You should say “yes” if you are sure you are connecting to the right machine. This makes your workstation remember firewall's host key, so that if it ever gets a different key, it will warn you. This mechanism is what protects ssh communication from so called “man in the middle” attack. Once you accepted the key, ssh should put you into the shell prompt on the firewall. If you do not get there even though you type correct password, the root login may be disabled in sshd configuration on the firewall. To enable it you need to edit file /etc/ssh/sshd_config on the firewall, see if the line like this is there and uncomment it if it is commented out:
#PermitRootLogin yes
now send SIGHUP signal to the sshd daemon on the firewall and try to connect again.
Once you've made sure you can communicate with the firewall using ssh, you should follow instructions on using fwb_install script that is used to install and activate firewall policy remotely.
Copyright © 2000-2008 NetCitadel, LLC. All rights reserved.
Free CSS Templates.