Erkennung von Webserver-Probing und Fuzzing in Traefik mit automatisierter Cloudflare-Antwort

Einführung

Selbstgehostete Dienste, die über einen Reverse-Proxy zugänglich sind, ziehen unweigerlich automatisierte Scanner an, die nach Fehlkonfigurationen, Admin-Panels und angreifbaren Endpunkten suchen. In diesem Artikel zeige ich, wie man mithilfe von Elastic Security und Cloudflare routinemäßige Traefik- Zugriffsprotokolle in eine aktive Verteidigungssteuerung umwandeln kann.

Ich verwende eine standardmäßige ES|QL- Erkennungsregel, um das Verhalten von Webservern bei der Erkennung und beim Fuzzing zu identifizieren. Werden verdächtige Sondierungsmuster erkannt, blockiert ein automatisierter Workflow die betreffende Quell-IP-Adresse umgehend am Netzwerkrand über die Cloudflare-API. Das Beste an diesem System ist, dass es sich mühelos skalieren lässt. Indem ich diese Antwortinfrastruktur einmalig für die Fuzzing-Erkennung erstelle, kann ich die exakt gleiche Blockierungsaktion an jede andere Elastic-Regel anhängen, beispielsweise an solche, die SQL-Injections oder Dateieinbindungsversuche abfangen. Dadurch wird eine einfache Protokollierungspipeline in eine hochgradig anpassungsfähige Perimeterverteidigung verwandelt.

Hintergrund und Bedrohungslandschaft

Mein Heimnetzwerk-Setup nutzt Proxmox VE für Container und VMs. Ich verwende einen Traefik Reverse-Proxy, der mit Authelia zur Authentifizierung gesichert ist, um externen Zugriff ohne VPN zu ermöglichen. Cloudflare verwaltet mit aktiviertem Proxy die DNS-Auflösung.

Für diejenigen, die mit diesem speziellen Stack weniger vertraut sind: Traefik fungiert als Eingangstür des Netzwerks. Wenn eine Webanfrage über Cloudflare eingeht, leitet Traefik den Datenverkehr dynamisch an den richtigen internen Container weiter und verwaltet gleichzeitig die SSL-Zertifikate, um die Verbindungen verschlüsselt zu halten. Bevor der Datenverkehr jedoch tatsächlich diese Backend-Anwendungen erreicht, wird er von Authenlia abgefangen. Durch die Nutzung der Vorwärtsauthentifizierungsfunktion von Traefik erzwingt Authelia Single Sign-On und Multi-Faktor-Authentifizierung durchgängig. Das bedeutet, dass automatisierte Scanner und Angreifer nicht einmal die Anmeldebildschirme meiner internen Dienste erreichen können, ohne dieses erste sichere Portal zu passieren.

Um Transparenz und Sicherheit zu gewährleisten, importiere ich diese Traefik-Zugriffsprotokolle mithilfe der offiziellen Integration in Elastic. Bei der routinemäßigen Überwachung habe ich in diesen Protokollen zahlreiche HTTP 404 -Antwortcodes beobachtet, die von denselben Quell-IP-Adressen stammen.

Dieses Muster deutet auf potenziellen Webserver-Probing- oder Fuzzing-Traffic hin, der auf Schwachstellen in Anwendungen abzielt, die in meinem Netzwerk tatsächlich nicht im Einsatz sind. Beispiele für diese Zielpfade sind /wp-includes/mani., /wp-content/plugins/all-in-one-wp-security-and-firewall/templates.php, /archive.php, und /wp-admin/includes/header.php.

Designphilosophie: Warum nicht Fail2Ban?

Eine häufig gestellte Frage in der Homelab-Community ist, warum man nicht einfach lokale Tools wie Fail2Ban oder CrowdSec direkt auf dem Traefik-Server verwendet. Das sind zwar hervorragende Tools, aber die Orchestrierung der Reaktion über Elastic Security und die Weiterleitung der Blockierung an Cloudflare bietet zwei große Vorteile. Durch das Abfangen schädlichen Datenverkehrs am Cloudflare-Rand wird lokale Bandbreite gespart und Scanner werden vollständig vom Heimnetzwerk ferngehalten. Darüber hinaus ermöglicht uns die Orchestrierung der Reaktion über Elastic, die gesamte Sicherheitsüberwachung zentral zu steuern.

Erkennungsstrategie und Implementierungsstrategie

Um böswillige Aufklärung effektiv zu erkennen, basiert unsere Strategie auf der Analyse der Häufigkeit von HTTP-Antwortcodes auf Proxy-Ebene. Konkret suchen wir nach einer hohen Anzahl von 404 (Nicht gefunden)-Fehlern, die von einer einzigen Quell-IP innerhalb eines kurzen Zeitraums generiert werden – ein klassischer Indikator für Directory Fuzzing oder Schwachstellenscans.

Elastic Security bietet zwar robuste, sofort einsatzbereite Erkennungsregeln für genau dieses Szenario, diese Regeln benötigen jedoch ordnungsgemäß normalisierte ECS-Daten (Elastic Common Schema), um korrekt zu funktionieren. Das Erkennen und Eindämmen dieser Scans erfordert daher einen koordinierten Ablauf. Um dies zum Laufen zu bringen, müssen wir die Traefik-Logs einlesen, das fehlende Feld host.name mithilfe einer benutzerdefinierten Pipeline ergänzen und die Erkennungsregel auf unsere Daten ausrichten.

Schwellenwertlogik und -einstellung

Unsere Erkennungsstrategie verzichtet auf einfache Zeichenkettenvergleiche und stützt sich stattdessen auf statistische Schwellenwerte. Die Regel überwacht insbesondere verweigerte oder nicht existierende Ressourcen, die durch die HTTP-Antwortcodes 403 und 404 dargestellt werden, und aggregiert diese Aktivität nach der Ursprungs-Quell-IP-Adresse.

Dieses Verhalten wird durch die letzte where -Anweisung in der Abfrage gesteuert. Standardmäßig wird eine Warnung nur dann ausgelöst, wenn eine Quell-IP während des Abfragefensters mehr als 500 Fehler über 250 verschiedene URI-Pfade hinweg erzeugt. Dieser zweistufige Schwellenwert dient dazu, Fehlalarme zu vermeiden und sicherzustellen, dass ein einzelnes defektes Asset keine Sperrung auslöst, während gleichzeitig automatisierte Skripte identifiziert werden, die Verzeichniswortlisten durchlaufen.

In kleineren Heimlaboren oder kleineren Teams sind diese Standardeinstellungen oft zu nachgiebig. Da legitimer externer Datenverkehr keinen Grund hat, nicht existierende Admin-Panels in meinem Netzwerk zu erreichen, habe ich die Empfindlichkeit angepasst, um heimlichere Aufklärungsversuche frühzeitig zu erkennen. Ich habe die Logik so angepasst, dass sie bei event_count > 100 und url_original_count_distinct > 50 ausgelöst wird.

Für Produktionsumgebungen, in denen Anwendungen naturgemäß ein höheres Fehleraufkommen erzeugen, sollten Sie erwägen, diese Werte zu erhöhen oder eine ES|QL where not -Klausel anzuhängen, um bekannte defekte Links auszuschließen. Abschließend verwende ich einen where source.ip not in (...) -Filter, um sicherzustellen, dass autorisierte Sicherheitstools oder persönliche Schwachstellenscanner nicht versehentlich durch den automatisierten Workflow gesperrt werden.

Einlesen von Traefik-Zugriffsprotokollen

Um die Traefik-Zugriffsprotokolle in den Cluster einzubinden, habe ich die Standardintegration für Traefik verwendet. Der Elastic Agent sammelt Protokolle von Traefik-Servern. Diese Integration schreibt die aufgenommenen Protokolle in den Datenstrom logs-traefik.access-default .

Erstellung einer benutzerdefinierten Datenaufnahmepipeline

Das Feld host.name ist für die von mir verwendete Erkennungsregel von entscheidender Bedeutung, wird aber von der standardmäßigen Traefik-Integration nicht ausgefüllt. Daher ist eine benutzerdefinierte Datenaufnahmepipeline erforderlich, um dieses Feld hinzuzufügen. Da die Traefik-Integration einen Dateistream auf dem Traefik-Server verwendet, kann ich den Wert aus dem vorhandenen Feld agent.name kopieren, um das Feld host.name zu füllen.

Ich verwende bewusst die logs-traefik.access@custom -Pipeline, anstatt die Hauptpipeline zu modifizieren. Elastische Integrationen sind so konzipiert, dass sie diese @custom -Pipelines automatisch direkt am Ende ihres Verarbeitungsablaufs aufnehmen und ausführen. Noch wichtiger ist jedoch, dass die Standardpipelines bei jedem Upgrade einer Integration vollständig überschrieben werden. Indem ich meine Logik in der benutzerdefinierten Pipeline speichere, stelle ich sicher, dass meine Feldzuordnungen auch nach dem nächsten Update erhalten bleiben. Der notwendige API-Aufruf zum Erstellen dieser Pipeline kann in der Entwicklerkonsole ausgeführt werden:

PUT _ingest/pipeline/logs-traefik.access@custom
{
  "description": "copy the agent.name field to the host.name field",
  "processors": [
    {
      "set": {
        "field": "host.name",
        "value": "{{{agent.name}}}",
        "override": false,
        "ignore_empty_value": true,
        "ignore_failure": true
      }
    }
  ]
}

Automatisierte Antwort über den Cloudflare-Workflow

Um von der Erkennung zur aktiven Verteidigung überzugehen, implementieren wir einen Workflow, der die Lücke zwischen unseren Elastic-Warnungen und dem Cloudflare-Edge schließt. Die Logik ist auf Effizienz ausgelegt: Anstatt für jede einzelne Warnung eine neue Firewall-Regel zu erstellen, was schnell an die Regelgrenzen von Cloudflare stoßen würde, ruft der Workflow zunächst die bestehende Sperrliste ab. Anschließend wird die neue, fehlerhafte Quell-IP dynamisch an diese Liste angehängt, bevor das Update an die Cloudflare-API zurückgesendet wird. Sobald die Netzwerkschnittstelle gesichert ist, wird der Workflow mit der Bestätigung der Warnung in Elastic abgeschlossen, wodurch der Vorfall effektiv beendet wird.

Voraussetzungen und Token-Gültigkeitsbereich

Für diesen Vorgang werden sowohl ein API-Schlüssel als auch die Zonen-ID für die Cloudflare-Konfiguration benötigt. Das API-Token muss über die Berechtigung "Zone WAF edit" verfügen, um die Erstellung der Regel zu ermöglichen. Wenn Sie dieses Token im Cloudflare-Dashboard generieren, verwenden Sie die Option "Benutzerdefiniertes Token erstellen" und setzen Sie die Berechtigungen strikt auf Zone -> Zone WAF -> Edit.

Sobald der Workflow konfiguriert ist, muss er der Erkennungsregel „Webserver-Erkennung oder Fuzzing-Aktivität“ als Aktion zugewiesen werden.

Nachdem die Voraussetzungen geschaffen sind, wollen wir nun Schritt für Schritt durchgehen, wie wir den Workflow aufbauen.

Workflow-Konfiguration und Trigger

Zuerst definieren wir die grundlegenden Metadaten. Dieser Workflow blockiert die in den Warnmeldungen der Webserver-Erkennung oder Fuzzing-Aktivität gefundenen IP-Adressen. Der Workflow ist aktiviert und hat ein Timeout von 30 Sekunden für die API-Anfrage. In diesem Fall basiert es auf einer Warnmeldung und wird daher automatisch ausgeführt, wenn eine Sicherheitswarnung ausgelöst wird.

# =========================================================================
# Workflow: Block IP at Cloudflare test
# Category: security/response
# =========================================================================
version: '1'
name: Block IP at Cloudflare
enabled: true

triggers:
  - type: alert

Konstanten und Authentifizierung

Dieser Abschnitt enthält die Variablen für die Authentifizierung. Denken Sie daran, die Platzhalterzeichenfolgen durch Ihr tatsächliches API-Token und Ihre Zonen-ID zu ersetzen.

consts:
  cloudflare_api: "<cloudflare API>"
  cloudflare_zone: "<cloudflare ZONE>"

Schritt 1: Abrufen der aktuellen Sperrliste

Die Sequenz prüft, ob die Firewall-Regel bereits existiert. Der Workflow sendet eine HTTP-GET-Anfrage, um die bestehende IP-Sperrregel abzurufen.

steps:
  - name: cloudflare_current_block
    type: http
    with:
      url: "https://api.cloudflare.com/client/v4/zones/{{consts.cloudflare_zone}}/rulesets/phases/http_request_firewall_custom/entrypoint"
      headers:
        Authorization: Bearer {{consts.cloudflare_api}}
      method: GET
    on-failure:
      continue: true

Schritt 2: Aktualisieren oder Erstellen der Firewall-Regel

Existiert die Regel, wird sie um die IP-Adresse ergänzt; andernfalls wird sie erstellt. Der Workflow erkennt, ob die Beschreibung "Webserver-Scanblock" vorhanden ist. In diesem Fall wird die neue IP-Adresse über eine PUT-Anfrage an die aktuelle Liste der gesperrten IP-Adressen angehängt. Andernfalls wird eine neue Regel erstellt.

 - name: cloudflare_block
    type: if
    condition: 'steps.cloudflare_current_block.output.data.result.rules[0].description == "webserver scanning block"'
    steps:
      - name: ip-block-cloudflare_add
        type: http
        with:
          url: "https://api.cloudflare.com/client/v4/zones/{{consts.cloudflare_zone}}/rulesets/phases/http_request_firewall_custom/entrypoint"
          method: PUT
          headers:
            Authorization: Bearer {{consts.cloudflare_api}}
          timeout: 30s
          body: '{ "rules": [ { "description": "webserver scanning block", "expression": "{{steps.cloudflare_current_block.output.data.result.rules[0].expression}} or (ip.src eq {{event.alerts[0].source.ip}})", "action": "block" } ]}'
    else:
      - name: ip-block-cloudflare_new
        type: http
        with:
          url: "https://api.cloudflare.com/client/v4/zones/{{consts.cloudflare_zone}}/rulesets/phases/http_request_firewall_custom/entrypoint"
          method: PUT
          headers:
            Authorization: Bearer {{consts.cloudflare_api}}
          timeout: 30s
          body: '{ "rules":[ { "description": "webserver scanning block", "expression": "(ip.src eq {{event.alerts[0].source.ip}})", "action": "block" } ]}'
    on-failure:
      continue: true

Schritt 3: Die Benachrichtigung bestätigen

Anschließend wird die Benachrichtigung bestätigt. Dieser Schritt nutzt die Aktion kibana.SetAlertsStatus , um die Warnung in Elastic Security automatisch zu schließen.

  - name: update_alert_status
    type: kibana.SetAlertsStatus
    with:
      status: "acknowledged"
      signal_ids: ["{{event.alerts[0]._id}}"]

Schritt 4: Den Workflow der Regel zuordnen

Nachdem der Workflow vollständig erstellt ist, besteht der letzte Schritt darin, ihn der Erkennungsregel zuzuordnen, damit er automatisch ausgelöst wird. In den Elastic Security-Regeleinstellungen für die Regel "Web Server Discovery or Fuzzing Activity" navigiere ich zur Registerkarte "Regelaktionen " und füge eine neue Aktion hinzu. Im Connector-Dropdown-Menü wähle ich einfach den Cloudflare-Workflow aus, den ich gerade erstellt habe.

Hinweis zu WAF-Grenzwerten

Da dieser Workflow IP-Adressen mithilfe einer or -Anweisung (or (ip.src eq <IP>)) verknüpft, ist zu beachten, dass Cloudflare eine Zeichenbegrenzung für benutzerdefinierte WAF-Ausdrücke hat (typischerweise 4096 Zeichen in Standardtarifen). In Umgebungen mit hohem Zielgruppenfokus kann diese Zeichenkette irgendwann an ihre Grenzen stoßen. Für Heimlabore und kleine Teams dient das gelegentliche manuelle Löschen dieser WAF-Regel als eine Art gesunder Neustart.

Testen und Validieren

Um zu überprüfen, ob die Pipeline durchgängig funktioniert, können wir mit einem Standard-Fuzzing-Tool etwas Rauschen erzeugen. Sie können einen Scanning-Angriff auf Ihr eigenes Heimnetzwerk mit Hilfe eines Fuzzing-Tools wie ffuf oder gobuster simulieren.

Führen Sie einen Schnellscan eines nicht existierenden Verzeichnisses auf Ihrer öffentlich zugänglichen Traefik-Domain durch:

ffuf -u https://your-domain.com/FUZZ -w /path/to/wordlist.txt

Sobald die Simulation läuft, können wir die automatisierte Verteidigungskette in Aktion beobachten. Die 404 -Fehler treten fast sofort im logs-traefik.access-default -Datenstrom auf. Innerhalb des Abfrageintervalls erkennt die ES|QL-Regel das Muster und generiert eine neue Warnung auf der Seite „Elastic Security Alerts“. Von dort an übernimmt der Workflow: Er ändert den Alarmstatus auf „bestätigt“ und überträgt die IP-Sperre an unsere Cloudflare WAF-Regel, wodurch der Scanner effektiv am Netzwerkrand neutralisiert wird, bevor er seine Aufklärung fortsetzen kann.

Sie können die erfolgreiche Blockierung überprüfen, indem Sie Ihr Cloudflare-Dashboard unter Security -> WAF -> Custom rules aufrufen. (Hinweis: Vergessen Sie nicht, Ihre IP-Adresse anschließend aus der Cloudflare-Regel zu entfernen, damit Sie sich nicht selbst aussperren!)

Ausweitung der Verteidigung

Das Schöne an diesem Setup ist, dass unser Cloudflare-Workflow nicht nur auf die Fuzzing-Erkennung beschränkt ist. Sobald die Automatisierung eingerichtet ist, können wir sie an jede Elastic-Regel anhängen, die verdächtigen Proxy-Datenverkehr kennzeichnet. Beispielsweise können wir genau diese Reaktionsaktion mit vordefinierten Regeln verknüpfen, die auf bestimmte Anwendungs-Exploits abzielen, wie z. B. lokale Dateieinbindungsaktivitäten auf dem Webserver oder potenzielle Remote-Dateieinbindungsaktivitäten auf dem Webserver , um den Angreifer sofort zu stoppen. Es passt außerdem perfekt zu Potential Spike in Web Server Error Logs und Unusual Web User Agent, um falsch konfigurierte Scraper und allgemeineres Netzwerkrauschen aufzuspüren. Wir verlegen die Rohrleitungen einmal, und plötzlich wird das gesamte Umfeld intelligenter.

Fazit

Die Integration von Traefik und Cloudflare in Elastic Security ist eine hervorragende Möglichkeit, einfache Zugriffsprotokolle in eine aktive Verteidigung umzuwandeln. Heimlaborumgebungen werden ständig von automatisierten Scannern überflutet, die nach leicht zu findenden Schwachstellen suchen. Dieser automatisierte Workflow blockiert nicht nur Angreifer am Netzwerkrand, sondern reduziert auch die Alarmmüdigkeit, indem er die Vorfälle automatisch bestätigt. Es ist ein praktisches Beispiel dafür, wie Sicherheitsorchestrierung und -reaktion Zeit sparen und gleichzeitig Ihre Sicherheitslage deutlich verbessern können.