Server Hardening
Server Hardening (Serverhärtung) bezeichnet die systematische Absicherung eines Servers durch Reduktion der Angriffsfläche. Dazu gehören das Entfernen unnötiger Dienste, das Einschränken von Zugriffsrechten und die Konfiguration von Firewalls. Im Rahmen einer Zero Trust -Strategie ist Hardening keine einmalige Maßnahme, sondern ein kontinuierlicher Prozess. Für Unternehmen schützt es vor automatisierten Angriffen und erfüllt Compliance-Anforderungen.
Warum ist Server Hardening für Webprojekte entscheidend?
Jeder öffentlich erreichbare Webserver ist ein potenzielles Angriffsziel. Ungehärtete Server mit Standardkonfigurationen, offenen Ports oder veralteter Software werden regelmäßig automatisiert kompromittiert. Server Hardening ist kein einmaliger Vorgang, sondern ein kontinuierlicher Prozess, der durch Monitoring und regelmäßige Audits begleitet werden muss. Ohne Härtung ist auch ein gültiges SSL-Zertifikat nur oberflächlicher Schutz.
Kernmaßnahmen der Serverhärtung
Minimalprinzip: Nur notwendige Dienste und Pakete installieren. SSH-Absicherung: Key-basierte Authentifizierung, Root-Login deaktivieren, Port ändern. Firewall: Nur explizit benötigte Ports öffnen (UFW, iptables, nftables). Updates: Automatisierte Sicherheitsupdates (unattended-upgrades). Dateisystem: Separate Partitionen mit noexec/nosuid-Mountoptionen. Prozess-Isolation: Dienste als unprivilegierte Benutzer ausführen. Header-Konfiguration: Content-Security-Policy, X-Frame-Options und HSTS in der Webserver-Konfiguration setzen.
Hardening im Container-Kontext
Bei Containerisierung mit Docker oder Kubernetes gelten zusätzliche Härtungsregeln: Non-Root-Container, Read-Only-Dateisysteme, minimale Base-Images (Alpine, Distroless), Security Contexts und Network Policies. Das CIS Docker Benchmark bietet einen strukturierten Leitfaden. Auch das Management von Umgebungsvariablen und Secrets innerhalb von Containern erfordert besondere Sorgfalt.
Häufige Fehler bei der Serverhärtung
Standardpasswörter nicht ändern, Debug-Modi in Produktion belassen, veraltete TLS-Versionen akzeptieren oder Logging deaktivieren. Ein weiterer verbreiteter Fehler: Security Headers nur auf der Hauptdomain setzen, aber auf API-Subdomains oder CDN -Endpunkten vergessen. Auch fehlende Automatisierung der Härtung führt dazu, dass neue Server ungehärtet deployed werden.
So setzen wir es um
Für btech-solutions.eu konfigurieren wir Apache mit HSTS (max-age=31536000, includeSubDomains, preload), strikter Content-Security-Policy und deaktivierten Hardware-Permissions. Docker-Container laufen als Non-Root-User mit Read-Only-Dateisystem. SSH-Zugang ist Key-basiert mit deaktiviertem Root-Login. Alle Härtungsmaßnahmen sind in .htaccess und Dockerfiles als Infrastructure as Code versioniert und werden über CI/CD bei jedem Deploy automatisch ausgerollt.