Skip to content

Web Application Firewall Trade Off

Jump to bottom
Thill edited this page Apr 11, 2022 · 3 revisions

Introduction

This trade off aims to study how to implement a WAF in the RS context. A WAF or Web Application Firewall is a security tool positionned in front of web applications. It generally analyses HTTP requests ( OSI level 7 ) and checks that no malicious payloads are embedded in requests. To do so, it compares the HTTP requests with a threat database that contains known patterns (XSS, SQL injections, Remote File Inlusion, Remote Code execution, Reverse shell etc..). As 0-days are often disclosed, the WAF threats databases/rules needs to be updated as quickly as possible to ensure the best security which implies to have an available security team to look after it.

This trade off will presents differents architectures choices to be implemented. For each architecture it will presents products that could be used.

WAF in Apisix

arch1

In this solution, the goal is to embbed the WAF within Apisix that offers a way to implements your own plugins that can be either:

  • Lua plugins (Apisix standard).
  • External plugins, that are developped with others languages and required a "plugin runner" as interface.

The languages supported as externals plugins are the followings:

This architecture could also leads to modify the Apisix container image to add the WAF in it.

Time estimation: 12 day/men.

Pros

  • Free.
  • Open sources solutions to adapt exists.
  • We benifit from cloud provider's load balancer DDOS protection.

Cons

  • The threats database has to be updated regulary by security team.
  • In case of heavy usage, it can cause perfomance issues.
  • Time to integrate in Apisix as no solution currently exists, thus it require to develop it from scratch.
  • External module is a young feature.
  • If the Apisix image is changed, each update of Apisix implies to update this generated image.

Products

Coraza

Welcome to OWASP Coraza Web Application Firewall, OWASP Coraza is a golang enterprise-grade Web Application Firewall framework that supports Modsecurity's seclang language and is 100% compatible with OWASP Core Ruleset.

ModSecurity-nginx connector

The ModSecurity-nginx connector is the connection point between nginx and libmodsecurity (ModSecurity v3). This project provides a communication channel between nginx and libmodsecurity. This connector is required to use LibModSecurity with nginx.

The current Apisix version uses Nginx with Openresty, unfortunately ModSecurity is not available but could be enabled by manipuling the container image. Howerver by making such changes the performances could be demean.

A proposal has been made in order to integrate Modsecurity as a plugin (https://github.com/zenozeng/apisix-plugin-waf).

Sources

Dedicated VM

arch3

In this scenario, we propose to add within the cluster a dedicated VM that will be used as reverse proxy/WAF, analysing HTTP traffic before fowarding to Apisix.

Time estimation: 5 day/men.

Pros

  • Free and open source tools exists.
  • Probably better performances than the first architecture.
  • We benifit from cloud provider's load balancer DDOS protection.

Cons

  • The threats database has to be updated regulary by security team.
  • Costs and maintenance for a dedicated VM.
  • Single Point Of Failure.

Products

ModSecurity

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analys…

ModSecurity can be used as software or as library code, and run under Apache License 2.0. The project is build by SpiderLabs that has recently announced the end of support of Modsecurity for 2024, it will then be fully maintened by open source community.

ModSecurity is the main open source player with 5.3k stars on github.

Sources

Cloud-based WAF

arch2

In this architecture, we propose to fall back on dedicated external actors. In this scenario, all HTTP requests are sent to this external WAF service that will handle the HTTP analysis,before forward them back to the cluster.

Time estimation: 2 day/men.

Pros

  • Simplest solution.
  • Rules are updated by specialized service provider.
  • Performance.
  • Easy rules management.

Cons

  • Potentially paying services.
  • Not open source.
  • Black box.
  • The provider can potentially snif the network traffic.
  • If it's free, you are the product.

Products

Cloudflare

Leader in the WAF (Saas), cloudflare is known to be one of the best WAF. It handle the classic OWASP top 10 attacks and update the threats database at each new zero day discovered. Three packages exists, and the price vary according to the options (20$/month minimum). You’ll need to update your DNS to allow Cloudflare to manage it. This is a simple process that only requires the creation of a new MX and TXT record. Moreover, CloudFlare offers several add-on services that can be purchased to improve the security.

From a recent blog article it seems that the WAF feature could be soon free even for free plan account.

Cloudflare plan
Feature Free Pro Business Enterprise
Active rules 5 20 100 1,000
Supported actions All except Log All except Log All except Log All
Regular expression support No No Yes Yes
Number of IP Lists 1 10 10 10
Minimal Pricing (Add-ons billed monthly) Free 20$ per Month 200$ per Month Requires a quote

Flexible engine WAF

Flexible engine is also presents on the WAF market, and is similar with cloudflare. FE WAF support 3 associations for WAF users.

The following are common scenarios.

  • Using only WAF but DNS for customer application would be outside of FE on some public DNS.
  • Using WAF + DNSaaS which would also configure DNS record in FE DNSaaS.
  • Using WAF + DNSaaS + ECS/CCE which would allow to deploy all the apllication landscape including protection, dns, instances within the FE.

However the pricing startegy is not the same as cloudflare.

Public Pricelist - Flexible Engine Cloud
Domain € per hour per domain
1-2000 0,21€
2001-5000 0,17€
5001-9999999999 0,14€
Requests (€ per million) 0,60€

Sources

Conclusion

The first solution that consist in using a WAF directly in Apisix seems too complicated and hazardous. It requires to use an external open source library such as Coraza (go) and try to interface it with Apisix or to update the Apisix container image in order to integrate Modsecurity. The development/testing endeavour could be heavy for no performances guarantee. Another option consists in waiting for an Apisix plugin as the Apisix community seems to look into solutions for this need.

The second architecture is simpler, nevertheless it required change in the current architecture and introduces somehow a SPOF.

However, the main issue with those two architectures is the maintenance that they require in order to keep WAF rules up to date.

The third architecture is the simplest and can be quickly setted up. This is the one that we recommand. Even if it's not open source and could be paying (according to wished add-on), the main avantage is that it does not require any maintenance and it offers the best expertise.

Clone this wiki locally