Skript/Apache/Webserver
Skript/Apache/Webserver
Inhalt
Nr | Option | Beschreibung |
---|---|---|
1 | Grundlagen | |
2 | Installation | |
3 | Konfiguration | |
4 | Logging | |
5 | Virtuelle Server | |
6 | Sicherheit | |
7 | Zugriffsrechte | |
8 | Verschlüsselung | |
9 | Module | |
10 | Proxy-Server | |
11 | PHP |
01 - Grundlagen
Apache/HTTP/Grundlagen - Apache Webserver Grundlagen
Beschreibung
Client-Server
Instanz | Beispiel |
---|---|
Webserver | Apache-Webserver |
Webbrowser | Firefox |
Protokolle
Instanz | Beschreibung |
---|---|
HTTP | Hypertext Transfer Protocol |
HTTPS | Verschlüsseltes HTTP |
WebDAV | HTTP-Ordner-Freigabe |
Adressierung
DoD-Schicht | Adresse | Beispiel |
---|---|---|
4 | URL | https://wiki.foxtom.de/index.php?title=DoD-Schichtenmodell&veaction=edit |
3 | Port |
|
2 | IP-Adresse |
|
1 | Mac-Adresse | 80:fa:5b:70:cf:a2 |
02 - Installation
Apache/HTTP/Installation - Installation eines Apache-Webservers
Betriebssystem | Beschreibung |
---|---|
Linux | |
Windows |
03 - Konfiguration
Apache/HTTP/Konfiguration - Apache Webserver Konfiguration
Beschreibung
Apache2 Debian Standard Seite - Beschreibung

Beschreibung
- Apache2 Debian Standard-Seite
Es funktioniert!
Dies ist die Standardbegrüßungsseite, die verwendet wird, um den korrekten Betrieb des Apache2-Servers nach der Installation auf Debian-Systemen zu testen.
* Wenn Sie diese Seite lesen können, bedeutet dies, dass der auf dieser Website installierte Apache-HTTP-Server ordnungsgemäß funktioniert.
* Sie sollten diese Datei (zu finden unter /var/www/html/index.html
) ersetzen, bevor Sie Ihren HTTP-Server weiter betreiben.
Konfigurationsübersicht
- Debians Apache2-Standardkonfiguration
Unterscheidet sich von der Standardkonfiguration
- ist in mehrere Dateien aufgeteilt
- die für die Interaktion mit Debian-Werkzeugen optimiert sind
- Konfigurationslayout
Das Konfigurationslayout für eine Apache2-Webserver-Installation auf Debian-Systemen sieht wie folgt aus:
/etc/apache2/ |-- apache2.conf | `-- ports.conf |-- mods-enabled | |-- *.load | `-- *.conf |-- conf-enabled | `-- *.conf |-- sites-enabled | `-- *.conf
Option | Beschreibung |
---|---|
apache2.conf | Hauptkonfigurationsdatei
|
ports.conf | ist immer in der Hauptkonfigurationsdatei enthalten
|
mods-enabled/ conf-enabled/ sites-enabled/ |
Die Konfigurationsdateien in den Verzeichnissen mods-enabled/ , conf-enabled/ und sites-enabled/ enthalten bestimmte Konfigurationsausschnitte, die Module, globale Konfigurationsfragmente bzw. virtuelle Hostkonfigurationen verwalten
Sie werden aktiviert, indem verfügbare Konfigurationsdateien von ihren jeweiligen *-available/-Gegenstücken per Symlink verknüpft werden.
|
Aufgrund der Verwendung von Umgebungsvariablen muss apache2 in der Standardkonfiguration mit /etc/init.d/apache2
oder apache2ctl
gestartet/gestoppt werden.
- Ein direkte Aufruf von
/usr/bin/apache2
funktioniert nicht in der Standardkonfiguration.
Dokument-Wurzeln
Standardmäßig erlaubt Debian keinen Zugriff durch den Webbrowser auf jede Datei
- Außer denen, die sich in den Verzeichnissen
/var/www
, public_html (wenn aktiviert) und/usr/share
(für Webanwendungen) befinden
Wenn Ihre Website ein Web-Dokumentenstammverzeichnis verwendet, das sich an einem anderen Ort befindet (z. B. in /srv
), müssen Sie Ihr Dokumentenstammverzeichnis in /etc/apache2/apache2.conf
auf die Whitelist setzen
Das standardmäßige Debian-Dokumentenverzeichnis ist /var/www/html
- Sie können Ihre eigenen virtuellen Hosts unter /var/www erstellen
- Dies unterscheidet sich von früheren Veröffentlichungen, die von Haus aus eine bessere Sicherheit bieten
04 - Logging
Apache/HTTP/Logging - Beschreibung
Beschreibung
Log-Dateien sind ein wichtiges Hilfsmittel für Sicherheit, Webdesign beziehungsweise Webentwicklung und sogar für das Marketing
- Apache verfügt über ein äußerst flexibles Verfahren zum Erstellen von Log-Dateien
Die erste Anlaufstelle bei Fehlern und Problemen ist die ErrorLog-Datei
- Wenn Apache sich merkwürdig verhält, sollten Sie das LogLevel herabsetzen und sie genau beobachten
- Besonders bei der Einstellung Debug gibt Apache bereitwillig über jeden Arbeitsschritt Auskunft
- Das ist wertvoll bei der Fehlersuche sowie bei der Modulprogrammierung, sollte aber im Alltagsbetrieb natürlich nicht verwendet werden
Die Nutzer- und Erfolgsanalyse Ihrer Website können Sie mithilfe von Zugriffsstatistiken vornehmen
- Apache macht es Ihnen leicht, genau die Informationen zu sammeln, die Sie benötigen: Die Definition eigener Log-Formate kann zahlreiche Felder enthalten, die weit über das Common Log Format hinausgehen
Die Auswertung der fertigen Log-Dateien können Sie leicht mithilfe eigener Skripte vornehmen; die Perl-Beispiele in diesem Kapitel geben einen ersten Einblick in die verschiedenen Möglichkeiten
- Darüber hinaus gibt es noch zahlreiche vorgefertigte Hilfsmittel: Zum einen wird Apache mit Hilfsmitteln wie rotatelogs oder logresolve geliefert, zum anderen gibt es viele DrittanbieterTools, die besonders die Aufbereitung und Analyse Ihrer Logs erleichtern
- Eine
Auswahl davon finden Sie auf der beiliegenden DVD-ROM
Log-Dateien (»logfiles«, Protokolldateien) sind für den ernsthaften Betrieb einer Website sehr wichtig: Sie geben sowohl über das Besucherverhalten als auch über Fehler und sogar Angriffsversuche Auskunft
- Apache kann deshalb nicht nur einfache Log-Dateien im klassischen CLF-Format oder im NCSA-Stil erstellen, sondern bietet zahlreiche zusätzliche Möglichkeiten
- In diesem Kapitel werden zunächst die eingebauten Logging-Fähigkeiten und -Tools von Apache 2 vorgestellt; anschließend lernen Sie noch einige »selbst gestrickte« Perl-Skripte sowie Hilfsprogramme von Drittanbietern kennen
Traditionellerweise werden mindestens zwei Log-Dateien geführt: die FehlerLog-Datei (ErrorLog), in der sämtliche unerwünschten Vorkommnisse dokumentiert werden, und die Zugriffs-Log-Datei (TransferLog oder auch AccessLog), die alle Client-Zugriffe protokolliert
Die TransferLog-Datei besitzt üblicherweise entweder das Common Log Format (CLF) oder das erweiterte Log-Format des NCSA HTTPd (Combined Log Format)
Ein Eintrag im Common Log Format sieht beispielsweise so aus
163.15.41.28 – - [29/Aug/2011:15:35:07 +0200] "GET / HTTP/1.1" 200 2263
Die Bedeutung der einzelnen Bestandteile wurde bereits in Kapitel 2, »Funktionsweise von Webservern«, erläutert
- Kurz gesagt handelt es sich um die IP-Adresse des Clients, die RFC-1413-Identität des entfernten Users (in aller Regel »–«, also nicht verfügbar), den Benutzernamen, das Datum und die Uhrzeit, die erste Zeile der HTTP-Anfrage, den HTTP-Statuscode sowie die Anzahl der Bytes im Antwort-Body
Das Combined Log Format enthält noch zwei zusätzliche Felder: den Referer (die URL der zuvor besuchten Seite) sowie den User-Agent (den Namen des ClientProgramms)
- Ein typischer Eintrag hat diese Form
163.15.41.28 – - [29/Aug/2011:15:36:24 +0200] "GET /seite2.html HTTP/ 1.1" 200 2326 "http://www.mynet.de/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0; .NET CLR 1.0.3705)"
In Apache können Sie das Format der Log-Einträge völlig frei definieren
- Sie sind also nicht auf diese beiden Standardformate angewiesen
- Da zahlreiche Auswertungs- und Weiterverarbeitungsprogramme allerdings diese Formate erwarten, lohnt es sich, auf jeden Fall eine TransferLog-Datei in einem dieser Formate zu führen und zusätzlich eine weitere Datei für Ihre Spezialanwendungen anzulegen
Das Format der ErrorLog-Datei entspricht dagegen dem UNIX-Systemstandard syslog: Jede Zeile enthält das Datum, die Dringlichkeit der Meldung (siehe weiter unten bei der Beschreibung der Direktive LogLevel) und eine Beschreibung des Fehlers
- Beispiel
[Mon Aug 29 15:34:57 2011] [error] [client 145.82.41.93] File does not exist: /usr/local/apache2/htdocs/unavail.html
Seit Apache 2.4 existiert allerdings die neue Direktive ErrorLogFormat, mit der genau festgelegt werden kann, welche Informationen im ErrorLog abgelegt werden sollen
- Direktiven und Module
In diesem Abschnitt werden die Logging-Bordmittel des Apache-Webservers vorgestellt
- Die Einstellungen für die ErrorLog-Datei sind aufgrund ihrer besonderen Wichtigkeit im Core definiert
- Die TransferLog-Optionen befinden sich im Modul mod_log_config, weitere im Modul mod_logio
- Recht neue Entwicklungen sind die Module mod_log_forensic für forensische Log-Dateien sowie mod_dumpio zur Protokollierung der gesamten Ein- und Ausgabe des Servers
- Daneben enthält das URL-Umwandlungsmodul mod_rewrite (siehe Kapitel 8, »Weiterleitungen und Indizes«) seine eigenen Logging-Direktiven, die in Abschnitt 11.1.6, »Logging-Direktiven in mod_rewrite«, vorgestellt werden
Ein etwas anderes Ziel verfolgt mod_usertrack: Es ermöglicht die Verfolgung einer Client-Session über Cookies
- Auch die Direktiven dieses Moduls werden in einem eigenen Abschnitt, und zwar in Abschnitt 11.1.5, »mod_usertrack«, behandelt
Logdateien
Konfiguration
Analyse
Log Dateien analysieren
05 - Virtuelle Server
Apache/HTTP/Virtuelle Server - Mehrere Domains verwenden
Beschreibung
- Hauptserver
- Allen Definitionen besteht, außerhalb von
<VirtualHost>-Abschnitte
- Virtuelle Server
Es gibt virtuelle Server, sogenannte vhosts, die durch <VirtualHost>-Abschnitte
definiert werden.
- Jede
VirtualHost-Richtlinie
enthält eine oder mehrere Adressen und optionale Ports
- Hostnamen
- Hostnamen können anstelle von IP-Adressen in einer virtuellen Hostdefinition verwendet werden, aber sie werden beim Start aufgelöst, und wenn eine Namensauflösung fehlschlägt, werden diese virtuellen Hostdefinitionen ignoriert. Dies wird daher nicht empfohlen.
- Die Adresse kann als
*
angegeben werden, was einer Anfrage entspricht, wenn kein anderer vhost die explizite Adresse hat, unter der die Anfrage empfangen wurde.
Die Adresse, die in der VirtualHost-Direktive
erscheint, kann einen optionalen Port haben.
- Wenn der Port nicht angegeben ist, wird er als Platzhalter-Port behandelt, der auch explizit mit
*
angegeben werden kann. - Der Platzhalter-Port passt auf jeden Port.
- Die in der
VirtualHost-Direktive
angegebenen Portnummern haben keinen Einfluss darauf, an welchen Portnummern der Apache lauscht, sie steuern nur, welcherVirtualHost
für die Bearbeitung einer Anfrage ausgewählt wird. - Verwenden Sie die
Listen-Direktive
, um die Adressen und Ports zu steuern, an denen der Server lauscht
Die Gesamtheit der Adressen (einschließlich mehrerer Ergebnisse von DNS-Abfragen) wird als Adressensatz des vhost bezeichnet
Der Apache unterscheidet automatisch auf der Grundlage des vom Client übermittelten HTTP-Host-Headers
, wenn die spezifischste Übereinstimmung für eine IP-Adresse und eine Port-Kombination in mehreren virtuellen Hosts aufgeführt ist.
Die Richtlinie ServerName
kann an jeder beliebigen Stelle innerhalb der Definition eines Servers erscheinen.
- Jedes Vorkommen überschreibt jedoch das vorherige Vorkommen (innerhalb dieses Servers).
- Wenn kein
Servername
angegeben ist, versucht der Server, ihn aus der IP-Adresse des Servers abzuleiten.
Der erste namensbasierte vhost in der Konfigurationsdatei für ein bestimmtes IP:Port-Paar ist von Bedeutung, da er für alle Anfragen verwendet wird, die an dieser Adresse und diesem Port eingehen und für die kein anderer vhost für dieses IP:Port-Paar einen passenden ServerName oder ServerAlias hat. Er wird auch für alle SSL-Verbindungen verwendet, wenn der Server die Server Name Indication nicht unterstützt.
Die vollständige Liste der Namen in der VirtualHost-Direktive
wird wie ein (nicht wildcard) ServerAlias
behandelt (wird aber nicht durch eine ServerAlias-Anweisung
überschrieben).
Für jeden vhost werden verschiedene Standardwerte festgelegt. Insbesondere:
- Wenn ein vhost keine
ServerAdmin-
,Timeout-
,KeepAliveTimeout-
,KeepAlive-
,MaxKeepAliveRequests-
,ReceiveBufferSize-
oderSendBufferSize-Direktive
hat, wird der entsprechende Wert vom Hauptserver geerbt. (Das heißt, er wird von der endgültigen Einstellung dieses Wertes auf dem Hauptserver geerbt). - Die "lookup defaults", die die Standardverzeichnisberechtigungen für einen vhost festlegen, werden mit denen des Hauptservers zusammengeführt. Dies gilt auch für alle verzeichnisbezogenen Konfigurationsinformationen für jedes Modul.
- Die Serverkonfigurationen für jedes Modul des Hauptservers werden auf dem vhost-Server zusammengeführt.
Im Wesentlichen wird der Hauptserver als "Standard" oder "Basis" behandelt, auf der jeder vhost aufgebaut wird. Die Positionierung dieser Hauptserver-Definitionen in der Konfigurationsdatei ist jedoch weitgehend irrelevant - die gesamte Konfiguration des Hauptservers wurde geparst, als diese endgültige Zusammenführung stattfand. Selbst wenn eine Hauptserver-Definition nach einer Vhost-Definition erscheint, kann sie also die Vhost-Definition beeinflussen.
Wenn der Hauptserver zu diesem Zeitpunkt keinen Servernamen
hat, wird stattdessen der Hostname des Rechners, auf dem httpd
läuft, verwendet. Als Hauptserver-Adressensatz werden die IP-Adressen bezeichnet, die durch eine DNS-Suche nach dem ServerName
des Hauptservers zurückgegeben werden.
Bei undefinierten ServerName-Feldern
wird bei einem namensbasierten vhost standardmäßig die Adresse verwendet, die in der VirtualHost-Anweisung
, die den vhost definiert, an erster Stelle steht.
Jeder vhost, der den magischen Platzhalter _default_
enthält, erhält denselben Servernamen
wie der Hauptserver.
Abgleich von virtuellen Hosts
Der Server bestimmt wie folgt, welcher vhost für eine Anfrage zu verwenden ist:
IP-Adressen-Suche
Wenn die Verbindung zum ersten Mal über eine bestimmte Adresse und einen bestimmten Port empfangen wird, sucht der Server nach allen VirtualHost-Definitionen
, die dieselbe IP-Adresse und denselben Port haben.
Wenn es keine exakten Übereinstimmungen für die Adresse und den Anschluss gibt, werden Wildcard-Übereinstimmungen(*
) berücksichtigt.
Wird keine Übereinstimmung gefunden, wird die Anfrage vom Hauptserver bearbeitet.
Wenn es VirtualHost-Definitionen
für die IP-Adresse gibt, ist der nächste Schritt die Entscheidung, ob es sich um einen IP-basierten oder einen namensbasierten vhost handelt.
IP-basierter vhost
Wenn es genau eine VirtualHost-Direktive
gibt, die die Kombination aus IP-Adresse und Port auflistet, die als beste Übereinstimmung ermittelt wurde, werden keine weiteren Aktionen durchgeführt und die Anfrage wird von dem passenden vhost bedient.
Namensbasierter vhost
Wenn es mehrere VirtualHost-Direktiven
gibt, in denen die IP-Adress- und Port-Kombination aufgeführt ist, die als beste Übereinstimmung ermittelt wurde, bezieht sich die "Liste" in den verbleibenden Schritten auf die Liste der übereinstimmenden vhosts in der Reihenfolge, in der sie in der Konfigurationsdatei stehen.
Wenn die Verbindung SSL verwendet, der Server die Server Name Indication unterstützt und der Handshake des SSL-Clients die TLS-Erweiterung mit dem angeforderten Hostnamen enthält, wird dieser Hostname weiter unten verwendet, genauso wie der Host:
Header bei einer Nicht-SSL-Verbindung verwendet werden würde. Andernfalls wird der erste namensbasierte vhost, dessen Adresse übereinstimmt, für SSL-Verbindungen verwendet. Dies ist wichtig, weil der vhost bestimmt, welches Zertifikat der Server für die Verbindung verwendet.
Wenn die Anfrage ein Host:
-Headerfeld enthält, wird die Liste nach dem ersten vhost mit einem übereinstimmenden ServerName
oder ServerAlias
durchsucht, und die Anfrage wird von diesem vhost bedient. Ein Host:
Header-Feld kann eine Portnummer enthalten, aber der Apache ignoriert sie immer und gleicht sie mit dem echten Port ab, an den der Client die Anfrage gesendet hat.
Der erste vhost in der Konfigurationsdatei mit der angegebenen IP-Adresse hat die höchste Priorität und fängt jede Anfrage an einen unbekannten Servernamen oder eine Anfrage ohne Host:
Header-Feld (wie eine HTTP/1.0-Anfrage) ab.
Dauerhafte Verbindungen
Die oben beschriebene IP-Abfrage wird nur einmal für eine bestimmte TCP/IP-Sitzung durchgeführt, während die Namensabfrage bei jeder Anfrage während einer KeepAlive/Persistent-Verbindung erfolgt. Mit anderen Worten: Ein Client kann während einer einzigen dauerhaften Verbindung Seiten von verschiedenen namensbasierten vhosts anfordern.
Absoluter URI
Wenn der URI aus der Anfrage ein absoluter URI ist und sein Hostname und Port mit dem Hauptserver oder einem der konfigurierten virtuellen Hosts übereinstimmen und mit der Adresse und dem Port übereinstimmen, an die der Client die Anfrage gesendet hat, dann wird das Schema/Hostname/Port-Präfix entfernt und der verbleibende relative URI wird von dem entsprechenden Hauptserver oder virtuellen Host bedient. Stimmt er nicht überein, bleibt der URI unberührt und die Anfrage wird als Proxy-Anfrage gewertet.
Beobachtungen
- Das namensbasierte virtuelle Hosting ist ein Verfahren, das angewendet wird, nachdem der Server den am besten passenden IP-basierten virtuellen Host ausgewählt hat.
- Wenn es Ihnen egal ist, mit welcher IP-Adresse sich der Client verbunden hat, verwenden Sie ein "*" als Adresse jedes virtuellen Hosts, und das namensbasierte virtuelle Hosting wird auf alle konfigurierten virtuellen Hosts angewendet.
ServerName-
undServerAlias-Prüfungen
werden nie für einen IP-basierten vhost durchgeführt.- Nur die Reihenfolge der namensbasierten vhosts für einen bestimmten Adressensatz ist von Bedeutung. Derjenige namensbasierte vhosts, der in der Konfigurationsdatei an erster Stelle steht, hat die höchste Priorität für seinen entsprechenden Adressensatz.
- Ein Port im
Host:
Header-Feld wird beim Abgleich niemals verwendet. Der Apache verwendet immer den echten Port, an den der Client die Anfrage gesendet hat. - Wenn zwei vhosts eine gemeinsame Adresse haben, fungieren diese gemeinsamen Adressen implizit als namensbasierte virtuelle Hosts. Dies ist ein neues Verhalten ab 2.3.11.
- Der Hauptserver wird nur dann für eine Anfrage verwendet, wenn die IP-Adresse und die Portnummer, mit der sich der Client verbunden hat, mit keinem vhost übereinstimmen (auch nicht mit einem
*
vhost). Mit anderen Worten, der Hauptserver fängt nur eine Anfrage für eine nicht spezifizierte Adresse/Port-Kombination ab (es sei denn, es gibt einen_Standard_
vhost, der zu diesem Port passt). - Sie sollten niemals DNS-Namen in
VirtualHost-Direktiven
angeben, da dies Ihren Server dazu zwingt, sich beim Booten auf DNS zu verlassen. Außerdem stellt es ein Sicherheitsrisiko dar, wenn Sie nicht die DNS für alle aufgeführten Domänen kontrollieren. Zu diesem und den nächsten beiden Themen gibt es weitere Informationen. ServerName
sollte immer für jeden vhost festgelegt werden. Andernfalls ist ein DNS-Lookup für jeden vhost erforderlich.
Tipps
Zusätzlich zu den Tipps auf der Seite über DNS-Probleme finden Sie hier einige weitere Tipps:
- Platzieren Sie alle Hauptserver-Definitionen vor allen
VirtualHost-Definitionen
. (Dies dient der besseren Lesbarkeit der Konfiguration - der Post-Config-Merging-Prozess macht es nicht offensichtlich, dass Definitionen, die um virtuelle Hosts herum gemischt sind, alle virtuellen Hosts betreffen könnten).
IP-basierte virtuelle Server
Namensbasierte virtuelle Server
Namensbasierte virtuelle Server
Beispiele
Apache/HTTP/Virtuelle Server/Beispiele
06 - Sicherheit
Apache/HTTP/Sicherheit - Beschreibung
Beschreibung
07 - Zugriffsrechte
Apache/HTTP/Zugriffsrechte - Apache Webserver Zugriffsrechte
Beschreibung
- Zugriffskontrolle
Die Zugriffskontrolle bezieht sich auf jedes Mittel zur Kontrolle des Zugriffs auf eine Ressource
- Dies ist getrennt von Authentifizierung und Autorisierung
Verwandte Module und Direktiven
Es gibt drei Arten von Modulen, die am Authentifizierungs- und Autorisierungsprozess beteiligt sind
- In der Regel müssen Sie mindestens ein Modul aus jeder Gruppe auswählen
Authentication type (see the AuthType
directive)
mod_auth_basic
mod_auth_digest
Authentication provider (see the AuthBasicProvider
and AuthDigestProvider
directives)
mod_authn_anon
mod_authn_dbd
mod_authn_dbm
mod_authn_file
mod_authnz_ldap
mod_authn_socache
Authorization (see the Require
directive)
mod_authnz_ldap
mod_authz_dbd
mod_authz_dbm
mod_authz_groupfile
mod_authz_host
mod_authz_owner
mod_authz_user
Zusätzlich zu diesen Modulen gibt es noch mod_authn_core
und mod_authz_core
- Diese Module implementieren Kernrichtlinien, die für alle Auth-Module grundlegend sind
Das Modul mod_authnz_ldap
ist sowohl ein Authentifizierungs- als auch ein Autorisierungsanbieter
- Das Modul
mod_authz_host
bietet Autorisierung und Zugriffskontrolle auf der Basis von Hostname, IP-Adresse oder Merkmalen der Anfrage, ist aber nicht Teil des Authentifizierungsprovider-Systems - Für die Abwärtskompatibilität mit mod_access gibt es ein neues Modul
mod_access_compat
Vielleicht möchten Sie auch einen Blick auf die Anleitung zur Zugriffskontrolle werfen, in der die verschiedenen Möglichkeiten zur Kontrolle des Zugriffs auf Ihren Server besprochen werden
Einführung
Wenn Sie Informationen auf Ihrer Website haben, die sensibel oder nur für einen kleinen Personenkreis bestimmt sind, können Sie mit den Techniken in diesem Artikel sicherstellen, dass die Personen, die diese Seiten sehen, auch die sind, die sie sehen sollen
Dieser Artikel behandelt die „Standard“-Methode zum Schutz von Teilen Ihrer Website, die die meisten von Ihnen verwenden werden
- Hinweis
Wenn Ihre Daten wirklich sicher sein müssen, sollten Sie in Erwägung ziehen, zusätzlich zur Authentifizierung mod_ssl
zu verwenden
Voraussetzungen
Die in diesem Artikel besprochenen Direktiven müssen entweder in Ihrer Hauptkonfigurationsdatei des Servers (typischerweise in einem <Directory>
-Abschnitt) oder in Konfigurationsdateien für einzelne Verzeichnisse (.htaccess
-Dateien) enthalten sein
Wenn Sie .htaccess
-Dateien verwenden wollen, müssen Sie eine Serverkonfiguration haben, die es erlaubt, Authentifizierungsanweisungen in diese Dateien zu schreiben
- Dies geschieht mit der Direktive
AllowOverride
, die angibt, welche Direktiven, wenn überhaupt, in die Konfigurationsdateien pro Verzeichnis aufgenommen werden dürfen
Da es hier um Authentifizierung geht, benötigen Sie eine AllowOverride
-Direktive wie die folgende
AllowOverride AuthConfig
Wenn Sie die Direktiven direkt in die Hauptkonfigurationsdatei Ihres Servers einfügen wollen, müssen Sie natürlich Schreibrechte für diese Datei haben
Und Sie müssen ein wenig über die Verzeichnisstruktur Ihres Servers Bescheid wissen, um zu wissen, wo einige Dateien gespeichert sind
- Dies sollte nicht besonders schwierig sein, und ich werde versuchen, dies zu erläutern, wenn wir zu diesem Punkt kommen
Sie müssen auch sicherstellen, dass die Module mod_authn_core
und mod_authz_core
entweder in die httpd-Binärdatei eingebaut oder durch die Konfigurationsdatei httpd.conf geladen wurden
- Diese beiden Module stellen zentrale Direktiven und Funktionen bereit, die für die Konfiguration und Verwendung von Authentifizierung und Autorisierung im Webserver entscheidend sind
Betrachten wir jede dieser Direktiven einzeln
- Die Direktive
AuthType
wählt die Methode aus, die zur Authentifizierung des Benutzers verwendet wird - Die gebräuchlichste Methode ist
Basic
, und dies ist die Methode, die vonmod_auth_basic
implementiert wird - Es ist jedoch wichtig zu wissen, dass Basic Authentication das Passwort unverschlüsselt vom Client zum Server sendet
- Diese Methode sollte daher nicht für hochsensible Daten verwendet werden, es sei denn, sie wird von
mod_ssl
begleitet - Apache unterstützt eine weitere Authentifizierungsmethode:
AuthType Digest
- Diese Methode wird durch
mod_auth_digest
implementiert und war als sicherer gedacht - Dies ist nicht mehr der Fall und die Verbindung sollte stattdessen mit
mod_ssl
verschlüsselt werden
Die Direktive AuthName
legt den Realm fest, der bei der Authentifizierung verwendet wird
- Der Realm dient zwei Hauptfunktionen
- Erstens zeigt der Client dem Benutzer diese Information oft als Teil des Passwortdialogs an
- Zweitens wird er vom Client verwendet, um zu bestimmen, welches Kennwort für einen bestimmten authentifizierten Bereich zu senden ist
Hat sich ein Client beispielsweise einmal im Bereich „Eingeschränkte Dateien“
authentifiziert, wird er automatisch dasselbe Kennwort für jeden Bereich auf demselben Server wiederholen, der mit dem „Eingeschränkte Dateien“
Realm gekennzeichnet ist
- Sie können also verhindern, dass ein Benutzer mehr als einmal zur Eingabe eines Passworts aufgefordert wird, indem Sie mehrere eingeschränkte Bereiche auf denselben Realm zugreifen lassen
- Aus Sicherheitsgründen wird der Client natürlich immer wieder nach dem Passwort fragen müssen, wenn sich der Hostname des Servers ändert
Der AuthBasicProvider
ist in diesem Fall optional, da file
der Standardwert für diese Direktive ist
- Sie müssen diese Direktive verwenden, wenn Sie eine andere Quelle für die Authentifizierung wählen, wie
mod_authn_dbm
odermod_authn_dbd
Die Direktive AuthUserFile
setzt den Pfad zu der Passwortdatei, die wir gerade mit htpasswd
erstellt haben
- Wenn Sie eine große Anzahl von Benutzern haben, kann es ziemlich langsam sein, eine reine Textdatei zu durchsuchen, um den Benutzer bei jeder Anfrage zu authentifizieren
- Apache hat auch die Möglichkeit, Benutzerinformationen in schnellen Datenbankdateien zu speichern
- Das Modul
mod_authn_dbm
bietet die DirektiveAuthDBMUserFile
- Diese Dateien können mit den Programmen
dbmmanage
undhtdbm
erstellt und manipuliert werden - Viele andere Arten von Authentifizierungsoptionen sind in Modulen von Drittanbietern verfügbar
Schließlich sorgt die Require
-Direktive für den Autorisierungsteil des Prozesses, indem sie den Benutzer festlegt, der auf diesen Bereich des Servers zugreifen darf
- Im nächsten Abschnitt werden wir verschiedene Möglichkeiten zur Verwendung der
Require
-Direktive diskutieren
Mehr als eine Person reinlassen
Die obigen Direktiven lassen nur eine Person (speziell jemanden mit dem Benutzernamen rbowen
) in das Verzeichnis
- In den meisten Fällen werden Sie mehr als eine Person reinlassen wollen
- Hier kommt die
AuthGroupFile
ins Spiel
Wenn Sie mehr als eine Person zulassen wollen, müssen Sie eine Gruppendatei erstellen, die Gruppennamen mit einer Liste von Benutzern in dieser Gruppe verknüpft
- Das Format dieser Datei ist recht einfach, und Sie können sie mit Ihrem bevorzugten Editor erstellen
Der Inhalt der Datei wird wie folgt aussehen
GroupName: rbowen dpitts sungo rshersey
Das ist einfach eine Liste der Mitglieder der Gruppe in einer langen Zeile, getrennt durch Leerzeichen
Um einen Benutzer zu Ihrer bereits bestehenden Passwortdatei hinzuzufügen, geben Sie ein
htpasswd /usr/local/apache/passwd/passwords dpitts
Sie erhalten die gleiche Antwort wie zuvor, aber sie wird an die bestehende Datei angehängt, anstatt eine neue Datei zu erstellen. (Das -c
bewirkt, dass eine neue Passwortdatei angelegt wird)
Nun müssen Sie Ihre .htaccess
-Datei oder Ihren <Directory>
-Block so ändern, dass er wie folgt aussieht
AuthType Basic
AuthName "By Invitation Only"
# Optional line
AuthBasicProvider file
AuthUserFile "/usr/local/apache/passwd/passwords"
AuthGroupFile "/usr/local/apache/passwd/groups"
Require group GroupName
Jetzt wird jeder, der in der Gruppe Gruppenname
aufgeführt ist und einen Eintrag in der Datei Passwort
hat, eingelassen, wenn er das richtige Passwort eingibt
Es gibt noch eine andere Möglichkeit, mehrere Benutzer einzulassen, die weniger spezifisch ist
Anstatt eine Gruppendatei zu erstellen, können Sie einfach die folgende Richtlinie verwenden
Require valid-user
Wenn Sie dies anstelle der Zeile Require user rbowen
verwenden, kann sich jeder anmelden, der in der Passwortdatei aufgeführt ist und sein Passwort korrekt eingibt
Mögliche Probleme
Aufgrund der Art und Weise, wie die Basic-Authentifizierung spezifiziert ist, müssen Ihr Benutzername und Ihr Passwort jedes Mal überprüft werden, wenn Sie ein Dokument vom Server anfordern
- Dies gilt auch, wenn Sie dieselbe Seite neu laden, und für jedes Bild auf der Seite (wenn es aus einem geschützten Verzeichnis stammt)
- Wie Sie sich vorstellen können, verlangsamt dies die Abläufe ein wenig
- Die Verlangsamung ist proportional zur Größe der Kennwortdatei, denn sie muss diese Datei öffnen und die Liste der Benutzer durchgehen, bis sie zu Ihrem Namen gelangt
- Und das muss jedes Mal geschehen, wenn eine Seite geladen wird
Dies hat zur Folge, dass die Anzahl der Benutzer, die in einer Kennwörterdatei gespeichert werden können, in der Praxis begrenzt ist
- Diese Grenze hängt von der Leistung Ihres Servers ab, aber ab einigen hundert Einträgen ist mit einer Verlangsamung zu rechnen, so dass Sie dann vielleicht eine andere Authentifizierungsmethode in Betracht ziehen sollten
Speichern von Passwörtern
- Alternatives Speichern von Kennwörtern
Da das Speichern von Passwörtern in reinen Textdateien die oben genannten Probleme mit sich bringt, möchten Sie Ihre Passwörter vielleicht woanders speichern, zum Beispiel in einer Datenbank
mod_authn_dbm mod_authn_dbd
sind zwei Module, die dies möglich machen
Anstatt AuthBasicProvider-Datei
zu wählen, können Sie stattdessen dbm
oder dbd
als Speicherformat wählen
Um eine dbm-Datei statt einer Textdatei auszuwählen
<Directory "/www/docs/private">
AuthName "Private"
AuthType Basic
AuthBasicProvider dbm
AuthDBMUserFile "/www/passwords/passwd.dbm"
Require valid-user
</Directory>
Andere Optionen sind verfügbar
- Lesen Sie die mod_authn_dbm Dokumentation für weitere Details
Mehrerer Anbieter
- Verwendung mehrerer Anbieter
Mit der Einführung der neuen anbieterbasierten Authentifizierungs- und Autorisierungsarchitektur sind Sie nicht mehr auf eine einzige Authentifizierungs- oder Autorisierungsmethode festgelegt
- Vielmehr können Sie eine beliebige Anzahl von Anbietern miteinander kombinieren, um genau das Schema zu erhalten, das Ihren Anforderungen entspricht
- Im folgenden Beispiel werden sowohl der datei- als auch der LDAP-basierte Authentifizierungsanbieter verwendet
<Directory "/www/docs/private">
AuthName "Private"
AuthType Basic
AuthBasicProvider file ldap
AuthUserFile "/usr/local/apache/passwd/passwords"
AuthLDAPURL ldap://ldaphost/o=yourorg
Require valid-user
</Directory>
In diesem Beispiel versucht der Dateianbieter zunächst, den Benutzer zu authentifizieren
- Ist er nicht in der Lage, den Benutzer zu authentifizieren, wird der LDAP-Anbieter aufgerufen
- Dadurch kann der Bereich der Authentifizierung erweitert werden, wenn Ihre Organisation mehr als eine Art von Authentifizierungsspeicher implementiert
- Andere Authentifizierungs- und Autorisierungsszenarien können die Kombination einer Authentifizierungsart mit einer anderen Art von Autorisierung beinhalten
- Etwa die Authentifizierung anhand einer Kennwortdatei und die Autorisierung anhand eines LDAP-Verzeichnisses
Genauso wie mehrere Authentifizierungsanbieter implementiert werden können, können auch mehrere Autorisierungsmethoden verwendet werden
- In diesem Beispiel wird sowohl die Dateigruppenautorisierung als auch die LDAP-Gruppenautorisierung verwendet
<Directory "/www/docs/private">
AuthName "Private"
AuthType Basic
AuthBasicProvider file
AuthUserFile "/usr/local/apache/passwd/passwords"
AuthLDAPURL ldap://ldaphost/o=yourorg
AuthGroupFile "/usr/local/apache/passwd/groups"
Require group GroupName
Require ldap-group cn=mygroup,o=yourorg
</Directory>
Um die Autorisierung noch ein wenig weiter zu fassen, ermöglichen Autorisierungs-Container-Direktiven wie <RequireAll>
und <RequireAny>
die Anwendung einer Logik, so dass die Reihenfolge der Autorisierung vollständig über die Konfiguration gesteuert werden kann
- Siehe Authorization Containers für ein Beispiel, wie sie angewendet werden können
08 - Verschlüsselung
Apache/HTTP/SSL - Beschreibung
Beschreibung
Was ist SSL/TLS
Funktionsweise von SSL/TLS
Digitale Zertifikate
SSL/TLS installieren
09 - Module
Apache/HTTP/Module - Beschreibung
Beschreibung
- Konzept
Apache-HTTP-Server ist modular aufgebaut
- Wichtige Module
Bereich | Module |
---|---|
Verschlüsselung | mod_ssl, mod_gnutls |
Skriptsprachen | mod_php, mod_perl, mod_python |
WebDAV | mod_dav, mod_dav_fs, mod_dav_lock, mod_dav_repos |
Authentifizierung | mod_auth* |
Weiterleitung | mod_proxy |
Umschreiben von Anfragen | mod rewrite |
Änderungen an Headerzeilen | mod_headers |
Informationen zu Dateitypen | mod_mime, mod_mime_magic |
Statusberichte | mod_status |
Kernfunktionen
- Kernfunktionen und Multi-Processing-Module
Option | Beschreibung |
---|---|
core | Kernfunktionen des Apache HTTP-Servers, die immer verfügbar sind |
mpm_common | Eine Sammlung von Direktiven, die von mehr als einem Multi-Processing-Modul (MPM) implementiert werden |
event | Eine Variante des Worker-MPM mit dem Ziel, nur für Verbindungen mit aktiver Verarbeitung Threads zu verbrauchen
|
mpm_netware | Multi-Processing-Modul zur Implementierung eines für Novell NetWare optimierten Webservers mit ausschließlichem Threading |
mpmt_os2 | Hybrides Multiprozess- und Multithreading-MPM für OS/2 |
prefork | Implementiert einen Pre-Forking-Webserver ohne Threads |
mpm_winnt | Multi-Processing-Modul optimiert für Windows NT. |
worker | Multi-Processing-Modul zur Implementierung eines hybriden Multithreading-Multiprozess-Web-Servers |
Weitere Module
Modul | Bereich | Funktion |
---|---|---|
mod_access_compat | Access | Gruppenzugriffsberechtigung basierend auf dem Hostnamen |
mod_actions | Skriptsprachen | Führt CGI-Skript abhängig vom MIME-Typ des angefragten Inhalts aus |
mod_alias | URL-Umleitung | |
mod_allowmethods | Verbietet einzelne HTTP-Methoden (GET, HEAD, POST, PUT, DELETE, TRACE) | |
mod_asis | Sendet Datei ohne neue HTTP-Header zu setzen | |
mod_auth_basic | Authentifizierung | HTTP-Authentifizierung |
mod_auth_digest | Authentifizierung | Authentifizierung mit MD5-Hash |
mod_auth_form | Authentifizierung | Formular-Authentifizierung |
mod_authn_anon | Authentifizierung | Erlaubt anonymen Zugriff in authentifizierten Bereichen |
mod_authn_core | Authentifizierung | Kernmodul für die Authentifizierung |
mod_authn_dbd | Authentifizierung | Benutzer-Authentifizierung über eine SQL-Datenbank |
mod_authn_dbm | Authentifizierung | Benutzer-Authentifizierung über eine DBM-Datei |
mod_authn_file | Authentifizierung | Benutzer-Authentifizierung über Textdateien |
mod_authn_socache | Authentifizierung | Verwaltet einen Cache aus Zugangsberechtigungen |
mod_authnz_fcgi | Authentifizierung | Allows a FastCGI authorizer application to handle Apache httpd authentication and authorization |
mod_authnz_ldap | Authentifizierung | Benutzer-Authentifizierung über LDAP |
mod_authz_core | Authentifizierung | Kernmodul für Authentifizierungsmechanismen |
mod_authz_dbd | Authentifizierung | Gruppen-Authentifizierung über SQL |
mod_authz_dbm | Authentifizierung | Gruppen-Authentifizierung über DBM |
mod_authz_groupfile | Authentifizierung | Gruppen-Authentifizierung über Textdateien |
mod_authz_host | Authentifizierung | Gruppen-Authentifizierung basierend auf dem Hostnamen |
mod_authz_owner | Authentifizierung | Authentifizierung über Besitzerzugehörigkeit von Dateien |
mod_authz_user | Authentifizierung | Benutzer-Authentifizierung |
mod_autoindex | Access | Automatische Verzeichnisanzeige |
mod_buffer | Caching | Anfragen-Pufferung |
mod_cache | Caching | HTTP-Caching-Filter nach RFC 2616 |
mod_cache_disk | Caching | Festplattenspeicherung für HTTP Caching-Filter |
mod_cache_socache | Caching | Shared object cache (socache)-basierte Speicherung für den HTTP Caching-Filter |
mod_cern_meta | CERN Metadaten-Semantik | |
mod_cgi | Skriptsprachen | Ausführung von CGI-Skripten |
mod_cgid | Skriptsprachen | Ausführung von CGI-Skripten über externen daemon |
mod_charset_lite | Legt andere Zeichenkodierung fest | |
mod_data | Data-URL nach RFC 2397 | |
mod_dav | WebDAV | WebDAV |
mod_dav_fs | WebDAV | Dateisystem-Modul für WebDAV |
mod_dav_lock | WebDAV | Locking-Modul für WebDAV |
mod_dbd | Verwaltet SQL-Verbindungen | |
mod deflate | Komprimiert Inhalt vor der Auslieferung mit Deflate | |
mod_dialup | Dialup | |
mod_dir | Ordner-Verzeichnisanzeige | |
mod_dumpio | Dumps all I/O to error log as desired | |
mod_echo | Test | Echo-Server für Testzwecke |
mod_env | Ändert die Umgebung | |
mod_example_hooks | Beispielmodul | |
mod_expires | Caching | Erzeugt die Expires und Cache-Control HTTP-Header |
mod_ext_filter | Filter | Gibt die Server-Antwort vor dem Ausliefern an externes Programm weiter |
mod_file_cache | Caching | Puffert Dateien im Arbeitsspeicher |
mod_filter | Filter | Kontextsensitive Filter |
mod_headerss | Filter | Anpassung der HTTP-Header |
mod_heartbeat | Sendet Serverstatus an Proxyserver | |
mod_heartmonitor | Monitor für mod_heartbeat Server | |
mod_ident | RFC 1413 ident lookups | |
mod_imagemap | Imagemaps | |
mod_include | Serverseitiges Einbinden von HTMl-Dokumenten (Server Side Includes) | |
mod_info | Serverinformationen | |
mod_isapi | ISAPI (Apache for Windows) | |
mod_lbmethod_bybusyness | Für mod_proxy_balancer | |
mod_lbmethod_byrequests | Für mod_proxy_balancer | |
mod_lbmethod_bytraffic | Für mod_proxy_balancer | |
mod_lbmethod_heartbeat | Für mod_proxy_balancer | |
mod_ldap | LDAP | |
mod_log_config | Logging | Logging der Anfragen |
mod_log_debug | Logging | Debug Log |
mod_log_forensic | Logging | Forensisches Logging |
mod_logio | Logging | Logging der input/output bytes |
mod_lua | Lua-Hooks | |
mod_macro | Makro-Unterstützung für die Konfigurationsdateien | |
mod_mime | MIME | |
mod_mime_magic | Feststellung der MIME per Magic Byte | |
mod_negotiation | Content Negotiation | |
mod_nw_ssl | SSL-Kryptografie für NetWare | |
mod_php | Skriptsprachen | Ausführung von PHP-Skripten |
mod_privileges | Solaris Privileges | |
mod proxy | Proxy | Proxy |
mod_proxy_ajp | Proxy | AJP für mod_proxy |
mod_proxy_balancer | Proxy | Lastverteilung für mod_proxy |
mod_proxy_connect | Proxy | Unterstützung von CONNECT-Anfragen für mod_proxy |
mod_proxy_express | Proxy | Dynamische Reverse-Proxy-Unterstützung für mod_proxy |
mod_proxy_fcgi | Proxy | FastCGI-Unterstützung für mod_proxy |
mod_proxy_fdpass | Proxy | fdpass-Unterstützung für mod_proxy |
mod_proxy_ftp | Proxy | FTP-Unterstützung für mod_proxy |
mod_proxy_html | Proxy | Rewrite HTML links in to ensure they are addressable from Clients’ networks in a proxy context |
mod_proxy_http | Proxy | HTTP-Unterstützung für mod_proxy |
mod_proxy_scgi | Proxy | SCGI-Gateway-Unterstützung für mod_proxy |
mod_proxy_wstunnel | Proxy | WebSocket-Unterstützung für mod_proxy |
mod_ratelimit | Bandbreitenbegrenzung | |
mod_reflector | Kann einen Ausgabefilter in einen HTTP-Dienst verwandeln | |
mod_remoteip | Ersetzt die Client-IP mit einer Useragent-IP | |
mod_reqtimeout | Legt Timeout fest | |
mod_request | Unterstützung für HTTP-Anfragen (Requests) | |
mod rewrite | Rewrite-Engine | |
mod_security | Sicherheit | Sicherheitsmodul (Web Application Firewall) |
mod_sed | Filter | Filtern mit sed |
mod_session | Session | Unterstützung für Sitzungen |
mod_session_cookie | Session | Sitzungen mit Cookies |
mod_session_crypto | Session | Sitzungsverschlüsselung |
mod_session_dbd | Session | DBD/SQL-basierte Sitzungen |
mod_setenvif | Erlaubt das Setzen von Umgebungsvariablen je nach Anfrage | |
mod_slotmem_plain | Slot-based shared memory provider | |
mod_slotmem_shm | Slot-based shared memory provider | |
mod_so | Unterstützung für das Laden von Programmbibliotheken | |
mod_socache_dbm | Caching | DBM-basierter socache |
mod_socache_dc | Caching | Distcache-basierter socache |
mod_socache_memcache | Caching | Memcache-basierter socache |
mod_socache_shmcb | Caching | shmcb-basierter socache |
mod_speling | Modul zum Korrigieren von Rechtschreibfehlern bei der Eingabe | |
mod ssl | Kryptografie mittels SSL bzw. TLS | |
mod_status | Informationen über Serveraktivität und -leistung | |
mod_substitute | Filter | Ermöglicht Suchen & Ersetzen in der Serverantwort |
mod_suexec | CGI-Skripte als anderer Benutzer ausführen (SuEXEC) | |
mod_unique_id | Provides an environment variable with a unique identifier for each request | |
mod_unixd | Sicherheit | Basic (required) security for Unix-family platforms |
mod_userdir | Benutzer-spezifische Verzeichnisse | |
mod_usertrack | Clickstream-Logging | |
mod_version | Versionsabhängie Konfiguration | |
mod_vhost_alias | Dynamische Konfiguration für Virtual Hosting | |
mod_watchdog | Periodisches Ausführen von Aufgaben | |
mod_xml2enc | Filter | Fremde Zeichensätze für libxml2-Filtermodule |
10 - Proxy-Server
mod_proxy - Ausgabefilter, der HTML-Links so umschreiben kann, dass mehrere Webserver kombiniert werden können
Beschreibung
mod_proxy_html ist ein Ausgabefilter, der HTML-Links so umschreiben kann, dass mehrere Webserver nahtlos miteinander kombiniert werden können.
So kann z.B. ein zweiter Webserver (welchen z.B. Dienste wie ejabberd bereitstellen) unter http://server/ejabberd erreicht werden, obwohl der zweite Webserver auf der IP 127.0.0.1 und dem Port 5281 läuft.
- Die Hauptaufgabe (und damit der Unterschied zum "normalen" mod_proxy) besteht darin, dass das übertragene HTML so modifiziert wird, dass alle Links mit der veränderten Situation klarkommen.
Hier eine grafische Darstellung des Ganzen: Bild(mod_proxy_html.png, align=center) Wie im Beispiel zu sehen wird man über `http://server/ejabberd` auf den eingebauten Webserver vom [:Archiv/ejabberd:] umgeleitet.
- Alle Seiten, die der ejabberd sendet, werden durch mod_proxy_html so verändert, dass die Links mit http://server/ejabberd/ beginnen.
- So ist eine normale Funktion der ejabberd-Administrationsseiten gewährleistet.
- Natürlich funktioniert dieses Verfahren auch mit vielen anderen Diensten.
Sicherheitskonzept
Installation
Seit Apache 2.4 ist mod_proxy_html enthalten und muss nur aktiviert werden
Module aktivieren
sudo a2enmod proxy sudo a2enmod proxy_html sudo a2enmod proxy_http
- Hinweis
Anschließend muss der Apache Webserver neu gestartet werden (force-reload)
Anwendung
Problembehebung
Konfiguration
Zum Verwenden des Moduls muss die Apache-Konfiguration entsprechend angepasst werden.
- Beispiel
<VirtualHost *>
...
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /ejabberd/ http://127.0.0.1:5281/
ProxyPassReverse /ejabberd/ http://127.0.0.1:5281/
...
</VirtualHost>
- Hinweis
Nach dieser Änderung muss der Apache Webserver neu gestartet werden (reload)
- Warnung
Die Option ProxyRequests sollte ohne weitere Sicherheitsvorkehrungen (z.B. nur für bestimmte Subnetze erlaubt) NICHT auf On gesetzt werden, ansonst hat man einen sog. Open Proxy, was im Normalfall ein großes Sicherheitsproblem darstellt!
Proxy-Eigenschaften
Dateien
11 - PHP
- mod_php
- mod_php