Tutorials - Apache allgemein - Die Logs des Apache-Servers

image
Folgende Fragen werden hier erklärt:

Was sind Log-Dateien - wofür brauche ich sie?

Kurz: Eine Logdatei (to log, engl. = Buch führen über) ist eine Datei, die mit einem Texteditor geöffnet und eingesehen werden kann. Sie dient der Protokollierung und kann über ganz verschiedene Dinge Auskunft geben. Du hast bestimmt in Deinem Windows- oder Programmverzeichnissen schon Dateien gesehen namens "xyzinstalllog.txt", in denen steht, inwiefern die Installation eines Programmes erfolgreich war, oder nicht. In unserem Fall gibt es mehrere Logdateien, die uns Aufschluß über den Zustand des Apache-Servers geben. Als Betreiber eines Servers möchte man natürlich darüber im Bilde sein, ob selbiger fehlerfrei läuft, wer wann auf den Server zugegriffen hat, etc.

[Home]    [Übersicht Tutorials]    [^ nach oben]

Welche Apache-Logfiles gibt es?

Wo liegen die Logfiles? Du findest sie unter Windows im Verzeichnis: "C:\Apache\logs" (wen wundert's?). Am besten legst Du Dir zu diesem Ordner gleich eine Verknüpfung auf dem Desktop an, dann kannst Du immer schnell auf die Dateien zugreifen.
Unter Linux liegen die Dateien in "var/log/apache/".
Was siehst Du nun in Deinem Log-Ordner? Richtig, dort befinden sich standardmäßig drei Dateien, namens "access.log", "error.log" und "httpd.pid". Die Namen lassen schon ahnen, wozu die Dateien dienen:

[Home]    [Übersicht Tutorials]    [^ nach oben]

Wie sieht ein Apache-Logfile aus?

Bevor's losgeht, eines vorweg: Um die Logfiles des Apache "richtig zu verstehen" ist leider erst etwas trockene Theorie nötig. Aber keine Angst: das macht die Sache umso leichter, wenn wir nachher mal die "access.log" öffnen. Dann erklären sich alle Einträge darin von selber. Tieeeeef Luft holen und los geht's:

Da es natürlich einige Server auf dieser Welt gibt, die auch alle "Logfiles ausspucken", lag der Gedanke nahe, einen Standard für alle Server-Logfiles festzulegen, um zu verhindern, daß die Logfiles von Server-Software zu Server-Software anders aussehen. Denn das wäre Zeitaufwändig und umständlich. So begab es sich, daß das World Wide Web Consortium (W3C) folgendes Format als ''Allgemeines Logfileformat (Common Log Format)'' vorschlug:

remotehost rfc931 authuser [date] "request" status bytes

Böhmische Dörfer, Katze im Brunnen??? Keine Sorge, alles wird erklärt. Die einzelnen Worte haben folgende Bedeutung:


Aha, so weit, so gut. Wie sieht dann ein Logbucheintrag in echt aus? Na so, z.B:

127.0.0.1 - - [15/Jan/1985:11:06:34 +0200] "GET / HTTP/1.1" 200 3853

Wie man sieht, wurde hier durch Eingabe der URL: "http://localhost" lokal auf den Server zugegriffen, also ist die IP-Adresse 127.0.0.1. "rfc931" wird unter Windows nicht verwendet. An dieser Stelle wird in der Protokolldatei "-" eingetragen. Es handelte sich um keinen passwortgeschützten Bereich, deshalb ist kein "authuser" angegeben. Das Datum und die Zeit des Zugriffs wurden festgehalten, der Request-Befehl lautet "Get", also wurden Daten angefordert, die erfolgreich ausgeliefert wurden (Zahlencode 200 = o.K.). Bei dieser Anfrage wurden 3853 Bytes übertragen.
Dieses war jetzt ein Beispiel für das Standard-Logformat des Apache-Servers. Es gibt auch noch andere Formate, die kommen jetzt dran.

[Home]    [Übersicht Tutorials]    [^ nach oben]

Logformat anpassen

Wie bereits erwähnt, lässt sich das Format des Log-Eintrags noch verändern und an die eigenen Wünsche und Erfordernisse anpassen. Aber wie? -Ganz einfach, Du öffnest die httpd.conf im Editor, gehst auf "Suchen" und gibst als Suchbegriff "Logformat" ein. Du kommst in der httpd.conf-Datei zu einer solchen Stelle:

----------- Ausschnitt aus der httpd.conf -------------------

#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

#
# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a <VirtualHost>
# container, they will be logged here. Contrariwise, if you *do*
# define per-<VirtualHost> access logfiles, transactions will be
# logged therein and *not* in this file.
#
CustomLog logs/access.log common

#
# If you would like to have agent and referer logfiles, uncomment the
# following directives.
#
#CustomLog logs/referer.log referer
#CustomLog logs/agent.log agent

#
# If you prefer a single logfile with access, agent, and referer information
# (Combined Logfile Format) you can use the following directive.
#
#CustomLog logs/access.log combined

--------------------------------------------------------------------

Sehen wir uns das mal ganz in Ruhe von oben nach unten an: Was Du erst mal siehst, sind 4 Zeilen die ein Logformat festlegen. Da stehen aber so kryptische Zeichen dahinter. Was heißt das nun genau? Fangen wir mal mit der oberen Zeile an. Sie ist, wie Du siehst, die umfangreichste. Also, wenn Dir einmal klar ist, was diese Zeile bedeutet, stellen Dich die anderen Zeilen auch vor kein Rätsel mehr. Diese kryptischen Zeichen brauchen uns auch keine Angst machen, sie werden "Variablen" genannt, und stellen eine Kurzform für den oben besprochenen Satz

remotehost rfc931 authuser [date] "request" status bytes

dar. Hier eine Übersicht über die Variablen und deren Bedeutung:

So, nun können wir die erste Zeile nach dieser Tabelle "übersetzen". Wir kommen so weit wie oben, allerdings bleibt noch folgende Kette über:

\"%{Referer}i\" \"%{User-Agent}i\"" combined

Schauen wir mal: was heißt das nun wieder:

Gut, wir erfahren also noch, woher der Besucher kam und welchen Browser er benutzt hat. Und das "combined" am Ende steht einfach nur für das Logformat.
Wenn Du nun in der httpd.conf etwas weiter unten schaust, steht dort der folgende Satz:

CustomLog logs/access.log common

Dieser ist nicht auskommentiert. Das heißt, die Zugriffe auf den Server werden im Standardformat geloggt, ohne Referer und User-Agent. Möchtest Du nun das "ausführliche Log" haben, dann musst Du diese Zeile auskommentieren und statt dessen die Zeile

#CustomLog logs/access.log combined

aktivieren. Dann werden folgende Einträge in Deinem Logfile stehen:

127.0.0.1 - - [15/Jan/1985:11:37:53 +0200] "GET / HTTP/1.1" 200 17083 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)"

Verständlich? Ich hoffe, doch. Jedoch haben wir ja noch zwei Einträge in der httpd.conf stehen, die bis jetzt noch nicht zur Sprache kamen, nämlich:

#CustomLog logs/referer.log referer
#CustomLog logs/agent.log agent

Also, nehmen wir einmal an, es würde Dich brennend interessieren, von welcher Seite aus Deine Besucher kamen, oder mit welchem Browser sie im Netz unterwegs waren. Dann kommentierst Du diese beiden Zeilen einfach ein, und bekommst im Logs-Ordner zwei zusätzliche Dateien namens "referer.log" und "agent.log", in denen das festgehalten ist. Du siehst, man kann schon einiges über seine Besucher herausfinden. Interessant ist das dann zu wissen, wenn Du auf anderen Seiten einen Link auf Deine Seite hast. Dann kannst Du sehen, wie viele Leute dem Link gefolgt sind (Kann recht interessant sein, wenn der Kampf um Traffic und Besucher losgeht...).

Dann gibt es ja noch die "error.log"-Datei. Ihre Funktion ist schnell erklärt. Wenn Du sie öffnest, wirst Du Einträge wie diesen sehen:

[Mon Mar 26 13:29:26 1999] [error] [client 127.0.0.1] File does not exist: j:/home/guestboo.html

Der Grund der Fehlermeldung liegt auf der Hand: Es wurde eine falsche Adresse abgesetzt, statt "Guestbook" wurde "Guestboo" eingegeben. Der Server hat diese Datei nicht gefunden, und einen 404-Error gemeldet. Dieser Vorfall wurde hier in die Log-Datei geschrieben.

So, mit diesem Know-How öffne nun Deine "Access-Log" -Datei. Dann wirst Du sehen: es ist gar nicht mehr so schwer, da durchzublicken. Nun kannst Du die Logdateien schon nach Deinen Wünschen anpassen.

[Home]    [Übersicht Tutorials]    [^ nach oben]

Unerwünschte Einträge ausfiltern

Nun weißt Du schon einiges über die Logdateien. Spätestens jedoch, wenn Du Deinen Server im Internet stehen hast, wirst Du eines Tages Deine Logdateien überprüfen, und im "access.log" stehen z.B. folgende Einträge (IP-Adresse geändert):

--------- Ausschnitt aus access.log -------------

1.2.3.4 - - [15/May/2002:12:39:31 +0200] "GET /scripts/root.exe?/c+dir HTTP/1.0" 404 291
1.2.3.4 - - [15/May/2002:12:39:32 +0200] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 289
1.2.3.4 - - [15/May/2002:12:39:32 +0200] "GET /c/winnt/system32/ cmd.exe?/c+dir HTTP/1.0" 404 299
1.2.3.4 - - [15/May/2002:12:39:33 +0200] "GET /d/winnt/system32/ cmd.exe?/c+dir HTTP/1.0" 404 299
1.2.3.4 - - [15/May/2002:12:39:33 +0200] "GET /scripts/..%255c../winnt/ system32/cmd.exe?/c+dir HTTP/1.0" 404 313

--------------------------------------------------------

Du kannst mir glauben, als ich diese Zeilen das erste Mal sah, bekam ich einen Riesen-Schreck weil ich dachte, da will einer meinen Server lahmlegen. Im Grunde geht es auch darum, es handelt sich hierbei um eine "Anfrage" des Nimda-Wurmes, der im Internet nach Webservern von Microsoft (IIS) sucht, um dort eine bekannte Sicherheitslücke auszunutzen und sich weiter zu verbreiten. Aber da können wir nur grinsen: wir haben ja einen "ernsthaften Webserver" aufgesetzt, und so kann Nimda alias "Code Red" bei uns nichts holen. Interessant ist die Tatsache daß dieser Wurm noch recht intensiv unterwegs ist, wohl weil einige Leute das Wort "Antivirensoftware" noch nie in ihrem Leben gehört haben. Wenn Du es Dir zutraust, schiesst Du auch noch ein paar Angriffe auf die befallenen Rechner ab, denn deren IP-Adresse hast Du ja nun, und bei schon befallenen Rechnern mit Microsoft-Software hast Du gute Chancen... NEIN, das machst Du natürlich nicht, das war nur Spass!!! Wir wollen uns daran machen, diese unerwünschten Einträge aus dem Logfile zu verbannen. Aber wie?
Du könnstest nun sagen: "Ich markiere die Stelle in der access.log und lösche sie manuell". - Das wäre eine Möglichkeit, aber leider ist es uns nicht möglich, bei laufendem Server auf die Datei zuzugreifen. Wir müssen den Apache erst beenden, bevor wir Änderungen an den Logdateien vornehmen können, was ich jedoch nicht empfehle.
Elegant geht es auch auf diese Art und Weise: Man filtert die Einträge des Nimda-Wurms von vornherein aus, und schickt sie an eine andere Datei, in der sie eingetragen werden. Dazu musst Du Deiner httpd.conf lediglich einige Zeilen hinzufügen. Das ganze sieht folgendermaßen aus:

----------- Ausschnitt aus der httpd.conf ----------------

#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

#
# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a <VirtualHost>
# container, they will be logged here. Contrariwise, if you *do*
# define per-<VirtualHost> access logfiles, transactions will be
# logged therein and *not* in this file.
#
------- Diese Zeilen werden eingetragen: ---------------

SetEnvIf Request_URI "/root.exe" attacks
SetEnvIf Request_URI "/cmd.exe" attacks
SetEnvIf Request_URI "/default.ida" attacks
SetEnvIf Request_URI "/scripts" attacks
SetEnvIf Request_URI "/c/winnt" attacks
SetEnvIf Request_URI "/d/winnt" attacks
SetEnvIf Request_URI "/_mem_bin" attacks
SetEnvIf Request_URI "/_vti_bin" attacks
SetEnvIf Request_URI "/MSADC" attacks
SetEnvIf Request_URI "/msadc" attacks

CustomLog logs/attack.log common env=attacks
CustomLog logs/access.log common env=!attacks

----------------------------------------------------------

#CustomLog logs/access.log common <--- Dieser Eintrag wird auskommentiert.

-------------------------------------------------------

Was bewirken diese Zeilen? Es wird dem Server gesagt, daß er alle Nimda-Anfragen in eine extra Datei schreibt, nämlich der "attack.log" im Logs-Verzeichnis. So werden diese nicht weiterhin in die access.log eingetragen, und man kann sofort anhand der "attack.log" sehen, wieviele Nimda-Anfragen noch so durch's Netz sausen.


[Home]    [Übersicht Tutorials]    [^ nach oben]