Netfilter

Certify and Increase Opportunity.
Be
Govt. Certified Linux Administrator

Security is increasingly important for companies and individuals alike. The Internet has provided them with a powerful tool to distribute information about themselves and obtain information from others, but it has also exposed them to dangers that they have previously been exempt from. Computer crime, information theft, and malicious damage are all potential dangers.

An unauthorized and unscrupulous person who gains access to a computer system may guess system passwords or exploit the bugs and idiosyncratic behavior of certain programs to obtain a working account on that machine. Once they are able to log in to the machine, they may have access to information that may be damaging, such as commercially sensitive information like marketing plans, new project details, or customer information databases. Damaging or modifying this type of data can cause severe setbacks to the company.

The safest way to avoid such widespread damage is to prevent unauthorized people from gaining network access to the machine. This is where firewalls come in.

IP filtering is simply a mechanism that decides which types of IP datagrams will be processed normally and which will be discarded. By discarded we mean that the datagram is deleted and completely ignored, as if it had never been received. You can apply many different sorts of criteria to determine which datagrams you wish to filter; some examples of these are:

• Protocol type: TCP, UDP, ICMP, etc.
• Socket number (for TCP/UPD)
• Datagram type: SYN/ACK, data, ICMP Echo Request, etc.
• Datagram source address: where it came from
• Datagram destination address: where it is going to

It is important to understand at this point that IP filtering is a network layer facility. This means it doesn’t understand anything about the application using the network connections, only about the connections themselves. For example, you may deny users access to your internal network on the default telnet port, but if you rely on IP filtering alone, you can’t stop them from using the telnet program with a port that you do allow to pass trhough your firewall. You can prevent this sort of problem by using proxy servers for each service that you allow across your firewall. The proxy servers understand the application they were designed to proxy and can therefore prevent abuses, such as using the telnet program to get past a firewall by using the World Wide Web port. If your firewall supports a World Wide Web proxy, their telnet connection will always be answered by the proxy and will allow only HTTP requests to pass. A large number of proxy-server programs exist. Some are free software and many others are commercial products. The Firewall-HOWTO discusses one popular set of these, but they are beyond the scope of this book.

The IP filtering ruleset is made up of many combinations of the criteria listed previously. For example, let’s imagine that you wanted to allow World Wide Web users within the Virtual Brewery network to have no access to the Internet except to use other sites’ web servers. You would configure your firewall to allow forwarding of:

• datagrams with a source address on Virtual Brewery network, a destination address of anywhere, and with a destination port of 80 (WWW)
• datagrams with a destination address of Virtual Brewery network and a source port of 80 (WWW) from a source address of anywhere

To build a Linux IP firewall, it is necessary to have a kernel built with IP firewall support and the appropriate configuration utility. In all production kernels prior to the 2.2 series, you would use the ipfwadm utility. The 2.2.x kernels marked the release of the third generation of IP firewall for Linux called IP Chains. IP chains use a program similar to ipfwadm called ipchains. Linux kernels 2.3.15 and later support the fourth generation of Linux IP firewall called netfilter. The netfilter code is the result of a large redesign of the packet handling flow in Linux. The netfilter is a multifaceted creature, providing direct backward-compatible support for both ipfwadm and ipchains as well as a new alternative command called iptables.

The ipfwadm utility – The ipfwadm (IP Firewall Administration) utility is the tool used to build the firewall rules for all kernels prior to 2.2.0. Its command syntax can be very confusing because it can do such a complicated range of things, but we’ll provide some common examples that will illustrate the most important variations of these.

The ipfwadm utility is included in most modern Linux distributions, but perhaps not by default. There may be a specific software package for it that you have to install. If your distribution does not include it, you can obtain the source package from ftp.xos.nl in the /pub/linux/ipfwadm/ directory, and compile it yourself.

The ipchains Utility – Just as for the ipfwadm utility, the ipchains utility can be somewhat baffling to use at first. It provides all of the flexibility of ipfwadm with a simplified command syntax, and additionally provides a “chaining” mechanism that allows you to manage multiple rulesets and link them together. We’ll cover rule chaining in a separate section near the end of the chapter, because for most situations it is an advanced concept.

The ipchains command appears in most Linux distributions based on the 2.2 kernels. If you want to compile it yourself, you can find the source package from its developer’s site at http://www.rustcorp.com/linux/ipchains/. Included in the source package is a wrapper script called ipfwadm-wrapper that mimics the ipfwadm command, but actually invokes the ipchains command. Migration of an existing firewall configuration is much more painless with this addition.

The iptables Utility – The syntax of the iptables utility is quite similar to that of the ipchains syntax. The changes are improvements and a result of the tool being redesigned to be extensible through shared libraries. Just as for ipchains, we’ll present iptables equivalents of the examples so you can compare and contrast its syntax with the others.

The iptables utility is included in the netfilter source package available at http://www.samba.org/netfilter/. It will also be included in any Linux distribution based on the 2.4 series kernels.

Filtering

Consider how a Unix machine, or in fact any machine capable of IP routing, processes IP datagrams. The basic steps, shown in figure below

• The IP datagram is received. (1)
• The incoming IP datagram is examined to determine if it is destined for a process on this machine.
• If the datagram is for this machine, it is processed locally. (2)
• If it is not destined for this machine, a search is made of the routing table for an appropriate route and the datagram is forwarded to the appropriate interface or dropped if no route can be found. (3)
• Datagrams from local processes are sent to the routing software for forwarding to the appropriate interface. (4)
• The outgoing IP datagram is examined to determine if there is a valid route for it to take, if not, it is dropped.
• The IP datagram is transmitted. (5)

In our diagram, the flow 1→3→5 represents our machine routing data between a host on our Ethernet network to a host reachable via our PPP link. The flows 1→2 and 4→5 represent the data input and output flows of a network program running on our local host. The flow 4→3→2 would represent data flow via a loopback connection. Naturally data flows both into and out of network devices. The question marks on the diagram represent the points where the IP layer makes routing decisions.

The Linux kernel IP firewall is capable of applying filtering at various stages in this process. That is, you can filter the IP datagrams that come in to your machine, filter those datagrams being forwarded across your machine, and filter those datagrams that are ready to be transmitted.

In ipfwadm and ipchains, an Input rule applies to flow 1 on the diagram, a Forwarding rule to flow 3, and an Output rule to flow 5. An Input rule is applied at flow 2, and an Output rule is applied at flow 4. This has important implications for how you structure your rulesets, but the general principle holds true for all versions of Linux firewalling.

This may seem unnecessarily complicated at first, but it provides flexibility that allows some very sophisticated and powerful configurations to be built.

ipchains

There are two ways you can use the ipchains utility. The first way is to make use of the ipfwadm-wrapper shell script, which is mostly a drop-in replacement for ipfwadm that drives the ipchains program in the background. If you want to do this, then read no further. Instead, reread the previous sections describing ipfwadm, and substitute ipfwadm-wrapper in its place. This will work, but there is no guarantee that the script will be maintained, and you will not be taking advantage of any of the advanced features that the IP Firewall Chains have to offer.

The second way to use ipchains is to learn its new syntax and modify any existing configurations you have to use the new syntax instead of the old. With some careful consideration, you may find you can optimize your configuration as you convert. The ipchains syntax is easier to learn than the ipfwadm, so this is a good option.

The ipfwadm manipulated three rulesets for the purpose of configuring firewalling. With IP Firewall Chains you can create arbitrary numbers of rulesets, each linked to one another, but there are three rulesets related to firewalling that are always present. The standard rulesets are direct equivalents of those used with ipfwadm, except they have names: input, forward and output.

The ipchains command syntax is straightforward. We’ll now look at the most important of those. The general syntax of most ipchains commands is:

ipchains command rule-specification options

Commands – There are a number of ways we can manipulate rules and rulesets with the ipchains command. Those relevant to IP firewalling are:

Command	Details
-A chain	Append one or more rules to the end of the nominated chain. If a hostname is supplied as either source or destination and it resolves to more than one IP address, a rule will be added for each address.
-I chain rulenum	Insert one or more rules to the start of the nominated chain. Again, if a hostname is supplied in the rule specification, a rule will be added for each of the addresses it resolves to.
-D chain	Delete one or more rules from the specified chain that matches the rule specification.
-D chain rulenum	Delete the rule residing at position rulenum in the specified chain. Rule positions start at one for the first rule in the chain.
-R chain rulenum	Replace the rule residing at position rulenum in the specific chain with the supplied rule specification.
-C chain	Check the datagram described by the rule specification against the specific chain. This command will return a message describing how the datagram was processed by the chain. This is very useful for testing your firewall configuration, and we look at it in detail a little later.
-L [chain]	List the rules of the specified chain, or for all chains if no chain is specified.
-F [chain]	Flush the rules of the specified chain, or for all chains if no chain is specified.
-Z [chain]	Zero the datagram and byte counters for all rules of the specified chain, or for all chains if no chain is specified.
-N chain	Create a new chain with the specified name. A chain of the same name must not already exist. This is how user-defined chains are created.
-X [chain]	Delete the specified user-defined chain, or all user-defined chains if no chain is specified. For this command to be successful, there must be no references to the specified chain from any other rules chain.
-P chain policy	Set the default policy of the specified chain to the specified policy. Valid firewalling policies are ACCEPT, DENY, REJECT, REDIR, or RETURN. ACCEPT, DENY, and REJECT have the same meanings as those for the tradition IP firewall implementation. REDIR specifies that the datagram should be transparently redirected to a port on the firewall host. The RETURN target causes the IP firewall code to return to the Firewall Chain that called the one containing this rule and continues starting at the rule after the calling rule.

Rule specification parameters – A number of ipchains parameters create a rule specification by determining what types of packets match. If any of these parameters is omitted from a rule specification, its default is assumed:

Parameter	Detail
-p [!]protocol	Specifies the protocol of the datagram that will match this rule. Valid protocol names are tcp, udp, icmp, or all. You may also specify a protocol number here to match other protocols. For example, you might use 4 to match the ipip encapsulation protocol. If the ! is supplied, the rule is negated and the datagram will match any protocol other than the protocol specified. If this parameter isn’t supplied, it will default to all.
-s [!]address[/mask] [!] [port]	Specifies the source address and port of the datagram that will match this rule. The address may be supplied as a hostname, a network name, or an IP address. The optional mask is the netmask to use and may be supplied either in the traditional form (e.g., /255.255.255.0) or the modern form (e.g., /24). The optional port specifies the TCP or UDP port, or the ICMP datagram type that will match. You may supply a port specification only if you’ve supplied the -p parameter with one of the tcp, udp, or icmp protocols. Ports may be specified as a range by specifying the upper and lower limits of the range with a colon as a delimiter. For example, 20:25 described all of the ports numbered from 20 up to and including 25. Again, the ! character may be used to negate the values.
-d [!]address[/mask] [!] [port]	Specifies the destination address and port of the datagram that will match this rule. The coding of this parameter is the same as that of the -s parameter.
-j target	Specifies the action to take when this rule matches. You can think of this parameter as meaning “jump to.” Valid targets are ACCEPT, DENY, REJECT, REDIR, and RETURN. We described the meanings of each of these targets earlier. However, you may also specify the name of a user-defined chain where processing will continue. If this parameter is omitted, no action is taken on matching rule datagrams at all other than to update the datagram and byte counters.
-i [!]interface-name	Specifies the interface on which the datagram was received or is to be transmitted. Again, the ! inverts the result of the match. If the interface name ends with +, then any interface that begins with the supplied string will match. For example, -i ppp+ would match any PPP network device and -i ! eth+ would match all interfaces except Ethernet devices.
[!] -f	Specifies that this rule applies to everything but the first fragment of a fragmented datagram.

Options – The following ipchains options are more general in nature. Some of them control rather esoteric features of the IP chains software:

Option	Details
-b	Causes the command to generate two rules. One rule matches the parameters supplied, and the other rule added matches the corresponding parameters in the reverse direction.
-v	Causes ipchains to be verbose in its output. It will supply more information.
-n	Causes ipchains to display IP address and ports as numbers without attempting to resolve them to their corresponding names.
-l	Enables kernel logging of matching datagrams. Any datagram that matches the rule will be logged by the kernel using its printk( ) function, which is usually handled by the sysklogd program and written to a log file. This is useful for making unusual datagrams visible.
-o[maxsize]	Causes the IP chains software to copy any datagrams matching the rule to the userspace “netlink” device. The maxsize argument limits the number of bytes from each datagram that are passed to the netlink device. This option is of most use to software developers, but may be exploited by software packages in the future.
-m markvalue	Causes matching datagrams to be marked with a value. Mark values are unsigned 32-bit numbers. In existing implementations this does nothing, but at some point in the future, it may determine how the datagram is handled by other software such as the routing code. If a markvalue begins with a + or -, the value is added or subtracted from the existing markvalue.
-t andmask xormask	Enables you to manipulate the “type of service” bits in the IP header of any datagram that matches this rule. The type of service bits are used by intelligent routers to prioritize datagrams before forwarding them. The Linux routing software is capable of this sort prioritization. The andmask and xormask represent bit masks that will be logically ANDed and ORed with the type of service bits of the datagram respectively.
-x	Causes any numbers in the ipchains output to be expanded to their exact values with no rounding.
-y	Causes the rule to match any TCP datagram with the SYN bit set and the ACK and FIN bits clear. This is used to filter TCP connection requests.

Netfilter

While developing IP Firewall Chains, Paul Russell decided that IP firewalling should be less difficult; he soon set about the task of simplifying aspects of datagram processing in the kernel firewalling code and produced a filtering framework that was both much cleaner and much more flexible. He called this new framework netfilter.

netfilter.org is home to the software of the packet filtering framework inside the Linux 2.4.x and later kernel series. Software commonly associated with netfilter.org is iptables.

Software inside this framework enables packet filtering, network address and port translation and other packet mangling. It is the re-designed and heavily improved successor of the previous Linux 2.2.x ipchains and Linux 2.0.x ipfwadm systems.

netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. A registered callback function is then called back for every packet that traverses the respective hook within the network stack.

iptables is a generic table structure for the definition of rulesets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target).

netfilter, ip_tables, connection tracking (ip_conntrack, nf_conntrack) and the NAT subsystem together build the major parts of the framework.

The iptables utility is used to configure netfilter filtering rules. Its syntax borrows heavily from the ipchains command, but differs in one very significant respect: it is extensible. What this means is that its functionality can be extended without recompiling it. It manages this trick by using shared libraries. There are standard extensions and we’ll explore some of them in a moment.

Before you can use the iptables command, you must load the netfilter kernel module that provides support for it. The easiest way to do this is to use the modprobe command as follows:

modprobe ip_tables

The iptables command is used to configure both IP filtering and Network Address Translation. To facilitate this, there are two tables of rules called filter and nat. The filter table is assumed if you do not specify the -t option to override it. Five built-in chains are also provided. The INPUT and FORWARD chains are available for the filter table, the PREROUTING and POSTROUTING chains are available for the nat table, and the OUTPUT chain is available for both tables. In this chapter we’ll discuss only the filter table.

The general syntax of most iptables commands is:

iptables command rule-specification extensions

Commands, rule specification parameters and options as listed for ipchains will be applicable.

Extensions – The iptables utility is extensible through optional shared library modules. There are some standard extensions that provide some of the features ipchains provided. To make use of an extension, you must specify its name through the -m name argument to iptables. The following list shows the -m and -p options that set up the extension’s context, and the options provided by that extension.

TCP Extensions: used with -m tcp -p tcp

• – -sport [!] [port[:port]] Specifies the port that the datagram source must be using to match this rule. Ports may be specified as a range by specifying the upper and lower limits of the range using the colon as a delimiter. For example, 20:25 described all of the ports numbered 20 up to and including 25. Again, the ! character may be used to negate the values.
• – -dport [!] [port[:port]] Specifies the port that the datagram destination must be using to match this rule. The argument is coded identically to the – -sport option.
• – -tcp-flags [!] mask comp Specifies that this rule should match when the TCP flags in the datagram match those specified by mask and comp. mask is a comma-separated list of flags that should be examined when making the test. comp is a comma-separated list of flags that must be set for the rule to match. Valid flags are: SYN, ACK, FIN, RST, URG, PSH, ALL or NONE. This is an advanced option: refer to a good description of the TCP protocol, such as RFC-793, for a description of the meaning and implication of each of these flags. The ! character negates the rule.
• [!] – -syn Specifies the rule to match only datagrams with the SYN bit set and the ACK and FIN bits cleared. Datagrams with these options are used to open TCP connections, and this option can therefore be used to manage connection requests. This option is shorthand for: – -tcp-flags SYN,RST,ACK SYN When you use the negation operator, the rule will match all datagrams that do not have both the SYN and ACK bits set.

Main Features

• stateless packet filtering (IPv4 and IPv6)
• stateful packet filtering (IPv4 and IPv6)
• all kinds of network address and port translation, e.g. NAT/NAPT (IPv4 and IPv6)
• flexible and extensible infrastructure
• multiple layers of API’s for 3rd party extensions

Application

• build internet firewalls based on stateless and stateful packet filtering
• deploy highly available stateless and stateful firewall clusters
• use NAT and masquerading for sharing internet access if you don’t have enough public IP addresses
• use NAT to implement transparent proxies
• aid the tc and iproute2 systems used to build sophisticated QoS and policy routers
• do further packet manipulation (mangling) like altering the TOS/DSCP/ECN bits of the IP header

netfilter is a framework for packet mangling. It has four parts as,

• Each protocol defines hooks (IPv4 defines 5) which are well defined points in a packet’s traversal of that protocol stack. At each points, protocol calls the netfilter framework with the packet and hook number.
• Parts of the kernel register to listen to different hooks of the protocol. Thus, when a packet is passed to netfilter framework, it checks if any hook has registered for the protocol and hook. If there is a registration, they can examine the packet, discard the packet (NF_DROP), pass(NF_ACCEPT), forget the packet (NF_STOLEN) or queue it for userspace (NF_QUEUE).
• Packet which have been queued, are collected (by the ip_queue driver) for sending to userspace; these packets are handled asynchronously.
• Add comments in the code and documentation.

Netfilter was designed with the idea to write firewalling rules as easy as write a network shema on a papersheet or speaking. By speaking, I mean sentences such as :

• “I want to authorize the access of people to my webserver through my firewall.”
• “I want to authorize the users of the LAN to connect on the web through my firewall.”
• “I accept that nice people connect to the ssh server on my firewall.”
• “I want my firewall to be able to ping all the internet.”

So a simple way to classify the packets managed by a firewall is to be split the flow in three parts :

• packets addressed to the firewall (third case)
• packets going through the firewall (first and second cases)
• packets emitted by the firewall (fourth case)

Assuming that, the simpliest way to manage authorization is to use this three categories which we name :

• INPUT
• FORWARD
• OUTPUT

When a packet comes to an interface, the kernel has first to take a routing decision. The incoming packet can be addressed to the firewall (the packet is next directed through the INPUT chain) or the packet can only be routed by the firewall (packets directed through the FORWARD chain) For the outgoing packets we’ve got two chains :

• packets coming from the firewall: the OUTPUT chain
• packets going through the firewall: the FORWARD chain

Thus, the packets flow is the following :

Logical Packet Flow

Netfilter provides flexibility for manipulating packets as they flow through the gateway. Depending upon the origin and destination of packets, they may be passed, blocked or redirected to another IP/port. The logic path for Netfilter follows:

• DNAT: Destination Network Address Translation
• Routing Decision #1: Is the packet destined for a local process or external process?
• Forward Filter: Packet Filtering
• SNAT: Source Network Address Translation
• Input Filter: Packets destined for a local process
• Output Filter: Packets sourced from a local process
• Routing Decision #2: Was the original packet in initiated via a local process?
• DNAT #2: For packets associated with a local process, apply the proper destination NAT mapping.
• Layer2 Function: Add appropriate MAC addresses to packet.

Back to Tutorial