Thursday | 8 January, 2009
LinuxWorld.com.au

Linux Firewall Survey, Part 1

Pawel Leszek 11/10/2000 10:28:55

Security has always been a critical issue for computer networking, and firewalls are an essential ingredient for network security. In this series, I will show you how Linux offers you freedom of choice in this area. There are many firewall solutions for Linux. Most are open source applications, but some excellent commercial products have been ported to Linux. I'll also show you how the Linux kernel can be used to build a highly integrated hardware firewall.

Setting up a firewall on Linux
Many companies and ISPs use Linux machines as an Internet gateways. These machines often serve as mail, Web, news, or dialup servers. In addition, they also often work as network firewalls, enforcing access control policies between the Internet and corporate networks. That functional flexibility makes Linux an attractive alternative to commercial, proprietary network operating systems.

 Firewall architectures  

A firewall is a set of rules, applications, and policies that should ensure that users get access to network services and that the internal network remains secure from attackers from the Internet or other networks. There are two basic firewall architectures:

  1. Proxy services work between external and internal networks and provide replacement connections instead of direct connections with remote services. Proxies try to act more or less transparently. Proxy firewalls require powerful machines. It is possible to divide this category into a two groups:

    1. A circuit-level gateway is a proxy service that establishes a TCP connection (or crosswire TCP ports) between internal and external networks according to defined rules (a security policy). No content filtering can be defined. The freely available SOCKS (a standard, generic networking proxy protocol -- see Resources for more information) proxy server is a typical example of this approach. Circuit-level gateways don't provide user authentication.

    2. An application-level gateway is a proxy service that establishes TCP connections between internal and external networks; with an application-level gateway in place, an administrator can control access for selected applications/network services (i.e., HTTP, FTP, NNTP). Application-level gateways can filter content, while packet-filter and circuit-level gateways are unable to determine transmission content. Some application proxies can cache requested data to save bandwidth. Application-level gateways can provide user authentication and implement an access rights policy.

  2. Filtering gateway firewalls use a special rule set to filter IP, TCP, ICMP, and other packets that pass through the network interface. This is what ipchains does. Arriving and outgoing packets are filtered by the type, source address, destination address, and port information contained in each packet. A filtering gateway doesn't require a powerful machine to run on; using an old x468 box and a specialized one-floppy Linux minidistribution should do the trick. These firewalls don't provide user authentication.

    3. Most of the modern firewall applications are hybrid products that cannot be easily classified into either of the above groups. However, the main distinction between a filter and a proxy remains. Firewalls usually contain additional security that support software like a VPN server, strong authentication services (tokens, smart cards), or virus scan engines.

The standard firewalling support in the Linux kernel is built upon two components -- ipchains and IP Masquerading. Both features are included in standard kernel distributions. Ipchains is a mechanism for filtering IP packets; its inclusion means that any flavor of Linux can be configured to run as a filtering gateway/firewall almost right out of the box. The second important firewalling component in the kernel is IP Masquerading -- a network address translation (NAT) implementation feature with which you can hide real IP addresses used in an internal network so you can use nonrouting IP addresses in your LAN. If you want to set up IP Masquerading, you will need to use the ipchains command-line tool.

Most firewall applications for Linux, such as PMFirewall or Mason, are nothing more than ipchains configuration tools that simplify the setting and maintenance of IP-filtering rules. If you want to use ipchains, you will need to establish a set of rules that will be used to define permissible and forbidden connections. Your rule set can look something like this:

# Allow Web connections to your Web Server
/sbin/ipchains -A our_chains_rules -s 0.0.0.0/0 www -d 192.16.0.11 1024:
-j ACCEPT
 # Allow Web connections to outside Web Server
/sbin/ipchains -A our_chains_rules -s 192.61.0.0/24 1024: -d 0.0.0.0/0
www -j ACCEPT
# We want to deny everything else
/sbin/ipchains -P our_chains_rules input DENY

The most common network configuration for packet filtering is a dual-homed host -- a computer with two network interfaces, with each interface assigned a different IP address. These kinds of firewalls almost always cooperate with IP Masquerading to hide the internal network. Packet filtering is completely transparent to users and no additional client software (i.e., Web browser) configuration is required.

Unfortunately, the packet filtering included in the standard Linux kernel isn't a sufficient solution when you want to control and block content. Ipchains, for example, is unable to block ActiveX or Java applications. Another disadvantage is that the only identity a user has is the IP number assigned to his or her workstation, so problems arise when the administrator decides to use DHCP (dynamic IP assignments). The administrator will have to adjust the rules every time a new IP number is assigned. This can easily become a nightmare.

Thus, proxy gateway architectures are becoming more popular: they fulfill the need for active control and content blocking.

T.Rex Firewall -- use the source!
T.Rex Firewall is a complex application-gateway firewall developed by Freemont Avenue Software, a small company that has specialized in Internet security since 1994. T.Rex firewall is the company's main product. (By the way, the firewall is named after the Terrier Rex, a breed of dog known for its bravery.) The firewall runs on a multihomed machine with two or more network interfaces and contains specialized application proxy servers, a generic proxy server for TCP applications, and a SOCKS server for setting up a circuit gateway. T.Rex also comes with a simple intrusion detection system, extended logging, and strong authentication support.

T.Rex is the most powerful proxy firewall suite freely available to Linux users at this time. It features many tools and services (like process monitoring and failover capabilities) that have previously been available only in expensive proprietary firewalls.

T.Rex was open sourced in April 2000 and over 14,000 copies have been distributed since then. It isn't covered by the GPL license, however. Instead, it uses the more restrictive Livermore Public License 1.0 (LPL), which is based on the Q Public License (QPL, used by the Qt library). I think the GPL would have been a better choice, especially now that Trolltech has released a Qt Free Edition that is covered by the GPL. Therefore, T.Rex should be considered to be an open source application to the same degree that Qt is.

T.Rex is available in two versions. The commercial product comes on a CD-ROM along with precompiled binaries, source code, and an easy-to-use installation script. The second version is just the source code freely available for download. Documentation is also available for free download (including the T.Rex Administration Guide, which is 400 pages long!); however, you won't find too much information specific to Linux installation and configuration issues.

T.Rex strives to be a complete firewall solution. It has so many features that it's hard to briefly describe them all. T.Rex includes a bunch of application-specific proxy servers for FTP, HTTP, Telnet, RPC/UDP, reverse HTTP, and Real Audio. It also contains secure mail wrappers; Aproxy, a generic proxy for TCP applications (i.e., NNTP, Lotus Notes, Sybase SQL, DB2, Oracle SQL Net, Microsoft Exchange) and a SOCKS 4/5 server for setting a circuit gateway. It also features NAT, packet filtering, Web caching, and a dual DNS server (separate servers for internal and external hosts).

All proxies run without root privileges (in user-space mode), so software failures or security violations cannot propagate and cause a whole system to be compromised. The HTTP proxy has a Web content blocking ability and T.Rex comes with large sample list of IP addresses divided into 30 thematic categories. You can also turn on blocking for Java, JavaScript, and ActiveX objects.

There are also two tools intended for remote administration: ptelnet, a secure Telnet client, and Hoplite, a Java-based GUI administration tool that simplifies administration and is also intended for remote administration. Both tools use triple DES encryption and challenge-response strong authentication for external connections. Both tools are available for most common Unix systems and also for Windows.

I was impressed by the amazing support for tokens and smart cards that can be used for building a strong challenge-response-based authentication system (see Figure 1). This is another feature that cannot be found in other free firewalls. Tokens provide higher levels of security and are very comforting for administrators.


Figure 1. Hoplite's challenge-response login screen

Setting up T.Rex on Linux
Like all application-level proxies, T.Rex requires a powerful machine. An average configuration would include a Pentium III processor with 32 MB RAM for every 100 concurrently active Web browsers, along with an Ultra Wide SCSI hard disk for caching. It is also a good idea to get a separate drive for firewall logs. Each log record contains about 150 bytes, so you can easily accumulate hundreds of megabytes of logs when running popular Web services. T.Rex can work not only in an Ethernet environment but also with Gigabyte Ethernet, Token Ring, and ATM networks.

I was able to compile T.Rex and perform a basic configuration in about an hour. The great thing about T.Rex is that it doesn't require kernel recompilation and doesn't use kernel modules. This simplifies initial setup. Of course, you must turn off the IP packet forwarding option in the kernel to force every IP packet through the proxy. If you're preparing a production environment, you should recompile the kernel without any extra options turned on (i.e., no sysRq key feature). The whole T.Rex compilation is started from one script, buildsetup.sh, and doesn't require too much interaction with the user.

Compilation takes about 20 minutes (though that can vary depending on your machine's processor speed) and will proceed without errors if you have the common GNU development tools installed (more or less the same requirements as for a kernel compilation). It is a good idea to prepare these binaries on a machine other than the firewall host itself because you shouldn't install unnecessary software (compilers, libraries, etc.) on a firewall machine.

Installation of T.Rex requires operating system hardening. You should remove all unnecessary network services such as lpd, all the r commands (rsh, rlogin, rexd, rexecd, rstatd, and rwalld), and finger, so you'll need to edit three key system configuration files: /etc/inittab, /etc/inetd.conf, and /etc/services. All T.Rex configuration files can be found in the /etc/firewall/ directory. The single most important file is /etc/firewall/securenets, which defines IP addresses for networks that should be treated as secure (no strong authentication is required to fulfill requests for various services from these nets). The second most important file is /etc/firewall/secureports, which contains IP addresses for the network adapter attached to the secure network.

Every proxy has its own short configuration file located in /etc/firewall -- /etc/ftproxy.conf for the FTP proxy or /etc/tnproxy.conf for the Telnet proxy, for example. I like this because it is easier and more secure to edit and check many short files than maintain one huge config file with hundreds of options.

T.Rex runs from the /etc/rc.d/TREX script that starts all services and tools in the appropriate order, so you need only make the appropriate symbolic links to the default run-level directory in /etc/rc.d/. All T.Rex binaries can be found in the /usr/local/etc/ directory, so it's easy to control them.

After a successful installation and initial configuration, you should create a special administration account in T.Rex to use for remote firewall administration. (You can, of course, also use the local system console.) To create an administration account, first create an ordinary Linux user account and then use the gwuser command to attribute administrative rights to it. You will also need to generate a private DES key, using the tnkey command, for the ptelnet and Hoplite administration tools. This key should be copied to the client machine that will be used by the administrator.

The T.Rex account system reminds me of the Linux account system for groups and users, but it uses its own encryption keys and access control rights database. The T.Rex access system is based on an individual user's ID and password; additional restrictions are based on source or destination addresses.

The next step is to configure Hoplite, the Java administration tool that connects with a special admin server, padminsvr, running on the firewall. This is where my troubles began: I was unable to run Hoplite right out of the box. This is because Hoplite comes in a binary form prepared under JDK 1.1.x plus the Swing libraries; I was unable to run it under JDK 1.2.2. My troubles ended after a Hoplite recompilation (although Hoplite's starting script also required some tweaking of the JDK base directory setting).

Hoplite is a rather primitive tool, used for editing configuration files for different proxies and backing up the T.Rex configuration. Nevertheless, it provides basic realtime event monitors, like Log Viewer and Alert Panels. You can even use it to start and stop selected proxies (see Figure 2). Unfortunately, you cannot create a firewall account for firewall users with Hoplite. You must use gwuser and gwgroup instead.


Figure 2. Managing T.Rex proxy servers with Hoplite

Monitoring and logging features
T.Rex uses the syslogd daemon for logging all network and proxy activity. Only the HTTP proxy generates its own separate transfer and error logs. Hoplite can display a realtime preview for the system log. Logging levels can be set separately for each proxy server. Most proxies have their own reporting tools that read the system log and produce a concise report with information specific for that proxy. For example, Aproxy uses aproxsum, sockd uses sockdsum, and tnproxy uses tnrpt. Such reports are a good idea; it's much easier to read filtered and condensed information than it is to dive into a huge log file.

T.Rex also has a built-in monitoring/intrusion detection system that is built on three daemons, fwmon, procmon, and spoofmon:

  • fwmon periodically checks the operating system's IP forwarding settings and disables them if needed. (See Figure 3).

  • procmon counts the number of occurrences for each defined process and issues an alert if that number falls outside of the specified range (e.g., if the process isn't running). You can use procmon to monitor processes other than the T.Rex system.

  • spoofmon is a spoofing detection system that monitors TCP/IP connection requests to the firewall to determine if a request's source IP address has been spoofed. It communicates with the proxies in order to reject and log any source IP address that is originating spoofing attempts.


Figure 3. Configuring the fwmon intrusion detection tool

I also recommend the use of some automated tool (Tripwire is a good choice) for checking the integrity of binaries and configuration files.

 Pros and cons of T.Rex 

T.Rex strengths:

  • The source code is available for free and you can tailor it to your needs.
  • It is comprehensive. It is a universal security suite that combines functions that normally require the installation of multiple products.
  • It has very good user access control management.
  • Proxy servers are available for common network services.
  • It has content-blocking lists for HTTP proxy.
  • It has a circuit-level proxy compatible with SOCKS.
  • It supports strong challenge-response authorization with security tokens (SecureNet Key Card and CRYPTO Card).
  • It includes many supporting features, like an intrusion-detection system, monitoring, and extended reporting features.

T.Rex weaknesses:

  • You'll still need to pay for binaries and Web content filtering subscription updates.
  • Proper installation requires a good knowledge of networking in Linux and some experience with firewalls.
  • The administration tool, Hoplite, is limited and primitive.
  • There's no ICSA certification.
  • It can run only on dual-homed hosts. This configuration isn't the ideal choice because if T.Rex is your only security outpost and the machine it runs on is broken or compromised, your secured network will be open to hackers.
The source code for T.Rex is available for free download. There is also a precompiled version available on CD-ROM for about $10. The professional version CD-ROM, which includes additional security auditing tools and support for hardware-supported VPN, costs about $150. A content-filtering subscription costs $995.

Alternative free firewall solutions
Of course, T.Rex isn't the only open source proxy firewall available for Linux. Here are some of the alternatives:

Dante
Dante is a circuit-level firewall/proxy developed by Inferno Nettverk A/S and is freely available under the BSD license along with source code. Dante tries to be transparent to clients while offering detailed access-control and logging facilities to the server administrator. Dante derives from SOCKS 4/5. Dante has experimental (and incomplete) support for Microsoft Proxy, so Linux client applications can use that proxy.

SINUS
The SINUS Firewall is a TCP/IP packet filter for Linux distributed under the GNU GPL. It tries to address the disadvantages of ipchains -- static IP addressing and complicated administration. Its greatest advantage is that it is easy to configure and contains a Java-based GUI management interface, called sfControl (see Figure 4), for remote configuration and firewall management. SINUS is able to switch configurations on the fly without breaking existing TCP connections. If you combined SINUS with FWTK (see below), you could build a strong and flexible firewall solution.


Figure 4. Defining a filtering rule with the sfControl tool

TIS Firewall Toolkit
TIS Firewall Toolkit (also known as FWTK) was developed by Trusted Information Systems, which merged with Network Associates in 1998. The TIS Internet Firewall Toolkit (available with source code under the TIS Firewall Toolkit License, a BSD-like license) is a set of proxy servers and tools designed to facilitate the construction of network firewalls. It contains proxy servers for FTP, Telnet, SMTP, the Web, Gopher, and rlogin. FWTK contains a simple tool, netacl (Network Access Control List), that simplifies access management to network services. Access is based on IP addresses. FTWK includes a login program called login-sh that replaces the user's initial shell. The shell supports Security Dynamics SecurID, SecureNet Key, and Racal Watchword authentication services.


Resources

More about Mandrake, Gateway, Security Dynamics, Trolltech, Oracle, Microsoft, Tripwire, SecureNet, ICSA, NEC, Sybase
Additional Resources
Newsletter Subscription
Sign up for our LinuxWorld newsletters!
RSS Feeds
 
Get a job Careerone
Sponsored Links