Web Application Firewalls with Inbound Routes

VGS + WAF = ❤

The long, complex history of HTTP provides fertile ground for HTTP desync attacks, and there remain no guardrails for application security flaws. Website compromise and data breaches are still common, leading to the loss of revenue and customer trust, as well as lawsuits and even the extinction of many businesses. Therefore, it is essential that web app owners up their security game and invest in a Web Application Firewall (WAF).

Traditional firewalls sit at the network or transport layer of the OSI model, between trusted and untrusted networks. But today, you can deploy a WAF at the highest layer (the application layer), where it sits right in front of your users and data. Both types of firewalls handle access control and network defense, but in unique positions with unique tools and strategies. Working together, they offer your enterprise greater defense-in-depth.

WAFs protect your enterprise against a wide range of attacks that specifically target web apps, including remote code execution, insufficient authentication, exploits, SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), directory traversal, file inclusion, HTTP floods, malicious scanning, and more. Many of these attacks are detailed in the Open Web Application Security Project’s Top 10 Web Application Security Risks.

There are three different types of WAFs: network, host, and cloud. Network and host-based devices are typically located on-premises, while a cloud model is a SaaS solution. There are both commercial and non-commercial WAFs. One open-source WAF, ModSecurity, is a part of OWASP and has its own rule configuration language called “SecRules.” Commercial WAFs vary significantly in price depending on interface, options, requirements, etc. Typical costs are based on the number of rules you configure and the number of HTTP requests you receive. All things considered, we believe that most VGS customers would be best served with a cloud-based WAF.

How does a WAF work?

A WAF intercepts and inspects inbound web requests (HTTP/HTTPS) to detect and prevent malicious traffic from reaching your web apps. WAFs are powerful and can dig deep into network packets to evaluate what is inside the payload. They can parse data, identify malicious signatures, and evaluate suspicious behavior. All of this is necessary to recognize and stop sophisticated network attacks.

A web request must adhere to your security rules, often called policies, or it does not get permission to touch your web app. As with traditional firewalls, WAFs can make decisions based on “positive” or “negative” logic. Positive security policies, such as an allowlist, typically run first and may allow only a certain type of inbound request or from a certain location (or both). Negative security policies, which usually run second, can block an inbound request that matches a malicious signature (e.g., SQL injection) or an attempted denial-of-service.

Each strategy has its strengths and weaknesses, and it is often necessary to leverage both. However, you are highly encouraged to create allowlists because they are designed to deny everything except that which is specifically allowed. They also consume fewer resources than a blacklist and go a long way toward preventing zero-day exploits.

WAF Configuration

A WAF has three components:

1. Conditions: the characteristics of an inbound web request used for decision-making, such as source IP address, hostname, geography, time, or type of attack (e.g., XSS).

2. Rules: with boolean logic, you tell your WAF what to do, including whether to stop the request or simply alert on specific behavior.

3. Web access control list (ACL): “A B C” stands for allow, block, or count (the latter is used for rate-based rules, in which you allow a maximum number of requests matching specific criteria, and then block the rest).

WAF rule sets can quickly become long and complicated. There are many sketchy IP addresses out there and thousands of malicious signatures to consider. The attack space is constantly growing, and hackers have the incentive to innovate. With rate-based defenses, it can be difficult to stop offensive behavior without creating your own denial-of-service in the process.

In spite of these challenges, help is never too far away. Some WAF providers offer pre-built templates to get you started. The open-source ModSecurity WAF Core Rule Set covers many popular web apps and common threats, and offers a high level of security for Apache web servers. One of the strengths of a WAF is the ability to modify policies quickly; for example, in the event of a DDoS attack, rate limiting can be set to slow the barrage.

Finally, WAFs have a transparent mode and a proxy mode. In the first case, a WAF sends web requests directly to the web application. In the latter, a WAF provides additional protection to the server by acting as an intermediary hop -- which can increase security, but unfortunately also increase latency.

Testing & Remediation

Due to the size, speed, and complexity of today’s networks, security can be hard to achieve and is always a moving target. You must continually test your WAF configuration. Vulnerability scanners and penetration testing can find software coding errors and discover unknown vulnerabilities.

Many web apps can be quite unique, with their own intrinsic vulnerabilities and exploits. Furthermore, enterprises often have numerous web apps to protect.

Positive rules are highly restrictive, but can be a challenge to create and maintain. Negative rules are often complex and voluminous, result in a high number of false positives, and still have trouble identifying every malicious web request.

Hackers engage in numerous strategies to bypass WAFs. Here are some examples:

1. Pre-processor exploitation: deceiving a WAF into skipping input validation

2. Impedance mismatch: a WAF interprets input differently than the backend

3. Rule-set bypassing: sending payloads undetectable by a WAF

Once security vulnerabilities become known, it is critical to fix them, and the sooner, the better. For some hard-to-kill bugs, it may be necessary to apply virtual patches or immediate but temporary fixes.

For any modern enterprise, a WAF plays a vital role in a cloud-based defense-in-depth security strategy. Not only does it protect against malicious web traffic and hedge against web app vulnerabilities, but it also helps to fulfill information security guidelines and compliance requirements such as PCI DSS and SOC2. And as a bonus, filtering out all of that junk traffic can reduce costs and improve your customer user experience.

WAF Placement

One of the most important configuration questions you will face is whether to place your WAF in front of VGS or behind. Whichever placement you choose, there will be benefits, drawbacks, and tradeoffs. Fortunately, the VGS proxy protocol is both secure and flexible, allowing you to tailor your architecture in a way that best suits your needs.

A good way to approach this question is to consider exactly how you want your clients to interact with your backend. You know your enterprise and web apps best, and only you can fine-tune all of the options to their ideal state. That said, in the end, a major determinant will be which type of WAF you choose: network, host, or cloud-based.

VGS First

Network- and host-based WAFs are on-premises, co-located with your backend. In this scenario, your WAF is your primary ingress, and you are already familiar with its role in protecting your backend services. Therefore, we recommend that you maintain this architecture, as you can easily route your traffic through the VGS proxy first.

By putting VGS first, you take advantage of numerous VGS security features. This includes our default capability to rate-limit traffic, which significantly helps to minimize the harmful effects of a denial-of-service and is typically a feature for which WAF providers add a surcharge. Furthermore, VGS provides other types of traffic restrictions, such as IP allowlisting, in which only specific, pre-authorized source IP addresses have the right to access your backend.

WAF First

Now let’s consider a cloud- or SaaS-based WAF. In this scenario, your WAF is the edge ingress, has initial access to the unredacted web requests, and restricts traffic before it routes to VGS. Thus, VGS sits behind your WAF but in front of your backend. This architecture has some significant design advantages -- as well as some important caveats.

First, VGS customers should take advantage of our IP allowlisting feature. Depending on your cloud WAF implementation, the request routing to VGS may be known, or it could be hidden. This could happen, for example, when the route is configured with a DNS CNAME (and even if you do not use a CNAME, your vault DNS is not expected to be a secret). Thus, allowlisting is an important part of securing your APIs, as specifying your WAF egress IPs helps to ensure that your WAF is not easily bypassed. Most WAF providers provide easy access to their egress IPs (e.g., Cloudflare: https://www.cloudflare.com/ips/).

Second, placing your WAF first is a smart choice for VGS clients because VGS currently does not have the capacity of a global content delivery network (CDN). SSL termination points that are physically closer to the end user dramatically improve connection speeds. A global CDN can improve user experience via faster initial connections and SSL handshakes that normally require multiple back-and-forth requests and response messages, which can lead to significant latency.

Third, if your WAF sits in front of VGS, your WAF must process the web requests first and perform the rate limiting. The simple reason is that VGS cannot determine the original source of the requests. Therefore, you should inform VGS so that we can disable this vault feature. This is necessary to avoid a VGS rate limit against the WAF (which would include the traffic of all your clients combined).

Fourth, when your WAF is in front of VGS, your WAF vendor is now within your compliance scope. Because the WAF must perform SSL termination, your WAF provider will see the sensitive contents of your web requests before VGS has had a chance to alias them. However, there are many great cloud-based WAF providers with strong compliance certifications, so make sure you choose one aligned with your organization’s compliance goals.

Better Visibility = Increased Security

Whichever configuration you choose, the goal is the same: better visibility into your web requests and increased security for your enterprise.

If you have an on-prem WAF (and VGS processes your web requests first), VGS will provide you with an accurate source IP in the X-Real-IP request header. Please ensure that your on-prem WAF or other ingress does not replace this field with a VGS egress IP. Additionally, VGS provides the X-Forward-For in the header, but this must be used with caution, as an attacker can append new, incorrect values to this field.

If your WAF sits in front of VGS and proxies web requests through VGS, please note that VGS appends the X-Real-IP from your upstream WAF. You can configure your WAF to inject an alternate header, such as X-Forward-For. However, you should only do so if your WAF is capable of ignoring user-supplied values; remember that an attacker may try to hide their origin by specifying an incorrect or fake value in this field. An alternative, if the WAF provides the capability, is to use a new and unique header.

When used in tandem, VGS + WAF integration offers numerous potential advantages for your enterprise. Remember that security is a journey, not a destination, and there is always more to do. If you have any questions, please ask!