Linux Firewall Configuration (Firewall Rules) using commands in ipfwadm Utility

IP Firewall Conifugration Using ipfwadm Utility 

The ipfwadm command was the configuration tool for the second generation Linux IP firewall. 

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. 

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

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.

Listing our rules

After we've entered our rules, we ask ipfwadm to list them for us using the command:

# ipfwadm -F -l

This command will list all of the configured forwarding rules. The output should look something like this:

# 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 ipfwadm command will attempt to translate the port number into a service name using the /etc/services if an entry exists there.

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, 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 ...

A 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

Right? Well, not necessarily. FTP servers can operate in two different modes: passive mode and active mode.In passive mode, the FTP server listens for a connection from the client. In active mode, the server actually makes the connection to the client. Active mode is usually the default. 

FTP active mode is somewhat nonintuitively enabled using the PORT command. FTP passive mode is enabled using the PASV command.

FTP server modes

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.

The Pro FTPd daemon is a good example of an FTP server that doesn't, at least in older versions.

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 rule set for it. A real firewall configuration can be quite complex.

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.

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

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

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

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.