11.2. Webserver (HTTP)

The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian Bullseye at version 2.4.52.

11.2.1. Apache installieren

Die Installation des Pakets apache2 genügt. Es enthält alle Module, einschließlich der Multi-Processing-Module (MPMs), die beeinflussen, wie der Apache mit der parallelen Verarbeitung vieler Anfragen umgeht, die früher in separaten apache2-mpm-*-Paketen bereitgestellt wurden. Auch wird es apache2-utils mit den Kommandozeilenprogrammen, die wir später behandeln werden, nachladen.

Das verwendete MPM beeinflusst wesentlich die Art und Weise, wie Apache gleichzeitige Anfragen behandelt. Mit dem worker MPM verwendet es Threads (leichte Prozesse), während es mit dem Prefork MPM einen Pool von im Voraus erstellten Prozessen verwendet. Mit dem Event MPM werden auch Threads verwendet, aber die inaktiven Verbindungen (insbesondere diejenigen, die durch das HTTP keep-alive Feature offen gehalten werden) werden an einen dedizierten Management Thread zurückgegeben.

The Falcot administrators also install libapache2-mod-php so as to include the PHP 7.4 support in Apache. This causes the default event MPM to be disabled, and prefork to be used instead. To use the event MPM one can use php-fpm.

SICHERHEIT Ausführung unter dem Benutzer www-data

By default, Apache handles incoming requests under the identity of the www-data user as defined in /etc/apache2/envvars. This means that a security vulnerability in a CGI script executed by Apache (for a dynamic page) won't compromise the whole system, but only the files owned by this particular user.

Der Einsatz der durch apache2-suexec-* zur Verfügung gestellten suexec-Module macht es möglich, diese Regel zu umgehen, sodass einige CGI-Skripte unter der Identität eines anderen Benutzers ausgeführt werden. Dies wird mit einer Anweisung der Art SuexecUserGroup BenutzerGruppe in der Apache-Konfiguration eingestellt.

Eine weitere Möglichkeit besteht darin, ein speziell hierfür vorgesehenes MPM zu benutzen, wie das von libapache2-mpm-itk bereitgestellte. Dieses Modul weist ein etwas abweichendes Verhalten auf: es ermöglicht das „Isolieren“ virtueller Hosts (eigentlich eine Anzahl Seiten), so dass jeder von ihnen als ein anderer Benutzer läuft. Eine Schwachstelle in einer Website kann somit keine Dateien gefährden, die dem Benutzer einer anderen Website gehören.

Apache ist ein modularer Server, und viele Leistungsmerkmale werden durch externe Module umgesetzt, die das Hauptprogramm während der Initialisierung lädt. Die Standardkonfiguration aktiviert nur die gebräuchlichsten Module, aber das Aktivieren neuer Module geschieht einfach mit dem Befehl a2enmod modul; der Befehl zum Abschalten eines Moduls lautet a2dismod modul. Diese Programme erstellen (oder löschen) in Wirklichkeit nur symbolische Verknüpfungen in der Datei /etc/apache2/mods-enabled/, die auf die tatsächlichen Dateien zeigen (die in /etc/apache2/mods-available/ gespeichert sind).

In seiner Standardkonfiguration nimmt der Webserver an Port 80 Verbindungen an (wie in /etc/apache2/ports.conf konfiguriert), und liefert Seiten aus dem Verzeichnis /var/www/html/ (wie in /etc/apache2/sites-enabled/000-default.conf konfiguriert).

11.2.2. Unterstützung für SSL hinzufügen

Apache 2.4 bringt von vornherein das für sicheres HTTP (HTTPS) erforderliche Modul (mod_ssl) mit. Man muss es nur durch den Befehl a2enmod ssl aktivieren und danach die erforderlichen Anweisungen zur Konfigurationsdatei hinzufügen. Ein Konfigurationsbeispiel wird in /etc/apache2/sites-available/default-ssl.conf bereitgestellt.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

Wenn Sie vertrauenswürdige Zertifikate erzeugen möchten, können Sie dem Abschnitt Abschnitt 10.2.1, „Erstellen kostenloser vertrauenswürdiger Zertifikate“ folgen und dann die folgenden Variablen anpassen:

SSLCertificateFile      /etc/letsencrypt/live/DOMAIN/fullchain.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/DOMAIN/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem
SSLCACertificateFile    /etc/ssl/certs/ca-certificates.crt

Some extra care must be taken if you want to favor SSL connections with Perfect Forward Secrecy (those connections use ephemeral session keys ensuring that a compromise of the server's secret key does not result in the compromise of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

As an alternative to the standard SSL module, there is an extension module called mod_gnutls, which is shipped with the libapache2-mod-gnutls package and enabled with the a2enmod gnutls command. Unfortunately the version packaged for Debian had serious issues and even security implications and is therefor not part of the Debian Bullseye release.

→ https://mod.gnutls.org/

11.2.3. Virtuelle Hosts konfigurieren

Ein virtueller Host ist eine zusätzliche Identität des Web-Servers.

Apache berücksichtigt zwei verschiedene Arten virtueller Hosts: diejenigen, die auf der IP-Adresse (oder dem Port) basieren, und diejenigen, die sich auf den Domainnamen des Web-Servers stützen. Bei der ersten Methode muss jeder Seite eine andere IP-Adresse (oder ein anderer Port) zugeordnet werden, während die zweite mit einer einzigen IP-Adresse (und einem einzigen Port) auskommt und die Seiten durch den Hostnamen, der vom HTTP-Client gesendet wird, unterschieden werden (was nur in Version 1.1 des HTTP-Protokolls funktioniert - glücklicherweise ist diese Version schon so alt, dass alle Clients sie verwenden).

Die (zunehmende) Knappheit von IPv4-Adressen begünstigt gewöhnlich die zweite Methode; jedoch ist sie komplizierter, wenn der virtuelle Host auch HTTPS bereitstellen muss, da das SSL-Protokoll nicht von jeher virtuelles Hosting auf Namensbasis ermöglicht hat. Nicht alle Browser können mit der SNI-Erweiterung (Server Name Indication), die diese Kombination ermöglicht, umgehen. Wenn mehrere HTTPS-Seiten auf demselben Server laufen müssen, werden sie gewöhnlich dadurch unterschieden, dass sie auf verschiedenen Ports laufen oder unter verschiedenen IP-Adressen (IPv6 ist hier hilfreich).

Die Standardkonfiguration für Apache 2 aktiviert virtuelle Hosts auf Namensbasis. Zusätzlich wird ein voreingestellter virtueller Host in der Datei /etc/apache2/sites-enabled/000-default.conf ausgewiesen; dieser virtuelle Host wird verwendet, wenn es keinen anderen Host gibt, der zur Anfrage des Clients passt.

KURZER BLICK Apache unterstützt SNI

Der Apache-Server unterstützt eine SSL-Protokollerweiterung namens Server Name Indication (SNI). Diese Erweiterung ermöglicht es dem Browser, den Hostnamen während des Aufbaus der SSL-Verbindung zu senden, viel früher als die HTTP-Anfrage selbst, die vorher dazu benutzt wurde, den gewünschten virtuellen Host unter denen zu identifizieren, die auf demselben Server (mit derselben IP-Adresse und demselben Port) untergebracht sind.

Vor SNI hätte Apache stets das Zertifikat des voreingestellten virtuellen Hosts verwendet. Clients, die auf einen anderen virtuellen Host zugreifen wollten, würden dann Warnmeldungen anzeigen, da das erhaltene Zertifikat nicht zu der Website passte, auf die sie zugreifen wollten. Glücklicherweise arbeiten die meisten Browser inzwischen mit SNI; hierzu gehören Microsoft Internet Explorer ab Version 7.0 (ab Vista), Mozilla Firefox ab Version 2.0, Apple Safari ab Version 3.2.1 und alle Versionen von Google Chrome.

Das in Debian bereitgestellte Apache-Paket wird mit Unterstützung für SNI erstellt; daher ist keine besondere Konfiguration erforderlich.

Jeder zusätzliche virtuelle Host wird dann in einer unter /etc/apache2/sites-available/ gespeicherten Datei festgelegt. Die Einrichtung einer Website für die Domain falcot.org erfordert daher nur die Erstellung der folgenden Datei und anschließend die Aktivierung des virtuellen Hosts mit dem Befehl a2ensite www.falcot.org.

Beispiel 11.13. Die Datei /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80>
ServerName   www.falcot.org
ServerAlias  falcot.org
DocumentRoot /srv/www/www.falcot.org
</VirtualHost>

Der Apache-Server, so wie er bis jetzt konfiguriert ist, benutzt für alle virtuellen Hosts dieselben Protokolldateien (obwohl dies durch das Hinzufügen von CustomLog-Anweisungen in den Definitionen der virtuellen Hosts geändert werden könnte). Es ist daher sehr sinnvoll, das Format dieser Protokolldatei so anzupassen, dass es den Namen des virtuellen Hosts enthält. Dies kann durch die Erstellung einer Datei namens /etc/apache2/conf-available/customlog.conf erreicht werden, die für alle Protokolldateien (mit der LogFormat-Anweisung) ein anderes Format festlegt und durch Einschalten mit a2enconf customlog. Außerdem muss die CustomLog-Zeile aus der Datei /etc/apache2/sites-available/000-default.conf entfernt (oder auskommentiert) werden.

Beispiel 11.14. Die Datei /etc/apache2/conf-available/customlog.conf

# Neues Log-Format einschließlich des (virtuellen) Hostnamens
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# Jetzt soll dieses „vhost“-Format standardmäßig benutzt werden
CustomLog /var/log/apache2/access.log vhost

11.2.4. Gebräuchliche Anweisungen

Dieser Abschnitt rekapituliert in Kürze einige der häufig genutzten Konfigurations-Direktiven von Apache.

Die Hauptkonfigurationsdatei enthält gewöhnlich mehrere Directory-Blöcke; sie ermöglichen es, unterschiedliches Verhalten des Servers in Abhängigkeit von der zu liefernden Datei festzulegen. Solch ein Block enthält häufig Anweisungen des Typs Options und AllowOverride.

Beispiel 11.15. Verzeichnisblock

<Directory /srv/www>
Options Includes FollowSymlinks
AllowOverride All
DirectoryIndex index.php index.html index.htm
</Directory>

Die Anweisung DirectoryIndex enthält eine Liste von Dateien, die ausgewählt werden sollen, wenn die Client-Anfrage auf ein Verzeichnis zutrifft. Die in der Liste als erste aufgeführte Datei wird herangezogen und als Antwort gesendet.

Auf die Anweisung Options folgt eine Liste von zu aktivierenden Optionen. Der Wert None deaktiviert alle Optionen; dementsprechend aktiviert All alle außer MultiViews. Unter anderem stehen folgende Optionen zur Verfügung:

ExecCGI bedeutet, dass CGI-Skripte ausgeführt werden können.
FollowSymlinks teilt dem Server mit, dass er symbolischen Verweisen folgen kann und dass die Antwort den Inhalt des Ziels solcher Verweise enthalten soll.
SymlinksIfOwnerMatch also tells the server to follow symbolic links, but only when the link and its target have the same owner.
Includes aktiviert Server Side Includes (abgekürzt SSI). Dies sind in HTML-Seiten eingebettete Anweisungen, die bei jeder Anforderung im laufenden Betrieb ausgeführt werden.
IncludesNOEXEC lässt Server Side Includes (SSI) zu, deaktiviert jedoch den Befehl exec und beschränkt die Direktive include auf Text-/Markup-Dateien.
Indexes weist den Server an, den Inhalt eines Verzeichnisses aufzulisten, falls die von einem Client gesendete HTTP-Anforderung auf ein Verzeichnis ohne Indexdatei weist (das heißt, wenn es in diesem Verzeichnis keine der von der Anweisung DirectoryIndex genannten Dateien gibt).
MultiViews aktiviert die Inhaltsabstimmung; diese kann vom Server dazu verwendet werden, eine Webseite in der im Browser eingestellten bevorzugten Sprache anzuzeigen.

Die Anweisung AllowOverride führt alle Optionen auf, die mithilfe einer .htaccess-Datei aktiviert oder deaktiviert werden können. Eine verbreitete Anwendung dieser Option besteht darin, ExecCGI einzuschränken, so dass der Administrator entscheidet, welchen Benutzern es erlaubt ist, Programme unter der Identität des Web-Servers (des Benutzers www-data) auszuführen.

11.2.4.1. Authentifizierung verlangen

In some circumstances, access to part of a website needs to be restricted, so only legitimate users who provide a username and a password are granted access to the contents. These feature are provided by the mod_auth* modules.

Beispiel 11.16. Authentifizierung für die Datei .htaccess verlangen

Require valid-user
AuthName "Private directory"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-private

SICHERHEIT Keine Sicherheit

Das in oben stehendem Beispiel verwendete Authentifizierungssystem (Basic) bietet nur geringfügige Sicherheit, da das Passwort als Klartext gesendet wird (es ist nur als base64 kodiert, die eine einfache Kodierungs- aber keine Verschlüsselungsmethode ist). Es sollte auch beachtet werden, dass die mit diesem Verfahren „geschützten“ Dokumente ebenfalls als Klartext über das Netzwerk laufen. Falls Sicherheit wichtig ist, sollte die gesamte HTTP-Verbindung mit SSL verschlüsselt sein.

Die Datei /etc/apache2/authfiles/htpasswd-private enthält eine Liste von Benutzern und Passwörtern; sie wird normalerweise mit dem Befehl htpasswd gehandhabt. Der folgende Befehl wird zum Beispiel dazu benutzt, einen Benutzer hinzuzufügen oder sein Passwort zu ändern:

# htpasswd /etc/apache2/authfiles/htpasswd-private user
New password:
Re-type new password:
Adding password for user user

11.2.4.2. Zugang beschränken

Die Direktive Require steuert Zugriffsbeschränkungen für Verzeichnisse (und rekursiv, deren Unterverzeichnisse).

→ https://httpd.apache.org/docs/2.4/howto/access.html

Es kann eingesetzt werden, um den Zugriff auf der Grundlage vieler Kriterien zu beschränken. Wir werden uns darauf beschränken, die Zugriffsbeschränkung auf der Grundlage der IP-Adresse des Clients zu beschreiben, aber es kann viel mächtiger gemacht werden, besonders wenn mehrere Require Direktiven in einem RequireAll-Block kombiniert werden.

Beispiel 11.17. Nur aus dem lokalen Netzwerk zulassen

Require ip 192.168.0.0/16

ALTERNATIVE Alte Syntax

Die Syntax Require ist nur in Apache 2.4 verfügbar (die Version, die seit Jessie geliefert wird). Für Benutzer von Wheezy ist die Syntax des Apache 2.2 anders und wir beschreiben sie hier hauptsächlich als Referenz, obwohl sie auch in Apache 2.4 durch das Modul mod_access_compat verfügbar ist.

Die Direktiven Allow from und Deny from steuern Zugriffsbeschränkungen für Verzeichnisse (und, rekursiv, deren Unterverzeichnisse).

Die Anweisung Order informiert den Server über die Reihenfolge, in der die Anweisungen Allow from und Deny from angewendet werden; die zuletzt zutreffende erhält Vorrang. Konkret erlaubt Order deny,allow Zugang, falls kein Deny from gilt, oder falls eine Allow from Anweisung zutrifft. Umgekehrt verweigert Order allow,deny den Zugang, falls keine Allow from Anweisung zutrifft (oder falls eine Deny from Anweisung gilt).

Auf die Anweisungen Allow from und Deny from kann eine IP-Adresse folgen, ein Netzwerk (wie zum Beispiel 192.168.0.0/255.255.255.0, 192.168.0.0/24 oder sogar 192.168.0), ein Host- oder Domain-Name oder das Schlüsselwort all, das jeden bezeichnet.

Zum Beispiel, um Verbindungen standardmäßig abzulehnen, sie aber aus dem lokalen Netzwerk zuzulassen, können Sie folgendes verwenden:

Order deny,allow
Allow from 192.168.0.0/16
Deny from all

11.2.5. Protokoll-Analysatoren

Häufig wird ein Protokoll-Analysator auf einem Web-Server installiert, da er den Administratoren ein genaues Bild der Einsatzmuster des Servers vermittelt.

Die Falcot Corp. Administratoren haben AWStats (Advanced Web Statistics) für die Analyse ihrer Apache-Protokolldateien ausgewählt.

Der erste Konfigurierungsschritt besteht darin, die Datei /etc/awstats/awstats.conf anzupassen. Die Falcot Administratoren lassen sie bis auf die folgenden Parameter unverändert:

LogFile="/var/log/apache2/access.log"
LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"
SiteDomain="www.falcot.com"
HostAliases="falcot.com REGEX[^.*\.falcot\.com$]"
DNSLookup=1
LoadPlugin="tooltips"

All diese Parameter sind durch Kommentare in der Vorlagendatei dokumentiert. Insbesondere bezeichnen die Parameter LogFile und LogFormat den Ort und das Format der Protokolldatei sowie die Information, die sie enthält; SiteDomain und HostAliases führen die verschiedenen Bezeichnungen auf, unter denen die Haupt-Website bekannt ist.

Für Internet-Präsenzen mit starkem Datenverkehr sollte DNSLookup normalerweise nicht auf 1 gesetzt werden; für kleinere, wie die oben beschriebene Falcot-Site, ermöglicht diese Einstellung jedoch besser lesbare Berichte, die vollständige Rechnernamen enthalten statt unverarbeiteter IP-Adressen.

AWStats wird auch für andere virtuelle Hosts aktiviert; jeder virtuelle Host benötigt seine eigene Konfigurationsdatei, wie zum Beispiel /etc/awstats/awstats.www.falcot.org.conf.

Beispiel 11.18. AWStats-Konfigurationsdatei für einen virtuellen Host

Include "/etc/awstats/awstats.conf"
SiteDomain="www.falcot.org"
HostAliases="falcot.org"

AWStats uses many icons stored in the /usr/share/awstats/icon/ directory. In order for these icons to be available on the web site, the Apache configuration needs to be adapted to include the following directive (check out /usr/share/doc/awstats/examples/apache.conf for a more detailed example):

Alias /awstats-icon/ /usr/share/awstats/icon/

Einige Minuten später (und nachdem das Skript einige Male gelaufen ist) stehen die Ergebnisse online zur Verfügung:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

VORSICHT Rotation von Protokolldateien

In order for the statistics to take all the logs into account, AWStats needs to be run right before the Apache log files are rotated. Looking at the prerotate directive of /etc/logrotate.d/apache2 file, this is solved by the awstats package by putting a script in /etc/logrotate.d/httpd-prerotate running /usr/share/awstats/tools/update.sh.

Note also that the log files created by logrotate need to be readable by everyone, especially AWStats. This is ensured by changing /etc/logrotate.d/apache2 to include create 644 root adm (instead of the default 640 permissions) for example. But please refer to /usr/share/doc/awstats/README.Debian.gz for a more extensive documentation about this topic and alternatives.