Da Microsoft die Windows Server 2008 R2-Version im Kern immer noch auf Windows Server 2008 basiert, sind die technischen Anforderungen auf beide Versionen anwendbar. Unterschiede gibt es natürlich trotzdem, diese betreffen aber hauptsächlich Detailverbesserungen wie Stromsparfunktion, DirectAccess, BrancheCache und ein verbessertes Rollenkonzept.

Als Information zur Umsetzung der Vorgaben der Grundschutzkataloge sollte erwähnt werden, dass die Vorgaben des BSI für die Betriebssysteme Windows Server 2003 (B 3.108) und der Allgemeine Server (B 3.101)  nach bestem Wissen auf Windows Server 2008 angewendet wurden, da Windows Server 2008 leider noch nicht Teil der aktuellen Grundschutzkataloge ist.

Alle Informationen zu dem Produkt finden Sie auch auf unserer Homepage.

/ssu

Die im Titel genannte Maßname M 2.319 Migration eines Servers aus den IT-Grundschutz-Katalogen des BSI gibt einen guten Anreiz, was bei einer Migration eines Servers zu beachten ist:

• Welche Daten muss ich mitnehmen? Dabei wichtig: nicht nur Konfigurations- und Anwendungsdaten (wie in 90% aller Fälle) sollten übernommen werden. Sobald Kryptografie mit an Bord ist, sollte auch bedacht werden, dass die Schlüssel sicher transferiert werden.
• Wie schaffe ich Kompatibilität? Genaue Prüfung der Kompatibilität erspart so manche Mühen, denn treten Inkompatibilitäten auf, kann das gesamte Migrationsprojekt scheitern oder zumindest nicht im dafür vorgesehenen Rahmen erfolgreich sein.
• An welchen Rädern muss gedreht werden? Nicht nur IP-Adressen oder DNS-Namen wie in der Maßnahme genannt sind wichtige Aspekte, sondern auch weitere infrastrukturelle Aspekte wie z. B. Monitoring.
• Wo sind kritische Wege? Hilreich ist sich im Voraus auch eine oder einige Notfallstrategien zurecht zu legen.

Ungemein Hilfreich ist die Abarbeitung einer sorgfältig zusammengestellten Migrationscheckliste. So ist sichergestellt, dass alle geplanten, wichtigen Punkte abgearbeitet werden  (Und für Menschen, die es glücklich stimmt, wenn man etwas abhaken kann, ist dies zudem motivierend  – Randbemerkung: der Autor zählt sich nur bedingt zu dieser Gattung von Menschen ).

Weitere Hilfe

Sofern Sie ein schwieriges Migrationsprojekt vor sich haben und das gefühl haben, dass Sie Hilfe benötigen, so nehmen Sie einfach und unverbindlich Kontakt mit uns auf – wir unterstützen Sie gerne mit unserem starken Know-How und unserer zielstrebigen Vorgehensweise.

/SB

P.s.: Es handelte sich heute übrigens um einen Releasewechsel unserer Groupware und vorherigem Betriebssystemrelease- und Architekturwechsel von 32 Bit auf 64Bit. Ein vergleichsweise kleines Migrationsprojekt aus unserem Portfolio – aber auch das will geplant sein.

In Windows existieren Gruppenrichtlinieneinstellungen, welche sehr ähnlich klingen. Exemplarisch seien hier die Einstellungen “Domänenmitglied: Daten des sicheren Kanals digital signieren (wenn möglich)” und “Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)” genannt.

.

Die Grupperichtlinie “Domänenmitglied…” (M 5.89 Konfiguration des sicheren Kanals unter Windows) kann immer angewendet werden, da diese Einstellung lediglich bewirkt, dass die Kommunikation verschlüsselt wird sofern der Kommunikationspartner dazu in der Lage ist. Dabei wird bei der Anmeldung von einem Client am Domänencontroller versucht, die Kommunikation zu verschlüsseln, sofern der Kommunikationspartner, also der Domänencontroller, dazu fähig ist. Ist der Server dazu nicht in der Lage, wird die Kommunikation unverschlüsselt fortgesetzt.

Nach den Vorgaben des IT-Grundschutzes sind aus Kompatibilitätsgründen, sofern sämtliche Rechner im Informationsverbund auf Microsoft Windows basieren und höher als Windows 2000 sind, sämtliche oben aufgeführten Einstellungen zu setzen. Falls auch Linux-Betriebssysteme zum Einsatz kommen, sind zumindest die ersten zwei Einstellungen zu aktivieren.

Neben den Einstellungen für die Anmeldevorgänge gibt es weitere, welche die Kommunikation nach der Anmeldung, z. B. für die Ablage von Dateien im Netzwerk (über Datei- und Druckerfreigabe) bei Microsoft Windows zuständig sind. Diese lauten ziemlich ähnlich (“Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)”) und es ist sowohl bei den Einstellungen für die Authentifizierung an einem Domänencontroller, als auch die Einstellungen für das SMB-Protokoll möglich, die Einstellungen so zu setzen, dass die Kommunikation sowohl verschlüsselt als auch signiert durchgeführt wird. Als kleine Randinfo für Personen, die sich mit dem Thema näher befassen möchten, das Absichern des SMB-Protokolls wird in der Informationstechnik auch “SMB-Signing“ genannt.

Diese Funktion wird auch im Linux-Bereich durch den Samba Daemon ab Version 3 unterstützt und daher können diese Einstellungen im Regelfall immer, unabhängig vom Betriebssystem, umgesetzt werden.

Durch das Produkt „Sicheres Windows“ erhalten Sie eine konsolidierte Übersicht über diese und weitere technische Anforderungen, die in den Maßnahmen der IT-Grundschutzkataloge enthalten sind.

Diese Übersicht bietet den Vorteil, dass die Grundschutzkataloge nicht nach den relevanten Einstellungen durchsucht werden müssen. Falls Sie Interesse an der Dokumentation und an der Vorgehensweise für die Umsetzung der technischen Vorgaben haben, können Sie sich gerne über unsere Homepage bei uns melden.

/ssu

Diesen Monat dreht sich alles um die Einstellungen zum Thema BIOS. BIOS-Einstellungen können zwar je nach System auch zentral ausgerollt werden, meistens fehlt jedoch die entsprechende Software bzw. die dafür notwendige homogene Umgebung. Die gute Nachricht: In den Grundschutzkatalogen existieren lediglich zwei Anforderungen zur Absicherung des BIOS von Windows Clients (siehe Bild).

Es muss sowohl das BIOS-Passwort aktiviert, als auch die Boot-Reihenfolge definiert festgelegt werden. Die Reihenfolge ist so zu wählen, dass das Booten von anderen Medien verhindert wird. Für jeden Client-PC ist nach Grundschutz ein individuelles BIOS-Passwort zu vergeben. Da für Administratoren dadurch ein erheblicher Mehraufwand entsteht, stößt diese Maßnahme selten auf freudige Gesichter. Um das Setzen und Merken der BIOS-Passwörter zu beschleunigen, empfiehlt es sich,  zusammengesetzte Passwörter (z. B. aus Parameter wie Seriennummer und der ID des PCs) zu nutzen. So besitzt jeder Rechner ein individuelles Passwort. Damit wird das Einrichten bzw. Betreuen von Rechnern erheblich einfacher, als wenn man die Passwörter zunächst aus einer Passwortdatenbank holen muss. Bei dieser Methodik muss natürlich sichergestellt werden, dass die Regel zum Erstellen des Passworts nur einem kleinen Personenkreis bekannt ist und nicht nach außen kommuniziert wird. Natürlich ergibt sich dadurch die Problematik, dass beim Ausscheiden von Mitarbeitern, das Passwort nicht mehr sicher ist. Für hochsichere Informationsverbünde müssten hier sukzessive die BIOS-Passwörter mittels einer neuen Methodik geändert werden.

Alternativ können auch Passwortspeicher-Tools verwendet werden, jedoch besteht auch hier die Möglichkeit, dass ein potentieller Angreifer, der die Datenbank kopiert und anschließend ausscheidet, auch Zugriff auf sämtliche BIOS-Informationen eines Rechners erhält.

Letztendlich kann jeder Angreifer auch einfach die BIOS-Batterie ausbauen um an das gewünschte BIOS heranzukommen. Trotz allem erschwert diese Einstellung einem Angreifer das Kompromittieren von Systemen und das muss ja schließlich das Ziel eines Informationsverbundes sein

/ssu

Dabei wird dem Administrator die Möglichkeit geboten, die einzelnen Einstellungen mittels Gruppenrichtlinien zu verteilen. Diese befinden sich innerhalb der Computerkonfiguration unter dem Reiter Windows-Einstellungen. Wenn man hier den Reiter Windows Firewall mit erweiterter Sicherheit öffnet und anschließend die Eigenschaften per Rechtsklick öffnet, hat der Anwender die Möglichkeit, verschiedene Einstellungen für ein Domänenprofil, ein privates Profil sowie ein öffentliches Profil zu setzen.

Dies hat den Vorteil, sofern man das Domänennetz entsprechend abgesichert hat, dass die Firewall innerhalb der Domäne deaktiviert werden könnte, um Komplikationen bei der Kommunikation aus dem Weg zu gehen.

Windows-Firewall-Einstellungen innerhalb des Active-Directory

Die Vorgabe der Microsoft Sicherheitsrichtlinien lautet aber grundsätzlich, die Windows-Firewall in jeder Umgebung aktiviert zu haben.

Neben dem reinen Aktivieren/Deaktivieren bieten die Gruppenrichtlinien auch noch die Möglichkeit, verschiedene Einstellungen, wie Protokollierung, zu setzen.

Wenn Sie weitere Informationen über die Absicherung von Windows wünschen, können Sie sich gerne über unsere Homepage darüber informieren.  Bei Fragen können Sie sich auch gerne über unser Kontaktformular bei uns melden.

/ssu

Diese Funktion des AD wird mangels Know-How, leider eher selten genutzt.

Viele Personen wissen nicht, dass es über das Active-Directory möglich ist, die Berechtigungen auf Ordner/Dateien bzw. auf Registrywerte zu setzen. Sofern die Benutzer angewiesen sind sensible Dateien auf dem Fileserver zu speichern, kann man folgende Berechtigung im AD setzen (Quelle: M 4.149 Datei- und Freigabeberechtigungen unter Windows).

(Zum Vergrößern, bitte Bild anklicken)

Dadurch ist es dem normalen Anwender nicht mehr möglich, auf die Festplatte des Windows-Systems zu schreiben, also kann er keine Programme mehr dort installieren oder Daten darauf ablegen. Er hat nur noch lesenden Zugriff und kann Dateien ausführen.

Diese Gruppenrichtlinie ermöglicht es Administratoren ohne großen Aufwand (Erstellen und Einbinden von Skripten) diese Restriktionen zu setzen.

Außerdem ist es noch möglich die Einstellungen auf Unterordner und Dateien zu vererben, damit man die Einstellungen nur einmal  setzen muss.

Wenn Sie weitere Details zum Thema “Sicheres Windows” erfahren möchten, können Sie sich auf unserer Homepage darüber informieren.

/ssu

Da heutzutage in vielen Firmen Windows Bordmittel (um die Kosten für teure Software von Drittanbietern zu sparen) eingesetzt werden, ist es unerlässlich zum Schutz der IT-Umgebung, diese abzusichern.

Im Folgenden ist ein Screenshot angefügt um einen Auschnitt der Umsetzungen zur Absicherung von Remotedesktop unter Windows zu zeigen.

(Zum Vergrößern bitte Bild anklicken)

Die erste Einstellung konfiguriert die Verschlüsselungsstufe für die Client-Verbindung fest.  Sofern beide Partner der Verbindung aktueller sind als Windows 2000 SP4 ist die Einstellung Höchste Stufe auszuwählen, sodass mittels dem Sniffer-Tool “Wireshark” keine Kommunikationsdaten ausgespäht werden können.

Die zweite Einstellung legt fest, dass es nicht möglich ist mittels gespeicherten RDP-Verbindungen sich automatisch auf das entferne System aufzuschalten. Dies ist nun erst nach Eingabe eines gültigen Passworts möglich. Durch das Setzen dieser Einstellung wird es Angreifern erschwert, nachdem Sie ein System kompromittiert haben, sich direkt auf einem weiteren System einzuloggen.

Falls noch weitere Fragen bzw. mehr Informationen über diese Admin-Klick-Tabelle für Windows gewünscht werden, können Sie sich gerne auf unserer Homepage informieren.

/ssu

Da die Anwender immer wieder berichteten, dass die technischen Anforderungen so nicht umzusetzen sind, haben wir uns überlegt, dies zu evaluieren. Sämtliche Informationen wurden dabei durch mich in verschiedene Excel-Listen für Windows Server (2003, 2008) und Clients (XP, Win7), mit jeweils über 200 technischen Anforderungen, gegossen. Dabei habe ich die teilweise fehlenden Pfade, sowie die entsprechenden Einstellungen angepasst und dokumentiert.

Dabei sollte erwähnt werden, dass die Vorgaben des BSI für die Betriebssysteme Windows XP (B 3.209) und Windows Vista (B 3.210) sowie der Allgemeine Client (B 3.201)  nach bestem Wissen auf Windows 7 angewendet wurden, da Windows 7 noch nicht Teil der aktuellen Grundschutzkataloge ist.

Zusätzlich zu den Anforderungen des BSI sind in die Excel-Tabelle noch Best Practices aus der Praxis verschiedener Kundenprojekte bzw. der Security Guides von Microsoft eingeflossen .

Hier ist ein exemplarischer Auszug dieser Liste:

Erläuterung:

Die Anr ist eine laufende Nummer um referenzieren zu können. In der folgenden Spalte ist die Ausführung beschrieben bzw. welche Einstellung umzusetzen ist und ob der Wert nach einer Standardinstallation des Systems gesetzt ist oder nicht. In der 3. Spalte wird der Status der Einstellung (Aktiviert/Deaktiviert) bzw. die dazugehörige Einstellung beschrieben. Anschließend folgt noch die Beschreibung,  wo die Einstellung zu finden ist (Pfad).

Die letzten beiden Spalten sind für die Herkunft der Anforderung. Dies dient der Nachvollziehbarkeit, da Anwender auf Kundenseite oft wissen möchten, auf welche Anforderung eine Aktion zurückzuführen ist und woher diese Anforderung stammt.

Ein Beispiel einer sehr schönen Maßnahme, die selten auf Begeisterung stößt, ist die Umsetzung der Gruppenrichtlinie “Letzten Benutzernamen nicht anzeigen”. Dadurch muss bei jedem Systemstart der Benutzername explizit eingegeben werden. Die Gegner der Maßnahme kommen dann meistens mit dem Argument, dass wenn der Benutzername angezeigt wird, der Anwender die Möglichkeit hat zu sehen, ob sich eine Dritte Person am Rechner angemeldet hat? Das ist zugegebenermaßen ein Argument gegen die Umsetzung, jedoch ist das System trotzdem sicherer, da ein lokaler Angreifer erst einmal einen Benutzernamen wissen muss um ein ggfs. zugehöriges Passwort einzugeben. Außerdem kann man noch dem mutwilligen Sperren eines Benutzerkontos, durch falsche Eingaben des Passworts, entgegenwirken.

Alle Informationen zu dem Produkt finden Sie auch auf unserer Homepage.

/ssu

Die aktuelle Windows-Schwachstelle, bei der sich über .LNK-Dateien Schadcode aus DLL-Dateien beim Laden der Icons nachladen lässt, kann u. A. mit Hilfe einer Softwareeinschränkungsrichtlinie eingedämmt werden. Eine Anleitung dazu gibt es hier.

Was man mit Softwareeinschränkungsrichtlinien noch so alles treiben kann beschreibt der Autor ebenfalls in mehreren Artikeln. Will man ein paar Basics, dann kann man aber auch hier nachsehen

/sb

Das Archiv befindet sich auf unserem Webserver und enthält alle Maßnahmen als PDF Dokumente, sortiert nach den üblichen Schichten des IT-Grundschutz. Alle Änderungen zur vorherigen Version 2008 sind mit Änderungsmarkierungen hervorgehoben.

Wir danken dem BSI für die Erlaubnis die Daten bereitstellen zu dürfen und wünschen allen Anwendern viel Spaß beim Lesen nach Änderungen.

Update 09.03.: Wir haben eine neue Version des GSK-Vergleichs bereitgestellt, dieser beinhaltet jetzt auch den Vergleich der Baustein-Übersichten.

Update 14.04.: Noch einmal wurde der  GSK-Vergleich verbessert.

Update 12.05.: Leider stolpert der Batchjob bei der Verarbeitung ab und zu. Dadurch können leere Änderungsmarkierungen vorkommen (vielen Dank für das Feedback). Wir haben versucht diesen Fehler weitestgehend zu behebn. Vereinzelt kann es aber noch vorkommen.

/sf