Webanwendungen schützen mit AWS Web Application Firewall und Shield (2)
Wer als Unternehmen eine Webseite oder -anwendung betreibt, muss sich meist früher als später mit Angriffen auseinandersetzen. Bei deren Abwehr spielen neben einem umfassenden Sicherheitskonzept Schutzdienste auf Perimeter-Ebene eine entscheidende Rolle. Sie prüfen Verbindungen an erster Stelle, verifizieren sie und weisen sie gegebenenfalls ab. AWS hat hierzu WAF und Shield im Portfolio. Im zweiten Teil erfahren Sie, wie Sie mit WAF Bots abwehren, Account Takeover verhindern und wie Best Practices aussehen könnten.
Bots müssen draußen bleiben
Die Managed Rule "Bot Control" bietet zwei Erkennungsmodi: "Common" und "targeted". Beginnen wir mit den Common Bots, also denen, die für das Internet nützlich sein können – denn sie füllen die Indizes von Suchmaschinen, Social Media, Preisvergleichsportalen und so weiter. Auch wenn diese Bots per se nicht bösartig sind, verursachen sie doch Last auf den Systemen, die sie besuchen. Ferner gibt es Angreifer, die ihre Bots so entwickeln, dass diese sich durch Manipulation des User-Agent-Headers als bekannte Bots ausgeben.
Viele Betreiber von gutartigen Botnetzen bieten daher die Möglichkeit, Ihre Crawler durch Reverse-DNS- oder ASN-Lookups zu verifizieren. Diese Verifizierung übernimmt bei AWS die WAF-Regel "Bot Control" im Common-Modus. Sie erlaubt Seitenbetreibern zum einen, die "falschen" Bots zu blocken, zum anderen aber auch mit gerechtfertigten Anfragen entsprechend umzugehen: Verursacht zum Beispiel ein Suchmaschinen-Crawler zu viel unnötige Daten oder zu viel Last auf der Anwendung, kann das Unternehmen eine sogenannte "Rate-based Rule" einsetzen, die dem Bot lediglich eine bestimmte Anzahl pro Requests in einem Fünf-Minuten-Intervall erlaubt und nach Überschreitung alle unmittelbar darauffolgenden Anfragen der HTTP-Etikette gemäß mit dem Antwortcode 429 (too many requests) abweist. So lässt sich die eigene Anwendung schützen, ohne das Verhalten des Bot-Betreibers abzustrafen.
Neben diesen sehr eindeutig erkennbaren Bots gibt es jene, die aufwendiger programmiert sind und die Engines gängiger Browser verwenden: Sie lassen sich nur sehr schwer bis gar nicht von menschlichen Besuchern unterscheiden und können komplexere Abfolgen von Befehlen und Anfragen, wie zum Beispiel einen Opt-in-Vorgang, ausführen und sogar JavaScript interpretieren. Solche Bots werden meist mit mehr Aufwand und zu einem bestimmten Zweck zielgerichtet entwickelt, daher rührt der Name des Erkennungsmodus der Bot-Control-Regel: Targeted.
Derart fortgeschrittene Bots sind weniger durch einen einzelnen Request erkennbar, sondern durch ihr Verhalten. Targeted Bot Control wendet unterschiedliche Mechanismen zur Erkennung an, etwa Browser Fingerprinting, Captcha, dynamisches Rate-Limiting und JavaScript Challenges. Da sich das Aufspüren schwieriger gestaltet, sind die WAF-Kosten hierfür höher als bei den Common Bots. Es empfiehlt sich daher, die Regel mit einem sogenannten "scope-down statement" zu versehen, um die Anzahl der zu inspizierenden Requests auf das Notwendigste zu reduzieren.
Account Takeover verhindern
Die überwiegende Anzahl der Personen im Internet nutzt Konten bei mehreren Plattformen: Social Media, E-Mail, Shopping, Banking und so weiter. Nicht selten findet dabei dieselbe Kombination aus Benutzername und Passwort Verwendung – entgegen allen Empfehlungen und technischen Möglichkeiten, nicht selten, weil die digitale Welt trotz aller Verbesserungen bei der Nutzererfahrung nach wie vor eine große Herausforderung für manche Menschen darstellt. Denn es ist schlicht sehr einfach, sich nur ein Passwort merken zu müssen.
Leider kommt es dadurch immer wieder zu sogenannten Data Breaches: Zugangsdaten von Internetportalen kommen durch Angriffe oder aufgrund einer ungenügenden Absicherung abhanden und bilden die Grundlage für weitere Angriffe. Die Konten der User, die ein Passwort mehrfach verwenden, sind hier besonders gefährdet. Angreifer können Listen von kompromittierten Zugangsdaten in speziellen Börsen im Darknet käuflich erwerben. Das Angriffsmuster, das sich daraus ableitet, nennt sich "Credential Stuffing". Der Angreifer nutzt dabei oftmals automatisiert alle ihm zur Verfügung stehenden Zugangsdaten, in der Hoffnung auf einen erfolgreichen Login in einem Account, von wo er dann Geld, Informationen oder Dienste des Opfers stehlen kann. Dies ist oftmals mit einer Passwortänderung verbunden, die das Opfer aus dem eigenen Konto aussperrt.
Die Managed Rule "Account Takeover Prevention" (ATP) schützt Clients unter anderem, indem sie die Eingaben von Benutzername und Passwort mit bereits bekannten Listen von kompromittierten Zugangsdaten verschlüsselt abgleicht. Die WAF-Aktion auf eine positive Aktivitätserkennung kann der WAF-Betreiber selbst wählen: So lässt sich anstelle einer Abweisung (block) des Requests der Webanwendung durch einen zusätzlichen HTTP-Header die Information einer möglichen Kompromittierung weitergeben. In diesem Zug kann die Anwendung dann beispielsweise eine Zweifaktor-Authentifizierung auslösen oder den User auf eine Passwort-Reset-Seite umleiten. Zusätzlich erkennt ATP Loginversuche durch Brute Force, das vermehrte Auftreten von missglückten Logins sowie andere Unregelmäßigkeiten beim Loginvorgang.
Best Practices für AWS WAF
Nicht selten kommen die bisher gezeigten Bedrohungen zusammen in einem Workload vor. Es spricht daher nichts dagegen, Managed Rules, Bot Control, ATP und weitere WAF-Features wie beispielsweise benutzerdefinierte Regeln in einem Szenario zu kombinieren. Die von AWS verwalteten Regeln (AWS Managed Rules) sind in jedem Fall ein guter Basisschutz für sämtliche Webanwendungen, vor allem die Regelgruppe "core". Je nach Anwendungsfall lassen sich weitere Regeln davor (für Ausnahmen) oder danach (zur weiteren Absicherung) hinzufügen.
Sicherheitsverantwortliche sollten jede neue Regel mit der "count"-Aktion verknüpfen, zusammen mit aktiviertem Logging. Letzteres ist im produktiven Einsatz besonders wichtig, denn von einer WAF geblockte Requests tauchen in keinem Access- oder Anwendungslog mehr auf. Für die Targeted Bot Control als auch für Account Takeover Prevention bietet AWS WAF ein JavaScript- und Mobile-SDK an, das in den clientseitigen Teil der Anwendung integriert werden sollte. Die Erkennungsrate lässt sich dadurch erheblich verbessern. AWS WAF ist, wie viele Dienste des Cloudanbieters, vollständig durch CLI-Befehle und API konfigurierbar. Eine WAF ist der erste Kontaktpunkt zum Client – deshalb gilt hier ganz besonders, menschliche Fehler zu vermeiden und stattdessen einen DevOps-Ansatz für ein Deployment mit CI/CD in Betracht zu ziehen.
ln/David Heidt
Im dritten und letzten Teil der Workshopserie dreht sich alles um AWS Shield und wie Sie damit DDoS-Angriffe zurückschlagen und Webanwendungen absichern. Im ersten Teil haben wir die Grundlagen der Services beschrieben und wie Sie mit Managed Rules und Geofencing für Sicherheit sorgen.
