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

Detecting Web Server Probing & Fuzzing in Traefik with Automated Cloudflare Response
The article shows how Traefik access logs can be used in Elastic Security to detect web server discovery and fuzzing, then automatically block the source IP at the Cloudflare edge. It also explains how a reusable Cloudflare workflow can be attached to other Elastic detections such as SQL injection or file inclusion attempts. #Traefik #ElasticSecurity #Cloudflare #Authelia #ffuf #gobuster

Keypoints

  • Traefik access logs are ingested into Elastic Security to monitor suspicious probing activity against self-hosted services.
  • An ES|QL detection rule identifies web server discovery and fuzzing by looking for high volumes of 404 and 403 responses from a single source IP.
  • The setup uses a custom ingest pipeline to populate the missing host.name field required by the detection rule.
  • When suspicious behavior is detected, a Cloudflare workflow updates the WAF custom rule to block the offending IP at the edge.
  • The response workflow reuses the same mechanism for other detections, including SQL injection and file inclusion-related alerts.
  • The alert is automatically acknowledged in Elastic Security after the Cloudflare block is applied.
  • The article demonstrates validation with fuzzing tools such as ffuf and gobuster against a public Traefik domain.

MITRE Techniques

  • [T1595 ] Active Scanning – Automated probing of exposed services and endpoints is detected through repeated 404s from the same source IP, indicating discovery and fuzzing activity (‘high volume of 404 (Not Found) errors generated by a single source IP within a short time window’).
  • [T1595.001 ] Scanning IP Blocks – The workflow is designed to stop scanners by blocking the source IP at Cloudflare after detection (‘immediately blocks the offending source IP at the edge via the Cloudflare API’).
  • [T1083 ] File and Directory Discovery – The rule flags repeated requests for non-existent paths and admin-related resources, consistent with directory fuzzing (‘targeting vulnerabilities in applications that are not actually in use on my network’).
  • [T1190 ] Exploit Public-Facing Application – The article references detections for SQL injections and file inclusion attempts against exposed web applications (‘attach the exact same block action to any other Elastic rule such as those catching SQL injections or file inclusion attempts’).
  • [T1110 ] Brute Force – The use of automated fuzzing tools to rapidly try many paths reflects automated repeated attempts typical of brute-force-like probing (‘simulate a scanning attack… using a fuzzing tool like ffuf or gobuster’).

Indicators of Compromise

  • [File paths ] Suspicious probe targets in Traefik logs – /wp-includes/mani., /wp-content/plugins/all-in-one-wp-security-and-firewall/templates.php, and other similar paths
  • [Datastream ] Elastic ingestion target for Traefik logs – logs-traefik.access-default
  • [API endpoint ] Cloudflare firewall ruleset endpoint used by the workflow – https://api.cloudflare.com/client/v4/zones/{{consts.cloudflare_zone}}/rulesets/phases/http_request_firewall_custom/entrypoint
  • [YAML workflow name ] Response automation identifier – Block IP at Cloudflare
  • [Detection rule name ] Elastic rule referenced for triggering the workflow – Web Server Discovery or Fuzzing Activity
  • [Tool names ] Validation tools used to simulate scanning – ffuf, gobuster
  • [Cloudflare rule description ] Custom WAF rule label used for blocking – webserver scanning block


Read more: https://www.elastic.co/security-labs/detecting-web-server-probing-and-fuzzing