Die eigene Seite härten, in 16 Schritten

Ein Inventar führen

Du kannst nur schützen, was du kennst. Eine Liste aller Dienste, Geräte, Images und Versionen ist die Grundlage für alles Weitere, vom Update bis zur Wiederherstellung.

• Am einfachsten ist eine Datei im Git-Repository, ein Abschnitt pro Dienst.
• Pro Dienst festhalten: Zweck, Version, öffentlich ja/nein, wo die Daten liegen.
• Beim Hinzufügen oder Entfernen eines Dienstes gleich mit pflegen, nicht „später“.

Die eigene Angriffsfläche kennen

Welche Subdomains, Ports und Dienste sieht das Internet? Oft mehr, als man denkt: ein vergessener Testdienst, ein Router-Panel, ein offener Datenbank-Port.

• Von außen prüfen, zum Beispiel über das Mobilnetz, nicht aus dem eigenen LAN.
• Zertifikats-Transparenzlogs zeigen, welche Subdomains öffentlich bekannt sind.
• Abhängigkeiten aufschreiben: Was fällt aus, wenn die Datenbank oder das DNS ausfällt?

Genau ein Eingang, alles andere zu

Ein Reverse Proxy nimmt alle Anfragen auf Port 443 entgegen und verteilt sie. Kein Dienst bekommt einen eigenen Port im Router. Datenbanken und Admin-Oberflächen sind von außen gar nicht erreichbar.

• Router: nur 80/443 weiterleiten, und 80 nur für die Umleitung auf HTTPS.
• Vor Apps ohne eigene starke Anmeldung gehört ein zentrales Login, zum Beispiel per ForwardAuth.
• Dienste, die nur du brauchst, über VPN statt öffentlich erreichbar machen.

TLS überall, automatisch erneuert

Jede Verbindung ist verschlüsselt. Zertifikate erneuern sich selbst, denn ein abgelaufenes Zertifikat ist der häufigste selbstverschuldete Ausfall.

• Let's Encrypt mit automatischer Erneuerung, idealerweise ein Wildcard-Zertifikat per DNS-Challenge.
• HSTS aktivieren, damit Browser nie mehr unverschlüsselt anfragen.
• Veraltete Protokolle (TLS 1.0/1.1) abschalten.

Security-Header setzen

Mit wenigen Antwort-Headern sagst du dem Browser, was er darf. Die wichtigste Regel ist die Content Security Policy: Sie legt fest, woher Skripte, Styles und Schriften geladen werden dürfen. Ein allgemeines Beispiel für eine rein statische Seite:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self';
  img-src 'self' data:; font-src 'self'; frame-ancestors 'none';
  base-uri 'self'; form-action 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

• Erst im Modus „Content-Security-Policy-Report-Only“ testen, dann scharf schalten.
• Schriften und Bibliotheken selbst hosten statt aus einem CDN zu laden. Das hilft auch beim Datenschutz.

Zweiter Faktor für jede Anmeldung von außen

Gestohlene Passwörter sind der häufigste Weg hinein. Ein zweiter Faktor macht ein erbeutetes Passwort allein wertlos.

• Am besten Passkeys oder Hardware-Schlüssel, sonst eine TOTP-App. SMS nur, wenn nichts anderes geht.
• Ein zentraler Identity Provider bedeutet: einmal richtig einrichten statt in jeder App neu.
• Wiederherstellungscodes offline aufbewahren.

Updates mit Plan statt mit Glück

Bekannte Lücken werden innerhalb von Stunden automatisiert ausgenutzt. Updates müssen also schnell kommen, aber nachvollziehbar.

• Image-Versionen festschreiben statt :latest. So weißt du, was läuft.
• Ein Bot (z. B. Renovate) schlägt neue Versionen als Pull Request vor, du entscheidest.
• Sicherheitsmeldungen der wichtigsten Komponenten abonnieren.

Geheimnisse raus aus Git

Ein Passwort in einem Repository ist für immer im Verlauf, auch wenn es später gelöscht wird.

• Zugangsdaten aus einem Passwort-Tresor in Dateien oder Secrets verteilen, im Repository steht nur der Verweis.
• Einen Secret-Scanner als Pre-Commit-Hook oder in der Pipeline einsetzen.
• Was einmal geleakt ist, wird rotiert. Löschen allein reicht nicht.

Minimale Rechte für jeden Dienst

Wird ein Dienst übernommen, entscheidet seine Rechte-Ausstattung über den Schaden.

• Container nicht als root, mit no-new-privileges und wenn möglich read-only.
• Den Docker-Socket nur dort einbinden, wo es unvermeidlich ist. Er entspricht Root-Rechten auf dem Host.
• Standardpasswörter ändern, ungenutzte Admin-Zugänge und Fernzugriffe abschalten.

Anmeldungen zentral sammeln und auswerten

Ein Angriff beginnt fast immer mit Anmeldeversuchen. Wer die Logs nur hat, aber nie hineinsieht, bemerkt ihn nicht.

• Logs aller Dienste an eine zentrale Stelle schicken.
• Alarm bei gehäuften Fehlversuchen, neuen Geräten oder Anmeldungen zu ungewöhnlichen Zeiten.
• Alarme aufs Handy, aber nur die wichtigen. Zu viele Alarme werden ignoriert.

Stille Ausfälle hörbar machen

Das gefährlichste Backup ist das, das seit Wochen still fehlschlägt. Jeder wichtige Job meldet aktiv seinen Erfolg. Bleibt die Meldung aus, gibt es Alarm.

• Ein „Dead Man's Switch“: Push-Monitor mit erwartetem Intervall.
• Monitoring für Erreichbarkeit, Zertifikatslaufzeit, Plattenplatz.
• Den Alarmweg selbst testen: Kommt die Nachricht wirklich an?

Unerwartete Änderungen bemerken

Wer einen Server übernimmt, ändert Dateien: Startskripte, geplante Aufgaben, Schlüssel. Eine Prüfsumme über die kritischen Dateien macht das sichtbar.

• Kritische Dateien regelmäßig hashen und mit einer Referenz vergleichen.
• Die Referenz außerhalb des überwachten Systems ablegen.
• Jede Abweichung erklären, statt sie wegzuklicken.

Netze trennen, ausgehend begrenzen

Ein übernommener Dienst soll nicht mit allem reden können. Und er soll keinen beliebigen Rückkanal ins Internet aufbauen können.

• Container nur an die Netze hängen, die sie brauchen. Datenbanken in ein internes Netz.
• IoT-Geräte in ein eigenes VLAN.
• Ausgehenden Verkehr pro Dienst auf das Nötige beschränken. Das ist mühsam, aber wirksam.

Am Rand filtern, aber mit Bedacht

Ratenbegrenzung und Reputationslisten halten Scanner und Brute-Force-Versuche fern, bevor eine App sie sieht. Ein falsch gesetzter Filter kann dich aber selbst aussperren.

• Zuerst dort einführen, wo ein Fehlalarm nichts kostet.
• Nie vor dem Weg, über den du einen Fehler beheben würdest.
• Ein DNS-Filter im Heimnetz blockt bekannte Schad-Domains für alle Geräte.

Den Notfall vorher aufschreiben

Im Ernstfall fehlt die Ruhe zum Nachdenken. Ein kurzes Runbook sagt, was in welcher Reihenfolge zu tun ist.

• Konto sperren und alle Sitzungen beenden. Wie geht das bei dir, in welchem Menü?
• Welche Zugangsdaten müssen neu, wenn Dienst X übernommen wurde?
• Einen Notzugang haben, der nicht von dem System abhängt, das gerade ausgefallen ist.

3-2-1-Backups, und die Wiederherstellung üben

Drei Kopien auf zwei Medien, eine außer Haus, verschlüsselt. Ein Backup ist aber erst dann eines, wenn die Wiederherstellung einmal geklappt hat.

• Mindestens einmal im Jahr einen Dienst vollständig auf leerer Hardware wiederherstellen.
• Das Passwort des Backups nicht nur in dem Tresor ablegen, der selbst im Backup steckt.
• Die Kopie außer Haus so anlegen, dass ein Angreifer sie nicht löschen kann.