ModSecurity and OWASP, managed
A free WAF load balancer you can tune without guessing
ModSecurity with the OWASP Core Rule Set, installed across every node from one page and switched on per site. It starts in watching mode, so the first thing it does is tell you what it would have blocked rather than blocking it.
Why most WAF projects get abandoned
Getting a WAF running is not the hard part. Compiling ModSecurity and pointing it at the OWASP rules is an afternoon. The hard part is the week afterwards, when the rules start refusing things your own application does perfectly legitimately, and you have no good way to tell a real attack from a false alarm.
What usually happens next is that somebody turns it off, or turns the rules down so far that it stops catching anything. Both of those are worse than never having started, because now there is a WAF on the box and everybody believes it is doing something.
The trap
A WAF switched straight into blocking mode on a real site will refuse something important within about a day, usually a file upload or an admin form with rich text in it. The person who finds it will be a customer.
The way round it
- Watching mode first. A new site starts here. Every rule that would have fired is recorded and nothing is refused. Run it for a week on real traffic.
- Read what fired. The page shows which rules triggered, on which paths, and how often. Patterns show up quickly: one noisy rule on one form is a false alarm, a hundred different rules from one address is somebody scanning you.
- Run a learning session. Give it your testers' addresses, have them use the site properly, and every rule that fires against them is a candidate exception. Tick the ones that were your own application and save them.
- Turn on blocking. Start with known malicious traffic only, then move to the full attack rules once the noise is gone.
- Save it as a profile and point your other similar sites at it, so the tuning is done once rather than per site.
The four modes
| Mode | What it does | When to use it |
|---|---|---|
| Off | Nothing. | A site where the WAF has proved to be more trouble than it is worth. |
| Watching, refuse nothing | Logs what would have been refused. | Always, first. For at least a week. |
| Block known malicious | Refuses the high confidence attacks only. | A good permanent home for a site you cannot risk breaking. |
| Block what the attack rules catch | The full rule set, enforcing. | Once the false alarms are tuned out. |
There is a second control alongside it called the allowed surface, which works the opposite way round. Instead of listing what is forbidden, it learns which paths your application actually uses and can refuse anything outside that. It also has a report only setting, for the same reason.
It is a fleet feature, not a per box one
The rule set is installed on every node from one page, and it follows the version track you pick: long term support, which is the sensible default, or latest release. New versions can be fetched on a schedule.
Site settings replicate like everything else, so a site that is blocking on one node is blocking on all of them. There is no scenario where a visitor gets a different security posture depending on which node answered.
What a WAF is not
It is one layer. It will not fix an application with a real hole in it, it will not stop somebody who has valid credentials, and it is not a reason to skip patching. Anybody selling a WAF as a substitute for fixing your code is selling you something.
What it does buy you is time. When a widely exploited hole turns up in something you run, a tuned WAF often blocks the common exploit attempts before you have finished reading the advisory. That gap is where it earns its keep.
Web application firewall
ModSecurity with the OWASP Core Rule Set, per site.
Read moreWAF learning sessions
Watch real testing, then keep only the exceptions you need.
Read moreWAF profiles
One tuned rule set shared by every site that needs it.
Read moreLogin watch
Catch password spraying, not just brute force.
Read moreCountry blocking
Cut scanner noise and meet a rule about where you serve.
Read moreAccess lists
Who may reach a site, by address, with a password on top.
Read moreQuestions people ask
Is this really a free WAF loadbalancer?
Yes. ModSecurity and the OWASP Core Rule Set are both open source, and the layer that installs, tunes and manages them is MIT licensed with no paid tier. The usual price of a managed WAF is somewhere between a few hundred and a few thousand a month. This is the same rule set with a management layer on top, for nothing.
Will the WAF break my application?
It can, which is why it does not start in blocking mode. A new site begins in watching mode, where every rule that would have fired is logged and nothing is refused. You look at what fired on real traffic, decide what is a genuine attack and what is your own application, and only then turn on blocking.
What is a learning session?
You give it the addresses your testers will come from and a name for the round. Testers then use the site normally while every rule that fires against them is recorded. At the end you see a list of what fired, tick the ones that were your own application behaving normally, and save those as exceptions. The tuning comes from real use rather than from guessing.
What does the WAF cost in performance?
Expect single digit percentage overhead on processor for typical traffic, and a small amount of extra latency per request. The heavier cost is memory during rule loading. On a machine sized for the traffic it is not the thing you will notice first.
Can I run it on some sites and not others?
Yes. It is per site, and each site can be off, watching, blocking only known malicious traffic, or blocking everything the attack rules catch. A tuned rule set can also be saved as a profile and shared by several sites, so you tune once.
Start it in watching mode
Ubuntu 22.04 or newer, root access, and about twenty minutes. The installer does the rest and it is safe to run twice.