Blog

Building a firewall for the first time: Part 1

Many of us in the security field have been working with firewalls for so long that we forget that it’s still a new topic for many administrators.  If you’ve never built a firewall before – don’t worry – we’ll go over the process, step by step, and show you how it’s done so you can do it yourself.

Basic concepts – the bouncer

A firewall is a piece of software or hardware that sits between your servers and the rest of the machines on the Internet.  For every conversation between one of your servers and another external machine, the firewall has to decide: should this be allowed to proceed, or should it be blocked?

A firewall is much like a bouncer at a bar, who applies different rules to people entering and exiting a building. Let’s start with the rules for people trying to exit the building:

(People going out)
OUT1: If someone is trying to leave the building, let them go.

That’s it – very simple.  Whenever someone tries to leave the bar, we start at the top of the list, see that the person leaving matches the “trying to go from the inside to the outside” part, and take the action listed at the end: “let them go”.

OK, how about for people trying to enter the bar?  Let’s organize these rules in a separate list, since anyone approaching the bouncer is either exiting or entering the building, but never both at the same time:

(People coming in)
IN1: If someone is trying to go from the outside to the inside and they’re drunk, block them from entering.
IN2: If someone is trying to go from the outside to the inside and they’re carrying automatic weapons, block them from entering and call the police.
IN3: If someone is trying to go from the outside to the inside and they’re 21 or over, let them in.
IN4: If someone is trying to go from the outside to the inside, block them from entering.

Here we have a couple more things to check; are they coming in, are they drunk, are they carrying weapons, and are they at least 21.  One of the confusing parts is that someone could match more than one of these; what do we do with Karl, who is over 21 and is carrying a submachine gun?  The second rule says to block him and call the police, the third rule says to let him in.

Here’s where we use the order of the rules.  For every person coming in, we start at the top of the list and see if they match the first rule.  Karl isn’t drunk, so we skip rule IN1.  He is carrying an automatic weapon, so we block him and call the police.  At that point we stop looking through the list; we’ve found a match and stop.

If Melissa, just behind Karl in line, isn’t drunk (so we skip IN1), isn’t carrying automatic weapons (so we skip IN2), and is 19 (so we skip IN3), we land on IN4 and block her from entering.  IN4, the last rule in the list, is and should be a catch-all; what do we do with anything not caught in previous rules.  The formal term in firewalls is a “default policy”, and each list of rules needs one at the bottom.

So how does this apply to network firewalls, looking at packets flying by on the network?  At a practical level, firewalls do essentially the same thing.  There are conversations that start on the protected system heading out to the Internet, and there are conversations that start on the Internet coming in to our protected servers.  We need to decide which outbound conversations should be permitted and which should be denied, and which inbound conversations should be permitted and which should be denied.  Our job as firewall designers is to think up rules like the 5 we created above for our bouncer, and hand them off to the firewall that actually allows or blocks packets based on our rules.

Building a set of firewall rules

Let’s walk through a typical example first.  Lets say you have an Apache web server with a back end MySQL database.  You manage it over SSH.  It needs to be able to pull down software updates.  How would we create a rules for this system?

First, let’s decide which types of traffic are coming in to the system from the Internet (we’ll group those under Inbound), and which types are going out to the Internet (we’ll group those under Outbound).
Inbound:
– People making HTTP requests to the web service on this machine.
– People making sql queries to the sql service on this machine.
– People connecting up via ssh for remote access to this machine.

Outbound:
– Pulling down software updates.
That’s most of it right there, with 1 exception: dns lookups.  If your copy of Apache looks up the name of every http client so the logs show hostnames instead of IP addresses, this machine needs to make outbound DNS queries.  Our Outbound list really should include that:

Outbound:
– Pulling down software updates.
– Outbound dns queries

When we did the bouncer example, we had a set of checks to perform, and for each one we had an action to take (let them in, block them or block them and call the police).  We need to do the same here; for each of the types of traffic listed above, do we allow the traffic or block it?  These are called ALLOW and DROP in the firewall world, so we’ll use those terms here.  There’s a third less commonly used option called REJECT that still blocks the conversation but sends back a network error message to the sender.

First, this is a public web server, so we really want to ALLOW incoming web traffic.

The SQL server, on the other hand, holds a lot of sensitive data and I really don’t want people to making queries of it directly; they should be using the web scripts I’ve provided.  So I want to ALLOW the web server software to make queries, but I want to DROP requests from everyone else.

I want to ALLOW incoming ssh, but not to everybody.  Ideally, I’d like to restrict it to just the few computers used by the sysadmin team.

Other than the things I’ve mentioned above, I want to block everything else coming in from the Internet.

Now let’s look at the Outbound traffic.  I do want to ALLOW the outbound connections needed to pull down software updates.  I also want to ALLOW outbound DNS queries.  Those are the only two types I want to allow Outbound – everything else will be blocked.

So let’s look at our rules again.  I’ll add the port numbers needed to make these happen in parentheses.  The more commonly used port numbers are already set up for you in the Halo portal; we’ll look at how to find rarer ones in a future blog.

Inbound:
– People coming from the Internet making HTTP requests (TCP port 80 and TCP port 443) to the web service on this machine: ALLOW
– The Apache web server making sql queries (TCP port 3306) to the sql service on this machine: ALLOW
– People coming from the Internet making sql queries (TCP port 3306) to the sql service on this machine: DROP
– People coming from just a few IP addresses connecting up via ssh (TCP port 22) for remote access to this machine: ALLOW
– All other connections from the Internet to this machine: DROP

Outbound:
– This machine going out to the Internet pulling down software updates (TCP ports 80 and 443): ALLOW
– This machine going out to the Internet making dns queries (UDP port 53 and TCP port 53): ALLOW
– All other connections from this machine to the Internet: DROP

At this point we’ve really covered the major functional rules in a firewall.  All that’s left is to put it in a form that can be handed down to the Linux kernel.

In our next blog, we’ll look at how to set up a firewall policy and apply it to a group of machines.

Stay up to date

Get the latest news and tips on protecting critical business assets.

Related Posts