Relying on Bad Firewalls
First Published: SC Magazine

When protecting networked assets and business critical infrastructure from attack, most organizations’ defensive line begins with their firewall - unfortunately, all too often it ends with it as well. Too many organizations see a firewall as the suit of armor protecting their infrastructure investment. A better analogy would be the breastplate - capable of stopping killing strokes to the main body, but ineffectual against the kick to the groin or blow to the head. That being the case, the firewall should still constitute the first line of defence - but must also be supported with other defence-in-depth security practices.

When conducting security assessments, I emphasize the necessity to begin with an on-site component - carrying out ‘on the wire’ ethical hacking against each host, from each network segment. Often the first response is “I don’t need that. I’m only interested in what hackers from the internet can do. I have a firewall to protect me.” If a client feels a little nervous about their firewall they may include the IP address as part of a remote ethical hack. Unfortunately, they are missing the point. If the firewall is so vital to the security of their infrastructure investment, why aren’t they checking it to ensure it is providing all the protection they think it is?

Despite the best efforts in the world, no firewall will protect your hosts against ‘zero-day’ exploits targeted at the services accessible from the internet. However, if correctly configured and maintained, it can help to limit the actions an attacker can make from a compromised host. Controlling network traffic leaving the compromised network (such as disallowing HTTP or FTP out) will often make it difficult for the attacker to obtain the tools necessary to escalate permissions, or compromise other internal hosts.

Quite often, the firewall represents the single biggest expenditure of an organization’s security budget on a per-project basis. It receives a lot of attention when installed within the environment and is often configured well - initially. However, by the time the infrastructure has been operating for a year or more the firewall often no longer provides the protection it used to. The key failures can be seen in the accompanying box.

Having assessed and reviewed numerous firewall policies, sometimes containing hundred of rules, I would strongly recommend that organizations arrange for an annual review and ‘spring clean’ of their firewall policies. It is important that both firewall administrators and infrastructure developers/ maintainers are present to evaluate the required changes. The focus should be on minimizing the complexity of the policy, while ensuring that network traffic is regulated in both directions.

Organizations should then test the security of the firewall using a variety of port scanning and validation techniques. Scanning the firewall itself is of limited value, but will help to identify any services or system responses that ordinarily should be disabled (e.g. responses to ICMP, routing protocols and open management ports). It is however, vital to scan each host (including the firewall) from all network segments connected to the firewall, and compare these findings with expectations based upon the policy. Longer term, organizations need to ensure that their firewall administrators are thoroughly trained in the use of the current version of the firewall and host operating system.

Organizations running firewall-based VPN tunneling services must also evaluate any associated policies and configuration. In the past, when carrying out a network mapping exercise as part of a remote ethical hacking exercise, I found the ability to anonymously download the network topology could provide a wealth of valuable information which could be used to target hosts.

Just as organizations should not see their firewall as a complete security defence, they should ensure that this critical component is well maintained and managed. After all, the breastplate to your suit of armor is only as good as the steel and the blacksmith who made it.

Key failures in firewall protection
(1) Missing security patches and updates to both the firewall application and host operating system.
(2) The addition of new hosts within the protected environment requiring changes to the firewall policy. These are often added as generic host rules, affecting the security of existing hosts.
(3) The removal of hosts from the infrastructure without the corresponding changes to the firewall policy. This creates a ‘leaky’ policy should a host ever be remotely compromised.
(4) The addition of ‘temporary’ policy changes to overcome one-time problems throughout the year. Often a favorite with system administrators who have to obtain and install the latest security patches or updates to the protected hosts.
(5) The reviewing of firewall logs becomes less frequent over time. Administrators invest less time monitoring the day-to-day functioning of the firewall and attacks go unnoticed.
(6) Administration of the firewall changes hands (as it no longer interests the ‘techie’ who initially installed it) to someone less qualified and less capable of altering the firewall policy - particularly the addition of rules that restrict incoming traffic, but place no restrictions on outbound traffic.
(7) Many more people gain rights to administer the firewall, such that no single person knows why certain rules were created in the first place or the significance of a change.
    Copyright 2001-2007 © Gunter Ollmann