SMTP: Was ist es und wie funktioniert es?

Das Internet steckt voller Cyber-Gefahren – und dein Webserver steht dabei an vorderster Front. Neben dem Code deiner Webseiten und Webanwendungen (z. B. dein CMS) spielt auch die Absicherung der Server-Basis eine entscheidende Rolle. Dazu gehören:

Die Serveranwendung selbst (häufig Apache oder Nginx)
Die Datenbankverwaltung (z. B. MySQL/MariaDB)
PHP und weitere Skriptsprachen

Hier erfährst du, wie du deinen Apache-Webserver absichern kannst, um Angriffe und Sicherheitsrisiken zu minimieren.

Schwachstellen vermeiden

Beim Absichern deines Webservers musst du zwei Arten von Gefahren berücksichtigen:

Sicherheitslücken in der Software
Konfigurationsfehler, die ungewollt Zugriff ermöglichen

Damit du dich vor Sicherheitslücken schützt, halte dich an diese zwei goldenen Regeln:

Halte deinen Webserver und alle Module immer aktuell!
Lade nur die Module, die du wirklich brauchst!

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.

Nur benötigte Module laden

Apache lädt im Standard zahlreiche Module, von denen du wahrscheinlich nicht alle benötigst. Wenn du die für deine Anwendung überflüssigen Module deaktivierst, erhöhst du nicht nur die Sicherheit (die meisten Security-Schwachstellen stecken in Modulen), sondern verbesserst auch die Performance deines Servers. Allerdings lassen sich an dieser Stelle schlecht pauschale Empfehlungen aussprechen, nicht nur, weil es von deinen Anforderungen abhängt, was du deaktivieren kannst, 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 sind aktuell geladen?

Gib in der Kommandozeile folgendes ein:

Für Debian/Ubuntu:

apache2ctl -M

Für RHEL (CentOS, Fedora) und Windows:

httpd -M

Zur Deaktivierung eines Moduls verwendest du (auf Debian-basierten Systemen wie Ubuntu oder Linux Mint) den Befehl a2dismod zusammen mit dem jeweiligen Modulnamen. Ohne solche Angabe listet a2dismod dir alle Module auf, die du deaktivieren kannst, ohne Apache neu zu kompilieren. Informiere dich bei deinen Deaktivierungskandidaten im Zweifelsfall über Funktion und Abhängigkeiten und teste nach dem Deaktivieren (und Apache-Neustart) gründlich dein System.

Wie Apache kritische Informationen preisgibt – und wie du das verhinderst

Würdest du einem Hacker freiwillig mitteilen, mit welchen Softwareversionen von Anwendungen, Modulen oder Bibliotheken und mit welchen Einstellungen du deinen Webserver betreibst? Natürlich nicht, denn du weißt ja, dass sich ein Hacker mit diesen Informationen ganz gezielt auf bekannte Schwachstellen deines Systems konzentrieren kann. Dennoch fanden sich, wie die c’t 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 kannst du im Produktiveinsatz gefahrlos deaktivieren (siehe oben) und nur dann laden, wenn du entsprechende Infos brauchst.

Webserver absichern - Apache-Konfiguration bearbeiten

Um zu verhindern, dass die Ergebnisseiten von mod_info oder mod_status von jedermann gelesen werden können, musst du 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, musst du Apache neu starten.

Den Zugriff auf die Info- bzw. Statusseite schränkst du ü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) kannst du Apaches Auskunftsfreude zügeln: Durch

ServerTokens Prod

weise 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.

Achte 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 deines 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.

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