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:
Auf dieser Seite
Sicherheitsentwurf für Windows NT-HostsZur Absicherung des Windows NT 4.0-Betriebssystems sind die Bewertung und das Verständnis mehrerer Themen erforderlich. Erstmaliges Installieren des Betriebssystems und der PatchbasisDer 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:
Absichern der StartsequenzWenn 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:
![]() 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-InsWindows 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:
Verwenden von Systemrichtlinien und des Managers für SicherheitskonfigurationenBei 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 SystemrichtlinienIn 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:
Systemrichtlinien weisen viele Ähnlichkeiten mit Gruppenrichtlinien auf, es sind jedoch einige Beschränkungen und Unterschiede zu beachten:
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:
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
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 SystemrichtlinienbereitstellungBeachten Sie bei der Entwicklung und Bereitstellung von Richtlinien diese potenziellen Systemrichtlinienkomplikationen, um ein Höchstmaß an Sicherheit zu gewährleisten:
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:
Manager für SicherheitskonfigurationenDer 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:
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
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:
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:
Auswählen der NTLM-AuthentifizierungsebeneWindows 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:
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
Aktualisieren der NTLM-Authentifizierung unter Windows 98Mit 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.0Windows 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 2003Die 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 SperrungsrichtlinienEin 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 DateisystemsIm 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 DienstenMehrere 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)
RestrictNullSessAccess (REG_DWORD)
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ßnahmenEs können weitere Absicherungsmaßnahmen für unterschiedliche Umgebungen geeignet sein. Deaktivieren der automatischen Generierung von 8.3-DateinamenWindows 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 AutorunBei 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 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-SubsystemenOS/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:
Anwendungen, die auf den OS/2- oder POSIX-Subsystemen beruhen, werden nicht länger ausgeführt. Erhöhen von ObjektschutzebenenDer 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:
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 hindernMit 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:
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 AdministratoranmeldungWindows 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:
Dies hat keinerlei potenzielle Auswirkungen auf Benutzermodusanwendungen. Deaktivieren von Benachrichtigungen an den Novell-ClientWindows 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 Die Kennwortsynchronisierung zwischen Windows und Netware ist in Umgebungen, in denen Netware verwendet wird, deaktiviert. ImplementierungImplementierungsvoraussetzungenUm 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übersichtZur Implementierung dieses Lösungsszenarios müssen die folgenden Aktivitäten durchgeführt werden:
Einrichten einer Basis für das BetriebssystemJedes 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:
So überprüfen Sie die Verschlüsselungsversion von Windows NT 4.0
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 SyskeyZur 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
Verringern der Anzeigedauer des SystemstartmenüsIm Folgenden wird beschrieben, wie sich die Anzeigedauer des Systemstartmenüs ändern lässt. So verringern Sie die Anzeigedauer des Systemstartmenüs
Installieren des SCMIm 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
Laden des Snap-In für den SCMNach 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
Anwenden der Trey-RichtlinienvorlageIm 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
So wenden Sie die Richtlinienvorlage von der SCE-Benutzeroberfläche aus an
So wenden Sie die Richtlinienvorlage von der Eingabeaufforderung aus an
Verhindern der Speicherung von LM-Kennwort-HashwertenIm 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
Festlegen der NTLM-AuthentifizierungsebeneIm 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
So legen Sie die NTLM-Ebene anhand von Registrierungseinträgen unter Windows NT 4.0 SP3 oder höher fest
So legen Sie die NTLM-Ebene anhand von Registrierungseinträgen unter Windows 98 fest
Konvertieren eines Datenträgers in NTFSIm Folgenden wird die Konvertierung eines FAT-Datenträgers in NTFS erläutert. So konvertieren Sie einen FAT-Datenträger in NTFS
Durchführen weiterer AbsicherungsmaßnahmenIm Folgenden werden die zur Implementierung weiterer Absicherungsmaßnahmen erforderlichen Schritte erläutert. Deaktivieren der automatischen Generierung von 8.3-DateinamenMit 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
Deaktivieren von AutorunMit diesem Verfahren wird die Autorun-Funktion für CD-ROM-Laufwerke deaktiviert. So deaktivieren Sie Autorun
Entfernen von OS/2- und POSIX-SubsystemenMit diesem Verfahren werden die OS/2- und POSIX-Kompatibilitätssubsysteme deaktiviert. So deaktivieren Sie OS/2 und POSIX
Erhöhen von ObjektschutzebenenMit diesem Verfahren werden die Schutzebenen für Kernelobjekte erhöht. So erhöhen Sie Objektschutzebenen
Benutzer am Hinzufügen von Druckertreibern hindernMit diesem Verfahren wird verhindert, dass normale Benutzer Druckertreiber hinzufügen können. So verhindern Sie das Hinzufügen von Druckertreibern durch normale Benutzer
Bestätigen der Deaktivierung der automatischen AdministratoranmeldungMit diesem Verfahren wird die automatische Anmeldung des Administratorkontos deaktiviert. So deaktivieren Sie die automatische Administratoranmeldung (die standardmäßig nicht aktiviert ist)
Deaktivieren von Benachrichtigungen für den Novell-ClientMit 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
Testen der LösungNach erfolgter Implementierung des Trey-Szenarios können Sie überprüfen, ob sie Ihren Anforderungen gerecht wird. ÜberprüfungAnhand 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
ZusammenfassungWenngleich 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
| In diesem Beitrag |