Websites und Webanwendungen vor Angriffen zu schützen, ist heute wichtiger denn je. Monat für Monat lesen wir Schlagzeilen über Unternehmen, die von Cyberattacken getroffen wurden. Im April 2025 führte ein Angriff auf den britischen Einzelhändler Marks & Spencer zu geschätzten 400 Millionen Dollar Umsatzverlust.
Wie lassen sich die Risiken solcher hartnäckigen Bedrohungen am effektivsten behandeln?
Die bewährteste Methode ist der „Defense-in-Depth“-Ansatz: es handelt sich hierbei um mehrere, voneinander unabhängige Sicherheitsschichten, die wie die Ringe einer Zwiebel aufgebaut sind. Selbst wenn eine Schicht überwunden wird, bleiben weitere aktiv, um Angriffe abzuwehren.
Eine Web Application Firewall (WAF) ist ein zentrales Element einer mehrschichtigen Sicherheitsstrategie. Sie überwacht den Webverkehr, erkennt verdächtige Anfragen und blockiert diese proaktiv. So werden öffentlich erreichbare Websites und Anwendungen davor geschützt, zum leicht erreichbaren Ziel für Angreifer zu werden.
Für jeden öffentlich zugänglichen Webservice ist eine WAF heute quasi Pflicht. Viele Sicherheitsstandards (z. B. PCI DSS) und interne Sicherheitsrichtlinien schreiben ihren Einsatz sogar verbindlich vor.
Wenn die Sicherheitsvorteile so überzeugend sind, wo liegt dann der Haken?
Die zusätzlichen Prüfungen und Regeln einer WAF können Fehlalarme auslösen: harmlose Anfragen werden irrtümlich als Angriff gewertet und blockiert. Das kann sowohl Nutzer frustrieren als auch Entwickler in eine endloses Fehlersuche zwingen.
Dieser Blogbeitrag ist der erste einer Serie zu WAF-Funktionen. Er behandelt:
Was ist ein Fehlalarm?
Warum sind Fehlalarme problematisch?
Wie lassen sich Fehlalarme beheben
Und wie unterstützen die erweiterten WAF-Features in Progress LoadMaster 360 dabei?
Beim Einsatz einer WAF, wie der in Progress Kemp LoadMaster integrierten, läuft der Grundprozess immer gleich ab: Jede eingehende HTTP-Anfrage eines Nutzers wird Schritt für Schritt anhand einer Reihe vordefinierter WAF-Regeln überprüft. Jede dieser Regeln ist darauf ausgelegt, ein bestimmtes schädliches oder ungewöhnliches Verhalten zu erkennen.
Beispiele für solche WAF-Regeln sind:
Fehlender Host-Header? (Ein Standardbestandteil jeder Webanfrage)
Zugriff auf verdächtige Dateitypen? (z. B. .bat, .conf, .ini)
Enthält die Anfrage SQL-Befehle? (Möglicher Hinweis auf einen Injection-Angriff)
Eine legitime HTTP Anfrage sollte alle Erkennungsregeln problemlos passieren können und als harmlos eingestuft werden. Die WAF gibt sie dann frei und leitet sie an den Anwendungsserver weiter. Das sieht in etwa so aus:
| Wussten Sie schon? Eine leistungsfähige WAF – wie die LoadMaster WAF – kann nicht nur eingehende Anfragen prüfen, sondern auch ausgehende HTTP Antworten inspizieren. Damit lassen sich etwa versehentliche Datenlecks sensibler Informationen erkennen. Diese Antwortprüfung ist jedoch deutlich seltener als die Prüfung eingehender Anfragen. Um den Fokus zu behalten, betrachten wir in diesem Beitrag nur eingehenden Traffic. |
Was passiert, wenn eine legitime Anfrage dennoch eine WAF-Regel nicht passieren kann? Das gilt als Fehlalarm. In diesem Fall stuft die WAF die eigentlich harmlose Anfrage fälschlich als potenziell gefährlich ein – und blockiert diese womöglich komplett.
Das erste und offensichtlichste Problem: Frust bei den Nutzern.
Stellen Sie sich vor, Sie klicken im Onlineshop auf „Bestellen“ und werden statt einer Bestätigung mit einer „403 – Zugriff verweigert“-Fehlermeldung abgewiesen.
Das ist einfach nur ärgerlich. Fehlalarme blockieren echte Anfragen und hindern Ihre Kunden daran, das zu tun, was sie eigentlich wollten.
Verärgerte Nutzer beschweren sich dann möglicherweise beim Support. Das kann schnell Druck von Seiten des Managements erzeugen, die WAF zu deaktivieren oder ganz zu entfernen, was eine gravierende Sicherheitslücke zugunsten vermeintlicher Benutzerfreundlichkeit auslöst.
Wenn eine WAF viele Fehleralarme generiert, gehen die echten Angriffe leicht im Rauschen unter. Wichtige Sicherheitsinformationen können auf diese Weise verloren gehen. Darüber hinaus schenken Betriebs- und Sicherheitsteams den Warnungen einer WAF natürlich weniger Aufmerksamkeit, wenn sie dafür bekannt ist, ständig Fehlalarme auszulösen: Dies führt wiederum dazu, dass echte Angriffe übersehen werden.
Oft werden Fehlalarme durch vom Nutzer eingegebene Daten ausgelöst, wie z.B. Benutzernamen, Passwörter, Lieferadressen usw.
Wenn eine WAF-Regel fälschlicherweise anschlägt, landet diese Information häufig im Klartext im WAF-Logfile.
Das kann schnell zum Verstoß gegen Datenschutzgesetze wie DSGVO, CCPA, PCI DSS und andere führen. Fehlalarme sind also nicht nur ärgerlich, sondern können auch rechtliche Probleme verursachen, wenn sensible Daten protokolliert werden.
Ein Beispiel für personenbezogene Daten, die einen Fehlalarm verursachen und protokolliert werden:
Um es möglichst einfach und reibungslos zu gestalten, gehen einige kommerzielle WAF-Anbieter das Problem von Fehlalarmen an, indem sie es größtenteils ignorieren.
In der Praxis zeigt sich das oft in Form von unterdrückten Meldungen. Regelverstöße werden nur dann angezeigt, wenn sie zu einer vollständigen Blockierung führen oder einer niedrigen Empfindlichkeitseinstellung, bei der eine Anfrage gleich mehrere Regeln verletzen muss, bevor sie blockiert wird.
Diese Vorgehensweise führt oft zu einer „Einrichten und vergessen“-WAF, die leise arbeitet und kaum Aufmerksamkeit erfordert.
Klingt im ersten Moment verlockend, doch der Haken ist: Die niedrige Empfindlichkeit macht das System deutlich leichter zu umgehen und liefert wahrscheinlich nicht das erwartete Schutzniveau.
Mit einer reduzierten Sensibilität muss ein Angriff schon sehr auffällig sein, um erkannt zu werden. Zudem erschwert oder verhindert das Unterdrücken von Fehlalarmen eine gründliche Analyse und nachhaltige Behebung der Ursache.
Die sicherste und effektivste Vorgehensweise ist es, Fehlalarme konsequent zu eliminieren. Tritt ein Fehlalarm auf, sollte die zugrunde liegende Erkennungsregel untersucht werden.
Zum Beispiel: Ist die Regel, die den Fehlalarm verursacht, für die geschützte Webanwendung irrelevant (z. B. eine PHP-Injection-Regel, obwohl PHP nirgendwo verwendet wird)? Falls ja, kann die Regel deaktiviert werden, und das durch sie verursachte Rauschen bzw. die Fehlalarme verschwinden sofort.
Verursacht die betreffende Regel nur in einem bestimmten Teil der Webanwendung Probleme, funktioniert aber ansonsten einwandfrei? Dann kann die Regel für diesen problematischen Bereich angepasst oder deaktiviert werden, z. B. für /webstore/quote-form – und die Fehlalarme verschwinden.
Verursacht eine bestimmte Benutzereingabe regelmäßig Fehlalarme bei bestimmten Regeln? Zum Beispiel ein Freitextfeld, in dem Benutzer eine Lieferanmerkung schreiben und absenden können. Die Fehlalarme lassen sich beseitigen, indem das Freitextfeld von den problemverursachenden Regeln ausgeschlossen wird (oder sogar von allen Erkennungsregeln, falls es im gesamten System erhebliche Probleme verursacht).
Wenn man systematisch vorgeht und die störenden Fehlalarme wegjustiert, bleiben am Ende nur noch die echten Angriffe übrig, die auf einem gut abgestimmten WAF klar erkennbar und leicht blockierbar sind.
Der Prozess des Feinjustierens von WAF-Regeln, um Fehlalarme zu beheben, beinhaltet das Prüfen von Protokolldateien, das Auffinden der Fehlalarme und deren Behebung. Eine typische Strategie besteht darin, zunächst die auffälligsten Fehlalarme zu lösen: Sie finden, vollständig beheben und dann den Prozess wiederholen.
Idealerweise würde dieser anfängliche Abstimmungsprozess in einer isolierten Testumgebung stattfinden, um die Möglichkeit auszuschließen, einen echten Angriff fälschlicherweise als Fehlalarm zu identifizieren. Zeit und Ressourcen lassen dies jedoch oft nicht zu, sodass die Arbeit mit echtem Datenverkehr ab Tag eins häufig unvermeidlich ist.
Die Identifizierung eines echten Fehlalarms erfordert Erfahrung. Nützliche Anzeichen dafür sind zum Beispiel:
Die ausgelöste Regel (verursacht sie häufig oder nur selten Fehlalarme?)
Die Quell-IP-Adresse (ist dies eine erwartete Adresse? Wo befindet sie sich?)
Die aufgerufene Ressource (sieht der Zugriff legitim aus oder ist er verdächtig?)
Die Tageszeit (wird eine Geschäftsanwendung während der Bürozeiten oder um 4 Uhr morgens aufgerufen?)
Sobald ein Fehlalarm identifiziert wurde, wird er durch das Schreiben einer neuen Regel behoben, um die problematische Regel durch Anpassung ihres Verhaltens zu tunen. Dies sollte idealerweise vorsichtig erfolgen, sodass legitimer, blockierter Datenverkehr wieder zugelassen wird, ohne dabei eine Sicherheitslücke zu öffnen, die Angriffe unentdeckt passieren lassen könnte.
Die LoadMaster 360-Plattform bietet eine speziell entwickelte Suite erweiterter WAF-Berichte und Tools. Sie ist darauf ausgelegt, den Prozess der Identifizierung und Behebung von WAF-Fehlalarmen schneller und einfacher zu gestalten.
Zu Beginn des Prozesses zum Tunen von Fehlalarmen werden die WAF-Protokolldaten durch eine Reihe intelligenter Filter vorgefiltert, um so viel Schwerarbeit wie möglich zu automatisieren. Die überwiegende Mehrheit der WAF-Ereignisse wird herausgefiltert, sodass nur die wahrscheinlichsten Fehlalarm-Kandidaten der Aufmerksamkeit eines menschlichen Operators überlassen bleibt.
Betrachten wir folgendes Beispiel:
Die Vorstellung, 1.584 WAF-Ereignisse manuell zu prüfen und zu beurteilen, erscheint unmöglich. Nach der Anwendung der Smart-Filter von LoadMaster 360 wurden jedoch nur noch 13 mögliche Fehlalarme für die menschliche Überprüfung hervorgehoben. 13 ist ein wesentlich handhabbarerer Ausgangspunkt als 1.584 (oder sogar die vollen 83.000+ Ereignisse).
Der LoadMaster 360 WAF vereinfacht die Feinabstimmung, indem er automatisch die richtigen Anweisungen erstellt, sobald ein Fehlalarm erkannt wird. Diese Automatisierung entfernt die Notwendigkeit technischer Vorkenntnisse und macht die WAF-Konfiguration auch für Nicht-Experten zugänglich.
Der automatische Regel-Tuner bietet eine Reihe von Optionen und Funktionen und verdient eine genauere Betrachtung. Um ihn effektiv zu nutzen, ist Einarbeitung notwendig. Häufige Fragen, die dabei auftreten, sind:
Wie wird der Regel-Tuner eingesetzt?
Welche Optionen sind am besten und zugleich am sichersten zu verwenden?
Wann ist es sinnvoll, einen bestimmten „Regelausschluss-Typ“ zu wählen, und was bedeuten diese Typen?
Es wird eine Blog-Serie geben, bei der der Regel-Tuner im Detail behandelt wird: wie man ihn verwendet, welche Optionen es gibt, und Schritt für Schritt durch Beispiele führen.
Verarbeitet Ihr Load Balancer öffentlichen Web-Traffic? Wenn ja, sollten Sie die LoadMaster WAF-Funktionen durchgehen, um Ihre Webanwendungssicherheit zu stärken.
Haben Sie bereits ein LoadMaster Enterprise Plus Abonnement? Dann haben Sie bereits vollen Zugriff auf alle LoadMaster WAF-Funktionen.
Nutzen Sie LoadMaster 360 und haben Sie die erweiterten WAF-Funktionen ausprobiert? Wenn nicht, ist jetzt der perfekte Zeitpunkt, um loszulegen. Folgen Sie den WAF-Tutorials in dieser Blogserie und lernen Sie die erweiterten Funktionen des LoadMaster 360 WAF kennen.
So können Sie die Vorteile einer optimal konfigurierten WAF-Lösung effektiv nutzen.