Copyright (c) 2000 Brad Marshall.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections , with no Front-Cover Texts and with no Back-Cover Texts. A copy of the license is available at http://www.gnu.org/copyleft/fdl.html.

In this article we'll cover some of the design decisions that have to be made before creating a firewall, from architecture of the firewall to various decisions that need to be made.

Before we start delving into the depths of firewall design, first we need to figure out what a firewall is. A firewall is a device of some kind that seperates and protects your network - in most cases, from the Internet. It can restrict traffic to only what is acceptable to you, and allows monitoring to see what is happening.

An important thing to remember about firewalls is that they enforce a security policy by allowing a single point for security decisions to be made. They also limit your exposure to the internet, and allow you to log traffic.

However, they are many things firewalls can't do. They can't protect against malicious insiders - if someone wants to copy your data onto a disk and walk out with it, the best firewall in the world can do nothing about it. Similarly to this, they also can't protect connections that don't pass though them - if someone has a dialout modem, there is nothing the firewall can do to protect this connection. And, perhaps most importantly, they can't set themselves up - all firewalls need some measure of configuration, and all networks are at the very least slightly different. A misconfigured firewall may give you an illusion of security, which might entice you to act as if you're protected when you really aren't.

The first step towards figuring out what you want your firewall to do is figure out what you are protecting. In general, there are 3 main things you may want to consider - your data, your resources, and your reputation.

Data has a few aspects you may wish to consider - secrecy, integrity, and availability. You might have some confidential data you wish to keep from your competition, or just generally don't want other people to know about - an example of this is financial data. Or you might have some data you don't care about keeping secret but you don't want changed. The last case is ensuring the data is available to you when you require it. It is useful to be able to distinguish what category your data falls in, so you can protect it appropriately.

Next comes resources - you'll want to protect your computer so only people you want to allow can use them. A typical case made by crackers is that the computer wasn't going to be doing anything anyway, so someone may as well use it. This is rarely true, and, if it is it doesn't really matter. If you have a computer you just want to leave idle, thats your choice. Or you might just about to be starting some job that will require each and every bit of CPU power and disk space you have.

Finally, we have reputation. If someone hacks your computer, and uses it to hack into someone elses it is your reputation that suffers, and it is you that it will be traced back to. In a company situation, loss of reputation can be almost as bad as loss of data - people need to trust who they are dealing with.

So, where does this leave us? We've discussed what you want to protect, now we need to talk about how we are going to protect it. There are a few generally accepted models that people use, some of more use in some situation than others.

First, there is no security - perhaps you feel safe just installing the operating system and applications, and just making it available as is - generally, this is considered a bad idea. Next is security though obscurity - the view that if nobody knows about it, nobody will hack it. With the ease in which people can automatically scan huge sections of the internet, in some ways using this as your only bit of security is obviously not a good idea.

The next two models are much more useful - host based security, and network security. The idea of host based security is to protect yourself by securing machines on a host by host basis, and remove any security problems on that particular host. This is very useful on servers, for example, but don't scale well to large, diverse networks. Network security takes the view of controlling network access to your network, by building firewalls, using encryption to protect sensitive data, and the like. This allows you to protect many machines by a single firewall.

The important thing to remember is that no security model can do it all. There will always be things that need to be taken care of by other means, such as management. Security is not an absolute - you can increase it to make it difficult to break in, but there is always a trade off, be it in convience, or cost. In general, it means you have to weigh up risk versus reward of a particular model in your situation.

There are a few different types of firewalls that you can use, each of which imposes a different type of architechure on your network. The standard type that many of you will know about is packet filtering firewalls - these work by routing packets between networks, selectively controlling the data that is allowed though. This type of firewall is implemented using ipchains or iptables, and works by specifying rules that say what services are allowed, and what is denied. Packet filtering is widely available, quite efficient to implement, and helps protect an entire network, but reduces router performance, and can sometimes be hard to configuree.

Proxy services, or application level gateways work by taking requests from clients, deciding if the client has authorisation to perform the action, and then connects to the destination server on the clients behalf. They are useful because they can perform logging of actions that you wouldn't otherwise get, and can provide user level authentication, which is impossible to do with a packet filtering firewall. Additionally, some proxies perform caching by keeping a local copy of the data, which can increase performance dramtically in some cases - the best example of this is a web proxy. However, there are some disadvantages to using proxy servers. You may require a different proxy server for each service you wish to proxy, as the server has to understand the protocol it will be proxying. Proxy servers also lag behind - when a new service is introduced there may be some time before a proxy server that can handle it becomes available, dependant on how suitable the service is for proxying, and how popular they are.

Next we have Network Address Translation, or NAT. Most of you will know of IP masquerading, which is a limited form of NAT. NAT takes internal addresses and changes, or translates them to an external address that can reach the service you desire. By using this form of firewalling, you can ensure control over outgoing connections, as the internal network can't reach outside without using it. Additionally, it gives good control over access to the internal network, as there are no direct connections available through this type of firewall. However, not every protocol works with NAT, as some rely on state information that is not passed though. Under Linux, there are IP masquerading modules that allow some of these protocols to work, but you require a module for each protocol of this type. NAT also interfers with logging - an entire network can appear to be coming from one address, which makes it hard to work out who's done what.

Now we'll talk about different security strategies that you may have heard about, and discuss some of the advantages you can gain from understanding them.

Possibly the most important thing to realise is it is important to have a fail safe firewall - this means, if it fails, it fails in a safe way. Of course, failing in a safe way means different things to different environments, but, in a firewall environment, it generally makes sense to deny access to the service.

This relates to setting default policies on firewalls - to keep in line with the fail safe method, it would be considered sensible to have a default of deny. This gives you the advantage of the firewall only allowing though traffic that you specifically have let though, presumeably because you have reviewed it and considered the risk of running the service to be outweighted by the benefit it provides. This also reduces the risk that you will be attacked by some protocol or service you have never heard of, or one that you don't need to run that has recently been found vunerable. The other option is default of allow - this means that you explicitly list what you don't want. The disadvantages of this should be obvious - you end up playing catch up to any new service the users want to use that has security ramifications.

Another stratgey is that of least privilege. This means giving the least amount of privilege to the user, service or whatever that it absolutely needs to run - for example, services shouldn't run as root unless they absolutely need to be. This also carries across to administration - you should never do anything as a more privileged user than it needs. This means, for example, you should only use root when you have to. This is important because it limits your exposure, and it also limits the amount of damage that can be done - the difference between a hacker getting access to an unpriviliged user such as nobody, and getting access to root is huge.

A chain is only as strong as its weakest link, and this is certainly true in security as well. It is important to know where the weakest link is in your defences, and to ensure that the risk involved is acceptable. Knowing where your weak link is means you can either take steps to secure it, or if the risk isn't high enough, to monitor it carefully.

A firewall is also a choke point - all your traffic should be going though this one point, so you can defend against attacks, and also monitor and respond to any incidents. The alternative to having a choke point is to have many ways into your network, and you have to pay attention to them all - the theory with having a choke point is that you can adequetly defend it, without being distracted by possible diversions.

It is important not to depend on one security mechanism, no matter how strong it is - this strategy is called defence in depth. The idea is to have multiple layers of security, each of which back each other up. While firewalls are important, it is a good idea to have multiple layers - network security (firewall), host security (especially for servers), and user security (training). This is useful to have in place because no matter how secure a firewall is, there will always be some way around it - the idea is to make it as risky and tricky as possible for the hackers to get around it. Also, this means if your first layer of defence fails for some reason - be it misconfiguration, hardware failure or whatever, you are not totally exposed to the Internet.

Closely related to this is diversity of defence, which takes it one step further than defence in depth. The idea is not only having multiple layers, but that each layer of security is a different kind. The theory behind this is simple - if the hacker has the ability to get though, for example, your packet filtering firewall putting a second one will only slow them down by a small amount. The problem with diversity of defence is that it is expensive to implement and maintain, and also increases the complexity of your firewall. Additionally, it takes a lot of care to ensure that the different layers don't have much in common. For example, there are inherent weaknesses in packet filtering, such as a previously secure protocol being used for some new attack. The other problem is that of common configuration - if the same person configures all the different layers, they could certainly all be misconfigured in the same manner. There are a lot of issues with using diversity of defence, and it is up to you as to whether the cost of implementing it is worth the reward.

As we've mentioned before, it is also important to keep things simple. This simplicity buys you a lot - if you can't understand the system, how are you sure that it is secure? Complex programs are also more likely to have bugs, or areas in which problems can hide. However, securing a system is complex - don't give up security to gain some simplicity.

Security though obscurity is another principle we've mentioned before - the idea here is to hide, or obscure the system so people don't know what they are dealing with. On the Internet, this can take a few forms - from not telling anyone that the machine is there to changing the port the service runs on from the standard one. While security though obscurity is usually disregarded as being useless, it can have a place - just be careful not to overrate it in the scheme of things.

A firewall is a very important part of protecting a network, but as you can see, there are many issues that must be considered. There are many issues here that we have only touched on.