Detecting Web Server Probing & Fuzzing in Traefik with Automated Cloudflare Response

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