Sicherheit unter Windows 2000 und Unix Betriebssystemen

Möglichkeiten und Grenzen auf Betriebssystemebene

Autor: Michael Krausz, C.I.S.-Auditor, Wien

Version 30.7.2003

(1) Auf Kompatibilität verzichten

Windows 2000 unterstützt einen Mechanismus, die sog. Server-Client Authentifizierung, mit der sowohl Server als auch Client feststellen können, dass der jeweils andere auch entsprechend zum Zugriff berechtigt ist. Dieser Mechanismus wird vom Administrator konfiguriert und operiert ohne jede Intervention des Benutzers. Er kann allerdings in einem gemischten Windows 2000/Windows NT 4.0 Netzwerk nicht verwendet werden, da er von Windows NT 4.0 Geräten nicht unterstützt wird.

Eine ähnliche Situation existiert im Bereich der Passwörter. Windows NT 4.0 Passwörter konnten zwar 14 Zeichen lang sein, waren jedoch aus Kompatibilitätsgründen mit dem DOS-Lanmanager in zwei Blöcke zu je 7 Zeichen geteilt. Dadurch wurde die Sicherheit des Passwortes wesentlich verringert, denn statt eines Zeichenraums von 6214 Kombinationen, musste ein Angreifer nur 2x627 Kombinationen durchprobieren, um ein Passwort erraten zu können. (Die Zahl 62 stammt aus der Anzahl der Großbuchstaben, Kleinbuchstaben und Ziffern, sie könnte noch erhöht werden, wenn man auch Sonderzeichen berücksichtigt.)

Unter Windows 2000 wurde diese Schwachstelle nun insofern beseitigt, als dass die Rückwärtskompatibilität ein- oder ausgeschaltet werden kann. Wiederum ist es vom Standpunkt der Informationssicherheit empfehlenswert, im Falle einer Migration auf diese Rückwärtskompatibilität zu verzichten und nur Windows 2000 „native“ Komponenten und Dienste einzusetzen.

(2) Domänen statt Arbeitsgruppen

Unabhängig von der Größe des Netzes ist es empfehlenswert zentralisierte Architekturen einzusetzen, da in diesen die Vergabe (und auch der Entzug!) und die Überwachung von Rechten wesentlich leichter bewerkstelligt werden kann, als in dezentralen Architekturen. Zentrales Logging stellt sicher, dass der Sicherheitsadministrator jederzeit einen qualitativ hochwertigen Überblick über die Lage des Netzwerks hat.

(3) Gruppenrichtlinien einsetzen

Gruppenrichtlinien bieten dem Administrator unter Windows 2000 die Möglichkeit, alle besonderen Rechte, die ein Benutzer haben kann (wie z.B. schon allein das Stellen der Uhrzeit auf einem lokalen Rechner), nach Benutzergruppen zu verwalten und damit ein Windows 2000 Netzwerk so beliebig dicht wie möglich zu machen. Mit Hilfe der über 100 verschiedenen Einstellungen lässt sich das den Benutzern Erlaubte und Verbotene so feingliedrig regeln, dass auch subtile Anforderungen erfüllt werden können.

(4) Eingebaute Firewalls nutzen

Sofern die betriebenen Windows 2000 Server leistungsgerecht ausgelegt sind, ist es empfehlenswert die in Windows 2000 inkludierten Firewallfunktionalitäten zu nutzen. Dadurch kann im Inneren des Netzes am Server selbst der erlaubte bzw. verbotene Netzwerkverkehr weiter reglementiert werden und damit das System vor nicht autorisierten Zugriffen geschützt werden. Selbstverständlich sollte diese Möglichkeit nicht anstatt einer zentralen Firewall verwendet werden, sonder zusätzlich, da dadurch ein zweistufiger Schutz realisiert werden kann.

Alle folgenden Ausführungen gelten unabhängig von der konkreten UNIX-Implementierung und können auf allen gängigen UNIX/LINUX-Systemen angewandt werden.

(1) Zentralisierte Benutzerverwaltung

Besonders unter Unix, das prinzipiell nicht zentral, sonder dezentral ausgelegt ist, sollte in mittleren oder sicherheitssensiblen Netzen, die Benutzerverwaltung zentralisiert werden, um zu verhindern, dass einerseits böswillige Angestellte oder unentdeckte Hacker auf einem System einen Benutzeraccount als Hintertür zurücklassen. Diese Funktionalität lässt sich leider nur mit Zusatzprodukten von Drittanbietern implementieren, da die eingebauten Methoden technisch nicht ausreichend sind.

Konkret ist davon abzuraten, auf allen Systemen das selbe Passwort für den Benutzer „root“ zu verwenden, sofern eine Zentralisierung der Benutzerverwaltung nicht möglich ist.

(2) Kernel-Firewalling

Alle modernen UNIX Systeme verfügen über Kernel-Firewalling, mit dem – wie oben für Windows 2000 ausgeführt – der Datenverkehr, der von einem bestimmten Rechner akzeptiert wird, reglementiert werden kann. Für als Server eingesetzte Systeme sollte diese Funktionalität in jedem Fall als zusätzliches Sicherheitsmerkmal benutzt werden.

(3) Zentrales Logging und Auswertung

Gerade unter Unix mit seiner dezentralen Struktur spielt zentrales Logging eine wichtige Rolle, um sicherstellen zu können, dass mit Hilfe geeigneter Analyseprodukte, die Sicherheitssituation des Netzes festgestellt werden kann und Hacker rechtzeitig entdeckt werden. Der Einsatz von zusätzlicher Software ist notwendig, da die meisten UNIX-Distributionen keine besonderen Analysemethoden zur Verfügung stellen, um große Logdateien auch effizient nach sicherheitsrelevanten Ereignissen durchforsten zu können.

(4) Lokale Dateisystemintegrität

Um sicherzustellen, dass Dateien (vor allem Systemdateien) nicht verändert wurden, sei es von externen oder internen Crackern, ist es unter Unix sehr leicht möglich, Programme zu installieren, die die Integrität beliebiger Verzeichnisse oder einzelner Dateien sicherstellen können. Gerade unter UNIX ist es bei Crackern eine beliebte Methode, Systemdateien durch manipulierte Versionen zu ersetzen, die dann als Hintertüre zum System dienen können.

In einem dem Autor bekannten Fall hat ein Cracker in einem Schwung über 100.000 Dateien auf einem System ausgetauscht, mit denen insgesamt 15 verschiedene Hintertüren geöffnet wurden.

Die Verwendung von Programmen zur Wahrung der Dateiintegrität kann solches Verhalten in Echtzeit feststellen und den Administrator entsprechend alarmieren.

(5) Eigene Benutzer für wichtige Dienste

Keinesfalls sollte man auf einem UNIX System alle ständig laufenden Dienste einfach unter dem Benutzer „root“ laufen lassen, da dadurch das gesamte System kompromittiert wird, falls ein Dienst eine ausbeutbare Schwachstelle aufweist.

Es hat sich in der Praxis bewährt, für jeden wichtigen Dienst einen eigenen Account einzurichten, wodurch der Zugriff auf das Dateisystem entsprechend eingeschränkt wird und bleibt. Bei manchen Programmen, wie z.B. manchen Mail-Servern, ist dies jedoch nicht möglich, da diese den Zugriff als Benutzer „root“ benötigten, um funktionieren zu können.

Es wird jedoch die Informationssicherheit des betroffenen Systems stark angehoben, wenn nach detaillierter Analyse der laufenden Dienste, diejenigen, die den Zugriff als Benutzer „root“ nicht unbedingt benötigen, unter eigenen Benutzeraccounts betrieben werden.

Die hier vorgestellten Methoden können leider keinen Anspruch auf Vollständigkeit erheben, da eine genauere Abhandlung ein gesamtes Buch über operatives Sicherheitsmanagement füllen würde. Wir hoffen jedoch, Ihnen wichtige Anhaltspunkte für Ihre eigenen Konfigurationen gegeben zu haben.