Was bedeutet Website härten – und warum reicht ein Antivirusprogramm nicht?
Viele Betreiber glauben, ein Sicherheits-Plugin oder eine Firewall-Appliance genüge. Sicherheits-Härtung ist ein anderer Ansatz: Sie reduzieren aktiv die Angriffsfläche Ihres Systems, bevor ein Angreifer sie ausnutzen kann. Das unterscheidet präventive Härtung von reaktiven Sicherheitslösungen wie Antivirusprogrammen, die erst nach einer Infektion eingreifen.
Defence-in-Depth: Mehrere Schichten, kein einzelner Schutzwall
Das Konzept hinter professioneller Härtung ist Defence-in-Depth: Jede Sicherheitsschicht setzt voraus, dass die nächste versagen könnte. Eine WAF allein nützt wenig, wenn der Datenbanknutzer Root-Rechte hat. Ein starkes Passwort bringt wenig, wenn veraltete Bibliotheken eine bekannte CVE enthalten. Erst das Zusammenspiel aller Schichten erzeugt echte Widerstandsfähigkeit.
- Patch-Management: Software, Frameworks und CMS-Plugins aktuell halten
- Zwei-Faktor-Authentifizierung (2FA / MFA): Kontodiebstahl auch bei geleakten Passwörtern verhindern
- Web Application Firewall (WAF): Angriffe auf Anwendungsebene filtern und blockieren
- Least Privilege / Minimale Rechte: Jeder Prozess, Nutzer und Dienst erhält nur die Rechte, die er wirklich benötigt
- Datei-Integritätsmonitoring (FIM): Unerlaubte Änderungen an Systemdateien sofort erkennen
- Sichere Konfiguration: Webserver, TLS, Security Headers und Netzwerk korrekt einrichten
- Monitoring und Logging: Auffälligkeiten früh erkennen, dokumentieren und darauf reagieren
Sicherheits-Härtung ist eine Teildisziplin unserer übergeordneten Leistung Website-Sicherheit. Wenn Sie zuerst wissen möchten, wo Ihr System aktuell steht, empfehlen wir einen Sicherheits-Audit als Einstieg.
Patch-Management: Bekannte Lücken schließen, bevor Angreifer sie finden
Die meisten erfolgreichen Angriffe auf Webanwendungen nutzen bekannte Schwachstellen – keine Zero-Days. Angreifer scannen das Internet automatisiert nach ungepatchten Versionen von WordPress, Symfony, Laravel, jQuery oder gängigen Server-Paketen. Ein konsequentes Patch-Management ist damit oft die wirksamste Einzelmaßnahme überhaupt.
Automatisierte Updates und Dependency-Scanning
- 1
Inventarisierung aller Abhängigkeiten
Wir erfassen sämtliche eingesetzten Pakete, Libraries, Plugins und Server-Komponenten mit ihren Versionsnummern und konfigurieren Software Composition Analysis (SCA) – zum Beispiel über Dependabot oder npm audit – direkt in Ihre CI/CD-Pipeline.
- 2
Konfiguration automatisierter Sicherheitsupdates
Für Debian/Ubuntu-Server richten wir unattended-upgrades so ein, dass sicherheitsrelevante Pakete automatisch eingespielt werden – ohne manuellen Aufwand und mit konfigurierbaren Blacklists für kritische Produktivpakete, die Sie manuell freigeben möchten.
- 3
Lock-Files und Prüfsummen für Abhängigkeiten
Lock-Files (composer.lock, package-lock.json) werden versioniert. Jede Änderung an Abhängigkeiten läuft über einen definierten Freigabeprozess mit Prüfsummen-Vergleich, sodass keine ungeprüfte Bibliothek in die Produktion gelangt.
- 4
Secrets-Scan im Quellcode
Laut GitGuardian State of Secrets Sprawl Report 2025 wurden allein 2024 rund 23,8 Millionen Zugangsdaten auf GitHub exponiert – und 70 % der 2022 geleakten Secrets waren 2025 noch gültig. Wir richten automatisierte Scans ein, die Credentials, API-Keys und Tokens im Quellcode erkennen, bevor sie in ein Repository gelangen.
Zwei-Faktor-Authentifizierung: Den größten Hebel für Konto-Sicherheit aktivieren
Laut einer Microsoft-Studie (Alex Weinert, RSA 2020) blockiert MFA über 99,9 % aller automatisierten Kontoübernahme-Angriffe. Trotzdem ist 2FA bei vielen Unternehmenswebseiten und Admin-Oberflächen nicht aktiviert – oder es wird eine schwache Variante eingesetzt. Das BSI hat die gängigen 2FA-Verfahren bewertet; nicht alle sind gleich sicher.
2FA-Verfahren im Vergleich (nach BSI-Bewertung)
| Verfahren | Sicherheitsniveau | Phishing-Resistent | BSI-Empfehlung |
|---|---|---|---|
| FIDO2 / Hardware-Token | Sehr hoch | Ja – kryptografische Domain-Bindung, privater Schlüssel verlässt das Gerät nie | Erste Wahl |
| TOTP-App (z. B. Authenticator) | Hoch | Nein – Echtzeit-Phishing-Proxy-Angriffe möglich | Empfohlen |
| Push-TAN | Mittel bis hoch | Nein – gerätegebunden, aber ohne Domain-Bindung | Akzeptabel |
| SMS-TAN | Mittel | Nein – anfällig für SIM-Swapping und Dienst-Leaks | Schwächste Option |
Wir implementieren 2FA passend zu Ihrer bestehenden Infrastruktur: FIDO2/WebAuthn für maximale Sicherheit, TOTP-Integration für CMS und Admin-Panels (WordPress, Typo3, Laravel Fortify, Filament), und begleiten Ihr Team bei der Umstellung ohne Produktivitätsverlust.
SMS-TAN ist nach BSI-Bewertung die schwächste 2FA-Variante und anfällig für SIM-Swapping. Wenn Ihr Admin-Bereich aktuell per SMS gesichert ist, empfehlen wir die Migration auf TOTP oder FIDO2.
Web Application Firewall (WAF): Angriffe auf Anwendungsebene filtern
Eine klassische Netzwerk-Firewall blockt auf IP- und Port-Ebene. Eine WAF operiert auf Layer 7 des OSI-Modells – sie analysiert den HTTP-Inhalt jeder Anfrage und blockiert bekannte Angriffsmuster wie SQL-Injection, Cross-Site-Scripting (XSS) oder Server-Side Request Forgery (SSRF), bevor diese Ihre Anwendung erreichen.
ModSecurity mit OWASP Core Rule Set: Open-Source, bewährt, anpassbar
Für Apache- und Nginx-Server setzen wir ModSecurity in Kombination mit dem OWASP Core Rule Set (CRS) ein. Das CRS bietet vorkonfigurierte Erkennungsregeln für alle OWASP-Top-10-Angriffskategorien und wird aktiv gepflegt. Im Anschluss an die Installation führen wir ein Tuning durch: URI-Parameter-Whitelists, explizite Allow/Deny-Regeln und ein Paranoia-Level, das zu Ihrem Traffic-Profil passt – damit keine legitimen Anfragen fälschlicherweise geblockt werden.
- SQL-Injection und NoSQL-Injection (OWASP A03)
- Cross-Site-Scripting (XSS) und HTML-Injection
- Server-Side Request Forgery / SSRF (OWASP A10)
- Path Traversal und Local File Inclusion
- Layer-7-DDoS und Brute-Force-Angriffe auf Login-Endpunkte
- Bekannte Exploit-Signaturen auf Basis öffentlicher CVEs
Eine WAF ist kein Allheilmittel – sie ist eine Schicht in einem Defence-in-Depth-Konzept. Wir konfigurieren sie immer zusammen mit den übrigen Härtungsmaßnahmen, nie als Ersatz dafür.
Least Privilege: Jeder Prozess bekommt nur, was er wirklich braucht
Das Prinzip minimaler Rechte (Least Privilege) ist eines der wirksamsten Konzepte in der IT-Sicherheit: Jeder Nutzer, jeder Prozess und jeder Dienst erhält ausschließlich die Berechtigungen, die er für seine konkrete Aufgabe benötigt – nicht mehr. BSI IT-Grundschutz Baustein ORP.4 fordert dies explizit, ebenso Art. 32 Abs. 4 DSGVO, der die Verarbeitung personenbezogener Daten nur auf Weisung des Verantwortlichen erlaubt.
Konkrete Umsetzung auf Infrastruktur-Ebene
Ein kompromittiertes Konto mit eingeschränkten Rechten kann erheblich weniger Schaden anrichten als ein kompromittiertes Admin-Konto. Least Privilege begrenzt den sogenannten Blast Radius – also den maximalen Schaden, den ein Angreifer nach einem erfolgreichen Einbruch verursachen kann.
Datei-Integritätsmonitoring: Unerlaubte Änderungen sofort erkennen
Webshells – vom Angreifer eingeschleuste PHP- oder Script-Dateien – fallen ohne aktives Monitoring oft wochenlang nicht auf. Datei-Integritätsmonitoring (FIM) erstellt kryptografische Prüfsummen aller sicherheitsrelevanten Dateien und schlägt Alarm, sobald eine Datei ohne autorisierte Änderung verändert, gelöscht oder hinzugefügt wird.
AIDE oder OSSEC: Das richtige Werkzeug für Ihre Infrastruktur
FIM-Werkzeuge im Vergleich
| Werkzeug | Architektur | Echtzeit-Alerts | Geeignet für |
|---|---|---|---|
| AIDE | Standalone, kein Daemon | Nein – zeitgesteuert via Cron | Einzelne Server, einfache Deployments ohne zentrale Infrastruktur |
| OSSEC | Client-Server (HIDS) | Ja – inkl. Log-Analyse und Rootkit-Detection | Multi-Server mit zentralem Log-Management, auch Windows-Agenten |
| Tripwire | Standalone mit Policy-Engine | Nein – zeitgesteuert | Umgebungen mit strengen Audit-Anforderungen, Zwei-Schlüssel-Verschlüsselung |
Für einzelne Server empfehlen wir AIDE (Advanced Intrusion Detection Environment): leichtgewichtig, kein zusätzlicher Daemon, SHA-256/SHA-512-Prüfsummen, Überwachung von Inode, Zugriffsrechten und Dateigröße. Für Umgebungen mit mehreren Servern setzen wir OSSEC mit zentralem Management und Echtzeit-Alerts ein. Wir konfigurieren das Monitoring, integrieren die Alerts in Ihr Benachrichtigungssystem und stellen sicher, dass die Baseline nach jedem legitimen Deployment aktualisiert wird.
Sichere Server-Konfiguration: Von TLS bis Security Headers
Eine falsch konfigurierte Server-Umgebung stellt eine der größten Angriffsflächen dar – und ist gleichzeitig eine der am einfachsten zu behebenden. Versionsinfos in HTTP-Headern, veraltete TLS-Versionen, fehlende Security Headers und offene HTTP-Methoden sind typische Befunde, die bei jedem Penetrationstest auftauchen.
Apache und Nginx: Die wichtigsten Härtungsmaßnahmen
Fehlende Security Headers wie CSP oder HSTS sind kein ästhetisches Problem – sie ermöglichen Clickjacking, XSS und Protokoll-Downgrade-Angriffe. Qualys SSL Labs und securityheaders.com listen diese Lücken als kritische Befunde.
Monitoring und Logging: Angriffe früh erkennen, bevor sie Schaden anrichten
OWASP klassifiziert unzureichendes Logging und Monitoring als eigenständige Kategorie (A09:2021) – weil fehlende Protokollierung bedeutet, dass ein Angreifer oft tagelang unentdeckt agieren kann. DSGVO Art. 32 fordert zudem die regelmäßige Prüfung, Bewertung und Evaluierung der Wirksamkeit aller Sicherheitsmaßnahmen – was ohne belastbare Logs schlicht nicht möglich ist.
Was geloggt werden muss – und wie
- Authentifizierungsfehler (fehlgeschlagene Logins, gesperrte Konten)
- Abgelehnte Zugriffsversuche auf geschützte Ressourcen
- WAF-Auslöser und Rate-Limit-Ereignisse
- Konfigurationsseitige Änderungen an Server- und Anwendungsdateien
- Admin-Aktionen (Nutzeranlage, Rechtevergabe, Massenexporte)
- Fehler in der Kryptografie oder beim Session-Management
Wir richten zentralisiertes, manipulationssicheres Logging ein: JSON-Format für SIEM-Integration, Write-Once-Konfiguration und Remote-Log-Shipping, sodass ein Angreifer seine Spuren nicht verwischen kann. Automatische Alerts für definierte Anomalie-Schwellenwerte stellen sicher, dass Ihr Team bei einem Vorfall sofort benachrichtigt wird – und nicht erst nach Tagen durch Zufall.
Incident-Response-Pläne gehören zum Monitoring: DSGVO verpflichtet zur Meldung von Datenpannen innerhalb von 72 Stunden. Ohne dokumentierte Prozesse und belastbare Logs ist diese Frist kaum einzuhalten.
Häufige Fehler beim Website-Härten – und wie wir sie systematisch beheben
Die meisten Schwachstellen, die wir in der Praxis vorfinden, sind keine exotischen Zero-Days. Sie sind bekannte, dokumentierte Fehler, die seit Jahren in OWASP, BSI-Grundschutz und CVE-Datenbanken gelistet sind – aber nie behoben wurden. Security Misconfiguration belegt in der OWASP Top 10:2021 als Kategorie A05 Platz fünf und ist damit eine der häufigsten und folgenreichsten Schwachstellenklassen überhaupt.
Häufige Schwachstellen und ihre Behebung
| Schwachstelle | Risiko | Unsere Maßnahme |
|---|---|---|
| Default Credentials nicht geändert | Hoch – trivialer Einstiegspunkt bei echten Einbrüchen | Sichere Passwörter erzwingen, 2FA aktivieren |
| Veraltete TLS-Versionen (1.0/1.1 aktiv) | Hoch – Downgrade-Angriffe möglich | TLS 1.2/1.3 erzwingen, ältere Versionen deaktivieren |
| Versionsinfos in HTTP-Headern sichtbar | Mittel – erleichtert gezieltes Vulnerability-Scanning | server_tokens off, ServerTokens Prod konfigurieren |
| Fehlende Security Headers | Hoch – XSS, Clickjacking und MIME-Sniffing möglich | CSP, HSTS, X-Frame-Options, nosniff vollständig setzen |
| Datenbanknutzer mit Root-Rechten | Kritisch – vollständige Datenbank bei SQL-Injection kompromittierbar | Minimale SQL-Rechte, kein admin-Account für Anwendungen |
| Secrets im Quellcode oder Repository | Kritisch – Zugangsdaten dauerhaft exponiert | Secrets-Scan, Umgebungsvariablen, Secret Manager einrichten |
| Kein Datei-Integritätsmonitoring | Hoch – Webshells bleiben wochenlang unentdeckt | AIDE oder OSSEC konfigurieren, regelmäßige Baseline-Prüfung |
| Fehlende oder unvollständige Logs | Hoch – Angriffe bleiben unentdeckt, DSGVO-Nachweis fehlt | Zentralisiertes Logging, automatische Alerts einrichten |
Präventive Härtung setzt an diesen dokumentierten Schwachstellen an: systematisch, checklisten-basiert und vollständig schriftlich dokumentiert, damit Sie gegenüber Prüfern und Aufsichtsbehörden jederzeit belastbare Nachweise erbringen können.
BSI IT-Grundschutz und DSGVO Art. 32: Normative Anforderungen, die wir erfüllen
Härtung ist nicht nur eine technische Best Practice – sie ist regulatorisch gefordert. BSI IT-Grundschutz, DSGVO Art. 32, NIS 2 und ISO 27001 verlangen explizit Konfigurationsmanagement, Zugriffskontrollen und nachweisbare Sicherheitsmaßnahmen. Wir liefern nach jeder Härtungsmaßnahme eine schriftliche Dokumentation, die Sie als Nachweis gegenüber Aufsichtsbehörden und im Falle eines Audits verwenden können.
- DSGVO Art. 32: Pseudonymisierung, Verschlüsselung, Vertraulichkeit, Integrität, Verfügbarkeit, Wiederherstellbarkeit und regelmäßige Wirksamkeitsprüfung – wir implementieren und dokumentieren alle genannten Maßnahmen
- BSI OPS.1.1.1: Konfigurationsvorgaben zur Härtung dokumentieren, bereitstellen und automatisiertes Monitoring einrichten – unser Standard-Lieferumfang
- BSI ORP.4: Vollständige Dokumentation des Benutzer- und Gruppen-Lebenszyklus, regelmäßige Zugriffsrevision – wir liefern das Berechtigungskonzept schriftlich
- NIS 2: Risikomanagementmaßnahmen, Incident-Response, sichere Lieferkette – unsere Härtungsmaßnahmen adressieren alle drei Bereiche
- ISO 27001: International anerkannter Nachweis gegenüber Aufsichtsbehörden und Geschäftspartnern – unsere Dokumentation ist auf ISO-Auditanforderungen abgestimmt
Laut einer Analyse von FB Pro GmbH enthält das BSI IT-Grundschutz-Kompendium 2023 den Begriff Härtung 55-mal – doppelt so häufig wie die 2018er-Edition. Härtung ist damit kein Bonus-Feature, sondern Kernanforderung des Grundschutzes (Quelle: FB Pro GmbH – BSI Grundschutz Systemhärtung, Drittquelle auf Basis des BSI-Kompendiums).