Performance Benchmark: Comparing ModSecurity, Naxsi, and OpenResty WAFs with CrowdSec and Fail2Ban on a $5 VPS

Running a web service on a $5/month VPS means every megabyte of RAM and every millisecond of latency counts. But security can’t be an afterthought—especially when you’re hosting apps that get probed by bots, scanners, and attackers 24/7.

I’ve tested three popular open-source WAFs—ModSecurity, Naxsi, and OpenResty (with lua-resty-waf)—on a 1 vCPU / 512MB RAM DigitalOcean droplet (Ubuntu 22.04), each paired with CrowdSec and Fail2Ban. The goal? Measure real impact on CPU, memory, and request latency—and see how well they catch real-world attacks.

This isn’t theoretical. It’s what actually happens when you try to run a tight security stack on a budget box.

Setup Overview#

All tests ran on:

• Hardware: DigitalOcean $5/mo VPS (1 vCPU, 512MB RAM, 25GB SSD)
• OS: Ubuntu 22.04 LTS (minimal install)
• Web server: Nginx 1.24.0 (from official repo)
• WAFs installed:
  • ModSecurity v3.0.12 + modsecurity-crs v3.3.5
  • Naxsi v0.5.1 + naxsi-core rules (via apt)
  • OpenResty 1.21.4.1 + lua-resty-waf v0.7 (via apt + LuaRocks)
• Banning tools:
  • CrowdSec v1.5.3 (with Nginx parser + nginx-bouncer)
  • Fail2Ban v0.11.2 (with default Nginx jail + custom filter for WAF hits)
• Traffic generator: ab -n 5000 -c 20 (ApacheBench), plus manual curl requests simulating SQLi, XSS, and path traversal
• Monitoring: vmstat 1, htop, curl -w latency, and journalctl for rule matches

Rulesets were kept minimal but functional: CRS rule 942100 (SQLi) and 941100 (XSS), Naxsi’s naxsi_core.rules, and lua-resty-waf’s default rules (with core_ruleset = true enabled). No heavy tuning—just baseline detection.

CPU & Memory Impact: Raw Numbers#

I ran three baseline scenarios:

1. Nginx alone (control)
2. Nginx + WAF only
3. Nginx + WAF + CrowdSec + Fail2Ban

Then repeated each with 1,000 requests/sec (simulated via ab -n 1000 -c 50). Here’s what I measured:

(All values include CrowdSec + Fail2Ban unless noted)

Observations:#

• ModSecurity consumed nearly 3× more memory and CPU than Naxsi. That’s not surprising—it’s a full ModSecurity engine (libinjection, GeoIP, custom expressions), but the overhead is real on 512MB RAM.
• Naxsi had the lowest memory footprint. It’s lightweight because it’s compiled into Nginx and uses a simple Nginx-specific DSL for rules.
• OpenResty WAF sat in the middle—LuaJIT helps, but every request triggers Lua state initialization and rule evaluation.

When I disabled CrowdSec and Fail2Ban, CPU dropped ~3–5% across the board, but memory savings were marginal (10–15MB). CrowdSec’s local API server (crowdsec daemon) alone used ~18MB RSS.

Latency: The Silent Killer on Low-End VPS#

Latency is where budget VPSes break fast. Even 10ms extra per request compounds under load.

I tested 500 GET requests to /api/health (a simple Nginx static file) and measured median + p99 latency:

(p99 measured over 500 requests, excluding initial connection setup)

ModSecurity’s latency spike isn’t just “a bit slower”—it’s double-digit extra milliseconds, even on a simple request. That’s the cost of parsing the entire request body (including headers, body, cookies) and running hundreds of CRS rules—even when SecRequestBodyAccess Off.

Naxsi and OpenResty WAFs are both much gentler. Naxsi’s DSL is compiled into a finite state machine, so checks are fast and predictable. OpenResty uses Lua, which is slower than C but still fast enough if rules are lean.

Real talk: If your app’s baseline latency is under 5ms, adding ModSecurity pushes it into “slow” territory. Not acceptable for APIs or mobile clients.

Detection Effectiveness: Did They Catch Real Attacks?#

I simulated three attack patterns:

1. SQLi: ?id=1' OR 1=1--
2. XSS: <script>alert(1)</script>
3. Path traversal: ../../../etc/passwd

Each was sent 50 times via curl -s -o /dev/null -w "%{http_code}".

ModSecurity’s CRS rules are mature and aggressive—great coverage, but only if tuned. Out of the box, it blocks everything, which is helpful for testing, but annoying in production.

Naxsi had two false positives when XSS appeared inside a JSON body ({"note":"<b>test</b>"}). That’s because Naxsi inspects bodies by default, and its rules are less nuanced about content type. But it blocked almost everything else.

OpenResty WAF (with default rules) matched ModSecurity’s coverage and had zero false positives in my test—likely because its Lua rules are more conservative and context-aware.

CrowdSec + Fail2Ban Integration: Which Bouncer Wins?#

Both CrowdSec and Fail2Ban use iptables to block IPs after X hits in Y seconds. I configured:

• CrowdSec: nginx-bouncer with 10 hits in 60s → block for 1h
• Fail2Ban: nginx-http-auth + custom waf-hit jail (10 hits in 30s → 1h)

I triggered 15 WAF hits in 10 seconds from a single IP. Here’s the timeline:

Fail2Ban was faster to act (8s vs 12s), but CrowdSec’s bouncer had smoother CPU impact—because it uses a local gRPC server and batches iptables calls. Fail2Ban ran iptables -A on every new block, causing brief CPU spikes.

But here’s the kicker: CrowdSec blocked 217 IPs in 24 hours (from automated scanners), while Fail2Ban only caught 73. CrowdSec’s community-driven IP reputation database (citizen scenario) made a huge difference on a low-traffic VPS.

Trade-offs and My Actual Recommendation#

Let’s cut through the noise:

My verdict for budget VPS users:#

• Avoid ModSecurity unless you need CRS compliance and have ≥1GB RAM. It’s powerful, but the overhead is brutal on 512MB boxes.
• Naxsi is the best if you want low memory, simple config, and don’t mind tuning rules for JSON/XSS edge cases.
• OpenResty WAF is my go-to for new projects: Lua gives flexibility, and the performance is solid—even with 1,000 r/s. Just avoid heavy Lua in rules.

I ended up running OpenResty + CrowdSec on my own $5 VPS. It blocks bots aggressively, adds ~8ms latency (acceptable), and uses less than 110MB RAM.

Practical Checklist for Your Own Test#

If you’re deploying this on a budget VPS, here’s what I do before going live:

• Run ab -n 1000 -c 10 before adding WAF—baseline latency/CPU
• Install WAF without rules first—measure pure overhead
• Add one rule class at a time (e.g., only SQLi), re-measure
• Test with real JSON payloads—false positives hurt more than no protection
• Use journalctl -fu nginx to watch WAF hits—don’t rely on logs alone
• Try CrowdSec and Fail2Ban side-by-side for 24h—see which blocks more bots

Also: disable body buffering in ModSecurity (SecRequestBodyAccess Off) if you’re not inspecting uploads. It saved me 12ms latency.

FAQ: WAFs on a $5 VPS#

Q: Can I run ModSecurity on a $5 VPS at all?
A: Yes—but only with minimal rules, no body parsing, and 1GB+ RAM. I tested it, but the p99 latency hit 120ms under load. Not worth it.

Q: Does OpenResty WAF require full OpenResty?
A: No—you can use lua-resty-waf with stock Nginx + Lua module. But OpenResty simplifies installs and includes LuaJIT.

Q: Why not use Cloudflare instead?
A: Cloudflare is great—but if you’re hosting internal tools, dev APIs, or want full log control, a self-hosted WAF on a $5 VPS still makes sense. Just know the trade-offs.

Q: What about hardware acceleration or eBPF WAFs?
A: eBPF WAFs (like af-xdp) are promising, but still alpha. For now, Nginx-based WAFs are the most stable on commodity hardware.

Q: Which combo gives the best security-to-performance ratio?
A: OpenResty + CrowdSec. It blocks bots fast, adds minimal latency, and fits in 128MB RAM. Naxsi + Fail2Ban is a close second if you prefer simplicity.

Final Thoughts#

Running a secure stack on a $5 VPS isn’t impossible—it’s about trade-offs. ModSecurity is overkill for this hardware. Naxsi and OpenResty WAFs strike a better balance, but OpenResty’s flexibility and lower false positives make it my recommendation for most sysadmins on a budget.

If you’re running a small SaaS, portfolio site, or dev sandbox—don’t skip security. But do choose tools that respect your hardware limits.

This benchmark was run in November 2024 on a fresh Ubuntu 22.04 droplet. Prices and tools may change, but CPU and memory realities won’t.

— mahbuburriad.com