server-haertung

Härtung ist Defense in Depth – keine einzelne Headerliste

Grundhaltung: verstehen statt kopieren

Die häufigste Fehlentwicklung bei Server-Härtung ist nicht zu wenig Technik, sondern zu wenig Verständnis. Man übernimmt Konfigurationsblöcke aus Foren, Generatoren oder Blogposts, bekommt vielleicht einen grünen Testbericht und merkt erst später, dass die Hälfte davon nicht zur eigenen Seite passt.

Eine saubere Konfiguration beantwortet drei Fragen: Was schützt diese Direktive? Welchen Nebeneffekt hat sie? Wie prüfe ich nach einer Änderung, ob sie noch korrekt greift? Wenn eine dieser drei Antworten fehlt, ist die Zeile in der Konfiguration bereits verdächtig.

„Ein guter Security-Score ist kein Ziel. Er ist nur ein Nebenprodukt sauberer Entscheidungen.“

Vor der Konfiguration steht die Frage: Was soll gegen wen geschützt werden?

Eine statische Informationsseite, ein Loginbereich, ein Administrationspanel und eine Upload-Anwendung haben nicht dieselbe Angriffsfläche. Härtung beginnt deshalb mit einem einfachen Bedrohungsmodell statt mit einer maximal langen Headerliste.

• Assets: Inhalte, Zugangsdaten, personenbezogene Daten, Schlüssel und Konfigurationen.
• Entry Points: HTTP-Endpunkte, Formulare, APIs, SSH, Adminoberflächen und Datei-Uploads.
• Trust Boundaries: Internet, Reverse Proxy, Anwendung, Datenbank, internes Netz und Backup.
• Failure Impact: Was passiert bei Manipulation, Ausfall, Datenabfluss oder Credential-Diebstahl?

Was nicht benötigt wird, sollte nicht erreichbar oder aktiv sein

Unbenutzte Dienste, Module, Beispielanwendungen, Testverzeichnisse und offen gelassene Administrationspfade vergrößern die Angriffsfläche. Die stärkste Konfiguration eines Webservers hilft wenig, wenn daneben ein vergessener Dienst mit alter Software lauscht.

Bekannte Schwachstellen sind wichtiger als kosmetische Scores

Betriebssystem, Webserver, Laufzeitumgebung, Bibliotheken und Administrationswerkzeuge brauchen einen nachvollziehbaren Updateprozess. Eine öffentlich bekannte und ausnutzbare Schwachstelle wiegt in der Praxis meist schwerer als ein fehlender dekorativer Header.

Updates werden trotzdem nicht blind eingespielt: Relevanz prüfen, Sicherung und Rückweg kennen, Änderung testen, anschließend extern verifizieren und Logs beobachten.

Der Webprozess sollte nur das dürfen, was seine Aufgabe verlangt

Ein statischer Webserver braucht typischerweise keinen Schreibzugriff auf den gesamten Webroot. Ein Uploadbereich sollte nicht automatisch ausführbar sein. Ein Dienstkonto sollte nicht zugleich allgemeiner Administrationsbenutzer sein.

Least Privilege begrenzt den Schaden nach einem Fehler: Benutzer, Gruppen, Dateirechte, Service-Sandboxing und getrennte Secrets sind deshalb Härtungsmaßnahmen, keine reine Systempflege.

Nur notwendige Dienste nach außen – Administration getrennt behandeln

Ein öffentlicher Webserver muss HTTP/HTTPS erreichbar machen. Daraus folgt nicht, dass Datenbank, Verwaltungsoberfläche, Monitoring oder interne Dienste ebenfalls öffentlich lauschen müssen.

Firewallregeln, Bind-Adressen, private Netze und vorgeschaltete Gateways können die Erreichbarkeit begrenzen. Die genaue Architektur ist systemspezifisch; der Grundsatz bleibt: Exposition muss begründet sein.

TLS: der Transport muss zuerst stimmen

TLS ist die Grundlage. Ohne saubere Transportverschlüsselung sind alle späteren Header nur Kosmetik. Der erste Schritt ist deshalb schlicht: HTTP konsequent nach HTTPS umleiten und auf veraltete Protokollgenerationen verzichten.

• HTTP → HTTPS: ausnahmslos umleiten, nicht optional anbieten.
• Nur moderne Protokolle: keine historischen Versionen mehr mitschleppen, nur weil einzelne Altgeräte sonst noch durchkommen.
• Zertifikate: vollständige Chain, automatische Erneuerung und Prüfung nach Änderungen.
• OCSP Stapling: sinnvoll, wenn der Server es sauber ausliefert und der Resolver korrekt steht.

TLS ist nicht nur eine Protokollzeile, sondern ein Betriebsprozess

RFC 8996 stuft TLS 1.0 und 1.1 als veraltet ein; moderner Betrieb beginnt daher mindestens bei TLS 1.2 und kann TLS 1.3 anbieten. Welche Cipher-Details sinnvoll sind, hängt von Bibliothek, Serverversion und Zielclients ab.

Zum Betrieb gehören außerdem vollständige Zertifikatskette, automatisierte Erneuerung, externer Ablaufcheck und die Prüfung, welches Zertifikat der reale TLS-Endpunkt tatsächlich ausliefert.

OCSP Stapling ist keine universelle Pflichtzeile, die blind in jede Konfiguration gehört. Unterstützung und Nutzen hängen von CA, Client-Ökosystem und Serveraufbau ab.

HSTS wirkt im Browser – Preload ist ein zusätzlicher, externer Mechanismus

HSTS wird nur über eine sichere HTTPS-Antwort gelernt. Der Header auf einer HTTP-Antwort wird vom Browser ignoriert.

includeSubDomains bindet auch untergeordnete Namen an HTTPS. preload ist zusätzlich eine Aufnahme in Browser-Preload-Listen und nicht Teil des eigentlichen HSTS-Standards. Vor dem Einsatz muss deshalb die gesamte betroffene Domainfamilie dauerhaft HTTPS-fähig sein.

HTTP-Security-Header: klein, aber nicht nebensächlich

Security-Header sind kein Sammelalbum. Einige sind heute zentral, andere eher Altkompatibilität. Ich setze nur, was klaren Nutzen hat und im Browser auch noch sauber verstanden wird.

• Strict-Transport-Security: verankert HTTPS beim Client, nicht nur auf dem Server.
• X-Content-Type-Options: nosniff verhindert MIME-Sniffing und gehört ohne Diskussion hinein.
• Referrer-Policy: reduziert unnötige URL-Preisgabe an Dritte.
• Permissions-Policy: verbietet Browser-Funktionen, die die Seite gar nicht braucht.
• X-Frame-Options: bleibt als robuste Altkompatibilität nützlich, auch wenn frame-ancestors in CSP die modernere Steuerung ist.

Security-Header haben unterschiedliche Aufgaben und Reichweiten

Kein Header ersetzt sichere Anwendungslogik. Besonders Permissions-Policy sollte nur mit geprüften, tatsächlich unterstützten Direktiven eingesetzt werden.

CSP: die eigentliche Grenze gegen unnötiges Vertrauen

Eine Content-Security-Policy ist nur dann gut, wenn sie zur Seite passt. Für eine rein statische Seite ohne fremde Skripte ist die CSP erfreulich streng. Für komplexere Seiten muss sie bewusst erweitert werden. Was ich nicht tue: eine universelle „irgendwie grüne“ Policy aus dem Netz übernehmen.

Für klassische Informationsseiten ist dieser Aufbau ein sauberer Ausgangspunkt:

Der Unterschied zwischen einer guten und einer schlechten CSP liegt oft in zwei Dingen: erstens dem Verzicht auf bequeme Weichmacher wie 'unsafe-inline', zweitens in ehrlicher Prüfung mit Report-Only, bevor blockiert wird.

Für stark statische Seiten kann statt Nonce auch ein Hash für kleine Inline-Skripte sinnvoll sein. Für dynamische Anwendungen ist Nonce oft praktischer. Beides ist sauberer als globale Inline-Freigaben.

Eine CSP muss zur realen Seite passen – einschließlich Inline-Code

Eine Policy mit script-src 'self' blockiert Inline-Skripte, sofern diese nicht über Nonce oder Hash erlaubt werden. Dasselbe gilt sinngemäß für Inline-Styles unter style-src.

Für statische, handgeschriebene Seiten sind feste SHA-256-Hashes für unveränderte Inline-Skripte eine nachvollziehbare Möglichkeit. Bei jeder Änderung des Skriptinhalts ändert sich jedoch auch der Hash. Dynamische Anwendungen nutzen häufig Nonces.

OWASP empfiehlt für starke CSP-Ansätze insbesondere nonce- oder hashbasierte Policies; 'unsafe-inline' sollte nicht nur eingesetzt werden, um Warnungen schnell verschwinden zu lassen.

CSP-Reporting wird heute über report-to und den Reporting-Endpoints-Header modelliert. Das ältere report-uri ist veraltet, kann aber übergangsweise für ältere Clients zusätzlich sinnvoll sein. Reports selbst sind untrusted input.

Trusted Types: nur dort relevant, wo DOM-Sinks wirklich benutzt werden

Trusted Types ist kein allgemeiner Schmuck für jede Website. Es ist dort interessant, wo JavaScript mit riskanten DOM-Sinks wie innerHTML arbeitet und wo man den Fluss zu diesen Sinks bewusst kontrollieren will. Für eine rein statische Seite ohne solche Muster ist es nicht der erste Hebel.

Wenn es eingesetzt wird, dann nicht als bloßer String-Durchreicher, sondern über eine klar definierte Policy, die HTML bewusst aufbereitet oder sanitisiert.

Trusted Types schützt DOM-XSS-Sinks – nicht beliebigen Servercode

require-trusted-types-for 'script' zwingt unterstützende Browser dazu, an bestimmten DOM-XSS-Sinks typisierte Werte statt beliebiger Strings zu akzeptieren. Die Direktive trusted-types kann zusätzlich erlaubte Policy-Namen begrenzen.

Seit 2026 ist die Browserunterstützung deutlich breiter geworden, ältere Clients können die Mechanismen aber weiterhin nicht kennen. Die beste Lösung bleibt oft, riskante HTML-Sinks gar nicht zu benutzen.

Eine selbstgeschriebene Funktion wie „ersetze einfach jedes <“ ist kein belastbarer HTML-Sanitizer. Wenn dynamisches HTML wirklich benötigt wird, gehört Sanitization in eine kleine, auditierbare und etablierte Verarbeitungskette.

Rate Limiting: kleine Bremse, großer Unterschied

Nicht jede Seite braucht dieselbe Härte. Aber fast jede öffentlich erreichbare Seite profitiert davon, wenn einzelne Clients nicht unbegrenzt und ohne Taktung feuern können. Für Login- oder Formular-Endpunkte ist das Pflicht. Für statische Seiten ist es zumindest ein vernünftiger Filter gegen den alltäglichen Lärm.

Rate Limiting ersetzt keine Zugangskontrolle und auch kein Fail2Ban, aber es nimmt Druck aus vielen banalen Angriffsmustern und macht Logbilder lesbarer.

Rate Limiting gehört an die passende Ressource und hinter das richtige Clientmodell

Ein globales Limit pro IP kann bei NAT, Mobilfunk-Gateways, Unternehmensnetzen oder vorgeschalteten Proxies viele legitime Nutzer gemeinsam treffen. Umgekehrt kann ein Angreifer über viele IP-Adressen ein simples Limit umgehen.

Deshalb werden besonders empfindliche Endpunkte gezielt betrachtet: Login, Passwort-Reset, Suchendpunkte, APIs oder teure dynamische Operationen. nginx verwendet dafür im limit_req-Modul ein Leaky-Bucket-Verfahren und bietet auch Dry-Run-Unterstützung zur Beobachtung vor scharfem Einsatz.

Rate Limiting ist Schutz gegen Übermaß und Missbrauch – keine Identitätsprüfung und kein vollständiger DDoS-Schutz.

Logs: nur hilfreich, wenn sie wirklich gelesen werden

Security ohne Log-Sicht ist blind. Ein Scanner, der nachts zehnmal nach /.env, /wp-login.php oder alten PHPMyAdmin-Pfaden fragt, ist kein Weltuntergang. Aber man sollte wissen, dass er da war, wie häufig er auftaucht und ob das Muster kippt.

• 404-Cluster: zeigen typischen Scanverkehr und geben ein Gefühl für den Hintergrundlärm.
• 429-Antworten: verraten, ob Rate Limiting greift oder zu locker ist.
• TLS-Fehler: zeigen, ob veraltete Clients, Bots oder Konfigurationsfehler aufschlagen.
• Ungewöhnliche User-Agents: sind nicht automatisch böse, aber oft ein guter Startpunkt für Blicktiefe.

Gleichzeitig gilt: Access-Logs enthalten personenbezogene Daten. Kurze Aufbewahrung, klarer Zweck und kein Sammeltrieb.

Logmanagement bedeutet sammeln, schützen, rotieren und löschen

NIST behandelt Logmanagement als eigenen Betriebsprozess: Logs müssen erzeugt, übertragen, gespeichert, ausgewertet und schließlich nach definierten Regeln aufbewahrt oder gelöscht werden.

Für Websysteme bedeutet das: Zugriffsrechte auf Logs begrenzen, Rotation und Speicherbedarf planen, Zeitstempel konsistent halten und Datenschutzanforderungen berücksichtigen.

Ein Log, das niemand liest, hilft nur rückblickend. Ein Log, das unbegrenzt alles sammelt, kann selbst zum Datenschutz- und Speicherproblem werden.

Monitoring muss Abweichungen sichtbar machen, nicht nur Daten sammeln

• Verfügbarkeit: antwortet der reale öffentliche Endpunkt?
• TLS: läuft das Zertifikat ab oder wird das falsche Zertifikat ausgeliefert?
• Fehlerquote: steigen 5xx-Fehler oder Timeouts ungewöhnlich an?
• Ressourcen: laufen Platte, Speicher oder Prozessgrenzen voll?
• Security: ungewöhnliche Loginfehler, Scanmuster oder Policy-Verstöße?

Ein Alarm braucht einen Empfänger und eine Reaktion. Sonst ist Monitoring nur eine weitere Datenquelle.

Apache und nginx: saubere Grundbausteine

Ich halte Security-Header und TLS-Parameter gern in wiederverwendbaren Snippets. Nicht, weil Modularisierung schön aussieht, sondern weil Pflegefehler sonst schnell auf mehreren Hosts gleichzeitig auseinanderlaufen.

nginx

Apache

Reverse Proxy und TLS-Termination verschieben die Sicherheitsgrenze

Wenn TLS an CDN, Load Balancer oder Reverse Proxy endet, ist der dahinterliegende Webserver nicht automatisch der öffentliche Sicherheitsrand. Dann müssen Client-IP-Weitergabe, interne Transportverschlüsselung, vertrauenswürdige Proxy-Header und Zugriff auf den Origin bewusst konfiguriert werden.

Besonders gefährlich ist es, beliebige eingehende X-Forwarded-For- oder ähnliche Header blind als vertrauenswürdig zu behandeln. Nur bekannte Proxy-Pfade dürfen solche Informationen autoritativ setzen.

Adminzugriff gehört getrennt vom öffentlichen Webverkehr

SSH-Administration sollte mit begrenzten Konten, nachvollziehbarer Authentisierung und minimal notwendiger Erreichbarkeit betrieben werden. Direkter dauerhafter Root-Arbeitsmodus vergrößert den Schadensradius.

Ob Schlüssel, zusätzliche Faktoren, VPN oder Bastion sinnvoll sind, hängt von Umgebung und Risiko ab. Der Grundsatz lautet: Administrationszugänge sind Hochwert-Zugänge und brauchen eine eigene Schutzstrategie.

Secrets gehören nicht in Webroot, Repository oder Logausgabe

Private Schlüssel, API-Tokens, Datenbankpasswörter und andere Geheimnisse müssen getrennt von öffentlich ausgelieferten Dateien und möglichst getrennt von gewöhnlichem Quelltext verwaltet werden.

Backup, Rotation und Widerruf beziehungsweise Austausch gehören zum Lebenszyklus. Ein Secret, das in einem Log oder öffentlichen Repository auftauchte, sollte nicht nur „wieder gelöscht“, sondern als potenziell kompromittiert behandelt werden.

Vor Reload oder Restart: Syntax und effektive Konfiguration prüfen

Webserver und Dienste bieten häufig eigene Konfigurationstests. Diese sollten vor einem Reload genutzt werden, weil ein Tippfehler sonst aus einer Sicherheitsänderung einen Ausfall machen kann.

Zusätzlich zählt die effektive Konfiguration: Include-Dateien, Vererbungsregeln und virtuelle Hosts können bewirken, dass eine scheinbar gesetzte Direktive an einem anderen Ort überschrieben wird.

Härtung wird als kontrollierte Änderung betrieben

Härtung verhindert nicht jeden Ausfall – Recovery gehört dazu

Konfiguration, Webdaten, Zertifikatsbezüge und gegebenenfalls Anwendungsdaten brauchen eine Wiederherstellungsstrategie. Ein Backup ist erst belastbar, wenn ausgewählte Restores getestet wurden.

Backups sollten nicht mit denselben Zugangsdaten und demselben Fehlerpfad vollständig vom Produktivsystem zerstörbar sein. Die ausführliche Restore-Praxis bleibt auf datensicherung-und-backups.htm.

Bei Verdacht auf Kompromittierung reicht „Server neu starten“ nicht

Ein Incident braucht mindestens eine belastbare Reihenfolge: Auswirkung begrenzen, Beweise und Logs sichern, Zugangsdaten und Schlüssel bewerten, Ursache identifizieren, betroffene Komponenten neu aufbauen oder bereinigen und erst danach kontrolliert zurückkehren.

Wenn ein Secret kompromittiert sein könnte, gehört Rotation zum Vorfall. Wenn die Vertrauensbasis des Systems unklar ist, kann ein sauberer Neuaufbau sicherer sein als punktuelles „Weiterreparieren“.

Auch externe Bibliotheken und Build-Werkzeuge gehören zur Angriffsfläche

Webserverhärtung schützt nicht vor einer verwundbaren Anwendung, einem kompromittierten Plugin oder einer ungeprüften Abhängigkeit. Inventar, Herkunft, Versionen und Updatefähigkeit der eingesetzten Komponenten gehören deshalb zum Sicherheitsbild.

Für sehr statische Seiten ist eine kleine Abhängigkeitsfläche selbst bereits ein Sicherheitsvorteil: weniger Fremdcode, weniger Updateketten und weniger externe Laufzeitabhängigkeiten.

Scanner und A+-Scores sind Messpunkte – keine Sicherheitsgarantie

Automatische Tests sind wertvoll, weil sie reproduzierbar TLS, Header oder bekannte Fehlkonfigurationen prüfen können. Sie sehen aber nicht automatisch Geschäftslogik, gestohlene Credentials, fehlerhafte Berechtigungen im Backend oder fehlende Restorefähigkeit.

Ein hoher Score ist deshalb nützlich, wenn die zugrunde liegenden Entscheidungen verstanden sind. Er ist gefährlich, wenn er ausschließlich als Ziel optimiert wird.

Checkliste vor Go-Live oder größerer Änderung

„Eine sichere Konfiguration ist nicht die längste. Sie ist die, die auch nach Monaten noch verstanden und gepflegt wird.“

Sicherheitskonfigurationen brauchen Versions- und Herkunftskontext

Eine historische nginx- oder Apache-Konfiguration ist ohne Serverversion, Betriebssystem, Module und Architekturkontext nur teilweise verständlich. Direktiven können veraltet, umbenannt oder in späteren Versionen anders bewertet werden.

Geheimnisse, private Schlüssel und echte Zugangsdaten werden dabei getrennt behandelt und nicht in eine öffentliche Dokumentation kopiert.

Technische Referenzen

Die Referenzen liefern technische Grundlagen. Konkrete produktive Konfigurationen müssen immer gegen installierte Versionen, Architektur, Browseranforderungen und reale Dienste geprüft werden.

Querverweise im SSLXY-Archiv

• Zur SSLXY-Hauptseite
• SSL und Zertifikate
• Shell-Accounts und Hosts
• Unix und Linux im Alltag
• CGI und Logfiles
• Fernwartung und Remote-Zugriffe
• Datensicherung und Backups
• Software- und Tool-Alltag