Härtungs-Checkliste für Windows Server im Internet

Wie diese Liste zu benutzen ist

Härtungs-Checklisten scheitern meist aus einem Grund: Sie sind alphabetisch statt nach Risiko geordnet. Man arbeitet sie von oben ab, und die Zeit ist irgendwo bei der Bildschirmschoner-Richtlinie aufgebraucht, ohne dass der Fernzugriff je drankam.

Diese hier ist geordnet. Die ersten Abschnitte entfernen die Wege, auf denen Server tatsächlich übernommen werden. Der letzte ist wichtig und rettet Sie allein nicht. Wenn Sie nur einen Nachmittag haben: Abschnitte 2 und 3, dann aufhören.

Die Liste setzt einen Server voraus, der aus dem Internet erreichbar bleiben muss. Wenn Ihrer das nicht muss, schrumpft Abschnitt 3 auf eine Zeile, und das ist eine gute Nachricht.

1. Konten und Authentifizierung

Nahezu jede Übernahme eines Servers im Internet beginnt mit gültigen Zugangsdaten — geraten, gesprayt, aus einem fremden Leak wiederverwendet oder gephisht. Hierhin gehört der Aufwand.

• Deaktivieren oder benennen Sie das eingebaute Administrator-Konto um. Es ist der erste Name auf jeder Angriffsliste, und seine allgemein bekannte SID bedeutet, dass Umbenennen allein keine Abwehr ist — deaktivieren ist besser, mit einem separaten benannten Admin-Konto.
• Verlangen Sie Multi-Faktor-Authentifizierung für jedes Konto mit Remote-Anmeldung. Das ist die wertvollste Maßnahme auf dieser Liste; ein erratenes Passwort ist ohne zweiten Faktor nichts wert.
• Erzwingen Sie lange Passwörter — 15 Zeichen Minimum widerstehen Offline-Cracking weit besser als Komplexitätsregeln auf einem kürzeren — und sperren Sie bekannt geleakte Passwörter, wenn Ihre Werkzeuge das können.
• Prüfen Sie, wer tatsächlich Fernzugriff hat. Entfernen Sie Konten Ausgeschiedener, von Auftragnehmern mit beendeter Arbeit und von Diensten, die es nicht mehr gibt. Jedes ruhende Konto ist Angriffsfläche ohne Aufsicht.
• Geben Sie Dienstkonten eigene Identitäten, keine interaktiven Anmelderechte und Passwörter, die sonst nirgends verwendet werden.
• Gehen Sie mit der Kontosperrung vorsichtig um. Auf einem Host im Internet lässt sie jeden Ihre Konten auf Zuruf deaktivieren; halten Sie die Schwelle moderat und verlassen Sie sich nie darauf als Abwehr gegen Raten.

2. Netzwerk-Exponiertheit

Die zweite Frage nach „wer darf sich anmelden" lautet „von wo". Jeder aus dem Internet erreichbare Port ist ein Dienst, den gerade jemand testet.

• Inventarisieren Sie von außen, was wirklich lauscht. Get-NetTCPConnection -State Listen auf dem Host, dann von einem anderen Netz aus prüfen, was davon antwortet.
• Schließen Sie SMB (445) am Perimeter. Es sollte praktisch nie ins Internet zeigen, und es ist ein häufiger Zweitfund auf Servern, die nur RDP exponieren sollten.
• Dasselbe für WinRM (5985/5986), MS SQL (1433) und jede Management-Schnittstelle. Muss ein Dienst nicht aus dem Internet erreichbar sein, ist genau das die ganze Lösung.
• Schränken Sie bei RDP selbst die Quelladressen ein, wenn möglich. Wenn nicht, lesen Sie weiter — Abschnitt 3 ist die kompensierende Maßnahme.
• Aktivieren Sie Network Level Authentication, damit für einen nicht authentifizierten Client nie eine Sitzung entsteht.
• Prüfen Sie auch die Cloud-Sicherheitsgruppe, nicht nur die Windows-Firewall. Zwei Ebenen heißt zwei Stellen, an denen man es falsch machen kann, und eine alles erlaubende Gruppe vor einer sorgfältigen Host-Firewall ist eine häufige Diskrepanz.

3. Automatisches Sperren fehlgeschlagener Anmeldungen

Diesen Abschnitt lassen die meisten Checklisten aus, und er ist derjenige, der den Alltag eines exponierten Servers verändert.

Windows protokolliert jede fehlgeschlagene Authentifizierung als Ereignis 4625 und bringt eine durchaus fähige Firewall mit, liefert aber nichts, was beides verbindet. Sich selbst überlassen, schluckt ein Server tausende Rateversuche pro Tag: verbrauchte CPU, aufgewühltes Audit-Log und keine Obergrenze dafür, wie lange ein Angreifer weiterprobieren darf.

Was Sie brauchen, ist das Äquivalent von fail2ban: den Fehlschlagstrom beobachten und eine Quelle, die eine Schwelle überschreitet, an der Firewall verwerfen. Drei Eigenschaften trennen eine funktionierende Umsetzung von einer leckenden — das Subnetz statt der Einzeladresse sperren, Sperren dauerhaft und neustartfest machen, und den eigenen Zugang auf die Whitelist setzen, bevor irgendetwas aktiviert wird.

Man kann das als geplante PowerShell-Aufgabe bauen, und für einen einzelnen täglich betreuten Server ist das eine vertretbare Wahl. Planen Sie einen Tag ein und wissen Sie, dass ihr Fehlerfall Stille ist: Geplante Aufgaben stoppen nach Neustarts und Passwortänderungen, ohne jemandem Bescheid zu geben. RDP Protector ist dieselbe Logik als verwalteter Agent, mit Whitelist, Subnetzbehandlung, Porterkennung und einer Lebendanzeige.

4. Patches und Angriffsfläche

Zugangsdaten sind der übliche Weg hinein; ungepatchte Dienste der einprägsame.

• Aktivieren Sie automatische Updates oder fahren Sie einen Patch-Zyklus, den Sie wirklich einhalten. RDP hatte Schwachstellen mit Codeausführung vor der Authentifizierung und wird weitere haben.
• Entfernen Sie Rollen und Features, die Sie nicht nutzen. Eine IIS-Installation, an deren Aktivierung sich niemand erinnert, ist ein Dienst, den jemand anderes finden wird.
• Deinstallieren Sie Software, die mit dem Image kam und nicht gebraucht wird. Jeder Agent, jede Toolbar und jeder Hersteller-Updater ist Code, der mit Rechten auf Ihrem Host läuft.
• Halten Sie die Agent-Software aktuell, die Sie tatsächlich betreiben, einschließlich Monitoring und Backup.
• Schalten Sie Legacy-Protokolle ab — SMBv1, TLS 1.0 und 1.1, NTLMv1 —, sofern nichts sie wirklich braucht; und wenn doch, schreiben Sie auf was, und kommen Sie darauf zurück.

5. Protokollierung und Erkennung

Sie können nicht untersuchen, was Sie nicht aufgezeichnet haben, und die Standardkonfiguration zeichnet weniger auf, als Sie denken, und kürzer, als Sie erwarten.

• Stellen Sie sicher, dass die Anmeldeüberwachung Fehler erfasst, nicht nur Erfolge: auditpol /get /subcategory:"Logon" muss beides zeigen.
• Erhöhen Sie die Maximalgröße des Sicherheitsprotokolls. Die Voreinstellung füllt sich auf einem exponierten Host in Stunden, und die Ereignisse, die Sie brauchen, sind weg, bevor Sie hinsehen.
• Leiten Sie Ereignisse vom Host weg. Das lokale Protokoll einer kompromittierten Maschine ist Beweismaterial, das ein Angreifer bearbeiten kann; eine Kopie anderswo ist es nicht.
• Alarmieren Sie auf das Bedeutsame statt auf Volumen: eine erfolgreiche Anmeldung aus einem neuen Land, ein neuer lokaler Administrator, ein installierter Dienst, das Leeren des Audit-Logs (Ereignis 1102).
• Sehen Sie gelegentlich und bewusst durch, wer sich erfolgreich angemeldet hat. Fehlanmeldungen sind Rauschen; eine erfolgreiche, die Sie nicht erklären können, ist die ganze Sache.

6. Backups, die Sie tatsächlich wiederhergestellt haben

Dieser Abschnitt steht nicht deshalb am Ende, weil er am wenigsten zählt. Sondern weil er die Maßnahme ist, die voraussetzt, dass alle anderen versagt haben — und an diesem Tag zählt nur eine Eigenschaft Ihrer Backups.

Halten Sie mindestens eine Kopie, die der Server selbst weder erreichen noch löschen kann. Ransomware-Betreiber suchen das Backup-Ziel, bevor sie irgendetwas verschlüsseln, und eine Freigabe, auf die der kompromittierte Host schreiben kann, ist kein Backup, sondern eine zweite Kopie, die auf ihre Zerstörung wartet.

Und dann stellen Sie eines wieder her. Ein Backup, das nie zurückgespielt wurde, ist eine Hypothese. Testen Sie es planmäßig, notieren Sie, wie lange es gedauert hat, und sorgen Sie dafür, dass mehr als eine Person das Verfahren kennt.