Ein verbotener 403-Fehler tritt am häufigsten auf, wenn unsere Sicherheitssysteme Ihre Website schützen. In den meisten Fällen schützt unsere Webanwendungs-Firewall (genannt Mod Security oder modsec) Ihre Website vor automatisierten Hacking-Versuchen.
In einigen Fällen können legitime Aktionen jedoch fälschlicherweise als Angriff identifiziert werden und Ihre Aktion wird blockiert. Dies wird als falsch positiv bezeichnet. Hier sind einige gängige Szenarien, wenn dies passiert:
- Wenn Sie einen Website-Builder verwenden, werden Ihre Änderungen möglicherweise nicht gespeichert
- Wenn Sie das Divi-Theme/Builder für WordPress verwenden, wird es so etwas wie „Fehler beim Speichern der Seite“ anzeigen und dann eine Liste möglicher Ursachen bereitstellen.
- Beim Hinzufügen von Javascript- oder PHP-Code über das Admin-Panel Ihrer Website (und nicht über den Plesk File Manager oder FTP).
Wenn Sie einen verbotenen 403-Fehler erhalten, der nicht mit einer der oben genannten Aktionen übereinstimmt, sollten Sie zuerst unseren allgemeinen Leitfaden zur Fehlerbehebung bei 403-Fehlern lesen.
Das kann scheinbar aus heiterem Himmel passieren weil unsere Firewall-Regeln wöchentlich aktualisiert werden; Möglicherweise werden jede Woche neue Regeln hinzugefügt, die den Betrieb Ihrer Website beeinträchtigen könnten. Beachten Sie, dass die Regeln höchstwahrscheinlich das Einreichen beeinflussen Daten an den Server, z. B. beim Absenden eines Formulars oder beim Aktualisieren von Daten im Backend Ihrer Website.
So finden und interpretieren Sie Firewall-Protokolle
Der erste Schritt besteht darin, die Serverprotokolle zu überprüfen, um herauszufinden, warum ein solcher Fehler angezeigt wird. Lesen Sie unseren Leitfaden zur Verwendung des Plesk-Dateimanagers zur Analyse Ihrer Website-Protokolle.
Da unsere Firewall für Webanwendungen dabei hilft, häufige Angriffe zu blockieren, sehen Sie möglicherweise viele ModSecurity-Einträge im Protokoll . Es ist wichtig, die Protokolleinträge zu identifizieren, die direkt entsprechen Sie der Aktion, die Sie ergreifen, andernfalls schwächen Sie am Ende sowohl die Firewall als auch das Problem nicht gleichzeitig.
Firewall-bezogene Fehler sehen etwa so aus:
ModSecurity: Access denied with code 403 (phase 2).
Pattern match "(asfunction|data|javascript|livescript|mocha|vbscript):" at ARGS:input_5_7_data_canvas.
[file "/etc/httpd/conf/modsecurity.d/rules/comodo/07_XSS_XSS.conf"] [line "227"]
[id "212770"] [rev "4"]
[msg "COMODO WAF: XSS Attack Detected||customerdomain.tld|F|2"]
[data "Matched Data: data: found within ARGS:input_5_7_data_canvas: data:image/png;base64,{{{{snipped}}}}]
[severity "CRITICAL"] [hostname "customerdomain.tld"]
[uri "/specific_uri_requested/"] Unser obiger Beispielprotokolleintrag ist ein falsch positives Ergebnis, das beim Senden eines Gravity Forms-Formulars mit einem Bildanhang aufgetreten ist.
Wir haben eine Menge Kauderwelsch herausgeschnitten und durch {{{{snipped}}}} ersetzt, um die Lesbarkeit zu verbessern. Wir haben auch bestimmte Teile fett gedruckt, um anzuzeigen, was für uns am relevantesten ist.
Wenn Sie die fettgedruckten Abschnitte der Reihe nach lesen, besagt dieser Fehler, dass die Firewall Folgendes gefunden hat:
- Der Zugriff wurde mit einem verbotenen Fehler verweigert (Code 403 ) (Hinweis:Wenn Sie „Code 403“ oder „Zugriff verweigert“ nicht sehen, ist der von Ihnen betrachtete ModSecurity-Protokolleintrag nicht relevant:Fahren Sie mit dem nächsten fort. Einige Einträge dienen dem Debugging oder allgemeinen Informationen, nicht alle sind zum Blockieren.)
- Eine Art Skript (Javascript, Livescript , usw.)
- Mit Regel-ID 212770
- Dass es als XSS-Angriff betrachtet wurde (Cross Site Scripting)
- Als ein Bild im codierten base64-Format (data:image/png;base64 )
- Mit Schweregrad „KRITISCH“ (Beachten Sie, wenn Sie einen Schweregrad von DEBUG oder WARNING sehen, sind diese wahrscheinlich nicht für einen sichtbaren 403-Fehler verantwortlich)
- Auf URI /specific_uri_requested/
Die Firewall wird deswegen ziemlich nervös! Verständlich:Es ist ein zufälliges Skript mit seltsam aussehenden Daten …
Da wir wissen, dass das Problem auftritt, wenn ein legitimer Benutzer ein Gravity-Formular einreicht, und es sich tatsächlich um ein Bild handelt, ist dies wahrscheinlich ein legitimer Anwendungsfall und daher ist der Fehler ein Fehlalarm.
Bitte öffnen Sie ein Ticket, wenn Sie Hilfe beim Dolmetschen benötigen! Fügen Sie unbedingt den Protokolleintrag hinzu, damit wir ihn schnell für Sie analysieren können.
Nachfolgend finden Sie zwei Möglichkeiten, diese Fehler zu umgehen:1) Deaktivieren der Firewall (nur in ausgewählten Fällen empfohlen) und 2) Ausschließen der bestimmten Regel(n), die das Fehlalarm erzeugen.
Lösung 1 (vorübergehend):Entwickeln? Firewall deaktivieren
Wenn Sie die Website derzeit entwickeln, ist es am besten, die Firewall einfach vollständig zu deaktivieren, da Sie wahrscheinlich auf eine Reihe von Hindernissen stoßen, wenn Sie Code über HTTP an den Server senden (dh:eine CSS-Änderung speichern) innerhalb von WordPress.
Bitte denken Sie daran, die Firewall wieder zu aktivieren, wenn Sie mit der Bearbeitung der Website fertig sind, da Ihre Website sonst nicht vor einer großen Anzahl gängiger Angriffe geschützt ist.
So deaktivieren Sie es:
- Kehren Sie in Plesk zu „Websites und Domains“ oder „Domains“ zurück und klicken Sie auf die Domain.
- Klicken Sie auf „Web Application Firewall“.
- Wählen Sie unter „Firewall-Modus für Webanwendungen“ „Aus“.
Hinweis:Wenn Sie „Nur Erkennung“ auswählen, erfasst unsere Firewall auf TCP-Ebene weiterhin die Protokolleinträge und richtet vorübergehende Sperren ein. Aus ist während der Entwicklung am besten. - Klicken Sie zum Speichern auf OK oder Anwenden.
Wenn Sie mit der Entwicklung fertig sind, aktivieren Sie die Firewall erneut, indem Sie denselben Schritten folgen, aber „Ein“ statt „Aus“ wählen.
Lösung 2 (permanent):ModSec-Regeln ausschließen
Wenn Benutzer Ihrer Website regelmäßig dieselbe Aktion ausführen, die den 403-Fehler ausgelöst hat, reicht es nicht aus, die Firewall vollständig zu deaktivieren!
Lassen Sie uns stattdessen fortfahren und diese Regel von der Firewall für die Domäne ausschließen. In unserem obigen Beispiel haben wir die Sicherheitsregel-ID 212770 identifiziert, aber Ihre wird sicherlich anders sein. Durchsuchen Sie den Protokolleintrag, bis Sie die ID finden. Sie sieht so aus:[id „212770“] dann…
- Kehren Sie in Plesk zu „Websites und Domains“ zurück
- Klicken Sie auf „Web Application Firewall“.
- Geben Sie unter „Sicherheitsregeln ausschalten“ die ID-Nummer ein, die Sie im Protokoll gefunden haben (normalerweise eine pro Zeile, wenn Sie mehr als eine haben).
- Klicken Sie zum Speichern auf OK oder Anwenden.
Versuchen Sie nun, die Aktion auszuführen, die zuvor das Problem verursacht hat.
Wenn das Problem NICHT behoben ist und Sie immer noch einen 403-Fehler erhalten, hat die Aktion wahrscheinlich mehrere ausgelöst Firewall-Regeln. Wiederholen Sie den obigen Vorgang, bis Sie alle Regel-IDs gefunden und ausgeschlossen haben, die Probleme verursachen. Beachten Sie, dass mehrere Regel-IDs, die diesen Fehler verursachen, wahrscheinlich sehr ähnlich sind Schauen Sie also genau hin, wenn Sie die neuesten Protokolleinträge überprüfen, um sicherzustellen, dass sich die angezeigten Einträge geringfügig von denen unterscheiden, die Sie bereits ausgeschlossen haben.
Wir mussten höchstens 5 in einer Sitzung ausschließen, also besteht eine gute Chance, dass Sie dies innerhalb von nur 2 oder 3 Ausschlüssen beheben können.
Fehlerbehebung
Wenn Sie eine Reihe von Regeln ausschließen, erhalten Sie einen Fehler wie diesen, dem keine ID zugeordnet ist:
ModSecurity: Output filter: Response body too large (over limit of 524288, total not specified).
Das bedeutet, dass Sie diese Limits erhöhen müssen. Wenn Sie Administratorzugriff auf Plesk haben, können Sie Folgendes unter Tools &Einstellungen> ModSecurity> Registerkarte Einstellungen> Benutzerdefinierte Anweisungen einfügen:
SecResponseBodyLimit 546870912SecRequestBodyInMemoryLimit 546870912
Wenn Sie keinen Administratorzugriff auf Plesk haben und bei uns gehostet werden, eröffnen Sie ein Ticket und wir kümmern uns darum!