Firewalls, Filters and NAT

Introduction

In the arsenal of defensive tools available for network administrators, firewalls probably occupy the most prominent, and vital position. Firewalls can be used as both a perimeter and host based defense against intrusion. Firewalls are a critical part of "defense in depth" - one of the guiding principles of network and computer security that states that your defensive strategy should be a layered one. Thus, your resources should be protected by several layers of security that help to limit access to only authorized usage.

Because firewalls can affect routing information they are effective at limiting access and shielding vulnerably assets. This is critical given that many times service vulnerability is announced well before any fix or patch can be issued or implemented. Utilizing a firewall to limit access to a vulnerable service can protect that service from exploit or worm by limiting access rules.

At the core of internet communications lies IP (Internet Protocol) traffic. This includes TCP/IP, UDP, ICMP and other protocols that help to route information on the network. Because much of this traffic is specific to usages and services you may not implement on your network, a firewall can help to quiet your network by siphoning off extraneous traffic, while simultaneously blocking malicious traffic. A properly implemented firewall presents the added benefit of reducing the overall noise in a network, allowing more accurate network analysis.

Network firewall technology can be broken into two broad categories. I will refer to these categories as 'filter firewalls' that operate by analyzing streams and/or packet payloads, and 'protocol firewalls' that merely examine and react to packet headers. The former is more robust in that it can actually look at the payload of network traffic to determine if there is malicious traffic destined for regularly allowable services. For instance, a filter firewall might be able to detect a attack against a web server and block the attack. A protocol firewall merely examines packet headers, including their source and destination, but would only be able to allow or deny access to a resource, not conditionally limit access based on the interaction of requests. In this way a protocol firewall would only be able to allow access to a web server's HTTP port, and would be unable to detect or respond to an attack on that web server through it's HTTP port.

While the protection advantages of filter firewalls are obvious, their resource expense is extremely high. Because filter firewalls are required to stop, examine, and then pass on or drop each packet they can become a bottleneck. While protocol firewalls will examine each packet, they will only examine the header information, which accounts for a small percentage of the actual packet size. Filter firewalls must examine the entire contents of the packet, which is much more resource intensive and can have a debilitating effect on network traffic. Additionally, some malicious traffic could be contained in more than one packet, so in order to be truly effective, a filter firewall has to reconstruct communication streams by assembling multiple packet payloads and applying filter rules to the resultant exchange. This becomes exponentially more expensive as the firewall has to collect, analyze and ultimately route packets. Given the massive amount of traffic on even small networks this sort of filtering isn't very feasible given computing resources today. Thus, true filtering technology is still rare in firewalls.

Types of Firewall Technology

There are several different types of firewalls available to defend computing resources. Each has it's own advantages and disadvantages. Ideally a network can employ several of these types of defenses to provide a more complete layer of protection. Regardless of type or deployment, however, ultimately a firewalls effectiveness is dependent on its proper configuration and maintenance. There are four broad types of network firewall technologies available:

• Personal Firewalls - these are firewalls installed on end host systems. Often times these firewalls offer two types of protection - application layer firewalling and network layer firewalling. Because they include application specific rules they can provide for a finer grain of control than a network firewall. An application level firewall serves to block access to specific resources on a machine rather than simply affecting routing information of IP traffic. Unfortunately, the proportion of end users required to install and configure firewalls in a timely manner to prevent worm outbreaks is far too high to make them effective at this task. This should not mean, however, that a network should ignore host based protections. Because these firewalls are placed on end nodes they can't be effective in limiting traffic on the network as a whole and so in and of themselves cannot provide much overall network protection. However, it is often the case that the gravest threat to an organization is from an insider, and thus protecting resources that lie behind your perimeter with further access control measures only helps to strengthen your network security and provides defense in depth.
• NAT - Network Address Translation devices do not actually perform filtering but can be used to implement rudimentary firewalling because they manage traffic. Their main function is to translate network addresses by rewriting header information. However, due to their widespread use and highly configurable interfaces, NAT devices can be used to implement basic routing rules that mimic many firewall features.
• Network Firewalls - Network firewalls are typically placed at the network perimeters to filter down incoming traffic by examining packets and dropping what is deemed to be unacceptable traffic. Network firewalls are usually the first line of defense on a network and thus must be carefully and thoughtfully implemented and maintained to provide maximum protection for resources.
• Proxies - These devices simulate client connections, cache and then filter data from connections. Proxies often only interact with one specific protocol, and so even though their operation can be resource intensive, the specialization can help to limit bottlenecks. Proxies can also be useful in that they stand between a resource and a client, making resource abuse difficult since interaction is abstracted by the proxy layer.

NAT

NAT devices break internet invariance by allowing alternate IP naming schemes behind the NAT device. NAT leverages dual facing interfaces, masking the IP of all machines on the network behind it by rewriting packet headers. The device accomplishes this by replacing the port numbers in the headers with NAT id numbers. This id number is the same size as a port number in the packet header (16 bits). NAT's overload the meaning of ports to keep track of inbound and outbound requests. The NAT device, in essence, uses the combination of the IP address and the port number as a machine identifier.

NAT devices keep internal tables which map ports to hosts for this translation. This effectively shields internal hosts because an attacker can not easily guess the NAT id for a specific host. Additionally this table has an expiry, with a garbage collection occurring within the device on a fixed time schedule. This garbage collection clears the table and new addresses are reassigned when requests originate. This means that the table entry for a specific machine and port is merely temporary, further reducing the window of opportunity for an attacker. This also means that the NAT device will only route external packets to specific ports on internal machines that are listed in it's current lookup table.

This schema does create problems for servers behind the NAT device that wish to provide resources on well known ports to clients beyond the NAT perimeter. To solve this problem port forwarding can be enabled on most NAT devices. This allows the device to be configured statically route certain port request to specific hosts by adding an entry to the NAT routing tables that survives garbage collection. This pokes a hole in the firewall functionality of the NAT address, but is necessary in cases where a server needs to run on a well known port and serve requests from beyond the NAT device. For instance, the NAT device could add an entry that always maps inbound port 80 requests to a specific internal host IP on port 80. This allows the NAT device to appear as if it supports all well known protocols by routing inbound requests appropriately.

The NAT device's rewriting of packet headers is not without disadvantages. The IP address is only rewritten in the header, so protocols that utilize IP information contained within the packet body might not function properly over a NAT device's connection. Additionally, protocols that utilize header based encryption could fail due to the header rewriting. NAT devices must replace header checksums in packets as they rewrite the header information in order to provide accurate checksums on the new packets. Tunneling protocols can also break down across NAT devices.

There is an argument that the widespread implementation of NAT has slowed the adoption of IPv6. The argument states that because NAT has eased the IP address space burden (by providing what can amount to an entire class A address space behind each IP address) that there is less demand for the increased address space provided by IPv6. Also, NAT corrupts IP addressing schemes by effectively allowing the combination of a port number and an IP address to be used as a machine address.

Network Firewalls

Conceptually filter firewalls are supposed to prevent bad packets at the perimeter. Traditional network models, however, do not always map to real life topologies. Sometimes the network leaks outside of the firewall, blurring the concept of a perimeter. For this reason many organizations deploy multiple firewalls, defining perimeter on a more resource based analysis. Thus, a firewall might be deployed to protect a group of servers, rather than the network as a whole. Often times firewalls are deployed incrementally, perhaps with one firewall protecting a subset of resources, and another protecting the entire superset. This can allow the outermost firewall some leniency in it's rules set and an increasing intolerance on subsequent firewalls. This effectively squeezes down legitimate traffic to only smaller group for each subsequent firewall from the outside in towards a resource, lowering the load on each firewall while concurrently increasing security.

Filtering firewalls can also become a bottleneck to network traffic, however, if improperly configured or deployed. Packet inspection is resource intensive, and firewalls must have appropriate hardware support for the loads they are expected to manage. Limiting packet inspection to header information only can help to lighten this load, with the trade of that it provides less security. One step up from mere packet header inspection is primitive state analysis. Some firewalls can monitor state, allowing conditional filtering on connections based upon their state (for instance, dropping an ACK without a corresponding SYN). This does cause additional overhead and retards responsiveness.

Filtering firewalls consult internal rules tables and construct allow/deny instructions that determine whether or not to pass a packet or drop it. Ideally firewalls should be configured with least privilege, allowing the smallest number of packets possible while preserving legitimate traffic. Typical firewalls either enable communication on certain ports (default deny) or disable communications on certain ports (default allow).

Firewalls often rely on well known ports, so they can be end run by placing services on non-standard ports, or by running non-standard services on well known ports. This is advantageous in that it lightens the load on the firewall, but also opens the firewall rules to abuse. Because services are not required to run on well known ports, port information is not always an accurate gauge of the service or traffic type actually utilizing the port.

Firewalls can be configured in multiple ways (GUI, shell scripts, config files, etc.) but all construct a rules based table. Typically there is a precedence among the rules and the first match in the table governs the firewalls treatment of a packet. If a packet reaches the end of a table without matching any of the rules it can either be allowed or denied based on the specific firewall.

Filtering can occur at four points:

	--------->1			3---------->
LAN			| Firewall |			External Net
	<---------2			4<---------

These four points are 1) the point at which the firewall receives traffic from the internal network 2) the point at which the firewall forwards traffic to the local network 3) the point at which the firewall forwards information to the external network and 4) the point at which the firewall receives traffic from the external network. To be most effective a firewall should allow configuration on all four points. At a minimum, the firewall should allow configuration at point 4, to limit the traffic entering the local network.

Some firewalls will only allow control over some of the points of contact with the firewall. Allowing configuration at all four points of contact is most effective. For instance, if a packet arrives at point 1 (from within the local network) with an IP address that does not belong in the internal network then the firewall can assume it is a bad packet and drop it. Similarly, if a packet arrives at 4 with a source address on the internal network it can be discarded as a forgery. Without these protections it becomes possible for an attacker to artificially craft packets that may be able to bypass a firewall's filter rules.

As a rule of thumb firewalls should be designed to do filtering as soon as possible. In this way the firewall can reduce the amount of traffic that has to be processed at the earliest possible point. This reduces overhead on the network. For instance, a DDOS against a machine on the network could be mitigated by dropping inbound packets at point 4. Of course, in this example the firewall is absorbing the brunt of the processing and may itself become the victim of the DDOS.

Rules authoring can be made considerably easier or more difficult depending on how configurable the firewall is. Having the ability to write rules on all four points of contact with the firewall allows for greater conditional filtering, but can also be complex and lead to ms-authored rules that actually degrade traffic or unintentionally block legitimate traffic. Firewalls that only allow a small numbers of contact point configurations must be more permissive, but are often simpler to configure.

Because firewalls make assumptions about conventions an attacker can exploit these assumptions (such as well known ports). The only way to mitigate this risk is to do packet inspection. This can become possible, however, at an internal point if an external firewall filters down the amount of traffic sent to the filter. This precision filtering is less resource intensive and might be feasible depending on the traffic level the resource experiences.

Conclusions

It should be noted that while most firewalls are active intrusion prevention systems (IPS), many do not provide the robust intrusion detection that passive solutions offer. While passive intrusion detection systems(IDS), like Snort usually do not have the ability to affect traffic routing, they are capable of alerting network administrators of suspicious traffic or attacks on the network. Often times deploying a passive IDS behind an firewall is a perfect solution. The firewall can cut down on noise in the network and the IDS can be used to monitor traffic within the perimeter. This sort of monitoring can be used to detect anomalies or abuses amongst the network resources, including serving as a valuable troubleshooting aid. By carefully deploying a series of firewalls and network monitoring a network can increase it's security profile without necessarily negatively impacting the networks responsiveness.