The tools I will be using to provide firewall functions are built on the Netfilter framework that exists in the Linux kernel. Netfilter was written by Rusty Russell and has been in Linux since version 1.0 although at that stage it was a rewrite of pf from NetBSD. It allows the operating system to perform packet filtering and shaping at a kernel level, and this allows it to be under fewer restrictions than user space programs. This is especially useful for dedicated firewall and router hosts.
Netfilter is a stateful packet-filtering firewall. Two types of packet-filtering firewalls exist: stateful and stateless. A stateless packet-filtering firewall examines only the header of a packet for filtering information. It sees each packet in isolation and thus has no way to determine if a packet is part of an existing connection or an isolated malicious packet. A stateful firewall maintains information about the status of the connections passing through it. This allows the firewall to filter on the state of the connection, which offers considerably finer-grained control over your traffic.
Netfilter is controlled and configured in user space by the iptables command. In previ- ous versions of the Linux kernel, other commands provided this functionality. In kernel version 2.2 it was ipchains, and in version 2.0 it was ipfwadm. I cover the iptables command in this chapter, and I will frequently use this name to refer to the firewall technology in general. Most Linux-based distributions will have an iptables package, but they may also have their own tool for configuring the rules. Some of these may be worth looking into, but they may not be easy to use for more complicated configurations or may make dangerous configuration assumptions.
Netfilter works by referring to a set of tables. These tables contain chains, which in turn contain individual rules. Chains hold groups of like rules; for example, a group of rules govern- ing incoming traffic could be held in a chain. Rules are the basic Netfilter configuration items that contain criteria to match particular traffic and perform an action on the matched traffic.
Traffic that is currently being processed by the host is compared against these rules, and if the current packet being processed satisfies the selection criteria of a rule, then the action specified by that rule is carried out. These actions, amongst others, can be to ignore the packet, accept the packet, reject the packet, or pass the packet onto other rules for more refined processing. Let’s look at an example; say the Ethernet interface on your Web server has just received a packet from the Internet. This packet is checked against your rules and compared to their selection criteria. The selection criteria include such items as the destination IP address and the destination port. For example, you want incoming Web traffic on the HTTP port 80 to go to the IP address of your Web server. If your incoming traffic matches these criteria, then you specify and action to let it through. This is a simple example that shows how an iptables rule could work.
Each iptables rule relies on specifying a set of network parameters as selection criteria to select the packets and traffic for each rule. You can use a number of network parameters to build each iptables rule. For example, a network connection between two hosts is referred to as a socket. This is the combination of a source IP address, source port, destination IP address, and destination port. All four of these parameters must exist for the connection to be estab- lished, and iptables can use these values to filter traffic coming in and out of hosts. Addition- ally, if you look at how communication is performed on a TCP/IP-based network, you will see that three protocols are used frequently: Internet Control Message Protocol (ICMP), Transmis- sion Control Protocol (TCP), and User Datagram Protocol (UDP). The iptables firewall can easily distinguish between these different types of protocols and others.
With just these five parameters (the source and destination IP addresses, the source and destination ports and the protocol type), you can now start building some useful filtering rules. But before you start building these rules, you need to understand how iptables rules are structured and interact. And to gain this understanding, you need to understand further some initial iptables concepts such as tables, chains, and policies.
I talked about Netfilter having tables of rules that traffic can be compared against and some action taken. Netfilter has three built-in tables that can hold rules for processing traffic. The first is the filter table, which is the default table used for all rules related to the filtering of your traffic. The second is nat, which handles NAT rules, and the last is the mangle table, which covers a variety of packet alteration functions. When constructing the iptables rules in this chapter, I will focus on the filter table.
The iptables rules are broken down within the tables I have described into groupings called chains. Each table contains default chains that are built into the table. You can also create chains of your own in each table to hold additional rules. Let’s focus on the built-in chains in the filter table. These are FORWARD, INPUT, and OUTPUT. Each chain correlates to the basic paths that packets can take through a host. When the Netfilter logic encounters a packet, the first evaluation it makes is to which chain the packet is destined. If a packet is coming into the host through a net- work interface, it needs to be evaluated by the rules in the INPUT chain. If the packet is generated by this host and going out onto the network via a network interface, then it needs to be evalu- ated by the rules in the OUTPUT chain. The FORWARD chain is used for packets that have entered the host but are destined for some other host (for example, on hosts that act as routers or software- based firewalls at the perimeter of your network or between your network and the Internet).
Each chain defined in the filter table also can have a policy. A policy is the default action a chain takes on a packet to determine if a packet makes it all the way through the rules in a chain with- out matching any of them. The policies you can use for packets are DROP, REJECT, and ACCEPT. When the iptables commands is first run, it sets some default policies for built-in chains. The INPUT and OUTPUT chains will have a policy of ACCEPT, and the FORWARD chain will have a policy of DROP.
The DROP policy discards a packet without notifying the sender. The REJECT policy also dis- cards the packet, but it sends an ICMP packet to the sender to tell it the rejection has occurred. The REJECT policy means that a device will know that its packets are not getting to their destina- tion and will report the error quickly instead of waiting to be timed out, as is the case with the DROP policy. The DROP policy is contrary to TCP RFCs and can be a little harsh on network devices; specifically, they can sit waiting for a response from their dropped packet(s) for a long time. But for security purposes it is generally considered better to use the DROP policy rather than the REJECT policy, as it provides less information to the outside world.
The ACCEPT policy accepts the traffic and allows it to pass through the firewall. Naturally from a security perspective this renders your firewall ineffective if it is used as the default policy. By default iptables configures all chains with a policy of ACCEPT, but changing this to a policy of DROP for all chains is recommended. This falls in line with the basic doctrine of a default stance of denial for the firewall. You should deny all traffic by default and open the host to only the traf- fic to which you have explicitly granted access. This denial can be problematic, because setting a default policy of DROP for the INPUT and OUTPUT chains means incoming and outgoing traffic are not allowed unless you explicitly add rules to allow traffic to come into and out of the host. This will cause all services and tools that connect from your host that are not explicitly allowed to enter or leave that host to fail.
Published on Wed 08 April 2009 by Larry Epson in Linux with tag(s): linux firewall