The Elements of a Linux Firewall

---

This section details the following primary goals of a firewall, and the next section describes how to customize a Red Hat Linux system to meet these goals and act as a firewall:

• Minimizing exposure

• Locking out the bad guys

• Masquerading

• Servicing the network

Minimizing Exposure

The first priority of a firewall must be to protect itself. After all, if your firewall is compromised, your entire network is exposed. Thus, a good firewall always has minimal exposure to attack.

Being "exposed" to an attack means the machine is running software that has a vulnerability that can be exploited to compromise the system. Typically, an all too-common bug in software known as a buffer overflow allows an attacker to overload the program with carefully created input that causes the program to give the attacker a command line shell. If the program was running as the root user, then this command shell will be running with root privileges, meaning that the attacker has full permissions to the system! (Other types of attacks exist, such as denial-of-service attacks, for which there is little defense without the cooperation of your ISP, and even simple bugs that allow attackers to gain access they're not supposed to have.) If a program with a buffer overflow vulnerability is a network program, then it may also be vulnerable to a remote exploit. If the program is a server program such as an FTP or web server, then a buffer overflow bug can be exploited by a user on a remote system, making the exploit a remote exploit. Remote exploits are the holy grail of system crackers, since they allow attackers to compromise a system without ever even seeing it.

All programs have bugs, and so any server program can have a remote buffer overflow exploit. Even if none exist for a given program, that may not mean that none exist, it simply means that none are known—yet! In other words, any time you have a program running on a system, you are exposing the system to any remote exploits that may exist in that program. It's a risk vs. reward tradeoff: You tolerate the risk of running a program because its usefulness outweighs the risk.

Thus, any server system should run as few services as possible, since unused services are adding risk but no value. This is especially true of a firewall system, since the potential impact of having the system compromised is so great; it makes the risk less acceptable. Thus, a firewall should have as few services running as possible. The firewall as presented in this book runs no services whatsoever that are accessible to the outside network, and runs only a few that are required for the inside network. If you probe this configuration from the outside with a port scanning program (such as the nmap program mentioned later in this chapter), then you won't find anything, and in fact the system may appear to not even be running!

Taking this thought to its logical conclusion, you should uninstall any software you don't use. This way it doesn't take up disk space, and you're guaranteed it isn't running! Additionally, the smaller the installation footprint the better, because tools such as Tripwire (mentioned later in this chapter) are easier to manage with smaller installations. For this case study, you should instruct the system to install only the packages you actually need and omit the ones you do not; there are more details on this later in the section on "Slimming Down the Package List."

Locking Out the Bad Guys

If the firewall's first job is to protect itself, then it's second job (and ultimate goal!) is to protect the network. This essentially means preventing external users from accessing the internal network, at the Internet Protocol (IP) packet level. That is, the firewall simply rejects unauthorized packets bound for the internal network.

This is typically accomplished by configuring the firewall with a set of rules that are consulted for each incoming packet. Each rule consists of a pattern used to identify a packet, and an action to take when a packet matches that pattern. Usually, the pattern can contain things like the source or destination IP addresses, the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port of the packet, the state of the TCP/IP connection, and so on; almost any aspect of the TCP/IP headers can be used in the pattern. The actions typically include accepting the packet, rejecting the packet (by sending an appropriate rejection packet back to the sender), or ignoring the packet entirely. A firewall's configuration is simply a set of rules that implement the policy defined by the network administrators (in this case, by you)!

Clearly, these rulesets are where the real work gets done in a firewall. If there is a mistake in the ruleset, then the network could be exposed. Additionally, sometimes patterns and actions can be pretty subtle, making them tricky to work with. However, there is a general rule of thumb most security experts use: First deny everything, then allow only what you explicitly want.

Really, this is just common sense: If your house has 200 doors but you only use 2, then you really want to just lock all the doors, and only unlock the ones you need when you need to. In the case of your network, the ports, IP addresses, and so on are the doors, so you should create a default firewall rule that rejects all access to the network, and then only allow specific access to the specific ports and IP addresses you need. The configuration script in Listing 16-1 presented later in the section "Creating the Startup Scripts" has more details.

This will all become clearer later as you read about the script that configures the actual firewall ruleset, discussed in the section "Presenting an iptables Script."

Masquerading

Unfortunately, we're not talking about a Victorian-era costume party; no "paper faces on parade" here. Masquerading is a term sometimes used in the Linux community to refer to a special case of Network Address Translation (NAT). NAT is used to make firewalls, well, usable.

The problem with firewalls is that usually they work in both directions: They shut down internal users' access to the outside network just as effectively as they shut down external access to the internal network. This means that legitimate internal users have a hard time accessing Internet resources, such as web sites, File Transfer Protocol (FTP) sites, remote servers via the SSH protocol, and so on. NAT and the special case of masquerading are a way to restore most of the users' ability to access the network, while still retaining the security features provided by a firewall. You should view firewalls and NAT as separate concepts, even though they are implemented in Linux by the same functionality (known as the netfilter or iptables code.)

Masquerading runs on the firewall, and simply takes all frames from internal machines and "mangles" them (which is actually the technical term) so that they appear to have originated from the firewall itself. That is, the firewall masquerades as the originator of the packet. The packet is then relayed to the destination, and any replies to it are unmangled before being returned to the original computer. From the perspective of the destination machine on the Internet, masqueraded packets appear to have originated from the firewall machine, whereas in reality they originated from one of a number of machines behind the firewall.

NAT is more sophisticated than simple masquerading. Essentially, NAT is fullfeatured packet mangling. Masquerading mangles a specific part of the packet for a specific purpose: It mangles the source IP address in order to avoid revealing the existence of the original PC. NAT, however, supports a wider variety of patterns that it can operate on and rules that it can take.

With NAT, you can do things like forward connections to port 80 (the HTTP port) to another internal web server, even though the firewall itself runs no such server. (This is sort of the opposite of Masquerading; this particular form of NAT is known as Destination NAT or DNAT.) Doing so allows the web server to remain safely behind the firewall, exposing only port 80. From outside the firewall, the firewall server itself appears to be the web server, even though that's not the case. Figure 16-1 compares the functioning of masquerading and the reverse or destination NAT just described.

Figure 16-1: DNAT vs. masquerading

In Figure 16-1, two boxes depict network packet transformations that are performed by the firewall. The lefthand box depicts Destination NAT (DNAT), in which incoming requests to a server on the protected network are actually received by the firewall, and forwarded transparently to the actual server. In this box, the solid lines represent actual packets as transmitted from hosts, whereas dotted lines represent packets after they have been transformed by the firewall. What this figure really boils down to is that each host—both inside and outside the firewall—"believes" that it is talking only to the firewall, rather than talking to each other through a middleman. The firewall handles all appropriate transformations to complete that illusion, with the hosts being none the wiser. All software on both hosts runs normally.

The righthand box depicts masquerading, also roughly known as Source NAT. This figure is the analog of the lefthand box, and depicts a client on the protected network attempting to access a server out on the Internet. In this case, the client actually believes that it really is communicating with the real Internet server, and has no idea that the firewall is even present. The firewall, meanwhile, transforms the client's original packets (shown as solid lines) to appear to have come from the firewall itself, so that the remote Internet server believes that it is talking to the firewall. (The transformed packets are depicted as dashed lines.) The server's return packets are then transformed again, this time to tweak the destination address so that they eventually make it back to the client that originally requested them.

Just remember this summary: in the DNAT case, both hosts think that they're talking directly to the firewall, and have no idea that the firewall is merely acting as a middleman. With masquerading, though, the internal protected client believes it is talking directly to the server, whereas the server believes it is talking to the firewall. In both cases, the firewall handles all the transformations that need to occur. Keep this notion in mind as you read the rest of this chapter; it helps to come back to it if the various firewall concepts get blurred in your mind.

The Linux kernel supports firewalls and NAT. Each of the major versions of the kernel has its own mechanism, though. In the 2.0 series, the kernel really only supported IP masquerading and limited firewalling. In the 2.2 series, an enhanced system known as ipchains was developed, and in 2.4 the ipchains functionality was further expanded and called iptables (also known as netfilter).

Red Hat Linux 7.3 uses kernels from the 2.4 series, and so this book describes the use of iptables rather than the earlier versions. However, Debian GNU/Linux and Slackware Linux use the older 2.2 series kernels by default; if you're using those systems, you'll have to read up on ipchains in order to adapt the content in this chapter. Fortunately, the differences are not huge, so by now this should not be too difficult for you. (If you do need information on ipchains, a good starting point would be Linux IPCHAINS-HOWTO at http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html.)

Servicing the Network

The final task of a firewall is to provide some basic services to the other machines on the network. Generally, this involves running a Dynamic Host Configuration Protocol (DHCP) server so that other machines can obtain IP addresses, and a Domain Name Service (DNS) server so that the other machines have access to domain name lookups. Later in this chapter, you'll find discussions about how to set up these services on your firewall.

Some people might argue that services such as DNS and DHCP are not appropriate to install on the firewall computer itself, as doing so would both bog down the firewall with needless computation and make the firewall vulnerable to exploits that exist in the DNS and DHCP server software. Indeed, for many networks it might be more appropriate to have dedicated DHCP and DNS servers. However, this chapter is describing a firewall configuration for a network of modest size, and so it's probably not a big deal to run these services directly on the firewall.

Now that you understand the basics of a firewall and what one has to accomplish, the next section discusses the details of how to build a firewall from a Red Hat Linux 7.3 system.

---