The netfilter/iptables firewall software for Linux includes advanced firewall features such as NAT, rate limiting, connection tracking, and packet mangling. These features, along with a few more we’ll talk about, make iptables the new top dog in Linux-based firewalls. In a recent article, we looked at the basics of getting an iptables firewall up and running. This time around, we’re going to dig deeper into the many advanced features provided by this excellent packet-filtering software.
As you monitor your system logs and inbound traffic, you may notice a particular IP address attempting to access your system without permission. Or you may see your Apache logs being flooded with Nimda requests from an entire range of addresses. This is where iptables' ability to DENY or REJECT packets comes in handy. Here are a couple of examples that would drop these packets before they could do further harm:
iptables –A INPUT –p TCP –s 10.1.2.3 --dport 6000:6009 –j DROP
iptables –A INPUT –p TCP –s 10.1.2.0/24 --dport 80 –j DROP
In the first example, we are denying inbound attempts to access X-Windows (we'll pretend that's what you notice a hacker trying to access) from a specific IP address of 10.1.2.3. Notice that a range of ports can be used here, and unlike with ipchains, they need not be sequential. In the second example, we are blocking the 10.1.2.0 class C subnet (/24) from accessing HTTP on port 80. In both cases, we are using the DROP rule. REJECT performs the same action while additionally sending an error packet in response.
Network address translation
Network address translation (NAT) is handled in various ways depending on your needs. The first approach is Source NAT (SNAT), which is what's done when you allow internal users to access the Internet via your firewall. SNAT refers to the modification of the packet’s source address to make it seem as if the external-facing machine is making the request. The initial request is remembered, and the reply is transferred back to the internal computer.
Redirection, on the other hand, is done with Destination NAT (DNAT). This is where the destination address of the packet is modified. You may also specify a port or range of ports to redirect. An example of using this feature would be in transparent proxying. You could redirect outbound HTTP connections to a proxy server, removing the need to configure a proxy server on every machine.
A third option is MASQUERADE. This target should be used only when you have a dynamically assigned IP address on your external interface. Dial-up PPP connections are the most common example of this. MASQUERADE is similar to SNAT, except that previous connections are flushed when the interface goes down. This option ensures that there are no lingering relationships built on previous IP addresses.
Here are some examples of configuring NAT:
iptables -t NAT -A POSTROUTING -o eth0 -j SNAT --to-source 10.0.0.1
iptables -A FORWARD -i eth1 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
This first example sets up which packets we're going to NAT (ones outbound on the eth0 interface), what we are going to do with them (SNAT), and what IP address to change the source address to (10.0.0.1). The second example states which packets we're going to forward. In this instance, we are forwarding all packets sourced on the internal interface. The third example implements the stateful firewall and allows connection tracking. This is an excellent feature that allows reply packets to be matched back to the originating machine.
State options are ESTABLISHED (part of an existing connection), RELATED (related to an existing connection), NEW (packet is attempting to create a connection), and INVALID (packet does not match an existing connection). This provides enhanced security, as the firewall just opens arbitrary ports as needed on a packet-by-packet basis.
Rate limiting and logging
Iptables provides an option for limiting the rate of packets handled on an interface over a given period of time. This should immediately bring to mind denial of service (DoS) attacks. The option is also helpful when used with logging to limit the size of your files. Let’s look at a couple of examples:
iptables -A INPUT –p TCP --syn -m limit --limit 5/second -j ACCEPT
iptables -A INPUT -s 192.168.1.25 -m limit --limit 1/minute –j LOG
In the first example, we see a way to perform SYN flood protection. This particular option matches packets with the SYN bit set and the ACK and FIN bits cleared. What this means is it affects only packets wishing to open a connection, not packets involved in previously created connections.
This is specified with the --syn command appended to the –p TCP option. We then specify that we want rate limiting with –m limit and the actual rate to accept with --limit 5/second. This offers protection from hackers attempting to DoS attack your machine with SYN flooding.
The second example limits logging from the source address of 192.168.1.25 to one per minute. This can help slim down those log files on larger servers that receive a large amount of requests. Perhaps you have a machine that polls SNMP traps every few seconds, but you really don’t need to see every single attempt. In this case, limiting the logs to just one per minute will serve to both track incoming attempts and keep file logging to a minimum.
Another interesting feature provided in iptables is prefix logging, which allows an administrator to prefix an entry in the log file with a description of up to 29 characters. This can be useful when you want to make certain entries easy to find or when you just want to make your file easier to process. This feature is also great when used with external scripts. The prefixes can act as targets to help you find the exact message you want. Here's an example:
iptables -A INPUT -s 192.168.1.45 -j LOG \
--log-prefix ' ## Internal SMTP server ## '
Other logging options are --log-level, --log-tcp-sequence, --log-tcp-options, and --log-ip-options. Consult the man page of iptables if you are in need of some advanced logging.
Packet mangling and TOS
Another handy feature provided by iptables is packet mangling, which is the modification of packets for a particular reason. One use of this feature is for Type of Service (TOS) prioritization. This means you can modify certain packets to give them higher priority. The MANGLE table has two built-in chains, PREROUTING and OUTPUT. With PREROUTING, the work is done on incoming packets before routing decisions are made. OUTPUT does the same for locally generated packets. There are five valid TOS values, which can be used with either numeric or descriptive values:
Minimize-Delay 16 (0x10)
Maximize-Throughput 8 (0x08)
Maximize-Reliability 4 (0x04)
Minimize-Cost 2 (0x02)
Normal-Service 0 (0x00)
These examples show how to use packet mangling in conjunction with TOS:
iptables -A PREROUTING -t MANGLE -p TCP --sport telnet \
-j TOS --set-tos Minimize-Delay
iptables -A PREROUTING -t MANGLE -p TCP --sport http \
-j TOS --set-tos Maximize-Throughput
In the first example, we're looking to minimize the delay given to inbound Telnet connections, making them a priority. At the same time, we want to give Web connections the best throughput available, even at the expense of other types of traffic. Notice that we're using the names of the service instead of a simple port number. This can be done with most common ports. Check /etc/services for a full list.
The netfilter/iptables system provides some of the best packet-filtering options available for Linux. Using iptables' features, you can configure your Linux firewall to be highly secure and to provide excellent logging and performance. You should now have a better idea of how to implement some of the more robust iptables capabilities, from denying simple types of packets to SNAT to packet mangling.