Connectivity
What’s the difference between a Next Generation Firewall and a Web Application Firewall?
When it comes to protecting web applications we’re often asked: “Why use a web application firewall if there is a next generation firewall in place?” The short answer is, you need both.
So, what is a Web Application?
During the web’s infancy, websites were just static pages with very little user interaction. This changed in the 1990’s as web servers started to allow communication with server-side custom scripts [1], and developers now had the ability to build solutions such as web-based email, web stores and blogs. These are all examples of web applications, a program that is stored on a remote server and delivered over the internet through a browser [1].
Nowadays, web applications are more complicated, with a dependence on HTML5, JavaScript and databases etc. They may be a repository for corporate data, customer data or payment information and as a result have become an attractive target for attackers and must be secured correctly.
What is a Next Generation Firewall?
A NGFW combines the functions of a traditional firewall with additional features like intrusion detection and prevention, URL filtering, Antivirus/Anti malware, identity awareness, time-based decisions and location awareness.
Most importantly, a NGFW provides ‘application awareness.’ A traditional firewall is based solely on network-layer attributes (like IP address, port and protocol) but this is not enough information to accurately identify or police an application. A NGFW looks for abnormal information in the headers of a message and even within the data itself, and can be set to look for specific character strings (words or phrases) within the message body to identify an application. From there it makes context-based decisions on application traffic in order to protect the network, typically this would be internal users heading outside the network.
Protecting the Application Layer isn’t Enough
The issue here comes from the terms used by typical networking frameworks, in the OSI model for example the application layer is used to define “the collection of shared communications protocols and interface methods used by hosts in a communication network” [2], examples of which include HTTP, FTP, BitTorrent and SNTP.
Protecting the traditional application layer fails to fully protect an “application”. As shown in Figure 1, additional resources within infrastructure applications need protecting, such as web servers, business applications and application data.
Figure 1 – The full computing stack model [3]
To protect Infrastructure apps, business apps and data, application fluency is required. Although a NGFW can identify an application regardless of the port and protocol being used this is not the same as application fluency, which needs the ability to truly understand how an application works rather than just what it is.
Enter the Web Application Firewall
A Web Application Firewall protects web servers and hosted web applications from threats at the highest level of the full computing stack and from non-volumetric attacks in the network layer.
WAFs are different from NGFWs in that they have the ability to:
- Provide DDoS protection at the application level
- Validate inputs (Stopping SQL injection)
- Provide cross site scripting protection
- Provide virtual patching to apps before vendors release official patches
- Block attacks based on known or custom defined application vulnerabilities
- Detect cookie and session tampering attacks
- Block unwanted web traffic from websites and applications
- Block potentially sensitive server responses from attackers
- Increase site speed and performance through advanced caching mechanisms
A WAF achieves critical application fluency in a few different ways. Many modern WAFs use automated learning to understand typical application behaviour over time, and as a result can differentiate between malicious and legitimate traffic. Manual configuration of application policies allows developers/ admins to tell the WAF exactly how their application works and the application fluency required to make decisions on traffic. High spec WAF’s and many cloud solutions will have the ability to conduct HTTPS decryption, enabling the WAF with deeper insights into application traffic. Couple these features with a default security capability and some business logic and it can make decisions a NGFW couldn’t on how to process web app traffic, which in turn grants them a greater level of protection.
Figure 2 – A WAF in the Data Path [4]
WAFs are typically deployed inline, behind a traditional or next-gen firewall (See figure 2) functioning as a transparent reverse proxy or a reverse proxy. A transparent WAF allows traffic to be sent directly to the application server, whereas a non-transparent WAF will have a client’s traffic sent to it first and can provide greater protection to the application server, although often at the cost of performance.
References:
[1] https://securelink.net/en-be/insights/waf-vs-ngfw/
[2] https://osi-model.com/application-layer/
[4] https://www.f5.com/company/blog/where-does-a-waf-fit-in-the-data-path