www.fabiankeil.de/blog-surrogat/2005/12/08/403-dauersendung.html

Drei Stunden 403-Dauersendung

Gestern kam es unerklärlicherweise zu einer Fehlkonfiguration auf dem Server. Das Problem in Zahlen:

fk@T51 ~/logs $grep " 403 " fabiankeil.de-2005-12-07|cut -d " " -f 1|sort|uniq|wc
      83      83    1178

Ich bin mir keiner Schuld bewusst, doch die Indizien sprechen gegen mich.

Protokoll einer kleinen Katastrophe

Laut FTP-Logfile aktualisierte ich um 13:02:45 Uhr style_v2.css. Dem Apache-Logfile nach wurde um 13:03:28 Uhr der erste 403er ausgeliefert. Nicht für die frisch hochgeladene Datei, sondern für die von mir nicht bewusst berührte Heimseite.

Im Normalfall teste ich nicht, ob das Hochladen erfolgreich war, Fehler sehe ich frühestens am nächsten Tag im Logfile. Gestern machte ich eine Ausnahme um style_v2.css zu validieren.

Wie sich herausstellte, lieferte der Server für jede Abfrage 403. Selbst für Abfragen für die 404 passend wäre:

fk@T51 ~ $lynx -dump -head http://www.fabiankeil.de/adlfldsf.html
HTTP/1.1 403 Forbidden
Date: Wed, 07 Dec 2005 12:22:54 GMT
Server: Apache/df-exts 1.2 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7d
AuthPG/1.3 Connection: close
Content-Type: text/html; charset=iso-8859-1

Firefox gegenüber beschwerte sich der Server nicht nur über fehlende Rechte beim Surfer, sondern auch darüber, nicht auf meine handgestrickte Fehlerseite zugreifen zu können. Sehr mysteriös.

Lösungssuche

Die Datei-Rechte der Webseiten hielt ich für ausreichend. Der Besitzer und die Besitzer-Gruppe durften sie lesen. Zur Sicherheit räumte ich auch noch dem Rest der Welt Leserechte ein. Half nichts.

Das Mutter-Verzeichnis war les- und ausführbar für alle außer dem Rest der Welt. Auch hier lockerte ich die Rechte weiter. Half nichts.

Die .htaccess machte ich schließlich noch für jeden lesbar. Umsonst.

Hilfeschrei

Meine Macht hatte ich damit ausgespielt, in meinem Kindertarif ist kein Shell-Zugang enthalten, Apache-Meldungen bekomme ich – abgesehen von den abgerufenen Seiten – nicht zu sehen.

Um halb zwei wandte ich mich frustriert an Domainfactory, machte den Rechner aus und las ein Buch.

Problem gelöst

Nicht ganz drei Stunden später kam die Antwort:

Haben Sie per FTP die Datei- und Verzeichnisrechte verändert? Dort war einiges durcheinander.

Ich habe dies wieder korrigiert, die Homepage kann nun wieder ohne Probleme aufgerufen werden.

Nehmen Sie bitte keine Änderungen an den dateirechten vor, diese sind in der Grundeinstellung bereits ideal und bedürfen keiner Änderung (diese führen nur zu Problemen).

Ungefähr zeitgleich begann der Server wieder mit 200 und 304 zu antworten.

Whiskey Tango Foxtrott?

Auf dem Server sind die Rechte nun für Webseiten 640, für Unterverzeichnisse 750 und für das Oberverzeichnis 710. Strenger als nach meinen erfolglosen Bastelversuchen.

Ich habe keine Ahnung, wie dadurch das Problem gelöst worden sein soll. Weiterhin bleibt unklar, wie es entstanden ist.

Vor wenigen Tagen bin ich auf gFTP umgestiegen, mit dem Programm bin ich noch nicht besonders vertraut, es reagiert manchmal anders als von mir erwartet.

In der Vergangenheit hat das Hochladen damit trotzdem geklappt. Selbst nach erneuter Besichtigung habe ich keinen Zerstöre alle Dateirechte-Knopf gefunden, den ich ausversehen gedrückt haben könnte. Ich nehme nicht an, dass eine derartige Funktion über Mausgesten ausgelöst werden kann.

An den Dateirechten habe ich erst bewusst rumgespielt, als die 403-Dauersendung begonnen hatte. Im FTP-Logfile werden Rechteänderungen nicht protokolliert, ich kann es nicht überprüfen.

Paranoid genug?

Ich bin eigentlich nicht paranoid genug, Domainfactory zu verdächtigen, ein Skript auf mich angesetzt zu haben, um sich nach dem ersten FTP-Hochladen für die vorhergehende Kritik von vorgestern zu bedanken.

Andererseits habe ich keine Ahnung, wie ich welche Dateirechte vermurksen müsste, um Apache zu dem amüsanten Verhalten zu bringen. Zudem: die von mir kontrollierten Rechte passten.