iptables Overview

The power and flexibility of netfilter is implemented through the iptables interface. This command-line tool is similar in syntax to its predecessor, ipchains; however, iptables uses the netfilter subsystem to enhance network connection, inspection, and processing; whereas ipchains used intricate rule sets for filtering source and destination paths, as well as connection ports for both. iptables features advanced logging, pre- and post-routing actions, network address translation, and port forwarding all in one command-line interface.

This section provides an overview of IPTables. For more detailed information about iptables, refer to the Official Red Hat Linux Reference Guide.

Using iptables

The first step in using iptables is to start the iptables service. This can be done with the command:

service iptables start

	Warning
	The IPChains and IP6Tables services must be turned off to use the IPTables service with the following commands: service ipchains off service ip6tables off

To make IPTables start by default whenever the system is booted, you must change runlevel status on the service using chkconfig.

chkconfig --level 345 ip6tables on

The syntax of iptables is separated into tiers. The main tier is the chain. A chain specifies the state at which a packet will be manipulated. For example:

iptables -P OUTPUT ACCEPT

The OUTPUT chain specifies any packets that originate from inside a LAN and travels outside (for example, to a remote website). In the example above, the rule states that all packets coming from the inside to the outside of the local network is allowed to pass through the firewall. This is usually an acceptable rule for administrators because the likelihood of dangerous packets going out into an untrusted carrier network such as the Internet is small compared to malicious packets going into the local network. The three built-in chains of iptables (that is, the chains that affect every packet which traverses a network) are INPUT, OUTPUT, and FORWARD. These chains are permanent and cannot be deleted, whereas user-defined chains can be.

Some basic rules established from the outset can aid as a foundation for building more detailed, user-defined rules. For example, you may want to allow all connections originating from the inside by default and then customize unique cases with their own rule sets. Accepting all OUTPUT by default is a sufficient foundation to build upon regarding outbound connections. It is also recommended that, by default, all incoming connections be denied by your firewall. The following rule will block all incoming connections:

iptables -P INPUT REJECT

Additionally, it is recommended that any forwarded packets — network traffic that is to be routed from the firewall to its destination node — be denied as well, to restrict internal clients from inadvertent exposure to the Internet (for example, if a LAN user accidentally turns on a service on some arbitrary port, then your network becomes vulnerable because of that machine's service). To do this, use the following rule:

iptables -P FORWARD REJECT 

After setting basic rules, you can now create new rules for your particular network and security requirements. The following sections will outline some common rules you may implement in the course of building your iptables firewall.

service iptables save

INPUT Filtering

Keeping remote attackers out of a LAN is an important aspect of network security, if not the most important. The integrity of a LAN should be protected from malicious remote users through the use of stringent firewall rules. In the following example, The LAN (which uses a private class C 192.168.1.0/24 IP range) rejects telnet access from the outside. The rule for this looks like the following:

iptables -A INPUT -p tcp --sport telnet -j REJECT

The rule rejects all outside tcp connections using the telnet protocol (typically port 23) with a connection refused error message. Rules using the --sport or --dport options can use either port numbers or common service names. So, using both --sport telnet and --sport 23 are acceptable.

Note

There is a distinction between the REJECT and DROP target actions. The REJECT target denies access and returns a connection refused error to users who attempt to telnet users. The DROP, as the name implies, simply drops the packet without any warning to telnet users. Administrators can use their own discretion when using these targets; however, to avoid user confusion and attempts to continue connecting, the REJECT target is recommended.

There may be times when certain users require remote access to the LAN from the road or from a field office. Secure services, such as SSH and CIPE, can be used for encrypted remote connection to LAN services. For administrators with PPP-based resources (such as modem banks or bulk ISP accounts), dialup access can be used to circumvent firewall barriers securely, as modem connections are typically behind a firewall/gateway because they are direct connections. However, for remote users with broadband connections, special cases can be made. You can set iptables INPUT to accept connections from remote SSH and CIPE clients. For example, to allow remote SSH access to the LAN, the following may be used:

iptables -A INPUT -p tcp --sport 22 -j ACCEPT

CIPE connection requests from the outside can be accepted with the following command:

iptables -A INPUT -p udp -i cipcb0  -j ACCEPT

Since CIPE uses its own virtual device which transmits datagram (UDP) packets, the rule allows the cipcb0 interface for incoming connections, instead of source or destination ports (though they can be used in place of device options). For information about using CIPE, refer to Chapter 6.

There are other services for which you may need to define INPUT rules. Refer to the Official Red Hat Linux Reference Guide for comprehensive information on iptables and its various options.

OUTPUT Filtering

There may be instances when an administrator must block certain users on the internal network from making outbound connections. Perhaps the administrator intends to curtail malicious trojans from contacting their intended hosts or wants to keep an employee from misusing network resources for inappropriate or illicit reasons. In these cases, specialized rules can be established using OUTPUT action in iptables. The OUTPUT action places restrictions on outbound data.

Suppose an administrator notices heavy amounts of network traffic on port 6699 (a commonly used port for peer-to-peer file sharing services). To stop the traffic and conserve bandwidth for legitimate business purposes, the administrator can block LAN users from communicating on this port. After a thorough examination of what other services may be adversely affected by the blockage of port 6699, the administrator can add the following rule to the firewall and effectively block outbound traffic from the source port:

iptables -A OUTPUT -p TCP --sport 6699 -j REJECT

More elaborate rules can be created that control access to specific subnets, or even specific nodes, within a LAN. You can also restrict certain dubious services such as trojans, worms, and other client/server viruses from contacting their server. For example, there are some trojans that scan networks for services on ports from 31337 to 31340 (called the elite ports in cracking lingo). Since there are no legitimate services that communicate via these non-standard ports, blocking it can effectively diminish the chances that potentially infected nodes on your network independently communicate with their remote master servers.

iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP 

FORWARD and NAT Rules

Most organizations are allotted a limited number of publicly routable IP addresses from their ISP. Due to this limited allowance, administrators must find creative ways to share access to Internet services without giving scarce IP addresses to every node on the LAN. Using class C private IP address is the common way to allow all nodes on a LAN to properly access network services internally and externally. Edge routers (such as firewalls) can receive incoming transmissions from the Internet and route the bits to the intended LAN node; at the same time, it can also route outgoing requests from a LAN node to the remote Internet service. This forwarding of network traffic can become dangerous at times, especially with the availability of modern cracking tools that can spoof internal IP addresses and make the remote attacker's machine act as a node on your LAN. To prevent this, iptables provides routing and forwarding policies that you can implement to prevent aberrant usage of network resources.

The FORWARD policy allows an administrator to control where packets can be routed. For example, to allow forwarding for an entire internal IP address range, the following rule can be set:

iptables -A FORWARD -i eth1 -j ACCEPT

	Note
	By default, IPv4 policy in Red Hat Linux kernels disables support for IP forwarding, which prevents boxes running Red Hat Linux from functioning as dedicated edge routers. To enable IP forwarding, run the following command or place it in your firewall initialization script: echo "1" > /proc/sys/net/ipv4/ip_forward

FORWARD rules can be implemented to restrict certain types of traffic to the LAN only, such as local network file shares through NFS or Samba. The following rules reject outside connections to Samba shares:

iptables -A FORWARD -p tcp --sport 137:139 -j DROP
iptables -A FORWARD -p udp --sport 137:139 -j DROP

To take the restrictions a step further, you can block all outside connections that attempt to spoof private IP address ranges to infiltrate your LAN. If a LAN uses the 192.168.1.0/24 range, a rule can set the Internet facing network device (for example, eth0) to drop any packets to that device with an address in your LAN IP range. Because it is recommended to reject forwarded packets as a default policy, any other spoofed IP address will be rejected automatically.

iptables -A FORWARD -p tcp -s 192.168.1.0/24 -i eth0 -j DROP
iptables -A FORWARD -p udp -s 192.168.1.0/24 -i eth0 -j DROP

Rules can also be set to route traffic to certain machines, such as a dedicated HTTP or FTP server, preferably one that is isolated from the internal network on a DMZ. To set a rule for routing all incoming HTTP requests to a dedicated HTTP server at IP address 10.0.4.2 and port 80 (outside of the 192.168.1.0/24 range of the LAN), network address translation (NAT) calls a PREROUTING table to forward the packets to the proper destination ( the \ denotes a continuation of a one-line command):

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \
 -j DNAT --to 10.0.4.2:80

With this command, all HTTP connections to port 80 from the outside of the LAN will be routed to the HTTP server on a separate network from the rest of the internal network. This form of network segmentation can prove safer than allowing HTTP connections to a machine on the network.