THE CHAINS
THAT BIND 

SuSE integrates premier Open Source security components in a CD-based firewall.

  

by Chris Amaru
  Every day brings new threats to our computers and need for reliable ways to secure our computers grows exponentially. With every new worm, virus, and DoS (Denial of Service) attack reported in the news, it becomes clear that leaving our systems open to outside attack is bad for business. Small-to-medium sized businesses are especially at risk if they connect to the Internet via DSL or cable modems.   ADDITIONAL FIREWALL REVIEWS  
MandrakeSecurity Multi Network Firewall (MNF)
Geared for small-to-medium-sized businesses, MNF goes a long way to filling the void in firewalls that are easy to configure and manage. A secure web interface and a very minimalist configuration built on the Linux secure kernel provide the foundation platform that supports multiple Virtual Private Networks with an unlimited number of clients and provides high-throughput IPSec encryption.

NetMAX FireWall ProSuite 5
 NetMAX FireWall ProSuite 5, which facilitates setting up a firewall, router, and a proxy/cache server on top of Red Hat Linux 9.
         
 

OPENBENCH LABS SCENARIO


UNDER EXAMINATION:
 • Open Source integrated firewall with proxy server

WHAT WE TESTED:
 • SuSE Linux Firewall on CD 
http://www.suse.com

 KEY FINDINGS:
 •   Running on CD makes any hack of the firewall transient
 •   Supports outbound proxies and inbound reverse proxies
.•  The reverse web proxy is limited to allowing access to a single web site
 •  GUI configuration utility very limited in capabilities

Click to download a zip file with a sample IPCHAINS script and its equivalent in
ipchains-save format

 
 

Since Linux systems are impervious to the growing number of security hacks that specifically target Microsoft systems such as ILOVEYOU, Melissa, and the Code Red worm, they have rapidly gained attention as the systems of choice for hosting corporate firewalls. As a result, most current distributions include either the IPChains or IPTables, modules that can be configured to act as packet filtering firewalls. Nonetheless, even if you configure a Linux box to act as a router and set up either IPCHAINS or IPTABLES rules to filter unwanted Internet traffic, you are still not completely safe.

If Linux is set up to route traffic from a LAN to the Internet, you can use a packet filter to plug holes that are known to be open, but what about the unknown? For organizations that want their users to be connected to the Internet for e-mail and web browsing and still be safe from any and all attacks, proxy servers are a good solution. With a proxy server, a web or e-mail client has no direct connection to the Internet. Under this scheme, the client connects to the proxy server, which then connects to the Internet on the client’s behalf. All direct access into or out of the LAN is cut off completely except for the proxy server.

 
     
 

Of course if you have more elaborate needs, proxy servers may not be the entire solution. If there is a service that you need to access for which a proxy server doesn’t exist, you will have to find some other solution. When no proxy service is available, you can open specific ports on the firewall to outgoing traffic. This will work if you have a large block of IP addresses and every system on your LAN uses a routable address. But If you are like many people and use addresses in one of the RFC 1597 private address ranges, these addresses are not routable. Fortunately, both IPCHAINS and IPTABLES allow for masquerading of IP addresses, which allows clients inside a firewall to access Internet services outside the firewall even if they use RFC 1597 addresses.

Similar to masquerading is port forwarding, which allows IP traffic destined for a port on one system to be forwarded to another system. This is useful if you have web services inside your firewall that you want to make available to the Internet and you aren’t running an appropriate reverse proxy. This functionality was provided in kernel 2.2.x by add-on software known as ipmasqadm, which, in combination with IPCHAINS, can be used to enable port forwarding. In kernel 2.4.x, IPTABLES is able to do port forwarding natively.

It is clear with the numerous threats confronting network managers and the plethora of solutions available to counter them, making an enterprise secure can be confusing. Add to that the daunting task of finding, downloading, installing, and configuring all of these diverse software packages and you are in for a serious bit of work.

Capitalizing on the need for an integrated collection of security packages with a GUI interface for installation and configuration, SuSE has introduced the SuSE Linux Firewall on CD. Combining a standalone version of SuSE Linux, with an administration interface and some popular proxy packages, the Firewall on CD goes a long way towards helping you secure your LAN from external (or internal) mischief.

The key difference between a bunch of firewall-related software collected on a CD and the SuSE Linux Firewall on CD is its “live” nature. After you have used the administration tool to configure the firewall and write a configuration floppy, you can boot the firewall off the CD with no hard disk required. You might ask why you would want to do this, and the answer is simple: security.

By running off a CD, if someone were to successfully break into the firewall, and make changes to the running system, those changes would disappear when the firewall was rebooted. This highlights the importance of making the firewall system as secure, if not more secure, than the systems on your LAN that it protects. Although the changes a hacker might make are transient, they would still be dangerous until the firewall was rebooted.

Although you are not required to use a hard disk, you can if you want to store log files on the firewall itself, or use the cache feature of the web proxy. The majority of the operating system still runs off the CD and will be refreshed at reboot, but the web proxy cache can lead to performance increases, so don’t rule out using a hard disk. We didn’t use a hard disk during our testing, but using one involved only changing a checkbox or two.

Obviously SuSE can’t know the particulars of your LAN setup, so they use a collection of configuration files stored on a floppy disk to store the appropriate customization such as IP addresses, firewall rules, etc. To create this configuration floppy you have to install the Firewall Administration System (FAS) on a separate Linux system.

You have two choices for this installation. First, you can use the Admin CD to install a standalone version of SuSE Linux 7.2 (and FAS) on an unused system, which is the preferred choice as you can restrict access to this system for tighter security. Second, you can install FAS on an existing SuSE Linux 7.2 box. Our advice is to dedicate a machine to FAS and use the standalone install. It’s the more secure option and very easy.

 
       

Once you have FAS set up on a system, you have to run a configuration application for FAS itself. This sets up the Firewall administration user, including the user name, home directory, and password. The key to making your firewall secure is making the whole process secure. Therefore, access to FAS should be limited to very few people and protected by good passwords. This is all done with this configuration application. Once FAS is set up and configured, you can dive in and start configuring the firewall.

We need to note here that on many occasions while using FAS, it would disappear after we clicked the finish button having completed the configuration of a module. Our advice is to save your configuration after each module is completed or else you might lose a lot of work.

Naturally you’ll need to start by configuring the base parameters for the firewall system such as NICs and IP addresses, hostname, DNS server, routing, and whether a hard disk will be used. This is all very simple and self-explanatory. The simplest configuration would be to set up one NIC connected to the Internet and one connected to your LAN.

 
  This is the first screen you see when you run FAS. On the left is a list of all the modules, along with their status. The pane on the right holds either explanatory material about the module that is highlighted on the left or a configuration screen for the highlighted module.
     
 

A more elaborate configuration would have another NIC connected to a DMZ (a separate LAN isolated from both the Internet and your LAN). You would do this if you wanted to place machines running web services (such as web servers) on a separate subnet and better protect your LAN clients. You can also create a DMZ with two firewalls, one connected to the Internet and the DMZ, and the other connected to the DMZ and the LAN.

A lot of SOHO businesses might like to use this product to create a firewall that is connected to the Internet by a dial-up modem. Unfortunately, this is not easily accomplished. You are not given the option of choosing a PPP device for your external LAN interface, just Ethernet. We snooped around on the configuration floppy and noticed some files that might be used to enable this, but it is completely undocumented and we did not try to do it.

 
       

After you have completed the base configuration, you must configure the syslog module. If you have configured a hard disk you can log messages to the hard disk; otherwise you can log to a host on your LAN that is running syslog-ng, which is provided with the Admin CD. Logging information from the firewall to another system is important, as it will alert you to potential break-in attempts. We examined our syslog with the xlogmaster application and noted the entries that were generated when we were debugging the firewall rules before everything was working. You have to interpret what these entries mean: a break-in attempt, a bad firewall rule, or an innocent attempt to access your web services.
 
  We set up a rule to block outgoing access from one of our clients via anything but the web proxy (at port 3128) to demonstrate the logging of denied packets. The log entries for our attempt to access a web site via masquerading is highlighted in yellow, while our attempt to access the firewall with SSH is highlighted in green. Not shown is our successful use of the web proxy, which does not get logged.
     
 

Once the base and syslog modules are configured you can configure the remaining modules in any order. The two stand-out modules are the SUSEfirewall, which can be used to generate IPCHAINS rules via the GUI interface, and the IPCHAINS module, which gives you more fine-grained control over the firewall rules; however, you have to generate all of the rules yourself.

Using the GUI-based SUSEfirewall module, we were able to properly generate the rules that prevented common attack methods like source address spoofing, TCP SYN flooding, and ping flooding. Nonetheless, we couldn’t get it to generate the rules that would allow the traffic we needed to go in and out of the firewall. For instance, we could get the outbound web proxy to work with the SUSEfirewall module, but not the inbound (reverse) proxy. The documentation notes that you will have to open certain ports on the firewall to allow the reverse proxy to work, it just doesn’t say which ports and how to do it. So what we ended up with was a great firewall that was useless as a method for accessing the Internet.

We only go into such detail here because it highlights the major drawback of the product: The GUI Admin interface is next to useless. This product is not for amateurs. While this product brings a host of separate complex security products together on one CD, you still must know what you’re doing. You need to know about packet filtering, potential security holes, and basic Linux system management principles.

To get what we wanted, our only alternative was to use the IPCHAINS module. When we started this module, our first inclination was to enter the filename of an IPCHAINS command file we were already using on an existing firewall. The SuSE IPCHAINS module, however, does not want the raw commands: They have to be in ipchains-save format. Just run your IPCHAINS script on any system, use the ipchains-save command, and then pipe the results to a file. It doesn’t seem to matter whether the rules refer to interfaces and IP addresses that don’t exist on the system where you run the script. Once we had our existing rules in an ipchains-save formatted file, we added the IPCHAINS commands to enable our reverse proxy service to work.

If you don’t have an existing IPCHAINS script, there are a number of such files readily available on the Internet. One very good place to start is the Linux Firewalls book by Robert L. Ziegler, published by New Riders. Sample code can be found at www.linux-firewall-tools.com/linux.

 
         

To enable your clients to have access to the Internet you need to configure one of the proxies. The SuSE package contains outbound and inbound proxies for HTTP and FTP traffic, as well as Mail and DNS. We tested and configured these proxies and for the most part had no trouble.

The HTTP proxy is the well known Squid proxy and in addition to its base proxy capabilities it can also act as a web cache to increase HTTP retrieval performance. The squid proxy allows you to set up Access Control Lists (ACL) to control which users can access which web sites. These ACLs can grant access to certain web sites and restrict access to others. Also, you can filter out certain tags to stop badly behaving web sites from hurting your web clients.

The reverse web proxy is easy to configure, but it is limited to allowing access to a single web site. As previously noted, you must also set up some IPCHAINS rules to make it work properly. This is why buying the Ziegler book is a good idea. It has a good explanation of what to do to allow traffic for many different services through your firewall.

 
The internal HTTP Proxy module is used to allow access from internal clients to external web sites. The screen shown here is the first of five configuration screens for this module.
         

To allow access from the Internet to more than one internal web site, you will have to use port forwarding. This is done with ipmasqadm, which is provided by default, but the kernel modules that it needs are not loaded by default. This issue is nicely handled by the SUSEfirewall module, which prompts for kernel modules to be loaded at boot time. When we switched to using the IPCHAINS module and our own script, however, we had to find a way around this problem. In doing so we discovered a lot of good hooks in the product that are unfortunately poorly documented.

To make port forwarding work, you need to find a way to load the kernel module ip_portfw.o, and find a way to run the ipmasqadm commands at boot time. The first task can be done by entering the full path name to any kernel module that you want to load into the /etc/modules.boot file that resides on the configuration floppy. The second task is a two step process. First, you have to put a file with the ipmasqadm commands in the /sbin/init.d directory.

 

  
This screen is from the SUSEfirewall module configuration. It allows you to specify kernel modules to load at boot time. We have selected some modules that enable port forwarding. When we used the IPCHAINS module, we had to put these modules in /etc/modules.boot on the configuration floppy.
     
  Next, you have to modify the file /etc/runlevel.firewall to include this file at the proper runlevels. Once these tasks are completed, the right kernel module will be loaded at boot time and your ipmasqadm script will be executed.

One important feature that we haven’t mentioned yet is the products support for the Secure Shell standard implemented by OpenSSH. With the SSH module you can configure secure shell access to the firewall (and other hosts) and disable root access from the firewall console. This is important because it closes one more potential security hole that hackers can exploit. The SSH module uses RSA Public Key Cryptography to provide authenticated access, and is very difficult to crack.

All in all we found the SuSE Linux Firewall on CD to be a useful product with many positive points and a few major drawbacks. As long as you understand that SuSE Linux Firewall isn’t an instant solution to all your security problems and spend the time to learn Linux firewall and packet filtering concepts, you will be able to use the product to full effect. In the end your LAN will be safer and your users will still be able to surf the net to their hearts' content without exposing your LAN's heart to hacker jackals.