Webserver härten: Nginx und Apache für KMU sicher konfigurieren

Erst kürzlich wurde eine kritisch eingestufte Sicherheitslücke in Nginx Open Source und Nginx Plus bekannt, über die sich unter bestimmten Bedingungen Schadcode auf dem Server ausführen lässt. Für viele KMU, die ihre Website, Kundenportale oder interne Anwendungen über einen selbst betriebenen Webserver ausliefern, ist das ein Weckruf: Ein ungepatchter oder falsch konfigurierter Webserver ist eines der direktesten Einfallstore ins Unternehmensnetz, weil er aus dem Internet erreichbar sein muss.

Warum der Webserver ein besonders exponiertes Ziel ist

Anders als interne Systeme, die durch Firewall und Netzwerksegmentierung geschützt werden können, muss ein Webserver zwangsläufig aus dem Internet erreichbar sein, um seine Aufgabe zu erfüllen. Das macht ihn zum bevorzugten Angriffsziel: Automatisierte Scanner durchsuchen permanent das Internet nach verwundbaren Nginx- und Apache-Versionen, veralteten Modulen und Fehlkonfigurationen. Sobald eine neue Schwachstelle wie die aktuelle Nginx-Lücke öffentlich wird, beginnt das gezielte Scannen nach ungepatchten Systemen oft innerhalb weniger Stunden.

Für ostdeutsche KMU, die ihre Website oder Webanwendungen häufig auf einem eigenen Linux-Server statt bei einem Managed-Hoster betreiben, liegt die Verantwortung für Patches und Härtung vollständig im eigenen Haus. Ohne festen Prozess dafür bleiben Sicherheitslücken oft wochen- oder monatelang offen.

Was bei der aktuellen Nginx-Lücke zu tun ist

Bei kritischen Schadcode-Lücken wie der aktuell bekannt gewordenen zählt jede Stunde. Betroffene Unternehmen sollten umgehend prüfen, welche Nginx-Version im Einsatz ist, das bereitgestellte Sicherheitsupdate einspielen und den Dienst danach neu starten. Ein automatisiertes Patch-Management hilft, solche Lücken künftig ohne manuellen Aufwand zeitnah zu schließen.

Grundlegende Härtungsmaßnahmen für Nginx und Apache

Server-Version und interne Details verbergen

Sowohl Nginx als auch Apache geben standardmäßig ihre genaue Versionsnummer in HTTP-Headern und Fehlerseiten preis. Angreifer nutzen diese Information, um gezielt nach passenden Exploits für die erkannte Version zu suchen. Die Direktiven server_tokens off (Nginx) beziehungsweise ServerTokens Prod und ServerSignature Off (Apache) unterbinden diese Preisgabe.

Nur notwendige Module aktivieren

Jedes aktivierte Modul vergrößert die Angriffsfläche. Insbesondere bei Apache lohnt sich eine Bestandsaufnahme der aktiven Module – häufig sind Module aktiv, die für den tatsächlichen Betrieb gar nicht benötigt werden, etwa für WebDAV oder veraltete Authentifizierungsmechanismen.

TLS-Konfiguration konsequent modernisieren

Veraltete TLS-Protokollversionen wie TLS 1.0 und 1.1 sowie schwache Cipher-Suiten sollten deaktiviert werden. Eine aktuelle, restriktive TLS-Konfiguration verhindert nicht nur Downgrade-Angriffe, sondern wird auch von Browsern und Suchmaschinen zunehmend vorausgesetzt.

Sicherheits-Header setzen

HTTP-Sicherheits-Header wie Content-Security-Policy, X-Content-Type-Options, X-Frame-Options und Strict-Transport-Security reduzieren das Risiko von Cross-Site-Scripting, Clickjacking und Protokoll-Downgrades erheblich und lassen sich zentral in der Server-Konfiguration ergänzen.

Rate Limiting und Zugriffsbeschränkungen

Sowohl Nginx (limit_req) als auch Apache (mod_ratelimit, mod_evasive) erlauben es, die Anzahl der Anfragen pro Client zu begrenzen. Das erschwert Brute-Force-Angriffe auf Login-Formulare und automatisierte Massen-Scans deutlich.

Admin- und Verwaltungsbereiche einschränken

Verwaltungsoberflächen, Statusseiten oder Admin-Panels sollten nicht offen im Internet stehen. Eine IP-Whitelist oder der Zugriff ausschließlich über ein VPN reduziert die Angriffsfläche erheblich, ohne die Funktionalität für berechtigte Nutzer einzuschränken.

Praxis: Webserver-Härtung in fünf Schritten umsetzen

1. Bestandsaufnahme: Welche Webserver-Software und -Version läuft aktuell auf welchem System, und welche Module beziehungsweise Anwendungen sind darüber erreichbar?
2. Patch-Prozess etablieren: Sicherheitsupdates für Nginx oder Apache sollten zeitnah und idealerweise automatisiert eingespielt werden, statt manuell und unregelmäßig.
3. Konfiguration gegen eine Härtungs-Checkliste prüfen: Server-Header verbergen, unnötige Module deaktivieren, TLS-Konfiguration modernisieren, Sicherheits-Header ergänzen.
4. Zugriff auf sensible Bereiche einschränken: Admin-Interfaces und Statusseiten hinter VPN oder IP-Filter legen.
5. Regelmäßig scannen: Ein Schwachstellenscanner prüft in festen Abständen, ob neue Lücken oder Fehlkonfigurationen auf dem Webserver auftauchen, bevor Angreifer sie finden.

Härtung ist ein Prozess, kein einmaliges Projekt

Ein Webserver, der heute sicher konfiguriert ist, kann in sechs Monaten wieder verwundbar sein – weil eine neue Schwachstelle bekannt wird, ein Modul aktualisiert werden muss oder sich die Konfiguration im laufenden Betrieb unbemerkt verändert hat. Wer Webserver-Sicherheit als kontinuierliche Aufgabe statt als einmaliges Setup versteht, reduziert das Risiko eines erfolgreichen Angriffs dauerhaft.

Rexoma als Ansprechpartner in Dresden

Sie betreiben Ihre Website oder Webanwendungen auf einem eigenen Server und sind unsicher, ob Nginx oder Apache aktuell sauber gehärtet sind? Rexoma unterstützt KMU in Dresden, Sachsen und im gesamten ostdeutschen Raum bei der Absicherung von Linux-Servern und Webserver-Konfigurationen – von der Erstprüfung über die Härtung bis zum laufenden Patch-Management.

Häufige Fragen zur Webserver-Härtung

Reicht es, den Webserver hinter einer Firewall zu betreiben? Nein. Eine Firewall schützt vor unautorisiertem Zugriff auf andere Dienste, muss den Webserver selbst aber zwangsläufig aus dem Internet erreichbar lassen. Die Härtung der Webserver-Konfiguration bleibt daher unverzichtbar.

Wie oft sollten Nginx oder Apache aktualisiert werden? Sicherheitsupdates sollten zeitnah nach Veröffentlichung eingespielt werden, insbesondere bei kritisch eingestuften Lücken wie zuletzt bei Nginx. Ein fester, idealerweise automatisierter Patch-Prozess verhindert, dass Updates untergehen.

Was ist der Unterschied zwischen Härtung und einer Web Application Firewall? Härtung sichert die Grundkonfiguration des Webservers selbst ab. Eine Web Application Firewall ergänzt das um eine vorgeschaltete Schutzschicht, die Angriffe auf Anwendungsebene erkennt und blockiert, bevor sie den Server erreichen.

Betrifft das auch Unternehmen, die nur eine einfache Firmenwebsite betreiben? Ja. Auch eine einfache Website läuft auf einem Webserver, der bei fehlender Härtung als Sprungbrett ins Netzwerk oder zum Versand von Schadinhalten missbraucht werden kann – unabhängig von der Größe der Website.

Wie erkenne ich, ob mein Webserver bereits kompromittiert wurde? Anzeichen sind unter anderem unerklärliche Ressourcenauslastung, unbekannte Prozesse, veränderte Dateien im Webverzeichnis oder ungewöhnliche Einträge in den Zugriffs-Logs. Regelmäßiges Monitoring und Log-Auswertung helfen, solche Auffälligkeiten frühzeitig zu erkennen.