Firewalls: Is your firewall hardened?

If you’re working with firewalls, you should have a pretty good grasp of the OSI model by now. If not, review my brief “nuts and bolts” post (The OSI model in a nutshell) that explains each layer.

Before discussing how firewalls are bypassed, it’s important to know the types of firewalls. Depending on your infrastructure and protection needs, there are a number of firewall types you may use. I won’t go into specific vendor brands (such as PIX/ASA, CheckPoint NG, ISA, Juniper, etc.), but I will briefly cover the main firewall technologies. A few of the common types of firewalls on the market today fall into one or more of the following categories:

• Packet filtering: packet filtering firewalls make decisions based on header information: IP address, protocol and port number. They use access control lists (ACLs) to determine what to accept or deny. One shortcoming, however, is that packet filtering firewalls can be bypassed when the traffic is fragmented or configured to arbitrarily meet the ACL criteria.

• Application proxies: application proxies are firewall devices that act as the middle man to hosts. Unlike packet filtering firewalls, application proxies focus on the top layers of the OSI model. When establishing communications, proxies re-create conversations between the host and outside sources, masking the sources’ identity. They work in tandem with traditional firewalls, as they typically don’t possess the ability to deny traffic. One shortcoming is that proxies are a single point of failure, since all connections to the outside world must be re-created at this single point.

• Stateful packet inspection: stateful packet inspection firewalls maintain a state table that keeps track of each session, or conversation. This type of firewall is more secure, as communication is only allowed through the firewall if a valid connection exists. Whether it’s TCP (connection-oriented) or UDP (connectionless), data is recorded in the state table. If traffic isn’t in response to a session, it’s blocked. Note: the state table includes source and destination IP addresses, ports, TCP sequence data, and other flags associated with the connection.

Now that you know a little bit about the types of firewalls, let’s discuss a common way attackers find out what rules are configured on your firewall. A tool known as Firewalk, can be used to determine which ports are open through the firewall. Firewalk is freely available at packetstorsecurity.org.  So how does firewalk work? Well, according to their authors, “Firewalk works by sending out TCP or UDP packets with a TTL one greater then the targeted gateway. If the gateway allows the traffic, it will forward the packets to the next hop where they will expire and elicit an ICMP_TIME_EXCEEDED message. If the gateway host does not allow the traffic, it will likely drop the packets on the floor and it will see no response.” So in essence, it works like traceroute which uses the time-to-live (TTL) field to determine the hops packets take to reach a particular destination.

Each organization is unique and may have to live with the fact that external sources can figure out their firewall rules. Depending on the complexities of your network, not allowing ICMP_TIME_EXCEEDED messages is an option. Security administrators will have to assess the impact against their infrastructure in regards to network diagnostics.  Beyond assessing Firewalk, there are other means to hardening your firewall.

Most security administrators realize that the basic way to secure any product is to disable unnecessary services and processes. The same holds true with firewalls. Many of the latest brands come equipped with additional functionality that your infrastructure may not need or support. This may be due to integration issues or if another device is already performing the additional function. Therefore, if it’s not required, disable it.

Firewalls can have vulnerabilities, just like anything else. Some administrators have a false sense of security when they think of their “firewall” as the king reigning over their fortress. How silly will they feel when they realize their firewall was owned by a foreign source because of a buffer overflow that had a patch released over 6 months ago? So like other systems and applications, maintain proper patch management with firewalls and other security devices.

Another hardening measure is to know your configuration. If your firewall allows comments or a description, use it. This enhances change management and complements maintaining backups. Backups should be made of your configuration as consistent as you make changes. When descriptions are used, an old backup will reveal exactly what each rule was in place for.

I could write for hours on this topic, but some additional measures include maintaining proper logs (while securing your syslog server), using warning banners, a consistent naming convention, and defining a proper baseline. Although firewalls are great for network security, they are far from the “silver bullet” solution.