Webanwendungen schützen mit AWS Web Application Firewall und Shield (1)
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 ersten Teil der Workshop-Serie beschreiben wir die Grundlagen der Services und wie Sie mit Managed Rules und Geofencing für Sicherheit sorgen.
Das Internet hat eine schier unendliche Teilnehmerzahl: Neben Computern haben längst Smartphones und Tablets in den meisten Haushalten Einzug gehalten, ganz abgesehen von weiteren Geräten wie Smart-TVs, digitalen Assistenten und einer Vielzahl von IoT-Devices. All diese Teilnehmer nutzen Webanwendungen, um Mehrwerte für den Nutzer zu schaffen. Das ist auch für Angreifer die erste Gelegenheit, um Attacken zu planen und auszuführen, oftmals mithilfe von Botnetzen – laut aktuellen Schätzungen gehen rund 40 Prozent des Internet-Traffics von Bots aus.
So schützt AWS WAF
Eine Web Application Firewall (WAF) schützt Anwendungen, indem sie den HTTP-Request auf unerwünschte Inhalte prüft, bevor dieser in der eigentlichen Anwendung landet. Meistens sitzt die WAF auf der Ebene eines Loadbalancers oder von Reverse Proxies, bei global verteilten Anwendungen ist sie oftmals Teil des Content Delivery Network (CDN). WAFs werden für gewöhnlich mit dem Schutz vor Angriffen in Verbindung gebracht, die Einsatzmöglichkeiten sind jedoch deutlich vielfältiger.
Bei AWS funktioniert der gleichnamige Service so: Die Konfiguration eines oder mehrerer Workloads wird in einer Web-ACL (Web Access Control List) abgebildet. Innerhalb einer solchen Liste sind mehrere WAF-Regeln mit unterschiedlichen Prioritäten angeordnet, wobei sich für jede Regel eine abschließende Aktion definieren lässt: "allow", "deny", "count". Die ersten beiden sind selbsterklärend, die count-Aktion bedeutet, dass die Regel nicht in den Request eingreift, jedoch Metriken für das Zutreffen einer Regel erzeugt. So kann ein Betreiber einer Webanwendung vorab nachvollziehen, ob eine Regel den gewünschten Effekt erzielen wird.
Weiterhin gibt es die Aktionen "CAPTCHA" und "challenge", die wir im weiteren Verlauf des Artikels noch näher erläutern werden. Im Folgenden betrachten wir Anwendungsbeispiele von AWS WAF anhand verschiedener Szenarien.
Patchen dauert oft zu lang
Im Dezember 2021 rüttelte die Entdeckung der Log4Shell-Sicherheitslücke die IT-Welt durch. Diese Schwachstelle ermöglicht es Angreifern, beliebigen Code über das Log4J-Framework mittels Zeichenmanipulation in bestehende Java-Anwendungen einzuschleusen. Sie gilt bis dato als kritischste und größte Sicherheitslücke des vergangenen Jahrzehnts.
Tatsächlich wurden die nötigen Patches zum Beheben der Sicherheitslücke bereits drei Tage vor Bekanntgabe veröffentlicht. Klingt in der Theorie gut, in der Praxis ist der positive Effekt davon aber gering: Der Großteil bestehender Quellcodes ist so stark in Abhängigkeiten, Business-Prozesse, Testzyklen und vor allem in Legacy-Systeme eingebunden, dass sich oftmals nicht "mal eben" ein Patch ausrollen lässt.
Was also tun, wenn die IT-Abteilung temporär mit einer unsicheren Komponente leben muss, bis alle Abhängigkeiten aufgelöst und die notwendigen Tests abgeschlossen sind? Da die Angreifer die Sicherheitslücken via Internet ausnutzen und hierfür Webformulare und API-Aufrufe verwenden – also POST/PUT-Requests – liegt der Gedanke nahe, eine WAF einzusetzen.
Managed Rules und Geofencing
Mit sogenannten "Custom Rules" kann jeder AWS-WAF-Nutzer HTTP-Requests und deren Inhalte inspizieren. So lassen sich fein abgestimmte, individuelle Regelsätze für jede Art von Webanwendung erstellen. Geht es um etablierte Sicherheits-Best-Practices, beispielsweise jene, die sich aus den OWASP Top 10 ableiten, bietet die WAF von AWS sogenannte "Managed Rules" an. Nutzer können solche verwalteten Regelsätze verwenden, um für bereits bekannte Schwachstellen und Angriffsmuster keine eigenen Regeln erstellen und verwalten zu müssen. Neben solchen, die von AWS gepflegt werden, ist auch die Nutzung verwalteter Regelsätze von verschiedenen Sicherheitsanbietern im AWS Marketplace eine Option.

Um das Beispiel Log4Shell wieder aufzugreifen: AWS reagierte zeitnah auf die Sicherheitslücke und veröffentlichte bereits am nächsten Tag ein Security Bulletin. Wenige Tage später wurden dann die AWS WAF Managed Rules der Kategorie "Known bad inputs" auf die Eingabemuster von möglichen Angriffen durch Zeichenketten angepasst.
Betreiber von regulierten Workloads haben oftmals zudem die Anforderung, Ihre Internetanwendung nur in bestimmten Ländern und geografischen Regionen zugänglich zu machen. Hier hilft eine einfache Regel in AWS WAF weiter, die auf das Ursprungsland (nach ISO 3166) des Besuchers anhand der IP-Adresse prüft. Neben der Möglichkeit, Requests zu blocken oder zu erlauben, setzt die WAF hier selbstständig sogenannte Labels, die der Betreiber weiter verwenden kann, um den Request näher zu untersuchen. Denn: Nicht selten werden solche Ländersperren durch den Einsatz von Proxys oder VPNs umgangen.
Eine weitere Managed Rule, "Anonymous IP List", identifiziert Requests, die von Rechenzentren oder Anonymisierungsdiensten ausgehen, und kann entsprechend helfen zu entscheiden, wie mit dem Request weiter zu verfahren ist.
ln/David Heidt
Im zweiten Teil der Workshopserie erfahren Sie, wie Sie mit WAF Bots abwehren, Account Takeover verhindern und wie Best Practices für AWS WAF aussehen könnten. Im dritten und letzten Teil dreht sich alles um AWS Shield und wie Sie damit DDoS-Angriffe zurückschlagen und Webanwendungen absichern.