Life, Football, Technology and Vespas…

Shorewall for Dummies

If IPtables is too daunting for you, then shorewall is probably the easiest way to setup and maintain an iptables based firewall on Linux. Let me go through the basics.

Interfaces & Zones

Shorewall builds some intelligence into your firewall thinking. Networks can be considered as ‘zones’ – i.e. your internet interface (ppp0) could be your ‘web’ zone and your internal network could be considered as your ‘int’ zone. I do not know why shorewall only allows 3 letter zone names… but that is not relevant here.

So –  what I am doing is setting up a basic internet sharing firewall. It has 2 zones (web & int) for WWW and internal network. first thing, setup up your interfaces file:

# vi /etc/shorewall/interfaces
#ZONE   INTERFACE       BROADCAST       OPTIONS
web     ppp+            -               dhcp,upnp
int     eth0

Here are my 2 zones – my dialup interface (ppp) and my internal network (eth0). The ‘+’ in ppp+ simply means it is a wildcard (ppp0,ppp1…etc). I have specified dhcp in my options to indicate that this interface gets it’s ipaddress dynamically. See man shorewall-interfaces for more information on interfaces.

For this example – /etc/shorewall/zones is very basic. Unless you are doing IPSEC tunnelling or any other fancy stuff, you can input the following:

# vi /etc/shorewall/zones
#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
web     -
int     -

You see that there are three zones in the zones file. The third one is a zone for the firewall itself.

Policies

This is where Shorewall makes some sense over other firewalls. Instead of having millions of rules from one zone to another, you can simply specifiy a policy for communication between entire zones. You need not have a separate rules in addition like some firewalls do – Juniper. Here I have setup two policies that allow the Firewall to get to the other zones:

# vi /etc/shorewall/policy
#SOURCE DEST POLICY LOG LIMIT CONNECTLIMIT
$FW     web     ACCEPT
$FW     int     ACCEPT

I then want to ensure that the internal zone (int) can get out to the internet (web) and I want to be able to administrate the firewall from my internal zone from any of my internal machines. You may not want the second policy, but I am just putting it in as an example.

int     web    ACCEPT
int     $FW    ACCEPT

I then want to implement a default drop policy for internet traffic (web) to the firewall or my internal network and it’s a good idea to have a reject ALL ALL rule at the end.

web     all     ACCEPT
all     all     ACCEPT

So now you have default policies based on your zones. You do not need to manage individual rules for inter-zone traffic.

Masquarade / NAT

Ok this is the part that makes your internet connection sharing work. Effectively what you want to do is have all your internal machines route through you firewall. To do this, you must NAT your internal traffic to your internet interface on your firewall. Shorewall makes this so simple. One line:

# vi /etc/shorewall/masq
eth0     192.168.2.0/24     detect

Done. Restart the service – /etc/init.d/shorewall restart. You now have internet sharing for your internal network users through your linux firewall.

The last thing that you may want to do is to have traffic from the web reach a particular machine in the network. For example, you may have a web server on your internal network that want to be accessible from the internet – this simple rule will allow traffic to be forwarded from the firewall to the correct machine on the internal network:

# vi /etc/shorewall/rules
DNAT     web     int:192.168.2.100     tcp     80,443

The rule implements allows traffic from the internet (web) to the internal network machine – 192.168.2.100 on tcp ports 80 and 443.

That is really just a basic introduction to shorewall. To see the syntax of any of the shorewall the man pages are accessible as follows:

# man shorewall-rules
Advertisements

One response

  1. anon

    You may want to revisit the last couple of policy lines. I believe they should read REJECT or DROP at the end rather than ACCEPT 😉

    August 10, 2010 at 10:21 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s