Webserver mit Apache

Einer der häufigsten genutzten Webserver ist Apache. Abgesehen davon, dass man bereits mit der Standardkonfiguration relativ schnell zu einer einfachen Website kommt, bringt er den Vorteil, dass viele Module bereits eingbunden oder schnell nachzuinstallieren sind (z.B. libapache2.php). Zudem werden regelmäßig Updates gegen mögliche Exploits auf diesen weit verbreiteten Webdienst geliefert, also Versionsstand aktuell halten! Zum Entstehungszeitpunkt dieses Dokuments war die aktuellste Version der apache2. Wir verlassen uns aber nicht auf diese Aussage, sondern prüfen den Versionsstand selbst nach mit

# aptitude search apache

Danach installieren wir die aktuellste Version:

# aptitude install apache2

Nach der Installation läuft der Dienst auch schon. Überprüfung mit

# ps auxw | grep apache

Konfigurationsdateien

Diese befinden sich im Verzeichnis /etc/apache2. Die wichtigste Datei ist die apache2.conf. Diese verweist auf weitere Dateien und Unterverzeichnisse.
In einem Standard /etc/apache2-Verzeichnis wird man folgende Dateien und Ordner vorfinden:

apache2.conf    
conf-enabled  
magic           
mods-enabled  
sites-available
conf-available
envvars
mods-available
ports.conf
sites-enabled

Dies ist die Verzeichnisstruktur für Debian. Andere Distributionen können sich anders verhalten, z.B. werden unter CentOS keine sites-available/sites-enabled verwendet. Wie gesagt, handelt es sich bei der apache2.conf um die Hauptkonfigurationsdatei. Diese nur mit Vorsicht anfassen, weil Gefahr besteht, dass die Änderungen mit dem nächsten Update überschrieben werden.

Die eigentliche Konfigurationsdateien befinden sich in sites-available bzw. conf-available. Meistens wird sites-available für selbst erstellte Konfig benützt und conf-available für Konfig, die aus Software-Paketen mitgeliefert wird (z.B. Nagios oder Mediawiki). Die Dateien, die hier abgelegt werden, sind aber noch nicht aktiv. Dies passiert per Symlink in den Verzeichnissen conf-enabled und sites-enabled. Darauf achten, dass die Symlinks immer mit .conf enden !

Module

Module sind kleine Codestücke oder Konfigschnipsel, die die Funktionalität des Webservers erweitern. es gibt z.B. welche für andere Scriptsprachen (php, cgi), für Verschlüsselung, Authentifizierung u.v.m. Im Verzeichnis mods-available sind bereits einige Standardmodule abgelegt. Diese lassen sich durch einen Symlink im mods-enabled Verzeichnis aktivieren oder durch das a2enmod Kommando, z.B.

# a2enmod ssl

Wohin mit den Webseiten

Der Standardordner für Webseiten ist das Verzeichnis /var/www/. Wer weitere/andere Verzeichnisse festlegen will, kann das in der Datei sites-available/default im Abschnitt DocumentRoot tun. Wir wollen in unserem Fall die Standardwebseite im Verzeichnis /var/www haben. Zu diesem Zweck ändern wir in der Datei sites-available/default den Eintrag

             RedirectMatch ^/$ /apache2-default/

in

             RedirectMatch ^/$ /index.html

(setzt natürlich voraus, dass mit einer Datei index.html begonnen wird)

Neustart des Apache nach Konfigurationsänderungen erfolgt mittels

# systemctl reload apache2

Virtual Hosting

Mal angenommen, ihr entschließt euch, mehrere Domains auf einem Webserver zu hosten. Dafür gibt es die Virtual-Host-Einträge in der Datei sites-available/default. In unserem Fall wollen wir 2 Domains hosten, example.de unter /var/www/kdxxl und nomorebluescreen.com unter /var/www/nmbs. Zu diesem Zweck werden unter /etc/apache2/sites-available 2 Dateien angelegt, z.B. example.conf und kdxxl.conf.

1. Datei:

 <VirtualHost *:80>
       ServerName www.example.de
       ServerAlias ...
       ServerAdmin webmaster@example.de
       (...)
 </VirtualHost>

2. Datei:

<VirtualHost *:80>
       ServerName www.nomorebluescreen.com
       (...)
</Virtual Host>

Der Webserver liefert per Default immer die Datei aus, die im Alphabet als erstes kommt. Wer eine bestimmte Domain als Default haben will, sollte diese unter /etc/apache2/sites-available/000-default.conf unter ServerName eintragen. Um die Änderung wirksam zu machen, müssen diese Seiten noch nach sites-enabled verlinkt sein. Hierbei darauf achten, dass die Dateiendung .conf ist, sonst wird die Datei ignoriert.

Die entsprechenden Namen müssen natürlich im DNS (oder zu Testzwecken auch in der /etc/hosts) hinterlegt sein!

Test

Standardeinstellungen: Ein Connect mit dem Browser auf die IP des Webservers sollte die eingestellte Indexseite oder den Apache-Default „It works!“ zeigen. Virtual Hosting: Nach Eingabe der unterschiedlichen Servernamen sollten die entsprechenden Webseiten zu sehen sein.

Ein einfacher Configcheck geht mit

apache2ctl -t

Hier sollte "Syntax OK" zurückkommen.

Logfiles

Diese befinden sich im Verzeichnis /var/log/apache2

Mit der Direktive

CustomLog

bzw.

ErrorLog

in der entsprechenden Konfigdatei kann (auch für VirtualHosts getrennt) der Pfad zur Logdatei angegeben werden.

Es gibt die Möglichkeit, die geloggten Parameter selbst zu definieren: https://httpd.apache.org/docs/2.4/logs.html#accesslog

Hier ein paar Beispiele, wie man in den Logfiles suchen kann:

request per hour
cat access.log | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $2":00"}' | sort -n | uniq -c

request per hour by date
grep "23/Jan" access.log | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $2":00"}' | sort -n | uniq -c

request per hour by IP
grep "XX.XX.XX.XX" access.log | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $2":00"}' | sort -n | uniq -c

requests per minute:
cat access.log | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $2":"$3}' | sort -nk1 -nk2 | uniq -c

requests per minute for date:
grep "02/Nov/2017" access.log | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $2":"$3}' | sort -nk1 -nk2 | uniq -c

requests per minute for url:
grep "[url]" access.log | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $2":"$3}' | sort -nk1 -nk2 | uniq -c

per IP per minute
grep "XX.XX.XX.XX" access.log | cut -d[ -f2 | cut -d] -f1 | awk -F: '{print $2":"$3}' | sort -nk1 -nk2 | uniq -c

s.a. http://www.inmotionhosting.com/support/website/server-usage/view-level-of-traffic-with-apache-access-log

php einbinden

Dies ist zumindest unter Debian sehr trivial, weil nur das Paket php und das entsprechende Modul installiert werden muss.

Mit

# aptitude search php

informieren wir uns über die aktuelle Version. Mit "aptitude install php<version>" wird diese installiert.

Um den apache php-fähig zu bekommen, muss außerdem das php-Modul installiert werden (wird u.U. schon bei der apache-Installation mitgeliefert):

# aptitude install libapache2-mod-php

Kontrollieren, ob das Modul bereits geladen ist:

# ls /etc/apache2/mods-enabled/|grep php

Hier sollte (je nach Version) zu sehen sein:

php7.0.conf
php7.0.load

Wenn nicht, gibt es den Befehl a2enmod, um Module zu installieren:

# a2enmod php7

Der Neustart des apache wird während der php-Installation übernommen. Hier ein Beispiel für ein schlichtes Testscript:

<?php
   phpinfo();
?>

Bei Ausführung desselben ist im Browser folgende Auflistung zu sehen

Directory Listing erlauben

Wenn in einem Unterverzeichnis von DocumentRoot eine Index-Datei (index.html, index.php, ... ) fehlt, bekommt der Benutzer normalerweise eine Fehlermeldung

Forbidden
You don't have permission to access /images/ on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Wenn man stattdessen möchte, dass der Benutzer alle Dateien aufgelistet bekommt, muss man folgendes einrichten

<Directory /var/www/images>
	Option +Indexes
</Directory>

Falls die Option auf alle Verzeichnisse zutreffen soll, die den String „images“ enthalten, macht man besser einen DirectoryMatch

<DirectoryMatch images>
       Option +Indexes
</DirectoryMatch>

Security

.htaccess und .htpasswd

Zum Passwortschutz einzelner Ordner bieten sich o.g. Dateien an. Die .htaccess beinhaltet, wer sich überhaupt wie anmelden darf, die .htpasswd beinhaltet die Passwörter

Beispiel für eine .htaccess:

AuthType basic 
AuthName "Access limited"
AuthUserFile /var/www/download/.htpasswd
Require valid-user

Die .htpasswd wird mit folgendem Command erzeugt

htpasswd -c <dateiname> <username>

Dann erfolgt eine Eingabeaufforderung für das Passwort. Vorhandene User in einer htpasswd ändert man durch Weglassen der Option -c

Die .htaccess schützt automatisch auch alle Unterverzeichnisse durch ein Passwort. Wenn man das nicht will, muss man in seiner Config für jedes der Verzeichnisse eine Ausnahme generieren, z.B.

<DirectoryMatch "/fotos/fotoclub/example/images/">
               Satisfy any
</DirectoryMatch>

Fail2ban

Zum Ausbremsen von Brute-Force-Angriffen hilft fail2ban, ein Tool, das zu häufige Fehlversuche beim Anmelden mit einer IP-Tables-Regel auf die zugehörige Source IP quittiert.

Beispiel

Erstmal das Paket „fail2ban" installieren, dann ins Verzeichnis /etc/fail2ban wechseln.

Die Optionen in der fail2ban.conf sind normal bereits auf sinnvolle Werte gesetzt. Gegebenenfalls lässt sich bei Problemen noch das Loglevel raufsetzen

loglevel = 4 # default=3

Achtung: nach dem Debuggen wieder auf default (=3) setzen. Die Logfiles werden sonst sehr schnell sehr groß!
Nun kann man in der jail.conf die unterschiedlichen jails für die einzlenen Dienste einrichten, also für apache:

[apache]

enabled  = true 
port     = http,https
filter   = apache-auth
logpath  = /var/log/apache*/*error.log
maxretry = 10 
bantime = 300

Bei den allgemeinen Optionen kann man Excludes für einzelne IPs oder Netze angeben

ignoreip = 127.0.0.1/8 192.168.99.0/24

Achtung: Als Trenner ein Space benutzen. Kommas o.ä. werden zwar akzeptiert, danach funktioniert aber die Banaction nicht. Bei „banaction“ sollte im allgemeinen Teil „iptables-multiport" eingestellt sein. Dienst neu starten, fertig.

Erfolgskontrolle
n- mal falsch anmelden und „iptables -L -n -v“ ausführen (zum testen evtl. eine etwas kürzere bantime wählen)

Debugging
Bei Problemen kann man den Dienst auch im Vordergrund starten:

# fail2ban-server -f

und in einer anderen Shell

# fail2ban-client reload

Verschlüsselte Webseiten

Feind hört mit (Gerüchten zufolge zuweilen auch Freund). Also am besten nichts im Klartext übers Netz schicken. Verschlüsselt wird bei apache üblicherweise mit TLS, die Echtheit (Authentizität) der Webseite wird durch ein Zertifikat überprüft. Wer geschäftlich eine Seite (Webshop o.ä.) betreibt, wird sein Zertifikat höchstwahrscheinlich durch eine offizielle Zertifizierungsstelle (Certificate Authority) signieren lassen, Privatanwender signieren i.d.R. selbst.

Schritte von der Zertifikatserstellung zur verschlüsselten Webseite:

1. Verzeichnis für Zertifikate anlegen

mkdir /etc/apache2/ssl/

2. Request, Key und gleichzeitig Zertifikat erstellen

openssl req -x509 -nodes -days 720 -newkey rsa:4096 -keyout /etc/apache2/ssl/www.example.de.key -out /etc/apache/ssl/www.example.de.crt

Darauf achten, dass bei FQDN unbedingt der Servername eingetragen wird, unter dem der Webserver erreichbar ist (i.d.R. identisch mit dem Wert für ServerName im apache)

Alternative Cert Request für offizielle CA erstellen

1. Key erstellen

openssl genrsa -out www.example.de.key 4096

2. Zertifikats-Request erstellen

openssl req -new -key www.example.de.key -out www.example.de.csr

3. Das .csr file an die Zertifizierungsstelle schicken
in der Regel kommt z.B. ein File namens www.example.de.crt zurück
4. Überprüfen des Zertifikats:

openssl x509 -in www.example.de.crt -text -noout

Alternativ bietet sich das im Paket openssl enthaltene Tool CA.pl an (hier nicht weiter ausgeführt, da ungetestet).

5. Apache konfigurieren
 5.1. mod_ssl aktivieren

cd /etc/apache2/sites-enabled/
ln -s ../mods-available/ssl.conf
ln -s ../mods-available/ssl.load

 5.2. Virtual-Host auf Port 443 einrichten

<VirtualHost *:443> 	  	
                ServerAdmin webmaster@example.de
       	  	ServerName  www.example.de:443
       	  	ServerAlias mail.example.de:443
       	  	SSLEngine on
       	  	SSLCertificateFile       /etc/apache2/ssl/www.example.de.crt
       	  	SSLCertificateKeyFile    /etc/apache2/ssl/www.example.de.key
                SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
                SSLCipherSuite \ EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
</VirtualHost>

Letztere Parameter lassen nur sichere Protokolle (TLS>=2) und Cipher-Suites mit starker Verschlüsselung zu.
Ein Beispiel für geeignete Cipher-Suites gibt es auf https://cipherlist.eu/.

 5.3. Redirects
Wer es nicht dem Zufall überlassen will, ob der Benutzer im Browser http:// oder https:// eingibt, kann eine automatische Weiterleitung zur verschlüsselten Seite einrichten:

a2enmod rewrite

Dann im VirtualHost:80-Abschnitt folgendes eintragen (z.B. wenn „download“ im URL-Name dann auf https umleiten)

       RewriteEngine On
       RewriteCond %{HTTPS} !=on
       RewriteRule ^/?download(.*) https://%{SERVER_NAME}/download/$1 [R,L]

Immer verschlüsseln

Wer immer von http auf https umleiten will, kann in seine Config folgendes eintragen:

RewriteCond %{HTTPS} !=on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}  [L]

Alternative letsencrypt

Hier sind keine openssl-Commands nötig. Signiert wird über einen sogenannten „certbot“, der einmalig eingerichtet wird und dann als Cron weiterläuft.

# apt install python3-certbot-apache

Eine Art Manpage erhält man mit dem Command

# certbot (--help)

Initial Zertifikate erzeugen

root ##i## # certbot --apache certonly

(interaktive Abfragen z.B. fqdn, evtl. config file)

Anschließend hat man im Verzeichnis /etc/letsencrypt haufenweise neue Dateien. Die eigentlichen Zertifikate findet man im Verzeichnis „live“.

• archive: Alte Zertifikate
• options-ssl-apache.conf: Configschnipsel
• accounts: private Key fürs Erzeugen der nonce (don't lose!)

Die Zertifikate, die automatisch erzeugt werden, landen im renewal Verzeichnis.

Die entstandenen Zertifikate können entweder ins entsprechende Verzeichnis (/etc/ssl/...) kopiert werden (dann muss man aber dafür sorgen, dass das ggf. automatisch passiert) oder man verwendet den direkten Pfad in der Konfig, z.B.:

SSLCertificateFile            /etc/letsencrypt/live/mail.example.de/fullchain.pem     
SSLCertificateKeyFile     /etc/letsencrypt/live/mail.example.de/privkey.pem

Wobei fullchain.pem sowohl das Zwischenzertifikat als auch das eigentliche Zertifikat enthält.

In der Datei /etc/cron.d/certbot sollte sich der Cronjob befinden, der alle 12h prüft, ob ein Zertifikat < 30 Tage gültig ist und ggf. erneuert. Natürlich lässt sich der Certbot auf alle Virtual Hosts anwenden.

Manuell erneuern

root ##i## # cerbot renew

Error

Sollten beim Erneuern Fehlermeldungen auftauchen aka

An unexpected error occurred:
OpenSSL.SSL.Error: [('x509 certificate routines', 'X509_load_cert_crl_file', 'no certificate or crl found')]
Please see the logfiles in /var/log/letsencrypt for more details.

gibt es ein Problem mit den default ca-certificates. In dem Fall hilft ein:

># update-ca-certificates

Das waren die ersten Schritte mit Apache. Viel Spaß beim Konfigurieren und Probieren!