Webserver Apache
Willemers Informatik-Ecke
Wer einen Webserver auf der Basis von Windows aufsetzt, demonstriert damit, dass er Angst hat, sich mit Linux zu befassen. Ein Linux-Server ist lizenzfrei, wartungsärmer und schon allein deshalb performanter, weil nicht ständig ein Virenscanner mitläuft. Darüber hinaus sind die Software-Quellen sicher und ein Update deutlich unproblematischer.

Da es also keinen sachlichen Grund für einen Windows-Server gibt, befasst sich diese Seite auch nicht mit Apache in einer Windows-Umgebung.

Installation

Jedes Linux hat Apache in seinem Repository. Da das Repository die denkbar sicherste Quelle ist, sollte der Apache von dort installiert werden.

Debian, Ubuntu und Linux Mint verwenden das Tool apt für die Installation seiner Pakete. Dazu benötigt man root-Rechte. Das Apache-Paket heißt apache2. Vor der eigentlichen Installation stellt man sicherheitshalber mit apt update die Konsistenz der Paketliste zwischen Computer und Repository sicher. 

# apt update
# apt install apache2
Im weiteren Verlauf der Seite wird von einer Debian-Installation ausgegangen, die auch der unter einem Ubuntu-Server entspricht. Andere Linux-Versionen unterscheiden sich in Details.

Red Hat und CentOS

Red Hat und CentOS verwenden das Tool yum und das Apache-Paket heißt dort httpd, weil Apache ein HTTP-Server (oder Daemon) ist. 
yum install httpd
Entsprechend heißt das Konfigurationsverzeichnis bei Red Hat und CentOS auch /etc/httpd.

SUSE und OpenSUSE

Installation unter SUSE

Test und Neustart

Ob der Apache auf dem lokalen Computer läuft, lässt sich einfach durch einen dort gestarteten Browser, beispielsweise Firefox prüfen.

Bei Änderungen an der Konfiguration muss der Apache neu gestartet werden. Dazu verwendet man das Kommando: 

# systemctl reload apache2
Im Allgemeinen ist es auch noch möglich, die System-V-Startskripte zu verwenden. 
/etc/init.d/apache2 restart

Websites konfigurieren

Die Konfiguration eines Apachen erfolgt im Verzeichnis /etc/apache2. Dort befinden sich nach der Installation typischerweise zwei Dateien, eine für HTTP-Seiten une eine für HTTPS-Seiten, also Seiten, bei denen die Übertragung mit einem Zertifikat verschlüsselt wird.

Apache kann mehrere Domänen auf einem Server betreiben. Für jede Präsenz wird typischerweise eine eigene Konfigurationsdatei erstellt. und im Verzeichnis /etc/apache2/sites-available abgelegt.

Konfigurationsdateien anlegen und scharfstellen

Damit die Konfigurationsdatei wirksam wird, muss sie im Verzeichnis /etc/apache2/sites-enabled erscheinen. Anstatt die Dateien zu verschieben, wird üblicherweise ein symbolischer Link auf die jeweilige Datei des Verzeichnisses sites-available angelegt. Änderungen in einer der beiden Verzeichnisse gelten so für beide und die Konfiguration der Site läuft nicht auseinander. Ein solcher symbolischer Link wird wie folgt angelegt: 
cd /etc/apache2/sites-enabled
ln -s ../sites-available/meineseite
Die Struktur der Verzeichnisse sieht folgendermaßen aus: 
/etc/apache2
        +--- sites-enabled
        +--- sites-available
Dateien in den enabled-Verzeichnissen sind normalerweise symbolische Links auf Dateien im parallelen available-Verzeichnis.

Struktur einer Konfigurationsdatei

Für jede Website wird sinnvollerweise eine eigene Konfigurationsdatei angelegt. Sie beginnt mit dem Schlüsselwort VirtualHost. Ihm folgen der Asterix, ein Doppelpunkt und die Portnummer. 
<VirtualHost *:80>
    ... Direktiven ...
</VirtualHost>

<VirtualHost *:80>
    # ServerName www.meinedomain.de
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    ... Direktiven ...
</VirtualHost>
Die Direktive DocumentRoot legt fest, wo sich die HTML-Dateien befinden. Ihr folgt also der Pfad, typischerweise liegt er unterhalb von /var/www.

Jeder Pfad kann einzeln konfiguriert werden. Dazu wird ein Bereich mit dem Schlüsselwort Directory gekennzeichnet. Es folgt der Pfad des Aufrufs. Erfolgt der Aufruf per www.firma.de/produkte, kann der Bereich der Produkte gesondert behandelt werden, indem Folgendes definiert wird: 

<VirtualHost *:80>
    ServerName www.meinedomain.de
    DocumentRoot /var/www/html
    <Directory /produkte>
        AllowOverride All
        ... Direktiven ...
    </Directory>
    ErrorLog ${APACHE_LOG_DIR}/error.log
    ... Direktiven ...
</VirtualHost>
In diesem Fall liegt unterhalb des Verzeichnisses die Direktive AllowOverride, die es ermöglicht, .htaccess-Dateien in diesem Verzeichnis abzulegen.

Der Verzeichnisname /produkte bezieht sich auf die URL, würde also hier auf www.meinedomain.de/produkte wirken.

Direktiven

An verschiedenen Stellen der Konfiguration können Direktiven gesetzt werden, wie in den bisherigen Beispielen bereits erkennbar ist. Hier sind einige gänge Direktiven und ihre Bedeutung.

Module

Apache kann durch Module erweitert werden. Am bekanntesten dürfte das Interpretermodul für die Sprache PHP sein.

Module müssen manchmal aus dem Repository nachgeladen werden, wenn sie nicht zum Standardlieferumfang von Apache gehören.

Für das Modul von PHP, wie für alle anderen Module, gibt es je eine Datei mit der Endung .conf und eine Datei mit der Endung .load. Die erstere konfiguriert das Modul und ist modulspezifisch, die zweite Datei gibt an, wo sich das Modul befindet und wie es geladen wird.

Neben dem PHP-Modul existiert noch das SSL-Modul (ssl.conf und ssl.load), das explizit freigeschaltet werden muss.

Im Falle von SSL muss das Modul auch zunächst aktiviert werden. Dazu dient der Befehl a2enmod. Erst dann öffnet Apache den Port 443. 

# # a2enmod ssl
# systemctl restart apache2

Auch die Module werden in zwei Verzeichnissen enabled und available abgelegt und werden analog zu sites verwaltet. 

/etc/apache2
        +--- mods-enabled
        +--- mods-available

Private Konfiguration mit .htaccess

Wurde in der Konfiguration die Direktive AllowOverride freigeschaltet, kann im Datenverzeichnis eine Datei .htaccess abgelegt werden, die Konfigurationen auf Verzeichnisebene erlaubt. Das ist insbesondere interessant, wenn man eine Webpräsenz bei einem Provider hat, dessen Apache sich der eigenen Konfiguration entzieht.

Eine .htpasswd-Datei wird mit dem Befehl htpasswd gepflegt. Der folgende Befehl trägt einen Benutzer paul in der Datei /var/www/sicher/.htpasswd ein. Er fordert anschließend die doppelte Eingabe des Passworts auf der Konsole ein. 
htpasswd -c /var/www/sicher/.htpasswd paul

Mehrere Domänen auf einem Server

Ein Apache kann mehrere Domänen betreuen. Dazu werden die betroffenen Domänen typischerweise durch Domain Name Service (DNS) auf diesen Server umgeleitet. Für die Tests kann dazu die Datei /etc/hosts verwendet werden.

Die vom Client angeforderte Domain liest der Server aus der HTTP-Anfrage. Er muss sich also nicht in dieser Domain befinden.

Einrichten der Konfigurationsdateien

  • Für jede Domain wird im Verzeichnis /etc/apache2/sites-available eine eigene Datei angelegt. Der Einfachheit halber kopiert man eine existierende.
  • Der Eintag ServerName wird mit dem Domännamen besetzt.
  • Der Eintrag DocumentRoot wird auf den Pfad umgebogen, in dem sich die HTML-Dateien der Präsenz befinden sollen.
  • Gibt es einen Eintrag Directory, muss dieser auch angepasst werden.
  • Aktiviert wird dies durch Erzeugen eines symbolischen Links im Verzeichnis sites-enabled. 
    cd /etc/apache2/sites-enabled
ln -s ../sites-available/dieneuedomain.conf
    Anschließend wird Apache aufgefordert, die neue Konfiguration zu laden. 
    systemctl reload apache2

    Anlegen der Dateien und Pfade

    Für jede Domain werden eigene Dateien benötigt. Diese legt man dort an, wo die Direktive DocumentRoot hinweist, typischerweise unterhalb des Verzeichnisses /var/www.

    Steht in DocumentRoot beispielsweise /var/www/meinedomain, wird man dieses Verzeichnis anlegen, Dateien hineinlegen und das Eigentum an den Benutzer von Apache www-data übertragen.

    • Verzeichnis anlegen. 
      mkdir /var/www/meinedomain
    • Eine HTML-Datei anlegen und den Inhalt ändern. 
      vi /var/www/meinedomain
      Eine einfache HTML-Seite 
      <html>
<body>
<h1>Meine Domain</h1>
</body>
</html>
    • Die Dateien dieses Verzeichnisses dem Benutzer www-data zuordnen 
      chown -R www-data /var/www/meinedomain

    Testen der Domänen

    Wer nicht gleich ein DNS aufsetzen will, kann sich durch Manipulation der /etc/hosts helfen, um den Server zu testen.

    • Man bestimmt die Server-IP-Adresse, etwa mit ip a oder ifconfig. Das Ergebnis könnte beispielsweise 192.168.1.10 lauten.
    • In der /etc/hosts trägt man für diese IP die Domains ein. 
      # /etc/hosts
...
192.168.1.10   www.eins.edu www.zwei.edu www.drei.edu
    • Nun kann man Firefox (oder einen anderen Browser) starten und als Adresse die entsprechende Domain, bspw. www.eins.edu eintragen.

    HTTPS-Der verschlüsselte Zugriff

    Bei der HTTP-Kommunikation über den Port 80 werden alle Daten im Klartext übertragen. Das ist insbesondere bei der Eingabe von Passwörtern nicht gut. Für einen verschlüsselten Transport wird HTTPS verwendet, das über den Port 443 kommuniziert.

    HTTPS bietet gegenüber HTTP zwei wichtige Eigenschaften:

    • Die Übertragung ist verschlüsselt.
    • Der Server weist sich gegenüber dem Client als verlässliche Quelle aus.
    Beides wird über Zertifikate erreicht, die zur vollständigen Funktion bei einer CA bestätigt werden müssen. Für die ersten Tests oder für die Verwendung im Intranet, kann man die CA-Zertifizierung selbst übernehmen, muss aber diese bei allen beteiligten Browsern eintragen.

    Verschlüsselung über das Zertifikat

    • Der Server sendet dem Client, also dem Browser, bei Verbindungsaufnahme den öffentlichen Teil seines Zertifikats. Das Zertifikat enthält den Domain-Namen der Webseite.
    • Der Client prüft, ob Zertifikat und Domain-Namen zusammenpassen und kann aufgrund der anderen Zertifikatsinhalte feststellen, wer der Eigner ist.
    • Auf der Basis dieses Zertifikats kann eine asymmetrische Verschlüsselung stattfinden. Der Client verschlüsselt mit dem öffentlichen Schlüssel des Zertifikats. Dies kann dann nur durch den privaten Schlüssel des Zertifikats entschlüsselt werden.
    • Unter dieser Verschlüsselung wird ein zufälliger symmetrischer Schlüssel ausgetauscht, der für den weiteren Verlauf der Verschlüsselung verwendet wird. Die symmetrische Verschlüsselung ist weniger prozessorbelastend und darum auch schneller.

    Zertifizierung der Zertifikate

    Damit der Client die Echtheit des Zertifikats prüfen kann, müsste er jedes Zertifikat eines Webservers weltweit mit sich führen. Das ist nicht machbar.

    Wie bei einem Personalausweis, der durch den Stempel des Ausstellerlandes autorisiert wird, geht man bei Zertifikaten vor. Es gibt es Zertifikatsautorisierungsstellen (CA - Certificat Authority), die Zertifikate quasi zertifizieren.

    Dazu sendet man sein Zertifikat an die CA, die mit ihrem privaten Schlüssel das Zertifikat autorisiert. Parallel macht die CA-Stelle ihren öffentlichen Schlüssel verfügbar. Beispielsweise enthält ein Browser bereits eine Bibliothek der relevanten CA-Stellen. Zeigt der öffentliche CA-Schlüssel, dass das Zertifikat von einer bekannten CA-Stelle autorisiert wurde, kann der Client das Zertifikat bedenkenlos verwenden.

    Das CA-Zertifikat wird nicht zur Verschlüsselung verwendet, sondern um das Zertifikat zu autorisieren, das zur Verschlüsselung verwendet wird. Wenn die CA also betrügerisch wäre, käme sie dennoch nicht an die verschlüsselten Daten.

    Für das eigene Netzwerk kann man das CA-Zertifikat auch selbst erstellen. Das ist bei Intranet-Anwendungen durchaus sinnvoll, weil die meisten Browser auf Zertifikate ohne bekannte CA sehr aufgeregt reagieren, was sich leicht auf die Anwender überträgt, die mit Warnungen überhäuft werden.

    • Der private CA-Key wird benötigt, um das Zertifikat zu autorisieren.
    • Der öffentliche CA-Key muss zum Browser, damit er bestätigt, dass das Zertifikat autorisiert ist. Aber auch der Server benötigt ein Exemplar.

    Browser-Einbindung

    Beim Firefox wird der öffentliche CA-Key über die drei waagerechten Striche, die neuerdings ein Menü darstellen sollen und dann über folgende Schritte eingefügt.
    1. Einstellungen|Erweitert|Zertifikate
    2. Dort wählen Sie den Button Zertifikate anzeigen.
    3. Klicken Sie auf den Reiter Zertifizierungsstellen.
    4. Dort wählen Sie den Button Importieren. In der nun erscheinenden Dateiauswahlbox können Sie die Datei auswählen.

    Webserver mit kombinierten Schlüsseln

    Bei einigen Webservern kann der öffentliche CA-Schlüssel nicht separat eingebunden werden. In diesen Fällen ist es möglich, den öffentlichen CA-Schlüssel direkt an das öffentliche Zertifikat anzuhängen. Das funktioniert mit einem einfachen Linux-Standardbefehl: 
    cat ca-pub.pem >> zertifikat-pub.pem

    Konfigurieren des Apachen für HTTPS

    Damit der Apache HTTPS verwendet, muss er den Port 443 betreuen und das Modul ssl installiert haben. In der VirtualHost-Konfiguration müssen die Pfade zu den Zertifikaten liegen und natürlich muss festgelegt werden, wo die HTML-Dateien liegen sollen.

    Port 443 und Modul ssl

    Zunächst wird überprüft, ob der Apache den Port 443 vielleicht bereits bedient. Zum Scannen offener Ports dient das Tool nmap, das allerdings erst installiert werden muss. 

    # apt update
# apt install nmap
# nmap 127.0.0.1
    Sollte der Port 443 nicht auftauchen, kontrolliert man, ob es in der Datei /etc/apache2/ports.conf eingetragen ist. Das sieht normalerweise so aus: 
    <IfModule mod_gnutls.c>
        Listen 443
</IfModule>
    Schließlich wird das Modul ssl aktiviert. Dann muss Apache neu gestartet werden. 
    # a2enmod ssl
# systemctl restart apache2

    Verweis auf die Zertifikate in der VirtualHost-Konfiguration

    Für den Apachen liegt nach der Installation bereits eine Default-Konfiguration für SSL unter /etc/apache2/sites-available/default-ssl.conf vor. Diese Konfiguration muss nur angepasst und aktiviert werden. Abgesehen von Kommentaren enthält sie folgende Einträge: 
    <IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
        SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    </VirtualHost>
</IfModule>
    Zunächst prüft die Konfiguration, ob das Modul ssl installiert ist. In der Folgezeile der Konfiguration wird der Zugriff für den Port 443 zugelassen, dem Standard-Port von HTTPS. Die anderen Einträge unterscheiden sich nicht von der Standardkonfiguration, nur die mit SSL beginnenden Direktiven sind neu. Sie sollten auf die erstellten Dateien verweisen. 
    SSLCertificateFile    /etc/apache2/ssl/zertifikat-pub.pem
SSLCertificateKeyFile /etc/apache2/ssl/zertifikat-priv.pem
...
SSLCertificateChainFile: /etc/apache2/ssl/ca-pub.pem
    • SSLCertificateFile zeigt auf den öffentlichen Teil des Zertifikats.
    • SSLCertificateKeyFile enthält den passenden privaten Tei.
    • SSLCertificateChainFile verweist auf den öffentlichen Teil des CA-Zertifikats, den Sie vom Zertifizierer erhalten.
    Natürlich müssen zuvor die Dateien in die angegebenen Verzeichnisse geschoben werden.

    Die so angepasste Datei liegt im Verzeichnis sites-available, muss aber noch im parallelen Verzeichnis sites-enabled auftauchen. Das macht man nach guter UNIX-Sitte mit einem symbolischen Link: 

    cd /etc/apache2/sites-enabled
ln -s ../sites-available/default-ssl.conf 001-ssl.conf
    Das Apache-Modul für mod_ssl wird, falls noch nicht vorhanden, installiert. 
    apt install libapache2-mod-gnutls
    Das Modul SSL wird freigeschaltet. 
    a2enmod ssl
    Nach allen Konfigurationsänderungen muss der Apache neu gestartet werden: 
    systemctl restart apache2