server-haertung

Härtung ist Defense in Depth – keine einzelne Headerliste

Grundhaltung: verstehen statt kopieren

Eine häufige Fehlentwicklung bei Server-Härtung entsteht durch Konfigurationsblöcke, die aus Generatoren, Foren oder Beispielen übernommen werden, ohne Zweck, Nebenwirkung und Gültigkeitsbereich jeder Direktive ausreichend zu verstehen.

Eine saubere Konfiguration beantwortet deshalb für jede relevante Zeile mindestens drei Fragen: Welche Bedrohung oder Fehlkonfiguration wird begrenzt? Welche Nebenwirkungen sind möglich? Wie lässt sich nach einer Änderung nachweisen, dass die Direktive tatsächlich wie vorgesehen greift?

„Ein guter Security-Score ist ein Messwert – kein Ersatz für nachvollziehbare Entscheidungen.“

Zusammenhang: Diese Arbeitsweise setzt sich in Webmaster-Arbeit seit 1996, der technischen Philosophie und Software- und Tool-Alltag fort.

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?

Zusammenhang: Netzwerk und Heimvernetzung vertieft Trust Boundaries und Netzpfade.

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.

Zusammenhang: Unix und Linux im Alltag sowie Shell-Accounts und Hosts behandeln Dienste, Prozesse und Benutzerkontexte.

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.

Vertiefung: Benutzer, Gruppen und Dateirechte stehen ausführlicher auf Shell-Accounts und Hosts.

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.

Vertiefung: Netzwerk und Heimvernetzung behandelt Bindings, Netzgrenzen und Erreichbarkeit aus Netzwerksicht.

TLS: Transportverschlüsselung als eigene Sicherheitsschicht

HTTPS schützt den Transport zwischen den beteiligten TLS-Endpunkten. Diese Schicht muss korrekt funktionieren, bevor Browser-Policies oder Anwendungsschutz sinnvoll bewertet werden können. Transportverschlüsselung ersetzt jedoch weder sichere Serverkonfiguration noch sichere Anwendungslogik.

• HTTP → HTTPS: öffentliche Webinhalte konsequent auf HTTPS führen, sofern kein technischer Sonderfall ausdrücklich dagegen spricht.
• Protokollversionen: TLS 1.0 und 1.1 nicht mehr anbieten; TLS 1.2 nur mit zeitgemäßen Verfahren betreiben und TLS 1.3 bevorzugt ermöglichen.
• Zertifikate: vollständige Zertifikatskette, kontrollierte Erneuerung und Prüfung des tatsächlich ausgelieferten Zertifikats.
• Schlüsselmaterial: private Schlüssel nicht im Webroot, in öffentlichen Repositories oder ungeschützten Diagnoseausgaben ablegen.
• OCSP Stapling: als optionale, server- und CA-abhängige Funktion behandeln – nicht als universelle Pflichtzeile.

Vertiefung: SSL und Zertifikate behandelt Protokollgeschichte, Zertifikatsketten und den Übergang von SSLeay zu heutigen TLS-Umgebungen.

TLS-Betrieb 2026: Version, Algorithmen, Zertifikat und realer Endpunkt

TLS 1.0 und TLS 1.1 sind seit Jahren veraltet und sollen nicht mehr ausgehandelt werden. TLS 1.3 ist die modernere Protokollgeneration; TLS 1.2 bleibt für Kompatibilität relevant, verlangt aber eine zeitgemäße Auswahl der tatsächlich verwendeten Verfahren.

Im Jahr 2026 ist die Betrachtung von TLS 1.2 deshalb genauer geworden: Nicht nur die Protokollversionsnummer zählt. Auch der verwendete Schlüsselaustausch muss bewertet werden. Historische RSA-Key-Exchange- und klassische finite-field-DH-Verfahren gehören nicht in neue TLS-1.2-Konfigurationen; statisches ECDH sollte ebenfalls vermieden werden.

Zum Betrieb gehören außerdem vollständige Zertifikatskette, automatisierbare Erneuerung, externer Ablaufcheck und die Prüfung, welches Zertifikat der reale öffentliche TLS-Endpunkt tatsächlich ausliefert. Bei Reverse Proxy oder CDN kann dieser Endpunkt von der Origin-Maschine getrennt sein.

OCSP Stapling ist keine universelle Pflichtdirektive. Unterstützung, Nutzen und Fehlerverhalten hängen von Server, TLS-Bibliothek, Zertifizierungsstelle und Client-Ökosystem ab.

Zusammenhang: Die Trennung von öffentlichem TLS-Endpunkt und Origin wird im Abschnitt Reverse Proxy / TLS-Termination weitergeführt; historische und moderne Zertifikatspraxis steht auf SSL und Zertifikate.

HSTS: Browserzustand mit langfristiger Wirkung

HSTS wird über eine sichere HTTPS-Antwort gelernt. Ein Strict-Transport-Security-Header auf einer ungesicherten HTTP-Antwort begründet keinen vertrauenswürdigen HSTS-Zustand.

includeSubDomains erweitert die Regel auf untergeordnete Hostnamen. Das ist nur sinnvoll, wenn die betroffene Domainstruktur tatsächlich vollständig und dauerhaft HTTPS-fähig ist.

preload ist ein zusätzlicher Browserlisten-Mechanismus und nicht Teil der eigentlichen HSTS-Spezifikation. Für eine Aufnahme in entsprechende Preload-Listen gelten zusätzliche Voraussetzungen. Die Entscheidung sollte deshalb nicht nur wegen eines Security-Scores getroffen werden.

Vertiefung: SSL und Zertifikate behandelt Zertifikate, Namen und Vertrauensketten ausführlicher.

HTTP-Security-Header: kleine Direktiven mit klar abgegrenzten Aufgaben

Security-Header sind keine vollständige Sicherheitsarchitektur. Sinnvoll sind sie dort, wo ihre Aufgabe zur tatsächlichen Website passt und ihre Wirkung nach der Auslieferung überprüft wird.

• Strict-Transport-Security: merkt HTTPS-Nutzung im Browser für einen definierten Zeitraum vor.
• X-Content-Type-Options: nosniff: begrenzt MIME-Sniffing in den dafür vorgesehenen Browserkontexten.
• Referrer-Policy: steuert, welche Referrer-Informationen bei Navigationen und Requests weitergegeben werden.
• Permissions-Policy: kann ausgewählte Browser-Funktionen einschränken; verwendete Feature-Namen müssen zur realen Browserunterstützung passen.
• frame-ancestors: steuert innerhalb der CSP, welche Seiten das Dokument einbetten dürfen.
• X-Frame-Options: kann ergänzend als ältere Kompatibilitätsschicht dienen.

Zusammenhang: Browser-Policies ergänzen Server- und Anwendungsschutz. Die zugrunde liegende Webpraxis wird auf Webmaster-Arbeit seit 1996 weiter eingeordnet.

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: Ressourcen und Browseraktionen ausdrücklich begrenzen

Eine Content Security Policy ist nur dann belastbar, wenn sie zur realen Seite passt. Eine statische Website ohne externe Skripte, Frames, Netzwerk-Requests aus JavaScript oder Formularendpunkte kann wesentlich enger gefasst werden als eine komplexe Webanwendung.

Für sslxy.de wird die CSP als HTTP-Response-Header über die Serverkonfiguration beziehungsweise .htaccess ausgeliefert. Ein zusätzlicher CSP-Meta-Tag im HTML ist deshalb nicht Bestandteil des Seitenstandards.

Hash-Sources sind für unveränderte Inline-Blöcke nachvollziehbar: Schon eine kleine Änderung am exakten Inline-Inhalt erzeugt einen neuen Hash. Deshalb werden die CSP-Hashes bei jeder Änderung der betreffenden HTML-Datei neu berechnet.

Globale Freigaben wie 'unsafe-inline', unnötige Wildcards oder sehr breite Fremdquellen sollten nicht verwendet werden, nur um eine fehlerhafte Policy schnell „grün“ zu bekommen.

Zusammenhang: Der minimalistische Ansatz wird auf philosophy.htm und webmaster.htm weitergeführt.

Eine CSP wird gegen die reale Seite entwickelt und geprüft

script-src 'self' erlaubt nicht automatisch beliebige Inline-Skripte. Inline-Code benötigt – sofern er beibehalten wird – eine passende Nonce oder Hash-Source. Entsprechendes gilt für Inline-Styles unter style-src.

Für handgeschriebene statische Seiten mit stabilen Inline-Blöcken sind feste SHA-256-Hashes gut nachvollziehbar. Dynamische Anwendungen verwenden häufig Nonces oder verlagern Code vollständig in externe Ressourcen.

Vor einer scharf blockierenden Policy kann ein Report-Only-Betrieb helfen, reale Verstöße sichtbar zu machen. Ein Reporting-Endpunkt ist jedoch selbst ein öffentlich erreichbarer Dateneingang: Reports sind fremdgesteuerte Eingaben und brauchen Datenminimierung, Begrenzung, sichere Verarbeitung und eine definierte Aufbewahrung.

Reporting-Mechanismen und ihre Browserunterstützung entwickeln sich unabhängig von der eigentlichen Blockierwirkung weiter. Deshalb muss eine Reporting-Konfiguration gegen die tatsächlich unterstützten Browser und den konkret eingesetzten Server geprüft werden.

Vertiefung: CGI und Logdateien behandelt fremdgesteuerte Eingaben und Protokolldaten; die Datenschutzseite datenschutz.htm beschreibt die aktuelle Datenverarbeitung auf sslxy.de.

Trusted Types: zusätzliche Grenze für riskante DOM-Sinks

Trusted Types ist kein allgemeiner Sicherheitszusatz für jede Website. Der Mechanismus wird relevant, wenn JavaScript tatsächlich mit DOM-XSS-gefährdeten Sinks arbeitet und der Datenfluss zu diesen Sinks ausdrücklich kontrolliert werden soll.

Die einfachste Lösung bleibt häufig, einen riskanten HTML-Sink gar nicht zu verwenden. Für reine Textausgabe ist beispielsweise textContent der direkte und weniger fehleranfällige Weg.

Trusted Types schützt bestimmte DOM-Sinks – nicht beliebigen Code

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

Browserunterstützung und Detailverhalten sind versionsabhängig. Eine Website darf deshalb nicht davon ausgehen, dass Trusted Types allein jeden Client oder jeden XSS-Pfad abdeckt.

Selbstgeschriebene Minimalfunktionen wie „ersetze jedes <“ sind keine belastbaren HTML-Sanitizer. Wenn dynamisches HTML unvermeidbar ist, gehört Sanitization in eine kleine, nachvollziehbare und etablierte Verarbeitungskette.

Rate Limiting: gezielte Begrenzung statt pauschaler Bremse

Rate Limiting ist besonders bei Login-, Reset-, Formular-, API- oder rechenintensiven Endpunkten sinnvoll. Für rein statische Dateien ist ein pauschales Limit dagegen nicht automatisch die beste Maßnahme und kann bei gemeinsam genutzten IP-Adressen unnötig legitime Abrufe treffen.

Rate Limiting ersetzt keine Authentisierung, Autorisierung oder anwendungsspezifische Missbrauchserkennung. Gegen verteilte Angriffe kann außerdem eine vorgelagerte Netz- oder Providerstrategie erforderlich sein.

Zusammenhang: Netzwerk und Heimvernetzung behandelt Netzgrenzen; CGI und Logdateien die Diagnose dynamischer Endpunkte.

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: Beobachtungen für Betrieb und Diagnose

Protokolldaten können Scanverkehr, Fehlermuster, Rate-Limit-Reaktionen und ungewöhnliche Änderungen im Betrieb sichtbar machen. Einzelne Logzeilen sind jedoch zunächst Beobachtungen; ihre Bedeutung entsteht erst durch technische Einordnung und Vergleich mit dem erwarteten Zustand.

• 404-Cluster: können typischen Scanverkehr oder veraltete interne Links sichtbar machen.
• 429-Antworten: zeigen Reaktionen eines Rate Limits und helfen bei der Abstimmung.
• TLS-Fehler: können veraltete Clients, Bots oder Fehlkonfigurationen anzeigen.
• User-Agent-Angaben: sind fremdgesteuerte Werte und allein kein zuverlässiger Identitätsnachweis.

Access-Logs können personenbezogene oder anderweitig sensible Daten enthalten. Zweck, Zugriffsschutz, Aufbewahrung und Löschung müssen deshalb zum tatsächlichen Betrieb passen.

Vertiefung: CGI und Logdateien behandelt Request- und Error-Logs ausführlich. Die aktuelle Datenverarbeitung auf sslxy.de steht in datenschutz.htm.

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: wiederverwendbare Bausteine mit Versionsbezug

Wiederverwendbare Konfigurationsbausteine können Pflegefehler reduzieren, solange Vererbung, Include-Reihenfolge und Serverversion verstanden werden. Ein Snippet ist keine universelle Sicherheitsvorlage.

nginx – Beispielprinzip

Apache – Beispielprinzip

Besonders bei Apache und nginx können Direktiven, Module und Vererbungsregeln versions- oder kontextabhängig wirken. Vor Reload oder Restart gehört deshalb ein Konfigurationstest ebenso zum Ablauf wie die externe Prüfung der tatsächlich ausgelieferten Header.

Vertiefung: Unix und Linux im Alltag, Shell-Accounts und Hosts und CGI und Logdateien behandeln die System- und Diagnoseebene hinter der Webserverkonfiguration.

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.

Zusammenhang: SSL und Zertifikate behandelt TLS-Endpunkte und Zertifikatsnamen; Netzwerk und Heimvernetzung die darunterliegenden Netzpfade.

Adminzugriff gehört getrennt vom öffentlichen Webverkehr

SSH-Administration sollte mit begrenzten Konten, nachvollziehbarer Authentisierung und möglichst kleiner Exposition betrieben werden. Ein dauerhaft genutzter direkter Root-Arbeitsmodus vergrößert den Schadensradius und erschwert die Zuordnung von Änderungen.

Ob Schlüssel, zusätzliche Faktoren, VPN, Bastion oder eine Kombination sinnvoll ist, hängt von Architektur und Risiko ab. Entscheidend bleibt, dass Administrationszugänge als besonders schützenswerte Zugänge eine eigene Schutz- und Wiederherstellungsstrategie erhalten.

Vertiefung: Fernwartung und Remote-Zugriffe behandelt die Entwicklung von Telnet/FTP zu verschlüsselten Remote-Verfahren; Shell-Accounts und Hosts den historischen Accountkontext.

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.

Zusammenhang: Schlüsselmaterial gehört auch zu SSL und Zertifikate; sichere Kopien und Wiederherstellung zu Datensicherung und Backups.

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.

Zusammenhang: Diese kontrollierte Prüfweise wird auf Software- und Tool-Alltag und Webmaster-Arbeit seit 1996 weitergeführt.

Härtung wird als kontrollierte Änderung betrieben

Zusammenhang: Datensicherung und Backups liefert den Rückfallpfad; Software- und Tool-Alltag die Werkzeugperspektive.

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 mindestens ausgewählte Restores unter realistischen Bedingungen erfolgreich geprüft wurden.

Sicherungen sollten nicht vollständig über denselben Fehlerpfad, dieselben Zugangsdaten oder dieselbe administrative Vertrauensgrenze wie das Produktivsystem zerstörbar sein.

Vertiefung: Die ausführliche Restore- und Archivpraxis steht auf Datensicherung und Backups.

Bei Verdacht auf Kompromittierung reicht ein Neustart nicht

Ein Sicherheitsvorfall braucht eine nachvollziehbare Reihenfolge: Auswirkungen begrenzen, relevante Beweise und Protokolle sichern, Zugangsdaten und Schlüssel bewerten, Ursache und Reichweite bestimmen, betroffene Komponenten kontrolliert neu aufbauen oder bereinigen und erst danach in einen vertrauenswürdigen Betriebszustand zurückkehren.

Wenn ein Secret kompromittiert sein könnte, gehört Rotation zum Vorfall. Wenn die Vertrauensbasis des Systems nicht mehr zuverlässig bewertbar ist, kann ein sauberer Neuaufbau belastbarer sein als eine Folge punktueller Reparaturen.

Zusammenhang: Datensicherung und Backups behandelt den Wiederherstellungspfad; CGI und Logdateien die Sicherung und Auswertung relevanter Protokolldaten.

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.

Zusammenhang: Der bewusste Umgang mit Abhängigkeiten wird auf Software- und Tool-Alltag und philosophy.htm vertieft.

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.

Zusammenhang: Tests bleiben nur dann aussagekräftig, wenn ihre Grenzen bekannt sind. Diese Werkzeugbewertung wird auf Software- und Tool-Alltag weitergeführt.

Checkliste vor Go-Live oder größerer Sicherheitsänderung

„Eine sichere Konfiguration ist nicht die längste, sondern diejenige, deren Zweck, Wirkung und Rückweg auch später noch nachvollziehbar sind.“

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.

Vertiefung: Datensicherung und Backups behandelt Erhaltung und Restore; Unix und Linux im Alltag den Systemkontext historischer Konfigurationen.

Querverweise im SSLXY-Archiv

Server-Härtung überschneidet sich mit Hostbetrieb, Webentwicklung, Netzwerken, Zertifikaten, Logging, Remote-Zugriffen, Backups und Werkzeugbewertung. Die bekannten Zielseiten sind bereits mit ihren endgültigen Dateinamen verknüpft.

• Startseite von sslxy.de
• Webentwicklung 1996
• Webmaster-Arbeit seit 1996
• Shell-Accounts und Hosts
• CGI und Logdateien
• SSL und Zertifikate
• Unix und Linux im Alltag
• Fernwartung und Remote-Zugriffe
• Netzwerk und Heimvernetzung
• Datensicherung und Backups
• Software- und Tool-Alltag
• Technische Philosophie
• Datenschutz auf sslxy.de