Windows VPS absichern: die Härtungs-Checkliste

Um einen Windows VPS abzusichern, ohne daraus ein Forschungsprojekt zu machen: zuerst patchen, RDP mit NLA und IP-Allowlists härten, Kontosperrung erzwingen, eingehende Firewall-Regeln eng halten, den Echtzeitschutz von Defender aktiviert lassen und die Backups testen. Für Remote-Arbeit, Websites oder Anwendungen ist das Ziel einfach: Angriffsfläche verkleinern, Identität schützen und die Protokolle im Blick behalten.

Zuerst patchen: Updates, Treiber und Rollen

Vor allem anderen: patchen. Ungepatchte Server mit öffentlicher Erreichbarkeit sind leichte Ziele, und die meisten Einbrüche beginnen genau dort. Halten Sie Sicherheitsupdates aktuell, entfernen Sie nicht benötigte Windows-Rollen, und planen Sie Neustarts nach einem Zeitplan, mit dem Ihr Team leben kann. Das ist die unspektakuläre Arbeit, die die lauten Probleme verhindert.

• Konfigurieren Sie Windows Update so, dass Sicherheitsupdates regelmäßig eingespielt werden, und legen Sie Wartungsfenster fest, die zu Ihren Geschäftszeiten passen.
• Entfernen Sie Rollen und Features, die Sie nicht brauchen, etwa veraltete IIS-Module oder SMB-1.0-Komponenten.
• Spielen Sie Treiber-, Firmware- und App-Updates regelmäßig ein und starten Sie den Server planmäßig neu, nicht erst zwei Monate später.
• Wenn der VPS unter einer öffentlichen IP erreichbar ist, prüfen Sie die Exposition in Ihrem Cloud-Portal und schließen Sie, was nicht benötigt wird.

Fangen Sie hier an und führen Sie ein einfaches monatliches Änderungsprotokoll, damit Sie sagen können, was sich wann geändert hat. Das bereitet den Boden für das Thema Identität, wo die meisten Fortschritte entstehen.

Identität absichern: Starke Passwörter und MFA-Pfade

Identität ist Ihre Eingangstür. Lange Passphrasen und ein zweiter Faktor stoppen die meisten Standardangriffe, und sie lassen sich auch auf einem kleinen Windows Server einfach einrichten.

• Verwenden Sie Passphrasen mit mindestens 14 Zeichen. Ist der Server in eine Domäne eingebunden, ergänzen Sie eine Sperrliste für Passwörter über Ihren Identity-Stack.
• Ergänzen Sie MFA für Remote Desktop über ein RD Gateway, ein VPN oder einen Credential-Provider von Drittanbietern.
• Verwenden Sie separate, namentlich benannte Admin-Konten und erledigen Sie die tägliche Arbeit unter einem Standardbenutzer.
• Prüfen Sie, wer sich per RDP einloggen darf, kürzen Sie diese Liste und halten Sie das Prinzip der minimalen Rechte ein.

Nichts davon ist ein Trick. Es ist Konsequenz, und Konsequenz führt direkt zum Thema Konten. Wenn Sie das für einen Kunden tun, nehmen Sie diese Prüfungen in die Übergabedokumentation auf, damit der nächste Admin beim Plan bleibt.

Das Standardkonto „Administrator“ abschalten und Kontosperrung aktivieren

Angreifer bombardieren das eingebaute Administrator-Konto. Deaktivieren Sie es, legen Sie einen benannten Admin an und konfigurieren Sie eine Kontosperrung, damit Brute-Force-Versuche ins Leere laufen.

• Legen Sie ein eigenes, benanntes Admin-Konto an, testen Sie es, und deaktivieren Sie dann das integrierte Administrator-Konto. Muss es erhalten bleiben, benennen Sie es um und schützen Sie es als Notfallkonto.
• Setzen Sie die Kontosperrung auf 10 Versuche, 15 Minuten Sperrzeit und 15 Minuten Rücksetzungszeit für eine praxistaugliche Balance.
• Dokumentieren Sie einen schnellen Entsperrweg, damit der Support nicht blockiert ist, wenn jemand ein Passwort vertippt.

Basiseinstellungen und Abwägungen finden Sie in der Microsoft-Referenz zum Schwellenwert für Kontosperrung.

Kleine Änderungen wie diese zahlen sich auf einer öffentlichen VM schnell aus. Ist die Standardtür geschlossen und die Sperrung aktiv, folgt als nächste Schicht die RDP-Oberfläche.

RDP absichern: NLA, Port-Rauschen und IP-Allowlists

Remote Desktop ist ein bevorzugtes Angriffsziel. Schärfen Sie die Absicherung: Aktivieren Sie Network Level Authentication, begrenzen Sie die Angriffsfläche mit Allowlists und reduzieren Sie Bot-Anfragen auf Port 3389. Ein geänderter Port ist keine Sicherheitsmaßnahme für sich allein; er hält nur automatisierte Scanner ruhiger.

• NLA auf dem Server vorschreiben; ältere Clients ohne NLA-Unterstützung sollten sich nicht verbinden können.
• Erlauben Sie für TCP 3389 oder den neuen Port nur bestimmte Quell-IPs; besser noch, stellen Sie RDP hinter ein VPN oder ein RD Gateway.
• Den Standard-RDP-Port ändern, um Scanner-Aktivität zu reduzieren, aber diese Maßnahme nicht als eigenständige Sicherheitslösung betrachten.
• Laufwerk- und Zwischenablage-Umleitung deaktivieren, wenn nicht benötigt; Leerlauf-Timeouts setzen und erneute Authentifizierung erzwingen.

RDP abzuriegeln stoppt die meisten automatisierten Angriffe, und die Allowlist erledigt dabei den Großteil der Arbeit. Den Quellbereich einzugrenzen oder RDP-Allowlisting und Geofencing zu nutzen wenn alle Ihre Nutzer in einer Region sitzen, hält Drive-by-Traffic schon vom Anmeldebildschirm fern. Das passt gut zu vernünftigen Firewall-Regeln.

Firewall-Regeln, die Actually helfen

Host-Firewall-Regeln sollten einfach sein: standardmäßig ablehnen und dann nur öffnen, was Sie auch nutzen. Binden Sie RDP-Regeln an bekannte Quell-IPs, protokollieren Sie verworfene Pakete und halten Sie Altprotokolle draußen.

• Mit standardmäßig abgelehntem eingehenden Traffic beginnen, dann nur benötigte Ports und Protokolle freigeben.
• RDP-Regeln auf bekannte IPs beschränken, nicht auf 0.0.0.0/0, und blockierten Traffic zur Auswertung protokollieren.
• TLS 1.2 oder neuer verwenden; SMBv1 vollständig deaktivieren.
• Lassen Sie ausgehenden Verkehr standardmäßig zu, sofern Sie keine verwaltete Egress-Richtlinie haben; gezielte ausgehende Sperren nur dort, wo ein definierter Bedarf besteht.

Die Regeln, die sich wirklich lohnen, decken meist Ports ab, die niemand absichtlich geöffnet hat. Windows RPC auf TCP 135 ist das Standardbeispiel, und die Beschränkung auf vertrauenswürdige Quellen in der Host-Firewall ist derselbe Default-Deny-Reflex, nur Port für Port angewandt. Hinter diesen Ports stehen die Dienste selbst.

Dienste aufräumen: Entfernen Sie, was Sie nicht nutzen

Unnötige Dienste schaffen zusätzliche Angriffsflächen. Deaktivieren Sie alles, was Sie nicht brauchen, und prüfen Sie einen Monat später, was sich wieder eingeschlichen hat.

• Deaktivieren Sie den Print Spooler, wenn der Server kein Druckserver ist.
• Deaktivieren Sie den Remote Registry-Dienst und veraltete Protokolle, die Sie nicht verwenden.
• Deinstallieren Sie Web-, Datei- oder FTP-Rollen, die nicht Teil Ihrer Arbeitslast sind.
• Prüfen Sie Autostart-Einträge und geplante Aufgaben, und untersuchen Sie alles Unbekannte, bevor Sie es deaktivieren.

Ist das Haus aufgeräumt, ergänzen Sie Basisschutz mit Defender und leichten EDR-Einstellungen. Der Aufwand ist gering, und man merkt ihn im Alltag.

Defender, EDR und geplante Scans

Microsoft Defender Antivirus liefert auf aktuellen Windows Server-Versionen eine solide integrierte Grundlage. Halten Sie Echtzeitschutz und cloudbasierten Schutz aktiv, und nutzen Sie Schnellprüfungen für den regulären Zeitplan.

• Ist der Server in Defender for Endpoint eingebunden, aktivieren Sie dort den Manipulationsschutz (Tamper Protection).
• Halten Sie Echtzeit- und cloudbasierten Schutz aktiv, und planen Sie wöchentliche Schnellscans in einem ruhigen Zeitfenster.
• Führen Sie vollständige Prüfungen nur für konkrete Untersuchungen durch oder wenn Ihre Sicherheitswerkzeuge es verlangen.

Diese Einstellungen decken den Alltag ab, sie sind eine Grundlage und kein Managed-Detection-and-Response-Programm. Am besten wirken sie zusammen mit Backups, die Sie auch wirklich zurückspielen können.

Backups, Snapshots und Wiederherstellungstests

Ein Windows VPS, der sich nicht wiederherstellen lässt, ist ein einzelner Ausfallpunkt. Erstellen Sie täglich Snapshots, halten Sie externe Backups vor, und testen Sie die Wiederherstellung, damit Sie wissen, dass der Plan funktioniert.

• Tägliche automatische Snapshots mit einer Aufbewahrungsdauer von sieben bis 14 Tagen, bei Compliance-Anforderungen länger.
• Externe Backups bei einem Anbieter, in einer Region oder einem Bucket mit anderen Zugangsdaten.
• Monatliche Wiederherstellungstests mit dokumentierten Schritten und einer Kontaktliste für die Wiederherstellungszeit.

Wie sich Snapshots und Wiederherstellung verhalten, ist ebenso eine Plattform- wie eine Richtlinienfrage, und man prüft das besser vor dem Tag, an dem man es braucht. Wenn Sie einen neuen Server aufsetzen: unser Windows VPS offers one-click images for Server 2022, 2019, 2016, and 2012 R2.

Ein Vorbehalt wiegt hier schwerer als der Rest des Absatzes. Server 2012 steht wegen der Kompatibilität mit Altanwendungen noch auf der Image-Liste, ist aber kein Basisimage für einen gehärteten Aufbau. Microsofts Lifecycle-Hinweis zu Server 2012 nennt als Support-Ende den 10. Oktober 2023, und die kostenpflichtigen Extended Security Updates laufen am 13. Oktober 2026 endgültig aus. Auch Server 2016 nähert sich im Januar 2027 dem Support-Ende. Wenn Sie also etwas Neues bauen und es auf eine öffentliche IP stellen, beginnen Sie mit Server 2019 oder 2022.

Überwachen und protokollieren: RDP, Sicherheit, PowerShell

Für den Nutzen aus Windows-Protokollen brauchen Sie kein SIEM. Beginnen Sie mit fehlgeschlagenen Anmeldungen, erfolgreichen RDP-Sitzungen und PowerShell-Transkription. Diese drei Signale ergeben auf einem kleinen Server eine brauchbare Monitoring-Grundlage.

• Aktivieren Sie die Überwachung fehlgeschlagener Anmeldungen und beobachten Sie Event ID 4625 Spitzen.
• Verfolgen Sie erfolgreiche RDP-Anmeldungen über Event ID 4624, gefiltert auf Logon Type 10 (RemoteInteractive); 4634 steht für das Sitzungsende und 4647 für die vom Benutzer ausgelöste Abmeldung.
• Aktivieren Sie die PowerShell-Transkription per Richtlinie, damit Ein- und Ausgaben von PowerShell nachvollziehbar bleiben.

Steht die Sichtbarkeit, drucken Sie die einseitige Härtungsübersicht aus und halten Sie sie griffbereit. Hier beginnt der laufende Betrieb, denn es sind die Alarme, die die nächste Runde Patchen und Aufräumen anstoßen.

Windows VPS Härtungsübersicht

Eine kompakte Zusammenfassung zum schnellen Durchsehen vor Wartungsfenstern oder nach einem Neuaufbau.

Diese Übersicht zeigt alles auf einen Blick. Der nächste Abschnitt vergleicht dieselben Punkte für Linux, was Teams beim wechselseitigen Einarbeiten hilft.

Bonus: Vergleich mit Linux-Hardening

Manche Teams setzen auf mehrere Plattformen. Die wichtigsten Maßnahmen sind auf beiden Seiten dieselben: regelmäßige Patches, benannte Admin-Konten, starke SSH oder RDP, und Firewalls mit Deny-by-Default. Wenn dein Stack auch Linux-Server umfasst, passt dieser Windows-Plan gut zu einem sicheren Linux VPS als Ausgangspunkt, sodass deine Playbooks plattformübergreifend vertraut wirken.

Diese plattformübergreifende Sicht bereitet praktische Entscheidungen je nach Anwendungsfall vor und gibt Ihnen etwas an die Hand für die Kollegin oder den Kollegen, die den ganzen Tag SSH-Schlüssel und iptables verwalten und noch nie eine Gruppenrichtlinie geöffnet haben.

Schnellauswahl nach Anwendungsfall

Deine Liste sollte zu deiner Workload passen. Diese kurze Übersicht ordnet Maßnahmen typischen Setups zu.

• Einzelner Entwicklerrechner: NLA verlangen, den eigenen aktuellen IP-Bereich freigeben, optional den RDP-Port ändern, um Scanner-Rauschen zu senken, und wöchentliche Schnellprüfungen laufen lassen. Tägliche Snapshots aufbewahren und einmal im Monat testen.
• KMU-Anwendungsserver für ERP oder Buchhaltung: RDP hinter ein VPN oder ein RD Gateway stellen, Administratorrechte einschränken, Altprotokolle deaktivieren und Alarme bei 4625-Spitzen einrichten.
• Remote-Desktop-Farm für ein kleines Team: Zugriff über ein Gateway zentralisieren, MFA ergänzen, eindeutige Passphrasen verwenden und bei Verdacht auf Kompromittierung wechseln, und Firewall-Regeln ein- wie ausgehend eng halten.

Häufig gestellte Fragen

Reicht es, den RDP-Port zu ändern?

Nein. Es senkt nur die Zahl der Gelegenheitsscans; NLA, Kontosperrung und IP-Allowlists brauchen Sie weiterhin, oder ein VPN mit Gateway. Betrachten Sie den Portwechsel als Rauschunterdrückung, nicht als Schutzschild.

Brauche ich ein VPN für RDP?

Wenn RDP im Internet steht, reduzieren Sie die Angriffsfläche mit einem VPN oder einem RD Gateway. Kombiniert mit MFA und Firewall-Allowlists ergibt das ein einfaches, starkes Setup, das die meisten kleinen Teams betreiben können.

Wie oft sollte ich ein Windows VPS patchen?

Halten Sie sich an die Wartungsfenster Ihres Anbieters, sofern vorhanden, und spielen Sie Sicherheitsupdates für Betriebssystem und Anwendungen zeitnah nach Veröffentlichung ein. Angriffswege beginnen häufig mit öffentlicher Erreichbarkeit und bekannten Fehlern, geraten Sie beim Patchen also nicht in Rückstand. Liegen Kundendaten auf dem Server, halten Sie den Patch-Rhythmus schriftlich in einer Richtlinie fest, damit er auch eingehalten wird.

Was ist NLA, und warum sollte es aktiviert sein?

Network Level Authentication verlangt die Anmeldung, bevor die RDP-Sitzung startet, blockiert damit nicht authentifizierte Codepfade und spart Ressourcen. Microsoft empfiehlt NLA für die meisten Umgebungen; prüfen Sie, ob es aktiv ist, und lassen Sie es an.

Was sollte ich auf einem kleinen Server überwachen?

Beginnen Sie mit fehlgeschlagenen Anmeldungen (4625), 4624 mit Logon Type 10 für erfolgreiche RDP-Anmeldungen, 4634 für das Sitzungsende, 4647 für die vom Benutzer ausgelöste Abmeldung sowie der PowerShell-Transkription. Ergänzen Sie eine wöchentliche Durchsicht und eine einfache Alarmregel für Ausschläge. Das reicht als Sichtbarkeit auf einer kleinen Maschine, ganz ohne eine komplette Plattform zu kaufen.