Some information security specialists confuse the concepts of WAF and NGFW. Moreover, even some representatives of companies manufacturing products positioned as NGFW commit this fault.
“We have an NGFW, do we need a WAF?” or “Why do we need WAF?” are very common questions. This calls for figuring out the background of such confusion, agreeing once and for all on the terms and definitions, and determining the areas of application of each concept.
Intro
Let us start with the abbreviations that define the categories of information security products: WAF stands for Web Application Firewall, NGFW stands for Next-Generation Firewall. The confusion stems from the word Firewall that is present in both terms and initially encourages the comparison and opposition of the two product categories. However, NGFW and WAF are not interchangeable entities. They are designed to address different issues. They are located at different points in the network, and in most cases, are administered by different teams.
Reasons for confusion
NGFW is an evolution of traditional firewalls and serves to delimit access between network segments. The reality is that the terms NGFW and firewall are interchangeable today as referring to firewall implies NGFW.
Traditional firewalls filter network traffic using parameters such as IP addresses, network protocol identifiers, their attributes such as TCP and UDP port numbers, ICMP types, and other traffic parameters related to layers 3 – 4 of the ISO/OSI.
There is no clear definition of NGFW in the wild, and the functionality of the solutions presented on the market has significant differences. At the same time, we can lay down a set of basic features inherent in products of this category. NGFWs complement the capabilities of traditional firewalls by integrating the functions of a VPN gateway, intrusion detection and prevention (IDS/IPS) based on signatures, traffic inspection, and proxying application layer protocols with basic verification of their correctness and compliance with standards.
It is the IPS and traffic inspection functions implemented in NGFW that are one of the main causes of confusion and the source of the question: “Why do I need a WAF if I already have an NGFW?” Later in this article, I will discuss how these functions differ from what WAF can do.
It should be noted that the NGFW traffic inspection functions are primarily designed to control the actions of internal users during information exchange between segments of the protected network or leaving the protected perimeter. And WAF is designed to protect against malicious external influences on protected services, and its mechanisms working externally are meant only to prevent leakage of confidential data both as a result of external impacts and as a result of errors in the code of protected applications and services. In other words, the NGFW traffic inspection functions are primarily applied to the traffic of users of the protected perimeter, and the WAF tries to protect traffic directed to protected web applications/services.
WAF functionality
HTTP traffic features
In short, WAF is designed to protect specific instances of web applications/services that use the HTTP protocol family as transport. Some vendors’ implementations also support SMTP and FTP, but this feature is not determinative. The main battleground for WAF is the traffic of the HTTP family of protocols.
An understanding of the scope of the WAF would be incomplete without understanding the nature of the traffic that must be dealt with and what threats must be countered.
Over the thirty-year history of its existence, HTTP has evolved from a protocol for transferring the content of static HTML documents and images into a transport protocol that not only supports the encapsulation of various data structures but can also be a “backing” for other protocols.
The proliferation of HTML5 and browser frameworks, which actually turned the latter into fat clients, the penetration of mobile devices and applications for them into the daily life of a modern person has led to an increase in the share of HTTP traffic related to API services. According to the old Akamai 2019 Traffic Report, back then, 83% of HTTP traffic on the Internet was made up of API calls.
What does WAF protect?
WAF protects web applications/services that can be identified by the IP address (L3) and port (L4). In most cases, the scope of the protected web application/service is also characterized by the name of the resource, which is transmitted by the client in the HTTP request in the standard “Host” header.
So, WAF handles HTTP traffic analyzing HTTP requests addressed to a specific instance of a web application/API service and responses to them. Should it detect any illegitimate activities, WAF, subject to its configuration, either blocks the request or logs this activity and transfers information to other systems, for example, SIEM.
What about attacks?
The broad capabilities of the HTTP protocol have spawned an equally diverse set of attacks on web applications and services. The most significant types of attacks are described in the OWASP Top Ten Web Application Security Risks (for web applications) and OWASP API Security Top Ten (for API services).
Countering such attacks, first, requires decomposition of the HTTP request into individual primitives (uniform resource identifiers, headers, parameters) and analysis of the contents of data structures, as well as the subsequent analysis of their elements. This involves resource-intensive calculations. A good example is the transmission of data in JSON or XML formats.
It is especially worth highlighting the following:
⮚ Attacks on the application’s business logic, countering which requires a deep understanding of the normal behavioral patterns of a legitimate user.
⮚ Illegitimate automated actions using bots to collect information, brute-force attacks, attempts to bypass CAPTCHAs, etc.
⮚ Distributed denial of service attacks at the application level exhausting the resources of the application infrastructure components.
It is impossible to effectively counter such attacks using the mechanisms provided in NGFW. Traffic inspection mechanisms have limited functionality, and the use of IPS signatures to analyze HTTP traffic leads to many false positives. Therefore, HTTP signatures are disabled by default in IPS / NGFW of most vendors.
Some of you might argue that signature analysis is also used in most WAFs. In this regard, the following should be noted:
⮚ Signatures in leading WAFs can be applied “pointwise.” After decomposition of the content of the request to basic components, the signature is applied to a specific primitive of the HTTP protocol or transmitted data.
⮚ Despite this, WAF signatures, when applied out of the box, give a significant percentage of false positives. So, they require careful testing before being turned on to block malicious requests.
Thus, signatures in WAF are just one of many anti-attack mechanisms. To finish with signatures, let us consider a real example of a vulnerability that signature analysis fails to address. By sending an HTTP request containing JSON data, a key, or keys containing metacharacters, an attacker can trigger a denial-of-service attack.
Security model
Modern WAFs combine both negative (blacklisting) and positive (whitelisting) security models. The first type makes use of signature analysis and its more advanced variants taking into account, in addition to the patterns and contexts in which they are applied (how and where), the source of the attack (who, what, where from), obfuscation of confidential data transmitted from the web application/service to the client, as well as the prohibition of certain primitives of the HTTP protocol (for example, URI). A positive security model describes the characteristics of requests and their content that can be considered legitimate.
What to do with HTTPS?
One of the incentives for widespread use of the HTTP protocol is its cryptographically protected version, referred to as HTTPS. According to Google, by the end of February 2021, from 77% to 98% of web pages downloaded by the Chrome browser were transferred via the HTTPS protocol.
To analyze the content of an HTTPS session, WAF needs to decrypt it. In the recent past, when the protection of HTTPS traffic was built upon RSA cryptography, accessing the HTTPS content only required possessing a corresponding key; that is to say, using WAF did not require terminating HTTPS sessions or using WAF as expensive L7 IPS working with traffic copy.
The proliferation of TLS 1.3 and variations of the Diffie-Hellman cryptographic protocols has introduced a compulsory resource-intensive HTTPS termination routine directly on the WAF. Thus, the previously available options for installing WAF in the bridge mode or working with a copy of traffic are no longer applicable. WAF must terminate connections and work in full proxy mode. Nevertheless, there are trade-offs for cloud WAFs whereby traffic is not terminated on the WAF, and a log of HTTP requests is sent from the web application/service itself to the WAF for analysis. The functionality of such a WAF is severely limited, and the admissibility of such an approach is either determined by the requirements for application security or remains at the discretion of the team that secures the application/service.
What else cannot NGFW do?
Leading WAF solutions, in addition to the features described above, have the following capabilities that are not available in NGFW products:
⮚ Protection of complex API services, such as GraphQL.
⮚ Detecting automated HTTP clients (bots) and responding to certain categories of automated activity in accordance with the security policy.
⮚ Protection against distributed denial of service attacks at the application level.
⮚ Detection of attempts to bypass CAPTCHA.
⮚ Detection of credential stuffing.
⮚ Redirecting an attacker to a honeypot.
⮚ Creating an API protection policy by uploading a file containing the API description.
This list is selective and is provided to demonstrate the differences between the tasks faced by NGFW and WAF and methods for solving them.
Conclusion
It is safe to say that you need a WAF if your business depends on the sustainability and safety of your public web applications/services that your customers and partners use, especially if you are engaged in e-commerce, or if you are a bank and you, of course, have online banking, as well as in all other cases when information security/performance of your web applications can cause significant financial or reputational losses.
Do not rule out the possibility that you need a WAF for your internal web applications and services. For large geographically dispersed companies, the answer to the question “Do we need a WAF within the network?” in the overwhelming majority of cases is “Yes, we do.” This affirmation, in turn, raises many other questions that must be answered before making a choice in favor of a particular product and a particular WAF deployment model. But that is another story.