How requests are judged
Detection pipeline
Each request from the access log passes through a fixed sequence of checks. The result is a verdict, a reason, and, for some reasons, a ban request. The engine judges behavior over time rather than reacting to a single odd request.
Input
The engine parses NGINX's key-value access log format. It trusts X-Forwarded-For only from loopback, so a client cannot
forge its own address through the header. Client attribution is preserved when NGINX proxies to backend servers.
Checks, in order
| Stage | What it looks for | Effect |
|---|---|---|
| Dangerous methods | HTTP methods with no place on a public site | Accumulates toward a threshold |
| Absolute-URI requests | Proxy-style request lines used to probe for open proxies | Accumulates toward a threshold |
| Certificate challenges | ACME HTTP-01 validation paths, so certificate renewal is never disrupted | Allowed |
| Admin-panel probes | Requests for administration interfaces the site doesn't run | Accumulates toward a threshold |
| Exempt paths | A small, customer-specific list of paths that legitimately look unusual, such as an auto-refreshing dashboard | Skips the remaining checks |
| Blocklist patterns | Requests for sensitive files and known attack paths, such as .env files, .git metadata and configuration files | Ban |
| Webshell patterns | Requests matching known webshell names and behaviors | Ban |
| Machine learning (optional) | A CNN-GRU neural network compiled into the engine scores the request | Ban when the score crosses the threshold |
User-agent anomalies are logged but do not cause a ban on their own.
Behavior over time
- Probe accumulation: admin probes, absolute-URI requests and dangerous methods escalate after 3 hits from the same source within 30 minutes.
- Burst detection: 20 or more requests across 10 or more distinct paths within 30 seconds escalates the source.
- Shadow stage: suspicious sources are tracked and their activity accumulates without enforcement. Shadow state is saved and restored across restarts.
- Subnet correlation: several newly banned addresses in one /24 within an hour are flagged. Subnet-wide enforcement is in monitor mode.
Addresses that are never banned
- Loopback and private ranges, the server's own address, and addresses the administrator lists in the enforcement policy.
- Verified search-engine and CDN crawlers, which are detected and logged but treated as soft-trusted. Verification uses reverse-DNS checks performed asynchronously, so they never delay request processing.
The machine-learning model
The model is a CNN-GRU classifier trained on labeled real-world HTTP traffic on an NVIDIA GPU, then exported to a native Rust implementation compiled into the engine binary. No Python runtime or separate inference service runs in production. The native implementation was validated against 2,013 reference cases, matching the training framework within a maximum difference of 2.3e-6, with no change in any verdict at the thresholds tested. It runs on standard CPUs.
Outputs
| Output | Contents |
|---|---|
| Detection log | One line per detection: time, source, method and path, status, reason, ML score and the checks evaluated |
| Structured events | Newline-delimited JSON, consumed by the optional ingestion service and DAV SOC |
| Enforcement log | Ban and unban actions, duplicate suppression and connection cleanup results |
| Statistics and latency | Periodic counters and per-stage processing times |