Week 1: The Scanner Flood
Within 24 hours of going live, the WAF started blocking automated scanners. Not targeted attacks — just internet background radiation hitting anything with a public IP.
Week 1 stats:
- Total requests inspected: ~180,000
- Blocked: 2,847
- Top sources: USA (34%), China (22%), Russia (15%)
- Most common: Path traversal (
/wp-admin,/.env,/.git/config), SQL injection probes, XML-RPC brute force
These were all automated. Nobody was personally targeting this site. If you have a public IP, this traffic is hitting you right now whether you see it or not.
Week 2: Patterns Emerge
The same IPs came back. The same endpoints got probed. The WAF started recognizing scanner fingerprints — Nuclei, sqlmap, Nikto — and blocking them preemptively. Custom rules I'd written in week 1 for things specific to my app stopped triggering warnings because the attack patterns had been learned and were now handled silently.
Week 2 stats:
- New blocked: 1,920
- Repeat offenders flagged: 412
- False positives: 3 (all legitimate requests with SQL-like data in query params, whitelisted the endpoint)
Three false positives in two weeks. Compare that to ModSecurity, where you'd spend week one tuning out false positives on login forms and content editors before you felt comfortable turning blocking on. SafeLine's semantic analysis was blocking attacks that first day, without breaking anything.
Week 3-4: Quiet
Attack volume dropped because persistent scanner IPs were automatically blacklisted after repeated violations. The WAF learned which traffic patterns were normal for this specific site and stopped flagging borderline cases.
Month-end totals:
- Requests inspected: ~720,000
- Total blocked: 6,203
- False positives: 5 (all resolved with per-endpoint exceptions)
- Zero successful attacks confirmed
The site sat behind the WAF, origin IP hidden, getting probed constantly and ignoring all of it.
Data Privacy in Practice
This is where self-hosting matters. Every blocked request, every attack signature, every IP address — it's all on my server. No third party has access to traffic data. No vendor can analyze my traffic patterns for product improvement. No risk of a Cloudflare-like incident where a misconfiguration exposes customer data across accounts.
The data stays local. Logs rotate. And if I need forensic analysis, I have the raw request payloads.
For a personal site, this is nice. For a business handling customer data under GDPR or HIPAA, it's the only compliant approach.
What This Means for You
If you run a website without a WAF, this traffic is reaching your app. Your web server is processing every SQL injection probe, every path traversal scanner, every brute-force login attempt. Your application may be handling them correctly — or it may not be.
A WAF doesn't prevent attacks from existing. It prevents them from reaching anything that matters. It takes the background radiation of the internet and stops it at the gate, instead of letting it knock on every door inside.
FAQ
Do I really get attacked that much?
If your site has a public IP, yes. Most of it is automated scanning, not targeted attacks. But automated scanning is exactly how vulnerabilities get exploited — scanners find the hole, then the attacker comes back manually. Blocking the scanners prevents the follow-up.
What about legitimate traffic from blocked countries?
Geo-blocking is configurable per site and per rule. Block the countries you definitely don't serve, and monitor for false positives from the edge cases. If a real user from a blocked region complains, you whitelist their IP or adjust the rule. In practice, most small sites don't get legitimate traffic from every country.
How do I know if the WAF is blocking real attacks or just noise?
Check the payload. Path traversal probes for /wp-admin on a site that doesn't run WordPress are noise. SQL injection payloads that match known attack patterns are real threats, whether targeted or automated. The WAF blocks both — and you can review the logs to distinguish.
Try SafeLine Community Edition — free, self-hosted, and takes 5 minutes to deploy:
bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en
Dashboard: https://<your-server-ip>:9443 | Docs
How long has your current site been running without a WAF, and have you ever checked your server logs for attack attempts?
Top comments (0)