Zugriffsbeschränkung für Webserver

Auf dieser Seite möchten wir Ihnen zeigen, wie Sie Verzeichnisse, die über einen Apache Webserver zugänglich sind, mit einem Passwort schützen, so dass nur bestimmte Benutzer oder Benutzergruppen darauf Zugriff haben. Sie benötigen dafür einen Editor und einen SSH-Client.

Bitte lesen Sie die Abschnitte Allgemeine Hinweise zum Passwortschutz von Verzeichnissen, Vorbereitungen durch den Administrator und anschließend die Beschreibung zu einem der Authentisierungsmodule. Für weniger erfahrene Benutzer empfehlen wir Authentisierung mittels „mod_auth“. Bitte beachten Sie unbedingt auch den Abschnitt Sicherheitshinweise.

Allgemeine Hinweise zum Passwortschutz von Verzeichnissen
Vorbereitungen durch den Administrator
Passwortschutz mit „mod_auth“
Passwortschutz mit „mod_auth_pgsql“
Passwortschutz mit „mod_auth_mysql“
Passwortschutz mit „mod_auth_anon“
Passwortschutz mit „mod_auth_cookie“
Passwortschutz mit anderen Authentisierungsmodulen
Sicherheitshinweise

Allgemeine Hinweise zum Passwortschutz von Verzeichnissen

Die Funktionsweise der hier beschriebenen Authentisierungen – mit Ausnahme von „mod_auth_anon“ – beruht auf zwei Komponenten. Einerseits einer Datei mit Namen .htaccess (Bitte beachten Sie den Punkt vor dem „h“), die in dem zu schützenden Verzeichnis abgelegt wird. In dieser Datei wird spezifiziert, dass für das Verzeichnis (und alle Unterverzeichnisse) eine benutzerbasierte Zugriffsbeschränkung bestehend aus Benutzername und Passwort gilt. .htaccess bestimmt, welche Art der Authentisierung erfolgen soll, in welcher Datenbank Benutzer/Benutzergruppen und Passwörter zu finden sind und welche Benutzer oder Benutzergruppen Zugriff haben.

Andererseits wird eine Datenbank benötigt, die Benutzer- und evtl. Gruppennamen und Passwörter enthält. Der Webserver kann über verschiedene Module bei der Authentisierung auf unterschiedliche Datenbanken zugreifen. Die folgenden Erklärungen („Passwortschutz mit ...“) beziehen sich jeweils auf ein Authentisierungsmodul.

Hinweis: Sollten Sie Administratoren-Rechte für den Webserver haben, können Sie die Angaben der .htaccess Datei auch in der Server-Konfiguration (normalerweise der Datei httpd.conf) ablegen. Betten Sie dazu die Direktiven, die nachfolgend für .htaccess Dateien aufgeführt werden, in einen entsprechenden <Directory>...</Directory> Block ein. Die Apache Dokumentation spricht sich für Benutzer mit Administratoren Rechten gegen die Verwendung von .htaccess Dateien aus.

Vorbereitungen durch den Administrator

Um einen Passwortschutz mit Hilfe einer .htaccess Datei überhaupt zu ermöglichen, muss der Administrator des Webservers dies für das entsprechende Verzeichnis zulassen. Dies geschieht in der Konfigurationsdatei des Webservers mit folgendem Eintrag:

<Directory /home/server/www/schutz/>
    AllowOverride AuthConfig
</Directory>

Anstelle des orange gesetzten Eintrags muss das Verzeichnis stehen, für das der Passwortschutz realisiert werden soll. Bitte beachten Sie, dass mit dieser Anweisung auch die Verwendung von .htaccess Dateien zur Authentisierung in allen Unterverzeichnissen gestattet. Weitere Hinweise in englischer Sprache finden Sie in der Apache Dokumentation.

Sollten Sie nicht über die Rechte zur Änderung der allgemeinen Webserver-Konfiguration verfügen, bitten Sie den entsprechenden Administrator dies für Sie einzurichten.

Passwortschutz mit „mod_auth“

Dieses Modul verwendet einfache ASCII-Dateien, sog. flat files als Datenbanken.

http://www.server.de/schutz/ sei die Adresse die geschützt werden soll.
/home/server/www/schutz/ sei der Pfad zu diesem Verzeichnis auf dem Server.
/home/server/auth/schutz.user sei die Datei, die als Passwortdatenbank dient.
/home/server/auth/schutz.group sei die Datei, die als Gruppendatenbank dient.

Erstellen Sie die Datei .htaccess mit Hilfe eines Editors und kopieren Sie diese in /home/server/www/schutz. Die Datei .htaccess sollte folgende Einträge enthalten:

AuthName Bereich
AuthType Basic
AuthUserFile /home/server/auth/schutz.user
AuthGroupFile /home/server/auth/schutz.group

require Variante

Die orange gesetzten Einträge müssen Sie entsprechend anpassen:

Bereich steht dabei für eine Beschreibung des zu schützenden Bereichs, z.B. entwicklung@meinserver.de. Der Webserver erwartet hier ein einziges Argument. Wenn Sie Leerzeichen in den Bereichsnamen mit aufnehmen wollen, müssen diesen in Anführungszeichen einschließen, z.B. AuthName "mein Bereich".
AuthType bezeichnet das Authentisierungsverfahren. Hier muss Basic stehen.
AuthUserFile und AuthGroupFile bezeichnen die Passwortdatenbanken samt absolutem Pfad. Diese Dateien müssen – ebenso wie die Datei .htaccess – für den Webserver lesbar sein. Die Zeile beginnend mit AuthGroupFile wird nur benötigt, wenn sie Zugriff auf Gruppenebene realisieren wollen. Ist dies nicht der Fall, können Sie die Zeile weglassen.
Variante spezifiziert, wer Zugriff auf das Verzeichnis haben soll. Hierbei gibt es drei Möglichkeiten. require user admin webmaster gestattet den Zugriff für die Benutzer admin und webmaster. require group admin gestattet den Zugriff für alle Mitglieder der Gruppe admin (Auch hier ist die Angabe mehrerer Gruppen möglich.). Schließlich wird mit require valid-user der Zugriff für alle in der Datenbank erfaßten Benutzer erlaubt.
Weiterhin benötigen Sie die Datenbank /home/server/auth/schutz.user, die Sie mit dem Programm htpasswd erstellen können. Loggen Sie sich dafür (beispielsweise per SSH) auf dem Server ein und starten Sie das Programm wie folgt, wobei user für den Benuternamen steht, den Sie einrichten wollen:
```
[user@server:~]$ htpasswd -c ~/auth/schutz.user user
```
Nachdem Sie nun nach einem Passwort gefragt werden, das Sie zweimal eingeben müssen, erzeugt dieser Befehl die Datei schutz.user im Unterverzeichnis auth in Ihrem Homeverzeichnis. In dieser Datei findet sich nun der Benutzername und das zugehörige verschlüsselte Passwort. Bitte beachten Sie, dass [user@server:~]$ für die Eingabeaufforderung steht und nicht Teil der Eingabe ist.

Wenn die Datei schutz.user bereits existiert und Sie zu dieser weitere Benutzer hinzufügen wollen, dann lassen Sie bitte die Option -c im dargestellten Befehl aus.

Sie können die Passwortdatenbank auch ohne das Programm htpasswd erstellen. Die Datenbanken habe das Format Benutzername:Passwort (ein Eintrag pro Zeile). Das Passwort kann dabei mit der Standard UNIX crypt() Funktion verschlüsselt sein. Weiter Hinweise hält die Manual Page von htpasswd bereit.
/home/server/auth/schutz.group muss nur erzeugt werden, wenn Sie eine gruppenbasierte Authentisierung durchführen wollen. Legen Sie die Datei mit einem Editor Ihrer Wahl an und kopieren Sie diese in das entsprechnde Verzeichnis auf dem Server. Die Datei listet zeilenweise Gruppen im Format Gruppenname: Mitglied1 Mitglied2 .... Um also die Benutzer admin und webmaster der Gruppe admin und die Benutzer admin, webmaster und otto_normal der Gruppe users zuzuordnen, müßte /home/meinserver/authfiles/schutz.group wie folgt aussehen (Bitte beachten Sie das alle drei Benutzer einen gültigen Eintrag in /home/meinserver/authfiles/schutz.user benötigen.):
```
admin: admin webmaster
users: admin webmaster otto_normal
```

Damit ist die Einrichtung des Passwortschutzes abgeschlossen und Sie werden beim nächsten Zugriff auf das Verzeichnis von Ihrem Browser mit einem entsprechenden Authentifizierungsdialog konfrontiert.

Weitere Infomationen zu „mod_auth“ finden Sie auf der Website des Apache Servers.

Passwortschutz mit „mod_auth_pgsql“

Dieses Modul verwendet eine PostgreSQL-Datenbank zur Authentisierung. Auch bestehende Datenbanken können für die Authentisierung genutzt werden. Sind nur wenige Benutzer/Gruppen zu verwalten, dürfte der Aufwand der Erstellung einer solchen Datenbank nicht lohnen. Bei vielen Benutzern/Gruppen macht sich die Verwendung einer SQL-Datenbank jedoch schnell bezahlt.

Hinweis: Dieses Modul ist nicht Teil der Apache Distribution. Sie können es über die entsprechende Website beziehen. Das Modul muss vor der Verwendung jedoch zunächst vom Administrator in den Webserver eingebunden werden.

http://www.server.de/schutz/ sei die Adresse die geschützt werden soll.
/home/server/www/schutz/ sei der Pfad zu diesem Verzeichnis auf dem Server.
localhost sei der Server, auf dem die PostgreSQL-Datenbank läuft.
authdb sei der Name der Datenbank, die verwendet werden soll.
myname sei der Benutzername unter dem auf die Datenbank authdb zugegriffen wird.
mypass sei das Passwort mit dem auf die Datenbank authdb zugegriffen wird.
users sei der Name der Tabelle in authdb, die die Benutzernamen und -passwörter enthält.
groups sei der Name der Tabelle in authdb, die die Gruppenamen den Benutzernamen zuordnet.

Legen Sie in Ihrer Datenbank authdb die Tabellen users und groups an. Beide Tabellen müssen mindestens zwei Spalten enthalten, die Benutzernamen und Passwörter resp. Benutzernamen und Gruppen zuordnen. Eine typische Tabelle könnte wie folgt aussehen:

                  Table "users"
  Attribute  |          Type          | Modifier 
-------------+------------------------+----------
 user        | character varying(30)  | not null
 passwort    | character varying(30)  | not null
Index: users_pkey


                  Table "groups"
  Attribute  |          Type          | Modifier 
-------------+------------------------+----------
 user        | character varying(30)  | not null
 group       | character varying(30)  | not null
Index: groups_pkey

Tragen Sie in diese Tabellen Ihre Benutzer und Benutzergruppen ein. Die Passwörter sollten mit der UNIX crypt() Funktion verschlüsselt sein. Verschlüsselte Passwörter erhalten Sie beispielsweise mit Hilfe des Programms htpasswd, das im Abschnitt Passwortschutz mit „mod_auth“ beschrieben ist. Im nachfolgenden Beispiel existieren die Benutzer admin, webmaster und otto_normal. Die beiden erstgenannten sind Mitglieder der Gruppen admin und users, während otto_normal nur Mitglied der Gruppe users ist.

     user     |   passwort
--------------+----------------
 admin        | P8S2WLYadAjrS
 webmaster    | XYS4Pcasc53Dd
 otto_normal  | 2OLcT7UOubxdx
(3 rows)


     user     |    group
--------------+----------------
 admin        | admin
 admin        | users
 webmaster    | admin
 webmaster    | users
 otto_normal  | users
(5 rows)

Legen Sie nun eine .htaccess Datei in /home/server/www/schutz/ an, das folgende Direktiven enthält (Einzelheiten zur .htaccess Datei finden Sie im Abschnitt Passwortschutz mit „mod_auth“):

AuthName Bereich
AuthType Basic
Auth_PG_host localhost
Auth_PG_database authdb
Auth_PG_user myname
Auth_PG_pwd mypass
Auth_PG_pwd_table users
Auth_PG_grp_table groups
Auth_PG_uid_field user
Auth_PG_pwd_field passwort
Auth_PG_gid_field group
Auth_PG_authoritative on
Auth_PG_encrypted on

require Variante

Die orange gesetzten Einträge müssen Sie u.U. entsprechend anpassen:

Bereich steht für eine Beschreibung des zu schützenden Bereichs, z.B. entwicklung@meinserver.de. Der Webserver erwartet hier ein einziges Argument. Wenn Sie Leerzeichen in den Bereichsnamen mit aufnehmen wollen, müssen diesen in Anführungszeichen einschließen, z.B. AuthName "mein Bereich".
Auth_PG_host bezeichnet den Server, auf dem die Datenbank läuft. In der Regel können Sie hier localhost verwenden.
Auth_PG_database bezeichnet die Datenbank, die die Benutzer und Gruppentabellen vorhält.
Mit Auth_PG_user und Auth_PG_pwd authentisieren Sie sich wie gewohnt gegenüber der Datenbank. Sie sollten – wie auch bei anderen Datenbankabfragen über den Webserver – auf die entsprechenden Leserechte der Datei achten, die das Passwort enhält, damit ein Ausspähen verhindert wird.
Die Auth_PG_*_table und Auth_PG_*_field Direktiven bezeichnen die Tabellen und Tabellenspalten, in denen sich Benutzernamen, Passwörter und Benutzergruppen finden.
Mit Auth_PG_authoritative on wird das Authentisierungsmodul angewiesen, beim Scheitern einer Authetisierung nicht auf andere Authentisierungsmodule zurückzugreifen. Seien Sie äußerst vorsichtig, wenn Sie diese Option auf off setzen, da Sie sich hierdurch evtl. Sicherheitslücken einhandeln.
Auth_PG_encrypted on bedeutet dem Authentisierungsmodul, dass die Passwörter in der Datenbank verschlüsselt abgelegt sind. Es gibt keine Grund, diese Einstellung zu ändern.
require gibt wie üblich an, welchen Benutzern Zugriff gewährt werden sollen. Auf diese Direktive muss entweder das Schlüsselwort user, gefolgt von einem oder mehreren Benutzernamen (jeweils durch Leerzeichen getrennt) folgen, was den Zugriff für die angegebene Benutzer gestattet. Alternativ kann auch das Schlüsselwort group, gefolgt von einem oder mehreren Gruppennamen (jeweils durch Leerzeichen getrennt) folgen, was den Zugriff für die Mitglieder der genannten Gruppen erlaubt. Schließlich kann auch das Schlüsselwort valid-user folgen, was den Zugriff für alle in der Datenbank erfassten Benutzer erlaubt.

„mod_auth_pgsql“ unterstützt noch einige weitere Direktiven. Diese und zusätzliche Informationen erfahren Sie auf der Homepage des Moduls.

Passwortschutz mit „mod_auth_mysql“

Hinweis: Dieses Modul ist nicht Teil der Apache Distribution. Sie können es über den entsprechenden FTP-Server beziehen. Das Modul muss vor der Verwendung jedoch zunächst vom Administrator in den Webserver eingebunden werden.

„mod_auth_mysql“ erlaubt die Authentisierung gegen eine MySQL Datenbank. Um eine solche Authetisierung einzurichten, folgen Sie den Beschreibungen unter Passwortschutz mit „mod_auth_pgsql“. Die Konfiguration erfolgt analog zu diesem Modul. Lediglich die Direktiven in der Datei .htaccess lauten anders. Die im vorherigen Abschnitt gezeigte Konfiguration erforderte für „mod_auth_mysql“ folgende .htaccess Datei:

AuthName Bereich
AuthType Basic
AuthMySQLHost localhost
AuthMySQLDB authdb
AuthMySQLUser myname
AuthMySQLPassword mypass
AuthMySQLUserTable users
AuthMySQLGroupTable groups
AuthMySQLNameField user
AuthMySQLPasswordField passwort
AuthMySQLGroupField group
AuthMySQLAuthoritative on
AuthMySQLCryptedPasswords on
AuthMySQLKeepAlive off

require Variante

Weitere Infomationen zu „mod_auth_mysql“ finden Sie im Source Code des Moduls und den entsprechenden Begleittexten unter ftp://ftp.kciLink.com/pub/.

Passwortschutz mit „mod_auth_anon“

„mod_auth_anon“ bietet eine zu anderen Authentisierungsmodulen wesentlich unterschiedene Zugriffsfunktion. Der Zugang kann mit einem nahezu beliebigen Passwort erfolgen, welches jedoch protokolliert werden kann.

Für dieses Modul benötigen Sie dementsprechend auch keine Datenbank; die Datei .htaccess im entsprechenden Verzeichnis ist ausreichend. Informationen zur Erstellung der Datei .htaccess finden sie im Abschnitt Passwortschutz mit „mod_auth“.

Neben den Direktiven AuthName und AuthType (wiederum Basic) können die nachfolgend aufgeführten Direktiven verwendet werden. require Direktiven werden nicht beachtet und können weggelassen werden.

AuthName Bereich
Anonymous Benutzername
Anonymous_NoUserID Off
Anonymous_MustGiveEmail On
Anonymous_VerifyEmail On
Anonymous_LogEmail On
AuthType Basic

Die orange gesetzten Einträge müssen Sie u.U. entsprechend anpassen:

Benutzername bezeichnet den Namen, unter dem der Zugriff gestattet ist. Mehrere Namen können mit Leerzeichen getrennt angegeben werden, z.B. Anonymous anonymous gast „unbekannter Benutzer“.
Mit Anonymous_NoUserID kann die Notwendigkeit einen Benutzernamen anzugeben abgeschaltet werden (Off).
Sollen leere Passwortfelder akzeptiert werden, kann Anonymous_MustGiveEmail auf Off gesetzt werden.
Wenn Anonymous_VerifyEmail auf On gesetzt ist, überprüft das Modul, ob das Passwort die Zeichen „@“ und „.“ enthält.
Die Direktive Anonymous_LogEmail schließlich entscheidet darüber, ob anonyme Zugriffe im Error-Log des Webservers protokolliert werden sollen.

Zusätzliche Informationen zu „mod_auth_anon“ erfahren Sie auf der Homepage des Moduls.

Passwortschutz mit „mod_auth_cookie“

Dieses Modul führt keine Authentisierung im eigentlichen Sinne durch. Es arbeitet vielmehr mit anderen Authentisierungsmodulen zusammen. „mod_auth_cookie“ prüft, ob ein angegebener Cookie vorhanden ist. Ist dies nicht der Fall, wird die Authentisierung an ein anderes Modul weitergereicht. Kann der benannte Cookie jedoch ausgelesen werden, ermittelt „mod_auth_cookie“ aus dem Wert Benutzername und Passwort und übergibt sie an das zuständige Authentisierungsmodul genauso, als hätte der Benutzer die Angaben im Authentisierungsdialog selbst eingegeben. Dem Besitzer eines entsprechenden Cookies kann daher der Authentisierungsdialog erspart werden.

authcookie sei der Name des Cookies

Richten Sie zunächst eine Authentisierung unter Verwendung eines der hier beschriebenen Module ein und prüfen Sie, ob diese funktioniert. Anschließend modifizieren Sie die Datei .htaccess, indem Sie zwischen die Direktiven des entsprechenden Moduls und der Zeile beginnend mit require eine weitere Direktive einfügen:

AuthCookieName authcookie

Beim Zugriff auf das Verzeichnis, in dem sich diese .htaccess-Datei befindet, wird dem Benutzer kein Authentisierungsdialog präsentiert, wenn er einen Cookie mit Namen authcookie besitzt, aus dessen Wert Benutzername und Passwort korrekt hervorgehen. In allen anderen Fällen erfolgt ein gewöhnliche Authentisierungung.

Den Cookie selbst können Sie beispielweise mit Hilfe eines Formulars setzen (Perl, PHP, Ruby, JavaScript etc.). Der Wert muss das Format Benutzername:Passwort besitzen.

Hinweis: Zusätzlich zur Sicherheitsproblematik beim Authentisierungsverfahren Basic (siehe Sicherheitshinweise), liegt bei der Verwendung von „mod_auth_cookie“ eine weitere Sicherheitsschwachstelle beim Cookie selbst. Dieser enthält Benutzername und Passwort im Klartext, kann also von jedermann eingesehen werden, der Zugang zur Cookie-Datei des jeweiligen Nutzers hat.

Weitere Infomationen zu „mod_auth_cookie“ finden Sie im Source Code des Moduls und den entsprechenden Begleittexten unter ftp://ftp.kciLink.com/pub/.

Passwortschutz mit anderen Authentisierungsmodulen

Der Apache Webserver bietet eine vielzahl von weiteren Authentisierungsmodulen, z.B. Authentisierung gegen Berkeley DB Dateien, LDAP etc. Einen Überblick können Sie sich auf http://modules.apache.org verschaffen.

Sicherheitshinweise

Alle hier beschriebenen Schutzmechanismen verwenden das „Basic-Verfahren“, dass mit HTTP 1.0 und mittlerweile mit den meisten Browsern verwendet werden kann. Bei diesem Verfahren werden Benutzername und Passwort lediglich in Base64-Codierung übertragen, was im Prinzip einer Übertragung im Klartext gleichkommt. Daher reicht ein einfaches Abhören der Verbindung, um Benutzernamen und Passwort auszuspähen. Da die Sicherheit der beschriebenen Schutzmechanismen sehr gering ist, sollten unter keinen Umständen Systemaccounts/-passwörter für den Verzeichnisschutz verwendet werden.

Sollten Sie größere Sicherheitsbedürfnisse haben, können Sie ein SSL-Zertifikat für Ihren Server beantragen. Die Authentifizierung mit dem „Basic-Verfahren“ über SSL kann als sicher gelten. Außerdem haben Sie alternativ die Möglichkeit, eine Authentisierung über Benutzerzertifikate durchzuführen.

Alternativ zum „Basic-Verfahren“ kann mit dem Apache Webserver auch das „Digest-Verfahren“ eingesetzt werden, was ein Ausspähen des Passworts durch abhören des Kanals verhindert.

Leider ist eine Verwendung des „Digest-Verfahrens“ trotzdem derzeit nicht empfehlenswert. Das „Digest-Verfahren“ wird erst von der HTTP-Protokollversion 1.1 zwingend gefordert. Daher gibt es immernoch einige durchaus weitverbreitete Browser, die das „Digest-Verfahren“ nicht verwenden können. Prominenteste Beispiele hierfür sind Netscape 4.x und Internet Explorer 4.x. Außerdem liegt es im Wesen dieses Verfahrens, dass den Passwort-Daten auf dem Server ein besonderer Schutz zugute kommen muss, da diese auch in verschlüsselter Form von Angreifern verwendet werden können (Bei verschlüsselten Daten für das „Basic-Verfahren“ ist dies nicht der Fall.). Schließlich haben auch die beiden Apache-Module „mod_digest“ und „mod_auth_digest“ spezifische Schwächen. Das ältere „mod_digest“ implementiert Tests nur ungenügend, so dass beispielsweise der Zugriff auf einen Bereich durch die Wiederverwendung eines (abgehörten) HTTP-Headers möglich ist. Die Sicherheit vor unbefugten Zugriffen erhöht sich also nicht. Das neuere „mod_auth_digest“ hat diese Sicherheitslücken zwar nicht mehr, wird aber derzeit noch als experimentell und nicht für den Produktionseinsatz ausgewiesen.

Aus diesen Gründen kann eine Verwendung des „Digest-Verfahrens“ derzeit nicht empfohlen werden.