Listen to this Post
Introduction:
A Web Application Firewall (WAF) is far more than a simple “block bad traffic” tool—it is a critical layer of defense that inspects HTTP/S headers, cookies, JSON payloads, and API requests to detect and mitigate common web attacks. For SOC analysts, mastering WAF investigation workflows enables faster triage of SQL injection, cross-site scripting (XSS), remote code execution (RCE), local/remote file inclusion (LFI/RFI), botnets, and DDoS attempts, while reducing false positives through automation and tuning.
Learning Objectives:
- Analyze WAF logs to identify attack patterns (payloads, user-agent anomalies, geo‑location spikes) and differentiate between automated scans and manual exploitation.
- Implement custom WAF rules for login pages, admin panels, and APIs using ModSecurity Core Rule Set (CRS) or cloud-native policies.
- Automate incident response actions—IP blocking, CAPTCHA challenges, session termination—based on real-time WAF alerts and rate anomalies.
You Should Know:
- Inspecting HTTP/S Traffic and WAF Logs – A Step‑by‑Step Guide
WAF logs are typically stored in JSON, syslog, or custom CSV formats. To extract actionable intelligence, you need command-line fu on both Linux and Windows.
Linux (using `jq`, `grep`, `awk`)
Assume a log line:
`{“time”:”2026-05-16T10:00:00Z”,”src_ip”:”45.33.22.11″,”method”:”POST”,”url”:”/login.php”,”status”:403,”payload”:”‘ OR ‘1’=’1″,”rule_id”:942100}`
Extract all SQLi attempts (rule_id 942100-942199)
cat waf.log | jq 'select(.rule_id | startswith("942")) | {src_ip, url, payload}'
Count unique attacking IPs
cat waf.log | jq -r '.src_ip' | sort | uniq -c | sort -nr | head -10
Find spikes in 403/406 status codes per minute
cat waf.log | awk -F'"' '{print $4}' | cut -d: -f1,2 | sort | uniq -c
Windows (PowerShell)
Import JSON logs and filter for XSS attempts (rule_id 941100-941199)
Get-Content .\waf.log | ConvertFrom-Json | Where-Object { $_.rule_id -match '941' } | Select-Object src_ip, url, payload
Group by IP and show top attackers
Get-Content .\waf.log | ConvertFrom-Json | Group-Object src_ip | Select-Object Name, Count | Sort-Object Count -Descending | Select-Object -First 10
What this does: Quickly identifies the most active attack sources, targets, and payload types. Use these commands during the first five minutes of an alert to decide whether to block an IP or escalate to incident response.
- Blocking SQL Injection & XSS – Enabling and Tuning ModSecurity CRS
Most open‑source WAFs (like ModSecurity with Apache/Nginx) use the OWASP Core Rule Set. Here’s how to enable it and add custom blocking logic.
Step 1 – Install ModSecurity and CRS (Ubuntu 22.04)
sudo apt update && sudo apt install libapache2-mod-security2 -y sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf sudo git clone https://github.com/coreruleset/coreruleset.git /usr/share/modsecurity-crs sudo cp /usr/share/modsecurity-crs/crs-setup.conf.example /usr/share/modsecurity-crs/crs-setup.conf
Step 2 – Configure CRS to block SQLi and XSS
Edit `/etc/modsecurity/crs-setup.conf` and set:
SecAction "id:900000, phase:1, nolog, pass, t:none, setvar:tx.detection_paranoia_level=2" SecAction "id:900100, phase:1, nolog, pass, t:none, setvar:tx.executing_paranoia_level=2"
Step 3 – Test a blocked SQLi payload
curl -X POST "http://localhost/login.php" -d "user=admin' OR '1'='1&pass=x" Expected response: 403 Forbidden with a ModSecurity error page
Tuning to reduce false positives – Monitor `/var/log/modsec_audit.log` for legitimate requests that trigger rules, then add `ctl:ruleRemoveById=942100` in a custom rule file for that specific URL.
3. Monitoring Request Rate, Geolocation & Reputation Scores
Combine WAF logs with external intelligence to block abusive scanners. Use `fail2ban` for rate‑based blocking, and `geoiplookup` for country‑specific actions.
Step‑by‑step rate monitoring with `fail2ban`
Create `/etc/fail2ban/jail.d/waf.conf`:
[waf-403] enabled = true logpath = /var/log/modsec_audit.log filter = waf-403 maxretry = 5 findtime = 60 bantime = 3600 action = iptables-multiport[name=WAF, port="http,https", protocol=tcp]
Create filter `/etc/fail2ban/filter.d/waf-403.conf`:
[bash] failregex = ^.[client <HOST>] ModSecurity:.Access denied.$
Restart fail2ban: `sudo systemctl restart fail2ban`
Geolocation blocking (Linux)
Get country code for an attacking IP
geoiplookup 45.33.22.11 | awk -F': ' '{print $2}'
Block all traffic from a suspicious country using iptables
sudo iptables -A INPUT -m geoip --src-cc RU,CN,KP -j DROP
For cloud WAF (AWS WAF, Cloudflare), export logs to S3 and use Athena queries:
SELECT src_ip, COUNT() as requests, country FROM waf_logs WHERE action='BLOCK' AND timestamp > now() - interval '1' hour GROUP BY src_ip, country ORDER BY requests DESC;
- Creating Practical Rules for Login Pages, Admin Panels & APIs
Attackers focus on/admin,/api/v1/login, and/wp-admin. Create custom rules that block suspicious patterns without breaking legitimate traffic.
ModSecurity custom rule – block sequential admin page scans
SecRule REQUEST_URI "@rx ^/(admin|wp-admin|manager)" "phase:1,id:10001,msg:'Admin Panel Scan Detected',setvar:tx.admin_scan_count=+1,expirevar:tx.admin_scan_count=10" SecRule TX:ADMIN_SCAN_COUNT "@gt 3" "phase:1,id:10002,deny,status:403,msg:'Admin Panel Scan Blocked'"
API‑specific rule – enforce JSON content type and block oversized payloads
SecRule REQUEST_HEADERS:Content-Type "!@streq application/json" "phase:1,id:10003,deny,status:415,msg:'Invalid Content-Type for API'" SecRule REQUEST_BODY "@gt 1048576" "phase:2,id:10004,deny,status:413,msg:'Payload too large'"
Testing the rules
Should be blocked (wrong Content-Type)
curl -X POST https://yourapp/api/login -H "Content-Type:text/plain" -d '{"user":"test"}'
Should be allowed
curl -X POST https://yourapp/api/login -H "Content-Type:application/json" -d '{"user":"test"}'
- Investigating Attacking IPs, 403 Spikes & Payload Patterns
When a 403/406 spike occurs, you need to pivot quickly. Use `grep` and `awk` to build an investigation timeline.
Step 1 – Identify the time of spike
cat waf.log | awk '{print $1,$2}' | cut -d: -f1-2 | uniq -c
Look for a minute with > 10x normal volume
Step 2 – Extract all unique payloads during that spike
cat waf.log | grep "2026-05-16T14:35" | jq -r '.payload' | sort | uniq -c | sort -nr
Step 3 – Correlate with user‑agent anomalies
cat waf.log | jq -r '.user_agent' | sort | uniq -c | sort -nr | head -5 Look for "sqlmap/1.6", "Nuclei", "python-requests", or missing User-Agent
Example investigation output:
A spike at 14:35 shows 47 requests with payload ' UNION SELECT @@version,user() --, all coming from IP `185.130.5.253` with User-Agent sqlmap/1.6. This is a confirmed automated SQL injection campaign – immediate response required.
- Responding with IP Blocks, CAPTCHA Challenges & Session Kills
Automated response can be done via WAF API, firewall, or orchestration tools like TheHive/Cortex.
Immediate IP block using Linux iptables
sudo iptables -A INPUT -s 185.130.5.253 -j DROP sudo iptables -A OUTPUT -d 185.130.5.253 -j DROP Make persistent (Ubuntu) sudo apt install iptables-persistent && sudo netfilter-persistent save
Trigger CAPTCHA challenge (Cloudflare API example)
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/firewall/rules" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"action":"challenge","filter":{"expression":"(ip.src eq 185.130.5.253)"}}'
Session kill via application server (Node.js/Express example)
// Called by webhook from WAF
app.post('/kill-session', (req, res) => {
const badSession = req.body.session_id;
sessionStore.destroy(badSession, (err) => {
if(err) console.error(err);
res.sendStatus(200);
});
});
7. Automating and Tuning to Reduce False Positives
False positives exhaust SOC teams. Build a feedback loop that allows analysts to whitelist without modifying core rules.
Step 1 – Log all blocks to a separate “false‑positive‑candidate” file
In ModSecurity:
SecRule RESPONSE_STATUS "^403$" "id:20000,phase:5,log,msg:'Potential FP',setvar:tx.fp_candidate=1"
Step 2 – Create a weekly review script
fp_review.py
import json, re
with open('/var/log/waf.log') as f:
for line in f:
entry = json.loads(line)
if entry['rule_id'] in ['942100','941110'] and entry['status'] == 403:
Check if payload looks like legitimate data (e.g., "O'Brian")
if re.search(r"[a-zA-Z]'[a-zA-Z]", entry['payload']):
print(f"False positive candidate: {entry['src_ip']} -> {entry['url']} payload: {entry['payload']}")
Step 3 – Whitelist legitimate patterns
SecRule REQUEST_URI "@streq /search" "id:20001,phase:1,pass,nolog,ctl:ruleRemoveById=942100"
Run this script weekly and adjust whitelists. Aim for a false positive rate below 1% over a month.
What Undercode Say:
- Key Takeaway 1: A WAF is only as good as your ability to read its logs. Mastering command-line log analysis (jq, awk, PowerShell) turns raw data into actionable threat intelligence within minutes.
- Key Takeaway 2: Automation without tuning creates alert fatigue. Build a feedback loop that treats every 403 as a candidate for whitelist review, and use rate‑based blocking (fail2ban) rather than static IP blacklists.
Analysis (approx. 10 lines):
The post emphasizes that SOC analysts must go beyond “block bad traffic” and adopt an investigator mindset. By integrating WAF logs with external tools like geolocation databases, API-driven CAPTCHA challenges, and session kill mechanisms, teams can respond in real time without disrupting users. Practical exercises—such as extracting payload patterns or configuring ModSecurity CRS—bridge the gap between theory and hands-on defense. The inclusion of cloud WAF queries (Athena) and hybrid on‑premise commands ensures relevance across environments. Most importantly, the workflow stresses continuous tuning: false positives are inevitable, but a weekly review script turns them into learning opportunities. This transforms WAF from a noisy blocklist into a precision instrument for web application defense.
Prediction:
As web applications increasingly adopt API‑first architectures and AI‑generated attack payloads evolve, traditional signature‑based WAF rules will become insufficient. Within 24 months, SOC teams will rely on behavioral WAFs that use machine learning to model normal API traffic patterns and automatically generate anomaly detection rules. We’ll see tighter integration between WAFs and SIEM/SOAR platforms, where a single 403 spike triggers an automated playbook: pull vulnerability scan results, correlate with threat intel feeds, and push a temporary CAPTCHA challenge—all without human intervention. However, attackers will counter by using distributed residential proxies and generative AI to craft payloads that mimic legitimate JSON structures, forcing SOC analysts to adopt continuous retraining pipelines. The labs available at platforms like Haxcamp (www.haxcamp.com) will become essential for keeping blue teams sharp against these adaptive threats.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
