GPO Hardening: Die wichtigsten GPO-Einstellungen

Die Härtung von Systemen ist ein wichtiges Thema in der IT-Sicherheit. Viele Unternehmen, die sich neu mit diesem Thema befassen, sehen sich mit Sicherheitsvorfällen konfrontiert. Das Incident Response Team von Oneconsult steht bereit, um Unternehmen bei der Bewältigung solcher Vorfälle, auch Incidents genannt, zu unterstützen.

Hardening mit GPOs

In zahlreichen Incidents und Kundenprojekten konnten wir verschiedene Herausforderungen beim Systemhärten identifizieren. Eine wesentliche Problematik besteht in der Ressourcenknappheit, die es erschwert, die Vielzahl von Leitfäden, Tipps und Standards zu überprüfen und anzupassen. Zudem ist die Infrastruktur häufig bereits gewachsen, ohne dass das Härten eine Rolle spielte. Dies führt dazu, dass Härtungsmassnahmen nur langsam und ineffektiv umgesetzt werden können, da dies fast immer zu Beeinträchtigungen der Dienste führt.

Im vorliegenden Artikel werden die wichtigsten Group Policy Object (GPO)-Einstellungen aus der Perspektive der IT-Sicherheit zusammengetragen. Dabei handelt es sich um eine Zusammenfassung der aus Praxiserfahrung wichtigsten Härtungsmassnahmen, die jeder per GPO verteilen kann, beziehungsweise sollte. Zudem wird auf mögliche Auswirkungen eingegangen, die die entsprechenden Richtlinien verursachen könnten. Grundsätzlich gilt, dass nichts umgesetzt werden sollte, ohne es zuvor getestet zu haben. Testumgebungen sind dafür besonders geeignet. Auch eine Untergruppe von Geräten und Servern, die nicht allzu kritisch sind, kann dafür herangezogen werden. Der Vorteil bei Group Policy Objects ist, dass sie bei unerwünschtem Verhalten schnell wieder entfernt werden können. Der Nachteil liegt allerdings darin, dass zunächst herausgefunden werden muss, welche der vielen Einstellungen das Fehlverhalten verursacht hat.

UAC

Die UAC (User Account Control) schützt insbesondere die privilegierten Benutzerkonten. In einigen Fällen wurde bei einem Cyber Incident festgestellt, dass die UAC für Administratoren komplett deaktiviert wurde. Eine Schadsoftware, die durch einen Admin gestartet wurde, konnte sich danach uneingeschränkt auf dem System und meistens auch darüber hinaus ausbreiten. Die UAC verhindert das standardmässige Starten von Programmen mit erhöhten Berechtigungen, indem eine Bestätigung oder eine erneute Eingabe des Passworts angefordert wird. Ausserdem kann die UAC «Lateral Movement» (die Ausbreitung im Netzwerk) unter Umständen verhindern, da sie über das Netzwerk keine Verbindungen von lokalen Administratoren zulässt. Die Bedingung hierfür ist allerdings die korrekte Konfiguration der UAC.

Die folgenden empfohlenen Einstellungen zur Benutzerkontensteuerung werden in «Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: [verschiedene Einstellungen]» vorgenommen:

Einstellung	Wert
User Account Control: Admin Approval Mode for the Built-in Administrator account	Enabled
User Account Control: Only elevate UIAccess applications that are installed in secure locations	Enabled
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode	Prompt for consent on the secure desktop
User Account Control: Behavior of the elevation prompt for standard users	Automatically deny elevation requests
User Account Control: Detect application installations and prompt for elevation	Depending on use case *
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop	Disabled
User Account Control: Run all administrators in Admin Approval Mode	Enabled
User Account Control: Switch to the secure desktop when prompting for elevation	Enabled
User Account Control: Virtualize file and registry write failures to per-user locations	Enabled

* Siehe: Microsoft, User Account Control: Detect application installations and prompt for elevation

LDAP-Signierung

Bei aktiviertem LDAP Signing werden alle LDAP-Pakete signiert versendet. Dies gewährleistet, dass der Empfänger der LDAP-Pakete sicherstellen kann, dass die Kommunikation mit der richtigen Stelle erfolgt. Ein Client kann somit überprüfen, ob die LDAP-Antworten vom Domänencontroller stammen und nicht verändert wurden und umgekehrt. Dies erschwert insbesondere Replay-Angriffe, bei denen ein Cyber-Angreifer versucht, alte, aufgezeichnete Kommunikation wiederzuverwenden. Ebenso werden Man-in-the-Middle-Angriffe verhindert, bei denen sich ein Angreifer zwischen Client und Server in die Kommunikation einklinkt.

Des Weiteren ist die Verwendung von «LDAP Channel Binding Token» zu empfehlen, da diese die Sicherheit bei der Authentifizierung am Active Directory per LDAPs erhöhen.

Mögliche Auswirkungen sind insbesondere bei älteren Systemen zu erwarten, die mit LDAP Signing nicht umgehen können. An solchen Systemen können sich Domänenbenutzer nicht mehr anmelden und Dienste können nicht mehr richtig funktionieren oder starten, wenn sie unter einem Domänenkonto gestartet wurden. Um herauszufinden, ob derartige Systeme im Netzwerk vorhanden, kann ein Log konfiguriert werden, welches simple LDAP-Anfragen erkennt und rapportiert. Dazu muss in der Registry auf dem Domänencontroller unter dem Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics folgender Wert eingestellt werden:

• «16 LDAP Interface Events», Wert: 2

Somit wird die Event ID 2889 im Event Viewer angezeigt, wenn ein Client LDAP Signing nicht unterstützt.

Beim Channel Token unterstützen OS-Versionen wie Windows Server 2008 oder ältere Versionen LDAP Signing nicht. Für die 2008er-Linie gibt es Updates, welche die Funktion nachrüsten.

Die empfohlene Einstellung für Server und Client:

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements
  • Setzen auf: Require signing

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LDAP client signing requirements
  • Setzen auf: Require signing

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server channel binding token requirements
  • Setzen auf: Always

SMB-Signierung

SMB Signing hat im Prinzip dasselbe Ziel wie LDAP Signing. Es soll verhindert werden, dass ein Angreifer sich in die Kommunikation zwischen Client und Server schalten oder die aufgezeichnete Kommunikation später für einen Angriff wiederverwenden kann. Auch hier wird es zu Problemen kommen, wenn alte Systeme SMB Signing nicht unterstützen. Ein weiteres Problem könnte die Performance betreffen. Bei normalem 1GB-Ethernet und moderner CPU werden Benutzer kaum etwas merken. Wird hingegen eine 10GB-Leitung mit entsprechend hohem Durchsatz eingesetzt, können Performance-Einbussen durch SMB Signing spürbar sein.

Die empfohlenen Einstellungen für Server und Clients:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network client: Digitally sign communications (always)
  • Setzen auf: Enabled

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always)
  • Setzen auf: Enabled

Alternativ könnte folgende Einstellung bevorzugt werden, wenn mindestens teilweise unsignierte Kommunikation benötigt wird:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network client: Digitally sign communications (if server agrees)
  • Setzen auf: Enabled

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (if client agrees)
  • Setzen auf: Enabled

SChannel-Signierung

Die SChannel (Secure Channel) werden verwendet, wenn Domänencontroller untereinander replizieren sowie bei der Kommunikation mit Clients, wenn sicherheitsrelevante Vorgänge, wie etwa Authentisierung, durchgeführt werden.

Um Cyber-Angriffe zu verhindern, kann die Kommunikation verschlüsselt und/oder signiert übertragen werden. Wie bei SMB Signing gibt es auch hier die Option, Verschlüsselung und/oder Signierung nur dann zu verwenden, wenn dies möglich ist. Alte Betriebssysteme oder Non-Microsoft Clients können unter Umständen beim Forcieren der Einstellung nicht mit dem Domänencontroller oder dem gewünschten Dienst kommunizieren.

Folgende Einstellung wird empfohlen:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain member: Digitally encrypt or sign secure channel data (always)
  • Setzen auf: Enabled

Alternative Einstellung:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain member: Digitally encrypt or sign secure channel data (if client agrees)
  • Setzen auf: Enabled

NTLMv2 ohne alte Protokolle

In einer Domäne wird zur Authentisierung standardmässig Kerberos genutzt. In einigen Fällen ist dies nicht möglich oder es wird aufgrund einer falschen Konfiguration nicht verwendet. In solchen Fällen wird LM (LAN Manager), NTLM (New Technology LAN Manager) oder NTLMv2 (New Technology LAN Manager Version 2) gebraucht. NTLMv2 wird seit Windows 2000 nativ unterstützt. Die älteren Protokolle, insbesondere LM, haben Schwachstellen in ihrer Konstruktion, weshalb von deren Verwendung abzuraten ist. Da NTLMv2 weit verbreitet ist und seit längerer Zeit unterstützt wird, sollte die Umsetzung keine nennenswerten Schwierigkeiten bereiten.

Folgende Einstellung wird empfohlen:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level
  • Setzen auf: Send NTLMv2 responses only. Refuse LM & NTLM

CPasswords entfernen

In den GPPs (Group Policy Preferences) können Passwörter hinterlegt werden. GPPs stellen den Teil der GPOs dar, in denen Laufwerkszuordnungen, das Kopieren von Dateien, das Setzen von Umgebungsvariablen usw. aber auch Benutzer inklusive Passwörter angelegt werden können. In der Group Policy gespeicherte Passwörter sind für einen Angreifer auslesbar. Die Geheimnisse stehen zwar nicht im Klartext zur Verfügung, jedoch ist der von Microsoft einprogrammierte Schlüssel, der zum Schutz der Daten dient, allgemein bekannt. In den meisten Fällen existieren alternative Lösungen, die das gleiche Ziel erreichen, ohne dass ein Passwort in den GPPs gespeichert werden muss.

Ein weit verbreitetes Problem ist die Verwaltung der lokalen Administratoren auf den Servern und Clients. Oft wird per Voreinstellung überall dasselbe Passwort verwendet oder es wird ein Benutzer per GPP angelegt, was zum selben Resultat führt. Besser wäre die Verwaltung der lokalen Administratoren per LAPS (Local Admin Passwort Solution). LAPS ist ein Tool von Microsoft, das genau für diesen Zweck entwickelt wurde. Über das Tool kann per GPO gesteuert werden, welches lokale Admin-Konto gemäss den ebenfalls definierbaren Regeln verwaltet werden soll. Dabei wird der Client für den entsprechenden Account ein Passwort generieren und dieses auf dem Domänencontroller in ein neues Feld des jeweiligen Computerobjekts schreiben. Dieses Feld können nur Domänenadministratoren lesen. Auf diese Weise erhält jedes lokale Administratorenkonto ein eigenes, sicheres Passwort. Ein Domänenadministrator kann das Passwort aus dem Active Directory auslesen, am einfachsten per PowerShell.

Die Verwendung von LAPS erfordert die Installation der Management Tools auf dem AD-Server, eine Schemaerweiterung für die neuen Felder sowie neue GPO-Vorlagen. Auf den Clients wird eine GPO Extension installiert. Bei der nächsten Synchronisation der Richtlinien wird der Client die Einstellungen zu LAPS lesen und umsetzen.

Die genaue Installationsanleitung und Dokumentation sind bei Microsoft zu finden: Microsoft LAPS

Oneconsult empfiehlt, keine Passwörter in den GPPs und GPOs zu speichern, sondern eine andere Lösung zu finden.

Passwortrichtlinie

Zum Thema Passwortrichtlinie gibt es zahlreiche Ressourcen im Internet. Diese beziehen sich jedoch nicht immer auf dieselbe Ausgangslage. So wird zum Beispiel empfohlen, keine Komplexitätsanforderungen an Benutzerpasswörter zu stellen, aber sie dafür gegen eine möglichst umfassende Blacklist zu prüfen. Auf einem On-Premises-Domänencontroller können die Passwörter nicht gegen eine Blacklist geprüft werden. In einer Cloud hingegen können solche neuen Ansätze verfolgt werden. Manchmal sind die Empfehlungen für einen Webshop oder andere Websites gedacht und entsprechen nicht den Anforderungen und Gegebenheiten einer Active-Directory-Umgebung. Weiter gilt Vorsicht, wenn aus einer Empfehlung nur einzelne Punkte herausgesucht und umgesetzt werden. Dieses Vorgehen kann die Passwortrichtlinie schwächen.

Eine gute Orientierung bietet der CIS (Center for Internet Security) Password Policy Guide. Er beschreibt verschiedene Sachverhalte verständlich und klärt über verschiedene Angriffsszenarien auf. Entgegen der Passwortrichtlinie von CIS empfiehlt Oneconsult für normale Benutzer (mit 2FA) eine Passwortlänge von mindestens 10 Zeichen anstatt 8. Für weitere Empfehlungen lesen Sie «Passwortsicherheit (nicht nur) im Active Directory –  Schwierige Wahl».

Remote Credential Guard

In modernen Umgebungen mit Windows 10 und Server 2016 oder höher kann für RDP-Verbindungen Remote Credential Guard aktiviert werden. Bei Verbindungen zum RDP Host werden die Credentials oder Teile davon nicht mehr an den Host gesendet, der sie lokal im Cache ablegen würde. Ein Angreifer, der einen Host kompromittieren konnte, kann so nicht weitere Benutzerkonten abgreifen, nur weil sie sich auf das System verbinden. Vor allem dort, wo Support per RDP geleistet oder RDP auch für Verbindungen zu DMZ-Servern benutzt wird, ist Remote Credential Guard sinnvoll.

Microsoft hat dokumentiert, wie Remote Credential Guard eingerichtet werden kann und welche Voraussetzungen erfüllt werden müssen: Remote Credential Guard.

Werden die Anforderungen von Microsoft erfüllt und wird der Einsatz von Credential Guard vor dem Ausrollen getestet, sollten keine Probleme auftauchen. Wichtig bei der Umsetzung ist das genaue Studieren der Dokumentation von Microsoft, um alle Bedingungen zu erfassen.

NLA einschalten

Wird NLA (Network Level Authentication) eingesetzt, findet die Authentisierung bei RDP bereits beim Verbindungsaufbau statt, anstatt erst danach. Eine Verbindung kommt nur dann zustande, wenn sich der Benutzer entsprechend erfolgreich anmelden kann. Auf diese Weise können Angreifer und Viren Sicherheitslücken weniger gut ausnutzen und nicht unberechtigt Informationen abgreifen, die auch vor einem Login verfügbar sind (etwa angemeldete Benutzer). So konnte zum Beispiel der Befall durch den Computerwurm Bluekeep per NLA verhindert werden. Bei einer Umsetzung sollten in den seltensten Fällen Probleme auftauchen. Unterstützt wird NLA seit Windows XP SP3 und Server 2008. Es ist zu beachten, dass Benutzer, die ihr Passwort ändern müssen, sich nicht wie gewohnt per RDP anmelden und dann ihr Passwort ändern können. Die Verbindung würde beim Einsatz von NLA fehlschlagen. Des Weiteren ist eine Authentisierung mittels Smartcard bei domänenübergreifenden Verbindungen nicht möglich.

Folgende Einstellung wird empfohlen:

• Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require user authentication for remote connections by using Network Level Authentication
  • Setzen auf: Enabled

Log-Grösse des «Security Log»

Die Standardeinstellung für die Grösse des Security Logs ist insbesondere auf Domänencontrollern oft unzureichend. Bei der Analyse von Vorfällen wurde wiederholt festgestellt, dass die zur Aufklärung des Vorfalls verfügbaren Log-Daten nur zwei bis vier Stunden in die Vergangenheit reichen. Auch bei kleineren Unternehmen fallen auf dem Domänencontroller zahlreiche Log-Daten an, die bei Erreichen der eingestellten Log-Grösse wieder überschrieben werden. Die Grösse des Security Log ist je nach Unternehmen, Anforderungen und Audit Policy individuell festzulegen. Ein Anfang wäre, die Log-Daten vom Security Log auf allen Servern und Clients für drei Monate verfügbar zu machen.

Daher wird folgendes Vorgehen empfohlen:

1. Security Log öffnen, momentane Grösse notieren.
2. Den ältesten verfügbaren Log-Eintrag suchen.
3. Per Dreisatz ausrechnen, wie gross das Log sein müsste, um mindestens drei Monate in die Vergangenheit zu reichen
4. Geschätzte Log-Grösse per GPO einstellen: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Security: Specify the maximum log file size (KB)
5. Nach drei Monaten kontrollieren, ob das Datum des ältesten Log-Eintrags der Erwartung entspricht.

PowerShell Script Block Logging einschalten

PowerShell ist ein mächtiges Werkzeug, das sowohl von Administratoren als auch von Cyber-Angreifern verwendet wird. Um nachvollziehen zu können, wer wann welchen Befehl oder welches Script ausgeführt hat, sollten alle ausgeführten Befehle geloggt werden. Dadurch können Probleme oder Angriffe, bei denen PowerShell eine Rolle spielt, entdeckt und nachvollzogen werden.

PowerShell Script Block Logging kann per GPO eingestellt werden:

• Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging
  • Auf Enabled setzen und «Log script block invocation start/stop events» auswählen.

Audit-Policy erstellen

Bei vielen Incidents wird festgestellt, dass neben der kurzen Speicherzeit der Log-Daten die vorhandenen Daten eher spärlich ausfallen. Um einen Cyber-Vorfall aufzuklären, müssen zum Teil die verschiedensten Logs herangezogen und korreliert werden. Ein grosser Teil wird unter Windows standardmässig nicht aufgezeichnet und muss erst konfiguriert werden. Es empfiehlt sich, innerhalb eines Unternehmens zunächst zu überlegen, welche Informationen benötigt werden. Im Folgenden werden einige Fragen zur Anregung formuliert:

• Will man sehen können, wer sich wann wo eingeloggt hat?
• Wer hat wann auf die wichtigen Firmengeheimnisse auf der SMB-Freigabe zugegriffen?
• Wer hat welche Änderungen im Active Directory vorgenommen?
• Welche PowerShell-Befehle wurden ausgeführt?
• Welche Prozesse wurden gestartet? Wann und von wem?

Auf der darauf basierenden Audit Policy kann später eine einfache Auswertung, ein SIEM (Security Information and Event Management) oder gar ein SOC (Security Operation Center) aufgebaut werden. Bei den Einstellungen gibt es grundsätzlich kein richtig oder falsch. Es ist ein Abwägen zwischen dem, was man wissen möchte, und der Log-Grösse beziehungsweise Anzahl der Log-Einträge, die beachtliche Ausmasse erreichen können. Schlecht ist nur, sich darüber nie Gedanken zu machen. Am Anfang muss es nicht gleich ein SOC sein. Bei Incidents sind die Forensiker und Incident Responder bereits zufrieden, wenn überhaupt Log-Daten vorhanden sind.

Die verschiedenen Einstellungsmöglichkeiten sind unter folgendem Pfad zu finden:

• Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies

• Einen guten Einstieg bietet dieses Dokument: WINDOWS LOGGING CHEAT SHEET – Win 7 thru Win 2019

Benutzern das Hinzufügen neuer Geräte zum Active Directory verbieten

Es ist bekannt, dass standardmässig jeder Benutzer bis zu fünf Geräte mit seinem normalen Domänenbenutzer der Domäne hinzufügen kann. Die Möglichkeit, neue Geräte in die Domäne aufzunehmen, ist kein Privileg von Domänenadministratoren, ausser es wird so konfiguriert. Die durch Benutzer neu hinzugefügten Geräte entsprechen in den seltensten Fällen der Sicherheitsstrategie des Unternehmens. So werden sie zum Beispiel nicht über die zentrale Verwaltung des Antivirenprogramms erfasst, haben womöglich keine aktive BitLocker-Verschlüsselung oder sind bereits mit Viren verseucht.

Das Hinzufügen von neuen Geräten zur Domäne kann nur für Administratoren erlaubt werden:

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Add workstations to domain
  • Setzen auf: Administrators

Weiterführende Quellen und Massnahmen

Bezüglich der Härtung per GPO finden sich im Internet zahlreiche Quellen. Im Folgenden werden drei Ressourcen aufgeführt, die in der Oneconsult häufig verwendet werden:

• CIS Benchmarks
• Microsoft Security Baselines
• Ein weiterer Blogbeitrag des Autors, in dem erklärt wird, wie die Windows Firewall effektiv per GPO verwaltet und aktiviert wird: Schützende Windows-Firewall konfigurieren

Zum Thema Active Directory, dem Herzstück fast jeder Firma, sind die folgenden Ressourcen zu empfehlen:

• Die Sicherheit des eigenen Active Directory (AD) verbessern, ist ein Oneconsult-Blog über eine Möglichkeit des Selbstaudits, der kostengünstig und schnell die relevanten Ergebnisse liefert und anleitet, wie die Sicherheit des Active Directory ausgebaut werden kann.
• Das Absicherung Active Directory Training, welches die Grundlagen der Absicherung vermittelt, erläutert die Vorgehensweisen von Angreifern und zeigt auf, wie Angriffe verhindert und erkannt werden können.

Weitere Einstellungen

Zusätzlich zu den in den vorherigen Kapiteln genannten Einstellungen sind die nachfolgenden Massnahmen zu nennen, die sich nicht direkt oder nicht nur per GPO einstellen lassen und dennoch zur Basis beim Härten gehören.

LLMNR und NetBIOS deaktivieren

LLMNR (Link-Local Multicast Name Resolution) und NetBIOS sind Protokolle zur Namensauflösung in Ad-hoc-Netzwerken, bei denen kein DNS-Server zum Einsatz kommt. Anfragen per LLMNR oder NetBIOS werden an das ganze Netzwerk versendet. Antworten werden nicht auf Authentizität überprüft. Angreifer können diesen Mechanismus ausnutzen, indem sie solche Abfragen abhören und Antworten fälschen – und so das Opfer dazu bringen, bösartigen Servern zu vertrauen.

Falls LLMNR und NetBIOS nicht zum Einsatz kommen, sollten die Protokolle deaktiviert werden:

• Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client > Turn Off Multicast Name Resolution
  • Setzen auf: Enabled

NetBIOS kann nicht auf einfachem Weg per GPO deaktiviert werden. Es muss pro Adapter abgeschaltet werden. Wirklich nützlich ist das vor allem bei Servern, bei denen der Adapter nicht wechselt. In der Registry wird folgende Einstellung vorgenommen:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\ <ID>\NetbiosOptions
  • Setzen auf: 2

WPAD deaktivieren

WPAD (Web Proxy Autodiscovery) ist ein Protokoll zur automatischen Proxykonfiguration. Es kann, je nach Netzwerk, Man-in-the-Middle-Angriffe begünstigen. Auf Servern, die in der Regel in statischen Netzwerken installiert werden, kann der Proxy fix konfiguriert und WPAD abgeschaltet werden. Auf Clients, die die Funktion nicht benötigen, sollte WPAD ebenfalls deaktiviert werden.

WPAD sollte auf Servern und den Clients, die WPAD nicht benötigen, deaktiviert werden:

• In der Systemsteuerung muss bei der Einstellung des Proxys «Automatically detect settings» auf «Off» gestellt werden.
• Zudem muss der folgende Registry Key gesetzt werden:
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc
  • Wert von «Start» von 3 (manuell) auf 4 (deaktiviert)

Fazit

Am besten funktioniert das Härten von Systemen, wenn der IT-Sicherheitsgedanke bereits von Anfang an in den Prozessen wiederzufinden ist und nicht erst am Schluss oder nach Cyber Incidents nachgeholt wird. Werden neue Clients, Dienste und Server ausgerollt und aufgebaut, sollte IT-Sicherheit bereits bei der Konzeptionsphase eine Rolle spielen. Wenn die Vorgaben an die Sicherheit von Anfang an gegeben sind, ist die Umsetzung in der Regel weniger problematisch. Die genannten GPOs können dabei eine gute Grundlage bilden, um ein Basisniveau an Hardening zu erreichen. Natürlich ist das Härten von Systemen nicht nur auf GPOs zu beschränken. Auch bei den Richtlinien gibt es unzählige Einstellungen, die die Sicherheit eines Netzwerks erhöhen können und hier nicht behandelt wurden. Die weiterführenden Links bieten viele nützliche Informationen und Tools, die beim Absichern der Clients, Server und der ganzen Umgebung unterstützen können.