4. FIREWALLING

4.1 Software and reading

You should read the Firewall-HOWTO.

That will tell you where to get ipfwadm if you don't already have it. There are other tools you can get but I made no progress until I tried ipfwadm. It is nice and low level! You can see exactly what it is doing.

4.2 Preliminary checks

You have compiled IP-forwarding and masquerading into the kernel so you will want to check that the firewall is in its default (accepting) state with

ipfwadm -I -l ipfwadm -O -l ipfwadm -F -l 

That is respectively, "display the rules affecting the .." incoming or outgoing or forwarding (masquerading) ".. sides of the firewall". The "-l" means "list".

You might have compiled in accounting too:

ipfwadm -A -l 

You should see that there are no rules defined and that the default is to accept every packet. You can get back to this working state anytime with

ipfwadm -I -f
ipfwadm -O -f
ipfwadm -F -f 

The "-f" means "flush". You may need to use that.

4.3 Default rule

I want to cut the world off from my internal net and do nothing else, so I will want to give as a last (default) rule that the firewall should ignore any packets coming in from the internal net and directed to outside. I put all the rules (in this order) into /etc/rc.d/rc.firewall and execute it from /etc/rc.d/rc.local at bootup.

ipfwadm -I -a reject -S 192.168.2.0/255.255.255.128 -D 0.0.0.0/0.0.0.0 

The "-S" is the source address/mask. The "-D" is the destination address/mask.

This format to is rather long-winded. Ipfwadm is intelligent about network names and some common abbreviations. Check the man pages.

It is possibly more convenient to put some or all of these rules on the outgoing half of the firewall by using "-O" instead of "-I", but I'll state the rules here all formulated for the incoming half.

4.4 Holes per address

Before that default rule, I have to place some rules that serve as exceptions to this general denial of external services to internal clients.

I want to treat the firewall machines address on the internal net specially. I will stop people logging in to the firewall machine unless they have special permission, but once they are there they should be allowed to talk to the world.

ipfwadm -I -i accept -S 192.168.2.100/255.255.255.255 \
 -D 0.0.0.0/0.0.0.0 

I also want the internal clients to be able to talk to the firewalling machine. Maybe they can persuade it to let them get out!

ipfwadm -I -i accept -S 192.168.2.0/255.255.255.128 \
 -D 192.168.2.100/255.255.255.255 

Check at this point that you can get in to the clients from outside the firewall via telnet, but that you cannot get out. That should mean that you can just about make first contact, but the clients cannot send you any prompts. You should be able to get all the way in if you use the firewall machine as a staging post. Try rlogin and ping too, with tcpdump running on one card or the other. You should be able to make sense of what you see.

4.5 Holes per protocol

I went on to relax the rules protocol by protocol. I want to allow pings from the outside to the inside to get an echo back, for instance, so I inserted the rule:

ipfwadm -I -i accept -P icmp -S 192.168.2.0/255.255.255.128 \
 -D 0.0.0.0/0.0.0.0 

The "-P icmp" works the protocol-specific magic.

Until I get hold of an ftp proxy I am also allowing ftp calls out with port-specific relaxations. This targets ports 20 21 and 115 on outside machines.

ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
 -D 0.0.0.0/0.0.0.0 20 21 115 

I could not make sendmail between the local clients work without a nameserver. Rather than set up a nameserver right then on the firewall, I just lifted the firewall for tcp domain service queries precisely aimed at the nearest existing nameserver and put its address in the clients /etc/resolv.conf ("nameserver 123.456.789.31" on a separate line).

ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 \
 -D 123.456.789.31/255.255.255.255 54 

You can find which port number and protocol a service requires with tcpdump. Trigger the service with a an ftp or a telnet or whatever to or from the internal machine and then watch for it on the input and output ports of the firewall with tcpdump:

tcpdump -i eth1 -e host client04 

for example. The /etc/services file is another important source of clues. To let telnet and ftp IN to the firewall from outside, you have to allow the local clients to call OUT on a specific port. I understand why this is necessary for ftp - it's the server that establishes the data stream in the end - but I am not sure why telnet also needs this.

ipfwadm -I -i accept -P tcp -S 192.168.2.0/255.255.255.128 ftp telnet \
 -D 0.0.0.0/0.0.0.0 

There is a particular problem with some daemons that look up the hostname of the firewalling machine in order to decide what is their networking address. Rpc.yppasswdd is the one I had trouble with. It insists on broadcasting information that says it is outside the firewall (on the second card). That means the clients inside can't contact it.

Rather than start IP aliasing or change the daemon code, I mapped the name to the inside card address on the clients in their /etc/hosts.

4.6 Checks

You want to test that you can still telnet, rlogin and ping from the outside. From the inside you should be able to ping out. You should also be able to telnet to the firewall machine from the inside and the latter should be able to do anything.

That is it. At this point you probably want to learn about rpc/Yellow Pages and the interaction with the password file. The firewalled network wants to run without its unprivileged users being able to log on to the firewall - and thus get out. Some other HOWTO!