Sadly, whenever you connect your network to the outside world, you enter hostile territory. And there's no more hostile or dangerous territory than the Internet. On the Net, thousands of nameless, faceless attackers can probe and prod your network 24 hours a day, seven days week. To prevent this, you need either a firewall or a reasonable facsimile. That's what this chapter is all about.
A firewall, at its most basic, is a device that prevents outsiders from accessing your network. This device is typically a router, a standalone computer running packet filtering or proxy software, or a firewall-in-a-box (a proprietary hardware device that filters and proxies).
A firewall can serve as a single entry point to your site, commonly called a choke point. As connection requests are received, the firewall evaluates them. Only connection requests from authorized hosts are processed; the remaining connection requests are discarded.
But this is too narrow a definition. Today's firewalls perform all sorts of tasks, including
Packet filtering and analysis—. Firewalls can analyze incoming packets of multiple protocols. Based upon that analysis, firewalls can perform conditional evaluations ("If this type of packet is encountered, I will do this").
Protocol or content blocking—. Firewalls allow you to screen content. You can exploit this capability to block Java, JavaScript, VBScript, ActiveX, and cookies at the firewall. In fact, you can even create rules to block particular attack signatures.
Note
Attack signatures are command patterns common to a particular attack. For example, when a user telnets to port 80 and begins issuing command-line requests, this "looks" a certain way to your machine. By defining this behavior to your firewall, you can "teach" it to block such attacks.
This can also be done at a packet level. For example, some remote exploits generate specialized packets that are easily distinguished from other, non-malicious packets. These can be captured, recognized, and acted on.
User, connection, and session authentication and encryption—. Many firewalls use various algorithms and authentication schemes (including DES, Triple DES, SSL, IPSEC, SHA, MD5, BlowFish, IDEA, and so on) to verify users' identities, check session integrity, and shield transiting data from sniffing.
So, in sum, depending on a firewall's design, it protects your network on at least two of these levels (and in some cases, all of them):
Who can come in.
What can come in.
Where and how they come in.
In the more esoteric sense, at its inception, a firewall is a concept rather than a product. It's the sum total of all rules that you want to apply to your network. Generally, you furnish your firewall with rules that mirror access policies in your own organization.
There are two main firewall types:
Let's examine each now.
Network-level firewalls are typically routers with packet filtering capabilities. Using a network-level firewall, you can grant or deny access to your site based on several variables, including
Source address
Protocol
Port number
Content
Router-based firewalls are popular because they're perimeter solutions. That is, they're external devices. Please see Figure 18.1.
As depicted in Figure 18.1, all outside traffic must first pass through your router, which handles all accept/deny procedures. This approach offers a major advantage: it is operating system- and application-neutral. Therefore, router-based firewalls offer a quick, clean solution that obviates the need to tinker with internal workstations.
Additionally, advanced router-based firewalls can defeat spoofing and DoS attacks and even make your network invisible to the outside world.
Finally, routers offer an integrated solution. If your network is permanently connected to the Internet, you'll need a router anyway, so why not kill two birds with one stone?
On the other hand, router-based firewalls do have deficiencies. For example, some routers are vulnerable to spoofing attacks (although router vendors have more recently developed solutions for this). And router performance can dramatically decline when you enforce excessively stringent filtering procedures. This may or may not be an issue depending on how much incoming traffic you anticipate.
Finally, good router-based firewalls are expensive, and here you really do get what you pay for. Low-end systems don't maintain state on incoming packets and are therefore vulnerable to several attacks.
The other chief firewall type is the application-proxy firewall, often called an application gateway. Application gateways substitute for connections between outside clients and your internal network. During this exchange, IP packets are never forwarded. Instead, a type of translation occurs, with the gateway acting as the conduit and interpreter.
The upside to this is that you have more comprehensive control over each individual service. And in many cases, you can maintain packet state information.
However, application gateways also have deficiencies. One is that many of them demand substantial involvement on your part because you must configure a proxy application for each networked service (FTP, telnet, HTTP, mail, news, etc.). Additionally, inside users must use proxy-aware clients. If they don't, they'll have to adopt new policies and procedures. As John Wack explains in his article titled "Application Gateways":
A disadvantage of application gateways is that, in the case of client-server protocols such as telnet, two steps are required to connect inbound or outbound. Some application gateways require modified clients, which can be viewed as a disadvantage or an advantage, depending on whether the modified clients make it easier to use the firewall. A telnet application gateway would not necessarily require a modified telnet client, however it would require a modification in user behavior: the user has to connect (but not log in) to the firewall as opposed to connecting directly to the host. But a modified telnet client could make the firewall transparent by permitting a user to specify the destination system (as opposed to the firewall) in the telnet command. The firewall would serve as the route to the destination system and thereby intercept the connection, and then perform additional steps as necessary such as querying for a one-time password. User behavior stays the same, however at the price of requiring a modified client on each system.
("Application Gateways" by John Wack can be found online at http://www.telstra.com.au/pub/docs/security/800-10/node52.html.)
A good example of an application-gateway firewall package is the Trusted Information Systems (TIS) Firewall Tool Kit (FWTK). This package, which is free for non-commercial use, includes proxies for the following services:
Telnet
FTP
rloginsendmailHTTP
The X Window system
The FWTK demands that you not only proxy each application, but also apply access rules for each one. This can get confusing. But if you're simply interested in learning about firewalls and you don't have a pressing need for an immediate firewall solution, I recommend downloading the FWTK and playing with it. The experience is well worth it. Get the FWTK at http://www.fwtk.org.
Before hauling off and installing a firewall, though, consider whether you actually need or can feasibly deploy one. There are many environments in which firewalls aren't suitable. Two examples:
Universities—. Research in universities is often conducted with two or more departments collaborating. These departments (on separate network segments) may also supply limited public access to their students. In such environments, it's difficult to work under the tight security restraints enforced by firewalls.
Internet Service Providers—. ISP customers often access their accounts (to check mail, FTP files, etc.) from different locations (work, home, another ISP, etc.). Because the ISP staff cannot reliably ascertain every IP address that a customer might originate from, they cannot reliably maintain firewall-level access control. For example, suppose that several dozen customers also have AOL accounts. AOL proxies their traffic out of Reston. Hence, you have the choice of either blocking almost all AOL traffic or none at all, because their customers will likely carry dynamic IPs.
Beyond this, erecting and maintain a firewall is a major commitment. In many instances, it's not worth the trouble. For example, if you erect a Web server that serves primarily promotional information, you'd be better off battening down that host's hatches and offering it up as a sacrificial host. (If you have backups or decent redundancy, you can quickly recover from attack if it should come to that.)
Firewalls are more suited to protecting private networks that need outgoing Internet access and offer minimal and strictly controlled incoming public access. If your needs don't reach quite that far, you can still enjoy decent firewall-like network access control using other tools, like TCP Wrappers.
TCP Wrappers (by Wietse Venema) is one of world's most popular toolkits for enforcing network access control.
Application: tcpd
Required: tcpd
Config Files: hosts.deny, hosts.allow
Security History: TCP Wrappers has had a very meager security history. Most recently, on Thursday, January 21, 1999, someone posted a trojaned version (tcp_wrappers_7.6.tar.gz) to the Internet. This trojaned version offered attackers root access. You needn't worry about that; if you have a recent Linux distribution, TCP Wrappers is installed on your system already.
Notes: None.
TCP Wrappers adds network access control through a simple but reliable mechanism. Briefly, let's look at how it works.
On hosts without TCP Wrappers, inetd starts at boot and checks for various enabled servers in /etc/inetd.conf. Here's a typical inetd.conf from such a host, minus comments:
# Internet server configuration database # $Revision: 1.66 $ ftp stream tcp nowait root /usr/etc/ftpd ftpd -l telnet stream tcp nowait root /usr/etc/telnetd telnetd shell stream tcp nowait root /usr/etc/rshd rshd login stream tcp nowait root /usr/etc/rlogind rlogind exec stream tcp nowait root /usr/etc/rexecd rexecd finger stream tcp nowait guest /usr/etc/fingerd fingerd http stream tcp nowait nobody ?/var/www/server/httpd httpd ntalk dgram udp wait root /usr/etc/talkd talkd tcpmux stream tcp nowait root internal echo stream tcp nowait root internal discard stream tcp nowait root internal chargen stream tcp nowait root internal daytime stream tcp nowait root internal time stream tcp nowait root internal echo dgram udp wait root internal discard dgram udp wait root internal chargen dgram udp wait root internal daytime dgram udp wait root internal time dgram udp wait root internal
Each line is a separate entry, and each entry specifies a service, its socket type, its protocol type, the user it runs as, and its server. For example, examine the entry for fingerd:
finger stream tcp nowait guest /usr/etc/fingerd fingerd
Here's what the fingerd entry specifies:
The service is
finger.The socket type is
STREAM.The protocol is
TCP.The
nowaitdirective indicates thatinetdshould spawn newfingerdprocesses as needed.The
questdirective indicates thatfingerdshould run as userquest.The
/usr/etc/fingerddirective indicates the location of thefingerdprogram.
When inetd receives a request from a finger client, it starts an instance of fingerd, which then satisfies the finger request. The reason for this is that it's easier to run a single daemon like inetd than to perpetually run 12 or 20 different servers. This way, a server only runs if it's actually needed.
The problem with this approach is that these services may not apply access control by default, so you cannot easily accept or deny connections selectively across the board. Enter TCP Wrappers.
Venema has created a generic wrapper (tcpd) that can be applied to all such services. With TCP Wrappers installed, when inetd calls a server, tcpd intercepts the call and evaluates the connection request. During this process, tcpd compares the connection request against various rules. If the connection request passes these tests, tcpd starts the requested server, which in turn satisfies the client's request. But if the connection fails to pass tcpd's evaluation, the connection is dropped.
Unless you have an antiquated Linux distribution, TCP Wrappers is already installed on your system. In which case, your inetd.conf should look something like this:
# # inetd.conf This file describes the services that will be available echo stream tcp nowait root internal echo dgram udp wait root internal discard stream tcp nowait root internal discard dgram udp wait root internal daytime stream tcp nowait root internal daytime dgram udp wait root internal chargen stream tcp nowait root internal chargen dgram udp wait root internal #time stream tcp nowait root internal #time dgram udp wait root internal ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd gopher stream tcp nowait root /usr/sbin/tcpd gn #smtp stream tcp nowait root /usr/bin/smtpd smtpd #nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd shell stream tcp nowait root /usr/sbin/tcpd in.rshd login stream tcp nowait root /usr/sbin/tcpd in.rlogind exec stream tcp nowait root /usr/sbin/tcpd in.rexecd talk dgram udp wait nobody.tty /usr/sbin/tcpd in.talkd ntalk dgram udp wait nobody.tty /usr/sbin/tcpd in.ntalkd pop2 stream tcp nowait root /usr/sbin/tcpd ipop2d pop3 stream tcp nowait root /usr/sbin/tcpd ipop3d imap stream tcp nowait root /usr/sbin/tcpd imapd
Note the difference in how inetd.conf entries look when tcpd is installed:
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
Here, the /usr/sbin/tcpd process precedes in.telnetd. Hence, telnetd is wrapped with tcpd.
tcpd is quite a nice package. When tcpd evaluates a connection request, it also logs it the same way as syslog. As described in the TCP Wrappers documentation:
The wrapper programs send their logging information to the
syslogdaemon (syslogd). The disposition of the wrapper logs is determined by thesyslogconfiguration file (usually/etc/syslog.conf). Messages are written to files, to the console, or are forwarded to a@loghost. Somesyslogdversions can even forward messages down a pipeline.
So, in sum, TCP Wrappers affords you two powerful advantages:
Connection logging
Network access control
The first is a freebee: tcpd logs the connections without your assistance. However, for network access control, you must establish the rules. Let's cover that now.
TCP Wrappers reads network access control rules from two files:
/etc/hosts.allow—Here you specify authorized hosts./etc/hosts.deny—Here you specify unauthorized hosts.
On a fresh installation, these files are generally empty and look like this:
# hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. # In particular # you should know that NFS uses portmap! # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. # In particular # you should know that NFS uses portmap!
Your job is to make the appropriate entries. Let's look at some examples.
Configuring /etc/hosts.deny and /etc/hosts.allow requires some consideration. Venema developed a special language (hosts_options) specifically for this purpose, which is documented on the hosts_options(5) manual page. As described in that document, hosts_options is…
…a simple access control language that is based on client (host name/address, username), and server (process name, host name/address) patterns.
hosts_options supports copious features, and as you become more familiar with it, you can develop complex rules such as "If a connection meets this criteria, execute this shell command". Until you get more experience, though, your best bet is to stick to the basics, which essentially amount to this:
daemon_list : client_list
For example, suppose you entered this line into /etc/hosts.allow:
ALL: .mycompany.net EXCEPT techsupport.mycompany.net
Here, all machines in domain mycompany.net except techsupport are allowed to connect to all services. This is very useful, but only if you also add this entry to /etc/hosts.deny:
ALL: ALL
Here's why: If you specify the /etc/hosts.allow entry alone, the only host being denied is techsupport.mycompany.net.
As a general rule, you should add ALL: ALL to your /etc/hosts.deny file first. This disallows everyone. From there, you can start adding authorized hosts. The reason for this is that it's easier and more secure to specify that "that which is not permitted is denied" than it is to specify that "that which is not denied is permitted." This way, you account for unknown circumstances.
But there's more. hosts_options allows you to get into serious, granular detail. For example, assume that /etc/hosts.deny contains these entries:
ALL: .aol.com, .msn.com ALL EXCEPT in.telnetd: techsupport.theircompany.net
Here, folks from AOL and MSN are completely blocked, but folks on the host techsupport.theircompany.net can access your telnet services.
Recognizing that you might like to apply some sweeping rules, Venema has also incorporated several wildcard statements into hosts_options. These are summarized in Table 18.1.
Table 18.1. hosts_options Wildcards
Finally, hosts_options supports one operator: EXCEPT. You can use EXCEPT to create exceptions to specific rules in either daemon or client lists. For example, suppose you entered this line in /etc/hosts.deny:
ALL EXCEPT in.telnetd: techsupport.mycompany.net
Here, you are denying all services except telnet to the host techsupport. But you can also stack EXCEPT declarations, like this:
As you might expect, this can get complicated even without adding conditionally executed shell commands. Therefore, TCP Wrappers comes with tools you can use to verify your rules:
tcpdchk—The TCP Wrappers configuration checkertcpdmatch—The TCP Wrappers oracle
Let's quickly cover them now.
tcpdchk is a tool that verifies your TCP Wrappers setup. As explained in the tcpdchk manual page:
tcpdchkexamines your TCP Wrappers configuration and reports all potential and real problems it can find. The program examines the tcpd access control files (by default, these are/etc/hosts.allowand/etc/hosts.deny), and compares the entries in these files against entries in theinetdortlidnetwork configuration files.
tcpdchk analyzes your configuration for the following problems:
Bad syntax
Bad pathnames
Bad hostnames or IP addresses
Hostnames with IP addresses that don't correspond (an extension of the
PARANOIDwildcard functionality)Services that you specify rules on but aren't actually wrapped by
tcpd
tcpdchk supports several command-line options, which are summarized in Table 18.2.
Table 18.2. tcpdchk Command-Line Options
Whereas tcpdchk checks your rules to ensure that they're sound, tcpdmatch actually shows you what will happen when they're deployed. As explained on the tcpdmatch manual page:
tcpdmatchpredicts how the TCP Wrappers would handle a specific request for service.
Syntax is tcpdmatch [daemon] [host], like this:
tcpdmatch in.telnetd techsupport.theircompany.net
TCP Wrappers is the closest to firewall functionality that you can get without actually deploying a full-scale packet filter (or more), and it's a perfect choice when you can't use a firewall but still need network access control.
For example, suppose you have a sacrificial Web host and you want to block everything but HTTP traffic. You can do that but still cut a hole for SSH connections on port 22 so that your Web developers can upload files, change permissions, configure CGI scripts, and so on. For these tasks, TCP Wrappers is more than sufficient.
On the other hand, perhaps you need more, like real firewall functionality and packet filtering. If so, use ipfwadm (for kernels earlier than 2.2) or ipchains.
ipfwadm is a packet filtering tool for Linux. As explained on the manual page:
ipfwadmis used to set up, maintain, and inspect the IP firewall and accounting rules in the Linux kernel. These rules can be divided into four different categories: accounting of IP packets, the IP input firewall, the IP output firewall, and the IP forwarding firewall. For each of these categories, a separate list of rules is maintained.
For such a small utility, ipfwadm packs a wallop and is a formidable personal firewall solution all by itself.
ipfwadm allows you to set stringent rules on incoming and outgoing traffic. Basic ipfwadm syntax is
ipfwadm [rule_category] [policy_action] [policy] [interface] [target]
The rule category is the type of rule you're defining and whether it applies to accounting, incoming traffic, outgoing traffic, normal/non-filtered traffic, or masqueraded traffic.
The policy action is what you want to do with this policy: insert it, append it, or delete it.
The policy is what you want to do with the specified traffic: accept it, deny it, or reject it.
The interface is the network interface you want to apply these rules to.
The target is the IP address (and perhaps port) that you're applying these rules to.
Start with the rule categories and build your command line as you go. For the purposes of this example, you want to deny all PPP traffic over a PPP connection from the host 201.171.0.111.
ipfwadm offers you five rule categories, which are summarized in Table 18.3 (along with the command-line options to set them).
Table 18.3. ipfwadm Rule Categories and Their Command-Line Options
| Option | Function |
|---|---|
-A [direction] | Use this to specify IP accounting rules. direction can be in, out, or both (the default). |
-F | Use this to specify IP forwarding rules, or rules for garden-variety Internet routing. |
-I | Use this to specify IP input filtering rules, or rules about how incoming traffic is filtered. |
-M | Use this to specify IP masquerading rules. Masquerading is the practice of using one machine running ipfwadm to provide multiple machines with routing to the Internet. For example, you could have a LAN in your home and all machines on it can share an Internet connection. |
-O | Use the –O option to specify IP output filtering rules, or rules about how outgoing traffic is filtered. |
Again, your aim is to deny incoming PPP traffic from 207.171.0.111. So, begin like this:
ipfwadm –I
This specifies that your rule category is type –I and you're therefore aiming to establish a policy for incoming traffic. The next step is supply ipfwadm with a command. Table 18.4 summarizes the possible commands.
| Command | Function |
|---|---|
-a [policy] | Use this to appenda policy. |
-d [policy] | Use this to deletea policy. |
-f | Use this to flushall policies. |
-h | Use this to get help. |
-I [policy] | Use this to inserta policy. |
-l | Use this to listall policies. |
-p | Use this to change default policies. |
Here, you want to append a policy. Hence, add the –a option to your command line:
ipfwadm –I –a
So far, then, you've specified that you want to establish a policy for incoming traffic and append that policy. Next, you need to specify the actual policy. You have three choices:
acceptdenyreject
Since you're screeningout incoming traffic, choose deny:
ipfwadm –I –a deny
At this point, your command line specifies that you want to append a rule denying incoming traffic. What remains is adding identifying parameters to the command. Table 18.5 summarizes the possible parameters.
Table 18.5. ipfwadm Parameters
To complete our command line, you must add the –W and –S parameters and their respective values. First, add the interface:
ipfwadm –I –a deny –W ppp0
And then add the source address:
ipfwadm –I –a deny –W ppp0 –S 207.171.0.111
This will block all incoming PPP traffic from 207.171.0.111.
ipfwadm supports many other options. Table 18.6 summarizes a few important ones.
Table 18.6. ipfwadm Parameters
How you configure ipfwadm will depend much on your specific needs, but you'll want to make at least your basic configuration permanent. One way to do this is to start ipfwadm from /etc/rc.d and specify your rules in the rc.local startup script.
You should approach your ipfwadm configuration as you would your tcpd configuration, by first denying everything:
ipfwadm -I -p deny ipfwadm -O -p deny ipfwadm -F -p deny
From there, you can loosen things up. For example, you'll want to allow unrestricted traffic on your internal LAN. So, if you were using 172.16.0.1 for localhost, you would make a policy like this:
ipfwadm -I -a accept -V 172.16.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0 ipfwadm -O -a accept -V 172.16.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
This would ensure that 172.16.0.1 could come in or go out unrestricted to any address. (The designation 0.0.0.0/0 is functionally equivalent to anywhere.) Combined with the initial restrictive declarations above, this configuration denies access to all remote hosts but allows localhost to do anything. Beyond that, the rest is up to you.
Note
As you define your rules, ipfwadm will commit them to various files in /proc/net, including
-rw-r--r-- 1 root root 0 Jul 5 09:03 ip_acct -rw-r--r-- 1 root root 0 Jul 5 09:03 ip_forward -rw-r--r-- 1 root root 0 Jul 5 09:03 ip_input -r--r--r-- 1 root root 0 Jul 5 09:03 ip_masq_app -r--r--r-- 1 root root 0 Jul 5 09:03 ip_masquerade -rw-r--r-- 1 root root 0 Jul 5 09:03 ip_output
ipfwadm is a powerful package that offers you many possibilities. To learn more about its features and see some scenarios that might possibly suit your specific configuration, get these documents:
IPFWADM: Linux Firewall Facilities for Kernel-Level Packet Screening, Jos Vos and Willy Konijnenberg, The Netherlands (http://www.parkline.ru/Library/html-KOI/SECURITY/ipfwadm/paper.txt).
The IPFWADM FAQ, by Dreamwvr (http://www.dreamwvr.com/ipfwadm/ipfwadm-faq.html)
ipchains, available in the kernel 2.2 package, is ipfwadm's successor and supports all the functionality of ipfwadm and more. The chief difference, from a usage standpoint, is that commands are now in uppercase while arguments are in lowercase. This change and others are summarized in Table 18.7 below.
Table 18.7. ipchains Commands, Targets, and Predicates
ipfwadm -I -a accept -V 172.16.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
would become this under ipchains:
In all other respects, ipchains works much like ipfwadm. For a detailed analysis of variances between these two utilities, please see the ipchains HOWTO at http://www.fokus.gmd.de/linux/HOWTO/IPCHAINS-HOWTO.html.
ipchains does have a recent security history. Reported in late July 1999, the vulnerability allows attackers to bypass the packet filter. The technique is a fragmentation attack. Using custom packets with a zero offset, attackers can access ports normally blocked at the firewall. For more information and a fix, visit BUBGTRAQ at http://www.securityfocus.com.
Beyond ipfwadm, several freely available firewall tools exist, including
Dante—Developed by Inferno Nettverk A/S, this is a circuit-level firewall-proxy server for Linux. As of this writing, Dante is known to run well on Linux (
i686-pc-linux-gnu), RedHat5.2, kernel 2.0.34 or better. Dante can provide convenient and secure network connectivity to a wide range of hosts, while requiring only that the server Dante runs on has external network connectivity. Dante is a free SOCKS implementation, essentially. Learn more at http://www.inet.no/dante/.ip_filter—This is an advanced TCP/IP packet filter suitable for use in firewall environments. You can use it as a loadable kernel module or incorporate it into your kernel. IP Filter sports a staggering number of options, including filtering of fragmented packets, an issue at the heart of many denial-of-service attacks. Learn more at http://cheops.anu.edu.au/~avalon/ip-filter.html.SINUS—The SINUS Firewall is a free TCP/IP packet filter for Linux and provides most functions available in commercial firewalls. It is reportedly robust and reliable (the authors reported an uninterrupted run of 12 months without a crash). SINUS is great if you are studying firewalls or considering writing one. Learn more at http://www.ifi.unizh.ch/ikm/SINUS/firewall/.
Firewalls are serious business, and if you're planning on using one, you're probably running an enterprise network. If so, I urge you to consider a commercial solution. Here's why: As much as I favor the do-it-yourself, hack-until-you-get-it-right approach, it has no place in a commercial environment. When your livelihood is riding on security, you need something reliable that comes with technical support.
Note
This is not to say that you shouldn't have hands-on experience building your own firewall. You should. But until you do so successfully, don't gamble on homegrown solutions. Instead, seek guidance from (or collaboration with) someone who has deployed a firewall in a network environment similar to your own.
The following firewall products are known to interface nicely with Linux.
Firewall type: Firewall in a Box
Manufacturer: Galea Network Security, Inc.
Supported platforms: N/A
Features: IPSEC, DES, Triple-DES, MD5, and ISAKMP/Oakley
Further information: http://www.galea.com/En/Products/Avertis/Avertis.html
Avertis is a proprietary solution based on proprietary hardware and software. It provides real-time filtering and analysis of network traffic, protection against spoofing attacks, and hardware proxying.
Firewall type: Software-application gateway
Manufacturer: CSM-USA, Inc.
Supported platforms: Linux, Solaris, and Windows NT
Features: SSL, SOCKS, and SOCKS5
Further information: http://www.csm-usa.com/product/proxy/unix/
CSM Proxy is a comprehensive proxy server solution that includes filtering of ActiveX, Java, cookies, news, and mail. CSM Proxy now supports Windows 95 also.
Firewall type: Firewall in a Box
Manufacturer: Global Technology Associates
Supported platforms: N/A
Features: PPTP, unspecified encryption
Further information: http://www.gnatbox.com/
GNAT is a firewall-in-a-box. This is proprietary hardware and software that is packaged into a single unit. These types of products are plug-in solutions. You simply plug them in and go. The GNAT box can be managed in either a command-line or Web-based interface. GNAT filters incoming traffic based on IP source address, destination address, port, network interface, and protocol.
Firewall type: Hardware
Manufacturer: NetScreen Technologies, Inc.
Supported platforms: N/A
Features: IPSEC, DES, Triple DES, MD5, and SHA.
Further information: http://www.netscreen.com/netscreen100.htm
NetScreen is both a firewall and extranet solution that provides encryption and session integrity. Supported protocols are ARP, TCP/IP, UDP, ICMP, DHCP, HTTP, RADIUS, and IPSEC.
Firewall type: Firewall Appliance or Software
Manufacturer: Progressive Systems
Supported platforms: Linux
Features: Unspecified (proprietary?)
Further information: http://www.progressive-systems.com/
The Phoenix Adaptive Firewall is available for SuSE 5.3, Caldera 1.3, Red Hat 5.x, and Red Hat 4. Unfortunately, even though the Phoenix marketing documentation looks magnificent, I wasn't able to find sufficient detail in it about algorithms used. Therefore, I'm including a personal note here to the vendor: Your product is intriguing and clearly of interest to the Linux community. Tell us more.
Firewall type: Router-based
Manufacturer: Cisco Systems, Inc.
Supported platforms: N/A
Features: ASA, IPSEC, TACACS, RADIUS
Further information: http://www.cisco.com/warp/public/cc/cisco/mkt/security/pix/
PIX relies on a secure firmware system (Cisco IOS) and offers some very powerful and intelligent filtering technology. Additional features include HTML-based configuration and administration, IP concealment and non-translation, DoS and spoofing prevention, and support for 16,000 instant connections. Consider PIX if you're in an enterprise environment. Cisco products are expensive, but they rock.
Firewall Type: Router-based
Manufacturer: Ascend Communications, Inc.
Supported Platforms: N/A
Features: IPSEC, DES, Triple DES, MD5, and SHA1
Further Information: http://www.ascend.com/757.html
SecureConnect is provided through Ascend's MAX family of routers. Features include access control, encryption, advanced filtering, support for most known protocols, and RADIUS dial-up management.
Finally, this section provides the location of various online documents that will help you to better understand firewall technology.
Internet Firewalls and Network Security(Second Edition), Chris Hare and Karanjit Siyan, New Riders, 1996. ISBN: 1-56205-632-8.
Internet Firewalls, Scott Fuller and Kevin Pagan, Ventana Communications Group, Inc., 1997. ISBN: 1-56604-5061.
Building Internet Firewalls, D. Brent Chapman and Elizabeth D. Zwicky, O'Reilly&Associates, 1995. ISBN: 1-56592-124-0.
Firewalls and Internet Security: Repelling the Wily Hacker, William R. Cheswick and Steven M. Bellovin, Addison-Wesley Professional Computing, 1994. ISBN: 0-201-63357-4.
Actually Useful Internet Security Techniques, Larry J. Hughes, Jr., New Riders, 1995. ISBN: 1-56205-508-9.
Thinking About Firewalls, Marcus Ranum (http://csrc.nist.gov/secpubs/fwalls.ps).
Network (In)Security Through IP Packet Filtering, Brent Chapman (http://csrc.nist.gov/secpubs/pktfilt.ps).
Firewalls FAQ, Marcus J. Ranum (http://www.cis.ohio-state.edu/hypertext/faq/usenet/firewalls-faq/faq.html).
There Be Dragons, Steven M. Bellovin, Proceedings of the Third Usenix UNIX Security Symposium, Baltimore, September 1992. AT&T Bell Laboratories, Murray Hill, NJ (http://csrc.nist.gov/secpubs/dragon.ps).
Rating of Application Layer Proxies, Michael Richardson (http://www.sandelman.ottawa.on.ca/SSW/proxyrating/proxyrating.html).
Keeping Your Site Comfortably Secure: An Introduction to Internet Firewalls, John P. Wack and Lisa J. Carnahan, National Institute of Standards and Technology (http://csrc.ncsl.nist.gov/nistpubs/800-10/).
Covert Channels in the TCP/IP Protocol Suite, Craig Rowland, Rotherwick&Psionics Software Systems, Inc. (http://csrc.ncsl.nist.gov/nistpubs/800-10.ps).
Packet Filtering for Firewall Systems, CERT and Carnegie Mellon University, February 1995 (ftp://info.cert.org/pub/tech_tips/packet_filtering)).
A Network Perimeter with Secure External Access, Frederick M. Avolio and Marcus J. Ranum. A paper that details the implementation of a purported firewall at the White House (http://www.alw.nih.gov/Security/FIRST/papers/firewall/isoc94.ps)
Packets Found on an Internet, Steven M. Bellovin, Lambda. Interesting analysis of packets appearing at the application gateway of AT&T (ftp://ftp.research.att.com/dist/smb/packets.ps).
Firewall Application Notes, Livingston Enterprises, Inc. Good document that starts by describing how to build a firewall. It also addresses application proxies, sendmail in relation to firewalls, and the characteristics of a bastion host (http://www.telstra.com.au/pub/docs/security/firewall-1.1.ps.Z).
Creating a Linux Firewall Using the TIS Toolkit, Benjamin Ewy (http://linuxjournal.com:82/lj-issues/issue25/1204.html).
X Through the Firewall, and Other Application Relays, Treese/Wolman, Digital Equipment Corp, Cambridge Research Lab (ftp://crl.dec.com/pub/DEC/CRL/tech-reports/93.10.ps.Z).
A firewall can provide substantial security from external attack, but that doesn't make it a cure-all. You should guard against the temptation to rely on your firewall alone. Instead, choose your firewall carefully, learn it well, and try viewing it as just one major component in your overall security architecture. By taking these steps, you'll reap the maximum benefits that firewalls have to offer.