We’ve been developing a quite advanced WAF (Web Application Firewall) since 2013. When the first version of the WAF was released, we learnt an important lesson: there is an inevitable trade-off – WAFs are either accurate in their security checks or fast, not the both. Of course good WAF must not pass attacks, i.e. it must run tons of heavy-weight logic to do its tasks well. So it’s not rare to see peak performance for strong WAFs as just like 50Mbps, which surely not enough in modern Internet, especially with IoT in mind. Moreover, due to the low performance, the WAFs are attractive targets for DDoS attack. Having the problems in mind we came to WAF acceleration conception in Tempesta FW design.

A good WAF must deeply analyze HTML and XML, use many regular expressions and complex machine learning technologies. All the things are quite heavy. As an example consider a graph from our study on regular expressions performance for the WAF. The figure at the below shows performance degradation of the WAF, built on top of Nginx, if it runs regular expression rules using the fastest regular expression libraries, PCRE-JIT or Intel HyperScan. That time we came to 15,000 HTTP requests per second on 24 cores, which wasn’t good of course.

Read about more performance issues with modern WAFs in our blog post.

Tempesta FW and an accelerated WAF(s) can work on the same physical or virtual servers as well as on separate servers. Without loss of generality, let’s consider a cluster installation depicted on the figure at the below with one Tempesta FW instance (note that it’s recommended to use 2 mirrored instances for real life installations), 2 WAF instances and 4 backend servers protected by Tempesta FW and the WAFs. Consider also that there are 2 types of backend servers: servers with dynamic (and complex) logic, probably having wide attack surface, and servers with static content, having minimal attack surface thanks to simplicity (or absence) of application logic.

The most straightforward way to setup Tempesta FW as a WAF accelerator is build a hierarchy of reverse proxies, i.e. to configure both Tempesta FW and the WAF as usual reverse proxies communicating thought TCP/IP sockets and HTTP/1.1.

Tempesta FW accelerates the WAF(s) in following ways:

1. TLS offload – accepting HTTPS connections, Tempesta FW terminates TLS. The Linux kernel TLS implementation used by Tempesta FW is more efficient than user-space libraries, so it improves performance of the whole installation in cluster mode as well as in single node case.

2. DDoS mitigation – WAF(s) don’t need to handle malicious DDoS traffic and received DDoS-filtered traffic only.

3. Web cache – some of client requests can be satisfied by Tempesta FW’s cache. Since no server logic queried, there is no need to pass the requests to WAF(s) for verification.

4. WAF bypass – Tempesta FW can schedule requests for static (and safe) content bypassing WAF(s), leaving only request for dynamic logic for WAF(s) analyzing.

5. HTTP rules offloading – WAF(s) can offload complex blocking rules using TCP/IP as well as HTTP rules to Tempesta FW, e.g. exec action for ModSecurity can be used to add a blocking rule to Tempesta FW’s HTTP tables.

Our blog article WAF acceleration describes the accleration features in more details.

Note that since WAF(s) receive client requests from Tempesta FW, not the original clients, then must be configured to analyze X-Forwarded-For header set by Tempesta FW to get client IP addresses.

Setting a powerful WAF behind Tempesta FW you can get high performance, DDoS resistant, and secure installation, unreachable by using only one of the solutions.