Application firewall

An application firewall is a form of firewall which controls input, output, and/or access from, to, or by an application or service. It operates by monitoring and potentially blocking the input, output, or system service calls which do not meet the configured policy of the firewall. The application firewall is typically built to control all network traffic on any OSI layer up to the application layer. It is able to control applications or services specifically, unlike a stateful network firewall which is - without additional software - unable to control network traffic regarding a specific application. There are two primary categories of application firewalls, network-based application firewalls and host-based application firewalls.

Network-based application firewalls

A network-based application layer firewall is a computer networking firewall operating at the application layer of a protocol stack,^[1] and are also known as a proxy-based or reverse-proxy firewall. Application firewalls specific to a particular kind of network traffic may be titled with the service name, such as a web application firewall. They may be implemented through software running on a host or a stand-alone piece of network hardware. Often, it is a host using various forms of proxy servers to proxy traffic before passing it on to the client or server. Because it acts on the application layer, it may inspect the contents of the traffic, blocking specified content, such as certain websites, viruses, attempts to exploit known logical flaws in client software.

Network-based application-layer firewalls work on the application level of the network stack (for example, all web browser, telnet, or ftp traffic), and may intercept all packets traveling to or from an application. In principle, application firewalls can prevent all unwanted outside traffic from reaching protected machines.

Modern application firewalls may also offload encryption from servers, block application input/output from detected intrusions or malformed communication, manage or consolidate authentication, or block content which violates policies.

History

Gene Spafford of Purdue University, Bill Cheswick at AT&T Laboratories, and Marcus Ranum described a third generation firewall known as an application layer firewall. Marcus Ranum's work on the technology spearheaded the creation of the first commercial product. The product was released by DEC who named it the DEC SEAL product. DEC’s first major sale was on June 13, 1991 to a chemical company based on the East Coast of the USA.

TIS, under a broader DARPA contract, developed the Firewall Toolkit (FWTK), and made it freely available under license on October 1, 1993. The purposes for releasing the freely-available, not for commercial use, FWTK were: to demonstrate, via the software, documentation, and methods used, how a company with (at the time) 11 years' experience in formal security methods, and individuals with firewall experience, developed firewall software; to create a common base of very good firewall software for others to build on (so people did not have to continue to "roll their own" from scratch); and to "raise the bar" of firewall software being used.

The key benefit of application layer filtering is that it can "understand" certain applications and protocols (such as File Transfer Protocol, DNS, or web browsing), and it can detect whether an unwanted protocol is being sneaked through on a non-standard port or whether a protocol is being abused in any harmful way.

Host-based application firewalls

A host-based application firewall can monitor any application input, output, and/or system service calls made from, to, or by an application. This is done by examining information passed through system calls instead of or in addition to a network stack. A host-based application firewall can only provide protection to the applications running on the same host.

Application firewalls function by determining whether a process should accept any given connection. Application firewalls accomplish their function by hooking into socket calls to filter the connections between the application layer and the lower layers of the OSI model. Application firewalls that hook into socket calls are also referred to as socket filters. Application firewalls work much like a packet filter but application filters apply filtering rules (allow/block) on a per process basis instead of filtering connections on a per port basis. Generally, prompts are used to define rules for processes that have not yet received a connection. It is rare to find application firewalls not combined or used in conjunction with a packet filter.^[2]

Also, application firewalls further filter connections by examining the process ID of data packets against a ruleset for the local process involved in the data transmission. The extent of the filtering that occurs is defined by the provided ruleset. Given the variety of software that exists, application firewalls only have more complex rulesets for the standard services, such as sharing services. These per process rulesets have limited efficacy in filtering every possible association that may occur with other processes. Also, these per process ruleset cannot defend against modification of the process via exploitation, such as memory corruption exploits.^[2] Because of these limitations, application firewalls are beginning to be supplanted by a new generation of application firewalls that rely on mandatory access control (MAC), also referred to as sandboxing, to protect vulnerable services. Examples of next generation host-based application firewalls which control system service calls by an application are AppArmor^[3] and the TrustedBSD MAC framework (sandboxing) in Mac OS X.^[4]

Host-based application firewalls may also provide network-based application firewalling.

Examples

To better illustrate the concept, this section enumerates some specific application firewall examples.

Implementations

There are various application firewalls available, including both free and open source software and commercial products.

Mac OS X

Mac OS X, as of Leopard, includes an implementation of the TrustedBSD MAC framework, which is taken from FreeBSD.^[5] The TrustedBSD MAC framework is used to sandbox some services, such as mDNSresponder, much like AppArmor is used to sandbox services in some Linux distributions. The TrustedBSD MAC framework provides a default layer of firewalling given the default configuration of the sharing services in Mac OS X Leopard and Snow Leopard.

The Application firewall located in the security preferences of Mac OS X starting with Leopard provides the functionality of this type of firewall to a limited degree via the use of code signing apps added to the firewall list. For the most part, this Application firewall only manages network connections by checking to see if incoming connections are directed toward an app in the firewall list and applies the rule (block/allow) specified for those apps.

Linux

This is a list of security software packages for Linux, allowing filtering of application to OS communication, possibly on a by-user basis:

• AppArmor
• ModSecurity - Also works under Mac OS X, Solaris and other versions of Unix.
• Systrace
• Zorp

Windows

• WinGate
• WinRoute

Network appliances

These devices are sold as hardware network appliances.

Specialized application firewalls

Specialized application firewalls offer a rich feature-set in protecting and controlling a specific application. Most specialized network appliance application firewalls are for web applications.

History

Large-scale web server hacker attacks, such as the 1996 PHF CGI exploit,^[6] lead to the investigation into security models to protect web applications. This was the beginning of what is currently referred to as the web application firewall (WAF) technology family. Early entrants in the market started appearing in 1999, such as Perfecto Software’s AppShield,^[7] (who later changed their name to Sanctum and in 2004 was acquired by Watchfire ^[8] (acquired by IBM in 2007), which focused primarily on the ecommerce market and protected against illegal web page character entries. NetContinuum (acquired by Barracuda Networks in 2007) approached the issue by providing pre-configured ‘security servers’. Such pioneers faced proprietary rule-set issues, business case obstacles and cost barriers to wide adoption, however, the need for such solutions was taking root.

In 2002 the industry took another major step forward when the open source project, called ModSecurity run by Thinking Stone (acquired by Breach Security in 2006), was formed with a mission to solve these obstacles and make WAF technology accessible for every company. With the release of the core rule set, a unique open source rule set for protecting Web applications, based on the OASIS Web Application Security Technical Committee’s (WAS TC) vulnerability work, the market had a stable, well documented and standardized model to follow.

In 2003, the WAS TC’s work was expanded and standardized across the industry through the work of the Open Web Application Security Project’s (OWASP) Top 10 List. This annual ranking is a classification scheme for web security vulnerabilities, a model to provide guidance for initial threat, impact, and a way to describe conditions that can be used by both assessment and protection tools, such as a WAF. This list would go on to become the industry benchmark for many compliance schemes.

In 2004, large traffic management and security vendors, primarily in the network layer space, entered the WAF market through a flurry of mergers and acquisitions. Key among these was the mid-year move by F5 to acquire Magnifire WebSystems and the integration of the latter’s TrafficShield software solution with the former’s Big-IP traffic management system. This same year, F5 acquired AppShield and discontinued the technology. Further consolidation occurred in 2006 with the acquisition of Kavado by Protegrity, and Citrix Systems’ buying of Teros.

Until this point, the WAF market was dominated by niche providers who focused on web application layer security. Now the market was firmly directed at integrating WAF products with the large network technologies – load balancing, application servers, network firewalls, etc. – and began a rush of rebranding, renaming and repositioning the WAF. Options were confusing, expensive and still hardly understood by the larger market.

In 2006, another milestone was reached when the Web Application Security Consortium formed to help make sense of the now widely divergent WAF market. Dubbed the Web Application Firewall Evaluation Criteria project (WAFEC), this open community of users, vendors, academia and independent analysts and researchers created a common evaluation criterion for WAF adoption that is still maintained today.

Wide-scale interest in the WAF began in earnest, tied to the 2006 PCI Security Standards Council formation and compliance mandate. Major payment card brands (AMEX, Visa, Master Card, etc.) formed PCI as a way to regulate security practices across the industry and curtail the rampant credit card fraud taking place. In particular, this standard mandated that all web applications must be secure, either through secure development or use of a WAF (requirement 6.6). The OWASP Top 10 forms the backbone of this requirement.

With the increased focus on virtualization and Cloud computing to maximize existing resources, scaling of WAF technology has become the most recent milestone, marked by the 2009 white paper, Defining a dWAF to Secure Cloud Applications from art of defence and the Guidance for Critical Areas of Focus in Cloud Computing paper from the Cloud Security Alliance (CSA).

By 2010, the WAF market had matured to a market exceeding $200M in size according to Forrester. In a February 2010 report, Web Application Firewall: 2010 And Beyond, Forrester analyst Chenxi Wang wrote, "Forrester estimates the 2009 market revenue of the WAF+ market to be nearly $200 million, and the market will grow by a solid 20% in 2010. Security and risk managers can expect two WAF trends in 2010: 1) midmarket-friendly WAFs will become available, and 2) larger enterprises will gravitate toward the increasingly prevalent WAF+ solutions." She also wrote that "Imperva is the stand alone WAF leader."

Distributed web application firewalls

Distributed Web Application Firewall (also called a dWAF) is a member of the web application firewall (WAF) and Web applications security family of technologies. Purely software-based, the dWAF architecture is designed as separate components able to physically exist in different areas of the network. This advance in architecture allows the resource consumption of the dWAF to be spread across a network rather than depend on one appliance, while allowing complete freedom to scale as needed. In particular, it allows the addition / subtraction of any number of components independently of each other for better resource management. This approach is ideal for large and distributed virtualized infrastructures such as private, public or hybrid cloud models.

Cloud-based web application firewalls

Cloud-based Web Application Firewall is also member of the web application firewall (WAF) and Web applications security family of technologies. This technology is unique due to the fact that it is platform agnostic and does not require any hardware or software changes on the host, just a DNS change. By applying this DNS change, all web traffic is routed through the WAF where it is inspected and threats are thwarted. Cloud-based WAFs are typically centrally orchestrated, which means that threat detection information is shared among all the tenants of the service. This collaboration results in improved detection rates and lower false positives. Like other cloud-based solutions, this technology is elastic, scalable and is typically offered as a pay-as-you grow service. This approach is ideal for cloud-based web applications and small or medium sized websites that require web application security but are not willing or able to make software or hardware changes to their systems.

In 2010, Imperva spun out Incapsula to provide a cloud-based WAF to small to medium sized businesses.

Web application firewalls

• Armorlogic - Profense web application firewall
• Array Networks - WebWall Multi-Layered Application Security
• Barracuda Web Application Firewall
• Cisco - Application Control Engine (ACE) Web Application Firewall
• Citrix NetScaler - Application Firewall
• F5 Networks - Application Security Manager ASM
• Fortinet - Fortiweb web application firewall
• Imperva - Web Application Firewall
• ModSecurity - Opensource web application firewall
• MONITORAPP - WEB INSIGHT SG Application Firewall
• NAXSI - An open source, Web Application Firewall module for Nginx (Positive model)
• Penta Security - WAPPLES (Web Application Firewall)
• Radware - AppWall Web Application Firewall
• SonicWALL - SonicWALL Web Application Firewall Service

Combination network and application firewalls

Combination network and application firewalls typically offer fewer features than specialized application firewalls. Many of these require separate licenses to activate the full application firewall functionality.

• Cyberoam
• Check Point Security Gateways
• Cisco Adaptive Security Appliance
• Fortinet FortiGate firewalls
• Juniper Networks SRX services gateway and SSG firewalls
• SonicWALL firewalls
• WatchGuard firewalls
• McAfee Firewall Enterprise
• Palo Alto Networks Next Generation of Firewall

See also

Computer security portal

• ModSecurity
• Computer security
• Content-control software
• Proxy server
• Information security
• Application security
• Network security

References

1. ^ Luis F. Medina (2003). The Weakest Security Link Series (1st ed.). IUniverse. pp. 54. ISBN 978-0595264940. http://books.google.com/books?id=Yz34zXV7VB8C&pg=PA54&dq=application+layer+firewall#v=onepage&q=application%20layer%20firewall&f=false. 
2. ^ ^{a b} http://www.symantec.com/connect/articles/software-firewalls-made-straw-part-1-2
3. ^ "Firewall your applications with AppArmor". http://www.linux.com/archive/feed/58789. Retrieved 2010-02-15. 
4. ^ "The TrustedBSD Project". The TrustedBSD Project. 2008-11-21. http://www.trustedbsd.org/mac.html. Retrieved 2010-02-15. 
5. ^ http://www.trustedbsd.org/mac.html
6. ^ CERT (March 20, 1996). "CERT Advisory CA-1996-06 Vulnerability in NCSA/Apache CGI example code". CERT Coordination Center. http://www.cert.org/advisories/CA-1996-06.html. Retrieved 2010-11-17. 
7. ^ Ellen Messmer (September 7, 1999). "New tool blocks wily e-comm hacker tricks". CNN. http://www.cnn.com/TECH/computing/9909/07/ecomm.hack.idg/index.html. Retrieved 2010-11-17. 
8. ^ Jaikumar Vijayan (August 4, 2004). "Q&A: Watchfire CTO sees Sanctum acquisition as a good fit". Computerworld. http://www.computerworld.com/s/article/95035/Q_A_Watchfire_CTO_sees_Sanctum_acquisition_as_a_good_fit. Retrieved 2010-11-17. 

External links

• NAXSI: An Opensource Web Application Firewall (Positive model)
• Mac OS X 10.5 Leopard: About the Application Firewall
• Web Application Firewall, Open Web Application Security Project
• Web Application Firewall Evaluation Criteria, from the Web Application Security Consortium
• Safety in the cloud(s): 'Vaporizing' the Web application firewall to secure cloud computing