Comment goes here
You should log in and post some comments! The link is up there in the toolbar. Go nuts!
 

Shorewall: Your Friendly Firewall (Part 1: Installation and Basic Configuration)

I received a request to write about how to configure Shorewall, I'll be honest...I was kind of afraid to look into it actually. The website wasn't exactly clean, and the documentation is lacking the "we're helpful to newcomers"...basically the idea I got from them before using the software is this: we're going to push you into the water, hope you can swim.

With that said, I'm not going to proclaim to be a guru with Shorewall, I still prefer to write iptables rules manually. However, this is a nice piece of front-end software that makes managing and configuring a firewall pretty simple...ish. As with most of my articles here on Linux.org, there are some assumptions:
  • You are installing Shorewall on a dedicated machine with a single NIC (I did this on a virtual machine)
  • You know at least basic networking (i.e.: what a DMZ is, the functions of passive and restrictive firewalls, etc...)
  • You have Shorewall installed and ready to be configured
  • You understand that what is provided in this series is not de-facto, but is instead one man's intent to provide some actual assistance on the matter
  • You know how to use your favorite terminal editor as I know most don't fancy the nano over vim

Got all of that? Then let's continue!

Where To Start?
Most guides I've seen tell you to automatically tell Shorewall to start on boot. This is probably the worst thing you can do when configuring a firewall, in my opinion. Doing this you can easily lock yourself out of the system, and if you're configuring the firewall remotely (i.e.: over SSH), you just might be in for a very, VERY long night. Instead, we'll hold off on that for a minute, and plan out our network.

Our way of living will consist of this:
  • Firewall (virtual machine)
  • WAN (Internet)

This will mean no DMZ, which simplifies this quite a bit. There's no LAN for this guide because it overly complicates things for an introduction article. However, that will be covered later. So, lets get started by doing this:

nano /etc/shorewall/zones
 Know how iptables operates in chains and tables? Well, Shorewall operates in zones, which is essentially chains. But, Shorewall makes it easy by allowing free reign on the name, so if you feel like naming the local network zone "BillyEatsLeaves", well then, by all means. Why don't we pick something a little bit easier to manage, however? Inside the file, have these lines:
fw firewall
net ipv4
 Here we specify the zone names and what they stand for in Shorewall. We have the firewall zone (fw), also known as our local host, which we tell Shorewall is our firewall chain. Then we have net, which operates on IPv4 and is our Internet chain Easy enough, right? Save that file, but make note of the zones.

Telling Shorewall What Goes Where
So we have our zones set up. What does it have to do with our network? Well, right now, nothing. But, remember that prequisite of one NIC? Well, now you know why.

In order to make Shorewall care (or even aware) of what zone is for what adapter, we need to edit /etc/shorewall/interfaces:
# cat /etc/shorewall/interfaces FORMAT 2 net eth0 dhcp,tcpflags,logmartians,nosmurfs
 "FORMAT" is specified to tell Shorewall that we aren't using the outdated original format of the interfaces file. Simple enough.

The next line takes a little bit more explaining, so I'll do it piece by piece:
  • net - The zone that the interface is associated with
  • eth0 - The NIC (see ip addr or ifconfig) that the zone will be associated with (virtual adapters [i.e.: eth0:0] are NOT supported)
  • dhcp - Set this option if DHCP is involvd at all on the network, no matter how deep into your network it is
  • tcpflags - Simply put: filters out packets with illegal TCP flag settings
  • logmartians - Logs packets with source addresses that are illegal/impossible (helps fight spoofing and detection attacks)
  • nosmurfs - Logs requests sent with the broadcast address as the source (generally helpful to keep enabled)


It might be a good idea to put this into better perspective now. Shorewall, when started, will load the zone assigned to the firewall (in this case "fw") into $FW, which can be used (and will be) throughout the rest of the configuration files. Similarly, this stores the interface "eth0" into the zone 'net', but instead of referencing it via net or similar, you just call it by the zone, which you see demonstrated next.

Rules
Shorewall separates the process of network flow into two separate processes: rules and policies. The Shorewall document teaches you about the policies first then rules, but I feel it's kind of defeating the purpose. Instead, we'll look at the various rules right now.

In iptables, you can have various rules in place for various TCP statuses (established, related, new, etc...). This is done by either the "-m state --state " or "-conntrack state --ctstate " argument. In Shorewall, they're organized by sections: ALL, ESTABLISHED, RELATED and NEW. Typically established has an accept all rule as it basically says "If a packet has already passed the firewall, don't bother." So, we'll focus on the NEW section instead, which is when connections are trying to get established on the firewall.

We'll add two rules to the NEW section:
# cat /etc/shorewall/rules SECTION NEW DROP net $FW icmp 8 ACCEPT $FW net icmp
 There's an easier way to write rules (usually), but we'll cover that in the next chapter. But lets go over this.

The first line tells us that we are working with fresh connection requests. The second line is saying that we want to DROP all ping (8/icmp) packets coming from the Internet into our firewall, lastly we will accept/allow all ICMP traffic going from our firewall to the Internet.

As a crash course into creating rules, this is a good place to start. Next, we'll touch on policies.


Policies
Basically after this, we're done with the beginner tutorial. Cool, huh? Just remember that rules are processed before policies.

Policies themselves are easy to manage and write, as they are last to be ran. Lets do some simple stuff here, and make our firewall restrictive!
cat /etc/shorewall/policy $FW net ACCEPT net all DROP info all all DROP info
 The basic format of a policy line is: SOURCE DESTINATION POLICY LOG_LEVEL LIMIT:BURST

Following that, we'll run through this line by line:
  • Accept (allow) all outgoing packets (from firewall to Internet)
  • Drop all packets going from the Internet to anywhere (i.e.: Internet to the firewall)
  • Drop any packets that don't match any other rules/zones/policies/etc... (this MUST be last, as it's a catch-all)

Log level acts on 7 different levels, info is level 4 and provides good enough information. So we'll stick with this for now. "LIMIT:BURST" matches the logging and basically tells Shorewall to log : amount of records of a single IP that matches this rule, similar to the limit/burst feature of iptables.


The Shorewall document says to set the last policy/action to REJECT instead, but here's the reason why I dislike REJECT: it lets the person sending the request know it's being filtered. It's the sadistic side of me that loves making a hacker question if the port is open and firewalled (REJECT) or simply not available period (DROP).

Conclusion
There's not a whole lot to get this up and running, and the documentation makes it a lot more convoluted than it actually is. Next guide will focus on diving more into it, but this is a good starter course.

Now, run this command:
# shorewall check
 If you see the message "Shorewall configuration verified", you're good to go! Just make sure you disable your current firewall (conflicts can definitely arise), such as iptables, and run Shorewall: shorewall start

If all goes well, you should be able to ping out from the firewall, but not be able to ping the firewall. Enjoy!