Detecting Web Server Probing & Fuzzing in Traefik with Automated Cloudflare Response
The article details a defensive architecture using Elastic Security to detect web server probing and directory fuzzing against Traefik reverse proxies. By analyzing HTTP 403 and 404 error thresholds, security teams can trigger automated workflows that dynamically update Cloudflare WAF rules to block malicious source IPs at the edge.
Detection / HunterGoogle
What Happened
Automated scanners constantly search the internet for vulnerable web servers and exposed admin panels. This article explains how to detect these scanners by monitoring for a high number of "Not Found" (404) errors using Elastic Security. When a scanner is detected, an automated system immediately blocks its IP address using Cloudflare, stopping the attack before it reaches the internal network. This approach saves time and improves security by automatically handling routine threats.
Key Takeaways
- Automated scanners constantly probe exposed self-hosted services for vulnerabilities and admin panels.
- Elastic Security can detect fuzzing by analyzing Traefik access logs for high volumes of HTTP 404/403 errors from a single IP.
- A custom ingest pipeline is required to map Traefik's agent.name to host.name for Elastic detection rules to function properly.
- An automated workflow can dynamically update Cloudflare WAF rules to block offending IPs at the edge.
- This automated response architecture can be scaled to other detection rules, such as those for SQL injection or file inclusion attempts.
Affected Systems
- Traefik reverse proxy
- Self-hosted web services
- Cloudflare WAF
- Elastic Security
Attack Chain
Attackers use automated scanning tools like ffuf or gobuster to probe external-facing web servers for misconfigurations, admin panels, and vulnerable endpoints. These tools generate a high volume of requests to non-existent directories, resulting in HTTP 404 and 403 errors. If unmitigated, this reconnaissance phase allows attackers to identify viable targets for subsequent exploitation, such as local file inclusion or SQL injection.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: Yes
- Other Detection Logic: Yes
- Platforms: Elastic Security
The article provides ES|QL threshold logic for detecting fuzzing behavior, as well as JSON configurations for an Elastic ingest pipeline and an automated Cloudflare response workflow.
Detection Engineering Assessment
EDR Visibility: None — The detection relies entirely on reverse proxy access logs, which are network/web-tier telemetry, not endpoint process telemetry. Network Visibility: High — The detection is based on HTTP response codes (404, 403) and URI paths observed at the reverse proxy level. Detection Difficulty: Easy — Identifying high volumes of 404 errors from a single IP is a standard and highly reliable method for detecting directory fuzzing, easily implemented with threshold alerts.
Required Log Sources
- Web Server Access Logs
- Reverse Proxy Logs (Traefik)
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| A single external IP address generating a high volume of HTTP 404 or 403 errors across multiple distinct URI paths indicates automated directory fuzzing or vulnerability scanning. | Web server or reverse proxy access logs | Reconnaissance | Low to Medium (Broken links on a legitimate site could trigger 404s, but usually not across dozens of distinct non-existent paths from a single user) |
Control Gaps
- Lack of normalized host.name fields in default Traefik integrations
- Cloudflare WAF custom expression character limits (4096 chars) can be exhausted by appending too many IPs
Key Behavioral Indicators
- High frequency of HTTP 404/403 response codes
- Requests to known WordPress admin or plugin paths on non-WordPress sites
- High count of distinct URLs requested by a single source IP
False Positive Assessment
- Medium. Legitimate users or broken application links might generate 404 errors, requiring threshold tuning (e.g., >100 errors across >50 distinct URIs) and exclusion lists for known broken assets or authorized vulnerability scanners.
Recommendations
Immediate Mitigation
- Implement threshold-based blocking for IPs generating excessive 404/403 errors.
- Deploy a custom ingest pipeline to map agent.name to host.name for Traefik logs in Elastic.
Infrastructure Hardening
- Place self-hosted services behind an authentication portal like Authelia to prevent unauthenticated access to internal routing.
- Utilize Cloudflare WAF to block malicious IPs at the edge rather than locally.
User Protection
- N/A
Security Awareness
- Regularly clear out dynamically generated WAF blocklists to avoid hitting character limits.
MITRE ATT&CK Mapping
- T1595.002 - Active Scanning: Vulnerability Scanning
- T1595.003 - Active Scanning: Wordlist Scanning
Additional IOCs
- Command Lines:
- Purpose: Simulate a scanning attack against a web server to test detection logic. | Tools:
ffuf| Stage: Reconnaissance |ffuf -u https://your-domain.com/FUZZ -w
- Purpose: Simulate a scanning attack against a web server to test detection logic. | Tools:
