:: Configuring Linux as a Firewall

• Making installation choices
• Introducing iptables
• Using iptables commands
• Simplifying things with firewall GUIs
• Adding proxy functionality

As Linux gains increasing acceptance in corporate datacenters and other places, more and more people are discovering something that Linux enthusiasts have known for a long time: Linux has built-in firewall features that allow an administrator to build a firewall. Recent versions of Linux generally ship with at least basic firewall capabilities, and several Linux versions include even more advanced features. Because Linux is open source software, and because it has only minimal hardware requirements, you can build a Linux-based firewall relatively inexpensively. Be forewarned, though — doing so does require some knowledge of Linux and how it fits into the networking scheme of things.

Making Installation Choices

To use the firewall built into Linux, you should make sure that the operating system you install includes iptables functionality. Iptables is the most popular Linux firewall, and this chapter covers it in detail. Fortunately, most Linux distributions do this by default, so you probably don’t have to worry about this.

Before you install Linux, make sure that all your network cards and any modem that you may use are installed in your computer. Generally, it’s much easier to have all your hardware in place before installing your Linux software than it is to install Linux first and then try to get Linux to recognize all the hardware stuff after the fact.

Red Hat Linux, in its ongoing effort to be top dog in the Linux field, goes one step further along the customer satisfaction road by giving you a choice of configuring the firewall during installation. One of the screens that you see during the installation procedure is shown in Figure 1. The choices you see on this screen are good starting points, whether you are just setting up a personal computer, or whether you are planning to configure a corporate firewall. Of course, when you are indeed configuring a dedicated firewall, you will have to perform some additional configuration after the installation is complete.

If you are using another distribution, just skip this section and go on to the section on iptables. The process of configuring the firewall after installation is virtually identical in all Linux distributions. Let’s look at each of the available choices:

_ Off: This option does just what its name implies: It configures Linux to allow all network traffic to enter or leave the computer. Obviously, this is not an appropriate setting for a firewall unless you want to do all your configuring at some later point. (No, deciding just to skip this whole firewall business is not an option. Need to reread Chapter 1?)

_ Medium: This is an appropriate choice if you want to use Linux as a personal firewall or if you are installing a server that performs limited functions, such as a Web server. When you select this option, Linux configures iptables to allow certain types of traffic into your computer. You can specify which types of traffic are allowed; for example, you can disable HTTP traffic or allow SMTP traffic. One of the limitations of the Red Hat setup program is that it can only perform very simple firewall configuration tasks for you. Keep in mind that you can add or remove rules later, but if you already know which traffic you want to allow and which traffic you want to block, you can easily configure this during setup.

_ High: When you select this option, you enable and configure the iptables firewall to block all traffic. This is the configuration that you should choose when you install a dedicated firewall. Best practices dictate that you configure your firewall to drop all network traffic unless you specifically allow it. Choosing this option gives you this starting configuration; you get to do all the other configuration steps after the operating system installation is complete.

Figure 1. Red Hat Linux firewall installation.

Introducing iptables

Although we already mentioned iptables a few times in this chapter, this is the section where we actually get down to brass tacks about the whole iptables business. Iptables is the command that you use to tell the Linux kernel — the core part of the operating system — how to treat network traffic. For example, you can use the iptables command to drop IP packets, forward them, or perform network address translation (NAT).

Before you can configure rules with the iptables command, you have to understand a few concepts and Linux-specific terms:

_ Tables: Locations where a Linux firewall stores and maintains sets of rules. The main table is the filter table, where you define most rules that apply to incoming and outgoing traffic. This is also the default table that commands apply to when you don’t specify a specific table. The nat table contains rules that define how Linux performs NAT. The mangle table is used for advanced packet routing, but isn’t used frequently. (Don’t worry; despite its name, this table won’t mutilate all your important data.)

_ Chains: At the core of a Linux firewall. Using a chain to lock your computer to a desk may be a good idea, but in this case, we’re talking about a different kind of chain. Linux uses this term to refer to a set of rules that Linux applies when filtering network traffic. Here are the three main chains, each of which is part of the filter table:

• Input chain: This chain applies to all traffic destined for the firewall computer. For example, if you want to enable remote administration of your firewall, you have to configure a rule for the input chain to allow whatever network traffic your remote administration tools use.

• Output chain: The output chain applies to all traffic that leaves the firewall computer. For example, if your firewall needs to contact a DNS server for name lookups, you have to configure the output chain to allow this traffic.

• Forward chain: This chain applies to all traffic that your Linux firewall handles for other computers. For example, if your firewall
allows network traffic from client computers to the Internet, you have to configure the forward chain to allow this traffic.

The nat table and mangle table also contain separate chains, but most firewall rules that you define are contained in the chains just described.

_ SNAT, DNAT, and Masquerading: These terms refer to different forms of network address translation. SNAT changes a packet’s source address before sending it on; this is most often used to hide the real IP address of a client computer in outgoing traffic. DNAT changes the destination address of packets, which is commonly used for transparent proxies — proxy servers that handle network traffic for clients without the client knowing. Masquerading is a specialized form of NAT because it doesn’t require a static IP address. Masquerading also hides internal clients from the outside world and is used when your external IP address changes dynamically — for example, when you use a dialup connection to connect to the Internet. Just like dressing up in a costume changes someone’s appearance, masquerading changes a packet’s appearance to the outside world.

Using iptables Commands

Linux includes a number of different iptables commands. All of them start with iptables and add a number of command-line options. The best way to start using the iptables commands is to look at the basic syntax for simple firewall rules.
To instruct Linux to add a rule to one of the chains or to remove one of its rules, the syntax is as follows (optional parameters are shown in square brackets):

iptables [-t table] CMD [chain] [filter_match] [target]

Iptables commands must specify the table where the command will be applied, the command itself, the chain to which the command will belong, an expression that defines what type of traffic the filter will apply to, and what Linux should do with the packet. For example, to add a simple rule to the input chain of the filter table that would drop all ICMP traffic, your code
would look something like this:

iptables -t filter -A INPUT –p icmp DROP

As you can see, this command starts with the required iptables. It then specifies which table and chain it refers to, goes on to include a match expression, and then finally defines a target. This particular command tells Linux: When the Filter table’s Input chain receives a packet that uses the ICMP protocol, send the packet to the Drop target. In other words: Dump all ICMP traffic.

iptables commands

Before you can build your own rules, you have to familiarize yourself with the basic commands, filter match expressions, and targets. Table 1 describes the most commonly used iptables commands.

Table 1. Common iptables Commands

iptables targets

Before using iptables commands, you also must understand the concept of a target. A target is the destination where the chain will send a packet, but you can also think of a target as an action that Linux will perform with the packet. Table 14-2 lists the most common targets.

Table 2. Common iptables Targets

Order matters

The order in which the rules are processed matters with iptables commands. Because of this, iptables has the convenient -A command that appends commands to the end of the processing chain and the equally convenient -I command that adds commands to the beginning of the processing chain or a user-specified location. Of course, an even better strategy is to plan for the order of processing of commands before you define your rules.

Unlike some other firewalls, iptables applies each filter command and stops processing commands once a match takes place. For example, if you create a rule that allows all network traffic and then you create other rules that deny specific types of traffic, you should make sure that the Drop All rule is at the end of the chain. That way, Linux stops processing the rules as soon as it recognizes that the packet should be allowed. The Drop All rule won’t be processed. If you reversed the order and applied the Drop All rule first, Linux would examine the packet and drop it when the Drop All rule is encountered. The rule that allows the packet would never be processed.

It’s a good practice in designing firewalls to place the rules that allow network traffic first and then apply rules that deny traffic later. To create more involved rules, you can create additional user-defined chains, which are chains that perform further processing, or add conditional statements, or create rules that contain more than one condition that the packet must match in order for a rule to apply.

Finally, rule processing doesn’t end when a packet is logged. You can make a decision to allow or drop a packet even after a rule has been applied to log the packet.

iptables options and conditions

Options are the last component of iptables commands that you need to have under your belt in order to build firewall rules. Options determine how a command is processed. Most often, these options are conditions that are checked before a command is applied. These conditional expressions are evaluated by Linux to decide whether a command should be applied or ignored for a given packet. Table 3 lists the most commonly used options, including conditional expressions.

Table 3 Common iptables Options

Putting it all together: Building a simple Linux firewall

Now that you have all the building blocks at hand, you’re ready to build a simple Linux firewall. How simple? The firewall that we have in mind is designed to allow all outgoing traffic and block all incoming traffic, with two exceptions: It allows incoming TCP traffic that is part of an established connection, and it allows incoming UDP traffic on port 53. The reason why we allow this UDP traffic is because we assume that our firewall has to make DNS lookup requests and also has to accept replies to these queries.

Although you can type each command in the following list manually each time you start Linux, it makes much more sense to add the commands to a script so you don’t have to type each command separately. Using a script also makes it less likely that you make typing mistakes. After you’ve created and tested the script, go ahead and have the script run each time you start your computer. If you need more information on how to create scripts, we recommend the book Linux For Dummies, by Dee-Ann LeBlanc, Melanie Hoag, and Evan Bloomquist, published by Wiley Publishing, Inc.

# Lines starting with this character are comments
# and are not executed.
# When you end a line with a backslash, \Linux treats the next line as a continuation of \the current line.
# Let’s start by clearing all chains that may have
# something in them.
iptables –F
# Just in case there are user-defined chains,
# let’s delete those too.
iptables –X
# Next, let’s allow all packets that arrive on the
# eth0 interface. If your internal interface has a different
# name, you have to use that name instead.
iptables –A INPUT –i eth0 –j ACCEPT
# Most likely your computer has to perform DNS lookups
# and will need to receive replies to these lookup requests.
# The following rule allows this. Replace xxx.xxx.xxx.xxx
# with your firewall’s external IP address.
iptables –A INPUT –p udp –s xxx.xxx.xxx.xxx –sport 53 \
–j ACCEPT
# Before you drop packets that do not meet the above
# criteria, let’s log those packets.
iptables –A INPUT –I eth0 –j LOG
# Finally you drop all packets that have not been
# allowed above.
iptables –A INPUT –I eth0 –DROP

After you have entered all the rules for the input chain, you can list them by using the iptables –v –L INPUT command. By using the -v option with this command, you get more verbose — another word for more detailed — information.

Masquerading and NAT

Linux provides two versions of NAT. Masquerading is designed for dynamic IP addresses; for example, an IP address assigned by an ISP to dialup connection. If you have a static external IP address, then you normally use a combination of SNAT and DNAT.

Enabling Masquerading

In most cases, you enable Masquerading — NAT for dynamic addresses — for all outgoing traffic from your network. This is a form of source NAT, which means that your firewall changes the source address of packets. To enable Masquerading, you need to enter the following iptables command.

iptables –t nat –A POSTROUTING –o ppp0 –j MASQUERADE

Notice that you are using iptables to modify the POSTROUTING chain of the NAT table. This means that the command is applied after the packet’s address is modified — after Linux has applied routing rules — but before it leaves the computer. The command also assumes that your outgoing interface is called ppp0 and your internal interface is called eth1. If either has a different name, you need to change the command accordingly.

You can find out all the gory details about the iptables command, as well as all other commands by reading the man page — short for manual — for it. To do this, simply type man iptables in a Linux command shell.

Masquerading means that NAT will be applied to all traffic that is forwarded, or routed. However, you still need to specify which traffic you allow to be forwarded. The following commands allow all TCP traffic from your internal network to be forwarded to the Internet, as well as all TCP traffic belonging to an established session to be returned. The example assumes that your internal interface is called eth1 and your external interface is called ppp0.

iptables -A FORWARD –i eth1 -o ppp0 -m state \
--state NEW,ESTABLISHED –j ACCEPT
iptables -A FORWARD –i ppp0-o eth1 -m state \
--state ESTABLISHED –j ACCEPT

If you have other network traffic that you want to allow from your internal network, then you need to configure additional rules for this traffic.

Using SNAT

Configuring source NAT, or SNAT, is similar to configuring Masquerading. The difference is that for SNAT, your external interface must have a static IP address. The following command enables SNAT. The command also assumes that your firewall’s external interface is called eth0. If it has a different name, you need to change the command accordingly. You also need to replace xxx.xxx.xxx.xxx with the external IP address of your firewall.

iptables –t nat –A POSTROUTING –o eth0 –j \
SNAT –to-source xxx.xxx.xxx.xxx

Using DNAT

Destination NAT, or DNAT, is used to allow incoming traffic into a network that uses NAT. For example, to make a public Web server at the IP address 192.168.1.80 available to your customers, you need to use the following series of commands. The first command enables DNAT. The second command creates the required forwarding rule to allow the traffic to be processed. The commands assume that your firewall’s external interface is called eth0, and the internal interface is called eth1. If either has a different name, you need to change the command accordingly. You also need to replace xxx.xxx.xxx.xxx with the external IP address of your firewall.

iptables –t nat –A PREROUTING –i eth0 –p tcp \
–sport 1024:65635 -d xxx.xxx.xxx.xxx –dport 80 \
-j DNAT –to-destination 192.168.1.80
iptables –A FORWARD -i eth0 –o eth1 –p tcp \
–sport 1024:65635 -d 192.168.1.80 –dport 80 \
–m state --state NEW –j ACCEPT

By using SNAT or DNAT, you can apply very flexible rules to incoming traffic. You can change the port of the traffic as you perform NAT, for example, or you can configure outgoing traffic from one internal host to be sent out with one external IP address as its source and all other traffic with a different IP address. No matter which kind of NAT you use, remember that SNAT, DNAT and Masquerading only control how NAT is performed. You also need to configure corresponding FORWARD rules to allow the traffic to be sent.

Simplifying Things: Firewall GUIs

Depending on which version of Linux you are using, you may have a graphical user interface, or GUI-based utility to do much of the work for you. Generally, such utilities allow you to configure basic personal firewall functionality. This may be all you need, but even if you are configuring a fullfledged firewall for your network, it’s a good idea to do the initial setup using a GUI and then add more rules later on.

One Linux distribution that has such an interface is Red Hat Linux. With the GUI interface, you get the same configuration choices that Red Hat Linux presented during setup. You start by configuring general security settings and then you specify the particular services to which you want to grant access. To start configuring the firewall using this utility, simply run the lokkit command. You’ll see a screen like the one shown in Figure 1 Then simply follow the on-screen instructions to configure firewall functionality.

Another distribution with a GUI-based firewall setup is the SuSEfirewall2 package included with SuSE Linux 8. You start the configuration program by selecting it on the YaST2 (Yet another Setup Tool) menu. This starts a wizard, shown in Figure 14-2, that guides you through the firewall configuration.

Figure 2. SuSEfirewall2 configuration.

Adding Proxy Functionality

You can enhance your firewall functionality by adding proxy support. Adding a proxy server to your network design enhances the packet filtering and stateful inspection capabilities of your iptables firewall by allowing the firewall to inspect network traffic at the application layer. A proxy server can also perform user-based authentication of network traffic.

Applications that are aware of the proxy server can send network requests to it instead of sending packets directly to the target. Unfortunately, not all applications are capable of doing this neat trick. To support applications that can’t use a proxy server, you have to install a piece of client software that intercepts regular network requests from an application and forwards it to the proxy server. This is often referred to as transparent proxy. Proxy capabilities for Linux are available by using two different types of proxy servers, SOCKS and Squid.

Put your SOCKS on

SOCKS, short for Sockets, is a proxy server — currently in version 5 — that can process all types of network requests. After the client forwards network requests, a SOCKS server performs an Application layer inspection and then fulfills the network request. The type of processing that occurs at the SOCKS server depends on the version you are using.

SOCKS specifications are defined in several RFCs (requests for comments) and several versions of SOCKS servers are available. Even Microsoft Security and Acceleration (ISA) Server, which we cover in Chapter 16, supports this protocol. Most of these SOCKS servers are commercial products, but you can use a version that’s available for non-commercial purposes, free of charge. You can find out more about SOCKS — where to get it, how to implement it, and how to wash dirty SOCKS — at www.socks.permeo.com. Among other items, this site contains a list of frequently asked questions (FAQs) that is a good starting point for learning more about SOCKS.

Squid anyone?

A more specialized type of proxy server for the Linux platform is the free bit of software known affectionately as Squid. Squid is a caching server, which means that it can accelerate Internet access by keeping local copies of frequently accessed Web pages and other Web objects, such as graphics. Most Web browsers allow you to configure a Squid-based caching server as a proxy server. Squid servers generally only support Web requests, which include HTTP and FTP requests that are issued by a proxy-aware client, such as a Web browser. However, Squid servers can’t handle other network requests, such as connections to mail servers. Several versions of Squid servers are available, some of which are free and some of which are commercial software. You can find out more about Squid and how to implement it at www.squid-cache.org. As was the case with the SOCKS Web site, the best starting point to learn more is the FAQ section.

What about the ipchains command?
If you have configured firewall rules using older versions of Linux, you may have encountered the ipchains command. The ipchains facility was used to configure firewall capability in Linux kernels up to version 2.3. The iptables facility is the preferred method for configuring firewalls using version 2.4 of the Linux kernel, which all current versions of Linux are based on. The iptables command allows for improved control over firewall rules and adds more flexibility in configuring firewall rules.

by Brian Komar, Ronald Beekelaar, and Joern Wettern,PhD
Wiley Publishing, Inc
credit by Black Hack
e-mail : black_hack@underground.com