Angriffsbeispiele aus Access-Logs

 (nishtahir.com)
1 Punkte von GN⁺ 2024-01-29 | 1 Kommentare | Auf WhatsApp teilen
  • Die Access-Logs einer seit über 10 Jahren selbst gehosteten öffentlichen IP zeigen Angriffsversuche, denen im Internet erreichbare Dienste regelmäßig ausgesetzt sind – von der Suche nach Zugangsdaten bis zu Command Injection gegen IoT-Geräte.
  • Das häufigste Muster war die Suche nach Konfigurationsdateien und Verzeichnissen wie .env, .aws/credentials, .git/config, backup/ oder test/; einige Requests nutzten User-Agents mit Tippfehlern wie Mozlila/5.0.
  • Shellshock-Versuche packten Payloads in Form von Bash-Funktionen in den User-Agent, um /etc/passwd auszulesen, und errieten wiederholt verschiedene CGI-Pfade.
  • Angriffe auf LuCI und Zyxel versuchten, Befehle in Webinterfaces von Routern und Embedded-Geräten einzuschleusen, um Remote-Skripte sowie Binärdateien für mehrere Architekturen herunterzuladen und auszuführen.
  • Man sollte die Angriffsfläche im öffentlichen Internet reduzieren, für notwendige Tools und Verzeichnisse Authentifizierung sowie IP-Beschränkungen einsetzen und IoT-Geräte aktuell halten sowie möglichst vom öffentlichen Netz trennen.

Traffic, den öffentlich im Internet erreichbare Dienste erhalten

  • Seit über 10 Jahren wird selbst gehostet, um die eigenen Daten selbst zu besitzen und Abhängigkeiten von Plattformen jenseits von Cloud-Hosts zu verringern.
  • Sobald eine IP im öffentlichen Internet erreichbar ist, trifft sehr viel bösartiger Traffic ein; anhand der Access-Logs lässt sich nachvollziehen, welche Angriffe zuletzt eingegangen sind.
  • Diese Analyse ist weniger forensische Arbeit eines Sicherheitsexperten als vielmehr die Beobachtung eines neugierigen Entwicklers.
  • IP-Adressen der Angreifer und einige von Angreifern verwendete beleidigende Ausdrücke wurden vorsichtshalber unkenntlich gemacht.

Suche nach Zugangsdaten und Konfigurationsdateien

  • Der häufigste Angriff war der Versuch, per Directory Traversal Zugangsdaten zu finden; besonders häufig tauchten Requests nach .env-Dateien auf.
    • Beispiele für Request-Pfade sind /laravel/.env, /backend/.env, /api/.env, /.env, //.env usw.
    • .env gilt üblicherweise als Datei, die Application-Secrets enthält.
  • Auch AWS-bezogene Dateien und Git-Repository-Konfigurationen wurden durchsucht.
    • Beispiele sind /aws.yml, /.env.bak, /info.php, /.aws/credentials, /config/aws.yml, /.git/config usw.
  • Ebenfalls wiederholt angefragt wurden gängige Verzeichnisse, die versehentlich zurückgelassen worden sein könnten.
    • Beispiele sind /old/, /new/, /test/, /backup/, /temp/ usw.
  • In einigen User-Agents stand Mozlila/5.0, offenbar ein Tippfehler von Mozilla/5.0.
    • Ergebnisse einer GitHub-Suche deuten darauf hin, dass dieser Tippfehler möglicherweise von verbreiteten Tools erzeugt und per Copy-and-paste weiterverwendet wurde.
  • Auch Requests auf Tools für Remote-Zugriff oder Konfigurationstools wurden beobachtet.
    • Beispiele sind /actuator/gateway/routes, /hudson, /ui/login.action, /?XDEBUG_SESSION_START=phpstorm usw.
  • Im öffentlichen Internet sollten nur die unbedingt notwendigen Bestandteile erreichbar sein; wenn Tools oder Verzeichnisse exponiert werden müssen, braucht es eine Authentifizierungsschicht und möglichst Beschränkungen auf bestimmte IPs.

Shellshock-Versuche

  • Mehrere Requests scheinen auf die Shellshock-Schwachstelle gezielt zu haben.
  • Dieser Angriff zielt auf die Ausführung beliebiger Befehle auf Webservern ab, die CGI-Skripte mit einer verwundbaren Bash-Version ausführen.
    • Beim Start eines CGI-Programms werden Umgebungsvariablen aus Request-Inhalten gesetzt; HTTP_USER_AGENT gehört zu den möglichen Zielen.
    • Enthält der Wert Zeichen wie () { :; };, interpretiert Bash dies als auszuführende Funktion.
  • Im User-Agent der tatsächlichen Logs fanden sich Payloads wie die folgenden.
    • () { ignored; }; echo Content-Type: text/html; echo ; /bin/cat /etc/passwd
    • () { ignored; }; hat die Form einer Bash-Funktionsdefinition.
    • echo Content-Type: text/html; echo ; gibt den Content-Type und eine Leerzeile für die HTTP-Antwort aus.
    • /bin/cat /etc/passwd ist ein Befehl, der den Inhalt von /etc/passwd mit Informationen zu Benutzerkonten auszugeben versucht.
  • Wäre der Angriff erfolgreich gewesen, hätte er Zugriff auf Benutzerinformationen und die Ausführung beliebigen Codes auf dem Server ermöglichen können.
  • Wie bei Directory Traversal errieten die Angreifer gängige Pfade wie /cgi-bin/status, /cgi-bin/stats, /cgi-bin/test, /cgi-bin/status/status.cgi, /test.cgi, /debug.cgi, /cgi-bin/test-cgi.

Command Injection gegen LuCI

  • Ein Request scheint auf LuCI, das Webinterface für OpenWRT-Router, gezielt zu haben.
  • Die Angriffs-URL war so aufgebaut, dass im Feld country ein Befehl eingeschleust wurde, um das Shellskript tenda.sh von einem Remote-Server herunterzuladen und auszuführen.
    • Nach dem URL-Decoding wechselte der Befehl nach /tmp, löschte Dateien, lud per wget das Skript herunter, setzte Ausführungsrechte und führte es aus.
  • Das heruntergeladene Skript enthielt Anweisungen, weitere Binärdateien herunterzuladen und auszuführen.
    • Enthalten waren Architekturbezeichnungen wie mips, mpsl, x86_64, arm, arm5, arm6, arm7, i586, i686, powerpc, sh4, m68k, sparc.
    • Der Versuch, Binärdateien für mehrere Architekturen auszuführen, wirkt wie ein Ansatz, die Angriffsfläche zu vergrößern, wenn die Architektur des Zielgeräts unbekannt ist.
  • Für weitere Untersuchungen wurde eine mit der eigenen Umgebung inkompatible Binärdatei heruntergeladen und mit Ghidra untersucht.
    • Anfangs gab es nur drei Funktionen und nicht viele String-Daten.
    • In einem großen Datenbereich wurden die Strings $Info: This file is packed with the UPX executable packer und UPX 3.94 gefunden.
  • Es handelte sich um eine mit UPX gepackte ELF-Binärdatei; sofern UPX-Header oder packed binary nicht verändert wurden, lässt sie sich mit upx -d entpacken.
    • Tatsächlich wuchs die Dateigröße nach upx -d mips von 34932 auf 93732, und es waren deutlich mehr Strings sichtbar.
  • Die Strings der entpackten Binärdatei enthielten M-SEARCH * HTTP/1.1, ST: urn:dial-multiscreen-org:service:dial:1 sowie XML-Payloads für Upgrades von Huawei-Geräten.
    • Dies sieht nach einem UPnP-Befehl aus, der Geräte mit Unterstützung für das DIAL-Protokoll im Netzwerk sucht.
    • Der XML-Payload scheint darauf ausgelegt zu sein, nach Huawei-Geräten zu scannen, die für Command Injection anfällig sind.
    • Dieses Verhalten wurde offenbar als Teil des Mirai-Botnets identifiziert.
  • Die referenzierte Datei yeye.mips war beim Abruf nicht verfügbar.
    • Ein nmap-Scan des Servers zeigte als offene Ports nur 22/tcp ssh und 646/tcp filtered ldp.

Command Injection gegen Zyxel

  • Ein anderer Request enthielt Shell-Befehle in der GET-URL; entfernt man die Shell-Substitution ${IFS}, wird er leichter lesbar.
    • Der bereinigte Befehl wechselte nach /tmp, löschte *mips*-Dateien, lud huhu.mips herunter, setzte Ausführungsrechte und führte die Datei mit dem Argument zyxel.selfrep aus.
  • Dieser Angriff scheint auf einen zhttpd-Exploit für Zyxel-Geräte gezielt zu haben.
  • Diese Binärdatei war nicht gepackt, sodass die Strings in Ghidra direkt sichtbar waren.
    • Zu den Strings gehörten M-SEARCH * HTTP/1.1, der DIAL-bezogene ST-Header, skyljne.arm, skyljne.arm5, skyljne.arm6, skyljne.arm7, skyljne.mips, skyljne.mpsl, skyljne.x86_64, skyljne.sh4 usw.
    • Ebenfalls enthalten war ein XML-Payload, der gegen Huawei-Geräte gerichtet ist, huhu.mips herunterlädt und als selfrep.huawei ausführt.
  • Ein weiterer String enthielt einen Befehl, der einen POST an /goform/set_LimitClient_cfg sendet.
    • Zusammen mit dem Header Cookie: user=admin versucht er, über den Parameter mac einen Befehl einzuschleusen, um huhu.mpsl herunterzuladen und auszuführen.
    • Laut einem Akamai-Beitrag richtet sich diese Schwachstelle gegen Router und kann ohne vorherige Authentifizierung ausgenutzt werden, da keine besonderen Authentifizierungs- oder Autorisierungsprüfungen stattfinden.
  • Es wird als sehr wahrscheinlich eingeschätzt, dass diese Binärdatei ein Agent des Mirai-Botnets ist.
    • Einige Quellen erwähnen auch eine mögliche Verbindung zu Linux Medusa.

Betriebliche Gegenmaßnahmen

  • Die geprüften Logs sind nur ein Ausschnitt; täglich gibt es viele weitere Exploit-Versuche.
  • Es ist wichtig, Geräte, insbesondere IoT-Geräte, aktuell zu halten.
  • IoT-Geräte sollten möglichst nicht direkt im öffentlichen Internet erreichbar sein.
  • Falls sie zwingend exponiert werden müssen, sollten sie nach Möglichkeit in einem separaten VLAN isoliert werden.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-29
Hacker-News-Kommentare

  • Interessanterweise scheinen manche Angreifer Certificate-Transparency-Logs zu überwachen, um neu ausgestellte Zertifikate zu finden.
    Wenn man einen neuen Server auf einer neuen IP länger als eine Woche laufen lässt, sieht man in den Access Logs nur ein paar zufällige Scans; aber etwa eine Stunde nachdem man ein Let’s-Encrypt-Zertifikat erhalten hat, kamen bei mir schon mehrfach Hunderte Requests wie die im Artikel beschriebenen herein.
    Fazit: Neue Dienste sollten so früh wie möglich abgesichert werden, idealerweise bevor sie dem Internet ausgesetzt werden.

    • Es fühlt sich so an, als müsste man vom ersten Moment der öffentlichen Exponierung an zumindest so etwas wie Basic Auth davor schalten.
      Oder man nutzt eine eigene Zertifizierungsstelle und bis zur Umstellung selbstsignierte Zertifikate plus mTLS.
      Wenn eine Software zum Beispiel einen Initial-Setup-Bildschirm für das Anlegen eines Admin-Kontos oder die DB-Verbindung offen ausliefert, ist das riskanter, als diese Werte von Anfang an über Umgebungsvariablen, Konfigurationsdateien oder ein dediziertes Secret-Management-Tool festzulegen.
    • Ich habe mir kürzlich Certificate-Transparency-Logs angesehen und frage mich, ob es bequeme Tools oder Methoden gibt, um CT-Logs abzufragen.
      Zum Beispiel, um Domains innerhalb eines bestimmten Zeitraums zu durchsuchen.
      Cloudflares Merkle Town[0] ist nützlich für einen Überblick, aber eine einfache Möglichkeit, CT-Logs abzufragen, habe ich noch nicht gefunden; ct-woodpecker[1] sieht ebenfalls vielversprechend aus.
      [0] https://ct.cloudflare.com/
      [1] https://github.com/letsencrypt/ct-woodpecker
    • Es hilft auch, häufiger Wildcard-Zertifikate zu verwenden. Allein anhand der CT-Logs wird es dadurch schwieriger, konkrete Subdomains für einen Angriff herauszufinden.
    • Das sind oft weniger Angreifer als vielmehr Dienste wie urlscan.io, die CT-Logs überwachen und das Web crawlen, um Malware zu finden.
    • Ich hoste mehrere Dienste selbst, habe es aber komplett aufgegeben, sie direkt ins Internet zu stellen.
      VPNs sind heutzutage so gut, dass ich damit viel ruhiger schlafe; Dinge wie Fotohosting oder Backups möchte ich besonders ungern öffentlich exponieren.

  • Als ich anfing, eine selbst gehostete Website zu betreiben, habe ich mir auch die Access Logs angesehen und eine Zeit lang sogar ein Intrusion-Detection-System genutzt, das Daten sammelte und eingehende Angriffsversuche anzeigte.
    Am Ende habe ich sowohl die proaktive Durchsicht der Logs als auch das Bezahlen für ein Intrusion-Detection-System aufgegeben; es war Zeitverschwendung und lenkte nur ab.
    Gute Zusammenfassungen gängiger Schwachstellen und Angriffe findet man leicht, und die kann man als Maßstab für die Serveradministration nehmen. Für jede verbreitete Webserver-Technologie gibt es viele Best-Practice-Guides, und allein deren vollständige Umsetzung bringt einen schon weit vor fast alle Angreifer.
    Der nächstbeste Einsatz von Zeit und Ressourcen ist, einen möglichst schnellen Patch-Zyklus zu priorisieren. Die meisten Angriffe zielen auf öffentlich bekannte Schwachstellen.
    Besonders nützlich sind Logs, wenn man nach einem Vorfall eine Diagnose stellen muss. Mit Log-Analyse-Software konnte ich gespeicherte Logs durchsuchen und in zwei oder drei Fällen die Root Cause eines erfolgreichen Angriffs finden; jedes Mal war eine bekannte Schwachstelle die Ursache, die viel zu spät gepatcht worden war.

    • Wenn es in allen Fällen bekannte Schwachstellen waren, die zu spät gepatcht wurden, dann muss ein Ansatz, der nur auf Patches setzt, irgendwann scheitern. Es könnte eine 0-Day-Schwachstelle sein, oder der Angreifer ist schneller.
      Die Lösung ist Defense in Depth, und beim Selbsthosting persönlicher Dienste lässt sich das meist ziemlich einfach umsetzen.
      Man setzt eine Firewall davor oder versteckt den Dienst hinter VPN/Tailscale; wenn man ihn statt unter /phpmyadmin/ unter einem Unterordner wie /mawer/phpmyadmin/ versteckt, den automatisierte Angriffe nicht ansteuern, finden ihn 99,9 % nicht. Das nennt man Security by Obscurity, und man sollte sich nicht allein darauf verlassen, aber als zusätzliche Schicht ist es sehr nützlich.
      Man sollte Apps in Sandboxes betreiben und Server isolieren, damit sich ein Eindringling nach einem Kompromittieren nur schwer weiterbewegen kann, und Logs schreiben, damit man erkennen kann, ob ein Angriff stattgefunden hat und ob er erfolgreich war.
      Der Kernpunkt ist: Man darf sich nicht auf eine einzige Schutzmaßnahme verlassen, egal ob Patch oder Firewall. Irgendeine davon wird am Ende versagen.
    • Mich interessiert der Teil, den schnellstmöglichen Patch-Zyklus zu priorisieren. Nutzt du Tools, um den Patch-Zeitpunkt festzulegen, oder gehst du nach festen Zeitintervallen vor?
      Im Moment versuche ich, Pakete quartalsweise zu aktualisieren[0], aber ein Tool, das mich über bekannte Schwachstellen informiert, damit ich sofort reagieren kann, wäre hilfreich.
      [0] Mit „versuche“ meine ich hier, dass ich nicht sofort upgraden kann, wenn es Breaking Changes gibt, die sich schwer auf die neueste Version übertragen lassen, oder wenn es sich um ein X.0.0-Release handelt, dem ich noch nicht vertraue.

  • Da der Autor gesagt hat, dass er kein Sicherheitsexperte ist, eine kleine Korrektur: Das Beispiel am Anfang ist Credential- und Konfigurations-Scanning, nicht Directory Traversal.
    Unter Directory Traversal verstehe ich eine Technik, bei der ein Angreifer aus dem Webroot „ausbricht“ oder den Server dazu bringt, Dateien außerhalb des normalen Verzeichnisses auszuliefern.

    • Wenn es darum geht, Dateien einzubeziehen, die eigentlich nicht gehostet werden sollten, kann es technisch gesehen beides sein. Zum Beispiel bei "/../../passwd/etc".

  • Zumindest meiner Erfahrung nach ist ein wesentlicher Punkt, dass viele dieser Angriffe von feindlichen staatlichen Akteuren kommen.
    Das ist umstritten, aber es kann sinnvoll sein, ganze IP-Bereiche problematischer Länder zu blockieren, mit denen man ohnehin nichts zu tun hat. Auf diese Weise habe ich einmal 100 % der Scan-Versuche auf einen neuen Dienst verhindert.

    • Das ist nicht das Kernproblem; viele Menschen wollen einfach nicht auch legitime Nutzer aus diesen Regionen aussperren.
    • Schön wäre es, wenn staatliche Akteure keinerlei Möglichkeit hätten, Server in anderen Ländern zu kaufen und von dort aus Angriffe auszuführen.
    • Vor über 15 Jahren, als ich die Server-Logs kleiner lokaler Unternehmen durchsah, die wir hosteten, kam ich zu dem Schluss, dass man APNIC-IP-Adressen komplett blockieren könnte.
    • Geoblocking blockiert am Ende doch nur legitimen Traffic und bringt entschlossene Angreifer dazu, Proxys zu verwenden, oder?
    • Dann müsste man die USA und die Niederlande blockieren.
      Die Scans auf meinen Server kommen größtenteils aus den USA, mit den Niederlanden mit großem Abstand auf Platz zwei. Vermutlich stammt das meiste davon von AWS und anderen Rechenzentren.

  • Ich arbeite im Bereich Anwendungs-/Produktsicherheit und habe über Jahre hinweg WAFs von Unternehmen im Milliarden-Dollar-Bereich verwaltet.
    Man muss das DNS zu Cloudflare umziehen und ein paar WAF-Regeln für die Site einrichten. Zum Beispiel eine Managed Challenge auslösen, wenn der Bot-Score unter 2 liegt, oder entsprechend reagieren, wenn der Attack-Score einen bestimmten Wert erreicht. Das dürfte wahrscheinlich kaum etwas kosten und viele Probleme lösen.
    Vor dem Umzug in die Produktion muss man das aber unbedingt testen. Eine Test-Domain zu haben ist ebenfalls sinnvoll. Eine WAF ist keine Allzwecklösung, sondern eher ein Pflaster; wenn die App selbst nicht so gehärtet ist, dass sie Angriffe aushält, kann sie auch die fortschrittlichste WAF oder Bot Protection nicht retten.

    • Für alle, die damit nicht vertraut sind: https://blog.cloudflare.com/waf-for-everyone/
      Das Free Managed Ruleset scheint standardmäßig ausgerollt zu werden, und Cloudflare pflegt das Änderungsprotokoll hier: https://developers.cloudflare.com/waf/change-log
    • Aus Sicht eines Self-Hosters nutze ich Cloudflares WAF und mutual-TLS-Regeln, um nur die mir bekannten legitimen Aufrufer durchzulassen.
      Das funktioniert sehr gut. Da nur meine Familie darauf zugreift, war die Einrichtung einfach, und jeder hat ein eigenes Zertifikat, das ich bei Bedarf widerrufen kann.
    • Heutzutage verwalte ich meist nur interne Anwendungen, daher ist die Angriffsfläche viel kleiner als bei öffentlichen Diensten.
      Da du dich in diesem Bereich offenbar gut auskennst, würde mich interessieren, ob du auch schon Lösungen mit Azure-Infrastruktur zusammen mit Cloudflare verwaltet hast, und falls ja, ob es abseits der üblichen Dinge wie OWASP Punkte gibt, die Leute häufig übersehen.
    • Für Standard-WordPress-Sites passt das gut, und als zusätzliche Schicht kann man GuardGiant und das Sucuri-Plugin davorschalten.
    • Eine WAF vor die App zu setzen und die Sache damit als erledigt zu betrachten, ist nichts anderes, als einem Schwein Lippenstift aufzutragen.
      Wenn ein Unternehmen aus irgendeinem Grund unbedingt etwas betreiben muss, das nicht auf dem neuesten Stand ist, kann das nötig sein, aber am Ende bleibt es nur ein Pflaster.

  • Ich hoste seit etwa einem Jahr einen selbst entworfenen HTTP/S-Server mit 400 Zeilen Code selbst, und die Menge an Angriffs-Traffic, die über die drei offenen Ports (22, 80, 443) hereinkommt, ist erstaunlich hoch.
    Allerdings habe ich mir nie die Zeit genommen zu analysieren, was die Angreifer eigentlich versuchen; dieser Artikel füllt viele Lücken.
    Die merkwürdigen Dinge in /var/log/auth.log auf die gleiche Weise zu analysieren, wäre ebenfalls gut.
    Der gesamte Code ist Open Source und es gibt keinen serverseitigen Zustand, daher ist es seltsam, dass ein Angreifer ausgerechnet mich ins Visier nehmen sollte. Das Beste, was er bekommen könnte, wäre Root-Zugriff auf einen 5-Dollar-im-Monat-VPS und eine vorübergehende Verunstaltung einer Domain, die niemand besucht.

    • Das sind alles automatisierte Bots. Niemand kümmert sich gezielt darum.
      Wenn man die drei bekanntesten Ports öffnet, kommen Verbindungen herein; sie wissen weder, was du betreibst, noch interessiert es sie.
    • Zugriff auf dein VPN ist ein guter Ausgangspunkt für Angriffe auf andere Maschinen und fügt eine weitere Ebene hinzu, um Spuren zu verschleiern.
      Auch das Hosten von Malware oder das Ausführen eines Kryptowährungs-Miners ist möglich.
    • Bei Port 22 kann man erwägen, nur die eigene IP zuzulassen und den Rest zu blockieren.
      Mein ISP ändert die IP tatsächlich kaum, und wenn sie sich ändert, kann ich mich im Web-Admin-Panel des Hosters anmelden und die Regel aktualisieren.

  • Auf jedem Server lasse ich unbedingt fail2ban laufen und füge auch eigene Jails hinzu, um Angriffe abzufangen, die auf die Art der jeweils exponierten Site-Funktionalität zugeschnitten sind.
    Allerdings habe ich schon lange nicht mehr geprüft, ob die anderen Standardwerte von fail2ban noch ausreichen, um gängige Angriffe zu blockieren. Ich sollte diesen Link für später bookmarken.

    • Wenn dein System eine Schwachstelle offenlegt, die so leicht zum Ziel wird, wird fail2ban dich nicht retten.

  • Ich prüfe ebenfalls die Access-Logs meiner selbst gehosteten Dienste, und in dieser Analyse fehlt ein Detail, das deutlich auffällt.
    Ein großer Teil der bösartigen Requests stammt von ganz normalen Leuten, die Security-Scanner ausführen, die man leicht auf GitHub oder anderswo findet. Meist sind das keine ausgefeilten Angriffe; Instanzen solcher Projekte hämmern auf Server ein, ohne sich überhaupt die Antworten anzusehen oder darauf zu achten, ob sie gedrosselt wurden.
    Manche Angriffe zielen nicht direkt auf IPs, sondern überwachen Domains und Subdomains und wiederholen regelmäßig denselben Scan aus demselben IP-Bereich.
    Bei einem früheren Arbeitgeber kamen ständig wiederholte Scans von einer einzelnen statischen IP aus der Türkei; das Team begann, sie „den Türken“ zu nennen, und bei seltsamen Request-Mustern gehörte es zur Incident Response, zuerst zu prüfen, ob diese Person gerade unseren Dienst anfasst.

  • Wenn man solche Logs bei AWS sieht, sollte man bitte AWS WAF vor die VPC setzen.
    Das ist nicht teuer und hilft in solchen Situationen ziemlich gut dabei, viele Kopfschmerzen zu reduzieren. Selbst wenn es nicht alles blockiert, was bis zum Service durchkommt, kann es eine große Hilfe sein.

    • Guter Vorschlag, aber mit den Standard-Regelsätzen sollte man vorsichtig sein. Wir haben AWS WAF wegen SOC-2-Compliance aktiviert.
      Einige überaktive Regeln haben Teile der App unauffällig kaputtgemacht.
      Es gab eine Request-Body-Regel, die Anfragen blockierte, wenn der Request-Body "localhost" enthielt, und auch eine Regel, die Requests ohne User-Agent-Header blockierte. Da wir vorher für API-Requests keinen User-Agent verlangt hatten, hat das für einige Nutzer die gesamte API kaputtgemacht, bis wir die Ursache gefunden hatten.
    • Die im Artikel genannten Angriffe sollten für keine moderne Webanwendung ein Problem sein. Deshalb verstehe ich nicht, warum man eine WAF hinzufügen sollte.
    • Die AWS-WAF-Standardregeln zu verwenden, ist nicht ganz so einfach. In unserer Anwendung wurden viele legitime Requests und IPs blockiert.
      Man muss wissen, was blockiert wird, und es zuerst validieren; sonst verliert man in manchen Fällen Kunden.
    • Tatsächlich richtet eine WAF oft mehr Schaden an, als sie hilft.
      Sie vermittelt ein trügerisches Sicherheitsgefühl, obwohl sie leicht umgangen werden kann, verursacht erhebliche Performance-Kosten und hat ein beträchtliches Risiko, legitimen Traffic zu blockieren: https://www.macchaffee.com/blog/2023/wafs/
    • WAFs neigen dazu, breit zu blockieren, und manchmal ist der Grund unklar.
      Zum Beispiel erforschen Forschende an unserer Universität Twitter-Daten, und weil sie Links aus einer kleinen zufälligen Stichprobe von Tweets folgen, werden die IPs der Universität von den meisten WAFs blockiert.

  • Manchmal kommt mir der Gedanke, dass es lustig wäre, einen Express-Server zu bauen, der auf einen dieser Angriffe korrekt reagiert und damit jemandes Zeit verschwendet
    Aber dadurch würde ich auch meine eigene Zeit verschwenden