The iptables Command

Many security experts will argue that iptables is best managed from the command line if you have the time and expertise that it requires. The iptables command has a number of options that allow you to access the iptables subsystem in a variety of ways. Before you begin to issue iptables commands, however, make sure that the kernel modules are loaded:

   # lsmod | grep ^ip
   ipt_REJECT    4216   1   (autoclean)
   ipt_state       1080   3   (autoclean)
   ip_conntrack    27752  1   (autoclean) [ipt_state]
   iptable_filter  2444   1   (autoclean)
   ip_tables       14560  3 [ipt_REJECT    ipt_state iptable_filter]

This output shows that the base kernel module ip_tables is running, and that several related modules are loaded on top of it. This is roughly the default state on a Fedora Core system. If you see output similar to this, you can check the status of the iptables service with the following command:

#  /etc/init.d/iptables status
Table: filter
Chain INPUT (policy ACCEPT)
target prot opt source        destination
RH-Firewall-1-INPUT all -- anywhere               anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source        destination
RH-Firewall-1-INPUT all -- anywhere               anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source        destination

Chain RH-1-Firewall-1-INPUT (2 references)
target prot opt source             destination
ACCEPT all -- anywhere             anywhere
ACCEPT icmp-- anywhere             anywhere  icmp any
ACCEPT ipv6-crypt-- anywhere           anywhere
ACCEPT ipv6-auth-- anywhere            anywhere
ACCEPT all -- anywhere             anywhere          state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere             anywhere          state NEW tcp dpt:http
ACCEPT tcp -- anywhere             anywhere          state NEW tcp dpt:ssh
REJECT all -- anywhere             anywhere          reject-with icmp-host-
prohibited

This output shows that iptables is running, that you are looking (by default) at the table named "filter," and that there are several chains of rules in the "filter" table.

In a nutshell, iptables contains three base tables (nat, mangle, and filter), each of which contains various chains of rules. Some functions (such as INPUT, OUTPUT, RH-Firewall-1-INPUT, intrusion, portsentry, and so on) contain an ordered set of access control rules called a chain. Each chain is named for the associated function. A chain of rules determines the ACCEPT or REJECT ordering and behavior toward a given packet flowing through the chain. Figure 11-5 illustrates this concept.

Figure 11-5: The most commonly used iptables for simple firewalls, called "filter." iptables is composed of multiple sets of tables of chains, and these chains have ordered sets of rules.

   # /etc/init.d/iptables status

   # service iptables status

   # iptables -L

The "filter" table contains INPUT, FORWARD, and OUTPUT chains by default (as seen in Figure 11-5). In newer Red Hat Linux and Fedora Core systems, you will also see a custom chain in "filter" called RH-Firewall-1-INPUT. This custom chain is installed for you, and is configured at installation time based on the options you select. (Yours may appear slightly different from the one shown here depending on your installation selections.) Note that the INPUT and FORWARD chains pass control to the RH-Firewall-1-INPUT chain. Most of the ACCEPT and REJECT rules in this final chain control what is allowed into the server and what is not. For example, if you follow along Figure 11-5 or the previous iptable listing, in this particular setup it looks as if the first rule in the RH-Firewall-1-INPUT chain ACCEPTs "all" from "*" to "*". This is not for all interfaces on the server but actually just for the to (localhost) loopback device (the server itself), but it is just not identified as such in this type of listing. The second rule in the RH-Firewall-1-INPUT chain ACCEPTs icmp (for example, ping) packets, followed by IPv6 encryption and authentication packets, incoming traffic state related to already established sessions, incoming NEW web (http) and ssh requests, in that order. Everything else is caught by the last REJECT rule in that chain and rejected. Remember, order is important when setting up chains of rules (or ACLs) like this.

/etc/sysconfig/iptables

Querying iptables for its table listing is a good way to see what's currently running in your firewall configuration. If someone has added a new rule from the command line, you'll see it in the output of iptables -L. However, you can also examine the /etc/sysconfig/iptables configuration file to view the "filter" table and its boot time chains. Here's the /etc/sysconfig/iptables configuration file that produced the rule set we listed above:

# cat /etc/sysconfig/iptables
# Firewall configuration written by redhat-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80-j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22-j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Stepping Through the RH-Firewall-1-INPUT Chain

If you're having problems thus far, don't worry. In this section we'll step through each rule in our filter table here.

The settings in this example RH-Firewall-1-INPUT chain are fairly basic. The first entries are the rules that tell the INPUT and FORWARD chains to jump (-j), or send, their output on to the RH-Firewall-1-INPUT chain:

   -A INPUT -j RH-Firewall-1-INPUT
   -A FORWARD -j RH-Firewall-1-INPUT

These settings are actually not a part of the RH-Firewall-1-INPUT chain itself (they belong to the INPUT and FORWARD chains), but without them the RH-Firewall-1-INPUT chain would never be referenced since all incoming requests come through either the INPUT or the FILTER chain.

The first rule of the RH-Firewall-1-INPUT chain is actually

   -A RH-Firewall-1-INPUT -i lo -j ACCEPT

This rule tells iptables to automatically ACCEPT all packets coming in from lo (the loopback device). Remember this line from the iptables - L output shown earlier?

   ACCEPT all -- anywhere        anywhere

Although all from anywhere is allowed, the first rule in the RH-Firewall-1-INPUT chain shows that this actually happens only for the lo or the loopback or localhost interface (127.0.0.1), as defined by the -i lo component of the rule.

The next line of the chain contains the first all-interface rule:

   -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT

This line shows that the firewall is appending (the -A switch) a new rule to the chain and that the protocol type ICMP (-p icmp) will jump to the target ACCEPT. The location to which these requests jump is called the target, and it defines how this type of incoming data will be handled. Since ping uses ICMP (Internet Control Management Protocol), this rule says that the firewall will ACCEPT and react normally to ping requests, as well as other ICMP packet types.

If you've never used iptables before, or don't have a good feel for it, it is critical that you get a feel for how this all works. For those readers who aren't functionally familiar with iptables, let's stop for a moment and test some of what I've been showing you.

Testing Other iptables Rule Variations

If you want to change the jump action, or target behavior, to actively DROP ICMP packets immediately rather than relying on a REJECT rule later in the file, try this rule instead of the default ICMP line:

   -A CHAIN-NAME -p icmp --icmp-type any -j DROP

DROPping a packet is the most secure way to not accept traffic. To the machines on the outside, it looks like the packet just goes away.

You may configure this rule to affect only the networking interface eth1 with (if you have a second network card)

-A CHAIN-NAME -p icmp --icmp-type any -i eth1 -j DROP

What about stopping this type of traffic only from outside networks?

-A CHAIN-NAME -p icmp --icmp-type any -s ! 10.1.1.0/24 --j DROP

Target values can be set to ACCEPT, QUEUE, RETURN, or DROP. The target QUEUE is little used, but can pass a specified packet from the kernel into user program space. RETURN is another uncommon target that simply passes a packet back to the previous chain.

The DROP target is an excellent security solution as nothing at all is returned to the requesting client. From the client's perspective, it looks like the machine isn't there at all. The machine does not appear to be on the network, which can be very useful.

However, depending on the type of reject message you want to return to the client, you may want to use REJECT instead of dropping the packet cold. There are several types of REJECT messages that send specific ICMP information. Search the iptables man page for "reject-with" to learn more.

RH-Firewall-1-INPUT Chain (Continued)

Now that you are familiar with more of the inner workings and functionality of iptables in action, we can return to the RH-Firewall-1-INPUT chain.

We've seen the first couple of rules in this chain (accept lo and accept icmp); the next two rules in our RH-Firewall-1-INPUT chain are

   -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
   -A RH-Firewall-1-INPUT -p 51 -j ACCEPT

to append the acceptance of IPv6-Crypt and IPv6-Auth protocols. These are the encryption and authentication protocols defined in /etc/protocols for initiative IPv6-based connections.

Next, the entry

-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

triggers stateful inspection. The -m, or MATCH, extension allows you to load specialized packet-matching modules for specific packet types and uses. The -m state component tells iptables to load the special state-tracking kernel module called state. (The actual module name is ipt_state, and it requires ipt_conntrack to run properly.)

With this stateful inspection and conntrack in place, iptables can use state tables to track which incoming and outgoing packets are associated with each other over time. In essence, the system will know that incoming packet X is associated with the existing two-way session Y using protocol Z; the state of the session is known and tracked over time. The aforementioned rule allows ESTABLISHED bidirectional continuing packets to come in if they are associated with a known connection, and RELATED for new packets if they are associated with a known connection, even if the session is on a different port or spread over multiple ports (such as NFS or FTP).

You can even enable custom kernel modules to track other special bidirectional multiport applications like active FTP, IRC, and SNMP. This type of stateful firewalling is what allows iptables to handle, for example, active (nonpassive) FTP sessions started from your machine's ftp client, connecting to another FTP server, and allowing that server to establish the data channel (port 20) back to your machine. Older firewalls that don't use stateful tracking have serious problems letting external boxes establish anything "back in" through not-so-intelligent firewall software, and as such require passive FTP connections.

The next two rules from our RH-Firewall-1-INPUT chain are something new:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j
  ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j
  ACCEPT

These are rule matches for client requests on ports 80 and 22. These two rules are holes that have been punched in the firewall to allow new sessions (anyone who wants to try), or clients with the state NEW, on these ports, which happen to allow us to serve HTTP and SSH respectively. These holes were probably punched at installation when we enabled WWW and SSH traffic in the firewall for the example server we've been building, or from running the redhat-config-securitylevel tool.

The final rule is probably the most important from a security perspective:

   -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

This REJECT-all rule ensures that if a packet has gotten this far without matching any ACCEPT rules, it will match and be rejected here. Such packets won't make it past iptables into any daemons or applications, not even TCP wrappers. This function is usually managed with either a REJECT or a DROP rule. In this case, we're being network-friendly and returning a message that says icmp-host-prohibited.

Finally, you must be sure that this /etc/sysconfig/iptbales file-specific command ends your iptables config file:

   COMMIT

Without this, there is no firewall.

After making any changes you need in /etc/sysconfig/iptables, save the file, and exit the text editor. Restart iptables with the /etc/init.d/iptables restart command.

Firewall State Triggers

You might wonder how we figured out the various state triggers to use in our rules, such as NEW, RELATED, and ESTABLISHED. Luckily, the match module itself can help you out. Once you've loaded the module into iptables from the command line, you can ask it for help at the command line. The module will append its own help file onto the regular iptables help output. For example, to get help on the match module named state, issue this command:

   # iptables -m state-help
   iptables v1.2.8
   Usage: iptables -[AD] chain rule-specification [options]
        iptables -[RI] chain rulenum rule-specification [options]
        iptables -D chain rulenum [options]
   ...
     --set-counters PKTS BYTES   set counter during insert/append
     --version   -V              print package version.


   state v1.2.8 options:
     --state [INVALID | ESTABLISHED | NEW | RELATED][,...]
                          State(s) to match

In the next to last line, the module prints all the valid states that can be used in your firewall. Try this with other match modules-but, you may ask, how do I know what other match modules I've got? Issue these commands:

   #  export LC_ALL=C
   #  locate netfilter/ipt_|grep \/$(uname -r)\/.*[a-z].o$

   There you go-enough iptables black magic to consume your time for the next year
   (and potentially double your salary in the process!).

Now that you've seen the rules in /etc/sysconfig/iptables and determined the settings for your basic firewall, we can return to the example server shown earlier in this chapter. Remember that we wanted to lock clown the Apache web server so that only our 172.16.1.* remote office network can access these web resources. Do that by changing the port 80 web server line from

   -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p
      tcp --dport 80 -j ACCEPT

to

   -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p
      tcp -s 172.16.1.0/24 --dport 80 -j ACCEPT

This will only match all of our criteria when the source IP address is from the 172.16.1.* network. Save the file, exit the editor, and restart iptables.

Once the stand-alone server's iptables firewall is set up and restarted, you can rescan your system with the nmap program to see how the new firewall looks from the outside. The scan will take much longer this time, since you've locked down a whole range of ports. Go to another Linux machine on your network and issue this command:

# nmap 192.168.128.25
Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
Interesting ports on mydomain.com (192.168.128.25):
(The 1552 ports scanned but not shown below are in state: filtered)
Port       State       Service
22/tcp     open        ssh
80/tcp     open        http
Nmap run completed -- 1 IP address (1 host up) scanned in 680 seconds

This network profile looks a lot better than the first time we scanned the server. All those old services are still running, but no one but the people we want can get to them now. The fewer doors and windows you leave open to curious passersby, the more secure your house. Notice how long this scan took, as well. Most script kiddies will get bored and move on long before a scan this lengthy is complete.