Security Handbook/Firewalls

This section is on filtering packets. == Firewalls ==

A firewall
People often think that a firewall provides the ultimate security, but they are wrong. A firewall is also a piece of software and should be treated the same way as any other piece of software, because it is just as likely to contain bugs.

So think before implementing a firewall! Do you really need one? If you think you need one write a policy on how it should work, what type of firewall, and who should operate it. But first read this guide.

Firewalls are used for two purposes:


 * To keep users (worms/attackers) out.
 * To keep users (employees/children) in.

Basically there are three types of firewalls:


 * Packet filtering.
 * Circuit relay.
 * Application gateway.

A firewall should be a dedicated machine running no services (or as the only one) and secured the way this guide recommends it be.

Packet filtering
All network traffic is sent in the form of packets. Large amounts of traffic is split up into small packets for easy handling and then reassembled when it arrives at its destination. In the packet header every packet contains information on how and where it should be delivered. And this information is exactly what a packet filtering firewall uses. Filtering is based on:


 * Allow or disallow packets based on source/destination IP address.
 * Allow or disallow packets based on source/destination port.
 * Allow or disallow packets based on protocol.
 * Allow or disallow packets based on flags within a specific protocol.

In other words, this filtering is based on all the data within the header of a packet and not its content.

Weaknesses:


 * Address information in a packet can potentially be a bogus IP address (or as we say spoofed by the sender).
 * Data or requests within the allowed packet may contain unwanted data that the attacker can use to exploit known bugs in the services on or behind the firewall.
 * Usually single point of failure.

Advantages:


 * Simple and easy to implement.
 * Can give warnings of a possible attack before it happens (ie. by detecting port scans).
 * Good for stopping SYN attacks.

Examples of free packet filters on Linux:


 * iptables
 * nftables
 * Ipchains
 * SmoothWall

Circuit relay
A circuit level gateway is a firewall that validates connections before allowing data to be exchanged. This means that it does not simply allow or deny packets based on the packet header but determines whether the connection between both ends is valid according to configurable rules before it opens a session and allows data to be exchanged. Filtering is based on:


 * Source/destination IP address
 * Source/destination port
 * A period of time
 * Protocol
 * User
 * Password

All traffic is validated and monitored, and unwanted traffic can be dropped.

Weakness:


 * Operates at the Transport Layer and may require substantial modification of the programs that normally provide transport functions

Application gateway
The application level gateway is a proxy for applications, exchanging data with remote systems on behalf of the clients. It is kept away from the public safely behind a DMZ (De-Militarized Zone: the portion of a private network that is visible through the firewall) or a firewall allowing no connections from the outside. Filtering is based on:


 * Allow or disallow based on source/destination IP address.
 * Based on the packet's content.
 * Limiting file access based on file type or extension.

Advantages:


 * Can cache files, increasing network performance.
 * Detailed logging of all connections.
 * Scales well (some proxy servers can "share" the cached data).
 * No direct access from the outside.
 * Can even alter the packet content on the fly.

Weakness:


 * Configuration is complex.
 * Application gateways are considered to be the most secure solution since they do not have to run as root and the hosts behind them are not reachable from the Internet.

Example of a free application gateway:


 * Squid

Iptables
In order to use iptables, it must be enabled in the kernel. I have added iptables as modules (the command will load them as they are needed) and recompiled my kernel (but you may want to compile iptables in, if you intend to disable Loadable Kernel Modules as discussed previously). For more information on how to configure your kernel for iptables go to the Iptables Tutorial Chapter 5: Preparations. After you have compiled your new kernel (or while compiling the kernel), you must add the iptables command. Just and it should work.

Now test that it works by running. If this fails something is wrong and you have to check you configuration once more.

Iptables is the new and heavily improved packet filter in the Linux 2.4.x kernel. It is the successor of the previous ipchains packet filter in the Linux 2.2.x kernel. One of the major improvements is that iptables is able to perform stateful packet filtering. With stateful packet filtering it is possible to keep track of each established TCP connection.

A TCP connection consists of a series of packets containing information about source IP address, destination IP address, source port, destination port, and a sequence number so the packets can be reassembled without losing data. TCP is a connection-oriented protocol, in contrast to UDP, which is connectionless.

By examining the TCP packet header, a stateful packet filter can determine if a received TCP packet is part of an already established connection or not and decide either to accept or drop the packet.

With a stateless packet filter it is possible to fool the packet filter into accepting packets that should be dropped by manipulating the TCP packet headers. This could be done by manipulating the SYN flag or other flags in the TCP header to make a malicious packet appear to be a part of an established connection (since the packet filter itself does not do connection tracking). With stateful packet filtering it is possible to drop such packets, as they are not part of an already established connection. This will also stop the possibility of "stealth scans", a type of port scan in which the scanner sends packets with flags that are far less likely to be logged by a firewall than ordinary SYN packets.

Iptables provides several other features like NAT (Network Address Translation) and rate limiting. Rate limiting is extremely useful when trying to prevent certain DoS (Denial of Service) attacks like SYN floods.

A TCP connection is established by a so called three-way handshake. When establishing a TCP connection the client-side sends a packet to the server with the SYN flag set. When the server-side receives the SYN packet it responds by sending a SYN+ACK packet back to the client-side. When the SYN+ACK is received the client-side responds with a third ACK packet in effect acknowledging the connection.

A SYN flood attack is performed by sending the SYN packet but failing to respond to the SYN+ACK packet. The client-side can forge a packet with a fake source IP address because it does not need a reply. The server-side system will add an entry to a queue of half-open connections when it receives the SYN packet and then wait for the final ACK packet before deleting the entry from the queue. The queue has a limited number of slots and if all the slots are filled it is unable to open any further connections. If the ACK packet is not received before a specified timeout period the entry will automatically be deleted from the queue. The timeout settings vary but will typically be 30-60 seconds or even more. The client-side initiates the attack by forging a lot of SYN packets with different source IP addresses and sends them to the target IP address as fast as possible and thereby filling up the queue of half-open connections and thus preventing other clients from establishing a legitimate connection with the server.

This is where the rate limit becomes handy. It is possible to limit the rate of accepted SYN packets by using the -m limit --limit 1/s. This will limit the number of SYN packets accepted to one per second and therefore restricting the SYN flood on our resources.

Now some practical stuff!

When iptables is loaded in the kernel it has 5 hooks where you can place your rules. They are called INPUT, OUTPUT, FORWARD, PREROUTING and POSTROUTING. Each of these is called a chain and consists of a list of rules. Each rule says if the packet header looks like this, then here is what to do with the packet. If the rule does not match the packet the next rule in the chain is consulted.

You can place rules directly in the 5 main chains or create new chains and add them to as a rule to an existing chain. Iptables supports the following options:

First we will try to block all ICMP packets to our machine, just to get familiar with iptables.

Block all ICMP packets:

First we specify the chain our rule should be appended to, then the protocol of the packets to match, and finally the target. The target can be the name of a user specified chain or one of the special targets,  ,  ,  ,  , or. In this case we use, which will drop the packet without responding to the client.

Now try. You will not get any response, since iptables will drop all incoming ICMP messages. You will also not be able to ping other machines, since the ICMP reply packet will be dropped as well. Now flush the chain to get ICMP flowing again:

Now lets look at the stateful packet filtering in iptables. If we wanted to enable stateful inspection of packets incoming on eth0 we would issue the command:

This will accept any packet from an already established connection or related in the INPUT chain. And you could drop any packet that is not in the state table by issuing just before the previous command. This enables the stateful packet filtering in iptables by loading the extension "state". If you wanted to allow others to connect to your machine, you could use the flag --state NEW. Iptables contains some modules for different purposes. Some of them are:

Lets try to create a user-defined chain and apply it to one of the existing chains.

First create a new chain with one rule:

The default policy is all outgoing traffic is allowed. Incoming is dropped:

And add it to the INPUT chain:

By applying the rule to the input chain we get the policy: All outgoing packets are allowed and all incoming packets are dropped.

One can find documentation at Netfilter/iptables documentation.

Lets see a full blown example. In this case my firewall/gateway policy states:


 * Connections to the firewall are only allowed through SSH (port 22).
 * The local network should have access to HTTP, HTTPS and SSH (DNS should also be allowed).
 * ICMP traffic can contain payload and should not be allowed. Of course we have to allow some ICMP traffic.
 * Port scans should be detected and logged.
 * SYN attacks should be avoided.
 * All other traffic should be dropped and logged.

Some advice when creating a firewall:


 * 1) Create your firewall policy before implementing it.
 * 2) Keep it simple.
 * 3) Know how each protocol works (read the relevant RFC (request For comments))
 * 4) Keep in mind that a firewall is just another piece of software running as root.
 * 5) Test your firewall.

If you think that iptables is hard to understand or takes to long to setup a decent firewall you could use Shorewall. It basically uses iptables to generate firewall rules, but concentrates on rules and not specific protocols.

Squid
Squid is a very powerful proxy server. It can filter traffic based on time, regular expressions on path/URI, source and destination IP addresses, domain, browser, authenticated user name, MIME type, and port number (protocol). I probably forgot some features, but it can be hard to cover the entire list right here.

In the following example I have added a banner filter instead of a filter based on porn sites. The reason for this is that Gentoo.org should not be listed as some porn site. And I do not want to waste my time trying to find some good sites for you.

In this case, my policy states:


 * Surfing (HTTP/HTTPS) is allowed during work hours (Mon-Fri 8-17 and Sat 8-13), but if employees are here late they should work, not surf
 * Downloading files is not allowed (,, , , , , , , etc.)
 * We do not like banners, so they are filtered and replaced with a transparent gif (this is where you get creative!).
 * All other connections to and from the Internet are denied.

This is implemented in 4 easy steps:

Next fill in the files you do not want your users to download files. I have added, , , , , , , , , , , , , , , and files.

Next we add the regular expressions for identifying banners. You will probably be a lot more creative than I:

And as the last part we want this file to be displayed when a banner is removed. It is basically a half html file with a 4x4 transparent gif image.

As you can see, Squid has a lot of possibilities and it is very effective at both filtering and proxying. It can even use alternative Squid proxies to scale on very large networks. The configuration I have listed here is mostly suited for a small network with 1-20 users.

But combining the packet filter (iptables) and the application gateway (Squid) is probably the best solution, even if Squid is located somewhere safe and nobody can access it from the outside. We still need to be concerned about attacks from the inside.

Now you have to configure your clients browsers to use the proxy server. The gateway will prevent the users from having any contact with the outside unless they use the proxy.

It can also be done transparently by using iptables to forward all outbound traffic to a Squid proxy. This can be done by adding a forwarding/prerouting rule on the gateway:

We have learned that:


 * 1) A firewall can be a risk in itself. A badly configured firewall is worse than not having one at all.
 * 2) How to setup a basic gateway and a transparent proxy.
 * 3) The key to a good firewall is to know the protocols you want do allow.
 * 4) That IP traffic does not always contain legitimate data, e.g. ICMP packets, which can contain a malicious payload.
 * 5) How to prevent SYN attack.
 * 6) Filtering HTTP traffic by removing offensive pictures and downloads of viruses.
 * 7) Combining packet filters and application gateways provides better control.

Now, if you really need to, go create a firewall that matches your needs.