Bundesamt für Sicherheit in der Informationstechnik

M 5.123 Absicherung der Netzkommunikation unter Windows

Verantwortlich für Initiierung: Administrator, IT-Sicherheitsbeauftragter

Verantwortlich für Umsetzung: Administrator

Die Sicherheit einer Windows Infrastruktur wird nicht ausschließlich von der sicheren Konfiguration und dem sicheren Betrieb einzelner Systeme bestimmt. Die Gesamtsicherheit hängt auch wesentlich von der Sicherheit in der Netzkommunikation ab, die unter anderem durch die Absicherung der Kommunikationswege (Signaturen, Verschlüsselung) und die verwendeten Authentisierungsmechanismen bestimmt wird.

Generell gilt, dass nicht verwendete Netzkomponenten (z. B. Datei- und Druckerfreigabe für Microsoft-Netzwerke) von existierenden Schnittstellen zu entfernen sind. Die Beurteilung, welche Netzprotokolle entfernt werden sollten, hat anhand konkreter Umstände und im Einzelfall zu erfolgen.

Sicherer Kanal

Die Kommunikation eines Clients mit einem Domain Controller erfolgt über den so genannten Sicheren Kanal, der unter anderem für die Übertragung der Authentisierungsdaten verwendet wird. Die Daten des Sicheren Kanals werden mit einem Sitzungsschlüssel verschlüsselt. Das jeweilige Computer-Konto des Clients (automatisch von Windows verwaltet) wird für den Aufbau dieses Kanals verwendet. Die regelmäßigen Änderungen des Kennworts für das Computer-Konto sind maßgebend für die Sicherheit des Sicheren Kanals (siehe M 5.89 Konfiguration des sicheren Kanals unter Windows ).

Signieren und Verschlüsseln der Kommunikation

Alle Daten, die über den Sicheren Kanal übertragen werden, sollten signiert und verschlüsselt werden. Standardmäßig erfolgt dies nur dann, wenn beide Kommunikationspartner die gleichen Verfahren verwenden. Unterstützt einer der beiden Partner die Verschlüsselung oder das Signieren nicht, erfolgt die Kommunikation ungeschützt (Richtlinien Domänenmitglied: Daten des sicheren Kanals digital signieren (wenn möglich) und Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln (wenn möglich) unter Computerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Lokale Richtlinien | Sicherheitsoptionen). Wird die Richtlinie Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) aktiviert, muss die Kommunikation signiert oder verschlüsselt werden. Unterstützen beide Partner nicht die gleichen Verfahren, wird keine Verbindung aufgebaut. Diese Option wird für den Einsatz empfohlen, wenn alle Domain Controller der Domäne und aller vertrauten Domänen mindestens Windows 2000 ausführen.

Das SMB -Protokoll (Server Message Block) unterstützt nicht nur eine gegenseitige Authentisierung, sondern erlaubt auch das Signieren der SMB -Pakete. Durch die Authentisierung und das Signieren werden Man-in-the-Middle-Angriffe verhindert.

Die SMB -Signaturen werden mit folgenden Richtlinien unter Computerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Lokale Richtlinien | Sicherheitsoptionen konfiguriert:

  • Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt),
  • Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer),
  • Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt),
  • Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer).

Standardmäßig werden Signaturen für SMB -Pakete unter Windows nicht erzwungen, aktiviert ist lediglich die Richtlinie Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt). Nur wenn auf dem SMB -Server das Signieren der Pakete aktiviert wurde, wird die Kommunikation signiert. Es besteht jedoch die Möglichkeit, die Signaturen zu erzwingen. Hierfür sind die restlichen oben aufgeführten Richtlinien zu aktivieren.

Das Aktivieren der Richtlinien zum Signieren der SMB -Kommunikation kann sich auf die Kompatibilität mit Clients, Diensten und Anwendungen auswirken. Vor der Aktivierung dieser Einstellungen sind daher Kompatibilitätstests erforderlich.

Nicht alle SMB -Server von Drittanbietern unterstützen die Kennwortverschlüsselung während der Authentisierung. Wird mit dem SMB -Protokoll auf einen solchen Server zugegriffen, kann das Kennwort unverschlüsselt übertragen werden, wenn die Richtlinie Microsoft-Netzwerk (Client): Unverschlüsseltes Kennwort an SMB -Server von Drittanbietern senden aktiviert ist. Allerdings sollte die Übertragung ungeschützter Kennwörter nicht zugelassen werden, das heißt die genannte Richtlinie darf nicht aktiviert werden.

Windows erlaubt das Festlegen der minimalen Sitzungssicherheit für die Kommunikation auf Anwendungsebene (z. B. zwischen RPC -Komponenten). Folgende Optionen können in den beiden Richtlinien Netzwerksicherheit: minimale Sitzungssicherheit für NTLM -SSP-basierte Clients (einschließlich sicherer RPC -Clients) und Netzwerksicherheit: minimale Sitzungssicherheit für NTLM -SSP-basierte Server (einschließlich sicherer RPC -Server) unter Computerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Lokale Richtlinien | Sicherheitsoptionen gewählt werden:

  • NTLMv2 -Sitzungssicherheit erfordern,
  • 128-Bit-Verschlüsselung erfordern.

Standardmäßig werden keine Minimaloptionen festgelegt. Werden auf allen IT -Systemen Client-Betriebssysteme ab Windows XP und Server-Betriebssysteme ab Windows Server 2003 mit aktivierter 128-Bit-Verschlüsselung ausgeführt, sind die Optionen für die NTLMv2 -Authentisierung und 128-Bit-Verschlüsselung zu aktivieren.

Starker Authentisierungsmechanismus

Die Güte des Authentisierungsverfahrens bei Netzanmeldungen spielt ebenfalls eine signifikante Rolle für die Gewährleistung der Sicherheit. Insgesamt können vier Authentisierungsmechanismen verwendet werden: LM, NTLMv1, NTLMv2 und Kerberos. Vor Windows 2000 wurde zunächst das LM-Verfahren und ab Windows NT das NTLM -Verfahren (in zwei Versionen) eingesetzt. Die alten Verfahren haben jedoch Schwächen, so dass aus einem übertragenen Authentisierungswert das Kennwort bestimmt werden kann. Den besten Schutz bieten die Version 2 des NTLM Protokolls sowie Kerberos. Kerberos ist als Standardprotokoll für die Authentisierung bei Benutzeranmeldung implementiert. NTLM ermöglicht die Kompatibilität mit älteren Systemen.

Bei Kerberos handelt es sich um ein kryptographisches Netzprotokoll zur verteilten Authentisierung. Kerberos realisiert eine Authentisierung innerhalb des Netzes, inklusive eines Schlüsselaustausches, ohne das den beteiligten Stellen ein gemeinsamer Schlüssel bekannt ist. Erreicht wird dies durch die Einführung einer weiteren Protokollinstanz.

In reinen Windows-Netzen (mit Client- und Server-Betriebssystemen ab Windows 2000) sollte möglichst Kerberos als das sicherste verfügbare Verfahren eingesetzt werden. Ist ein Einsatz von Kerberos nicht möglich, so wird automatisch die Authentisierung mittels NTLMv2 umgesetzt. Die älteren Protokolle sollten aufgrund ihrer Schwächen abgelehnt werden. Dazu ist in der zugehörigen Richtlinie Computerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Lokale Richtlinien | Sicherheitsoptionen | Netzwerksicherheit: LAN Manager-Authentifizierungsebene der Wert Nur NTLMv2 -Antworten senden\LM& NTLM verweigern einzustellen.

Die Speicherung der LAN Manager-Hashwerte bei Kennwortänderungen sollte deaktiviert werden. Dies wird durch das Aktivieren der Richtlinie Computerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Lokale Richtlinien | Sicherheitsoptionen | Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern erreicht.

Sind noch ältere Systeme im Einsatz (Windows 9x bzw. Windows NT 4.0 vor Service Pack 4), so kann es aus Kompatibilitätsgründen notwendig sein, auch andere Authentisierungsmechanismen zuzulassen, was aus Sicherheitssicht jedoch nicht empfohlen wird. Grundsätzlich wird empfohlen, die älteren Systeme mit Hilfe entsprechender Service Packs zu aktualisieren (Windows NT 4.0 Service Pack 4 oder höher) oder Zusatzsoftware zu verwenden ( NTLMv2 ist zusammen mit dem optionalen Client für Verzeichnisdienste auch unter Windows 95/98 verfügbar).

Anonymer Zugriff

Anonyme Zugänge über das Netzwerk sollten grundsätzlich nicht möglich sein (sogenannte NULL SESSIONS). Unter Windows XP ist es standardmäßig vorgesehen, bestimmte Aktivitäten wie das Aufzählen von SAM -Konten anonym durchzuführen. Diese Funktionalität ist durch das Aktivieren der Richtlinien Netzwerkzugriff: Anonyme SID -/Namensübersetzung nicht erlauben, Netzwerkzugriff: Anonyme Aufzählung von SAM -Konten nicht erlauben und Netzwerkzugriff: Anonyme Aufzählung von SAM -Konten und Freigaben nicht erlauben (unter Computerkonfiguration | Windows-Einstellungen | Sicherheitseinstellungen | Lokale Richtlinien | Sicherheitsoptionen) explizit abzuschalten. Die Richtlinie Netzwerkzugriff: Die Verwendung von "Jeder"-Berechtigungen für anonyme Benutzer ermöglichen ist zu deaktivieren. Unter IT -Systemen ab Windows Vista ist diese Richtlinie bereits in der Standardeinstellung deaktiviert.

Netzkommunikation mit DirectAccess absichern

Ab Windows 7 und Windows Server 2008 R2 ermöglicht die Funktion DirectAccess eine permanente logische Verbindung eines Clients mit dem Netz des Informationsverbundes, unabhängig von der Art der Netzanbindung. Bei dem Verfahren erfolgt die Netzkommunikation über eine Tunnelverbindung vom Client zu anderen Computern der Windows-Domäne. Der Tunnel kann sowohl von externen Netzen aus als auch innerhalb des Netzes des Informationsverbundes verwendet werden. Er bleibt solange bestehen, wie das Windows-System eine Netzverbindung hat.

Unter Verwendung von DirectAccess stellt der Client die Verbindung zum Netz des Informationsverbundes bereits vor der Benutzeranmeldung mittels Zertifikat her. Somit werden zum Beispiel GPO Updates und neue Richtlinien übernommen, bevor sich der Nutzer mit seinem Account angemeldet hat. Für die Datenübertragung nach der Benutzeranmeldung sind in der Grundkonfiguration keine Sicherheitsmaßnahmen vorgesehen. Lediglich die Computer-Authentisierung der Clients erfolgt verschlüsselt. Deshalb sollte die Übertragung mit zertifikatsbasiertem IPSec gesichert werden. Dafür ist eine PKI nötig, die im Netz des Informationsverbundes aufgebaut werden sollte. Für die Konfiguration von IPSec ist die Maßnahme M 5.90 Einsatz von IPSec unter Windows umzusetzen.

Standardmäßig ist keine einheitliche Sicherheitsprotokollierung für DirectAccess an Windows Clients voreingestellt. Überwachungsmöglichkeiten sind unter anderem hier zu finden:

  • gpedit.msc | ... | Erweiterte Überwachungsrichtlinienkonfiguration | Anmelden/Abmelden | IPSec ...
  • perfmon. exe | Leistungsüberwachung | Leistungsindikatoren (z. B. IP - HTTPS , Teredo, IPSec , WFP )

Diese Protokolle können sehr schnell wachsen und die Arbeitsfähigkeit des Rechners beeinträchtigen. Daher sollten die Überwachungseinstellungen gemeinsam mit den Serverkomponenten von DirectAccess sorgfältig auf die Anforderungen des Informationsverbunds abgestimmt werden. Eine Protokollierung auf Clientseite muss sichergestellt sein.

Prüffragen:

  • Sind alle nicht verwendeten Netzwerkkomponenten von existierenden Schnittstellen entfernt worden?

  • Wird das Kennwort für das Computer-Konto regelmäßig geändert?

  • Werden alle Daten, die über den Sicheren Kanal übertragen werden, signiert und verschlüsselt?

  • Werden anonyme Zugänge über das Netzwerk verhindert?

  • Wird Kerberos als Authentisierungsverfahren oder mindestens NTLMv2-Authentisierung genutzt sowie die 128-Bit-Verschlüsselung aktiviert, wenn auf allen Rechnern Client-Betriebssysteme ab Windows XP bzw. Server-Betriebssysteme ab Windows Server 2003 mit aktivierter 128-Bit-Verschlüsselung ausgeführt werden?

  • Wurde gewährleistet, dass auch ältere Clients das NTLMv2 Verfahren zur Authentisierung verwenden (z. B. durch das Einspielen entsprechender Service Packs oder zusätzlicher Software)?

  • Wurde anonymen Zugängen über das Netz die Berechtigung "Jeder" entzogen?

Stand: 15. EL Stand 2016

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK