Olaf Kirch - Linux Network Administrator Guide, Second Edition

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.

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.

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

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

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

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.

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

Most aspects of Linux are evolving to meet the increasing demands of its users; IP firewall is no exception. The traditional IP firewall implementation is fine for most applications, but can be clumsy and inefficient to configure for complex environments. To solve this problem, a new method of configuring IP firewall and related features was developed. This new method was called "IP Firewall Chains" and was first released for general use in the 2.2.0 Linux kernel.