Tutorials - Apache allgemein - Die Logs des Apache-Servers

Folgende Fragen werden hier erklärt:
- Was sind Logdateien, wofür brauche ich sie?
- Welche Apache-Logfiles gibt es?
- Wie sieht eine Apache-Logdatei aus?
- Logformat anpassen
- Unerwünschte Einträge ausfiltern
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.
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:
- access.log: Alle Zugriffe auf den Server werden in dieser Datei festgehalten.
- error.log: Eventuell aufgetretene Fehler werden hier festgehalten
- httpd.pid: Datei, die interne Informationen über Server-Prozesse aufnimmt (soll hier nicht weitergehend behandelt werden).
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:
- remotehost: Das ist der Rechnername oder die Internetadresse des Klienten, der das Dokument geholt hat. Die meisten Server können konfiguriert werden, ob sie für jeden Klienten den Namen aus der Internetadresse ermitteln sollen oder nicht. Eine Logdatei mit Namen ist natürlich Aussagevoller, aber die Tatsache, daß für jeden Request der Nameserver befragt werden muß, erzeugt einiges an Prozessorleistungsverbrauch oder Netzlast.
- rfc931: Der Loginname des Nutzers, unter dem er sich am Klientenrechner angemeldet hat. Dies wird normalerweise nicht vom Klienten mitgeliefert. Ist der Klientenrechner aber ein UNIX-Rechner auf dem ein sogenannter identd (nach RFC931) installiert ist, so kann der WWW-Server dies dort erfragen.
- authuser: Nutzerkennung die vom Nutzer bei der Authendifizierung auf dem Webserver angegeben wurde, wenn Dokumente aus einem mit Authendifizierung geschütztem Bereich geholt werden.
- [date]: Zeitpunkt der Transaktion z.B. [20/Dec/1999:15:22:34 +0100].
- ''request'': Die an den Server gestellte Anfrage z.B. ''GET /''.
- status: Zahlencode für den Abschlußzustand der Verbindung z.B. 200 = OK oder 404 = File not Found.
- bytes: Menge der abgeschickten Daten in Bytes.
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.
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:
- %a = IP-Adresse des Clienten
- %B = Die Größe der ausgelieferten Datei
- %{Variable}e = Eine Environment-Variable
- %f = Datei inklusive Pfades der angefragten Datei
- %h = Hostname des Clienten
- %{Header}i = Zeile aus dem Header der Client-Anfrage
- %l = Remote Username
- %{Header}o = Zeile aus dem Header der Antwort
- %q = der Query-String der Anfrage
- %r = Erste Zeile der Client-Anfrage
- %>s = Letzer Status der Anfrage (wie es der Client sieht)
- %t = Zeitangabe im CommonLog-Format
- %{Format}t = Zeitangabe im selbstdefinierten Format
- %T = Bearbeitungsdauer der Anfrage
- %u = Userid, wenn eine Authentifizierung erfolgt ist
- %U = Urlpfad der Anfrage
- %v = Konfigurierter Name des virtuellen Servers
- %V = Realer Name des virtuellen Servers
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:
- Referer = die Seite von der aus der Besucher auf Deine Seite kam
- User-Agent = Welchen Browser benutzt der Besucher?
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.
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.