We had deployed on our production servers a new version of our HTTP reverse-proxy engine. It embeds a lot of new features. We cover them in this collection of blog posts.
Here, we want to introduce you to the Web Application Firewall (WAF) that is now built-in our reverse-proxy.
What’s a WAF?
All software have bugs. It’s even true for web applications. They may present security holes, that may compromise their integrity. Attackers may want to get a full-control over the web application. We call this kind of attack an infection. If they compromise the service by itself, the consequences may be dramatic, from a simple unavailable website to a leak of personal data.
Cybersecurity is a full-time job. By following some good practices, and by using a WAF, you may increase your security level. Good news! We now embed it directly inside our infrastructure, and using it is as simple as a click.
A Web Application Firewall is a firewall that protects your website from malicious requests. It parses the HTTP(s) requests and allows or deny them to access the server. It can block, alert or put in quarantine some of them if it considers it as malicious. It can also react to many attacks, to limit infections.
Modsecurity WAF
Instead of developing a new solution from scratch, we choose the ModSecurity WAF, developed by Trustwave SpiderLabs. This project has an excellent reputation concerning security. It’s also an open source project, so we can stick to our policy to give you a hosting platform only powered by open source solutions. Finally, the ModSecurity community is very active, and it increases the way the project evolves day-by-day.
ModSecurity is only a security engine. It uses some set of rules to analyze a request and mark it as malicious or not. We chose to use the open source ruleset from OWASP ModSecurity Core Rule Set (CRS) which offer an excellent level of protection for web applications. It also implements the OWASP Top 10 with a shallow level of false-positive.
Configuring a WAF at alwaysdata
For a high convenience, the built-in WAF is available for every website hosted at alwaysdata individually.
You find six profiles with various levels of protection:
- Disabled
- Basic
- Force strict HTTP protocol
- Detect malicious bots
- Strong
- Basic profile
- Detect Remote Code Execution (RCE)
- Detect Cross-Site Scripting (XSS) attacks
- Detect SQL Injections
- Full
- Strong profile
- Detect attacks for PHP language
- Detect attacks by Local File Injection (LFI)
- Detect attacks by Remote File Injection (RFI)
- WordPress
- Full profile
- A WordPress’ specific ruleset
- Drupal
- Full profile
- A Drupal’s specific ruleset
Please note that activating your WAF may increase the latency time for every HTTP(s) request. This latency (about a few ms) increases with the robustness of the selected profile. It’s due to the parsing time of the request which increases with the number of OWASP rules to apply.
To use it, select a protection profile in the Sites → Edit → WAF section.
This feature is in a beta state yet.
It’s our objective to give you a reliable, robust and safe environment for your hosting, without a mess of complexity. That’s why we want to give you a solid built-in WAF that you can enable with a simple click.
After security, performance! In our next blog post, we introduce you to our new HTTP cache and its impact on your websites delivery.
Hello,
Thanks, exactly what I need. I put the WAF in strong mode after discovering these kind of entries in my HTTP logs :
54.235.163.229 — - [30/Jan/2019:17:35:45 +0100] “GET /ncbook/ncbook.cgi?action=default¤t=|cat%20/etc/passwd|&form_tid=996604045&prev=main.html&list_message_index=10 HTTP/1.1” 403 22 “-” “Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8)”
403 forbidden error because I put an IP filter middleware in my webapp.
Is the feature still in Beta? I will tell you if the WAF stops correctly this kind of bot.
Regards
It’s still in beta, but is now working pretty well. We have added new options to exclude rules, paths, and soon IP addresses from the WAF.
And can we access the logs of the WAF to check the rejected requests?
Regards
Yes, in ~/admin/logs/sites.