The Dashboard Isn't Just Numbers
Your WAF blocks attacks. The Attack Logs tell you what those attacks were, where they came from, and whether any got through. Reading these logs turns random blocks into actionable intelligence.
Anatomy of an Attack Log Entry
When SafeLine blocks an attack, each log entry shows:
Time: 2026-08-06 03:12:45 UTC
Source IP: 185.220.101.34 (Russia)
Target: example.com/login
Attack type: SQL Injection
Payload: admin' OR '1'='1' --
Action: Blocked
Rule: Semantic analysis (score: 98/100)
Everything you need to understand:
- When it happened (3 AM = automated, not targeted)
- Where from (Russia = likely scanner, not a customer)
- What they tried (SQL injection on login = credential bypass)
- Confidence (98/100 = near-certain attack)
How to Read Logs for Patterns (Not Just Events)
One blocked SQL injection is noise. Ten blocked SQL injections from the same IP range, all targeting /api/graphql, at 3 AM — that's a coordinated attack. Here's what to look for:
Pattern 1: Geographic concentration
20+ attacks from Russian IPs -> all targeting /wp-login.php
-> Action: Geo-block Russia if you don't serve that market
Pattern 2: Endpoint targeting
50+ attacks on /api/graphql over 2 hours
-> Action: Add GraphQL-specific rate limiting, review query depth limits
Pattern 3: Payload evolution
Day 1: Basic SQL injection (' OR 1=1)
Day 2: Blind SQL injection (sleep functions)
Day 3: UNION-based injection
-> Action: Attacker is iterating. Block the IP range aggressively.
Pattern 4: Quiet Monday, loud Thursday
Monday: 200 blocked attacks
Thursday: 1,200 blocked attacks
-> This is normal. Attack volume spikes mid-week. Don't freak out.
What to Ignore
Not every log entry matters:
- Single SQL injection probes — scanners try every URL. It'll never work on updated software.
-
/.envrequests — automated scanners looking for Laravel config leaks. If you're not on Laravel, ignore. - Port scans — your WAF only sees HTTP. Port scans hitting closed ports are not your problem.
- WordPress path scans on non-WordPress sites — harmless noise.
What to Act On Immediately
- Multiple failed logins from the same IP — bump up rate limiting on auth endpoints
- Successful logins from unusual locations — this gets through the WAF but should trigger application-level alerts
- Any attack with confidence score > 95 — near-certain actual attack, worth reviewing what they targeted
- Attacks on custom endpoints — someone mapped your API. They know your stack. Take this seriously.
- Data exfiltration patterns — large outbound responses after suspicious POST requests
Using Logs to Tune Your WAF Rules
After 2 weeks of log analysis, here's what I adjusted:
| Finding | Adjustment |
|---|---|
| 80% of attacks from 5 countries | Enabled geo-blocking for those countries |
| Login endpoint hit 300x/day | Added 5/min rate limit |
/api/search scraped by script |
JS challenge for high-frequency search |
Zero attacks on /health
|
Added whitelist (no inspection needed) |
| 3 false positives on webhook receiver | Whitelisted the webhook source IP |
FAQ
How long should I keep attack logs?
At least 30 days. Attack patterns emerge over weeks, not hours. SafeLine uses PostgreSQL for log storage — set retention to 90 days unless you're tight on disk space. Attackers sometimes come back after 2-3 weeks with different techniques.
What's the difference between "Blocked" and "Detected"?
"Blocked" means the request was stopped at the WAF. "Detected" means the WAF flagged it but you're in monitoring mode. Switch to blocking mode once you've confirmed no false positives for your traffic patterns.
Should I report attacks to anyone?
For most small sites: no. Law enforcement won't act on individual attack logs. If you see a coordinated, persistent attack from a specific hosting provider, you can send an abuse report to their network operations team. That occasionally works.
What's the most common attack showing up in your server logs right now?
#security #devops #webdev #monitoring
Top comments (0)