Access denied on this server: Ursachen und Lösungen

Was die Fehlermeldung bedeutet

Der Wortlaut ist Teil keines Standards, weshalb er in so vielen unterschiedlichen Formen auftaucht. Apache gibt ihn aus einer Verzeichnisregel heraus aus. ModSecurity und Hosting-Kontrollpanels geben ihn aus, wenn eine Regel greift. Ein CDN oder eine WAF gibt eine eigene, markenspezifische Version mit Referenznummer aus. AWS liefert ihn als kurzes XML-Dokument von S3 oder CloudFront. Alle sagen auf HTTP-Ebene dasselbe: 403, verweigert, und keine Einladung, es mit Zugangsdaten erneut zu versuchen.

Genau dieser letzte Punkt unterscheidet ihn von den Fehlern, mit denen er verwechselt wird. Ein 401 fordert Sie zur Authentifizierung auf und erwartet einen erneuten Versuch. Ein 404 sagt, die Ressource sei nicht vorhanden. Ein 403 sagt, die Ressource sei vorhanden und Sie bekommen sie nicht, und die unveränderte Wiederholung der Anfrage liefert dasselbe Ergebnis. Der Status selbst wird in 403 Forbidden behandelt; in dieser Anleitung geht es darum, herauszufinden, welche Ebene Nein gesagt hat.

Finden Sie zuerst heraus, ob es nur Sie betrifft oder alle, denn die Lösungen haben nichts gemeinsam. Lädt die Seite bei einem Kollegen in einem anderen Netzwerk problemlos, sind Sie blockiert. Kann niemand die Seite laden, ist die Website falsch konfiguriert.

Warum es passiert

• Ihre IP-Adresse ist blockiert. Eine Firewall- oder WAF-Regel, die nach fehlgeschlagenen Anmeldungen hinzugefügt wurde, ein Scraper in Ihrem Netzwerk, oder eine manuelle Sperre, die niemand entfernt hat.
• Rate Limiting. Zu viele Anfragen in kurzer Zeit, was sich leicht durch eine reload-intensive Debugging-Sitzung oder eine gemeinsam genutzte Büroverbindung auslösen lässt.
• Geografische Einschränkungen. Websites, die auf ein Land beschränkt sind, oder die nach Missbrauch aus einer Region diese komplett sperren.
• Eine geteilte oder als verdächtig eingestufte IP. VPN-Exit-Nodes, Mobilfunk-NAT und günstige Hosting-Adressbereiche werden oft als Gruppe blockiert, wegen dem, was andere Nutzer getan haben.
• Bot-Regeln, die Ihren User-Agent auslesen. Kommandozeilen-Tools, Headless-Browser und ungewöhnliche User-Agent-Strings werden abgelehnt, wo ein normaler Browser durchgelassen wird.
• Veraltete Cookies oder eine defekte Sitzung. Ein abgelaufenes Sitzungstoken kann eine Ablehnung statt einer Weiterleitung zur Anmeldeseite erzeugen.
• Eine Browser-Erweiterung, die Header entfernt oder hinzufügt, oder ein Firmenproxy, der die Anfrage umschreibt.
• Datei- und Verzeichnisberechtigungen. Der Webserver-Nutzer kann die Datei nicht lesen oder ein übergeordnetes Verzeichnis nicht durchqueren.
• Keine Indexdatei bei deaktivierter Verzeichnisauflistung. Eine Anfrage an ein Verzeichnis ohne auszuliefernden Inhalt liefert bei aktivem Options -Indexes einen 403 statt einer leeren Seite.
• Eine explizite Deny-Regel. Ein Require all denied in der Apache-Konfiguration oder eine übrig gebliebene .htaccess aus einem Wartungsfenster.
• Ein WAF-Fehlalarm. ModSecurity und ähnliche Regelwerke weisen legitime Anfragen zurück, die etwas enthalten, das einem Injection-Versuch ähnelt, oft in einem Formularfeld oder einem Query-String.
• Berechtigungen im Cloud-Speicher. Eine S3-Bucket-Policy oder eine CloudFront-Origin-Access-Einstellung, die das Lesen des Objekts nicht erlaubt.

Wenn Sie der Besucher sind

1. Bestätigen Sie den Statuscode, statt dem Seitentext zu vertrauen. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page zeigt, ob es wirklich ein 403 ist oder ein 401 oder 429 im ähnlichen Gewand.
2. Öffnen Sie die Seite in einem privaten Fenster. Das entfernt in einem Schritt Cookies und die meisten Erweiterungen. Funktioniert es dort, liegt die Lösung an Ihrem Profil, nicht an der Website.
3. Löschen Sie gezielt die Cookies für diese Website statt alles zu löschen, und laden Sie dann neu.
4. Schalten Sie VPN oder Proxy aus und versuchen Sie es erneut. Funktioniert es dann, war die Adresse des Exit-Nodes das Problem, und der Wechsel zu einer anderen Region behebt es meist.
5. Probieren Sie ein anderes Netzwerk, am einfachsten ein Smartphone im Mobilfunknetz. Das ist der schnellste Weg zu beweisen, dass Ihre Adresse blockiert ist.
6. Deaktivieren Sie Erweiterungen einzeln, beginnend mit Werbeblockern, Datenschutztools und allem, was Header verändert.
7. Prüfen Sie, ob die Sperre regional ist, indem Sie jemanden in einem anderen Land fragen oder die Blockierseite auf einen Hinweis zu Ihrem Standort durchsehen.
8. Kontaktieren Sie die Website mit der Referenznummer, falls die Blockierseite eine anzeigt. WAF-Seiten geben meist eine Vorfall-ID aus, mit der der Betreiber die genaue ausgelöste Regel in Sekunden findet.

Wenn Sie die Website betreiben

1. Lesen Sie zuerst das Fehlerprotokoll. Es nennt die Ursache direkt, und jeder Schritt danach ist ohne es reines Raten:

   sudo tail -50 /var/log/apache2/error.log
   sudo tail -50 /var/log/nginx/error.log
   sudo grep -i modsecurity /var/log/apache2/error.log | tail -20

   Apache protokolliert ein Berechtigungsproblem als "client denied by server configuration" oder "Permission denied". nginx protokolliert "directory index of ... is forbidden" oder "open() ... failed (13: Permission denied)". Diese drei Meldungen decken die meisten Fälle ab.
2. Prüfen Sie die Berechtigungen entlang des gesamten Pfads, einschließlich jedes übergeordneten Verzeichnisses. Ein Verzeichnis, das der Webserver nicht betreten kann, verweigert alles darunter, egal wie korrekt die Datei selbst aussieht:

   namei -l /var/www/html/index.html
   sudo chmod 755 /var/www/html
   sudo chmod 644 /var/www/html/index.html
   sudo chown -R www-data:www-data /var/www/html

3. Suchen Sie nach einer Deny-Regel im vHost und in jeder .htaccess unterhalb des Document Root. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html findet sie in einem Durchgang.
4. Fügen Sie eine Indexdatei hinzu oder aktivieren Sie die Auflistung, wenn die Anfrage einem Verzeichnis gilt. Für ein bloßes Verzeichnis 403 auszuliefern ist der Standardfall, kein Fehler.
5. Prüfen Sie SELinux auf Systemen der Red-Hat-Familie, wo korrekte Unix-Berechtigungen allein noch nicht ausreichen: ls -Z /var/www/html, dann sudo restorecon -Rv /var/www/html.
6. Finden Sie die ausgelöste WAF-Regel und korrigieren Sie entweder die Anfrage oder fügen Sie eine eng gefasste Ausnahme für diese Regel und diesen Pfad hinzu. Das Regelwerk vollständig abzuschalten, um den Fehler loszuwerden, tauscht ein Problem gegen ein schlimmeres.
7. Überprüfen Sie die Sperrliste auf Adressbereiche, die während eines Vorfalls hinzugefügt wurden. Temporäre Sperren, die nie ein Ablaufdatum erhalten haben, sind eine häufige Ursache für Beschwerden Wochen später.
8. Bei S3 oder CloudFront prüfen Sie die Bucket-Policy und die Origin-Access-Konfiguration. Der XML-Body nennt die verweigerte Operation, was auf die konkret zu erteilende Berechtigung hinweist.

Von außen prüfen

Eine Sperre, die auf eine Adresse zielt, sieht von dieser Adresse aus genau wie ein websiteweiter Ausfall aus, und Sie können die beiden von der blockierten Maschine aus nicht unterscheiden. Fragen Sie von woanders nach.

Die Antwort-Header nennen meist die Ebene, die geantwortet hat. Achten Sie auf Server sowie auf herstellerspezifische Header wie CF-Ray oder X-Amz-Cf-Id, die verraten, ob die Ablehnung von Ihrem Ursprungsserver kam oder von einem Edge-Knoten, der ihn nie erreicht hat:

curl -sS -D - -o /dev/null https://example.com/page
curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://example.com/page

Liefert der zweite Befehl 200, wo der erste 403 zurückgab, liegt die Sperre am User-Agent, und mit Ihren Berechtigungen stimmt nichts nicht. Führen Sie dann die HTTP-Prüfung für dieselbe URL gleichzeitig von Prüfpunkten in mehreren Ländern aus. Ein 403 von jedem Standort ist ein Konfigurationsproblem der Website. Ein 403 aus zwei Ländern und 200 aus dem Rest ist eine geografische Regel oder eine regionale Sperrliste, eine Schlussfolgerung, die Sie mit einem curl von einem Schreibtisch aus nicht erreichen können.

Einen ungewollten 403 rechtzeitig erkennen

Zugriffsregeln brechen auf Arten, die auf Ihrer Seite keinen Fehler erzeugen. Ein WAF-Regelwerk wird aktualisiert, ein Skript zur Zertifikatsverlängerung schreibt eine Konfiguration um, eine temporäre Sperre gerät in Vergessenheit, und die Website liefert Ihnen weiterhin 200, während sie einem Teil der echten Besucher die Auslieferung verweigert. In Ihren eigenen Protokollen sieht nichts alarmierend aus, denn aus Sicht des Servers ist ein 403 eine normale, erfolgreiche Ablehnung. Eine geplante Prüfung, die den Statuscode von über 300 Prüfpunkten in 158 Städten ausliest, erkennt den Tag, an dem eine Region anfängt, abgelehnt zu werden, und alarmiert per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr. Die weiteren Anleitungen hier finden Sie im Bereich Problemlösung, und der Statuscode hinter dieser Meldung hat seine eigene Referenz unter 403 Forbidden.