© Warawoot Nanta, 123RF

Cyberangriffe machen auch vor dem altgedienten HTTP-Server Apache nicht halt. Doch eine ausgefeilte Konfiguration, zeitnahe Updates und durchdachte Sicherheitskonzepte bewahren ihn vor dem Untergang.

Egal, ob man Apache selbst kompiliert oder ein Paket aus einem Repository verwendet: Es gilt, die Software aktuell zu halten und Sicherheitslücken möglichst zeitnah zu schließen. Dazu empfiehlt sich ein Abonnement der Announce-Mailingliste http://httpd.apache.org/lists.html#http-announce. Neben der Webserver-Software selbst sollte man auch für Updates bei Interpretern wie PHP, Python oder Perl sowie bei den verwendeten Webapplikationen sorgen. Zu guter Letzt patcht jeder sicherheitsbewusste Admin auch das darunterliegende Betriebssystem laufend.

Installation, Module und Updates

Als eine erste Maßnahme empfiehlt es sich grundsätzlich, unnötige Module zu deaktivieren. Unter Debian und Ubuntu klappt das ganz einfach mit dem Kommando »a2dismod«. Ansonsten muss man sich auf die Suche nach der »LoadModule«-Direktive machen.

Zu den ersten Kandidaten für das Deaktivieren zählen Autoindex, CGI/CGId, Include, Userdir und Suexec. Welche Module bereits fix einkompiliert sind, stellen Sie mit »apache2 -l« fest. Nach dem Deaktivieren von Modulen rufen Sie vor dem Neustart von Apache das Kommando »apache2ctl -t« auf, das eine syntaktische Prüfung der Konfiguration anstößt. Im Ergebnis sehen Sie unter anderem, ob das Modul, das Sie deaktivieren wollten, noch referenziert wird.

Auch der Einsatz einer Firewall – entweder zentral oder auch direkt im Betriebssystem – ist sinnvoll. Auf diesem Weg limitieren Sie etwa die Anzahl der eingehende Verbindungen pro IP (bei Iptables »connlimit«, bei Nftables Meters oder Dynamic Sets). Außerdem ist es oft nicht notwendig, auf einem Webserver alle ausgehenden Verbindungen zu erlauben. Die Iptables-Regel aus Listing 1 etwa verbietet ausgehenden Traffic des Systembenutzers www-data, der zu keiner bestehenden Verbindung gehört.

# iptables -A OUTPUT -m owner --uid-owner www-data -m state --state new -j DROP

Zusätzliche Sicherheit auf Betriebssystemebene lässt sich durch SELinux (Red Hat, Suse) oder AppArmor (Debian, Ubuntu) erreichen. Beide Erweiterungen realisieren eine Zugriffskontrolle via Mandatory Access Control (MAC) und sind extrem mächtig, benötigen aber auch einiges an Einarbeitungszeit.

Eigentlich selbstverständlich sollte es sein, den Webserver mittels einer Monitoring-Lösung wie zum Beispiel Icinga oder Zabbix zu überwachen. Dadurch kann man zeitnah auf Ausfälle reagieren. Zu den weiteren sinnvollen Erweiterungen zählen Intrusion-Prevention/Detection-Systeme (IPS/IDS), wie etwa Suricata oder OSSEC aus dem Open-Source-Bereich. Zu einem umfassenden Sicherheitsmanagement gehört außerdem die Prüfung von Log-Dateien auf mögliche Angriffe sowie im Optimalfall die Integration in ein SIEM-System (Security Information and Event Management).

Konfiguration

Momentan gibt es 90 Direktiven für die Konfiguration des Apache-2.4-Cores [1]. Auf alle Fälle vertraut sollte man mit den Konfigurationsgruppen »<Directory>«, »<Files>«, »<Limit>«, »<Location>« und »<VirtualHost>« sein. Wer schon viele Jahre mit Apache arbeitet, wirft am besten einen Blick auf die Änderungen in Version 2.4 [2]. Dazu zählt unter anderem das neue Zugriffsmodul »mod_authz_host« mit der Direktive »Require«, die die bisherige Syntax »Order«/»Allow«/»Deny« ablöst.

Ohne explizite Konfiguration erlaubt »<Directory>« den Zugriff auf das gesamte Root-Dateisystem, was sich nur durch die in Listing 2 gezeigte Konfiguration unterbinden lässt. Im Anschluss stattet man je nach Bedarf nur die tatsächlich verwendeten Unterverzeichnisse mit mehr Rechten aus.

<Directory "/">
  Options None
  AllowOverride None
  Require all denied
</Directory>
<Directory "/var/www/html/">
  Require all granted
</Directory>

Ein aktiviertes »FollowSymLinks« erlaubt das Verfolgen von symbolischen Links im Dateisystem. Hier sollten Sie daran denken, dass man über einen symbolischen Link beispielsweise auch an die Datei »/etc/passwd« gelangen könnte. Eine sicherere Variante stellt hier »SymLinksIfOwnerMatch« dar, die dem Link nur dann folgt, wenn die Besitzer von Symlink und Ziel identisch sind.

Die »Options« steuern, welche Funktionen in einem Verzeichnis verfügbar sind. »Indexes« beeinflusst das Verzeichnis-Listing, »Include« und »ExecCGI« erlauben oder verbieten Server-Side-Includes via »mod_include« beziehungsweise CGI-Skripte via »mod_cgi«. Ein Beispiel für eine sehr restriktive Konfiguration der »Options«-Direktive zeigt Listing 3.

<Directory "/var/www/html/">
  AllowOverride None
  Options -Indexes -Includes -ExecCGI -FollowSymLinks
</Directory>

Options lassen durch Verwenden von »+« und »-« auch eine Vererbung zu. In der Konfiguration in Listing 4 gilt für das Verzeichnis »/var/www/html/help« effektiv dann »FollowSymLinks« und »Includes«.

<Directory "/var/www/html/">
  Options Indexes FollowSymLinks
</Directory>
<Directory "/var/www/html/help">
  Options +Includes -Indexes
</Directory>

Die Direktive »AllowOverride« verdient besondere Beachtung, da sie den Umgang mit den sehr mächtigen ».htaccess«-Dateien bestimmt. »None« deaktiviert die Verwendung von ».htaccess«-Files. Mit »AuthConfig«, »FileInfo«, »Indexes« und »Limit« können Sie bestimmte Einstellungen erlauben. Ist ein direkter Zugriff auf die Apache-Konfiguration möglich, sollten Sie generell von der Verwendung von ».htaccess« absehen. Es ist sinnvoll, Konfiguration und Inhalt zu trennen.

Analog zu »<Directory>« lassen sich mit der Direktive »<Files>« Einschränkungen für bestimmte Dateinamen vornehmen. Im Beispiel aus Listing 5 untersagen die Zeilen 1 bis 3 etwa den Download von ».htaccess«- und ».htpasswd«-Dateien. Via »Limit« schränken Sie den Zugriff auf gewisse HTTP-Methoden ein (Zeile 4 bis 6). In diesem Fall hat nur ein erfolgreich authentifizierter Benutzer Zugriff auf die angegebenen Methoden. Die Direktive »<Location>« bezieht sich auf die URL und sollte nur dann zum Einsatz kommen, wenn es um Inhalte außerhalb des Dateisystems geht (Zeile 7 bis 10).

<Files ".ht*">
    Require all denied
</Files>
<Limit POST PUT DELETE>
   Require valid-user
</Limit>
<Location /status>
   SetHandler server-status
   Require ip 192.0.2.0/24
</Location>

Zuerst werden immer »<Directory>« sowie »<Files>« abgearbeitet. Mit »DirectoryMatch«, »FilesMatch« und »LocationMatch« lassen sich jeweils auch reguläre Ausdrücke verwenden, wie in folgendem Beispiel:

<FilesMatch "\.(gif|jpe?g|png)$">

Man sollte immer auch dem Kontext Beachtung schenken, in dem einzelne Direktiven Gültigkeit haben. Die offizielle Dokumentation zeigt ihn auf (siehe Abbildung 1).

Abbildung 1: Auszug aus der Apache-HTTP-Dokumentation, die auch den Kontext der Direktive zeigt.

Sicherheitsfragen

Oft wird in der Sicherheitsdiskussion auf die Direktiven »ServerTokens« und »ServerSignature« verwiesen. Generell erhöht ein Verstecken der Webserver-Software oder Versionsnummer nicht wirklich die Sicherheit; auf Updates darf man trotzdem auf keinen Fall verzichten. Immerhin malt man sich nicht gleich das Fadenkreuz auf die Stirn, indem sich der Webserver mit einer völlig veralteten Version meldet.

»ServerSignature« steht per Default auf »Off«, was bedeutet, dass Apache normalerweise den Seiten keine Fußzeile mit Apache Server at www.example.com Port 443 hinzufügt. Im Gegensatz dazu ist »ServerTokens« in der Voreinstellung auf »Full« gestellt, die resultierende Ausgabe erfolgt über einen Header. Über »wget -s« (»–server-response«) kann man diesen Header abfragen.

Hier empfiehlt sich in der Regel eine andere Einstellung, um nicht sofort möglichst viel über den Webserver zu verraten. Mit der Minimalvariante »Prod« gibt der Server nur den Namen Apache aus (Listing 6). Die Direktiven »FileETag« und »TraceEnable« sollte man aus Sicherheitsgründen mit »None« beziehungsweise »off« deaktivieren.

ServerSignature Off
ServerTokens Prod

DoS-Attacken abwehren

Die folgenden Direktiven bieten sich an, um Apache besser gegen Denial-of-Service-Angriffe abzusichern:

• »RequestReadTimeout«
• »TimeOut«
• »KeepAliveTimeout«
• »LimitRequestBody«
• »MaxRequestWorkers« (früher »MaxClients«)
• »MaxConnectionsPerChild« (früher »MaxRequestsPerChild«)

Die Timeout-Optionen haben Einfluss darauf, wie lange Apache Verbindungen offenhält. Aktuelle Apache-2.4-Versionen nutzen meist sinnvolle Voreinstellungen; bei der Version 2.2 war etwa »RequestReadTimeout« noch auf »0« gesetzt.

»LimitRequestBody« hat auch in der aktuellen Apache-Version den Wert null, was bedeutet, dass ein Client grundsätzlich unlimitierte Datenmengen übermitteln darf. Mit »MaxRequestWorkers« lässt sich steuern, wie viele gleichzeitige HTTP-Verbindungen erlaubt sind. Das sollte man immer im Einklang mit dem vorhandenem RAM festlegen. »MaxConnectionsPerChild« verzichtet standardmäßig auf eine Limitierung. Hier kann ein Limit sinnvoll sein, damit Prozesse im Falle von Memory-Leaks den schon verbrauchten Arbeitsspeicher überhaupt wieder freigeben.

HTTP-Header

Es gibt einige Möglichkeiten, durch das Setzen von HTTP-Headern die Sicherheit von Webseiten zu erhöhen. Das klappt einerseits im HTML-Code sowie mit serverseitigen Skriptsprachen, andererseits auch zentral über die Apache-Konfiguration. Die Beispiele aus Listing 7 zeigen mögliche Einsatzszenarien.

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header always set Strict-Transport-Security "max-age=63072000"
Header always append X-Frame-Options SAMEORIGIN
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options nosniff
Header always set Content-Security-Policy "default-src 'mailto' 'self'"

Das »HttpOnly«-Flag verhindert das Auslesen von Cookies mit Skriptsprachen wie Java- oder VB-Script. Das »Secure«-Flag übermittelt das Cookie nur bei einer verschlüsselten HTTPS-Verbindung. Der »Strict-Transport-Security«-Header aktiviert HSTS für eine Domain. Dies stellt sicher, dass bei zukünftigen Besuchen der Browser die konkrete Domain immer automatisch mit HTTPS aufruft und einen HTTP-Zugriff verweigert. Die restlichen Optionen zielen auf den Schutz vor Cross-Site-Scripting (XSS) und ähnlichen Attacken auf den Browser ab.

Einen guten Überblick über bereits umgesetzte Sicherheitsmaßnahmen bei einer Webseite sowie weiterführende Empfehlungen (Abbildung 2) gibt das Mozilla HTTP Observatory [3].

Abbildung 2: Das Mozilla HTTP Observatory zeigt, dass es bei der Webseite des Linux-Magazins noch Potenzial für Optimierungen gibt.

TLS/SSL-Konfiguration

Nachdem die meisten Browser mittlerweile vor unverschlüsselten HTTP-Verbindungen warnen, gehören HTTPS-Verbindungen schon zur Standardkonfiguration eines Webservers.

Einen guten Startpunkt für eine sinnvolle Konfiguration gibt der Mozilla SSL Configuration Generator [4] ab. Dort geben Sie die Server-Software mit exakter Apache- und OpenSSL-Version an und wählen dann das gewünschte Sicherheits-Level aus. Voreingestellt ist Intermediate, mit dem man in den meisten Fällen gut fährt. Wünschen Sie besonders hohe Sicherheit, greifen Sie zu Modern. Dann wird allerdings nur TLS 1.3 unterstützt, was bei viel besuchten Seiten sicherlich den ein oder anderen Besucher aussperrt. Optional lassen sich HSTS und OCSP-Stapling (HTTP Strict Transport Security und TLS-Zertifikatsstatusabfrage) aktivieren – beides ist zu empfehlen.

Abbildung 3: Der Mozilla SSL Configuration Generator hilft, die optimale Apache-TLS-Konfiguration zu finden.

Als Ergebnis erhalten Sie eine vorgefertigte Konfiguration (Abbildung 4), die Sie direkt in die eigenen Apache-Settings übernehmen können. Vor dem Aktivieren der Konfiguration via Neustart steht wieder eine Syntaxprüfung mit »apache2ctl -t« an.

Abbildung 4: Oberhalb der resultierenden Konfiguration gibt der Mozilla-Generator an, ab welcher Webbrowser-Version jeweils ein HTTPS-Zugriff gelingt.

Mithilfe der Webseiten Tls-check.de und Ssllabs.com prüfen Sie im Nachgang die TLS-Konfiguration. Die deutsche Variante Tls-check.de geht dabei nach den Technischen Richtlinien 03116, Teil 4 des Bundesamts für Sicherheit in der Informationstechnik vor. Diese Richtlinien sind auch eine gute Quelle, wenn es um seriöse Empfehlungen zum Thema TLS/SSL geht.

Let’s Encrypt mit <C>mod_md<C>

Das Modul »mod_md« (managed domain) ist seit Apache 2.4.30 dabei und steht somit ab Ubuntu 20.04 sowie Debian 10 zur Verfügung. Zusätzlich kümmert sich das Modul »mod_watchdog« um die periodischen Tasks. Das für die Zertifikatsausstellung zuständige ACME-Protokoll integrieren Sie durch »mod_md« direkt in die Apache-Konfiguration. In der einfachsten Variante sieht die Syntax so aus wie in Listing 8.

MDomain example.org
MDCertificateAgreement accepted
<VirtualHost *:443>
  ServerName www.example.com
  ServerAdmin hostmaster@example.com
  SSLEngine on
</VirtualHost>

Dadurch bezieht der Server automatisch ein neues Zertifikat bei Let’s Encrypt, das der virtuelle Host verwendet. Auch die Erneuerung läuft automatisch ab. Welche Let’s-Encrypt-Challenge greift, hängt davon ab, auf welchem Port Apache lauscht. Für Port 80 kann man die Http-01-Challenge verwenden, sonst TLS-ALPN-01 via Port 443.

Ein Wildcard-Zertifikat erfordert die DNS-01-Challenge. Dafür müssen Sie ein Skript angeben, das sich um das Anpassen der DNS-Einträge kümmert (»MDChallengeDns01 /usr/bin/acme-setup-dns«). Dieses Skript muss dann jeweils die zwei Aufrufe »acme-setup-dns setup example.com <challenge-data>« und »acme-setup-dns teardown example.com« unterstützen. Außerdem ist es nötig, eine gültige E-Mail-Adresse via »ServerAdmin« zu hinterlegen. Diese verlangt Let’s Encrypt verpflichtend und verwendet sie für wichtige Benachrichtigungen.

Wurde erfolgreich ein neues Zertifikat bezogen, kann man das im Apache-Log (Listing 9) erkennen. Anschließend ist zumindest ein Graceful Restart erforderlich. Da der auch bei einer Zertifikatserneuerung anfällt, ist ein automatischer Neustart via Cronjob sinnvoll.

[Fri Jan 01 13:41:06.880247 2020] [md:notice] [pid 776:tid 139942708430592] AH10059: The Managed Domain www.example.com has been setup and changes will be activated on next (graceful) server restart.

Das Modul »mod_md« erweitert »mod_status« um den Bereich »md-status«. Dadurch bekommt man einen JSON-Output zu einer bestimmten Domain geliefert. Die Abfrage erfolgt dann via »https://www.example.com/md-status/example.com«. Diese spezielle Statusseite lässt sich mit folgender Konfiguration aus Listing 10 aktivieren.

<Location "/md-status">
 SetHandler md-status
 Require ip 192.0.2.0/24
</Location>

In der Grundeinstellung lässt sich zusätzlich ein Zertifikatsstatus via »https://www.example.com/.httpd/certificate-status« abrufen. Den Zugriff darauf kann man via »MDCertificateStatus off« deaktivieren.

Möchten Sie keine Let’s-Encrypt-Zertifikate verwenden, können Sie das Modul »mod_md« auch zusammen mit anderen kommerziellen Zertifizierungsstellen nutzen. Hier gibt es mittlerweile einige Anbieter, die das standardisierte ACME-Protokoll unterstützen.

Web Application Firewall

Das Apache Modul »mod_security2« realisiert eine vollwertige Web Application Firewall (WAF). Da sich diese direkt in Apache integriert, funktioniert sie auch unabhängig davon, ob eine Verbindung mit HTTPS verschlüsselt erfolgt oder nicht. Die WAF kann direkt in den Request beziehungsweise in die Response des Webservers eingreifen. Das Modul kann also eingreifen und vor einem Angriff schützen, noch bevor der Request bei der Webapplikation ankommt.

Unter Ubuntu und Debian gestaltet sich die Installation dank eines bereits vorgefertigten Moduls im Repository sehr einfach. Die Installation erfolgt mit dem Kommando »apt install libapache2-mod-security2«. Danach benötigt man noch eine Konfigurationsdatei mit dem Namen »/etc/modsecurity/modsecurity.conf«. Das war es dann allerdings auch schon mit dem einfacheren Teil der Übung. Das Modul <»mod_security2« ist extrem mächtig, sodass wir an dieser Stelle nur einen kurzen Überblick geben können.

In der Grundeinstellung startet das Modul im Erkennungsmodus (»SecRuleEngine« »DetectionOnly«). Dadurch funktioniert die Webapplikation weiterhin wie gewohnt, und Sie können die Übereinstimmungen der Regelwerke prüfen. Unter Debian und Ubuntu finden Sie die Log-Datei in »/var/log/apache2/modsec_audit.log«.

Sie können alle Regeln, Allow- und Blocklists selbst erstellen. Es gibt aber auch kostenlose und gut gewartete Standardregeln, wie etwa das OWASP ModSecurity Core Rule Set. Es bietet laut eigenen Angaben Schutz vor vielen verschiedenen Angriffstypen [5].

Chroot versus Container

Mit dem Modul »mod_unixd« und der Direktive »ChrootDir« kann man Apache in einer Chroot-Umgebung betreiben. Bei einem simplen statischen Webserver funktioniert das mit wenig Aufwand.

Komplexer wird es, sobald man im Chroot auch Skriptsprachen verwenden möchte. Das funktioniert mit »mod_php« grundsätzlich auch im Chroot; im Detail stößt man aber schnell auf Einschränkungen bei gewissen Funktionen, wie etwa dem »mail«-Kommando. Dafür sind dann weitere Libraries und Konfigurationsdateien im Chroot-Verzeichnis erforderlich, was das Unterfangen schnell fehleranfälliger macht.

Als Alternative zum PHP-Modul bietet die FastCGI-Variante PHP-FPM eine eigene Chroot-Option an. Das Apache-Modul »mod_security2« offeriert zwar für denselben Zweck eine Direktive »SecChrootDir«, der Aufwand bleibt aber ähnlich.

Unabhängig von der Chroot-Möglichkeit bietet sich auch eine Isolierung in Containern an. Technisch klappt das entweder mit Docker oder LXC/LXD, was eigene Apache-Instanzen für einzelne Applikationen ermöglicht. Wenn man mit virtuellen Hosts IP-Adressen sparen muss, kann es in solch einem Szenario sinnvoll sein, einen Proxy vorzuschalten, der mit SNI (Server Name Indication) bei HTTPS-Verbindungen umgehen kann.

Fazit

Eine ausgefeilte Konfiguration, zeitnahe Updates und durchdachte Sicherheitskonzepte lassen sich nicht im Vorübergehen implementieren und erfordern die stete Aufmerksamkeit des Administrators. Beachten Sie aber alle Hinweise aus diesem Artikel zur Absicherung Ihres Webservers, müssen Sie sich keine allzu großen Sorgen mehr machen – dann sind die Schotten dicht. (jcb/jlu)