Warum scheinen Web Application Firewalls so komplex zu sein?

Wenn wir mit Interessenten und Kunden über Cloud-Security sprechen, kommt unweigerlich Komplexität als Herausforderung zur Sprache. Viele Angriffe auf Web-Applikationen waren erfolgreich, da sie auf falsch konfigurierte Web Application Firewalls (WAFs) abzielten. Einer der beliebtesten Angriffe – SQL Injection (SQLi) – ist nicht neu, aber viele Organisationen scheinen nichts daraus gelernt zu haben, seit Heartland Payment Systems 2008 erfolgreich mit SQL Injection gehackt wurde. Heartland war zu diesem Zeitpunkt der sechstgrößte Zahlungsverkehr-Abwickler in den USA und der Verstoß kompromittierte Millionen von geschäftlichen und privaten Kredit-/Debit-Konten.

Heartland verfügte zwar über eine Web Application Firewall, aber die Security-Konfiguration des Unternehmens schützte nicht vor dem SQLi-Angriff. Das Unternehmen zahlte eine Entschädigung in Höhe von 145 Millionen USD, verlor vorübergehend seine PCI DSS-Compliance und sein Aktienkurs fiel in den folgenden drei Monaten um fast 80 %. Trotz der enormen Kosten und der negativen Publicity rund um diesen Angriff entfielen 2020 immer noch mehr als 68 % aller Angriffe auf Web-Applikationen auf SQLi. Das ist ein Anstieg von 44 % gegenüber 2017.

Da SQL-Injection als „leichte Beute“ auf der Skala der potenziellen Webangriffe gilt, wird schnell klar, dass es zahlreiche Möglichkeiten gibt, Web-basierte Seiten anzugreifen und ein ebenso beeindruckendes Aufgebot an Lösungen, um sie zu verhindern. Jeder Angriff kann etwas anders sein und auf einen einzelnen Schwachpunkt abzielen. Darin liegt die Komplexität.

SQL-Injection ist das einfachste Beispiel: „Traue niemandem“ und „Verwende kein dynamisches SQL“. Das ist leichter gesagt als getan, vor allem in einer Welt des externen Arbeitens. Eine Web Application Firewall verfügt über spezielle Funktionen, um verdächtigen Code und versuchte Einschleusungen zu identifizieren Injection, aber sie müssen richtig angewendet werden.

SQLi ist nicht die einzige Art eines erfolgreichen Angriffs auf Web-Applikationen. Der zweitbeliebteste ist ein Distributed-Denial-of-Service- oder DDoS-Angriff, bei dem eine Website im Wesentlichen mit falschen, automatisierten Anfragen überschwemmt wird, die zum Absturz führen. Die Security und die Konfiguration, die Sie benötigen, um DDoS zu verhindern, unterscheiden sich deutlich von denen, die Sie zur Abwehr von SQLi, Cross-Site Scripting und anderen Angriffen benötigen.

Gründe, warum so viele Angriffe erfolgreich sind

Web Application Firewalls sind so konzipiert, dass sie alle diese Web-basierten Angriffe verhindern. Warum gibt es also noch so viele erfolgreiche Angriffe? Es stellt sich heraus, dass die Websites und Kunden von Organisationen zusammen eher einzigartig als ähnlich sind. Eine WAF muss für jede Organisation und jede Benutzergruppe konfiguriert werden. Zurück zu unserem SQLi-Beispiel: Wenn eine Organisation mit vom Benutzer bereitgestelltem Code arbeitet, könnte sie versucht sein, den SQL-Untersuchungsanteil einer WAF einfach zu deaktivieren. Das ist der Fehler, den Heartland gemacht hat.

Eine weitere beliebte Funktion ist das Geoblocking, das alle IP-Adressen blockiert, die von einem bekannten Hacker-Hotspot oder -Standort stammen. Dies kann eine gute Idee für Unternehmen sein, die nicht international tätig sind. Viele Unternehmen sind jedoch international tätig, da sie entweder ins Ausland verkaufen oder Waren aus dem Ausland beziehen. Das Blockieren einer ganzen Region ist für diese Unternehmen möglicherweise keine Option.

Die Konfiguration einer WAF ist ein Balanceakt. Wenn Sie alle Schutzmaßnahmen aktivieren und den gesamten Datenverkehr blockieren, kommt am Ende kein Datenverkehr mehr zu Ihrer Anwendung. Ihre Online-Geschäft ist nicht mehr im Geschäft. Viele Unternehmen richten ihre Web Application Firewalls im Überwachungsmodus ein. Bestimmte Schutzmaßnahmen werden eingesetzt, aber die WAF überwacht auch im Hinblick auf bestimmte Angriffe, damit das IT-Team die Security bei Bedarf verstärken kann.  Das andere Ende des Spektrums ist die Bereitstellung einer einfachen „Einheitsgröße“-Security in einer als Service bereitgestellten WAF. Dies funktioniert bis zu einem gewissen Grad, versagt aber, wenn die Organisation auf eine Anwendung oder einen Benutzer stößt, die dem „Einheitsgröße“-Parameter dieser Geräte nicht entsprechen und die Unternehmen den Schutz einfach für alle Benutzer ausschalten. Es ist ein architektonisches Problem. Diese einfachen WAFs setzen einen zentralen Regelsatz (CRS) ein, der bestimmt, ob Daten durch die WAF gehen oder nicht. Eine Reverse-Proxy-WAF hingegen fängt die Daten ab und untersucht jedes Paket in beide Richtungen. Die WAF wendet dann benutzerdefinierte Regeln an, je nachdem, was sie im Paket findet.

Wie Barracuda Sie unterstützen kann

Bei Barracuda haben wir erkannt, dass wir eine Web Application Firewall entwickeln können, welche die besten Funktionen und Vorteile jeder Lösung bietet. Wir konnten unsere WAF in einem Cloud-Rechenzentrum einrichten, einen „Standard“-Regelsatz erstellen, der auf dem basiert, was wir in den letzten mehr als 10 Jahren der WAF-Entwicklung festgestellt haben und dies als eine SaaS-Lösung anbieten, die über alle „Knöpfe und Schalter“ einer WAF mit vollem Funktionsumfang verfügt. Grundlegende Schutzmechanismen, die für die meisten Anwendungsfälle geeignet sind, sind bereits aktiviert, aber Organisationen können Anpassungen vornehmen, wenn sie Apps und Benutzer betreffen, die der Standardschutz nicht ordnungsgemäß schützt.

Kurz gesagt, wir bieten die gesamte Leistung einer traditionellen Web Application Firewall mit der Einfachheit und Leichtigkeit einer als Service bereitgestellten WAF.

Barracuda WAF-as-a-Service ist ein mit allen Funktionen ausgestatteter Anwendungssicherheit-Service, der in nur wenigen Minuten mit dem Schutz Ihrer gesamten Apps beginnen kann.