WAF (Web Application Firewall)

  • Joomla Version
    5.4.7
    PHP Version
    PHP 8.5.x
    Hoster
    fc-hosting

    Sicher auch interessant

    kitepascal hat einen sehr informativen Artikel zum Thema joomla Firewall (Stichwort WAF) geschrieben. Er beschreibt u.a., auf welchen drei Ebenen der Schutz greift:

    • vor dem Server: CDN und Netzwerk
    • auf dem Server: htaccess
    • in Joomla: die echte WAF

    Weiter erfährt man, welcher Schutz zur individuellen joomla-Seite passt und welche Dinge jeder selbst einrichten kann.

    Link: Joomla Firewall: Welche WAF deine Seite wirklich schützt

    Gruß aus dem Emsland
    HoSe

  • Inhaltlich durchaus diskutable Inhalte. Dass eine WAF dann mehr “versteht” wenn sie näher an der Applikation ist, ist für mich nicht nachvollziehbar, denn der gesamte request-Payload ist bereits bei vorgeschalteten Systemen verfügbar, einzig Session und State Infos fehlen dort. Die haben WAFs auf Applikationsebene zwar, dafür haben sie den fatalen Nachteil dass sie erst im verlauf des Aufrufs des Systems aktiv werden und bei frühen Angriffsvektoren nutzlos sind. Zudem schützen sie nur die “offiziellen” Eintrittspunkte ins System.


    Sind WAFs auf App Ebene schlecht? Nein. Sind sie “Echter” oder gar “richtiger”? Nein.

  • Die "echte WAF" ist normalerweise immer vor einer Anwendung. Bei Apache-Webservern üblicherweise Tools wie mod_security, also Teil des Webservers selbst. Eine .htaccess kann dann noch etwas ergänzen auf Script- oder Kunden-spezifischer Ebene - und sei es nur der Passwortschutz des administrator-Verzeichnisses bei Joomla oder der wp-login.php bei Wordpress. Derart mächtige Regeln wie mit mod_security sind damit nicht möglich.

    Wir versuchen bekannte gewordene Angriffsvektoren mit mod_security bereits vorab abzufangen. Das gilt dann global für den ganzen Server und allen Webs.

    Für mich besteht ein Firewall-Konzept aus diesen Teilen:

    1. "Echte" Firewall für ein/ausgehenden Traffik noch vor dem physikalischen Server. In der Regel dann direkt im Rechenzentrum. Ein DDOS-Schutz kann man noch davor platzieren, wenn man das mitrechnen will. Cloudflare ggf. auch noch.
    2. Globale WAF für den Webserver (z.B mod_security)
    3. .htaccess für einige individuelle Regeln und PW-Schutz
    4. Bei Bedarf -nicht zwangsweise erforderlich- eine Schutzfunktion innerhalb eines Scriptes. Hier muss man bedenken, das jede weitere Software in Scripten die Angriffsfläche gleichzeitig erhöht.

    Punkt 4) ist alleine kein Allheilmittel, auch wenn das von verschiedenen Herstellern gerne behauptet wird. Dazu habe ich schon zu viele Hacks gesehen, wo solche Tools installiert waren und versagt haben.

    Wichtiger -meiner Ansicht nach- sind diese Punkte:

    • Keine aufgeblähten Installationen. So wenig Erweiterungen wie möglich. Nur Software aus Quellen, die tatsächlich sehr zeitnah updaten und supporten.
    • Regelmäßige Prüfungen, Updates und Kontrollen.
    • Backups, Backups, Backups...
    • Fachwissen

    Weil ich weiß das diese Punkte eher theoretischer Natur sind, User "jeden Scheiss" installieren und sich oft monatelang nicht um Updates kümmern, geschweige denn regelmäßig mal "nach dem Rechten schauen", oft genug gar keine große Ahnung haben, ist eine Software-Absicherung gemäß Punkt 4), wie z.B. HTProtect aktuell, rsfirewall usw. oder anderen Tools, durchaus oft sinnvoll - aber kein Allheilmittel.

  • Gute Punkte, danke euch - sind eingearbeitet. mod_security steht jetzt als WAF auf Serverebene drin und der POST-Teil ist geradegerückt. SniperSisters "echter oder richtiger? Nein" passte dabei so gut, dass es jetzt praktisch als Fazit im Artikel steht. Hat den Beitrag klar besser gemacht.

    Und letztlich zählt jede zusätzliche Absicherung einer Seite - über welche Schicht auch immer.