Kurz gesagt
Eine Web Application Firewall (WAF) prüft jede Anfrage an Ihre Website, bevor sie die Website erreicht, und blockiert typische Angriffsmuster wie SQL-Injection, eingeschleusten Code oder Zugriffe auf Systemdateien. Sie ersetzt keine Updates, schließt aber die Zeit zwischen einer bekannten Lücke und dem Update. Für jede Website mit Login, Formularen oder einem verbreiteten CMS ist sie sinnvoll.
Was eine WAF anders macht als eine normale Firewall
Eine klassische Firewall entscheidet nach Adressen und Ports: Darf diese Verbindung überhaupt zustande kommen? Eine Web Application Firewall schaut in die Anfrage hinein. Sie liest, welche Seite aufgerufen wird, was im Formular steht und welche Parameter mitgeschickt werden, und vergleicht das mit Mustern bekannter Angriffe.
Wogegen sie hilft
- SQL-Injection: Eingaben, die versuchen, Befehle an die Datenbank zu schmuggeln.
- Cross-Site-Scripting: eingeschleuster Code, der später im Browser anderer Besucher läuft.
- Zugriffe auf Systemdateien: Versuche, Konfigurationsdateien oder Passwörter vom Server zu lesen.
- Ausnutzen bekannter Lücken: Angriffe auf veraltete Plugins und Systeme, oft schon wenige Stunden nach Bekanntwerden.
- Scanner: Programme, die Ihre Seite nach Schwachstellen absuchen. Werden sie früh gestoppt, finden sie nichts.
Viele WAFs nutzen dafür das OWASP Core Rule Set, eine frei verfügbare und gepflegte Sammlung von Erkennungsregeln. Dazu kommen Zusatzregeln für verbreitete Systeme wie WordPress, die deren typische Angriffswege kennen.
Wogegen sie nicht hilft
- Gestohlene Passwörter. Wer sich mit echten Zugangsdaten anmeldet, ist für die WAF ein normaler Besucher. Hier hilft Zwei-Faktor-Anmeldung.
- Fehler in der Logik Ihrer Anwendung, etwa ein Shop, der Rabatte doppelt zählt.
- Sehr große Überlastungsangriffe auf Netzebene. Was dagegen realistisch ist, steht in DDoS-Schutz für kleine Firmen.
- Fehlende Updates auf Dauer. Eine WAF verschafft Zeit. Sie macht eine veraltete Website nicht modern.
Das Problem der Fehlalarme
Eine zu strenge WAF blockiert auch echte Besucher, etwa wenn ein Kontaktformular Programmcode enthält, weil jemand eine Frage zu seiner Website stellt. Deshalb braucht jede WAF eine Einlaufphase, in der man beobachtet, was blockiert wird, und die Regeln an die eigene Seite anpasst. Eine WAF, die niemand betreut, wird entweder abgeschaltet oder ist zu lasch.
Wo die WAF sitzen kann
- Als Plugin in der Website, etwa in WordPress. Einfach, aber der Angriff erreicht Ihren Server bereits, bevor er geprüft wird.
- Auf dem eigenen Server vor der Anwendung. Wirksam, braucht aber Zugriff auf den Server und jemanden, der sie pflegt.
- Als vorgelagerter Dienst, der vor Ihrer Website steht. Der Angriff erreicht Ihren Server gar nicht. So arbeitet Shield Web: Ihre Website bleibt bei Ihrem Hoster, nur der DNS-Eintrag zeigt auf den Schutzserver.
Braucht meine Website eine?
Wenn Ihre Website ein Login, Formulare, einen Shop oder ein verbreitetes CMS hat: ja, mit hoher Wahrscheinlichkeit. Eine rein statische Seite ohne Formulare ist ein kleineres Ziel, profitiert aber von der Bot-Abwehr, die bei vorgelagerten Diensten meist dazugehört. Ob Ihre Seite gerade normal antwortet, zeigt unser Website-Check.
Häufige Fragen
- Macht eine WAF meine Website langsamer?
- Die Prüfung einer Anfrage dauert Millisekunden. Weil Angriffe und Bots den Server nicht mehr belasten, wird die Seite für echte Besucher oft sogar schneller.
- Reicht ein Sicherheits-Plugin in WordPress?
- Ein Plugin ist besser als nichts, prüft aber erst, wenn die Anfrage schon auf Ihrem Server angekommen ist und WordPress geladen hat. Ein vorgelagerter Schutz hält Angriffe vorher ab.
- Was ist virtuelles Patchen?
- Eine Regel in der WAF, die eine bekannte Lücke blockiert, bevor das eigentliche Update eingespielt ist. Sie verschafft Zeit, ersetzt aber das Update nicht.