Last time I showed you how I set up dnsmasq and OpenSSH. Now we'll take a look at setting up Shorewall. Well, actually, I've already set it up, and now I'm writing this from my notebook behind the firewall. I accidentally closed my browser the first time I was writing this tutorial, and I've lost everything I was typing in while I was actually setting up the Shorewall. Some details might be missing from this article because of that... if you notice something, or it doesn't work for you, please e-mail me using the contact form.

DISCLAIMER

I'm in no way an expert in this field. I've just started learning this stuff, so please take every piece of information found here with extreme caution, and read through the docs to verify the options I set. The solution outlined before works beautifully, but I suspect it is neither too secure or too detailed. You have been warned!

About Shorewall

So why do we use Shorewall? First of all, Shorewall is ridiculously easy to configure. Secondly, Shorewall relies on the well-tested and field-proven netfilter, a Linux kernel's packet filter. Of course, some BSD guys will laugh at Shorewall, and they are probably right about some of the laughter, but Shorewall is still a powerful tool if it is used right. Besides, BSDs have the excellent Packet Filter... :)

As I said above, Shoreline Firewall (Shorewall) is the wrapper for iptables, ipchain, and netfilter. It abstracts the complexity of those tools, and makes the configuration easier. It's not just about suiting newbies. If you cannot read your own firewall configuration, that poses a security risk in its own right. So, it's better to use a tool you can wield confidently, than use what others think is the perfect tool, and not be able to do anything with it.

That said, I will most definitely direct my attention to iptables once I'm done experimenting with Shorewall. Nice thing about it is that Shorewall is actually configuring iptables for you, so you can look over what Shorewall did to iptables for a free iptables tutorial. ;)

Installing Shorewall and basic setup

Installing Shorewall is nothing short of easy. A simple pacman -Sy shorewall is all that's needed.

Now, since we're using two interfaces, there are some sample configuration files we need to copy over to /etc/shorewall. The files we're looking for are located in /usr/share/shorewall/Samples/two-interfaces. Copy the files from there to /etc/shorewall, and open /etc/shorewall/shorewall.conf.

Near the beginning of the file, you will notice the STARTUP_ENABLED option which is probably set to "No". Leave it as it is. This option will simply prevent Shorewall from starting up at all if set to "No". It's a good idea to keep it like that until you've fully configured your firewall.

Let's first specify the log file. I've seen examples where this file was set some arbitrary files, but I could only use logging successfully when the option is set like so:

LOGFILE=/var/log/iptables.log

This file (iptables.log) is the default log file for iptables on Arch Linux. It is perfectly fine to log into this file, as far as I know. Well, actually, Shorewall doesn't do the logging. The logging itself is carried out by syslog daemon, and the iptables.log we specify via LOGFILE option is where shorewall will look for the log.

One more option we are going to change is SUBSYSLOCK which tells shorewall where to create and look for the lock file. The lock file itself tells shorewall if it is already started or not.

SUBSYSLOCK=/var/run/shorewall.lock

The name of the lock file, as well as its location, can be completely arbitrary. However, it is customary in Arch Linux that all lock files be stored in /var/run.

Now that we've set up the basics, we can move on to actually configuring our interfaces and our packet filtering rules. We will save this file now, and move on to the next one. You can set the STARTUP_ENABLED flag to "Yes" at this point, but I will not do so for more or less obvious reasons.

Configuring the interfaces and SNAT

Configuration of interfaces tells shorewall what interface belongs to what zone. Zones are what we are dealing with most of the time because Shorewall is a connection-oriented firewall, and the rules are set based on connections that are made from one zone to the other. In our case, eth0 is where the machine on the LAN are connecting, so it will be named "loc" (local). The eht1 interface connects the gateway to the modem (and therefrom to WAN), so it will be labeled "net". Open the /etc/shorewall/interfaces file, and edit it like so:

net     eth1            detect          dhcp,tcpflags,routefilter,nosmurfs,logmartians
loc     eth0            detect          dhcp,tcpflags,nosmurfs

Note that the loc interface must contain "dhcp" in the list of options in the last column. Okay, so this defines two out of three zones. Where's the third one? Well, the third one is "here". That is, the third one is the gateway itself. In rules file, you will refer to the first two zones by "loc" and "net", and the Firewall will have an alias of "$FW".

Next we will set up IP masquerading. Because machines on our LAN have IP addresses in the 10.x.x.x range which is also called Class A non-routable range defined in a document called "RFC 1918", the source IP for packets originating from those machines cannot be routed by Internet backbone routers. Well, they could route them, techinically... but they won't, because that's the rule. This means that there can be any number of networks that use the same IP range from Class A (B, or C) as per RFC 1918, but in order for machines on the LANs that use the IP ranges to be able to communicate with hosts on the Internet, the source IP has to be dynamically rewritten into routable ones. This is typically the job of the gateway, and the procedure is called NATing (Network Address Translation), or, more precisely, SNATing (Source Network Address Translation).

We set up SNATing using the file /etc/shorewall/masq. Our case is fairly simple, where the source IP of machines on our LAN must be rewritten for the WAN-side interface. LAN interface is eth0, so the source interface is that one. eth1 is the WAN-side interface. Open the file, and edit it so it looks like this:

#INTERFACE              SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK
eth1                    eth0

This will enable IP masquerading, and the firewall configuration will now involve the very meat of firewalling: rules and policies.

Rules and policies

The main piece of firewall configuration in Shorewall is the /etc/shorewall/rules file. Shorewall looks there first to see if a packet is dealt with in the file. If the file doesn't cover this particular connection, Shorewall will refer to policies (more general rules) and determin if the connection will be rejected or allowed.

The policy file is fairly simple. We have three zones, and we deal with different combinations of all three and the default rules for connection for each combination. Since I wanted my firewall to be as strict as possible, I've set all connections except net -> others to REJECT. I've also left the default of net -> others DROP. Open the file /etc/shorewall/rules and familiarize yourself with it. It is fairly straightforward so I will not waste time on it here.

The next thing we do is open the /etc/shorewall/rules and set up some rules. For starters, let's allow SSH connections to the host. So, add the following rule:

ACCEPT  loc  $FW  tcp  2990

Replace 2990 with the port number your SSH daemon will be listening on. With this rule, you should be able to access your gateway system using SSH.

Now to allow the hosts on the LAN to access the Internet, you need this:

Web/ACCEPT  loc  net
DNS/ACCEPT  loc  $FW

The part which says Web/ACCEPT is actually a Shorewall macro in action. Instead of writing the actual protocol and port number, we have a number of those macros which are just a shorthand version of the full rules. The list of all the macros can be obtained by issuing the following command:

shorewall show macros

Take a look at the list and configure connections you need. Remember we set up dnsmasq on this gateway? So now we must allow hosts on the LAN to do a DHCP query to the firewall. The second line above will allow that. That's a macro right there, you're right.

With these rules in place, you can now go back to /etc/shorewall/shorewall.conf, and change the STARTUP_ENABLED flag to "Yes". The firewall is now configured and ready for deployment. Issue the following command to start it up:

/etc/rc.d/shorewall start

If you get an error message, type shorewall start and see what it tells you. Fix the problems and try again. After this, you should be able to ssh into your gateway, and access the Internet with your web browser.

Next time, I will write about intrusion detection software, network monitoring, and other security tools to further secure the gateway.