Wie Sie Ihren Webserver absichern - Beispiel Apache Webserver

In diesem Artikel zeigen wir Ihnen die Absicherung der Webserveranwendung am Beispiel von Apache, einem der meistbenutzten Webserver im Internet.

Selbstgemanagte vServer bieten Ihnen höchste Flexibilität und Leistungsstärke für Ihre Webprojekte 

Schwachstellen vermeiden

Bei der Absicherung des Webservers müssen zwei Arten von Gefahren berücksichtigt werden: Sicherheitslücken und Konfigurationsfehler. In Bezug auf Sicherheitslücken gilt es zwei Regeln zu beherzigen:

1. Halten Sie Ihre Serveranwendung inkl. aller Module (auch von extern) stets aktuell!

2. Laden Sie am besten nur die Module, die Sie wirklich benötigen.

Zwar finden sich im Vergleich zu anderer Software in Apache relativ wenig kritische Sicherheitslücken, aber sie kommen doch vor. Die Schwachstellen-Datenbank CVE Details listet für die letzten 20 Jahre insgesamt 225 Lücken auf, von denen 14 in 2019 entdeckt wurden (vor Veröffentlichung aktualisieren – Daten zu 2020 noch nicht enthalten). Die meisten davon (79) sind Denial-of-Service-Schwachstellen (der Webserver reagiert nicht mehr), aber immerhin 25 würden sogar die Ausführung von unerwünschtem Code erlauben. Deshalb ist es wichtig, dass Web-Admins in Bezug auf mögliche Sicherheitsbedrohungen auf dem Laufenden bleiben und Updates zügig einspielen.

10% Rabatt auf alle DF Produkte

Jetzt 2-Jahre Laufzeit wählen!

Nur benötigte Module laden

Apache lädt im Standard zahlreiche Module, von denen Sie wahrscheinlich nicht alle benötigen. Wenn Sie die für Ihre Anwendung überflüssigen Module deaktivieren, erhöhen Sie nicht nur die Sicherheit (die meisten Security-Schwachstellen stecken in Modulen), sondern verbessern auch die Performance Ihres Servers. Allerdings lassen sich an dieser Stelle schlecht pauschale Empfehlungen aussprechen, nicht nur, weil es von Ihren Anforderungen abhängt, was Sie deaktivieren können, sondern auch, weil Apache auf unterschiedlichen Systemen nicht die gleichen Module standardmäßig lädt (auf Ubuntu sind es wesentlich weniger als auf RHEL/CentOS).

Welche Module Ihr Apache aktuell geladen hat, überprüfen Sie auf der Kommandozeile mit

apache2ctl -M

oder (bei RHEL-basierten Systemen sowie Windows) mit

httpd -M

Zur Deaktivierung eines Moduls verwenden Sie (auf Debian-basierten Systemen wie Ubuntu oder Linux Mint) den Befehl a2dismod zusammen mit dem jeweiligen Modulnamen. Ohne solche Angabe listet a2dismod Ihnen alle Module auf, die Sie deaktivieren können, ohne Apache neu zu kompilieren. Informieren Sie sich bei Ihren Deaktivierungskandidaten im Zweifelsfall über Funktion und Abhängigkeiten und testen Sie nach dem Deaktivieren (und Apache-Neustart) gründlich Ihr System.

Keine sensiblen Infos preisgeben

Würden Sie einem Hacker freiwillig mitteilen, mit welchen Softwareversionen von Anwendungen, Modulen oder Bibliotheken und mit welchen Einstellungen Sie Ihren Webserver betreiben? Natürlich nicht, denn Sie wissen ja, dass sich ein Hacker mit diesen Informationen ganz gezielt auf bekannte Schwachstellen Ihres Systems konzentrieren kann. Dennoch fanden sich, wie die c’t im Dezember 2020 berichtete, bei einem systematischen Test mehr als 70.000 de-Domains, bei denen solche Infos oder auch Benutzernamen, IP-Adressen von Besuchern und von diesen besuchte URLs oder Kennungen von Videokonferenzräumen öffentlich zugänglich waren. Zu den betroffenen Serverbetreibern gehörten auch große Organisationen wie Banken, das Bundesfinanzministerium und sogar IT-Sicherheitsspezialisten wie G-Data oder das BSI (CERT-Bund). Dies zeigt schon, dass es nicht immer ganz einfach ist, solche Effekte zu verhindern – dazu später mehr.

Apache gibt auf verschiedenen Wegen Informationen preis, die für den Admin nützlich, öffentlich sichtbar aber kritisch sein können. Das geschieht zum Beispiel in servergenerierten Seiten, z. B. Fehlermeldungen und Statusseiten, sowie in den Kopfzeilen von Antworten auf HTTP-Requests (HTTP-Response-Header). Im gerade erwähnten Test ging es um Infoseiten der Module mod_info (Serverkonfiguration) und mod_status (Server-Monitoring). Tipp: Auch diese beiden Module können Sie im Produktiveinsatz gefahrlos deaktivieren (siehe oben) und nur dann laden, wenn Sie entsprechende Infos brauchen.

Webserver absichern - Apache-Konfiguration bearbeiten

Um zu verhindern, dass die Ergebnisseiten von mod_info oder mod_status von jedermann gelesen werden können, müssen Sie die Konfiguration anpassen. Auch das ist wieder betriebssystemabhängig und geschieht normalerweise für die meisten hier genannten Punkte in der Konfigurationsdatei httpd.conf oder in separaten Dateien, die per include in diese eingebunden werden (Infos dazu finden sich jeweils im einleitenden Abschnitt der httpd.conf). Damit Konfigurationsänderungen wirksam werden, müssen Sie Apache neu starten.

Den Zugriff auf die Info- bzw. Statusseite schränken Sie über eine Require-Anweisung ein, etwa auf bestimmte Rechner (ip / host) oder auf Anwendungen auf dem gleichen System (local), zum Beispiel:

<Location "/server-status">
    SetHandler server-status
    Require host example.com
    Require ip 192.168.1.10
</Location>

bzw.

<Location "/server-info">
    SetHandler server-info
    Require host local
</Location>

Aber Achtung: Läuft auf dem gleichen System etwa ein Loadbalancer, erscheinen Apache alle Requests von lokal zu kommen. Zudem können sich Konfigurationsanweisungen verschiedener Bereiche überlagern und dadurch unter Umständen wirkungslos werden (ein Beispiel finden Sie im oben verlinkten c’t-Artikel).

Apache kann auch in der Fußzeile von servergenerierten Standardseiten, etwa von Fehlermeldungen wie 404 Not Found“, Systeminformationen einblenden. Die entsprechende Einstellung ServerSignature ist allerdings im Standard deaktiviert (ServerSignature Off). Sicherheitsrelevanter ist Apaches Angewohnheit, in der Voreinstellung bei jeder HTTP-Anfrage Informationen über Serverversion, Betriebssystem und einkompilierte Module im Response-Header „Server“ mitzuliefern, zum Beispiel:

Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

Mit der Einstellung ServerTokens (Standardeinstellung: Full) können Sie Apaches Auskunftsfreude zügeln: Durch

ServerTokens Prod

weisen Sie Apache an, sich im Server-Header auf die Nennung des „Produkts“ (Server: Apache) zu beschränken.

Berechtigungen

Im Kontext von Cyber-Sicherheit ist das Thema Zugriffsrechte besonders wichtig. Aufgrund seines Umfangs kann es hier leider nur angerissen werden (zu nützlichen Verzeichniseinstellungen bei Apache gibt es bald einen eigenen Beitrag). Apache muss mit Root-Rechten gestartet werden und wechselt dann zu einem (per Group und User definierten) speziellen Benutzer, um Requests zu bedienen. Dieser Benutzer sollte exklusiv für Apache reserviert sein und auf keinen Fall über Root-Rechte verfügen, damit bei einem erfolgreichen Hack des Webservers nicht das ganze System kompromittiert ist. Er darf auch keinen Schreibzugriff auf Verzeichnisse und Dateien haben, die von Root beschrieben bzw. ausgeführt werden. Stattdessen wird mit der Direktive DocumentRoot ein eigenes, für das Web bestimmtes Top-Level-Verzeichnis festgelegt (Standard bei Apache ist „/usr/local/apache/htdocs“). Verschiedene Linux-Distributionen definieren eigene Standard-Webverzeichnisse (z. B. „/var/www/html“) und auch Default-User für Apache (z. B. „apache“ oder „www-data“). Abzuraten ist von den früher gebräuchlichen Pseudo-Usern wie „nobody“ oder „daemon“, weil diese möglicherweise noch für andere Services verwendet werden.

Achten Sie auch darauf, dass die Schreibrechte für das Apache-Installationsverzeichnis (das Sie mit ServerRoot festlegen können, Standard ist „/usr/local/apache“), und seine Unterverzeichnisse („bin“, „conf“, „logs“) restriktiv gesetzt sind (chmod -r 755, nur Besitzer Root darf schreiben). Unter Umständen ist es sinnvoll, anderen Nutzern als Root auch das Anschauen von Programmverzeichnis und Konfiguration zu verbieten (chmod -r 750 bin conf).

Webserver absichern mit HTTP-Tweaks

Ein weiterer Weg, die Sicherheit Ihres Webservers zu erhöhen, sind HTTP-Tweaks – die Beeinflussung des Antwortverhaltens des Servers. Neben den schon erwähnten Maßnahmen zum Infoverhalten gehören dazu beispielsweise auch die Beschränkung der zulässigen HTTP-Methoden für Requests (etwa per LimitExcept) oder die gezielte Konfiguration von Antwort-Kopfzeilen per Header. Auch dazu gäbe es einiges zu sagen – mehr dazu finden Sie in einem separaten Beitrag.

Zu guter Letzt: Auch Profis kann es passieren, dass sie eine unsichere Einstellung ihrer Webserver-Konfiguration übersehen. Deshalb empfehlen wir Ihnen, auch einen Blick auf nützliche Tools und Module zu werfen, die Ihre Konfiguration auf Fehler überprüfen, Einstellungen vorschlagen oder als Firewall gegen DDoS- und andere Attacken fungieren. Oder Sie schauen sich gleich Sucuri Website Security an, das Ihnen darüber hinaus auch noch einen Rundum-Schutz inkl. Malware-Scans und -Beseitigung bietet.