Studienarbeit A Linux Based Virtual Teaching NetworkHarald Sau harald.sau@tu-harburg.de http://umlnet.sva.tu-harburg.de/ 29. Juli 2005Betreuer: Prof. Dr. Dieter Gollmann Dipl.-Ing. Jens Ove Lauf

Technische Universitt Hamburg-Harburg a Sicherheit in verteilten Anwendungen Arbeitsbereich 4-16 Harburger Schlossstrae 20 21079 Hamburg-Harburg

AbstractThe 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.

i

Inhaltsverzeichnis1 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 . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7 Die 7.1 7.2 7.3 7.4

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.

1

Konventionen fr diesen Artikel uUML1 -Kernel: Der Kernel, der als Prozess im Host-System luft und den Kernel a (die Abstraktionsschicht) fr die Gast-UML bereitstellt. u Host-Kernel: Der Kernel des Host-Systems, auf dem der UML-Kernel der GastUML luft. Da der Host-Kernel auch mit einem UML-Patch vera sehen ist (SKAS3, siehe Kapitel 4.2.2), kann es durch die Namensgebung hier leicht zu Verwechselungen mit dem UML-Kernel kommen. In Quellcodelistings bedeutet dieses Zeichen, dass aus Grnden u der Zeilenlnge ein Zeilenumbruch stattgefunden hat, der in der a Original-Sourcecodedatei nicht vorhanden ist. Dies wird auch in der Zeilennumerierung deutlich.

1

User Mode Linux, siehe Kapitel 3.2.3

2

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

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

3.1 Virtuelle MaschinenEine virtuelle Maschine ist allgemein ein Modell eines Prozessors und der zugehrenden Systemarchitektur, dessen Rechenweise unabhngig von der o a technischen Ausfhrung beschrieben wird (Hardware). Verwendet wird der u Begri synonym fr das Computerprogramm, dass eine virtuellen Maschine u auf einem vorhandenen Prozessor emuliert.[5] Eine virtuelle Maschine ist also ein laufendes (Betriebs-)system bzw. die Summe ihrer laufenden Prozesse, die aber nicht auf klassischer Computerhardware ausgefhrt wird, u sondern auf einem virtuellen System, das von einem Host-Rechner erzeugt wird. Fr die u Anwendungssoftware besteht in der Regel kein Unterschied darin, ob sie auf realer oder emulierter Hardware ausgefhrt wird - sie setzt in den meisten Fllen auf einer Hardwareu a 2 Abstraktionsschicht (HAL ) des Betriebssystems auf, so dass ihr die Details uber die darunterliegende Hardwareschicht unbekannt sind. Erst beim Einsatz hardwarenaher Software (z. B. Gertetreiber) knnen die Unterschiede zwischen realer und emulierter a o Hardware auftreten. Es gibt viele Grnde, aus denen man eine virtuelle Maschine einer realen Maschine u vorziehen kann: leichte Transportierbarkeit: Wenn virtuelle Maschinen eingesetzt werden, so knnen die Gast-Systeme mit o verhltnismig geringem Aufwand von einem Host-System zu einem anderen a a ubertragen werden, da die emulierte Hardware unabhngig von der realen Harda ware auf allen eingesetzten Host-Systemen identisch ist. Dies ist von Vorteil, wenn z. B. ein Defekt auftritt, bei dem Hardware ausgetauscht wird und diese nicht durch identische Bauteile ersetzt werden kann. Weiterhin kann auch ein Systemumzug z. B. in ein neues Rechenzentrum schnell durchgefhrt werden, indem die Container-Dateien3 der Gast-Systeme auf die neue u Hardware kopiert und dort neugestartet werden. bessere Wartbarkeit: Durch die auf allen Systemen identische Hardware ist eine bessere Wartbarkeit gegeben, da die Gast-Systeme nicht auf unterschiedliche Hardwareplattformen angepasst sein mssen. u2 3

Hardware Abstraction Layer Die Container-Dateien enthalten das Dateisystem des Gast-Systems mitsamt der Dateien, die zu dessen Betrieb ntig sind ( virtuelle Festplatte). o

4

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.

3.2 Realisierungen virtueller MaschinenZur Realisierung virtueller Maschinen gibt es verschiedene Anstze: diese reichen von a der Emulation der gesamten Hardware bis zur Nutzung des Prozesssystems des Hostes, und werden im Folgenden vorgestellt. 3.2.1 Emulatoren Bei Emulatoren wird die gesamte Hardware des Gast-Systems emuliert. Ein Vorteil liegt nicht nur darin, vollkommen unabhngig von der verwendeten Host-Hardware zu sein, a4

bei nichtredundanter Hardware

5

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 a5

Just-In-Time-Compiler

Prozess 1

System-Kern virt. Hardware

Prozess 2

Prozess 3

Prozess 4

Prozess n

Linux-Kernel

Hardware

Prozess 16

System-Kern virt. Hardware

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 87

{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

Linux-Kernel mit VServer-Patch

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 einen6

vgl. View im Kontext von Datenbanksystemen

8

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-

9

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 110

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.

4.1 Die KomponentenDie in diesem Abschnitt erluterten Komponenten sind die drei Softwareelemente, die a zusammen den technischen (technisch im Gegensatz zu inhaltlich, siehe Kapitel 7) Roh bau des Ubungsnetzwerkes bilden. 4.1.1 Die UMLs Die UMLs wurden bereits in Kapitel 3.2.3 erlutert. An dieser Stelle folgen deshalb nur a noch einige Bemerkungen und Ergnzungen. a Obwohl es mglich ist, ohne sehr groe Anpassungsarbeit einen eigenen UMLo Kernel zu kompilieren, so wurde fr dieses Projekt doch darauf verzichtet. Stattdessen u wurde aus Debian unstable der vorkompilierte UML-Kernel in der Version 2.4.26-um3 gewhlt. Die Grnde dafr sind folgende: Die vorkompilierte Version basiert auf a u u einer sinnvollen Auswahl der zur Verfgung stehenden Features. Fr den vorliegenden u u Anwendungsfall wurde es nicht fr zwingend notwendig erachtet, eine genau auf den u Anforderungsbereich minimierte Version des UML-Kernels zu erstellen. Weiterhin ist es so einfacher mglich, spter ein Update durchzufhren, da man o a u sich auf das Debian-Paketmanagement verlassen kann und sich nicht erst in die Konguration des UML-Kernels vertiefen muss, die doch diverse Unterschiede zur Kernel-Konguration fr eine Standard-Prozessorarchitektur (wie z. B. x86) besitzt. u Der UML-Kernel bendet sich standardmig in /usr/bin/linux, die eingesetza ten Kommandozeilenparameter zur Steuerung des Verhaltens der UML werden im Kapitel 4.3.3 auf Seite 22 erlutert. a 4.1.2 Die TUN-/TAP-Devices Die TUN-/TAP-Devices sind eine spezielle Form von Netzwerktreiber, die bentigt o werden, um die im Userspace laufenden UMLs an den Netzwerkstack des Host-Kernels anbinden zu knnen. o Ein Netzwerktreiber fr eine klassische NIC7 stellt eine Schnittstelle zwischen dem u physikalischen Netzwerkdevice und dem Kernel bereit. Der TUN-/TAP-Treiber stellt7

Network Interface Card, Netzwerkkarte

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.c8

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 u9

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, aber10

der Code ist in den genannten Versionen bitgleich

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

4.3 Die Hilfsskripte Um das komplette Ubungsnetzwerk in Betriebszustand zu bringen wre es mglich, alle a o Befehle zur Errichtung der Netzwerkinfrastruktur und alle Parameter zum Start der UMLs von Hand einzugeben. Da dies aber uerst inezient und fehleranfllig wre, a a a wurde eine handvoll Skripte erstellt, die diese und weitere Aufgaben automatisiert. Im Folgenden werden diese Skripte entweder mit ihrer Funktion kurz genannt oder auch ausfhrlicher erlutert. u a Anmerkungen zur Verzeichnisstruktur Fr den Betrieb der UML-Kernel-Prozesse wurde ein Benutzer uml erstellt, der sein u Home-Verzeichnis in /home/uml/ hat. In $HOME benden sich u.a. die beiden Verzeichnisse uml und .uml - das erste der beiden Verzeichnisse enthlt die Verzeichnisse fr die a u Containerdaten der UMLs und die meisten der Hilfsskripte (auer des in Kapitel 4.3.1 genannten), das zweite (versteckte) Verzeichnis enthlt Dateien, die nur zur Laufzeit a von den UML-Kernel-Prozessen angelegt werden. Die Namen der UMLs, der screen-Sessions (siehe Kapitel 4.3.3) und der Verzeichnisse sind ubereinstimmend gewhlt worden, so dass die Verzeichnisse wie folgt angelegt sind a bzw. werden: /home/uml/uml/uml[1-6]/ bzw. /home/uml/.uml/uml[1-6]/ 4.3.1 /etc/init.d/uml Im Verzeichnis /etc/init.d/ liegen traditionellerweise die Start- und Stop-Skripte fr u smtliche Systemdienste. Diese werden referenziert durch Symlinks in den Verzeichnisa sen /etc/rc[0-6S].d/, die beim Eintritt in einen Runlevel bzw. bei dessen Verlassen mit dem Parameter start bzw. stop aufgerufen werden. Da die Netzwerkstruktur bestehend aus den TAP-Devices und den Ethernet-Bridges vom Benutzer root angelegt werden muss, ist es sinnvoll, dies bereits whrend des Sysa temstarts durchzufhren. u Das folgende Listing zeigt einen Auszug aus dem start-Block des Netzwerkinfrastrukturskriptes, exemplarisch am TAP-Device tap1, das zu der Bridge br0 hinzugefgt u wird. Alle weiteren TAP-Devices und Bridges werden analog dazu erstellt. (Anmerkung: Da es sich nur um einen Auszug aus dem wirklichen Skript handelt, sind die Zeilennummern nicht mit dem wirklichen Skript ubereinstimmend, sie werden zu Erluterungszwecken aber trotzdem angezeigt und auch referenziert.) a1 2 3 4 5 6 7

$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 o11

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 NetzwerkDieses 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

5.1 Der aktuelle Stand Abbildung 4 zeigt den Aufbau des Ubungsnetzwerks, wie er zum jetzigen Zeitpunkt gewhlt wurde. a

japan10.10.0.10 00:FF:00:00:00:00

10.10.4.0/24uml410.10.4.4 00:FF:00:00:00:07

uml510.10.4.5 00:FF:00:00:00:08

uml110.10.0.1 00:FF:00:00:00:01

uml210.10.0.2 00:FF:00:00:00:02

uml310.10.0.3 00:FF:00:00:00:03

uml410.10.0.4 00:FF:00:00:00:04

uml510.10.1.5 00:FF:00:00:00:05

uml610.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.

5.2 Denkbare ErweiterungenDieser Abschnitt diskutiert mgliche Erweiterungen der gesamten Netzwerkstruktur. o Es geht hier also nicht um die Installation von Diensten, die auf der bestehenden Netzwerkinfrastruktur aufsetzen, sondern um Dienste, die im Rahmen eines Szenarios eine Infrastruktur erfordern, die z. Zt. nicht gegeben ist. Ein Beispiel dafr ist die Erhhung der Anzahl von Maschinen im Ubungsnetzu o werk, wobei sich diese in mehr Subnetzen benden und die Subnetze durch echte Router verbunden werden (nicht nur statisches Routing). Dies wre sinnvoll, wenn vier oder mehr Subnetze existierten, die z. B. mittels der a Routing-Software GNU Zebra12 zusammengeschaltet wren. Dies wrde es ermglichen, a u o Angrie gegen die Protokolle der Router zu untersuchen. Angrie, bei denen man den Routen-Cache der Router vergiftet, wrden sich u auch bei der jetzigen Netzwerkstruktur durchfhren lassen, allerdings lieen sich die u12

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.

6.1 Die HardwareDie UML-Host-Maschine hat folgende Hardwareausstattung: Komponente Mainboard CPUs RAM HDD Bezeichnung ASUS P2B-DS 2 Intel Pentium III (Katmai), 550 MHz, 512 kB Cache 1 GB SDRAM, 100 MHz 18 GB IBM DNES-318350W (SCSI) Tabelle 2: Hardware des UML-Hostes Der Hauptspeicherausbau ist der wohl wichtigste Faktor in der Hardwareausstattung, da die Performance der UMLs uerst schlecht wird, wenn fehlender Hauptspeicher durch a das Auslagern auf Festplatte ersetzt werden muss. Den UMLs im Ubungsnetzwerk wurden jeweils 64 MB RAM zugewiesen. Bei 1 GB Hauptspeichergre des Hostes werden bis zu 768 MB als shmfs-RAM-Disk fr die o u Hauptspeicherabbilder der UMLs genutzt, was rechnerisch bis zu 12 UMLs ermglicht. o Da in der Regel aber keine UML den gesamten ihr zugewiesenen Speicher ausnutzt (bzw. ungenutzte aber belegte Speicherbereiche vom Host ausgelagert werden) ist davon auszugehen, dass im normalen Netzwerkbetrieb auch noch mehr emulierte Maschinen mit guter Performance ausgefhrt werden knnen. u o Die Prozessorlast auf dem Host ist im Standby sehr gering, sechs sich im Leerlauf bendliche UMLs erzeugen praktisch keine merkliche Last auf dem Host (eine CPU ist stndig zu 100% idle, die andere zu > 95%13 ). a

6.2 Das BetriebssystemAls Betriebssystem kommt Debian GNU/Linux zum Einsatz. Es wird das stabile Release 3.0 eingesetzt, das auf den testing-Zweig upgedatet wurde (dieser Zweig ist inzwischen erschienen als Debian GNU/Linux Release 3.1). Hierzu wurde eines der fertigen, bootfhigen root-Images von der UML-Webseite [4] a heruntergeladen, ein Debian GNU/Linux Release 3.0 r0, das im Grundzustand ein sehr minimales Betriebssystem beinhaltet (das gesamte root-Image ist komprimiert nur 23 MB gro). Nach dem Update auf die o. g. Version wurden nur wenige Dienste hinzugefgt, wie u z. B. ein Apache-Webserver. Weiterhin wurden in allen root-Images die in Kapitel 7 genannten Tools installiert. Ansonsten sollten die UMLs keine unntigen Dienste o13

gemessen mit top

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

6.3 Die Performance Eine wichtige Frage war, welche Performance von dem Ubungsnetzwerk auf der eingesetzten Hardware zu erwarten sei, da beim aktuellen Setup sieben Betriebssysteme parallel auf der selben Hardware ausgefhrt werden. u Dazu wurden einige Performance-Messungen durchgefhrt, die in diesem Abschnitt u vorgestellt und ausgewertet werden. Die erzielten Ergebnisse sind immer unter der Prmisse zu betrachten, dass es sich bei a den UMLs nicht um hochbelastete Systeme handelt, wie z. B. einen Datenbank-Server. Die UMLs benden sich die meiste Zeit im idle-Zustand, und verschicken nur von Zeit zu Zeit einige Datenpakete, die von den Analyse-Tools aufgefangen und bearbeitet werden mssen. Da es sich hier nie um ein mit hohem Volumen belastetes Netz handeln u wird, folgt daraus auch die Aussage, dass das Netz in seiner Gre noch erweitert o werden knnte. o Die reine CPU-Leistung stellt kein Problem dar, wenn der SKAS3-Patch installiert ist (siehe Kapitel 4.2.2). Zur Gesamtleistung sagt die UML-Webseite [4], dass eine Kernel-Kompilierung (als Benchmark) innerhalb von 30% der Zeit des Hostes abluft ( a kernel build [. . . ] is a within 30% of the hosts time). Dies heit, dass die Gesamtleistung der UML fr den u 10.3 Fall einer Kernel-Kompilierung bei uber 70% der Host-Leistung liegt ( 1 = 0.7 oder 1 0.77). 1+0.3 Da aber die in Kapitel 7 genannten Programme zur Netzwerkanalyse bzw. -manipulation keine hohe I/O-Leistung der Massenspeicher bentigen (wie es bei der Kernelo Kompilierung der Fall ist), wurde noch eine Messung der Prozessor-/SpeicherPerformance durchgefhrt. Hierzu wurde die Test-Funktion des Passwort-Crackers u john herangezogen. john berechnet dazu die Geschwindigkeit einiger kryptographierelevanter Algorithmen, wie z. B. DES und MD5. Diese Test-Funktion wurde auf dem Host und in der UML je dreimal aufgerufen14 , die drei Ergebnisse jeweils gemittelt und dann miteinander verglichen. Das Ergebnis ist folgendes: Die Leistung innerhalb der UML bendet sich bei allen Algorithmen zwischen 98,9% und 99,8% der Leistung der Host-Maschine. Da john keinen Gebrauch14

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. uDie 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. u15

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

7 Die Ubungsszenarios und Tools In diesem Abschnitt geht es um Aufgaben und Szenarios, die im Ubungsnetzwerk zu Lehrzwecken bearbeitet werden knnen. Es wird nicht jeder einzelne Versuch beschrieo ben, sondern hnliche Experimente werden gruppiert und zusammengefasst. a Weiterhin werden zu jedem Themenkomplex einige Tools vorgestellt, die fr diesen u Aufgabenbereich ntzlich sein knnen. Auch diese Liste erhebt keinen Anspruch auf u o Vollstndigkeit, hug wird es Programmalternativen geben, auch abhngig von den a a a persnlichen Vorlieben des Benutzers. o

7.1 Die NetzwerkanalyseZu Beginn gilt es, sich mit dem Netzwerk und den netzwerktopologischen Eigenschaften vertraut zu machen. Wenn die Ubersichtsgrak (Abbildung 4) nicht gegeben ist, so kann man sich mittels der Kommandos route und ifconfig einen groben Uberblick uber die Netzwerksituation (Routingtabelle und Netzwerkdevicekonguration) verschaen. Auch ping und traceroute knnen dabei behilich sein (hierbei erfhrt man die o a 17 Entfernung eines Rechners in Hops durch die sich verringernde TTL ). Bereits bei dieser Erkundung des Netzwerkes kann man den Netzwerkverkehr mittels tcpdump in eine Datei mitloggen lassen. Um diese Dumps mittels ethereal mglichst o ezient auswerten zu knnen, ist es hilfreich, sich mit den Kommandozeilenparametern o von tcpdump auseinanderzusetzen. Folgende Parameter haben sich fr den Einstieg als u sinnvoll erwiesen (fr weitere Features siehe die zugehrige man-Page): u o tcpdump -s 0 -w dump.file.1 not port 22 Diese Parameter sorgen dafr, dass die kompletten Pakete (-s 0) in die Datei (-w) u dump.file.1 geschrieben werden, und nicht nur die Headerbytes. Solange nur die Header analysiert werden sollen, reicht dies aus, doch sobald die Nutzdaten wichtig sind, werden die kompletten Pakete bentigt. Der Ausdruck not port 22 ist die o sogenannte lter expression die bestimmt, welche Pakete in den Dump geschrieben werden. Da der Benutzer keinen Zugang zu einer lokalen Konsole hat, sondern uber SSH angemeldet ist, sollten mit der angegeben lter expression die Pakete, die die eigene SSH-Sitzung erzeugt, herausgeltert werden. Dies kann zwar auch nachtrglich a mit ethereal getan werden, aber dieser Schritt verkleinert die Dumps und spart Arbeit, da die Filter-Kriterien in ethereal nicht zustzlich diese unntigen Pakete ausltern a o mssen und somit einfacher ausfallen knnen. u o Diese Dumps knnen dann mittels o scp root@umlnet.sva.tu-harburg.de:/root/dump.file.1 . auf die lokale Maschine transferiert werden, um dort mittels ethereal ausgewertet zu werden. Hierbei knnen auch andere Grundlagen der IP-Kommunikation betrachtet o17

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

7.2 Das SningNachdem es im vorigen Abschnitt um reine Analyse von Netzwerkprotokollen ging, geht es in diesem Abschnitt an das Snien von Daten, also das gezielte Mithren und o Auswerten. Prominentestes Beispiel fr Sning ist das Mithren von Passwrtern unverschlsselter u o o u Protokolle, wie z. B. HTTP, POP3, Telnet, usw. Hierzu wird wiederum tcpdump eingesetzt, um den Datenverkehr mitzuschneiden. Im Ubungsnetzwerk sind zwei Cronjobs aufgesetzt worden, die regelmig von dem a Webserver auf uml3 eine mittels Basic-Authentizierung gesicherte Datei abfragen. Einer der beiden Requests erfolgt mintlich und schlgt fehl, da die Credentials zur u a Authentizierung nicht ubermittelt werden. Der zweite Request erfolgt dreimintlich u und gelingt. Diese Pakete gilt es in dem Dump zu nden. Da bei der Basic-Authentizierung Benutzername und Passwort nur Base64-codiert ubertragen werden, lassen sich die Daten mittels ethereal leicht auslesen. Alternativ kann auch das Tool dsniff eingesetzt werden. Hierbei handelt es sich um einen Passwortsnier fr viele verschiedene Protokolle, wie z. B. HTTP und FTP, u aber auch fr Messenger-Dienste wie ICQ. Das Tool muss nur gestartet werden, es u wertet alle ihm bekannten Protokolle gleichzeitig aus und gibt seine Ergebnisse auf der Kommandozeile (oder in eine Datei) aus. In der dsni-Suite ist auch das Tool urlsnarf enthalten. Es snit nur den HTTPVerkehr und liest dabei alle URLs mit, die abgerufen worden sind. Diese Informationen knnte man ebenfalls aus den vollstndigen Dumps mit Ethereal extrahieren, aber o a dieses Tool ist darauf spezialisiert.

35

7.3 Das SpoongAls nchster Schritt ist das Spoong zu betrachten. Hierbei werden Datenpakete mit a geflschten Informationen versendet, entweder mit geflschten Quell- bzw. Zieladressen a a oder mit geflschtem Inhalt, um bestimmten Diensten Fehlinformationen zukommen zu a lassen. Dies beginnt mit dem Tool hping2, das eigentlich dafr geschrieben wurde, Dau tenpakete zum Testen von Paketlterregeln zu erzeugen. Versendet man nun aber von vielen Hosts gleichzeitig Pings mit der geflschten Absenderadresse eines Hosts X, a so antworten alle Empfnger dieser Pings an den Host X (der diese Pakete niemals a versendet hat). Bei gengend vielen beteiligten Maschinen kann man so von einer u DDoS-Attacke auf Host X sprechen. Interessant bei der Ethereal-Analyse ist wiederum, dass man die geflschten Pakete a daran erkennen kann, dass sie als Absender-MAC-Adresse die echte MAC-Adresse des spoofenden Rechners tragen. Mit entsprechenden Tools und Treibern lassen sich aber auch die MAC-Adressen beliebig ndern. a Das Tool arpspoof fhrt ARP-Spoong durch. Es basiert auf einer Schwachstelu le von ARP, die darin liegt, dass der ARP-Daemon Antworten auf ARP-Requests auch dann annimmt, wenn vorher kein ARP-Request ausgesendet worden war. Das Tool sendet in regelmigen Abstnden ARP-Replies aus, in denen die Antwort a a steht, eine bestimmte IP-Adresse wre auf einer bestimmten MAC-Adresse zu nden a (in diesem Fall auf der eigenen MAC-Adresse). Dieses geflschte IP/MAC-Paar wird a nun in den ARP-Caches aller Maschinen gespeichert, so dass Pakete an diese IP-Adresse an den falschen Rechner geschickt werden. Der Angreifer wrde in so einem Fall u die Adresse des Standard-Gateways ubernehmen und knnte so jedes Paket aus dem o internen Netz zur Auswertung durch seine Maschine leiten. Da es sich bei dem hier vorgestellten Tool nicht um ein bsartiges Programm handelt, o utet es das Netz nicht mit ARP-Replies und setzt bei seiner Beendigung die geflschten a Adressen wieder auf die richtigen Werte zurck. u Ein anderes Tool, das mit gespooften Adressen arbeitet, ist macof. Wie in Kapitel 4.1.3 erlutert, speichert ein Switch in seinem MAC-Cache, welche MAC-Adresse a sich an welchem Switchport bendet, um so unntige Broadcasts zu vermeiden. Mchte o o ein Angreifer nun den Switch in ein hubhnliches Verhalten zwingen, so hat er die a Mglichkeit, den MAC-Cache des Switches mit extrem vielen unterschiedlichen MACo Adressen zu uten, und so die echten MAC-Adressen zu verdrngen. In diesem Fall a mssen die echten Pakete gebroadcastet werden, da keine Zuordnung von MAC-Adresse u zu Switchport besteht. Einige Switches schalten in dieser Situation auch einfach in einen Broadcast-Modus um. Das genannte Tool ist im Ubungsnetzwerk aber mit Vorsicht einzusetzen, da die groe Anzahl an gespooften MAC-Adressen die virtuellen Switches uberlastet und somit das gesamte Netzwerk (zumindest zeitweise) lahmlegt.

36

7.4 Das DNS Cache PoisoningDNS Cache Poisoning ist ein Verfahren, um in den Cache eines Nameservers bei einer rekursiven Namensausung fr einen Domainnamen eine falsche IP-Adresse zu o u injezieren. Das Prinzip des Angris ist vollstndig beschrieben in [9]. a Die Schwachstelle beruht darauf, dass der Nameserver zur Uberprfung der Valiu ditt einer Antwort auf seine Anfrage nur zwei Dinge uberprft: ob die 16bittige a u Transaktions-ID korrekt ist und ob das Antwort-UDP-Paket auf dem richtigen Port eingeht. Da der Nameserver BIND dazu neigt, die selben Ports immer wieder zu benutzen, steigt die Wahrscheinlichkeit, dass ein Angreifer die Transaktions-ID raten kann (die Sicherheit durch die zustzlichen Mglichkeiten der Port-Nummern wird a o nicht genutzt). Nach dem Geburtstagsparadoxon18 bentigt man nur ca. 700 Pakete o mit geratenen Transaktions-IDs um mit einer Wahrscheinlichkeit von fast 100% eine Kollision herbeizufhren und somit den DNS-Cache des Nameservers zu vergiften. u Kurz zusammengefasst luft der Angri wie folgt ab: a Der Angreifer stellt durch eine Test-Anfrage die zu nutzende UDP-Portnummer fest. Danach schickt er eine groe Anzahl (ca. 700) von DNS-Anfragen mit gespooften Absender-Adressen an den Nameserver. Whrend der Nameserver versucht, durch a rekursive Nachfragen seinerseits die gewnschte IP zu erfahren, utet der Angreifer u mit geflschten Antwortpaketen den Nameserver. Sofern er eine Kollision herbeifhren a u kann bevor der echte Nameserver antwortet, wird die geflschte Adresse in den Cache a des Nameservers aufgenommen, und alle zuknftigen Anfragen von Clients werden mit u der geflschten IP beantwortet. Der Angreifer kann so groe Mengen von Anfragen auf a seinen eigenen Server umleiten. Diese Geburtstagsattacke wird z. B. mit dem Skript happydnspoofing [7] und den beiden BIND9-Nameservern auf uml3 und uml6 durchgefhrt. Die beiden Nameu server sind fr die Domains *.uml.int bzw. *.uml.ext verantwortlich (siehe auch u Kapitel 5.1). Nach Einarbeitung in das Tool und diverse Tracanalysen musste aber festgestellt werden, dass es eine groe Hrde zu uberwinden gilt, um diese Attacke erfolgreich u durchfhren zu knnen: u o Der kritische Abschnitt des Angris besteht im Timing - nicht umsonst wird in der Dokumentation darauf hingewiesen, dass es von Vorteil sein kann, den Nameserver, der von dem zu vergiftenden Nameserver befragt wird, mittels sehr vieler Anfragen auszu bremsen, um so mehr Zeit zum Ubertragen der geflschten Pakete zu bekommen. Das a Ubungsnetzwerk simuliert nmlich eine fr die Attacke denkbar ungnstige Situation: a u u einen DNS-Server mit sehr groen Performancereserven sowie ein Netzwerk mit auerst geringer Latenz und hohem Durchsatz. Die Attacke schlgt im Ubungsnetzwerk also a fast unweigerlich fehl, da zwischen rekursiver Anfrage und korrekter Antwort nur wenige Millisekunden vergehen - in dieser kurzen Zeit kann oft nur eine einstellige Zahl von geflschten Paketen ubertragen werden, die Chance einer Kollision ist damit beinahe a gleich Null, da die ntige Anzahl von ca. 700 Paketen nicht einmal annhernd erreicht o a wird.18

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. D