Technische Universitt Hamburg-Harburg a Sicherheit in verteilten Anwendungen Arbeitsbereich 4-16 Harburger Schlossstrae 20 21079 Hamburg-Harburg
Abstract
The Linux Based Virtual Teaching Network is built upon open-source software components. These components are the Linux operating system, the virtual TUN/TAP network cards, and User Mode Linux (UML). UML enables one or more instances of the Linux kernel to run in the userspace of a host system. The UMLs are then interconnected by the virtual TUN/TAP devices which provide bridges between the UML kernel in the userspace and the networking stack of the host in the kernel space. As an emulation of a complete network consisting of dierent hosts, subnets, and the necessary network components, it oers the possibility to perform research in the eld of computer and network security and to experiment with network assaults in a secure environment. This report describes the setup of the Linux Based Virtual Teaching Network, the structure of the network created, the selected hardware platform and its performance, and example scenarios implemented.
Inhaltsverzeichnis
1 Einfhrung u 2 Die Aufgabe 3 Virtuelle Server 3.1 Virtuelle Maschinen . . . . . . . . . 3.2 Realisierungen virtueller Maschinen . 3.2.1 Emulatoren . . . . . . . . . . 3.2.2 Linux VServer . . . . . . . . 3.2.3 User Mode Linux . . . . . . . 1 3 4 4 5 5 7 9 12 12 12 12 13 17 17 18 19 19 20 22 24 24 26 26 28 30 30 30 31 32 33 34 34 35 36 37 39
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
4 Das Setup 4.1 Die Komponenten . . . . . . . . . . . . . . . . . . 4.1.1 Die UMLs . . . . . . . . . . . . . . . . . . . 4.1.2 Die TUN-/TAP-Devices . . . . . . . . . . . 4.1.3 Die IEEE802.1d-Bridges . . . . . . . . . . . 4.2 Optimierungen . . . . . . . . . . . . . . . . . . . . 4.2.1 /tmp auf shmfs . . . . . . . . . . . . . . . . 4.2.2 Separate Kernel Address Space, SKAS3 . . 4.3 Die Hilfsskripte . . . . . . . . . . . . . . . . . . . . 4.3.1 /etc/init.d/uml . . . . . . . . . . . . . . 4.3.2 /home/uml/uml/startall . . . . . . . . . . 4.3.3 /home/uml/uml/uml1/startuml bzw. uml1 4.3.4 /home/uml/uml/stopall . . . . . . . . . . 4.3.5 /home/uml/uml/rmcows . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
5 Das Netzwerk 5.1 Der aktuelle Stand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Denkbare Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Das 6.1 6.2 6.3 System Die Hardware . . . . . Das Betriebssystem . . Die Performance . . . 6.3.1 Der Durchsatz 6.3.2 Die Latenz . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Ubungsszenarios und Tools Die Netzwerkanalyse . . . . Das Sning . . . . . . . . . Das Spoong . . . . . . . . Das DNS Cache Poisoning .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
8 Schlussbemerkung
ii
1 Einfuhrung
Angesichts tglich neuer Meldungen uber Sicherheitslcher, Viren und Wrmer, die a o u sogar schon den Weg in die Massenmedien gefunden haben, spielt das Thema Compu tersicherheit eine immer grere Rolle. o Um die Mglichkeit zu haben, sich mit den Sicherheitsrisiken, die im Besonderen die o immer weiter fortschreitende Vernetzung mit sich bringt, auseinanderzusetzen, reichen theoretische Betrachtungen oft nicht aus. Praktische Arbeit, Experimente und Analysen helfen beim Verstndnis immer neuer Sicherheitsbedrohungen. Sie ebnen den Weg fr a u Programmierer und Administratoren, diese und neue Sicherheitslcken zu schlieen u oder bereits im Vorfelde zu vermeiden. Im Rahmen der Vorlesung Network Security des Arbeitsbereiches Sicherheit in verteilten Anwendungen an der Technischen Universitt Hamburg-Harburg, gehalten a von Prof. Dr. Gollmann, sollte Studenten die Mglichkeit gegeben werden, Erfahrungen o im Bereich der Netzwerksicherheit zu sammeln. Hierfr wurde ein Ubungsnetzwerk u bentigt, das die Analyse von aktuellen Sicherheitsprotokollen ermglicht, aber auch o o die Mglichkeit bietet, durch Ausprobieren von Exploits mitzuerleben, wie gut es um o die Sicherheit im Internet tatschlich bestellt ist. a Ein reales Ubungsnetzwerk zu errichten, erfordert eine Menge Ressourcen. Der Platz, um die dafr ausgewhlten Maschinen aufzubauen, muss vorhanden sein. Da u a es sich in den meisten Fllen nicht um eine uniforme Hardwarebasis handelt, ist ein a erhhter Aufwand fr die Pege und Administration ntig. Dies schlgt sich sowohl in o u o a der aufzuwendenden Zeit, wie auch indirekt im nanziellen Aufwand nieder. Weiterhin sollte das Netz vom Campus-Netzwerk abgeschottet sein, um strende Einsse der o u Aktivitten im Ubungsnetzwerk vom universitren Netzwerk fernzuhalten. a a An dieser Stelle entstand der Plan, dieses komplette Ubungsnetzwerk zu emulieren. Die oben genannten Nachteile treten so entweder gar nicht oder in stark abgeschwchter a Form auf: durch Remote-Logins und die Emulation wird nur eine Host-Maschine bentigt, ein Ubungs-Labor kann ganz wegfallen. Alle virtuellen Ubungsrechner teilen o die selbe (virtuelle) Hardwarebasis, was die Administration und Pege vereinfacht. Und durch das Einschlieen des gesamten Netzwerkes in einen Host-Rechner ist auch eine gute Kontrolle des evtl. bsartigen Netzwerkverkehrs leicht mglich. o o Diese Ausarbeitung beschreibt nun die Entwicklung eines solchen virtuellen Ubungsnetzwerkes.
2 Die Aufgabe
Um die Vorlesung Netzwerksicherheit mit geeigneten Ubungen untersttzen zu knnen, u o ist es notwendig auf ein Ubungsnetzwerk zurckgreifen zu knnen. Die Aufgabe eines u o Ubungsnetzwerks ist es, Studenten die Mglichkeit zu geben, verschiedene Attacken o und Sicherheitskonzepte in der Praxis zu erfahren. Darber hinaus soll dieses Netzwerk u auch die Forschung untersttzen knnen, indem es ein Testlabor bereitstellt. u o Der nanzielle Aufwand fr ein reales Computer-Netz ist relativ hoch, zumal die u beteiligten Computer nicht zeitgleich am produktiven Tagesbetrieb teilnehmen knnen. o Die Aufgabe ist es daher, ein Computernetzwerk virtuell auf einem Computer aufzubauen. Fr die Umsetzung dieser virtuellen Serverumgebung gibt es einige Mglichkeiu o ten. Zwei populre Technologien fr Linux sind dabei das Linux VServer Projekt a u und User Mode Linux. Plattformbergreifend gibt es zustzlich die Mglichkeit auf u a o Emulatoren (PearPC, VMware) zurckzugreifen. Ein intensives Auswahlverfahren soll u den besten Kandidaten ermitteln. Anschlieend soll das Ubungsnetzwerk aufgebaut werden. Bei der Auslegung und Gestaltung der einzelnen virtuellen Einheiten sollen eektive Test-Szenarios bercksichu tigt werden. Beim Entwurf der Test-Szenarios sollen grundlegende Konzepte der Netzwerksicherheit verdeutlicht werden. Bei der Auslegung der freien Parameter fr das Netzwerk sollen Geschwindigu keitstests das optimale Ergebnis ermitteln - sinnvolle Optimierungen sind hier zu whlen. a Abschlieend soll das Computernetzwerk in Betrieb genommen und in der Ubung Netzwerksicherheit vorgestellt werden. Es sollte dabei ein einfaches Verfahren der Zugriskontrolle entwickelt werden. Die Studenten sollen zeitlich begrenzte Passworte zugeteilt bekommen. Wenn die Zugriszeit abgelaufen ist, muss das Netzwerk sich in den initialen Zustand zurcksetzen, damit alle temporren Anderungen und Angrie u a ohne weitere Folgen bleiben.
3 Virtuelle Server
Das Ubungsnetzwerk soll vollstndig in einer Host-Maschine emuliert werden. Deshalb a gibt dieses Kapitel eine Ubersicht darber, was virtuelle Server bzw. virtuelle Maschinen u eigentlich sind und welche Mglichkeiten zur Realisierung es gibt. o Die Aufzhlung der Realisierungen erhebt nicht den Anspruch auf Vollstndigkeit, stellt a a aber drei Mglichkeiten mit ihren doch recht unterschiedlichen Konzepten vor. o
Hardware Abstraction Layer Die Container-Dateien enthalten das Dateisystem des Gast-Systems mitsamt der Dateien, die zu dessen Betrieb ntig sind ( virtuelle Festplatte). o
Ebenfalls ist es leicht mglich, Backups oder Wiederherstellungen der Gast-Systeo me vorzunehmen, indem man Images der Gast-Systeme sichert oder aufspielt. bessere Systemauslastung: Auf der einen Seite haben virtuelle Maschinen durch die zustzlichen Abstraktia onsschichten und Verwaltungsstrukturen immer gewisse Performanceeinbuen im Vergleich zu Maschinen, auf denen das System direkt auf der realen Hardware luft. Auf der anderen Seite kann man eine deutlich erhhte Auslastung der vora o handenen Hardware erreichen, wenn es sich bei den Gast-Systemen um weniger aufwendige Anwendungen handelt. Als Sicherheitsmanahmen werden z. B. die angebotenen Dienste auf unterschiedlichen Maschinen betrieben. Im Falle der Kompromittierung eines Dienstes (und damit evtl. der ganzen Maschine) kann so der Betrieb der ubrigen Services auf recht erhalten werden. Wenn es sich dabei jeweils um Anwendungen handelt, die die Maschine, auf der sie laufen, nicht auslasten, so kann mittels virtueller Maschinen eine bessere Systemauslastung erzielt werden. Die Maschinen der einzelnen Dienste werden als virtuelle Maschinen auf wenigen physikalischen Maschinen zusammengefasst, die vorhandenen Hardwareressourcen werden dabei ezienter ausgelastet. Nachteil dabei ist jetzt ein neuer Single Point of Failure: Bei einem Ausfall der Hostmaschine sind alle Dienste nicht erreichbar - der Vorteil erhhter Ausfallsichero heit durch physikalisch getrennte Maschinen geht im Gegenzug der verbesserten Systemauslastung verloren. geringere Kosten: Die genannten Punkte fhren alle zu reduzierten Kosten beim Einsatz virtuelu ler Maschinen. Gnstiger Umzug von Maschinen, schnellere Wiederaufnahme des u Dienstes bei Hardwareschden4 , einfachere Wartbarkeit durch uniforme Hardwaa replattform sowie verbesserte Systemauslastung, was zu geringeren Hardwareanschaungskosten fhren kann. u Die Vorteile der verringerten Kosten werden aber mit einem erhhten Risiko ero kauft, bei dem individuell abgewogen werden muss, ob das eingegangene Risiko die gesparten Ausgaben wert ist.
sondern auch Hardware emulieren zu knnen, die eine grundlegend andere Systemarchio tektur hat. Ein gutes Beispiel dafr ist PearPC.[1] u PearPC ist ein PowerPC-Emulator, d. h., er ermglicht es, auf x86-Hardware eine o PowerPC-Maschine zu emulieren. Der PowerPC ist ein RISC-Prozessor, der mit BigEndian-Bytereihenfolge arbeitet, whrend x86-Prozessoren (wie Intel und AMD) CISCa Prozessoren mit Little-Endian-Bytereihenfolge sind. Diese Prozessoren wurden z. B. von Apple mit dem Betriebssystem Mac OS X eingesetzt. Diese Architektur-Unterschiede verhinderten bis vor kurzem die native Ausfhrung von u z. B. Mac OS X auf x86-basierten Computern (Apple wird nun in Zukunft Mac OS X auch fr x86 anbieten). u
Emulator 1 Anwendungen
Emulator 2 Anwendungen
Abbildung 1: Schema eines Emulators, Grak in Anlehnung an [3] PearPC stellt nun eine emulierte PowerPC-CPU bereit, sowie weitere Hardwarekomponenten, die bentigt werden, um ein Betriebssystem in einer emulierten Umgebung o ausfhren zu knnen: PCI-Bridge, IDE-Controller, Pseudo-USB-Controller, sowie eine u o Firmware zum Systemstart. Bei der CPU gibt es zwei unterschiedliche Betriebsarten: a) die vollstndige Emulation in Software und b) einen JITC5 fr x86-Systeme, der die a u Maschinenbefehle fr den PowerPC zur Laufzeit in x86-Befehle umsetzt und dann auf u der realen Hardware des Host-Systems ausfhrt. Die zweite Variante ist deutlich peru formanter, aber auf x86-Systeme als Host beschrnkt. a Im Groen und Ganzen ist die Performance bei der Emulation einer anderen ProzessorArchitektur im Vergleich zu echter Hardware aber sehr schlecht: Bei PearPC ist die Performance der JITC-Variante ca. 15mal langsamer als das Host-System, whrend die a softwaremige CPU-Emulation ca. 500mal langsamer als der Host ist. Die Performance a
5
Just-In-Time-Compiler
Prozess 1
Prozess 2
Prozess 3
Prozess 4
Prozess n
Linux-Kernel
Hardware
Prozess 1
6
Prozess 2
Prozess 3
Prozess 4
Prozess n
Anwendungen
der emulierten Hardware (wie z. B. der IDE-Controller) ist dagegen nicht betroen und damit im Verhltnis als sehr gut einzustufen.[2] a 3.2.2 Linux VServer Ein anderes Projekt fr virtuelle Maschinen auf Linux-Basis ist das Linux VServer u Projekt.[8] Als groer Unterschied zu der vorher vorgestellten Emulatorlsung ist zu nennen, dass o der Emulator nicht nur betriebssystemunabhngig, sondern auch plattformunabhngig a a ist. Das jetzt folgende Konzept der Linux VServer ist weder das eine noch andere: sowohl Prozessorarchitektur als auch Betriebssystem von Host-System und Gast-System mssen identisch sein. u Linux VServer sind eine sehr leichtgewichtige Mglichkeit, das Konzept virtueller o Maschinen umzusetzen, sie haben deutlich weniger Overhead als z. B. ein Emulator. Dadurch ist es mglich, sehr viele VServer auf einer Maschine einzusetzen (Berichte o sprechen von bis zu einigen Hundert VServern auf einem Host).
Host
VServer 1
VServer 2
Host
{
Hardware Prozess 5 Prozess 6 Prozess 7 Prozess 8
7
{
Prozess 2 Prozess 3 Prozess 4
Abbildung 2: Schema des Linux VServer Projektes, Grak in Anlehnung an [3] Die Leichtgewichtigkeit der VServer liegt darin, dass keine eigenstndigen Gast-Systeme a mit eigenem Systemkern etc. gestartet werden, sondern die ntigen Programme, o Skripte und Kongurationsdateien im Dateibaum des Hosts liegen und sogenannte Security Contexts eingefhrt werden. Dies bedeutet, dass die Prozessstrukturen des u Host-Systems um eine ID ergnzt werden, mittels derer man zur Laufzeit unterscheiden a
{
Prozess 1
{
Anwendungen Prozess 9 Prozess n
kann, welcher Prozess zu welchem VServer gehrt - dabei laufen aber alle Prozesse o parallel auf dem selben Scheduler des Hostes - die nicht zum eigenen VServer gehrigen o 6 Prozesse werden uber eine Art View ausgeblendet. Diese zustzlichen Datenstrukturen bedeuten im Vergleich zu einer Emulator-Lsung, a o die als reines Userspace-Programm luft, einen massiven Eingri in die Kernel-Quellen a von Linux. Das Linux VServer Projekt war ursprnglich zur Realisierung dieser Studienarbeit u vorgesehen gewesen, da der geringe Overhead der VServer als groer Vorteil angesehen wurde, der es ermglicht htte, ein verhltnismig groes Ubungsnetzwerk auch auf o a a a einer lteren, performanceschwcheren Maschine zu errichten. a a Nach dem Studium der Grundlagen der VServer und dem Aufbau einer passenden Arbeitsumgebung auf dem Host-System begannen die ersten Versuche mit den VServern. Das Erstellen, Starten und Beenden von VServern sowie das Arbeiten innerhalb der VServer war nach recht kurzer Zeit mglich. Danach wurden die Netzwerkanbindungen o der VServer realisiert. Dazu wurden die VServer z. B. mit einem Alias auf das externe Netzwerkdevice eth0 als zu benutzende Netzwerkverbindung gestartet. Mit dieser Konguration ist es mglich von auen auf die auf den VServern laufenden Dienste o zuzugreifen sowie die VServer untereinander anzusprechen. Da aber nicht jeder VServer Zugri auf alle anderen VServer haben sollte, musste eine virtuelle Netzwerkstruktur geschaen werden. Dazu kamen als virtuelle Netzwerkkarten die TUN-/TAP-Devices des Linux-Kernels (siehe Kapitel 4.1.2, Seite 12) sowie das Ethernet-Bridging nach IEEE 802.1d (siehe Kapitel 4.1.3, Seite 13) als virtuelle Switches (Multiport-Bridges) zum Einsatz. Den VServern wurden als zu nutzende Netzwerkkarten die virtuellen TUN-/TAPDevices deniert, die entsprechend der gewnschten Netzwerkstruktur geswitched u worden waren. Die Kommunikation zwischen den VServern konnte jedoch nicht beeinusst werden. Noch immer konnte jeder VServer auf jeden zugreifen, selbst, wenn sich diese in unterschiedlichen virtuellen Subnetzen befanden und die dazwischenliegenden VServer kein Routing durchfhrten. Auch konnte auf den VServern, u die die Pakete htten weiterleiten mssen, kein Trac festgestellt werden, obwohl die a u bestehenden Kommunikationsverbindungen der anderen Maschinen auf jeden Fall durch die beobachteten Maschinen verliefen. In einem weiteren Schritt wurden Paketlter-Regeln (iptables) erzeugt, die auf den virtuellen Netzwerkkarten den IP-Verkehr reglementieren sollten - diese zeigten aber wiederum keinen Eekt, die Kommunikation zwischen allen VServern blieb ungestrt. o Weitere Internet-Recherchen ergaben dann, dass diese Idee und die damit verbundenen Probleme oensichtlich bereits einmal aufgekommen waren, allerdings war keine Lsung o des Problems zu nden. Eine Erklrung fr die beschriebenen Probleme ergab sich erst bei einer Diskusa u sion mit dem Betreuer des Linux VServer Projektes, Herbert Ptzl: o Dadurch, dass es trotz des Konzeptes der Security Contexts tatschlich nur ein a einziges Linux-System gibt, gibt es nur einen einzigen Linux-Kernel als HardwareAbstraktionsschicht und damit auch nur einen einzigen TCP/IP-Stack. Diesem einen
6
Netzwerk-Stack sind zu jedem Zeitpunkt alle in diesem System existenten IP-Adressen bekannt, unabhngig von den Security Contexts, die sich auf die User-Prozess-Ebene a beziehen. Dies fhrt dazu, dass jedes von einem VServer versendete IP-Paket, das an u eine IP-Adresse innerhalb der selben Maschine adressiert ist, vom Netzwerk-Stack als ein internes Paket erkannt wird und damit immer uber das Loopback-Device versendet wird. Die Folge daraus ist, dass smtliche Strukturen, wie das virtuelle Netzwerk und die a iptables-Regeln auf diesen Netzwerk-Devices, umgangen werden - fr dieses Problem u gibt es keine Lsung. Die VServer knnen untereinander mittels ihrer externen Adressen o o unbeschrnkt kommunizieren (unter Nutzung des Loopback-Devices), und sie sind a durch den Paketlter des Host-Systems gegen Pakete von auen geschtzt. Fr eine u u virtuelle Netzwerkstruktur innerhalb eines Hostes ist das Linux VServer Projekt damit aber ungeeignet. Aus diesem Grund, und da die in Kapitel 3.2.1 genannten Emulator-Lsungen zu o viele Ressourcen beanspruchen, el die Wahl auf ein anderes Projekt: 3.2.3 User Mode Linux User Mode Linux (UML) [4] verfolgt einen hnlichen Ansatz wie ein Emulator, setzt aber a auf einer anderen Ebene auf. Der Linux-Kernel ist die Hardware-Abstraktionsschicht fr die Benutzer-Prozesse in eiu nem Linux-Kernel. Hardwareseitig ist er mit den fr die Plattform ntigen Treibern u o ausgestattet, whrend er softwareseitig standardisierte Schnittstellen fr die Programa u me anbietet. Ein Programm ist also im Idealfall vollkommen unwissend uber z. B. die hardwaremige Struktur des Arbeitsspeichers, es greift nur uber die Softwareschnitta stellen des Kernels auf den Speichers zu. Fr UML wird der Kernel des Gast-Systems so verndert, dass er fr eine neue Zielu a u plattform kompiliert werden kann. D. h., dass der Kernel hardwareseitig nicht z. B. eine i386-Hardware erwartet, sondern eine neu denierte UML-Architektur. Diese hat die Besonderheit, nicht auf die reale Hardware zuzugreifen, sondern den Kernel als BenutzerProzess auf einem Linux-Host-System laufen zu lassen. Um bei dem Beispiel des Speicherzugris zu bleiben: Fordert ein Prozess innerhalb der UML einen Speicherzugri beim UML-Kernel an, so wird der Speicherzugri durch den UML-Kernel nicht mittels eines Hardwarezugris auf dem RAM-Baustein des HostRechners durchgefhrt, sondern der Speicherzugri von dem UML-Prozess an den Kernel u des Host-Systems weitergereicht - erst dieser Kernel fhrt dann den physikalischen Speiu cherzugri aus. dass der Speicherzugri des Programms innerhalb der UML nicht direkt auf echter Hardware ausgefhrt wird, bleibt dem Prozess unbekannt, da die genaue u Vorgehensweise des Speicherzugris durch die Hardware-Abstraktion des UML-Kernels verdeckt wird. Durch die beschriebene Vorgehensweise ist es beispielsweise mglich, einen UML-Kernel o der Version 2.4.x auf einem Host-System mit einem Kernel der Version 2.2.x laufen zu lassen. Um aber nicht nur beim Kernel eine Unabhngigkeit vom Host-System zu erreia chen, sondern dies auch fr die eigentliche Linux-Distribution zu haben, liegen bei UML u die Dateien des Gast-Systems nicht in einem Verzeichnis des Host-Systems (wie bei Li-
nux VServer, siehe Kapitel 3.2.2), sondern in einer Container-Datei, die jedes beliebige Linux-Dateisystem enthalten kann und dem UML-Prozess mit Mount-Punkt als Startparameter ubergeben wird. Diese Container-Dateien lassen sich auch leicht auerhalb der UML-Umgebung als Loop-Device mounten, um so z. B. Anderungen an der Konguration durchfhren zu knnen, ohne auf eine lauhige UML-Umgebung angewiesen u o a zu sein. Weiterhin lassen sich diese Container sehr viel leichter von einem Host zu einem anderen transportieren, da man sich z. B. uber die Vergabe der Dateirechte oder die Ubereinstimmungen der User-IDs auf altem und neuen Host keine Gedanken machen muss. Alle Eigenschaften des UML-Gast-Systems sind vollkommen autonom von denen des Host-Systems und werden mit der Container-Datei transportiert.
UML 1
UML 2
Anwendungen
Anwendungen
Anwendungen
Abbildung 3: Schema von User Mode Linux, Grak nach [3] UML bietet in Verbindung mit dem Konzept der Container-Dateisysteme ein weiteres Feature an, das sich Copy-On-Write (COW) nennt. Hierbei werden zwei Container dateien geschichtet. Alle Schreibzugrie werden auf der COW-Datei durchgefhrt. u Lesezugrie werden aus der COW-Datei bedient, sofern die angeforderten Daten dort vorhanden sind, ansonsten erfolgt der Lesezugri auf die Master-Datei. Dies passiert fr u das Gast-System vollkommen transparent. Die Vorteile dieses Verfahrens liegen darin, dass man sehr einfach testweise Verndea rungen an dem System vornehmen kann (diese Anderungen erfolgen nur auf der COW Datei). Sollte eine dieser Anderungen zu unerwnschten Ergebnissen fhren, so reicht u u es, das System herunterzufahren, die COW-Datei zu lschen, und so den Systemzustand o zum Zeitpunkt der COW-Erstellung wiederherzustellen. Diese Funktion erweist sich als sehr praktikabel im Anwendungsfall des Ubungsnetzwerkes (siehe Kapitel 4.3.5). Weiterhin ist es auf diese Weise mglich, ein Master-Dateisystem zwischen mehreren o
Prozess 1
UML-Kernel
Prozess 2
Prozess 3
Prozess 4
Linux-(Host-)Kernel
Prozess n
Hardware
Prozess 1
10
UML-Kernel
Prozess 2
Prozess 3
Prozess 4
Prozess n
UMLs zu teilen. Dabei kann sehr viel Speicherplatz gespart werden. Das Basissystem ist nur einmal vorhanden und kann von vielen UMLs benutzt werden, whrend jedes a Gast-System seine Anderungen in die eigene COW-Datei schreibt.
11
4 Das Setup
In diesem Abschnitt werden zuerst die Teilkomponenten des gesamten Ubungsnetzwerks erlutert, bevor sie im folgenden Kapitel zur Errichtung des Netzwerks zusammengefhrt a u werden. Weiterhin werden einige Optimierungen erlutert, die an den Komponenten zur Funktioa nalittssteigerung durchgefhrt wurden, sowie die ntigen Hilfsskripte, die zur Steuerung a u o und Administration des Netzwerks auf dem UML-Host eingesetzt werden.
12
nun eine Schnittstelle fr Userspace-Prozesse bereit, so dass diese mit dem Kernel u kommunizieren knnen. Pakete, die vom Kernel erzeugt und an den Netzwerktreiber o geschickt werden, werden von einem klassischen Ethernet-Treiber als Ethernet-Rahmen auf das Ethernet geschrieben, whrend der TUN-/TAP-Treiber die Pakete in den a Userspace schreibt, wo ein Programm sie entgegennehmen und weiterverarbeiten kann. Dies ist z. B. sinnvoll bei einer Tunnellsung wie VTun, die die Verschlsselung der o u getunnelten Pakete im Userspace durchfhrt und so keinen Eingri in die Netzwerku funktionen des Linux-Kernel ntig macht. o Der Name TUN-/TAP-Device rhrt daher, dass dieses Device in zwei unterschiedlichen u Betriebsarten arbeiten kann: als TUN- oder als TAP-Device. Der Unterschied besteht im jeweiligen ISO/OSI-Layer, in dem die Pakete angenommen bzw. ausgegeben werden: Das TUN-Device arbeitet auf IP-Ebene, also auf Schicht 3 des OSI-Modells. Es arbeitet mit IP-Paketen mitsamt den darin gekapselten Daten. Das TAP-Device arbeitet auf Ethernet-Ebene, also auf Schicht 1/2 des OSIModells. Es arbeitet mit Ethernet-Rahmen und damit eine Kapselungsschicht weiter auen als das TUN-Device. Fr das Ubungsnetzwerk werden nur die TAP-Devices eingesetzt, da die UMLs auf u einem virtuellen Ethernet-Device aufsetzen und somit Daten, die von innerhalb der UML kommen, als Ethernet-Rahmen nach auen an das virtuelle Netzwerk-Device weiterreichen. Der TUN-/TAP-Device-Treiber kann im Linux-Kernel als Modul eingebunden oder direkt in den Kernel hineinkompiliert werden. Whrend der Arbeiten zu dem a Ubungsnetzwerk stellte sich das Nachladen als Modul mehrfach als problematisch heraus. Diese Fehlfunktionen unbekannten Ursprungs lieen sich aber dadurch beheben, dass der Treiber direkt in den Kernel hineinkompiliert wurde. Der Treiber kann dann whrend der Laufzeit mittels des Userspaceprogramms tunctl, a welches sich unter Debian im Paket uml-utilities bendet, konguriert werden. Dieses Tool ermglicht es, Devices anzulegen, sie mit den korrekten Rechten zur o Verwendung durch bestimmte Benutzer zu versehen, sowie die Devices nach Gebrauch wieder zu entfernen. 4.1.3 Die IEEE802.1d-Bridges Die virtuellen Netzwerkkarten der UMLs mssen untereinander verbunden werden, um u so dem virtuellen Netzwerk eine Struktur zu geben. Bei echten (physikalischen) Maschinen mit echten (physikalischen) Netzwerkkarten werden die Verbindungen durch Hubs oder Switches realisiert. Ein Hub ist dabei ein sog. Multiport-Repeater - ein elektrischer Verstrker, der die elektrischen Signale der a eingehenden Netzwerkkabel an alle angeschlossenen Ausgnge verstrkt ausgibt. Ein a a Switch (genauer: eine Multiport-Bridge) fhrt zwar die gleiche Aufgabe aus, erreicht u dieses Ziel durch integrierte Logik jedoch auf eine ezientere Art und Weise. Das
13
Verhalten von Ethernet-Switches ist in [6] beschrieben. Auf dem Ethernet-Layer werden Informationen aus den eingehenden Ethernet-Rahmen herausgezogen und dann fr eine intelligente Steuerung der Rahmen benutzt - nach einem Lernprozess werden u die ausgehenden Rahmen nur noch auf diejenigen ausgehenden Verbindungen herauskopiert, auf denen auch die entsprechenden empfangenden Stationen angeschlossen sind. Daraus ergeben sich folgende Vorteile: Unicast-Rahmen werden nicht unntig gebroadcastet, wie dies bei einem Hub paso siert weniger Kollisionen, mehr nutzbare Bandbreite es entstehen virtuelle Datenpfade auf denen mehrere Stationen die volle Bandbreite des Netzwerks gleichzeitig ausnutzen knnen hhere Performance bei groen o o Netzen durch das zielgerichtete Weiterleiten der Ethernet-Rahmen wird das Lauschen auf dem Netzwerk erschwert, da ein Mithrer am Switch nur die Pakete erhlt, die o a entweder gebroadcastet wurden oder fr ihn bestimmt sind erhhte Sicherheit u o Der Linux-Kernel stellt nun eine Software-Implementierung solcher Bridges bereit, mit denen sowohl virtuelle NICs der UMLs als auch physikalische NICs des Hostsystems verbunden werden knnen. Die virtuellen Bridges untersttzen dabei alle Features, die o u auch eine reale Bridge zur Verfgung stellt, also von der MAC-Adressen-lernenden Logik u bis hin zum Spanning-Tree-Algorithmus zur Selbstorganisation von Netzen mit mehreren Bridges. In diesem Szenario eines Ubungsnetzwerkes fhrt aber das Verhalten der Bridges zu eiu nem verhltnismig groen Problem, das sich nur mit recht groem Aufwand umgehen a a liee: Die Tatsache, dass das Mithren von Netzwerkkommunikation nur unter erschwero ten Bedingungen mglich ist. o Ziel soll es allerdings gerade sein, auf mglichst einfachem Wege zu einem Dump des o Netzwerkverkehrs zu kommen, um diesen dann mittels eines Netzwerkanalysators wie z. B. Ethereal8 untersuchen zu knnen. Wenn aber bereits fortgeschrittene Technio ken wie ARP-Spoong eingesetzt werden mssten, um uberhaupt den gewnschten u u Datenverkehrs-Mitschnitt zu erhalten, muss bereits zu viel Aufwand investiert werden. Aus diesem Grund wre es wnschenswert, die Bridges auf ein Hub-hnliches Verhalten a u a kongurieren zu knnen, was aber leider nicht mglich ist. Aus diesem Grund wurde o o eine kleine Modikation an den Quelltexten des Bridge-Codes im Linux-Kernel durchgefhrt, um die gewnschte Verhaltensweise zu erhalten. u u Dieser Patch wird im Folgenden erlutert: a Der Hub-Patch Der gesamte Bridge-Code bendet sich im Verzeichnis /usr/src/linux-2.4.29/net/bridge/ des Linux-Kernels. Bei der Analyse des Bridge-Codes stellte sich heraus, dass die Datei bridge input.c
8
http://www.ethereal.com/
14
den Codeteil enthlt, der fr die Entscheidung zustndig ist, ob ein Paket zielgericha u a tet weitergeleitet oder uber alle angeschlossenen Ports gebroadcastet ( geooded) wird.
79 80 81 82 83 84
i f ( dest [ 0 ] & 1) { b r f l o o d f o r w a r d ( br , skb , ! passedup ) ; i f ( ! passedup ) b r p a s s f r a m e u p ( br , skb ) ; goto out ; } Listing 1: /usr/src/linux-2.4.29/net/bridge/br input.c.orig dest ist ein Zeiger auf die Ziel-MAC-Adresse des gerade bearbeiteten EthernetRahmens. In Zeile 79 des Quellcodes wird uberprft, ob es sich bei dem vorliegenden u Rahmen um einen zu broadcastenden Rahmen (Broad- bzw. Multicast) handelt. Wenn dies der Fall ist, so wird die Funktion br flood forward() aufgerufen und durch das u goto in Zeile 83 die weitere Uberprfung des Rahmens ubersprungen. Durch einen minimalen Eingri in den Quelltext lsst sich nun ein hubhnliches a a Verhalten realisieren. Dazu sollen smtliche Rahmen gebroadcastet werden, nicht a nur die Rahmen, die aufgrund ihrer MAC-Adresse dazu bestimmt sind. Um dieses Verhalten zu erreichen, wird der Quelltext wie folgt abgendert: a
79 80 81 82 83 84
i f (1) { b r f l o o d f o r w a r d ( br , skb , ! passedup ) ; i f ( ! passedup ) b r p a s s f r a m e u p ( br , skb ) ; goto out ; } Listing 2: /usr/src/linux-2.4.29/net/bridge/br input.c In Zeile 79 wird nun die MAC-Adresse nicht mehr in die Entscheidung, ob ein Rahmen gebroadcastet werden soll, mit einbezogen.9 Tests haben auf der einen Seite ergeben, dass sich die Bridges nach dem Patchen wie vorgesehen verhalten, auf der anderen Seite hat diese Lsung aber zwei Nachteile: o 1. Dieser Patch wird in den Quelltexten hartcodiert, somit ist das Verhalten nur zur Kompilierzeit nderbar. Whrend der Laufzeit des Systems lsst sich das Verhalten a a a nicht beeinussen. Hierzu wren deutlich tiefere Eingrie in die Kernel-Quellen a ntig, um dann mittels eines Programms im Userspace das Verhalten umschalten o zu knnen. o Zum jetzigen Zeitpunkt mssen zwei Kernel mit den beiden Betriebsarten der u
9
Um den Eingri in den Quelltext so klein wie mglich zu halten, wurde das Konstrukt if (1) o nicht entfernt. Es wird durch die Optimierung des Compilers whrend des Ubersetzungsvorganges a entfernt.
15
Bridge kompiliert werden, von denen zum Bootzeitpunkt der jeweils gewnschte u ausgewhlt wird. a 2. Ein weiterer Nachteil ist, dass alle Bridge-Instanzen in einem System auf den selben Code zugreifen. Deshalb verhalten sich alle Bridges immer gleich - entweder als Bridge, oder als Hub. Ein gemischter Betrieb (br0 als Bridge, br1 als Hub) ist nicht mglich. o Diese Eigenschaft erweist sich im vorliegenden Einsatzbereich aber nicht als ein schrnkend, da das Ubungsnetzwerk nicht auf die Vorteile von Switches angewiesen a ist. Die Software-Bridges im System werden zur Laufzeit mittels des Programms brctl, das sich im Paket bridge-utils bendet, erstellt. Mit brctl lassen sich auch alle Parameter der Bridges beeinussen, wie z. B. das Spanning Tree Protocol (STP) und das Hinzufgen und Entfernen von zur Bridge gehrigen Netzwerkdevices. u o Bemerkung zur Kernel-Version Whrend der Bearbeitung des Projektes kamen mehrere Versionen des Linux-Kernels a zum Einsatz. Der Hub-Patch wurde erstmals im Linux-Kernel 2.4.27 erfolgreich eingesetzt. Mit neu erscheinenden Kernel-Versionen kam der Patch auch in den Versionen 2.4.28 und 2.4.29 zum Einsatz. Das Update auf 2.4.30 konnte allerdings nicht durchgefhrt werden: Ein u mit Hub-Patch versehener Linux-Kernel in der Version 2.4.30 bringt die eingesetzte UML-Version beim Booten zum Absturz. Die UML startet bis zur Netzwerkinitialisierung und bleibt dort stehen, ein Beenden des UML-Prozesses ist nur noch mittels kill vom Hostsystem aus mglich. o Dieses Fehlverhalten tritt mit einem gepatchten 2.4.30er Kernel in Verbindung mit dem UML-Kernel von Debian unstable in Version 2.4.26-um3 reproduzierbar auf. Der Kernel scheint aber kein generelles Problem mit dem Bridging-Code in dieser Version zu haben, da das gesamte Ubungsnetzwerk ohne Hub-Patch wie vorgesehen funktioniert. Kernel-Version 2.4.27 2.4.28 2.4.29 2.4.30 ohne Hub-Patch mit Hub-Patch
Tabelle 1: Kompatibilittsmatrix des Ubungsnetzwerks mit dem Hub-Patch und den a Kernel-Versionen Da sich an dem Bridge-Code von Kernel-Version 2.4.29 zu 2.4.30 nichts gendert hat10 a und auch die selbe UML-Version eingesetzt wurde, liegt die Vermutung nahe, dass an anderer Stelle im Kernel eine Anderung erfolgt ist, die sich jetzt indirekt auswirkt. Evtl. handelt es sich dabei um eine Anderung in der Behandlung von Broadcasts, aber
10
16
dies ist derzeit reine Spekulation, da dieses Verhalten vorerst nicht weiter untersucht worden ist.
4.2 Optimierungen
Die genannten Komponenten, die zur Erstellung des Ubungsnetzwerks bentigt werden, o lassen sich alle ohne weitere Modikationen einsetzen, allerdings gibt es zwei Optimierungen, die als uerst sinnvoll anzusehen sind und deshalb mglichst angewendet wera o den sollten. Beide dieser Optimierungen werden auf die Umgebung des UML-Kernels angewendet: 4.2.1 /tmp auf shmfs Wenn ein UML-Prozess gestartet wird, so erzeugt er standardmig im Verzeichnis a /tmp eine Datei, die in ihrer Gre der Menge Hauptspeicher entspricht, der der UML o beim Start zugewiesen worden ist, da jede UML ihren eigenen Adressraum erhlt. Diese a Datei enthlt also ein Hauptspeicherabbild, das es ermglicht, einer UML mehr RAM a o zuzuweisen, als physikalisch auf dem UML-Host vorhanden ist. Solange der der UML zugewiesene Hauptspeicher deutlich kleiner als der physikalisch vorhandene Speicher ist, wird das Hauptspeicherabbild vollstndig vom Cachea Mechanismus des Hosts erfasst, so dass die Hauptspeicher-Performance der UML als gut zu bezeichnen ist. Wenn man in der UML aber diesen physikalisch nicht vorhandenen Hauptspeicher auch tatschlich ausnutzt, so bricht die Performance der a UML massiv ein, da das Host-System nicht das gesamte Hauptspeicherabbild cachen kann, und somit teilweise Hauptspeicherzugrie in der UML als Festplattenzugrie im Host-System durchfhren muss. Die im Vergleich zu echtem Hauptspeicher um u mehrere Grenordnungen schlechtere Performance von Festplattenzugrien fhrt zu o u dem beschriebenen Performanceeinbruch. Schwachstellen in den Caching-Algorithmen des Hostes knnen aber auch unter der o Bedingung, dass weniger UML-Hauptspeicher als physikalischer Hauptspeicher verwendet wird, dazu fhren, dass UML-Hauptspeicherzugrie auf der langsamen Festplatte u ausgefhrt werden. u Deswegen ist eine bei UMLs hug angewendete Optimierungsmanahme, das /tmpa Verzeichnis auf eine RAM-Disk (genauer gesagt, auf ein Dateisystem vom Typ shm) auszulagern, bzw. ein solches shm-Dateisystem an der Stelle des /tmp-Verzeichnisses in den Verzeichnisbaum einzuhngen. a Die klassische RAM-Disk (ramfs) unter Linux zeichnet sich dadurch aus, dass ihre Gre nicht gendert werden kann und dass die Gre der RAM-Disk fest im Haupto a o speicher reserviert wird, der Hauptspeicher also fr nichts anderes mehr zur Verfgung u u steht und sich somit die RAM-Menge um die Gre der RAM-Disk reduziert. o Im Gegensatz dazu zeigt das shmfs ein deutlich dynamischeres Verhalten: shmfsRAM-Disks knnen beliebig zur Laufzeit erzeugt werden, die Gre ist variabel o o (sogar uber den Hauptspeicherausbau hinaus bis zur Summe aus physikalischem RAM und Swapspeicher), und sie belegen dabei nicht die ihnen zugewiesene Menge an Hauptspeicher, sondern nur den tatschlich belegten Platz. Weiterhin ist das shmfs a
17
auslagerungsfhig, d. h., dass Daten, die zwar in der shmfs-RAM-Disk liegen aber a lngere Zeit nicht bentigt wurden, auf den Swap-Bereich der Festplatte ausgelagert a o werden knnen. o Der Unterschied zwischen einem Standard-/tmp und einem shmfs-/tmp ist also folgender: Beim Standard-/tmp liegt das UML-Hauptspeicherabbild auf der langsamen Festplatte und bendet sich nur unter Umstnden im schnellen RAM (Cache). a Beim shmfs-/tmp liegt das UML-Hauptspeicherabbild im schnellen RAM (shmfs) und bendet sich nur unter Umstnden auf der langsamen Festplatte (Swap). a Damit ist bei der shmfs-Lsung eine potentiell hhere Speicherperformance der o o UMLs zu erwarten. 4.2.2 Separate Kernel Address Space, SKAS3 Ein UML-Kernel-Prozess kann auf jedem Host-Kernel laufen. Wenn der Host-Kernel aber mit keinen speziellen Patches versehen ist, so bendet sich der UML-Kernel immer im sogenannten TracingThread-Modus (tt mode). Dieser Modus ist zwar auf allen HostPlattformen anwendbar, hat aber einige Nachteile: Fr jeden Prozess in der UML wird ein Prozess im Host-System gestartet. Weiu terhin existiert ein sogenannter Tracing Thread, der die UML-Prozesse beobachtet und deren System-Aufrufe uberwacht und abfngt. Er bringt den jeweiligen UMLa Prozess dann dazu, in den Code des UML-Kernels einzutreten, der in den oberen Adressbereich jeden Prozesses gemapped wird. Durch das Mapping des UML-Kernels in den Adressbereich jeden Prozesses haben die Prozesse lesenden und schreibenden Zugri auf den Kernelspeicher, was eine groe Sicherheitslcke darstellen kann. Der schreibende Zugri lsst sich unter u a Performanceeinbuen deaktivieren (jail mode), aber auch der lesende Zugri stellt noch immer ein Problem dar. Whrend der abgefangenen Systemaufrufe oder whrend Interrupts erfolgt die a a Kommunikation mit dem UML-Kernel mittels Signalen, die einen schlechten Einuss auf die Performance der UMLs haben. Der SKAS3-Patch (Separate Kernel Address Space) erweitert den Host-Kernel nun um Funktionen, die es ermglichen, dass der UML-Kernel in einem anderen Speicherbereich o luft, als die Prozesse in der UML. Der Speicher, in dem der UML-Kernel luft, ist a a damit also vllig gegen Zugrie von seinen Prozessen geschtzt, was z. B. fr einen Hoo u u neypot wichtig ist. Weiterhin fllt die Kommunikation uber die Signale weg, was zu a einer sprbaren Geschwindigkeitssteigerung fhrt. u u Die UML-Webseite [4] berichtet von einer Geschwindigkeitssteigerung um bis zu ca. 250%.
18
$TUNCTL u $UMLUSER t tap1 $BRCTL addbr br0 $BRCTL a d d i f br0 tap1 $IFCONFIG tap1 hw e t h e r 0 0 :FF : FF : 0 0 : 0 0 : 0 1 $IFCONFIG tap1 0 . 0 . 0 . 0 promisc up $IFCONFIG br0 1 0 . 1 0 . 0 . 1 0 netmask 2 5 5 . 2 5 5 . 2 5 5 . 0 $IFCONFIG br0 up Listing 3: /etc/init.d/uml start
19
Wichtig ist die Reihenfolge der Arbeitsschritte: wenn beispielsweise tap1 bereits mit ifconfig tap1 up aktiv geschaltet wurde bevor es der Bridge hinzugefgt wurde, so u kann es zu durchaus merkwrdigem Verhalten kommen. u Die einzelnen Skript-Zeilen im Detail: 1. Mit dem Tool tunctl wird das Device tap1 angelegt. Dies gehrt dem User, der o in der Variable $UMLUSER gespeichert ist. $UMLUSER ist der User, der spter den a UML-Kernel-Prozess starten wird, der auf dem jeweiligen TAP-Device aufsetzt. Weitere TAP-Devices knnen z. B. auf diese Zeile folgen. o 2. Mit dem Tool brctl wird die Ethernet-Bridge br0 erstellt. Weitere Bridge-Erstellungen knnen z. B. auf diese Zeile folgen. o 3. Der gerade erstellten Bridge wird ein erstes Device (tap1) hinzugefgt. Es verhlt u a sich also analog zu einem Ethernet-Port an einer physikalischen Bridge. 4. Mit dem Tool ifconfig wird die (virtuelle) Hardware-Adresse (MAC) des Ethernet-Devices gesetzt. Beim Erstellen wird das Device mit einer generierten Adresse versehen. Diese wird aber an dieser Stelle uberschrieben, um der Uber sichtlichkeit halber von Hand ausgewhlte Adressen zu haben. Dies vereinfacht a auch spter die Auswertung von Trac-Dumps. a Da die ersten 3 Oktetts der MAC-Adresse den Hardware-Hersteller angeben, htte a an dieser Stelle AC:DE:48 gewhlt werden mssen. Dies ist ein als privat mara u kierter Bereich, der fr den lokalen Gebrauch freigegeben ist. Da das Netzwerk u aber keinen Kontakt zur Auenwelt hat, wurde die bestehende Nomenklatur beibehalten. 5. Mit dem Tool ifconfig wird das TAP-Device nun, ohne an eine IP-Adresse gebunden zu werden (0.0.0.0), im Promiscuous-Modus (damit es smtliche Etherneta Rahmen annimmt) aktiviert. 6. Im vorletzten Schritt wird nun die Bridge (bzw. der Bridge-Port) auf eine IPAdresse konguriert (sofern dies ntig ist). o 7. Letztlich wird die fertig kongurierte Bridge aktiviert. Nach diesem Muster werden alle TAP-Devices und Bridges erstellt, die das gesamte Ubungsnetzwerk bilden. Auf den genauen Aufbau wird im Kapitel 5 eingegangen. Das Netzwerkinfrastrukturskript entfernt im stop-Block smtliche TAP-Devices a und Bridges. Dazu durchluft es den start-Block in umgekehrter Reihenfolge. a 4.3.2 /home/uml/uml/startall Das Startskript startall muss im Grunde nur die Startaufrufe der UMLs zusammenfassen. Wenn aber keine weiteren Sicherungen eingebaut werden, so kann es zu groen Schden an den Containerdateien kommen. Sollten die UMLs bereits laufen und a startall wird nochmals aufgerufen, so werden Prozesse gestartet, die auf die bereits
20
geneten Container-Dateien zugreifen. Da es sich hierbei in aller Regel sowohl um Leseo als auch um Schreibzugrie handelt, kommt es damit fast zwangslug zur Zerstrung a o der Dateisysteme. Um also den Doppelaufruf der UML-Prozesse zu verhindern ist das Startskript wie folgt aufgebaut:
1 2 3 4 5 6 7 8 9 10
#! / b i n / sh cd /home/uml/uml/ for i i n l s F | g r e p / | c ut d / f 1 | s o r t ; do l e t ru nnin g=0 cd /home/uml / . uml/ for j i n l s F | g r e p / | c ut d / f 1 | s o r t ; do t e s t $ i = $ j && l e t running=1 && break done t e s t $running eq 0 && ( echo s t a r t $ i ; cd /home/uml/uml/ $ i ; . / s t a r t u m l ; s l e e p 3 ) done cd /home/uml/uml/ /home/uml/uml/ rmcows28800 & Listing 4: /home/uml/uml/startall Es werden nur die relevanten Zeilen erlutert: a 4. Die Befehle in Backticks liefern eine aufsteigend sortierte Liste aller Unterverzeichnisse im Verzeichnis /home/uml/uml/ zurck, also uml[1-6] - dies sind alle UMLs, u die im System vorhanden sind. Diese Liste wird durch die for-Schleife durchlaufen, so dass $i die Verzeichnisnamen als Werte annimmt. 7. Diese for-Schleife durchluft mit dem selben Kommando wie in Zeile 4 alle Una terverzeichnisse des Verzeichnisses /home/uml/.uml/ - nur beinhaltet die Variable $j in diesem Fall die Namen aller z.Zt. laufenden UMLs (jeder UML-Prozess legt in /home/uml/.uml/ ein Unterverzeichnis an, so dass man an der Existenz dieser Verzeichnisse die Prozessaktivitt erkennen kann). a 8. Stimmt die aktuell zu startende UML ($i) mit einer der aktuell laufenden UMLs ($j) uberein, so wird die Variable running gleich 1 gesetzt und die innere for Schleife abgebrochen. 10. Nach der inneren for-Schleife wird uberprft, ob die UML gestartet werden muss u oder nicht. Dadurch wird verhindert, dass eine bereits laufenden UML ein weiteres Mal aufgerufen wird. 13. Es wird ein im Hintergrund laufender Timer gestartet, der das Ubungsnetzwerk nach Ablauf der Session-Time (in diesem Fall 28800 Sekunden, also 8 Stunden) hart beendet und in den Ursprungszustand zurckversetzt. u Dieses Skript wird in Kapitel 4.3.5 genauer erlutert. a
11 12 13
21
4.3.3 /home/uml/uml/uml1/startuml bzw. uml1 Mit den startuml-Skripten in jedem UML-Verzeichnis lassen sich die UMLs einzeln starten. Diese Skripte werden z. B. zentral von startall aufgerufen. In diesem Abschnitt wird das Start-Skript der UML1 exemplarisch erlutert, die Starta skripte der anderen UMLs sind analog aufgebaut, auf wichtige Abweichungen wird hingewiesen.
1 2 3
#! / b i n / sh s c r e e n d m s . / uml1 S uml1 Listing 5: /home/uml/uml/uml1/startuml Das Programm screen stellt ein virtuelles Terminal zur Verfgung, das es ermglicht, u o eine Terminal-Sitzung in den Hintergrund zu schicken und spter (sogar nach einem a erneuten Login von einer anderen Maschine) wieder aufzunehmen. In diesem Fall wird es folgendermaen aufgerufen: -d und -m veranlassen screen, detached (im Hintergrund) mit einer neuen Session zu starten. Diese wird mittels -S uml1 mit dem Namen uml1 versehen (dieser Parameter ist nicht unbedingt notwendig, erleichtert die Handhabung aber, da mehrere screen-Sessions sonst nur anhand ihrer PID identizierbar sind). Wre der Parameter a -s ./uml1 nicht gegeben, so wrde eine neue interaktive Shell (z. B. bash) gestartet u werden - hier wird aber als auszufhrende Session das Skript ./uml1 ubergeben, das u den UML-Prozess startet und dessen Ausgaben in der neu erstellten screen-Session ausgibt. screen stellt also im Grunde nur den Rahmen dar, in dem der eigentliche Aufruf der UML erfolgt. Man kann das uml1-Skript auch von Hand auf der Konsole aufrufen, wenn man auf die Mglichkeit verzichten kann, die Session in den Hintergrund o zu stellen. Die Parameter fr den UML-Aufruf werden im Folgenden erlutert: u a
1 2 3 4
#! / b i n / sh LINUX=/u s r / b i n / l i n u x $LINUX mem=64M ubd0=r o o t f s , m r o o t f s ubd1=s w a p f s eth0=tuntap , tap1 , 0 0 : FF : 0 0 : 0 0 : 0 0 : 0 1 con=n u l l con0=f d : 0 , f d : 1 u m l d i r=/home/uml / . uml/ umid=uml1 Listing 6: /home/uml/uml/uml1/uml1 mem=64M - der UML wird ein virtueller Hauptspeicher von 64MB zugewiesen. Es ist auch mglich, der UML mehr virtuellen Hauptspeicher zuzuweisen, als physio kalischer Hauptspeicher im Host-System vorhanden ist (siehe Kapitel 4.2.1). 64MB wurden aber fr die Hosts des Ubungsnetzwerks als ausreichend empfunu den, um mit gengender Performance Programme zur Trac-Analyse (auch z. B. u
22
in perl) ausfhren zu knnen. Auerdem lsst diese Hauptspeichermenge genug u o a Spielraum fr die Einrichtung von mindestens einem Dutzend UMLs auf der einu gesetzten Hardware (siehe Kapitel 6.1). ubd0=root fs,mroot fs - dieser Parameter vereint die Konguration zweier Funktionen: das Mapping der Container-Daten auf den UML-internen Device-Namen sowie die COW-Funktion. So wie in einem Linux-System die erste Partition auf einer als primary master kongurierten IDE-Festplatte in der Regel /dev/hda1 heit, so heit das primre a Massenspeicherdevice in einer UML /dev/ubd0. In diesem Fall wird nun die Datei mroot fs (master root, read-only) geschichtet mit dem COW-Device root fs auf das Device /dev/ubd0 gemapped. udb1=swap fs - den UMLs wird noch eine zweite Container-Datei als Swap-Device mit ubergeben, fr den Fall, dass der Hauptspeicher doch nicht ausreicht. Das u Swap-Device /dev/ubd1 wurde nach der Faustregel Swapspeicher = 2 Hauptspeicher auf 128MB dimensioniert. eth0=tuntap,tap1,00:FF:00:00:00:01 - an dieser Stelle wird das NetzwerkDevice konguriert, das der UML zur Nutzung ubergeben wird. Intern wird es sich um ein Ethernet-Device mit dem Namen eth0 handeln. Der Parameter tuntap muss ubergeben werden, um festzulegen, um was fr eine Art von Netzwerkdeu vice im Host-System es sich handelt, da verschiedene Arten der Kommunikation zur Auswahl stehen. Das im Host genutzte Device ist tap1 (siehe Kapitel 4.3.1), die MAC-Adresse von eth0 wird auf 00:FF:00:00:00:01 festgelegt (Man beachte den Unterschied zu der MAC-Adresse von tap1! Die unterschiedlichen MACAdressen sind notwendig, da bei gleichen MAC-Adressen der Konikt entsteht, welches Ethernet-Device die jeweiligen Ethernet-Rahmen zu verarbeiten hat: eth0 oder tap1.) Bei UMLs mit zwei oder mehr Netzwerk-Devices wird dieser Parameter entsprechend hug in angepasster Form wiederholt (z. B. bei UML4 und UML5, siehe a Abbildung 4). con=null con0=fd:0,fd:1 - dieser Befehl deaktiviert die Konsolen der UML, was in der Standardkonguration sonst zu mehreren xterm-Fenstern fhren wrde (das u u setzt voraus, dass eine grasche Oberche installiert ist). Nur stdin und stdout a werden in der screen-Session angezeigt. uml dir=/home/uml/.uml/ - dieser Parameter gibt an, in welchem Verzeichnis die Dateien angelegt werden, die z. B. von stopall verwendet werden. umid=uml1 - schlussendlich wird noch der Name der UML gesetzt. Dieser Name wird verwendet, um mit dem Tool uml mconsole (UML Management Konsole) bestimmte Low-Level-Zugrie auf die UML durchfhren zu knnen. u o
23
4.3.4 /home/uml/uml/stopall Das stopall-Skript ist dafr gedacht, wenn das Netzwerk graceful heruntergefahren u werden soll. Dies setzt voraus, dass an der internen Konguration der UMLs nicht manipuliert wurde. Wenn die UMLs uber das Netzwerk nicht mehr erreicht werden knnen oder aber Passwrter gendert wurden, so versagt das Skript eventuell. In o o a diesem Fall muss das Netzwerk hart beendet werden. Dieser Fall sollte in der Regel nicht eintreten, wenn am Netzwerk zu Wartungszwecken gearbeitet wurde.
1 2 3 4 5 6
#! / b i n / sh for i i n l s /home/uml / . uml/ | s o r t r ; do echo n H a l t i n g $ i . . . ( s s h r o o t @ $ i h a l t && echo h a l t e d ) | | echo f a i l e d done Listing 7: /home/uml/uml/stopall Es werden nur die relevanten Zeilen erlutert: a 3. Die Befehle in Backticks liefern eine absteigend11 sortierte Liste aller Unterverzeichnisse im Verzeichnis /home/uml/.uml/ zurck, also uml[1-6] - dies sind alle u UMLs, die z.Zt. im System laufen. Diese Liste wird durch die for-Schleife durchlaufen, so dass $i die Verzeichnisnamen als Werte annimmt. 5. Fr jede gefundene, laufende UML wird nun mittels ssh der Befehl halt aufu gerufen, um die UML zu veranlassen, den UML-Kernel-Prozess (und damit sich selbst) zu beenden. Dieser ssh-Aufruf erfolgt ohne Benutzereingri, da der PublicKey des Benutzers uml in die Datei /root/.ssh/authorized keys kopiert wurde, um somit eine publickey-Authentizierung durchfhren zu knnen. Der private u o Schlssel ist dabei nicht mit einem Passwort versehen, dies wrde wiederum einen u u Benutzereingri ntig machen. o 4.3.5 /home/uml/uml/rmcows rmcows ist die harte Version des Stopskriptes aus Kapitel 4.3.4. Es beendet die UMLProzesse mittels killall und durchluft danach die Verzeichnisse der UMLs, um die a COW-Dateien zu entfernen (sofern vorhanden). Da sich in den COW-Dateien nur die Anderungen zu dem Master-Dateisystem benden (siehe Kapitel 3.2.3, Seite 10), wird die gesamte UML in den Urzustand zurckversetzt. u Dieses Skript kann entweder von Hand ausgelst werden um testweise Anderungen o
11
Die absteigende Sortierung ist in diesem Fall wichtig, da sich das Skript beim Beenden in aufsteigender Reihenfolge sonst selbst den Netzwerkzugang zu den verbleibenden UMLs blockieren wrde u (eine Maschine kann nicht mehr beendet werden, wenn die einzige Verbindung zu ihr vorher beendet wurde).
24
zurckzunehmen, es wird aber in der modizierten Form rmcows28800 auch beim u startall-Aufruf automatisch mitgestartet. Diese modizierte Form unterscheidet sich lediglich dadurch, dass ihr das Kommando sleep 28800 vorangestellt ist. Das bedeutet, dass mit dem Start des Netzwerks ein 8h-Timer gesetzt wird, der nach Ablauf dieser Zeit das gesamte Netzwerk hart beendet und in den Urzustand zurckversetzt. u Diese Funktionsweise wurde gewhlt, um den Benutzern ein tatschlich limitiertes Zeita a fenster zur Verfgung zu stellen, damit es zu keinem Mibrauch kommt oder die Netzu werkoperation auer Kontrolle gert. a
25
5 Das Netzwerk
Dieses Kapitel erlutert die grundlegende Netzwerktopologie, die fr den konkreten Ana u wendungsfall gewhlt wurde, sowie die Basisstruktur der eingesetzten Software. Dienste, a die extra fr bestimmte Szenarios installiert wurden, werden an entsprechender Stelle in u Kapitel 7 erlutert. a Es folgen weitere Uberlegungen zu mglichen Erweiterungen oder Strukturnderungen, o a die fr gewisse Szenarios sinnvoll sein knnen. u o
japan
10.10.0.10 00:FF:00:00:00:00
10.10.4.0/24
uml4
10.10.4.4 00:FF:00:00:00:07
uml5
10.10.4.5 00:FF:00:00:00:08
uml1
10.10.0.1 00:FF:00:00:00:01
uml2
10.10.0.2 00:FF:00:00:00:02
uml3
10.10.0.3 00:FF:00:00:00:03
uml4
10.10.0.4 00:FF:00:00:00:04
uml5
10.10.1.5 00:FF:00:00:00:05
uml6
10.10.1.6 00:FF:00:00:00:06
10.10.0.0/24
10.10.1.0/24
Abbildung 4: Die Struktur des Ubungsnetzwerks Das grundlegende Prinzip der Namensgebung ist, dass jede UML anhand der selben Zahl auf jeder Protokollebene (FQDN, IP, MAC) leicht wiedererkannt werden kann. Dies erleichtert das Verstehen eines Netzwerkdumps erheblich, da kein Ubersetzungsprozess zwischen Adressen und Maschinen mehr ntig ist, die Kommunikationsrichtungen lassen o sich leichter intuitiv erfassen. Die Beschriftungen an den virtuellen Hosts geben folgende Informationen wieder: Den Host-Namen. Jede UML trgt den Namen uml gefolgt von einer Zahl zwischen a 1 und 6. Die ersten 4 UMLs liegen im ersten, internen IP-Adressbereich. Die UMLs 5 und 6 liegen im zweiten, externen IP-Adressbereich. Die Bezeichnungen intern und extern beziehen sich nur auf die Namensgebung innerhalb des DNS (*.uml.int bzw. *.uml.ext). Da das DNS mit den Domains
26
Bestandteil eines der Szenarios ist (siehe Kapitel 7.4), wird an dieser Stelle nur der Hostname und nicht der FQDN angegeben. Bei Verwendung von IP-Adressen gibt es keine Unterscheidung zwischen intern und extern. Die IP-Adresse. Das letzte Oktett jeder IP-Adresse stimmt mit der laufenden Nummer der UML uberein. Die MAC-Adresse. Auch hier korrespondiert das letzte Oktett mit der laufenden Nummer der UML. Die hier angegebenen MAC-Adressen sind die innerhalb des Ubungsnetzwerk sichtbaren Adressen, nicht die MAC-Adressen, die den TAP-Devices in der HostUmgebung zugewiesen sind (Grund: siehe Kapitel 4.3.3). Die virtuelle Ethernet- und IP-Struktur Die Ethernet- und IP-Struktur wird hier in einem Abschnitt behandelt, da sich die beiden Strukturen in diesem Fall decken. Die virtuelle physikalische Netzwerkstruktur des Ubungsnetzwerks wurde wie folgt errichtet: Die UMLs 1 bis 4 bilden das erste Subnetz, sie sind alle mit dem selben Hub verbunden. Auf IP-Ebene benden sich diese UMLs im Subnetz 10.10.0.0/24. Die UMLs 5 und 6 bilden das zweite Subnetz, diesmal mit dem IP-Bereich 10.10.1.0/24. Die UMLs 4 und 5 unterscheiden sich insofern von den ubrigen virtuellen Maschi nen, dass sie als Router zwischen den beiden Subnetzen agieren und deswegen auch zwei Netzwerkdevices besitzen - auf der einen Seite die Verbindung in das eigene Subnetz, sowie auf der anderen Seite eine Verbindung in das Subnetz, welches die beiden Netze verbindet (10.10.4.0/24). Das Routing zwischen den Netzen erfolgt statisch, die Routing-Tabellen sind von Hand festgelegt und werden im Regelfall auch nicht verndert. Das Thema dynamisches a Routing wird im Kapitel 5.2 diskutiert. Die Maschine mit der IP 10.10.0.10 ist nicht direkt Bestandteil des Ubungsnetzwerks. Es handelt sich hierbei um das virtuelle Bridge-Device, das das virtuelle Netzwerk an den physikalischen Host anbindet. Diese Verbindung ist im Normalfall aber durch iptables-Regeln vollstndig abgeschottet, um die Einschlieung des a Ubungsnetzwerkes zu gewhrleisten. Durch Anderung der Paketlterregeln auf dem a Host ist es aber mglich, diese Verbindung zu nen, um so nach dem Setzen des o o Standard-Gateways dem Ubungsnetzwerk Zugri auf das Internet zu gewhren, z. B. a um online ein Distributions-Upgrade durchfhren zu knnen. u o
27
Diese Funktion ist nur vorhanden, wenn man root-Zugri auf den Host-Rechner hat. Von einem User-Account im Ubungsnetzwerk knnen die ntigen Zugrie nicht o o durchgefhrt werden. u Die installierten Dienste Die UMLs sind nur mit einer sehr kleinen Zahl von Diensten ausgestattet, eine Erweiterung der angebotenen Dienste soll nur dann erfolgen, wenn diese konkret fr ein u Szenario bentigt werden. o So erlaubt jede UML den Login per SSH. Dabei sind aber die Passwrter den o Benutzern nicht bekannt. Einzig das root-Passwort von uml1 wird den Benutzern des Ubungsnetzwerkes zur Verfgung gestellt. Dies ist der abgefragte Login, wenn sich ein u Benutzer von auen mit dem Befehl ssh root@umlnet.sva.tu-harburg.de anmelden will. Als weiterer Dienst ist ein Apache-Webserver auf allen UMLs installiert. Als Erweiterung fr den Apache wurde ein PHP-Modul installiert. Die Konguration wurde u nicht verndert, die Webserver laufen mit der Standard-Konguration (Ausnahmen: a siehe Kapitel 7). Wie oben erwhnt ist das Host-System (und damit die Auenanbindung) durch a einen Paketlter gesichert. Die UMLs jedoch besitzen selbst keinerlei Paketlterregeln.
http://www.zebra.org/
28
Folgen weniger gut beobachten. Auch das Re-Routing nach Zusammenbruch von Kommunikationsverbindungen liee sich nur anschaulich demonstrieren, wenn uberhaupt Alternativrouten vorhanden sind, die genutzt werden knnten. o Fr diese Szenarios ist das Ubungsnetzwerk zum jetzigen Zeitpunkt zu klein. u
29
6 Das System
Dieses Kapitel stellt das System vor, auf dem das Ubungsnetzwerk im Arbeitsbereich SVA an der TUHH realisiert worden ist, und welche reellen Performance-Werte bei dieser Hardwareausstattung erreicht werden.
30
anbieten, sondern nur die Funktionalitt fr die vorgesehenen Aufgaben bereitstellen. a u Der Host-Kernel stammt aus der 2.4er-Serie, zuletzt wurde erfolgreich die Version 2.4.29 eingesetzt (siehe Tabelle 1, Seite 16). Am Kernel sind keine nennenswerten Modikationen durchgefhrt worden, es wurden lediglich die Debian-Standard-Kernelu Konguration an die vorhandene Hardware angepasst, sowie unntige Treiber und o Subsysteme entfernt (Bluetooth, IEEE1394, etc.). Bei den hinzugefgten Kompou nenten sind das TUN-/TAP-Device, die IEEE802.1d-Bridges, der Hub-Patch und der SKAS3-Patch zu nennen. Alle diese Modikationen wurden bereits in Kapitel 4 erlutert. a
Immer nur auf einer UML zur Zeit, bei sonst unbelastetem System. Bei Aufruf auf mehreren UMLs gleichzeitig knnen die Messergebnisse sehr stark schwanken. o
31
von dem SMP-Setup des Hosts macht, sind die Ergebnisse durchaus vergleichbar. Der wahrscheinlich wichtigere Aspekt bei der Betrachtung der Performance eines Ubungsnetzwerkes als die Leistung der Hosts ist die eigentliche Netzwerkperformance. Hierzu werden die beiden Parameter Durchsatz und Latenz genauer untersucht. 6.3.1 Der Durchsatz Zur Durchsatzmessung im emulierten Netz des Ubungsnetzwerkes wird das Tool bing eingesetzt. bing berechnet durch die Ubertragung zweier unterschiedlich groer ICMP ECHO REQUEST-Pakete den Punkt-zu-Punkt-Durchsatz zwischen zwei Hosts. Es wird auf der UML uml1 mit dem Kommando bing -s 1000 -S 10000 -e 10000 10.10.0.1 $remotehost aufgerufen, wobei $remotehost immer durch die Adresse der zu testenden, weiter entfernten Maschine ersetzt wird. Die Parameter -s und -S bestimmen die Gre der zu o 15 ubertragenden kleinen und groen Test-Pakete , der Parameter -e bestimmt die Anzahl der zu sendenden Pakete. Zum nheren Verstndnis der Messwerte sollte Abbildung 4 herangezogen werden. Die a a Messwerte sind folgender Tabelle zu entnehmen: $remotehost # Hops 10.10.0.4 1 10.10.1.5 2 10.10.1.6 3 MBit/Sek. 175 95 65
Tabelle 3: Durchsatz-Messwerte des Programms bing Die Messergebnisse erklren sich wie folgt: a Bei der ersten Durchsatzmessung sind die beiden Hosts nur einen Hop voneinander entfernt, sie sind also am selben Switch (bzw. Hub) angeschlossen. In diesem Fall mssen die Datenpakete je einmal den TCP/IP-Stack von uml1 und uml4 sowie u eine Bridge durchlaufen. Mit dem Durchlaufen einer Bridge passieren die EthernetRahmen den Host-Kernel also einmal.16 Bei der zweiten Durchsatzmessung sind die beiden Hosts zwei Hops voneinander entfernt, die beiden Netze sind durch einen Router verbunden. In diesem Fall mssen die Datenpakete also je einmal den TCP/IP-Stack von uml1 und uml5, u zweimal den von uml4 sowie zwei Bridges durchlaufen. Mit dem Durchlaufen zweier Bridges passieren die Ethernet-Rahmen den Host-Kernel also zweimal. dass der Durchsatz nicht auf weniger als die Hlfte einbricht, liegt vermutlich a daran, dass die Lastverteilung auf dem SMP-System gnstig ist. u
Die Gre der Pakete muss entgegen der Standard-Werte des Programms so gro gewhlt werden, o a da die Ubertragungsdauer sonst nahe der Timer-Przision liegt und damit keine bzw. nur ungenaue a Messungen mglich sind. o 16 Die Antwortpakete durchlaufen diese Kette in umgekehrter Reihenfolge natrlich noch einmal. u
15
32
Bei der dritten Durchsatzmessung sind die beiden Hosts drei Hops voneinander entfernt, die beiden Netze sind durch ein Subnetz mit zwei Routern verbunden. In diesem Fall mssen die Datenpakete also je einmal den TCP/IP-Stack von uml1 u und uml6, zweimal den von uml4 und uml5 sowie drei Bridges durchlaufen. Dies bedeutet, dass jeder Ethernet-Rahmen sechsmal im Userspace verarbeitet wird und dreimal in den Kernel-Space des Host-Kernels eintritt, bevor er einmal die grtmgliche Entfernung im Netzwerk durchlaufen hat. o o Diese Messungen haben ergeben, dass die erreichbaren Durchsatzraten unerwartet hoch sind. Sie liegen damit deutlich uber dem, was fr Ubungs- und Analysezwecke an Dau tenverkehr zu erwarten ist. Dies deckt sich auch mit den Aussagen in [10], nach dem bei Hacking-Wettbewerben zu Lehrzwecken ubermiger Trac nicht nur zu vermeiden ist, sondern auch negativ a in die Bewertung einiet. 6.3.2 Die Latenz Die Latenzen im Ubungsnetzwerk werden mit dem Tool ping gemessen. Der Aufruf von ping geschieht wie folgt: ping -c 1000 $remotehost Der Parameter -c bestimmt die Anzahl der pings, nach der sich das Programm beendet und die Ergebnisse anzeigt. Die Messwerte sind folgender Tabelle zu entnehmen: $remotehost # Hops 10.10.0.4 1 10.10.1.5 2 10.10.1.6 3 ms 0.6 0.9 1.3
Tabelle 4: RTT-Messungen (roundtriptime) des Programms ping Diese Messwerte sind in der Hinsicht aullig, als das man bei den Durchsatzmessungen a gerade bei nur einem Hop Entfernung sehr hohe Datenraten von ca. 175 MBit/Sek. registriert hat, damit also deutlich uber den Werten eines 100 MBit/Sek. Ethernet liegt, die Ping-Zeiten jetzt aber deutlich schlechter als bei einem echten Ethernet sind (0.6 ms gegenber ca. 0.35 ms). u Die Latenz des emulierten Netzwerkes ist also hher als die eines echten Ethernets, die o TCP-Mechanismen wie das TCP-Receive-Window ermglichen aber dennoch sehr hohe o Datenraten. Nichtsdestrotz sind auch die Latenzen des Ubungsnetzwerks immer noch als sehr nied rig einzustufen, bei Verbindungen ins Internet sind Latenzen, die um den Faktor 300 hher sind, nichts Ungewhnliches. o o
33
Time-To-Live
34
werden, die hug nur theoretisch bekannt sind. Ein gutes Beispiel dafr ist der 3a u Wege-Handshake des TCP-Protokolls. Dieser wird in der Regel nicht wahrgenommen, aber hier bietet sich die Gelegenheit, das SYN, SYN/ACK, ACK beim Abrufen einer Webseite durch das Kommando wget http://10.10.0.3/ nachzuvollziehen. Weiterhin interessant sind die ARP-Requests, die jeder neuen Verbindung vorausgehen, um die Abbildung von IP- auf MAC-Adressen zu aktualisieren. Auch die Tatsache, dass IP- und MAC-Adressen nicht ubereinstimmen, wenn zum Erreichen des Zielhosts ein Router in Anspruch genommen werden muss, ist hier gut zu verfolgen. Die genannten Analysen und Tools sind auch ntzlich fr die weiteren Aufgaben. u u
35
36
siehe http://de.wikipedia.org/wiki/Geburtstagsparadoxon
37
In weiteren Tests ist es nicht gelungen, das Netzwerk auf eine so schlechte Performance zu bringen, dass die Attacke erfolgreich verlaufen ist. Die ntigen Performancewerte htten mit NIST Net 19 des amerikanischen National o a Institute of Standards and Technology geschaen werden knnen. Hierbei handelt es o sich um ein Tool, das als Linux Kernelmodul sehr viele Netzwerkbedingungen emulieren kann. Zu diesen Netzwerkbedingungen zhlen z. B. Bandbreitenbeschrnkungen, Paketa a verluste und auch Verzgerungen. Dieses Tool wrde die einfache Demonstration von o u DNS Cache Poisoning ermglichen, indem das Delay zwischen den beiden Nameservern o auf den ntigen Wert eingestellt wird. o Da das Tool aber seit dem Jahr 2002 nicht mehr weiterentwickelt wird und es zwischen zeitlich starke Anderungen am Linux-Kernel gab, gelang es nicht, NIST Net mit der aktuell eingesetzten Kernelversion (und einigen lteren) zu kompilieren. a
19
http://www-x.antd.nist.gov/nistnet/
38
8 Schlussbemerkung
Am Ende des Projektes steht die Erkenntnis, dass das virtuelle Ubungsnetzwerk alle Anforderungen der Aufgabenstellung erfllt: Es steht in seiner Funktionalitt u a einem physikalischen Netzwerk in beinahe nichts nach, es ist auf Standardhardware billig zu implementieren, leicht zu warten, einfach zu erweitern, und von ihm gehen keinerlei Risiken fr den Host oder das umliegende Netzwerk aus. Weiterhin u knnen Anderungen schnell vorgenommen werden, sofern die Anforderungen es ntig o o machen. Dabei knnen diese Anderungen genauso schnell zu 100% wieder zurckgenomo u men werden. In dieser Hinsicht ubertrit das virtuelle Netzwerk sogar das physikalische. Die vorgestellten Ubungsszenarios geben fr den Anfang einen guten Einblick in u Netzwerkprotokolle und -angrie. Wenn auch das interessante DNS Cache Poisoning nicht zu demonstrieren ist, so ist doch die Ursachenforschung eine Aufgabe, die einen guten Uberblick uber die Protokolle, den Angri und die Analysetools bietet. Als Aufgaben fr die Zukunft stehen besonders neue Angrisszenarios im Raum, u wobei auch uber grundlegende strukturelle Anderungen des Netzwerks nachzudenken ist. Der Host-Rechner des Ubungsnetzwerkes steht im Arbeitsbereich SVA der TUHH und kann jederzeit genutzt werden. Die Kontaktaufnahme erfolgt uber die Homepage des Arbeitsbereiches, so dass im Falle mehrerer Interessenten die Koordination der Nutzungszeiten gewhrleistet ist. a
39
Literatur
[1] Biallas, Sebastian: Website. In: PearPC - PowerPC Architecture Emulator. Verfgbar unter http://pearpc.sourceforge.net/ (26.07.2005). u [2] Biallas, Sebastian: Limits of PearPC. In: PearPC - PowerPC Architecture Emulator. Verfgbar u unter http://pearpc.sourceforge.net/about.html#limits (26.07.2005). [3] Diedrich, Oliver: Alles nur getrumt : Wie Xen virtuelle Maschinen erschat. a In: ct magazin fr computer technik (2005), Nr. 11, S. 222226. ISSN 0724-8679 u [4] Dike, Jeff: User Mode Linux. In: The User-mode Linux Kernel Home Page. Verfgbar unter http://user-mode-linux.sourceforge.net/ (26.07.2005). u [5] Diverse: Virtuelle Maschine. In: Wikipedia - Die freie Enzyklopdie. a Verfgbar u unter http://de.wikipedia.org/wiki/Virtuelle Maschine (16.02.2005). [6] Institute of Electrical and Electronics Engineers: IEEE Std 802.1DTM - 2004 : IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges. [7] Izaguirre, Ramon: An Implementation of a Birthday Attack in a DNS Spoong. In: Bugtraq Mailingliste (2003). Verfgbar unter http://cert.uni-stuttgart.de/archive/bugtraq/2003/04/ u msg00311.html (26.07.2005). [8] Linux VServer Projekt: Website. In: Linux VServer Project. Verfgbar unter http://linux-vserver.org/ (26.07.2005). u [9] Stewart, Joe: DNS Cache Poisoning - The Next Generation. In: SecurityFocus (Ohne Jahr, Originalartikel nicht mehr erreichbar). Verfgbar unter http://www.lurhq.com/dnscache.pdf (26.07.2005). u [10] Vigna, G.: Teaching Network Security Through Live Exercises. In: Proceedings of the Third Annual World Conference on Information Security Education (WISE 3) (Juni 2003), S. 318. Verfgbar unter http://www.cs.ucsb.edu/vigna/pub/2003 vigna wise03.pdf u (26.07.2005).
40