The Present Netfilter

Linux kernel 2.4 includes a number of features and stability enhancements that make it a very robust platform to use for your firewall. One of the most noticeable improvements of this kernel version is the packet-filtering subsystem, which is now named Netfilter. The development of Netfilter has been largely funded by Watchguard Technologies. This U.S.-based company develops and markets commercial firewalls appliances based on Linux platforms, as well as security services based on their firewall platforms. Figure 9.1 shows the Netfilter Project home page, located at http://netfilter.kernelnotes.org. This Web site features

■ Information about the Netfilter Project team members and their contributions

■ iptables downloads

■ Documentation on Linux networking, packet filtering, network address translation, and the Netfilter architecture in English and several other languages

■ Netfilter FAQs

■ Information on Netfilter-related mailing lists

PART 4

Figure 9.1 The Netfilter Project home page

Figure 9.1 The Netfilter Project home page

The next section explains how to configure your Linux kernel making use of the new Netfilter support to build a network layer firewall using a Linux server.

Configuring Netfilter

In order to configure Netfilter support into the kernel, install the 2.4 kernel sources and enter Y to the CONFIG_NETFILTER question during the make config stage of the kernel configuration.

NOTE The details of kernel configuration are beyond the scope of a Linux security book. See Linux System Administration, by Vicki Stanfield and Roderick W. Smith (Sybex, 2001) to find out more about Linux kernel configuration.

By default, a Linux system is configured as a network host—not as a router. The RFCs that define Internet standards require that hosts do not forward packets. However, for a Linux system to act as a firewall, it must forward packets. In effect, for a Linux system to act as a firewall, it must first act as a router. Therefore, once the kernel is configured to support filtering, you enable IP forwarding by setting the ip_forward switch to true. This can be done by setting the variable to 1. One way to do this is to set the value of the ip_forward switch through the /proc filesystem, as in the following example:

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

Every time the system restarts, the ip_forward switch is cleared to 0 and must be explicitly reset to 1. Add the echo line to a startup script such as /etc/rc.d/rc.local to set the switch back to 1. Some Linux distributions, for example, Red Hat and Caldera, attempt to simplify this process by providing an argument to the network startup script that explicitly sets the ip_forward switch. For example, on a Red Hat 7 system, setting net.ipv4.ip_forward in the /etc/sysctl.conf file sets the ip_forward switch to a corresponding value. The following example sets ip_forward to 1:

# Enables packet forwarding net.ipv4.ip_forward = 1

On a Caldera system, the ip_forward value can be set through the /etc/sysconfig/ network file by setting a value for IPFORWARDING. If IPFORWARDING is set to true or yes, ip_forward is set to 1. If it is set to false or no, ip_forward is set to 0. The following example sets ip_forward to 1 to enable forwarding:

[ramon]$ cat /etc/sysconfig/network

PART 4

NOTE The Netfilter kernel feature provides backward compatibility by allowing you to create packet-filtering rules with both ipfwadm and ipchains.

iptables

An integral part of Rusty Russell's Netfilter package, iptables is the user space utility that you use to affect changes in the three built-in network layer kernel-filtering chains (input, output, and forward). An evolution of the ipchains utility, iptables only runs on the 2.3 and 2.4 Linux kernels, and differs from ipchains in a number of important areas:

■ The names of the built-in parameters (INPUT, OUTPUT, and FORWARD) have changed from lowercase to uppercase.

NETWORKING=yes

IPFORWARDING=yes

HOSTNAME=ibis.foobirds.org

Personally, I recommend that you use the echo command to directly set /proc/sys/net/ ipv4/ip_forward. The extensions that various vendors add to simplify setting this switch often increase the complexity of the task because the extensions are different. The echo command works the same on all Linux distributions.

■ The -i (interface descriptor) flag now designates the incoming interface and only works in the input and forward chains. If you need an interface descriptor for a rule in the forward or output chains, use the -o flag instead.

■ The ipchains' -y flag (to match IP packets with the SYN bit set) is now --syn.

■ You can now zero a single chain (with the -Z option) while listing it. (This capability did not work in ipchains.)

■ Zeroing built-in chains clears policy counters (also a bug fix).

■ REJECT and LOG chain actions are now extended targets (separate kernel modules).

■ Chain names can now be up to 31 characters.

■ The ipchains's MASQ chain is now called MASQUERADE and uses a different syntax (see the section "Network Address Translation").

Figure 9.2 shows the flow of packets as they move around the kernel and shows where the three chains fit within the overall process flow.

Figure 9.2 Linux kernel packet-filtering built-in chains

Not Local

Routing

Local

Incoming Packet

FORWARD chain

Outgoing Packet

Data Link Layer Subsystem

Outgoing Packet

INPUT chain

Input

Local process

Output

OUTPUT chain

As discussed in the "Using ipchains" section, a chain is the term used to describe a set of rules that are checked in sequence. These rules determine what is done with the packets. Consider the following example:

[ramon]$ sudo iptables -A INPUT -p tcp --dport smtp -j ACCEPT

[ramon]$ sudo iptables -A INPUT -j DROP

This simple example adds two rules to the input built-in chain. The first rule matches all packets whose transport layer protocol is TCP and whose destination TCP port is 25 (Internet mail or SMTP). If a packet matches this rule, Netfilter is to accept this packet.

The second rule is a catchall rule (sometimes called the stealth rule because it hides the server from all external systems not explicitly allowed to talk directly to it). The catchall rule instructs Netfilter to drop all other input chain traffic. The two rules in the preceding example might be used to ensure that your mail server is only accepting connections destined for the SMTP port.

NOTE One of the most important enhancements of the Netfilter framework over the legacy packet-filtering support in pre-2.4 Linux kernels is the handling of both the input and output chains. Before Netfilter, the kernel consulted the input chain for all packets received from the network driver, regardless of whether the packet would eventually be bound for another system (routing) or for the local system (local processing). The same applied to the output chain, with both forwarded and locally originated packets. This forced network administrators to apply non-intuitive rules to the input chain to account for both types of packets. With Netfilter, only packets bound for local processing are subject to the input chain, and only packets originated at the local host and bound for another host are subject to the output chain.

Both iptables and its ancestors (ipfwadm, ipchains) fulfill the same need: to reinstate a number of packet-filtering rules to the kernel every time the system reboots. Since the kernel does not have any non-volatile storage, you need to reinitialize your packet-filtering policy using the iptables scripts every time your system comes up. Since these rules do not survive system reboots, you must place your iptables commands in a script file and place the script inside /etc/rc.d/init.d directory.

Using iptables

Not all Linux distributions ship with iptables standard. Simply browse on over to your favorite RPM depot (my favorite is www.rpmfind.net) and install the latest version as follows:

This command installs a number of shared libraries in /usr/lib, a man page for iptables, and /sbin/iptables, the main executable.

You must operate with root privileges at all times when invoking the iptables command because it is actually writing the chain rules to the running kernel.

The general command-line syntax of the iptables command is as follows: iptables -[ADC] chain rule-specifications [options] iptables -[RI] chain rulenum rule-specifications [options] iptables -D chain rulenum [options]

PART 4

iptables -[LFZ] [chain] [options] iptables -[NX] chain iptables -P chain target [options] iptables -E old-chain-name new-chain-name

The command-line switches and their meanings are listed in Table 9.3.

Table 9.3 iptables Command-Line Switches

Switch	Meaning
-t table	Select the table to act upon. There are currently three of them: filter (the default), nat (network address translation, and mangle (specialized packet translation).
-A	Add a rule to a chain (append to end of the chain).
-D	Delete a rule from a chain.
-C	Create a new chain.
-R	Replace an existing rule in the chain.
-L	List all rules in the chain.
-I	Insert numbered rules in the chain.
-F	Flush all rules from the chain (empty the chain).
-Z	Zero (reset) the packet and byte counters on all chains.
-N Create a new chain.
-X	Delete the user-defined chain.
-P	Set policy for the chain to the given target.
-E	Rename the chain.

The [options] field for the iptables command can take one of values listed in Table 9.4.

Table 9.4 iptables Command-Line Options

Option	Meaning
--verbose	Display rich (verbose) output.
--numeric	Output IP addresses in numeric format (no
	DNS lookup).
--exact	Expand numbers in the output.
--line-numbers	Show line numbers when listing the rules.

iptables Rule Specifications

The real power in the iptables command is its ability to match a specific type of traffic using its rich ruleset. Every packet that is forwarded from the server arrives at the server, or is originated by the server, and is compared to the ruleset for the appropriate chain (forward, input, and output). If the packet matches the rule, the specified action (defined by the -j action option) is taken. Table 9.5 lists the parameters to be used in the rule-specifications portion of the iptables command.

Table 9.5 iptables Rule Specification Parameters j|

Parameter Meaning

PART 4

-p [!]protoco7 Protocol ID to match. This can be tcp, udp, icmp, or any numeric or alphabetic representation of a service in /etc/services.

-s [!]address[/mask] Source address to match. This can be a host name, an IP address, or a network name in network/mask format.

Specification of source port or source port range.

Table 9.5 iptables Rule Specification Parameters (continued)

Parameter	Meaning
-d [!]address[/mask]	Destination address to match. The same rules as the -s parameter apply here.
--dport [port:[port]]	Specification of destination port or destination port range.
-i [!]interface	Interface through which the packet was received, such as eth0, ppp0, etc.
-o [!]interface	Interface through which the packet is to be sent, such as eth0, ppp0, etc.
[!] -f	The packet is a second or subsequent fragment of a larger fragmented packet.

Note that for each of the parameters listed in Table 9.5, a leading exclamation mark [! ] instructs iptables to look for packets that do not meet that criterion. The rule specification parameters for iptables are very similar to the parameters available to ipchains, and they include options to match the protocol ID of the incoming packet (-p), the source and destination address (-s and -d) as well as the source and destination port number (-sport and -dport).

In addition to these basic parameters, you can specify extended matching parameters for packets of certain types (e.g., tcp, udp, and icmp), by using protocol-specific rules. For example, the following iptables line will match and accept all ICMP packets that carry the echo-request type (the type of packets used by the ping application).

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

The converse of the previous command is iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT

where you allow the local system to reply to the echo-request with an echo-reply, so that your system responds to ping requests properly.

Table 9.6 lists the protocol-specific parameters corresponding to the TCP, UDP, and ICMP traffic types included in iptables.

Table 9.6 iptables Protocol-Specific Packet-Matching Parameters

Parameter

Meaning protocol type

Matches packets with a given source port, or from a given port: port range.

Matches packets with a given destination port, or from a given port: port range.

tcp, udp

Matches packets with an equal source and destination port.

Matches packets with TCP flags as specified. Flags are SYN, ACK, FIN, RST, URG, PSH, ALL, and NONE.

Matches TCP packets with the SYN bit set and the ACK and FIN bits cleared.

Matches if the packet has the TCP option set.

Matches if the packet has the give ICMP type.

icmp

PART 4

In addition, iptables allows you to load so-called extended packet-matching modules. These are similar to external plug-ins that can be added to the basic iptables package to dynamically extend its ability to match packets. In order to extend the syntax of an iptables command with one of these modules, simply use the -m module option.

The following extended packet-matching modules are included in the standard iptables distribution:

■ owner: The owner module is used to match packets on the characteristics of the local packet creator. As such, it only applies to the output chain.

■ state: The state module allows access to the connection-tracking state for this packet.

■ tos: The tos module matches the eight bits of the type-of-service field in the IP header.

■ limit: The limit module regulates the rate at which the rule should match incoming packets. It is most often used in order to reduce the rate at which packets are accepted into an interface to avoid denial-of-service attacks.

Table 9.7 lists the parameters that are available for building rules when preceded by the -m module switch. The leftmost column includes the module to which the parameter applies.

Table 9.7 iptables Extended Packet-Matching Parameters

Parameter Meaning Extended Module

--uid-owner userid Matches if the packet was created by a process with the given user ID.

--gid-owner	groupid	Matches if the packet was created by a process with the given group ID.	-m	owner
--pid-owner	processid	Matches if the packet was created by a process with the given process ID.
--sid-owner	sessionid	Matches if the packet was created by a process with the given session group.
--state state		Matches one of the following states: INVALID, ESTABLISHED, NEW, or RELATED.	-m	state
--tos tos		Matches the eight-bit type-of-service (TOS) field in the standard IPv4 packet.	-m	tos

Table 9.7 iptables Extended Packet-Matching Parameters (continued)

Parameter Meaning Extended Module

--limit rate Maximum average packet rate. Used to restrict a certain kind of packets to a maximum frequency. The rate must have one of the following suffixes: / second,/minute,/hour, or -m limit /day. Default is 5/hour.

--limit-burst number Maximum initial number of packets. Used to restrict the maximum burst of packets of a given type. Default is 5.

For example, let's say that your firewall is protecting a private server whose primary mission is to serve Web content but also runs an FTP server for a few of your customers. You would like to allow unrestricted HTTP traffic to this server:

iptables -A FORWARD -p tcp -dport 80 -j ACCEPT

but you want to limit FTP connections to one every 30 seconds (or two per minute):

iptables -A FORWARD -p tcp --syn -dport 21 -m limit --limit 2/minute$ -j ACCEPT

iptables -A FORWARD -p tcp -dport 21 -j ACCEPT

Note that in addition to the -m limit extended match, you're also matching - -syn type connections in the first command in the preceding example. This ensures that you only rate-limit connection requests. The rest of FTP traffic is accepted by the second command.

As you can see, the iptables command has a very complex syntax. The next section presents some examples about how you can use iptables, describes a number of real-world network architecture scenarios, and offers suggested iptables commands that would be used in each case.

PART 4

Continue reading here: Sample Firewall Scenarios

Was this article helpful?

0 0