IPChains

Well, now that we've got a working kernel, we've got two things left to do: install IPChains, and put some rules together. First, installing IPChains.

Head off to http://netfilter.filewatcher.org/ipchains/ and download and install the latest version. When I grabbed 1.3.10, I noticed there was already a version of ipchains compiled in the directory. Being the paranoid sod that I am, I deleted that binary, and recompiled from source with a simple "make." Even on my P75, compilation took less than a minute. Then a "make install" as root, and you'll be ready to install some ipchains rulesets.

IPChains Rulesets

Well, the simplest possible set of rules would look like this:

 /sbin/ipchains -F forward

 /sbin/ipchains -P forward DENY

 /sbin/ipchains -A forward -j MASQ -s 192.168.2.0/24 -d 0.0.0.0/0

Basically, the first line flushes all forwarding rules. The second line says, "Our standard reaction to forwarding requests is to deny them." The third line says, " Anyone coming from 192.168.2.0 is AOK by me. They can send packets anywhere and get responses." Obviously, you'd want to substitute your own internal IP address space for 192.168.2.0. If you use the 192.168.0.x space, simply replace 192.168.2.0 with 192.168.0.0. The terminating 0 means "anyone whose IP address starts with the preceding three numbers ." (Actually, the combination of the subnet mask (24) and the IP subnet (192.168.2.0) are what determine that, but if you don't understand subnet masks and subnets, that's okay.)

Throw those rules up on your firewall and go to town. You should now be able to connect from any internal machine to any external provided you have set the firewall's IP address as that machine's default gateway. To set your default gateway on Linux, type

 route add default gw xxx.yyy.www.zzz

where xxx.yyy.www.zzz is the internal IP address of your firewall. The internal IP address is the IP address assigned to the NIC that is attached to your internal network. The other NIC will have some ISP-assigned IP address, about which we don't care. For MS Windows, you can set the default gateway in the TCP/IP properties section of the network control panel.

If your internal machines can't connect, there are several things to check:

1. Does the internal machine have the correct default route set?

2. Are you sure you typed the ipchains commands properly on the firewall? Use ipchains -L to verify the currently running rules.

3. Are you running the right kernel on the firewall machine (you remember, the one you compiled with IP Masquerading support)?

4. Did you remember to turn on IP Forwarding, as mentioned earlier?

5. Can the firewall itself reach the site you're using to test?

6. Can your firewall ping the default route on its external NIC?

7. Do you have network connectivity between the firewall and internal machines?

If all those things are true, and you still can't reach the outside world from the internal network, then well, it's time to hit the documents. Take a look at the IPChains-HOWTO and the IP-Masquerading-HOWTO, available from http://www.linuxdoc.org/ , or from the homepage listed at the beginning of the chapter.

If, however, everything is working fine at this point, go ahead and put the three earlier commands into something /etc/rc.d/rc.ipchains or /etc/rc.d/rc.firewall, make sure the file is executable, and call it from your rc.local file (on RedHat, Mandrake, and Turbolinux, at least; on SuSE, you'll need to create a start-up and shutdown script ”just copy one of the existing ones, and change the relevant bits).

Secure IPChains Rules

The next set of rules I'll give you will help secure your system a bit better, but it's no catch-all. The first thing you have to do is go through your firewall box and deactivate all unnecessary services. /etc/inetd.conf has lots of things listed, and go ahead and deactivate pretty much all of them. For connecting to your firewall, you should install openssh (see Chapter 14 on SSH). Never use Telnet or File Transfer Protocol (FTP) to connect to your firewall, and certainly not from the outside. Go into your /etc/rc.d directory and make a new directory called unused. At the very least move the nfs and smb and nfsserver scripts into the unused directory. Delete the symbolic links from /etc/rc.d/rcX.d. You can even get away with deactivating inetd entirely. This will help avoid inetd-based DoS attacks, since inetd can't swamp the system if it's not even running (sshd isn't usually started from inetd, so sshd can still be running without needing inetd). Basically, don't run anything unnecessary on your firewall. I run openssh and the distributed.net client. Why do I consider the distributed.net client? Because I have a chance of winning $1000 by running it. Anyway, those two applications are it ”I don't run anything else. Anything else is a security hole.

On to the secure rules:

 /sbin/ipchains -F input

 #stuffed masquerading? no thanks

 /sbin/ipchains -A input -i eth1 -s 192.168.2.0/24 -d 0.0.0.0/0 -l -j REJECT

 #inbound stuffed routing? no way

 /sbin/ipchains -F output

 /sbin/ipchains -A output -i eth1 -s 0.0.0.0/0 -d 192.168.2.0/24 -l -j REJECT

 /sbin/ipchains -F forward

 /sbin/ipchains -P forward DENY

 /sbin/ipchains -A forward -j MASQ -s 192.168.2.0/24 -d 0.0.0.0/0

The first thing this does is to flush all input rules, then it sets up a rule that rejects IP packets that come from the outside but have internal IP addresses. Since it's impossible for one of your internal machines to be on the outside, someone is doing something nasty. It also logs any such request into /var/log/messages.

Next, all output rules are flushed, and then a rule that forbids stuffed routing ”packets that have been specially constructed to breach your network. Obviously, it's not hard to see why we're rejecting those. No upstanding netizen has any use for those sorts of packets.

The last three rules should look familiar to you ”they're the rules that are already running on your firewall. They still do the same thing.

Blocking Specific Ports

You can add additional rules to kill specific services on your firewall. A rule like

  ipchains -A input -p tcp -i eth1 -s 0.0.0.0/0 21 -l -j REJECT

will deny any port 21 (FTP) packets that try to come in via eth1. This will also kill your outgoing FTP connections, since it's going to terminate any incoming FTP data. Basically, you'll make an FTP connection out, but all replies from the remote server will be rejected (and logged) by the firewall.

"Gee Whiz, Wally, I can't block only incoming FTP packets?" Nope, Beav, you can't. But that's not such a big deal, unless you insist on running an FTP server on your firewall ”which you should not be doing. The preceding rule isn't necessary in 99.9% of network setups. If you don't have it, and the firewall isn't running ftpd , those FTP request packets won't do anything. Why? Basically, the FTP request will come into your firewall, but since there are no forwarding rules set up for FTP (see the next section, Port Forwarding ) and your firewall doesn't have any software running on port 21, the packet is denied . A really clever attacker might try stuffed routing to get past this, but well, we already blocked stuffed routing.)

Where the per-port rules come in handy is in blocking your internal users from doing specific things. You may not want them to be able to use Gopher (port 70) or Usenet News (port 119). You may want to block AIM (AOL Instant Messenger), but it really can't be done. The programmers at AOL thought of you already, and they've built in the ability to use all the common ports that people don't dare block (like port 80 for www and port 25 for smtp). Simply set your user 's PC speakers on maximum, and run around pummeling anyone whose machine generates the AIM login sound.

You can also block the ports that backdoor software might use, like the cDc's BackOrifice program. Of course, since BO2K doesn't have a default port (the old version uses 31337 as the default port), you're going to end up blocking a lot of ports. It'd probably be easier just to alter your first three rules so that you're allowing only a few services and blocking all others. Remember to leave icmp and the Domain Naming System (DNS) open ! Without DNS, your machines won't be able to figure out the IP address to which they should send requests.