Windows Server 2022 absichern (Hardening)

In diesem Artikel finden sich meine Einstellungen für das Hardening von Windows Server 2022. Diese Einstellungen können für das Template für VMs genutzt werden. Neue VMs basierend auf diesen Einstellungen erhalten somit schon ein gewisses Maß an Sicherheit. Die Einstellungen sind meiner Meinung nach nicht zu restriktiv und dürften sich damit für die meisten Anwendungen/Dienste eignen.

Für das Hardening habe ich einen Windows Server 2022 Standard (mit Desktop) installiert. Dieser Artikel setzt direkt nach der Installation des Betriebssystems an. Bis auf nötige Treiber bzw. Tools des Hypervisors ist keine weitere Software installiert.

Nach der Installation des Betriebssystems sollte nur die unbedingt erforderliche Software installiert werden (beispielsweise Treiber für die Hardware oder VM-Tools), natürlich in der jeweils aktuellen Version. Zusätzliche Software, welche nur der eigenen Bequemlichkeit dienen, wie beispielsweise andere Browser oder Editoren, haben auf einem Server nichts verloren.

Windows Updates installieren

Direkt nach der Installation des Betriebssystems können schon die ersten Updates installiert werden. Wenn man es noch nicht getan hat, kann man sich an dieser Stelle auch direkt Gedanken über das Patch Management machen.

Updates müssen zeitnah installiert werden, nicht nur für das Betriebssystem, sondern auch für weitere Software, welche auf dem Server installiert wird.

Lokalen Administrator deaktivieren oder umbenennen

Am besten ist es, wenn der ein neues lokales Administrator Konto angelegt und das vorhandene Konto „Administrator“ deaktiviert wird. Hintergrund ist, dass die SID des lokalen Administrators mit „S-1-5“ beginnt und mit „-500“ endet. Somit ist es recht einfach auch den Namen eines unbenannten Administrator Kontos zu ermitteln:

Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$PrincipalContext = New-Object System.DirectoryServices.AccountManagement.PrincipalContext([System.DirectoryServices.AccountManagement.ContextType]::Machine, $env:computername)
$UserPrincipal = New-Object System.DirectoryServices.AccountManagement.UserPrincipal($PrincipalContext)
$Searcher = New-Object System.DirectoryServices.AccountManagement.PrincipalSearcher
$Searcher.QueryFilter = $UserPrincipal
$Searcher.FindAll() | Where-Object {$_.Sid -Like "*-500"} | Select-Object SamAccountName,Sid

Die bessere Variante ist also ein neues Administrator Konto zu erstellen und das Konto „Administrator“ zu deaktivieren. Wer auf Nummer sicher gehen will, deaktiviert das lokale Administrator Konto, benennt es um und legt ein neues Konto für die Administration an.

Automatischen Start des Server Manager deaktivieren

Das Deaktivieren des Server Managers ist eher kosmetischer Natur, ich persönlich finde es furchtbar, wenn Programme nach der Anmeldung automatisch starten. Gerade der Server Manager startet recht träge und verursacht für eine kurze Zeit eine relativ hohe CPU Last, dass muss ja nicht bei jeder Anmeldung am Server sein, gerade wenn man den Server Manager eher selten oder nicht benutzt:

Damit der Server Manager nicht bei jeder Anmeldung startet, kann der Task für den Server Manager im Task Scheduler deaktiviert werden:

Das Deaktivieren des Tasks schaltet den automatischen Start des Server Manager auch für weitere Benutzer ab, welche sich an dem Server anmelden.

Nicht benötigte Dienste deaktivieren

Windows Server 2022 bringt einige Dienste mit, die für die meisten Server nicht erforderlich sind. Einige der Dienste werden automatisch gestartet, manche werden nur bei Bedarf oder zyklisch durch das Betriebssystem gestartet. Ein gutes Beispiel ist der „Print Spooler“, dieser Dienst ist auf jedem Server aktiv, auch wenn der Server weder als Druckserver dient oder selbst auf Druckern drucken muss. Gerade der „Print Spooler“ sorgte aber mit der „PrintNightmare“-Schwachstelle für erhebliche Sicherheitslücken.

Dienste welche nicht benötigt werden, sollten daher unbedingt deaktiviert werden. Das folgende PowerShell Script liefert alle Dienste, welche meistens nicht benötigt werden:

$Services = @(
"InstallService",
"Spooler",
"WPDBusEnum",
"fdPHost",
"ShellHWDetection",
"TrkWks",
"bthserv",
"NcbService",
"SensrSvc",
"WiaRpc",
"upnphost",
"AudioEndpointBuilder",
"FrameServer"
)
foreach ($Service in $Services) {
Get-Service $Service | select Name,Displayname,StartType,Status
}

Mit dem oben angegeben Script lassen sich die Dienste prüfen. Wenn die Dienste nicht benötigt werden, können diese mit dem folgenden Script deaktiviert werden:

$Services = @(
"InstallService",
"Spooler",
"WPDBusEnum",
"fdPHost",
"ShellHWDetection",
"TrkWks",
"bthserv",
"NcbService",
"SensrSvc",
"WiaRpc",
"upnphost",
"AudioEndpointBuilder",
"FrameServer"
)
foreach ($Service in $Services) {
Get-Service $Service | Set-Service -StartupType Disabled
}

Wenn ein Dienst doch benötigt wird, lässt dieser sich ja wieder per Gruppenrichtlinie oder manuell wieder aktivieren. Der Spooler Dienst ist dafür ein gutes Beispiel: In der Standardeinstellung sollte dieser unbedingt deaktiviert sein und nur wenn benötigt wieder aktiviert werden.

Internet Explorer / Edge deinstallieren

In Windows Server 2022 sind gleich zwei Browser vorinstalliert: Internet Explorer und Edge. Auf einem Standard Server benötigt man meiner Meinung nach keinen Browser, daher sollte mindestens der Internet Explorer deinstalliert werden.

Der Internet Explorer erhält ab Juli 2022 keine Sicherheitsupdates und sollte daher deinstalliert werden:

dism /online /Remove-Capability /CapabilityName:Browser.InternetExplorer~~~~0.0.11.0

Auch Edge ist auf Windows Server 2022 vorinstalliert, kann aber ebenfalls deinstalliert werden:

Umso weniger Software auf einem Server installiert ist, umso weniger Angriffsfläche gibt es. Natürlich ist es bequem, wenn ein Browser installiert ist und Links in Fehlermeldungen direkt geöffnet werden können.

Wenn es unbedingt erforderlich ist, lässt sich ja später ein Browser wieder bei Bedarf nachinstallieren und direkt mit einer Policy versehen (siehe Abschnitt „Edge Security Baseline“).

Windows Security Baseline anwenden

Microsoft bietet mit dem „Microsoft Security Compliance Toolkit“ einen Satz von Einstellungen an, welche die Sicherheit des Betriebssystems erhöhen. Die empfohlenen Einstellungen lassen sich einfach anwenden und bei Bedarf auch granular zurücknehmen oder erweitern. Das Security Compliance Toolkit kann hier runtergeladen werden:

• Microsoft Security Compliance Toolkit 1.0

Aus dem Download mindestens die folgenden beiden Komponenten benötigt:

• LGPO.zip
• Windows Server 2022 Security Baseline.zip

Mit LGPO lassen sich die empfohlenen Sicherheitseinstellungen in eine lokale Gruppenrichtlinie übernehmen. Die lokale Gruppenrichtlinie hat den Vorteil, dass sie immer angewendet wird, egal ob der Server später einem Active Directory beitritt oder ein Stand-Alone Server bleibt. Die lokalen Gruppenrichtlinien lassen sich auch mit Domain Gruppenrichtlinien überschreiben, wenn dies erforderlich ist. Somit kann man immer ein gewisses Sicherheitslevel für das Betriebssystem durchsetzen, auch wenn es mal nur schnell ein Testsystem wird, welches möglicherweise keine Gruppenrichtlinie aus dem AD anwendet.

Die Sicherheitseinstellungen aus dem Security Compliance Toolkit lassen sich aber auch in eine Gruppenrichtlinie für die Domain übernehmen. Ob die Einstellungen lokal oder in der Domain vorgenommen werden, kann also frei gewählt werden.

Um die Einstellungen lokal anzuwenden, muss das Tool LGPO in den Unterordner „\Scripts\Tools“ kopiert werden:

Mit der PowerShell und dem folgenden Befehl können die Richtlinien dann importiert werden:

.\Baseline-LocalInstall.ps1 -WSMember

Der Parameter „WSMember“ gibt dabei ein, welcher Satz von Richtlinien importiert werden soll. Möglich sind die folgenden Angaben:

• WSMember – Windows Server, domain-joined member server
• WSNonDomainJoined – Windows Server, non-domain-joined
• WSDomainController – Windows Server, domain controller

WSMember eignet sich daher für die meisten Server.

Tipp: Bei VMs kann es nach dem Anwenden der Security Baseline zu dem folgenden Fehler bei der Anwendung der lokalen GPO kommen:

C:\Windows\system32>gpupdate /force
Updating policy…

Computer Policy update has completed successfully.

The following warnings were encountered during computer policy processing:

Windows failed to apply the {F312195E-3D9D-447A-A3F5-08DFFA24735E} settings. {F312195E-3D9D-447A-A3F5-08DFFA24735E} settings might have its own log file. Please click on the „More information“ link.
User Policy update has completed successfully.

For more detailed information, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

Das Problem sind hier die Einstellungen zum „Device Guard“ bzw. „Virtualization Based Security“ aus der Security Baseline. Diese Einstellungen sind möglicherweise innerhalb einer VM nicht verfügbar oder müssen erst für die VM aktiviert werden. Unter folgendem Link finden sich die Einstellungen für ESXi 7:

• Enable Virtualization-based Security on a Virtual Machine

Wenn Virtualization Based Security (VBS) vom Hypervisor nicht unterstützt wird, muss die folgende Einstellungen in der lokalen GPO geändert werden:

Edge Security Baseline anwenden

Auch für den Edge Browser gibt es eine Security Baseline, diese ist ebenfalls im Microsoft Security Compliance Toolkit halten. Wenn der Edge Browser installiert ist, lassen sich mit der Richtlinie auch ein paar wichtige Einstellungen für Edge direkt anwenden. Auch hier ist es wieder möglich die Sicherheitseinstellungen lokal oder per GPO anzuwenden.

Für eine lokale Richtlinie muss wieder das Tool LGPO in den Unterordner „Scripts\Tools“ kopiert werden. Die lokale Richtlinie kann dann wieder mit „.\Baseline-LocalInstall.ps1“ (ohne Parameter) angewendet werden.

Windows Firewall konfigurieren

Auch die Windows Firewall enthält einige aktivierte Regeln die auf einem Standard Server nicht unbedingt benötigt werden. Eingehende sind 64 Regeln aktiv:

Ausgehend sind es sogar 75 Regeln, obwohl die Windows Firewall hier in der Standardeinstellung alle ausgehenden Verbindungen zulässt.

In der Standardeinstellung lässt die Windows Firewall nur Verbindungen zu, die durch eine Regel erlaubt werden. Ausgehende Verbindungen werden (vom lokalen Server zu anderen Zielen) werden in der Standardeinstellung zugelassen und nur geblockt, wenn es es eine entsprechende Regel gibt.

Die Firewall Regeln lassen sich mit dem folgenden PowerShell Script etwas ausdünnen:

$FirewallRules = @(
"AllJoyn Router (TCP-In)",
"AllJoyn Router (TCP-Out)",
"AllJoyn Router (UDP-In)",
"AllJoyn Router (UDP-Out)",
"Captive Portal Flow",
"Cast to Device functionality (qWave-TCP-In)",
"Cast to Device functionality (qWave-TCP-Out)",
"Cast to Device functionality (qWave-UDP-In)",
"Cast to Device functionality (qWave-UDP-Out)",
"Cast to Device SSDP Discovery (UDP-In)",
"Cast to Device streaming server (HTTP-Streaming-In)",
"Cast to Device streaming server (RTCP-Streaming-In)",
"Cast to Device streaming server (RTP-Streaming-Out)",
"Cast to Device streaming server (RTSP-Streaming-In)",
"Cast to Device UPnP Events (TCP-In)",
"Connected User Experiences and Telemetry",
"Desktop App Web Viewer",
"DIAL protocol server (HTTP-In)",
"Email and accounts",
"mDNS (UDP-In)",
"mDNS (UDP-Out)",
"Microsoft Media Foundation Network Source IN [TCP 554]",
"Microsoft Media Foundation Network Source IN [UDP 5004-5009]",
"Microsoft Media Foundation Network Source OUT [TCP ALL]",
"Narrator",
"Start",
"Windows Default Lock Screen",
"Windows Feature Experience Pack",
"Work or school account",
"Your account"
)
foreach ($FirewallRule in $FirewallRules) {
Get-NetFirewallRule -Displayname $FirewallRule | Set-NetFirewallRule -Enabled:false
}

Das Script deaktiviert die entsprechenden Regeln, löscht diese aber nicht. Zusätzlich macht es meiner Meinung nach Sinn, ausgehende RDP Verbindungen vom Server zu anderen Zielen zu verbieten, dies schützt ein wenig davor, dass der Server als „Jump Server“ zu anderen Servern genutzt wird. Es schützt aber nur ein wenig, da jeder mit Administrator Rechten auf dem Server, diese Firewall Regeln einfach wieder deaktivieren kann. Die Firewall Regeln gehören daher eher in eine Domain Gruppenrichtlinie. Wer trotzdem eine entsprechende Firewall Regel zum blockieren von ausgehenden RDP Verbindungen erstellen möchte, kann dafür den folgenden Befehl nutzen:

New-NetFirewallRule -DisplayName "Block Outgoing Remote Desktop Connection" -Direction Outbound -Program "%windir%\system32\mstsc.exe" -Action Block -Description "Block outgoing RDP Sessions by mstsc.exe"