Ein Hoster eines Kunden schrieb mir vor ein paar Tagen, dass die von uns eingesetzte Web Application Firewall „ein Witz“ sei. Wir hingegen installieren bei jeder von uns dauerhaft betreuten WordPress-Website eine solche Web Application Firewall. Es stellt sich also die Frage: „ein Witz“ oder nicht?
Was sind eigentlich Web Application Firewalls?
Firewalls kennen wir aus ganz unterschiedlichen IT-Zusammenhängen. Immer geht es darum, ein internes System vor äußeren Einwirkungen zu schützen. Das kann ganz klassisch eine Firewall sein, die im Unternehmensumfeld das lokale Netzwerk schützt oder auch im persönlichen Umfeld (als Firewall zum Beispiel im DSL-Router oder früher auch als Software-Firewall auf Computern mit Modem-Einwahl). Dabei werden die Zugriffe von außen kontrolliert, ob diese auffällig oder ungewöhnlich sind und ggf. blockiert. Dies geschieht auf Basis eines Regelwerks und definierten Ausnahmen.
Web Application Firewalls (WAFs) unterscheiden sich davon nicht grundlegend. Es handelt sich hierbei um eine spezielle Art der Firewall, die explizit die Web-Anwendung (gemeinhin die Website) auf einem Webserver vor Angriffen von außen schützt. Dazu werden die eingehenden Anfragen geprüft und mit den definierten Regeln verglichen. Ist ein Request verdächtig, wird dieser blockiert. Dabei kann das Regelwerk vielfältig sein. Eine WAF kann Regeln enthalten für unspezifische Angriffe, die allgemein verdächtige Vorgehensweisen enthalten oder aber auch sehr spezielle Regeln, um bekannte Sicherheitslücken (z.B. von WordPress-Plugins) abzufangen. Somit kann eine Firewall eine Website absichern, obwohl diese weiterhin ein Plugin mit Sicherheitslücke nutzt. Gleichzeitig heißt das aber natürlich nicht, dass die Firewall vor jeder Art Angriff schützt. Sind für die Firewall (noch) keine passenden Regeln für einen Angriff definiert und ist der Angriff nicht über allgemeine Regeln erkennbar, schützt die Firewall an dieser Stelle nicht oder zumindest nicht umfassend. Allerdings sind Firewalls in der Lage, allgemeine Angriffsvektoren wie zum Beispiel Cross-Site-Scripting oder SQL-Injections zu erkennen und unabhängig von Sicherheitslücken oder Bekanntheit des Angriffs zu blockieren.
Welche Arten von Web Application Firewalls gibt es?
Web Application Firewalls werden natürlich nicht nur im Umfeld einzelner Websites eingesetzt, sondern auch in großen Strukturen, zum Beispiel bei den Hostern selbst. Diese sichern so Ihre eigenen Netzwerke und die Websites ihrer Kunden ganz generell ab. Dies ist ggf. auch als eigene Hardware-Lösung in den Rechenzentren implementiert. Zudem haben Hoster die Möglichkeit, auf dem Webserver selbst, z.B. mit mod_security oder ähnlichen Komponenten, die Sicherheit durch Filterregeln zu erhöhen.
Als Seitenbetreiber und Server-Nutzer stehen einem zwei verschiedene Arten von Firewalls zur Verfügung:
- Cloud-basierte Firewalls:
Diese werden von Dienstleistern auf einem anderen Server bereitgestellt. Via DNS-Umstellung werden alle Anfragen an die eigene Website zuerst über den Server der Cloud-Firewall umgeleitet. Dort werden die Anfragen von der Firewall geprüft und dann geblockt oder weitergeleitet. Der große Vorteil hier ist, dass der Firewall-Anbieter sehr schnell neue Regeln für die WAF definieren und einspielen kann, die dann sofort bei allen Nutzern der WAF angewendet werden. Wird eine neue Sicherheitslücke bekannt, sind die Firewall-Nutzer so schnellstmöglich geschützt. Auch ist es dem Dienstleister möglich, weitere Zusatzleistungen auf den eigenen Servern zu implementieren wie zum Beispiel DDoS-Schutz oder Bildoptimierung.
Allerdings bedeutet das auch, dass ein Problem beim Firewall-Anbieter zu großen Ausfällen bei vielen verschiedenen Seitenbetreibern führt. Es müssen immer zwei Server fehlerfrei laufen, damit die Website erreichbar ist. - Host-basierte Firewalls:
Lokale Firewalls werden auf dem eigenen Server installiert, zum Beispiel in Form eines WordPress-Plugins. Dieses wird so konfiguriert, dass alle Anfragen, die per PHP verarbeitet werden, zuerst durch die Software-Firewall laufen und dort geprüft werden. Die anzuwendenden Regeln sind auch lokal auf dem Server installiert und müssen entsprechend regelmäßig aktualisiert werden. Für die im WordPress-/PHP-Umfeld genutzten üblichen Firewalls wird meist in der PHP-Konfiguration ein „auto_prepend_file“ definiert, so dass die Firewall auch ganz unabhängig und autark von WordPress selbst funktioniert und jede Anfrage über die Firewall geleitet wird.
Ist denn eine solche Web Application Firewall nun ein Witz?
Offensichtlich sind Web Application Firewalls ganz generell eine sinnvolle Einrichtung. Durch das definierte Regelwerk werden diverse bösartige Anfragen blockiert und Angriffe vereitelt. Web Application Firewalls machen also Sinn.
Aber warum fand der Hoster, dass die Firewall offensichtlich unnütz sei? Je nachdem, welche Sicherheitsvorkehrungen der Hoster selbst bereits in seinem Netzwerk getätigt hat (zum Beispiel eine netzwerk-seitige Firewall, entsprechende Webserver-Konfigurationen mit mod_security o.ä.), sind bereits viele Angriffsvektoren hoster-seitig abgefangen. Das führt dazu, dass die WAF für das WordPress-Umfeld weniger zu tun hat, da viele Angriffe schon vorab abgefangen werden und gar nicht erst auf die Ebene des einzelnen Webservers bzw. die PHP-Ebene durchdringen. Man könnte hier also zu der Einschätzung kommen, dass eine weitere eigene Firewall nicht notwendig sei. Dies stimmt jedoch aus mehreren Gründen nicht:
- die Web Application Firewalls im WordPress-Umfeld enthalten auch wordpress-spezifische Regeln, die sich ganz konkret auf Sicherheitslücken einzelner WordPress-Plugins und deren Ausnutzung beziehen. Möglicherweise sind solche sehr spezifischen Regeln für die hoster-seitigen Firewalls nicht definiert.
- Ganz generell ist in der Regel im Detail unbekannt, welche Sicherheitsvorkehrungen der Hoster einsetzt. Der einzelne Seitenbetreiber kann also gar nicht abschätzen, ob die Sicherheitsmaßnahmen des Hosters bereits ausreichend sind oder nicht.
- Es ist ein Irrglaube, dass die WAFs, die als WordPress-Plugin daherkommen, keine Sicherheitsfunktionen bieten könnten, da sie ja „in WordPress“ laufen. Alle nutzen den o.a. Mechanismus der PHP-Konfiguration und werden somit autark von WordPress im PHP-Umfeld deutlich vor der WordPress-Initialisierung ausgeführt und sind so schon in der Lage, entsprechende Zugriffe zu blocken.
- Ergänzend wird häufig angenommen, dass die PHP-seitige Ausführung einer Web Application Firewall deutliche negative Einflüsse auf die Website-Performance hätte. Dies ist in der Regel nicht so. Natürlich sind netzwerk-seitige Firewalls performanter als PHP-Firewalls, die Auswirkungen sind bei den allermeisten Websites minimal und nicht spürbar.
Wir setzen deswegen bei allen unseren Kunden generell eine Web Application Firewall ein, damit wir ein Mindestmaß an Sicherheit für die Websites garantieren können. Da auch uns in der Regel unbekannt ist, welche Sicherungsmaßnahmen die Hoster ergreifen, wissen wir durch den Einsatz der Web Application Firewall aber, dass zumindest dieser Schutz besteht. Ist der Hoster dagegen gut aufgestellt, wird die PHP-seitige Web Application Firewall, die von uns installiert wurde, wenig Arbeit haben, da die meisten Angriffe schon vorab geblockt wurden. Somit bringt die Firewall in diesem Fall zwar kein besonderes Mehr an Sicherheit, schadet im Umkehrschluss jedoch auch genauso wenig.
Bei unserer Arbeit hat sich in den letzten Jahren eine Web Application Firewall bewährt: NinjaFirewall. Diese ist nicht wordpress-spezifisch, es gibt jedoch ein WordPress-Plugin, welches zur Konfiguration und Übersicht genutzt werden kann.
Fazit
Web Application Firewalls sind ein guter Baustein für die Sicherheit der eigenen Website. Dies kann auch im Rahmen einer Firewall auf PHP-Basis geschehen, insbesondere wenn unbekannt ist, welche Vorkehrungen der Hoster selbst bezüglich Firewalls trifft. „Ein Witz“ sind diese Firewalls jedoch nie, selbst wenn sie, wegen den guten Vorkehrungen des Hosters, nur wenig Arbeit verrichten müssen.
Danke für diesen Artikel, auf den werde ich sicher gerne ab und zu verweisen, wenn mal wieder jemand Argumente gegen eine WAF hat.
Und danke auch, dass du mich erneut daran erinnert hast, mir die Ninja Firewall noch einmal genauer anzusehen 🙂