Die TCP/IP-Implementierung der Xbox

Die TCP/IP-Implementierung der Xbox
Marc Ruef <marc.ruef@computec.ch>
http://www.computec.ch
Version 2.7 [26. April 2003]
Alle Rechte vorbehalten - Kopieren erlaubt

Inhaltsverzeichnis

Inhaltsverzeichnis
Vorwort zur ersten Version
Vorwort zur zweiten Version
Danksagung
1. Einführung
2. Das Verhalten bei ICMP-Zugriffen
3. Das Verhalten bei TCP-Zugriffen
4. Das Verhalten bei UDP-Zugriffen
5. Die ARP-Implementierung
6. Die unterstützten Protokolle
7. Verbindung testen
8. Das System as.xboxlive.com
9. Die Kerberos-Authentisierung
10. Der Port 3074
11. Kontrollpakete
12. Die Live-Einwahl
13. Time-to-live Werte
14. Ein Live-Spiel mit Ghost Recon
15. Bei Ghost Recon kein Beitreten möglich
16. Content-Downloads
17. Das Live-Ausloggen
18. Denial of Service-Attacken
19. LAN-Verbindung ohne Xbox Live
FAQ
Nachwort
Literaturverzeichnis

Vorwort zur ersten Version

Keine andere Konsole hat mich bisher so fasziniert, wie die Microsoft Xbox. Das liegt zum einen an den technischen Möglichkeiten, die durch grandiose Titel wie "Halo" schon beim Launch präsentiert wurden. Das erste Mal seit dem Erscheinen der Sony Playstation fühlte ich das lang ersehnte Aha-Erlebnis, das ich bei der Playstation 2 so schmerzlich vermisst habe.

Abbildung 0.1: Ein Screenshot des Spiels Halo

Doch noch etwas anderes, macht die Xbox zu einer ganz besonderen Konsole. Dies ist die erstmals integrierte Netzwerkfähigkeit. Segas Dreamcast war die erste Konsole, die sich die Vernetzbarkeit zunutze machen wollte. Doch der kommerzielle Erfolg blieb aus, weil das Gerät erstens aufgerüstet werden musste und zweitens der Markt einfach noch nicht reif für die neue Technik war. Bei der Playstation 2 hielten sich über Monate die Ankündigungen, dass in Bälde ein Zusatz erhältlich sein sollte, der auch diese Nextgen-Konsole netzwerkfähig machen können soll. Als Besitzer einer PS2 kam man sich jedoch irgendwann im Regen stehen gelassen vor, als auch nach fast einem Jahr das entsprechende Kit nicht in den Läden erhältlich war.
Als ich das erste Mal in den Genuss von Xbox Live kam, war ich hin und weg von den neuen Möglichkeiten, die mir da ins heimische Wohnzimmer gebracht werden würden [Ruef 2003]. Netzwerkspiele kannte ich zwar schon lange vom PC - Meines Erachtens ist ein PC jedoch ein Arbeitswerkzeug und kein Spielzeug. Das ewige Einspielen von Patches, Anpassen von Konfigurationen und verhunzte Betriebssysteme trübten mein Zeitalter der Internet-Spiele am PC. Bei der Xbox, so hatte ich das Gefühl, würden diese Nachteile jedoch minimiert werden. Aufgrund der standardisierten Hard- und Software sollten Versionskonflikte und Probleme beim Installieren von Patches nichtig werden. Ob sich dieser Wunsch wirklich bewahrheiten kann, wird erst die Zukunft zeigen.
In der Zwischenzeit habe ich mich intensiv mit der TCP/IP-Implementierung der Xbox auseinandergesetzt. Die Früchte dieser Arbeit sind in dieser Publikation zusammengefasst. Ich wünsche viel Spass beim Lesen und Eintauchen in die TCP/IP-Welt der Microsoft Xbox. Wie immer bin ich für Kritik, Ergänzungen und Anregungen dankbar. Diese gilt es mir bestmöglich auf dem Weg der elektronischen Post mitzuteilen.
Marc Ruef <marc.ruef@computec.ch>
Wettingen, Februar 2003
http://www.computec.ch

Vorwort zur zweiten Version

Die Resonanz auf die erste Version dieses Dokuments hat mich ungemein gefreut. Grundsätzlich war ein guter Tenor zu herauszuspüren und die Leute begrüssten meine Arbeit. Grundsätzlich bemängelten viele Leser, dass die meisten niedergeschriebenen Kapitel sehr schwer verständlich sind. Dem habe ich nichts entgegenzusetzen, dann wahrhaftig setzt diese Dokumentation gefestigte Kenntnisse über Netzwerke und TCP/IP voraus. Die meisten Besitzer einer Spielkonsole geben jedoch wenig darauf, sich dieses Wissen in einem langwierigen Prozess anzueignen. Mir selber ist es nahezu unmöglich, die vorgetragenen Informationen auch für Leute, die keine Ahnung von TCP/IP haben, aufzubereiten. Da müsste ich mit den grundlegenden Sachen der modernen Netzwerktechnik beginnen. Ich denke, dass genügend Bücher über dieses Thema geschrieben wurde. Siehe das Literaturverzeichnis im Anhang.
Trotzdem habe ich mich bemüht, in der FAQ im Anhang, die seit der Version 2 dieses Dokuments neu hinzugekommen ist, die grundlegenden Fragen zur TCP/IP-Implementierung der Xbox kurz und bündig zu beantworten. Wer zusätzliche Informationen möchte, der wird direkt auf die entsprechenden Kapitel dieser Dokumentation verwiesen. Dort werden die jeweiligen Themen detaillierter behandelt und weiter ausgeführt.
Marc Ruef <marc.ruef@computec.ch>
Wettingen, Februar 2003
http://www.computec.ch

Danksagung

Sämtlichen Mitgliedern der xbox-crew.de und den Freunden auf meiner Buddy-Liste möchte ich meinen Dank für die freundliche Aufnahme und Unterstützung aussprechen. Unzählige Stunden haben wir mit dem Spielen und Chatten über Xbox Live verbracht. Dies macht nach wie vor sehr viel Spass und ich freue mich schon auf das nächste Mal "Tom Clancy Ghost Recon".
Vielen Dank an JOHND03 für seine wertvollen Anregungen im Forum arealive.de, Pascal C. Kocher für seine Ergänzungen zum Kerberos-Kapitel und Werner Ferstl den Hinweis in punkto ICMP echo request-Verhalten. Bei Jörg Mayer muss ich mich dafür bedanken, dass er mich auf einige kleinere faktische Fehler hingewiesen hat.
Auch wenn ich mich eher zum Linux/UNIX-Lager zähle und eingeschworener Anhänger der Sony Playstation war, muss ich Microsoft ein Lob für die sehr gelungene Xbox und das Live-System aussprechen. Diese Konsole kann ich, im Gegensatz zu fast allen anderen Microsoft-Produkten, uneingeschränkt empfehlen.
Ich muss mich schlussendlich bei alcom.ch bedanken, die mir frühzeitig das Xbox Live Starter Kit haben zukommen lassen. Ohne sie hätte ich noch viel länger warten müssen, bis ich meine Xbox Internet-tauglich machen konnte.
Bei Max Moser möchte ich mich dafür bedanken, dass er mich in die Geheimnisse der Mod-Chips für die Xbox eingeweiht hat. Ohne ihn hätte ich mich wohl kaum intensiver mit der Technologie der Microsoft-Konsole beschäftigt.
Ebenso ein dickes Dankeschön an meinen Vater, der mir in Punkto Kreditkarte ausgeholfen und mich beraten hat. Ich habe Dich ganz fest lieb.

1. Einführung

Diese Facharbeit beschäftigt sich ausschliesslich mit der TCP/IP-Implementierung der Microsoft Xbox. Ein Grossteil dieser Arbeit macht die Analyse des generierten Netzwerkverkehrs aus. Um diesen visualisieren zu können, habe ich klassische Diagnose-Utilities benutzt [Stevens 1994, Ruef et al. 2002]:

[tcpdump] Die meisten Mitschnitte, wenn es vorwiegend um die Richtung und Art des Datenauschtauschs geht, werden durch tcpdump dargestellt.

[ngrep] Ist der Datenteil eines Pakets interessant - zum Beispiel bei der Kerberos-Authentiserung in Kapitel 9 -, ziehen wir ngrep zurate.

Kommando-Eingaben, die von unserer Seite umgesetzt wurden, werden fettgedruckt dargestellt. In einigen Bildschirm-Ausgaben finden sich am linken Rand zweistellige Zahlen. Diese sind nicht Teil der eigentlichen Mitschnitte, sondern werden zur einfacheren Referenzierung genutzt. Die folgende tcpdump-Ausgabe demonstriert diese Darstellung [Stevens 1994, Northcutt et al. 2000, Ruef et al. 2002]:
01 debian:~# tcpdump -n
02 tcpdump: listening on eth0
03 22:55:08.904080 207.46.246.6.3074 > 192.168.0.2.3074: udp 24
04
05 1 packets received by filter
06 0 packets dropped by kernel
Die Interpretation solcherlei Mitschnitte setzt ein solides Hintergrundwissen zu TCP/IP und die Kenntnisse der Funktionsweise von tcpdump voraus. Entsprechendes Verständnis kann in der einschlägigen Literatur erworben werden. Siehe dazu das Literaturverzeichnis am Anhang dieser Publikation.
Zusätzlich bediene ich mich sogenannter Timelines, die erstmals in den Netzwerk-Büchern von Richard W. Stevens aufgetaucht sind [Stevens 1990, 1994]. Ich habe die Darstellung jedoch ein wenig für meine Bedürfnisse angepasst. Dabei blieb trotzdem das Prinzip des Client und Servers gleich: Auf der linken Seite findet sich der Client und auf der rechten Seite der Server. Jenachdem werden diese Parteien genauer spezifiziert (z.B. Xbox oder as.xboxlive.com). Die vertikalen Pfeile mit der Spitze nach unten symbolisieren den Zeitverlauf der Kommunikation. Der Datenaustausch wird durch die horizontalen Pfeile angegeben. Die Pfeilspitze definiert dabei die Richtung des Transfers. Die ausgetauschten Pakete werden in der Regel mit knappen Worten beschriftet (z.B. "ICMP echo request"). Die verschiedenen Stati - sofern es die zu erwähnen gilt - werden in der zusätzlich auf der rechten Seite des Diagramms dargestellt. Die Abbildung 1.1 (Beispiel für eine Timeline) visualisiert diese Darstellungsweise:

Abbildung 1.1: Beispiel für eine Timeline
Der Aufbau des Testnetzwerks ist relativ simpel gehalten. Die folgende Abbildung versucht dies zu illustrieren.

Abbildung 1.2: Das Standard-Testnetzwerk

Die logische Unterteilung erfolg zwischen dem LAN (Local Area Network), dem Internet und Microsoft-Netzwerk. Dem LAN wird nach RFC 1918 das private Klasse C-Netzwerk 192.168.0.0/24 zugeteilt [Rekhter et al. 1996]. Die IP-Adressvergabe erfolgt dabei durch DHCP (Dynamic Host Configuration Protocol) [Stevens 1994, Comer 1995]. Zum LAN gehören die folgenden vier Elemente, die jeweils von extern nach intern aufgelistet werden. Die IP-Adresse(n) - sofern vorhanden - finden sich nach dem Namen.

Cisco Kabelmodem

NetGear FM114P; 192.168.0.1/24 und 12.34.56.78

Microsoft Xbox; 192.168.0.2/24

Debian GNU/Linux; 192.168.0.3/24

Windows XP Professional; 192.168.0.4/24

Das Cisco Kabelmodem verbindet das LAN mit dem ISP (Internet Service Provider). In unserem Falle ist dies eine 256/128 KBit/Sek.-Verbindung zu CableCom/Swissonline. Auf der NetGear-Firewall werden keine restriktiven Regeln appliziert, so dass nicht aus Versehen wichtiger Datenverkehr unterbunden werden könnte. Sie fungiert also eher als Router, der NAT (Network Address Translation) umsetzt. Der Mittelpunkt des LANs macht der NetGear Hub aus. Dieser unterstützt zwar 10 und 100 MBit, wobei jedoch sämtliche Elemente mit 100 Mbit arbeiten.
Die Microsoft Xbox ist eine der ersten Generation. Diese habe ich kurz nach der Einführung der PAL-Versionen in der Schweiz gekauft. Eine Modifizierung (z.B. Einbau eines ModChips oder Wechsel des IDE-Kabels) habe ich vorerst nicht vorgenommen. Es handelt sich also um eine Standard-Xbox. Wenn nicht anders angegeben, dann werden die Tests mit der deutschen PAL-Version des Spiels "Tom Clancy Ghost Recon" durchgeführt. Dies habe ich deshalb gewählt, weil ich mich am besten damit auskenne.

Abbildung 1.3: Das Spiel "Ghost Recon"

Das Linux-System mit der IP-Adresse 192.168.0.3 ist in erster Linie für die Protokoll-Analysen zuständig. Dort werden die entsprechenden Diagnose-Tools (tcpdump und ngrep) betrieben und die Mitschnitte erstellt. Zudem werden gleichzeitig von diesem System Angriffe gefahren. Vorzugsweise kommen klassische Anwendungen wie ping, traceroute und nmap zum Einsatz. Ebenso werden vom Windows-System mit der IP-Adresse 192.168.0.4 einige Zugriffe durchgeführt.
Dem Internet werden sämtliche Hosts zugeteilt, die sich im Internet befinden und weder dem LAN noch dem Microsoft-Netzwerk zugeteilt werden können. Dabei befinden sich natürlich sämtliche Nameserver, die für die Umwandlung von IP-Adressen und Hostnamen zuständig sind, in diesem Netzwerkabschnitt. Systeme, die nicht direkt mit dem Xbox Live-System oder den in dieser Dokumentation festgehaltenen Tests in Verbindung stehen, werden nicht dargestellt. Im Microsoft-Netzwerk findet sich primär das System mit dem Namen as.xboxlive.com.

2. Das Verhalten bei ICMP-Zugriffen

Erstaunlicherweise reagiert die Xbox nicht auf ICMP echo request-Anfragen während des produktiven Betriebs. Es ist somit nicht möglich, die Erreichbarkeit eines Xbox-Systems mit der Hilfe solcher Diagnose-Pakete (ping) zu überprüfen. Auf sämtlichen Systemen wird ein Paketverlust von 100 % angezeigt [Stevens 1994], wie die folgende Ausgabe eines Ping-Zugriffs unter Windows XP Professional zeigt:

C:\Dokumente und Einstellungen\mruef>ping 192.168.0.2
Ping wird ausgeführt für 192.168.0.2 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 192.168.0.2:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),
Bis zur Version 2.4 dieses Dokuments ging ich davon aus, dass im Kernel der Xbox keinerlei Routine für die korrekte Behandlung von ICMP echo request-Anfragen nach RFC 792 [Postel 1981, Stevens 1994, Comer 1995, Northcutt et al. 2000, Arkin 2001, Ruef et al. 2002] implementiert worden ist. Dies verwunderte mich, denn geht so ein wichtiges Werkzeug für die Netzwerkdiagnose verloren.
Abbildung 2.1: Ping-Verhalten der Xbox während des Spielens
Werner Ferstl machte mich dann jedoch am 7. April 2003 mit einem privaten Email darauf aufmerksam, dass meine Einschätzung nicht ganz korrekt ist:
[...] habe aber festgestellt das sich meine XBox sehr wohl durch ein "ping" erreichen lässt! Und zwar ab genau dem Moment in dem im Dashboard "IP Adresse eingestellt" erscheint, aber noch vor der DNS Auflösung. Es dürfte so sein das die XBox die Netzwerkeinstellungen erst dann vornimmt wenn man sich bei Live einzuloggen verucht.
Meine Tests ergaben, dass diese Annahme absolut richtig war. Ich startete auf einem meiner Linux-Systeme einen kontinuierlichen Ping mit der Eingabe von "ping 192.168.0.2". Die Antworten blieben aus; also eine Zeitüberschreitung der Anforderung. Ging ich dann ins Dashboard, wählte "Xbox Live", dann "Network Setup" und klickte auf "Connect", vollzog die Xbox die Überprüfungen, wie ich sie in Kapitel 7 (Verbindung testen) festgehalten habe. Nachdem der Punkt "IP Settings Configured" auf dem Bildschirm erschien, konnte jedoch der Ping-Zugriff erfolgreich durchgeführt werden. Die Xbox antwortete auf die ICMP echo request-Anfragen schön artig mit den gewünschten ICMP echo reply-Rückantworten:
C:\Dokumente und Einstellungen\mruef>ping 192.168.0.2
Ping wird ausgeführt für 192.168.0.2 mit 32 Bytes Daten:
Antwort von 192.168.0.2: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.2: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.2: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.2: Bytes=32 Zeit<1ms TTL=64
Ping-Statistik für 192.168.0.2:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
Interessant ist der Time-to-Live Wert von 64, der auch bei UDP-Verkehr standardmässig gesetzt wird, wie wir in Kapitel 13 (Time-to-Live Werte) noch genauer sehen werden. Dieses Ping-Verhalten blieb so lange bestehen, bis man den Verbindungs-Test wieder verlief. Sodann konnten keine Pings mehr durchgeführt werden. Diese Entscheidung bei der Entwicklung ist nachvollziehbar. Die meisten Benutzer der Xbox werden aufgrund des fehlenden Wissens über Netzwerke die Diagnose den Spezialisten (z.B. Microsoft Hotline) überlassen. Ist es dann wirklich so weit, dass eine Analyse durchgeführt werden muss, hat der Benutzer halt seine Xbox kurzzeitig in einen diagnosefreundlichen Status zu schalten. Während normalen Spielen mittels Live ist dies jedoch nicht mehr nötog. Da ist es aus Sicherheitsgründen keine schlechte Wahl, dass man auf das Antworten auf ICMP echo request-Anfragen verzichtet. Die meisten Angriffstools und Skript-Kiddies werden also gar nicht erst die besagte Xbox ausmachen können.
Ich werde im weiteren Verlauf dieser Publikation weitere Mapping-Zugriffe mittels ICMP echo request-Anfragen unterbinden, um Komplikationen und fehlerhaften Resultaten aus dem Weg zu gehen. Dies geschieht beispielsweise mit der Option "-P0" von nmap [Ruef 2000, 2001, Ruef et al. 2002, Rogge 2002].
Wie vorherzusehen ist, antwortet die Xbox auch nicht auf ICMP timestamp- und address mask-Anfragen [Postel 1981, Stevens 1994, Comer 1995, Northcutt et al. 2000, Arkin 2001, Ruef et al. 2002]. Ich sah mich nicht in der Lage, mit den entsprechenden Parametern bei hping2 die gewünschten Rückantworten zu provozieren:
debian:~# hping2 -c 3 --icmp-addr 192.168.0.2
HPING 192.168.0.2 (eth0 192.168.0.2): icmp mode set, 28 headers + 0 data bytes
--- 192.168.0.2 hping statistic ---
3 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Auch mit traceroute konnte ich keine ICMP time exceeded in-transit-Fehlermeldung provozieren [Postel 1981, Stevens 1994, Comer 1995, Northcutt et al. 2000, Arkin 2001, Ruef et al. 2002]. Hierzu habe ich ein UDP-Datagramm mit einer TTL von 1 an die Xbox geschickt. Wie die folgende traceroute-Ausgabe verrät, blieb die erhoffte Rückantwort gänzlich aus:
debian:~# traceroute -p 3073 192.168.0.2
traceroute to 192.168.0.2 (192.168.0.2), 30 hops max, 38 byte packets
1 * * *
2 * * *
3 * * *

3. Das Verhalten bei TCP-Zugriffen

Als erstes muss ich vorausschicken, dass die Xbox ihre Vorgehensweise bei ICMP-Mapping auch bei TCP-Zugriffen beizubehalten versucht. Sie geht so spärlich wie möglich mit dem Antworten auf Anfragen um. Dabei ist der Netzwerkverkehr stets gleich, egal welche Scan-Technik eingesetzt wird. Die Xbox weigert sich standhaft auf TCP-Segmente mit gesetzter SYN-Flagge zu antworten - Auch auf ein alternatives RST-Segment wartet man vergebens [Stevens 1994, Comer 1995, Northcutt et al. 1995, Ruef et al. 2002].
tcptraceroute ist also vorerst nicht nutzbar. Zudem fallen Full-connect TCP-, half-open SYN- und ACK-Scans auch aus. Da keine Rückantworten erhalten werden - siehe den folgenden tcpdump-Mitschnitt -, weist nmap die jeweiligen Ports als "filtered" (dt. gefiltert) aus.
debian:~# tcpdump -n
tcpdump: listening on eth0
23:20:33.680874 192.168.0.3.32862 > 192.168.0.2.80: S 2576673064:2576673064(0) win 5808 <mss 1452,sackOK,timestamp 1665519 0,nop,wscale 0> (DF)
23:20:36.675815 192.168.0.3.32862 > 192.168.0.2.80: S 2576673064:2576673064(0) win 5808 <mss 1452,sackOK,timestamp 1665819 0,nop,wscale 0> (DF)
23:20:39.695877 192.168.0.3.32863 > 192.168.0.2.80: S 2591310272:2591310272(0) win 5808 <mss 1452,sackOK,timestamp 1666121 0,nop,wscale 0> (DF)
3 packets received by filter
0 packets dropped by kernel
Doch auch exotische Scan-Techniken versagen ihren Dienst. Bei FIN, Null- und Xmas-Scans werden sämtliche Ports aufgrund der fehlenden Rückantworten als "open" (dt. offen) deklariert [Ruef 2000, 2001, Ruef et al. 2002, Rogge 2002]. Die folgende Timeline illustriert, dass eine unangeforderte TCP-Abfrage grundsätzlich ignoriert wird. Dabei sind die gesetzten TCP-Flaggen absolut irrelevant.
Abbildung 3.1: Verhalten bei TCP-Anfragen
Da die Xbox standardmässig keine TCP-Dienste anbietet, konnte kein Drei-Wege-Handschlag im Rahmen von TCP beobachtet werden. Zur aktuellen Stunde ist es überhaupt fragwürdig, ob die TCP/IP-Implementierung der Xbox mit TCP-Verkehr umgehen kann. Ein solcher ist momentan nicht nötig, wie wir noch in Kapitel 7 (Verbindung testen) genauer sehen werden.
Ich kann mir nicht vorstellen, dass Microsoft gänzlich auf die Implementierung einer TCP-Routine verzichtet hat. Vielleicht wird dieses Transportprotokoll in Zukunft irgendwelche Verwendung finden (z.B. bei Content-Download). Es kann aber auch weiterhin sein, dass Microsoft ein transparentes Update der TCP/IP-Implementierung durch den Live-Dienst durchführt, so dass erst dann die notwendigen TCP-Routinen implementiert werden.

4. Das Verhalten bei UDP-Zugriffen

Die Xbox weigert sich auf ein UDP-Datagramm an einen geschlossenen Port mit der obligaten ICMP port unreachable-Fehlermeldung zu antworten [Stevens 1994, Comer 1995, Northcutt et al. 1995, Ruef et al. 2002]. Dieses Verhalten reiht sich nahtlos in jenes bezüglich ICMP- und TCP-Verkehr ein. Die folgende tcpdump-Ausgabe verdeutlicht, dass auf unsere UDP-Reize keinerlei Reaktion auszumachen sind:

debian:~# tcpdump -n
tcpdump: listening on eth0
21:34:12.783425 192.168.0.3.39374 > 192.168.0.2.80: udp 0
21:34:18.785850 192.168.0.3.39375 > 192.168.0.2.80: udp 0
2 packets received by filter
0 packets dropped by kernel
Als erstes sind Xbox-Benutzer deshalb vor dem relativ unpopulären UDP-Mapping geschützt (z.B. "nmap -P0 -sU -p80 192.168.0.2"). Zum zweiten sind keine traceroute-Zugriffe über UDP möglich (z.B. "traceroute -p53 192.168.0.2"). Drittens werden dadurch UDP-Portscans nichtig, da nicht zwischen erreichbaren und nicht erreichbaren UDP-Ports unterschieden werden kann (z.B. "nmap -s0 -sU 192.168.0.2"). Ein UDP-Portscan mit nmap weist daher sämtliche gescannten UDP-Ports als offen aus [Ruef 2000, 2001, Ruef et al. 2002, Rogge 2002]. Die folgende Timeline erläutert, dass auch bei geschlossenen UDP-Ports keine ICMP port unreachable-Fehlermeldung provoziert werden kann:
Abbildung 4.1: Verhalten bei UDP-Anfragen
Diese Entwicklungsentscheidung ist fragwürdig. Sehr wohl werden auf der Xbox UDP-Dienste angeboten, wie wir im Kapitel 14 (Ein Live-Spiel mit Ghost Recon) erstmals detailliert sehen werden. Die Chance ist jedoch sehr gering, dass ein falsch konfigurierter Client auf einen sich nicht im LISTENING-Modus befindlichen UDP-Port zugreifen möchte. Der Grund liegt darin, dass die meisten Clients aus Xbox-Spielen bestehen, die die Port-Informationen hardcodiert haben.

5. Die ARP-Implementierung

Die Xbox führt bei jedem Aufstarten eine ARP who-has Anfrage durch, wie man dies von netzwerkfähigen Elementen gewohnt ist [Plummer 1982, Stevens 1994, Comer 1995]. Damit wird die zuvor genutzte IP-Adresse auf ihre Einsatzfähigkeit überprüft. Wir illustrieren dies mit der folgenden tcpdump-Ausgabe. Bei dieser wurde zusätzlich die Option "-e" aktiviert, mit dem die Informationen des link-layers (Layer 2) abgebildet werden. Sodann können wir die Ethernet-Adressen der involvierten Systeme erkennen:

debian:~# tcpdump -e -n
tcpdump: listening on eth0
18:32:12.612584 0:50:f2:5f:19:13 Broadcast arp 60: arp who-has 192.168.0.2 tell 192.168.0.2
18:32:23.866223 0:50:f2:5f:19:13 Broadcast arp 60: arp who-has 192.168.0.2 tell 192.168.0.2
18:32:24.887055 0:50:f2:5f:19:13 Broadcast arp 60: arp reply 192.168.0.2 is-at 0:50:f2:5f:19:13
3 packets received by filter
0 packets dropped by kernel
Da bei ICMP, UDP und TCP keine direkten Rückantworten provoziert werden können, ist das sehr unpopuläre ARP-Mapping die mir einzige aktive Mapping-Methode für die Xbox. Die in Abbildung 5.1 dargestellte Timeline verrät das Prinzip dieses simplen Zugriffs.
Abbildung 5.1: Verhalten bei ARP-Mapping
Wir können dies durch die Eingabe von "arping -c 3 192.168.0.2" verifizieren. Hiermit wird ein ARP-Mapping mittels drei ARP who-hast Anfragen für das System mit der IP-Adresse 192.168.0.2 durchgeführt:
debian:~# arping -c 3 192.168.0.2
ARPING 192.168.0.2
60 bytes from 00:50:f2:5f:19:13 (192.168.0.2): index=0 time=44.107 usec
60 bytes from 00:50:f2:5f:19:13 (192.168.0.2): index=1 time=566.959 usec
60 bytes from 00:50:f2:5f:19:13 (192.168.0.2): index=2 time=558.972 usec
--- 192.168.0.2 statistics ---
3 packets transmitted, 3 packets received, 0% unanswered
Der tcpdump-Mitschnitt dieses Zugriffs verrät uns, dass die Xbox schön artig mit den gewünschten ARP is-at Rückantworten entgegnet:
debian:~# tcpdump -e -n arp
tcpdump: listening on eth0
20:28:53.754177 0:50:da:42:c:f3 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.2 tell 192.168.0.3
20:28:53.754245 0:50:f2:5f:19:13 0:50:da:42:c:f3 0806 60: arp reply 192.168.0.2 is-at 0:50:f2:5f:19:13
20:28:54.751645 0:50:da:42:c:f3 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.2 tell 192.168.0.3
20:28:54.751730 0:50:f2:5f:19:13 0:50:da:42:c:f3 0806 60: arp reply 192.168.0.2 is-at 0:50:f2:5f:19:13
20:28:55.751645 0:50:da:42:c:f3 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 192.168.0.2 tell 192.168.0.3
20:28:55.751725 0:50:f2:5f:19:13 0:50:da:42:c:f3 0806 60: arp reply 192.168.0.2 is-at 0:50:f2:5f:19:13
6 packets received by filter
0 packets dropped by kernel

6. Die unterstützten Protokolle

Die unterstützten Protokolle wurden mit dem Parameter "-sO" von nmap festgestellt [Ruef 2000, 2001, Ruef et al. 2002, Rogge 2002]. Die entsprechende Ausgabe verrät uns, dass sämtliche Protokolle unterstützt werden. Diese Information ist sicher falsch, denn in keinster Weise konnten wir beim tcpdump-Mitschnitt die erforderlichen Rückantworten der Xbox ausmachen.
Abbildung 6.1: Verhalten bei der Wahl eines IP-Protokolls
Einmal mehr bekräftigt dies, wie sparsam die Xbox mit der Herausgabe potentiell sensitiver Informationen umgeht. Dieses Verhalten ist sehr begrüssenswert.
debian:~# nmap -sP -P0 192.168.0.2
Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
Interesting protocols on xbox (192.168.0.2):
Protocol   State       Name
1          open        icmp
2          open        igmp
3          open        ggp
4          open        ip
5          open        st
[...]
250        open        unknown
251        open        unknown
252        open        unknown
253        open        unknown
254        open        unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 312.546 seconds
Bei diesem nmap-Durchlauf fällt uns in der letzten Zeile auf, wie lange dieser Zugriff doch gedauert hat. Rund 312 Sekunden (über 5 Minuten) benötigte nmap, um die Unterstützung der 255 (2^16-1) möglichen Protokolle herauszufinden.

7. Verbindung testen

Es gibt Situationen, in denen die Verbindung mit Xbox Live urplötzlich abbricht oder nicht zustande kommen kann. Die meisten Spiele weisen einem auf diesen Umstand mit einer Fehlermeldung hin. Bei dieser stehen meistens zwei weitere Vorgehen zur Auswahl:

Offline spielen
Verbindung testen

Fällt die Auswahl auf "Verbindung testen", wird das Spiel verlassen und in die Xbox Live-Kategorie des Dashboards gewechselt. Dort wird automatisiert eine Überprüfung der Verbindung initialisiert. Diese wollen wir uns mit der folgenden tcpdump-Ausgabe ansehen. Die zweistelligen Zahlen am linken Rand des Mitschnitts sind für die Referenzierung bei der danach folgenden Erläuterung und somit nicht Teil des eigentlichen tcpdump-Durchlaufs.

01 debian:~# tcpdump -n

02 tcpdump: listening on eth0

03 21:48:39.241954 arp who-has 192.168.0.2 tell 192.168.0.2

04 21:48:40.249966 arp reply 192.168.0.2 is-at 0:50:f2:5f:19:13

05 21:48:40.449292 arp who-has 192.168.0.2 tell 192.168.0.2

06 21:48:41.436759 arp who-has 192.168.0.2 tell 192.168.0.2

07 21:48:42.441712 arp who-has 192.168.0.2 tell 192.168.0.2

08 21:48:43.446652 arp who-has 192.168.0.2 tell 192.168.0.2

09 21:48:44.451602 arp who-has 192.168.0.2 tell 192.168.0.2

10 21:48:45.474690 arp reply 192.168.0.2 is-at 0:50:f2:5f:19:13

11 21:48:48.283987 arp who-has 192.168.0.2 tell 192.168.0.2

12 21:48:49.275347 arp who-has 192.168.0.2 tell 192.168.0.2

13 21:48:50.280292 arp who-has 192.168.0.2 tell 192.168.0.2

14 21:48:51.285240 arp who-has 192.168.0.2 tell 192.168.0.2

15 21:48:52.290185 arp who-has 192.168.0.2 tell 192.168.0.2

16 21:48:53.311698 arp reply 192.168.0.2 is-at 0:50:f2:5f:19:13

17 21:48:53.379389 192.168.0.2.1024 > 239.255.255.250.1900: udp 128

18 21:48:53.379397 192.168.0.2.1024 > 239.255.255.250.1900: udp 129

19 21:48:53.379778 arp who-has 192.168.0.1 tell 192.168.0.2

20 21:48:53.381859 arp reply 192.168.0.1 is-at 0:9:5b:c:58:b0

21 21:48:53.381894 192.168.0.2.1256 > 62.2.17.60.53: 45484+ A? AS.XBOXLIVE.COM. (33)

22 21:48:53.395984 62.2.17.60.53 > 192.168.0.2.1256: 45484 1/0/0 A 207.46.247.6 (49)

23 21:48:53.442838 192.168.0.2.1257 > 207.46.247.6.88: v5

24 21:48:53.820856 207.46.247.6.88 > 192.168.0.2.1257: v5

25 21:48:53.842868 192.168.0.2.1256 > 62.2.17.60.53: 45487+ A? TGS.XBOXLIVE.COM. (34)

26 21:48:53.856193 62.2.17.60.53 > 192.168.0.2.1256: 45487 2/0/0 CNAME as.XBOXLIVE.COM., (67)

27 21:48:53.870159 192.168.0.2.1257 > 207.46.247.6.88:

28 21:48:54.257299 207.46.247.6.88 > 192.168.0.2.1257:

29 21:48:54.390135 192.168.0.2.1024 > 239.255.255.250.1900: udp 128

30 21:48:54.390144 192.168.0.2.1024 > 239.255.255.250.1900: udp 129

31 21:48:55.389550 192.168.0.2.1024 > 239.255.255.250.1900: udp 128

32 21:48:55.389556 192.168.0.2.1024 > 239.255.255.250.1900: udp 129

33 21:48:56.407167 192.168.0.2.1024 > 239.255.255.250.1900: udp 128

34 21:48:56.407173 192.168.0.2.1024 > 239.255.255.250.1900: udp 129

35 21:48:57.405971 192.168.0.2.1024 > 239.255.255.250.1900: udp 128

36 21:48:57.405976 192.168.0.2.1024 > 239.255.255.250.1900: udp 129

37 21:48:58.402612 192.168.0.2.1024 > 239.255.255.250.1900: udp 128

38 21:48:58.402618 192.168.0.2.1024 > 239.255.255.250.1900: udp 129

39 21:48:59.405541 192.168.0.2.3074 > 207.46.246.6.3074: udp 1404

40 21:49:01.335013 192.168.0.2.3074 > 207.46.246.6.3074: udp 1404

41 21:49:03.344907 192.168.0.2.3074 > 207.46.246.6.3074: udp 1404

42 21:49:05.354810 192.168.0.2.3074 > 207.46.246.6.3074: udp 1404

43 21:49:07.363720 192.168.0.2.3074 > 207.46.246.6.3074: udp 1404

44

45 41 packets received by filter

45 0 packets dropped by kernel

03-16 Kabelanschluss und IP-Adresse mittels ARP testen

Plummer 1982

Stevens 1994

Comer 1995

Sehr wahrscheinlich möchte Microsoft an dieser Stelle ganz sicher gehen, dass aufgrund hoher Netzwerkauslastung die entsprechenden ARP-Anfragen verloren gehen könnten, und so das Resultat dieses ersten Checks verfälscht werden könnte. Mit einer Verfälschung und der daraus erforderlichen Netzwerkdiagnose sind die meisten Xbox Live-Benutzer aufgrund fehlender TCP/IP-Kenntnisse überfordert.

17-18 Multicasting überprüfen

Eine whois-Überprüfung dieses Adressbereichs weist darauf hin, dass der Adressblock 224.0.0.0/4 für spezielle Zwecke reserviert wurde. Weiterführende Informationen finden sich in RFC 2365 [Meyer 1998] und 3171 [Albanna et al. 2001]. RFC 2365 führt in Absatz 6.1 (The IPv4 Local Scope -- 239.255.0.0/16) ganz genau aus, für was dieser IP-Adressbereich vorgesehen ist:

239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local

Scope is the minimal enclosing scope, and hence is not further

divisible. Although the exact extent of a Local Scope is site

dependent, locally scoped regions must obey certain topological

constraints. In particular, a Local Scope must not span any other

scope boundary. Further, a Local Scope must be completely contained

within or equal to any larger scope. In the event that scope regions

overlap in area, the area of overlap must be in its own local scope.

This implies that any scope boundary is also a boundary for the Local

Scope. The more general topological requirements for administratively

scoped regions are discussed below.

RFC 3171 fasst dies nocheinmal in Absatz 2 (Definition of Current Assignment Practice) mit einer kurzen Tabelle zusammen:

Unlike IPv4 unicast address assignment, where blocks of addresses are

delegated to regional registries, IPv4 multicast addresses are

assigned directly by the IANA. Current assignments appear as follows

[IANA]:

224.0.0.0 - 224.0.0.255 (224.0.0/24) Local Network Control Block
[...]

Dieser Datenverkehr ist also für die Überprüfung von Multicasting erforderlich. Dabei wird der Kontroll-Adressblock des lokalen Netzwerks angeschrieben. Dieser Datenverkehr hat laut Kapitel 3 von RFC 3171 das lokale Netzwerk nicht zu verlassen [Albanna et al. 2001]:

Addresses in the Local Network Control block are used for protocol

control traffic that is not forwarded off link. Examples of this

type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].

Wenn wir den Datenteil der Multicast-Pakete an den Zielport 1900 betrachten, dann sehen wir Folgendes. Wir haben hier mit ngrep einen UPNP-Zugriff (Universal Plug and Play) aufgezeichnet:

U 192.168.0.2:1025 -> 239.255.255.250:1900

M-SEARCH * HTTP/1.1..Host:239.255.255.250:1900..ST:urn:schemas-upnp-org:ser

vice:WANIPConnection:1..Man:"ssdp:discover"..MX:2....

19-20 ARP-Auflösung des Gateways

0:9:5b:c:58:b0

21-22 Adressauflösung für as.xboxlive.com

Kapitel 8 (Das System as.xboxlive.com)

Konnte dieser Schritt erfolgreich durchgeführt werden, dann wird im Test-Menü des Dashboards die Meldung "DNS resolved" auftauchen. Einer Namens- und Adressauflösung mittels DNS steht somit nichts im Weg [Stevens 1994, Comer 1995].

23-24 Erste Authentisierung mittels Kerberos v5

Kapitel 9 (Die Kerberos-Authentisierung)

as

25-26 Adressauflösung für tgs.xboxlive.com

tgs

Das es sich bei der Authentifizierung um Kerberos handelt, könnte man davon ausgehen, dass es sich beim host tgs.xboxlive.xom um den Ticket Granting Server (Service) handelt, wie in RFC 1510 beschrieben.

Die Rückantwort verrät uns, dass dieser Host der gleiche ist, wie das zuvor identifizierte System as.xboxlive.com. Da es sich bei meinen Versuchen bei den Systemen as.xboxlive.com und tgs.xboxlive.com um die gleichen Hosts handelt, werde ich nicht gross zwischen den beiden Unterscheiden. Es ist damit zu rechnen, dass Microsoft bei einem grösseren Ansturm auf Xbox Live die beiden Hosts trennen wird, um eine Last-Verteilung zu erreichen.

27-28 Zweite Authentisierung mittels Kerberos

Nun erfolgt eine zweite Authentifizierung mittels Kerberos. Diese will voraussichtlich mit dem System tgs.xboxlive.com durchgeführt. Da die Systeme as und tgs die gleichen sind, erfolgt nun eine Wiederholung der ersten Authentifizierung (Zeilen 23-24).

29-38 Multicasting zum zweiten Mal überprüfen

Komischerweise findet an dieser Stelle wieder der gleiche Multicasting-Verkehr statt, wie wir ihn in den Zeilen 17 und 18 kennengelernt haben. Diesesmal ist er jedoch viel ausgedehnter. Er umfasst nun fünf UDP-Datagramme à 128 und fünf à 129 Bytes. Es werden zwei Anfragen pro Sekunde versendet.

39-43 UDP-Verkehr mit tgs.xboxlive.com

Kapitel 10 (Der Port 3074)

8. Das System as.xboxlive.com

Eine wichtige Aufgabe bei der Einwahl in Xbox Live übernimmt das System mit dem Namen as.xboxlive.com. Wie wir in Kapitel 9 (Die Kerberos-Authentisierung) noch sehen werden, wird mit diesem in einer frühen Phase die Kerberos-Authentisierung durchgeführt. Aber auch andere Kommunikationen finden momentan zwischen der Xbox und diesem Rechner statt (wahrscheinlich erfolgt bald eine Aufteilung zu Gunsten von tgs.xboxlive.com). Eine whois-Abfrage [Stevens 1994] für dieses System ergibt, dass es sich im IP-Adressbereich von Microsoft befindet:
mruef@debian:~# whois 207.46.247.6
OrgName:    Microsoft Corp
OrgID:      MSFT
NetRange:   207.46.0.0 - 207.46.255.255
CIDR:       207.46.0.0/16
NetName:    MICROSOFT-GLOBAL-NET
NetHandle: NET-207-46-0-0-1
Parent:     NET-207-0-0-0-0
NetType:    Direct Assignment
NameServer: DNS1.CP.MSFT.NET
NameServer: DNS2.CP.MSFT.NET
NameServer: DNS1.TK.MSFT.NET
NameServer: DNS1.DC.MSFT.NET
NameServer: DNS1.SJ.MSFT.NET
Comment:
RegDate:    1997-03-31
Updated:    2002-12-05
TechHandle: ZM39-ARIN
TechName:   Microsoft
TechPhone: +1-425-936-4200
TechEmail: noc@microsoft.com
OrgTechHandle: MSFTP-ARIN
OrgTechName:   MSFT-POC
OrgTechPhone: +1-425-882-8080
OrgTechEmail: iprrms@microsoft.com
# ARIN Whois database, last updated 2003-02-03 20:00
# Enter ? for additional hints on searching ARIN's Whois database.
Am 5. und 6. Februar 2003 führte ich erstmals einen traceroute-Zugriff auf diesen Host durch, um sämtliche Hops zwischen der Xbox und diesem Microsoft-System ausmachen. Ein tcptraceroute hat von vornherein nicht funktioniert. Dann war bin ich ein bisschen erstaunt, dass scheinbar wenigstens die beiden klassischen ICMP- und UDP-Varianten von traceroute-Zugriffen zum Erfolg führen würden [Stevens 1994, McClure et al. 1999, Northcutt et al. 2000, Ruef 2001]:
debian:~# traceroute 207.46.247.6
traceroute to 207.46.247.6 (207.46.247.6), 30 hops max, 38 byte packets
1 10.225.64.1 (10.225.64.1) 11.802 ms 11.426 ms 13.563 ms
2 gig-15-0.blxOTF001.cablecom.net (62.2.24.221) 15.307 ms 13.853 ms 14.056 ms
3 pos1-0-0.ar1.ZRH1.gblx.net (62.24.33.149) 16.946 ms 12.775 ms 14.291 ms
4 pos3-1-622M.cr1.CDG2.gblx.net (64.215.37.45) 36.646 ms 33.951 ms 55.183 ms
5 pos0-0-2488M.cr2.SEA1.gblx.net (64.215.195.2) 194.221 ms 195.996 ms 194.903 ms
6 so1-0-0-2488M.br2.SEA1.gblx.net (64.213.83.182) 199.115 ms 200.328 ms 201.608 ms
7 208.51.243.22 (208.51.243.22) 195.000 ms 196.252 ms 193.863 ms
8 207.46.33.229 (207.46.33.229) 194.617 ms 199.143 ms 198.417 ms
9 207.46.36.78 (207.46.36.78) 198.107 ms 192.298 ms 194.027 ms
10 207.46.155.13 (207.46.155.13) 196.868 ms 200.545 ms 196.047 ms
11 207.46.224.145 (207.46.224.145) 195.751 ms 203.772 ms 196.013 ms
12 207.46.225.10 (207.46.225.10) 207.925 ms !A * 210.846 ms !A
Beim näheren Hinblicken registrierte ich jedoch, dass das System mit der IP-Adresse 207.46.225.10 das letzte war, das auf die Zugriffe geantwortet hat. Zudem folgt nach der Zeitangabe in Millisekunden das Zeichen "!A", das darauf hindeutet, dass der Zugriff zum Host oder Netzwerk nicht gestattet ist. Eine Analyse mit tcpdump verrät uns, was für eine ICMP-Fehlermeldung wir erhalten:
debian:~# tcpdump -n icmp
tcpdump: listening on eth0
19:14:27.187122 207.46.225.10 > 192.168.0.3: icmp: host 207.46.247.6 unreachable - admin prohibited filter
1 packets received by filter
0 packets dropped by kernel
Nämlich eine ICMP host unreachable - admin prohibited für das System mit der IP-Adresse 207.46.247.6. Diese Nachricht wird vom System mit der IP-Adresse 207.46.225.10, das letzte System in der traceroute-Ausgabe, ausgegeben. Es handelt sich hierbei also um ein Firewall-Element (z.B. ein Router mit Zugriffskontrollliste oder ein dediziertes Firewall-System) [Ruef et al. 2002].
Meine Tests mit traceroute wollte ich am 7. Februar 2003 nocheinmal durchführen und erweitern. Dabei ist mir aufgefallen, dass von nun an keine ICMP-tracerouteings mehr möglich sind. Die folgende Ausgabe des entsprechenden Zugriffs auf Windows XP Professional verdeutlicht dies. Es scheint, als hätte es von der Nacht des 6. auf den 7. Februar 2003 eine Änderung im Netzwerk-Aufbau zum System as.xboxlive.com gegeben.
C:\Dokumente und Einstellungen\mruef>tracert 207.46.247.6
Routenverfolgung zu as.xboxlive.com [207.46.247.6] über maximal 30 Abschnitte:
1     9 ms    10 ms     8 ms 10.225.64.1
2     9 ms    10 ms    10 ms gig-15-0.blxOTF001.cablecom.net [62.2.24.221]
3     9 ms     9 ms    11 ms pos1-0-0.ar1.ZRH1.gblx.net [62.24.33.149]
4    31 ms    31 ms    35 ms pos3-1-622M.cr1.CDG2.gblx.net [64.215.37.45]
5   194 ms   196 ms   195 ms pos0-0-2488M.cr2.SEA1.gblx.net [64.215.195.2]
6   195 ms   195 ms   196 ms so1-0-0-2488M.br2.SEA1.gblx.net [64.213.83.182]
7   190 ms   190 ms   193 ms 208.51.243.22
8   191 ms     *        *     207.46.33.229
9     *        *        *     Zeitüberschreitung der Anforderung.
10     *        *        *     Zeitüberschreitung der Anforderung.
11     *        *        *     Zeitüberschreitung der Anforderung.
12 ^C
Dies deutet bisher alles darauf hin, dass das Zielsystem durch ein Firewall-System geschützt wird. Das Versagen des Traceroutings mittels TCP kann auf einen Fehler im Kabelnetzwerk meines ISPs zurückzuführen sein. Ein Ping-Zugriff bestärkt unsere Annahme, dass die Kommunikation von der Gegenseite aus Sicherheitsgründen eingeschränkt wird. Wir erhalten 100 % Paketverlust.
C:\Dokumente und Einstellungen\mruef>ping 207.46.247.6
Ping wird ausgeführt für 207.46.247.6 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 207.46.247.6:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust),
Entweder werden unsere ICMP echo request-Anfragen verworfen, das Zielsystem will/kann nicht auf diese Antworten oder die ICMP echo reply-Rückantworten werden auf ihrem Rückweg behindert. Aus Erfahrung weiss ich, dass nahezu alle öffentlichen Systeme von Microsoft nicht auf ICMP echo request-Anfragen zu antworten pflegen. Bestes Beispiel hierfür ist www.microsoft.com, das selbst in der man-Page von nmap zum Thema ICMP-Mapping aufgelistet wurde [Fyodor 2000]. Es scheint also eine Richtlinie der Firma Microsoft zu sein, die öffentlichen Systeme möglichst restriktiv in Bezug auf ICMP arbeiten zu lassen.
-P0   Verhindert das Pingen eines Hosts, bevor er gescannt wird. Dies ermoeglicht das Scannen von Netzwerken, die keine ICMP echo requests (oder responses) aufgrund einer restriktiv konfigurierten Firewall zulassen. microsoft.com ist ein Beispiel fuer ein solches Netzwerk, in dem diese Funktion stets genutzt werden sollte. Gebrauchen Sie -P0 oder -PT80 wenn ein Portscan gegen microsoft.com durchgefuehrt werden soll.
Ich werde mich hier nicht weiter mit den Möglichkeiten des Systems as.xboxlive.com befassen. Der Titel dieser Abhandlung lässt vermuten, dass die TCP/IP-Implementierung der Xbox im Mittelpunkt steht. Wir wenden uns also schon nur alleine aus diesem Grund vom System as.xboxlive.com ab.

9. Die Kerberos-Authentisierung

Die Kerberos-Authentisierung findet als erstes zwischen der Xbox und dem System mit dem Namen as.xboxlive.com statt. Schon alleine der Hostname "as" lässt vermuten, dass es sich hierbei um den Authentication-Server handelt. In Kapitel 8 (Das System as.xboxlive.com) haben wir uns schon ein bisschen intensiver mit diesem Host beschäftigt. Die Kerberos-Authentisierung benutzt den UDP-Zielport 88; als Quellport wird ein kurzlebiger Port über 1023 ausgewählt. In unserem Beispiel konnten wir zwei Kerberos-Authentisierungen ausmachen: Die Zeilen 23-24 und 27-28. Danach fand der eigentliche Datenaustausch über den Game-Port udp/3074 statt [IANA 2003]. Diesen Port besprechen wir in Kapitel 10 (Der Port 3074) genauer. Die folgende Timeline illustriert diese drei Stufen.
Abbildung 9.1: Die Kerberos-Authentisierung
In der Analyse der Kerberos-Authentisierung, die durch unsere Xbox initialisiert wird, fallen im ersten Datagramm die Daten auf, die im Klartext übertragen werden. So finden sich die Versions-Nummer der Xbox. In unserem Fall ist dies "1.00.4831.5". Danach folgt eine Titel-Angabe mit einem hexadezimalen Wert von "0xFFFE0000" und einer Versionsnummer von "268595456". Ich dachte zuerst, dass sich diese Daten auf das eingelegte Spiel beziehen. Als ich jedoch im April 2003 ausgiebige Tests mit vier verschiedenen Live-Titel machte, musste ich bemerken, dass alle Spiele den gleichen Wert - nämlich 0x49470024 - übertragen. Den Wert der ersten Tests während der Beta-Phase Anfang 2003, 0xFFFE0000, konnte ich nicht mehr reproduzieren. Zwei Zeilen weiter unten findet sich eine Seriennummer, die mit dem Akronym SN angekündigt wird ("314228520803@xbox.com"). Hierbei handelt es sich um die Seriennummer der Xbox selbst. Auf der gleichen Zeile fällt das erste Mal auf, dass das Passport.net-System von Microsoft irgendwie mitspielt.
Im zweiten Datagramm sehen wir auf den ersten Blick nichts neues. Insgesamt wird das Wort PASSPORT.NET vier Mal übertragen. Jeweils auf der ersten und zweiten Zeile. In der ersten Zeile wird zudem die Seriennummer der Xbox, die zuvor durch unser System verschickt wurde, gespiegelt.
debian:~# ngrep
interface: eth0 (192.168.0.0/255.255.255.0)
U 192.168.0.2:1257 -> 207.46.247.6:88
j...0.................0...0:.......2.0.%.......90^<.....ah......Q'...eo+...
.~7(..G....0_.......W.U.o&...'.....].u(I..2Xbox Version=1.00.4831.5 Title=0
xFFFE0000 TitleVersion=268595456.0H......A.?0=......6.4..>..N......0.].....
.jLu.._c.h..8.....s....."....(..0...........0........0..........0..........
..%0#.......0...SN.314228520803@xbox.com....PASSPORT.NET..0........0...krbt
gt..XBOX.COM....20370913024905Z......W...0....
#
U 207.46.247.6:88 -> 192.168.0.2:1257
k...0.................PASSPORT.NET.301......*0(..SN.314228520803@xbox.com..
PASSPORT.NET....a...0............PASSPORT.NET..0........0...krbtgt..XBOX.CO
M....0................{...w...r.`e.'.b?.%.4.....x...t..........."..:.X|...I
..`\g....r..>~.....v.z....e.........M...2x...)..D.Y.x.|......>...f. [O...ga
..... .WZzXX....}.NF.B..s..j\.m..4^.`....Bq....XWa.o..0..GB......j.-..h.._.
.,A...w.c8w..,...c.;.5.g....P.Y..R....h!...3f....P.9d..O...#..lq....O .'..3
^Ua.._.\M.......o.......kB.....j>~6o.|(.....&.d.l6....@.Ig....N........@..F
..Ebl...n...5.FY.(....G......0..................A.....HY..*?...:..Ic..?N.#
.JGi...Z..W1V.w...\..{.z.....T...!.......$.m.....f..z:..h~.3..Q.=...zN..9..
)....&.b.d.Q..@...A......qT.....*7V.......*...x......'5wzH=.....xI,R...D...
..!..E.`........ir...*f..wn.ZO...N
exit
3 received, 0 dropped
Das Abfangen dieser Seriennummer kann unter Umständen für einen Angreifer von Vorteil sein. Momentan ist ihm dadurch der Xbox-Support bei Microsoft gewährleistet (siehe http://www.xbox.com). Zudem war durch die Angabe der Seriennummer der Xbox erst die Teilnahme am Beta-Test von Xbox Live möglich. Es ist abzuwarten, ob auch zusätzliche Angebote und Vorteile durch den Besitz dieser Nummer gegeben sein werden. Entsprechend würde sich der Wert der Seriennummer verändern.

10. Der Port 3074

Der Port 3074 spielt beim Xbox Live-System eine wichtige Rolle. Schauen wir uns die Ausgabe Februar 2003 der Portliste der IANA an, so sehen wir, dass sich Microsoft offiziell den TCP- und UDP-Port 3074 registriert hat [IANA 2003]:
xbox            3074/tcp   Xbox game port
xbox            3074/udp   Xbox game port
#                          Damon Danieli <damond@microsoft.com>
Wir werden in den kommenden Kapiteln sehen, dass praktisch sämtliche Kommunikationen im Spiel-System von Xbox Live über den UDP-Port 3074 ausgetragen werden. Dabei wird meistens nicht nur der Ziel-, sondern auch der Quellport auf diese Zahl gesetzt. Dies ist verwunderlich, denn die meisten Client/Server-Dienste pflegen eine dynamische Quellport-Zuweisung zu nutzen [Stevens 1990]. Ausnahmen hierbei sind jedoch Lösungen wie BOOTP und DHCP [Stevens 1994, Comer 1995].
Da diesem Port eine solch hohe Wichtigkeit beigemessen wird, gilt es diesen auf etwaigen Firewall-Systemen freizuschalten [Ruef 2001, Ruef et al. 2002]. Zudem muss ein Nameserver zugänglich und der Kerberos-Dienst (udp/88) freigeschalten sein, um in den Genuss von Xbox Live zu kommen.

11. Kontrollpakete

Befinden wir uns noch einige Minuten im abgeschlossenen Menü des Verbindungs-Tests, so fallen uns kontinuierliche Aktivitäten mit dem System 207.46.246.6 auf:

debian:~# tcpdump -n
tcpdump: listening on eth0
22:49:29.689821 192.168.0.2.3074 > 207.46.246.6.3074: udp 24
22:49:33.336002 207.46.246.6.3074 > 192.168.0.2.3074: udp 24
22:49:49.787781 192.168.0.2.3074 > 207.46.246.6.3074: udp 24
22:50:03.862505 207.46.246.6.3074 > 192.168.0.2.3074: udp 24
22:50:09.885713 192.168.0.2.3074 > 207.46.246.6.3074: udp 24
22:50:29.983661 192.168.0.2.3074 > 207.46.246.6.3074: udp 24
22:50:34.268136 207.46.246.6.3074 > 192.168.0.2.3074: udp 24
7 packets received by filter
0 packets dropped by kernel
Hierbei werden fortwährend UDP-Datagramme à 24 Bytes in bidirektionaler Richtung vom und zum Port 3074 geschickt. Dies geschieht alle 20 Sekunden von der Xbox zum Internet-Server und alle 30 Sekunden vom Internet-Server zur Xbox. Dies ist auf den ersten Blick ungewöhnlich, denn die Anzeige unserer Xbox informiert uns in keinster Weise über diesen Datenaustausch. Es ist zu vermuten, dass hierbei zusätzlich und für den Benutzer transparent Kontrolldaten für eine etwaige weiterführende Analyse übertragen werden.
Leider lässt sich auch durch die Einsicht in den Datenteil der UDP-Datagramme nicht genau ausmachen, was für Informationen an dieser Stelle übertragen werden. Sehr wahrscheinlich kommt hier ein propriäteres und komprimiertes Protokoll zum Einsatz, dessen Analyse ohne entsprechende Vorkenntnisse ziemlich utopisch sein dürfte:
debian:~# ngrep
interface: eth0 (192.168.0.0/255.255.255.0)
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
.......3.d..)..C.......9
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.#..U..I,...7..9U3.._0..
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.#......%?.G8..Ji.Be[s._
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
........4..p*....2....Rg
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.#..S,..ad..9.."..'....Z
exit
7 received, 0 dropped
Ein ähnliches Verhalten ist dann auszumachen, wenn man sich passiv in der Freunde-Liste befindet. Dort werden ebenso kontinuierlich die Stati der jeweiligen Kollegen über den gleichen Datenkanal aktualisiert.

12. Die Live-Einwahl

Nach der Auswahl des Kontos vollzieht "Ghost Recon" einen Datenaustausch mit dem Internet-Server. Zum einen findet die Kommunikation einmal mehr über den Port 3074 statt, der auch jeweils als Quellport gewählt wurde. Zum zweiten variiert die Anzahl der übertragenen Bytes zwischen 24 (Zeile 12) und 1336 (Zeile 09). Dabei fallen lediglich die Zeilen 10 und 16 aus dem Rahmen, denn dies sind die einzigen ungeraden Zahlen. Schon in Kapitel 9 (Die Kerberos-Authentisierung)und 11 (Kontrollpakete) haben wir es nur mit Paketen gerader Grösse zu tun gehabt. Dies kann natürlich ein Zufall sein. Werfen Sie einen Blick auf den folgenden tcpdump-Mitschnitt der Live-Einwahl:

01 debian:~# tcpdump -n
02 tcpdump: listening on eth0
03 22:55:08.904080 207.46.246.6.3074 > 192.168.0.2.3074: udp 24
04 22:55:10.121457 192.168.0.2.3074 > 207.46.246.6.3074: udp 24
05 22:55:18.699436 arp who-has 192.168.0.2 tell 192.168.0.2
06 22:55:19.720504 arp reply 192.168.0.2 is-at 0:50:f2:5f:19:13
07 22:58:24.274049 arp who-has 192.168.0.1 tell 192.168.0.2
08 22:58:24.274737 arp reply 192.168.0.1 is-at 0:9:5b:c:58:b0
09 22:58:24.274883 192.168.0.2.3074 > 207.46.246.6.3074: udp 1336
10 22:58:24.480402 207.46.246.6.3074 > 192.168.0.2.3074: udp 795
11 22:58:24.510831 192.168.0.2.3074 > 207.46.246.6.3074: udp 320
12 22:58:24.705186 207.46.246.6.3074 > 192.168.0.2.3074: udp 24
13 22:58:24.733843 192.168.0.2.3074 > 207.46.246.6.3074: udp 36
14 22:58:24.929927 207.46.246.6.3074 > 192.168.0.2.3074: udp 36
15 22:58:24.930052 192.168.0.2.3074 > 207.46.246.6.3074: udp 32
16 22:58:24.953713 192.168.0.2.3074 > 207.46.246.6.3074: udp 219
17 22:58:24.973597 192.168.0.2.3074 > 207.46.246.6.3074: udp 32
18 22:58:25.167127 207.46.246.6.3074 > 192.168.0.2.3074: udp 32
19 22:58:25.201583 207.46.246.6.3074 > 192.168.0.2.3074: udp 140
20 22:58:25.203091 207.46.246.6.3074 > 192.168.0.2.3074: udp 32
21 22:58:25.203144 192.168.0.2.3074 > 207.46.246.6.3074: udp 32
22 22:58:25.288713 207.46.246.6.3074 > 192.168.0.2.3074: udp 48
23
24 20 packets received by filter
25 0 packets dropped by kernel
Eine Analyse des Datenteils der übertragenen UDP-Pakete lässt keine offensichtlichen Rückschlüsse auf den Informationsaustausch zu. Es ist mir absolut schleierhaft, zu welchem Zweck und in welcher Form an dieser Stelle eine Kommunikation stattfindet. Zuerst dachte ich, dass hier eine weitere Kommunikation bezüglich des Nicknames stattfindet oder eine Aktualisierung der Freunde-Liste durchgeführt wird. Dagegen spricht jedoch, dass die jeweiligen Namen nicht in den Datenpaketen auftauchen.Wahrscheinlich wird eine solch starke Komprimierung eingesetzt wird, dass die Namen nicht im ASCII-Klartext übertragen werden.
debian:~# ngrep
interface: eth0 (192.168.0.0/255.255.255.0)
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
..#.m.&1G......q.b..^...
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.....X............fs.'3" ....Xd..".a"......6..8.....lfBv..m.l..0fJol...e>l.
.A.3.........t.+.H....k...A.5J..J....)E.d>.t..Q...a.6.X..n...0.............
..... .......a...0............XBOX.COM..0........0...sg..site1....0........
........~...z../J4...w..Q......!..d....y.qE.M?..C..(1d1/.t..20..vUn.."..{u@
[j.\.)p........~.@.L.....@...g6.....<...e.2...V......~.......6..y.{s......@
...i{4~3/2...Q_..'G.O..(..@....w,.....)$...g.h.........Zfw....E..&.c.JwW...
..@....'&..]..m.>.....-.(.t......]foN.. b........@.sh..cb/..?...Z....&miZq.
...'e../.A.T..UD.(.$..:......M}....I.q..|......DS....B........CJ...'..r.k.k
...?+...m..Z@.5....0.............Z...z..:.I4...Kr.......|8H.v....m.Rse....+
u2.......l....0.%(./.M...d~+.W....c.4S...K.0.......C...q.Wfb......3+.......
X...d.u...5Y..;.:...4.V........,. ..g...c_.=.....?...X...".#....:.2-.'2 ...
[.....mn/Eu.E#..%.HY....O.(...N!2*....O..<.f....uk.Vg.PF&.Nd.}.C%.]......(S
k........v...\...5F..#....~..s...E....G...+.....L..y.....s...e..i..q3Z...#
...if......~......"......."z.........s\U_K=.^4.4M...K,}h..W..S.(...-...K...
.bx.6......}..e....p.v..u..t.mj..!......W..1.. ...e./.j...u.^F.`/..y>.w..D.
.pa..f. ..JG'Ct...$0....b9...:.5..]...q...*.-.~KF.4.f....*....M.|.h.&.i....
..7....(.G...u.6..-..q1.9^4:M..i.G..C....d4....s..}l..i....c/q.....g.....N.
t)c.Te..A.jw.7.....\.[.&.,..lJ.E....o..^".........tQ......C.#
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
.....X@..........emk..fs.'3"..o._n....?..'>...#Q..=...-...X..i.......Xd..=_
...8I....Z.Uz.H.*..9y..P.p._.K>u..-..".#....r....1..I.9..d...RG.Xn.u..?-=.}
.P.9X5.o.$.q...1.].X......=.>g..d.......E..^.....qEcK?..D...D.n..J...F{....
z.....y.......!z^Q..i..."df0<..|.h kX9.d.....T.9s..l...\N.....&.a.{:....D..
...l.......jP.....n.0ht{N..1..o..........,..!.....d9..h)..&8.Q...j-...3<}..
.9..|....f.ao......8+..E...A.).\....r{..V.,6..>.5.y..;-4.=c.y.tC...........
......j..8i...]..9~...5.h.\/...o[........|.+=}..vE...h..u.!CteO.0).Z.y....1
..:6J...B..Dw.r..s...n...Z.h..Z.......q.I5E....|Bd.......(.W.M.....1t.uq..)
U..N.+.y...]U...DK...U..ht.5..=Q#... _.U....<>...xK....J.5...n.....U..v....
..Xw.oq0o...........c0a......Z.X...4...\i&c0.=.}&%C..v.E.>.(?.5`....f...n.'
..a..4c.n....5.qa...B..p.f.............|9B...
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.emkl..L../.]...`.ZU)UK2......b.:_p`.....F........g..r.2...'.....8..;..=)..
..y8c.....".08?....j...9sehR..G...a9....h..a~.&2.....}.....M..rRu.....G....
.=1...~..\5...+..>.G...h.9.......`.@....+rI`5d.w.....2..;.......y........U.
. ...N....J..yDx......+VlX......#...q14q..HRuy3......X?.../G.-9.:..W..*...,
.\V..2.....K....x...
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
....X[.0..UW..e..g<.....
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.emk..Z.)?..........`.B8....>..V..Q.
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
....I...............`.B8.........}.g
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.emk............P.B8..&{...0e...
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.emk.Q/.m......*F.H..82XvC...]...Q.S.%f..#i...v'.2.....Um...s1b{......qKJ.x
.u.w..........p..m...Y.'....2?1.Cd..T-......+O1.C#:'.....d.....~.[G....E..%
.....f.%.X4[G.x...@Z?...s.......bcb..X....`\Rh.......P.B8..]..M...D_.
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.emk............P.B8......b..iS.
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
................P.A}.......1A...
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
................P.A}..%.".....z.
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
.........N..%dm..$.Wh...$o."7A..5......U/.!_.... .f...#q......_@..!.._r.B..
.....M..$Sn]...%.&...6......wk$1l.0..............P.A}.....j..R.L.
#
U 207.46.246.6:3074 -> 192.168.0.2:3074
...........~....P.A}....R..^...w
#
U 192.168.0.2:3074 -> 207.46.246.6:3074
.emk............P.A...-A....-L..
#

13. Time-to-live Werte

In Fachkreisen wird schon lange behauptet, dass es sich bei der Xbox um ein abgespecktes Windows 2000 handelt. Diese Theorie wurde durch ein Interview mit einem Kern-Entwickler des Systems erhärtet [Island 2002]. Das Verhalten der Xbox auf exotische UDP- und TCP-Zugriffe lässt eigentlich keine Rückschlüsse auf das eingesetzte Betriebssystem zu [Fyodor 1998, Ruef et al. 2002]. Die meisten Zugriffe bleiben unbeantwortet, wie wir in den frühen Kapiteln dieser Publikation gesehen haben.
Eine weitere Möglichkeit bleibt jedoch, um doch noch ein bisschen was über die TCP/IP-Implementierung und das eingesetzte Betriebssystem herauszufinden [Fyodor 1998, Ruef et al. 2002]. Hierzu analysieren wir den Time-to-live Wert (TTL) der UDP-Kommunikationen [Stevens 1994]. Dies ermöglicht uns tcpdump mit dem Schalter "-v", der die gwünschte Verbose-Funktion aktiviert. Zusätzlich spezifizieren wir mit dem Filter 'src 192.168.0.2', dass wir lediglich jenen Datenverkehr angezeigt bekommen wollen, der als Quell-IP-Adresse 192.168.0.2 aufweist. Der TTL-Wert findet sich nach der Angabe der Datenbytes der jeweiligen Pakete, direkt nach der ersten runden Klammer.
debian:~# tcpdump -n -v src 192.168.0.2
tcpdump: listening on eth0
18:41:31.055954 192.168.0.2.3074 > 207.46.246.6.3074: udp 1336 (ttl 64, id 9462, len 1364)
18:41:31.291853 192.168.0.2.3074 > 207.46.246.6.3074: udp 320 (ttl 64, id 9463, len 348)
18:41:31.525808 192.168.0.2.3074 > 207.46.246.6.3074: [udp sum ok] udp 36 (ttl 64, id 9464, len 64)
18:41:31.723248 192.168.0.2.3074 > 207.46.246.6.3074: [udp sum ok] udp 32 (ttl 64, id 9465, len 60)
18:41:31.752432 192.168.0.2.3074 > 207.46.246.6.3074: udp 219 (ttl 64, id 9466, len 247)
18:41:31.772278 192.168.0.2.3074 > 207.46.246.6.3074: [udp sum ok] udp 32 (ttl 64, id 9467, len 60)
18:41:32.053365 192.168.0.2.3074 > 207.46.246.6.3074: [udp sum ok] udp 32 (ttl 64, id 9468, len 60)
7 packets received by filter
0 packets dropped by kernel
Die Xbox setzt den TTL-Wert für UDP jeweils auf 64. Vergleichen wir die Liste anderer Betriebssysteme und ihrer TCP/IP-Implementierungen (siehe Tabelle 1) [Ruef et al. 2002], so stellen wir fest, dass dieser Wert bisher noch bei keinem netzwerkfähigen Microsoft-Betriebssystem zum Einsatz kam. Zu Beginn der netzwerkfähigen Windows-Ära wurde ein TTL-Wert von 32 festgelegt, als man dann ab Windows NT 4.0 bzw. 2000 auf 128 erhöhte. Eine TTL von 64 wird erstaunlicherweise von vielen populären UNIX-Betriebssystemen - zum Beispiel BSD4.4, FreeBSD 2.1 und Linux - eingesetzt.

Betriebssystem UDP ICMP

AIX 30

BSD4.4 64

DEC Pathworks V5 30

Cisco Router ISO 12.2.1 255

FreeBSD 2.1R 64

HP/UX 9.0x 30

HP/UX 10.01 64

Irix 5.3 60

Irix 6.x 60

Linux 64

MacOS/MacTCP 2.0.x 60

NetGear FM114P 64

OS/2 TCP/IP 3.0 64

OSF/1 V3.2A 30

QNX Neutrino OS 255

Solaris 2.x 255

SunOS 4.1.3/4.1.4 60

Ultrix V4.1/V4.2A 30

VMS/Multinet 64

VMS/TCPware 64

VMS/Wollongong 30

VMS/UCX 128

Windows for Workgroups 32

Windows 95 32

Windows 98 32

Windows 98 Second Edition 32

Windows ME 128

Windows NT 3.51 32

Windows NT 4.0 128

Windows 2000 128

Windows XP Professional 128

Xbox Live 64 64

Tabelle 13.1: Die Standard Time-to-live Werte

Auf eine Einsicht von ICMP- und TCP-Datenverkehr müssen wir bisweilen verzichten, denn dieser konnte bisher von meiner Seite nicht provoziert werden (z.B. keine ICMP-Pings und full-connect TCP-Portscans möglich). Entsprechende Informationen entnehmen Sie den Kapiteln 2 (Das Verhalten bei ICMP-Zugriffen) und 3 (Das Verhalten bei TCP-Zugriffen).

14. Ein Live-Spiel mit Ghost Recon

In diesem Kapitel wollen wir uns ganz kurz mit dem Datenverkehr beschäftigen, der während eines Live-Spiels mit "Ghost Recon" entsteht. Die hier gewonnenen Erkenntnisse können stark von den Betrachtungen anderer Xbox Live-fähigen Spiele abweichen (z.B. Unreal Championship). Wir wollen hier jedoch nur die Grundzüge der Technik kennenlernen und keine detaillierte Analyse der Datenkommunikation während eines Live-Spiels dokumentieren. Betrachten Sie die folgende tcpdump-Ausgabe, die einen extrem kleinen Ausschnitt einer solchen Spiel-Sitzung darstellt. Diese Datagramme werden innerhalb einer halben Sekunde verschickt.
01 debian:~# tcpdump -n
02 tcpdump: listening on eth0
03 21:01:20.339224 192.168.0.2.3074 > 207.46.246.6.3074: udp 24
04 21:01:20.481553 192.168.0.2.3074 > 217.44.157.58.1025: udp 30
05 21:01:20.540193 217.44.157.58.1025 > 192.168.0.2.3074: udp 63
06
07 3 packets received by filter
08 0 packets dropped by kernel
03 Datenkommunikation mit tgs.xboxlive.com
Auf dieser Zeile begegnen wir einmal mehr unserem altbekannten System namens tgs.xboxlive.com. Die Quell- und Zielports wurden wieder auf den wohlbekannten UDP-Port 3074 gesetzt [IANA 2003]. Dies ist soweit alles nichts neues.
04-05 Spiel-Kommunikation mit dem Spiel-Server
Auf diesen Zeilen können wir erkennen, dass ein Datenaustausch zwischen unserer Xbox und dem System mit der IP-Adresse 217.44.157.58 stattfindet. Dieses System ist der Server, der durch einen anderen Xbox-Spieler aufgemacht wurde. Im Volksmund spricht man auch davon, dass es sich dabei um den Game-Hoster handelt.
Interessant zu beobachten ist die Portwahl, die ein bisschen aus dem Rahmen fällt. Zwar wählt unsere Spielkonsole einmal mehr den UDP-Port 3074 als Quellport. Der Zielport ist jedoch auf udp/1025 gesetzt. Ein Blick in die Portliste der IANA verrät folgendes [IANA 2003]:

blackjack       1025/tcp   network blackjack
blackjack       1025/udp   network blackjack
#                          Unknown contact

Wie mir JOHND03 in seinem Posting auf arealive.de mitteilte, handelt es sich hierbei gar nicht um einen statischen Port [JOHND03 2003]:

In Abschnitt 14 stellst Du fest, dass der Ghost Recon-Server den UDP-Port 1025 als Zielport verwendet. Dieser ist jedoch mit ziemlicher Sicherheit nicht fest gewählt, sondern schlicht und einfach der erste freie Port oberhalb der Registered Ports (0-1023) und kann deshalb von Session zu Session variieren.

Der Game-Hoster gält sich an die von uns initiierten Portnummern und schickt die Daten von udp/1025 (dynamischer kurzlebiger Port) auf udp/3074 (statischer Port) zurück.

15. Bei Ghost Recon kein Beitreten möglich

Ein Phänomen macht den Spielern von "Ghost Recon" immerwieder zu schaffen: Man versucht immerwieder erfolglos dem bestehenden Spiel eines Freundes beizutreten. Obwohl dieser online auf der Freundes-Liste erscheint, man den Knopf für das Beitreten ausgewählt hat und die Bestätigung für den Beitritt aktiviert hat, erscheint plötzlich die Fehlermeldung "Verbindung zu Sitzung beendet" auf dem Bildschirm. Dies ist verwunderlich, denn es schien, als seien alle Voraussetzungen für ein erfolgreiches Internet-Spiel gegeben. Betrachten wir den Netzwerkverkehr mit der Hilfe von tcpdump, erkennen wir das Problem sehr genau:
01 debian:~# tcpdump -n
02 tcpdump: listening on eth0
03 20:30:10.556241 192.168.0.2.3074 > 80.143.131.33.33897: udp 82
04 20:30:10.556249 192.168.0.2.3074 > 80.143.131.33.33897: udp 82
05 20:30:10.766633 80.143.131.33 > 192.168.0.2: icmp: 80.143.131.33 udp port 33897 unreachable [tos 0xc0]
06 20:30:10.770900 80.143.131.33 > 192.168.0.2: icmp: 80.143.131.33 udp port 33897 unreachable [tos 0xc0]
07
08 4 packets received by filter
09 0 packets dropped by kernel
03-04 UDP-Anfragen für den Beitritt
In diesem initialen UDP-Verkehr versucht unsere Xbox mit der IP-Adresse 192.168.0.2 dem Zielsystem mit der IP-Adresse 80.143.131.33 beizutreten. Bei letzterem handelt es sich um den Host des selektierten Mitglieds auf der Freunde-Liste. Der Quell-Port dieser Verbindung ist 3074, der Game-Port für Xbox Live. Als Zielport wurde der kurzebige UDP-Port 33897 ausgewählt. In diesem initialen Datagramm werden 156 Bytes übertragen. Dieser Zielport ist ungewöhnlich in jeglicher Hinsicht: Wir sind ihm noch nie begegnet und er ist relativ hoch. Ansonsten wurden für die Kommunikationen immer die Zielports 53 (DNS), 88 (Kerberos), 1025 (Ghost Recon) oder 3074 (Xbox Live Game-Protokoll) ausgewählt.
05-06 ICMP port unreachable-Fehlermeldungen
Sodann antwortet das angeschriebene Zielsystem mit der IP-Adresse 80.143.131.33 mit entsprechenden ICMP port unreachable-Fehlermeldungen [Stevens 1994, Northcutt et al. 2000, Ruef et al. 2002]. Bei diesen werden wir darüber informiert, dass der gewünschte Zielport udp/33897 durch uns nicht erreicht werden kann. Die Vermutung liegt nahe, dass diese Kommunikation durch ein Firewall-Element unterbunden wird. Denn die Xbox selbst weigert sich bei fehlerhaften ICMP-, UDP- und TCP-Anfragen standhaft mit den entsprechenden Fehlermeldungen den Absender über den aktuellen Zustand zu informieren. Es könnte aber auch sein, dass der Game-Hoster bzw. seine Xbox eine falsche Server-Portnummer ausgewählt hat. Vielleicht unterstützt die Xbox in der aktuellen Version keine UDP-Ports im LISTENING-Modus in diesem hohen Portbereich. Oder vielleicht wurde der falsche Server-Port durch den Game-Hoster propagiert. Unsere Xbox versucht nun verzweifelt zu einem UDP-Port mit CLOSED-Status zu verbinden.
Dieser tcpdump-Mitschnitt ist stark gekürzt und stellt noch nicht mal eine Sekunde dar. Insgesamt werden 19 dieser UDP-Anfragen übertragen. Die ersten 10 erfolgen im Zweierpack, jeweils alle zwei Sekunden, wie sie in der vorhergehenden tcpdump-Ausgabe (Zeilen 03 und 04) dargestellt werden. Ebenso werden darauf zwei ICMP-Fehlermeldungen generiert (Zeilen 05 und 06). Die letzten 9 UDP-Anfragen erfolgen einzeln, jeweils eine pro Sekunde, und provozieren daher auch nur eine ICMP port unreachable-Rückantwort. Diese sind nicht mehr in der hier gekürzten tcpdump-Ausgabe abgebildet worden.
Abbildung 15.1: Kein Beitreten möglich
In einer früheren Version dieses Dokuments (vor 1.1, 7. Februar 2003) vermute ich, dass diese ICMP-Fehlermeldungen von der Xbox selbst stammen. JOHND03 aus dem Xbox-Forum arealive.de hat mich in seinem Posting entsprechend auf die richtige Lösung des Problems aufmerksam gemacht [JOHND03 2003]:
In Abschnitt 15 analysierst Du das Problem, weshalb manchmal das Beitreten zu einem Spiel nicht möglich ist, und führst dies auf einen nicht erreichbaren UDP-Port 33897 zurück.
Tatsächlich deutet diese hohe Port-Nummer aber darauf hin, dass der Game-Server hinter einem NAT-Router steht: ein NAT-Router setzt die Port-Nummer des Game-Servers im LAN (die wie oben vermutet knapp oberhalb 1023 liegt) auf eine pseudo-zufällig gewählte hohe Port-Nummer gegenüber dem WAN um, damit auch mehrere Rechner aus dem LAN über denselben Port kommunizieren können.
Das Problem, weshalb es dann zu der port-unreachable-Meldung kommt, liegt mit einiger Wahrscheinlichkeit daran, dass der Wert für das UDP-Aging im Router zu niedrig gewählt wurde:
Der Game-Server kontaktiert höchstwahrscheinlich zunächst den Xbox-Live-Server mit dem gewählten Quellport (also in obigen Beispielen 1025 bzw. 33897), damit dieser die potentiellen Clients darüber informieren kann, auf welchem Port der Game-Server erreichbar ist (Diese Methode wurde von Microsoft wohl deshalb gewählt, da damit auch hinter einem NAT-Router stehende Server gehostet werden können, ohne dass dazu ein explizites Port Forwarding notwendig wäre).
Dabei erstellt der Router einen Eintrag in der NAT-Tabelle, der besagt, dass inbound UDP-Connections mit Zielport 33897 auf die lokale IP-Adresse des Game-Servers mit der Port-Nummer 1025 umgesetzt werden sollen.
Wurde im Router der Wert für das UDP-Aging nun aber beispielsweise auf 5 Sekunden eingestellt und hat sich innerhalb dieser Zeit niemand auf dem Game-Server eingeloggt, so wird der Eintrag in der NAT-Tabelle nach 5 Sekunden wieder gelöscht und es kommt es zu der von Dir festgestellten ICMP-Meldung "port unreachable".

16. Content-Downloads

Einige Spiele unterstützen den Download von Content. Manche dieser Spiele gewähren lediglich diese Funktionalität und erlauben kein Spielen mit anderen Personen über Xbox Live (z.B. "Tom Clancy Splinter Cell"). Andere Spiele erlauben sowohl den Content-Download als auch das Spielen mit anderen über das Internet (z.B. "Unreal Championship", "Mech Assault" und die "2k3-Sportreihe von Sega"). Wieder andere Spiele stellen Online-Ranglisten zur Verfügung, bei denen Statistiken zur Verfügung gestellt werden, durch die sich die Spieler untereinander messen können (z.B. "Unreal Championship" und "Capcom vs. SNK 2 EO"). Die Tabelle 16.1 gewährt einen Überblick der jeweiligen Live-Funktionalitäten.

Spiel Online-
Spiele Content-
Download Ranglisten

Capcom vs SNK EO 2 X X

Mech Assault X X

Moto GP X X

Sega NBA 2k3 X X X

Sega NFL 2k3 X X X

Sega NHL 2k3 X X X

Tom Clancy Ghost Recon X ?

Tom Clancy Splinter Cell X

Whacked X

Tabelle 16.1: Die Live-Funktionalität einiger Spiele

Wir haben am Beispiel von "Tom Clancy Ghost Recon" gesehen, dass die Online-Spiele von UDP getragen werden (Kapitel 14, Ein Live-Spiel mit Ghost Recon). Bei Online-Spielen jeglicher Art ist die Reaktionszeit sehr wichtig, weshalb auf das zuverlässigere aber trägere TCP als Transportprotokoll verzichtet, und stattdessen lieber das schnellere UDP-Protokoll vorgezogen wird. Diese Reaktionszeit ist jedoch nicht zwingend erforderlich, wenn es um den Download von Content und das Einsehen von Online-Statistiken geht. Es wäre also zu vermuten, dass bei diesen beiden Zugriffen TCP eingesetzt wird, um eine gewisse Zuverlässigkeit zu garantieren und den Zugriff effizienter ausfallen zu lassen. Erstaunlicherweise verwenden die aktuellen Live-Spiele auch für den Content-Download und die Ranglisten-Funktion UDP. Diese Kommuniktion findet ganz normal über den reservierten Port 3074 statt.

17. Das Live-Ausloggen

In jedem Fall wird bein Verlassen des Live-Dienstes scheinbar ein Quittierungs-Datagramm an den Spielserver geschickt. Dies geschieht selbstverständlich, wenn man eine Sitzung softwaremässig verlässt. Aber auch beim Betätigen des Power-Knopfs an der Xbox, mitten in einem Live-Spiel, wird noch schnell ein solches UDP-Datagramm verschickt. Die Socket-Informationen sind dabei nicht neu. Auch hier werden als Quell- und Zielport udp/3074 gewählt.

debian:~# tcpdump -n
tcpdump: listening on eth0
23:51:29.097581 192.168.0.2.3074 > 207.46.246.6.3074: udp 24
1 packets received by filter
0 packets dropped by kernel

18. Denial of Service-Attacken

In diesem Kapitel wollen wir uns mit klassischen und neumodischen Denial of Service-Attacken (DoS) und ihren Auswirkungen auf die Xbox beschäftigen.
Als erstes ist mir aufgefallen, dass ab und an die Verbindung zu Xbox Live abbricht, wenn man einen TCP-Portscan auf die Xbox durchführt (z.B. "nmap -P0 -sT 192.168.0.2"). Sodann ist es nicht mehr möglich, sich regulär über Xbox Live einzuwählen. Leider ist dieser Zustand nicht immer reproduzierbar, weshalb ich nicht mit Bestimmtheit sagen kann, worin der Fehler liegt. In etwa 10 % aller Portscans mit nmap konnte dieser Zustand nach wenigen Minuten erreicht werden. Es könnte sein, dass ein Bufferoverrun durch das Überfüllen der Backlog verursacht werden kann. Es kann aber genauso sein, dass die Bandbreite des Netzwerks ausgelastet wurde, so dass die UDP-Kontrolpakete nicht zwischen der Xbox und den Live-Servern ausgetauscht werden konnten.
Die Xbox verhält sich sehr robust gegenüber Ping-Flooding, die ich unter anderem durch die Eingabe von "ping -f 192.168.0.2" auf dem Linux-System herbeigeführt habe:
debian:~# ping -f 192.168.0.2
PING xbox (192.168.0.2): 56 data bytes
.......................................................................................
.......................................................................................
.......................................................................................
.......................................................................................
.......................................................................................
..................................................................................
--- xbox ping statistics ---
517 packets transmitted, 0 packets received, 100% packet loss
Wie schon in Kapitel 2 (Das Verhalten bei ICMP-Zugriffen) gesagt, bleiben die ICMP echo reply-Rückantworten während des nomalen Betriebs aus. Es ist keine negative Beeinträchtigung der Netzwerkfähigkeit der Xbox zu beobachten. Weder ein Verbindungsunterbruch zu Xbox Live noch zusätzlicher Lag sind auszumachen. Dies ändert auch nichts, wenn man die Paketgrösse der ICMP echo request-Anfragen mittels dem zusätzlichen Parameter "-s 65468" maximiert.
Ich habe verschiedene klassische Denial of Service-Attacken ausprobiert [McClure et al. 1999, Northcutt et al. 2000, Ruef 2000, Ruef et al. 2002], die allesamt keine Wirkung gezeigt haben. Tabelle 18.1 listet diese Angriffe auf. Einige Angriffe habe ich manuell ausgeführt, andere zusätzlich oder ersetzend durch verschiedene Vulnerability Scanner (ISS Internet Scanner und Nessus) umsetzen lassen.

Name Beschreibung

arnudp.c UDP-Flooder

echok.c ICMP echo-Flooder

jolt.c Übergrosse Fragmente

overdrop.c Modifizierte Variante von teardrop.c, die übergrosse Pakete benutzt.

synful.c SYN/ACK-Flooder

Tabelle 18.1: Getestete Denial of Service-Attacken

Da auf der Xbox standardmässig keine Dienste angeboten werden, können keine Attacken auf der Anwendungsebene umgesetzt werden. Dies gilt es nocheinmal beim Erscheinen entsprechender Server-Anwendungen (z.B. Webserver) zu überprüfen. Sollten dabei jedoch Probleme ausgemacht werden, hat man diese wahrscheinlich nicht der Xbox, sondern der betroffenen Netzwerkapplikation anzukreiden.

19. LAN-Verbindung ohne Xbox Live

Weiterhin ist es möglich, diverse Spiele im LAN, ohne Xbox Live, zu spielen. Die einfachachste Umsetzung dessen ist der Zusammenschluss zweier Xbox-Konsolen mit einem gekreuzten Kabel (engl. cross cable). Aber auch die Kommunikation mittels Hub bzw. Switch sind möglich. Wir verlassen unser bisheriges Szenario und benutzen nun den in Abbildung 19.2 (Das Testnetzwerk mit zwei Xbox-Konsolen) illustrierten Netzwerkaufbau:

Abbildung 19.2: Das Testnetzwerk mit zwei Xbox-Konsolen

Dabei fehlt ein DHCP-Server, der die dynamische Zuweisung der TCP/IP-Einstellungen umsetzen kann [Stevens 1994, Comer 1995]. Die Xbox wählt sodann als erstes die IP-Adresse 0.0.0.1 und schickt einen Broadcast. Merkt das System, dass schon ein anderes Netzwerkgerät diese IP-Adresse für sich in Anspruch nimmt, wird die Adresse um 1 erhöht. Aber auch bei vorhandenem DHCP-Server verzichten die Xbox-Systeme auf das Beziehen der Informationen. Es scheint, als würde erst mit dem Aktivieren von Xbox Live der DHCP-Client installiert werden.
Ein TCP/IP-Mitschnitt der sodann durchgeführten Kommunikation ist interessant. Für dieses Beispiel benutzen wir zwei Xbox-Konsolen und verbinden sie mit einem Hub. Die erste Xbox nimmt für sich die IP-Adresse 0.0.0.1, die zweite 0.0.0.2 in Anspruch. Ein drittes System, unser albewährtes Debian GNU/Linux, ist für die Aufzeichnung der Kommunikation zuständig:
01 Broadcast Packet
02 Length: 102 Bytes
03 Source Address: 0.0.0.1
04 Destination Address 255.255.255.255
05 UDP
06 Source Port = 3074
07 Destination Port = 3074
08 60 Bytes of Data
Wir können sodann sehen, dass grundsätzlich ein Broadcast-Verkehr an die Zieladresse 255.255.255.255 stattfindet (Zeile 04). Dies ist erstaunlich, denn Xbox Live arbeitet im Gegensatz zu Unicast-Datenverkehr auf den gleichen Ports (Zeilen 06 und 07).
Negativ wirkt sich daher ein LAN-Spiel mit der Xbox in einem lokalen Netzwerk aus, in dem auch noch andere Systeme zu arbeiten pflegen. Das Datenaufkommen wird aufgrund des stetigen Broadcast-Verkehrs der Xbox-Systeme verhältnismässig hoch sein.
Ein weiterer Nachteil dieser Kommunikation ist, dass sie unter anderem sehr schwer durch einen VPN-Tunnel (Virtual Private Networks) zu bringen ist. Meine Versuche mit meinem Cisco 2611 sind alle fehlgeschlagen. Es ist aber sowieso fragwürdig, ob man LAN-Spiele wie "Halo" über VPN spielen muss.

FAQ

In diesem Anhang wollen wir die meistgestellten Fragen (FAQ, Frequently Asked Questions) zur TCP/IP-Implementierung der Xbox besprechen. Die Antworten werden kurz und bündig gegeben, so dass sie für jederman leicht verständlich sind. Wer weitere Informationen möchte, der wird jeweils in der Antwort auf die entsprechenden Kapitel dieser Dokumentation verwiesen.
Was passiert, wenn ich meine Xbox anpinge?
Grundsätzlich passiert nichts. Eine ICMP echo reply-Rückantwort bleibt aus. Das Resultat ist, dass im ping-Programm ein Paket-Verlust von 100 % angezeigt wird. Aus diesem Grund werden sämtliche Tests in dieser Dokumentation - zum Beispiel mit nmap - ohne Ping-Mapping durchgeführt. Siehe Kapitel 2 (Das Verhalten bei ICMP-Zugriffen).
Sind traceroute-Anfragen zu einer Xbox möglich?
Nein, denn die Xbox pflegt keine ICMP time exceeded in-transit-Fehlermeldungen auszugeben. Dabei ist es unabhängig, mit welchem Protokoll der traceroute-Zugriff durchgeführt wurde (ICMP, UDP oder TCP). Das traceroute-Programm wird dies registrieren und stets angeben, dass die gewünschten Antworten ausblieben.
Der letzte antwortende Host dieses Zugriffs wird stets der letzte Hop vor der Xbox sein, der die gewünschten ICMP-Fehlermeldungen auszugeben in der Lage ist. Siehe Kapitel 2 (Das Verhalten bei ICMP-Zugriffen), Kapitel 3 (Das Verhalten bei TCP-Zugriffen) und Kapitel 4 (Das Verhalten bei UDP-Zugriffen).
Wie kann ich die Erreichbarkeit einer Xbox überprüfen?
Dazu ist die passive Möglichkeit mit einem Protokoll-Analyzer oder Sniffer möglich. Durch die aufgezeichneten Datagramme lässt sich die Aktivität der Xbox ausmachen.
Die einzige aktive Möglichkeit der Überprüfung besteht im ARP-Mapping, das in Kapitel 5 (Die ARP-Implementierung) besprochen wurde. Diese kann jedoch nur in gleichen Netzwerksegmenten angewandt werden und funktioniert daher nicht über das Internet.
Diese Entwicklungsentscheidung fällt sehr zu Gunsten der Sicherheit des Xbox-Systems aus. Skript-Kiddies und Hacker sind genötigt, die Erreichbarkeit der netzwerkfähigen Xbox zu erahnen. Die meisten Angriffs-Tools können somit nicht mehr einfachso genutzt werden (z.B. nmap oder LANguard).
Welche IP-Protokolle werden von der Xbox unterstützt?
Wie wir in Kapitel 6 (Die unterstützten Protokoll) gesehen haben, können mit der Option "-sO" von nmap die unterstützten IP-Protokolle nicht ausgemacht werden. Es bleiben bei allen 255 Möglichkeiten die gewünschten Rückantworten aus, weshalb die nicht unterstützten Protokolle nicht identifiziert werden können.
Ich gehe davon aus, dass nicht sämtliche IP-Protokolle unterstützt werden. Ganz sicher wird jedoch UDP (siehe Kapitel 4). Eventuell werden jetzt oder in einer späteren TCP/IP-Implementierung auch ICMP (Kapitel 2) und TCP (Kapitel 3) unterstützt werden. Für die Unterstützung der anderen Protokolle sehe ich keine Notwendigkeit.
Ist OS-Fingerprinting bei der Xbox möglich?
Aktives OS-Fingerprinting ist momentan nicht wirklich möglich, denn von der Xbox lassen sich praktisch keine ICMP-, TCP- oder UDP-Rückantworten provozieren, wie in den Kapiteln 2 (Das Verhalten bei ICMP-Zugriffen), 3 (Das Verhalten bei TCP-Zugriffen) und 4 (Das Verhalten bei UDP-Zugriffen) dokumentiert wurde. Es ist nicht damit zu rechnen, dass die Xbox in die Fingerprint-Datenbank populärer Auswertungs-Anwendungen wie nmap oder queso aufgenommen wird.
Auch passives OS-Fingerprinting gestaltet sich auf Grund der aktuellen Situation nicht besonders einfach. Lediglich der TTL-Wert bei UDP-Datagrammen lässt Rückschlüsse auf die Xbox zu. Siehe Kapitel 13 (Time-to-Live Werte).
Was wird genau bei einem Verbindungstest überprüft?
Ich fasse die einzelnen Schritte, die in Kapitel 7 (Verbindung testen) detaillierter besprochen werden, nocheinmal zusammen:

Als erstes überprüft die Xbox, ob ein Netzwerkkabel in der RJ45-Buchse steckt. Dies geschieht auf reiner Hardware-Ebene.

Danach wird eine ARP-Auflösung für die zuletzt der Xbox zugewiesene IP-Adresse durchgeführt. Dadurch soll die Verfügbarkeit dieser Adresse überprüft werden.

Durch UDP-Verkehr an den Port 1900 wird das Multicasting des lokalen Netzwerks überprüft.

Nachdem die Xbox die ARP-Auflösung für das Standard-Gateway durchgeführt hat, wird eine Adressauflösung für das System mit dem Namen as.xboxlive.com durchgeführt. Weitere Informationen zum System as.xboxlive.com finden sich in Kapitel 8 (Das System as.xboxlive.com).

Bei diesem wird sich über den UDP-Port 88 mittels Kerberos authentisiert. Weitere Informationen zur Kerberos-Authentisierung finden sich in Kapitel 9 (Die Kerberos-Authentisierung).

Danach findet eine Adressauflösung für das System mit dem Namen tgs.xboxlive.com statt.

Auch bei diesem wird eine Kerberos-Authentisierung durchgeführt.

Dann erfolgt zum zweiten Mal eine Multicasting-Überprüfung.

Zum Schluss findet ein kontinuierlicher UDP-Datenaustausch mit dem Port 3074 des Systems tgs.xboxlive.com statt. Dieser ist Mittelpunkt von Kapitel 11 (Kontrollpakete).

Welche Rolle übernimmt das System as.xboxlive.com?
Der Hostname "as" deutet darauf hin, dass es sich hier um den "Authentication Server" (AS) handelt.
Diese Vermutung wird bekräftigt, weil tatsächlich eine Kerberos-Authentisierung mit diesem Host stattfindet. Es scheint also, dass dieses System für die Einwahl und Überprüfung des Xbox Live-Benutzers zuständig ist. Das System as.xboxlive.com haben wir genauer in Kapitel 8 (Das System as.xboxlive.com) unter die Lupe genommen.
Welche Rolle übernimmt das System tgs.xboxlive.com?
Bis und mit Version 2.2 dieses Dokuments dachte ich, dass der Hostname "tgs" auf soetwas wie "Team Game Server" hindeuten würde (siehe TCPdump-Analyse in Kapitel 7, Verbindung Testen). Pascal C. Kocher berichtigte mich jedoch in einer privaten Email, in der er darauf hinwies, dass um den Ticket Granting Server (Service) nach RFC 1510 handeln könnte.
Momentan ergibt eine IP-Adressauflösung für die beiden System as.xboxlive.com und tgs.xboxlive.com die gleiche IP-Adresse. Es handelt sich also noch um das selbe System.
Scheinbar möchte Microsoft die beiden Hosts in naher Zukunft separat betreiben, um beim grossen Ansturm auf Xbox Live eine Lastverteilung erreichen zu können. Siehe auch Kapitel 8 (Das System as.xboxlive.com). Wahrscheinlich wird dann das tgs-System der eigentliche Game Server darstellen.
Sind die Systeme as.xboxlive.com und tgs.xboxlive.com sicher?
In Kapitel 8 (Das System as.xboxlive.com) haben wir uns mit dem System as.xboxlive.com beschäftigt. Diese erste Analyse hat gezeigt, dass sich Microsoft alle Mühe gibt, das System vor unnötigen und unerlaubten Zugriffen (z.B. Ping und traceroute) zu schützen.
Ob die Systeme as.xboxlive.com und tgs.xboxlive.com wirklich als sicher eingestuft werden können, wird die Zukunft zeigen. In jedem Falle spielen sie eine zentrale Rolle im gesamten Live-System. Kann ein Angreifer diese Systeme kompromittieren, sollte es ihm möglich sein, Xbox Live Accounts oder Spiel-Statistiken zu manipulieren. Microsoft tut gut daran, die besagten Systeme nach bestem Wissen und Gewissen zu schützen.
Welche Daten werden bei der Kerberos-Authentisierung übertragen?
Es kann nicht mit Sicherheit festgestellt werden, welche Daten alle bei den Kerberos-Authentisierungen übertragen werden.
In Kapitel 9 (Die Kerberos-Authentisierung) haben wir jedoch gesehen, dass die folgenden Daten im Klartext durchs Internet geschickt werden:

Die Versions-Nummer der Xbox.

Die eindeutige Seriennummer der Xbox selbst. Achtung, dies sind sehr sensitive Daten!

Etwaige Informationen zum Passport.net-System von Microsoft.

Wieso werden zwei Kerberos-Authentisierungen durchgeführt?
Zur aktuellen Stunde handelt es sich bei den Systemen as.xboxlive.com und tgs.xboxlive.com um ein und den selben Computer. Es ist jedoch damit zu rechnen, dass diese getrennt und von dedizierten Maschinen gegeben sein werden:

So scheint es, dass das System as.xboxlive.com die Aufgabe des Authentication Servers (AS) übernimmt. Hier findet eine erste Überprüfung des Xbox Live Accounts statt. Siehe Kapitel 9 (Die Kerberos-Authentisierung).

Die zweite Kerberos-Authentisierung wird nötig, wenn sich der Live-Benutzer mit dem Ticketing Generating Server (tgs.xboxlive.com) verbindet.

Was hat es mit dem Port 3074 auf sich?
Seit Anfang 2003 hat Microsoft den UDP-/TCP-Port 3074 in der Portliste der IANA für seinen Xbox Live-Dienst reserviert [IANA 2003]. Dieser Port, vorwiegend im Zusammenhang mit dem Transportprotokoll UDP, spielt eine wichtige Rolle bei diesem Service. Die meisten Kommunikationen werden darüber durchgeführt. Zum Beispiel der Informationsaustausch zwischen der Xbox und dem Spielserver tgs.xboxlive.com.
Interessant ist zu bemerken, dass bei diesen Kommunikationen sowohl Ziel- als auch Quellport auf 3074 gesetzt werden. Weitere Informationen zu diesem Port finden sich in Kapitel 10 (Der Port 3074).
Wie funktionieren Content-Downloads und Ranglisten?
Erstaunlicherweise werden bei Content-Downloads und Online-Ranglisten auch das UDP-Protokoll mit dem Port 3074 genutzt. Da bei diesen Zugriffen Reaktionszeit weniger eine Rolle spiel und eher die Zuverlässigkeit im Mittelpunkt steht, müsste an dieser Stelle eigentlich TCP eingesetzt werden. Siehe Kapitel 16 (Content-Downloads).
Es kann jedoch sein, dass zukünftige Live-Titel TCP für das Übertragen grosser Datenmengen ausserhalb eines Online-Spiels nutzen werden.
Welche Time-to-Live Werte pflegt die Xbox zu setzen?
Bei den bisherigen Kommunikationen konnte lediglich UDP-Verkehr beobachtet werden. Es ist uns deshalb zur aktuellen Stunde nur möglich, den initialen TTL-Wert für dieses verbindungslose Protokoll der Transportschicht auszuweisen. Dieser wird auf 64 gesetzt, was für ein Windows-Betriebssystem sehr untypisch ist. Wir wir in Kapitel 13 (Time-to-Live Werte) ausgeführt haben, pflegen ältere Windows-Systeme für UDP eine TTL von 32 und neuere eine von 128 zu setzen. Auffällig ist, dass viele der populären UNIX-Systeme - zum Beispiel BSD4.4, FreeBSD 2.1 und Linux - eine initiale TTL von 64 für UDP vergeben.
Werden bei gehosteten Spielen peer-to-peer Verbindungen genutzt?
Ja, neben der Verbindung zum zentralen Microsoft-System tgs.xboxlive.com besteht eine neue Verbindunt zum Hosting-Server. Der Zielport dieser Kommunikation ist einmal mehr 3074. Der Quellport scheint der kleinste zur Verfügung stehende, kurzlebige Port über 1023 zu sein. Siehe hierzu Kapitel 14 (Ein Live-Spiel mit Ghost Recon).
Warum ist manchmal kein Beitreten möglich?
Grundsätzlich können klassische Netzwerkprobleme hierfür verantwortlich sein:

So kann ein Firewall-Element (z.B. Router mit ACL) beim Game-Hoster oder dem ISP für den nicht erfolgreichen Beitritt verantwortlich sein.

Aber es kann auch sein, dass der Fehler bei der Xbox bzw. dem Spiel selbst liegt. Die Zukunft wird zeigen, ob der Spiel-Hersteller einen Patch herausbringen wird, der das Problem behebt.

Falls ein Patch vom Spiel-Hersteller kommt, dann lag die Schuld eindeutig bei ihm. Kommt ein Patch von Microsoft, dann hat was mit der TCP/IP-Implementierung der Xbox nicht gestimmt. Falls nichts von der Richtung kommen wird, dann liegt das Problem entweder bei den ISPs oder dem Game-Hoster selbst.
In Kapitel 15 (Kein Beitreten möglich) untersuchen wir dieses Phänomen anhand des Spiels "Ghost Recon".
Kann mit der "10 Sekunden Regel" der Spielfluss eines Ghost Recon-Spiels optimiert werden?
Teilweise ja. Zu Beginn eines neuen Spiels muss der Host alle Clients über den aktuellen Stand der Dinge - zum Beispiel die Position der Figuren - informieren. Dies erzeugt verhältnismässig viel Datenaufkommen.
Bei jeder Bewegung, dem Wechsel der Waffe und dem Sprechen werden Daten übertragen. Bewegen sich die Mitspieler zu Beginn des Spiels, kann die initiale Informations-Verteilung nur langsam vorangehen. Aus diesem Grund kann es von Vorteil sein, sich erst nach etwa 10 Sekunden zu bewegen.
Trotzdem ist der Nutzen dieser Wartezeit sehr begrenzt. Denn auch wenn sich sämtliche Figuren sofort nach dem Eintritt ins Spielgeschehen bewegen, wird die initiale Informations-Verteilung irgendwann zu Ende sein. Dies ist nach etwa 20 Sekunden der Fall, grundsätzlich von der Bandbreite und der Latenzzeit der involvierten Systeme abhängig. Bei grossen Karten kann also theoretisch die 10 Sekunden-Regel ignoriert werden, denn bis sich die Teams gegenüberstehen, werden die initialen Daten längst übertragen sein. Bei kleineren Karten, wie zum Beispiel "Hafen" bei Ghost Recon, macht dies schon eher Sinn.
Auf das Spielgeschehen nach dem initialen Datenaustausch hat die 10 Sekunden-Regel keinen Einfluss. Man kann also sodann nicht mehr Leute hosten.
Welche Auswirkungen hat Fast-Path auf Xbox Live-Sitzungen?
Hierbei wird bei xDSL die Fehlerkorrektur abgestellt. Vorteil hiervon ist eine schnellere Übertragung. Die Latenzzeit, im Volksmund fälschlicherweise als Ping bezeichnet, sinkt so beachtlich. Meistens wirkt sich Fast-Path jedoch nur bis zum letzten Hop des xDSL-Netzwerks aus. Somit kann die Geschwindigkeitseindämmung im xDSL-Netz ausgebessert werden. Verlassen die Daten dieses Netzwerk, sind sie an andere Gegebenheiten gebunden. Fast-Path bringt hier direkt also nichts. Somit ist diese Lösung nur dann von Vorteil, wenn das DSL-Netzwerk der Flaschenhals der Kommunikation ist [Ruef 2003].
Aufgrund des Weglassens der Fehlerkorrektur kann es zu einer höheren Anzahl an Übertragunsgwiederholungen aufgrund korrupter Pakete kommen. Dies wirkt sich vor allem negativ auf die Übertragung grosser Pakete, wie zum Beispiel bei FTP-Sitzungen, aus.
Was passiert, wenn ich meine Xbox mitten in einer Live-Sitzung abschalte?
Es passiert das gleiche, wie wenn man die Sitzung normal verlässt. Die eigene Xbox meldet sich beim Spielserver tgs.xboxlive.com ab, indem ein letztes UDP-Datagramm an den Zielport 3074 geschickt wird. Siehe hierzu Kapitel 17 (Das Live-Ausloggen).
Sind Denial of Service-Attacken auf die Xbox möglich?
Durch Überlastung ist es möglich, jedes netzwerkfähige System in die Knie zu zwingen - Natürlich auch die Xbox. So gibt es bisher auch keine umfassende Möglichkeiten, sich vor Überlastungsangriffen (z.B. Distributed Denial of Service-Attacken, DDoS) zu schützen. Dies ist ein grundlegendes Problem des modernen Internets und der eingesetzten Protokolle.
Es scheint, als könnte man die Xbox durch einen Portscan vom Live-System trennen. Diverse Tests mit nmap haben dies gezeigt. Es war mir jedoch nicht möglich, diesen Zustand gewollt zu reproduzieren. Lediglich in etwa 20 % aller Fälle konnte dieses Resultat beobachtet werden. Es könnte durchaus sein, dass man die Xbox durch das Überfüllen der Backlog in die Knie zwingen kann. Dies gilt es noch weiter zu untersuchen.
Mit klassischen Denial of Service-Attacken auf fehlerhafte TCP/IP-Implementierungen kommt man bei der netzwerkfähigen Xbox nicht besonders weit. So versagen zum Beispiel überlange Ping-Pakete (Ping of Death) und fragment overlapping (Teardrop) ihren Dienst [Ruef 2000].
Da auf das Anbieten von Services durch die Xbox verzichtet wird, können auch klassische Methoden wie WinNuke oder smbdie nicht zum Ziel führen.
Das Kapitel 18 (Denial of Service-Attacken) beschäftigt sich mit dem Thema, wie die Xbox über das Netzwerk negativ beeinträchtigt werden kann.
Wie kommuniziert die Xbox ohne Live im LAN?
Wie wir in Kapitel 19 (LAN-Verbindung ohne Xbox Live) gesehen haben, geschieht dies mittels Broadcast-Paketen an die Adresse 255.255.255.255. Auch hier wird der registrierte Game-Port 3074 gewählt [IANA 2003].
Diese Methode treibt die Netzwerkauslastung unnötig in die Höhe und sollte daher in kritischen Umgebungen nicht eingesetzt werden. Auf Unicast-Verkehr wird scheinbar verzichtet, um das Risiko von Problemen so gering wie möglich zu halten. Dieser Komfort geht eindeutig auf die Kosten der Effizienz.
Ist die Xbox sicher gegen Hacking-Attacken?
Hier mit einem verbindlichen "Ja" zu antworten, das wäre ungemein töricht. Ich möchte aber durchaus betonen, dass Microsoft nur so viel Netzwerk-Funktionalität implementiert hat, wie es nötig ist. Dies kommt auch der Sicherheit des Systems zugute, die derjenigen anderer Microsoft-OS' überlegen sein dürfte. Ein Heavy Scan während laufenden Verbindungstests im Dashboard mit Symantec NetRecon 3.5 weist insgesamt zwei Punkte aus (Siehe Abbildung A.1; der Report kann hier als PDF-Datei gefunden werden):

Network resource identified, Risk 16

Responds to ICMP echo request (ping), Risk 15

Abbildung A.1: Diagramm der mit NetRecon gefundenen Schwachstellen

Aber erst die Zukunft wird zeigen, wie anfällig die Xbox gegen Attacken wirklich ist.

Nachwort

Wir haben gesehen, wie die Grundzüge der TCP/IP-Implementierung der Microsoft Xbox aussehen. Dabei haben wir einige Geheimnisse gelüftet; zum Beispiel, in welcher Form die Authentisierung stattfindet und was genau bei einer Verbindungs-Überprüfung durchgeführt wird.
Trotzdem haben wir noch lange nicht alles über die Netzwerkfähigkeit der Xbox gesehen. Es gibt einige Dinge, die als Aussenstehender nur sehr schwer aufzudecken sind. Die Zukunft wird zeigen, ob sich trotzdem die eine oder andere Unklarheit herausfinden lässt. In jedem Fall ist hierfür viel Aufwand nötig.
In diesem Sinne möchte ich darum bitten, mich über Berichtigungen und Neuerungen bezüglich der Netzwerkfähigkeit der Xbox auf dem Laufenden zu halten.

Literaturverzeichnis

Albanna, Z., Almeroth, K., Meyer, D., Schipper, M. [August 2001], RFC 3171 - IANA Guidelines for IPv4 Multicast Address Assignments, http://www.faqs.org/rfcs/rfc3171.html
In diesem RFC werden Zuweisungen von Multicast-Adressen in IPv4-Netzwerken festgehalten. Dieses Dokument ist wichtig, wenn wir den automatisierten Verbindungs-Test bei Xbox Live betrachten. Hier werden nämlich UDP-Datagramme an die spezifizierten Multicast-Adressbereiche verschickt.
Arkin, Ofir [Juni 2001], ICMP Usage in Scanning, http://www.sys-security.com
In dieser Online-Publikation verrät Ofir Arkin sämtliche Möglichkeiten und Tricks von ICMP. Neben den klassischen Mapping-Techniken werden die Methoden zur Betriebssystemerkennung vorgetragen. Ein sehr wichtiges Dokument zum Thema ICMP.
Comer, Douglas E. [1995], Internetworking with TCP/IP, Volume 1: Principles, Protocols, and Architectures, Prentice Hall
Comer vermag in seinem Buch einen ausgezeichneten Überblick über die Idee und Funktionsweise der TCP/IP-Protokolle zu geben. Kurz und bündig werden die wichtigsten Fakten, die mit einer Prise persönlicher Erfahrung gemixt sind, zusammengefasst. Leider fehlen einmal mehr die aufschlussreichen tcpdump-Ausgaben.
Fyodor [1998], Remote OS detection via TCP/IP Stack FingerPrinting, http://www.insecure.org/nmap/nmap-fingerprinting-article.html, deutsche Übersetzung von Stefan Maly [10. April 1999], http://www.insecure.org/nmap/nmap-fingerprinting-article-de.html
Fyodor erklärt in seiner bahnbrechenden Arbeit, wie aktiv ein Betriebssystem anhand des Verhaltens seiner TCP/IP-Implementierung erkannt werden kann. Diese Technik, die als OS-Fingerprinting bekannt wurde, implementierte Fyodor kurze Zeit später in seine nmap-Software.
Fyodor [2000], nmap man-Page, http://www.insecure.org, deutsche Übersetzung von Marc Ruef, [20. September 2002], http://www.computec.ch
In der offiziellen man-Page des populären Auswertungs-Tools nmap (Network Mapper) erklärt der Entwickler selbst, wie seine Software bestmöglich zu nutzen ist. Dieses Dokument ist sehr gut geeignet, um die Grundlage des Scannings und die Funktionsweise von nmap zu verstehen. Die man-Page von nmap wurde in verschiedene Sprachen übersetzt, darunter auch in Deutsch.
Island, Cactuar [19. November 2002], Re: Windows 2000 Kernal on Xbox - wtf?, alt.games.video.xbox
In diesem Posting behauptet Cactuar Island, dass auf der Xbox eine sehr abgespeckte Version von Windows 2000 eingesetzt wird. Leider wird in diesem Zusammenhang keine Quellen oder weiterführende Literatur erwähnt.
IANA, Internet Assigned Numbers Authority [4. Februar 2003], Port Numbers, http://www.iana.org/assignments/port-numbers
Die Portliste der IANA informiert über die reservierten Ports. In der frühen Ausgabe von 2003 kann eindeutig erkennt werden, dass sich Microsoft den UDP-/TCP-Port 3074 für Xbox Live reserviert hat.
JOHND03 [8. Februar 2003], Re: TCP/IP-Implementierung der Xbox, Adrea Live Forum (Technik), http://www.arealive.de/viewtopic.php?t=1251
JOHND03 liefert in seiner Reply auf meine Ankündigung dieses Textes einige wertvolle Hinweise, wie zum Beispiel die dynamische Portvergabe in Kapitel 14 und das zu kurze UDP-Aging eines Routers in Kapitel 15.
McClure, Stuart / Scambray, Joel / Kurtz, George [1999], Hacking Exposed, McGraw-Hill Companies, Deutsche Übersetzung durch Ian Travis, Das Anti-Hacker-Buch, MITP Verlag
In diesem Buch wurde erstmals eine Unterscheidung der verschiedenen Denial of Service-Vorgehensweisen dokumentiert.
Meyer, D. [Juli 1998], RFC 2365 - Administratively Scoped IP Multicast, http://www.faqs.org/rfcs/rfc2365.html
Dieses RFC beschäftigt sich mit dem für administrative Zwecke vorgesehenen IP-Adressbereich des Multicastings.
Northcutt, Stephen / Novak, Judy [2000], Network Intrusion Detection, MITP, deutsche Übersetzung, Intrusion Detection-Systeme – Spurensuche im Internet, MITP-Verlag, zweite Auflage durch Marc Ruef übersetzt, April 2003
Stephen Northcutt und Judy Novak geniessen in Kreisen der Intrusion Detection-Analytiker einen hervorragenden Ruf. Und dies nicht zuletzt wegen ihres Buches über elektronische Einbruchserkennung, das erstmals auf technischer Ebene sehr tiefgründig klassische Angriffsmuster untersucht hat.
Plummer, David C., [November 1982], RFC 826 - An Ethernet Address Resolution Protocol, http://www.faqs.org/rfcs/rfc826.html
David C. Plummer beschreibt in seinem RFC sehr detailliert die Funktionsweise von ARP (Address Translation Protocol), das für die Umwandlung von IP- in Ethernet-Adressen zuständig ist. Dabei wird auch der fiktive Algorithmus einer Implementierung abgedruckt.
Postel, Jon [September 1981], RFC 792 - Internet Control Message Protocol, http://www.faqs.org/rfcs/rfc792.html
In diesem grundlegenden RFC des verstorbenen Jon Postel werden die grundlegenden Spezifikationen von ICMP festgelegt. Darin findet sich eine detaillierte Auflistung aller Typen und der möglichen Codes. Eine wichtige Quelle, wenn es um ICMP geht.
Rekhter, Y., Moskowitz, B., Karrenberg, D., De Groot, G. J., Lear, E., [Februar 1996], RFC 1918 - Address Allocation for Private Internets, http://www.faqs.org/rfcs/rfc1918.html
In diesem RFC werden die neuen privaten Adressbereiche bekanntgegeben. Der wichtigste dieser für diese Publikation ist das Klasse C-Netzwerk 192.168.0.0/24. Dieses verwenden wir für das lokalen LAN.
Rogge, Marko [August 2002], nmap Secure Scanner, http://www.computec.ch
Diese Abhandlung von Marko Rogge beschäftigt sich mit dem populären Scanning- und Auswertungs-Tool nmap. Es werden die verschiedenen Möglichkeiten anhand der Windows-Portierung des ursprünglich für Linux geschriebenen Programms erläutert. Ein gutes Dokument für Einsteiger; als Ersatz oder Ergänzung zur man-Page der Software geeignet.
Ruef, Marc [4. April 2000], Denial of Service, http://www.computec.ch
In dieser Publikation beschäftige ich mich mit den klassischen Denial of Service-Methoden. So werden die Möglichkeiten von SYN-Flooding, Ping of Death und Teardrop vorgestellt.
Ruef, Marc [28. April 2000], nmap (Network Mapper) – Erweiterte Scanning-Techniken, http://www.computec.ch
In dieser relativ frühen Publikation von Marc Ruef wird die Funktionsweise und Möglichkeiten der populären Scanning-Software nmap (Network Mapper) von Fyodor vorgetragen. Lange Zeit bevor es erstmals eine offizielle deutschsprachige Übersetzung der nmap man-Page gab, galt diese Publikation als deutschsprachige Referenz für die Software.
Ruef, Marc [21. Januar 2001], Die Sicherheit von Windows, http://www.computec.ch
In diesem Kompendium zur Computersicherheit werden kurz und knapp die verschiedenen Angriffs-Techniken betrachtet. Gut als Einführung oder Spickzettel geeignet.
Ruef, Marc [31. Januar 2003], Xbox Live Rezension, http://www.amazon.de/exec/obidos/ASIN/B000089Q4N/
Auf amazon.de veröffentlichte ich eine der ersten Benutzer-Rezensionen zum Xbox Live-System von Microsoft. Ich war absolut ud auf ganzer Linie begeistert.
Ruef, Marc [10. April 2003], Xbox-Crew Forum - TCP/IP-Implementierung der Xbox Version 2.5 [7. April 2003], http://www.xbox-crew.de/forum/thread.php?threadid=326
In diesem Thread des Xbox-Crew Forums werden nocheinmal die Grenzen von Fast-Path besprochen.
Ruef, Marc / Gieseke, Wolfram / Rogge, Marko / Velten, Uwe [November 2002], Hacking Intern, Data Becker, Düsseldorf, ISBN 381582284X
In diesem Buch wird die Funktionsweise von Portscanning und full-connect TCP-Portscans vorgetragen. Die Funktionsweise wird jeweils durch einleuchtende tcpdump-Ausgaben erläutert, so dass der Leser schnell versteht, was auf der Netzwerkebene bei den besagten Zugriffen stattfindet.
Stevens, Richard W. [1990], UNIX Network Programming, Prentice Hall, ISBN 0-13-949876-1
In diesem Buch erläutert Stevens ungemein detailliert die TCP/IP-Programmierung. Man könnte fast sagen, dass dieses Buch den Blickwinkel von Stevsn populärer "TCP/IP Illustrated"-Reihe Richtung Entwickler verschiebt.
Stevens, Richard W. [1994], TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley Professional Computing Series, ISBN 0-201-63346-9
Der erste Band von Stevens' Trilogie zum Thema TCP/IP ist ein wahrer Schatz. Einmal mehr versteht es der Autor eine hochkomplexe Materie dem Leser leicht verständlich und mit interessanten Hintergrundinformationen gespickt näherzubringen. Auch wer TCP/IP nur vom Hörensagen kennt, wird sich in diesem Buch schnell zurechtfinden. Langweilig wird es einem selten, denn man erhält viele Informationen und spannende Details, die der Autor durch jahrelanges Arbeiten mit der Materie erworben hat.

Betriebssystem	UDP	ICMP
AIX	30
BSD4.4	64
DEC Pathworks V5	30
Cisco Router ISO 12.2.1	255
FreeBSD 2.1R	64
HP/UX 9.0x	30
HP/UX 10.01	64
Irix 5.3	60
Irix 6.x	60
Linux	64
MacOS/MacTCP 2.0.x	60
NetGear FM114P	64
OS/2 TCP/IP 3.0	64
OSF/1 V3.2A	30
QNX Neutrino OS	255
Solaris 2.x	255
SunOS 4.1.3/4.1.4	60
Ultrix V4.1/V4.2A	30
VMS/Multinet	64
VMS/TCPware	64
VMS/Wollongong	30
VMS/UCX	128
Windows for Workgroups	32
Windows 95	32
Windows 98	32
Windows 98 Second Edition	32
Windows ME	128
Windows NT 3.51	32
Windows NT 4.0	128
Windows 2000	128
Windows XP Professional	128
Xbox Live	64	64

Spiel	Online- Spiele	Content- Download	Ranglisten
Capcom vs SNK EO 2	X		X
Mech Assault	X	X
Moto GP	X		X
Sega NBA 2k3	X	X	X
Sega NFL 2k3	X	X	X
Sega NHL 2k3	X	X	X
Tom Clancy Ghost Recon	X	?
Tom Clancy Splinter Cell		X
Whacked	X

Name	Beschreibung
arnudp.c	UDP-Flooder
echok.c	ICMP echo-Flooder
jolt.c	Übergrosse Fragmente
overdrop.c	Modifizierte Variante von teardrop.c, die übergrosse Pakete benutzt.
synful.c	SYN/ACK-Flooder