Freigeben über


The Cable GuyStarke und schwache Hosts

Joseph Davies

Eine immer gebräuchlichere Konfiguration für Netzwerkhosts ist die Vernetzung mit mehreren Netzwerkschnittstellen. Ein mehrfach vernetzter Host bietet verbesserte Konnektivität, weil eine Verbindung zu mehreren Netzwerken gleichzeitig hergestellt werden kann, wie z. B. zu einem Intranet oder dem Internet. Weil sie aber sowohl mit einem Intranet als auch mit dem

Internet verbunden sein können, können Dienste, die auf mehrfach vernetzten Hosts ausgeführt werden, für Angriffe anfällig sein. Als Beitrag zur Verhinderung von Angriffen, und um eine Vorstellung davon zu vermitteln, wie IP-Datenverkehr für einen mehrfach vernetzten Host verarbeitet wird, werde ich im Folgenden die Modelle des schwachen und starken Hosts bei mehrfach vernetzten Hosts untersuchen und beschreiben, wie diese Modelle unter Windows® unterstützt werden.

RFC 1122 ist die Spezifikation, welche die zwei Modelle für einen mehrfach vernetzten Host beschreibt, der sich nicht als Router verhält, und nur Unicast-IP-Datenverkehr sendet und erhält. Die entsprechenden Modelle werden als starker Host bzw. schwacher Host bezeichnet und geben an, ob gesendeter oder empfangener Unicastdatenverkehr der Netzwerkschnittstelle, auf der sich der Datenverkehr bewegt, zugeordnet werden muss. Anhand dieser Modelle wird bestimmt, wie ein Host Pakete sendet und empfängt. Sie haben zudem Auswirkungen auf die Sicherheitsrisiken für Dienste, die auf dem Host ausgeführt werden.

Diese Modelle wurden für IPv4 definiert, gelten aber auch für IPv6. Ein Beispiel für einen mehrfach vernetzten Host unter IPv6 ist ein Computer, der sowohl IPv4 als auch IPv6 verwendet und über einen Netzwerkadapter mit einem Intranet und einer IPv6-Tunnelschnittstelle verbunden ist.

Schwache Hosts

Ein schwacher Host kann IP-Pakete (IPv4 oder IPv6) über eine Schnittstelle senden, der die Quell-IP-Adresse des gesendeten Pakets nicht zugewiesen ist. Das ist das Sendeverhalten eines schwachen Hosts. Ein solcher Host kann zudem Pakete an einer Schnittstelle empfangen, der die Ziel-IP-Adresse des empfangenen Pakets nicht zugewiesen ist. Das ist das Empfangsverhalten eines schwachen Hosts.

Wenn Sie einen mehrfach vernetzten IP-Host mit mehreren Schnittstellen haben und das Empfangsverhalten eines schwachen Hosts an Schnittstellen aktivieren, kann dies den Host für Multihome-Angriffe anfällig machen. Abbildung 1 zeigt beispielsweise Host A, der sowohl mit dem Internet als auch einem Intranet eine Verbindung hergestellt hat. Der Internetschnittstelle von Host A ist die öffentliche IPv4-Adresse 131.107.89.211 zugewiesen, der Intranetschnittstelle die private IPv4-Adresse 192.168.17.48.

Abbildung 1 Beispiel eines mehrfach vernetzten Computers

Abbildung 1** Beispiel eines mehrfach vernetzten Computers **

Ist das Sendeverhalten eines schwachen Hosts sowohl an der Internet- als auch der Intranetschnittstelle aktiviert, kann Host A Pakete von 131.107.89.211 und von 192.168.17.48 an seine Internetschnittstelle und an seine Intranetschnittstelle senden.

Ist das Empfangsverhalten eines schwachen Hosts aktiviert, kann Host A die folgenden Arten Pakete empfangen (vorausgesetzt, dass die Firewallregeln des Hosts den eingehenden Datenverkehr zulassen): Pakete an 131.107.89.211 an seiner Internetschnittstelle, Pakete an 192.168.17.48 an seiner Internetschnittstelle, Pakete an 131.107.89.211 an seiner Intranetschnittstelle, Pakete an 192.168.17.48 an seiner Intranetschnittstelle.

Wenn Sie das Empfangsverhalten eines schwachen Hosts aktiviert haben, kann ein Unbefugter im Internet Pakete an die Internetschnittstelle von Host A senden, um Dienste anzugreifen, die auf Host A ausgeführt werden und nur den Hosts im Intranet zur Verfügung stehen. Diese Art Angriff ist möglich, wenn die Internet-Infrastruktur das Weiterleiten von Paketen unterstützt, die für 192.168.17.48 an die Internetschnittstelle von Host A bestimmt sind. Sie können diese Art Angriff durch Festlegen der passenden Firewallregeln an der Internetschnittstelle von Host A verhindern. Trotzdem können aber die Dienste, die auf Host A ausgeführt werden und den Intranetclients zur Verfügung stehen, gefährdet sein.

Starke Hosts

Beim Modell des starken Hosts sind Sende- und Empfangsverhalten anders. Ein starker Host kann nur dann Pakete an eine Schnittstelle senden, wenn der Schnittstelle die Quell-IP-Adresse des Pakets, das gesendet werden soll, zugewiesen ist. Zudem kann er nur dann Pakete an einer Schnittstelle empfangen, wenn der Schnittstelle die Ziel-IP-Adresse des Pakets, das empfangen werden soll, zugewiesen ist.

Ist das Empfangsverhalten eines starken Hosts an der Internet- und Intranetschnittstelle aktiviert, kann Host A in Abbildung 1 nur Pakete von 131.107.89.211 an seine Internetschnittstelle senden, und Pakete von 192.168.17.48 an seine Intranetschnittstelle.

Ist das Empfangsverhalten eines starken Hosts aktiviert, kann Host A nur Pakete an 131.107.89.211 an seiner Internetschnittstelle und Pakete an 192.168.17.48 an seiner Intranetschnittstelle empfangen.

In Abbildung 1 weist das starke Hostmodell für Host A alle an der Internetschnittstelle eingehenden Pakete ab, die an 192.168.17.48 adressiert sind, ohne dass Sie Firewallregeln konfigurieren müssen, die wirksam die Intranetschnittstelle von Host A vom Internet isolieren.

Wenn Sie das starke Hostmodell auswählen, denken Sie daran, dass es sich auf einige Konnektivitätsarten auswirken könnte, die auf ein schwaches Hostverhalten ausgelegt sind. Ein Beispiel hierfür wäre ein Lastenausgleichssystem, bei dem das Empfangsverhalten eines schwachen Hosts aktiviert ist, sodass Pakete an allen Schnittstellen empfangen und intern an die passende Schnittstelle weitergeleitet werden können. Ein weiteres Beispiel wäre ein Host mit dem Sendeverhalten eines schwachen Hosts, der Datenverkehr von jeder Quelladresse an eine Schnittstelle senden soll, die eine schnelle Verbindung darstellt.

Senden und Empfangen beim starkem Host

Im Folgenden wird erläutert, wie der Sende- und Empfangsprozess auf einem generischen IPv4- oder IPv6-Host abläuft, wenn Sie ermöglichen, dass das Sende- und Empfangsverhalten eines starken Hosts auf Schnittstellenbasis aktiviert und deaktiviert wird.

Bei Paketen, die gesendet werden sollen, prüft IP zuerst, ob eine Quelladresse bereits angegeben worden ist. Wenn nicht, führt IP eine unbegrenzte Suche der Zieladresse des Pakets in der Routingtabelle durch. In einer unbegrenzten Suche werden alle Routen in der Routingtabelle berücksichtigt. Basierend auf der ausgewählten Zielroute bestimmt IP die Schnittstelle des nächsten Abschnitts (die Schnittstelle, die verwendet wird, um das Paket auf der Linkschicht abzulegen) und die Adresse des nächsten Abschnitts. Basierend auf der Schnittstelle des nächsten Abschnitts verwendet IP den in RFC 3484 definierten Adressauswahlprozess so, dass beste Quelladresse bestimmt werden kann. Jetzt hat IP alles, was es braucht, um das Paket zu senden: Quell- und Zieladresse, Schnittstelle des nächsten Abschnitts und Adresse des nächsten Abschnitts.

Wenn die Quelladresse angegeben wurde, ist die Quellschnittstelle bekannt. Der Quellschnittstelle wird die Quelladresse zugewiesen. IP prüft dann, ob das Sendeverhalten eines starken Hosts auf der Quellschnittstelle aktiviert ist.

Wenn es deaktiviert ist, führt IP eine unbegrenzte Suche der Zieladresse des Pakets in der Routingtabelle durch. Basierend auf der am besten passenden Zielroute bestimmt IP die Schnittstelle des nächsten Abschnitts und die Adresse des nächsten Abschnitts. IP hat die Quell- und Zieladresse, die Schnittstelle des nächsten Abschnitts und die Adresse des nächsten Abschnitts. Ist das Sendeverhalten eines starken Hosts an der Quellschnittstelle deaktiviert, ist die Schnittstelle des nächsten Abschnitts mit der Quellschnittstelle eventuell nicht identisch.

Wenn Sendeverhalten eines starken Hosts an der Quellschnittstelle aktiviert ist, führt IP eine eingeschränkte Suche der Zieladresse des Pakets in der Routingtabelle durch. Bei einer eingeschränkten Suche werden nur die Routen der Quellschnittstelle mit einer Schnittstelle des nächsten Abschnitts berücksichtigt. Basierend auf der ausgewählten Zielroute bestimmt IP die Adresse des nächsten Abschnitts. IP hat die Quell- und Zieladresse, die Schnittstelle des nächsten Abschnitts und die Adresse des nächsten Abschnitts. Bei aktiviertem Sendeverhalten eines starken Hosts an der Quellschnittstelle ist die Schnittstelle des nächsten Abschnitts immer mit der Quellschnittstelle identisch. Abbildung 2 zeigt den generischen IP-Sendeprozess.

Abbildung 2 Generischer IP-Sendeprozess

Abbildung 2** Generischer IP-Sendeprozess **(Klicken Sie zum Vergrößern auf das Bild)

Wurde die Quelladresse angegeben, kann die eingeschränkte Routensuche unter mehreren Routen in der Routingtabelle eine Route mit einer höheren Metrik auswählen, die dem Ziel am besten entspricht. Host A hat zum Beispiel in Abbildung 1 zwei Standardrouten. Eine verweist auf das Internet mit einer Metrik von 10, die zweite verweist auf das Intranet mit einer Metrik von 20. Starkes Hostverhalten ist an beiden LAN-Schnittstellen aktiviert.

Wenn die sendende Anwendung auf Host A keine Quelladresse angibt, ist das Ergebnis der Routensuche die Standardroute mit der niedrigsten Metrik. Host A sendet den Datenverkehr aus der Internetschnittstelle immer mit einer Quelladresse von 131.107.89.211. Wenn aber die sendende Anwendung auf Host A eine Quelladresse von 131.107.89.211 angibt, ist das Ergebnis der Suche die Standardroute für die Internetschnittstelle. Host A sendet den Datenverkehr aus der Internetschnittstelle. Wenn die sendende Anwendung auf Host A eine Quelladresse von 192.168.17.48 angibt, wählt die Suche die Standardroute für die Intranetschnittstelle aus. Host A sendet den Datenverkehr aus der Intranetschnittstelle. Mit der eingeschränkten Routensuche sendet IP Datenverkehr mit einer Quelladresse von 192.168.17.48 und verwendet die Standardroute mit der höheren Metrik.

Bei Datenempfang bestimmt IP zuerst, ob die Daten für den Host bestimmt sind. Wenn nicht, verwirft IP das Paket still, weil sich der Host nicht wie ein Router verhält. IP bestimmt dann, ob Empfangsverhalten eines starken Hosts an der Eingangsschnittstelle (an der das Paket empfangen wurde) aktiviert ist. Falls nein, verarbeitet IP das Paket. Falls ja, bestimmt IP, ob die Zieladresse im Paket der Eingangsschnittstelle zugewiesen ist. Falls ja, verarbeitet IP das Paket. Falls nicht, verwirft IP still das Paket. Abbildung 3 zeigt den generischen Empfangshostprozess.

Abbildung 3 Empfangshostprozess

Abbildung 3** Empfangshostprozess **

Schwaches und starkes Hostverhalten in Windows

In Windows XP und Windows Server® 2003 gilt für alle IPv4-Schnittstellen das schwache Hostmodell zum Senden und Empfangen und für alle IPv6-Schnittstellen das starke Hostmodell zum Senden und Empfangen. Sie können dieses Verhalten nicht konfigurieren. Die nächste Generation des TCP/IP-Stacks in Windows Vista und Windows Server 2008 unterstützt an allen IPv4- und IPv6-Schnittstellen (außer der Teredo-Tunnelschnittstelle für ein hostspezifisches Teredo-Relay) standardmäßig Sende- und Empfangsverhalten eines starken Hosts. Abbildung 4 enthält die Befehle, die Sie verwenden können, um das Sende- und Empfangsverhalten für IPv4 und IPv6 auf Schnittstellenbasis zu konfigurieren. InterfaceNameOrIndex ist entweder der Name der Schnittstelle aus dem Netzwerkverbindungsordner oder dessen Schnittstellenindex. Sie können den Schnittstellenindex einer Schnittstelle über folgenden Befehl erhalten:

Figure 4 Befehle zum Konfigurieren von starkem und schwachem Sende- und Empfangsverhalten

• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
 
netsh interface ipv6 show interface

Schwaches und starkes Hostverhalten und RFC 3484

Für eine normierte Methode zur Auswahl von IPv6- und IPv4-Quell- und Zieladressen, mit denen der Verbindungsaufbau versucht wird, enthält RFC 3484 zwei Algorithmen. Der erste ist ein Algorithmus zur Quelladressauswahl, um die beste Quelladresse zur Verwendung mit einer Zieladresse auszuwählen. Der andere ist ein Algorithmus zur Zieladressauswahl, um die Liste möglicher Zieladressen nach Präferenz zu sortieren.

Starkes und schwaches Hostverhalten gilt bei der Bestimmung der Liste von Quelladresskandidaten für eine gegebene Zieladresse, was sich auch auf die sortierte Liste der Zieladressen auswirkt. Beim Sendeverhalten eines starken Hosts besteht die Liste von Quelladresskandidaten aus den Unicastadressen, die der sendenden Schnittstelle für das Ziel zugewiesen sind. Beim schwachen Host kann die Liste Adressen umfassen, die einer Schnittstelle zugewiesen sind, auf welcher das Sendeverhalten eines schwachen Host aktiviert ist. Weitere Informationen zur Quell- und Zieladressauswahl finden Sie unter microsoft.com/technet/community/columns/cableguy/cg0206.mspx.

Standardmäßig sind sowohl Sende- als auch Empfangsverhalten eines schwachen Hosts für alle IPv4- und IPv6-Schnittstellen deaktiviert (außer Teredo Tunnelschnittstelle für ein hostspezifisches Teredo-Relay).

Weitere Informationen zu RFC 3484 finden Sie in der Randleiste „Schwaches und starkes Hostverhalten und RFC 3484“.

Deaktivieren von Standardrouten für Remote Access VPN-Verbindungen

Ein Remote-Access-Client eines virtuellen privaten Netzwerks (VPN) ist ein weiteres Beispiel für einen mehrfach vernetzten Host. Obwohl er vielleicht nur eine einzige LAN-Schnittstelle mit Verbindung zum Internet hat, ist er bei Aufbau einer VPN-Verbindung mehrfach vernetzt. Er hat zwei Schnittstellen: Seine LAN-Schnittstelle und eine Schnittstelle für die VPN-Verbindung, die auf dem Point-to-Point-Protokoll (PPP) basiert. Er besitzt zudem zwei IPv4-Adressen: Eine vom Internetdienstanbieter zugewiesene IPv4-Adresse für die LAN-Schnittstelle und eine vom VPN-Server zugewiesene IPv4-Adresse für die PPP-Schnittstelle.

Um sicherzustellen, dass der VPN-Client Standardrouten-Datenverkehr über die VPN-Verbindung zum Intranet sendet, ändern Windows XP und Windows Server 2003 die IPv4-Routingtabelle durch Anheben der Metrik der vorhandenen Standardroute und durch Hinzufügen einer neuen Standardroute mit einer niedrigeren Metrik, welche die PPP-Schnittstelle verwendet. Dieses Standardverhalten macht für die Dauer der VPN-Verbindung die Orte im Intranet erreichbar und fast alle Orte im Internet unerreichbar. Es ist möglich, einen VPN-Client für geteiltes Tunneln zu konfigurieren, um gleichzeitigen Zugriff auf das Internet und Intranetspeicherorte zu erhalten. Hierfür wird die Standardroute für die VPN-Verbindung nicht hinzugefügt, während bestimmte Routen für Intranetziele hinzugefügt werden. Es besteht jedoch das Risiko, dass geteiltes Tunneln von VPN-Clients Pakete zwischen dem Internet und dem Intranet weiterleiten kann. Weitere Informationen finden Sie unter microsoft.com/technet/community/columns/cableguy/cg1003.mspx.

Das Standardverhalten von VPN-Clients in Windows XP und Windows Server 2003 war auf das Sendeverhalten eines schwachen Hosts ausgelegt. Die Routensuche verwendet immer die Standardroute für die VPN-Verbindung, weil sie die niedrigste Metrik hat. Wenn Sie jedoch das Sendeverhalten eines starken Hosts verwenden, hängt die Standardroute, die für gesendeten Datenverkehr verwendet wird, von der Quell-IP-Adresse im Paket ab. Die Routensuche für Datenverkehr von der vom ISP zugewiesenen IPv4-Adresse verwendet die Standardroute der LAN-Schnittstelle und macht alle Internet-Orte erreichbar. Die Routensuche für Datenverkehr von der vom VPN-Server zugewiesenen IPv4-Adresse verwendet die Standardroute der PPP-Schnittstelle und macht alle Intranet-Orte erreichbar. Wenn Sie das Sendeverhalten eines starken Hosts verwenden, besitzt der VPN-Client daher eine Konfiguration mit geteiltem Tunneln und gleichzeitig Zugriff auf das Internet und das Intranet. Das gilt sogar für Anwendungen, die keine Administratorberechtigung zur direkten Änderung der IPv4-Routingtabelle besitzen.

Damit beim starken Hostsenden verhindert wird, dass geteiltes Tunneln als Standardkonfiguration entsteht, deaktiviert der VPN-Client in Windows Vista® und Windows Server 2008 automatisch die Standardrouten von LAN-Schnittstellen, wenn die VPN-Verbindung hergestellt wird. Somit gibt es für die PPP-Schnittstelle nur eine einzige aktive Standardroute in der Routingtabelle. Damit wird auch gewährleistet, dass Anwendungen ohne Berechtigungen auf Administratorenebene kein geteiltes Tunneln durchführen können.

Da Daten vom VPN-Clientcomputer von der IPv4-Adresse stammen müssen, die vom VPN-Server zugewiesen wurde, ist eine bessere Isolierung des Intranet vom Internet möglich. Bei Trennung der VPN-Verbindung werden die deaktivierten Standardrouten aktiviert.

Sie können dies mit folgendem Befehl steuern:

netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

Joseph Davies ist technischer Redakteur bei Microsoft und lehrt und schreibt seit 1992 über Themen im Bereich der Windows-Netzwerke. Er hat fünf Bücher für Microsoft Press verfasst und ist Autor des monatlich erscheinenden TechNet-Artikels „The Cable Guy“.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.