Anleitung zur Verringerung von Sicherheitsbedrohungen unter Windows NT 4.0 und Windows 98

Kapitel 4: Absichern von Microsoft Windows NT 4.0

Veröffentlicht: 13. Sep 2004

Microsoft® Windows NT® 4.0 enthält nicht alle erweiterten Sicherheitsfunktionen, die spätere Versionen des Microsoft Windows®-Betriebssystems aufweisen. Dennoch verfügt es über eine Vielzahl äußerst nützlicher Funktionen und Techniken zur Erhöhung der Sicherheit Ihres Systems. In diesem Kapitel wird detailliert auf die entsprechenden Themen eingegangen und erläutert, wie Arbeitsstationen und Server in Windows NT 4.0-Systemen anhand dieser Funktionen abgesichert werden können.

Dabei wird die Vorgehensweise für folgende Aufgaben beschrieben:

Erstmaliges Installieren des Betriebssystems und der Patchbasis

Absichern der Startsequenz

Installieren des Verzeichnisdienstclient-Add-Ins

Verwenden von Systemrichtlinien und des Managers für Sicherheitskonfigurationen

Auswählen der Windows NT LAN Manager- (NTLM-)Authentifizierungsebene

Festlegen geeigneter Kennwortrichtlinien

Verwenden von Kennwort- und Kontosperrungen

Absichern des Zugriffs auf das Dateisystem

Absichern von Diensten

Weitere Absicherungsmaßnahmen

Auf dieser Seite
Sicherheitsentwurf für Windows NT-HostsSicherheitsentwurf für Windows NT-Hosts
ImplementierungImplementierung
Testen der LösungTesten der Lösung
ZusammenfassungZusammenfassung

Sicherheitsentwurf für Windows NT-Hosts

Zur Absicherung des Windows NT 4.0-Betriebssystems sind die Bewertung und das Verständnis mehrerer Themen erforderlich.

Erstmaliges Installieren des Betriebssystems und der Patchbasis

Der erste wichtige Schritt zur Absicherung von Windows NT-basierten Systemen ist das Installieren der aktuellsten Sicherheitspatches für das Basisbetriebssystem. Im Idealfall wird dies im Rahmen des normalen Patchverwaltungsprozesses wie in Kapitel 6 ("Patchverwaltung") beschrieben vorgenommen. Dieser Prozess sollte mit einer umfassenden Inventur zur Ermittlung der jeweiligen Versionsebene jedes Computers beginnen. Sie können Windows NT 4.0-Systeme entweder mithilfe von Microsoft Baseline Security Analyzer (MBSA) oder von Microsoft Systems Management Server (SMS) lokal oder von einem anderen Standort aus untersuchen. Untersuchen Sie nach Abschluss der Inventur die Ergebnisse daraufhin, ob auf jedem Windows NT-System die erforderlichen Basisupdates installiert sind. Dazu zählen folgende Updates:

Service Pack 6a (SP6a) für Windows NT 4.0, das neueste Service Pack für Windows NT 4.0. Es enthält einen umfassenden und regressionsgetesteten Satz von Patches, die als eine Einheit zu installieren sind.

Das Sicherheits-Rollup-Paket (SRP) nach dem Windows NT 4.0 Service Pack 6a. Das SRP umfasst mehrere Patches, die nach SP6a veröffentlicht wurden und eine Voraussetzung für nachfolgende Patches von Windows Update sind.

Ein aktueller Satz von Sicherheitspatches. Microsoft hat seit Veröffentlichung des SRP kein integriertes SRP oder Service Pack für Windows NT 4.0 herausgebracht, jedoch wurden einzelne Komponenten, z. B. Teile des Betriebssystems, Microsoft Internet Explorer sowie Add-On-Dienstprogramme wie der Routing- und RAS-Dienst (RRAS) und die Internetinformationsdienste (IIS), aktualisiert. Eine aktuelle Liste der Patches ist von Microsoft TechNet erhältlich. Sie können auch die auf Windows Update verfügbare Liste der Patches zu Rate ziehen.

Eine aktualisierte Version von Internet Explorer. Internet Explorer 6.0 Service Pack 1 (SP1) ist die aktuellste Version. Sie enthält hunderte von Sicherheitsupdates und Verbesserungen, die seit den unter Windows NT verfügbaren Versionen von Internet Explorer veröffentlicht wurden. Je nach vorliegender Umgebung können Sie Internet Explorer entweder direkt von der Microsoft-Website herunterladen, auf CD-ROM bestellen oder mithilfe des Internet Explorer Administration Kit auf mehreren Computern installieren.

Absichern der Startsequenz

Wenn das System über einen korrekten und vollständigen Mindestsatz an Patches verfügt, muss als Nächstes der ihm zum Systemstartzeitpunkt verfügbare Schutzgrad erhöht werden. Dieser Schutz weist zwei Formen auf: Verkürzung der Anzeigedauer des Startmenüs auf null, um die Möglichkeit des Startens eines anderen Betriebssystems zu erschweren, und Verwendung des integrierten Syskey-Dienstprogramms zur Verschlüsselung der in der SAM-Datenbank (Security Account Manager) gespeicherten Informationen.

Windows NT Server speichert Benutzerkontoinformationen, einschließlich einer Ableitung des Benutzerkontokennworts, in einem gesicherten Bereich der Registrierung, der durch Zugriffssteuerung sowie eine Verschleierungsfunktion geschützt ist. Auf die Kontoinformationen in der Registrierung kann ausschließlich von Mitgliedern der Administratorgruppe zugegriffen werden. Wie bei anderen Betriebssystemen auch ermöglicht Windows NT Server Administratoren den Zugriff auf alle Ressourcen im System. Bei Installationen mit erhöhtem Sicherheitsbedarf wird durch die sichere Verschlüsselung von Kontokennwortableitungen zusätzliche Sicherheit gewährleistet, so dass Administratoren, die Registrierungsprogrammierschnittstellen verwenden, nicht absichtlich oder unbeabsichtigt auf Kennwortableitungen zugreifen können. Syskey schützt SAM-Daten ebenfalls vor unterschiedlichen durch Starten eines anderen Betriebssystems und Zugriff auf die SAM-Dateien erfolgenden Offline-Angriffen.

Syskey generiert einen zufälligen Verschlüsselungsschlüssel für die SAM-Daten. Nach erfolgter Verschlüsselung der SAM-Daten muss der Schlüssel beim Systemstart geladen und zur Entschlüsselung der speicherresidenten Kopie der SAM-Daten verwendet werden. Für Syskey gibt es drei Betriebsmodi, wie in Abbildung 4.1 dargestellt:

Im Modus 1 (Systemstartschlüssel lokal speichern) wird der Schlüssel verschlüsselt und auf dem lokalen Computer gespeichert. Beim Systemstart wird der Schlüssel entschlüsselt und geladen, wodurch der Computer ohne Administratoreingriff neu gestartet werden kann.

Im Modus 2 (Option Kennwort für den Systemstart und zugehörige Textfelder) wird der Schlüssel mit einem vom Administrator festgelegten Kennsatz verschlüsselt. Beim Systemstart muss der Administrator diesen Kennsatz in der Konsole eingeben. Das System wird erst nach Eingabe des Kennsatzes gestartet.

Im Modus 3 (Option Systemstartschlüssel auf Diskette speichern) wird der zufällig erzeugte Syskey-Schlüssel auf einer Diskette gespeichert, die während des Systemstarts bei Aufforderung eingelegt werden muss. Diese Diskette ist sicher zu verwahren und zu verwalten.

nt980401.gif

Abbildung 4.1. Dialogfeld zur Modusauswahl für Syskey

Trey hat sich für die Einrichtung des Syskey-Schutzes auf allen Windows NT-Computern entschieden (Syskey ist unter Windows 2000, Microsoft Windows Server™ 2003 sowie Windows XP standardmäßig aktiviert). Die meisten Server und sämtliche Arbeitsstationen bei Trey wurden zur Verwendung von Syskey-Modus 1 eingerichtet. Trey hat diesen Modus für den umfangreichen Einsatz gewählt, da er einen vernünftigen Ausgleich zwischen Sicherheit und Benutzerfreundlichkeit bietet. Für hochwertige Server verwendet Trey den Modus 2, auch wenn dies die Eingabe eines Kennworts durch einen Administrator bei jedem Neustart des Computers erforderlich macht. Aufgrund der Notwendigkeit, eine Diskette für jeden geschützten Computer sicher zu verwahren und zu verwalten, hat sich Trey generell gegen die Verwendung von Modus 3 entschieden.

Installieren des Verzeichnisdienstclient-Add-Ins

Windows NT 4.0-Systeme können ausschließlich in Windows NT-Domänen verwendet werden. Bei Vorhandensein von Microsoft Active Directory®-Verzeichnisdienstdomänen können Windows 98 und Windows NT nur über die NetBIOS-Schnittstelle (Network Basic Input/Output System) systemeigen verwendet werden. Unter Windows 2000 und Windows Server 2003 ist die NetBIOS-Kompatibilität durch Emulation eines primären Domänencontrollers (PDC) für Windows NT gegeben. Auch wenn Active Directory beiderseitige transitive Vertrauensstellungen bietet, können in Windows NT 4.0-Systemen nur einseitige explizite Vertrauensstellungen genutzt werden. Dies gilt unabhängig davon, ob das System einen Active Directory-Domänencontroller oder einen Windows NT-BDC verwendet.

Anstatt Domänen nach Windows NT-Art bereitzustellen, können Computer, auf denen Windows NT bzw. Windows 98 ausgeführt wird, durch Hinzufügen des Add-Ins für den Verzeichnisdienstclient (DSClient) Teil von Active Directory-Domänen sein. Mit DSClient werden diese Systeme in die Lage versetzt, an Active Directory-Domänen teilzunehmen. Sie können dank dieser Software eine Vielzahl der Active Directory-Funktionen nutzen, etwa die Verwendung von transitiven Vertrauensstellungen innerhalb einer Gesamtstruktur. Transitive Vertrauensstellungen ermöglichen autorisierten Benutzern den Zugriff auf geeignete Ressourcen in jeder beliebigen Domäne der Gesamtstruktur. Die DSClient 2003-Aktualisierung kann unter Windows NT 4.0 mit SP6a sowie Internet Explorer 6 SP1 ausgeführt werden. Für die mit Windows 2000 gelieferte DSClient-Version ist außerdem SP6 erforderlich, jedoch kann Internet Explorer 4.01 oder höher verwendet werden (eine Beschreibung der Voraussetzungen für die Verwendung von DSClient unter Windows 98 finden Sie in Kapitel 5, "Absichern von Microsoft Windows 98").

Nach der Installation bietet DSClient keine Unterstützung für sämtliche Active Directory-Funktionen. Insbesondere werden die Kerberos-Authentifizierung, die Anwendung von Gruppenrichtlinien und die Verwendung von Dienst- oder Benutzerprinzipalnamen (UPNs) für die Authentifizierung nicht unterstützt. Allerdings wird die Unterstützung für folgende Active Directory-Funktionen aktiviert:

Active Directory Service Interfaces (ADSI). ADSI bieten eine gemeinsame Programmier-API für Skripts und Programme, die Active Directory berücksichtigen. Mit ADSI können zahlreiche Verzeichnisoperationen geskriptet werden, die sich unter Windows NT normalerweise nicht skripten lassen.

Verteiltes Dateisystem (Distributed File System, DFS) – Fehlertoleranz-Client. Fehlertolerante DFS- und Failover-Dateifreigaben stellen in Active Directory integrierte verteilte Dateifreigaberessourcen bereit.

Eigenschaftenseiten des Windows-Adressbuchs (WAB) in Active Directory. Benutzerobjektseiten, auf die über das Menü Suchen zugegriffen wird, bieten autorisierten Benutzern die Möglichkeit, Eigenschaften (z. B. Adressen und Telefonnummern) von Benutzerobjekten zu aktualisieren.

Authentifizierung durch NTLM, Version 2. NTLM sorgt für verbesserte Authentifizierungsfunktionen und bietet neben Kerberos den besten Sicherheitsgrad für Authentifizierungen.

Standort-Erkennung. Systeme, auf denen DSClient verwendet wird, erkennen Active Directory-Standorte und verwenden selbst für Kennwortänderungsoperationen einen Domänencontroller am lokalen Standort, sofern DNS (Domain Name System) ordnungsgemäß konfiguriert wurde und die Standorte korrekt in Active Directory registriert sind. Weitere Informationen zur Auswirkung von DSClient auf das Anmeldungs- und Kennwortänderungsverhalten finden Sie im englischsprachigen Microsoft Knowledge Base-Artikel 249841 ("How Windows 98 Active Directory Client Extension uses Active Directory site information") unter http://support.microsoft.com/?kbid=249841.

Suche nach Objekten in Active Directory. Benutzer können über das Menü Suchen Drucker und andere Benutzer in Active Directory finden.

Verringerte Abhängigkeit auf dem PDC. Clients können für Kennwortänderungen die Verbindung zu jedem beliebigen Domänencontroller in der Domäne herstellen.

Verwenden von Systemrichtlinien und des Managers für Sicherheitskonfigurationen

Bei den Systemrichtlinien handelt es sich um eine spezifische Konfigurationsverwaltungsmaßnahme, die erstmals unter Windows 95 und Windows NT 4.0 verfügbar gemacht wurde. Sie allein erhöhen die Sicherheit eines Systems noch nicht, allerdings ermöglichen sie die Einschränkung des Zugriffs auf bestimmte Ressourcen so, dass andere Sicherheitsmaßnahmen eine Verbesserung erfahren und die Wahrscheinlichkeit der mutwilligen oder unbeabsichtigten Umgehung Ihrer Richtlinien und Einschränkungen verringert wird. Wenn diese Richtlinien auf geeignete Weise entworfen und angewendet werden, stellen sie einen wichtigen Faktor für die Gewährleistung der Integrität älterer Systeme dar. Aufgrund ihrer Nützlichkeit hat Microsoft die Gruppenrichtlinienobjekt-Funktionalität (Group Policy Object, GPO) unter Windows 2000 und höher auf sie aufgebaut.

Eine Systemrichtlinie ist ein Satz aus einer oder mehreren Einschränkungen, die auf die Registrierungsstrukturen HKEY_CURRENT_USER und HKEY_LOCAL_MACHINE angewendet werden. Wenn sich ein Benutzer bei einem Computer anmeldet, werden aufeinander folgende Richtlinien gesucht und, sofern gefunden, angewendet. Dies erfolgt auf der Grundlage des Benutzernamens, der Mitgliedschaft in globalen Gruppen in der Domäne und computerspezifischer Richtlinien. Systemrichtlinien sind für die Verwendung in Windows NT-Domänenimplementierungen gedacht und ergänzen andere Domänen berücksichtigende Funktionen, wie z. B. Benutzerprofile.

Es ist wichtig, zwischen Systemrichtlinien und Benutzerprofilen zu unterscheiden. Benutzerprofile sind eine Sammlung von benutzerkonfigurierten Verzeichnissen, Dateien, Verknüpfungen und Registrierungsstrukturen, die unter HKEY_CURRENT_USER (Ntuser.dat unter Windows NT bzw. User.dat unter Windows 98) geladen werden. Mit ihnen werden die Desktop-Darstellung, Browser-Favoriten und Lesezeichen sowie andere vom Benutzer konfigurierbare Optionen sowohl im Betriebssystem als auch in beliebigen Anwendungen gesteuert. Im Gegensatz dazu sind Systemrichtlinien ein zusätzlicher Satz von Registrierungseinträgen, die nach erfolgtem Laden des aktiven Benutzerprofils auf den Computer angewendet werden. Durch sie werden bestimmte Funktionen des Betriebssystems festgelegt, auf die der aktuelle Benutzer keinen Zugriff erhält.

Arbeiten mit Systemrichtlinien

In dem von Microsoft erhältlichen englischsprachigen Whitepaper "Guide to Microsoft Windows NT 4.0 Profiles and Policies" werden Benutzerprofile und Systemrichtlinien sowie deren separate und gemeinsame Verwendungsweise erläutert. (Im Abschnitt "Weitere Informationen" wird angegeben, wo das Whitepaper erhältlich ist).

Systemrichtlinien stellen eine Vielzahl von Steuerungsmöglichkeiten für frühere Versionen der Desktop- und Benutzeroberfläche bereit. Wenn Sie mit Gruppenrichtlinien unter Windows 2000 vertraut sind, kennen Sie bereits die grundlegenden Funktionen von Systemrichtlinien. Im Allgemeinen bieten sie folgende Möglichkeiten:

Festlegen von Bannern oder Verzichtserklärungen, die angezeigt werden, bevor ein Benutzer die Erlaubnis zur Anmeldung erhält, z. B. mit Hinweisen auf anwendbare rechtliche Nutzungsrichtlinien.

Unterbinden der Anzeige von sicherheitsrelevanten Informationen wie z. B. des Namens des letzten Benutzers oder der Schaltfläche zum Herunterfahren im Anmeldedialogfeld.

Festlegen des Verhaltens von Anmeldeskripts, von auf dem Server zwischengespeicherten Profilen, der Erkennung von langsamen Netzwerken, des Startbanners sowie von Tipps für den Benutzer.

Angabe des Speicherorts unterschiedlicher freigegebener Ordner einschließlich des Startordners im Menü Start, wodurch sichergestellt werden kann, dass bestimmte Anwendungen bei der Anmeldung immer gestartet werden.

Einschränken der auf dem Desktop angezeigten Elemente: Hintergründe, Symbole, Farben und im Menü Start verfügbare Befehle.

Festlegen des Verhaltens verschiedener Funktionen mit Bezug auf das Dateisystem, z. B. Shell-Erweiterungen, Aktualisierungen von Zugriffszeiten auf schreibgeschützte Dateien und lange Dateinamen.

Einschränken des Zugriffs auf Netzwerkressourcen, verfügbare Laufwerksbuchstaben und die Möglichkeit, Laufwerke in Windows Explorer zuzuordnen. Weitere Informationen finden Sie in den englischsprachigen Knowledge Base-Artikeln 156698 ("Disabling Access to Network Resources Using System Policies") unter http://support.microsoft.com/?kbid=156698 und 220955 ("Using System Policies to Hide Specific Drive Letters") unter http://support.microsoft.com/?kbid=220955.

Einschränken der Erstellung verborgener Dateifreigaben.

Festlegen und Einschränken von Drucker-, SNMP- (Simple Network Management Protocol) und RRAS-Einstellungen.

Einschränken der Fähigkeit der Shell, bestimmte ausführbare Dateien zu starten.

Einschränken der Fähigkeit, Registrierungs-Editoren und die Eingabeaufforderung aufzurufen.

Systemrichtlinien weisen viele Ähnlichkeiten mit Gruppenrichtlinien auf, es sind jedoch einige Beschränkungen und Unterschiede zu beachten:

Systemrichtlinien sind nicht hierarchisch gegliedert. Aufgrund des "flachen" Windows NT-Domänenmodells weist die Möglichkeit der Definition von überlappenden, komplementären Systemrichtlinien eine geringere Flexibilität auf, als dies bei Gruppenrichtlinien in Active Directory der Fall ist. Es können Richtlinien für einzelne Benutzer, Standardbenutzer, Gruppen, einzelne Computer und Standardcomputer festgelegt werden. Weiter unten in diesem Kapitel wird die Methode zu deren Anwendung beschrieben.

Systemrichtlinien nehmen Änderungen direkt an der entsprechenden Registrierungsstruktur vor. Sie bleiben so lange wirksam, bis sie etwa durch eine andere Richtlinie geändert werden. Gruppenrichtlinien in Active Directory nehmen Änderungen an einer bestimmten Stelle in der Registrierung vor, die Windows danach zum Umgehen der normalen Registrierungseinträge heranzieht. Man kann sich die Systemrichtlinienpraxis von direkt in der Registrierung vorgenommenen Schreibvorgängen als ein "Tätowieren der Registrierung" vorstellen; hierbei sind Annahmen über den Zustand von jeglichen verwalteten Einstellungen nicht möglich.

Systemrichtlinien werden mithilfe des Systemrichtlinien-Editor-Dienstprogramms (System Policy Editor, SPE) und administrativer Vorlagedateien (.adm) eingerichtet. Durch diese Vorlagedateien werden die SPE-Kategorien und -Unterkategorien, Registrierungsschlüssel und -werte sowie jegliche zutreffenden Optionen, Einschränkungen und Standardwerte bereitgestellt. Sie können eigene Vorlagedateien erstellen und auf bestimmte Registrierungseinstellungen anwenden, die nicht bereits durch im SPE enthaltene Standardvorlagen berücksichtigt werden.

Nach Ausführung des SPE und Einrichtung einer Gruppe von Einstellungen, die anschließend einem Benutzer, einer Gruppe, einem Computer oder einem Standardbenutzer bzw. -computer zugeordnet werden, liegt eine Richtliniendatei mit dem Namen Ntconfig.pol vor. Standardmäßig laden Computer, auf denen Windows NT ausgeführt wird, die entsprechenden Richtliniendateien von der NETLOGON-Freigabe auf den Domänencontrollern herunter. Richtliniendateien sind auf dieser Freigabe auf dem PDC abzulegen. Der Inhalt dieser Freigabe wird danach über den Verzeichnisreplikationsdienst in den Reservedomänencontrollern repliziert. Computer, auf denen Windows NT ausgeführt wird, können alle zutreffenden Richtlinien vom Domänencontroller herunterladen, der für die Anmeldung verwendet wird. Diese Verhaltensweisen sind für Domänencontroller unter Windows NT, Windows 2000 und Windows Server 2003 identisch, da Windows 2000-, Windows XP- und Windows Server 2003-Clients Richtliniendateien in der NETLOGON-Freigabe ignorieren und in Active Directory integrierte GPOs verwenden.

Systemrichtlinien werden in Windows NT folgendermaßen geladen und angewendet:

1.

Bei Vorhandensein einer benutzerspezifischen Richtlinie wird diese geladen und die Registrierung geändert, und die Richtlinienverarbeitung wird mit Schritt 4 fortgesetzt.

2.

Bei Vorhandensein der Richtlinie für Standardbenutzer wird diese geladen und angewendet.

3.

Bei Vorhandensein von Gruppenrichtlinien werden diese geladen und nach Erfordernis in aufsteigender Prioritätsreihenfolge angewendet. Sollte es zu einem Konflikt zwischen einer Gruppenrichtlinie und der Richtlinie für Standardbenutzer kommen, hat die Gruppenrichtlinie Vorrang, sofern sie nicht auf "Ignorieren" eingestellt wurde.

4.

Bei Vorhandensein einer computerspezifischen Richtlinie wird diese geladen und die Registrierung geändert, und die Richtlinienverarbeitung wird mit Schritt 4 fortgesetzt.

5.

Bei Vorhandensein einer Richtlinie für Standardcomputer wird diese geladen und die Registrierung geändert.

6.

Damit ist die Richtlinienanwendung abgeschlossen.

Systemrichtlinien werden unter Windows NT standardmäßig heruntergeladen und angewendet. Dieses Verhalten wird im englischsprachigen Knowledge Base-Artikel 168231 ("System Policies Are Not Applied in Windows NT") unter http://support.microsoft.com/?kbid=168231 beschrieben und durch folgenden Registrierungswert gesteuert:

HKEY_LOCAL_MACHINE\System\CurrentControlSet
\Control\Update\UpdateMode (REG_DWORD)

Durch den Wert 0 wird die Anwendung von Systemrichtlinien deaktiviert.

Durch den Standardwert 1 wird der automatische Modus aktiviert. Windows sucht die Systemrichtliniendatei Ntconfig.pol wie zuvor beschrieben auf dem authentifizierenden Domänencontroller.

Durch den Wert 2 wird der manuelle Modus aktiviert. Windows untersucht den Wert NetworkPath (REG_SZ; im gleichen Schlüssel) und versucht, die dort vorhandene Richtliniendatei zu finden.

Es ist wichtig, die ordnungsgemäße Funktionsweise der Systemrichtlinien zu überprüfen. Im Knowledge Base-Artikel 154120 ("Debuggen von Benutzerprofilen und Systemrichtlinien in Windows NT 4.0") unter http://support.microsoft.com/?kbid=154120 finden Sie eine Beschreibung des Vorgangs zum Ersetzen von userenv.dll durch die geprüfte Version, wodurch eine Protokolldatei zum Debuggen von Richtlinienanwendungen erstellt werden kann. Dieses Verfahren lässt sich auf alle Versionen und Service Pack-Ebenen unter Windows NT 4.0, einschließlich Terminal Server Edition, anwenden.

Das Standardverhalten von Systemrichtlinien hängt zwar von einer funktionsfähigen Windows NT-Domäneninfrastruktur ab, jedoch können auch Windows 2000-Computer, eigenständige Windows NT-Computer sowie Benutzer in der lokalen Kontodatenbank von Systemrichtlinien profitieren. Der englischsprachige Knowledge Base-Artikel 168579 ("How to Set Up Locally-Based System Policies") unter http://support.microsoft.com/?kbid=168579 enthält genaue Anleitungen für zwei Methoden zur Konfiguration eines Windows NT-Systems, so dass es Systemrichtlinien für Benutzer in der lokalen Kontodatenbank bereitstellen kann. Der englischsprachige Knowledge Base-Artikel 274478 ("Group Policies for Windows 2000 Professional Clients in Windows NT 4.0 Domain or Workgroups") unter http://support.microsoft.com/?kbid=274478 erläutert bei Verwendung von Computern, auf denen Windows 2000, Windows XP oder Windows Server 2003 in einer Windows NT-Domäne ausgeführt wird, das zur Verteilung von Windows 2000-kompatiblen Richtlinien durch Windows NT-Domänencontroller erforderliche Verfahren.

Überlegungen zur Planung der Systemrichtlinienbereitstellung

Beachten Sie bei der Entwicklung und Bereitstellung von Richtlinien diese potenziellen Systemrichtlinienkomplikationen, um ein Höchstmaß an Sicherheit zu gewährleisten:

Aufgrund einer Reihe von Fehlern bei der Implementierung von Systemrichtlinien unter Windows NT 4.0 ist mindestens SP3 erforderlich, um sicherzustellen, dass alle wichtigen Patches mit Bezug auf Systemrichtlinien auf Ihre Systeme angewendet wurden. Im Allgemeinen stellt dies kein Problem dar, sofern keine besonderen Anforderungen für unterstützte Anwendungen bestehen, da andere Sicherheitsanforderungen SP6a praktisch für alle Windows NT-Systeme erforderlich machen.

Es sind bis zu zwei Anmeldungen und Abmeldungen erforderlich, um das korrekte Auffinden, Herunterladen und Anwenden von Systemrichtlinien zu gewährleisten.

Da Richtlinien nicht automatisch von einem Computer entfernt werden, sollten Sie eine gruppenspezifische Richtlinie für Ihre Administratorkonten erstellen. Diese ist so einzurichten, dass mindestens die Einschränkungen entfernt werden, die Administratoren benötigen, um sich selbst erneut den Zugriff auf ggf. erforderliche Funktionen zu genehmigen. Eine übliche Richtlinie für die Administratorengruppe besteht darin, einfach sämtliche eingeschränkten Funktionen wiederherzustellen.

Betrachten Sie genau jede einzelne Einstellung in Ihren Richtlinien und vergewissern Sie sich, dass alle potenziellen Doppelnegationen korrekt analysiert werden. Einige Einstellungen müssen aktiviert werden, damit das festgelegte Verhalten ausgeschaltet wird.

Überprüfen Sie nochmals den Speicherort der Systemrichtliniendateien. Diese sollten sich in der NETLOGON-Freigabe befinden, die sich ihrerseits an unterschiedlichen Speicherorten befinden kann, je nachdem, ob auf dem primären Domänencontroller Windows NT 4.0, Windows 2000 oder Windows Server 2003 ausgeführt wird.

Die einwandfreie Funktionsfähigkeit des Verzeichnisreplikationsdiensts muss unbedingt gewährleistet sein, und der Inhalt der NETLOGON-Freigabe auf dem PDC muss ordnungsgemäß auf alle Reservedomänencontroller kopiert werden.

Vergewissern Sie sich, dass die Änderungszeit der Richtliniendateien jedes Mal aktualisiert wird, wenn Sie eine neue Richtlinie ändern und bereitstellen. Bei einigen Clients mit älteren Service Packs werden die Richtliniendateien zwischengespeichert. Auf ihnen wird die Änderungszeit als Indikator für die Aktualisierung der Datei herangezogen. Die beste Lösung besteht darin, auf allen Computern, auf denen Windows NT ausgeführt wird, mindestens SP3 oder nach Möglichkeit SP6a zu installieren.

Wenn eine Kombination von Windows NT 4.0- und Windows 2000- bzw. Windows Server 2003-Domänencontrollern vorhanden ist, besteht die Möglichkeit, einen Replikationsprozess als Brücke zwischen dem Verzeichnisreplikationsdienst von Windows NT und dem Dateireplikationsdienst von Windows 2000 einzurichten.

Die Verwendung von Systemrichtlinien unter Windows NT 4.0 Terminal Server Edition führt zu einigen Komplikationen. Weitere Informationen finden Sie im Knowledge Base-Artikel 192794 ("Anwenden von Systemrichtlinien in Terminalserver") unter http://support.microsoft.com/?kbid=192794.

Es sei nochmals daran erinnert, dass Systemrichtlinien keinen adäquaten Ersatz für die ordnungsgemäße Anwendung von Zugriffssteuerungslisten (ACLs) für die Registrierung und das Dateisystem darstellen und auch nicht für Einsparungen bei anderen Systemabsicherungsmaßnahmen geeignet sind. Als Beispiel sei ein System mit einer Systemrichtlinie betrachtet, durch die ein Benutzer ausschließlich Binärdateien von Microsoft Office-Anwendungen ausführen kann. Der Benutzer könnte über das standardmäßige Office-Menü Datei neue Ordner erstellen und ausführbare Dateien wie z. B. cmd.exe oder einen der Registrierungs-Editoren an Speicherorte ohne Schreibschutz kopieren und dort umbenennen, so dass die Systemrichtlinie die neuen Namen zulässt und somit umgangen wird.

Es gibt bestimmte Schwachstellenbereiche, die bei der Bereitstellung von Systemrichtlinien berücksichtigt werden müssen, indem sie durch weitere Sicherheitsmaßnahmen ergänzt werden:

Alle eingeschränkten ausführbaren Dateien in Systemrichtlinien sollten durch den vollständigen Pfad angegeben werden und nicht auf den standardmäßigen Suchpfad zurückgreifen.

Ziehen Sie in Erwägung, die Verwendungsmöglichkeiten der Menüs Extras und Ansicht in Windows Explorer einzuschränken. Diese Menüs enthalten eine Vielzahl von Optionen, die zur Überwindung von Richtlinieneinschränkungen verwendet werden können.

Registrierungsdateien (.reg) können normalerweise ausgeführt werden, auch wenn der Zugriff auf RegEdt32 und RegEdit deaktiviert wurde, da die standardmäßige Zuordnung der Dateinamenerweiterung nach wie vor besteht.

Verzeichnisse, in die Benutzer schreiben können (z. B. das temporäre Verzeichnis oder Profilverzeichnis), sollten zu keinem Zeitpunkt Teil des standardmäßigen Suchpfads sein.

Die globale Sicherheits-ID (SID) in der Registrierung gewährt mehr Zugriffsmöglichkeiten als erforderlich. Ziehen Sie die Möglichkeit in Betracht, diese ID auf die Abfrage-, Auflistungs- und Leseberechtigungen zu begrenzen. Dadurch könnte allerdings die korrekte Funktion älterer Anwendungen beeinträchtigt werden, und es sind u. U. umfassende Tests zur Ermittlung der spezifischen Berechtigungen erforderlich, die zur Aufrechterhaltung der Funktionalität anzuwenden sind.

Sämtliche ausführbaren Dateien in Systemverzeichnissen sind genau zu untersuchen. Selbst nach Entfernen der Berechtigung zum Ausführen aus den ausführbaren Dateien könnten Benutzer mit Berechtigung zum Lesen sie an einen Speicherort ohne Schreibschutz kopieren und dort ausführen.

Manager für Sicherheitskonfigurationen

Der Manager für Sicherheitskonfigurationen (Security Configuration Manager, SCM) wurde ursprünglich für Windows 2000 konzipiert und von Microsoft später für Windows NT 4.0 SP4 und höher zur Verfügung gestellt. Der SCM ist auf der CD-ROM für SP6a verfügbar und kann von der Microsoft-FTP-Site heruntergeladen werden. Das wichtigste Tool im SCM ist der Sicherheitskonfigurations-Editor (Security Configuration Editor, SCE), der zum Erstellen und Verwalten von Sicherheitsvorlagen und Systemrichtlinien dient.

Mit dem SCE können mehrere nützliche Aufgaben ausgeführt werden. Dies umfasst beispielsweise Folgendes:

Einrichten von Sicherheitsvorlagen zur Festlegung von Überwachungen, Benutzerrechten und Sicherheitseinstellungen für Computer, auf denen Windows NT ausgeführt wird.

Automatisches Anwenden von Vorlagen auf einen oder mehrere Computer in einer Domäne.

Scannen eines oder mehrerer Computer zur Bewertung der Kompatibilität mit einer bestimmten Vorlage.

Standardmäßig wird durch die Installation des SCE ein Vorlagensatz im Ordner %winnt%\security\templates abgelegt. Jede Vorlage ist für eine bestimmte Sicherheitsumgebung und einen bestimmten Computertyp vorgesehen:

Durch die Basisvorlagen (Basic*4.inf) wird eine standardmäßige Sicherheitsstufe auf Zielcomputer angewendet, einschließlich einer sechswöchigen Geltungsdauer für Kennwörter und eines grundlegenden Satzes von Berechtigungen für Registrierungsschlüssel, Dateisystem und Benutzerrechte.

Mit den kompatiblen Vorlagen (Comp*4.inf) ist ein höheres Sicherheitsmaß als bei den Basisvorlagen gegeben. Sicherheitseinstellungen, die ältere Clients oder Anwendungen beeinträchtigen könnten, bleiben jedoch ausgeschaltet. Der Zweck dieses Vorlagensatzes besteht in der Erhöhung der Sicherheit, ohne Probleme hinsichtlich der Anwendungskompatibilität zu verursachen.

Hochsicherheitsvorlagen (HiSec*.inf) wenden einige zusätzliche Sicherheitsrichtlinien an, etwa die Erhöhung der minimalen Kennwortlänge von sieben auf acht Zeichen sowie die Verwendung eines restriktiveren Satzes an Dateisystem- und Registrierungsberechtigungen. Diese Vorlagen können bei älteren Anwendungen, für die Dateisystem- oder Registrierungsberechtigungen oder Zuweisungen von Benutzerrechten erforderlich sind, zu Problemen führen.

Sichere Vorlagen (Secur*.inf) stellen die Standardvorlagen mit dem größten Schutz dar, mit ihnen werden jedoch Funktionen wie z. B. die SMB-Signierung (Server Message Block) aktiviert, durch die die Interoperabilität zwischen gesicherten Computern und Windows 95/98-Clients ohne ähnliche Konfiguration beeinträchtigt wird.

Tabelle 4.1: Vordefinierte Vorlagen im Umfang der SCE-Tools von Windows NT

Gewünschte SicherheitFürZu verwendende Vorlage

Basissicherheit

Primäre Domänencontroller/Reservedomänencontroller

BasicDC4.inf

Mitgliedsserver

BasicSv4.inf

Arbeitsstationen

BasicWk4.inf

Erhöhte Sicherheit mit guter Anwendungskompatibilität

Primäre Domänencontroller/Reservedomänencontroller

CompDC4.inf

Mitgliedsserver

CompDC4.inf

Arbeitsstationen

CompWS4.inf

Hohe Sicherheit mit reduzierter Anwendungskompatibilität

Mitgliedsserver oder Domänencontroller

HiSecDC4.inf

Arbeitsstation

HiSecWS4.inf

Hohe Sicherheit bei reduzierter Windows 98-Konnektivität

Mitgliedsserver oder Domänencontroller

SecurDC4.inf

Da der SCM ursprünglich für Windows 2000 konzipiert wurde, verfügt er über eine vertraute Schnittstelle für Administratoren, die Gruppenrichtlinien verwenden. Diese Schnittstelle weist eine Funktion zum Aktualisieren des in Windows NT integrierten ACL-Editors auf den unter Windows 2000 verwendeten ACL-Editor auf. Dieser Vorgang ist für das Verhalten von Zugriffssteuerungslisten im gesamten System von Bedeutung, da für den SCM das ACL-Vererbungsmodell von Windows 2000 erforderlich ist, durch das vererbte Zugriffssteuerungslisten dynamisch angewendet werden. Anstatt Zugriffssteuerungseinträge (Access Control Entries, ACEs) aus dem übergeordneten in das untergeordnete Objekt zu kopieren, verweist das neue Subsystem zur Überprüfung der Aktivierung auf die Richtlinie Berechtigungen übergeordneter Objekte. Das aktualisierte Vererbungssystem wird von den herkömmlichen ACL-Editoren in Windows Explorer sowie von den durch den SCM angewendeten Richtlinien verwendet. Es kann allerdings nicht direkt über den Registrierungs-Editor (regedt32.exe) auf sie zugegriffen werden. Daher können vom SCM angewendete Richtlinien, durch die Zugriffssteuerungslisten in der Registrierung geändert werden, Zugriffssteuerungslisten erstellen, die nicht mit dem Registrierungs-Editor bearbeitet werden können. Weitere Informationen zum neuen ACL-Editorsystem und dessen Auswirkungen, einschließlich Informationen zu dessen Deaktivierung (wodurch wiederum der SCM deaktiviert wird), finden Sie im englischsprachigen Knowledge Base-Artikel 195509 ("Installing Security Configuration Manager from SP4 Changes Windows NT 4.0 ACL Editor") unter http://support.microsoft.com/?kbid=195509.

Mit dem SCM können Sie folgende Bereiche konfigurieren:

Kontorichtlinien, was Optionen für Kennwort- und Kontosperrung umfasst.

Lokale Richtlinien, wozu Optionen für Überwachungen, Benutzerrechtszuweisungen und Sicherheitsrichtlinien gehören.

Ereignisprotokollrichtlinien.

Eingeschränkte Gruppen, durch die die Mitgliedschaft einzelner Gruppen aufgehoben werden kann.

Systemdienste, mit denen Optionen zur Konfiguration verschiedener Dienste und Transportmöglichkeiten bereitgestellt werden.

Registrierungsberechtigungen.

Berechtigungen im Dateisystem.

Die SCM-Benutzeroberfläche enthält eine Auflistung der definierten und im Ordner %winnt%\security\templates gespeicherten Richtlinien. Über die grafische Benutzeroberfläche können Sie für die von Ihnen unterhaltenen älteren Systeme mehrere geeignete Richtlinien definieren, bearbeiten und verwalten sowie das System analysieren und dessen Kompatibilität mit einzelnen Richtlinienvorlagen überprüfen.

Der Hauptunterschied zwischen dem SCM und Active Directory-Richtlinien besteht darin, dass Windows NT keine Funktion zur automatischen Bereitstellung von Richtlinienvorlagen in einer Gruppe von verwandten Computern bietet, weshalb Konfigurationsvorlagen nach wie vor auf andere Weise auf die entsprechenden Computer verteilt werden müssen. Für die Verteilung ist entweder ein manueller Eingriff oder ein Skripten sowie ein Mechanismus zur Sicherstellung der automatischen und regelmäßigen Anwendung von Richtlinien erforderlich.

Verwenden Sie den SCM als Hilfsmittel zum Vornehmen und Bereitstellen folgender grundlegender Kontorichtlinienänderungen auf allen Systemen:

Umbenennen des Gastkontos (neben der Möglichkeit der Deaktivierung) mithilfe des SCM (über die Einstellung Lokale Richtlinien | Sicherheitsoptionen | Gastkonto umbenennen). Sorgen Sie auch bei erfolgter Deaktivierung für ein äußerst sicheres Kennwort. Überprüfen Sie regelmäßig, dass es nicht Teil einer anderen Gruppe als der der Domänengäste ist, die keine anderen Mitglieder aufweisen sollte.

Umbenennen des Administratorkontos in einen nicht offensichtlichen Namen (anhand der Einstellung Lokale Richtlinien | Sicherheitsoptionen | Administrator umbenennen) und anschließendes Erstellen eines fiktiven Kontos mit der Bezeichnung "Administrator", das keine Rechte oder Berechtigungen aufweist. Verfahren Sie mit diesem fiktiven Konto wie mit dem Gastkonto, indem Sie ein sicheres Kennwort einrichten und es deaktivieren. Vermeiden Sie den häufigen Fehler, dieses Konto in den Anmerkungen als fiktiv zu bezeichnen, da dies den Zweck dieses Kontos zunichte machen würde. Auch hier können regelmäßige Überprüfungen notwendig sein, um zu vermeiden, dass das fiktive Konto zu Gruppen hinzugefügt wird. Achten Sie auf Authentifizierungsversuche, die bei diesem Konto durchgeführt werden könnten. Durch diese Maßnahme wird zwar nicht verhindert, dass Angreifer im Netzwerk die bekannte SID zur Ermittlung des tatsächlichen Administratorkontonamens verwenden können, allerdings ist sie gegen nachlässige Angreifer und Angriffe aus externen Netzwerken wirksam; in diesen Fällen erhalten Sie frühzeitige Warnungen über bösartige Absichten.

Unterbinden der Auflistung von Kontonamen und Dateifreigaben durch anonym angemeldete Benutzer (Nullsitzung). Standardmäßig genehmigt Windows Remote-Systemen die Verbindungsaufnahme ohne Anmeldeinformationen und die Auflistung dieser Angaben. Diese Möglichkeit wird häufig für Angriffe missbraucht. Verwenden Sie die Einstellung Disallow enumeration of account names and shares by anonymous (Anonyme Aufzählung von Kontennamen und Freigaben nicht erlauben) im Sicherheitsrichtlinienobjekt des Knotens Lokale Richtlinien.

Auswählen der NTLM-Authentifizierungsebene

Windows NT 4.0-Clients vor SP4 verwenden die NTLMv1-Authentifizierung, die nachweislich einen fehlerhaften Entwurf aufweist und dadurch nicht ausreichend vor unautorisierten Zugriffe und Entschlüsselungsversuchen geschützt ist. Die NTLM-Authentifizierung wurde als Nachfolger für das noch unsicherere LAN Manager- (LM-)Authentifizierungsprotokoll konzipiert, für das die Speicherung aller Kennwortinformationen in einem als LM-Hash bezeichneten schwächeren Hash erforderlich ist (im folgenden Abschnitt wird detaillierter hierauf eingegangen). Der LM-Hash ist einfach zu entschlüsseln, wodurch das Kennwort gefährdet ist.

LM, NTLM und NTLMv2 dienen zur Authentifizierung von Vorgängen wie Folgenden:

Beitritt zu einer Domäne

Authentifizierung zwischen Active Directory-Gesamtstrukturen

Authentifizierung für Windows NT 4.0-Domänen

Authentifizierung für Windows NT 4.0- oder Windows 98-Computer mit Datei- oder Druckserverfunktion

Authentifizierung für Server, die keine Domänenmitglieder sind

Trey verfügt über eine Kombination von Computern, auf denen Windows Server 2003 (für Domänencontroller), Windows 98 und Windows NT 4.0 ausgeführt wird. Daher muss eine NTLM-Authentifizierungsebene ausgewählt werden, die die bestmögliche Sicherheit bietet, während vorhandene Clients weiterhin in der Lage sein müssen, normal betrieben zu werden. Windows NT, Windows 2000 und Windows Server 2003 unterstützen sechs LM-Kompatibilitätsebenen, die über den Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
\LSA\LMCompatibilityLevel gesteuert werden:

0 (LM- und NTLM-Antworten senden). Mit dieser Einstellung wird die größtmögliche Interoperabilität gewährleistet, da Clients LM oder eine beliebige NTLM-Version zur Authentifizierung nutzen können. Allerdings wird unsicherer LM-Verkehr im Netzwerk zugelassen.

1 (LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt)). Diese Einstellung bietet ein höheres Maß an Sicherheit, jedoch ist die DSClient-Software für Windows 98 erforderlich. Bei Auswahl dieses Werts kann NTLMv2 ausgehandelt werden, sofern beide Computer dies unterstützen. Dieser Wert eignet sich am besten während der Bereitstellung. Sämtliche Computer mit DSClient verwenden NTLMv2, während die Authentifizierung auf allen anderen Clients mit einer älteren Windows-Version ebenfalls möglich ist.

2 (Nur NTLM-Antworten senden). Durch diesen Wert wird die Nutzung von Windows 98-Clients mit fehlender DSClient-Installation eingeschränkt, da Server nicht auf LM-Anforderungen von unveränderten Computern antworten, auf denen Windows 98 ausgeführt wird.

3 (Nur NTLMv2-Antworten senden). Verwenden Sie diesen Wert nur dann, wenn auf sämtlichen Clients, auf denen ältere Windows-Versionen als Windows NT 4.0 SP4 ausgeführt werden, DSClient installiert wurde.

4 (Nur NTLMv2-Antworten senden\LM verweigern). Verhält sich wie die vorherige Einstellung mit dem Zusatz, dass bei Anforderung der LM-Authentifizierung keine NTLMv2-Antwort gesendet wird.

5 (Nur NTLMv2-Antworten senden\LM & NTLM verweigern). Verhält sich wie die vorherige Einstellung mit der Ausnahme, dass NTLM-Anforderungen ebenfalls ignoriert werden. Diese Einstellung ist ausschließlich für Netzwerke mit Computern geeignet, auf denen entweder Windows 2000 oder höher oder Windows 98 mit installiertem DSClient ausgeführt wird.

Aktualisieren der NTLM-Authentifizierung unter Windows 98

Mit der DSClient-Erweiterung können Windows 98-Systeme NTLMv2 für die Authentifizierung verwenden. Standardmäßig wird für die Verschlüsselung der NTLMv2-Sitzungssicherheit eine Schlüssellänge von maximal 56 Bit verwendet. Um 128-Bit-NTLMv2 nutzen zu können, muss Internet Explorer 4 oder höher installiert und die 128-Bit-Unterstützung installiert und konfiguriert sein. Dies muss vor der Installation von DSClient erfolgt sein.

Nach Verteilung der DSClient-Software auf die Client-Computer können Sie einschränkend festlegen, welche der Versionen der LM-Protokollfamilie für die Authentifizierung verwendbar sein sollen. Diese Einschränkung muss auf allen Domänencontrollern und anderen Servern, die Konten für die Remote-Authentifizierung bereitstellen, konfiguriert werden.

Aktualisieren der NTLM-Authentifizierung unter Windows NT 4.0

Windows NT 4.0 SP4 und höher bietet die Möglichkeit der selektiven Verwendung und Beantwortung von LM-, NTLM- und NTLMv2-Authentifizierungsanforderungen. Für diese Änderung ist ein zusätzlicher Registrierungsschlüssel erforderlich (dieser wird im Implementierungsabschnitt weiter unten beschrieben). Trey hat die Kompatibilitätsstufe 5 (nur NTLMv2 zulassen) auf seinen Windows NT-Systemen festgelegt, aber diese Änderung erst nach Installation der DSClient-Erweiterung auf allen Windows 98-Systemen vorgenommen.

Aktualisieren der NTLM-Authentifizierung unter Windows 2000 und Windows Server 2003

Die IT-Administratoren bei Trey haben ein neues GPO auf den Domänencontrollern des Unternehmens erstellt, mit dem die NTLM-Authentifizierungsebene auf Computern und Domänencontrollern eingestellt wird, und haben es zur Organisationseinheit "Domänencontroller" hinzugefügt. Dies erfolgte durch Änderung der Einstellung Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen\LAN Manager-Authentifizierungsebene. Achten Sie darauf, die Domänencontroller-Richtlinie für Domänencontroller, die Domänen-Richtlinie für Active Directory-Mitglieder und die lokale Richtlinie für eigenständige Computer oder solche, die Mitglied von Windows NT-Domänen sind, zu verwenden.

Nachdem DSClient vollständig auf allen Windows 98-Systemen bereitgestellt wurde, empfiehlt sich, die LM-Authentifizierungsebene auf 3, 4 oder 5 einzustellen, wodurch LM-Authentifizierungen nicht mehr verwendet werden können. Bis dies geschehen ist, verlieren alle Systeme, auf denen frühere Windows-Versionen ohne DSClient ausgeführt werden, den Zugriff auf sämtliche Netzwerkdaten.

Da Trey u. a. über Windows 98-Clients verfügt, die alle die DSClient-Erweiterung aufweisen, wurde dieser Wert auf Windows NT-basierten Computern (Windows NT, Windows 2000 und Windows XP) auf 5 und auf Windows 98-Computern auf 3 gesetzt. Einstellungen höher als 3 auf Computern, auf denen Windows 98 nicht ausgeführt wird, verhindern ansonsten, dass für diese Computer ohne DSClient-Erweiterung Authentifizierungen durchgeführt werden können.

Informationen zu einem Hotfix, mit dem die Funktionsfähigkeit dieser Einstellung in Netzwerken sowohl mit Windows 2000- als auch mit Windows NT 4.0-Systemen sichergestellt wird, finden Sie im englischsprachigen Knowledge Base-Artikel 305379 ("Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain") unter http://support.microsoft.com/?kbid=305379.

Windows-Systeme erzeugen Kommunikationskanäle, die als sichere Kanäle bezeichnet und zur Authentifizierung von Computer- und Benutzerkonten in vertrauenswürdigen Domänen verwendet werden. Sichere Kanäle verhindern Man-in-the-Middle-Angriffe und ermöglichen es Clients, auf Kontodatenbanken in vertrauenswürdigen Domänen zuzugreifen. Sie können digital verschlüsselt oder signiert werden, es muss jedoch Windows NT 4.0 SP6a oder höher auf allen Domänencontrollern ausgeführt werden. Da sich das Signieren von sicheren Kanälen auf alle Clients in der Domäne sowie auf Clients in vertrauenden Domänen auswirkt, sollten Sie diese Funktion nicht leichtfertig aktivieren.

Festlegen geeigneter Kennwort- und Sperrungsrichtlinien

Ein grundlegendes Sicherheitsprinzip besteht in der Vermeidung der Übertragung oder Speicherung von Kennwörtern im Klartext. Ein Kennwort im Klartext ist leicht entschlüsselt, sei es durch Untersuchen des SAM oder durch Netzwerksniffing. Aktuelle Windows-Authentifizierungsprotokolle nutzen als Hashes bezeichnete Verschlüsselungsalgorithmen, die sämtliche Übertragungen von Authentifizierungsinformationen schützen und das Kennwort ab dem Zeitpunkt der Eingabe durch den Benutzer speichern. Es ist jedoch notwendig, Richtlinien zu definieren, mit denen die Länge und Sicherheit von Kennwörtern gesteuert und die zulässige Anzahl fehlgeschlagener Anmeldungsversuche vor Sperrung des entsprechenden Kontos festgelegt wird.

Das Security Guidance Kit von Microsoft enthält eine Reihe von Referenzdokumenten, die eine Hilfestellung bei der Auswahl und Implementierung sicherer Kennwort- und Kontosperrungsrichtlinien geben. Zusätzliche Hilfe ist im englischsprachigen Whitepaper "Account Passwords and Policies" unter http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx verfügbar.

Absichern des Dateisystems

Im Zusammenhang mit der Absicherung des Startvorgangs ist es erforderlich, die Sicherheit des Dateisystems und der Speichergeräte auf jedem Computer in der Organisation zu erhöhen, auf dem Windows NT 4.0 ausgeführt wird.

Der erste wichtige Schritt dabei besteht in der Sicherstellung, dass alle Windows NT 4.0-Computer das NTFS-Dateisystem verwenden. Zusätzlich zu den unter Windows NT, Windows 98 und deren Nachfolgern verfügbaren Berechtigungen auf Freigabe-Ebene bietet NTFS Datei- und Ordnerberechtigungen. Durch die Verwendung von NTFS-Berechtigungen wird die Fähigkeit von Benutzern eingeschränkt, auf einem Computer Dateien anderer Benutzer zu lesen, und Angreifern mit physischem Zugang zur Konsole wird das Stehlen oder Ändern von Daten ohne Starten eines alternativen Betriebssystems erschwert. Windows NT enthält einen Befehl, der verlustfrei FAT- bzw. FAT32-Datenträger (File Allocation Tables, Dateizuordnungstabellen) in NTFS konvertiert, wobei Exklusivzugriff auf den jeweiligen Datenträger erforderlich ist.

Bei der Konvertierung eines Datenträgers in NTFS mithilfe des Konvertierungshilfsprogramms wird die Standardberechtigung Jeder:Vollzugriff angewendet. Diese Berechtigung muss geändert werden, da sie einen zu umfangreichen Zugriff gewährt. Bei vorhandenen NTFS-Systemen könnte dies ebenso der Fall sein.

Die US-amerikanische National Security Agency (NSA) hat einen Satz von Berechtigungen ausgearbeitet, die für Windows NT-Server und -Arbeitsstationen empfohlen werden und im englischsprachigen Guide to Securing Microsoft Windows NT Networks veröffentlicht wurden. Diese Empfehlungen können manuell mit Skripts, die das Tool xcacls verwenden (eine Beschreibung dieses Tools finden Sie im Knowledge Base-Artikel 318754 ("So wird's gemacht: Verwenden von "Xcacls.exe" zum Ändern von NTFS-Berechtigungen") unter http://support.microsoft.com/?kbid=318754), oder durch Verwendung vordefinierter SCM-Vorlagen angewendet werden. Die Empfehlungen in den Kapiteln 11 und 13 des Handbuchs sind recht umfangreich, daher sollten Sie zu deren Implementierung unbedingt auf die detaillierten Anleitungen in dieser Publikation zurückgreifen.

Absichern von Diensten

Mehrere Konfigurationsänderungen, die das Sichern von Diensten und Konten betreffen, sind normalerweise für alle Windows NT-Umgebungen geeignet.

Eine der vielen Verbesserungen in Windows NT 4.0 SP3 besteht in der Erstellung der Sicherheitsgruppe "Authentifizierte Benutzer". Diese Gruppe dient als Ersatz für das Sicherheitsprinzipal "Jeder" in allen Bereichen, in denen Benutzer oder Prozesse unabhängig vom Authentifizierungsstatus nicht auf Dateien und Dienste zugreifen können sollen. Diese Gruppe sollte in jeder von Ihnen erstellten und verwalteten Zugriffssteuerungsliste (ACL) für Dateien ersetzt werden, sofern das Zulassen von anonymen Verbindungen nicht unbedingt erforderlich ist. Für die meisten Dienste sollte dies nicht notwendig sein. Bei IIS z. B. werden alle anonymen Anforderungen einem bestimmten Konto zugeordnet. Drittanwendungen sind jedoch genau zu testen, da für einige von ihnen die Gruppe "Jeder" erforderlich sein könnte.

Abgesehen von der Gruppe "Authentifizierte Benutzer" müssen Sie außerdem anonyme Verbindungen zur Registrierung deaktivieren und die Möglichkeit der Auflistung von Domänenbenutzerkonten und Freigaben auf Servern durch anonym angemeldete Benutzer anhand folgender Registrierungseinträge einschränken:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

RestrictAnonymous (REG_DWORD)

Durch den Wert 0 wird diese Einschränkung aufgehoben, und anonym angemeldete Benutzer (Nullsitzungen) können die Benutzer- und Freigabeliste auflisten.

Durch den Wert 1 wird diese Einschränkung wirksam; bei Nullsitzungen können Benutzer und Freigaben nicht aufgelistet werden.

RestrictNullSessAccess (REG_DWORD)

Durch den Wert 0 wird diese Einschränkung aufgehoben, und anonym angemeldete Benutzer (Nullsitzungen) können die Verbindung zur Registrierung herstellen.

Durch den Wert 1 wird diese Einschränkung wirksam; bei Nullsitzungen kann keine Verbindung zur Registrierung hergestellt werden.

Der Knowledge Base-Artikel 143474 ("Beschränken der Informationen, für anonym angemeldete Benutzer") unter http://support.microsoft.com/?kbid=143474 verdeutlicht die Verwendung der Gruppe der authentifizierten Benutzer in Verbindung mit manuellen Registrierungsbearbeitungen zur vollständigen Einschränkung anonymer Verbindungen zur Registrierung und Auflistungen der Benutzer- und Freigabenamen. Der Knowledge Base-Artikel 153183 ("So beschränken Sie den Zugriff auf die Registrierung von einem Remotecomputer aus") unter http://support.microsoft.com/?kbid=153183 enthält zusätzliche Informationen zur Einschränkung des Remotezugriffs auf die Registrierung für authentifizierte Benutzer.

Eine weitere wichtige Änderung, die vor allem auf Domänencontrollern vorzunehmen ist, besteht in der ordnungsgemäßen Sicherung des Verzeichnisreplikationsdiensts (Directory Replicator Service, DRS). Durch diesen Dienst kann der Inhalt von bestimmten Verzeichnissen auf mehrere Server repliziert werden. Er spielt für die korrekte Übertragung von Systemrichtlinien und anderen wichtigen Dateien auf alle Domänencontroller eine wichtige Rolle. Dies kann für die Verwaltung von Lastenausgleichs-Dateidiensten für wichtige Anwendungen äußerst nützlich sein.

Replikationsverbindungen werden auf dem Server-Manager für Domänen durch Klicken auf die Schaltfläche Replikation konfiguriert. Für jeden Replikationspartner gibt es einen Exporter (die Quelle) und einen Importer (das Ziel). Die Details für jede Partnerschaft müssen separat auf jeder Seite der Verbindung konfiguriert werden (ähnlich wie bei der Einrichtung von Vertrauensstellungen zwischen Domänen).

Standardmäßig wird für DRS das Konto "Lokales System" verwendet, was umgehend geändert werden sollte. Richten Sie ein separates Domänenbenutzerkonto speziell für die Nutzung durch DRS ein, das auf allen Computern verwendet wird. Verwenden Sie keine lokalen Konten. Nach erfolgter Kontoeinrichtung können Sie anhand des Dienst-Managers sicherstellen, dass DRS auf diesem Konto statt auf dem Konto "Lokales System" ausgeführt wird.

Viele Dienste werden standardmäßig aktiviert und lassen sich zur Reduzierung der Angriffsfläche eines Windows NT-Computers deaktivieren. Andere Computer wiederum können so konfiguriert werden, dass sie als nicht-privilegierte Konten anstelle des Kontos "Lokales System" ausgeführt werden. Weitere Informationen zur Sicherung von DRS und zur Deaktivierung nicht benötigter Dienste einschließlich detaillierter Empfehlungen für jeden Dienst auf Grundlage der jeweiligen Rolle eines Computers finden Sie in Kapitel 10 des englischsprachigen Handbuchs Microsoft NT 4.0 Security, Audit, and Control Technical Reference. Eine Voransicht dieses Handbuchs ist im Microsoft TechNet unter http://www.microsoft.com/technet/prodtechnol/winntas/maintain/nt4sac/sacch10.mspx verfügbar.

Weitere Absicherungsmaßnahmen

Es können weitere Absicherungsmaßnahmen für unterschiedliche Umgebungen geeignet sein.

Deaktivieren der automatischen Generierung von 8.3-Dateinamen

Windows NT unterstützt 8.3-Dateinamenformate zur Gewährleistung der Abwärtskompatibilität mit 16-Bit-Anwendungen. Bei der 8.3-Dateinamenkonvention handelt es sich um ein Namensformat, das bis zu acht Zeichen lange Dateinamen zulässt. Dadurch kann ein Angreifer durch Eingabe von nur acht Zeichen auf Dateien verweisen, die z. B. 20 Zeichen lang sind. Beispielsweise könnte auf die Datei Diesisteinlangerdateiname.doc anhand des 8.3-Dateinamens Diesis~1.doc verwiesen werden. Wenn Sie keine 16-Bit-Anwendungen verwenden, kann diese Funktion deaktiviert werden. Dadurch wird auf einer NTFS-Partition darüber hinaus die Leistung des Verzeichnisdiensts erhöht.

Angreifer können mithilfe der kurzen Dateinamen möglicherweise auf Datendateien und -anwendungen mit langen Dateinamen zugreifen, die anderenfalls schwer zu finden sind. Ein Angreifer, dem es bereits gelungen ist, auf das Dateisystem zuzugreifen, ist anschließend in der Lage, auf Daten zuzugreifen oder Anwendungen auszuführen.

Dies lässt sich anhand des folgenden Registrierungseintrags steuern: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

Mit den 16-Bit-Anwendungen in Ihrer Organisation kann nicht auf Dateien zugegriffen werden, deren Namenslänge über das 8.3-Format hinausgeht, sofern diese Dateien auf Computern gespeichert sind, auf denen diese Änderung vorgenommen wurde. Wenn diese Einstellung auf einem Server angewendet wird, auf dem bereits Dateien mit dem automatisch erstellten 8.3-Format vorliegen, werden die entsprechenden Dateinamen nicht gelöscht. Kopieren Sie zum Entfernen der vorhandenen 8.3-Dateinamen die entsprechenden Dateien in einen anderen Speicherort, löschen Sie die Dateien im ursprünglichen Speicherort auf dem Server, und kopieren Sie die Dateien anschließend wieder an den ursprünglichen Speicherort.

Deaktivieren von Autorun

Bei der automatischen Ausführung (Autorun) werden Daten von einem Laufwerk des Computers gelesen, sobald ein Medium eingelegt wird. Daher werden die Setupdatei von Programmen und die Wiedergabe von Audiomedien sofort gestartet. Über die Gruppenrichtlinie wird Autorun auf allen Laufwerken deaktiviert. Dadurch wird verhindert, dass beim Einlegen einer CD oder DVD ein bösartiges Programm gestartet wird.

Ein Angreifer mit physischem Zugang zum System könnte ein Medium mit Autorun-Funktion in den Computer einlegen, um etwa automatisch bösartigen Code zu starten, der innerhalb der Sitzung des aktuell angemeldeten Benutzers ausgeführt wird.

Dies lässt sich anhand des folgenden Registrierungseintrags steuern: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\CDROM\Autorun

Nach dieser Änderung wird die Autorun-Funktion beim Einlegen von Datenträgern mit Autorun-Funktion nicht mehr ausgeführt.

Entfernen von OS/2- und POSIX-Subsystemen

OS/2 ist eine Familie von Multitasking-Betriebssystemen im geschützten Modus mit virtuellem Arbeitspeicher von Microsoft, die für PCs mit Intel 80286- und Intel 80386-Prozessoren gedacht ist. Das POSIX-Subsystem (Portable Operating System Interface for UNIX) ist ein Standard des IEEE (Institute of Electrical and Electronic Engineers), durch das eine Gruppe von Betriebssystemdiensten festgelegt wird. Das OS/2-Subsystem ist im Fall von umfassenden Interaktionen zwischen Server und OS/2-Clients erforderlich. Das POSIX-Subsystem ist zum Ausführen von Anwendungen erforderlich, die POSIX-Dienste nutzen.

Diese Subsysteme gehen mit einem geringen Sicherheitsrisiko in Verbindung mit Prozessen einher, die möglicherweise über verschiedene Anmeldungen hinweg beibehalten werden. Das heißt, wenn ein Benutzer einen Prozess startet und sich anschließend abmeldet, ist es möglich, dass auf den Prozess vom nachfolgend angemeldeten Benutzer zugegriffen werden kann. Dabei kann der Prozess die Systemberechtigungen des ersten Benutzers beibehalten.

Um diese Subsysteme zu deaktivieren, können die folgenden für sie erforderlichen Binärdateien und Registrierungseinträge gelöscht werden:

der Registrierungsschlüssel und die Teilschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\OS/2 Subsystem for NT

der Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Session Manager\Environment\OS2LibPath

die POSIX- und OS/2-Teilschlüssel des Registrierungsschlüssels HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Control\SessionManager\Environment\Subsystems

das Verzeichnis \winnt\system32\os2 samt Unterverzeichnissen

Anwendungen, die auf den OS/2- oder POSIX-Subsystemen beruhen, werden nicht länger ausgeführt.

Erhöhen von Objektschutzebenen

Der Windows NT-Kernel erlaubt es Aufrufern unter Umständen, Attribute von Kernelobjekten unter verschiedenen Bedingungen zu ändern. In einigen Fällen können böswillige Aufrufer somit ihre Berechtigungen erweitern.

Dies lässt sich durch folgenden Registrierungseintrag steuern:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Session Manager\EnhancedSecurityLevel

Durch diese Änderung kann ausschließlich Kernelmodus-Code zur Änderung von Kernelobjektattributen für den aktuellen Prozess verwendet werden.

Dies hat keinerlei potenzielle Auswirkungen auf Benutzermodusanwendungen.

Benutzer am Hinzufügen von Druckertreibern hindern

Mit den standardmäßigen Berechtigungen unter Windows NT ist die Installation zusätzlicher Druckertreiber zulässig. In einigen Fällen ist es daher möglich, dass Berechtigungen durch bösartige oder fehlerhafte Treiber erweitert werden.

Dies lässt sich durch folgenden Registrierungseintrag steuern:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Print\Providers\LanMan Print Services
\Servers\AddPrinterDrivers

Durch diese Änderung können ausschließlich Mitglieder der Druckoperatoren- und Administratorengruppen neue Druckertreiber hinzufügen.

Dies hat keinerlei potenzielle Auswirkungen auf Benutzermodusanwendungen.

Bestätigen der Deaktivierung der automatischen Administratoranmeldung

Windows NT kann so konfiguriert werden, dass das Administratorkonto nach einem Neustart des Computers automatisch angemeldet wird. Dadurch wird die Konsole geöffnet und ein neuer Registrierungsschlüssel erstellt, der das Administratorkennwort im Klartext enthält. Weitere Einzelheiten zu dieser Einstellung finden Sie im Knowledge Base-Artikel 97597 ("Aktivieren der automatischen Anmeldung in Windows NT 3.x und 4.0") unter http://support.microsoft.com/?kbid=97597.

Dies lässt sich durch folgende Registrierungseinträge steuern:

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT
\CurrentVersion\Winlogon\AutoAdminLogon

HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT
\CurrentVersion\Winlogon\DefaultPassword

Dies hat keinerlei potenzielle Auswirkungen auf Benutzermodusanwendungen.

Deaktivieren von Benachrichtigungen an den Novell-Client

Windows NT ist standardmäßig so konfiguriert, dass der Novell-Netzwerkclient (FPNWCLNT.DLL) bei Änderung von Kennwörtern benachrichtigt wird. Sofern der Client nicht installiert ist, wird jedoch keine Kopie dieser DLL (Dynamic Link Library) installiert. Dadurch erhalten Angreifer die Möglichkeit, eine Ersatz-DLL zu erstellen und sämtliche vorgenommenen Benutzerkennwortänderungen zu übernehmen.

Um dies auszuschließen, vergewissern Sie sich, dass sich der Wert "FPNWCLNT" nicht im Registrierungseintrag HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\LSA\Notification Packages befindet.

Die Kennwortsynchronisierung zwischen Windows und Netware ist in Umgebungen, in denen Netware verwendet wird, deaktiviert.

Implementierung

Implementierungsvoraussetzungen

Um die korrekte Funktionsfähigkeit dieser Implementierung zu gewährleisten, muss eine grundlegende Trey Research-Infrastruktur implementiert worden sein, wie in Kapitel 2, "Anwenden von SRMD (Security Risk Management Discipline) auf das Beispiel von Trey Research" beschrieben.

Implementierungsübersicht

Zur Implementierung dieses Lösungsszenarios müssen die folgenden Aktivitäten durchgeführt werden:

Einrichten einer Basis und Versehen des Betriebssystems mit Patches

Aktivieren von Syskey

Verringern der Anzeigedauer des Systemstartmenüs

Installieren des SCM

Laden des Snap-In für den SCM

Anwenden der Trey-Richtlinienvorlage

Verhindern der Speicherung von LM-Kennwort-Hashwerten

Festlegen der NTLM-Authentifizierungsebene

Konvertieren der Serverdatenträger in NTFS

Durchführen weiterer Absicherungsmaßnahmen

Einrichten einer Basis für das Betriebssystem

Jedes Mal, wenn ein neuer Computer eingerichtet oder das Betriebssystem in einem vorhandenen System neu installiert wird, müssen die korrekten Sicherheitspatches zur Gewährleistung eines angemessenen Schutzes für den Computer installiert werden. Die Patchverwaltung stellt ein komplexes Thema dar, auf das in Kapitel 6 ("Patchverwaltung") genauer eingegangen wird. Die Basislinieneinrichtung für neue Systeme ist jedoch ein unverzichtbarer Teil der Sicherung von Computern, auf denen Windows NT ausgeführt wird. Auf jedem Computer in Ihrer Organisation, auf dem Windows NT ausgeführt wird, sollten die folgenden Patches installiert werden:

Service Pack 6a (SP6a) für Windows NT 4.0, das aktuellste Service Pack für Windows NT 4.0. Es enthält einen umfassenden und regressionsgetesteten Satz von Patches, die als eine Einheit zu installieren sind. Seit der Veröffentlichung von Windows NT 4.0 SP6a hat sich die US-amerikanische Gesetzgebung hinsichtlich des Exports von Verschlüsselungssoftware geändert. Sie können die für Ihre Windows NT 4.0-Computer verfügbare Verschlüsselungsstärke u. U. erhöhen, indem Sie auf die Version von SP6a mit starken Verschlüsselungschlüsseln aktualisieren. Durch deren Installation auf einer Version mit Standardverschlüsselungsstärke wird das Betriebssystem automatisch aktualisiert. Windows NT 4.0 Service Pack 6a finden Sie unter http://www.microsoft.com/ntserver/nts/downloads/recommended/sp6/128bitx86/.

So überprüfen Sie die Verschlüsselungsversion von Windows NT 4.0

1.

Melden Sie sich als Administrator beim Zielcomputer an, auf dem Windows NT 4.0 ausgeführt wird.

2.

Öffnen Sie in Windows Explorer den Ordner \winnt\system32.

3.

Markieren Sie die Datei schannel.dll, und klicken Sie danach auf Datei und Eigenschaften.

4.

Klicken Sie auf die Registerkarte Version.

5.

Betrachten Sie den Inhalt im Feld Beschreibung.

"Export Version" steht für die Version mit Standardverschlüsselungsstärke, während "U.S. domestic version" auf die Version mit hoher Verschlüsselungsstärke hinweist.

Das Sicherheits-Rollup-Paket (SRP) nach dem Windows NT 4.0 Service Pack 6a umfasst mehrere Patches, die nach SP6a veröffentlicht wurden und eine Voraussetzung für nachfolgende Patches auf Windows Update sind. Dies wird im Knowledge Base-Artikel 299444 ("Security Rollup Package nach Windows NT 4.0 Service Pack 6a") unter http://support.microsoft.com/?kbid=299444 dokumentiert. Das Sicherheits-Rollup-Paket selbst kann unter http://download.microsoft.com/download/winntsp/Patch/q299444/NT4/EN-US/Q299444i.exe heruntergeladen werden.

Microsoft hat seit Veröffentlichung des SRP kein integriertes SRP oder Service Pack für Windows NT 4.0 herausgebracht, jedoch wurden einzelne Komponenten, z. B. Teile des Betriebssystems, Internet Explorer sowie Add-On-Dienstprogramme wie der Routing- und RAS-Dienst (RRAS) und die Internetinformationsdienste (IIS) aktualisiert. Eine aktuelle Liste der Patches ist von Microsoft TechNet erhältlich. Sie können auch die auf Windows Update verfügbare Liste der Patches zu Rate ziehen.

Internet Explorer 6.0 Service Pack 1 (SP1) ist die aktuellste Version, die unter http://www.microsoft.com/windows/ie/ erhältlich ist. Sie enthält hunderte von Sicherheitsupdates und Verbesserungen. Je nach vorliegender Umgebung können Sie Internet Explorer direkt von der Microsoft-Website herunterladen, auf CD-ROM bestellen oder mithilfe des Internet Explorer Administration Kit (erhältlich unter http://www.microsoft.com/windows/ieak/) auf mehreren Computern installieren.

Da bereits einige Zeit seit der Veröffentlichung von Windows NT vergangen ist, hat die IT-Abteilung von Trey SP6a und das SRP auf sämtliche Computer angewendet, auf denen Windows NT ausgeführt wird. Es lag jedoch keine einheitliche Richtlinie zur Sicherstellung der Anwendung weiterer erforderlicher Patches von Microsoft vor, was das Unternehmen dazu veranlasste, das in Kapitel 6 ("Patchverwaltung") beschriebene Patchverwaltungsverfahren zu übernehmen.

Aktivieren von Syskey

Zur Nutzung des verschlüsselten Schutzes des Computer-SAM muss Syskey aktiviert werden. Trey hat sich für die Anwendung dieses Schutzes auf sämtliche Computer, sowohl Server als auch Arbeitsstationen, auf denen Windows NT ausgeführt wird, entschieden.

So aktivieren Sie Syskey

1.

Melden Sie sich als Administrator beim Zielcomputer an, auf dem Windows NT 4.0 ausgeführt wird.

2.

Starten Sie das Dienstprogramm Rdisk.exe von einer Eingabeaufforderung oder durch Verwendung des Befehls Run.

3.

Klicken Sie nach dem Start von Rdisk auf die Schaltfläche Aktualisieren und danach bei Aufforderung auf Ja.

4.

Legen Sie nach Abschluss der Reparaturinformationsaktualisierung eine leere Diskette in das Diskettenlaufwerk ein, und klicken Sie anschließend im Dialogfeld Programm zur Erstellung der Notfalldiskette auf Ja.

5.

5. Klicken Sie auf OK, um zu bestätigen, dass eine Notfalldiskette erstellt werden soll.

6.

Klicken Sie nach Abschluss der Diskettenerstellung erneut auf OK, um die Kenntnisnahme der Sicherheitswarnung zu bestätigen. Klicken Sie danach auf Beenden, um das Dienstprogramm Rdisk zu schließen.

7.

Starten Sie das Dienstprogramm Syskey.exe.

8.

Klicken Sie bei Anzeige des Fensters zur Sicherung der Windows NT-Kontodatenbank auf die Schaltfläche Verschlüsselung aktiviert und anschließend auf OK.

9.

Klicken Sie im Bestätigungsdialogfeld auf OK.

10.

Klicken Sie im Dialogfeld Kennwort für die Benutzerkontendatenbank auf Kennwort für den Systemstart lokal speichern (s. Abb. 4.1) und anschließend auf OK.

11.

Klicken Sie im Dialogfeld Erfolg auf OK.

12.

Starten Sie den Computer neu.

Hinweis: Auf Domänencontrollern sind die von Rdisk erfassten Wiederherstellungsdaten womöglich zu umfangreich für eine einzelne Diskette, sie werden jedoch auch im Verzeichnis %systemroot%\repair gespeichert. Mit einer aktuellen Notfalldiskette ist eine umgehende Wiederherstellung bei Problemen im Zusammenhang mit Syskey möglich. Eine ausführlichere Beschreibung des Befehls Rdisk /s finden Sie im Knowledge Base-Artikel 122857 ("Optionen "RDISK /S" und "RDISK /S-" in Windows NT") unter http://support.microsoft.com/?kbid=122857.

Hinweis: Weitere Informationen dazu, wie Syskey SAM-Daten vor Angriffen schützt, finden Sie im Knowledge Base-Artikel 143475 ("Windows NT-Systemschlüssel erlaubt starke Verschlüsselung des SAM") unter http://support.microsoft.com/?kbid=143475.

Verringern der Anzeigedauer des Systemstartmenüs

Im Folgenden wird beschrieben, wie sich die Anzeigedauer des Systemstartmenüs ändern lässt.

So verringern Sie die Anzeigedauer des Systemstartmenüs

1.

Öffnen Sie als Administrator eine Eingabeaufforderung.

2.

Wechseln Sie zum Stammverzeichnis des Systemdatenträgers (normalerweise C:\).

3.

Setzen Sie die Attribute "Schreibgeschützt", "Versteckt" und "System" für die Datei Boot.ini mit dem Befehl attrib zurück:

attrib –s –h –r boot.ini

4.

Öffnen Sie die Datei Boot.ini in einem Texteditor, z. B. im Editor.

5.

Ersetzen Sie in der Zeile timeout=30 den timeout-Wert durch 0.

6.

Speichern Sie die Datei, und schließen Sie den Texteditor.

7.

Setzen Sie die Attribute "Schreibgeschützt", "Versteckt" und "System" für die Datei Boot.ini mit dem Befehl attrib zurück:

attrib +s +h +r boot.ini

Installieren des SCM

Im Folgenden wird beschrieben, wie die SCM-Tools installiert werden. Der SCM kann auf jedem Computer ausgeführt werden, auf dem die Server Edition oder Workstation Edition von Windows NT 4.0 SP4 oder höher ausgeführt wird. Die IT-Abteilung bei Trey hat der Einfachheit halber den SCM auf ihren eigenen Arbeitsstationen installiert, von wo er auf jeden beliebigen Computer in ihrer Domäne mit Windows NT 4.0 angewendet werden kann.

So installieren Sie den SCM

1.

Öffnen Sie als Administrator Windows Explorer.

2.

Erstellen Sie das Verzeichnis c:\temp, sofern es nicht bereits vorhanden ist.

3.

Laden Sie die SCM-Installationsdatei unter http://www.microsoft.com/ntserver/nts/downloads/recommended/scm/default.asp herunter und speichern Sie sie unter C:\Temp.

4.

Doppelklicken Sie im Ordner C:\Temp auf die Anwendungsdatei Scesp4i.exe.

5.

Geben Sie bei Aufforderung durch das Installationsdienstprogramm den temporären Dateipfad C:\Temp\scminstall an, in dem die Supportdateien dekomprimiert werden, und klicken Sie danach auf OK.

6.

Öffnen Sie im Explorer den Pfad C:\Temp\scminstall.

7.

Doppelklicken Sie auf das Dienstprogramm Mssce, um das SCE- und das MMC-Tool (Microsoft Management Console), das für die Benutzeroberflächenversion von SCE erforderlich ist, zu installieren. Das Installationsprogramm legt die SCM-Komponenten automatisch am korrekten Speicherort auf dem Computer ab, auf dem die Installation erfolgt.

Laden des Snap-In für den SCM

Nach erfolgter Installation des SCM auf einer Arbeitsstation oder einem Server kann das Programm ausgeführt werden. Im Folgenden wird das Laden des Snap-In für SCM in die MMC erläutert.

So laden Sie den Snap-In für den SCM

1.

Melden Sie sich als Administrator bei einem Computer an, auf dem zuvor der SCM installiert wurde.

2.

Starten Sie die MMC.

3.

Wählen Sie Konsole und danach Snap-In hinzufügen/entfernen aus.

4.

Klicken Sie auf Hinzufügen.

5.

Wählen Sie Manager für Sicherheitskonfigurationen aus.

6.

Klicken Sie auf OK und dann erneut auf OK.

Anwenden der Trey-Richtlinienvorlage

Im Folgenden wird die Verwendungsweise der SCE-Benutzeroberfläche und der Tools der Befehlszeilenoberfläche zur Anwendung der Trey-Richtlinienvorlagen beschrieben. Trey hat sich für die Verwendung der Comp*-Vorlagen entschieden, da sie den besten Ausgleich zwischen Rückwärtskompatibilität und Sicherheit bieten.

So passen Sie die Richtlinienvorlage von der SCE-Benutzeroberfläche aus an

1.

Melden Sie sich bei einer Windows NT 4.0-Testarbeitsstation an.

2.

Fertigen Sie Sicherungskopien von %systemroot%\security\templates\compws4.inf und %systemroot%\security\templates\compdc4.inf an.

3.

Öffnen Sie %systemroot%\security\templates\compws4.inf im Editor.

4.

Gehen Sie zu der Zeile, die "MACHINE\System\CurrentControlSet\Services\Rdr\Parameters\EnableSecuritySignature" enthält.

5.

Ersetzen Sie in dieser Zeile den Wert für EnableSecuritySignature durch 1.

6.

Speichern Sie die Datei, und beenden Sie den Editor.

7.

Öffnen Sie %systemroot%\security\templates\compdc4.inf im Editor.

8.

Wiederholen Sie die Schritte 4 bis 6 für die neue Datei.

So wenden Sie die Richtlinienvorlage von der SCE-Benutzeroberfläche aus an

1.

Laden Sie als Administrator den Manager für Sicherheitskonfigurationen.

2.

Wählen Sie den Knoten Security Configuration Manager (Manager für Sicherheitskonfigurationen) aus.

3.

Wählen Sie den Knoten Configurations (Konfigurationen) aus.

4.

Wählen Sie zur Anzeige der Konfigurationsvorlagen das standardmäßige Konfigurationsdateiverzeichnis aus (%systemroot%\security\templates).

5.

Wählen Sie die passende Konfigurationsdatei aus (compws4.inf oder compdc4.inf).

6.

Machen Sie sich mit den verschiedenen Objekten und Einstellungen in der Richtlinienvorlage vertraut.

7.

Wählen Sie den Knoten Security Configuration Manager (Manager für Sicherheitskonfigurationen) aus.

8.

Klicken Sie mit der rechten Maustaste auf den Knoten Database (Datenbank), und wählen Sie Import Configuration (Konfiguration importieren).

9.

Wählen Sie die entsprechende Richtlinienvorlage aus, und klicken Sie danach auf OK.

10.

Klicken Sie mit der rechten Maustaste auf den Knoten Database (Datenbank), und wählen Sie Configure System Now (System jetzt konfigurieren).

11.

Klicken Sie auf OK, um den Standardpfad zur Protokolldatei zu akzeptieren.

12.

Warten Sie, bis die Richtlinie angewendet wurde, und überprüfen Sie danach die Ergebnisse in der Protokolldatei.

13.

Schließen Sie die Protokolldatei.

14.

Schließen Sie die MMC.

So wenden Sie die Richtlinienvorlage von der Eingabeaufforderung aus an

1.

Melden Sie sich beim Zielcomputer an.

2.

Öffnen Sie die Eingabeaufforderung.

3.

Führen Sie folgenden Befehl aus:

secedit /configure /cfg c:\winnt\security\templates\treysec.inf /overwrite

4.

Untersuchen Sie die Ergebnisse.

5.

Schließen Sie die Eingabeaufforderung.

Verhindern der Speicherung von LM-Kennwort-Hashwerten

Im Folgenden wird beschrieben, wie Domänencontroller anhand von Richtlinien oder direkter Registrierungsbearbeitungen zur Verhinderung der Speicherung von LM-Kennwort-Hashwerten konfiguriert werden.

So verhindern Sie die Speicherung von LM-Hashwerten durch Verwendung von Gruppenrichtlinien oder lokalen Richtlinien unter Windows 2000 SP2 oder höher, Windows XP oder Windows Server 2003

1.

Öffnen Sie den Gruppenrichtlinien-Editor.

2.

Erweitern Sie Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen und Lokale Richtlinien, und klicken Sie danach auf Sicherheitsoptionen.

3.

Doppelklicken Sie in der Liste der verfügbaren Richtlinien auf Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern.

4.

Klicken Sie auf Aktiviert und anschließend auf OK.

5.

Starten Sie den Computer neu, und ändern Sie dann Ihr Kennwort.

Festlegen der NTLM-Authentifizierungsebene

Im Folgenden wird beschrieben, wie die Ebene der in den Domänencontrollern verwendeten NTLM-Authentifizierung konfiguriert wird.

So legen Sie die NTLM-Ebene anhand von Gruppenrichtlinien unter Windows 2000, Windows XP oder Windows Server 2003 fest

1.

Melden Sie sich als Administrator bei einem Domänencontroller an.

2.

Öffnen Sie Active Directory-Benutzer und -Computer.

3.

Öffnen Sie den Gruppenrichtlinien-Editor.

4.

Klicken Sie mit der rechten Maustaste auf die Domäne, auf die Sie die Einstellung für die NTLM-Authentifizierungsebene anwenden möchten, und klicken Sie auf Eigenschaften.

5.

Klicken Sie im Dialogfeld Eigenschaften auf die Registerkarte Gruppenrichtlinie.

6.

Klicken Sie zur Erstellung eines neuen Gruppenrichtlinienobjekts auf Neu.

7.

Geben Sie NTLM-Authentifizierungsebene ein, und drücken Sie die EINGABETASTE.

8.

Klicken Sie auf die Schaltfläche Bearbeiten.

9.

Erweitern Sie Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen und Lokale Richtlinien, und klicken Sie danach auf Sicherheitsoptionen.

10.

Doppelklicken Sie in der Liste der verfügbaren Richtlinien auf Netzwerksicherheit: LAN Manager-Authentifizierungsebene.

11.

Wählen Sie Nur NTLMv2-Antworten senden\LM verweigern aus, was den besten Ausgleich zwischen Sicherheit und Kompatibilität bei gemischten Netzwerken mit Windows 98- und Windows NT-Computern bietet.

12.

Klicken Sie auf OK.

13.

Schließen Sie den Gruppenrichtlinien-Editor.

14.

Klicken Sie im Dialogfeld Eigenschaften der Domäne mit der rechten Maustaste auf das Gruppenrichtlinienobjekt der NTLM-Authentifizierungsebene, und wählen Sie danach den Befehl Kein Vorrang aus.

15.

Klicken Sie auf Schließen.

So legen Sie die NTLM-Ebene anhand von Registrierungseinträgen unter Windows NT 4.0 SP3 oder höher fest

1.

Starten Sie den Registrierungs-Editor (Regedt32.exe).

2.

Gehen Sie zu folgendem Schlüssel und klicken Sie darauf: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Lsa

3.

Klicken Sie im Menü Bearbeiten auf Wert hinzufügen.

4.

Wählen Sie als Datentyp die Option DWORD-Wert aus.

5.

Geben Sie als WertnameLMCompatibilityLevel ein, und klicken Sie danach auf OK.

6.

Geben Sie unter Daten den Wert 3 (oder eine andere gewünschte Ebene) als Dezimalwert ein.

7.

Beenden Sie den Registrierungs-Editor.

8.

Starten Sie den Computer neu.

So legen Sie die NTLM-Ebene anhand von Registrierungseinträgen unter Windows 98 fest

1.

Starten Sie den Registrierungs-Editor (Regedit.exe).

2.

Gehen Sie in der Registrierung zu folgendem Teilschlüssel, und wählen Sie ihn aus:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control.

3.

Zeigen Sie im Menü Bearbeiten auf Neu, und klicken Sie auf Schlüssel.

4.

Geben Sie Lsa ein, und drücken Sie danach die EINGABETASTE.

5.

Zeigen Sie im Menü Bearbeiten auf Neu, und klicken Sie auf DWORD-Wert.

6.

Geben Sie LMCompatibilityLevel ein, und drücken Sie danach die EINGABETASTE.

7.

Klicken Sie im Menü Bearbeiten auf Wert hinzufügen, und fügen Sie dann den folgenden Registrierungswert hinzu:

Wertname: LMCompatibility

Datentyp: REG_DWORD

Wert: 3

8.

Beenden Sie den Registrierungs-Editor.

9.

Starten Sie den Computer neu.

Konvertieren eines Datenträgers in NTFS

Im Folgenden wird die Konvertierung eines FAT-Datenträgers in NTFS erläutert.

So konvertieren Sie einen FAT-Datenträger in NTFS

1.

Öffnen Sie als Administrator eine Eingabeaufforderung.

2.

Legen Sie mit dem Befehl convert fest, welches Laufwerk zu konvertieren ist:

convert d: /fs:ntfs

3.

Starten Sie das System bei Aufforderung neu, damit das Konvertierungsdienstprogramm Exklusivzugriff auf das ausgewählte Laufwerk erhält.

Ein Neustart ist erforderlich beim Konvertieren der Systempartition, des Datenträgers mit dem aktuellen Arbeitsverzeichnis für den Befehlsinterpreter oder eines Datenträgers, auf dem Anwendungen geöffnete Dateien verwenden.

Hinweis: Der Knowledge Base-Artikel 214579 ("Konvertieren einer Partition in NTFS mit "Convert.exe"") unter http://support.microsoft.com/?kbid=214579 enthält eine ausführlichere Beschreibung des Befehls convert und seiner Anwendung.

Durchführen weiterer Absicherungsmaßnahmen

Im Folgenden werden die zur Implementierung weiterer Absicherungsmaßnahmen erforderlichen Schritte erläutert.

Deaktivieren der automatischen Generierung von 8.3-Dateinamen

Mit diesem Verfahren wird die automatische Generierung von Dateinamen im 8.3-Format für 16-Bit-Anwendungen deaktiviert.

So deaktivieren Sie die Generierung von 8.3-Dateinamen

1.

Starten Sie den Registrierungs-Editor (Regedt32.exe).

2.

Gehen Sie zu folgendem Schlüssel und klicken Sie darauf: HKEY_LOCAL_MACHINE\System\CurrentControlSet
\Control\FileSystem

3.

Sollte der Wert NtfsDisable8dot3NameCreation nicht vorhanden sein, klicken Sie im Menü Bearbeiten auf Wert hinzufügen, geben Sie NtfsDisable8dot3NameCreation ein und vergewissern Sie sich, dass er den Typ "REG_DWORD" aufweist. Drücken Sie danach die EINGABETASTE.

4.

Markieren Sie den Wert NtfsDisable8dot3NameCreation.

5.

Klicken Sie im Menü Bearbeiten auf Ändern.

6.

Geben Sie 1 (oder die gewünschte Ebene) ein, und klicken Sie danach auf OK.

7.

Beenden Sie den Registrierungs-Editor.

Hinweis: Trey verfügt über einige 16-Bit-Anwendungen, deren normale Ausführbarkeit gewährleistet bleiben muss. Diese Anwendungen werden jedoch nur auf einem Teil der Computer in der Domäne ausgeführt. Die Änderung wurde auf alle Datei- und Druckserver angewendet. Außerdem wurde sie auf ausgewählte Mitgliedsserver und Arbeitsstationen angewendet, auf denen keine 16-Bit-Anwendungen ausgeführt werden.

Deaktivieren von Autorun

Mit diesem Verfahren wird die Autorun-Funktion für CD-ROM-Laufwerke deaktiviert.

So deaktivieren Sie Autorun

1.

Starten Sie den Registrierungs-Editor (Regedt32.exe).

2.

Gehen Sie zu folgendem Schlüssel und klicken Sie darauf: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\CDROM

3.

Klicken Sie im Menü Bearbeiten auf Wert hinzufügen.

4.

Geben Sie Autorun ein, und vergewissern Sie sich, dass der Wert den Typ "REG_DWORD" aufweist. Drücken Sie danach die EINGABETASTE.

5.

Klicken Sie im Menü Bearbeiten auf Ändern.

6.

Geben Sie 0 (oder die gewünschte Ebene) ein, und klicken Sie danach auf OK.

7.

Beenden Sie den Registrierungs-Editor.

Entfernen von OS/2- und POSIX-Subsystemen

Mit diesem Verfahren werden die OS/2- und POSIX-Kompatibilitätssubsysteme deaktiviert.

So deaktivieren Sie OS/2 und POSIX

1.

Starten Sie den Registrierungs-Editor (Regedt32.exe).

2.

Gehen Sie zu folgendem Schlüssel und löschen Sie ihn: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\SessionManager\Environment\OS2LibPath

3.

Sofern der Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Session Manager\Subsystems vorhanden ist, löschen Sie dessen OS/2- und POSIX-Teilschlüssel.

4.

Sofern der Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Session Manager\Environment\Subsystems vorhanden ist, löschen Sie dessen POSIX- und OS/2-Teilschlüssel (falls vorhanden).

5.

Gehen Sie zu folgendem Schlüssel und löschen Sie ihn: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\OS/2 Subsystem for NT

6.

Beenden Sie den Registrierungs-Editor.

7.

Öffnen Sie Windows Explorer.

8.

Löschen Sie das Verzeichnis \winnt\system32\os2 sowie sämtliche Unterverzeichnisse.

9.

Starten Sie den Computer neu.

Erhöhen von Objektschutzebenen

Mit diesem Verfahren werden die Schutzebenen für Kernelobjekte erhöht.

So erhöhen Sie Objektschutzebenen

1.

Starten Sie den Registrierungs-Editor (Regedt32.exe).

2.

Gehen Sie zu folgendem Schlüssel und klicken Sie darauf: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Control\Session Manager

3.

Klicken Sie im Menü Bearbeiten auf Wert hinzufügen.

4.

Geben Sie EnhancedSecurityLevel ein, und vergewissern Sie sich, dass der Wert den Typ "REG_DWORD" aufweist. Drücken Sie danach die EINGABETASTE.

5.

Klicken Sie im Menü Bearbeiten auf Ändern.

6.

Geben Sie 1 (oder die gewünschte Ebene) ein, und klicken Sie danach auf OK.

7.

Beenden Sie den Registrierungs-Editor.

Benutzer am Hinzufügen von Druckertreibern hindern

Mit diesem Verfahren wird verhindert, dass normale Benutzer Druckertreiber hinzufügen können.

So verhindern Sie das Hinzufügen von Druckertreibern durch normale Benutzer

1.

Starten Sie den Registrierungs-Editor (Regedt32.exe).

2.

Gehen Sie zu folgendem Schlüssel und klicken Sie darauf: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers

3.

Klicken Sie im Menü Bearbeiten auf Wert hinzufügen.

4.

Geben Sie AddPrinterDrivers ein, und vergewissern Sie sich, dass der Wert den Typ "REG_DWORD" aufweist. Drücken Sie danach die EINGABETASTE.

5.

Klicken Sie im Menü Bearbeiten auf Ändern.

6.

Geben Sie 1 (oder die gewünschte Ebene) ein, und klicken Sie danach auf OK.

7.

Beenden Sie den Registrierungs-Editor.

Bestätigen der Deaktivierung der automatischen Administratoranmeldung

Mit diesem Verfahren wird die automatische Anmeldung des Administratorkontos deaktiviert.

So deaktivieren Sie die automatische Administratoranmeldung (die standardmäßig nicht aktiviert ist)

1.

Starten Sie den Registrierungs-Editor (Regedt32.exe).

2.

Gehen Sie zu folgendem Schlüssel und klicken Sie darauf: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

3.

Klicken Sie auf folgenden Wert, sofern vorhanden: AutoAdminLogon.

4.

Klicken Sie im Menü Bearbeiten auf Ändern.

5.

Geben Sie 0 (oder die gewünschte Ebene) ein, und klicken Sie danach auf OK.

6.

Löschen Sie den Wert DefaultPassword, sofern vorhanden.

7.

Beenden Sie den Registrierungs-Editor.

Deaktivieren von Benachrichtigungen für den Novell-Client

Mit diesem Verfahren wird die automatische Benachrichtigung über Kennwortänderungen an den Novell-Netzwerkclient deaktiviert.

So deaktivieren Sie die standardmäßigen Kennwortänderungsbenachrichtigungen an den Novell-Client

1.

Starten Sie den Registrierungs-Editor (Regedt32.exe).

2.

Gehen Sie zu folgendem Schlüssel und klicken Sie darauf: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3.

Klicken Sie auf folgenden Wert: Notification Packages.

4.

Klicken Sie im Menü Bearbeiten auf Ändern.

5.

Vergewissern Sie sich, dass der Wert FPNWCLNT nicht aufgeführt wird, und klicken Sie anschließend auf OK.

6.

Beenden Sie den Registrierungs-Editor.

Testen der Lösung

Nach erfolgter Implementierung des Trey-Szenarios können Sie überprüfen, ob sie Ihren Anforderungen gerecht wird.

Überprüfung

Anhand der Informationen in der folgenden Tabelle können Sie das Trey-Szenario testen und den Erfolg der Umsetzung dieses Leitfadens überprüfen.

Tabelle 4.2: Überprüfungstests

BeschreibungTestschritteErwartetes Ergebnis

Überprüfen der Installation von Internet Explorer 6 SP1

Starten Sie Internet Explorer. Klicken Sie im Menü ? auf Info.

Die Version sollte 6.0.2800.xxxx lauten.

Überprüfen der Installation von Windows NT 4.0 (SP6a)

Führen Sie die Windows NT-Diagnose in der Gruppe "Verwaltung" aus, und öffnen Sie die Registerkarte Version.

Die Versionsinformationen sollten SP6a aufweisen.

Überprüfen der Startsequenz

In Modus 1 (Systemstartschlüssel wird für die meisten Server und alle Arbeitsstationen von Trey lokal gespeichert).

Beim Systemstart wird der Schlüssel entschlüsselt und geladen, wodurch der Computer ohne Administratoreingriff neu gestartet werden kann.

In Modus 2 (Schaltfläche Kennwort für den Systemstart und zugehörige Textfelder – für hochwertige Server).

Beim Systemstart muss der Administrator diesen Kennsatz in der Konsole eingeben.

Die Anmeldung durch den Client ist erfolgreich.

Überprüfen der erfolgreichen DSClient-Installation

Klicken Sie auf Start, danach auf Suchen und anschließend auf Nach Personen.

Wenn Active Directory durchsucht werden kann, wurde DSClient erfolgreich installiert.

Überprüfen der Systemrichtlinien

Versuchen Sie auf Ressourcen zuzugreifen, die durch Systemrichtlinien eingeschränkt wurden.

Überprüfen Sie den Speicherort der Systemrichtlinien (normalerweise im Ordner C:\Winnt\system32\repl\import\scripts).

Sie können nicht auf verbotene Ressourcen zugreifen.

Systemrichtlinien sollten am angegebenen Speicherort verfügbar sein.

Überprüfen der NTLMv2-Authentifizierung

Richten Sie für den Domänencontroller die NTLMv2-Authentifizierung ein.

Die Anmeldung durch den Client ist erfolgreich.

Überprüfen des Managers für Sicherheitskonfigurationen

Erstellen Sie die Sicherheitsvorlagen und wenden Sie sie automatisch auf einen oder mehrere Computer in einer Domäne an.

Überprüfen Sie den Vorlagensatz im Ordner %winnt%\security\templates.

Sie sind in der Lage, die Mitgliedsserver und Arbeitsstationen zu sichern.

Vorlagen sollten am angegebenen Speicherort verfügbar sein.

Überprüfen der Erstellung langer Dateinamen

Erstellen Sie eine neue Datei mit einem Namen, der länger als das 8.3-Format ist.

Sie können nicht mit dem 8.3-Format auf die Datei zugreifen.

Überprüfen der Autorun-Funktion

Legen Sie Datenträger mit Autorun-Funktion in Laufwerke des Computers ein.

Die Autorun-Funktion wird beim Einlegen von Datenträgern mit Autorun-Funktion nicht mehr ausgeführt.

Überprüfen, dass Anwendungen, die auf den OS/2- oder POSIX-Subsystemen beruhen, nicht länger ausgeführt werden

Ein Benutzer startet einen Prozess und meldet sich anschließend ab. Es ist möglich, dass auf den Prozess vom nachfolgend angemeldeten Benutzer zugegriffen werden kann.

Anwendungen, die auf den OS/2- oder POSIX-Subsystemen beruhen, werden nicht länger ausgeführt.

Überprüfen der Objektschutzebenen

Böswillige Benutzer versuchen, die Attribute von Kernelobjekten unter verschiedenen Bedingungen zu ändern.

Das System sollte es böswilligen Aufrufern nicht erlauben, ihre Berechtigungen zu erweitern.

Benutzer am Hinzufügen von Druckertreibern hindern

Böswillige Benutzer versuchen, ihre Berechtigungen durch Hinzufügen einiger Druckertreiber zu erweitern.

Mitglieder der Druckoperatoren- und Administratorengruppen können neue Druckertreiber hinzufügen.

Überprüfen der Deaktivierung der automatischen Administratoranmeldung

Versuchen Sie, sich beim Neustart des Computers automatisch als Administrator anzumelden.

Die automatische Administratoranmeldung sollte deaktiviert sein.

Überprüfen der Anzeigedauer des Systemstartmenüs

Starten Sie den Computer neu und überprüfen Sie die Anzeigedauer des Systemstartmenüs.

Sie sollte von 30 in 0 geändert worden sein.

Überprüfen der SCM-Installation

Klicken Sie auf Start und Ausführen, geben Sie mmc ein, und drücken Sie die EINGABETASTE.

Microsoft Management Console des SCM sollte verfügbar sein.

Zusammenfassung

Wenngleich Windows NT nicht über die gesamte Bandbreite an modernen Sicherheitsfunktionen verfügt, gibt es noch viele Funktionen und Techniken zur Entschärfung von Bedrohungen und Sicherheitsrisiken für Windows NT-Systeme. Neben der erstmaligen Installation des Betriebssystems und der Patchbasis, der Absicherung des Startvorgangs und der Bereitstellung des Verzeichnisdienstclient-Add-Ins, der effizienten Nutzung von Systemrichtlinien, der Steuerung sicherheitsrelevanter Aspekte wie z. B. NTLM-Authentifizierung und Kennwortgenerierung, der Absicherung des Dateisystems und von Diensten und weiteren Absicherungsmaßnahmen gibt es noch eine Fülle von Möglichkeiten auf Betriebssystemebene, um Windows NT so sicher wie möglich zu gestalten.

Weitere Informationen

Windows NT 4.0 Service Pack 6a finden Sie unter http://www.microsoft.com/ntserver/nts/downloads/recommended/SP6/allSP6.asp.

Die FAQs zu Windows NT Server Service Pack 6a umfassen sicherheitsspezifische Informationen und stehen unter http://www.microsoft.com/ntserver/support/faqs/sp6faq.asp zur Verfügung.

Das Sicherheits-Rollup-Paket nach dem Windows NT 4.0 Service Pack 6a ist unter http://www.microsoft.com/ntserver/nts/downloads/critical/q299444/default.asp verfügbar.

Das Internet Explorer Administration Kit finden Sie unter http://www.microsoft.com/windows/ieak/.

Das englischsprachige Handbuch "Guide to Microsoft Windows NT 4.0 Profiles and Policies" kann unter http://www.microsoft.com/ntserver/docs/prof_policies.doc heruntergeladen werden.

Informationen zum Systemrichtlinien-Editor finden Sie auf der englischsprachigen Seite "Using the System Policy Editor" auf MSDN unter http://msdn.microsoft.com/library/en-us/policy/policy/using_the_system_policy_editor.asp.

Der Manager für Sicherheitskonfigurationen steht auf dem FTP-Server von Microsoft unter http://www.microsoft.com/ntserver/techresources/security/securconfig.asp zur Verfügung.

Ein umfassendes Handbuch zum SCM für Windows NT 4.0 kann unter http://www.microsoft.com/ntserver/docs/scm-nt4.doc heruntergeladen werden.

Das englischsprachige Handbuch "Guide to Securing Microsoft Windows NT Networks" der US-amerikanischen National Security Agency ist unter www.nsa.gov/snac/downloads_winnt.cfm verfügbar.


**
**