403 Forbidden: Ursachen, Lösungen und Bot-Sperren, die Monitore täuschen

403 gegenüber 401

RFC 9110 zieht die Grenze klar. Ein 401 Unauthorized bedeutet, dass eine Authentifizierung erforderlich ist oder die gelieferten Zugangsdaten nicht akzeptiert wurden, und die Antwort muss einen WWW-Authenticate-Header tragen, der beschreibt, wie authentifiziert wird. Ein 403 Forbidden bedeutet, dass der Server sich weigert, die Anfrage zu autorisieren, und eine erneute Authentifizierung wird nichts ändern.

Die Spezifikation erlaubt einem Server außerdem, statt eines 403 einen 404 zu antworten, wenn er nicht preisgeben will, dass eine Ressource überhaupt existiert. Deshalb kann eine URL, von der Sie wissen, dass sie da ist, von einem gehärteten Server als "nicht gefunden" zurückkommen. Untersuchen Sie einen 403, denken Sie daran, dass auch der umgekehrte Fall existiert.

Was einen 403 erzeugt

• Dateisystemberechtigungen. Der Webserver-Prozess kann die Datei nicht lesen oder das Verzeichnis nicht durchqueren. Ein Klassiker nach einer manuellen Dateikopie oder einer Wiederherstellung, die den Besitzer geändert hat.
• Verzeichnisauflistung deaktiviert. Eine Anfrage an einen Ordner ohne Indexdatei liefert auf Servern, die so konfiguriert sind, Auflistungen zu verweigern, einen 403. Korrektes Verhalten, verwirrender Fehler.
• Autorisierungsregeln der Anwendung. Der Nutzer ist angemeldet, hat aber nicht die Rolle, den Tarif oder die Mandantenzugehörigkeit, die diese Ressource verlangt.
• IP-Positiv- und -Negativlisten. Ein auf Büroadressen beschränkter Admin-Pfad liefert 403 für alle anderen, auch für jemanden, der von zu Hause oder aus einem Mobilfunknetz testet.
• Web-Application-Firewall-Regeln. Eine WAF blockiert eine Anfrage, deren URL, Header oder Body zu einer Signatur passte. Oft wirkt die Anfrage für Sie völlig harmlos.
• Geo-Blocking. Traffic aus manchen Ländern oder Regionen wird am Edge abgelehnt, die Website ist also von einem Kontinent aus in Ordnung und von einem anderen verboten.
• Hotlink-Schutz. Eine Regel, die Anfragen nach Bildern oder Medien ablehnt, deren Referer-Header fehlt oder auf eine andere Domain zeigt. Anfragen ohne Referrer werden oft versehentlich erwischt.
• Bot- und User-Agent-Filterung. Die Anfrage wird blockiert, wegen dem, was der Client zu sein behauptet, nicht wegen dem, wonach er gefragt hat. Das ist der Fall, der Monitoring erwischt.

Der Fall "403 für Monitore, 200 für Menschen"

Das ist der häufigste Fehlalarm im Uptime-Monitoring, und es ist kein Monitoring-Fehler. Die Website liefert tatsächlich 403, nur nicht an Browser.

Bot-Management bei einem CDN oder einer WAF bewertet jede Anfrage anhand von User-Agent, TLS-Fingerabdruck, Header-Reihenfolge, IP-Reputation und ob sie eine JavaScript- oder interaktive Challenge löst. Eine automatisierte HTTP-Prüfung ist naturgemäß ein automatisierter Client: Sie führt keine JavaScript-Challenges aus und gibt sich ehrlich zu erkennen. Sie wird also herausgefordert oder blockiert, während Ihr Browser problemlos durchkommt, das Ergebnis ist eine Website, die als down alarmiert, während jeder Mensch bestätigt, dass sie erreichbar ist.

Zwei Anzeichen erkennen das schnell: Der 403 kommt sofort, nicht erst nach einer Verzögerung, was Überlastung ausschließt, und er tritt beim automatisierten Client konsequent auf, lässt sich aber im Browser im selben Netzwerk nie reproduzieren.

So setzen Sie einen Monitoring-Dienst auf die Positivliste

1. Bestätigen Sie, dass die Sperre identitätsbasiert ist. Wiederholen Sie die Anfrage als reinen HTTP-Client und dann mit einem Browser-User-Agent-String, und vergleichen Sie:

   curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
   curl -sS -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://example.com/

   Unterscheiden sich die Codes, ist eine User-Agent-Regel dafür verantwortlich.
2. Finden Sie die ausgelöste Regel. WAF- und CDN-Dashboards protokollieren blockierte Anfragen mit der passenden Regel-ID. Das ist schneller und sicherer, als zu raten, welche Regel gelockert werden soll.
3. Setzen Sie wo möglich per IP-Adresse auf die Positivliste. Monitoring-Anbieter veröffentlichen die Adressen, die ihre Prüfpunkte verwenden. Sie als Ausnahmeregel hinzuzufügen ist präzise und schwächt den Schutz für niemand sonst.
4. Oder setzen Sie per User-Agent auf die Positivliste. Konfigurieren Sie die Prüfung so, dass sie einen unverwechselbaren User-Agent sendet, und fügen Sie eine Regel hinzu, die ihn ausnimmt. Das ist einfacher zu pflegen als eine IP-Liste, behandeln Sie es aber als Komfortfunktion, nicht als Sicherheitsgrenze, denn einen User-Agent kann jeder kopieren.
5. Bevorzugen Sie eine Ausnahmeregel gegenüber dem Abschalten des Schutzes. Nehmen Sie den Monitoring-Pfad oder -Client von der konkreten Regel aus, und lassen Sie den Rest des Regelwerks in Kraft.
6. Testen Sie erneut aus mehreren Regionen. Eine Regel kann über die Edge-Standorte hinweg ungleichmäßig angewendet werden, verifizieren Sie die Korrektur also von mehr als einem Ort, bevor Sie das Ticket schließen.

Einen 403 beheben, der nichts mit Bots zu tun hat

1. Prüfen Sie, ob die URL überhaupt öffentlich sein sollte. Die Hälfte aller 403-Untersuchungen endet mit der Erkenntnis, dass die Sperre korrekt ist.
2. Verifizieren Sie Dateibesitz und Berechtigungen auf dem Pfad und jedem übergeordneten Verzeichnis. Der Serverprozess braucht Ausführungsrechte auf Verzeichnissen, nicht nur Leserechte auf der Datei.
3. Suchen Sie nach einer Indexdatei, falls die URL ein Verzeichnis ist, oder aktivieren Sie eine Auflistung absichtlich, falls gewünscht.
4. Lesen Sie die Serverkonfiguration auf Deny-Regeln, IP-Einschränkungen und Referrer-Prüfungen für diesen Pfad, dann die Autorisierungsebene der Anwendung.
5. Prüfen Sie den Edge vor dem Ursprung. Fragen Sie den Ursprung direkt ab. Ein 403, der verschwindet, wenn Sie das CDN umgehen, ist eine Edge-Regel, kein Anwendungsproblem.

Die Sperre von außerhalb Ihres eigenen Netzwerks sehen

Ein durch ein WAF-Update oder eine Berechtigungsänderung eingeführter 403 sieht von innen nicht wie ein Ausfall aus: Ihre Sitzung ist authentifiziert, Ihre Adresse ist auf der Positivliste, und die Seiten, die Sie prüfen, sind die, die funktionieren. Eine geplante HTTP-Prüfung bestätigt den erwarteten Code auf den relevanten URLs, von außerhalb Ihres Netzwerks, eine neu verbotene Seite löst also sofort einen Alarm aus. Geo-Sperren und Edge-Regeln variieren je nach Region, die Anzahl der Beobachtungspunkte zählt also: HostTracker prüft von über 300 Prüfpunkten in 158 Städten, was aus "in manchen Ländern verboten" einen sichtbaren Unterschied zwischen Standorten macht. Ist die Ablehnung vorübergehend und an das Anfragevolumen statt an die Identität gebunden, ist der Code meist stattdessen 429, behandelt in der Anleitung zu 429 Too Many Requests, und die breitere Familie steht in der 4xx-Übersicht.