Merkwürdige Einträge in Apache-Log

[Hans-Otto]

hi,

seit ca. einem Jahr finden sich in meinen Logdateien des Apache-Servers merkwürdige Einträge.

In der Position, wo normalerweise die entsprechenden Methoden wie etwa "GET", "HEAD" oder "POST" stehen, findet sich stattdessen ein "8\r\xff", wie beispielsweise hier:

99.88.111.200 - - [21/Aug/2010:10:52:52 +0200] "8\r\xff" 400 226 "-" "-"

Bei einer Homepage waren es im Dezember über 2.000 solcher Einträge in der Logdatei, wobei die IP-Adresse hier keine Rolle spielt, es ist fast immer eine andere.

Außerdem merkwürdig: Genau dann, wenn diese "Abfrage" erfolgt, wird auf den Homepages, die mit PHP laufen, ein Fehler erzeugt (kann man feststellen, da sämtliche PHP-Fehler automatisch über den seterrorhandler() protokolliert werden; Datum und Uhrzeit des Apache-Logs und des Fehler-Logs stimmen überein).

Sobald das System die obige Abfrage ausführt und in der PHP-Datei die vorbelegte Variable $_SERVER['HTTP_HOST'] verwendet wird, erzeugt dies in PHP den Fehler

Undefined index:  HTTP\_HOST  

Irgendwie scheint es, dass das obige 8\r\xff entweder den Webserver oder das PHP-System bewusst durcheinander bringt (obwohl genau genommen die PHP-Datei gar nicht ausgeführt werden dürfte, da das System laut Logdatei mit Error 400 einen "Bad request" meldet).

Mein Provider ist leider auch ratlos (obwohl ich sicher nicht der einzige mit diesen Einträgen bin). Hat irgend jemand eine Idee, um was für merkwürdige Abfragen es sich in der Logdatei handelt?

Danke schon mal im voraus.

ciao
h-o

[Der Martin]

Hallo,

In der Position, wo normalerweise die entsprechenden Methoden wie etwa "GET", "HEAD" oder "POST" stehen, findet sich stattdessen ein "8\r\xff", wie beispielsweise hier:

99.88.111.200 - - [21/Aug/2010:10:52:52 +0200] "8\r\xff" 400 226 "-" "-"

sieht so aus, als ob hier jemand mit einem kaputten Script HTTP-Requests erzeugen will und nicht so richtig weiß, wie das geht. Oder aber derjenige hofft, den Server mit solchen unsinnigen Angaben aufs Kreuz legen zu können.

Außerdem merkwürdig: Genau dann, wenn diese "Abfrage" erfolgt, wird auf den Homepages, die mit PHP laufen, ein Fehler erzeugt ...

Nämlich welcher?

Sobald das System die obige Abfrage ausführt und in der PHP-Datei die vorbelegte Variable $_SERVER['HTTP_HOST'] verwendet wird, erzeugt dies in PHP den Fehler
Undefined index:  HTTP_HOST

Das ist kein Fehler, sondern eine Notice. Anyway - das heißt, dass im HTTP-Header kein Hostname angegeben war (war in HTTP/1.0 noch nicht Pflicht), also kann PHP diese Information auch nicht zur Verfügung stellen. Wenn das Script das Vorhandensein dieser Information nicht prüft, ist das nachlässig. Aber ehrlich gesagt, würde ich bei solchen Kerninformationen auch voraussetzen, dass sie da sind.
Viel interessanter finde ich die Frage: Wie kommt ein HTTP-Request ohne Host-Header überhaupt bis zu deinem VHost? Und wie kommt der dann auf die Idee, auch noch PHP damit zu betrauen? Dieser Request müsste eigentlich vom Default-VHost abgefrühstückt werden. Da scheint dein Provider also auch eine eigentümliche Konfiguration zu haben.

Irgendwie scheint es, dass das obige 8\r\xff entweder den Webserver oder das PHP-System bewusst durcheinander bringt (obwohl genau genommen die PHP-Datei gar nicht ausgeführt werden dürfte, da das System laut Logdatei mit Error 400 einen "Bad request" meldet).

Ein 400er wäre nachvollziehbar - aber nicht für deinen VHost, sondern den Default-Host.

Mein Provider ist leider auch ratlos (obwohl ich sicher nicht der einzige mit diesen Einträgen bin).

Das spricht nicht gerade für ihn.

So long,
 Martin

[dedlfix]

Hi!

Viel interessanter finde ich die Frage: Wie kommt ein HTTP-Request ohne Host-Header überhaupt bis zu deinem VHost?

Die einzige logische Erklärung, die mir einfällt, wäre, dass die fraglichen Requests auf einem Server ohne VHost oder dem Default-VHost landen, und der OP demzufolge einen eigenen Server hat und kein Shared-Hosting-Kunde ist.

Und wie kommt der dann auf die Idee, auch noch PHP damit zu betrauen?

Vermutlich zeigen die ErrorDocuments auf PHP-Files. Bei meinem Versuch konnte ich die Log-Zeile nachvollziehen. Bei mir antwortete der Server selbst mit einem 400 Bad Request (hab keine spezielle ErrorDocument-Konfiguration).

Dieser Request müsste eigentlich vom Default-VHost abgefrühstückt werden. Da scheint dein Provider also auch eine eigentümliche Konfiguration zu haben.

Kann auch sein, ist aber vermutlich nicht so. Er sprach ja auch von seinem Apache-Server. Wenn das nicht gerade nachlässig formuliert war ... aber die anderen Indizien deuten sehr darauf hin.

Irgendwie scheint es, dass das obige 8\r\xff entweder den Webserver oder das PHP-System bewusst durcheinander bringt (obwohl genau genommen die PHP-Datei gar nicht ausgeführt werden dürfte, da das System laut Logdatei mit Error 400 einen "Bad request" meldet).
Ein 400er wäre nachvollziehbar - aber nicht für deinen VHost, sondern den Default-Host.

Vom Server selbst, wäre eine Erklärung.

Mein Provider ist leider auch ratlos (obwohl ich sicher nicht der einzige mit diesen Einträgen bin).
Das spricht nicht gerade für ihn.

Es könnte auch gegen den Kunden sprechen, der die dem Preis angemessene Leistung erhält.

Gegen falsche Requests kann sich auch ein Provider nicht direkt wehren. Er könnte lediglich Filtertechnik einsetzen, die nur korrekte Requests durchlässt, was vermutlich ein unwirtschaftliches Kosten-Nutzen-Verhältnis hat. Meine Strategie wäre: Wenn es keinen Schaden anrichtet, ignorieren. Beziehungsweise dafür sorgen, dass es ungefährlich abgearbeitet wird. Konkret: Müssen 400er Fehler durch ein (vermutetes) PHP-ErrorDocument? Und wenn er schon dabei ist, wäre zu klären, für welche Fehler der OP für seinen Anwendungsfall eine Abarbeitung durch PHP für sinnvoll hält?

Lo!

[Held]

Ein 501 wäre hier eher angebracht. Viele Provider sind eben mit der Administration eines Webservers überfordert.

Generell sind ja beliebige Methoden für einen Request möglich. Ob der Server dann etwas damit anfangen kann steht allerdings auf einem anderen Blatt. "8\r\xff" könnte als Test oder Spass gedacht sein, wobei über 2.000 derartige Abfragen schon eher als Angriff gewertet werden könnten.

[Sven Rautenberg]

Moin!

Ein 501 wäre hier eher angebracht.

Nein, absolut nicht. Der Request des Clients scheint Müll zu sein. Also Statusklasse 4xx für Clientfehler.

Viele Provider sind eben mit der Administration eines Webservers überfordert.

Ich kann dieses Pauschalurteil nicht mehr hören, vor allem, weil's gerne gebracht wird, wenn man selbst auch keinen Schimmer hat, was abgeht. Und insbesondere auch keine Ahnung von HTTP-Fehlercodes hat.

Wenn der Provider dazu keine Auskunft geben kann, ist das sicherlich nicht dem mangelnden Administrationswissen zuzuordnen, sondern eher den Kundensupport-Strukturen.

- Sven Rautenberg

[hotti]

Moin,

Wenn der Provider dazu keine Auskunft geben kann, ist das sicherlich nicht dem mangelnden Administrationswissen zuzuordnen, sondern eher den Kundensupport-Strukturen.

Was zweifelsfrei wiederum auf den Provider zurückfällt ;-)

Hotti

[suit]

Was zweifelsfrei wiederum auf den Provider zurückfällt ;-)

Wieso?

Wie Martin schon gesagt hat: wer Scheiße bestellt, bekommt Scheiße serviert. Wenn die Scheiße dann auch noch schön cremig ist, gibts daran nichts auzusetzen.

Entschuldigt meine etwas übertragene Definition von Qualiät ;)

[hotti]

Was zweifelsfrei wiederum auf den Provider zurückfällt ;-)

Wieso?

Wenn Du schon zitierst, dann richtig: es geht um den Support.

Hotti