Http:Zugriffskontrolle

Aus KissDoc

Inhaltsverzeichnis 1 Allgemein 2 Authentifizierung 3 Zugriffskontrolle

Allgemein

Es wird zwischen Authentifizierung (Authentication), Autorisierung (Authorization) und Zugriffskontrolle (Access Control) unterschieden. Die Apache Group beschäftigt sich mit dieser Problematik auf einer eigenen Site. Viel Arbeit und nur relativer Schutz .... ist der Inhalt des Kapitels. Generell gilt: NICHTS ist wirklich sicherer, als das Ethernetkabel des Rechners abzuklemmen.

Authentifizierung

Mit den Direktiven CORE Direktiven AuthType, AuthName, Require und Satisfy und den Direktiven AuthUserFile und AuthGroupFile aus dem Modul mod_auth ist eine Apache Authentifizierung (unabhängig des OS) möglich. Mit der Direktive AuthType TYPE wird der Authentifizierungstyp festgelegt. Für TYPE können derzeit nur die zwei Schlüsselwörter Basic oder Digest (MD5 - Digest) eingesetzt werden. Die Direktive muß in Zusammenhang mit den Direktiven AuthName, Require, AuthUserFile und AuthGroupFile verwendet werden. Die Direktive AuthName NAME definiert einen Namensraum für den Zugriff auf Ressourcen. Der Name muß in Anführungszeichen geschrieben werden, wenn er Leerzeichen enthalten soll. Sonst würde Apache die einzelnen Teile als weitere Argumente interpretieren. Auch wird der Name in dem Dialog ausgegeben, in welchem der Nutzer seine Anmeldeinformationen eingeben muß. Er sollte also mit Bedacht verwendet werden, z.Bsp.: AuthGroupFile Produktion.

Die Authentifizierung erfolgt unter UNIX mit dem Utility htpasswd. Dieses Programm liegt in einer GNU/Linux Distribution unter /usr/bin/ und verwaltet eigene Nutzer - und Gruppendateien. Diese sind vom System unabhängig. Das hat zum einen den Vorteil für einen Provider, daß ein Kunde unabhängig vom Server Benutzer und Gruppen verwalten kann. Zum anderen hat es aber den Nachteil für normale Firmenrechner, daß für einen Nutzer wieder neue Paßwörter in der "Merkliste" hinzukommen. Um so mehr Paßwörter sich ein Nutzer merken muß, um so eher schlägt die ganze Technik nach hinten los, weil der Nutzer sich die Paßwörter aufschreibt, oder so einfache verwendet, daß er sie selbst (und andere auch) wieder erraten kann.

Wir wollen nun also ein Paßwort für die Mitarbeiterin Anja einfügen. Dazu müssen wir zunächst eine neue Datei mit dem Befehl htpasswd -c /etc/apache/ccd-net.pwd Anja anlegen. Mit der Direktive AuthUserFile FILE können Sie nun diese Datei einer Ressource zuordnen (AuthUserFile FILE ist .htaccess tauglich).

Ein Nutzer kommt selten allein. In der Administration gilt eigentlich die Regel, nichts einem Nutzer allein zuzuordnen. Auch wir sollten die Mitarbeiterin sofort in eine Gruppe pressen. Nennen wir diese members. Die Gruppendate hat in etwa folgendes Aussehen:

members: Anja Jana admins
admins: Falk

Zugriffskontrolle

Normalerweise wird eine Zugriffskontrolle über einen Benutzernamen mit Paßwort realisiert. Sie können die Zugriffe jedoch auch von der Umgebung abhängig gestalten. Kombiniert mit einer Authentifizierung erreichen Sie dadurch eine andere Sicherheitsebene.

Die Direktiven Allow, Deny und Order (mod_access) können für Ressourcen in den Blockdirektiven <Directory>, <Files>, and <Location> verwendet werden. Auch in den .htaccess Dateien sind die Direktiven zulässig. Die Direktiven Allow und Deny steuern den Zugriff über eine IP, ein Netz, einen Namen oder einer Umgebungsoption. Es ist also ein Zugriffsschutz für Rechner, Programme und Zustände. Allow gestattet und Deny verbietet den Zugriff.

Das erste Argument einer allow oder deny Direktive ist immer das Schlüsselwort from. Kombiniert mit dem Schlüsselwort all könnten Sie mit der Form allow from all Zugriff für alle Rechner und Netzwerke gestatten. Im Gegensatz dazu sperren Sie mit deny from all den Zugriff für alle. Für das Schlüsselwort all (das zweite Argument) können nun auch verschiedene einschränkende Angaben in folgender Form vorgenommen werden:

absolute Namen	verkehrsplanung.stadtrat.dresden.de
Sub Domänen	.ordnungsamt.dresden.de
absolute IP Adressen	123.123.123.1
IP Subnets	123.123.
IP Netzwerk/CIDR	123.123.123.0/255.255.255.0
	123.123.123.0/24

Sie können die Direktiven allow und deny auch mit mehreren Argumenten, getrennt durch ein Leerzeichen, verwenden. Auch ist die mehrfache Nutzung für eine Liste von Freigaben möglich:

deny from .stadtrat.dresden.de finanzplanung.dresden.de finanzverteilung.dresden.de
deny from unproduktiv.beamte.dresden.de
allow from jugendarbeit.dresden.de korrupte.beamte.dresden.de
allow from .de
deny from 123.123.123.1
deny from 123.123.124.

Die klingt gut, ist aber auch nur eine weitere überwindbare Sicherheitsstufe. Auch sind IP Adressen sind zumindest im IP/V4 knapp. Deshalb besitzen die meisten Anwender dynamische Adressen, welche ständig neu vergeben werden. Ein potentieller Angreifer wird ebenfalls eine dynamische Adresse bevorzugen. Namen haben jedoch den Nachteil, daß potentielle Angreifer (Kinder, coole Jungs, Arbeitslose, Studenten, sogenannte Marktforscher, Juristen, Behörden, Spinner u.ä.), welche die Kontrolle über das Reverse-Mapping ihrer IP-Adressen besitzen, Zugriff erlangen könnten.

Order steuert die Reihenfolge der Auswertung bzw. die Evaluierung der allow und deny Direktiven. Das erste und einzige Argument von Order ist die Reihenfolge als ein einzelnes Wort ohne Leerzeichen in der Form deny,allow. Die Standardreihenfolge ist zuerst deny und dann allow. Deshalb ist der Zugriff im folgenden Beispiel für alle gesperrt, für das Subnet 123.123. jedoch möglich:

allow from 123.123.
deny from all

Mit einem zusätzlichen order allow,deny wäre die Seite dicht. In der folgenden Liste können Sie die möglichen Reihenfolgen und deren Wirkung ablesen:

deny,allow

deny wird vor allow evaluiert (allow siegt)

allow,deny

allow wird vor deny evaluiert (deny siegt)

mutual-failure

nur Hosts, welche in allow, nicht jedoch in deny stehen, haben Zugriff

Wird die Order Direktive für eine Ressource mehrfach notiert, so gilt jene, welche vom Server zuletzt gelesen wird - die letzte also.

Eine weitere sehr schöne Möglichkeit, Zugriffe zu steuern, beruht auf Umgebungseigenschaften, welche in Variablen speicherbar sind. So können Zugriffe von den Programmen (z.B. einem Browser) abhängig gestaltet werden. Im folgenden Beispiel wird nur einem Client namens KnockKnock/2.0 Zugriff gewährt. Die allgemeine Syntax ist dabei Allow from env=VARIABLE bzw. Deny from env=VARIABLE:

SetEnvIf User-Agent ^KnockKnock/2.0 let_me_in
<Directory /docroot>
    Order Deny,Allow
    Deny from all
    Allow from env=let_me_in
</Directory>

Ein gutes Tutorial ist bei www.zeus.com zu finden.