Written by

We had deployed on our pro­duc­tion servers a new ver­sion of our HTTP reverse-proxy engine. It embeds a lot of new fea­tures. We cov­er them in this col­lec­tion of blog posts.

Here, we want to intro­duce you to the Web Application Firewall (WAF) that is now built-in our reverse-proxy.

What’s a WAF?

All soft­ware have bugs. It’s even true for web appli­ca­tions. They may present secu­ri­ty holes, that may com­pro­mise their integri­ty. Attackers may want to get a full-con­trol over the web appli­ca­tion. We call this kind of attack an infec­tion. If they com­pro­mise the ser­vice by itself, the con­se­quences may be dra­mat­ic, from a sim­ple unavail­able web­site to a leak of per­son­al data.

Cybersecurity is a full-time job. By fol­low­ing some good prac­tices, and by using a WAF, you may increase your secu­ri­ty lev­el. Good news! We now embed it direct­ly inside our infra­struc­ture, and using it is as sim­ple as a click.

Gandalf GIF @Giphy

A Web Application Firewall is a fire­wall that pro­tects your web­site from mali­cious requests. It pars­es the HTTP(s) requests and allows or deny them to access the serv­er. It can block, alert or put in quar­an­tine some of them if it con­sid­ers it as mali­cious. It can also react to many attacks, to lim­it infections.

The request goes through the WAF to be analyzed. The firewall then decides to let the request go to the upstream server or to drop or isolate it (illustration)
The HTTP request goes through the WAF (icons from The Noun Project)

Modsecurity WAF

Instead of devel­op­ing a new solu­tion from scratch, we choose the ModSecurity WAF, devel­oped by Trustwave SpiderLabs. This project has an excel­lent rep­u­ta­tion con­cern­ing secu­ri­ty. It’s also an open source project, so we can stick to our pol­i­cy to give you a host­ing plat­form only pow­ered by open source solu­tions. Finally, the ModSecurity com­mu­ni­ty is very active, and it increas­es the way the project evolves day-by-day.

ModSecurity is only a secu­ri­ty engine. It uses some set of rules to ana­lyze a request and mark it as mali­cious or not. We chose to use the open source rule­set from OWASP ModSecurity Core Rule Set (CRS) which offer an excel­lent lev­el of pro­tec­tion for web appli­ca­tions. It also imple­ments the OWASP Top 10 with a shal­low lev­el of false-positive.

Configuring a WAF at alwaysdata

For a high con­ve­nience, the built-in WAF is avail­able for every web­site host­ed at always­da­ta individually.

You find six pro­files with var­i­ous lev­els of protection:

  1. Disabled
  2. Basic
    • Force strict HTTP protocol
    • Detect mali­cious bots
  3. Strong
  4. Full
    • Strong pro­file
    • Detect attacks for PHP language
    • Detect attacks by Local File Injection (LFI)
    • Detect attacks by Remote File Injection (RFI)
  5. WordPress
    • Full pro­file
    • A WordPress’ spe­cif­ic ruleset
  6. Drupal
    • Full pro­file
    • A Drupal’s spe­cif­ic ruleset 

Please note that acti­vat­ing your WAF may increase the laten­cy time for every HTTP(s) request. This laten­cy (about a few ms) increas­es with the robust­ness of the select­ed pro­file. It’s due to the pars­ing time of the request which increas­es with the num­ber of OWASP rules to apply.

To use it, select a pro­tec­tion pro­file in the Sites → Edit → WAF section.

Screenshot of the interface allowing you to enable the WAF in your web site

This fea­ture is in a beta state yet.

It’s our objec­tive to give you a reli­able, robust and safe envi­ron­ment for your host­ing, with­out a mess of com­plex­i­ty. That’s why we want to give you a sol­id built-in WAF that you can enable with a sim­ple click.

After secu­ri­ty, per­for­mance! In our next blog post, we intro­duce you to our new HTTP cache and its impact on your web­sites delivery.