Wie kann der WAF-Schutz einer Website Fehlblockierungen bösartiger Anfragen reduzieren?

Warnmeldungen in den frühen Morgenstunden stellen Sicherheitsverantwortliche oft vor ein Dilemma: Die Zahl der WAF-Blockierungen steigt deutlich, was zunächst darauf hindeutet, dass Angriffe abgewehrt wurden. Doch kurz darauf meldet das Business-Team, dass Kunden im Ausland keine Anfragen absenden können, Händler sich nicht anmelden können oder die Conversion von Werbe-Landingpages plötzlich sinkt. Das Gefährlichste ist dann nicht nur ein „nicht blockierter Angriff“, sondern auch die Fehlblockierung legitimen Datenverkehrs durch ungenaue Richtlinien.

Der Wert eines Website-WAF-Schutzes liegt darin, Anfragen wie SQL-Injection, Cross-Site-Scripting, bösartige Scans, Exploit-Versuche, auffällige Crawler und DDoS-Angriffe zu erkennen und zu blockieren. Ein WAF ist jedoch seinem Wesen nach eine Sicherheitsschicht, die anhand von Regeln, Signaturen, Verhalten und Risikobewertungen entscheidet. Je komplexer die Website-Funktionen sind und je mehr Formularfelder, URL-Parameter, mehrsprachige Inhalte, Drittanbieter-Callbacks und API-Schnittstellen vorhanden sind, desto eher werden legitime Anfragen bei einer bloßen Erhöhung der Blockierungsintensität als riskant eingestuft.

Für Websites, die der internationalen Kundengewinnung, Werbeschaltung und mehrsprachigen Darstellung dienen, ist eine Fehlblockierung nicht nur eine technische Störung. Sie kann auch bedeuten, dass eine Anfrage, ein Auftrag oder ein erster Markenkontakt unbemerkt abgewiesen wird. Der Schlüssel zur Reduzierung von Fehlblockierungen liegt nicht darin, Regeln einfach „zu lockern“, sondern darin, den Website-WAF-Schutz die Geschäftsgrenzen wirklich verstehen zu lassen.

Zunächst klären: Welche „auffälligen Anfragen“ sind in Wirklichkeit normale Geschäftsvorgänge?

Viele Fehlblockierungen beruhen auf einem Irrtum: Auffällige Anfrageeigenschaften werden unmittelbar mit bösartigen Anfragen gleichgesetzt. Tatsächlich weisen viele normale Szenarien auf grenzüberschreitenden Geschäftswebsites bereits ein hohes „Risikoprofil“ auf. Beispielsweise geben Einkäufer in Anfrageformularen Modellnummern, Chemikalienbezeichnungen oder technische Parameter mit Sonderzeichen ein; Nutzer fügen in Nachrichten Bedarfsbeschreibungen mit Links ein; Kunden im Ausland greifen über VPN, Unternehmens-Proxys oder gemeinsam genutzte Ausgangs-IP-Adressen zu; Weiterleitungsparameter von Werbeplattformen wie Google und Meta sind lang und komplex codiert.

Auch bei B2B-Marketingwebsites übliche Funktionen wie Datei-Uploads, Angebotsdownloads, Rückübertragungen über ERP- oder CRM-Schnittstellen, mehrsprachige Suche und Filterfunktionen innerhalb der Website können allgemeine WAF-Regeln auslösen. Wenn die konkreten Geschäftsabläufe nicht bekannt sind und die Sensitivität nur aus Sicht einer Angriffssignaturdatenbank erhöht wird, kann das Sicherheitssystem echte Kunden als Angreifer behandeln.

Daher sollten Qualitäts- und Sicherheitsverantwortliche bei der Prüfung von Blockierungsprotokollen nicht nur darauf achten, „wie viel blockiert wurde“, sondern auch drei Fragen stellen: Auf welche Ressource hat die Anfrage zugegriffen? Welche Regel wurde ausgelöst? Ging der Anfrage echtes Nutzerverhalten voraus oder folgte darauf, etwa Seitenaufrufe, Formularübermittlungen, Anmeldungen oder Bestellvorgänge? Diese drei Fragen bestimmen, ob anschließend Regeln optimiert, Ausnahmen hinzugefügt oder Blockierungen beibehalten werden sollten.

Von einem einheitlichen Maßstab für die gesamte Website zu einem mehrstufigen Schutz

Um Fehlblockierungen zu reduzieren, ist es meist am effektivsten, nach dem Wert der Assets und dem Geschäftsrisiko zu staffeln, statt für die gesamte Domain dieselben strengen Richtlinien anzuwenden. Hochrisikobereiche wie Verwaltungsoberflächen, Anmeldezugänge, Zahlungsschnittstellen und Verzeichnisse für die Dateiverwaltung sollten ein hohes Schutzniveau beibehalten. Für Präsentationsseiten, Produktdetailseiten und öffentliche Hilfecenter können dagegen Richtlinien eingesetzt werden, die stärker auf Verhaltenserkennung und Zugriffshäufigkeitskontrolle ausgerichtet sind.

Für Pfade wie Formularübermittlungen, die Website-Suche und API-Callbacks, die häufig komplexe Parameter enthalten, können separate Richtliniengruppen eingerichtet werden. Entscheidend ist nicht, die Prüfung vollständig zu deaktivieren, sondern anhand der erwarteten Schnittstellenanforderungen zu validieren: Welche Anfragemethoden, Parameternamen, Inhaltstypen, Dateiformate und Größenbereiche sind zulässig? Anfragen, die nicht dem Schnittstellendesign entsprechen, werden anschließend streng blockiert. Das ist sicherer, als den Schutz vor SQL-Injection oder XSS pauschal zu deaktivieren.

Wenn eine Anfrageschnittstelle Kunden beispielsweise erlaubt, englische, arabische oder russische Texte sowie Texte mit Modellsymbolen einzureichen, bedeutet das nicht, dass sie beliebige Felder, beliebige Längen oder ausführbare Skripte akzeptieren sollte. Durch Parameter-Whitelists, Längenbeschränkungen, Kodierungsvorgaben und eine zweite serverseitige Validierung lassen sich geschäftliche Flexibilität und Sicherheitsgrenzen zugleich erhalten.

Bei der Regeloptimierung auf den „Trefferkontext“ achten, nicht nur auf den Regelnamen

Das Auftreten von „Verdacht auf SQL-Injection“ oder „Verdacht auf XSS“ in WAF-Protokollen bedeutet nicht zwangsläufig, dass die Regel fehlerhaft ist. Sicherheitsverantwortliche müssen den Anfragekontext prüfen, einschließlich IP-Reputation der Quelle, Zugriffsland oder -region, User-Agent, Anfragehäufigkeit, Referer-Quelle, Anfrageparametern, HTTP-Antwortstatuscode sowie der Verhaltenskette vor und nach derselben Sitzung.

Eine Formularanfrage, die von einer Werbe-Landingpage stammt und nach mehreren normalen Seitenaufrufen gesendet wird, hat ein anderes Risikoniveau als eine Anfrage, die in kurzer Zeit Hunderte von URLs durchläuft und fortlaufend Injection-Anweisungen verändert, selbst wenn ähnliche Regeln ausgelöst werden. Ein ausgereifter Website-WAF-Schutz sollte die Risikobewertung umfassend nutzen, statt sich auf das Prinzip „Treffer gleich Sperrung“ einer einzelnen Regel zu verlassen.

Es wird empfohlen, die Regeloptimierung in drei Maßnahmen zu unterteilen:

• Beobachten: Neue oder unsichere Regeln zunächst im Alarm- oder Beobachtungsmodus ausführen, reale Datenverkehrsmuster sammeln und erst dann entscheiden, ob sie blockieren sollen.
• Eingrenzen: Wenn eine Regel nur bei bestimmten Parametern oder URLs Fehlalarme auslöst, sollte ihr Geltungsbereich eingeschränkt werden, anstatt sie für die gesamte Website zu deaktivieren.
• Aufstufen: Bei bestätigten bösartigen Anfragekombinationen Frequenzbegrenzungen, CAPTCHA-Prüfungen, Maßnahmen auf Basis der IP-Reputation oder temporäre Sperren ergänzen, damit nicht wiederholt nur auf einzelne Signaturregeln vertraut wird.

Insbesondere der „Beobachtungsmodus“ eignet sich für Phasen eines Website-Relaunchs, der Hinzufügung mehrsprachiger Seiten, der Anbindung von Marketing-Automatisierungstools oder der Einführung neuer Schnittstellen. Erst den Datenverkehr beobachten und dann Schlussfolgerungen ziehen ist in der Regel souveräner, als nach einem Vorfall unter Zeitdruck zurückrollen zu müssen.

Eine Whitelist ist keine uneingeschränkte Freigabeliste, sondern eine kontrollierte Ausnahme

Whitelists sind ein notwendiges Werkzeug zur Lösung von Fehlblockierungen, werden jedoch auch besonders leicht missbraucht. Zu den häufigen Fehlern gehören das direkte Whitelisten eines gesamten Büro-Netzsegments, die langfristige Freigabe eines Landes oder einer Region oder das Umgehen einer gesamten Kategorie von Sicherheitsregeln zur Lösung eines einzelnen Problems. Diese Maßnahmen wirken zwar schnell, können Angreifern jedoch den Zugang über vertrauenswürdige Pfade ermöglichen.

Ein angemesseneres Whitelist-Management sollte den Grundsätzen „kleinstmöglicher Umfang, klar definierte Laufzeit und nachvollziehbare Überprüfung“ folgen. Ausnahmen sollten bevorzugt für konkrete URLs, Anfragemethoden, Parameterkombinationen oder verifizierte Callback-Signaturen von Drittanbietern eingerichtet werden. Wenn eine Freigabe nach IP erforderlich ist, müssen Zweck, Verantwortlicher und Ablaufzeit dokumentiert und regelmäßig überprüft werden. Für Partnersysteme, Zahlungsplattformen, CRM-Synchronisierungsschnittstellen und ähnliche Dienste sollten möglichst Signaturprüfungen, Token-Validierung oder gegenseitige Authentifizierung eingesetzt werden, statt sich nur auf die Quell-IP zu verlassen.

Auch bei Zugriffen aus dem Ausland sollte Geoblocking vorsichtig eingesetzt werden. Ein hoher Anteil von Angriffen aus bestimmten Regionen bedeutet nicht, dass es dort keine echten Käufer gibt. Für Außenhandelsunternehmen kann eine pauschale Sperrung nach Ländern direkt zum Verlust potenzieller Märkte führen. Die Einschränkung auffälliger Zugriffshäufigkeiten, bekannter bösartiger IPs, gefälschter Crawler und hochriskanter Anfrageketten entspricht dagegen häufig eher den tatsächlichen Geschäftsanforderungen.

Geschäftliche Änderungen in den WAF-Änderungsprozess einbeziehen

Fehlblockierungen treten häufig nach der Einführung neuer Website-Funktionen auf: wenn neue Produktfilter hinzugefügt, Formular-Plugins ersetzt, Zahlungen integriert, URL-Strukturen angepasst, neue Werbekanäle eingesetzt oder auf eine mehrsprachige Website-Architektur migriert wird. Entwicklung, Marketing und Sicherheit erledigen ihre Aufgaben jeweils getrennt, ohne die WAF-Richtlinien abzustimmen. Am Ende werden echte Nutzer zu „Kompatibilitätstestern“.

Es empfiehlt sich, einen schlanken, aber klaren Änderungsprozess einzurichten. Geschäfts- oder Entwicklungsteams beschreiben vor dem Go-live neue Pfade, Parameter und Drittanbieterdienste; Sicherheitsverantwortliche prüfen anhand der Testumgebung oder des schrittweise ausgerollten Datenverkehrs die Regeltreffer; nach dem Go-live werden innerhalb von 24 bis 72 Stunden besonders die 403-Rate, die Erfolgsrate von Formularen, die Anmeldefehlerrate, die API-Fehlerrate und Schwankungen bei der Werbe-Conversion beobachtet. Bei Auffälligkeiten sollte sich schnell feststellen lassen, ob WAF, Anwendung, CDN oder ein Drittanbieterdienst die Ursache ist, statt den Schutz blind zu deaktivieren.

Für Unternehmen, die intelligente Website-Erstellung, mehrsprachige Websites und grenzüberschreitende Onlineshops nutzen, ist dieser Prozess besonders wichtig. Bei Plattformen wie Yiyingbao, die Website-Erstellung, SEO, Werbe-Landingpages und internationale Marketingszenarien abdecken, sollte bei der Projektkonfiguration zugleich auf die Übereinstimmung von Seitenzugriffspfaden und Sicherheitsrichtlinien geachtet werden: Werden Werbeparameter beibehalten? Können Formulare in verschiedenen Sprachen normal übermittelt werden? Erhalten Suchmaschinen-Crawler angemessene Zugriffsrechte? Werden Rückübertragungen von Marketingtools fälschlich als Risiko eingestuft? Sicherheit und Wachstum stehen nicht im Widerspruch, sofern beide auf denselben überprüfbaren Regeln für den Datenverkehr basieren.

Mit einigen Kennzahlen beurteilen, ob ein WAF „präzise blockiert“

Bei der Bewertung der Wirksamkeit eines Website-WAF-Schutzes darf nicht nur die Anzahl blockierter Angriffe betrachtet werden. Eine sehr hohe Blockierungszahl kann vielmehr auf zu weit gefasste Richtlinien hinweisen. Kontinuierlich verfolgt werden sollten insbesondere: der Anteil manuell bestätigter Fehlalarme unter den vom WAF abgewiesenen Anfragen; der Anteil der 403-Antworten bei wichtigen Formularen und Anmeldeschnittstellen; die Anzahl der Whitelist-Einträge und deren langfristiger Bestand; die Wiederholungsrate von Angriffen nach Regelanpassungen; sowie Veränderungen der geschäftlichen Conversion in auffälligen Zeiträumen.

Zudem sollten durchsuchbare Protokolle und Änderungsaufzeichnungen aufbewahrt werden. Wenn bei einer Fehlblockierung keine Regel-ID, kein Anfragemuster, kein Bearbeiter und keine Wiederherstellungszeit dokumentiert wurden, werden bei der nächsten Überarbeitung häufig dieselben Fehler wiederholt. Für Sicherheitsverantwortliche besteht der ideale Zustand nicht darin, „nie einen Alarm auszulösen“, sondern darin, dass jeder Alarm erklärt, jede Ausnahme überprüft und jede Freigabe nachvollzogen werden kann, ohne unbekannte Risiken auszuweiten.

Letztlich wird die Verringerung von Fehlblockierungen durch Website-WAF-Schutz nicht durch niedrigere Sicherheitsanforderungen erreicht, sondern durch eine präzisere Geschäftserkennung, kleinere Geltungsbereiche der Richtlinien sowie kontinuierlichere Überwachung und Nachanalyse. Wenn Schutzregeln mit Änderungen an Website-Funktionen, internationalem Datenverkehr und Marketingprozessen Schritt halten, wird ein WAF zu einem Geländer für den stabilen Geschäftsbetrieb statt zu einer Mauer vor den Kunden.