Apache Webserver

Webserver sind Programme die HTTP-Anfragen verarbeiten und Dokumente zurückliefern. Im Normalfall handelt es sich dabei um HTML-Dokumente. Jedoch ist das HTTP-Protokoll nicht auf HTML Dokumente beschränkt und kann prinzipiell beliebige Dokumente ausliefern.

Apache ist der meistverwendeste Webserver im Internet. Er läuft auf allen Unixartigen Betriebssystemen und seit Version 2.0 auch auf Windows. Apache liegt derzeit in Version 2.2 vor, wobei im Internet auch die Versionen 1.3 und 2.0 noch häufig anzutreffen sind. Diese Unterlagen gehen auf Apache unter Unix ein, wobei das meiste gesagte für die Versionen 1.3, 2.0 und 2.2 gleichermassen gilt. Sollte es Unterschiede zwischen den Versionen geben, werden diese erwähnt.

Vor der eigentlichen Apache-Konfiguration ist es jedoch sinnvoll einige Grundlagen des HTTP-Protokolls zu kennen.

HTTP

HTTP ist ein Anwendungsprotokoll (OSI-Layer 5 bis 7) welches dazu dient Dokumente in einem Netzwerk anzufordern. HTTP steht für Hypertext Transport Protokoll. HTTP arbeitet mit TCP und nutzt als Standardport 80, beziehungsweise für SSL-verschlüsselte Verbindungen Port 443. Es existieren die beiden Versionen 1.0 und 1.1 des HTTP-Protokolls, wobei 1.1 so erweitert wurde, daß mehrere Anfragen über eine TCP Verbindung gestellt werden können (sogenanntes Keep Alive). Dies verbessert die Geschwindigkeit der Verbindungen, da nicht mehr für jede einzelne Anfrage (Clients stellen im Normalfall mehrere HTTP-Anfragen unmittelbar hintereinander) eine neue TCP Verbindung aufgebaut werden muß. Server für HTTP sind Webserver wie etwa Apache und IIS. Clients für HTTP sind üblicherweise Browser, wie Internet Explorer, Firefox oder Chrome, können aber alternativ auch zum Beispiel Downloadprogramme wie etwa wget sein. HTTP Version 1.0 wird definiert in RFC 1945 und HTTP Version 1.1 wird definiert in RFC 2616.

HTTP kennt verschiedene Anfragearten, wie etwa GET, POST, HEAD, OPTION, PUT und TRACE. Für einen normalen Webserver, der nur Dokumente ausliefern soll sind nur die Anfragearten GET, POST und HEAD relevant. Die meisten anderen Anfragearten machen nur Sinn bei Webdav-Servern auf denen das HTTP-Protokoll als Dateiserver genutzt wird oder bei Proxy-Servern. Die folgende Tabelle erklärt die Bedeutung der wichtigsten Anfragearten.

HTTP Anfragearten
Anfrageart	Bedeutung
GET	Diese Anfrage fordert ein Dokument beim Server an.
HEAD	Diese Anfrage fordert genauso wie GET ein Dokument beim Server an, verlangt jedoch nur die Headerzeilen der HTTP Antwort, statt des ganzen Dokumentes.
POST	Diese Anfrage sendet Daten an den Server, zum Beispiel zur Verarbeitung durch ein Script auf dem Server.
CONNECT	Diese Methode wird auf Proxy-Servern verwendet um SSL-Verbindungen aufzubauen. Die Verbindung wird dabei zwischen Client und Zielserver durchgereicht.
PUT	Diese Methode lädt ein Dokument auf dem Server herauf. Wird fast nur bei Webdav-Servern verwendet.
DELETE	Diese Methode löscht ein Dokument auf dem Webserver. Wird nur in Verbindung mit Webdav verwendet.
OPTIONS	Liefert eine Liste der vom Server unterstützen Optionen zurück.
TRACE	Liefert die Anfrage so zurück wie sie empfangen wurde. Dient dem Debugging von Verbindungen.

Normale Webserveranfragen, die ein Dokument verlangen sind GET-Anfragen. Sollen auch Daten mitgesendet werden, wird meist POST als Anfrageart verwendet.

HTTP ist ein Klartextprotokoll. Dies ermöglicht es HTTP-Anfragen auch "von Hand" zu stellen. Eine Beispielsitzung verdeutlicht dies:

telnet www.example.net 80
GET /index.html HTTP/1.1
Host: www.example.net

HTTP/1.1 200 OK
Date: Mon, 09 May 2011 15:05:29 GMT
Server: Apache
Last-Modified: Thu, 06 Jan 2011 21:37:43 GMT
ETag: "2212727e2316cb4cc48fd250bd72d5584f294567"
Accept-Ranges: bytes
Content-Length: 850
Content-Type: text/html

...

In diesem Beispiel wird mit dem Programm telnet eine Verbindung auf den Server www.example.net an Port 80 geöffnet. Anschließend werden 2 Zeilen eingegeben: In der ersten Zeile wird die Anfrageart definiert, in diesem Fall GET und anschließend das angeforderte Dokument, in diesem Fall /index.html. Anschließend wird noch die zu verwendende HTTP Version angegeben. In der zweiten Zeile wird der Hostname angegeben. Obwohl bereits eine Verbindung zu diesem Host aufgebaut wurde, ist diese Angabe notwendig, da ein Host mehrere Hostnamen haben kann, mit jeweils getrennten Websites. Die meisten HTTP-Clients senden noch einige Informationen mehr mit, als diese beiden Zeilen, jedoch sind diese beiden Zeilen, das Minimum in HTTP um eine Antwort zu erhalten.

Nach einer Leerzeile sendet der Server seine Antwort. Hier sind für die Antwort die HTTP-Headerzeilen zu sehen. Danach folgt noch das eigentliche Dokument, das in diesem Beispiel ausgelassen wurde. Die erste Zeile der Server-Antwort gibt wiederrrum die HTTP-Version an und einen HTTP-Statuscode. Der Statuscode ist eine dreistellige Nummer, die darüber Auskunft gibt, ob die Anfrage korrekt verarbeitet werden konnte, oder ein Fehler aufgetreten ist. In diesem Fall ist der Statuscode 200, was bedeutet, das die Anfrage korrekt verarbeitet wurde und das Dokument zurück geliefert wird. Der Server gibt sich auch als Apache Webserver im Header zu erkennen. Wichtig im Header ist auch die Angabe des Dokumententyps (Content-Type, hier in der letzten Zeile). Der Mimetype ist wichtig für den Client, damit dieser das Dokument korrekt anzeigen kann. Stimmt der Mimetype nicht, wird das Dokument vom Client womöglich falsch oder gar nicht angezeigt. Sollte etwa ein HTML-Dokument (Mimetype text/html) als Plaintext (Mimetype text/plain) ausgeliefert werden, zeigt ein Browser die HTML-Tags des Dokumentes als Inhalt mit an, statt diese als HTML zu parsen. Auch die Größe des Dokumentes (Content-Length) wird im HTTP-Header immer angegeben, in diesem Fall 850 Byte.

Die folgende Tabelle gibt einen Überblick über die wichtigsten HTTP-Statuscodes.

HTTP Statuscodes
Statuscode	Bedeutung
2xx	Alle Statuscodes die mit 2 beginnen, bedeuten die erfolgreiche Ausführung der Anfrage ohne Fehler.
200	Die Anfrage wurde akzeptiert und das Ergebnis der Anfrage wird in der Antwort übertragen.
3xx	Alle Statuscodes die mit einer 3 beginnen sind Umleitungen, das heißt der Client wird auf ein anderes Dokument verwiesen.
300	Das angefragte Dokument steht auf verschiedene Arten zur Verfügung. Die Antwort enthält eine Liste der Arten, welche vom Server zurück geliefert werden können.
301	Das angeforderte Dokument steht unter einer anderen Adresse zur Verfügung. Die Adresse wird im Location-Header der Antwort übertragen.
4xx	Alle Statuscodes die mit 4 beginnen sind Clientfehler.
400	Syntaxfehler in der Anfrage des Clients.
401	Autorisierung erforderlich.
403	Zugriff verboten
404	Das angeforderte Dokument wurde nicht gefunden.
5xx	Alle Statuscodes die mit 5 beginnen sind Serverfehler.
500	Unerwarteter Serverfehler (Sammelcode für nicht näher spezifizierte Serverfehler).

Allgemeines

Unter Unixartigen Systemen, gibt es für viele Systeme Betriebssystemspezifische Möglichkeiten um Apache zu installieren. Unter Linux wird im allgemeinen eine Paketverwaltung wie etwa rpm oder dpkg benutzt um ein Distributionsspezifisches Apachepaket zu installieren. Auf BSD Systemen kann entweder ein fertiges Package mit pkg_add installiert werden, oder es kann der Portstree benutzt werden. Unter OpenBSD ist ein modifizierter Apache 1.3 bereits im Basissystem enthalten. Daneben kann auf jeden unterstützten Unix der Quellcode von Apache kompiliert werden.

Wurde Apache aus dem Quellcode installiert, liegen alle Dateien die zu Apache gehören unterhalb von /usr/local/apache2 (für die Versionen 2.0 und 2.2). Werden fertige Pakete benutzt, liegen die Konfigurationsdateien des Apache meist in einem Unterverzeichnis unter /etc (zum Beispiel /etc/apache2). Unter OpenBSD liegen alle zum Apache zugehörigen Dateien unter /var/www, da der OpenBSD-Apache so modifiziert wurde, das er einen chroot in dieses Verzeichnis macht.

Die wichtigste Konfigurationsdatei des Apache ist die httpd.conf. Manche Pakete etwa von Linuxdistributionen teilen diese Konfigurationsdatei oft in mehrere Dateien auf. Außerdem wird mit Apache immer auch eine Datei namens mime.types ausgeliefert, welche die Konfiguration der Mimetypen beinhaltet.

Zum starten und Stoppen des Apache haben die meisten Pakete ein eigenes Start- und Stopscript, unter Linux etwa in /etc/init.d. Daneben wird mit Apache auch das Tool apachectl zum stoppen und starten des Apache mitgeliefert. apachectl kann alternativ zu einer Betriebssystemspezifischen Methode zum stoppen und starten des Apache verwendet werden oder wenn gar keine solche Methode vorhanden ist (dies ist unter OpenBSD der Fall). Über apachectl kann der Apache mit apachectl start gestartet werden und mit apachectl stop wieder beendet werden. Die folgende Tabelle gibt eine Übersicht über alle Kommandos die mit apachectl durchgeführt werden können. Diese Kommandos müssen alle mit root-Rechten ausgeführt werden.

apachectl Kommandos
Kommando	Bedeutung
start	Startet den Apache.
stop	Stoppt den Apache.
startssl	Startet den Apache mit SSL (nur 1.3/2.0). Diese Anweisung wurde in Version 2.2 entfernt.
restart	Führt einen Neustart des Apachedienstes aus.
configtest	Testet die Syntax der Konfigurationsdatei.
fullstatus	Gibt einen Statusbericht zum Server aus. Dies setzt vorraus, daß das Modul mod_status im Server aktiviert wurde.
status	Wie fullstatus, nur das die Liste der momentanen Anfragen nicht mit ausgegeben wird.
graceful	Lädt die Konfigurationsdatei des Servers neu. Im Gegensatz zu restart werden laufende Verbindungen dabei nicht unterbrochen.

Grundkonfiguration

Die gesamte folgende Konfiguration des Apache, wird über die Konfigurationsdatei httpd.conf vorgenommen. In den Paketen mancher Linuxdistributionen heißt diese Datei auch apache2.conf. Um alle wichtigen Konfigurationsdirektiven kennen zu lernen, beginnt man am besten mit einer neuen leeren httpd.conf. Die mit Apache ausgelieferte httpd.conf sollte einfach umbenannt werden um diese für Referenzzwecke aufzuheben. Zeilen die mit # beginnen werden als Kommentarzeilen betrachtet und nicht weiter ausgewertet. Die folgende Konfiguration ist eine minimale Konfiguration in der httpd.conf um den Apache betreiben zu können:

ServerRoot /etc/apache2/
DocumentRoot /var/www
User www-data
Group www-data
PidFile /var/run/apache2.pid
ErrorLog /var/log/apache2/error.log
Listen 80

Die Direktive ServerRoot definiert den Pfad zu den Konfigurationsdateien und anderen zu Apache gehörenden Dateien. Spätere Konfigurationsdirektiven, die keinen absoluten Pfad enthalten, werden immer relativ von diesem Pfad aus betrachtet. Speziell in OpenBSD ist dies auch das Verzeichnis, in das der Apache seinen chroot ausführt. Das DocumentRoot ist der Pfad, in dem die von Apache ausgelieferten Dokumente, wie etwa die HTML-Dateien liegen. Alles was in diesen Pfad liegt, wird vom Apache per HTTP angezeigt und ausgeliefert. Die Direktiven User und Group definieren den Benutzer und die Gruppe unter der der Apache läuft. Der Apache muß mit root Rechten gestartet werden, wechselt danach aber aus Sicherheitsgründen zu einem unprivilegierten Benutzer. Zu diesem Zweck ist auf den meisten Systemen bereits ein Benutzer und eine Gruppe vordefiniert. Unter Debian ist dies etwa www-data und unter OpenBSD www. Sollte für diesen Zweck noch kein Benutzer und keine Gruppe vorhanden sein, müssen diese vorher angelegt werden. Mit PidFile wird eine Datei definiert, in die der Apache seine Prozess-ID beim starten schreibt. Diese Datei wird von Tools zum starten und stoppen des Apache, wie etwa apachectl verwendet. Die Direktive ErrorLog definiert eine Logdatei für Fehlermeldungen des Apache. In dieser Datei werden sowohl 4xx und 5xx Statuscodes festgehalten, als auch Fehler zum Beispiel beim starten des Servers.

Mit Listen wird definiert auf welchen Port und welcher IP-Adresse der Apache Webserver lauscht. Dabei gibt es die Möglichkeit nur eine Portnummer anzugeben. In diesem Fall verwendet Apache alle auf dem System konfigurierten IP-Adressen. Alternativ kann eine IP-Adresse getrennt durch einen Doppelpunkt von einer Portnummer verwendet werden. In diesem Fall wird nur die definierte IP-Adresse verwendet. Es können auch mehrere Listen Direktiven verwendet werden. Hier eine etwas komplexere Konfiguration für Listen:

Listen 127.0.0.1:80
Listen 217.11.53.10:80
Listen 217.11.53.11:80
Listen 217.11.53.11:443

Mit dieser Konfiguration verwendet der Apache den Port 80 auf den IP-Adressen 127.0.0.1 (Localhost), 217.11.53.10 und 217.11.53.11 und zusätzlich den Port 443 nur auf der IP-Adresse 217.11.53.11. Der normale Webserverport ist 80. Für SSL Anfragen muß ein anderer Port verwendet werden, dies ist im Normalfall Port 443. IPv6 Adressen müssen in eckige Klammern eingeschlossen werden, da diese selber Doppelpunkte enthalten. Apache 1.3 kennt kein IPv6, jedoch wurde der OpenBSD Apache, der auf Apache 1.3 beruht um IPv6 Funktionalität erweitert. Soll mit dem OpenBSD Apache eine IPv6 Adresse in Listen verwendet werden, darf diese jedoch nicht in eckigen Klammern stehen, sondern muß statt des Doppelpunktes durch einen Leerschritt von der Portnummer getrennt werden.

Mit dieser minimalen Konfiguration läßt sich ein Apache zwar betreiben, aber es fehlen noch zahlreiche Features, die normalerweise von einem Webserver erwartet werden. Wird mit dieser Konfiguration versucht ein HTML-Dokument vom Webserver abzurufen, wird im Browser das HTML-Dokument als einfacher Text angezeigt und die HTML-Tags werden nicht interpretiert, sondern ausgegeben. Die Ursache dafür ist der fehlende Mime-Type der dem Client mitgeteilt werden muß. Für diesen Zweck wird der Apache mit einer Datei mime.types ausgeliefert, in der die gängisten Mime-Types bereits vordefiniert sind. Damit der Apache korrekte Mime-Types an die Clients beim ausliefern von Dokumenten angibt, muß zusätzlich ein Modul des Apache geladen werden. Viele Funktionen des Apache sind in Module ausgelagert. Dadurch bleibt der Kernserver sehr schlank und es müssen nur die Module geladen werden, die tatsächlich benötigt werden. Eine ganze Reihe solcher Module werden mit dem Apache zusammen ausgeliefert. Beim selbstkompilieren des Apache, kann es sein, das einige Module bereits fest einkompiliert wurden, so das diese nicht extra geladen werden müssen. Mit dem Kommando httpd -l listet der Apache alle fest einkompilierten Module auf. Bei fertigen Paketen, sind meistens alle Module separat und nicht in das Apache-Binary fest einkompiliert. In diesem Fall müssen die Module erst geladen werden um die jeweilige Funktion zu nutzen. Das Laden eines Moduls geschieht mit der Direktive LoadModule. Diese Direktive erwartet den Namen des Moduls und den Pfad auf das Modul.

Für das Mime-Modul kann das laden des Moduls beispielsweise so aussehen:

LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so

Das Mime-Modul hat den Namen mime_module. Der Pfad kann natürlich je nach System anders sein. Der hier gezeigte Pfad ist korrekt auf einem Debian Linux 6.0 System. Sobald ein Modul geladen wurde, steht die entsprechende Funktionalität zur Verfügung und die damit verbundenen Konfigurationsdirektiven können verwendet werden. Für das Mime-Modul ist dies vor allem die Angabe wo die Datei mit den Mime-Typen liegt, sowie eine Angabe welcher Mime-Typ verwendet werden soll, wenn er nicht bekannt ist:

TypesConfig /etc/mime.types
DefaultType text/plain

Mit TypesConfig wird die Datei mit Zuordnungen der Mime-Tyen definiert. Hierfür sollte die vordefinierte Datei verwendet werden. Diese Datei sollte nicht von Hand abgeändert werden, da sie bei Updates des Apache überschrieben wird. Möchte man eigene Mime-Typ Definitionen hinzufügen, existiert eine eigene Konfigurationsdirektive mit der dies innerhalb der httpd.conf möglich ist. Die Datei enthält pro Zeile eine Mime-Definition in der jeweils am Zeilenanfang der Mime-Typ steht und dahinter die Dateiendungen, für die dieser Mime-Typ gilt. Mit DefaultType wird der Mime-Typ definiert, der verwendet wird, wenn der Mime-Typ nicht festgestellt werden konnte.

Hat man die Konfiguration des Apache verändert, muß die Konfigurationsdatei neu geladen werden, was ein apachectl graceful erledigt. Generell ist ein apachectl graceful für die meisten Konfigurationsänderungen ausreichend. Lediglich, wenn eine SSL-Konfiguration hinzugefügt wurde oder wenn die Listen Direktive geändert wurde ist ein apachectl restart notwendig.

Nach dieser Veränderung sollte der Versuch ein HTML-Dokument vom Server abzurufen das gewünschte Ergebnis zeigen, so daß das Dokument als HTML, statt als reiner Text angezeigt wird.

Soll ein zusätzlicher Mime-Typ in die Serverkonfiguration aufgenommen werden, welche nicht in der mit TypesConfig definierten Datei vorkommt, wird die Direktive AddType verwendet. Die Syntax ist AddType Mimetype Dateiendung. Ein Beispiel:

AddType application/x-iso-image .iso

Ruft ein Nutzer eine Domain oder Verzeichnis auf, ist er gewohnt direkt eine Seite angezeigt zu bekommen. Für diesen Zweck ist auf dem Webserver ein bestimmter Dokumentname definiert, der angezeigt wird, wenn ein Verzeichnis, statt eines Dokumentes angefordert wird. Für diese Konfiguration hat der Apache wiedderum ein Modul:

LoadModule dir_module /usr/lib/apache2/modules/mod_dir.so
DirectoryIndex index.html index.htm default.html default.htm

Zuerst muß wieder das Modul geladen werden. Danach kann die Konfigurationsdirektive DirectoryIndex verwendet werden. DirectoryIndex definiert welche Dateien in einem Verzeichnis angezeigt werden, wenn das Verzeichnis, statt einer bestimmten Datei angefordert wurde. Meist ist dies index.html. Es können auch mehrere Dateien angegeben werden. Existiert die erste angegebene Datei nicht in dem Verzeichnis, wird die Zweite gesucht, existiert diese auch nicht, wird die Dritte gesucht und so weiter.

Sollte in einem Verzeichnis keine der mit DirectoryIndex definierten Dateien liegen, wird eine Fehlermeldung zurück geliefert. Möchte man stattdessen das Verzeichnislisting anzeigen lassen, so ist dies über ein weiteres Apache Modul möglich:

LoadModule autoindex_module /usr/lib/a2modules/mod_autoindex.so

Sobald das Modul autoindex_module geladen ist, werden Verzeichnislistings automatisch generiert. Mit der Direktive ServerSignature kann definiert werden, das an servergenerierte Dokumente wie etwa Verzeichnislistings eine Fußzeile angehängt wird, in der der Server einige Informationen preisgibt, wie etwa seine Versionsnummer. Die möglichen Werte für ServerSignature sind On, Off und Email. Wird Email verwendet, muß zusätzlich über die Direktive ServerAdmin eine Emailadresse des zuständigen Webmasters der Webseite angegeben werden. Diese Emailadresse wird dann ebenfalls in die Fußzeile eingefügt. Ein Beispiel:

ServerAdmin webmaster@example.net
ServerSignature Email

Die Direktive ServerTokensbestimmt ebenfalls wieviele Informationen der Server über sich selbst verrät. ServerTokens bezieht sich jedoch nicht auf eine Fußzeile in servergenerierten Dokumenten, sondern auf den HTTP Header der an Clients zurück gesendet wird. In diesem Header gibt sich der Apache als Serversoftware zu erkennen. In welchen Umfang dies geschieht, bestimmt der Wert von ServerTokens. Nicht alle Werte werden von allen Apache Versionen unterstützt. Mögliche Werte zeigt die folgende Tabelle.

Mögliche Werte für ServerTokens
Wert	Apache Versionen	Beispielausgabe
Minimal	alle	Apache/2.0.41
OS	alle	Apache/2.0.41 (Unix)
Full	alle	Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
ProductOnly	ab 1.3.12	Apache
Major	ab 2.0	Apache/2
Minor	ab 2.0	Apache/2.0

Wenn ServerTokens nicht angegeben ist, ist der Standardwert Full, im OpenBSD Apache, ist der Standardwert ProductOnly. Ab Version 2.0.44 steuert diese Direktive auch gleichzeitig die Menge an Informationen, die in einer durch ServerSignature erzeugten Fusszeile zu finden ist.

Eine der wesentlichen Unterschiede zwischen Apache 1.3 und Apache 2 ist die Regulierung der Serverbelastung. Der Apache-Webserver reagierte bis Version 1.3 grundsätzlich auf zusätzliche Clientanfragen, indem er neue Apache-Prozesse forkte. Jeder Apache-Prozess ist in der Lage eine Client-Anfrage auf einmal zu beantworten. Der Server hält, um auf neue Anfragen zu antworten, ein gewisse Anzahl von Prozessen auf Vorrat. Übersteigt die Menge der Anfragen einen kritischen Wert, werden weitere Apache-Prozesse erzeugt. Mit Apache 2 wurden zusätzliche Modelle für die Verarbeitung von Serveranfragen eingeführt. Dadurch konnte auch Windows (welches Thread-orientiert und nicht Prozessorientiert arbeitet) in die Liste der unterstützten Betriebssysteme aufgenommen werden. Unter Unix wird seit Apache 2 im wesentlichen 2 Arten der Prozessverarbeitung verwendet: Das Prefork Modell entspricht dem alten aus Apache 1.3 bekannten Modell. Das Worker Modell stellt eine Mischung aus Prozessorientierung und Threadorientierung dar. Beim Worker-Modell können mehrere Anfragen durch den gleichen Prozess (in separaten Threads dieses Prozesses) abgearbeitet werden. Dies führt dazu, daß der Apache Webserver bei vielen Anfragen weniger Prozesse und damit auch weniger Arbeitsspeicher benötigt. Das Worker-Modell ist daher auch für stark belastete Websites besser geeignet. Welches dieser Modelle verwendet wird, kann nicht durch die Konfiguration bestimmt werden, sondern muß beim kompilieren festgelegt werden. Ein bestimmtes Apache-Binary ist auf ein Prozess-Modell festgelegt. Diese Prozess Modelle werden als Multi-Processing Modules, kurz MPM bezeichnet.

Für alle MPMs existieren Konfigurationsdirektiven die beeinflussen wie die Serverbelastung genau verarbeitet wird. Die Direktiven für das Prefork MPM sind dabei auch auf Apache 1.3 anwendbar, während andere Direktiven nur in Apache 2 funktionieren. Ein Beispiel für das Prefork MPM:

StartServers 10
MaxClients 150
MinSpareServers 10
MaxSpareServers 15

Mit StartServers wird definiert wieviele Apache Server Prozesse beim starten des Apache erzeugt werden sollen. Startet man Apache wird man feststellen, daß es genau einen Apache Prozess mehr gibt, als hier angegeben wird. Dies hängt damit zusammen, das es einen Kontrollprozess gibt, der mit root-Rechten läuft, selber aber nicht auf Netzwerkanfragen antwortet. Alle anderen Prozesse laufen unter dem in der Konfigurationsdatei festgelegten Benutzer und bedienen Clientanfragen. Mit MaxClients wird festgelegt, wieviele Clientanfragen gleichzeitig maximal verarbeitet werden. Übersteigt die Anzahl der gleichzeitigen Anfragen diesen Wert, werden weitere Anfragen nicht mehr bedient. Dies soll verhindern, das der Server unter der Last der Anfragen zusammenbricht. Mit MinSpareServers wird definiert, wieviele Prozesse der Apache mindestens in Reserve halten soll um auf neue Clientanfragen zu reagieren. Meistens wird dieser Wert identisch gesetzt, wie StartServers. Mit MaxSpareServers wird definiert, wieviele Prozesse maximal laufen dürfen, ohne das diese gerade beansprucht werden. Laufen mehr Prozesse im System ohne das diese etwas zu tun haben, werden die überschüssigen Prozesse beendet.

Folgendes ist ein Beispiel für das Worker MPM:

StartServers 5
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25

Die Direktiven StartServers und MaxClients werden beim Worker MPM mit identischer Bedeutung, wie beim Prefork MPM verwendet. Allerdings kann der Wert für StartServers niedriger gewählt werden, da jeder Prozess nun mehrere Clientanfragen auf einmal abarbeiten kann. Die Direktive MinSpareThreads definiert wieviele Threads (nicht Prozesse) minimal in Reserve bereit gehalten werden. Mit MaxSpareThreads wird definiert wieviele Threads maximal untätig in Reserve sein dürfen. Mit ThreadsPerChild wird definiert wieviele Threads ein Prozess hat. Welche Werte hier sinnvoll sind, hängt von der Leistungsfähigkeit der verwendeten Hardware und der erwarteten Belastung ab.

Apache kennt auch sogenannte Container-Direktiven. Solche Direktiven sehen wie HTML-Tags aus und fassen Konfigurationsdirektiven, die nur für einen bestimmten Bereich gelten sollen zusammen. Die am häufigsten verwendete Containerdirektive ist <Directory>. Konfigurationsdirektiven die innerhalb von <Directory /verzeichnis> und </Directory> stehen, gelten nur für das Verzeichnis /verzeichnis. Dabei können natürlich nicht alle Anweisungen in solchen Containern stehen. Anweisungen wie etwa ServerRoot und Listen machen nur global Sinn. Neben dem <Directory> Container existiert auch noch der <Location> Container. Beide dienen dazu Konfigurationen nur auf bestimmte Verzeichnisse mitsamt ihren Unterverzeichnissen anzuwenden. Der Unterschied zwischen beiden besteht in der Art der Verzeichnisdefinition: Die Verzeichnisangabe in einem <Directory> Container bezieht sich auf das reale Dateisystem des Servers. Die Verzeichnisdefinition eines <Location> Containers bezieht sich hingegen auf den Verzeichnispfad so wie er von Clients im Web gesehen wird. Die Auflösung eines Pfades für einen <Location> Container geschieht dabei auch immer nach der Auflösung eventueller Umleitungsregeln, was bei Pfaden für die <Directory> Direktive nicht der Fall ist.

Ein Beispiel für einen <Directory> Container:

<Directory /var/www>
Options FollowSymLinks
<Directory>

Der Inhalt dieses <Directory> Containers gilt für das Verzeichnis /var/www. Die hier verwendete Konfigurationsdirektive Options steuert welche Funktionen in einem Verzeichnis zur Verfügung stehen. Die Options Direktive kennt die Werte all, Includes, Indexes, ExecCGI, FollowSymLinks, SymLinksIfOwnerMatch, IncludesNoExec und MultiViews. Die Standardeinstellung ist all, welches alle Funktionen mit Ausnahme von Multiviews einschaltet. Die folgende Tabelle erklärt die einzelnen Werte.

Mögliche Werte der Options Direktive
Wert	Bedeutung
all	Schaltet alle Werte mit Ausnahme von Multiviews ein.
Indexes	Dies erlaubt Verzeichnisindexe für ein Verzeichnis.
Includes	Schaltet die Verwendung von Server Side Includes (SSI) ein.
IncludesNoExec	Schaltet Server Side Includes (SSI) ein, verbietet jedoch die exec cgi und exec cmd Includes.
ExecCGI	Erlaubt die Ausführung von CGI Scripts.
FollowSymLinks	Erlaubt es dem Webserver symbolischen Links zu folgen. Dabei können auch Dateien angezeigt werden, die sich außerhalb des DocumentRoot befinden.
SymLinksIfOwnerMatch	Erlaubt es dem Webserver symbolischen Links zu folgen, aber nur dann wenn der Eigentümer des symbolischen Links identisch ist mit dem Eigentümer des Linkziels. Dies soll Sicherheitsprobleme vermeiden.
Multiviews	Dies erlaubt sogenannte Multiviews, welche bei der sogenannten Content Negotiation verwendet werden.

Es können auch mehrere Werte in einer Zeile für Options angegeben werden. Die Werte werden jeweils durch Leerzeichen getrennt. Ein weiteres Beispiel der Verwendung von Options:

<Directory /var/www/htdocs>
Options SymLinksIfOwnerMatch Indexes IncludesNoExec
</Directory>

Neben den <Directory> Containern und den <Location> Containern, existieren auch <Files> Container. Definitionen die in einem <Files> Container stehen, gelten nur für die angegebenen Dateien. Ein Beispiel:

Die Definitionen die in diesem <Files> Container stehen (in diesem Beispiel ist nichts angegeben) gelten nur für Dateien mit dem Namen README. Manchmal möchte man für alle Dateien mit einer bestimmten Endung oder alle Dateien die mit einem bestimmten Namensteil anfangen Konfigurationsdirektiven setzen. In diesem Fall läßt sich statt <Files> einfach <FilesMatch> verwenden, welches auch reguläre Ausdrücke im Dateinamen versteht. Ein Beispiel:

Dieser Container paßt auf alle Dateien deren Dateiname auf .gif endet.

Der <Files> Container versteht die beiden Wildcardzeichen ? und *, wobei das ? für ein beliebiges Zeichen und der * für eine beliebige Folge von Zeichen steht.

Tritt ein Fehler auf, also bei einem HTTP Statuscode von 4xx oder 5xx, kann der Apache eine eigene Fehlerseite anzeigen. Dies wird mit ErrorDocument konfiguriert. Hinter dieser Direktive muß ein HTTP Statuscode und entweder ein Fehlertext oder eine HTML-Seite folgen. Ein Beispiel:

ErrorDocument 403 http://www.example.com/verboten.html
ErrorDocument 404 /error404.html
ErrorDocument 500 "Interner Server Fehler aufgetreten"

Das erste Beispiel ruft ein externes Dokument auf. Das zweite Beispiel zeigt ein lokales Dokument an. Der Pfad auf dieses Dokument wird relativ zum DocumentRoot betrachtet. Das dritte Beispiel zeigt einen einfachen Fehlertext an. Die Syntax dafür hat sich zwischen Apache 1.3 und Apache 2.0 geändert. Unter Apache 1.3 wurde nur das öffnende Anführungszeichen verwendet, um einen Fehlertext anzuzeigen. Seit Apache 2.0 wird das Anführungszeichen am Ende des Textes auch geschlossen.

Der Microsoft Internet Explorer zeigt servergenerierte Fehlerseiten nur an, wenn diese nicht zu kurz sind. Damit die servergenerierten Fehlerseiten sicher angezeigt werden, sollten diese mindestens 512 Byte lang sein.

Ein weiteres Modul des Apache ist mod_alias. Mit diesem Modul lassen sich Dateipfade verändern. Normalerweise werden Urlpfade, wie sie der Client sieht, so gebildet, wie auch die Verzeichnisstruktur auf dem Server relativ zum DocumentRoot ist. Mit Aliasen kann ein Urlpfad für eine Datei oder ein Verzeichnis gebildet werden, das unter diesen Namen nicht existiert. Zuerst muß dazu das Modul geladen werden:

LoadModule alias_module /usr/lib/apache2/modules/mod_alias.so

Anschließend läßt sich die Direktive Alias verwenden. Alias erwartet einen Url-Pfad und einen realen Pfad. Ruft ein Client den Urlpfad auf, wird der Inhalt der unter den angegebenen realen Pfad liegt angezeigt. Ein Beispiel:

Alias /icons /usr/share/pixmaps

Ruft ein Client den Pfad /icons auf dem Server auf, wird der Inhalt von /usr/share/pixmaps angezeigt. Die Pfade können dabei sowohl Verzeichnisse, als auch einzelne Dateien sein. Wird bei einem Verzeichnis der abschließende Schrägstrich mit angegeben, dann greift der Alias nur, wenn auch der Client diesen Schrägstrich mit angibt.

Wird ein servergeneriertes Verzeichnislisting angezeigt, dann sieht ein Client mit der bisher besprochenen Konfiguration nur eine simple Liste von Dateinamen die sich in dem Verzeichnis befinden. Der Apache Webserver kann jedoch auch schönere Verzeichnislistings erzeugen, welche auch Eigenschaften zu einer Datei anzeigen und auch ein Icon zu jeder Datei. Diese Verzeichnislistings werden mit der Direktive IndexOptions gesteuert. IndexOptions kennt sehr viele Werte. Um aber einfach ein schöneres Verzeichnislisting zu erzeugen genügt die folgende Angabe:

IndexOptions FancyIndexing

Dies erzeugt ein Verzeichnislisting mit der Angabe zusätzlicher Dateieigenschaften für jede Datei.

Sollen auch Icons für Dateien angezeigt werden, muß der Server wissen welche Icons für welchen Dateityp verwendet werden sollen. Entsprechende Icongrafiken müssen dazu auf dem Server vorhanden sein (eine Reihe von Icons werden mit dem Apache mitgeliefert). Um Mimetypen einem Icon zuzuordnen, gibt es die Direktive AddIconByType. Diese Direktive erwartet die Angabe eines Alternativtextes und des Pfades auf eine Icondatei in Klammern und dahinter den Mimetype für den dieses Icon gelten soll. Der Alternativtext wird in das "alt" Attribut des img-Tags eingesetzt und beispielsweise auf Textbrowsern, die das grafische Icon nicht darstellen können angezeigt. Ein Beispiel:

AddIconByType (IMG,/icons/image.png) image/*
AddIconByType (TXT,/icons/text.png) text/plain

Im ersten Beispiel soll für alle Dateien deren Mimetyp mit image/ anfängt, also alle Grafikdateien, das Icon /icon/image.png angezeigt werden. Als Alternativtext wird "IMG" verwendet. Der * beim Mimetyp steht hier als Platzhalter, so das eine ganze Gruppe von Mimetypen zusammengefaßt werden kann. Der Pfad auf die Icondatei wird immer vom Browser aus gesehen, ist also relativ zum DocumentRoot und nach Auflösung eventueller Aliase. Das zweite Beispiel soll für Dokumente vom Typ Plaintext (text/plain), das Icon unter dem Pfad /icon/text.png anzeigen. Der Alternativtext ist "TXT".

Es ist auch möglich Icons einem festen Dateinamen zuzuordnen. Dies erledigt die Direktive AddIcon. Mit AddIcon wird ein Icon keinem Mimetyp sondern einem Dateinamen oder Teil eines Dateinamens zugeordnet. Die Syntax ist ähnlich wie die von AddIconByType, nur das statt des Mimetypes ein Dateiname, ein Teil eines Dateinamens mit Wildcardzeichen, eine Endung oder die Zeichenkette ^^DIRECTORY^^ angegeben wird. Die Zeichenkette ^^DIRECTORY^^ ermöglicht es, Verzeichnissen ebenfalls ein Icon zuzuordnen. Ein Beispiel:

AddIcon (IMG,/icon/image.png) .gif .png .jpg
AddIcon (DIR,/icon/dir.png) ^^DIRECTORY^^

Das erste Beispiel weist allen Dateien die auf eine der Endungen .gif, .png oder .jpg enden, ein Icon zu. Das zweite Beispiel weist Verzeichnissen ein Icon zu. Die Apache Dokumentation empfiehlt nach Möglichkeit der Direktive AddIconByType den Vorzug gegenüber AddIcon zu geben, sofern möglich.

Mit der Direktive HeaderName kann ein Dateiname angegeben werden, welcher sich innerhalb des Verzeichnisses für daß das Listing angezeigt wird, befindet. Die Datei muß Text enthalten. Existiert diese Datei in einem Verzeichnis für welches ein Listing generiert wird, dann wird der Text oberhalb des Verzeichnislistings angezeigt. Dies ermöglicht es zusätzliche Informationen zu einem Verzeichnislisting anzugeben.

Der Apache Webserver ist auch in der Lage Teile seiner Konfiguration in eigene Dateien auszulagern. Hierfür existieren 2 sehr unterschiedliche Möglichkeiten: Zum einen lassen sich in der Konfigurationsdatei weitere Konfigurationsdateien durch die Direktive Include einbinden. Include erwartet einen Dateinamen. Dabei können auch Wildcardzeichen verwendet werden. Jede Datei die mit Include geladen wird, wird wie ein Bestandteil der Hauptkonfigurationsdatei behandelt. Dieser Mechanismus wird oft verwendet um die httpd.conf in mehrere Dateien aufzuspalten, die für unterschiedliche Bereiche der Konfiguration gedacht sind.

Eine ganz andere Art der Auslagerung von Konfigurationsanweisungen kann über .htaccess Dateien erreicht werden. Diese Dateien liegen direkt im Webspace und können prinzipiell alle Konfigurationsanweisungen aufnehmen, welche auch in einem <Directory> Container stehen können. Anweisungen in einer solchen Datei gelten für das Verzeichnis in dem diese liegt und alle Unterverzeichnisse. Traditonellerweise heißt diese Datei .htaccess. Allerdings kann über die Direktive AccessFilename auch ein anderer Dateiname definiert werden.

Dieser Mechanismus erlaubt es Nutzern eines Webservers, die ihre Dateien zum Beispiel per FTP selbst pflegen können, Konfigurationsdirektiven abzuändern. Dies wird oft für einen Zugriffsschutz verwendet, kann aber auch verwendet werden um zum Beispiel eigene Fehlerseiten zu generieren. Da diese Konfigurationsmöglichkeiten relativ weitreichend sind, kann der Administrator des Systems diese Möglichkeiten aus Sicherheitsgründen begrenzen. Zu diesem Zweck existiert die Direktive AllowOverride. Diese bestimmt, welche Konfigurationsdirektiven innerhalb einer .htaccess Datei verwendet werden können. Die möglichen Werte für AllowOverride zeigt folgende Tabelle:

Mögliche Werte für AllowOverride
Wert	Bedeutung
Indexes	Erlaubt die Verwendung von Direktiven die Verzeichnisindexes steuern, wie etwa DirectoryIndex, AddIconByType oder IndexOptions.
AuthConfig	Erlaubt die Verwendung von Direktiven um Verzeichnisse mit einem Paswortschutz zu versehen.
FileInfo	Erlaubt die Verwendung von Direktiven zur Steuerung des Dokumententyps, wie etwa DefaultType oder ErrorDocument.
Limit	Erlaubt die Verwendung von Direktiven zur Steuerung des Zugriffs von Hosts, wie etwa Allow und Deny.
Options	Erlaubt die Verwendung der Options Direktive. Dies sollte nur erlaubt werden, wenn allen Benutzern vertraut wird.
All	Erlaubt die Verwendung aller Direktiven die im Verzeichniskontext verwendet werden können.
None	Erlaubt keine Direktiven. In diesem Fall sucht der Server nicht mehr nach .htaccess Dateien, was auch einen Performance Vorteil bringen kann.

AllowOverride darf nur innerhalb von <Directory> Containern benutzt werden. Es können auch mehrere Werte auf einer Zeile angegeben werden. Ein Beispiel:

AllowOverride AuthConfig FileInfo Indexes

Logfiles

Die bereits gezeigte Direktive ErrorLog legt die Datei zum speichern von Fehlermeldungen fest. Mit der Direktive LogLevel wird definiert, wie ausführlich das Fehler-Log sein soll. Mögliche Werte entsprechen den Priorities des Syslog-Dienstes:

debug: Debug Meldungen zur Fehleranalyse.
info: Informative Meldungen.
notice: Meldungen die beachtet werden sollten, aber keine Fehler darstellen.
warn: Warnungen.
error: Fehlermeldungen.
crit: Kritischer Fehler.
alert: Fehlermeldungen die sofortige Maßnahmen erfordern.
emerg: Fehler durch den das System nicht mehr funktionsfähig ist.

Weniger kritische Priorities schließen Meldungen der kritischeren Priorities immer mit ein. Der Standardwert für LogLevel ist warn.

Neben Fehlermeldungen, kann Apache auch Zugriffe loggen. Dies ermöglicht statistische Auswertungen der Zugriffe auf die Webseiten. Die Konfiguration von Zugriffslogs erfordert das Modul mod_log_config, welches jedoch fast immer in den Apache einkompiliert wird und daher nicht extra geladen werden muß. Mit der Direktive TransferLog wird eine Datei bestimmt, in der die Zugriffe protokolliert werden. Ein Beispiel für eine vollständige Konfiguration des Loggings (Fehler- und Zugriffslog):

ErrorLog /var/log/apache2/error.log
LogLevel warn
TransferLog /var/log/apache2/access.log

Das Format des Zugriffslogs entspricht dem sogenannten Common Format. Jede Zeile des Zugriffslogs entspricht einem einzelnen Zugriff auf ein Dokument. Da eine HTML-Seite meist aus mehreren Dateien besteht (eigentliche HTML-Seite, CSS Datei, Grafiken) löst der Zugriff auf eine Webseite meist mehrere Einträge ins Zugriffslog aus. Eine Zeile im Zugriffslog kann zum Beispiel so aussehen:

10.1.0.3 - - [17/May/2011:10:19:31 +0200] "GET / HTTP/1.1" 200 985

Am Anfang der Zeile steht die IP Adresse des Clients. Dahinter kommen 2 Bindestriche. Der erste Bindestrich steht für einen über eine ident-Anfrage ermittelten Benutzernamen. Da ident-Abfragen nicht mehr benutzt werden, steht hier immer ein Bindestrich. Der zweite Bindestrich steht für einen Benutzernamen, der aufgrund einer HTTP-Authentifizierung ermittelt wurde. Wurde solch eine Authentifizierung durchgeführt, taucht hier der Benutzername auf, sonst der Bindestrich. Anschließend folgt der Zeitpunkt des Zugriffs. Dabei wird auch die Zeitzone mit angegeben (in diesem Fall + 2 Stunden Abweichung zur Koordinierten Weltzeit UTC). Anschließend folgt in Anführungszeichen die gesamte erste Zeile der Abfrage, welche die Abfrageart (GET oder POST) enthält, anschließend das angefragte Dokument (in diesem Fall einfach /, was dem Wurzelverzeichnis entspricht) und die HTTP-Version. Anschließend wird der zurück gegebene HTTP-Statuscode angegeben (hier 200) und zuletzt die Länge des ausgelieferten Dokumentes in Byte.

Die Menge an zurück gelieferten Informationen im Common Logformat ist leider etwas begrenzt. 2 Angaben die viele Webmaster zusätzlich interessiert fehlen: Der verwendete Useragent (Browser) und der sogenannte Referer. Der Referer ist die Angabe von welcher vorangegangenen Webseite ein Besucher kommt. Diese Information wird ebenso wie der sogenannte Useragent, der den Browser spezifiziert von den meisten Browsern mit übertragen. Tatsächlich bietet Apache an, Logdateien in beliebigen Formaten zu erstellen. Neben dem Common Format hat sich daher auch das sogenannte Combined Format durchgesetzt, das auf dem Common Format aufbaut, die selben Informationen enthält und zusätzlich noch den Referer und den Useragent als zwei weitere Angaben, hinter den Angaben des Common Formats. Ein anderes Format für die Logdatei wird mit der Direktive LogFormat definiert. Die Syntax für LogFormat sieht so aus: LogFormat formatbeschreibung name. Die Formatbeschreibung innerhalb von LogFormat kennt eine Reihe von Variablen die mit dem %-Zeichen anfangen. Die wichtigsten listet die folgende Tabelle auf. Eine vollständige Übersicht findet sich in der Apache Dokumentation

Variablen für LogFormat
Variable	Beschreibung.
%a	IP Adresse des Clients.
%h	Hostname des Clients, falls keine Namensauflösung möglich ist, die IP Adresse.
%l	Von identd zurückgelieferter Nutzername.
%u	Benutzername aufgrund einer HTTP Authentifizierung.
%t	Zeitangabe.
%r	Erste Zeile des Requests.
%s	HTTP Statuscode. Falls interne Umleitungen greifen ist dies der originale Statuscode, wenn stattdessen %>s verwendet wird ist dies der letzte HTTP Statuscode.
%b	Größe in Bytes des zurück gelieferten Dokumentes. HTTP-Header werden nicht mit eingerechnet. Wenn nichts zurück gegeben wurde ein -.
%{Foobar}i	Der Inhalt des HTTP-Headers Foobar der vom Client an den Server gesendet wurde. Dies wird zum Beispiel für den Referer (%{Referer}i) und für den Useragent (%{User-agent}i) verwendet.
%{format}t	Eine Zeitangabe die so formatiert wurde wie es format angibt. Die Angabe für die Formatierung wird entsprechend der Systemfunktion strftime vorgenommen.
%U	Die vom Client angefragte Url.
%m	Die Anfragemethode.
%v	Der Servername (laut der ServerName Direktive)

Die Direktive TransferLog verwendet immer das zuletzt mit der Direktive LogFormat angegebene Format. Wurde LogFormat nicht benutzt, wird das Common Format verwendet. Die Definition des Combined Formats mit LogFormat sieht so aus:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined

Da die Formatdefinition selbst in Anführungszeichen steht, müssen Anführungszeichen die innerhalb der Formatdefinition vorkommen mit einem Backslash versehen werden um sie zu maskieren. Die Angabe muß auf einer Zeile stehen und wird hier nur aus Platzgründen umgebrochen.

Statt die Direktive TransferLog unmittelbar nach einer LogFormat Direktive zu verwenden, kann auch stattdessen die Direktive CustomLog verwendet werden, die zusätzlich zu einer Datei noch den Namen einer LogFormat Formatierung erwartet. Dadurch kann eine beliebige vorher getätigte Formatdefinition gewählt werden. Im folgenden Beispiel werden zuerst 2 Logformate erstellt (die Logformate entsprechen den beiden Standardformaten common und combined) und anschließend ein Logformat mit CustomLog verwendet:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog /var/log/apache2/access.log combined

Bei der Verwendung angepasster Logformate sollte bedacht werden, daß viele Auswertungstools, wie etwa webalizer nur mit Logdateien im Common oder im Combined Format umgehen können.

Logfiles werden mit der Zeit immer größer. Um ein volllaufen der Festplatte mit Logdateien zu vermeiden, werden diese in regelmäßigen Abständen rotiert, das heißt alte Logdateien, werden unter neuen Namen kopiert und eine neue Logdatei wird angefangen. Nach mehrmaligen kopieren unter neuen Namen werden alte Logdateien irgendwann ganz gelöscht. Logfilerotation wird nicht vom Apache selbst erledigt. Die meisten Betriebsysteme haben hierfür ein eigenes Programm wie etwa logrotate oder newsyslog, welches sich auch um die Apache Logfiles kümmern muß.

Zugriffsbeschränkungen

Der Apache Webserver kennt auch einige Direktiven um den Zugriff auf bestimmte Dokumente oder Verzeichnisse zu beschränken, bzw. mit einem Passwort zu versehen. Grundsätzlich gibt es 2 Arten von Zugriffsbeschränkungen: Zugriffsbeschränkungen von Hosts und Zugriffsbeschränkungen von Benutzern, die sich per Passwort ausweisen müssen. Benutzeranmeldungen mit Passwörtern können auf 2 verschiedene Arten erfolgen: Über die Basic oder die Digest Anmeldung. Die Basic Anmeldung ist simpel und wird von allen Browsern unterstützt. Bei der Basic Authentifizierung wird das Passwort jedoch im Klartext durch die Leitung gesendet. Die Digest Authentifizierung benutzt keine Klartextpasswörter, sondern ein sogenanntes Challenge-Response Verfahren, welches sicher stellt, das keine Passwörter auf dem Übertragungsweg abgefangen werden können. Die Digest Authentifizierung ist daher sicherer. Leider verstanden viele Browser die Digest Authentifizierung lange Zeit nicht. Die meisten modernen Browser sind inzwischen jedoch in der Lage eine Digest Authentifizierung durchzuführen, so das auch diese inzwischen sinnvoll im Web genutzt werden kann. Die Nutzdaten werden auch bei der Digest Authentifizierung im Klartext übertragen, da diese nur das Passwort schützt. Für eine vollständige Verschlüsselung kann SSL genutzt werden, welches auch die Nachteile der Basic Authentifizierung kompensiert.

Beide Authentifizierungsmechanismen können auf verschiedene Passwortbackends zugreifen. Häufig wird eine Textdatei als Passwortdatei benutzt. Alternativ kennt Apache jedoch auch Module ein LDAP-Verzeichnis oder eine Datenbank als Passwortbackend zu benutzen.

Für die unterschiedlichen Authentifizierungsarten des Apache sind jeweils unterschiedliche Module notwendig. Unter Apache 1.3 genügte für die Basic Authentifizierung mit Passwortdateien das Modul mod_auth. Die Unterstützung für Digest Authentifizierung im Apache 1.3 erfolgt durch das Modul mod_auth_digest Dieses Modul war als experimentell gekennzeichnet. Die Namen der Authentifizierungsmodule in Apache 2.0 entsprechen denen in Apache 1.3 (mod_auth und mod_auth_digest). Seit Apache 2.2 wurden die Module für die Authentifizierung komplett überarbeitet. In Apache 2.2 existieren eine ganze Reihe von Modulen für die Authentifizierung. Diese unterteilen sich nach Authentifizierungsart (Basic und Digest), dem Passwortbackend (zum Beispiel Datei oder Datenbank, diese Module beginnen mit authn_ im Namen) und der Art der Autorisierung (zum Beispiel Benutzerspezifisch oder Gruppenspezifisch, diese Module beginnen mit authz_ im Namen). Die Konfigurationsdirektiven um eine Basic Authentifizierung mit Passwortdateien in den Apacheversionen 1.3, 2.0 und 2.2 vorzunehmen sind dabei identisch, nur die jeweiligen Module sind in Version 2.2 anders.

Folgendes Beispiel lädt alle von Apache 2.2 für eine Basicauthentifizierung mit Passwortdateien benötigten Module und erstellt einen Passwortschutz für das Verzeichnis /var/www/htdocs/schutz. Im Fall von Apache 1.3 und 2.0 würde nur das Modul mod_auth geladen werden, der Rest der Konfiguration wäre jedoch identisch.

LoadModule auth_basic_module /usr/lib/httpd/mod_auth_basic.so
LoadModule authn_file_module /usr/lib/httpd/mod_authn_file.so
LoadModule authz_user_module /usr/lib/httpd/mod_authz_user.so

<Directory /var/www/htdocs/schutz>
AuthType basic
AuthName "Hier darf nicht jeder rein!"
AuthUserFile /etc/apache2/htpasswd
require valid-user
</Directory>

Mit AuthType wird der Typ der Authentifizierung, also Basic oder Digest angegeben. Mit AuthName wird ein Text angegeben, der in dem Passwortfenster, welches in einem Client angezeigt wird, erscheint. Das exakte Aussehen des Fensters zur Passworteingabe ist jedoch Clientspezifisch. Mit AuthUserFile wird der Pfad auf die Passwortdatei angegeben. Diese Datei sollte sich aus Sicherheitsgründen nicht im DocumentRoot befinden, da diese sonst downloadbar wäre. Mit require wird angegeben welche Benutzer aus der Passwortdatei das Verzeichnis betreten dürfen. Durch die Angabe valid-user dürfen alle in der Passwortdatei aufgeführte Benutzer, nachdem sie sich per Passwort authentifiziert haben, das Verzeichnis betreten. Alternativ läßt sich auch jeder erlaubte Benutzer mit seinem Benutzernamen, getrennt durch Leerschritte, auflisten.

Die benötigte Passwortdatei hat ein spezielles Format. Die Datei läßt sich durch das in Apache enthaltene Kommando htpasswd erzeugen:

htpasswd -c /etc/apache2/htpasswd user1

Dieses Kommando legt die Passwortdatei /etc/apache2/htpasswd als neue Datei an und darin den neuen Benutzer user1. Das Kommando wird interaktiv nach dem Passwort des neuen Benutzers fragen. Die Eingabe wird dabei nicht auf der Shell angezeigt und muß noch einmal wiederholt werden. Der Parameter -c erzeugt immer eine neue Passwortdatei und darf nicht verwendet werden, wenn die Datei schon existiert. Wird ein bereits existierender Benutzername angegeben, kann das Passwort für diesen Benutzer geändert werden. Die Passwortdatei sollte sich nicht nur außerhalb des DocumentRoot befinden, sondern sollte auch zusätzlich über restriktive Rechte geschützt werden. Der Apache Webserver selbst benötigt Leserecht auf diese Datei, um Benutzer authentifizieren zu können. Der Benutzer der die Passwörter verwaltet, benötigt auch Schreibrechte auf die Datei. Sollte der Benutzer der die Passwörter verwaltet über root-Rechte im System verfügen, sollte die Datei nur für root schreibbar und für die Gruppe unter der der Apache läuft lesbar sein. Alle anderen Benutzer sollten keine Rechte an der Datei haben.

Die Konfiguration für eine Digest-Authentifizierung mit Passwortdateien unter Apache 2.2 sieht so aus:

LoadModule auth_digest_module /usr/lib/httpd/mod_auth_digest.so
LoadModule authn_file_module /usr/lib/httpd/mod_authn_file.so
LoadModule authz_user_module /usr/lib/httpd/mod_authz_user.so

<Directory /var/www/htdocs/schutz>
AuthType digest
AuthName "Privat"
AuthDigestDomain /schutz/
AuthUserFile /etc/apache2/htdigest
require valid-user
</Directory>

Als Modul muß mod_auth_digest geladen werden. Die anderen Module bleiben gleich. AuthType muß natürlich auf digest stehen. Neu hinzu gekommen ist die Direktive AuthDigestDomain. Der Wert in dieser Direktive muß mit dem Pfad auf das Verzeichnis übereinstimmen, für welches der Verzeichnisschutz gilt. Dabei kann sowohl ein relativer Pfad verwendet werden, als auch eine vollständige http-Adresse. AuthUserFile und require bleiben in ihrer Verwendung identisch zur Basic-Autentifizierung. Allerdings hat die in AuthUserFile verwendete Datei ein anderes Format, so daß nicht dieselbe Datei, wie für die Basic-Authentifizierung verwendet werden kann. Der Wert der Direktive AuthName muß mit dem Realm, welcher in der Passwortdatei zusätzlich angegeben werden muß, übereinstimmen.

Die Passwortdatei wird mit dem Kommando htdigest erzeugt. Die Syntax ist ähnlich wie bei htpasswd, jedoch wird zusätzlich noch ein Realm benötigt:

htdigest -c /etc/apache2/htdigest Privat user1

Dies wird eine neue Passwortdatei anlegen (-c) und darin den Benutzer user1. Jeder Benutzer gehört auch einem Realm an, welcher identisch sein muß mit der jeweiligen Angabe für AuthName. Das Kommando fragt interaktiv nach dem Passwort des Benutzers. Existiert die Passwortdatei bereits, muß der Parameter -c weggelassen werden. Sowohl htpasswd, als auch htdigest verschlüsseln die Passwörter in den Passwortdateien.

Neben der Möglichkeit Benutzer zu authentifizieren, kann Apache auch Hosts, zum Beispiel anhand ihrer IP Adresse authentifizieren. Für die Host-Authentifizierung muß in Apache 1.3 und 2.0 das Modul mod_access geladen werden. In Apache 2.2 wird dafür das Modul mod_authz_host benötigt. Konfiguriert wird die Zugriffskontrolle in allen Versionen über die Direktiven Allow, Deny und Order. Hier ein Beispiel (ohne die Anweisung zum laden des Moduls):

<Directory /var/www/htdocs/verboten>
Allow from 10.0.8.0/24
Deny from 10.0.8.25
Order Allow,Deny
</Directory>

Die Direktiven Allow from und Deny from akzeptieren als Werte einzelne IP Adressen, Netzwerke in CIDR Schreibweise, Netzwerke die durch Netzwerkadresse und Subnetzmaske definiert werden (zum Beispiel 192.168.0.0/255.255.255.0) oder auch Hostnamen, die über DNS aufgelöst werden. Auch das Schlüsselwort all kann für alle Hosts verwendet werden. Die Direktive Allow erlaubt den Zugriff auf eine Ressource, die Direktive Deny verbietet ihn. Werden beide Angaben verwendet, definiert die Direktive Order die Reihenfolge der Abarbeitung. Steht Order auf Deny,Allow, werden erst die Deny Regeln ausgewertet und dann die Allow Regeln. Dabei gewinnt immer die letzte zutreffende Regel. Kommt ein Host also sowohl in einer Allow, als auch in einer Deny Regel vor, wäre dieser Host bei der Reihenfolge Deny,Allow erlaubt, bei Allow,Deny hingegen verboten. Kommt ein Host in keiner Regel vor, bestimmt die zuletzt bei Order definierte Aktion ob der Host zugreifen darf, im Falle von Allow,Deny wäre der Zugriff also verboten.

Zugriffsdirektiven lassen sich nicht nur auf Verzeichnisse anwenden, sondern zum Beispiel auch auf einzelne Dateien oder Muster von Dateinamen. Dadurch ist es zum Beispiel möglich Clients das herunterladen von .htacess Dateien zu verbieten:

<FilesMatch "^\.ht">
Order Allow,Deny
Deny from all
<FilesMatch>

Mit dieser Konfiguration wird der Zugriff von allen Hosts auf Dateien verboten, die mit dem Dateinamen ".ht" anfangen.

Sogar HTTP-Methoden lassen sich mit Zugriffsbeschränkungen versehen. Für HTTP-Methoden existieren die Containerdirektiven Limit und LimitExcept. Während Limit alle im Container gemachten Direktiven auf die genannten Methoden anwenden läßt, dreht LimitExcept dies um und läßt die Direktiven für alle außer den angegebenen Methoden gelten.

Auf einem normalen Webserver, machen Methoden außer GET und POST keinen Sinn, die meisten anderen HTTP-Methoden sind nur für Proxy-Server oder Webdav-Server interessant. Falls also Apache weder als Proxy- noch als Webdav-Server eingesetzt werden soll, können die anderen Methoden auch verboten werden:

<LimitExcept POST GET>
Order Allow,Deny
Deny from all
<LimitExcept>

Apache Webserver Teil 2

Literatur

Online-Dokumentation des Apache Projektes.

Andrew Ford, Sascha Kersken: Apache - kurz und gut. O'Reilly, 2007.

René Maroufi, dozent (at) maruweb.de