Building the Firewall | Tuning and Customizing a Linux System

< Free Open Study >

This section describes the process of building a firewall from a stock Red Hat Linux 7.3 system. Given the somewhat more complex hardware and security requirements of a firewall, you have to take a bit more care in its installation. The following sections start by explaining how to handle the need for multiple Ethernet cards in your firewall, and then move on to the tasks of selecting packages to install and configuring the actual firewall itself.

Required Hardware: Ethernet Cards

A firewall, if you think about it, doesn't have to do a greal deal. All it has to do is boot up, start a few services for the internal network, and then set up and start running firewall rules. From this, you might rightfully conclude that you don't need much in the way of hardware to run a firewall. At least, for your purposes, you might find that you need quite a bit more horsepower to build a firewall for a large corporate network than you do for the humble SOHO firewall in this example!

The firewall described in this section was implemented on an old spare system with a 166-MHz AMD processor and 128MB of memory. Even that fairly modest configuration is overkill: You can most likely get away with an old 486-class processor and perhaps 16MB of memory. Clearly, it doesn't take much to build a firewall, and you probably need even less power than that. Have you got any "ancient" systems you're using as doorstops?

Abusing Ether

The only remarkable thing, hardware-wise, about the firewall itself is that it has to have two Ethernet cards. After all, you're straddling two networks. Under Linux, though, this can be a bit tricky to manage. When the kernel starts up, it detects Ethernet cards and assigns them interface names in the order in which it detects them. However, it's difficult to predict the order in which the kernel will detect the devices, especially if the devices are run by the same driver (that is, if they are the same model card).

Meanwhile, the firewall rules obviously require that you know the interface names. (How can you tell it to, say, enable masquerading for the external interface if you don't know which interface is the external one?) So, it's clear that you need to control the order in which the Ethernet devices get detected, or at least know which is which.

Naming the Ethernet Devices

There are two ways to get your Ethernet devices named correctly. The first way is actually not to bother renaming them at all. Instead, just figure out which one is going to be external, and which one internal. (Either eth0 is external and eth1 is internal, or vice versa.) Then you can just edit the /etc/sysconfig/firewall settings file that appears later in this chapter in the section "Touring the Script" to set the extiface and intiface variables correctly.

If you prefer to force the eth0 device to be external and eth1 to be internal and you are using two different types of Ethernet cards, then you may have to reverse them. Fortunately Red Hat makes this fairly painless. Red Hat Linux loads the actual device drivers for the Ethernet cards in the order of how they're named; that is, the driver for the card that is supposed to be eth0 is loaded first, and the driver for eth1 is loaded second. It's able to do this because the modules are aliased with names of "eth0" and "eth1" in the file /etc/modules.conf. If your eth0 and eth1 came out switched, just edit /etc/modules.conf, and change the line "alias eth0 <device driver name>" to be "eth1" (and vice versa for the other device). Then you'll either have to unload the modules with the rmmod command (don't forget to first shut down the devices with the ifdown command, since they may already be up), or simply reboot the system.

If you're using two cards of the same model, then life is a little harder for you. Since cards of the same model will both be managed by the same device driver, you can't play the little name-swapping game just described. Your only real alternative is to figure out which card is eth0 and which is eth1, and then modify the /etc/sysconfig/firewall file as shown in Listing 16-2, provided later in this chapter. If you're feeling ambitious, depending on the driver you're using you may be able to pass parameters to the kernel via the bootloader (usually LILO or GRUB, on i386-based systems). If you are really interested, you can look into this, but it's probably quicker just to figure them out by trial and error.

To avoid confusion, the remainder of this chapter assumes that the external Ethernet device is named "eth0", and the internal device is named "eth1". Just keep this in mind, and adjust for it if your configuration is different.

Using the Firewall with a Dial-up Connection

This chapter assumes that your firewall's connection to the outside world uses an Ethernet network. This is typically the case for common broadband connections like DSL and cable modems, and for other permanent connections like T1 lines or ISDN. However, if your connection is a dial-up phone link via an acoustic modem, you'll need to do some extra work.

In that case, your ISP is probably using the Point-to-Point Protocol (PPP) and your external interface will most likely be ppp0. You internal device will therefore probably be eth0. The scripts presented in this chapter can handle this case; however, you'll have to set up the PPP link yourself. Fortunately this is decribed in detail in the PPP HOWTO at http://www.linuxdoc.org/HOWTO/PPP-HOWTO/index.html.

Configuring the Interfaces

Once you've got you Ethernet devices named in the right order, it's time to set them up. Generally, you'll use Red Hat's /usr/sbin/netconfig command to configure them. This is a text-based program that prompts you for all the information required to configure the device. If you prefer, you can also edit the files /etc/sysconfig/network-scripts/ifcfg-<device-name> and edit the contents manually. It's probably easier to just use netconfig; you can pass it the -d argument to specify which interface to use; for example, netconfig -d eth1 will configure the eth1 device.

You'll need to configure the external interface (which is eth0 in this example), however your Internet service provider (ISP) instructs you to; typically this will either be a static IP address or the DHCP protocol. Configure the external device just as you would if you were connecting a standalone workstation to your ISP connection.

You'll need to configure the internal interface statically. Your firewall will be the router for your internal network, so it always has to have the same IP address. Typically this will mean you'll assign it an IP address of something like 192.168.0.1, a netmask of 255.255.255.0, and leave the gateway and default nameserver fields blank. (The firewall will itself be acting as a gateway and name server for your other computers.) To know which IP address you should use, see the section later in this chapter entitled "Presenting an iptables Script."

To help you visualize all this, Figure 16-2 depicts the network configuration just described. It also includes some additional network components such as an Ethernet switch and optional Wireless Access Point, which is discussed later on in the section "Integrating a Wireless LAN."

click to expand
Figure 16-2: Example Network Topology

In Figure 16-2, the network firewall server is included, along with the Ethernet switch and a WAP, as part of the network's infrastructure. The infrastructure is collectively the technology that allows the four hosts depicted to communicate with each other, and ultimately with the Internet. The firewall also handles the additional task of keeping the hosts secure and isolated from the untrusted Internet. Of the four hosts, two are depicted as using traditional Ethernet (with wires), whereas the other two are depicted as using the newer 802.11 wireless Ethernet technology. The firewall is not aware of this distinction, and serves all hosts equally well.

Now that you understand the basics of the network configuration you need, it's time to consider how to actually install the system. The next few subsections walk you through this task; the next section makes some comments on sources you can use for the installation media.

Choosing Installation Media

Now that you've got the hardware in hand, you'll need to install the distribution. There's nothing too surprising here; you simply install Red Hat Linux as you normally would. However, you have to put a little thought into where you install from—that is, what installation media you use. Specifically, you may not want to perform a network installation, for two reasons.

The first reason is that if you're installing off the network, it's possible for someone to insert "Trojan horse" replacements for packages that include hostile code that opens up backdoors on your system. There have been many reported cases of crackers compromising software programs and replacing them with Trojan horses; probably the most prominent case was that of the tcp_wrappers program, which is itself security-related software! The same thing could, in theory, happen to a public installation repository such as Red Hat's site. This means that in installing your system over the network from a public FTP or HTTP server, you could be subjecting yourself to a Trojan horse. Is this a real possibility, or just a theoretical one? Well, it seems unlikely to happen, but then again any cracker would love the opportunity to compromise an installation server in this way.

The second—and far more likely—scenario is simply that the installation takes time, which means that your system is or at least may be vulnerable for the small window of time it takes to complete its configuration. For example, in this case study there are many tasks that have to be completed after you've installed the base Red Hat Linux system. In the time it takes you to complete them, an attacker could compromise your shiny new firewall. In these days of large-scale automated port scanning and a "lifetime" of 15 minutes, it's a very real possibility that someone could notice your new firewall on the network and compromise it before you can fully secure it.

These are real possibilities, though they may be remote. It's therefore probably a good idea to avoid network installations as much as possible, and install from reliable media such as CDs. If you absolutely must install from the network, then just keep these issues in mind. The safest firewall installation is one that occurs with the Ethernet cables unplugged.

Slimming Down the Package List

Recall that it's best to keep the list of installed packages on your server as small as possible. For example, don't even install any packages related to the X Window system, since it's a really bad idea to let users log in and work on the firewall computer. In general, the following types of applications are not necessary to a firewall and don't really need to be installed:

User desktop software (XFree86, GNOME, KDE, multimedia software, and so on)
Development tools (gcc, the GNU debugger, the Perl language, and the like)
Server software (such as web servers and inetd)
General user programs (FTP clients, text editors, printing tools, etc.)

By keeping the package list small, you'll not only keep the system lean and mean, you'll also save space (allowing you to install on older, smaller disk drives), and programs like Tripwire will be easier to manage. (Tripwire is discussed toward the end of this chapter in the section "Using the Tripwire Intrusion Detection System.")

Table 16-1 is the list of packages installed on the firewall system used to create this case study. Your list may vary, depending on what you need; just make sure that you have a legitimate reason for every package that's installed!

Table 16-1: A Sample Firewall Package List
anacron	ed	kernel	openssh-server	sh-utils

apmd	file	kernel-headers	openssl	slang
ash	filesystem	ksymoops	pam	slocate
at	fileutils	kudzu	parted	statserial
basesystem	findutils	less	passwd	sysklogd
bash	ftp	libstdc++	pciutils	SysVinit
bdflush	gawk	libtermcap	popt	tar
bind	gdbm	logrotate	procps	tcl
bind-utils	glib	losetup	psmisc	telnet
bzip2	glibc	mailcap	pump	termcap
bzip2-libs	glibc-common	MAKEDEV	pwdb	textutils
chkconfig	gmp	man	python	time
console-tools	gnupg	man-pages	python-popt	tmpwatch
cpio	gpm	mingetty	python-xmlrpc	traceroute
cracklib	grep	mkinitrd	rdate	up2date
cracklib-dicts	groff	mktemp	readline	utempter
crontabs	grub	modutils	redhat-logos	util-linux
db1	gzip	mount	redhat-release	vim-common
db2	hdparm	ncompress	rhn_register	vim-minimal
db3	hotplug	ncurses	rootfiles	vixie-cron
db3-utils	info	netconfig	rpm	wget
dev	initscripts	net-tools	rpm-python	which
dhcp	iproute	newt	sed	whois
diffstat	iptables	nmap	setserial	words
diffutils	iptables-ipv6	openssh	setup	zlib
e2fsprogs	iputils	openssh-clients	shadow-utils

Note

The list in Table 16-1 contains only RPM package names such as "openssh-clients" with no version, since the specific versions will vary from distribution to distribution, and from version to version.You can compare this list to yours, but just remember that the actual package name as installed on your system will include the version.

Adding Security Packages

Once you've installed the basic distribution, it's time to start customizing it. Perhaps the first thing you'll wish to do is install a few popular security-related tools on it. This section briefly discusses one of these tools, the nmap network mapper.

The nmap program is a tool for discovering network topology. Most readers will be acquainted with the common network diagnostic tools of ping, traceroute, and telnet. (For those of you who aren't, it's worth it to take a quick read through their manual pages, because they are truly very useful tools.) The nmap program is used to map out network topology and is a great addition to this arsenal.

Essentially, nmap addresses weaknesses in each of those other programs. The ping program, for example, can be used to check whether a host is up and running and on the network, but it can only check one host at a time. The telnet program, meanwhile, allows you to test arbitrary TCP ports to see if a host has any servers listening on them; however, it can only test one port at a time. The nmap program is capable of scanning ranges of IP addresses and can test for the presence of a variety of servers in a variety of ways.

Since nmap is a port-scanner, it is an extremely popular tool among the cracker crowd. That means that an attacker might very well use nmap to probe your network or your firewall for potential vulnerabilities. Fortunately, nmap is available to you, too, so you can use it to test your own network for the same vulnerabilities.

Red Hat Linux also includes a package of nmap, but again it's not installed by default. Once you've got it installed, it's fairly easy to use, and its manual page and command-line help are quite good. The online documentation at http://www.insecure.org is also a great resource. However, the command that you as a network administrator securing your network are most likely to use frequently is this:

 $ nmap -sT -p 1-1024 <hostname>

This command scans the machine <hostname> (which can also be a range of IP addresses, if you want to test your whole network at once) using the standard TCP scan method for open services on ports 1 through 1024. Most of the historically vulnerable Unix services reside on these low 1024 ports; you should probably also scan the higher ports as well, since occasionally crackers will install backdoor programs that open ports on compromised hosts.

As you assemble your firewall, run that command periodically, and watch as the output changes. When you're done, your system should appear to be almost invisible to nmap —or any other tool—except for the ports that you want to be open. Throughout the remainder of this section, the text will refer to nmap and describe the output that you should expect to see.

Setting Up User Accounts

During the system installation of Red Hat Linux, you'll be prompted to create at least one user account. Generally, it's a good idea to use the root account only for maintenance of a system, since this minimizes the potential damage you can do if you make a mistake. However, things are a bit different on a firewall.

Earlier in this chapter under "Minimizing Exposure", you read about remote exploits. These are vulnerabilities in server programs (usually through a common programming bug known as a buffer overflow) that allow attackers to gain unauthorized access to a system. However, nonserver programs can also have vulnerabilities. This type of weakness might still allow an attacker to gain root access, but only if she already has a normal user account.

Thus, having user accounts on a firewall system opens you up to another class of vulnerabilities. It's sort of like letting the crackers open a second front on your war against them. Moreover, normal users don't have any use for the firewall, anyway; this is a machine that does one task only. For these reasons, it's a good idea to not even create any local user accounts. If you use a centralized user authentication scheme such as Network Information Services (NIS), Kerberos, or Lightweight Directory Access Protocol (LDAP), you should not connect your firewall to these systems.

Configuring a New Kernel

As you know by now, the kernel is the core of the operating system. On a firewall system, all of the real action—that is, processing the firewall rules—occurs in the kernel. From this perspective, then, the kernel is the firewall. It's just as important to keep the kernel secure as it is the rest of the system.

The Linux kernel has the ability to use dynamically loadable modules for things like device drivers and additional features. (For example, the netfilter functionality itself is loaded as a kernel module.) This is a great convenience; however, it also means that you can alter the behavior of the kernel while the system is running.

Because of this, some people argue that crucial, secure systems such as firewalls should not be built with support dynamic modules. This prevents attackers from loading hostile modules and causing even more damage. However, it's also true that if the attackers can load modules at all, then they must by definition have root access to the system, and so they can replace the kernel anyway if they are determined enough. Of course, that would still require rebooting the firewall, but at least you're more likely to notice a firewall reboot (since it would temporarily shut down access to the outside network) than you are someone tinkering with the firewall. At any rate, it's an idea to consider. (For another alternative, see the section "Booting from Read-Only Media" later in this chapter.)

Creating the Startup Scripts

The best firewall setup in the world is useless if it isn't running. This section will discuss how to configure the system to start up the firewall on bootup. This section also goes into detail on the exact firewall rules. This is probably the most important section in this chapter; so far you've learned about concepts, but now you'll learn the details.

Selecting the Startup Services

As discussed in Chapter 4, Red Hat Linux uses the SysV model for its init scripts. Red Hat also provides a couple of tools—namely, chkconfig and service—that make it easy to manage these scripts. You will use these tools to set up the system. Specifically, you need to disable the default firewall configuration (if you had it running) to replace it with the custom system developed in this chapter.

Disabling the Default Firewall

Red Hat Linux's firewall configuration is contained in the SysV service ipchains. This means that the actual script file itself is /etc/init.d/ipchains. (This script functions by reading actual rules from the file /etc/sysconfig/ipchains, so if you're curious as to what Red Hat's default firewall looks like, that's the file to read.) In order to disable this script, you have to modify the symbolic links in the rc.d directories—for example, /etc/rc5.d for runlevel 5—or use the chkconfig tool.

In addition to disabling the ipchains script, you should also disable the iptables script. (The iptables and ipchains scripts are mutually exclusive; only one system can be used at a time. Normally, ipchains is enabled and iptables is not unless you altered the default, but you might as well disable both.) The following commands will shut down and permanently disable both scripts:

 $ chkconfig --del ipchains $ chkconfig --del iptables $ service ipchains stop $ service iptables stop

Executing the preceding commands will disable the default Red Hat firewall on your system. This may leave you temporarily exposed to attack. If you selected your package list appropriately and disabled all the services, then you shouldn't have any trouble. However, you may wish to proceed with the system disconnected from the external network until you finish configuring the iptables script anyway.

Running a Scan

At this point, it's worthwhile to run a quick port scan to see where you stand. If you run the nmap command introduced earlier in this chapter under "Adding Security Packages", you should see results indicating that the host is up, but with no ports open. If nmap reports any open ports, you probably have some services still running. Use the command netstat -a -p to determine which processes are running, and then use the service and chkconfig commands to shut them off.

ipchains vs. iptables

You probably noticed that even though Red Hat Linux uses a 2.4-series kernel, the default firewall configuration is based on the older, 2.2-series ipchains functionality.

For this reason, and because a few security issues have been uncovered (and fixed), you may wish to consider using the older, tried-and-true ipchains support (which is still available with 2.4-series kernels). In order to do this, though, you'll have to convert this chapter's content to the older system. The netfilter code should be just fine, however, as long as you keep your kernel up to date.

Presenting an iptables Script

Now that you've disabled the default firewall configuration, it's time to install the "new and improved" firewall. This is, of course, simply a script (like the /etc/init.d/ipchains and /etc/init.d/iptables scripts) that runs as a SysV service. The script you use, named simply "firewall", is presented in Listing 16-1. To install this script, simply copy it into the /etc/init.d directory as /etc/init.d/firewall, and then run the command chkconfig --add firewall. The next sections decompose the script and discuss its features.

Listing 16-1: A Firewall Configuration Script

 #!/bin/sh # # firewall        Set and activate firewall rules and IPmasq # # chkconfig: 2345 70 25 # description: Activate/Deactivates firewall rules and masquerading. PATH=/sbin:/bin:/usr/sbin:/usr/bin . /etc/rc.d/init.d/functions . /etc/sysconfig/network [ ${NETWORKING} = "no" ] && exit 0 if [ -x /etc/sysconfig/firewall ]; then     . /etc/sysconfig/firewall else     action "Firewall setup: No /etc/sysconfig/firewall" /bin/false     exit 1 fi case "$1" in  start)       # enable reverse path filtering (prevents IP spoofing across interfaces;       # e.g. prevents someone outside from pretending to be inside)       for iface in $extiface $intiface lo; do           echo 1 > /proc/sys/net/ipv4/conf/$iface/rp_filter       done       # flush table & set default policies: DROP everything except what we       # explicitly allow       iptables -F       iptables -t nat -F       iptables -P INPUT DROP       iptables -P OUTPUT DROP       iptables -P FORWARD DROP       # localhost is friendly       iptables -A INPUT -i lo -j ACCEPT       iptables -A OUTPUT -o lo -j ACCEPT       # DO accept input related to legitimate connections       iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT       # DO allow traffic originating from this machine to go out       iptables -A OUTPUT -s $extip -j ACCEPT       # specifically allow forwarding of internal iface to external iface,       # and activate MASQUERADING (AKA SNAT with auto-remangling)       iptables -A INPUT -i $intiface -j ACCEPT       iptables -A FORWARD -i $intiface -o $extiface -j ACCEPT       iptables -A FORWARD -m state -i $extiface -o $intiface \                --state ESTABLISHED,RELATED -j ACCEPT       iptables -t nat -A POSTROUTING -o $extiface -j MASQUERADE       # set up DNAT redirections, to relay ssh, web, etc. to internal server       for port in $redir_ports; do           # first allow the packets into the system...           iptables -A FORWARD -i $extiface -o $intiface -p tcp \                    --dport $port -j ACCEPT           # ...and then send them where they belong           iptables -t nat -A PREROUTING -p tcp -i $extiface --dport $port \                    -j DNAT --to $intserver       done       # enable ssh connections to this machine from internal net ONLY       iptables -A INPUT -i $intiface -p tcp --dport ssh -j ACCEPT       # allow traffic generated on this machine to the internal network       iptables -A OUTPUT -o $intiface -j ACCEPT       # drop reserved/private IP packets that come in from outside       # these get dropped by the default policies anyway, but dropping them       # here keeps them from getting logged below, which reduces log spam       iptables -A INPUT -i $extiface -s 192.168.0.0/16 -j DROP       iptables -A INPUT -i $extiface -s 10.0.0.0/8 -j DROP       iptables -A INPUT -i $extiface -s 172.16.0.0/16 -j DROP       # log everything else that's about to get dropped -i.e. log anomalies       iptables -A INPUT -m limit --limit 5/second -j LOG       iptables -A OUTPUT -m limit --limit 5/second -j LOG       iptables -A FORWARD -m limit --limit 5/second -j LOG       # Finally, enable IP forwarding now that everything is safe       echo "1" > /proc/sys/net/ipv4/ip_forward       action "Firewall startup" /bin/true       ;;  stop)       iptables -F       iptables -X       iptables -P INPUT ACCEPT       iptables -P OUTPUT ACCEPT       iptables -P FORWARD ACCEPT       echo "0" > /proc/sys/net/ipv4/ip_forward       action "Firewall shutdown [WARNING: system is unprotected]" /bin/true       ;;  status)       [ 0 != 'cat /proc/sys/net/ipv4/ip_forward` ] && \               echo "Forwarding enabled."       echo "Firewall rules:"       echo "***************"       iptables -L       echo       echo "NAT rules:"       echo "**********"       iptables -t nat -L       ;;  restart)       $0 stop       $0 start       ;; esac

Touring the Script

The firewall script is a Bourne shell (/bin/sh) script, and the first few lines are shell comments. Of particular note are these two lines, which permit the script to be used with Red Hat's chkconfig tool:

 # chkconfig: 2345 15 85 # description: Activate/Deactivates firewall rules and masquerading.

These lines configure the firewall script to be run on runlevels 2 through 5 (which are all the runlevels under which networking is enabled on Red Hat Linux). The service is also run with priority of 20; this places it after the network is activated, but before most other services are started. In other words, the firewall is started as soon as possible in the bootup process.

Cross-Reference

For more information on using chkconfig and creating chkconfig-aware scripts, see Chapter 4.

The next few lines set up some basic environment variables, and load some common scripts used by all SysV scripts on Red Hat Linux:

 PATH=/sbin:/bin:/usr/sbin:/usr/bin . /etc/rc.d/init.d/functions . /etc/sysconfig/network [ ${NETWORKING} = "no" ] && exit 0

Specifically, the /etc/rc.d/init.d/functions file contains some useful functions for writing SysV scripts, and the /etc/sysconfig/network file contains values for various network parameters. There is also a check for whether networking is enabled; obviously no firewall is required if the network is down.

Creating the /etc/sysconfig/firewall File

The next few lines check for the presence of an /etc/sysconfig/firewall file, which contains values for several variables important to the script:

 if [ -x /etc/sysconfig/firewall ]; then     . /etc/sysconfig/firewall else     action "Firewall setup: No /etc/sysconfig/firewall" /bin/false     exit 1 fi

If the file isn't present, the script generates an error message and terminates.

As you'll recall from Chapter 4, Red Hat Linux uses the /etc/sysconfig directory to store files containing data required by other scripts and programs. For example, the /etc/sysconfig/mouse file contains settings used to configure the system mouse. Files in /etc/sysconfig are expected to be volatile, meaning that their contents change from system to system. This makes it easier to manage RPM packages, since all the volatile files are in one place; for a full discussion, see Chapter 4. Listing 16-2 contains a sample /etc/sysconfig/firewall with typical values.

Handling a Potential File Conflict

The /etc/sysconfig/firewall script presented in this chapter may conflict with another file installed by a standard Red Hat Linux package. Namely, the "firewall-config" RPM package installs a file named /etc/sysconfig/firewall. This means that if you have this package installed, you'll have a conflict. However, the firewall-config package is actually an X Window program. Since you're building a firewall here and you won't have X installed, you can't have firewallconfig installed, and therefore the conflict shouldn't arise.

If you're building your system to do double duty as a desktop machine, though, you may run into this conflict, so it's useful to be aware of it. (If you need both installed, to avoid the conflict you can rename the firewall configuration file to something other than /etc/sysconfig/firewall. Just remember to change your copy of Listing 16-1 to match.) The firewall-config program is always optional, in any case.

Listing 16-2: Sample /etc/sysconfig/firewall Configuration

 # variables read by the firewall startup script extiface=eth0 intiface=eth1 intip=192.168.0.1 extip=`/sbin/ifconfig $extiface 2> /dev/null | sed -n \     's/^.*inet addr:\(\([0-9]*\.\)*[0-9]*\) *.*$/\1/p'` redir_ports="ssh http https" intserver=192.168.0.3

Essentially, the /etc/sysconfig/firewall file simply has to assign six variables. These variables are listed in Table 16-2 along with their meanings. The extip variable deserves particular attention: The line defining it in Listing 16-2 is actually a shell command that extracts the IP address of the external interface from the output of the ifconfig command. This technique is useful for cases where the IP address of the firewall itself varies, as is typical of the cable modem and DSL connections popular with many SOHO environments, and on dial-up connections that use the Point-to-Point Protocol. If your particular situation permits you a static IP address, you should replace the definition of extip with your hardcoded IP address.

Table 16-2: Firewall Configuration Variables
VARIABLE	TYPICAL VALUES	MEANING

extiface	eth0, ppp0	The name of the external network interface connecting the firewall to the Internet
intiface	eth1	The name of the network interface connected to the internal protected network
extip	Assigned by ISP	The IP address of the firewall on the Internet
intip	192.168.x.x	The IP address of the firewall on the internal protected network; usually one of the reserved unroutable IP addresses
redir_ports	Varies	A list of ports separated by spaces that are to be transparently forwarded to an internal server
intserver	IP Address	The IP address of a server on the internal network that handles requests on the ports in redir_port

The values that you should place in /etc/sysconfig/firewall vary according to your particular situation. For starters, the extiface variable will depend on how you connect your firewall to the Internet. If you're using a cable modem or DSL, chances are this will be an Ethernet device such as "eth0". If you're using a dial-up connection, though, you might be using PPP, and the device might be "ppp0".

For the internal interface variable intiface, you'll most likely be using an Ethernet device such as "eth1". Ethernet devices are named according to the order in which the kernel detects them; the first device is "eth0", the second is "eth1", and so on. As a result, your particular system might boot in such a way that your internal network card is actually detected first, making it eth0 and making the external interface eth1. In this case, you'll have to ensure that your extiface and intiface variables are set correctly. (You'll encounter a similar situation if you use a PPP dial-up connection to connect to the Internet: Your extiface might be "ppp0", but your intiface will probably be "eth0".)

Using the Firewall Script with PPP Connections

If you're using your internal network and firewall to share a PPP dial-up connection among several computers, then you won't be able to run the script in Listing 16-1 as a SysV script. This is because dial-up connections are only active when the modem is in use, so until you dial in, you have no external IP address (or PPP network interface) for the script to use!

Instead of running it as a SysV service, you'll have to run Listing 16-1 after you've dialed in. Additionally, you'll have to use Listing 16-1 to shut down the firewall rules after you hang up and the PPP connection goes down. For more information on how to do this, check the manual page on pppd (the PPP daemon) for more information.

Another alternative is to use the "demand-dialing" feature of pppd, which will enable the PPP device (for example, ppp0) but not physically dial in. This allows you to continue to use Listing 16-1 as a SysV service. Again, consult the manual page for more information.

Once you've correctly identified your network interfaces, determining their IP addresses is easy. For the external interface, your IP address will probably be assigned to you by your ISP, in which case it will be automatically detected in Listing 16-2. However, now you must choose an IP address for the internal network.

For most SOHO environments, your internal network will probably be pretty small. You'll therefore only need a single Ethernet subnet—that is, you won't need any extensive routing. For this case, you can assign your internal network IP addresses on the 192.168.0.x network. For example, your firewall might have address 192.168.0.1, and other machines might have addresses starting at 192.168.0.2.

Choosing an IP Address Range

The Internet Assigned Numbers Authority (IANA) standards body at http://www.iana.org assigns IP address ranges to organizations that require them. IANA, however, reserves three address ranges for testing, research, and other purposes. (There are three "classes" of IP networks—A, B, and C—of varying sizes. Class A is the largest, and C is the smallest.) These IP ranges are considered "nonroutable", meaning that they'll generally be ignored by routers and similar equipment. However, because they're reserved, they're free for anyone to use without restriction. Additionally, since the firewall being constructed in this chapter performs Network Address Translation, the IP addresses of the internal protected network are invisible to observers on the Internet. For this reason these unroutable network ranges are useful (and safe to use!) for this basic SOHO case.

You can really use any of the unroutable network ranges; I simply chose the 192.168.x.x range because it's the Class C range, and it would be very unusual for a SOHO environment to need more than that. However, you can choose any range you want. The ranges are 10.x.x.x for Class A addresses, 172.16.x.x (or any network range up to 172.31.x.x) for Class B addresses, and 192.168.x.x for Class C addresses.

Setting the DNAT Variables

The remaining variables in /etc/sysconfig/firewall are redir_ports and intserver. These variables are used to configure the DNAT rules that allow public access to servers (such as a web server) running behind your firewall. When activated, these rules instruct the kernel to forward any incoming connections on the indicated ports to another machine inside the firewall. The protected machine is otherwise invisible; to an outside observer, it will appear as though the firewall itself is accepting the connections.

Two variables in /etc/sysconfig/network activate this functionality: One is a list of ports to forward to an internal server, and the other is the IP address of the internal server. The IP address is simple: Just enter the IP address of the computer you're using as a server as the value of the intserver variable. (Read the section "Installing DHCP for Internal Machines" for more information.) The list of ports, meanwhile, is stored in the variable redir_ports, and is a list of ports (or the symbolic names of ports from the /etc/services file) separated by whitespace.

Note

Remember to include the list of ports in quotes, since it has to be a single variable!

Once you've set these variables, the script will automatically configure rules setting up DNAT redirections for each listed port to the IP address specified. The example in Listing 16-2 configures three ports: HTTP, secure HTTP (HTTPS), and SSH. Read the next section for more details on how DNAT actually works and is configured.

Understanding the Firewall Rules

Now that you've seen the /etc/sysconfig/firewall (with an example in Listing 16-2), you can return to Listing 16-1. Since Listing 16-1 is a SysV init script, it supports these four targets, or commands:

start
stop
restart
status

This isn't a book on shell programming, so there won't be an extensive discussion of the structure of the shell script. Specifically, you won't be reading about how the "framework" of the script works, and how each individual target is executed. If Listing 16-1 isn't clear to you, you should consult your favorite shell scripting reference.

You should keep in mind that this chapter will not necessarily make you an expert in building firewalls. It's important to remember that the focus of this chapter is to illustrate an example of how to take a stock installation of a Linux distribution and extensively customize it for your own needs, rather than to delve deeply into the very complicated world of computer security and firewall design. (If you are interested in those topics, Ziegler's Linux Firewalls, Second ed. is an excellent reference.) Remember this as you read the rest of this section. Hopefully you'll find enough detail to understand what's going on, but the goal is not a mastery of firewall design.

Starting the Firewall

The start case in the /etc/init.d/firewall script starts up the firewall by configuring a variety of netfilter rules via the iptables command, and executing a few other commands.

The first step in starting up the firewall is to enable reverse path filtering. This is a feature provided by the Linux kernel that drops packets whose "reverse path" doesn't match the IP address. For example, your firewall will only expect to "see" IP addresses in the range 192.168.x.x coming from inside the firewall—that is, from the eth1 device. If the kernel ever sees a packet coming from a 192.168.x.x address coming in over eth0 device, it can reasonably assume that the packet is either mistaken or an indicator of a hostile attack known as an IP spoof. The kernel will have to be compiled to include reverse path filtering support.

These lines enable reverse path filtering on both the internal and external network interfaces (as well as the local loopback device, just for safety's sake):

 for iface in $extiface $intiface lo; do     echo 1 > /proc/sys/net/ipv4/conf/$iface/rp_filter done

The next block of commands establishes the default policies for the firewall. These are the "catch-all" policies; the kernel uses them to decide the fates of packets that don't trigger any of the other rules. Good firewall design says that you should always deny everything by default, and explicitly accept only the packets you want to allow.

The following lines first flush the kernel of any preexisting rules, and then set default policies:

 iptables -F iptables -t nat -F iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP

Note that the OUTPUT chain is set to accept packets by default; this is because any packets that originate from the firewall (or are allowed to pass through it) are almost certainly safe. The other chains—INPUT and FORWARD—are set to drop all packets by default.

Next, the script starts executing rules that allow desired packets. The first such rules essentially give unrestricted access to the local loopback device, named "lo". This is the "phantom" network device that always has IP address 127.0.0.1. Since the loopback device is by definition local to the machine, it can be fully trusted. These lines accept packets on the loopback device:

 iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT

The next few lines in the /etc/init.d/firewall script are noteworthy because they are not used—they're disabled as comments:

 # iptables -A INPUT -i $intiface -j ACCEPT # iptables -A OUTPUT -o $intiface -j ACCEPT

What these rules would do if they were enabled is to implicitly trust the internal network device—that is, eth1—in the same way that the loopback device is trusted. The rationale for this would be that machines inside the firewall should be friendly, right? Well, perhaps on first blush, but if you think about it, there's no real reason that even internal machines need full access to the firewall. Suppose, for example, that you set up a wireless Ethernet network and connect it to your firewall. It would be possible for an attacker to "hijack" an IP address on this wireless network and attack your firewall from the inside. To avoid this kind of risk, these rules are commented out, protecting the firewall even from hostile attackers on the inside.

At this point, the firewall is configured to reject everything that comes in over the Ethernet devices; only the local loopback device is permitted to do anything. The firewall server might as well not even have network cards! The subsequent sets of commands are the ones that really start to establish the behavior of the firewall.

The next rule instructs the firewall to accept any packets that are known to be associated with legitimate connections requested by a user on the firewall system itself or behind the firewall:

 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

This is a crucial step: Without this rule, computers on your network could send communications to whatever hosts on the Internet that they desire—but they'd never get a response back! Of course, this rule only applies to incoming packets associated with known connections; any incoming packets that weren't solicited by a computer inside the firewall are still ignored.

The next set of rules turns on the IP masquerading functionality, discussed earlier in this chapter in the section "Masquerading." The term "masquerading" is specific to the Linux community; the same process is frequently referred to as Network Address Translation by other operating systems. Actually, even within Linux, masquerading is just a special case of what is called Source NAT (SNAT). Network Address Translation in general refers to when a firewall modifies the header of an IP packet to make it appear to have either a different source or destination; SNAT specifies the former type of modification, and DNAT indicates the latter.

However, IP masquerading obviously can't do anything if the packets get rejected before they even get in the door! Thus, the first two commands that follow allow packets from the internal interface into the kernel, and allow them to be forwarded to the external interface. This allows IP masquerading to be performed on them. Note that setting up forwarding has to have two rules—one for outgoing packets, and one for incoming responses; the incoming rule is further restricted to only relay packets related to known connections.

The following lines from /etc/init.d/firewall enable input and forwarding from the internal interface, and set up IP masquerading:

 iptables -A INPUT -i $intiface -j ACCEPT iptables -A FORWARD -i $intiface -o $extiface -j ACCEPT iptables -A FORWARD -m state -i $extiface -o $intiface \          --state ESTABLISHED,RELATED -j ACCEPT iptables -t nat -A POSTROUTING -o $extiface -j MASQUERADE

In the section "Setting the DNAT Variables", you read about the redir_ports and intserver variables specified in /etc/sysconfig/firewall. The next rules in Listing 16-1 actually make use of those variables. For each port specified in the redir_ports variable, two rules are created. One rule allows packets on that port that come in from the Internet over the external interface (eth0) to actually enter the system and be forwarded, and the second causes them to be redirected to the internal server.

This allows you to configure a server system running a service such as the Apache HTTP server, place it behind the firewall where it's protected, and still have it be accessible from the public Internet. In other words, this exposes your protected server's ports to the Internet. The following lines accomplish this task:

 for port in $redir_ports; do     # first allow the packets into the system...     iptables -A FORWARD -i $extiface -o $intiface -p tcp \         --dport $port -j ACCEPT     # ...and then send them where they belong     iptables -t nat -A PREROUTING -p tcp -i $extiface \        --dport $port -j DNAT --to $intserver done

Exposing Ports

It's probably obvious, but it's still important to remember that if you set up DNAT port redirection as discussed in this section, then those ports on your server are actually exposed to the Internet! For example, if you expose an SMTP mail server such as sendmail, then your server will be vulnerable to any security exploits that exist in sendmail. This still puts your server system at risk, so use DNAT with caution, and don't expose ports unless you really need to.

Chances are you'll periodically have to perform routine maintenance on your firewall. However, you might want your firewall to be placed somewhere out of the way, such as in a quiet corner or a closet, and so you might not have a monitor and keyboard connected to it. For this reason, it's useful to be able to access the firewall remotely, via the Secure Shell (SSH) protocol. (The OpenSSH server can be configured on the firewall as discussed in Chapter 8.)

The following command accepts SSH connections to the firewall—but only from the internal interface, eth1!

 iptables -A INPUT -i $intiface -p tcp --dport ssh -j ACCEPT

By restricting OpenSSH to only listen on the internal interface, you ensure that it is still not accessible to the outside world, even if the firewall script is temporarily disabled.

The last relevant line in the "startup" component of the /etc/init.d/firewall script enables IP forwarding:

 echo "1" > /proc/sys/net/ipv4/ip_forward

Essentially, this instructs the kernel to start behaving as a network router. Until this command is executed, the firewall won't actually do anything useful, since the kernel will simply ignore any packets not destined for it. Enabling IP forwarding allows packets to actually make it into the netfilter rules.

Stopping the Firewall

Deactivating the firewall is much easier than starting it up. All that needs to be done is to flush out and clear that the kernel's list of packet filtering rules, reset the default policies, and disable IP forwarding. The following lines accomplish exactly that, and shut down the firewall. (This will also leave the firewall exposed, so don't keep it connected to the Internet if you shut down the firewall service.)

 iptables -F iptables -X iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT echo "0" > /proc/sys/net/ipv4/ip_forward

One interesting feature of this /etc/init.d/firewall script is that the start command also begins with the command iptables -F. This means that in a certain sense, the start command also implicitly shuts down the firewall first, before re-creating it. In other words, you don't actually need to run service firewall stop before calling service firewall start.

Checking the Status of the Firewall

There isn't a good way to check to see if the firewall is running or not, since it's not a daemon program that you can simply look for in the list of running processes. Rather, the firewall is a set of kernel rules, and the only way to check on its status is to list all current rules.

That's exactly what the status command to /etc/init.d/firewall does, by executing the following commands:

 [ 0 != 'cat /proc/sys/net/ipv4/ip_forward` ] && \         echo "Forwarding enabled." echo "Firewall rules:" echo "***************" iptables -L echo echo "NAT rules:" echo "**********" iptables -t nat -L

The script also reports on whether IP forwarding is enabled.

Restarting the Firewall

The final command, restart, is the simplest of all. It literally just recalls the script with the stop command, and then calls it again with the start command. (Of course, this is redundant since, as mentioned previously, you don't technically need to call stop before start.) These lines are all it takes to implement restart:

 $0 stop $0 start

Validating the Installation

Now that you have the basic system installed, and the firewall rules running, it's a good time to do another quick port scan of your system using the nmap program introduced earlier in this chapter in the section "Adding Security Packages." However, you'll quickly find that this isn't as easy as it was before, because your firewall will have a different port scan depending on where you scan it from!

For example, if you connect your machine to the Internet and scan it from a remote host with nmap, it won't even appear to be on the network, except for the ports you list in the redir_ports list. If you scan it from inside the firewall, you'll get different results, and if you scan it from localhost, you'll yet again get different results! This, of course, is the point.

When scanned from outside, the firewall should have all ports filtered except the ones you put in the redir_list, which are 22 for SSH, 80 for HTTP, and 443 for HTTPS in this example. (These ports will appear to be either closed or open, depending on whether your internal server is actually running at the moment.)

When scanned from the internal network, all ports should appear closed except port 22 for SSH. When scanned from localhost, you might see SSH depending on how you configured OpenSSH.

Summary and Limitations

This section described the /etc/init.d/firewall script that sets up the kernel's network packet filtering rules. You should now have a good grasp of what the script does, and how it accomplishes its goal as a firewall. However, this isn't the whole story, and this script has limitations.

For example, consider the rules that set up DNAT. These rules cause a list of ports on the firewall to be redirected to an internal server. However, the way the script is written, all the ports get redirected to the same server. What do you do if you want to have HTTP requests sent to one internal server, but SSH requests to another? It's not hard to modify Listing 16-1 to accomplish that, but that support isn't included by default.

You've also probably noticed that there wasn't much detail into how the kernel netfilter framework and the iptables command work. Unfortunately, that's because this isn't a book about firewalls. It'd be great to provide more detail, but entire books have been written on this subject. Additionally, even once you understand what the netfilter and iptables code is doing, constructing good firewall rules is still a bit of an art.

In other words, if you want or need more detail, you're going to have to consult other references focused on those topics. Ziegler's book, Linux Firewalls, Second edition (referenced in the bibliography at the end of this chapter), is an excellent place to start, as is the Linux iptables HOWTO (also referenced in the bibliography). The best way to master the nuances of firewall rules, however, is to ask the experts; many of them can be reached at the Bugtraq mailing list (again, referenced in the bibliography). This book focuses on describing how to turn the overall Linux system into a firewall, rather than the nuances of the firewall rules. If you just want to create an installation of this material, you should be fine, but if you choose to modify it, it's imperative to make sure you understand it thoroughly first!

Supporting Internal Machines

Now that your firewall is up and running, you'll want to start connecting other computers to your newly protected internal network. This section will discuss how to set up two important aspects: a DNS nameserver and a DHCP server.

If you have a broadband connection such as a cable modem or DSL, your ISP provides various services to your computers, perhaps most importantly DHCP and DNS. The Dynamic Host Configuration Protocol (DHCP) is used to assign IP addresses to computers on a network, and many broadband ISPs use this to configure users' machines. (However, there are other possibilities, such as the Point-to-Point Protocol over Ethernet, or PPPoE and simply using static assigned IP addresses.) The Domain Name Service, meanwhile, is the standard way to resolve human-readable host names into IP addresses.

The computers on your internal network will need access to both of these services. However, since you've just installed a firewall, you've cut off their access to these services! You'll therefore need to configure your firewall to provide these services directly.

Installing DHCP for Internal Machines

The first step toward getting your internal computers active on the network is to assign them IP addresses. You could simply assign each system its own IP address, configure them all statically, and be done, but this can sometimes be a pain; for example, adding a new computer to the network can be tedious, and you might forget which IP addresses are already assigned and which are not. If you're configuring a laptop that also has to be able to access another network (such as your office network), it can be inconvenient to reset its network settings each time. DHCP addresses these issues and makes life generally easier. Almost every client you are likely to want to connect to your network will be capable of acting as a DHCP client, so all you need to do in order to get DHCP up and running on your internal network is install a DHCP server program on your firewall.

Installing the ISC DHCP Daemon

The Internet Software Consortium (ISC) provides an implementation of a DHCP server. This software can be obtained from their web site at http://www.isc.org. If you choose to build this software from source code, you'll find it to be a very typical server daemon, similar to OpenSSH or Apache as discussed in Chapters 8 and 11. However, Red Hat Linux includes an RPM package for the ISC's DHCP daemon, and there's little reason not to use it unless you have very specific needs.

To install the server (which is called "dhcpd",) simply install the RPM from CD, or use Red Hat's up2date program to obtain the latest available version. The package on the Red Hat Linux installation CDs is dhcp-2.0pl5-8.i386.rpm.

The package will also install a SysV init scripts service for the DHCP daemon, named dhcpd. Thus, to start or stop the DHCP server once you have it installed, just use the service command; use service dhcpd start and service dhcpd stop to start and stop it, respectively.

Note

The ISC DHCP Server program binary is called "dhcpd", but Red Hat's package of it is named "dhcp".

Configuring the DHCP Daemon

After you've installed the ISC's DHCP server, you'll need to configure it. The configuration file for dhcpd is /etc/dhcpd.conf. This file could become quite complicated for large networks, but for this example it remains simple; Listing 16-3 is a sample /etc/dhcpd.conf file. The contents of this file are discussed next, but only as they pertain to high-level configuration details; for complete information on the syntax of this file, you should consult the manual page for dhcpcd.conf.

Listing 16-3: A dhcpd Configuration File

 option domain-name-servers 192.168.0.1; option routers 192.168.0.1; # option domain-name "tacals.net"; # host wap.tacals.net { #    hardware ethernet 00:00:00:00:00:02; #    fixed-address 192.168.0.2; #    option host-name "wap"; # } host server {       hardware ethernet 00:00:00:00:00:03;       fixed-address 192.168.0.3;       option host-name "server"; } shared-network INTERNAL {     default-lease-time 3600;     max-lease-time 3600;     subnet 192.168.0.0 netmask 255.255.255.0 {          range 192.168.0.4 192.168.0.20;     } }

The format of /etc/dhcpd.conf is fairly straightforward. In a nutshell, you can set a number of parameters and options, and you can bind them to various scopes. For example, you can set options for specific host on the network, you can create groups of hosts and set options for them collectively (while setting different options for different hosts), or you can set global options that affect all hosts. (Compare this to the hierarchical configuration format of the Apache HTTP server configuration, as discussed in Chapter 11; though the syntax of /etc/dhcpd.conf is very different, the notion is similar.)

Several different scopes are present in Listing 16-3. The first three lines are in the global scope, since they affect all hosts. The next block, enclosed in braces ({}), defines a host, and sets options specific to that host. The last block defines a subnet and sets options for how DHCP leases are assigned to hosts.

Understanding DHCP Leases

When a DHCP server assigns an IP address, it assigns it as a lease, meaning that the client may only use that address for a certain amount of time. When that time is elapsed, the lease is said to be expired, and the client host must rerequest an IP address. Frequently the client will be assigned the same IP address it had last time, which just renews the lease, but this is not guaranteed to be the case.

The global options being specified by the first two lines are setting the values of several useful options that the DHCP server sends along to clients. As you probably know, simply getting an IP address is not enough for a computer to join a network; the computer also needs routing information such as the IP address of a gateway router computer that connects it to the rest of the network and the Internet. It also needs the IP address of a DNS server, so that it can perform lookups of the IP addresses of network and Internet hosts.

In this example, both the router and the DNS server are set to be the IP address of the firewall computer—192.168.0.1. (The next section discusses configuring the firewall to also function as a DNS forwarder.) These lines are used to set up routing information on the clients; you should be able to connect any client computer (such as a laptop or desktop system) configured to use DHCP, and this information will be enough for the machine to become active on the network.

The third line sets another global parameter, which is the domain name of the local network. This line is commented out (by prepending the line with the "#" character in the manner of many Unix configuration files), because it's important not to just choose a fictional domain name out of thin air and expect it to work.

If you have your own domain name and your DNS servers are configured correctly, then you can enable this line; however, in the typical SOHO network targeted by this example, you probably don't have such a setup. So, you should leave this line commented out. The down side of this, though, is that you must refer to your internal machines by their numeric IP addresses, which can be inconvenient. It is possible to configure the ISC's DHCP server to function with the bind program discussed in the next section, but this is a more complicated situation and is not relevant to the goal of this chapter's example. If you're interested, you should consult the ISC's documentation on their web site at http://www.isc.org.

The next few lines are a "host" block, and contain options that are set only for a specific host. This block is actually quite simple: It just assigns a specific, fixed IP address to a particular computer on the network. It does this via the "hardware ethernet" option line. This line causes DHCP to look for the particular Ethernet Media Access Control (MAC) address to see if it matches the address listed. If it does, it assigns the fixed IP address listed, and instructs the client to adopt the indicated hostname. The key to this is the MAC address: Since no two Ethernet cards have the same MAC address, the server can use the address to uniquely identify a host; it then simply assigns the same IP address to that host each time it requests an IP address.

From the client machine's perspective, this appears to be a normal DHCP transaction, and it has no idea that it is effectively using a static IP address. However, this is useful for the firewall rules. The firewall configuration script discussed earlier in this chapter includes commands that configure Destination NAT rules to redirect certain types of traffic (such as SSH and web traffic) to some other machine on the internal network. However, the network uses DHCP, so IP addresses are subject to change, which obviously renders the DNAT firewall rules useless when the server's IP address changes. By entering the Ethernet MAC address of your server computer in this host rule, you can ensure that it always receives the same IP address, keeping the firewall rules consistent with the topology of the internal network. In this example, the server is designated to have the IP address 192.168.0.3; however, you should be sure to enter your own server's MAC address in the "hardware ethernet" line.

Listing 16-3 contains a similar host block that has been commented out. This block does the same thing as the one just discussed; however, it uses the IP address of 192.168.0.2, and assigns the hostname "wap". This refers to a Wireless Access Point, which is a device for connection computers using the 802.11b wireless Ethernet standard to your primary, wired Ethernet. Some such WAPs can be configured over the network (typically via the Simple Network Management Protocol, or SNMP). If your network has such a WAP, you may wish to uncomment these lines and set the Ethernet MAC address accordingly, so that your WAP, like your server computer, always has the same IP address.

The final block sets options for a shared internal network, named "INTERNAL". This is where you set the parameters to be used for the rest of the computers that join your network. The lines "default-lease-time" and "max-lease-time" are both set to 3600 seconds, indicating that the leases assigned by the DHCP server always be 1 hour in duration. (The units of these lines are seconds; 3600 seconds is 1 hour.) After this time has elapsed, the DHCP clients will have to send a new request to the DHCP server to renew their leases. This is how the server detects clients that are no longer on the network: It requires them to check in periodically.

The "shared-network" block also contains a subblock that configures actual network settings for the network. The first line of this subblock indicates that the network in question is the 192.168.0.0 network with the usual netmask for such networks (255.255.255.0). The addresses included this network start at 192.168.0.1 and run to 192.168.0.254. (192.168.0.255 will be the broadcast address to which all computers on the network will respond.) However, the "subnet" block further restricts the DHCP server so that it will only physically assign IP addresses up to 192.168.0.20; in addition, it will only start assigning IP addresses at 192.168.0.4. (Remember that 192.168.0.1 is the firewall, 192.168.0.3 is your server, and 192.168.0.2 might be used by a WAP.) There's no real reason for the upper limit of 192.168.0.20; it doesn't add security because hostile clients that get access to your network can simply start using a static IP address, which the DHCP server can't do anything about.

Once you install Listing 16-3 as /etc/dhcpd.conf, you will have to start the server via the command service dhcpd start. Once it starts successfully, other devices on your network will be able to obtain IP addresses, so you can now start up your server computer, power up that WAP if you have one, and boot up your desktop system. These devices will now be able to access the network; however, they will only be able to do so by using numeric IP addresses, since your firewall has cut off access to the DNS servers they would normally use to look up humanreadable host names. The next section discusses how to configure a DNS forwarder to rectify this limitation.

Installing a Local Nameserver

A DNS server (also know as a nameserver) is simply a software program that runs as a daemon, and converts human-readable hostnames into IP addresses. Since the firewall rules from the previous section cut off access to your ISP's nameserver, you'll have to install one of your own on the firewall, to provide DNS services for your internal network.

The most commonly used Unix program for this is the bind program, which, like the DHCP server discussed in the previous section, is written by the Internet Software Consortium (ISC). (The name "bind" stands for "Berkeley Internet Name Domain.") The bind program can operate in a number of different ways: It can function as a full-fledged domain server to manage your own domain name zone, or it can merely act as a forwarder or relay to another server. The first case is a very substantial task, but fortunately the second case is much simpler and is all you need for the firewall you're building.

Configuring bind as a forwarder is pretty straightforward: You simply need to install the software, and then create its configuration file (which is /etc/named.conf) correctly.

Installing the bind Nameserver

As it happens, Red Hat Linux includes an RPM package for bind with the distribution. The package is bind-9.1.3-4.i386.rpm (for systems with Intel processors—see Table 4-1 in Chapter 4 if you use another architecture). You can either install this package from the CD media, or use the up2date program to get the latest copy from Red Hat.

You can also choose to download the source code for bind from the ISC (at http://www.isc.org) and install it yourself. In this case, the installation would be roughly similar to that of OpenSSH, as discussed in Chapter 8. However, here the package provided by Red Hat should work fine.

Configuring bind

The bind nameserver needs to be configured as a forwarder. A DNS forwarder is bind's term for a second DNS server to which bind defers. In this case, you're not going to be using bind to run your own domain, but rather to provide DNS services to your internal computers. To accomplish this, all you really need is for your local installation of bind to forward all queries submitted to it to the official DNS servers you might otherwise use.

There are three options that need to be set in /etc/named.conf to configure bind as a DNS forwarder. One instructs bind to function solely as a forwarder, one lists the IP addresses of the other DNS servers to which bind is to forward queries, and the third restricts the clients that bind will serve. Listing 16-4 is a complete /etc/named.conf that configures bind as a DNS forwarder.

Listing 16-4: A bind Configuration File

 options {         directory "/var/named";         forward only;         listen-on { 127.0.0.1; 192.168/16; };         forwarders { 1.2.3.4; 5.6.7.8; }; }; include "/etc/rndc.key";

Listing 16-4 is quite simple. It consists of an "options" block that sets the three relevant properties, and also contains two other lines that specify installation options. First I'll discuss the installation-specific options to get them out of the way.

The first line in the "options" block specifies a directory where bind is to look when searching for additional configuration files. (This directory, however, should actually be empty since you are using bind merely as a forwarder.) The last line in the file, meanwhile, includes a separate file that contains a secret key used to authenticate clients and other servers; again, though, this configuration will not make use of that key.

The remaining three lines set the three properties mentioned earlier. The "forward only;" line instructs bind to behave only as a forwarder (that is, never to service queries itself but rather forward them to another server.) The "listen-on" line instructs bind to only respond to queries from trusted machines—specifically, the local machine 127.0.0.1, and machines on the 192.168.x.x subnet. (If you're using a different IP address range on your network, you'll have to enter the correct information here; see the manual page on named.conf for more information.)

The last line in the "options" block sets the IP addresses of DNS servers to which queries should be relayed. The IP addresses you enter in the "forwarders" block must be real, functional DNS servers. Typically, these will be the DNS servers provided by your ISP, though they can technically point anywhere. If you don't already know the IP addresses of your ISP's DNS servers, you'll have to contact them to find out. You should not, of course, use the example values in Listing 16-4 of "1.2.3.4" and "5.6.7.8".

Once you've installed Listing 16-4 as /etc/named.conf, you must start the bind service running via the command service named start. (If it's already running, you may need to use service named restart.) Once this succeeds, your DNS forwarder is running, and the internal machines will have access to DNS services!

< Free Open Study >