IPFire 2.5: Firewalls and more
IPFire is a special-purpose Linux distribution that makes it easy to set up a firewall, in particular for users that want a secure gateway between internet and their home or small business. IPFire has an administrative web interface that aims to be clear to beginners but at the same time doesn't ignore experienced users.
The project started in 2005 as an IPCop derivative, but the 2.x version moved to Linux From Scratch as its base. There's no company behind IPFire, and the project is developed by a small but active core of developers (five core developers and about a dozen 'community developers' who develop new add-ons), under the supervision of project lead Michael Tremer. The latest release is IPFire 2.5 - Core 37, based on Linux kernel 2.6.27.42.
Straightforward installation
Your author downloaded IPFire 2.5 - Core 37. The download page offers the image in various formats: an installable CD image (via HTTP or a torrent, it's only 77 MB big), images for a USB stick, flash images for embedded x86 devices, and an image to run as a Xen guest.
IPFire has rather modest system requirements, but it's too heavy for real embedded use. A Pentium-class processor is the minimum, with a recommended clock frequency of at least 333 Mhz. The distribution requires 128 MB RAM but recommends 512 MB. The hard drive needs 1 GB, but 2 GB is recommended because of the need for log files. Of course if the firewall also acts as a file server, the hard drive should be much bigger, but combining these two purposes in one machine is not the most secure setup. And last but not least, the system needs at least two network cards: one for the WAN connection and one for the LAN. Add a wireless card for a wireless network.
The installation instructions guide the user through the installation process, which is rather straightforward and takes just a couple of minutes. It lets the user choose a target drive and a filesystem (the default ReiserFS, Reiser4, or ext3), partitions and formats the hard drive, and installs all files.
Colorful configuration
The configuration phase starts with the normal options, such as the keyboard layout, timezone, hostname and domain, and the root and admin passwords. After this comes the network configuration, but this introduces some new terminology; for "network type" there are the following possibilities: "GREEN + RED", "GREEN + RED + ORANGE", "GREEN + RED + BLUE", and "GREEN + RED + ORANGE + BLUE".
By default, IPFire configures a network of type "GREEN + RED", which means that it knows two networks: a green network for the LAN, and a red network for the WAN. Users that want a separate network for wireless clients should add a blue network, and users that want a separate server network (a "demilitarized zone"), should add the orange network.
Next, all the chosen networks will be assigned a network interface, IP address, and subnet mask. For the red interface, this obviously depends on the way the connection with the internet provider works. Users can choose from a static IP address, DHCP, or PPP dialup. In the following step, the DNS and gateway settings are made, but if the red interface uses DHCP, the correct values are already completed. In the last step, it's possible to enable the DHCP server and enter the IP range for the LAN. Users can redo the whole configuration procedure later using the command line program setup.
Add-ons and security
IPFire can be extended with add-ons, which are installed through the package manager Pakfire. Available add-ons include security and network tools like Tripwire, Guardian, Snort, or Squidclamav, but also file servers like Samba or NFS and Voice-over-IP packages such as Asterisk or Teamspeak, and some miscellaneous tools such as iftop, htop, or rsync. Right now, there are 97 add-ons available. Pakfire can be used from the web interface or from the console.
For a distribution that claims a focus on security, it's a bit strange to see that users have to do a full core update to get security fixes, but according Michael, users don't have to wait that long for fixes:
Web interface
Most of the features of IPFire can be configured using the web interface, available over the green network interface. The administrator has to log in using the admin username and password entered during the configuration. The web interface is subdivided into various "tabs": System, Status, Network, Services, Firewall, IPFire, and Logs. Each of them is again subdivided into different pages. The System tab contains IPFire's main settings: users can change the look and feel of the web interface, activate ssh access (which runs on port 222 by default to reduce brute force attacks) and save the configuration of their IPFire installation to a file to restore it later. The latter page even has an option that creates an ISO image with the current settings, which can be burned to a CD in order to reinstall the complete system with the same settings. It's also possible to back up the settings of the add-ons.
The Status tab gives access to graphs and tables about virtually anything users want to know about their firewall. There are graphs of the CPU usage and load, of the memory and swap usage, of the network traffic on each interface, of port scans and ping answer times, and so on. There's even a page with temporal data of hard disk and case temperature, and another one with SMART information and disk usage of the hard disk. Last but not least, the Services page gives a nice overview of the running services and diagrams of the memory usage of the processes. This page also allows the user to enable or disable the installed add-ons, which are mostly extra services.
The Network tab offers a lot of configuration options, from DHCP and DNS servers to Wake-on-LAN and a web proxy server (using Squid). The web proxy page is really extensive and allows some advanced settings, including a transparent mode which generates iptables rules with the nice effect that clients don't have to be configured for proxy use, and a URL filter that blocks access to specified web sites or web sites containing offensive words.
In the Services tab, users can configure the default services of IPFire. To create a virtual private network, IPSec or OpenVPN can be used. Dynamic DNS can be used to allocate a domain name to the dynamic IP address IPFire gets from the ISP, and IPFire is able to synchronize its time to an external server via NTP and serve its time to machines in the local network. On the Quality of Service page users can specify different classes of services and grant them a specific bandwidth usage, and the Intrusion Detection System page enables Snort to help detect malicious behaviour on the network.
The Firewall tab has settings for port forwarding, external access to the IPFire machine, and firewall rules for outgoing traffic. Add-ons can be installed in the IPFire tab. And last but not least, the Logs tab has pages with graphs and log files of a lot of services, and the behavior of syslog can be configured here.
All in all, the web interface gives access to a lot of functionality, but the pages are not laid out in the most consistent way. For example, the IP addresses and other connection information of the network interfaces is shown on the Home page under the System tab, while it would be more appropriate under the Status tab. And information about the services is interspersed between the Status - Services page and the pages under the Services tab. Moreover, services installed as an add-on can be started and stopped in the Status - Services menu, while the main services only show their status on the same page and have to be enabled or disabled on their own page. In addition, the pages in the Logs tab repeat a lot of information that is already shown in the Status tab, and shows some other information that would be more logically placed on other pages, such as the firewall logs and the logs of the intrusion detection system.
Development
In the meantime, the IPFire developers are working on the 3.x branch. It will probably be based on the stable Linux 2.6.32 kernel, patched by the IPFire developers with the grsecurity and PaX patches as well as the Open Cryptographic Framework for accelerated cryptographic primitives. The developers are also enabling the stack smashing protection of GCC to prevent buffer overflows.
For this new release, the developers will focus on the networking part of the distribution. According to Michael, there will definitely be support for IPv6, VLANs, more than the current four independent network zones, port trunking to increase bandwidth, and many more VPN features (e.g. using StrongSwan). The web interface will also be entirely rewritten with a focus on usability and configurability, and it will be based on Python instead of Perl. Pakfire will also be rewritten in Python. The first alpha release is already available.
The network zones model with the four colors will change slightly in the next release. According to Michael, it will be possible to create multiple zones of the same type, which could be interesting in a couple of cases:
As a consequence, the blue zone will be dropped in IPFire 3.0, and an additional network type will be added for the management of IPFire. The internet zone will be red, any local network would be green, the management network will be grey, and a DMZ zone would be orange.
Conclusion
IPFire is a nice solution for a secure network gateway for people that need a web interface, but that is the part of the distribution that still needs a lot of work. The web interface has too many options and doesn't show them in a consistent way, which will turn off many beginners. Fortunately, the web interface for the 3.x version will be entirely rewritten with a focus on usability.
| Index entries for this article | |
|---|---|
| Security | Distributions |
| Security | Tools/Firewall |
| GuestArticles | Vervloesem, Koen |
Posted Apr 29, 2010 15:12 UTC (Thu)
by felixfix (subscriber, #242)
[Link] (2 responses)
When I have my own firewall computer, I like the fact that it can reroute things from one side to the other based on ports etc. For a while, I had a system with dialup (low bandwidth but reasonable latency) and satellite (reasonable bandwidth but miserable latency) and it was nice to be able to route ssh over dialup and most other things over the satellite.
Is there any way to create virtual network devices which would allow this on a machine which is its own firewall? For simplicitiy sake, suppose the dialup device was /dev/eth0 and the satellite was /dev/eth1. What I would like to do is create /dev/eth2 as a single device used by all programs, and have iptables rules which would steer the outbound traffic to eth0 or eth1 as appropriate. With a separate firewall computer, this is the only way you can do it, and it was easy to understand.
VPNs use tun/tap devices -- are those virtual devices of the sort I would need? Or is there some way to simply make one up?
Posted Apr 30, 2010 2:10 UTC (Fri)
by JohnLenz (guest, #42089)
[Link]
Posted May 2, 2010 13:24 UTC (Sun)
by dmag (guest, #17775)
[Link]
http://marc.info/?l=sg-dc&m=102738963506440&w=2
I really wish there were GOOD documentation on IPTables. It's hard to find a comprehensive list of modules, let alone really good examples on how to use them. IPTables is under-used, especially for system administration tasks. I run HAProxy, which doesn't do graceful restarts (like Apache/Nginx which has a master process that doesn't exit). So to prevent the OS from dropping packets when nobody is listening, I used IPTables to short-circuit HAProxy to the first backend. So new connections are temporarily 'shunted' while HAProxy is restarting. The only annoying bit is you have to guess how long before HAProxy is ready.
(Hey, does anyone remember a newsgroup (I think it was alt.hackers) where you had to not only figure out how to forge a post, but your post had to be about an interesting hack? Ah, the good old days before eternal September.)
{OT] Virtual networks?
One way is to use shorewall which supports this. See MultiISP and Traffic Shaping.
You define two providers and are able to mark which packets should go to which provider. The rules to mark which packets go where can be as complex as you want to define. No need for tun-tap.
{OT] Virtual networks?
{OT] Virtual networks?
