Was ist eine WAF, und braucht Ihre Website wirklich eine?
Eine Web Application Firewall klingt wie Enterprise Overkill bis zum Tag, an dem sie still den Angriff blockiert, der Ihre Woche ruiniert hätte. Was eine WAF tut, was sie nicht tun kann und wer tatsächlich einen braucht.
Eine WAF oder eine Web Application Firewall prüft den Inhalt eingehender HTTP-Anfragen und blockiert die entsprechenden bekannten Angriffsmuster – SQL-Injektion, Cross-Site-Scripting, Pfad-Traversal – bevor sie Ihre Anwendung. Am Rand laufen, es stoppt bösartigen Verkehr, bevor es kostet Sie alles. Es ist kein Ersatz für das Schreiben von sicheren Code; es ist eine Ebene vor ihm.
Die meisten Leute treffen eine WAF, wie sie ihre Hausversicherung treffen: nachdem etwas bereits schief gelaufen ist, und in der Regel wünschen sie, sie hätten es früher eingerichtet. Es ist kein glamouröses Merkmal. Es ist der Türsteher an der Tür, überprüft jede Anfrage und wendet die, die etwas scharfes tragen weg.
Was eine WAF von einer normalen Firewall trennt
Eine Netzwerk-Firewall denkt in Ports und IP-Adressen: erlauben 443, blockieren Sie das Subnetz, fertig. Es hat keine Ahnung, was im Inneren des Verkehrs ist, den es erlaubt, und es kann nicht - alles, was auf Port 443 ankommen, sieht identisch aus, wo es steht.
Eine Web-Anwendung Firewall arbeitet eine Ebene bis, bei HTTP. Es liest die URL, die Abfrage Zeichenkette, die Header, die Cookies und die Anfrage Körper, und sucht nach den Mustern Angreifer verwenden. Zu einer Netzwerk Firewall, GET /products?id=5 und GET /products?id=5' OR '1'='1 sind die gleiche Anfrage an den gleichen Hafen. Für eine WAF sind sie sehr offensichtlich nicht.
Was ein WAF mit einer Anfrage macht
Drei mögliche Urteile, und das dritte ist das, was eine WAF nutzbar macht, anstatt zu ärgern.
Erlauben
Nichts stimmte überein. Die Anfrage geht wie gewohnt an Ihre Anwendung weiter, ohne messbare Verzögerung.
Blockieren
Passend zu einem bekannten Angriffsmuster, oder kam von einer verbotenen Adresse. Abgelehnt mit einem 403, bevor Ihre Anwendung jemals beteiligt ist.
Herausforderung
Verdächtig, aber nicht schlüssig schlecht. Der Client wird gebeten, zu beweisen, dass es ein echter Browser ist — ein Proof-of-Work-Puzzle oder ähnliche — und weiter, wenn es passiert. Dies ist, wie Sie Verkehr Sie nicht sicher sind, ohne echte Kunden zu blockieren.
Regelordnung entscheidet über alles
Ein WAF bewertet Regeln nach Priorität, und das erste Spiel gewinnt. Das ist kraftvoll und sehr leicht nach hinten zu kommen. Eine erlaubte Regel, die über Ihren Blockregeln sitzt, wird glücklich durch den genauen Verkehr winken, den Sie die Blockregeln geschrieben haben, um zu stoppen, und die WAF wird berichten, dass sie die ganze Zeit perfekt funktioniert.
Wenn Ihr WAF "nicht blockiert", überprüfen Regel-Ordnung vor allem anderen. Eine breite Allow-Regel über Ihren Block Regeln ist weit und weit weg der häufigste Grund, ein Angriff durch eine Firewall, die technisch eingeschaltet wird.
Der Teil, den niemand erwähnt: falsche Positive
Eine WAF, die noch nie eine legitime Anfrage blockiert hat, ist eine WAF mit zu weit abgeneigten Regeln. Die Spannung ist inhärent – Sie stimmen mit dem Text überein, und wirklicher Text sieht manchmal wie ein Angriff aus.
Die klassischen Beispiele sind es wert, im Voraus zu wissen, weil sie Ihnen passieren werden. Ein CMS, in dem ein Editor einen Artikel über SQL-Injection schreibt und speichert, reiht die SQL-Injection-Regel ab. Eine Form, in der der Nachname eines Menschen eine Apostrophe enthält. Ein Entwickler, der eine Stack-Trace in ein Support-Ticket einfügt. Eine Marketing URL mit einem ungewöhnlichen kodierten Parameter.
Deshalb sollte jeder WAF-Einsatz auf die gleiche Weise beginnen: führen Sie es zuerst im Überwachungsmodus aus. Loggen Sie, was es blockiert hätte, lassen Sie es für ein oder zwei Wochen von echtem Verkehr, dann lesen Sie das Protokoll. Sie finden zwei oder drei Regeln, die eine Ausnahme für Ihre spezifische Anwendung benötigen, und Sie finden sie, ohne dass sie verbracht haben, dass vierzehn Tage ablehnende Kunden.
Rand-WAF oder Ursprung WAF
| Bei Ihrer Herkunft | Am Rand | |
|---|---|---|
| Wo Angriffe aufhören | Nach Erreichen Ihres Servers | Bevor Sie Ihren Server erreichen |
| Last aus schlechtem Verkehr | Du zahlst für alles. | Kommt nie an |
| Verhalten während einer Flut | Kann überwältigt werden | Über das gesamte Netzwerk hinweg absorbiert |
| Siehe entschlüsselte Anfrage Stelle | Nein | Ja — TLS endet am Rand |
| Gilt für alle Ihre Websites auf einmal | Pro Server | Pro Zone, zentral |
Ein Ursprung WAF hat bereits Bandbreite und CPU verloren, bis es entscheidet, etwas abzulehnen. Während eines schweren automatisierten Angriffs, der der Unterschied zwischen einer gefilterten Logline und einem Server ist, der nicht mehr reagiert.
Was eine WAF nicht für Sie tun wird
Es lohnt sich, stumpf zu sein, denn WAFs werden als Sicherheitsstrategie verkauft und sie sind nicht eine.
- Es repariert nicht den verwundbaren Code. Es macht die Ausbeutung schwieriger, Sie Zeit zum Patchen zu kaufen. Die Verwundbarkeit ist immer noch vorhanden.
- Es verhindert nicht, dass Logikfehler auftreten. Wenn Ihr Checkout eine negative Menge akzeptiert, ist jede Anfrage, die dies tut, perfekt gut ausgebildetes HTTP.
- Es hört nicht auf, sich selbst mit der Beglaubigung zu stopfen. Ein Login-Versuch mit einem echten gestohlenen Passwort sieht genau wie ein legitimes Login aus. Das ist rate limiting und MFA-Gebiet.
- Es ersetzt das Patching nicht. Ein virtueller Patch am Rand ist ein nützlicher Stopgap für die Tage zwischen Offenlegung und Ihrem Einsatz – keine dauerhafte Antwort.
Brauchst du einen?
Wenn Ihre Website ist eine statische Broschüre ohne Formulare, keine Logins und nichts zu stehlen, können Sie vernünftig warten. Sobald Sie Benutzereingaben akzeptieren, einen Login ausführen, Zahlungen entgegennehmen oder alles speichern, was Sie hassen würden, ist eine WAF nicht mehr optional. Die Angriffe, die es blockiert sind automatisiert und konstant — Scanner sind Ihre Website im Moment für die WordPress-Schwachstellen von 2023, ob Sie WordPress laufen oder nicht.
Häufig gestellte Fragen
Was ist ein WAF?
Eine WAF oder Web Application Firewall ist eine Sicherheitsschicht, die den Inhalt eingehender HTTP-Anfragen – URLs, Header, Cookies und Körperdaten – inspiziert und die entsprechenden bekannten Angriffsmuster wie SQL-Injection blockiert. Cross-Site-Skripting und Pfad-Traversal. Im Gegensatz zu einer Netzwerk-Firewall, die nur Ports und IP-Adressen sieht, versteht eine WAF die Anwendungsebene.
Was ist der Unterschied zwischen einer WAF und einer Firewall?
Eine Netzwerk-Firewall filtert den Datenverkehr nach Port, Protokoll und IP-Adresse und kann nicht sehen, was sich in den Anfragen befindet, die sie durchlässt. Eine Web Application Firewall arbeitet an der HTTP-Schicht und prüft den tatsächlichen Inhalt jeder Anforderung. Eine Netzwerk-Firewall sieht zwei Anfragen zum Port 443 als identisch, selbst wenn man eine SQL-Injektions-Payload enthält; eine WAF nicht.
Verlangt ein WAF meine Website?
Kaum. Regelbewertung auf einem modernen Rand WAF fügt in der Regel unter einer Millisekunde pro Anfrage, die nicht wahrnehmbar neben Netzwerk Latenz ist. Ein WAF-Lauf am CDN-Edge verbessert in der Regel die Gesamtleistung in der Praxis, da bösartiger und automatisierter Verkehr abgelehnt wird, bevor er jede Ursprungskapazität verbraucht.
Kann ein WAF legitime Besucher blockieren?
Ja, und das wird es, wenn es sorglos eingesetzt wird. Falsche Positive beinhalten in der Regel Inhalte, die der Angriffssyntax ähneln — ein Artikel über SQL-Injektion, ein Nachname, der eine Apostrophe, eine pasted Stack-Trace enthält. Die Standardminderung besteht darin, die WAF zunächst für ein oder zwei Wochen im Überwachungsmodus zu betreiben, zu überprüfen, was sie blockiert hätte, und vor der Durchsetzung Ausnahmen hinzuzufügen.
Brauche ich noch einen sicheren Code, wenn ich eine WAF habe?
Auf jeden Fall. Ein WAF ist ein Filter vor Ihrer Anwendung, kein Fix für das, was darin ist. Es macht bekannt, Schwachstellen Klassen schwerer zu nutzen und kauft Zeit zwischen einer Offenlegung und Ihrem Patch, aber der zugrunde liegende Fehler bleibt durch jede Anforderung die Regeln nicht übereinstimmen ausnutzt. Betrachten Sie es als Verteidigung in der Tiefe, nie als Ersatz.
Braucht eine kleine Website eine WAF?
Wenn es irgendwelche Benutzereingaben akzeptiert — ein Login, ein Kontaktformular, ein Suchfeld, ein Kommentarfeld — dann ja. Angriffe auf kleine Websites sind fast vollständig automatisiert und untargeted: Scanner fegen das gesamte Internet auf bekannte Schwachstellen und egal, wie viel Verkehr Sie bekommen. Eine rein statische Seite ohne Formen und ohne Admin-Panel ist der einzige Fall, wo es vernünftigerweise warten kann.
Ein WAF liest eingehende Anfragen und blockiert die bösartigen, bevor sie Ihre Anwendung erreichen. Stellen Sie es an den Rand so schlechten Verkehr nie kostet Sie, starten Sie im Überwachungsmodus, so dass Sie Ihre falschen Positive sicher finden, denken Sie an Ihre Regelordnung, so dass Regeln nicht unterlaufen Block-Regeln - und halten Patching, weil eine WAF kauft Zeit statt Immunität.
Sehen Sie, wie NordicCDN dies für Ihre Website tut:
Mads hat seit seinem 16. Lebensjahr in der IT gearbeitet — hauptsächlich als Hosting. Er beteiligte sich früh an einer SaaS-Firma und half, sie bis zur Übernahme durch Visma weiterzuentwickeln, hat Data-Center-Netzwerke aufgebaut und betrieben und diente als CTO eines dänischen Rechenzentrums. Er hat NordicCDN gestartet, um eine schnelle, sichere Infrastruktur einfach zu bedienen.
