Zum Inhalt springen

Skript/Apache/Webserver

Aus Foxwiki
Die 5 zuletzt angesehenen Seiten:  Sed/Zeilen löschen » Skript/Apache/Webserver
(Weitergeleitet von Skript/Apache Webserver)

Skript/Apache/Webserver

Inhalt

Nr Option Beschreibung
1 Apache HTTP Server
2 Installation
3 Konfiguration
4 Module
5 Logging
6 Zugriffsrechte
7 Virtuelle Server
8 Verschlüsselung
9 PHP
10 Proxy-Server
11 Sicherheit

1 - Grundlagen

Apache HTTP Server - Webserver des Apache/Projekts

Beschreibung

Einer der meistbenutzten Webserver
Eigenschaften
Hohe Verbreitung
Leistungsfähig
Erweiterbar
Sicherheit
Frei Software
Support durch große Community
Langjährige Verfügbarkeit
Unterschiedlichste Betriebssysteme
Entstehung
Gründungsprojekt Apache Software Foundation
Entwicklungsgrundlage 1994 HTTPd Webserver des NCSA
Erste Version 1995 Apache HTTP Server
Name
Der Name wurde aus Respekt vor dem nordamerikanischen Indianerstamm der Apachen gewählt
"A patchy server"
  • „zusammengeflickter Server“
  • Diese Deutung entstand, weil die erste Version des Apache HTTP Servers eine gepatchte Version des NCSA HTTP Servers war

Apache/HTTP/Grundlagen - Apache Webserver Grundlagen

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
  • 80
  • 447
2 IP-Adresse
  • 116.202.118.50
  • 2001:470:6d:b25::100
1 Mac-Adresse 80:fa:5b:70:cf:a2

Eigenschaften und Funktionen

Betriebssysteme
Multiprocessing-Module

Hinzu kommen verschiedene Multiprocessing-Module (MPM), die je nach Plattform unterschiedliche Lösungen für die gleichzeitige Bedienung mehrerer Client-Anfragen anbieten:

  • Beispielsweise setzt das MPM prefork für klassische Unix-Systeme auf Forking von Prozessen, während mpm_winnt für die unter Windows empfehlenswerteren Threads optimiert ist
Modularer Aufbau

Durch entsprechende Module kann er beispielsweise die Kommunikation zwischen Browser und Webserver verschlüsseln (mod_ssl), als Proxyserver eingesetzt werden (mod_proxy) oder komplexe Manipulationen von HTTP-Kopfdaten (mod headers) und URLs (mod rewrite) durchführen

Serverseitige Skriptsprachen

Der Apache bietet die Möglichkeit, mittels serverseitiger Skriptsprachen Webseiten dynamisch zu erstellen

  • Häufig verwendete Skriptsprachen sind PHP, Perl oder Ruby
  • Weitere Sprachen sind Python, JavaScript (z. B. V8CGI), Lua, Tcl und .NET (mit ASP.NET oder Mono)
  • Diese sind kein Bestandteil des Webservers, sondern müssen ebenfalls entweder als Module eingebunden werden oder über das CGI angesprochen werden, da Apache im Gegensatz zu beispielsweise nginx modulbasiert ist
  • Die Module können jederzeit aktiviert oder deaktiviert werden. Über das bei der Apache-Installation enthaltene mod_include kann Server Side Includes (SSI) ausgeführt werden
  • Damit ist es möglich, einfache dynamische Webseiten zu erstellen und den Verwaltungsaufwand von statischen Webseiten zu minimieren
Lizenz

Der Apache HTTP Server ist, wie alle Programme der Apache Software Foundation, eine freie Software

  • Derzeit wird noch die stabile Version 2.4.x unterstützt und somit beispielsweise mit Sicherheitsupdates versorgt
  • Die Apache-Entwickler empfehlen die Version 2.4.x für den Produktiveinsatz

Distributionen

Versionen

Version Beschreibung
Apache 1.x Diese Version wurde erstmals im Jahre 1995 veröffentlicht
  • Die Weiterentwicklung des letzten Entwicklungszweiges 1.3.x lief im Februar 2010 aus
  • Seitdem wurde Version 1 nur noch, falls erforderlich, mit Sicherheitsupdates versorgt
  • Inzwischen ist auch die Versorgung mit Sicherheitsupdates eingestellt
Apache 2.0 Diese Version wurde erstmals im März 2000 veröffentlicht
  • In Version 2.0 wurde die Stabilität und Geschwindigkeit des Servers – vor allem auf Nicht-Unix-Systemen – erheblich verbessert:
  • Die Bibliothek Apache Portable Runtime (APR) stellt eine Verallgemeinerung wichtiger Systemaufrufe zur Verfügung, sodass die individuellen Stärken des jeweiligen Betriebssystems ausgenutzt werden können
Apache 2.4 In Apache 2.4 wurde der Support für ältere, lange schon nicht mehr weiter entwickelte Betriebssysteme wie BeOS, TPF und A/UX beendet

Dokumentation

Installation

sudo apt install apache2 apache2-doc
Aufruf

Das Handbuch wird je nach Sprachkonfiguration des Webbrowsers, die er im Feld Accept-Language des HTTP übermittelt, in der passenden Sprache ausgeliefert, sofern diese verfügbar ist


2 - Installation

Apache/HTTP/Installation - Installation eines Apache-Webservers

Betriebssystem Beschreibung
Linux
Windows


3 - Konfiguration

Apache/HTTP/Konfiguration - Apache Webserver Konfiguration

Beschreibung

Apache2 Debian Standard Seite

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
  • Fügt alle Teile zusammen
  • Bezieht alle anderen Konfigurationsdateien beim Starten des Webservers ein
ports.conf ist immer in der Hauptkonfigurationsdatei enthalten
  • Sie wird verwendet, um die lauschenden Ports für eingehende Verbindungen zu bestimmen, und diese Datei kann jederzeit angepasst werden
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.

  • Diese sollten mit a2enmod, a2dismod, a2ensite, a2dissite, und a2enconf, a2disconf verwaltet werden.
    • Detaillierte Informationen finden Sie in den jeweiligen Man Pages

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


4 - Module

Apache/HTTP/Module - Überblick

Beschreinung

Apache-HTTP-Server ist modular aufgebaut

Kernfunktionen

Modul Beschreibung
core Kernfunktionen, die immer verfügbar sind

Multi-Processing-Module

Modul Beschreibung
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 .
worker Multi-Processing-Modul zur Implementierung eines hybriden Multithreading-Multiprozess-Web-Servers

Wichtige Anwendungen

Anwendung 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
Statusbericht mod_status

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


5 - Logging

Apache/HTTP/Logging

Beschreibung

Um einen Webserver effektiv verwalten zu können, ist es notwendig, Feedback über die Aktivität und Leistung des Servers sowie über eventuell auftretende Probleme zu erhalten

  • Der Apache HTTP Server bietet sehr umfassende und flexible Protokollierungsfunktionen
  • In diesem Dokument wird beschrieben, wie Sie die Protokollierungsfunktionen konfigurieren und die Inhalte der Protokolle verstehen können

Überblick

Verwandte Module Verwandte Anweisungen

Der Apache HTTP-Server bietet eine Vielzahl verschiedener Mechanismen zur Protokollierung aller Vorgänge auf Ihrem Server, von der ersten Anfrage über den URL-Zuordnungsprozess bis hin zur endgültigen Auflösung der Verbindung, einschließlich aller Fehler, die während des Prozesses aufgetreten sind

  • Darüber hinaus können Module von Drittanbietern Protokollierungsfunktionen bereitstellen oder Einträge in die vorhandenen Protokolldateien einfügen, und Anwendungen wie CGI-Programme, PHP-Skripte oder andere Handler können Nachrichten an das Fehlerprotokoll des Servers senden

In diesem Dokument werden die Protokollmodule behandelt, die standardmäßig zum HTTP-Server gehören

Sicherheitswarnung

Jeder, der in das Verzeichnis schreiben kann, in das Apache httpd eine Protokolldatei schreibt, kann mit ziemlicher Sicherheit auf die Benutzerkennung zugreifen, unter der der Server gestartet wurde, normalerweise root. Gewähren Sie Personen KEINEN Schreibzugriff auf das Verzeichnis, in dem die Protokolle gespeichert sind, ohne sich der Konsequenzen bewusst zu sein

Außerdem können Protokolldateien Informationen enthalten, die direkt vom Client ohne Escape-Sequenz bereitgestellt werden

  • Daher ist es für böswillige Clients möglich, Steuerzeichen in die Protokolldateien einzufügen
  • Daher ist beim Umgang mit Rohprotokollen Vorsicht geboten

Fehlerprotokoll

Verwandte Module Verwandte Anweisungen

Das Server-Fehlerprotokoll, dessen Name und Speicherort durch die ErrorLog-Direktive festgelegt wird, ist die wichtigste Protokolldatei

  • An diese Stelle sendet Apache httpd Diagnoseinformationen und zeichnet alle Fehler auf, die bei der Verarbeitung von Anfragen auftreten
  • Es ist die erste Anlaufstelle, wenn beim Starten des Servers oder beim Betrieb des Servers ein Problem auftritt, da es oft Einzelheiten darüber enthält, was schiefgelaufen ist und wie es behoben werden kann

Das Fehlerprotokoll wird normalerweise in eine Datei geschrieben (normalerweise error_log auf Unix-Systemen und error.log auf Windows und OS/2)

Das Format des Fehlerprotokolls wird durch die ErrorLogFormat-Direktive definiert, mit der Sie anpassen können, welche Werte protokolliert werden

  • Wenn Sie keine angeben, wird ein Standardformat definiert

Eine typische Protokollmeldung lautet wie folgt: 

[Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416] [client 72.15.99.187] File does not exist: /usr/local/apache2/htdocs/favicon.ico

Der erste Eintrag im Logeintrag ist das Datum und die Uhrzeit der Meldung

  • Der nächste Eintrag ist das Modul, das die Meldung erzeugt hat (in diesem Fall "core"), und der Schweregrad dieser Meldung
  • Darauf folgt die Prozess-ID und gegebenenfalls die Thread-ID des Prozesses, bei dem der Zustand aufgetreten ist
  • Als Nächstes folgt die Client-Adresse, die die Anfrage gestellt hat
  • Und schließlich folgt die detaillierte Fehlermeldung, die in diesem Fall auf eine Anfrage nach einer Datei hinweist, die nicht vorhanden war

Im Fehlerprotokoll können die unterschiedlichsten Meldungen erscheinen

  • Die meisten sehen ähnlich aus wie das Beispiel oben
  • Das Fehlerprotokoll enthält auch Debugging-Ausgaben von CGI-Skripten
  • Alle Informationen, die von einem CGI-Skript in stderr geschrieben werden, werden direkt in das Fehlerprotokoll kopiert

Wenn Sie ein %L-Token sowohl in das Fehlerprotokoll als auch in das Zugriffsprotokoll einfügen, wird eine Protokolleintrags-ID erstellt, mit der Sie den Eintrag im Fehlerprotokoll mit dem Eintrag im Zugriffsprotokoll korrelieren können

  • Wenn mod_unique_id geladen ist, wird auch dessen eindeutige Anforderungs-ID als Logeintrags-ID verwendet

Beim Testen ist es oft nützlich, das Fehlerprotokoll kontinuierlich auf Probleme zu überwachen

Auf Unix-Systemen können Sie dies mit folgendem Befehl erreichen: 

 tail -f error_log

Protokollierung pro Modul

Die LogLevel-Anweisung ermöglicht es Ihnen, einen Protokollschweregrad auf Modulbasis festzulegen

  • Auf diese Weise können Sie bei der Fehlerbehebung eines Problems mit nur einem bestimmten Modul dessen Protokollierungsvolumen erhöhen, ohne auch die Details anderer Module zu erhalten, die Sie nicht interessieren
  • Dies ist besonders nützlich für Module wie mod_proxy oder mod_rewrite, bei denen Sie Details darüber wissen möchten, was sie zu tun versuchen

Geben Sie dazu den Namen des Moduls in Ihrer LogLevel-Anweisung an: 

 LogLevel info rewrite:trace5

Dies setzt den Haupt-LogLevel auf info, erhöht ihn jedoch auf trace5 für mod_rewrite

Dies ersetzt die modulbezogenen Logging-Anweisungen wie RewriteLog, die in früheren Versionen des Servers vorhanden waren

Access Log

Verwandte Module Verwandte Anweisungen

Das Server-Zugriffsprotokoll zeichnet alle vom Server verarbeiteten Anfragen auf

  • Der Speicherort und der Inhalt des Zugriffsprotokolls werden durch die CustomLog-Anweisung gesteuert
  • Die LogFormat-Anweisung kann verwendet werden, um die Auswahl der Protokollinhalte zu vereinfachen
  • In diesem Abschnitt wird beschrieben, wie der Server für die Aufzeichnung von Informationen im Zugriffsprotokoll konfiguriert wird

Die Speicherung der Informationen im Zugriffsprotokoll ist nur der erste Schritt der Protokollverwaltung

  • Der nächste Schritt besteht darin, diese Informationen zu analysieren, um nützliche Statistiken zu erstellen
  • Die Protokollanalyse im Allgemeinen geht über den Rahmen dieses Dokuments hinaus und ist nicht wirklich Teil der Aufgabe des Webservers selbst

Verschiedene Versionen von Apache httpd haben andere Module und Anweisungen zur Steuerung der Zugriffsprotokollierung verwendet, darunter mod_log_referer, mod_log_agent und die TransferLog-Anweisung

  • Die CustomLog-Direktive umfasst nun die Funktionalität aller älteren Direktiven

Das Format des Zugriffsprotokolls ist in hohem Maße konfigurierbar

  • Das Format wird mithilfe einer Formatzeichenfolge angegeben, die einer C-artigen printf(1)-Formatzeichenfolge ähnelt
  • In den nächsten Abschnitten werden einige Beispiele vorgestellt
  • Eine vollständige Liste der möglichen Inhalte der Formatzeichenfolge finden Sie in den mod_log_config Formatzeichenfolgen

Common Log Format

Eine typische Konfiguration für das Zugriffsprotokoll könnte wie folgt aussehen 

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common

Hierdurch wird der Spitzname common definiert und mit einer bestimmten Protokollformatzeichenfolge verknüpft

  • Die Formatzeichenfolge besteht aus Prozentanweisungen, die den Server jeweils anweisen, eine bestimmte Information zu protokollieren
  • In die Formatzeichenfolge können auch Literalzeichen eingefügt werden, die direkt in die Protokollausgabe kopiert werden
  • Das Anführungszeichen (") muss durch einen vorangestellten Backslash maskiert werden, damit es nicht als Ende der Formatzeichenfolge interpretiert wird
  • Die Formatzeichenfolge kann auch die speziellen Steuerzeichen ‚\n‘ für Zeilenumbruch und ‚\t‘ für Tabulator enthalten

Die CustomLog-Anweisung erstellt eine neue Protokolldatei unter Verwendung des definierten Spitznamens

  • Der Dateiname für das Zugriffsprotokoll ist relativ zum ServerRoot, es sei denn, er beginnt mit einem Schrägstrich

Die obige Konfiguration schreibt Protokolleinträge in einem Format, das als Common Log Format (CLF) bekannt ist

  • Dieses Standardformat kann von vielen verschiedenen Webservern erstellt und von vielen Protokollanalyseprogrammen gelesen werden

Die in CLF erstellten Protokolldateieinträge sehen in etwa so aus: 

 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

Jeder Teil dieses Logeintrags wird im Folgenden beschrieben

127.0.0.1 (%h)

Dies ist die IP-Adresse des Clients (Remote-Host), der die Anfrage an den Server gestellt hat

  • Wenn HostnameLookupsauf On gesetzt ist, versucht der Server, den Hostnamen zu ermitteln und anstelle der IP-Adresse zu protokollieren
  • Diese Konfiguration wird jedoch nicht empfohlen, da sie den Server erheblich verlangsamen kann
  • Stattdessen empfiehlt es sich, einen Protokoll-Postprozessor wie logresolve zu verwenden, um die Hostnamen zu ermitteln
  • Die hier gemeldete IP-Adresse ist nicht unbedingt die Adresse des Computers, an dem der Benutzer sitzt
  • Wenn sich zwischen dem Benutzer und dem Server ein Proxyserver befindet, ist diese Adresse die Adresse des Proxys und nicht die des Ursprungscomputers
- (%l)

Der "Bindestrich" in der Ausgabe zeigt an, dass die angeforderte Information nicht verfügbar ist

  • In diesem Fall ist die nicht verfügbare Information die RFC 1413-Identität des Clients, die von identd auf dem Client-Rechner ermittelt wurde
  • Diese Information ist höchst unzuverlässig und sollte fast nie verwendet werden, außer in streng kontrollierten internen Netzwerken
  • Apache httpd versucht nicht einmal, diese Informationen zu ermitteln, es sei denn, IdentityCheckist auf On gesetzt
frank (%u)

Dies ist die Benutzerkennung der Person, die das Dokument anfordert, wie durch die HTTP-Authentifizierung bestimmt

  • Der gleiche Wert wird normalerweise CGI-Skripten in der REMOTE_USER-Umgebungsvariable bereitgestellt
  • Wenn der Statuscode für die Anfrage (siehe unten) 401 ist, sollte dieser Wert nicht als vertrauenswürdig eingestuft werden, da der Benutzer noch nicht authentifiziert ist
  • Wenn das Dokument nicht kennwortgeschützt ist, lautet dieser Teil "-", genau wie der vorherige
[10/Oct/2000:13:55:36 -0700] (%t)

Die Uhrzeit, zu der die Anfrage empfangen wurde

Das Format ist 

[Tag/Monat/Jahr:Stunde:Minute:Sekunde Zone]
Tag = 2*Ziffer
Monat = 3*Buchstabe
Jahr = 4*Ziffer
Stunde = 2*Ziffer
Minute = 2*Ziffer
Sekunde = 2*Ziffer
Zone = (`+' | `-') 4*Ziffer

Es ist möglich, die Zeit in einem anderen Format anzuzeigen, indem %{format}t in der Logformatzeichenkette angegeben wird, wobei format entweder wie in strftime(3) aus der C-Standardbibliothek oder eines der unterstützten speziellen Token ist

"GET /apache_pb.gif HTTP/1.0"("%r")

Die Anforderungszeile des Clients wird in doppelten Anführungszeichen angegeben

  • Die Anforderungszeile enthält eine Vielzahl nützlicher Informationen
  • Erstens ist die vom Client verwendete Methode GET
  • Zweitens hat der Client die Ressource /apache_pb.gif angefordertund drittens hat der Client das Protokoll HTTP/1.0 verwendet
  • Es ist auch möglich, einen oder mehrere Teile der Anforderungszeile unabhängig voneinander zu protokollieren
  • Beispielsweise protokolliert der Formatierungsstring "%m %U%q %H" die Methode, den Pfad, die Abfragezeichenfolge und das Protokoll, was genau zur gleichen Ausgabe führt wie "%r"
200 (%>s)

Dies ist der Statuscode, den der Server an den Client zurücksendet

  • Diese Information ist sehr wertvoll, da sie anzeigt, ob die Anfrage zu einer erfolgreichen Antwort (Codes beginnen mit 2), einer Umleitung (Codes beginnen mit 3), einem vom Client verursachten Fehler (Codes beginnen mit 4) oder einem Fehler im Server (Codes beginnen mit 5) geführt hat

Die vollständige Liste der möglichen Statuscodes finden Sie in der HTTP-Spezifikation (RFC2616 Abschnitt 10)

2326 (%b)

Der letzte Teil gibt die Größe des an den Client zurückgegebenen Objekts an, ohne die Antwort-Header

  • Wenn kein Inhalt an den Client zurückgegeben wurde, lautet dieser Wert "-" um "0" für keinen Inhalt zu protokollieren, verwenden Sie stattdessen "%B"

Combined Log Format

Ein weiteres häufig verwendetes Format ist das Combined Log Format

Es kann wie folgt verwendet werden 

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

Dieses Format entspricht genau dem Common Log Format, mit dem Zusatz von zwei weiteren Feldern

  • Jedes der zusätzlichen Felder verwendet die Prozent-Direktive %{header}i, wobei header ein beliebiger HTTP-Request-Header sein kann
  • Das Zugriffsprotokoll in diesem Format sieht wie folgt aus:
 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

Zusätzlichen Felder:

"http://www.example.com/start.html"("%{Referer}i")

Der "Referer" (sic) HTTP-Anforderungsheader

  • Dieser gibt die Website an, von der der Client angibt, weitergeleitet worden zu sein. (Dies sollte die Seite sein, die auf /apache_pb.gif verlinkt oder diese einbindet)
"Mozilla/4.08 [en] (Win98; I ;Nav)"("%{User-agent}i\")

Der User-Agent-HTTP-Request-Header

  • Dies sind die identifizierenden Informationen, die der Client-Browser über sich selbst meldet

Mehrere Zugriffsprotokolle

Mehrere Zugriffsprotokolle können einfach durch Angabe mehrerer CustomLog-Anweisungen in der Konfigurationsdatei erstellt werden

  • Die folgenden Anweisungen erstellen beispielsweise drei Zugriffsprotokolle
  • Das erste enthält die grundlegenden CLF-Informationen, während das zweite und dritte Referer- und Browserinformationen enthalten
  • Die letzten beiden CustomLog-Zeilen zeigen, wie die Auswirkungen der ReferLog- und AgentLog-Anweisungen nachgeahmt werden können
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog-Protokolle/access_log common
CustomLog-Protokolle/referer_log "%{Referer}i -> %U"
CustomLog-Protokolle/agent_log "%{User-agent}i"

Dieses Beispiel zeigt auch, dass es nicht notwendig ist, mit der LogFormat-Direktive einen Spitznamen zu definieren

  • Stattdessen kann das Protokollformat direkt in der CustomLog-Direktive angegeben werden

Bedingte Protokolle

Manchmal ist es sinnvoll, bestimmte Einträge aus den Zugriffsprotokollen auszuschließen, die auf den Merkmalen der Client-Anfrage basieren

  • Dies lässt sich mithilfe von Umgebungsvariablen leicht bewerkstelligen
  • Zunächst muss eine Umgebungsvariable festgelegt werden, die angibt, dass die Anfrage bestimmte Bedingungen erfüllt
  • Dies wird in der Regel mit SetEnvIf erreicht
  • Anschließend wird die env= Klausel der CustomLog-Direktive verwendet, um Anfragen einzuschließen oder auszuschließen, bei denen die Umgebungsvariable festgelegt ist
Einige Beispiele
# Mark requests from the loop-back interface
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Mark requests for the robots.txt file
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Log what remains
CustomLog logs/access_log common env=!dontlog

Als weiteres Beispiel können Sie Anfragen von englischsprachigen Personen in einer Logdatei und Anfragen von nicht englischsprachigen Personen in einer anderen Logdatei protokollieren 

SetEnvIf Accept-Language "en" english
CustomLog logs/english_log common env=english
CustomLog logs/non_english_log common env=!english

In einem Caching-Szenario möchte man die Effizienz des Caches kennen

Eine sehr einfache Methode, dies herauszufinden, wäre: 

SetEnv CACHE_MISS 1
LogFormat "%h %l %u %t ‚%r ‘ %>s %b %{CACHE_MISS}e" common-cache
CustomLog logs/access_log common-cache

mod_cache wird vor mod_env ausgeführt und liefert bei Erfolg den Inhalt ohne diese

  • In diesem Fall wird ein Cache-Treffer protokolliert –während ein Cache-Fehler 1 protokolliert

Zusätzlich zur env=-Syntax unterstützt LogFormat Protokollierungswerte, die vom HTTP-Antwortcode abhängig sind: 

LogFormat "%400,501{User-agent}i" browserlog
LogFormat "%!200,304,302{Referer}i" refererlog

Im ersten Beispiel wird der User-Agent protokolliert, wenn der HTTP-Statuscode 400 oder 501 lautet

  • In anderen Fällen wird stattdessen ein "-" protokolliert
  • Ebenso wird im zweiten Beispiel der Referer protokolliert, wenn der HTTP-Statuscode nicht 200, 304 oder 302 lautet. (Beachten Sie das "!" vor den Statuscodes

Obwohl wir gerade gezeigt haben, dass die bedingte Protokollierung sehr leistungsstark und flexibel ist, ist sie nicht die einzige Möglichkeit, den Inhalt der Protokolle zu steuern

  • Protokolldateien sind nützlicher, wenn sie eine vollständige Aufzeichnung der Serveraktivität enthalten
  • Oft ist es einfacher, die Protokolldateien einfach nachzubearbeiten, um Anfragen zu entfernen, die Sie nicht berücksichtigen möchten

Protokollrotation

Selbst auf einem mäßig ausgelasteten Server ist die Menge der in den Protokolldateien gespeicherten Informationen sehr groß

  • Die Zugriffsprotokolldatei wächst in der Regel um 1 MB oder mehr pro 10.000 Anfragen
  • Daher ist es notwendig, die Protokolldateien regelmäßig zu rotieren, indem die vorhandenen Protokolle verschoben oder gelöscht werden
  • Dies kann nicht durchgeführt werden, während der Server läuft, da Apache httpd weiterhin in die alte Protokolldatei schreibt, solange die Datei geöffnet ist
  • Stattdessen muss der Server neu gestartet werden, nachdem die Protokolldateien verschoben oder gelöscht wurden, damit neue Protokolldateien geöffnet werden

Durch einen sanften Neustart kann der Server angewiesen werden, neue Protokolldateien zu öffnen, ohne dass bestehende oder ausstehende Verbindungen von Clients verloren gehen

  • Um dies zu erreichen, muss der Server jedoch weiterhin in die alten Protokolldateien schreiben, während er alte Anfragen bearbeitet
  • Daher muss nach dem Neustart eine gewisse Zeit gewartet werden, bevor die Protokolldateien verarbeitet werden
  • Ein typisches Szenario, bei dem die Protokolle einfach rotiert und die alten Protokolle komprimiert werden, um Speicherplatz zu sparen, sieht wie folgt aus:
mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
gzip access_log.old error_log.old

Eine weitere Möglichkeit, die Protokollrotation durchzuführen, ist die Verwendung von verketteten Protokollen, wie im nächsten Abschnitt beschrieben

Verkettete Protokolle

Apache httpd kann Fehler- und Zugriffsprotokolldateien über eine Pipe an einen anderen Prozess schreiben, anstatt sie direkt in eine Datei zu schreiben

  • Diese Funktion erhöht die Flexibilität der Protokollierung erheblich, ohne dass Code zum Hauptserver hinzugefügt werden muss
  • Um Protokolle in eine Pipe zu schreiben, ersetzen Sie einfach den Dateinamen durch das Pipe-Zeichen "|", gefolgt vom Namen der ausführbaren Datei, die Protokolleinträge über ihre Standardeingabe akzeptieren soll
  • Der Server startet den Piped-Log-Prozess, wenn der Server startet, und startet ihn neu, wenn er abstürzt, während der Server läuft
  • Diese letzte Funktion ist der Grund, warum wir diese Technik als "zuverlässige Piped-Protokollierung" bezeichnen können

Piped-Log-Prozesse werden vom übergeordneten Apache-httpd-Prozess erzeugt und erben die Benutzerkennung dieses Prozesses

  • Das bedeutet, dass Piped-Log-Programme normalerweise als root ausgeführt werden
  • Es ist daher wichtig, die Programme einfach und sicher zu halten

Eine wichtige Funktion von verketteten Protokollen besteht darin, eine Protokollrotation zu ermöglichen, ohne den Server neu starten zu müssen

  • Der Apache HTTP-Server enthält zu diesem Zweck ein einfaches Programm namens rotatelogs
  • Um etwa die Protokolle alle 24 Stunden zu rotieren, können Sie Folgendes verwenden:
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common

Beachten Sie, dass der gesamte Befehl, der für die Pipe aufgerufen wird, in Anführungszeichen gesetzt wird

  • Obwohl diese Beispiele für das Zugriffsprotokoll gelten, kann dieselbe Technik für das Fehlerprotokoll verwendet werden

Wie bei der bedingten Protokollierung sind über die Pipe verbundene Protokolle ein sehr leistungsstarkes Tool, sollten jedoch nicht verwendet werden, wenn eine einfachere Lösung wie die Offline-Nachbearbeitung verfügbar ist

Standardmäßig wird der Piped-Log-Prozess ohne Aufruf einer Shell gestartet

  • Verwenden Sie "|$" anstelle von "|", um eine Shell zu verwenden (normalerweise mit /bin/sh -c):
# "rotatelogs" über eine Shell aufrufen
CustomLog "|$/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common

Dies war das Standardverhalten für Apache 2.2

  • Je nach den Besonderheiten der Shell kann dies zu einem zusätzlichen Shell-Prozess für die Lebensdauer des Protokollierungs-Pipe-Programms und zu Problemen bei der Signalverarbeitung während des Neustarts führen
  • Aus Gründen der Kompatibilität mit Apache 2.2 wird die Notation "||" ebenfalls unterstützt und ist gleichbedeutend mit der Verwendung von "|"

Windows-Hinweis

Beachten Sie, dass es unter Windows zu Problemen kommen kann, wenn viele Piped-Logger-Prozesse ausgeführt werden, insbesondere wenn HTTPD als Dienst ausgeführt wird

  • Dies wird durch einen zu geringen Desktop-Heap-Speicherplatz verursacht
  • Der Desktop-Heap-Speicherplatz, der jedem Dienst zugewiesen wird, wird durch das dritte Argument des SharedSection-Parameters im Registrierungswert
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\SubSystems\Windows

angegeben.

Ändern Sie diesen Wert mit Vorsicht

Es gelten die üblichen Vorsichtsmaßnahmen für Änderungen an der Windows-Registrierung, aber Sie könnten auch den Desktop-Heap-Pool erschöpfen, wenn die Zahl zu hoch eingestellt wird.

Virtuelle Hosts

Beim Betrieb eines Servers mit vielen virtuellen Hosts gibt es mehrere Möglichkeiten, mit Protokolldateien umzugehen

  • Zunächst ist es möglich, Protokolle genau wie bei einem Server mit einem Host zu verwenden
  • Durch einfaches Platzieren der Protokollierungsanweisungen außerhalb der <VirtualHost>-Abschnitte im Hauptserverkontext ist es möglich, alle Anfragen im selben Zugriffs- und Fehlerprotokoll zu protokollieren
  • Diese Technik ermöglicht keine einfache Erfassung von Statistiken zu einzelnen virtuellen Hosts

Wenn CustomLog- oder ErrorLog-Anweisungen innerhalb eines <VirtualHost>-Abschnitts platziert werden, werden alle Anfragen oder Fehler für diesen virtuellen Host nur in der angegebenen Datei protokolliert

  • Bei jedem virtuellen Host, der keine Protokollierungsanweisungen hat, werden die Anfragen weiterhin an die Hauptserverprotokolle gesendet
  • Diese Technik ist für eine kleine Anzahl virtueller Hosts sehr nützlich, aber wenn die Anzahl der Hosts sehr groß ist, kann sie kompliziert zu verwalten sein
  • Darüber hinaus kann sie häufig Probleme mit unzureichenden Dateideskriptoren verursachen

Für das Zugriffsprotokoll gibt es einen sehr guten Kompromiss

  • Durch Hinzufügen von Informationen über den virtuellen Host zur Protokollformatzeichenfolge ist es möglich, alle Hosts im selben Protokoll zu protokollieren und das Protokoll später in einzelne Dateien aufzuteilen

Betrachten Sie beispielsweise die folgenden Anweisungen 

 LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost
 CustomLog logs/access_log comonvhost

Das %v wird verwendet, um den Namen des virtuellen Hosts zu protokollieren, der die Anfrage bearbeitet

  • Anschließend kann ein Programm wie "split-logfile" verwendet werden, um das Zugriffsprotokoll nachzubearbeiten und es in eine Datei pro virtuellem Host aufzuteilen

Weitere Protokolldateien

Verwandte Module Verwandte Anweisungen

Übertragene Byte

mod_logio fügt zwei zusätzliche LogFormat-Felder hinzu (%I und %O), die die tatsächliche Anzahl der im Netzwerk empfangenen und gesendeten Bytes protokollieren

Forensische Protokollierung

mod_log_forensic ermöglicht die forensische Protokollierung von Client-Anfragen

  • Die Protokollierung erfolgt vor und nach der Verarbeitung einer Anfrage, sodass das forensische Protokoll zwei Protokollzeilen für jede Anfrage enthält
  • Der forensische Logger ist sehr strikt und lässt keine Anpassungen zu
  • Er kann ein unschätzbares Debugging- und Sicherheitswerkzeug sein

PID-Datei

Beim Start speichert Apache httpd die Prozess-ID des übergeordneten httpd-Prozesses in der Datei logs/httpd.pid

  • Dieser Dateiname kann mit der PidFile-Anweisung geändert werden
  • Die Prozess-ID wird vom Administrator zum Neustarten und Beenden des Daemons verwendet, indem Signale an den übergeordneten Prozess gesendet werden
  • Unter Windows verwenden Sie stattdessen die Befehlszeilenoption -k
  • Weitere Informationen finden Sie auf der Seite Stoppen und Neustarten

Skriptprotokoll

Um die Fehlersuche zu erleichtern, ermöglicht die ScriptLog-Direktive die Aufzeichnung der Eingabe und Ausgabe von CGI-Skripten

  • Dies sollte nur zu Testzwecken verwendet werden – nicht für Live-Server
  • Weitere Informationen finden Sie in der mod_cgi-Dokumentation


6 - Zugriffsrechte

Beschreibung

Die Art und Weise, wie die Autorisierung angewendet werden kann, ist jetzt viel flexibler als nur eine einzelne Prüfung gegen einen einzelnen Datenspeicher

  • Ordnung, Logik und die Wahl, wie die Autorisierung durchgeführt werden soll, sind jetzt möglich

Anwenden von Logik und Reihenfolge

Die Kontrolle darüber, wie und in welcher Reihenfolge die Autorisierung durchgeführt wird, war in der Vergangenheit ein ziemliches Rätsel

  • In Apache 2.2 wurde ein anbieterbasierter Authentifizierungsmechanismus eingeführt, um den eigentlichen Authentifizierungsprozess von der Autorisierung und den unterstützenden Funktionen zu entkoppeln
  • Einer der Nebeneffekte war, dass die Authentifizierungsanbieter konfiguriert und in einer bestimmten Reihenfolge aufgerufen werden konnten, die nicht von der Ladereihenfolge des Auth-Moduls selbst abhing
  • Derselbe Provider-basierte Mechanismus wurde auch für die Autorisierung übernommen
  • Das bedeutet, dass die Require-Direktive nicht nur angibt, welche Autorisierungsmethoden verwendet werden sollen, sondern auch die Reihenfolge, in der sie aufgerufen werden
  • Mehrere Autorisierungsmethoden werden in der gleichen Reihenfolge aufgerufen, in der die Require-Direktiven in der Konfiguration erscheinen

Mit der Einführung von Autorisierungs-Container-Direktiven wie <RequireAll> und <RequireAny> hat die Konfiguration auch die Kontrolle darüber, wann die Autorisierungsmethoden aufgerufen werden und welche Kriterien bestimmen, wann der Zugriff gewährt wird

  • Siehe Authorization Containers für ein Beispiel, wie sie verwendet werden können, um komplexe Autorisierungslogik auszudrücken

Standardmäßig werden alle Require-Direktiven so behandelt, als wären sie in einer <RequireAny>-Container-Direktive enthalten

  • Mit anderen Worten: Wenn eine der angegebenen Autorisierungsmethoden erfolgreich ist, wird die Autorisierung erteilt

Autorisierungsanbieter

Verwendung von Autorisierungsanbietern für die Zugriffskontrolle

Die Authentifizierung mit Benutzername und Passwort ist nur ein Teil der Geschichte

  • Häufig möchte man Personen auf der Grundlage anderer Kriterien als ihrer Identität Zugang gewähren
  • Zum Beispiel, woher sie kommen

Mit den Berechtigungsanbietern all, env, host und ip können Sie den Zugriff auf der Grundlage anderer hostbasierter Kriterien wie dem Hostnamen oder der IP-Adresse des Rechners, der ein Dokument anfordert, erlauben oder verweigern

Die Verwendung dieser Provider wird durch die Direktive Require festgelegt

  • Diese Direktive registriert die Autorisierungsanbieter, die während der Autorisierungsphase der Anfrageverarbeitung aufgerufen werden
Beispiel
 Require ip <var>address</var>

wobei Adresse eine IP-Adresse (oder eine Teil-IP-Adresse) oder ist: 

 Require host <var>domain_name</var>

wobei domain_name ein voll qualifizierter Domänenname (oder ein teilweiser Domänenname) ist; Sie können mehrere Adressen oder Domänennamen angeben, falls gewünscht

Wenn Sie zum Beispiel jemanden haben, der Ihr Forum spammt, und Sie ihn davon abhalten wollen, könnten Sie Folgendes tun: 

<RequireAll>
 Require all granted
 Require not ip 10.252.46.165
</RequireAll>

Besucher, die von dieser Adresse kommen, können den von dieser Richtlinie abgedeckten Inhalt nicht sehen

  • Wenn Sie stattdessen einen Rechnernamen statt einer IP-Adresse haben, können Sie diesen verwenden
<RequireAll>
 Require all granted
 Require not host host.example.com
</RequireAll>

Und wenn Sie den Zugriff von einer ganzen Domäne aus blockieren möchten, können Sie auch nur einen Teil einer Adresse oder eines Domänennamens angeben: 

<RequireAll>
 Require all granted
 Require not ip 192.168.205
 Require not host phishers.example.com moreidiots.example
 Require not host ke
</RequireAll>

Die Verwendung von <RequireAll> mit mehreren <Require>-Direktiven, die jeweils mit not negiert werden, erlaubt den Zugriff nur, wenn alle negierten Bedingungen wahr sind

  • Mit anderen Worten, der Zugriff wird blockiert, wenn eine der verneinten Bedingungen nicht erfüllt ist

Zugriffskontrolle Rückwärtskompatibilität

Einer der Nebeneffekte der Einführung eines providerbasierten Mechanismus für die Authentifizierung ist, dass die früheren Zugriffskontrolldirektiven Order, Allow, Deny und Satisfy nicht mehr benötigt werden

  • Um jedoch Abwärtskompatibilität für ältere Konfigurationen zu gewährleisten, wurden diese Direktiven in das Modul mod_access_compat verschoben
Hinweis

Die Direktiven von mod_access_compat sind durch mod_authz_host veraltet

  • Das Mischen von alten Direktiven wie Order, Allow oder Deny mit neuen wie Require ist technisch möglich, aber nicht empfehlenswert
  • Das Modul mod_access_compat wurde erstellt, um Konfigurationen zu unterstützen, die nur alte Direktiven enthalten, um das 2.4 Upgrade zu erleichtern
  • Für weitere Informationen lesen Sie bitte die Upgrade-Anleitung

Authentifizierungs-Caching

Es kann vorkommen, dass die Authentifizierung eine inakzeptable Belastung für einen Anbieter oder Ihr Netzwerk darstellt

  • Dies betrifft am ehesten Benutzer von mod_authn_dbd (oder von Drittanbietern/angepassten Providern)
  • Um dieses Problem zu lösen, führt HTTPD 2.3/2.4 einen neuen Caching-Provider mod_authn_socache ein, der die Anmeldedaten zwischenspeichert und die Belastung des/der Ursprungsprovider(s) reduziert

Dies kann für einige Benutzer eine erhebliche Leistungssteigerung bedeuten

Weitere Informationen

Sie sollten auch die Dokumentation für mod_auth_basic und mod_authz_host lesen, die weitere Informationen darüber enthalten, wie das Ganze funktioniert

  • Die Direktive <AuthnProviderAlias> kann auch helfen, bestimmte Authentifizierungskonfigurationen zu vereinfachen

Die verschiedenen Chiffren, die der Apache für Authentifizierungsdaten unterstützt, werden in Passwortverschlüsselungen erläutert

Sie können auch einen Blick in die Anleitung zur Zugriffskontrolle werfen, in der eine Reihe verwandter Themen behandelt wird

Links

7 - Virtuelle Server

Apache/HTTP/Vhost - Mehrere Domains verwenden

Beschreibung

Hauptserver

Definitionen außerhalb von <VirtualHost>-Abschnitte

Virtuelle Server
  • sogenannte vhosts
  • Werden 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-Direktiveerscheint, 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, welcher VirtualHost 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-Direktivewird wie ein (nicht wildcard) ServerAliasbehandelt (wird aber nicht durch eine ServerAlias-Anweisung überschrieben)

Für jeden vhost werden verschiedene Standardwerte festgelegt

Insbesondere:

  1. Wenn ein vhost keine ServerAdmin-, Timeout-, KeepAliveTimeout-, KeepAlive-, MaxKeepAliveRequests-, ReceiveBufferSize- oder SendBufferSize-Direktivehat, wird der entsprechende Wert vom Hauptserver geerbt. (Das heißt, er wird von der endgültigen Einstellung dieses Wertes auf dem Hauptserver geerbt)
  2. 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
  1. 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 httpdlä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

Aufruf

Aufruf virtuelle Hosts

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- und ServerAlias-Prüfungenwerden 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
Tipp
  • 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

IP-basierte virtuelle Server

Namensbasierte virtuelle Server

Namensbasierte virtuelle Server



8 - Verschlüsselung

Apache/HTTP/SSL - Beschreibung

Beschreibung

Was ist SSL/TLS

Funktionsweise von SSL/TLS

Digitale Zertifikate

SSL/TLS installieren

9 - PHP

Beschreibung

10 - Proxy-Server

11 - Sicherheit

Apache/HTTP/Sicherheit - Beschreibung

Beschreibung

Abgerufen von „https://wiki.foxtom.de/index.php?title=Skript/Apache/Webserver&oldid=132025“