Are you a disenfranchised IBM Firewall user in need of a replacement product? Are you an IT manager who is just looking at your Internet connectivity options, undoubtedly worried about securing your internal network? Are you a person who enjoys sleeping at night?

The media has certainly encouraged the use of network security tools by publishing reports of crackers invading high-profile companies’ networks. Even if you believe that the media only sensationalizes these break-ins, as it did with the Y2K crisis, a foray to the mall amidst throngs of shoppers will quickly remind you of the dark side of humanity, “good will toward men” notwithstanding. Suffice it to say that I’m not willing to trust people to behave themselves, and I assume that you’re not either.

If you don’t know it already, you’ll learn that your network’s first line of defense is called a firewall (named after the firewall that sits between a vehicle’s engine and its occupants to protect the latter from a fire in the former). This device (the firewall on your computer) acts as a gateway between the big, bad outside world (also know as the Internet) and the pristine sanctuary that is your internal network. I use the term device because the firewall can be comprised of a computer running firewall software or a black box network appliance with the innards kept from view. This article describes the first of these two options using the Swiss Army knife of operating systems, Linux.

A Firewall Primer

A military base typically has a fence around it with gated checkpoints through which vehicles must pass to enter or exit the base. A nightclub often has a bouncer at the door to check the IDs of those attempting to gain entry and enforce minimum age requirements. In both cases, a choke point is created that makes traffic regulation possible. Holes in the fence or unguarded doors weaken security. Like both of these examples, securing your network requires that you create some kind of choke point through which your network traffic will pass. It is in this choke point that you will insert the firewall device.

There are two types of firewalls available. The first type of firewall is called a proxy firewall. These firewalls make the connection between the inside computer and the outside computer—sort of like on “Rowan and Martin’s Laugh-In” when Lily Tomlin did her “one ringee dingee” routine. The computers on either side of the firewall never communicate directly but instead must rely on the proxy to pass traffic back and forth. Proxy firewalls

are very secure when configured properly, since there is no direct route between computers on either side of the firewall.

The second type of firewall, when inserted into the choke point, will inspect each packet of traffic (effectively checking ID) and, based upon the rules you’ve specified, will either permit the traffic to pass or reject it. The act of checking ID is called IP or network filtering. This type of firewall is, not surprisingly, called a network filtering firewall. A network filtering firewall will allow computers on either side of it to make direct connections to one another. It’s fairly simple to set up this kind of firewall, but, depending on the services you want to pass, it can be somewhat problematic, too. This is the kind of firewall built into OS/400.

I tend to use filtering firewalls with Linux for the following reasons:

• The software required to do the job is already included with the Linux distribution.

• A lot of development is being done on tools to configure the Linux firewall code.

• Network address translation is included in the Linux firewall code.

• Filtering types of firewalls simply suit my purposes better.

Thus, this is the type of firewall on which I’ll concentrate in this article. Firewall software usually has some kind of logging capability. You will, at the very least, want to configure the software to log violations of your rules. This logging will allow you to keep tabs on what the riffraff is attempting to do—the riffraff existing both outside and inside your network. The more paranoid among you will want to log access to specific services or machines, too. Remember, just because you aren’t paranoid doesn’t mean that people aren’t out to get you.

Logging access is a good idea, if for no other reason, to ensure that your firewall rules are doing what you want.

The connection to any network, Internet or intranet, is called an interface. The logical (software) interface, which is what the operating system uses and which goes by names like eth0 or ppp0, is attached to a physical interface such as an Ethernet card or perhaps a serial port and modem. Although there are firewall products that use a single interface to do the job, the ones that I trust and will discuss use at least two: one on the distrusted side of the network and one on the trusted side, as shown in Figure 1. This configuration (with two interfaces) is called a dual-homed system.

Getting the Basic Linux System Ready

Now that you know what a firewall is and where it fits into the networking picture, the next topic for discussion is how Linux can act as a firewall. So the first question is, “What do I need to run Linux?”

Obviously, you’ll need a computer onto which you can load Linux, since that’s the first step. An old Pentium 100 or 486-66-based computer will be just fine if you can stick 24 or 32 MB of RAM into it (less, if you’re an old pro at optimizing Linux). The hard disk requirements will be more than satisfied with a 512-MB drive. This configuration should easily handle the network traffic from a couple hundred machines.

It should go without saying that you’ll need at least one network interface card (NIC) that matches the network topology that appears on the trusted side of the firewall—but I’ll say it anyway. Your connection to the Internet is the deciding factor for the other interface. If, for example, your Internet connection requires an Ethernet card (such as a cable modem or T1-and-hub combination), then you’ll need one for that. If you’re using a dial-up connection, then you’ll need a modem to act as the interface. Just be sure that the modem is not a WinModem, since the likelihood of that working on a Linux

box is a real crapshoot. This is because WinModems use software, rather than hardware, to communicate with the operating system, and Linux doesn’t like that. Of course, with a dialup configuration, you’re most certainly going to run out of network bandwidth long before you run out of computing horsepower anyway.

Another obvious point is that you’ll need some distribution of Linux. Although I usually use Red Hat, it’s not the only one or necessarily the best one. You might also want to use Caldera, SuSE, or any number of other distributions of Linux. For more information, point your browser to www.linuxlinks.com. But I’m familiar with the Red Hat distribution, so that makes things easier for me during installation. I do offer one bit of advice to anyone creating a Linux firewall box. Do not simply accept default installations as offered by the vendor. Red Hat’s installation options include work-station, server, and custom. As easy as it would be to select one of the former two types, particularly if you don’t know much about Linux, take the time to use the custom installation. The reason is simple: This computer is going to be exposed to the Internet and all of the bad people out there. If someone does manage to gain access to this machine, you at least want to deny him the availability of conveniently loaded software tools. The custom installation will allow you to select the packages you want loaded onto your hard drive. Red Hat’s installation provides you with descriptions about each of the packages it has available. Based upon these descriptions, you can ascertain if it applies to the firewall you want to construct. In a nutshell, if the description doesn’t indicate that the package is required for the system to operate and doesn’t specifically mention network tools, you probably don’t want it. To be on the safe side, be conservative with package selection. One of the nice things about Linux is that it’s fairly simple to load additional packages once your system is running. It’s also fairly simple to remove packages, too. So if you do go overboard, you have that life-preserving option.

Since the focus of this article is using Linux as a firewall, I’m not going to spend any time going over the ins and outs of Linux installation (or firewall configuration, since this isn’t a how-to article). There is already a copious amount of material covering this topic, available both in book form and on the Internet. I will suggest that you read the installation guide that comes with your Linux distribution to save you some headaches. I’ll also tell you the secret to understanding Linux: Learn where the documentation is hidden.

One of the installable packages available with most distributions is the documentation. Many distributions are getting large enough that the documentation appears on a separate CD. Surprisingly, you can easily install a Linux system without installing the documentation. It isn’t a given that the docs will be installed by default, so be sure to request it.

Unlike Windows and its frequently—but not always—single-stop “helpful” help system, Linux has a number of places where documentation can be hidden—I mean, placed. I find this situation kind of like a game of educa-tional hide-and-seek. To save you from being “it,” I offer the following tips:

• Packages that are included with the distribution have documentation in the /usr/doc directory. There are a number of good how-to documents located in the /usr/doc/ HOWTO directory, including a Firewall How-to.

• Packages downloaded from the Internet typically, but not always, dump their docs into the /usr/local/doc directory, so check there.

• Most Linux commands have online documentation available via the man (short for manual, and it must be lower case) command. The command man would give you the manual pages about the man command.

• Newer utilities have gravitated away from man towards info, so if man XXX fails, try info XXX instead. Conversely, info will default to the man page should there be no info available. So, you can use info to cover both man and info. Is that clear as mud?

Posting Tux as a Sentry

Once your system is up and running, you’re ready for the installation of the firewall. The next question is, “Do I need any additional software?” As with most things digital, the answer is an absolute “maybe.”

If you are interested in a filtering firewall, then you already have at your disposal everything you need to get started. Like OS/400 on the iSeries machines, Linux (which has Tux the penguin as its mascot) has a packet filtering code within the kernel (the core of the operating system). To manipulate the filtering in OS/400, you have to use the Operations Navigator tool. In Linux, this tool is manipulated with the ipchains command, assuming that you’re using a kernel version of 2.2 or greater. In ways I’ll discuss shortly, the Linux firewall code is more flexible than that of OS/400 simply because it is accessible via a command-line tool instead of requiring a GUI. To ensure that you have the most robust and stable firewall code, be sure to use a distribution that supplies a kernel that is at version 2.2 or greater. In the Red Hat world, this means Red Hat Version 6.0 or later. For other distributions, you can find the kernel version by looking at its specifications. The version is almost always clearly indicated. I mention this because I still find Red Hat

Version 5.2 for sale at some retail locations, and, if you don’t look carefully, you may not get the most recent version.

IP Filtering Explained

The IP filtering code available in Linux can be configured to pass or reject packets based upon the protocol (TCP, User Datagram Packet [UDP], or others), the IP source or destination address, or the source or destination port. This allows for some fairly sophisticated filtering. One of the problems with the kernel filtering code is that some network traffic, such as streaming audio and video or instant messaging services, isn’t readily filtered or passed. To solve this problem, modules have been written that will enhance the kernel filtering code to allow these services to function. These modules are generally included with the Linux distribution. For further information about IP filtering, be sure to read the August 2000 MC article “Secure Your AS/400 with IP Filtering.”

As mentioned earlier, the kernel filtering code is configured with the ipchains command.

Figure 2 displays a typical firewall script, which shows the ipchains command in action. I won’t go into any detail about it here, since the code itself is documented. Earlier, I mentioned that I believe the Linux implementation of filtering code to be superior to that included with OS/400 because an easy command line utility is available to configure it. The code shown is actually a script—the Linux equivalent of a batch file—so it can be run manually or automatically, as when PPP is started on Linux, and an interface-up script is called by the PPP daemon. But the real beauty of the command-line configurator shows through with programs like Portsentry, another open-source product. This program monitors the interface exposed to the outside world and, once again, based upon your rules, will dynamically adjust your firewall rules. For instance, if the program detects a person performing a port scan (considered to be a hostile act), it can add a rule to drop packets from the attacker’s IP address.

Another function that Linux shares with OS/400 is network address translation, known as masquerading in the Linux world. If you only have a few, or even one, public IP address assigned for your use, it’s a good bet that you’re masquerading your internal network machines where you should be using private IP addresses. Suppose you have a machine inside the firewall that is running a Web server, and you want the public to access

Chained

it. Linux provides for this by using the IPMASQADM command to do a function called port forwarding. What this means is that requests for your Web server, which typically appear on port 80 of your public IP address, will be forwarded to the appropriate machine inside your network. An example of this appears in the code shown in Figure 2. For further information about network address translation, see my September 2000 MC article “NAT —Not an Insect but a Powerful TCP/IP Tool.”

Give It a Try!

If you need the services of a good firewall, you should take a look at Linux for performing this duty. The firewall code is constantly being improved and enhanced, so its functionality will undoubtedly keep up with any new services thrown at it. In fact, kernel Version 2.4 has a complete rewrite of that code to fix some of the inadequacies found in the current version. For those who are uncomfortable with the thought of configuring their firewall, relax. There are many projects that provide question-and-answer firewall configuration.

To find them, point your browser at www.freshmeat.net (the wellspring of open- source software) and search on the keyword firewall. Also, there is another good site, www.linuxfirewall.org, that you should visit. I think that URL speaks for itself. For the ultimate in simplicity, there is the “Firewall on a Floppy,” which is a one-diskette Linux distribution optimized for this specific purpose. No hard drive is required! Visit www.floppyfw.org to investigate it. Linux makes a good, inexpensive alternative for a firewall. And, since OS/400 no longer has a native firewall product and you really need something to protect your system, why not give Linux a shot?

REFERENCES AND RELATED MATERIALS

• Firewall on a Floppy: www.floppyfw.org

• freshmeat home page: www.freshmeat.net

• Linux Firewall home page: www.linuxfirewall.org

• Linux Links home page: www.linuxlinks.com

• “NAT—Not an Insect but a Powerful TCP/IP Tool,” Barry Kline, MC, September 2000

• “Secure Your AS/400 with IP Filtering,” Barry Kline, MC, August 2000

A

B

C D

E

Figure 1: Create a choke point so you can regulate network traffic.

Firewall (ChokePoint)

The Internet

Computers A, B, C, D, E are nodes within your intranet. All traffic to and from the Internet must pass through the firewall. This depicts a dual-homed firewall.

#!/bin/sh
#

## This code is for demonstrative purposes only. Do NOT expect it to build a
# functional firewall!!!
## The next statement sets the path. This is equivalent to an AS/400 library list
PATH=/sbin:/bin:/usr/sbin:/usr/bin

# As mentioned in the article, some services require special handling. This
# statement checks to see if the ip_masq_raudio module is loaded and if not,
# loads it.
/sbin/modprobe ip_masq_raudio

# Although filewalling code is already compiled in, it’s disabled by default.
# This statement turns it on.
echo “1” > /proc/sys/net/ipv4/ip_forward

# Define what external interface to use and its IP address. This example
# assumes a full-time internet connection.
extip=”204.203.202.201”
extint=”ppp0”

# Assign the internal interface and IP address
intint=”eth0”
intnet=”192.168.1.0/24”

# Assign the IP address for the internal system that we want to access from
# the external internet.
paging=”192.168.1.2”

# First we’ll flush the input chain rules (anything goes!) and then
# set the default policy to deny. That way, anything not explicity
# permitted will be rejected.
ipchains -F input
ipchains -P input DENY

# Now specify what we’ll allow.
# local interface, local machines, going anywhere is valid
ipchains -A input -i $intint -s $intnet -d 0.0.0.0/0 -j ACCEPT

# remote interface, claiming to be local machines, IP spoofing, get deny
ipchains -A input -i $extint -s $intnet -d 0.0.0.0/0 -l -j DENY

# remote interface, any source, going to permanent PPP address is valid
ipchains -A input -i $extint -s 0.0.0.0/0 -d $extip/32 -j ACCEPT

# loopback interface is acceptable.
ipchains -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT

## This is a demonstration of port forwarding. We’re going to forward
# requests to 204.203.202.201, port 998 to 192.168.1.2, port 998
#/usr/sbin/ipmasqadm portfw -f
/usr/sbin/ipmasqadm portfw -a -P tcp -L $extip 998 -R $paging 998

# catch all rule, all other incoming is denied and logged.
ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j DENY

## This is the section that enables network address translation.
#ipchains -F forward
ipchains -P forward DENY

# Masquerade from local net on local interface to anywhere.
ipchains -A forward -i $extint -s $intnet -d 0.0.0.0/0 -j MASQ

# catch all rule, all other forwarding is denied and logged.
ipchains -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j DENY

Figure 2: This is sample ipchains firewall code.

Also Read

Practical OSS: MkDocs for the IBM i, Part 2

Practical OSS: MkDocs for the IBM i, Part 1

Practical OSS: MMAIL from EASY400