L7 / Application Layer Detection
Detect HTTP floods, credential stuffing, and application-layer abuse
What L7 Detection Covers
L7 detection operates independently from the L3/L4 PPS/BPS engine. It monitors HTTP access logs (not raw packets) and detects application-layer attacks that do not produce high PPS. A Slowloris attack at 50 requests/second can bring down a server while staying far below any PPS threshold.
L7 detection supports nginx, Apache, Caddy, LiteSpeed, HAProxy, Tomcat, Gunicorn, and any server that writes combined/CLF or JSON-format access logs.
How L7 Detection Works
- Log tailing: The L7 monitor tails the web server's access log file (e.g.
/var/log/nginx/access.log) - Request parsing: Each log line is parsed into IP, method, path, status code, response size, user-agent, response time, and HTTP version
- Window stats: Every tick (1 second), the monitor computes RPS, error rate, unique IPs, top paths, top IPs, bot percentage, threat pattern hits, and HTTP protocol distribution
- Signal evaluation: Multiple signals are checked against thresholds. At least 2 signals must fire simultaneously with 3+ unique source IPs to trigger an attack
- Baseline learning: RPS baseline is computed using an exponential moving average during clean traffic periods
Detection Signals
Each signal that fires adds to the signal count. An attack requires at least 2 simultaneous signals:
| Signal | Threshold | Points |
|---|---|---|
| RPS spike | Current RPS exceeds baseline * sensitivity multiplier | +2 |
| IP concentration | Single IP contributes >30% of requests (and >20 total) | +1 |
| Path focus | Single path receives >60% of requests (and >30 total) | +1 |
| Error rate anomaly | Error rate > configured threshold (default 50%) | +1 |
| 5xx spike | Server errors > 30% of requests (and >15 total) | +1 |
| Bot UA percentage | Known bot user-agents > 70% of requests | +1 |
| Threat patterns | SQLi/XSS/path traversal hits > 20% of requests | +1 |
L7 Attack Subtypes
When an L7 attack is detected, it is classified into a specific subtype:
| Subtype | Detection criteria |
|---|---|
h2_rapid_reset | HTTP/2 traffic >30%, RPS >200, >20% status 499 (client closed), per-IP RPS >50. Matches CVE-2023-44487. |
h2_settings_flood | HTTP/2 traffic >30%, per-IP RPS >200, <20 unique IPs, RPS >500. Connection-level abuse via multiplexed streams. |
h2_continuation_flood | HTTP/2 traffic >30%, per-IP RPS >100, <30 unique IPs, >40% 4xx errors. Matches CVE-2024-27983. |
quic_flood | HTTP/3 (QUIC) traffic >30%, RPS >300, >5 unique IPs. |
single_source_abuse | 1-2 unique IPs generating all traffic. |
credential_stuffing | >50% of requests to auth endpoints (/login, /signin, /oauth) with >40% error rate. |
scraping | >70% of requests to a single path with <20% error rate. |
api_abuse | Top path targets /api/ or /graphql endpoints. |
slow_rate | RPS <50 from >20 IPs with >60% error rate (Slowloris-like pattern). |
volumetric_flood | RPS >500 from >10 IPs. High-volume distributed HTTP flood. |
l7_flood | Default when no specific subtype matches. |
Threat Pattern Detection
The L7 engine scans request paths against known attack patterns:
| Pattern | What it catches |
|---|---|
sqli | SQL injection attempts (UNION SELECT, OR 1=1, DROP TABLE) |
xss | Cross-site scripting (<script>, javascript:, onerror=) |
path_traversal | Directory traversal (../../, %2e%2e/) |
rfi_lfi | Remote/local file inclusion (file://, /etc/passwd, /proc/self/) |
wordpress | WordPress-specific probes (/wp-admin, /xmlrpc.php, /wp-login.php) |
scanner_probe | Common scanner paths (/.env, /.git/, /actuator, /server-status) |
shell_shock | Shellshock exploit attempts (() {) |
log4j | Log4j/Log4Shell (${jndi:, ${lower:) |
api_abuse | API endpoint probing (/graphql, /oauth/token, /api/v*/admin) |
cve_exploit | Known CVE exploit paths (/cgi-bin/, /c99.php, /eval-stdin.php) |
Bot User-Agent Detection
The engine maintains a regex pattern that matches known bot and attack tool user-agents: python-requests, Go-http-client, curl/, wget/, nikto, sqlmap, nmap, masscan, zgrab, nuclei, ffuf, gobuster, and others. The bot request percentage is tracked and used as a detection signal.
Configuring L7 Detection
L7 detection is configured server-side via the dashboard and pushed to the agent during config sync. You do not need to edit config.json manually.
Configuration Options
| Setting | Default | Description |
|---|---|---|
| enabled | false | Enable L7 monitoring |
| action | auto_detect | auto_detect to let the agent find the web server and log path automatically |
| log_path | (auto) | Explicit path to the access log file |
| sensitivity | medium | low (8x multiplier, 250 min RPS), medium (5x, 150), or high (3x, 75) |
| rps_threshold | (auto) | Override the auto-calculated RPS threshold with a fixed value |
| error_rate_threshold | 50 | Error rate percentage above which the error rate signal fires |
Auto-Detection
When action is set to auto_detect, the agent checks for running web servers (nginx, Apache, Caddy, LiteSpeed, HAProxy) using both binary version commands and process table inspection. It then probes known log paths for each server type and reports the detected configuration to the dashboard.
L7 Incidents in the Dashboard
L7 incidents appear alongside L3/L4 incidents in the incident timeline. They include:
- Peak RPS and baseline RPS at time of detection
- Attack subtype classification
- Top source IPs, top targeted paths, top user-agents
- Status code distribution
- HTTP protocol version breakdown (HTTP/1.1, HTTP/2, HTTP/3)
- Threat pattern hit counts
- Detection reasons (which signals fired)
When an L7 attack occurs simultaneously with an L3/L4 attack, the L7 incident is flagged as correlated to indicate that the application-layer component may be part of a multi-layer attack.