Was ist ModSecurity? WAF Grundlagen und 403 Fehler beheben

Was ist ModSecurity und wofür braucht man es?

ModSecurity ist eine quelloffene Engine für eine Web Application Firewall (WAF). Sie hängt sich an Ihren Webserver und prüft jede eingehende HTTP Anfrage anhand von Regeln. Verdächtige Anfragen protokolliert sie also oder stoppt sie mit einem 403, bevor sie Ihre Seite erreichen. Somit kommen typische Angriffe wie SQL Injection Versuche gar nicht erst bei Ihrer Anwendung an.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hosting Anbieter. Alle technischen Aussagen in diesem Ratgeber stützen sich deshalb auf die offizielle Dokumentation. Unser Ziel ist einfach: Wenn Sie eines Tages einen überraschenden 403 Fehler sehen, sollen Sie verstehen, womit Sie es zu tun haben.

Vor allem bei WordPress und Onlineshops steckt ModSecurity oft hinter dem Satz "Die Seite läuft, aber mein Formular speichert nicht". Wir erklären Ihnen das Konzept, die Entscheidungslogik, den Umgang mit Fehlalarmen und den Punkt, an dem Sie das Problem besser an Ihren Hoster abgeben.

Zunächst zur Praxis: Was ist ModSecurity dabei konkret? Ein Besucher ruft eine Seite auf, die Anfrage trifft zuerst Ihren Webserver, und ModSecurity wendet seine Regeln an. Nur wenn die Anfrage durchkommt, erreicht sie Ihre Anwendung, zum Beispiel WordPress. Die WAF ist also ein Tor vor der Anwendung, und die Anwendung selbst erfährt nichts von der Entscheidung.

Was macht eine Web Application Firewall genau?

Eine WAF schaut anders als eine klassische Netzwerk Firewall auf den Inhalt des HTTP Verkehrs. Eine Netzwerk Firewall entscheidet nur, welche IP Adresse sich mit welchem Port verbinden darf. Die WAF liest dagegen Adresse, Parameter, Header und Inhalt der Anfrage und stellt eine Frage: Sieht das nach einem normalen Besucher aus?

Der Unterschied zählt, weil die meisten Angriffe über Port 80 oder 443 kommen, also durch eine völlig legitime Tür. Allerdings schützt es diese Tür nicht, einen Port zu schließen. Die WAF filtert dagegen, was hindurchgeht. Außerdem können Sie mit einem aktualisierten Regelwerk Schutz gegen eine neue Angriffsklasse gewinnen, ohne den Code Ihrer Anwendung anzufassen.

Eine WAF hat drei Grundaufgaben:

• Sie vergleicht Anfragen mit einem Regelwerk und bewertet die Treffer.
• Anfragen über dem Schwellenwert blockiert sie oder protokolliert sie nur.
• Jede Entscheidung schreibt sie in ein Audit Log, damit Sie später nachsehen können.

Trotzdem ist eine WAF kein Zauberschild. Eine Lücke in einem veralteten Plugin schließt sie zum Beispiel nicht. Stattdessen versucht sie lediglich, bekannte Muster zu stoppen, mit denen Angreifer solche Lücken ausnutzen.

Was ist ModSecurity, und wie unterscheidet es sich vom Regelwerk?

Viele Menschen nennen zwei verschiedene Dinge "ModSecurity", und das sorgt für Verwirrung. Erstens ist die Engine die Software, die Regeln liest und auf Anfragen anwendet. Zweitens ist das Regelwerk die Sammlung von Anweisungen, die der Engine sagt, worauf sie achten soll. Das heißt: Ohne Regeln blockiert die Engine allein nichts.

Laut dem offiziellen Referenzhandbuch steuert die Direktive SecRuleEngine, wie sich die Engine verhält, und ihr Standardwert ist aus. Die Installation der Engine schützt Sie daher noch nicht. Stattdessen müssen Sie Regeln laden und die Engine einschalten.

In der Praxis begegnen Ihnen drei Schichten:

• Engine: ModSecurity selbst, ein Modul für Webserver wie Apache.
• Regelwerk: meist das OWASP Core Rule Set (CRS) oder ein kommerzielles Set Ihres Hosters.
• Eigene Regeln: Ausnahmen und Zusatzregeln, die Ihr Anbieter oder Sie ergänzen.

Wenn Sie wissen, in welcher Schicht Sie suchen, lesen Sie die Protokolle daher viel leichter. Ist die Engine zum Beispiel aus, bringt es nichts, das Regelwerk zu verdächtigen. Ist sie dagegen an und ein Regelwerk geladen, sehen Sie im Protokoll eine Regel ID. Fehlt diese, liegt das Problem dann wohl woanders.

Was ist ModSecurity im Vergleich zu Netzwerk Firewall und IP Sperren?

Mehrere Sicherheitswerkzeuge für Server wirken ähnlich, arbeiten aber auf verschiedenen Ebenen. Eine Netzwerk Firewall schaut auf die Verbindung, also auf IP Adresse und Port. Werkzeuge für IP Sperren beobachten wiederholte Fehlversuche in Protokollen und halten die Adresse eine Zeit lang fern. ModSecurity prüft dagegen den Inhalt einer Anfrage, nachdem die Verbindung steht.

Anders gesagt: Diese Schichten ersetzen sich nicht gegenseitig. Eine Netzwerk Firewall mit offenem Port 443 weiß zum Beispiel nichts über den Inhalt einer Anfrage. Die WAF interessiert sich dagegen nur für den HTTP Inhalt, egal über welchen Port er kommt.

Kurz gesagt lassen sich die Schichten so zusammenfassen:

• Netzwerk Firewall: Wer darf an welche Tür klopfen?
• Werkzeuge für IP Sperren: Wer hat zu oft falsche Zugangsdaten probiert?
• WAF: Sieht der Inhalt dieser Anfrage normal aus?

Die Details der anderen Werkzeuge sind deshalb ein eigenes Thema. Dieser Ratgeber bleibt bei ModSecurity.

Was fängt das OWASP Core Rule Set ab?

Das OWASP Core Rule Set ist eine Sammlung allgemeiner Regeln zur Angriffserkennung für ModSecurity und kompatible Engines. Es soll gängige Risikoklassen wie die OWASP Top 10 abdecken, ohne dass Sie eigene Regeln für Ihre Anwendung schreiben.

Konkret schaut das Regelwerk auf Musterfamilien, nicht auf einzelne Signaturen. Es enthält zum Beispiel Regeln für diese Klassen:

• Versuche mit SQL Injection und Befehlseinschleusung.
• Versuche mit Cross Site Scripting (XSS).
• Zugriffe auf fremde Verzeichnisse und das Auslesen lokaler Dateien.
• Fehlerhafte oder gegen das Protokoll verstoßende HTTP Anfragen.
• User Agent Signaturen bekannter Scanner und Angriffswerkzeuge.

Angriffssignaturen schreiben wir hier bewusst nicht aus, denn sie bringen Ihnen nichts. Manche Server Firewalls lehnen sogar Seiten ab, die solche Muster enthalten. Die Namen der Kategorien genügen, um die Entscheidungen zu verstehen. Bedenken Sie außerdem, dass das Regelwerk allgemein gehalten ist. Es kennt das echte Verhalten Ihrer Anwendung nicht und stuft deshalb manchmal eine legitime Anfrage als verdächtig ein.

Wie entscheidet die Anomalie Bewertung über eine Sperre?

CRS blockiert allerdings nicht schon bei der ersten passenden Regel. Jede passende Regel erhöht den Anomalie Wert der Anfrage entsprechend ihrer Schwere. Erreicht die Summe am Ende den Schwellenwert, lehnt die Engine die Anfrage ab. Anders gesagt nennt die CRS Dokumentation dieses Verfahren kollaborative Erkennung.

Die dokumentierten Standardwerte sehen so aus:

• Schwellenwert für eingehende Anfragen (Inbound): 5.
• Schwellenwert für ausgehende Antworten (Outbound): 4.
• Eine CRITICAL Regel addiert 5 Punkte, ERROR 4, WARNING 3 und NOTICE 2.

Ein einziger CRITICAL Treffer überschreitet den Standardschwellenwert also allein. Andererseits können zwei Treffer mit geringerer Schwere ihn zusammen erreichen. Die Dokumentation nennt auch die Reihenfolge. Zunächst laufen die Anfrageregeln mit einer Schwellenprüfung. Danach laufen die Antwortregeln mit einer zweiten Prüfung.

Wenn Sie also einen 403 bekommen, lohnt sich eine Frage: Hat eine einzelne Regel gesperrt, oder haben mehrere kleine Treffer sich summiert?

Warum erhöhen Paranoia Level die Zahl der Fehlalarme?

CRS teilt seine Regeln in vier Paranoia Level (PL) ein, und jedes Level legt weitere Regeln auf das vorherige. Laut offizieller Beschreibung bietet PL 1 einen Basisschutz mit minimalem Aufwand für das Wegtunen von Fehlalarmen. Das zweite Level passt zu Seiten mit echten Nutzerdaten. PL 3 liefert Sicherheit auf Banking Niveau, erzeugt aber viele Fehlalarme. Schließlich ist das vierte Level das strengste.

Die Dokumentation warnt außerdem: Ein hohes Paranoia Level im Blockiermodus ohne Feinabstimmung ist sehr riskant. Für PL 4 kann die Abstimmung laut Dokumentation viele Wochen dauern.

Kurz gesagt steigt mit dem Level der Schutz, aber auch die Zahl der legitimen Anfragen, die hängen bleiben.

Fragen Sie Ihren Anbieter daher bei der Fehlersuche früh, welches Level er nutzt.

Was ist ModSecurity im DetectionOnly Modus, und wie unterscheidet er sich vom Blockiermodus?

Die Direktive SecRuleEngine kennt drei Werte. On verarbeitet Regeln und blockiert. Off verarbeitet gar keine Regeln. DetectionOnly verarbeitet die Regeln, führt aber laut Handbuch keine störende Aktion wie Blockieren, Ablehnen, Verwerfen oder Umleiten aus.

DetectionOnly ist also ein Beobachtungsmodus. Stattdessen landen Treffer im Protokoll, und der Besucher merkt nichts. Wenn Sie ein neues Regelwerk einführen, ist das deshalb der sicherste Start. Sie sehen dann, welche Anfragen hängen bleiben würden, ohne echten Verkehr zu unterbrechen. Wer fragt, was ist ModSecurity, hält diesen Modus oft für "Schutz aus". Tatsächlich laufen die Regeln, allerdings bleibt das Urteil ohne Wirkung.

So können Sie die Modi grob einordnen:

• Neue Einrichtung: Starten Sie mit DetectionOnly und beobachten Sie die Protokolle.
• Abstimmung fertig: Wechseln Sie in den Blockiermodus (On).
• Fehlersuche: Finden Sie zuerst die verantwortliche Regel, statt die Engine abzuschalten.

Eine Beispielzeile aus der Konfiguration sieht so aus:

SecRuleEngine DetectionOnly

Diese Zeile ändern Sie allerdings nur, wenn Sie Ihren eigenen Server verwalten. Bei Shared Hosting liegt diese Entscheidung dagegen bei Ihrem Anbieter.

Was ist ModSecurity bei cPanel Hosting, und warum ist es oft schon aktiv?

Viele Hosting Anbieter binden ModSecurity als Sicherheitsschicht in ihre cPanel Umgebung ein. Laut cPanel Dokumentation können Sie in der Benutzeroberfläche ModSecurity für alle Domains auf einmal ein oder ausschalten oder jede Domain einzeln einstellen. Bevor Sie einzelne Domains konfigurieren, müssen Sie es unter "Configure All Domains" aktivieren.

Die cPanel Dokumentation empfiehlt ausdrücklich, ModSecurity für alle Domains eingeschaltet zu lassen. Ausschalten sollen Sie es also nur, solange Sie ModSecurity bezogene Probleme untersuchen. Sehen Sie die Oberfläche nicht, muss der Anbieter laut Dokumentation das Apache Modul mod_security2 installieren und in WHM die Funktion ModSecurity Domain Manager aktivieren.

Auf der Administratorseite (WHM) gibt es allgemeine Einstellungen wie die Audit Log Stufe und die Regel Engine. Diese gehören dem Anbieter, denn ein normaler Hosting Kunde erreicht diese Ansicht nicht. In der Praxis entscheidet das, wen Sie wofür fragen. Den Schalter pro Domain ändern Sie selbst, eine Ausnahme auf Regelebene bitten Sie dagegen beim Anbieter an.

Was ist ein Fehlalarm (False Positive), und woran erkennen Sie ihn?

Laut CRS Dokumentation ist es ein Fehlalarm, wenn ein legitimer Vorgang irrtümlich eine Regel auslöst. Die Lösung besteht nicht darin, die Regel zu löschen. Stattdessen schreiben Sie eine Regelausnahme für genau diesen Fall.

Einen Fehlalarm erkennen Sie an diesen Anzeichen:

• Beim Absenden eines bestimmten Formulars erscheint ein 403 Forbidden Fehler.
• Dieselbe Seite funktioniert in einem anderen Browser oder mit anderem Inhalt.
• Beim Speichern einer Einstellung im Adminbereich erscheint eine leere Seite oder ein Fehler.
• Das Problem tritt nur bei einer Aktion auf, etwa beim Speichern einer langen Produktbeschreibung.

Beachten Sie allerdings, dass ein 403 nicht nur von ModSecurity kommt. Auch Dateirechte, .htaccess Regeln oder ein anderes Sicherheits Plugin können ihn erzeugen. Deshalb sollten Sie zunächst die Quelle des Fehlers bestätigen.

Zudem hilft ein einfacher Vortest. Probieren Sie dieselbe Aktion aus einem anderen Netz, etwa mit den mobilen Daten Ihres Smartphones. Ändert sich nichts, liegt das Problem dann sehr wahrscheinlich auf der Serverseite und nicht in Ihrem eigenen Netz.

Wie lesen Sie einen Fehlalarm im Protokoll?

Vor allem ist das Protokoll der einzige verlässliche Weg zur Lösung. Laut offizieller Referenz zeichnet die Engine bei SecAuditEngine mit dem Wert RelevantOnly nur Vorgänge auf, die eine Warnung oder einen Fehler ausgelöst haben oder als relevant gelten. Der Standardwert ist allerdings aus. Welche Teile ein Eintrag enthält, bestimmt SecAuditLogParts, und der Standard lautet ABCFHZ.

Diese Angaben suchen Sie im Eintrag:

1. Kennung der Regel, die ausgelöst hat.
2. Meldung und Tags der Regel.
3. Teil der Anfrage, der den Treffer ausgelöst hat, zum Beispiel ein Parameter oder ein Header.
4. Zeit und Adresse der Anfrage.

Die Regel ID ist der einzige Schlüssel, den Sie für eine Ausnahme brauchen. Ohne sie wird es zudem schwer, Hilfe von Ihrem Hoster zu bekommen. Geben Sie daher im Support Ticket immer Zeitstempel und Adresse an.

Wo die Protokolldatei liegt, hängt vom Anbieter ab. Bei Shared Hosting haben Sie zum Beispiel womöglich keinen Zugriff auf die Datei. Bitten Sie in diesem Fall Ihren Anbieter um die passende Protokollzeile.

Kann ein Audit Log personenbezogene Daten enthalten, und wie schützen Sie es?

Ja, das kann es. Laut den Teilebuchstaben im offiziellen Handbuch kann ein Eintrag Request Header und den Request Body enthalten. Im Body stehen unter Umständen Namen, E-Mail Adressen und ähnliche Felder aus einem Formular. Der Eintrag, den Sie bei der Fehlersuche öffnen, kann also Daten Ihrer Besucher zeigen.

Deshalb empfehlen wir diese Gewohnheiten:

• Teilen Sie Einträge nur mit den Personen, die das Problem lösen.
• Schwärzen Sie personenbezogene Felder, bevor Sie eine Zeile ins Ticket kopieren.
• Fragen Sie Ihren Anbieter, wie lange er die Einträge aufbewahrt.
• Protokollieren Sie nicht ohne Grund jeden Vorgang. Auch die cPanel Dokumentation warnt davor, alle Transaktionen aufzuzeichnen.

Haben Sie Pflichten beim Datenschutz, klären Sie das Thema zusätzlich mit Ihrer Rechtsberatung. Allerdings geben wir hier keine Rechtsauskunft. Stattdessen erinnern wir nur daran, dass ein Eintrag solche Daten tragen kann.

Wie schreiben Sie eine Regelausnahme?

Es gibt zwei Wege für eine Ausnahme. Die CRS Dokumentation unterscheidet Ausnahmen zur Konfigurationszeit und zur Laufzeit. Erstens entfernt SecRuleRemoveById zur Konfigurationszeit eine Regel von Anfang an. Zweitens gilt ctl:ruleRemoveById zur Laufzeit nur für eine bestimmte Anfrage.

Laut offiziellem Handbuch muss die Direktive SecRuleRemoveById nach der Regel stehen, die sie abschaltet. Ausnahmen zur Laufzeit funktionieren dagegen umgekehrt und müssen vor dem Laden von CRS stehen, weil eine Änderung an einer bereits gelaufenen Regel keine Wirkung hat. Außerdem unterstützt die Aktion ctl keine regulären Ausdrücke.

Das folgende Beispiel dient also nur der Veranschaulichung. Die Nummer 920230 ist eine Regel ID, die die CRS Dokumentation als Beispiel nennt. Die Nummer in Ihrem eigenen Protokoll sieht allerdings anders aus.

SecRule REQUEST_URI "@beginsWith /beispiel-formular/" "id:1000001,phase:1,pass,nolog,ctl:ruleRemoveById=920230"

Diese Ausnahme schaltet eine einzige Regel nur auf der Adresse /beispiel-formular/ ab. Das ist somit deutlich sicherer, als das ganze Regelwerk zu deaktivieren.

Warum ist es keine gute Idee, ModSecurity ganz abzuschalten?

Es wirkt wie eine schnelle Lösung, kostet aber viel. Sobald Sie es abschalten, bleibt jede Anfrage an Ihre Seite also ungeprüft. Schlimmer noch: Sie erfahren die wahre Ursache nie, und das Problem kehrt beim nächsten Mal an anderer Stelle zurück.

Wir empfehlen stattdessen diese Reihenfolge:

1. Erzeugen Sie den 403 erneut und notieren Sie die Uhrzeit.
2. Suchen Sie im Protokoll die Kennung der auslösenden Regel.
3. Bitten Sie um eine enge Ausnahme für diese Adresse oder diesen Parameter, oder schreiben Sie sie selbst.
4. Wiederholen Sie nach der Ausnahme die Aktion und prüfen Sie den Eintrag.

Die cPanel Dokumentation weist in dieselbe Richtung. Schalten Sie ModSecurity also nur während der Fehlersuche ab. Haben Sie es abgeschaltet, schalten Sie es danach sofort wieder ein.

Sinnvoll ist das Abschalten nur als kurzer Test, ob ModSecurity das Problem wirklich verursacht. Danach muss der Schutz zurückkehren. Legen Sie die Dauer des Tests vorher fest und ändern Sie währenddessen nichts anderes. Sonst wissen Sie nicht, was das Problem gelöst hat.

Warum liefert WordPress 403 Fehler?

WordPress sendet Anfragen, die ModSecurity gut kennt, und trotzdem bleiben sie oft hängen. Der Adminbereich, Plugins und Page Builder schicken viele detaillierte Anfragen. Manche davon tragen lange Parameter oder formatierte Inhalte.

Ein Inhalt, den Sie mit einem Page Builder speichern, sendet zum Beispiel Layoutdaten und HTML Fragmente in einer einzigen Anfrage. Daher kann das Regelwerk diesen Body als verdächtig einstufen. Auch die Hintergrundanfragen des Adminbereichs, etwa admin-ajax, gehören zu den Adressen, die häufig hängen bleiben.

Diese Situationen bleiben besonders oft hängen:

• Eine Produktbeschreibung mit langem Inhalt oder HTML speichern.
• Mehrfeldige Formulare auf Einstellungsseiten von Plugins absenden.
• Große Dateien hochladen, während Sie ein Theme oder Plugin installieren.
• Sonderzeichen in ein Suchfeld tippen.

Die Lösung bleibt also gleich: Finden Sie die Regel ID und bitten Sie um eine enge Ausnahme. Unser Ratgeber zu WordPress oder individueller Website zeigt außerdem, warum Plugin Abhängigkeit den Wartungsaufwand erhöht.

Warum bleiben Zahlungsrückmeldungen und Benachrichtigungen im Onlineshop hängen?

Der teuerste Fehlalarm im E-Commerce ist eine blockierte Benachrichtigung Ihres Zahlungsanbieters, etwa ein Webhook oder eine Rücksprungadresse. Der Kunde zahlt, aber die Bestellung bleibt dennoch auf "unbezahlt".

Solche Anfragen stammen nicht aus einem Browser mit Mensch davor. Stattdessen kommen sie von einem anderen Server, oft mit ungewöhnlichen Headern und signiertem Inhalt. Stuft das Regelwerk sie als automatisierten Werkzeugverkehr ein, liefert es womöglich einen 403.

Die Anzeichen sehen so aus:

• Bestellungen bleiben trotz erfolgter Zahlung auf "in Bearbeitung".
• Im Dashboard Ihres Zahlungsanbieters steht ein Fehler bei der Benachrichtigung.
• Ausfälle treten nur auf der Adresse nach der Zahlung auf.

Die Lösung ist also eine enge Ausnahme per Regel ID für genau diese Benachrichtigungsadresse. Die ganze Seite ungeschützt zu lassen, ist allerdings keine Lösung. Prüfen Sie die Adresse außerdem immer anhand der Dokumentation Ihres Zahlungsanbieters. Zum Zusammenhang von Ladezeit und Umsatz lesen Sie unseren Beitrag Ladezeit im Onlineshop: Beeinflusst sie den Umsatz?.

Was tun Sie, wenn ein Formular einen 403 liefert? Ein Beispielfall

Das folgende Szenario ist ein reines Beispiel und kein echter Kundenfall. Angenommen, Sie senden Ihr Kontaktformular ab, und es erscheint eine Seite "403 Forbidden", während der Rest der Seite einwandfrei läuft.

Probieren Sie zunächst das Formular mit einer kurzen Nachricht. Geht der kurze Text durch und der lange bleibt hängen, löst womöglich der Inhalt selbst die Regel aus. Senden Sie danach dasselbe Formular aus einem anderen Netz. Ändert sich nichts, liegt das Problem somit nicht in Ihrem Netz.

Dann gehen Sie in dieser Reihenfolge vor:

1. Notieren Sie die Uhrzeit des Fehlers so genau wie möglich.
2. Schreiben Sie auf, welche Adresse und welche Methode im Spiel war.
3. Kommen Sie an das Protokoll, suchen Sie die Regel ID; sonst fragen Sie Ihren Anbieter.
4. Fordern Sie eine enge Ausnahme an und probieren Sie das Formular erneut.
5. Prüfen Sie, ob andere Seiten unberührt blieben.

In der Praxis führt diese Reihenfolge schneller und sicherer zum Ziel als eine breite Bitte wie "Schalten Sie ModSecurity ab".

Welche Angaben schicken Sie Ihrem Hoster?

Ein gut vorbereitetes Support Ticket verkürzt deshalb Tage auf Minuten. Die Arbeit des Anbieters wird leichter, weil er den passenden Eintrag direkt findet.

Ergänzen Sie in Ihrem Ticket Folgendes:

• Die vollständige Adresse (URL) des Fehlers und die Methode, also Seitenaufruf oder Formularversand.
• Datum und Uhrzeit des Fehlers, samt Zeitzone.
• Ihre eigene IP Adresse; sie finden Sie mit unserem IP Abfrage Werkzeug.
• Einen Screenshot und den vollständigen Text der Fehlermeldung.
• Das Datum, ab dem das Problem besteht, und was Sie davor geändert haben.

Schreiben Sie außerdem: "Ich möchte wissen, welche ModSecurity Regel diese Anfrage ausgelöst hat und ob Sie für diese Adresse eine enge Ausnahme einrichten können." So merkt der Anbieter, dass Sie eine passende Einstellung erwarten und keine Abschaltung. Auch die schriftliche Form hilft, denn später können Sie nachlesen, was sich geändert hat.

Wer verwaltet ModSecurity bei Shared Hosting, VPS und Managed Angeboten?

Die Verantwortung hängt von der Hosting Art ab. Die Tabelle zeigt den allgemeinen Trend. Welche Lage im Detail gilt, richtet sich allerdings nach den Bedingungen Ihres Anbieters.

Diese Frage lohnt sich daher schon bei der Auswahl. Wir behandeln das Thema in unserem Ratgeber Webhosting auswählen: Server Kriterien. Dort sehen Sie zum Beispiel, dass WAF Unterstützung ein Vergleichskriterium ist.

Die allgemeine Regel lautet: Statt an einer Schicht zu basteln, die Ihnen nicht gehört, wenden Sie sich mit klaren Angaben an den Anbieter. Bei einem VPS ohne Panel liegt die ganze Arbeit allerdings bei Ihnen. Machen Sie dann vor jeder Änderung ein Backup und testen Sie zuerst.

Wie richten Sie ModSecurity auf Ihrem eigenen VPS sicher ein?

Verwalten Sie Ihren VPS selbst, ist die Reihenfolge somit klar. Einzelne Befehle nennen wir hier nicht, denn Paketnamen und Dateipfade unterscheiden sich je nach Distribution. Prüfen Sie Befehle daher immer in der offiziellen Dokumentation Ihrer Distribution und auf der CRS Installationsseite.

Die sichere Reihenfolge lautet:

1. Installieren Sie die ModSecurity Engine aus dem offiziellen Paket Ihrer Distribution.
2. Beziehen Sie das CRS Regelwerk aus der offiziellen Quelle und binden Sie es laut Dokumentation ein.
3. Lassen Sie SecRuleEngine zunächst auf DetectionOnly.
4. Schalten Sie das Audit Log ein und beobachten Sie echten Verkehr.
5. Schreiben Sie enge Ausnahmen für die gefundenen Fehlalarme.
6. Beruhigen sich die Protokolle, wechseln Sie in den Blockiermodus und beobachten Sie weiter.

Wer diese Reihenfolge überspringt und gleich im Blockiermodus startet, riskiert daher, dass Kunden schon in der ersten Stunde einen 403 sehen. Außerdem hilft es, die Änderung zuerst an einer kleinen Kopie zu probieren. Prüfen Sie vor jeder Änderung auch Ihre Backup Strategie.

Reicht eine WAF allein, und wie hängt sie mit den OWASP Top 10 zusammen?

Nein, sie reicht nicht. Eine WAF ist eine Verteidigungsschicht und ersetzt nicht die Sicherheit der Anwendung selbst. Eine sicher geschriebene Anwendung widersteht Schwachstellen also auch ohne WAF besser.

Die Risiken in unserem Ratgeber zu den OWASP Top 10 wurzeln meist im Code und in der Konfiguration. Eine WAF erschwert das Ausnutzen dieser Risiken, sie repariert die Ursache allerdings nicht.

Stellen Sie sich Ihre Sicherheitsschichten so vor:

• Aktuelle Software, Plugins und Themes.
• Starke Passwörter und Zwei Faktor Anmeldung.
• Ein richtig eingerichtetes SSL Zertifikat mit HTTPS.
• Regelmäßige Backups.
• ModSecurity als WAF.

Jede dieser Schichten wirkt gegen ein anderes Risiko. Mehr von einer Schicht gleicht deshalb nie das Fehlen einer anderen aus. Eine sehr strenge WAF kann zum Beispiel die Lücke in einem veralteten Plugin nicht vollständig schließen.

Beeinflusst ModSecurity Ladezeit und SEO?

Jede Anfrage mit Regeln zu vergleichen, bedeutet Rechenlast. Wie groß der Effekt ausfällt, hängt vom Regelwerk, vom Paranoia Level und von den Serverressourcen ab. Eine allgemeingültige Zahl haben wir daher nicht, und Zahlen ohne Quelle nennen wir nicht. Vermuten Sie eine spürbare Verlangsamung, messen Sie zunächst.

Das eigentliche SEO Risiko liegt allerdings woanders. Besucht ein Suchmaschinen Bot eine legitime Seite und bekommt einen 403, kann er diese Seite somit nicht crawlen. Fehlalarme betreffen also nicht nur Formulare, sondern auch die Crawlbarkeit.

Diese Vorkehrungen können Sie treffen:

• Prüfen Sie, ob Ihre wichtigen Seiten von einem anderen Gerät und aus einem anderen Netz öffnen.
• Testen Sie kritische Seiten nach einem neuen Plugin oder einer Regeländerung erneut.
• Behalten Sie Ihre Crawl Vorgaben mit einem robots.txt Generator im Griff.

Für das große Bild zur Performance ist unser Beitrag Wie beeinflusst die Ladezeit das SEO? ein guter Einstieg.

Wann überlassen Sie es besser Ihrem Anbieter, statt es selbst zu tun?

Die ehrliche Antwort lautet: Die meisten Website Betreiber sollten ModSecurity nie anfassen. Wichtig ist vor allem, das Problem gut zu beschreiben und an die richtige Person zu geben. Konkret nennt eine gute Beschreibung, wann, wo und bei welcher Aktion der Fehler auftrat.

In diesen Fällen überlassen Sie die Arbeit Ihrem Anbieter:

• Sie nutzen Shared Hosting und erreichen die Regeldateien nicht.
• Im Protokoll taucht keine Regel ID auf.
• Ihre Änderung würde den Zahlungsablauf eines Live Shops berühren.
• Es gibt kein Backup, oder der Weg zurück ist unklar.
• Serververwaltung ist für Sie Neuland.

Dagegen können Sie selbst weitermachen, wenn Sie Ihren VPS verwalten, eine Testumgebung haben und die Protokolle lesen können. Auch dann ändern Sie besser in kleinen Schritten.

Möchten Sie Sicherheit, Geschwindigkeit und Infrastruktur gemeinsam durchdenken, behandelt auch unser Webdesign Angebot diese Themen. Für Domain und DNS hilft Ihnen zudem die DNS Abfrage.

Was sind Ihre nächsten Schritte, nachdem Sie wissen, was ModSecurity ist?

Zusammengefasst: Was ist ModSecurity? Ein Filter vor Ihrer Seite, der Anfragen bewertet. Gut eingestellt arbeitet es dann unauffällig. Taucht ein Fehlalarm auf, lösen Sie ihn stattdessen durch Feinabstimmung und nicht durch Abschalten.

Ihre praktische Checkliste:

1. Bestätigen Sie, dass ModSecurity das Problem wirklich verursacht.
2. Finden Sie im Protokoll die Regel ID und die Uhrzeit.
3. Fordern Sie eine enge Ausnahme an oder schreiben Sie sie selbst.
4. Testen Sie das Ergebnis erneut.
5. Notieren Sie die Änderung und prüfen Sie wichtige Seiten noch einmal.

Ihre Sichtbarkeit und Ihre Conversions sind unser Geschäft. Wie technische Infrastruktur die Suchergebnisse beeinflusst, besprechen wir gern mit Ihnen; schauen Sie dazu auf unsere Seiten zur SEO Beratung und zur E-Commerce Beratung.

Quellen: CRS Anomaly Scoring, CRS Paranoia Levels, CRS False Positives und Tuning, ModSecurity Konfigurationsdirektiven, cPanel ModSecurity Dokumentation, WHM ModSecurity Einstellungen.