9.6. Original IP Firewall (2.0 Kernels)
The first generation IP firewall support for Linux appeared in the 1.1 series kernel. It was a port of the BSD ipfw firewall support to Linux by Alan Cox. The firewall support that appeared in the 2.0 series kernels and is the second generation was enhanced by Jos Vos, Pauline Middelink, and others.
9.6.1. Using ipfwadm
The ipfwadm command was the configuration tool for the second generation Linux IP firewall. Perhaps the simplest way to describe the use of the ipfwadm command is by example. To begin, let's code the example we presented earlier.
9.6.1.1. A naïve example
Let's suppose that we have a network in our organization and that we are using a Linux-based firewall machine to connect our network to the Internet. Additionally, let's suppose that we wish the users of that network to be able to access web servers on the Internet, but to allow no other traffic to be passed.
We will put in place a forwarding rule to allow datagrams with a source address on our network and a destination socket of port 80 to be forwarded out, and for the corresponding reply datagrams to be forwarded back via the firewall.
Assume our network has a 24-bit network mask (Class C) and an address of 172.16.1.0. The rules we might use are:
# ipfwadm -F -f # ipfwadm -F -p deny # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 # ipfwadm -F -a accept -P tcp -S 0/0 80 -D 172.16.1.0/24 |
The -F command-line argument tells ipfwadm that this is a forwarding rule. The first command instructs ipfwadm to "flush" all of the forwarding rules. This ensures we are working from a known state before we begin adding specific rules.
The second rule sets our default forwarding policy. We tell the kernel to deny or disallow forwarding of IP datagrams. It is very important to set the default policy, because this describes what will happen to any datagrams that are not specifically handled by any other rule. In most firewall configurations, you will want to set your default policy to "deny," as shown, to be sure that only the traffic you specifically allow past your firewall is forwarded.
The third and fourth rules are the ones that implement our requirement. The third command allows our datagrams out, and the fourth rule allows the responses back.
Let's review each of the arguments:
- -F
-
This is a Forwarding rule.
- -a accept
-
Append this rule with the policy set to "accept," meaning we will forward any datagrams that match this rule.
- -P tcp
-
This rule applies to tcp datagrams (as opposed to UDP or ICMP).
- -S 172.16.1.0/24
-
The Source address must have the first 24 bits matching those of the network address 172.16.1.0.
- -D 0/0 80
-
The destination address must have zero bits matching the address 0.0.0.0. This is really a shorthand notation for "anything." The 80 is the destination port, in this case WWW. You may also use any entry that appears in the /etc/services file to describe the port, so -D 0/0 www would have worked just as well.
ipfwadm accepts network masks in a form with which you may not be familiar. The /nn notation is a means of describing how many bits of the supplied address are significant, or the size of the mask. The bits are always counted from left to right; some common examples are listed in Table 9-1.
Table 9-1. Common Netmask Bit Values
| Netmask | Bits |
|---|---|
| 255.0.0.0 | 8 |
| 255.255.0.0 | 16 |
| 255.255.255.0 | 24 |
| 255.255.255.128 | 25 |
| 255.255.255.192 | 26 |
| 255.255.255.224 | 27 |
| 255.255.255.240 | 28 |
| 255.255.255.248 | 29 |
| 255.255.255.252 | 30 |
We mentioned earlier that ipfwadm implements a small trick that makes adding these sorts of rules easier. This trick is an option called -b, which makes the command a bidirectional rule.
The bidirectional flag allows us to collapse our two rules into one as follows:
# ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b |
9.6.1.2. An important refinement
Take a closer look at our ruleset. Can you see that there is still one method of attack that someone outside could use to defeat our firewall?
Our ruleset allows all datagrams from outside our network with a source port of 80 to pass. This will include those datagrams with the SYN bit set! The SYN bit is what declares a TCP datagram to be a connection request. If a person on the outside had privileged access to a host, they could make a connection through our firewall to any of our hosts, provided they use port 80 at their end. This is not what we intended.
Fortunately there is a solution to this problem. The ipfwadm command provides another flag that allows us to build rules that will match datagrams with the SYN bit set. Let's change our example to include such a rule:
# ipfwadm -F -a deny -P tcp -S 0/0 80 -D 172.16.10.0/24 -y # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b |
The -y flag causes the rule to match only if the SYN flag is set in the datagram. So our new rule says: "Deny any TCP datagrams destined for our network from anywhere with a source port of 80 and the SYN bit set," or "Deny any connection requests from hosts using port 80."
Why have we placed this special rule before the main rule? IP firewall rules operate so that the first match is the rule that is used. Both rules would match the datagrams we want to stop, so we must be sure to put the deny rule before the accept rule.
9.6.1.3. Listing our rules
After we've entered our rules, we ask ipfwadm to list them for us using the command:
# ipfwadm -F -l |
# ipfwadm -F -l IP firewall forward rules, default policy: accept type prot source destination ports deny tcp anywhere 172.16.10.0/24 www -> any acc tcp 172.16.1.0/24 anywhere any -> www |
The default output is lacking in some important detail for us. In the default listing output, we can't see the effect of the -y argument. The ipfwadm command is able to produce a more detailed listing output if you specify the -e (extended output) argument too. We won't show the whole output here because it is too wide for the page, but it includes an opt (options) column that shows the -y option controlling SYN packets:
# ipfwadm -F -l -e
P firewall forward rules, default policy: accept
pkts bytes type prot opt tosa tosx ifname ifaddress source ...
0 0 deny tcp --y- 0xFF 0x00 any any anywhere ...
0 0 acc tcp b--- 0xFF 0x00 any any 172.16.1.0/24 ...
|
9.6.2. A More Complex Example
The previous example was a simple one. Not all network services are as simple as the WWW service to configure; in practice, a typical firewall configuration would be much more complex. Let's look at another common example, this time FTP. We want our internal network users to be able to log into FTP servers on the Internet to read and write files. But we don't want people on the Internet to be able to log into our FTP servers.
We know that FTP uses two TCP ports: port 20 (ftp-data) and port 21 (ftp), so:
# ipfwadm -a deny -P tcp -S 0/0 20 -D 172.16.1.0/24 -y # ipfwadm -a accept -P tcp -S 172.16.1.0/24 -D 0/0 20 -b # # ipfwadm -a deny -P tcp -S 0/0 21 -D 172.16.1.0/24 -y # ipfwadm -a accept -P tcp -S 172.16.1.0/24 -D 0/0 21 -b |
Many FTP servers make their data connection from port 20 when operating in active mode, which simplifies things for us a little, but unfortunately not all do.[2]
But how does this affect us? Take a look at our rule for port 20, the FTP-data port. The rule as we have it now assumes that the connection will be made by our client to the server. This will work if we use passive mode. But it is very difficult for us to configure a satisfactory rule to allow FTP active mode, because we may not know in advance what ports will be used. If we open up our firewall to allow incoming connections on any port, we are exposing our network to attack on all services that accept connections.
The dilemna is most safely resolved by insisting that our users operate in passive mode. Most FTP servers and many FTP clients will operate this way. The popular ncftp client also supports passive mode, but it may require a small configuration change to make it default to passive mode. Many World Wide Web browsers such as the Netscape browser also support passive mode FTP, so it shouldn't be too hard to find appropriate software to use. Alternatively, you can avoid the issue entirely by using an FTP proxy server that accepts a connection from the internal network and establishes connections to the outside network.
In building your firewall, you will probably find a number of these sorts of problems. You should always give careful thought to how a service actually operates to be sure you have put in place an appropriate ruleset for it. A real firewall configuration can be quite complex.
9.6.3. Summary of ipfwadm Arguments
The ipfwadm has many different arguments that relate to IP firewall configuration. The general syntax is:
ipfwadm category command parameters [options] |
Let's take a look at each of these.
9.6.3.1. Categories
One and only one of the following must be supplied. The category tells the firewall what sort of firewall rule you are configuring:
- -I
-
Input rule
- -O
-
Output rule
- -F
-
Forwarding rule
9.6.3.2. Commands
At least one of the following must be supplied and applies only to those rules that relate to the supplied category. The command tells the firewall what action to take.
- -a [policy]
-
Append a new rule
- -i [policy]
-
Insert a new rule
- -d [policy]
-
Delete an existing rule
- -p policy
-
Set the default policy
- -l
-
List all existing rules
- -f
-
Flush all existing rules
The policies relevant to IP firewall and their meanings are:
- accept
-
Allows matching datagrams to be received, forwarded, or transmitted
- deny
-
Blocks matching datagrams from being received, forwarded, or transmitted
- reject
-
Blocks matching datagrams from being received, forwarded, or transmitted, and sends the host that sent the datagram and ICMP error message
9.6.3.3. Parameters
At least one of the following must be supplied. Use the parameters to specify to which datagrams this rule applies:
- -P protocol
-
Can be TCP, UDP, ICMP, or all. Example:
-P tcp
- -S address[/mask] [port]
-
Source IP address that this rule will match. A netmask of “/32” will be assumed if you don't supply one. You may optionally specify which ports this rule will apply to. You must also specify the protocol using the -P argument described above for this to work. If you don't specify a port or port range, “all” ports will be assumed to match. Ports may be specified by name, using their /etc/services entry if you wish. In the case of the ICMP protocol, the port field is used to indicate the ICMP datagram types. Port ranges may be described; use the general syntax: lowport:highport. Here is an example:
-S 172.29.16.1/24 ftp:ftp-data
- -D address[/mask] [port]
-
Specify the destination IP address that this rule will match. The destination address is coded with the same rules as the source address described previously. Here is an example:
-D 172.29.16.1/24 smtp
- -V address
-
Specify the address of the network interface on which the packet is received (-I ) or is being sent (-O). This allows us to create rules that apply only to certain network interfaces on our machine. Here is an example:
-V 172.29.16.1
- -W name
-
Specify the name of the network interface. This argument works in the same way as the -V argument, except you supply the device name instead of its address. Here is an example:
-W ppp0
9.6.3.4. Optional arguments
These arguments are sometimes very useful:
- -b
-
This is used for bidirectional mode. This flag matches traffic flowing in either direction between the specified source and destination. This saves you from having to create two rules: one for the forward direction of a connection and one for the reverse.
- -o
-
This enables logging of matching datagrams to the kernel log. Any datagram that matches this rule will be logged as a kernel message. This is useful to enable you to detect unauthorized access.
- -y
-
This is used to match TCP connect datagrams. The option causes the rule to match only datagrams that attempt to establish TCP connections. Only datagrams that have their SYN bit set, but their ACK bit unset, will match. This is useful to filter TCP connection attempts and is ignored for other protocols.
- -k
-
This is used to match TCP acknowledgement datagrams. This option causes the rule to match only datagrams that are acknowledgements to packets attempting to establish TCP connections. Only datagrams that have their ACK bit set will match. This is useful to filter TCP connection attempts and is ignored for all other protocols.
9.6.3.5. ICMP datagram types
Each of the firewall configuration commands allows you to specify ICMP datagram types. Unlike TCP and UDP ports, there is no convenient configuration file that lists the datagram types and their meanings. The ICMP datagram types are defined in RFC-1700, the Assigned Numbers RFC. The ICMP datagram types are also listed in one of the standard C library header files. The /usr/include/netinet/ip_icmp.h file, which belongs to the GNU standard library package and is used by C programmers when writing network software that uses the ICMP protocol, also defines the ICMP datagram types. For your convenience, we've listed them in Table 9-2. The iptables command interface allows you to specify ICMP types by name, so we've listed the mnemonics it uses, as well.
Table 9-2. ICMP Datagram Types
| Type Number | iptables Mnemonic | Type Description |
|---|---|---|
| 0 | echo-reply | Echo Reply |
| 3 | destination-unreachable | Destination Unreachable |
| 4 | source-quench | Source Quench |
| 5 | redirect | Redirect |
| 8 | echo-request | Echo Request |
| 11 | time-exceeded | Time Exceeded |
| 12 | parameter-problem | Parameter Problem |
| 13 | timestamp-request | Timestamp Request |
| 14 | timestamp-reply | Timestamp Reply |
| 15 | none | Information Request |
| 16 | none | Information Reply |
| 17 | address-mask-request | Address Mask Request |
| 18 | address-mask-reply | Address Mask Reply |