Your Iptable Is Ready: Using A Linux Firewall

In the Wild West atmosphere of the Internet, firewalls are a popular topic. That's a good thing: Whether you're responsible for hundreds of corporate servers or a single home workstation, anyone who manages a computer needs to know how firewalls work and how to deploy them properly.

A firewall controls access to a local network, locking out intruders while keeping your systems--and your data--safe on the inside. The firewall capabilities built into Linux can also restrict outgoing network access, ensuring that your corporate secrets remain secret, even against an attack from inside a local network I'll go into further detail about this later; for now, it's enough to know that you can use a Linux firewall to identify and control access to any computer with an IP address

Just The Facts: Linux Firewall Basics
The world of Linux firewall access depends on the interactions between three main players: netfilter, a subsystem in the Linux kernel that analyzes and filters IP data packets; iptables, a tool for managing and applying the rulesets that apply these packet filters; and hardware such as the eth0 device or an attached modem-*. The firewall software itself is defined as the interaction between input and output queues, transformation queues (there may be many other queues), and a rule base that further defines such interaction between queues.

It's not enough simply to attach a computer to a network connection; it also needs the right software to process arriving and outgoing data packets. A firewall controls this processing, applying pertinent rules and dictating what happens to a packet as a result. As a rule, a firewall may do three things with a packet: accept it and pass it onwards; accept it but refuse to pass it along or even respond to the sender ("dropping" the packet); or refuse to pass it while also returning a failure code/packet to the sender.

Playing By The Rules: Iptable Packet Analysis
What makes a rule pertinent to a particular packet? It all depends on whether a rule matches a packet's characteristics: its source or destination, data type, the user who owns the process that generated the packet, and a zillion other examples, most of which are rather technical and rarely used. Rules can be very specific: They may allow a packet to join the output queue, for example, only if it's targeted to a specific gateway machine, is of a particular type such as tcp or udp, came from a user named "fred", and so forth.More information on this topic is available on the iptable man pages. These are widely available on Web sites and installed Linux systems; for this article, I referred to the online version at http://www.unixhelp.ed.sc.uk.

There are other types of possible responses, but they're not germane to an introductory explanation, and we won't discuss them for now. (They're also available on the man pages, of course.)

One more important fact: Each packet includes source and destination IP addesses, and iptables can apply rules based upon these addresses as well as their packet type.

Start A Firewall: Working With Iptables
Let's install some firewall rules into iptables:

First, let's look at what you have immediately upon booting Linux. Login as root and type:

iptables -L (or iptables --list if you like being verbose)

By default, you'll have three chains: input, output, and forward, all perfectly happy to accept anything, from anyone, for any recipient. Not much of a firewall, eh? Add a few rules, however, and it quickly turns into a real firewall.

A useful example of firewall restriction involves the ubiquitous ping command. We've all used ping to see if a host is online and reachable. When you ping a site, your computer sends a special packet of type icmp to the host. The host catches the packet and responds with its own icmp packet. Your computer measures the time it takes to receive the return packet and then displays it, usually in milliseconds. That's it--simple and useful.

Alas, the wrong people can abuse even this seemingly innocent tool. First of all, if a site even reveals its presence online without a good reason, it creates a security risk. Also,when the initial icmp packet is transmitted, it contains a configurable buffer. If a user sets this buffer to a certain size, it can crash a receiving system that isn't properly "hardened" with up-to-date software--an exploit widely known as the "Ping of Death." In addition to crashing the computer at its final destination, a Ping of Death exploit can also crash every unprotected machine one of these bad packets traverses--and by design, most packets pass through several computers as they make their way across the Internet.

Firewalls can prevent both of these security risks. Here's how to do it.First, configure your firewall not to respond to ping attempts. Add a rule to iptables instructing the firewall to drop icmp packets when they arrive at the input queue. As the root user, at the command prompt type:

iptables -A INPUT -p icmp -j DROP 

This tells the input queue: When you get icmp packets of any type, just drop 'em. (The "-j" switch indicates a "jump" target such as "Drop", "Reject," or "Log.")

This command effectively makes your machine "drop" off the net: It can't respond to pings because it never sees them--they never make it out of the input queue.

Similarly, the following command:

iptables -A OUTPUT -p icmp -j DROP

instructs the firewall to drop outgoing icmp packets responding to a ping attempt. (This still leaves a system open to Ping of Death attacks, if it it's not properly patched.)

Each table entry can also include rules based on the source of incoming packets, as well as the destination of outgoing packets. For example, the following line will reject output packets of type tcp and originating from a telnet program, unless the packet is addressed to a computer on the local network (represented here by the "!" symbol and the 198.168.0.0 IP address):

iptables -A OUTPUT -p tcp  __ --destination-port telnet -d ! 198.168.0.0 -j DROP

This iptables entry instructs the firewall to drop packets going to other IP addresses. You could reject them instead by replacing the outgoing queue type with reject instead of drop. The telnet program will respond the same way whether it gets a response from a rejected packet or no response at all from a dropped packet.

Don't Pass A Bad Packet

Although it's not strictly required, it's a good idea to drop invalid packets rather than being a bad net citizen and propagating them further. This is easy to accomplish by entering a command such as:

iptables -A INPUT  -state INVALID -j DROP

The -state option shown here uses a comma-separated list of parameters, such as invalid, new, and established, that match a rule to a packet's connection state.

As you can see, even in this introduction, setting up a Linux firewall by using iptables can be extraordinarily powerful. To me, the best thing about all that power is the fact that it's so easy to access it and apply it to suit your own needs.More information on iptables is available at the Netfilter Homepage as well as through their mailing list: http://lists.samba.org/pipermail/netfilter/.

Ross M. Greenberg has been doing security related computer work since before there was an Internet or Linux, and was the forum manager of MSN's Virus & Security Forum .