Security Hardening für Legacy-Webserver: Apache und Nginx sicher konfigurieren

Der Server läuft seit 2014. Damals hat ihn jemand eingerichtet, der heute nicht mehr im Unternehmen ist. Die Konfigurationsdatei hat seitdem niemand mehr geöffnet. Die Anwendung darauf funktioniert, also gab es keinen Grund.

Genau so sieht es bei vielen Kunden aus, wenn wir zum ersten Mal auf einen alten Webserver schauen. Apache Sicherheit auf Legacy-Servern hängt meist an den Einstellungen, seltener an der Software selbst. Ein Apache 2.2 mit den Standardwerten von 2014 akzeptiert Verbindungen, die heute kein Browser mehr aushandeln sollte. Bei einem Nginx aus derselben Zeit sieht es ähnlich aus.

Dieser Artikel zeigt, welche Einstellungen Sie bei einem alten Webserver zuerst anfassen sollten. Die Reihenfolge folgt dem Verhältnis von Risiko zu Aufwand.

Warum die Webserver-Konfiguration das erste Einfallstor ist

Der Webserver ist die Tür zu Ihrer Anwendung. Jede Anfrage aus dem Internet geht zuerst durch ihn. Wenn diese Tür schlecht eingestellt ist, hilft der beste Anwendungscode dahinter wenig.

Angreifer wissen das. Automatisierte Scanner prüfen täglich Millionen von Servern auf dieselben Merkmale: alte TLS-Versionen, schwache Verschlüsselung, fehlende Schutz-Header, offene Statusseiten. Ein Legacy-Webserver mit Standardkonfiguration taucht in diesen Listen auf, ohne dass jemand gezielt nach Ihrem Unternehmen gesucht hätte.

Dazu kommt die Versionsfrage. Apache 2.2 hat seit Juli 2017 keine Updates mehr erhalten. Wer diese Version noch betreibt, hat seither keine Sicherheitskorrektur mehr eingespielt. Was das grundsätzlich bedeutet, haben wir im Beitrag zu alter Software als Sicherheitsrisiko beschrieben. Hier geht es um die Frage, was Sie in der Konfiguration tun können, auch wenn ein Versionswechsel gerade nicht möglich ist.

Schritt 1: TLS-Version und Cipher-Suites

TLS ist das Protokoll hinter dem "https" in der Adresszeile. Es verschlüsselt die Verbindung zwischen Browser und Server. Alte Server erlauben oft noch TLS 1.0 und TLS 1.1. Beide Versionen gelten seit 2020 als unsicher, und moderne Browser verweigern sie.

Prüfen Sie zuerst, welche Versionen Ihr Server anbietet. Ein Test mit dem kostenlosen SSL Labs Server Test von Qualys dauert zwei Minuten und zeigt das Ergebnis als Schulnote.

Für Apache lautet die Zeile in der Konfiguration:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Für Nginx:

ssl_protocols TLSv1.2 TLSv1.3;

Direkt danach kommen die Cipher-Suites. Das sind die Verschlüsselungsverfahren, die der Server dem Browser anbietet. Alte Listen enthalten oft RC4, 3DES oder Verfahren ohne Forward Secrecy. Forward Secrecy bedeutet: Selbst wenn der private Schlüssel des Servers später gestohlen wird, bleiben alte Mitschnitte unlesbar.

Eine sichere Liste müssen Sie nicht selbst zusammenstellen. Mozilla pflegt einen SSL Configuration Generator, der für Apache und Nginx fertige Blöcke ausgibt. Wählen Sie dort das Profil "Intermediate". Es funktioniert mit allen Browsern der letzten Jahre und schließt die bekannten Schwachstellen aus.

Ein Hinweis zu Apache 2.2: Diese Version unterstützt kein TLS 1.3. Sie können TLS 1.0 und 1.1 abschalten, mehr geht nicht. Spätestens hier lohnt der Blick auf ein Update auf Apache 2.4.

Wie Sie ein Zertifikat für eine alte Website überhaupt erst einrichten, steht im Beitrag HTTPS und SSL für alte Websites.

Schritt 2: HTTP-Header, die der Browser versteht

HTTP-Header sind kurze Anweisungen, die der Server mit jeder Antwort mitschickt. Der Browser liest sie und verhält sich entsprechend. Einige davon schützen Ihre Besucher vor Angriffen, die gar nicht auf dem Server stattfinden, sondern im Browser.

Vier Header lohnen sich bei fast jedem Legacy-Webserver.

Strict-Transport-Security sagt dem Browser: Sprich mit dieser Domain nur noch über https. Damit läuft kein Besucher mehr versehentlich über eine unverschlüsselte Verbindung. Setzen Sie ihn erst, wenn https auf allen Unterseiten wirklich funktioniert. Rückgängig machen dauert Monate.

X-Content-Type-Options mit dem Wert "nosniff" verhindert, dass der Browser Dateitypen errät. Ohne diesen Header kann eine hochgeladene Textdatei plötzlich als Skript ausgeführt werden.

X-Frame-Options oder die neuere Variante über Content-Security-Policy verhindern, dass Ihre Seite unsichtbar in eine fremde Seite eingebettet wird. Diese Technik heißt Clickjacking. Der Besucher klickt scheinbar auf eine harmlose Fläche und löst in Wahrheit eine Aktion auf Ihrer Seite aus.

Content-Security-Policy ist der mächtigste der vier und der aufwendigste. Er legt fest, aus welchen Quellen Skripte, Stylesheets und Bilder geladen werden dürfen. Bei einer alten Anwendung mit Inline-JavaScript kann eine strenge Policy die Seite lahmlegen. Beginnen Sie im Modus "report-only". Dann meldet der Browser Verstöße, blockiert aber nichts. Nach ein paar Wochen sehen Sie, was die Anwendung wirklich braucht.

In Apache setzen Sie Header über das Modul mod_headers:

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"

In Nginx über add_header innerhalb des server-Blocks. Beachten Sie bei Nginx: Ein add_header in einem location-Block überschreibt alle add_header-Zeilen der übergeordneten Ebene. Ein häufiger Grund, warum Header scheinbar gesetzt sind und trotzdem fehlen.

Zum Schluss der Header-Runde: Nehmen Sie Informationen raus, die niemand braucht. Der Header "Server" verrät standardmäßig die genaue Apache- oder Nginx-Version. Das erleichtert Angreifern die Suche nach passenden Schwachstellen. In Apache hilft "ServerTokens Prod", in Nginx "server_tokens off". Dasselbe gilt für "X-Powered-By", den PHP oft mitschickt.

Schritt 3: Verzeichnisse, Statusseiten und Module

Viele Legacy-Konfigurationen erlauben Verzeichnislisten. Wer eine URL ohne index-Datei aufruft, sieht dann alle Dateien im Ordner. Backups, alte Kopien, Konfigurationsdateien mit Datenbankpasswörtern. In Apache schalten Sie das mit "Options -Indexes" ab, in Nginx mit "autoindex off".

Prüfen Sie außerdem, ob mod_status oder die Nginx-Statusseite von außen erreichbar sind. Beide zeigen aktive Verbindungen und Anfragen in Echtzeit. Nützlich für den Betrieb, aber nur aus dem internen Netz.

Dann die Module. Ein alter Apache lädt oft 30 oder mehr Module, weil die Distribution sie damals so ausgeliefert hat. Jedes Modul ist Code, der Anfragen verarbeitet, und damit eine mögliche Angriffsfläche. Schalten Sie ab, was die Anwendung nicht braucht. Typische Kandidaten sind mod_cgi, mod_userdir, mod_autoindex und mod_info. Der Befehl "apachectl -M" listet, was geladen ist.

Schritt 4: mod_security als Web Application Firewall

mod_security ist eine Web Application Firewall, kurz WAF. Sie sitzt vor der Anwendung und prüft jede Anfrage gegen ein Regelwerk. Bekannte Angriffsmuster wie SQL-Injection oder Cross-Site-Scripting werden erkannt und abgewiesen, bevor sie den PHP-Code erreichen.

Für alte Anwendungen ist das interessant, weil die Lücke oft im Code liegt und nicht kurzfristig behoben werden kann. Die WAF fängt dann zumindest die bekannten Angriffsformen ab. Die Korrektur im Code bleibt trotzdem nötig. Die WAF verschafft Ihnen Zeit dafür.

Für Apache gibt es mod_security seit vielen Jahren. Für Nginx heißt das Modul ModSecurity-nginx und muss meist selbst kompiliert werden. In beiden Fällen empfehlen wir das OWASP Core Rule Set als Regelwerk. Es ist frei verfügbar und wird aktiv gepflegt.

Auch hier gilt: Erst im Erkennungsmodus starten. Legacy-Anwendungen erzeugen oft Anfragen, die für eine WAF verdächtig aussehen, aber legitim sind. Ein Formular, das HTML-Text speichert, löst zum Beispiel sofort Alarme aus. Diese Fälle müssen Sie als Ausnahmen eintragen, bevor Sie auf Blockieren umschalten. Sonst steht am Montagmorgen die Buchhaltung vor einer 403-Seite.

Schritt 5: Access-Logging, das im Ernstfall etwas nützt

Logs sind das Einzige, was Ihnen nach einem Vorfall sagt, was passiert ist. Bei alten Servern sehen wir regelmäßig drei Probleme.

Erstens fehlen Felder. Das Standardformat protokolliert Zeit, IP, URL und Statuscode. Für eine Untersuchung brauchen Sie zusätzlich den User-Agent, den Referer und bei https die verwendete TLS-Version. Beides lässt sich über das LogFormat in Apache und log_format in Nginx ergänzen.

Zweitens werden Logs zu früh gelöscht oder gar nicht rotiert. Angriffe fallen oft erst Wochen später auf. Sind die Logs dann schon weg, bleibt nur Raten. 90 Tage sollten es sein, bei personenbezogenen Daten mit Blick auf die DSGVO nicht deutlich mehr.

Drittens schaut niemand hinein. Ein Log, das nur wächst, hilft nicht. Schon ein einfaches Skript, das täglich die Statuscodes 404 und 500 zählt und bei Ausreißern eine Mail schickt, macht einen Unterschied. Ein plötzlicher Anstieg an 404-Fehlern ist fast immer ein Scanner, der Ihre Seite abklopft.

Was ist mit dem Versionswechsel?

Konfiguration härten ist nur der erste Schritt. Ein Apache 2.2 bleibt eine Software ohne Updates, egal wie gut die Cipher-Liste ist. Der Umstieg auf Apache 2.4 ist bei den meisten Anwendungen ein Wochenendprojekt. Die Syntax der Zugriffsregeln hat sich geändert, von "Order allow,deny" zu "Require all granted", sonst bleibt vieles gleich.

Ob Apache oder Nginx dabei die bessere Wahl für Ihre alte PHP-Anwendung ist, haben wir im Beitrag Apache oder Nginx für altes PHP verglichen. Kurz gesagt: Wer .htaccess-Dateien nutzt, bleibt meist bei Apache. Wer viele Anfragen mit wenig Ressourcen bedienen muss, schaut sich Nginx an.

Fazit: Vier Stunden, die sich lohnen

Die Punkte in diesem Artikel lassen sich an einem Nachmittag umsetzen. TLS-Versionen und Cipher-Suites anpassen, fünf Header setzen, Verzeichnislisten abschalten, Server-Kennung verstecken, Logformat erweitern. Das ist kein Projekt, das ein Budget braucht.

Nginx Sicherheit und Apache Sicherheit unterscheiden sich in der Syntax, kaum im Prinzip. Was zählt, ist der Anfang. Ein Legacy-Webserver mit gehärteter Konfiguration ist ein deutlich unattraktiveres Ziel als einer mit den Standardwerten von 2014.

Wenn Sie nicht sicher sind, wo Ihr Server steht, bietet sich ein Security Audit für Legacy-Software an. Wir prüfen dabei die Webserver-Konfiguration zusammen mit der Anwendung und liefern eine priorisierte Liste. Alternativ übernehmen wir die Sicherheitshärtung direkt.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos.