Rules for building a Firewall

This article is not for the masses, is not about the configuration of personal firewalls as XP and Zone Alarm. If you are considering setting up a firewall to protect your network, the article would be something for you.


Building firewall rules

All firewalls configured can be weak than they need to be, giving hackers and others the opportunities that should not be present. Indeed, it is relatively frequently encountered that firewalls may not be outright failures to be configured but can easily be tightened up without jeopardizing the ability of users to use their programs and go online. Generally speaking, the longer a firewall has been in operation, the more loose ends will be there potentially. You should review/consider your settings regularly.

The following article is an examination of the considerations and options that should be reviewed when its firewall rules are set up, and again before we examine settings again.


Inbound and outbound Settings

Most consider a firewall as something to protect their computer or network from any use to access it, so the incoming rules attached the greatest importance. Eg. Windows XP's built-in firewall. It contains only inbound filtering and allows all outgoing traffic. The firewall in Vista includes both, but by default only the input filter configured. A step in the right direction but not enough. This is a critical mistake in my eyes that makes both XP's and Vista's firewalls usefulness limited. Firewall is to provide security against viruses and worms entering the machine initially, but the infected machine by other means (email or infected files and documents), your machine could spread both viruses and worms without restriction. Security from hackers is also more limited than if there had been a reasonable outbound rules.

The reason for outbound rules are at least as important as depth to be found in the way hackers and worms often works. A vulnerability in your system is exploited through an exploit to get your machine to connect itself to the attacker's machine, after which the attacker retrieves the necessary tools for your machine. Often, the attacker could use Internet Explorer to retrieve data and tools with it, or browser, is available on most systems. If the attacker "only" have access to a command prompt (ie he can write text commands to/with your computer), he will be able to use ordinary FTP commands, and connect to its FTP server. In other words it is not the attacker who breaks in, but him taking your machine to break out if there had been set reasonable outbound rules, this traffic may have been stopped at the firewall and attack disapproved.


Close gaps or Open holes

Again, we get something really basic. Should we start allowing everything so it is easy for both users and administrator, and then close the dangerous gaps? Or will it start to close everything and then open it absolutely necessary? Microsoft has for years followed the first principle in order to facilitate ease of use, but there is no doubt that the security is much better to start with that is out entirely and then just open it when it is positively necessary and reasonable. Make a positive list of what users need, and allow this, instead of a negative list of what they should not.


Rules order

The order of a firewall's list of rules is very important, you can create inappropriate and genuine mistake, if you do not think very closely. The errors occur very often when the rules are added later or moved around the rules, probably because you do not have as good overview of all rules, which were since the first time settings.

This problem occurs because the traffic handled by the first rule to match, and thus not necessarily the best rule. Basically there are two "things" you can follow. You should always put the most specific rules first and least specific last, and you can then choose between firewall prioritize applications' performance or latency. If you place the most frequently used rules first, you will optimize the rulebook to firewall performance. If you place the rules that "serve" the most important applications, that will optimize the applications. Often you can combine the two, since it is always essential to check that you have not made a hole for yourselves by placing a less specific rule before a more specific.

A relevant example could, for example, be that you have made a specific rule which allows only your DNS server to access the IP address of your external DNS server that is only on port 53. Later you discover that the rule that all your machines must access everything on port 80, used all the time, so you move it up first in the rulebook. You have now created a hole in your rules, because your DNS server can now access everything on port 80 and it will not, of course, a DNS server will not surf the net, and if it does, something is seriously wrong. Note that an attacker has control of it and might have used the browser to download the tools up.

Inbound rules

What we need to allow much depends on what type of firewall we have. A packet filtering router is not as intelligent as a stateful firewall, which in turn are not as intelligent as a stateful inspection firewall. I therefore have to divide the reflection on the type of firewall we are talking about.


General idea for all types

Besides the type of firewall, there are two areas we should look at when we consider the incoming traffic. First, the traffic coming out from entering the services we offer, for example retrieve web pages from our web server, download files from our ftp server or deliver messages to our mailserver. And secondly, the traffic to enter through the firewall in response to something that is asked from within, for example a user who wants to see a web page from a foreign web server.


Packet filtering router

We need to open the gates to the services we offer on our network. For example port 80 on our web server and port 25 to our mail server, but it is perhaps not necessary in general to open to all incoming traffic on these ports. Maybe we can be content to allow traffic on port 80, specifically to our web server, so you can not access for example mail server or any workstation on port 80. Same is true for other ports.

Once we have narrowed the permissions so that you can only access the systems through the gate we want, let us look at who we want to allow connections from.
Eg. there is no reason to allow connections coming from internal IP addresses if they come from outside. It may sound as if that sort should not be possible, but it does often. These compounds are either spoofed IP addresses or misconfigured NAT devices. Internal loopback IP address (127.0.0.1) is not allocated/reserved IP addresses (see here which is reserved http://www.iana.org/assignments/ipv4-address-space) and IP addresses from areas which come very bad (see top 10 Internet Storm Center on http://isc.sans.org/top10.php) should not be allowed access from the outside. Consider always the permit that may specify and hence tighter over. (above address is an example of what should be prohibited because it would require more favorable configuration to allow the addresses to be entering). Antispoofing is the only place in the rulebook where it departs from the principle of banning everything and allow the necessary.

Then we need to make sure that the answers to our questions from within can come back. Here we run into the problem that a packet filtering router can not keep state ("to maintain state", meaning "track" the link between each outgoing and incoming packets, and keep track of the correlation between query and answers), so we have to open all the so-called ephemeral ports, ie. ports over 1023. It is such that when a user eg. want to open www.(example).org in his browser, then sent a request on port 80 but the reply port, for example 25000 (reply port is chosen randomly among ports greater than 1023).


Stateful router/firewall

The same principles and considerations which we used for packet filtering router is also true for a stateful router/firewall, but the gates to be opened to allow responses to requests to return, handled much more intelligently when we use stateful filtering. Instead of opening all ports above 1023, the firewall in the way that all queries recorded in a "state table". When a packet that attempts to enter through the firewall, this will make a lookup in its state table to see if this package is a response to a previous question. If the firewall positively identify the package as belonging to a previous question, it will open the gate for this one package at the moment the pass and then close the gate again. That is, a much smaller gap than what we have to open a packet filtering router.


Stateful Inspection Firewall

With stateful inspection, it will be again more intelligent. A firewall is only stateful, using the information listed in packet header to see whether there is a packet belonging to another package or pertaining to a response to a previous question and it will in most cases be enough to decide things. However, there are some records where you have to look in the data content to see that there actually is a package belonging to a previously sent query. Such a package would be a stateful firewall that be dropped while a stateful inspection firewall can handle it and shut it through.

ICMP protocol is used, inter alias, to ping, but it is also (perhaps even most) to provide error messages to a temporary error situations online. If a user on your network eg. want to open www.(example).org's browser and this page is down, the last router along the way could not deliver the query to the server containing the web page. Instead, the router will send a "ICMP host unreachable" packet back to the user on your network. When this packet frames your firewall, a stateful firewall to see a packet coming from a router which of course can not find any query to match, because the user requested a web page. Is the firewall is a stateful inspection firewall, this known ICMP protocol know it to look in the package containing the data to see what communications packages actually answers. ICMP package will be closed in, and the user will get to know your server is down. Had only been stateful firewall, the connection would remain open and the browser would have waited to reply until the connection timed out.

Outbound rules

The outbound rules are as I said, are relatively neglected area and there are many who assume the attitude that everything should be allowed inside and out, it is the internal users who sit on the inside of the network, so it is not dangerous so they can go with everything and it gives too many problems to start to close everything.

My advice is to start again to close all, then opened to what is necessary. If your users to browse the Internet, for example need to open port 80, start by opening up port 80, but allow only those client IP addresses you actually use on your network to communicate through the port. For example, no reason for your file and print server can go online, but why should it? Your mail server does not need to go online via port 80 and if it does, there is probably something wrong. Port 53 is used for name lookup and resolution between the www names and IP addresses. The safest is to have an internal DNS server that clients can make names (DNS) lookup on. This DNS server, and it alone, should then be allowed to communicate with an external DNS server via TCP and UDP on port 53 and it is important that you only allow communication from your DNS server's IP address to the external DNS server's IP address port 35 (TCP and UDP).

If you have a small home network without a DNS server, you should set up rules so that only your client IP addresses can communicate with the primary and secondary providers DNS servers IP addresses on port 53 (TCP and UDP) and nothing else.


Your thinking matters

Even the most expensive firewall provides no security if it is not properly configured and if you think you may threaten you to make rules which provide opportunities that do not have to be present and which can be exploited by a smart attacker.

1. Always start with everything closed and turned off.
   
   
2. Place the most specific rules before the less specific rules, and you think about before you alter the order.
   
   
3. Give the only authorized source of the IP addresses on your network absolutely and must use permit and only with the ports that is needed.
   
   
4. Give only permit entry to IP addresses outside of the gates, and there should be in, filter from the rest.
   
   
5. If you can restrict permission for certain IP addresses of outbound destinations, certain source IP addresses in detail on specific ports, with TCP or UDP, and nothing else, do it.

Follow the above principles first, that only the most necessary come in and that you have a good Internet. Nearby there emits spoofed packets and more.