
Steve Riley, Senior Program Manager, Security Business and Technology
Letzten Monat haben Sie eine Einführung zu IPSec gelesen - einer wunderbaren Technologie, die jedoch manchmal etwas verwirrend ist. Nachdem Ihnen nun klar ist, wie IPSec arbeitet, beschäftigen wir uns diesen Monat mit drei häufig auftretenden Sicherheitsproblemen, die Sie mit Hilfe von IPSec lösen können.
Schutz vor Würmern mit Hilfe von IPSecAuch wenn es trivial klingt - der beste Weg sich vor Würmern zu schützen ist, sie gar nicht erst aktiv werden zu lassen. Leider verstehen viele Leute die Risiken und Bedrohungen im Zusammenhang mit E-Mails und dem Browsen im Web nicht richtig, oder sie interessieren sich einfach nicht dafür. Daher sind Würmer heute ein Teil des täglichen Lebens. Wie können wir also den Schaden durch solche Angriffe verringern? Es gibt drei Wege, wie Sie schädlichem Programmcode entgegenwirken können:
Am schwersten ist es wohl, die Installation von schädlichem Programmcode zu verhindern. Auch wenn Host-Firewalls und Virenscanner einen gewissen Schutz bieten können, bleibt es doch oft dem Benutzer vorbehalten über die Installation von Programmcode zu entscheiden. Windows XP Service Pack 2 bietet zwar einige zusätzliche Schutzfunktionen im Bezug auf schädlichen Programmcode, ist jedoch weiterhin darauf angewiesen, dass die Benutzer diese Features auch aktiviert lassen (sie sind standardmäßig aktiv), oder, bei entsprechenden Meldungen, die richtigen Entscheidungen treffen. Einige dieser Entscheidungen können Sie dem Benutzer durch eine entsprechende Konfiguration dieser Features über Gruppenrichtlinien abnehmen. Richtlinien für Softwareeinschränkungen verhindern, dass schädlicher Programmcode ausgeführt wird. Mit Gruppenrichtlinien können Sie Einschränkungen für einen Computer durchsetzen, über die nur autorisierte Programme ausgeführt werden können. Gehen Sie nicht andersherum vor (alles zulassen und die schädlichen Programm verbieten) - auch wenn dieser Ansatz zunächst einfacher erscheint. Denn wie können Sie sicher sein, dass Sie wirklich jedes schädliche Programm ausgeschlossen haben? Wenn Sie eine Liste mit zugelassenen Programmen nutzen und die Benutzer nicht als lokale Administratoren arbeiten, dann verfügen Sie über eine Umgebung, in der schädlicher Programmcode keinen Schaden anrichten kann - selbst dann nicht, wenn sich der Programmcode bereits auf dem Computer befindet. Ich bin ein großer Fan der Richtlinien für Softwareeinschränkungen und empfehle Ihnen, sie auch in Ihrer Organisation zu berücksichtigen. Um Sie bei den ersten Schritten zu unterstützen, habe ich am Ende dieses Artikels einige Links zusammengetragen. In einigen Fällen ist Ihre einzige mögliche Option eventuell den schädlichen Programmcode an einer Kommunikation zu hindern. IPSec-Richtlinien unterstützen Sie hierbei - Sie können festlegen was für Netzwerkverkehr vom Computer ausgehen darf und welchen Netzwerkverkehr der Computer akzeptiert. Indem Sie Filterregeln verwenden die Netzwerkverkehr zulassen oder blockieren (in diesem Fall wird keine Sicherheitsaushandlung durchgeführt), können Sie sehr effektive und grundlegende Filter für einzelne Computer erstellen. Sie können dieses Regeln dann über Gruppenrichtlinien einzelnen Computern zuweisen und so den durch schädliche Programme in Ihrem Netzwerk verursachten Netzwerkverkehr reduzieren. Welche IPSec-Richtlinien Sie nutzen, hängt vom verwendeten Betriebssystem ab. Windows XP und Windows Server 2003 stellen hostbasierte Firewalls zur Verfügung, die eingehenden Netzwerkverkehr effektiver als IPSec-Richtlinien blockieren können. In diesem Fall benötigen Sie also nur Richtlinien, die den ausgehenden Netzwerkverkehr blockieren. Windows 2000 stellt keine hostbasierte Firewall zur Verfügung - in diesem Fall sollten Sie Richtlinien für den eingehenden und den ausgehenden Netzwerkverkehr erstellen. Nehmen wir zum Beispiel den Slammer-Wurm. Dieser Wurm sucht nach Computern, die SQL Server oder MSDE ausführen und somit Netzwerkverkehr über UDP-Port 1434 verarbeiten. Das Aktualisieren aller Computer mit Patches kann einige Zeit dauern. Somit wäre das Zuweisen von IPSec-Richtlinien über Gruppenrichtlinien und die Blockierung von Port 1434 eine hervorragende Interimslösung. Eine entsprechende Richtlinie müsste so aussehen:
Außerdem haben Sie die Möglichkeit, IPSec-Richtlinien skriptgesteuert über Kommandozeilentools zu erstellen. Hierbei gibt es drei unterschiedliche Möglichkeiten, die vom eingesetzten Betriebssystem abhängig sind. Unter Windows 2000 steht Ihnen das Tool ipsecpol.exe aus dem Resource Kit zur Verfügung; unter Windows XP verwenden Sie ipseccmd.exe aus dem Ordner "Support Tools" der Installations-CD; und unter Windows Server 2003 stellt das Betriebssystem den Befehl netsh ipsec zur Verfügung (entsprechende Links finden Sie am Ende des Artikels). Mit dem folgenden Befehl können Sie unter Windows 2000 einen Filter für den Slammer-Wurm erstellen: ipsecpol -w REG -p "Block UDP 1434 Filter" -r "Block Inbound UDP 1434 Rule" -f *=0:1434:UDP -n BLOCK –x Mit diesem Befehl erstellen Sie eine statische Richtlinie mit dem Namen "Block UDP 1434 Filter" und weisen sie zu. Sie enthält eine einzelne Regel mit dem Namen "Block Inbound UDP 1434 Rule". Statische Richtlinien werden in der Registrierung gespeichert und bleiben auch bei Neustarts bestehen. Die Richtlinie wird allerdings erst beim nächsten Neustart aktiv (alternativ können Sie auch den IPSec-Richtlinienagenten neu starten). Wenn die Richtlinie sofort aktiv werden soll, dann sollte Ihr Skript also auch noch den Dienst "policyagent" neu starten. Wenn ein Computer mit dem Slammer-Wurm infiziert wurde, können Sie über eine andere IPSec-Regel die Infizierung weiterer Computer verhindern. Blockieren Sie einfach die ausgehende Netzwerkkommunikation an UDP-Zielport 1434:
Beachten Sie den kleinen Unterschied zur ersten Regel: In der ersten Regel wird von jeder Adresse:jeder Port an meine Adresse:1434/UDP gefiltert. In dieser Regel wird von meiner Adresse:jeder Port an jede Adresse:1434/UDP gefiltert. Die zweite Regel blockiert also den gesamten ausgehenden Netzwerkverkehr, der an UDP-Port 1434 eines beliebigen Computers geht. Mit dem folgenden Befehl können Sie eine solche Regel erstellen und Sie zur vorhin erstellen Richtlinie hinzufügen: ipsecpol -w REG -p "Block UDP 1434 Filter" -r "Block Outbound UDP 1434 Rule" -f 0=*:1434:UDP -n BLOCK Lassen Sie bei diesem Befehl den Schalter "-x" weg - Sie fügen die Regel ja zu einer bestehenden Richtlinie hinzu. Über die Kommandozeilentools haben Sie außerdem die Möglichkeit, dynamische Richtlinien zu erstellen. Solche Richtlinien bleiben allerdings nur bis zum nächsten Neustart aktiv (beziehungsweise bis zum nächsten Start des Richtlinienagenten). Mit den folgenden zwei Befehlen können Sie dynamische Richtlinien erstellen, die statischen Richtlinien von vorhin entsprechen: ipsecpol –f[*=0:1434:UDP] ipsecpol –f[0=*:1434:UDP] Die rechteckigen Klammern um die Filterdefinition zeigen an, dass der Netzwerkverkehr blockiert werden soll. Wir wissen also nun, wie wir Netzwerkverkehr von und an bestimmte Ziele blockieren können. Sie könnten jedoch auch einen restriktiveren Ansatz verwenden. Beispielsweise könnten Sie den gesamten Netzwerkverkehr blockieren und dann bestimmten Netzwerkverkehr zulassen. In diesem Fall sollten Sie jedoch eine ausführliche Planung und umfassende Tests durchführen - gehen Sie immer davon aus, dass der erste Versuch fehlerhaft arbeiten wird. Schutz von Servern mit Hilfe von IPSecEine hervorragende Anwendungsmöglichkeit von Richtlinien, die alles blockieren und dann explizite Ausnahmen zulassen, ist der Schutz von Servern. Nehmen wir zum Beispiel an, Sie richten einen Webserver ein. Warum sollte dieser Server eingehenden Netzwerkverkehr verarbeiten, bei dem es sich nicht um Webanfragen handelt? Mit einer IPSec-Richtlinie können Sie einen rudimentären Paketfilter erstellen, der den gesamten Netzwerkverkehr verwirft - bis auf den Netzwerkverkehr, der für den entsprechenden Server tatsächlich Sinn macht. Für unseren Webserver wäre dies der Netzwerkverkehr an TCP-Port 80 (und 443 wenn Sie HTTPS nutzen). Solche Richtlinien verschaffen Ihnen Zeit um Patches zu testen und bereitzustellen - zum Beispiel dann, wenn eine neue Sicherheitslücke in einem Betriebssystem entdeckt wird. Setzen wir unser Webserver-Beispiel noch ein wenig fort. Ihre IPSec-Richtlinie hätte zwei Regeln: Regel 1
Regel 2
Mit diesen Befehlen können Sie die Richtlinie erstellen: ipsecpol -w REG -p "Allow Web Traffic" -r "Block Everything" -f *+0 -n BLOCK –x ipsecpol -w REG -p "Allow Web Traffic" -r "Permit Inbound TCP 80" -f *+0:80:TCP –f *+0:443:TCP -n PASS Beachten Sie, dass in diesem Beispiel das "=" in der Definition durch ein "+" ersetzt wurde. Das bedeutet für den Richtlinienagenten, dass er gespiegelte Regeln einrichten soll. Diese gelten dann für den Netzwerkverkehr, der von Webserver ausgeht. Isolierung von Domänen mit Hilfe von IPSecWenn Sie Active Directory nutzen, dann kennen Sie Ihre Benutzer - sie müssen sich ja schließlich vor der Nutzung von Netzwerkressourcen authentifizieren. Wie sieht das jedoch mit den Computern aus? Einige der Computer sind zwar Domänenmitglieder, dies ist jedoch unter Windows nicht zwingend erforderlich. Solange der Benutzer über gültige Anmeldeinformationen verfügt kann er von jedem Computer im Netzwerk aus auf Netzwerkressourcen zugreifen. Das Konzept der "Domänenisolierung" wird daher immer populärer. Wir haben es erstmalig Ende 2001 erwähnt, und es wird inzwischen im gesamten Netzwerk von Microsoft und bei vielen Kunden angewandt. Wenn Sie sich bis jetzt noch nicht mit diesem Konzept beschäftigt haben, dann sollten Sie auf jeden Fall darüber nachdenken. Am Ende dieses Artikels finden Sie einen Link mit weiteren Informationen. Die Domänenisolierung ist aus vielen Gründen wichtig. Da Sie Dinge wie Gruppenrichtlinien, Sicherheitsvorlagen, Softwareeinschränkungen usw. nutzen können, können Sie Domänenmitgliedern vertrauen (zumindest einigermaßen). Mit diesen Features und Technologien können Sie die entsprechenden Computer kontrollieren - und Computer, die Sie kontrollieren machen nur das, was Sie zulassen. Solche Computer stellen eine weitaus geringere Bedrohung für Ihre Umgebung dar, als unverwaltete Maschinen, bei denen Sie nicht wissen, wie die Konfiguration aussieht. Es ist also wichtig, dass kein Benutzer von einem unverwalteten Computer auf Domänenressourcen zugreifen kann - nur autorisierte Computer dürfen mit anderen autorisierten Computern kommunizieren können. Dies für Ihre gesamte Domäne umzusetzen, ist einfacher als Sie möglicherweise annehmen. Als erstes fügen Sie der "Default Domain Policy" die folgende IPSec-Richtlinien hinzu
Statt ESP könnten Sie auch AH nutzen. In diesem Fall würde Ihre Richtlinie jedoch nicht mit Geräten funktionieren, die nur über NAT erreichbar sind. Da Sie mit den Domänencontrollern für eine Authentifizierung und ein Kerberos-Ticket kommunizieren müssen, müssen Sie außerdem eine Regel erstellen, die die Domänencontroller ausnimmt:
Nachdem Sie diese Richtlinien getestet und bereitgestellt haben, sind Computer, die keine Domänenmitglieder sind nicht mehr in der Lage mit Domänenmitgliedern zu kommunizieren. Dies liegt daran, dass IPSec für Domänenmitglieder erforderlich ist. Sie können die Richtlinien nicht erhalten bevor Sie der Domäne nicht beigetreten sind. Auch können Sie keine eigenen Richtlinie erstellen - denn die Richtlinie erzwingt Kerberos (und dies geht nur in der Domäne). Alle Domänenmitglieder erhalten die Richtlinien, und sind daher in der Lage mit anderen Domänenmitgliedern zu kommunizieren. Ich hoffe, meine kleine zweiteilige Serie hat Sie für diese Technologie begeistern können. Viel Spaß beim Experimentieren mit IPSec. Zusätzliche InformationenRichtlinien für Softwareeinschränkungen IPSec-Kommandozeilentools
Domänenisolierung bei Microsoft
| In diesem Beitrag
|