next up previous contents
Next: AD als LDAP-Ersatz Up: Lösungsideen und Alternativen Previous: Strukturierung mittels Organisationseinheiten (OU)   Contents

Firewall-Aspekte

Auf Grund seiner Verbreitung ist das Windows-Betriebssystem oftmals Ziel vielseitiger Angriffe aus dem Inter- aber auch Intranet. Viren, Würmer und Hacking-Skripte sind nur eine kleine Auswahl der üblichen Gefahren. Auch fehlkonfigurierte Klienten können zu Problemen führen. Daher werden Server üblicherweise nur hinter einer Firewall oder in einer so genannten DMZ betrieben. Für den Betrieb bleibt somit allerdings die Frage, welcher Netzverkehr zum Server durchgelassen werden muss, um den Betrieb des eigentlichen Dienstes nicht zu beeinflussen.
Ein Windows Domaincontroller, der ein Active Directory bereitstellt, bietet verschiedene Dienste, auf die der Zugriff ermöglicht werden muss, um den erfolgreichen Betrieb zu gewährleisten. Das sind einerseits das Kerberos-Protokoll, aber auch der LDAP-Zugang zum Verzeichnis. Andererseits muss auch der globale Katalog bedacht werden und die windowstypischen RPC-Systeme für CIFS und SMB für Drucker- und Netzfreigaben. Da beispielsweise die Replikation, aber auch die Softwareinstallation mittels dieser RPC-Systeme funktioniert, sind diese auch unerläßlich für den regulären Betrieb. Somit sind bereits folgende Ports erreichbar zu halten:
Port Protokoll Anwendung
Notwendige Dienste fÃ14r einen Domaincontroller
88 tcp/udp Kerberos
389 tcp LDAP-Standardport
464 tcp/udp Kerberos V5 Passwortdaemon
636 tcp LDAP (SSL-verschlüsselt)
3268 tcp globaler Katalog (LDAP-Protokoll)
3269 tcp globaler Katalog (SSL-verschlüsselt)
Um WinNT-, Win9x-, WinME-Clienten bedienen und
die Windows-Netzwerkumgebung bereitstellen zu können
135 tcp/udp RPC-Portmapper
137 tcp/udp NetBIOS Name Server
138 udp NetBIOS Datagramm
139 tcp NetBIOS Session Services
445 tcp/udp SMB-Protokoll (Freigaben)
Weiterhin sinnvoller Dienst
3389 tcp Remote Desktop Protocol
Zusätzlich ist auf Grund der dynamischen Portzuteilung der RPC-Dienste durch den RPC Portmapper keine sinnvolle Porteinschränkung jenseits des priviligierten Portbereiches möglich.

Um diesen Umstand gerecht werden zu können, ist es mit Hilfe von Manipulationen an der Registry möglich, alle RPC-Aufrufe auf einen fest vereinbarten Port abzubilden, wodurch nur noch dieser erreichbar sein muss, um die volle Funktionalität zu gewährleisten. Dazu muss der entsprechend gewählte Port unter $HKEY\_LOCAL\_MACHINE\backslash SYSTEM\backslash$
$CurrentControlSet\backslash Services\backslash
NTDS\backslash Parameters\backslash$ als DWORD-Wert namens $TCP/IP
Port$ eingetragen werden. In der Folge wird der RPC-Portmapper auf Port 135 nur noch diesen einen Port als Konnektivitätsmöglichkeit melden. Entsprechend muss die obige Liste der Ports für die Firewall nur noch um diesen einen Port ergänzt werden.
Alternativ kann auch die Windows-Firewall beeinflusst werden, einen eingeschränkten Bereich zur weiterhin dynamischen Nutzung freizugeben. Dazu werden auch Registry-Keys erzeugt, die die Firewall entsprechend konfigurieren. Genaueres dazu und Weiterführendes kann im Kapitel "`Active Directory und Firewalls"' bei [KT04] nachgelesen werden.
In der Folge des Kapitels finden sich ebenfalls Ausführungen über eine weitere Sicherungsmöglichkeit mittels VPN beziehungsweise mittels PPP sowie Zertifikaten. Ersteres kann nur zur Replikation und zum Datenverkehr zwischen Domaincontrollern genutzt werden, ist Kerberosbasiert und daher nicht für den Beitritt eines DCs in eine Domäne realisierbar. Letzteres zieht die Notwendigkeit zum Aufbau einer Zertifikatstruktur nach sich, kann dann allerdings zur Sicherung jeglichen Traffics zwischen Domaincontrollern genutzt werden. Zur Einführung in die beiden Themen soll an dieser Stelle auf [KT04] verwiesen sein, sprengt aber in voller Breite selbst deren Rahmen und wäre hier weit ab vom Themenkern.


next up previous contents
Next: AD als LDAP-Ersatz Up: Lösungsideen und Alternativen Previous: Strukturierung mittels Organisationseinheiten (OU)   Contents
Marko Damaschke 2006-03-25