Application-layer firewalls work at the application layer of the TCP/IP stack, intercepting packets traveling to or from an application such as a browser. This provides a more thorough examination of network traffic than network firewalls, which only examine packet information at the transport layer and below. But to be effective, application-layer firewalls must be tailored closely to the applications and the specific network environment they're protecting. Poorly configured firewalls can block legitimate users, customers or partners -- or give hackers access to systems and data. This tip reviews types of application firewalls and how to tune them for your organization's environment.
Hardware vs. software
Application firewalls come in many different flavors, but really fall into two main categories: hardware and software. Hardware firewalls run on a dedicated appliance, often having a hardened operating system designed specifically for the task of firewalling. Software firewalls are installed on a general-purpose machine located between trust zones such as at the network perimeter, or in the case of a personal firewall, on the actual desktop machine.
Purpose-built hardware appliances generally deliver better performance, but are more complex to set up and configure. If you choose a software-based solution, make sure it runs on a platform your IT department is familiar with in order to avoid additional training and support issues. Software solutions often provide more flexibility than hardware solutions, but you need to ensure that the operating system the firewall is running on is patched and maintained on a regular basis.
Set up and rule sets
When it comes to setting up your firewall, most IT security books will tell you to start by denying all traffic by default, and then only allowing traffic that is expressly required -- the classic access model used in information security. However, you should be aware of how such an implicit deny rule affects and changes how a firewall behaves. For example, when a packet matches a rule in the access list, the packet is immediately dropped by a deny rule or forwarded by a permit rule. Because it isn't tested against any other rules you may have set in the access list, it is essential that you always put specific filters before general filters. Otherwise, a general rule might allow a packet access that may have been denied by a more specific rule later in the access list.
It helps if you build your set of rules in advance, putting the implicit deny rule at the end, as adding rules ad hoc can radically change how your firewall manages traffic. Approaching the access list rules from a "allow what you need" rather than "deny what you don't" perspective can also make the purpose of each rule that much more reasoned.
You should also implement rules for outbound traffic, ensuring that only packets with your network's source address leave the network. This egress filtering is essential to stop spyware and botnets from phoning home.
Whitelisting, blacklisting and auditing
Whitelists and blacklists define which sites, IP addresses, applications, etc., are to be trusted and which are not, respectively. You can use one or the other, or both. A whitelist approach is more restrictive and is ideal for a network that has a limited need for Internet access and a stable application requirement. However, while a whitelist is generally a more secure approach than a blacklist, it can give a false sense of security because malicious code can turn a trusted machine or application into an untrusted one in seconds by giving control to a hacker via Trojan or Zombie programs. Blacklists have a higher administrative overhead as they need regular updates to be effective and are of no use at all against a new unknown threat.
To help keep white and blacklists up to date, it is essential to log and audit the traffic passing through your application-layer firewall. Logs are invaluable for verifying that the firewall is operating effectively and for analyzing problems or attacks when they occur. Make sure you have the ability to audit and analyze your logs regularly. Even on a small network, the volume of traffic will create log files that are too large to manually audit, so you will need a full-featured log analyzer and the time to review its output.
This article originally appeared on SearchSecurity.com.
About the author
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for SearchSecurity's Web Security School and, as a SearchSecurity.com site expert, answers user questions on application and platform security.
