Home

2 Denial of Service (DoS)

1. o nen 59 Auibau des Intranets td o e o a EEN 67 Das Umfeld des Servers 2 2 2 aa et 70 Programme werden auf Ports gelinkt 71 Ein Objekt der Struktur Timenum 73 Illustration der Klasse Tcon 2 2 22 ee ee 73 Ablauf der Bearbeitung eines TCP Pakets 75 Illustration des Servers mit seinen Strukturen 77 Das Umfeld von Programmen 79 Propram Interfaee ted hit has 81 Das Umfeld des Routers ii a 2 0 Ee re 82 Verhalten des Routers bei verschiedenen Filteraktionen 82 Suchen einer passenden Filterregel erfolgreich 83 Suchen einer passenden Filterregel schl gt fehl 83 Aussehen eines Firewall Regelsatzes 84 Klassendiagramm eines Routers o o 84 Umfeld d s Netzes s gon il Ae Se Se ee Be a 85 Ablauf eines Time Updates im Netzwerk 86 bersicht ber die Pakettypen 88 M gliche Abl ufe eines Connects o oo 90 40 4 42 43 44 45 ABBILDUNGS VERZEICHNIS RTI Aufrufe aus der Anwendung Intranet 91 Einbindung des Intranet Federate Ambassadors 93 Der RTIhandler wird von Server und Router gebraucht 94 Verhalten des Servers bei einer SYN Attacke 98 Zeitlicher Ablauf einer SYN Attacke 2 2 22 2 2200 99 Verzeichnisstruktur 2 2 2 2 moon en 128 ERKLARUNG 9 Erklarung Erkl rung zur Diplomarbeit g
2. sendPacket sendPacket packet Packet Meldungen der RTI getNetID IntranetFedAmb i simEnd timeAdvGrant Abbildung 41 Einbindung des Intranet Federate Ambassadors Anwendung Intranet SimulationEnd unterrichtet den Federate dass die Simulation beendet werden soll Der IntranetFedAmb setzt den Wert der Variablen simEnd auf 1 und teilt so dem Anwendungsprogramm mit dass es sich von der Execution abmelden soll Erreicht die Interaktion AttackerJoin den Federate so erh ht er einen Z hler Bei Eingang der AttackerResign Interaktion wird der Z hler wieder verkleinert Dieser Z hler gibt also die Anzahl der aktuell bekannten Angreifer an oder genau er die Zahl der eingegangenen AttackerJoin Interaktionen minus der Anzahl der eingegangenen AttackerResign Interaktionen Erreicht der Z hler beim Erniedri gen den Wert 0 so wird die Simulation beendet da der letzte Angreifer aus der Simulation ausgestiegen ist Die Klasse Int ranet FedAmb ist auch f r den Empfang der Best tigungen f r Zeitverhalten und Voranschreiten in die neue Zeit zust ndig ber die Funktionen enableTimeConstrained bzw enableTimeRegulation erh lt der 94 8 IMPLEMENTIERUNG EINES PROTOTYPS Federate die Best tigung dass die RTI diese Verhaltensweisen f r ihn anwendet Damit das Hauptprogramm dies erf hrt setzt der Federate Ambassador die Variab len TimeRegulation und TimeConstrained bei Erhalt der je
3. Der Patch zam Anwenden auf das Original Installationsskript liegt dem Quell code des Prototyps bei Korrekte Funktionalit t kann aber bei einer von der hier verwendeten Umgebung abweichenden nicht garantiert werden 128 A AUSF HRUNG DES PROTOTYPS A 3 Organisation der Codeverzeichnisse Die Verzeichnisstruktur des Quelltextes gliedert sich folgenderma en Wurzelverzeichnis data DoS Sim fed RTL rid Executables Config Files include h Files Lei T cpp Files 4 Oo I b ka n rtiexec config rtienv sh Abbildung 45 Verzeichnisstruktur A 4 Starten der Federates 129 A 4 Starten der Federates Bevor die Federates gestartet werden sollte eine Instanz der RTI aufgerufen wer den Dazu werden zun chst mit dem Aufruf des Skripts rtienv sh die n tigen Um gebungsvariablen der laufenden Shell gesetzt dann erfolgt der Aufruf der RTI mit rtiexec Beispiel Angenommen man steht im Wurzelverzeichnis des Quellcodes dann fiihrt man folgende Befehle aus RTI config rtienv sh RTI bin rtiexec Hinweis Der Punkt vor dem Aufruf von rtienv sh ist n tig damit die Umge bungsvariablen f r die aktuelle Shell gesetzt werden Vergisst man ihn so kann die RTI nicht ausgef hrt werden Wenn man eine RTI am Laufen hat so kann man die Federates starten Dabei sollte mit dem Starten der Intranets begonnen werden die Angreifer sind als Letztes zu starten Zum Start der Federates ist auch der Aufruf de
4. angezeigt wobei X durch die entsprechende aktuelle Simulationszeit ersetzt wird Alle Ausgaben vor dieser Zeile stammen aus der Zeit vor dem Zeit wechsel alle darauf folgenden von danach e Betroffener Server Die Ausgaben die von den Servern erzeugt werden werden durch HP ee 9 2 Erfolgreicher Smurf Angriff 109 mit IP als der IP des jeweiligen Servers eingeleitet Fiir den Router erscheint statt einer IP der String Router Nachdem der letzte Server des Netzes seine Arbeit erledigt hat erscheint die Meldung net finished Zu den Meldungen geh rt dass jeder Server und auch der Router angibt wieviele Pakete er aktuell zu bearbeiten hat Dies wird mit packets to handle gefolgt von der Paketzahl gemeldet Dieses sind nur die Meldungen die der Server w hrend der Ausf hrung von doWork macht also w hrend der nicht interaktive Teil seines Programms abgearbeitet wird Alle Meldungen die danach generiert werden also durch Befehlsausf hrung aus dem Hauptprogramm heraus folgen erst nach der net finished Meldung Ein weiterer Hinweis zu dieser Simulation Wir starten hier die Federates in der Reihenfolge Amplifier Netz Opfernetz und dann den Angreifer 9 2 1 Angreifer Der Simulationslauf beginnt mit den Meldungen dass der Angreifer sich an der Simulation angemeldet hat Da der Angreifer als Letzter der Federation Execution beitritt existiert diese schon wenn er versucht sie zu erstellen In dieser S
5. B 7 Klasse Rule Rule IP IP int int Protocol Policies Erzeugt ein Objekt vom Typ Rule Die Parameter sind in folgender Reihen folge Absendeadresse Zieladresse Absendeport Zielport Protokoll und gew nschte Aktion Policies match IP IP int int Protocol berpr ft ob die Regel mit den bergebenen Daten bereinstimmt also zu treffend ist Wenn dies der Fall ist wird die in der Regel definierte Aktion zur ckgegeben B 8 Klasse Server Server int Net Konstruktor der aus einem Integer Wert die IP berechnet und damit und mit der Adresse des Heimatnetzes ein Objekt Server erzeugt Server int int Net Konstruktor der aus der Angabe von NetzID HostID und Adresse des Hei matnetzes ein Objekt Server erzeugt Server IP Net Erzeugt ein Serverobjekt aus einer IP und der Adresse des Heimatnetzes Server int int char Net Legt ein Objekt Server an mit NetzID HostID Konfigurationsfile des Servers und dem Heimatnetz Server int char Net Erzeugt ein Objekt Server aus einem Integer f r die IP dem Konfigurationsfile und dem Heimatnetz Server IP char Net Konstruktor der aus einem IP Objekt einem Konfigurationsfile und der Adresse des Heimatnetzes ein Serverobjekt erzeugt void newTime RTIfedTime Funktion mit der der Time Advance an den Server weitergegeben wird Der Server wird hier sein Tcon Objekt updaten und seine Paket Queues umsortie ren um
6. New Time 18 0000000000 Router ROUTER packets to handle 0 saa A 1 5 2 1 packets to handle 100 Too many packets arrived Can t handle every packet SoS A AR 2 2 packets to handle 0 Net finished 2 1 OUTOFORDER 2 2 ONLINE Zu Simulationszeit 19 ist der Angriff vor ber Das Opfer hat sich wieder erholt New Time 19 0000000000 Router ROUTER packets to handle 0 Sag kan 2 1 packets to handle 0 Sr 22 eege 2 2 packets to handle 0 Net finished 2 1 ONLINE 2 2 ONLINE 120 9 BEISPIELLAUF EINER DDOS SIMULATION Das Ende der Simulation ist fiir das Opfernetzwerk identisch mit dem Amplifier Netzwerk Der Federate erh lt das Zeichen zum Beenden und zieht sich zu Zeit 22 aus der Simulation zuriick Got end of simulation INTRANET Resigning Execution resigned INTRANET Destroying Execution destroyed 9 2 4 Der Simulationslauf Nachdem nun die einzelnen Federates auf ihr Verhalten untersucht worden sind bringen wir die Simulation in einen Zusammenhang Zu Zeit 7 schickt der Angreifer seine ersten Pakete Diese erreichen seinen Router zu Zeit 8 Eine Zeiteinheit sp ter Zeit 9 kommen die Pakete beim Router des Amplifiernetzes an und werden zur n chsten Zeit 10 beantwortet Die Flut der Ping Replys passiert den Router des Amplifier Netzes zu Zeit 11 und kommt zu Zeit 12 beim Router des Opfers an Ab Simulationszeit 13 ist das Opfer fiir die Dauer des
7. Will ein Programm Netzwerkkommunikation betreiben so stehen ihm mehrere Funktionen zur Verf gung Mit registerPort bindet sich das Programm an einen Port mit unregisterPort wird diese Verbindung gel st Um nun Pa kete zu senden sind die Funktionen sendTo und connect zu verwenden Den sendTo Funktionen m ssen die Zieldaten Protokoll und Inhalt des Pakets angegeben werden dann wird daraus ein entsprechendes Paket erzeugt Wird ex plizit eine AbsendelP angegeben so wird diese als Absender eingesetzt sonst wird vom Server die eigene korrekte IP verwendet Bei connect werden keine Daten gesendet es wird nur getestet ob auf dem Zielport ein Programm arbeitet Daher reichen dieser Funktion die Angaben von Absendeport Ziel IP und Zielport Als Protokoll wird automatisch TCP eingesetzt da diese Funktion bei den anderen Protokollen nicht existiert 12Es gibt noch Funktionen zum Einloggen Ausloggen Passwort ndern usw Genauer gehen wir hier nicht darauf ein weil diese Funktionen in unserem Prototyp nicht mehr verwendet werden 8 2 Netzwerk 79 Die hier erw hnten Funktionen zur Paketerzeugung sorgen dafiir dass TCP Pakete die Flags richtig gesetzt haben Das aufrufende Programm braucht sich somit nicht um diese Flags zu kiimmern Bei TCP und UDP wird bei der Bearbeitung der Inhalt der Pakete an das auf dem Port laufende Programm tibergeben Aufruf von run mit den Daten als Pa rameter Erzeugt dieser Pro
8. dumpRuleset char file Schreibt den Regelsatz in ein File aus dem er sp ter wieder eingelesen wer den kann mvRuleUp int i Tauscht die Position der ten und der i 1 ten Regel mvRuleDown int nr Tauscht die Position der ten und der i 1 ten Regel addRule Rule regel Fiigt das Objekt einer Regel an das Ende des Regelsatzes an delRule int 1 L scht die Regel an 2 ter Position void sendPacket Packet packet Wird benutzt um ein Paket an den Router zu senden void setHandler RTIhandler B 6 Initialisiert den RTIhandler damit der Router Pakete an das Internet RTD schicken kann Klasse RTIhandler RTIhandler RTI RTIambassador int int Erzeugt einen RTIhandler mit der Adresse des RTI Ambassadors den der Federate benutzt tellNewInstall IP Erzeugt eine Meldung an die RTI dass der Server mit der angegebenen IP neu installiert wurde tellOffline IP Meldet der RTI dass der Server mit der bermittelten IP offline gegangen ist immer noch offline ist int tellOnline IP bermittelt an die RTI dass der Server mit der angegebenen IP online ist int int tellOutofOrder IP Teilt der RTI mit dass der Server mit der bergebenen IP im Zustand Out of Order ist sendPacket Packet Sendet ein Paket an die RTI damit es andere Netzwerke erreichen kann B 7 Klasse Rule 137
9. 3 0 oder es kann ein symbolischer Link des Namens g 3 angelegt werden der auf die Bin rdatei des g V3 zeigt Die Make Aufrufe f r die verschiedenen Kompilierungs Aktionen sind aus dem src Verzeichnis wie folgt aufzurufen e Alle Federates make all e Intranet Federate make intranet Angreifer Federate make angreifer Smurf Angreifer make smurf l schen aller Object Files und Executables make clean Bei einem Makeaufruf werden alle ben tigten Klassen kompiliert soweit sie nicht schon in einer aktuellen Version vorliegen Aber Achtung das Makefile er kennt keine nderungen der include Dateien Werden die includes ver ndert so muss man die von der nderung betroffenen Object Files l schen und dann neu kompilieren 131 B Funktionsreferenz Dieses Kapitel ist als Referenz fiir jene gedacht die sich aktiv an der Entwick lung von DoS Simulationen auf der Basis des hier vorgestellten Prototyps beteili gen wollen Klassenweise werden die ffentlichen Funktionen erkl rt und es wird beschrieben fiir welchen Zweck sie gedacht sind Die privaten Funktionen werden hier weggelassen da sie nur fiir interne Zwecke gedacht sind Wer diese Abl ufe verstehen will sollte gleich den gesamten Quell text studieren B 1 Klasse IP IP int Legt eine IP mit dem bergebenen Wert an Dieser ist der aus HostID und NetzID kombinierte Wert IP int n int bi Legt eine IP mit der NetzID n und der HostID h an Resul
10. 8 2 Netzwerk 73 TimeOut laufen werden Abb 25 Hierzu wird eine Liste angelegt deren Ele mente Timenum Abb 24 immer die Anzahl von Verbindungsanfragen und die dazugeh rige Zeit zu der der TimeOut erreicht wird enthalten Timenum Anzahl Verbindungsversuche Zeit zu der der TimeOut erreicht wird Abbildung 24 Ein Objekt der Struktur Timenum Die Gesamtzahl der Verbindungsanfragen ergibt sich aus der Summe der in den Listenelementen stehenden Anzahlen Auch f r diese Gesamtzahl ist ein Maximal wert definiert dessen Wert hier auf 10 define MAX_CON 10 gesetzt wurde Eine nderung dieses Wertes ist wieder im File server h m glich Tcon Gesamtzahl Verbindungsversuche m1 m2 Timenum Timenum anz m1 anz m2 timeOut n timeOut n 1 Abbildung 25 Illustration der Klasse Tcon Gehen wir aber noch genauer auf die Datenstruktur Tcon ein Tcon enth lt ei ne Liste bestehend aus Timenum Elementen Diese Liste wird so behandelt dass jedes Element eine andere Zeit enth lt wobei ein kleinerer Wert fiir die Zeit bedeu tet dass das Element weiter vorne in der Liste zu finden ist Abb 25 Die Datenstruktur merkt sich auch die aktuelle Zeit Diese bekommt sie bei dem Aufruf ihrer Funktion update tibergeben Weiter wird w hrend dieser update Funktion das erste Element der Liste darauf tiberpriift ob die dort an gegebene Zeit timeOut der aktuellen entspricht Ist dies der Fall so wird die Gesamtzah
11. 8 2 Netzwerk 75 auf Ist ACK gesetzt so ist es ein ordentliches Paket Anhand des FIN Bits ent scheiden wir ob es ein Connect ist FIN ist gesetzt auf den wir dann eine Antwort generieren oder ob wir eine Dienstausf hrung haben und so die Daten an das Pro gramm des gewiinschten Ports tibergeben und eventuell eine Antwort generieren Ist das SYN Bit nicht gesetzt gibt es drei M glichkeiten was f r ein Paket uns erreicht 1 Das ACK Bit ist nicht gesetzt Dieses Paket kann verworfen werden da es eine ung ltige Flag Kombination besitzt 2 ACK und FIN sind gesetzt Dies ist eine Connect Antwort 3 ACK ist gesetzt FIN nicht Wir habe eine Antwort auf eine Dienstausf hrung erhalten und geben sie an das Programm weiter welches an den Zielport des Antwortpakets gebunden ist Bei Bedarf kann auf dieses Paket auch wieder eine Antwort generiert werden Dieser Ablauf ist in Abb 26 dargestellt TCP Paket empfangen Generiere ICMP Paket Port belegt gt ICMP Port unreachable p SYN Bit gesetzt a Paket verwerfen H Paket verwerfen SYN Attacke Sala con_possible ACK Bit gesetzt Nein gt ea Pisos Ja Ja SYN Attack Paket i Tcon inc aufrufen lt Nein ACK Bit gesetzt FIN Bit gesetzt Paket verwerfen Nei Ja J ein Connect Antwort Antwort auf eine Dienstausf hrung EIN BiEgesetzt erhalten erhalten gebe Daten an Programm l des Zielports weiter Ja pale bei Bedarf erneute Antwort m glich Or
12. Diese Grenze w re im sinnvollen Verh ltnis zu der Empfangsbandbreite festzulegen Da es dabei nicht reicht die Anzahl der Pakete die versendet werden k nnen zu beschr nken sollte noch eine Gr enangabe f r Pakete eingef hrt werden die dann bei der Feststellung welche und wieviele Pakete verschickt werden k nnen zu ber cksichtigen w re M gliche L sungsans tze 1 Ein Server muss selbst kontrollieren ob er noch Pakete verschicken darf Da bei tritt aber das Problem auf dass auf dem Prototyp Server die Program me sequentiell ausgef hrt werden und nicht parallel Somit w re ein dem Problem mit der ankommenden Paketreihenfolge in 8 10 1 hnelndes neues Problem entstanden 2 Das Netz k nnte die Paketrate berwachen Damit m sste das Netz die Pakete des Servers sammeln W re die Paketmenge zu gro m ssten nach noch zu bestimmenden Regeln die bersch ssigen Pakete verworfen werden Erst dann d rfte das Netz die Pakete weiterleiten Es w re ebenso anzuraten eine maximale Durchgangsrate f r Router festzule gen damit auch hier eine weitere Ann herung des Prototyps an die Realit t erreicht werden kann 107 9 Beispiellauf einer DDoS Simulation Nachdem wir ausf hrlich die Theorie erl utert haben die unserem Prototyp zugrun de liegt wollen wir nun zeigen wie er in der Praxis arbeitet Wir w hlen dazu als Angriff eine Smurf Attacke Weiter wollen wir an diesem Beispiel die Wirksamkeit einer Fi
13. Opfer tb le t e dr Ai Seet od at Goer a gee wt Gebel ge Se et gah at oR Oo Helfer at Soke POE Re Cw a iets 8 10 Schwachpunkte des Prototyps 208 8 10 1 Reihenfolge der Pakete abh ngig von HostID der Sender 8 10 2 Teilnetze mit gleicher NetzID m glich 8 10 3 Keine Festlegung von maximaler Bandbreite Beispiellauf einer DDoS Simulation IL SZEMAIO ss de ee Say ede Dd Gee ee Sx ee Bh ae 9 1 1 Amplifier Netz ara tert Bo re 9 12 e zur BE OO EE E A ADS A El ee end an INHALTS VERZEICHNIS 9 2 Erfolgreicher Smurf Angriff 92T A A IA 922 AmpliierNez a a A A a ap ES 92 3 A RN 9 2 4 Der Simulationslauf aro 2 oe Cae Rare 9 3 Verhinderter Smurf Angriff 2 2 2 Common nen 10 Ausblick 11 Zusammenfassung A Ausf hrung des Prototyps A l Verwendete Software A 2 Hinweise zur Installation derRTT A 3 Organisation der Codeverzeichnisse A 4 Starten der Federates e A 5 Kompilieren der Federates gt Dad oo e B Funktionsreferenz Bil IA e ee E See eck wo IEN EE P Klasse Packet 2 642448 adas a aa wae Fon BA Interface Klasse Droogram ee ee B3 EE EECHER B 6 Klasse RTIhandler ok Se are Pio es Si eS Bil Klasse Rites 44d da wa dl oe a a ee A ex B 8 Klasse server AN Ne a Rae Sek Baw BS Rs BI Klasse Tea toa e da aaa te wa ea B 10 Programm lassen 400 ee 24 Zeng ko In Hi db B 10 1 Programm IDT 4422 42 4 22 eher
14. bei dem der Benutzer versuchen soll 125 den Angriff zu erkennen und zu verhindern Der Anwender miisste beispielsweise Firewallregeln entwerfen und auf den Router spielen damit der Angriff abgeblockt wird So wie ein Systemadministrator es in der Realit t auch zu tun hatte So ein Ansatz wirft die Frage auf ob man eine reine Visualisierung und damit Aufkl rung ber die Problematik der Gefahren im Internet anstrebt oder ob man nicht durch diese aktive Teilnahme am Geschehen der Simulation weit mehr er reichen kann Mit interaktiven Angreifern und Netzwerken k nnten auch mehrere Personen gleichzeitig trainiert werden Der Verteidiger eines Netzes kann dann das Vorgehen des Angreifers nicht vorhersehen Aber auch konzeptuell sollten noch weitere Wege beschritten werden Das schon im Kapitel 7 4 ber das Konzept des Servers erw hnte Einbeziehen von si mulierten Usern und eine Vergabe von Nutzungsrechten auf Servern scheint weite re M glichkeiten zu erschlie en Damit k nnte man auch geeignete Simulationen der Verbreitung von E Mail Viren verwirklichen oder die Auswirkungen eines Ein bruchs in einen Rechner genauer darstellen 126 11 ZUSAMMENFASSUNG 11 Zusammenfassung Die gestellte Aufgabe war es eine Simulation von Bedrohungen im Internet zu ent wickeln und m gliche Auswirkungen anhand eines simulierten Beispielszenarios darzustellen Als Bedrohung wurden DoS Angriffe gew hlt deren Auswirkungen zu Serverausf llen und U
15. kann dies mit der Interaktion AttackerJoin den Intranetzen bekannt geben Wenn er seinen Angriff beendet hat und sich abmeldet so sendet er die Interaktion AttackerResign Damit wissen die Netze dass sie auf diesen Angreifer nicht mehr warten m ssen Wenn sich also alle Angrei fer die sich irgendwann angemeldet haben wieder abgemeldet haben wird die Simulation beendet 66 8 IMPLEMENTIERUNG EINES PROTOTYPS e Die Simulation kann unabh ngig vom Status der Angreifer nach einer gewis sen Zeit beendet werden Diese Art des Abbruchs ist im Prototyp nicht implementiert k nnte aber auf einfache Weise erg nzt werden Eine Implementierung hat nicht stattgefun den weil sich diese Simulation an den Angreifern orientiert F r eine Si mulation bei der das Verhalten des Internets im Vordergrund steht nicht der einzelne Angriff w re dieser Abbruch aber sinnvoll e Es kann eine Mischform zwischen den bisher genannten Varianten eingef hrt werden die den Abbruch nach sp testens einer vorgegebenen Zeit einleitet ihn aber auch fr her schon durch die Interaktion eines Angreifers durchf hren kann e Ein eigenst ndiger Management Federate k nnte implementiert werden der auch die Abbruchkriterien verwaltet Dieser k nnte sowohl die hier schon beschriebenen Methoden zum Bestimmen des Simulationsendes verwenden als auch andere Kriterien beispielsweise eine interaktive M glichkeit per Mausklick die Simulation zu beenden Von den anderen
16. um bei einem DoS Angriff die Auswirkungen zu zeigen Wenn man aber etwa zeigen will wie sich der Angriff aus Sicht der User auf die Erreichbarkeit des Systems auswirkt dann ist dieser Modellansatz nicht ausreichend 6 4 Modell der Netzwerkrechner Dieses Modell beschreibt die Rechner des Internets von denen der Angreifer einige zu seinen Helfern machen wird Diese Rechner k nnen in verschiedene Klassen eingeteilt werden e Wichtige Server Diese Server besitzen eine hohe Bandbreite und eine feste IP Adresse und sind f r den Betrieb zumindest in ihrem Teilnetz so wichtig dass man sie selbst bei einem Verdacht auf DoS Aktivit ten nicht so schnell aus dem Netz nimmt Bei einem Ausfall dieser Server wird die gesamte Internet Aktivit t oder zumindest die Aktivit t einzelner Netzbereiche stark eingeschr nkt Zu dieser Servergruppe geh ren beispielsweise Primary Name Server e Server Dieses sind Rechner die dauerhaft im Internet erreichbar sind aber von nicht so entscheidender Bedeutung Bei Verdacht auf DoS Aktivit ten k nnten die se Server leicht aus dem Netz genommen werden ohne andere Server oder 6 4 Modell der Netzwerkrechner 53 Netzaktivit ten stark zu beeintr chtigen Die einzigen gest rten Verbindun gen sind die die direkt mit diesem Server bestehen sollen e Privatrechner Diese Rechner besitzen keine feste IP Adresse Sie sind meistens nicht gut gegen Angriffe geschiitzt sind aber im Rahmen einer klassisc
17. Aber neben der Komplexit t gibt es ein weiteres Problem Das Internet ist riesig und es entwickelt sich st ndig weiter Es wird zum einen gr er zum anderen ndert sich die Charakteristik der benutzten Protokolle W hrend z B um 1992 der Schwerpunkt des Netztraffics bei FTP lag fing das HTTP Protokoll erst an wirklich benutzt zu werden Wenige Jahre sp ter kehrte sich das Verh ltnis von FTP zu HTTP um Mittlerweile ist ein Hauptteil des Netzverkehrs auf Applikationen zur Multimediadaten bertragung zur ckzuf hren zu denen unter anderem Napster oder Gnutella geh ren Vor wenigen Jahren war an solche Anwendungen noch nicht zu denken Aber nicht nur die Charakteristik der verwendeten Protokolle beeinflusst das In ternet sondern schon die Unterschiede in den einzelnen Implementierungen Auch 4 1 Simulation des Internets 35 diese Unterschiede k nnen unter Umst nden beim Simulationsverhalten zum Tra gen kommen Wie aber soll man ein so komplexes lebendiges Gebilde simulieren Gibt es berhaupt eine sinnvolle Methode daf r Die einzig m gliche Antwort ist dass man vereinfachen muss indem man sich die Aspekte die man f r seine Simulation braucht herausgreift und den Rest des Internets zu einem einheitlicheren einfachen Modell zusammenfasst Der gr te Teil der Vitalit t des realen Internets geht hierbei verloren Das Wachsen des Netzes wird ignoriert Man friert das Netzwerk sozusagen ein macht ein Abbild zu einem be
18. BA1V2 Prosramm Ping 22 Pose IE ea rin B 10 3 Programm Sm rf sorata 44 Ba ea a er B 10 4 Programm SynAttackTool aya sled rear B 10 5 Programm Webserver o Literatur 108 109 113 116 120 120 124 126 127 127 127 128 129 130 131 131 132 133 134 135 136 137 137 140 141 141 142 142 143 144 145 INHALTSVERZEICHNIS ABBILDUNGSVERZEICHNIS 7 Abbildungsverzeichnis GO AJ Ch Dn PWN Ke GHEET ott Se hd ee E BS Bee ae 4 17 TCP Verbindungsaufbau Vollst ndiger 3 Wege Handshake 18 Connect Versuch mit gespoofter Absendeadresse 19 Beispiel Einfaches Netzwerk vos bd oa e Ete eae 20 Beispiel Master Daemon Netzwerk 21 Stationen beim Paketversenden 32 Kommunikation zwischen Federate und RTI 41 Die Hierarchie der Interaktionen 44 Verhalten bei einer SYN Attacke 22 22 2202 46 Verhalten bei einer Smurf Attacke o 47 Ablauf bei Anwendung eines Exploits 47 Angreifer Del Smurf as oo Au u Gla eae e ae AN 48 Genaueres Angreifermodell 49 Grobes Zustandsdiagramm des Angreifers 50 Zustandsdiagramm des Opfers o o 52 Zustandsdiagramm eines Netzrechners 55 Ablauf einer Kommunikation 2 2 nn nn 56 Konzept im Kontext der realen Welt 58 Konzept im HLA Kontext e 59 Konzept eines Subnetzes
19. Klassen den FederateAmbassador IntranetFedAmb und den RTIhandler der die RTI Funktionen f r andere Klassen versteckt Die im An wendungsprogramm und dem RTIhandler erw hnten Funktionen werden von der RTI bereitgestellt und ber den RTI Ambassador aufgerufen from A to B Protocol TCP fromPort m toPort n sendPacket m1 flags 111 isSYN true isACK true isFIN true sendPacket m2 tcp connect m1 Packet Protocol TCP create fromPort m isSYN true isACK true isFIN true sep connect m1 Packet getNetlD to B Protocol TCP create fromPort m toPort n flags 111 isSYN true isACK true isFIN true getNetID s toPort n 1 flags 111 sendPacket m1 gt 8 IMPLEMENTIERUNG EINES PROTOTYPS getNetID s H f sendPacket m1 l con_possible l H H I l l H H 1 sendPacket m2 l 1 to A i Protocol TCP i fromPort n S toPort m flags 011 isSYN false isACK true isFIN true intranet Net myNetID s getNetID s create i f ICMP Packet sendPacket m2 m2 Packet La STEESEL Me Packet l sendPacket m2 i from B to A Protocol ICMP fromPort 3 ICMP Code toPort 3 ICMP Type flags sendPacket m1 sendPacket m1 LU I con_possible i i i i i Le _O FALSE _ 1 i l i Abbildung 39 M gl
20. Netzwerk 87 Paket durchf hren Dies f hrt zwar dazu dass man spezielle Angriffe die auf Din gen wie Paketfragmentierung beruhen wie z B den ber hmten Ping of Death nicht simulieren kann aber auch daf r kann man sich wenn n tig als Erweiterung des bestehenden Prototyps einen Ausweg ausdenken Ein Ping of Death spielt in der heutigen Zeit zum Gl ck keine Rolle mehr da die meisten Implementierungen der Betriebssysteme heute dagegen immun sind Weiterhin gibt es Entsprechungen der wichtigen Protokolle TCP UDP und ICMP Aber auch diese sind abstrahiert Alle Protokolle arbeiten mit der selben Klasse Packet Je nach Instanziierung der Attribute wird ein Paket als TCP UDP oder ICMP Paket interpretiert Die m glichen Paketinstanziierungen mit kennzeichnenden Werten sind Abbildung 38 zu entnehmen Die dort angegebenen Pakete sind noch in den Attributen f r Source und Ziel IP Source und Zielport variabel Ebenso ist der Datenanteil nicht festgelegt au er durch die Anwendung die die Pakete generiert Durch dieses Einheitspaket f r alle Protokolle sind manche Attribute auch ein mal unbelegt oder sie beinhalten einen anderen Wert als der Name andeutet So ist bei ICMP und UDP das lags Attribut unbelegt und sollte auch aus Protokoll gr nden nicht benutzt werden um andere Daten damit zu codieren da das bei den wirklichen Protokollen auch nicht m glich ist Und die beiden Port Attribute sind im Falle eines ICMP Pake
21. Rechner aus ihrem Netz kommunizieren oder Pakete ber das Internet versenden Sie m ssen so auch ihre Entscheidungen zum Paketverkehr im Intranet nicht danach treffen ob ein anderer Server erreichbar ist oder nicht 7 3 Kommunikation im Netzwerk Im Rahmen der DoS Simulation durch den Prototyp kann auf eine Darstellung von Netzwerkverkehr der nicht an der Darstellung der DoS Attacke beteiligt ist ver zichtet werden Dieser Verkehr macht nur dann Sinn wenn man die Auswirkungen des Angriffs auf die regul ren Nutzer des Opfers simulieren will Aber auch dann sollte man darauf achten eine Art der Netzlasterzeugung zu benutzen die auch in Hinsicht auf reale Netzlast sinnvoll ist Da in unserer Simulation dieser Netzverkehr noch nicht wirklich zu Auswir kungen auf das Netzverhalten f hrt und keine Auswirkungen auf den Angriffsver lauf aus bt nimmt uns seine Simulation h chstens Ressourcen zur Berechnung der brigen Simulation weg Weiter ist es schwer mit einem so kleinen Ausschnitt des Internets welches wir in den Beispielsimulationen verwendet haben realistischen Verkehr zu erzeugen Und um einen Federate zu schreiben der sich um Traffic erzeugung aus nicht eigenst ndig simulierten Netzen k mmert ist in dieser Arbeit keine Zeit verblieben Dies ist auch eine schwierige Aufgabe wie schon in Kapitel 4 oder in 18 erw hnt wird F r den von uns ben tigten Traffic scheint es sinnvoll zu sein ihn an die im rich tigen Intern
22. Russell Bradford Rob Simmonds and Brian Unger A Parallel Discrete Event IP Network Emulator In MASCOTS pages 315 2000 Lawrence S Brakmo and Larry L Peterson Experiences with Network Si mulation In Measurement and Modeling of Computer Systems pages 80 90 1996 Christoph Busch and Stephen Wolthusen Netzwerksicherheit Spektrum Aka demischer Verlag 2002 Laurent Cazard and Martin Adelantado HLA Federates Design And Fede rations Management Towards a Higher Level Object Oriented Architecture Hiding The HLA Services 2002 Cisco Defining Strategies to Protect Against TCP SYN Denial of Service Attacks 2003 http cio cisco com warp public 707 4 html CERT coordination Center Advisory CA 1998 01 Smurf IP Denial of Service Attacks 2000 http www cert org advisories CA 1998 01 html CERT coordination Center Trends in Denial of Service Attack Technology October 2001 v1 0 http www cert org archive pdf DoS_trends paf David Dittrich The DoS Project s trinoo distributed denial of service attack tool 1999 http staff washington edu dittrich misc trinoo analysis txt 146 12 13 kel 14 LL 15 LL 16 LL 17 18 19 20 21 22 LITERATUR David Dittrich The stacheldraht distributed denial of service attack tool 1999 http staff washington edu dittrich misc stacheldraht analysis txt David Dittrich The tribe flood network dis
23. als Server durch Pakete von au en ansprechbar Ein Programm im Zustand LISTENING ist an einem Port registriert und kann durch Senden eines Pakets an diesen Port zur Ausf hrung gebracht werden Der 80 8 IMPLEMENTIERUNG EINES PROTOTYPS Zustand RUNNING deutet auf ein in Ausfiihrung befindliches Programm hin Nur ein Programm in diesem Zustand wird zu einem Zeitwechsel vom Server ausgef hrt Jedes Programm ist selbst daf r verantwortlich einen konsistenten Zustand zu behalten Der Server auf dem das Programm l uft kann dies nicht gew hrleisten Sonst br uchte er Wissen ber die Funktionalit t der Programme und dies ist nicht w nschenswert weil es eine unrealistische Abbildung der Wirklichkeit w re Einzig bei einem Reboot des Servers wird das Programm automatisch in einen definierten Boot Zustand versetzt So soll sichergestellt werden dass bei einem Shut Down des Servers alle laufenden Programme beendet werden Hierzu stellt die Klasse Program eine Funktion boot state zur Verf gung die das Programm in den Zustand STOPPED versetzt Jedes Programm muss selbst darauf achten dass es bei einem erneuten Start dann wieder seinen Zustand einem Programmstart anpasst und nicht f lschlicherweise noch alte Daten ber cksichtigt Alle Programme m ssen gewisse Funktionen bereitstellen damit der Server sie bedienen kann Deshalb m ssen die Programme die man auf den Servern installie ren k n
24. den SYN Angriff 98 8 IMPLEMENTIERUNG EINES PROTOTYPS ist dieses der Z hler der die noch nicht zustandegekommenen Verbindungsaufbau versuche z hlt in Verbindung mit einer maximalen Anzahl solcher Versuche Kommt ein SYN Angriffspaket so wird der Z hler f r Aufbauversuche erh ht Ist er auf dem definierten Maximalwert so werden gar keine TCP Pakete mehr angenommen bei denen das SYN Bit gesetzt ist da keine neuen Verbindungen mehr aufgebaut werden k nnen Pakete ohne SYN Bit aber mit ACK kommen noch an Ihre Verbindung besteht ja schon es sind Antworten Das Verhaltensdiagramm eines Servers bei einer SYN Attacke ist in Abb 43 dargestellt Dass diese Implementierung gut zu dem von uns entworfenen Modell einer SYN Attacke passt beweist die gro e hnlichkeit dieser Abbildung mit der des Modells Abb 9 SYN Attack Packet an Tcon inc con anz Paketza die in TimeOut lauft STB E gibt con_possible true zur ck AE Pakete werden bearbeitet SYN Attack Packet Connection TimeOut Tcon anz gt MAX_CON Tcon anz Paketzahl die in TimeOut l uft SYN Attack PASA mit Kees Abbildung 43 Verhalten des Servers bei einer SYN Attacke In Abb 44 ist der Ablauf dargestellt der beim Empfang eines SYN Angriffspakets stattfindet Wenn das Paket beim Server ankommt wird berpr ft ob die Verbindung angenommen werden kann In a ist dies der Fall das Paket sorgt also daf r dass der Aufbauversuch Z hler erh
25. der 13 DNS Root Server sind eine Stunde lang durch einen DoS Angriff unerreichbar 46 November 2002 Die DNS Server von UltraDNS einem gro en Anbieter f r DNS Services werden 3 Stunden lang angegriffen Obwohl sich hier 40 Rechner 2 IP Adressen zum Lastausgleich teilen erh lt noch jeder Server mehr Pakete als eine T1 Standleitung ca 1 5 MBit s verkraften k nnte Der Angriff schafft zwar keine vollst ndige Auslastung der Systeme dennoch beschlie t UltraDNS eine Er h hung ihrer Bandbreite Diese Liste gibt nur einen kleinen Teil der bekannt gewordenen DoS Aktivit ten wieder die in den letzten Jahren stattgefunden haben Die Dunkelziffer ist sicher sehr hoch Dennoch kann man daran sehen dass Angreifer ihre Opfer nicht aus bestimmten Branchen w hlen und dass sie Angriffe auf die zugrunde liegende In frastruktur des Internets f hren Noch immer verkennen viele Entscheidungstr ger dieses Problem Sie beru fen sich darauf dass niemand ein Interesse daran h tte genau ihre Infrastruktur zu treffen Viele Angriffe werden aber von Personen ausgef hrt die einfach nur testen wollen ob ein Angriff funktioniert wobei es ihnen ganz egal ist wen sie ISiehe http www theregister co uk content 6 24773 html siehe http zdnet com com 2100 1105 947101 html 3siehe http www theregister co uk content 55 28291 html Eine genauere Auflistung von DoS Aktivit ten im Internet von 1999 bis 2001 ist 10 zu ent nehmen Weitere
26. die er f r seine Attacke braucht Die Programme sollten also kein fester Bestandteil des Servers sein sondern eine modulare Erg nzung zu einem Server darstellen Wir werden deshalb die Pro gramme als Klassen definieren und jeder Server wird eine Liste der auf ihm instal lierten Programme erhalten Diese Liste kann dann w hrend des Simulationslaufs ver ndert werden um Installationen und Deinstallationen zu erm glichen 62 7 KONZEPT F R DIE IMPLEMENTIERUNG Wenn die Programme nun als eigenst ndige Objekte von einem Server verwaltet werden so muss ein Server seinen Programmen auch die M glichkeit bieten ber ihn die Netzwerkkommunikation zu betreiben Er muss also Funktionen bereitstel len mit denen die Programme IP Pakete verschicken K nnen Weiter wird eine M glichkeit gebraucht ankommende Pakete an die richtigen Programme weiterzuleiten Hierzu wird ein Portsystem wie auf realen Servern nachgebildet bei dem sich ein Programm an einen freien Port bindet um die Pakete zu erhalten die an diesen Port gesendet werden Aber auch Programme die Pakete abschicken wollen m ssen sich an einen Port binden damit sie ihren Absende Port angeben k nnen und eventuelle Antworten auf ihr Paket zu erhalten Bei der Ausf hrung von Programmen gibt es in der realen Welt mehrere M g lichkeiten 1 Ein Programm ist ein Dienst z B ein Webserver der sobald er gestartet wur de st ndig an einem Port lauscht Kommt ein Paket an sei
27. e Protokollschw chen e begrenzte Ressourcen Programmfehler sind Implementierungsfehler in Programmen Protokollen oder Betriebssystemen Meistens sind diese Fehler von der Art dass Ausnahmen die z B durch Fehleingaben von Programmen auftreten k nnen nicht abgefangen werden oder dass das Programm nicht berpr ft ob behandelte Daten in den bereit gestellten Speicher passen buffer overflow oder auf deutsch Speicher berlauf Beispiele fiir Angriffe auf solche Programmfehler sind der Ping of Death bei dem das Empfangen eines manipulierten Ping Pakets den Rechner zum Absturz bringt weil das empfangene Paket mehr Speicherplatz beansprucht als fiir das Pa ket bereitsteht Ein weiteres Beispiel ist der sogenannte OOB Out of Bound bei dem es zu einem Crash kommt wenn auf einem bestimmten Port andere Daten eintreffen als die erwarteten Bei Protokollschw chen ist das Problem nicht eine fehlerhafte Implementie rung sondern eine Designschw che des Protokolls Angriffe auf Protokollschw chen nutzen aus dass manche Protokolle auf Serverseite der Server ist hier auch das Opfer deutlich mehr Ressourcen erfordern als beim Client Angreifer Ssiehe hierzu 35 25 38 6Zur Erkl rung ein Server ist ein Rechner der einen Dienst anbietet Ein Client ist ein Rechner der einen Dienst bei einem Server anfordert Da der Server oft Berechnungen anstellen oder gro e Datenmengen z B Datenbankserver be
28. ein simulierter Server so wie ein realer sich die Zust nde in denen sich eine TCP Verbindung befindet im Aufbau zustande gekommen etc merken miisste Ebenfalls w re zus tzlicher Aufwand bei der Bearbeitung der empfangenen Pakete n tig geworden So wurde ein einfacheres Konzept entwickelt wie man eine TCP Verbindung darstellen kann Dabei verlassen wir uns darauf dass die RTI alle Interaktionen wirklich weitergibt Somit k nnen wir auf die Best tigungs Pakete verzichten Der Status der Verbindung wird durch die TCP Flags codiert die in den Paketen gesetzt werden Damit reicht auch hier ein Paket f r jede Verbindungsrichtung genau wie bei UDP Genaueres zu diesem Konzept ist der Beschreibung der Implementierung 8 2 6 zu entnehmen 7 4 Konzept eines Servers Die Server sind sehr wichtig fiir unsere Simulation denn sie miissen uns die Funk tionalit t bieten die f r eine DoS Attacke gebraucht wird Sie m ssen auf SYN und Smurf Attacken reagieren also bei Auslastung weitere Verbindungen ableh nen sie m ssen als Server Programme anbieten die andere von au en erreichen k nnen um sie zu benutzen Und weiter soll es m glich sein dass man auf unter schiedlichen Servern auch unterschiedliche Programme laufen lassen kann Die Programme m ssen sogar w hrend der Simulation installiert und deinstal liert werden k nnen sonst k nnte ein DDoS Anwender z B nach seinem Einbruch in das System nicht die Programme installieren
29. eines Exploits Schwachstellen in einem Programm ausnutzen und damit Befehle auf einem fremden Rechner ausf hren kann Zun chst sendet der Angreifer Daten an ein Programm um es auszuf hren Wenn dies durch einen Exploit geschieht so werden diese Daten das Programm zur fehlerhaften Ausf hrung und so zu der Nebenreaktion bringen die der Angreifer w nscht Es wird dann eine Aktion aufgerufen die der Angreifer mit den von ihm gesendeten Daten bestimmen kann Allerdings muss das Programm selbst heraus finden k nnen ob die empfangenen Daten Fehler des Programms ausnutzen oder nicht Der Ablauf einer Exploitanwendung stellt sich also wie in Abb 11 dar 6 2 Angreifermodell 47 Zeiteinheit ist um Bei i lt n trifft ein Paket ein i wird auf Null gesetzt es wird bearbeitet Se i wird um 1 erh ht Bei i n ist ein weiteres MEILEN Paket eingetroffen Zeiteinheit ist um es wird nicht bearbeitet i wird auf Null gesetzt Ausgelastet alle weiteren Pakete werden nicht mehr bearbeitet Abbildung 10 Verhalten bei einer Smurf Attacke 6 2 Angreifermodell Es gibt kein allgemeing ltiges Angreifermodell Vielmehr muss man f r jeden Typ von Angreifer und Angriff ein eigenes Modell entwerfen Im Folgenden entwickeln wir beispielhaft zwei verschiedene Angreifermodelle Das erste Modell wird einen Angreifer beschreiben der eine Smurf Attacke durchf hrt das zweite behandelt einen Angreifer der zun chst ein Angriffsnetzwerk aufbaut um dann sei
30. erkl ren dass wir bis her nur Flooding Attacken Smurf Angriff und Protokollprobleme SYN Attacke dargestellt haben Man kann aber auch eine Programm Klasse schreiben bei der die Anwendung eines Exploits zu DoS Auswirkungen f hrt Sie k nnte den Server also beispiels weise zum Absturz bringen Eine genauere Beschreibung wie eine solche Programmklasse aussehen m sste erfolgt hier nicht Dies ist in dieser Arbeit nicht untersucht worden Was wir zu die sem Thema hier aber erw hnen m chten ist dass bei dieser Art von DoS Attacke das Implementierungsproblem nicht auf Seiten der Erzeugung des Serverausfalls liegt Durch die Anwendung des Exploits den Server in den Zustand OFFLINE zu bringen w re sp testens durch Anwendung der Serverfunktion shutDown ohne Probleme m glich Wie simuliert man dann aber nach einem solchen Server crash dass der Server wieder gebootet wird Es gibt zur L sung dieses Problems verschiedene Ans tze Der Server kann nach einer zuf lligen Zeit von sich aus wieder booten der Bootvorgang kann aber auch durch ein Anwendungsprogramm oder die Net Klasse initiiert werden Alle genannten M glichkeiten besitzen Vor und Nachteile sie zu untersuchen ist aber nicht Teil dieser Arbeit Kommen wir deshalb wieder zu den hier verwendeten Angriffen zur ck Im Ab schnitt ber die Serverimplementierung wurden die n tigen Grundlagen beschrie ben die wir brauchen um einen DoS Angriff zu simulieren F r
31. glichkeiten der Filterung implementiert Im Folgenden wird nun auf die einzelnen Klassen des Netzwerks genauer ein gegangen Es wird ihr Aufbau beschrieben und auf ihre Kommunikation sowohl untereinander als auch mit dem restlichen Internet eingegangen 68 8 IMPLEMENTIERUNG EINES PROTOTYPS 8 2 1 Basisklassen Fiir die bessere Ubersichtlichkeit des Quellcodes und somit auch zur Vermeidung von Fehlern sind neue Basistypen definiert worden Der Typ Policies definiert die m glichen Aktionen der Firewall ACCEPT er legt die Namen der Aktionen fest Es bleibt aber Sache des Rou PENY ters die dazugeh rige Ausf hrung festzulegen Dieser Basistyp wird FAULT von den Klassen Router und Rule ben tigt Implementiert wird dieser Typ als Aufz hlung C enum Der Basistyp Protocol ist ebenfalls eine Aufz hlung und legt die Kommuni kationsprotokolle fest die in unserem Netzwerk zur Verf gung stehen Diese beiden Basisklassen haben neben den eigentlich ver wendeten Aktionen bzw Protokollen jeweils noch einen Fehler zustand FAULT bzw ERR Dieser ist n tig um Fehler abzu fangen die beispielsweise beim Einlesen einer Firewallregel aus einem File auftreten k nnen Genauer wird auf dieses Problem im Kapitel ber den Router 8 2 4 eingegangen ServiceStates ist ebenfalls ein Aufz hlungstyp der die Zust nde definiert die ein Programm annehmen kann enum ServiceStates Denn der Server muss feststellen k nnen
32. in der neuen Zeit richtig arbeiten zu k nnen Hier wird auch gepriift ob der Server wieder automatisch booten soll z B nach einer Neuinstallati on 138 int int int int int int B FUNKTIONSREFERENZ doWork Die Arbeit des Servers zur aktuellen Zeit wird hiermit ausgef hrt Damit werden die laufenden Programme f r ihre Aktionen angesto en und die er haltenen IP Pakete werden bearbeitet setConfig char Funktion mit der man dem Server ein neues Konfigurationsfile zuweisen kann boot Der Server wird gebootet Dabei werden alle Programme bei denen die Va riable startAtBoot gesetzt ist gestartet Der Rechner erh lt den Status ONLINE shutDown Der Server wechselt in den Zustand OFFLINE Hierbei werden alle Program me beendet die TCP UDP Ports werden freigegeben newInstallation Zuerst wird der Server heruntergefahren wechselt damit in den Zustand OFFLINE Dann werden seine Programme gel scht Nun werden die im Konfigurationsfile angegebenen Programme installiert Die Zeit bis zum automatischen Boot wird auf den durch die Konstante DOWNTIME in server h definierten Wert gesetzt newInstallation char file Siehe oben aber hier wird gleichzeitig das Konfigurationsfile neu gesetzt void send Packet int int int Funktion um ein Paket an den Server zu senden sendTo int IP int Protocol char Funktion mit der Programme die auf dem Rechne
33. int 1 L scht den Server mit der HostID i aus dem Netz R ckgabewert ist 1 bei einem aufgetretenen Fehler und 0 wenn der Server gel scht werden konnte int delServer Server L scht den Server aus dem Netz der als Argument bergeben wurde R ck gabewert ist 1 bei einem aufgetretenen Fehler und 0 wenn der Server ge l scht werden konnte B 3 Klasse Packet Packet IP f IP t Protocol prot int fp int tp char msg Erzeugt ein Paket mit Absendeadresse f Zieladresse t Protokoll prot Absen deport fp und Zielport tp Das Flags Feld wird auf 0 initialisiert egal welchem Protokoll das Paket angeh rt Das Datenfeld erh lt den Inhalt msg Packet IP IP Protocol int int int flgs char Wirkt wie der erste Konstruktor Erster Parameter Absende IP dann Ziel IP Protokoll Absendeport und Zielport Dann folgt die gewiinschte Initialisie rung des Flags Felds abschlie end wieder der Inhalt des Daten Feldes int isSYN Fragt ab ob das SYN Bit gesetzt ist und gibt 1 gesetzt oder O nicht ge setzt zuriick int isACK Pr ft das ACK Bit und liefert 1 gesetzt oder O nicht gesetzt zur ck 134 B FUNKTIONSREFERENZ int isFIN Liefert 1 wenn das FIN Bit gesetzt ist sonst 0 int isRST Fragt ab ob das RST Bit gesetzt ist 1 gesetzt O nicht gesetzt void setSYN Setzt das SYN Bit des Pakets void setACK Setzt das ACK Bit void setFIN Setzt das FIN Bit void set
34. mehrere M glichkeiten vorstellen wie man einen Simulationslauf beenden kann F r jedes Simulations Szenario soll te getrennt entschieden werden welche Abbruchmethode gew hlt wird Hier nun einige M glichkeiten e Wenn nur ein Angreifer simuliert werden soll so kann dieser nach Beendi gung seines Angriffs das Signal geben die Simulation abzubrechen Hierzu kann er die Interaktion SimulationEnd verwenden Diese Interaktion sorgt daf r dass alle Intranetze ihre Ausf hrung beenden Wer trotz mehrerer An greifer diese Interaktion benutzt sollte sich im Klaren sein dass die anderen Angreifer bei Empfang von SimulationEnd nicht in jedem Fall auch ihre Ausf hrung beenden sondern nur dann wenn das f r sie so implementiert wurde Man kann auf diese Weise auch mehrere Angreifer simulieren aber man soll te dabei beachten dass nur der der als letzter seinen Angriff beendet diese Interaktion senden sollte da sonst die anderen Angreifer kein Internet mehr zum Agieren haben weil alle Subnetze sich aus der Simulation zur ckgezo gen haben Kann man nicht genau vorhersagen welcher Angreifer zuletzt fertig wird da die Ausf hrungsdauer des Angriffs vielleicht von dem Verhal ten der Simulation abh ngt sollte man eine andere M glichkeit des Simula tionsabbruchs vorziehen e F r den Fall dass mehrere Angreifer aktiv werden sollen kann eine andere Art von Interaktion verwendet werden Ein Angreifer der an der Simula tion teilnimmt
35. to handle 0 Net finished 2 1 ONLINE 2 2 ONLINE New Time 10 0000000000 Router ROUTER packets to handle 0 erst re 2 1 packets to handle 1 DEAD ee 2 2 packets to handle 0 Net finished 2 1 ONLINE 2 2 ONLINE 9 0000000000 x KKKXKXK 118 9 BEISPIELLAUF EINER DDOS SIMULATION New Time 11 0000000000 Router ROUTER packets to handle 1 Sra E 2 1 packets to handle 0 A 2 2 packets to handle 0 Net finished 2 1 ONLINE 2 2 ONLINE Zu Simulationszeit 12 erh lt der Router des Opfernetzes die Angriffspakete Noch ist bei den Servern im Netz alles ok Da aber der Router die Ping Pakete an das Opfer weiterleitet erf hrt dieses zu Zeit 13 eine berlastung New Time 12 0000000000 a Ro ter ROUTER packets to handle 100 Bari ii le or 2 1 packets to handle 0 ES 22 725 2 2 packets to handle 0 Net finished 2 1 ONLINE 2 2 ONLINE RARE New Time 43 0000000000 HR Router ROUTER packets to handle 100 A Se 2 1 packets to handle 100 9 2 Erfolgreicher Smurf Angriff 119 Too many packets arrived Can t handle every packet RA ie 2 2 packets to handle 0 Net finished 2 1 OUTOFORDER 2 2 ONLINE Zu Simulationszeit 18 ebbt die Flut der Pakete dann ab Der Router bekommt keine neuen Pakete mehr das Opfer muss aber noch welche bearbeiten
36. true isSYN false isACK true isACK true isFIN false isFIN false Abbildung 38 Ubersicht iiber die Pakettypen In Abb 39 ist der Ablauf eines Connects im Intranet dargestellt Dabei erzeugt der Server ein Paket welches er an sein Netz weitergibt Im Beispiel stellt das Netz fest dass das Paket lokal verschickt wird und gibt es an den gewiinschten Empfan ger weiter Dieser reagiert dann seiner Konfiguration und Lage entsprechend auf den Empfang Wenn der Port den das Paket ansprechen will belegt ist dann er zeugt er ein Antwortpaket welches den Connect best tigt und sendet es an den In 8 2 Netzwerk 89 itiator des Connects zur ck Abb 39 a Ist der Port nicht belegt so wird statt der Connect Antwort ein ICMP Port unreachable Paket generiert und zuriickgeschickt Abb 39 b Das ist das gewiinschte Verhalten eines Connects Aber stellt man sich den Fall einer laufenden SYN Attacke vor so darf der Server den Connect nur beantworten wenn er die n tigen Ressourcen dazu noch frei hat Wenn der Server feststellt dass der Port belegt ist so muss er noch zus tzlich abfragen ob er noch Verbindungen annehmen kann Und nur dann darf er die Connect Antwort senden Wenn keine Ressourcen frei sind so verh lt er sich als hatte er das Paket nicht bekommen Es findet keine Antwort statt Abb 39 c Der Unterschied zwischen der Kommunikation intranet intern und der Kommu nikation von Servern in unterschiedlichen
37. unm glich Dazu werden zu viele Details ber cksichtigt Und einen Entscheidungstr ger wird nicht inter essieren wieviele Daten nun genau bei einem Angriff ankommen ihn wird nur interessieren Sind wir noch funktionsf hig oder nicht und wenn nein wie k nnen wir etwas dagegen tun Informationen zu ns auf http www isi edu nsnam ns 4 2 Spielwiese DoS Attacken 37 Aus diesen Gr nden werden wir einen eigenen Simulator entwickeln der be sonders die f r Pr sentationen wichtigen Aspekte des Netzgeschehens aufzeigen soll Eine Vergleichbarkeit der DoS Tools wird er aber nicht bieten 4 2 Spielwiese DoS Attacken DoS Attacken sind weit verbreitet und man kann an ihnen viele Verhaltensweisen aufzeigen die zur Verst rkung der Probleme oder auch zu ihrer Abschw chung beitragen Deshalb wollen wir uns bei unserer Prototyp Simulation auf D DoS Attacken beschr nken Unbedarfte Internetuser handeln z B oft nach dem Motto Wenn mich jemand angreift dann schlage ich zuriick Da kann schon ein vermeintlicher Portscan des heimischen Rechners mit einem massiven DoS Angriff beantwortet werden Beliebt ist hier unter anderem der Versuch den Angreifer dazu zu bringen tiber sein Modem den String ATH0 zu senden das bei vielen Modems zu einem Verbindungsabbruch fiihrt weil sie es als Kommando zum Trennen der Verbindung interpretieren Aber es k nnten auch andere Reaktionen denkbar sein die auch Nicht Modem Nutzer b
38. welchem Abstraktionsniveau diese Abbildung stattfindet d h wie genau man Details der realen Welt nachbildet ist abh ngig von den Anforderungen an die einzelne Simulation Man sollte die reale Welt nicht genauer abbilden als n tig da man sonst unn tig komplizierte Modelle verwenden m sste Andererseits kann man sich durch zu gro es Abstrahieren sehr viele M glichkeiten der Ausgestaltung nehmen Es gilt also gut abzuw gen inwiefern man Details ber cksichtigt Warum eine solche Abbildung des realen Internets eine besonders schwere Auf gabe ist und wie man ein geeignetes Abstraktionsniveau f r eine DoS Attacke er mittelt wird im Folgenden erl utert Zur weiteren Lekt re wird auf 18 verwiesen 4 1 Simulation des Internets Wenn man ein Abbild der Realit t modelliert entsteht meist ein Modell eines sta tischen Sachverhaltes Damit kann man bestimmte Vorg nge in der Realit t be schreiben aber diese k nnen kein Eigenleben entwickeln sondern sich nur auf fest vorgeschriebenen Bahnen bewegen Das Internet ist aber eine sehr lebendige und komplexe Welt Statische Aspekte gibt es in ihr kaum sie besteht aus vielen verschiedenen Einheiten deren Zusam menspiel erst das Internet zu dem macht was es ist Diese Einheiten reichen von den verwendeten Kabeln ber die Protokolle Anwendungen und Betriebssysteme die von den Rechnern verwendet werden um das Internet zu bilden bis hin zu den Routern die den Verkehr im Netz regeln
39. werden als C String angegeben also beispielsweise als 1 1 Enth lt die Argumentliste weniger als zwei Elemente so bricht das Programm die Ausf hrung ab weitere Argumente als die zwei ben tigten werden ignoriert Neben dieser auf einen Zeitschritt beschr nkten Smurf Attacke kann man aber auch die Ausfiihrung des Angriffs durch start beginnen Der Angriff l uft dann wie oben beschrieben nur eben so lange bis stop aufgerufen wird Zu dieser Ausf hrung wird die bei start bergebene Argumentliste in eine dauer hafte umgesetzt die auch bei Aufruf von run ausgelesen werden kann 8 3 4 SynAttackTool Das SynAttackTool dient zum Test des SYN Angriffs und damit der Server Implementierung f r TCP Verbindungen Wird der Befehl exec aufgerufen so startet es eine SYN Attacke die ber 10 Zeitschritte l uft Die SYN Attacke versucht den Port 8 auf Opferseite f r die Attacke zu nutzten Dieses ist der Standardport f r Webserver in unserem Szenario exec setzt auch den Status des Programms auf RUNNING damit das Programm auch in den folgenden Zeit schritten ausgef hrt wird Ein Z hler turns wird auf den Wert gesetzt wie lange das Programm laufen soll hier 10 Solange das SynAttackTool im Zustand RUNNING ist wird es jeden Zeittakt vom Server aufgerufen und f hrt dabei weiter seine Attacke durch Jeden Takt wird dabei der Z hler turns erniedrigt und wenn er O erreicht hat beendet sich das Programm es nimmt den Zu
40. wie die anderen Netzwerke besteht der Angreifer aus einem kompletten Netzwerk also je einem Objekt Net und Router Da wir einen Angriff in ein anderes Netzwerk planen braucht das Heimatnetz des Angreifers nur ein Server Objekt zu verwenden Dieses ist der Basisrechner von dem der Angreifer aus agiert Wir gehen hier davon aus dass der Angreifer sein Netzwerk kontrollieren kann Daher lassen wir seinen Router s mtlichen Netzverkehr in beide Richtungen akzep tieren Die Pakete nach innen interessieren uns momentan nicht und nach auBen wiirde der Angreifer sich nicht selbst behindern wollen Als Routerkonfiguration ergibt sich daher ACCEPT als Default Policy bei einem leeren Regelsatz Um die Konfiguration des Servers des Angreifers m glichst einfach zu halten geben wir ihm nur die fiir den Angriff n tigen Programme Das Tool mit dem er seinen Angriff durchfiihrt ein Objekt vom Typ Smurf und ein Tool namens Ping mit dem wir die Netzwerkverbindung zwischen dem Angreifer und Servern anderer Netzwerke testen k nnen 8 8 Opfer 103 Im Gegensatz zu den Intranet Federates hat der Angreifer keine zyklische Arbeit zu erledigen Er beginnt mit der Installation des Ping und des Smurf Tools Wenn er nun in die nachste Zeit voranschreitet so schickt er mit dem Ping Befehl zu allererst ein Ping Request Paket an das Opfer und an den Rechner des Amplifier Netzes mit der HostID 1 Dann beginnt er seinen Angriff durch Starten des Smurf Be
41. wird ein Modell ben tigt das den Ab lauf von Verteilung und Installation von Tools beschreibt In diesen Kapitel werden die Vorg nge beschrieben die bei Anwendung eines Exploits zur Installation der DoS Tools auf dem Server ablaufen Die Aktivit ten des Angreifers selbst werden erst mit dem Angreifermodell in Kapitel 6 2 dargestellt Hier also das Server Verhalten bei den unterschiedlichen Angriffen Bei einer SYN Attacke werden auf dem Server alle Ressourcen belegt die zu einem TCP Verbindungsaufbau von au en ben tigt werden Andere Kommu nikation wie UDP ICMP oder eine ausgehende TCP Verbindung bleiben uneinge schr nkt Das Modell braucht also eine Beschr nkung wieviele eingehende Verbin dungen es gleichzeitig verwalten kann Das sind die Verbindungen bei denen der Server ein SYN Paket erhalten hat und nun auf das ACK wartet Wird diese Maxi malzahl berschritten so darf das Modell keine weiteren neuen TCP Verbindungen das sind solche mit gesetztem SYN Bit mehr annehmen Ist eine Verbindung nach einer bestimmten Zeit t noch nicht zustande gekom men das ACK Paket steht immer noch aus so wird sie durch Ausl sen eines Ti meOuts beendet die von ihr belegten Ressourcen werden freigegeben Diese Res sourcen werden auch freigegeben wenn eine Verbindung durch Ankunft des ACK Pakets zustande kommt Sobald eine Verbindung ihre Ressourcen wieder freigege ben hat kann eine neue Verbindung angenommen werden Das eben defi
42. 8 IMPLEMENTIERUNG EINES PROTOTYPS als unabh ngiger Federate auf einem anderen Rechner als die brigen Federates zu Pr sentationszwecken benutzt werden 8 7 Angreifer F r den Angreifer gibt es generell zwei verschiedene Ans tze Einerseits kann man den Angreifer ber das Userkonzept auf jedem beliebigen Server der bestehenden Netzwerke agieren lassen andererseits kann man ihn als Erbe eines Servers mit einem Hauptprogramm versehen welches als Arbeit eben einen Angriff durchf hrt Man kann die Aktionen aber auch gezielt vom Anwendungsprogramm aus starten F r den Smurf Angreifer wurde letztere M glichkeit gew hlt Bevor wir nun die Implementierung des Smurf Angreifers beschreiben sei dar auf hingewiesen dass dieser Angreifer f r ein spezielles Angriffsszenario konzi piert wurde Dieses wird sp ter in der Beispielsimulation verwendet Wie schon in 8 2 7 erw hnt muss ein Federate sich zuerst bei einer Federation Execution anmelden Nachdem der Angreifer Federate dies getan hat setzt er sein Zeitverhalten wie alle anderen Netzwerke auch auf zeitbestimmend und zeitabh n sig W hrend die Federates die keine Angreifer sind dann ihr Interesse an Interak tionen wie AngreiferResign AngreiferJoin oder SimulationEnd bekunden wird der Angreifer diese h chstens absenden Da der hier beschriebene Angreifer als alleiniger Angreifer konzipiert wurde meldet er nur die Ver ffentlichung von Si mulationEnd bei der RTI an Ebenso
43. ASSNAHMEN GEGEN D DOS ATTACKEN wird eingehender Verkehr gefiltert Hier sollte also tiberlegt werden welche Art von Paketen man in sein Netz hineinlassen m chte welche internen Rechner er reichbar sein sollen und welche Ports bzw Protokolle dort aus dem Internet ver wendet werden diirfen Ist im Intranet beispielsweise kein Web Server so braucht man keine Pakete mit Zielport 80 Standardport fiir http Dienste in sein Netz zu lassen Und hat man einen Web Server so reicht es im Allgemeinen nur zu ihm Pakete mit Zielport 80 durchzustellen Auch Pakete die auf die Broadcastadresse gesendet werden wie sie z B fiir Smurf Angriffe genutzt werden sind an diesem Punkt sinnvoll ausfilterbar Denn wer auBer Angreifern hat ein reelles Interesse daran diese Adresse von au erhalb des Netzes zu verwenden Empf nger Ausgangsfilter Traffic Kontrolle Eingangsfilter Abbildung 6 Stationen beim Paketversenden Abbildung 6 zeigt beispielhaft den Weg eines Pakets vom Sender ber ver schiedene Router zum Empf nger Hierbei wurde die egress filtering betreibende Router Firewall Kombination als Ausgangsfilter bezeichnet sowie die f r ingress filtering als Eingangsfilter Die Router die auf dem Weg des Pakets dazwischen liegen k nnen auch eine Kontrolle des Paketverkehrs bernehmen Dabei gibt es einmal den Ansatz einfach Pakete die zu einer berlastung des Netzes f hren wegzuwerfen Vereinfacht ausgedr ckt meldet dabei e
44. Angriffs auBer Gefecht gesetzt 9 3 Verhinderter Smurf Angriff Wir verwenden nun fast die gleiche Konfiguration fiir die Simulation noch ein mal Die einzige vorgenommene Anderung ist dass wir dem Router des Amplifier Netzwerks Firewallregeln geben Diese verhindern dass der Router Anfragen auf die Broadcastadresse in das Amplifier Netz hineinl sst Der verwendete Regelsatz sieht folgenderma en aus DENY EE 5 259 ALL DROP Ly Las ALL DROP Foz KE ALL ACCEPT oral de ALL ACCEPT Damit sollen alle Pakete die als Zieladresse die Broadcastadresse des Netzes haben weggeworfen werden Ebenso werden die Pakete die als Absender und Ziel das Netz haben verworfen werden Diese miissen eine falsche Absendeadresse ha ben da sie sonst nicht ber den Router geschickt w rden Der Router l sst auch 9 3 Verhinderter Smurf Angriff 121 keine Pakete mit falscher eigener Netzadresse nach drau en da entweder die Ab sendeadresse oder die Zieladresse die eigene NetzID enthalten muss Alle anderen Pakete d rfen das Netz verlassen oder werden hineingelassen Dass die Firewall damit nicht einfach alle Pakete blockt wird die Simulation zeigen Das Ping Paket mit dem der Angreifer die Verbindung zum Rechner aus dem Amplifier Netzwerk und zum Opfer testet schafft immer noch sowohl Hin als auch R ckweg wie der Trace zeigen wird Auf den Angreifer Trace werden wir nicht noch mal eingehen Dieser nder
45. Beispiele in 42 und 45 12 1 EINLEITUNG treffen Die Schlussfolgerung Keiner will mich absichtlich sch digen daher bin ich in Sicherheit ist unzutreffend Weiterhin geschehen viele Angriffe auch aus Unachtsamkeit oder gar Unwissenheit der eigenen Mitarbeiter und k nnten durch Aufkl rung dieser User verhindert werden Denn der Schaden der durch diese Gruppe verursacht wird ist nicht gering Deshalb ist eine Aufkl rung ber die bestehenden Gefahren notwendig Da statische Pr sentationen zu diesem Thema nicht so wirkungsvoll sind und sich auch nur zu leicht als das ist f r mich aber ganz unzutreffend abhandeln las sen ist eine andere Art der Aufkl rung notwendig Am lehrreichsten w re die Of fenlegung der Sicherheitsm ngel an der betreffenden Infrastruktur selbst Aber dies ist wohl aus Kostengr nden nicht m glich Denn vor m glichem Schaden zu war nen indem man die Produktionssysteme lahmlegt und den Schaden somit wirklich verursacht ist kaum die richtige Methode Die reale Infrastruktur zu duplizieren und dann auf dieser den Schaden zu zeigen scheitert an der kostspieligen Anschaf fung einer Menge an Hardware und meist auch zus tzlicher Lizenzen f r Soft ware Au erdem w rden hierbei wahrscheinlich auch andere Internet Teilnehmer gesch digt oder zumindest behindert Will man n mlich zeigen dass z B eine At tacke auf das interne Firmennetz aus dem Internet m glich ist so w rde man die Angriffspa
46. EN D DOS ATTACKEN Bei read only Filesystemen nutzt man den Effekt dass ein potentieller Angrei fer bei einem Einbruch in den Rechner keine M glichkeit bekommt Dateien ab zuspeichern Dadurch kann er weder neue Programme installieren noch kann er bestehende Konfigurationen oder Daten manipulieren Ganz so einfach ist das aber nicht da man selten ein ganzes System nur auf read only Filesystemen laufen las sen kann Bei Systemen auf denen User arbeiten werden schreibbare Filesysteme gebraucht Jeder andere Rechner auch wenn er nur als Web Server dient braucht die M glichkeit variable Daten wie Prozessinformationen zu speichern Wenn man aber zumindest die statischen Systemdaten die sich bei normalem Arbeitsverhalten nicht ndern sollten auf ein read only Filesystem bringt kann der Angreifer meist schon seine Tools nicht dort unterbringen wo er sie haben m chte Wenn der Angreifer aber das System so kompromittiert hat dass er Administra torrechte hat Kann er auch ein read only Filesystem in ein schreibbares Filesystem umwandeln Ein Dateisystem auf einer Festplatte also read only zu mounten kann fast nur gegen unbeabsichtigte Installation durch W rmer Viren oder automatisierte Tools helfen die dieses nicht vorsehen Um auch den auf dem Server selbst agie renden Angreifern Probleme zu machen sollten die statischen Systemverzeichnisse m glichst auf read only Speichermedien z B CD ROM wirklich vor Ver nderung gesch tzt werde
47. Federates sollten dann AttackerJoin und AttackerResign nicht mehr ausgewertet werden aber alle sollten dann auf den Empfang von SimulationEnd mit ihrer Be endigung reagieren 8 2 Netzwerk Ein Netzwerk auch Intranet besteht aus mindestens einem Server einem Netz und einem Router der gleichzeitig die Firewallfunktion bernimmt Darunter liegt das Anwendungsprogramm das die Zeit verwalten muss und daf r zust ndig ist das Netzwerk zu initialisieren Es muss eine NetzID beschaffen das Netz damit erzeu gen dann den Router erschaffen und ihm das Netz bekannt machen und die Server samt ihrer Konfigurationen erstellen Dieses Anwendungsprogramm kann sowohl interaktiv gestaltet als auch fest vorgegeben werden Interaktiv hei t hierbei man kann die Zahl der Server ver ndern ihre Konfiguration beeinflussen gezielt Server herunterfahren bzw wieder booten Und man kann die Regeln der Firewall w hrend der Simulation ver ndern Zu berlegen w re ob man eine interaktive Firewall erm glicht bei der der User des interaktiven Programms f r jedes Paket von au en oder nach au en entscheiden darf ob es durchgelassen wird oder nicht Hiermit k nnte man die Nachteile bestimmter Filterkonzepte die vielleicht zu statisch ar beiten erkennen ohne aufwendige Firewall Konzepte implementieren zu m ssen Noch einmal aus implementierungstechnischer Sicht beschrieben Ein Intranet besteht aus einem Objekt vom Typ Net und einem vom Typ Router
48. Hinzu kom men noch beliebig viele Objekte vom Typ Server Dieses so gebildete Paket wird 8 2 Netzwerk 67 von einer Anwendung z B dem Simulations Federate Intranet initialisiert und getaktet Jeder Server hat die NetzID seines Netzes Die Simulation des gesamten Internets kann dann aus mehreren solcher Netzwerke bestehen Auf den einzelnen Servern kann man verschiedene Programme installieren so dass sich verschiedene Server unterschiedlich verhalten k nnen Ebenso kann man auch das Verhalten des Routers manipulieren indem man durch Ver ndern des Re gelsatzes bestehend aus Objekten des Typs Rule sein Filterverhalten beeinflusst Dieses Filterverhalten bestimmt ob die zur Kommunikation unter Servern verwen deten Pakete Packet aus dem Netz hinausgelassen werden bzw ob Pakete aus anderen Netzen in dieses Netz hineingelassen werden Der gesamte Aufbau ist in Abb 21 dargestellt Anwendung IntranetFederate Host Server 1 Router Router Packet Packet Program Program A FirewallRules Rule Program Program Syn Attack Tool Webserver Abbildung 21 Aufbau des Intranets Program Portscanner Dieser Aufbau wurde so gew hlt um die Variationsm glichkeit der Netzwerke zu gew hrleisten Man kann beispielsweise einfach den hier beschriebenen und verwendeten Router durch einen anderen ersetzen der eine Firewall mit anderen M
49. Mal ausgef hrt Danach wird der Befehl Smurf ausgefiihrt der eine Meldung fiir jedes abgeschickte Paket ausgibt Wir sehen so 10 Pingpakete die an die Adresse 1 255 Netz 1 Broadcastadresse geschickt werden und dabei 2 1 als Absender angegeben haben KEKE NEW Time 72 0000 000000 FR Router ROUTER packets to handle 0 Sed Bel Sr 3 1 packets to handle 0 Net finished Befehl ping wird ausgef hrt auf 3 1 ping 1 ping 2 1 Befehl smurf wird ausgef hrt auf 3 1 ping to 1 255 Spoofed IP 2 ping to 1 255 Spoofed IP 2 ping to 1 255 Spoofed IP 2 ping to 1 255 Spoofed IP 2 ping to 1 255 Spoofed IP 2 ping to 1 255 Spoofed IP 2 1 ping to 1 255 Spoofed IP 2 1 ping to 1 255 Spoofed IP 2 1 ping to 1 255 Spoofed IP 2 1 ping to 1 255 Spoofed IP 2 1 9 2 Erfolgreicher Smurf Angriff 111 Im n chsten Zeittakt sehen wir dann dass der Router die 2 Ping und die 10 Angriffspakete erhalten hat Der Angreiferrechner sendet weiter noch die Angriffs pakete jetzt aber zeitlich bei der Ausf hrung von doWork New Time 8 0000000000 Router ROUTER packets to handle 12 ea Sie eas 3 1 packets to handle 0 Befehl smurf wird ausgefthrt auf 3 1 ping to 1 255 Spoofed IP 2 to 1 255 Spoofed I to 1 255 Spoofed I to 1 255 Spoofed to 1 255 Spoofed IP pin ping to 1 255 Spoofed IP ping to 1 255 S
50. Netzen ist nicht gro Der Server im Sendenetz generiert hier genauso ein Paket und sendet es an sein Netz Dieses stellt dann fest dass das Paket in ein fremdes Netz geschickt werden soll und reicht es an den Router weiter Der Router tiberpriift ob das Paket das Netz verlassen darf und sendet es dann an das Internet welches durch die RTI repr sentiert wird Der Rou ter initiiert also das Senden des Pakets als HLA Interaktion an die RTI Diese sorgt daf r dass die Subnetze von diesem Paket erfahren Nur das gewiinschte Emp fangsnetz tibernimmt dann die Weiterbearbeitung des Pakets alle anderen Netze ignorieren es Der Router des Empfangsnetzes tiberpriift ob das Paket nach seinen Filterregeln in das interne Netz weitergereicht werden kann und tut dies gegebe nenfalls Das interne Empfangsnetz gibt dann das Paket an den Empfangsserver weiter der mit dem Paket ebenso verfahrt wie der Empfanger es bei rein intranet interner Kommunikation getan hat Das eventuell generierte R ckpaket wird auf dieselbe Art an das Sendenetz geschickt wie vorher das Sendenetz das Paket an das Empfangsnetz gesendet hat 8 2 7 RTI Anbindung des Netzwerks Bisher wurde nur erw hnt dass Server Router Pakete oder Meldungen an die RTI schicken Wie geschieht dies aber genau Und auf welchem Weg erf hrt das Intra net davon dass andere Netze Pakete an es geschickt haben Die Interaktion mit der RTI l uft ber das Anwendungsprogramm Intranet und zwei weitere
51. P 3 1 Verhindern Opfer zu werden 27 gibt es z B Methoden die eine SYN Flood Attacke erschweren oder in vielen F l len verhindern k nnen Aber im Prinzip sind diese tats chlich Ab nderungen des Protokolls die dann das eigentliche Protokoll ersetzen oder sie sind Wrapper die fehleranf llige Teile zu verdecken versuchen Die Au enwelt kommuniziert dann mit dem Wrapper der Fehler abf ngt und nur korrekte Angaben an das eigentliche Protokoll weitergibt Meist haben diese Methoden aber auch einen Nachteil sei es h herer Speicherverbrauch schlechtere Performance oder gar die M glichkeit auch legitime Verbindungen zu behindern Und diese Methoden m ssen oft als Teil des Betriebssystems arbeiten und damit vom Betriebssytemhersteller bereitgestellt werden Ein berblick zu Abwehrma nahmen und ihren Vor und Nachteilen ist u a in 30 zu finden Zu den bekanntesten implementierten Methoden zur Abwehr von SYN Attacken die in einigen Standardbetriebssystemen z B Linux eingesetzt werden k nnen geh ren SYN Cookies oder das random request dropping Eine kurze Erkl rung zu diesen beiden Methoden ist 30 zu entnehmen Wie schon erw hnt sollte man bei der Entwicklung von zuk nftigen Protokol len darauf achten diese sicher zu gestalten Aber was hei t in diesem Zusammen hang sicher Man kann versuchen schon begangene Fehler zu vermeiden aber vorauszusehen was alles als Schwachstelle ausgenutzt werden kann ist f
52. PPED ber stop Bricht die exec Ausf hrung ab setzt turns auf O und setzt den Programm zustand auf STOPPED B 10 5 Programm Webserver Webserver char Konstruktor der ein Webserver Objekt mit einem speziellen Namen er zeugt Der Server wird nicht gesetzt Webserver char Server Konstruktor der ein Webserver Objekt mit einem speziellen Namen er zeugt und dabei auch den Host Server setzt int int int int start list lt char gt Startet den Webserver der damit in den Zustand LISTENING tibergeht Das Programm registriert sich bei dem ihm zugewiesenen Port standardm ig Port 8 kann aber mit setPort ver ndert werden run char Wird aufgerufen wenn ein Paket auf dem Port des Webservers eintrifft Der bergebene Parameter ist der Datenteil des Pakets stop Stoppt den Webserver der sich damit vom Port l st und in den Zustand STOPPED tibergeht setPort Funktion um den Port zu ver ndern auf dem sich der Webserver registriert Standardport ist 8 LITERATUR 145 Literatur 1 2 3 LL 4 kel 5 LL 6 7 8 9 10 11 M Allman and S Ostermann One The Ohio Network Emulator 1997 Jason Barlow and Woody Thrower TFN2K An Analysis 2000 http packetstormsecurity nl distributed TFN2k_Analysis 1 3 txt G Booch J Rumbaugh and I Jacobson Das UML Benutzerhandbuch Ad dison Wesley 1999
53. Port int toPort int proto Protocol action Policies match ipl IP ip2 IP portl int port2 int proto Protocol sendPacket p R ckgabewert ACCEPT sendTo p A ACCEPT p ist hierbei das Paket filter d h Abbildung 30 Das Umfeld des Routers sendPacket p See fiter R ckgabewert DROP A DROP das durch den Router m chte entweder vom Internet in das Intranet oder vom Intranet in das Internet p2 ist ein ICMP Port Unreachable Paket welches an die Absendeadresse von p gesendet wird Policies sendPacket p Be nent Riickgabewert DENY sendTo p2 Abbildung 31 Verhalten des Routers bei verschiedenen Filteraktionen 8 2 Netzwerk 83 Der Filter l uft den Regelsatz von oben nach unten durch wobei die erste tref fende Regel benutzt wird Abb 32 Trifft keine Regel zu so wird die Standardregel Default Policy benutzt Abb 33 Diese kann man mittels set Policy aktion setzen und mit dem Befehl get Policy abfragen filter Paket 1 1 I I policy Liste von Regeln Listenende Abbildung 32 Suchen einer passenden Filterregel erfolgreich filter Paket Liste von Regeln l match Paketdaten Seis match Paketdaten 2 Rule pm pm zm zm mm zm ul match Paketdaten age cect Sal FAULT e 1 Listenende Abbildung 33 Suchen einer passenden Filterregel schl gt fehl Der Regelsa
54. RST Setzt das RST Bit BA Interface Klasse Program void bootstate Diese Funktion setzt bei einem Reboot des Servers den Status des Programms auf den definierten Wert STOPPED void setServer Server host Diese Funktion ist dazu da dem Programm zu sagen auf welchem Server es l uft Denn ein Programm muss auf Funktionen des Servers zur ckgreifen k nnen um z B Pakete verschicken zu k nnen void setVulnerabilities char problem Diese Funktion fiigt die Schwachstelle problem der Liste der Verwundbarkei ten des Programms hinzu void patchVulnerabilities char problem Diese Funktion versucht die tibergebene Schwachstelle aus der Liste der Ver wundbarkeiten zu l schen Ist die Schwachstelle nicht in dem Programm so kann sie nicht gel scht werden es tritt aber kein Fehler auf virtual int exec list lt char gt F r die einmalige Ausf hrung eines Programms Diese Funktion muss aktiv aufgerufen werden es gibt keine Situation in der dies automatisch geschieht virtual int start list lt char gt arg Startet das Programm mit den Argumenten die als Liste bergeben wur den Soll das Programm je nach Funktion in den Zustand RUNNING oder LISTENING versetzen Ba Klasse Router 135 virtual char run Diese Funktion wird vom Server aufgerufen wenn dieser nach einem Time Advance seine Arbeit durchf hrt und er das Programm im Zustand RUNNING vorfindet virtual char run char m
55. Server den das Programm als seinen Host Rechner betrachtet also als den Rechner auf dem es l uft int exec list lt char gt Das Programm wird genau ein ICMP Ping request Paket an jeden Server schicken der in der Argumentliste steht Die IP dieser Server hat als C String in der Liste zu stehen B 10 3 Programm Smurf Smurf char Konstruktor der dem Smurf Programm einen speziellen Namen zuordnet Der Server wird nicht gesetzt dies passiert bei Installation des Programms auf dem Server durch Aufruf von set Server Smurf char Server Ordnet dem Programm neben einem Namen noch einen Server zu Dies ist der Server den das Programm als seinen Host Rechner betrachtet B 10 Programm Klassen 143 int exec list lt char gt Sendet genau einen Zeitschritt lang 10 Pakete an die Adresse die an zwei ter Position in der Argumentliste steht Das erste Listenelement gibt die Absender IP als C String an die beim Versenden der Pakete angegeben wer den soll Weitere Listenelemente werden ignoriert Sind weniger als zwei Elemente in der Liste bricht das Programm die Ausf hrung ab Zur ckgege ben wird dann der Wert 1 bei korrekter Ausf hrung 1 int start list lt char gt Bei dieser Funktion wird dasselbe ausgef hrt wie bei exec aber zus tz lich wird der Programm Zustand auf RUNNING gesetzt Die bergebenen Ar gumente werden in eine Liste bertragen auf die das Programm auch in den folgenden Zeittakten Zugriff
56. Simulation von Bedrohungen und deren Auswirkungen anhand eines Sicherheitsszenarios Diplomarbeit Marion Steiner Prof Dr Claudia Eckert Fachgebiet Sicherheit in der Informationstechnik Fachbereich Informatik Betreuer Kpatcha Bayarou 10 Juni 2003 TECHNISCHE UNIVERSITAT DARMSTADT INHALTSVERZEICHNIS Inhaltsverzeichnis 1 2 Einleitung Denial of Service DoS 2 1 Denial of Service Angriff 2 2 222mm 2 2 Distributed Denial of Service DDoS 2 3 Angriffspunkte f r DoS Attacken 2 4 Beschreibung einiger wichtiger DoS Attacken 24 1 SM e a ss da a 24 2 SYN Flooding 4 dea we ss ae a 2 5 Aufbau eines DDoS Angriffs o 2 5 1 Angriffsnetzwerk 2 222 2 onen 2 5 2 Aufbau eines Master Daemon Angriffsnetzwerks 2 5 3 Bemerkungen zu den Master Systemen 2 5 4 Bemerkungen zu den Daemon Systemen 2 6 DDoS Tools in der brav SE Klassiker ao e a a 2 602 Neuere Method as aaa area Ma nahmen gegen D DoS Attacken 3 1 Verhindern Opfer zu werden 3 2 Schutz vor dem Helferwerden 3 3 Als Routerbetreiber DoS Attacken verhindern DoS Simulation 4 1 Simulation des Internets 4 2 Spielwiese DoS Att cken gt da Saas 2er dr Simulationsumgebung Jle Bestie e A nn aR PE ey S e 5 2 Federation Management 5 3 Zeitverwallung 6 oes o Ho E ob Soe Md ies E 5 4 Datenaustausch z
57. ach Beendigung seiner Aktivit ten die Federation Execution mit dem Aufruf der RTI Funktion resignFederationExecution verlas sen HLA bietet auch Funktionen um eine Federation Execution zu synchronisie ren Dazu kann man in den Federates Synchronisationspunkte setzten an denen der Federate solange wartet bis alle anderen Federates auch diesen Punkt erreicht haben Dies ist z B sinnvoll um bei einer Simulation erst alle Federates ihre Initia lisierung beenden zu lassen bevor das eigentliche Simulieren beginnt Man wiirde deshalb am Ende der Initialisierungsphase jedes Federates einen Synchronisations punkt setzen Erst wenn alle Federates diesen Punkt erreicht haben also wenn jeder Federate fertig initialisiert ist diirfen sie weiterarbeiten 5 3 Zeitverwaltung Wollen mehrere Komponenten an einer Simulation teilnehmen so sollten sie sich auf eine gemeinsame Zeitbasis einigen Bei der verteilten Simulation von Abl u fen ist das notwendig um Abl ufe zwischen den verschiedenen Teilen in korrekter Reihenfolge darstellen zu k nnen Denn wenn die Einzelkomponenten auf unter schiedlichen Rechnern ausgef hrt werden werden die Uhren dieser Rechner un terschiedlich laufen Weiter m ssen Verz gerungen beim Datenaustausch tiber das 42 5 SIMULATIONSUMGEBUNG Netzwerk beriicksichtigt werden die sich zeitlich nicht genau vorherbestimmen las sen Daher bietet HLA eine solche gemeinsame Zeitbasis Die HLA bietet den Federates verschi
58. ackerResign und AttackerJoin erhalten m chte m l l createFederationExecution I joinFederationExecution f subscribelnteractionClass wird d l f r jede ben tigte Interaktion L subscribelnteractionClass aufgerufen also 4x subscribe l IPpacket AttackerResign l AttackerJoin SimulationEnd Arbeitszyklus l L I l I timeAdvanceRequest Der Zyklus aus Arbeit und Warten auf neue Zeit wird so lange wiederholt bis die Simulation beendet wird Kein Simulationsende resignFederationExecution l I I deleteFederationExecution x Abbildung 40 RTI Aufrufe aus der Anwendung Intranet 92 8 IMPLEMENTIERUNG EINES PROTOTYPS Bevor die eigentliche Arbeit des Netzes beginnt setzt das Programm noch sein Timing Verhalten so dass es sowohl zeitbestimmend als auch zeitabh n gig ist Dies geschieht mit den Funktionen enableTimeRegulation und enableTimeConstrained Die Federates die Netzwerke simulieren sollten diese beiden Timing Verhalten besitzen da es sonst Probleme mit der Kommunikation der Federates geben kann Durch die Eigenschaft des Zeitbestimmens miissen alle anderen Federates warten bis auch dieser Federate mit den Aktionen eines Zeitabschnitts fertig ist bevor sie in der Zeit voranschreiten diirfen Dadurch kann kein anderer Federate schon den n chsten Zeitschritt ausf hren solange dieser Federate noch RTI Interaktionen ab sende
59. ackets to handle 0 SHS A 1 2 packets to handle 0 9 2 Erfolgreicher Smurf Angriff 115 Ab Simulationszeit 10 beginnen dann die Rechner des Netzes die Broadcast Pings zu beantworten Rechner 1 1 muss zu Zeit 10 noch zus tzlich den einmaligen Ping des Angreifers bearbeiten New Time 10 0000000000 Router ROUTER packets to handle 10 LAT 1 1 packets to handle 11 ee SS 1 2 packets to handle 10 Zu Simulationszeit 11 ist dann ein sehr gro es Paketaufkommen beim Router des Netzwerks zu beobachten Dieser bearbeitet nun nicht nur die Broadcast Pings des Angreifers sondern auch alle Ping Antworten der Rechner seines Netzes New Time 11 0000000000 Router ROUTER packets to handle 111 Saa Sale 1 1 packets to handle 10 Soe whe 1 2 packets to handle 10 Nachdem auch die Antwort auf den einmaligen Ping des Angreifers das Netz wieder verlassen hat pendelt sich das Paketaufkommen des Routers bei 110 Paketen ein New Time 12 0000000000 Router ROUTER packets to handle 110 Ls sa 1 1 packets to handle 10 SOT 1 2 packets to handle 10 116 9 BEISPIELLAUF EINER DDOS SIMULATION Dieses Aufkommen ndert sich erst zu Simulationszeit 15 wieder Ab dieser Zeit kommen keine weiteren Pakete mehr vom Angreifer zu Zeit 15 und 16 werden deshalb nur noch die 100 Pakete aus dem eigenen Netz verschickt ab Zeit 17 findet keine Kommunikation mehr statt Zu Simu
60. arbeiten muss um die vom Client gew nschte Antwort be reitstellen zu k nnen ist der Aufwand einer Fragestellung des Clients oft deutlich geringer als der Arbeits und damit Ressourcenaufwand der auf der Seite des Servers entsteht 16 2 DENIAL OF SERVICE DOS Beispiele hierfiir sind z B das 3 Wege Handshake bei TCP das nur eine be grenzte Zahl von gleichzeitigen Verbindungsaufbauversuchen erlaubt siehe 2 4 2 oder CGI Anfragen die auf Serverseite deutlich mehr Prozessorkapazit t erfordern als auf Clientseite d h der Client kann mit wenig Arbeit eine gro e Auslastung des Servers erreichen Begrenzte Ressourcen ausnutzen hei t man verwendet Dienste des Servers auf erlaubte Art aber in einem Umfang dass der Server die Flut von Anfragen nicht alle beantworten kann Hierzu muss der Angreifer aber die selbe Bandbreite aufbringen die er am Opfer belegen will Solche Angriffe werden auch als Brute Force Angriffe oder Flooding Attacken bezeichnet 2 4 Beschreibung einiger wichtiger DoS Attacken 2 4 1 Smurf Smurf ist ein Angriff bei dem das Opfer mit einer Flut von Paketen bedacht wird Da diese Pakete in der Regel ICMP Echo Reply Pakete sind ist diese Attacke auch als ICMP Storm bekannt Den Namen Smurf erhielt sie nach dem ersten DoS Tool das sich den im Folgenden beschriebenen Effekt zum Angreifen zunutze machte Der Effekt der bei einem Smurf Angriff ausgenutzt wird ist der dass bei ei nem Ping auf die Broadcastadresse e
61. asse der Daemon Systeme kann der Angreifer durchaus verkraften nicht alle Daemons funk tionsf hig zu bekommen Das Fehlschlagen der Installation kann unter an derem an falschen Executables f r ein System oder dem Fehlschlagen des Kompiliervorganges liegen Die Installation der Master Systeme wird meist per Hand erledigt da die An zahl der Master Systeme zu gering ist um mehrere der Systeme nicht funk tionst chtig zu bekommen Bei Installation per Hand kann der Angreifer besser auf das jeweilige System eingehen Skripte und Programme so anpas sen dass sie beim Betrieb nicht auffallen und vor allem auf Probleme bei der Kompilation der Programme eingehen Um die installierten Programme und Hintert ren des Systems vor dem Entdecktwerden zu sch tzen werden meistens Root Kits verwendet die u a bestimmte Systemfunktionen ersetzen und so die Ausf hrung bestimmter Anwendungen verstecken Nun kann der eigentliche Angriff erfolgen Der Angreifer sendet den An griffsbefehl mit der Adresse des Opfers an seine Master diese geben ihn an die ihnen bekannten Daemon Systeme weiter Die Daemon Rechner greifen nun die ihnen mitgeteilte Adresse das Opfer an Ein Exploit ist ein Programm welches speziell daf r geschrieben ist Sicherheitsl cken auszu nutzen Meist geschieht dies mit der Absicht zu zeigen was die Schwachstelle ist und wie man sie ausnutzen kann 2 5 Aufbau eines DDoS Angriffs 23 Will man dieses Schema auf ein
62. ast un m glich Und schlie lich m ssen wir heute auch die Protokolle verwenden die schon existieren Auf sichere Protokolle zu warten hat also keinen Sinn Die Theorie hat weiterhin Ans tze wie Sicherheitsarchitekturen entwickelt die die M glichkeit besitzen Ressourcen von Verbindungen auf Ende zu Ende Ba sis zu verwalten und ihre Ressourcen zu begrenzen Der Prototyp einer solchen Sicherheitsarchitektur schafft es zuverl ssig illegitime Verbindungen aufzusp ren und zu beenden und kann dabei Qualit tsgarantien einhalten Leider aber ist er an ein Betriebssystem namens Scout gebunden und anscheinend nicht auf g ngige Betriebssysteme zu bertragen 30 2 2 3 In der Praxis sollten Serverbetreiber auf keinen Fall vergessen die offiziellen Patches gegen bekannt gewordene Schwachstellen in Betriebssystem und installier ten Programmen einzuspielen Denn keinesfalls sollte man die Gefahr die von sol chen Sicherheitsl cken ausgeht vernachl ssigen F r diese L cken sind meistens kurz nach ihrem Bekanntwerden schon Exploits also Programme zum Ausnutzen der Schwachstellen im Internet zum Download zu finden Und es gibt leider viele Skript Kiddies die nichts besseres zu tun haben als diese Exploits aus dem Inter net auszuprobieren und damit ohne jegliches Fachwissen Server zu berlasten Der Aufwand so gesamte Systeme zum Absturz zu bringen ist gering Aber herauszu finden warum der Server abgest rzt ist wenn manchmal
63. ch h ufigere Nutzung wiirde das Risiko des Entdecktwerdens gesteigert und damit der Ausfall dieses Helfers wahrscheinlicher 6 5 Netzwerkmodell 55 Start Reboot Neuinstallation saubere Installation offline Shut Down gt Angreifer erlangt Root Rechte Shut Down Reboot bernommen k Sfat Down Installation Installation Master Programe Daemon Programme installierter installierter Master Daemon Shut Down Reboot Abbildung 16 Zustandsdiagramm eines Netzrechners 6 5 Netzwerkmodell Will man das Internet simulieren so reicht es nicht die einzelnen Rechner die daran beteiligt sind zu simulieren Man muss sich ebenso berlegen wie diese Einzelteile zusammenarbeiten wie sie kooperieren und kommunizieren Dazu geh rt die Netzwerkverz gerungen einzuarbeiten Ein Rechner darf bei spielsweise nicht zu der Zeit zu der er seine Anfrage an einen Server stellt auch schon die Antwort des Servers erhalten Wenn wir unser Netzwerk in festen Schrit ten takten w rden so darf nur ein Schritt einer Kommunikation in einen Zeitab schnitt fallen Beispiel Im ersten Schritt sendet der Client seine Anfrage an den Server Im zweiten bearbeitet der Server die Anfrage und generiert eine Antwort Im dritten Schritt kann der Client die Antwort auswerten Veranschaulicht wird dieses Verhalten in Abb 17 die horizontalen gestrichelten Linien symbolisieren dabei den Schritt von einem Zeittakt zum n
64. chsten 56 6 MODELLE ZUR BESCHREIBUNG VON D DOS Server Auswerten der Anfrage Generieren der Antwort Abbildung 17 Ablauf einer Kommunikation 57 7 Konzept f r die Implementierung Um ein gutes Konzept zu entwickeln sollte erst ein Anforderungskatalog erstellt werden den das zu entwickelnde System sp ter weitgehend erfiillen sollte Hier bei gibt es Muss Kriterien die unbedingt enthalten sein m ssen und Soll Kriterien die w nschenswert sind aber nicht notwendig Die Wesentlichen Anforderungen die an den Prototyp einer DoS Simulation gestellt werden sind folgende e Simulation einer DoS Attacke muss m glich sein Ein unbedingt notwendiger Punkt denn man kann von keiner DoS Simulation reden wenn man keinen Angriff damit simulieren kann e Erweiterbarkeit Ein sinnvolles Kriterium das man bei der Entwicklung eines Prototyps beach ten sollte Denn wenn man den Prototyp sp ter noch erweitern kann damit auch andere als die mit ihm zusammen implementierten Attacken dargestellt werden K nnen ist das f r auf dem Prototyp aufbauende Arbeiten hilfreich e einfache Benutzbarkeit Um einfaches Erweitern und Anwenden des Prototyps zu erm glichen soll te kein Spezialwissen erforderlich sein So sollte versucht werden einfache Schnittstellen bereitzustellen mit denen z B HLA Aufrufe versteckt werden k nnen 7 1 Netzwerktopologie Wenn ein Angriff simuliert werden soll gibt es einen Angreifer der
65. cht der Federate die Execution zu beenden deleteFederationExecution und beendet sein Programm Die Execution wird dann beendet wenn der letzte Federate die Ausf hrung verlassen hat und jemand versucht sie zu l schen IntranetFedAmb Die im Folgenden erw hnten Variablen zur Mitteilung von Sachverhalten zwischen dem Hauptprogramm Intranet und dem Federate Ambassador IntranetFedAmb sind global in Intranet definiert und ber export in den 8 2 Netzwerk 93 Intranet FedAmb eingebunden Das ist zugegebenerma en kein guter Stil wur de aber aus Beispielprogrammen zur RTI Anwendung bernommen und aus Man gel an Zeit nicht mehr ge ndert Der IntranetFedAmb erh lt ber die von ihm implementier te Funktion receivelnteraction von der RTI Meldungen ber eingehende Interaktionen aber nur ber die die sein Federate per subscribeInteractionClass bei der RTI abonniert hat also IPpacket SimulationEnd AttackerResign und AttackerJoin Die Interaktion IPpacket steht f r das Eintreffen eines Pakets Der IntranetFedAmb berpr ft ob es die zu ihm geh rige NetzID aufweist Wenn ja so wandelt er die durch die Interaktion empfangenen Daten in ein Objekt vom Typ Packet um und sendet es an den Router wenn nein ist das Paket f r ein anderes Netz und die Interaktion wird nicht weiter ausgewertet Um seine Netz ID herauszufinden kann der IntranetFedAmb die Funktion getNetID seiner Net Klasse benutzen
66. dass das Programm 72 8 IMPLEMENTIERUNG EINES PROTOTYPS Progl an TCP Port 4 gebunden wurde und TCP Port 2 ist an das Programm Prog3 vergeben Mit der Funktion unregisterPort kann diese Bindung wieder gel st werden W hrend es eine Liste von Paketen wir nennen sie hier toHandle gibt die vom Server aktuell behandelt werden werden eingehende Pakete zun chst in eine War teschlange arrived eingereiht bei Aufruf von send da sie erst im n chsten Zeitabschnitt bearbeitet werden d rfen Zu einem Zeitwechsel wird dann die Liste der eingehenden Pakete an die dann leere toHandle Liste angeh ngt w hrend die Eingangsliste arrived selbst geleert wird Sie wartet dann wieder auf neue Pakete Die Pakete der toHandle Liste werden der Reihe nach bearbeitet Ist ein Paket bearbeitet worden so wird es danach aus der Liste entfernt F r jedes bearbeite te Paket wird ein Z hler erh ht der angibt wieviele Pakete zu der jeweiligen Zeit schon bearbeitet wurden Da Server in der Realit t auch nur eine bestimmte maxi male Paketzahl pro Sekunde bearbeiten k nnen wird eine Konstante definiert die f r unsere Serverimplementierung ein solches Maximum angibt F r unser Beispiel ist dieses auf den Wert 99 define MAX_PACKETS 99 gesetzt Durch Ande rung des ttde f i ne Macros in dem Include File server h kann dieser Maximal Wert fiir die Paketverarbeitung ver ndert werden Hat ein Server dann zu einer Zeit die maximalen 99 Pak
67. dem I IDT char Server DT Objekt neben einem Namen noch einen Server zu Dies ist der Server den das Programm als seinen Host Rechner betrachtet also als den Rechner auf dem es l uft Die Referenzliste der Programme ist leer int exec list lt char gt Wird als Parameter eine einelementige Liste mit dem Inhalt update tiberge ben so legt das Programm eine neue Referenzliste mit den auf dem Host Rechner installierten Programmen an Diese Funktion wird als Update Funktion bezeichnet 142 B FUNKTIONSREFERENZ int start list lt char gt Startet das IDT Sollte die Referenz Liste der auf dem Server installierten Programme leer sein so wird sie neu angelegt sonst wird die alte Liste wei terverwendet Der Zustand des Programms wird nach RUNNING gesetzt int run Ruft das IDT auf damit dieses die Referenzliste der Programme mit der aktu ellen Installation vergleicht Ist sie gleich so passiert nichts ist sie ver ndert so sorgt das IDT f r eine Neuinstallation des Servers int stop Stoppt das IDT dieses wechselt in den Zustand STOPPED Die Programm Referenzliste bleibt bestehen B 10 2 Programm Ping Ping char Konstruktor der dem Ping Programm einen speziellen Namen zuordnet Der Server wird nicht gesetzt dies passiert bei Installation des Programms auf dem Server durch Aufruf von setServer Ping char Server Ordnet dem Programm neben einem Namen noch einen Server zu Dies ist der
68. dentliches Paket erhalten Gebe Daten an Programm weiter bei Bedarf generiere Antwortpaket Connect erhalten generiere Connect Antwort Abbildung 26 Ablauf der Bearbeitung eines TCP Pakets 76 8 IMPLEMENTIERUNG EINES PROTOTYPS Jetzt wissen wir wie TCP und UDP Pakete behandelt werden Was passiert aber mit ICMP Paketen Da sie keine Portangaben besitzen k nnen wir sie nicht direkt an ein Programm weiterreichen Au erdem werden z B Ping Requests nicht von einem Programm bearbeitet welches ein Ping Reply generiert sondern dies wird w hrend der allgemeinen Bearbeitung der Pakete erledigt Wir implementieren dies auf folgende Art Wird ein ICMP Ping Request be arbeitet so generiert der Server ein Ping Reply Paket Weiter wird jedes erhal tene ICMP Paket in einer Liste f r ICMP Meldungen abgespeichert So k nnen Programme die sich f r ICMP Meldungen interessieren darauf zugreifen Damit jedes Programm auch auf alle ICMP Meldungen zugreifen kann muss die Bear beitung der Pakete vor der Ausf hrung der Programme stattfinden denn zu jedem Zeitwechsel wird die ICMP Liste wieder gel scht Sie w rde sonst zu gro werden und man br uchte weiteren Aufwand um die Pakete einer Zeit zuzuordnen damit man nicht auf veraltete Pakete zugreift Eine bersicht des Servers mit den bereits erw hnten Listen und Klassen und Fileabh ngigkeiten ist mit Abbildung 27 gegeben Wir haben nun mehrmals den Zeitwechsel erw hnt Beschreiben wir g
69. die Broadcastadresse geblockt wer den Daher taugt das Netz nicht mehr als Verst rker fiir den Angriff Das Gegenteil ist sogar der Fall denn alle Pakete die zur Erzeugung von direkten Angriffspaketen gedacht waren werden verworfen Kein einziges Angriffspaket kommt noch beim Opfer an 124 10 AUSBLICK 10 Ausblick Bei der Anwendung des Prototyps hat sich gezeigt dass durch die Simulation die Gefahren von DoS Attacken und die Schutzmechanismen in ihrer Wirkungsweise gut dargestellt und verfolgt werden k nnen Es ergaben sich bei den Testl ufen aber noch viele weitere Ideen wie der Pro totyp als Anwendungssystem weiterentwickelt werden K nnte siehe hierzu auch 8 10 In Kapitel 1 haben wir z B als Motivation f r diese Arbeit gesagt dass un ter anderem Entscheidungstr ger in Firmen mit einer Simulation ber Gefahren im Internet aufgekl rt werden k nnten F r dieses Ziel m ssen insbesondere die Dar stellungsm glichkeiten erweitert und verfeinert werden Die Entscheidungstr ger m ssen erkennen k nnen dass ihnen ein Abbild ihres eigenen Netzes pr sentiert wird dass die Gefahren auch genau dieses Netz betreffen und dass es wichtige Schutzmechanismen gibt Die Pr sentation vor Entscheidungstr gern muss eine geeignete Auswertung der Netzaktivit t liefern die anschaulich und bersichtlich ist Entscheidungstr ger wollen keine kryptisch anmutenden Tabellen zu Gesicht bekommen und sich die se dann noch von jemand ande
70. e sich im Zustand RUNNING befinden ausgef hrt run wird aufgerufen Genaueres zu den Programmen ihrem Zustand usw siehe 8 2 3 8 2 Netzwerk IP Intranet MyConfig TCP Verbindungsverwaltung Programmliste TCP Ports 77 UDP Ports toHandle Packets arrived Packets ICMP Packets Abbildung 27 Illustration des Servers mit seinen Strukturen Nachdem die Programme ausgef hrt wo rden sind ist die letzte Aufgabe des Servers seinen Zustand an sein Netz und die RTI zu melden Damit ist der Zeit wechsel abgeschlossen Beschreiben wir als N chstes einen Bootvorgang der durch die Funktion boot durchgef hrt wird Hier sorgen wir zun chst daf r dass die Programme des Servers nicht mehr laufen Es wird bei s mtlichen Programmen die Funktion stop aufgerufen und danach boot state Letztere Funktion f hrt die Pro gramme in den definierten Zustand STOPPE D Die Programme sollten zwar schon nicht mehr laufen aber auch hier wollen wir sicher gehen Man kann sich nicht darauf verlassen dass bei Erweiterungen des Prototyps z B um Serverabstiirze der Zustand der Programme richtig gesetzt wird und daher wollen wir bei der Im 78 8 IMPLEMENTIERUNG EINES PROTOTYPS plementierung des Prototyps schon vorbeugen Dann wird daf r gesorgt dass die Ports nicht an Programme gebunden sind Danach werden die Programme gestartet die zur Ausf hrung beim Bootvorgang durch d
71. edem weiteren Aufruf von start wird die bestehende Liste weiterverwendet vor ausgesetzt sie ist nicht leer Denn dann w rde das IDT ungefragt eine neue Liste generieren Bei run wird die Liste der auf dem Server installierten Programme mit der Referenzliste verglichen Tritt eine Abweichung auf so regt das IDT eine Neuin stallation des Servers an Sind die Listen identisch so wird nichts unternommen Um bei einer beabsichtigten Installation eines neuen Programms das Tool nicht Alarm ausl sen zu lassen gibt es eine Update Funktion f r das Tool Der Aufruf von exec mit dem String update als erstes Element der Argumentliste sorgt f r eine Aktualisierung der Referenzliste 8 3 2 Ping Das Ping Programm sendet bei Aufruf durch exec an jede IP die in der Argu mentliste steht ein ICMP Ping request Paket Dieses Programm dient zum Test der Verbindung im Prototyp So z B bei der Simulation in Kapitel 9 wo damit gezeigt wird dass nicht alle Pakete durch die Firewall geblockt werden Weiter dient dieses Programm zum Test der ICMP Implementierung der Server Klasse 96 8 IMPLEMENTIERUNG EINES PROTOTYPS 8 3 3 Smurf Dies ist die Klasse mit der ein Smurf Angriff ausgefiihrt werden kann Sie sendet bei exec einmalig 10 Ping Pakete an die Adresse die an zweiter Position der Argumentliste steht Das erste Listenelement gibt die Adresse des Opfers an also die Absendeadresse die in den Ping Paketen genannt wird Diese Adressen
72. edene M glichkeiten das HLA Zeitmanagement zu verwenden Unter anderem kann jeder Federate bei ihr die Optionen timeRegulation und timeConstrained setzen Diese sagen der RTI wie sie den Federate in das Zeitmanagement einf gen m ssen Ein Federate der die Op tion timeConstrained setzt wird von der RTI nur Meldungen bekommen die eine fortgeschrittenere Simulationszeit besitzen als er selbst Mit der Option timeRegu lation verpflichtet sich der Federate keine Meldungen an die RTI zu schicken die aus seiner Vergangenheit stammen Seine friihsten Meldungen diirfen einen Zeit stempel besitzen der sich aus t fea Look Ahead berechnet wobei t req die aktuelle Zeit des Federates ist und Look Ahead ein konstanter positiver Wert Dieser LookAhead dient dazu dass jeder Federate nur Meldungen erzeugen kann die einen Zeitstempel besitzen der in ihrer Zukunft liegt Den Sonderfall dass dieser LookAhead den Wert 0 annehmen darf vernachl ssigen wir hier Wir verweisen dazu auf 29 fiir uns ist dieser Fall nicht relevant Die gesetzten Zeit Optionen werden von der RTI beriicksichtigt wenn ein Fe derate in der Zeit voranschreiten will Der Federate ruft hierzu die Time Advance Funktion der RTI auf er meldet damit dass er die Arbeit seiner aktuellen Zeit beendet hat und weitergehen m chte Die RTI muss ihm dazu die Erlaubnis geben So kann sie fiir die Federates auf die Einhaltung der gesetzten Zeitoptionen ach ten Sie l sst einen Federa
73. eder erbenden Programm Klasse imple mentiert werden Um dann Sicherheitsl cken durch Patches beheben zu k nnen kann die Funkti on patchVulnerabilities verwendet werden mit der die durch einen be stimmten String identifizierte Schwachstelle behoben wird sofern sie existiert Da bei solchen Patches auch unter Umst nden neue Schwachstellen eingef hrt werden oder im Laufe der Zeit neue Schwachstellen in Programmen entdeckt werden exi stiert noch die Funktion set Vulnerabilities mit der durch Angabe eines Strings als Identifikation einem Programm eine neue Verwundbarkeit hinzugef gt werden kann Die im Rahmen des Prototyps implementierten Klassen werden in Abschnitt 8 3 erl utert 8 2 4 Router Der Router ist f r die Weiterleitung der Pakete aus dem Intranet ins Internet zu st ndig bzw umgekehrt Abb 30 Ebenso hat er die Funktionalit t einer ein fachen Firewall die Pakete nach Source IP Destination IP ZielPort SourcePort 82 8 IMPLEMENTIERUNG EINES PROTOTYPS und Protokoll filtern kann Als Aktion kann die Firewall ein Paket akzeptieren ACCEPT es fallen lassen DROP oder es zur ckweisen wobei dem Absender dann ein ICMP Port unreachable zur ckgesendet wird DENY Siehe hierzu auch die UML Sequenzdiagramme zum Routerverhalten Abb 31 from IP to IP fromPort int toPort int Proto taction Protocol Policies void sendTo packet Packet Rule from IP to IP from
74. eeintr chtigen k nnen Denkt man dass eine Reaktion nicht auf einen Portscan erfolgt sondern auf einen richtigen Angriff so k nnte der Angegriffene leicht zu Gegen DoS Angriffen als Abwehrma nahme greifen wollen Ist nun aber jeder dieser Angriffe mit falscher Absendeadresse versehen so k nnte ein DoS Angriff zu einer lawinenartigen Ausbreitung weiterer Angriffe f hren Den meisten Internet Nutzern ist dies nicht bewusst Neben den verst rkenden Effekten kann man gut die Auswirkung von Schutz ma nahmen Kapitel 3 zeigen Hierbei kann man von bisher rein theoretischen Ans tzen bis hin zu h ufig verwendeten Methoden vieles zeigen F r die Aufkl rung der Entscheidungstr ger in Firmen sind besonders praktisch anwendbare Methoden interessant Ihnen k nnte man die Funktion einer Firewall veranschaulichen Vielleicht w rde dann in einigen Firmen doch die sinnvolle Kon figuration dieser Firewall und der Schutz vor E Mail Sch dlingen mehr Unterst t zung erhalten als das Verlangen der User nach Anwenderfreundlichkeit die oftmals unbeabsichtigt auch Virenfreundlichkeit bedeutet Wenn man den Verantwortlichen die Potentiale der Schutzfunktionen zeigen kann und daneben auch die Risiken die ein potentieller Angriff darstellt verbun den mit den auftretenden Kosten so kann dies bei der Entscheidung f r oder gegen 0ygl http www opennet ru base usersoft 3 txt html 38 4 DOS SIMULATION bestimmte MaBnahmen helfen Man lern
75. eh rt und so ignoriert er das Paket Das Opfer wird also vergeblich auf das ACK warten Abb 3 Sendet der Angreifer nun sehr viele Anfragen so erreicht der Server sein Ma ximum an gleichzeitig verarbeitbaren Verbindungsanfragen und kann keine neuen auch legitimen Verbindungen mehr annehmen bis andere Verbindungen zustande kommen oder durch Erreichen des TimeOuts abgebrochen werden Diese M glich keiten f r neue Verbindungen k nnen aber zum gr ten Teil vom Angreifer gleich wieder durch neue Anfragen belegt werden 2 5 Aufbau eines DDoS Angriffs 19 m E l T i Angreifer Opfer Rechner mit der IP die der Angreifer als Absender angegeben hat Abbildung 3 Connect Versuch mit gespoofter Absendeadresse 2 5 Aufbau eines DDoS Angriffs In Abschnitt 2 2 wurde bereits erw hnt dass der Angreifer bei einer DDoS Attacke auf ein Angriffsnetzwerk zur ckgreift Er nutzt also viele fremde Rechner im Netz werk um eine Verteilung des Angriffs zu erreichen Wie ein solches Netzwerk aussehen kann und wie der Angreifer es erzeugen kann ist Thema der folgenden Abschnitte 2 5 1 Angriffsnetzwerk Es gibt viele M glichkeiten wie ein Angriffsnetzwerk bei einer DDoS Attacke auf gebaut wird Nun werden die zwei gebr uchlichsten Arten beschrieben wie solche Netze aussehen k nnen e Einfaches Netzwerk Hier besteht das Netzwerk aus lauter gleichwertigen Komponenten d h Rech nern die alle die selbe Aufgabe zu erfi
76. ein Opfer at tackiert Im Falle einer verteilten Attacke werden noch Helfer f r den Angriff hinzu gezogen die aus Sicht des Angreifers irgendwo im Internet zu finden sind Hieraus ergibt sich eine m gliche Gliederung nach Angreifer Opfer und Internet Es ist aber nicht sinnvoll ein so komplexes Gebilde wie das Internet in einem Block abzuhan deln Es w re sicherlich m glich aber dadurch gehen viele Aspekte des Internets unn tigerweise verloren Viele Funktionen die Routerbetreiber bei der Abwehr von DoS Angriffen aus ben k nnten w ren nicht oder nur sehr vermindert darstellbar Gerade einfache wichtige Techniken wie das Filtern von offensichtlich gespoof ten Paketen die von den Helfern im Internet abgeschickt w rden lie en sich mit diesem zu einfachen Konzept schlecht darstellen Stellen wir uns deshalb das Internet als Netz von Netzen vor Damit kann man jedem dieser Teilnetze einen Router zuordnen der den Paketverkehr aus dem oder 58 7 KONZEPT F R DIE IMPLEMENTIERUNG in das Netz kontrollieren kann Bei Verwendung von nur einem solchen Teilnetz ist das Konzept so einfach wie das vorherige weil dieses eine Teilnetz das gesamte Internet abdecken m sste aber schon bei Verwendung von zwei Netzen hat man deutlich mehr M glichkeiten Weiterhin braucht man bei diesem Ansatz keine Sonderbehandlung f r die Kom munikation mit Angreifern oder Opfern Diese kann man vorerst wie eigenst ndige Teilnetze behandeln Man kann aber a
77. einfaches Angriffsnetz bertragen so ist der Aufbau noch leichter Da das einfache Netzwerk nur einen Typ von Helfern kennt entf llt Aufz hlungsschritt 4 Schritt 5 und 6 fallen zusammen Weiterhin sollte man sich aber auch bewusst sein dass der Aufbau eines solchen einfachen Netzwerks oftmals gar nicht n tig ist da viele im Internet erreichbare Rechner so konfiguriert sind dass man sie schon als Helfer verwenden kann Ein Beispiel hierf r ist wieder der Smurf Angriff 2 4 1 da viele Router als Standard konfiguration ICMP Broadcasts im Netz weiterleiten und mancher Systemadmini strator diese Einstellung nicht ndert 2 5 3 Bemerkungen zu den Master Systemen Um den Angriffsbefehl weitergeben zu k nnen m ssen die Master eine Liste mit IP Adressen von Daemon Systemen besitzen Dabei braucht aber nicht jeder Ma ster jeden Daemon zu kennen sondern eben nur eine bestimmte Anzahl Daemons f r die er zust ndig ist Dabei k nnen allerdings Daemons in den Listen mehrerer Master auftauchen so dass immer noch fast alle Daemons erreichbar sind selbst wenn ein Master ausf llt Um die Verwaltung einfacher zu gestalten erhalten meist nicht die Master eine Liste von Daemons f r die sie zust ndig sind sondern die Daemons melden sich beim Aktivwerden bei den Mastern zu denen sie geh ren Diese nehmen sie dann in die Liste der aktiven Daemons auf 2 5 4 Bemerkungen zu den Daemon Systemen Daemon Systeme brauchen keine Information
78. eisen zu m ssen Der Angreifer Kann also beliebige falsche Adressen generieren Wenn die Absende adresse zu einem simulierten Server geh rt so kann dieser sich bei Reaktionen des Opfers entsprechend verhalten 104 8 IMPLEMENTIERUNG EINES PROTOTYPS 8 9 Helfer Die Helfer sind einfach vom Angreifer bestimmte Server aus den Teilnetzen Da man nicht wei welche der Server ausgesucht werden m ssen also alle Server die Funktionen beherrschen die ein Helfer braucht um an einen Viewer seine Status informationen weiterzugeben anhand derer der Viewer den Zustand des Servers darstellen kann Dabei erscheint es nicht sinnvoll die Zust nde Clean Ma ster etc wie sie in 6 4 definiert sind im Server direkt zu codieren da bei der Simulation mehrerer Angriffe gleichzeitig so Verwirrung oder gar Fehler auftre ten k nnen Viel eher sollte der Server bestimmte Vorg nge wie z B Installation eines Angriffstools mit einem bestimmten Code des zugeh rigen Angreifers als RTI Interaktion an den Viewer schicken der diese dann auswertet Aus diesem Grund senden die Server Statusmeldungen wenn sie neu installiert werden Angriffstools sollten wenn sie gestartet oder gestoppt werden jeweils eine Meldung Tool aktiviert bzw Tool gestoppt mit dem Code ihres Angreifers und ihrer eigenen Funktion Master Daemon an die RTI senden 8 10 Schwachpunkte des Prototyps Bei der Implementierung des Prototyps wurden verschiedene Prob
79. eispielsweise ei ne Komponente Flugzeug haben die das Flugzeug simuliert Eine andere w re f r die Erzeugung der Umweltdaten wie Windgeschwindigkeiten Wetterlage etc zu st ndig Wir nennen sie hier Wetter Um nun z B die Variation der Flugzeit in Abh ngigkeit von der Wetterlage zu bestimmen braucht man den Quelltext Flug zeug nicht zu ver ndern Flugzeug erh lt nur die Angaben ber die Umwelt die Wetter ihm liefert Man kann dann einen Wettererzeuger Wetter2 schreiben der alternative Wetterdaten liefert Dann kann man diese Wetterdaten auch f r einen zweiten Flugzeugtyp Flugzeug2 verwenden um f r ihn auch die unterschiedlichen Flugdaten zu ermitteln Damit diese Komponenten sinnvoll kooperieren k nnen braucht man einige Hilfsmittel Es wird eine gemeinsame Zeitbasis ben tigt die Simulationsteile m s sen miteinander kommunizieren und Daten austauschen k nnen Unser Prototyp wird f r diese Funktionen auf die High Level Architecture HLA zur ckgreifen die die angesprochenen Hilfsmittel bereitstellt HLA bietet noch viel mehr als wir hier verwenden werden Deshalb werden wir uns in der fol genden Beschreibung auf die wichtigsten Aspekte beschr nken F r eine genauere Beschreibung von HLA wird auf 29 verwiesen Gekl rt werden zun chst die Begriffe die f r den Umgang mit der HLA wich tig sind Danach werden die n tigen Mechanismen beschrieben sowie kurz die Funktionen erkl rt die in unserem Prototyp Verwe
80. em 19 Abs 6 DPO AT Hiermit versichere ich die vorliegende Diplomarbeit ohne Hilfe Dritter nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben Alle Stellen die aus den Quellen entnommen wurden sind als solche kenntlich gemacht worden Diese Arbeit hat in gleicher oder hnlicher Form noch keiner Pr fungsbeh rde vorgele gen Darmstadt den 10 Juni 2003 10 ERKLARUNG 11 1 Einleitung Dezember 2000 Ein Darmst dter GroBunternehmen das nicht in der Compu terbranche t tig ist wird Opfer einer Denial of Service DoS Attacke Es wird zwar kein direkter Schaden angerichtet aber durch zus tzliche Arbeitsstunden der Systemadministratoren entstehen Kosten von rund 10 000 DM 43 Januar 2001 Eine DoS Attacke gegen die Router von Microsoft schr nkt das Webangebot des Softwareunternehmens besonders in den Bereichen microsoft com und msn com ein 44 April 2002 Ein schottischer Internet Service Provider ISP wird durch einen DoS Angriff beeintr chtigt Teilweise werden zwei 45 Mbps Leitungen komplett ausgenutzt um Angriffspakete zu transportieren Durch Installation eines Paketfil ters kann der Angriff zwar beendet werden aber erst nachdem einige Kunden des Anbieters bis zu 12 Stunden die ihnen zustehenden Dienste nicht nutzen konnten Juli 2002 Die Webseite der Recording Industry Association of America wird ein ganzes Wochenende lang durch eine DoS Attacke blockiert Oktober 2002 7
81. en ber andere an dem Angriff betei ligte Systeme Sie ben tigen lediglich die Adresse des Opfers das es anzugreifen gilt Diese kann bei vielen Tools als Argument des Angriffsbefehls an den Daemon bermittelt werden Wenn allerdings wie in 2 5 3 beschrieben sich die Daemons bei ihren Mastern aktiv melden dann muss jeder Daemon eine Liste mit IP Adressen von mindestens einem Master besitzen 24 2 DENIAL OF SERVICE DOS 2 6 DDoS Tools in der Praxis Es gibt viele DDoS Tools die auf verschiedene Weise funktionieren Um wirksa me Gegenma nahmen entwickeln zu k nnen ist es n tig die Tools zu analysieren und ihre Funktionsweise zu verstehen So kann man unter anderem die Chancen erh hen die Tools nach ihrer Installation zu erkennen indem man ihre Kommuni kationssignaturen im Netzwerkverkehr aufsp rt Es folgt deshalb eine kurze Einf hrung in die bekannten Tools Hierbei wird vor allem Wert auf die Kommunikationseigenschaften gelegt Die Aufstellung be ginnt mit den Klassikern die sich im Grunde alle sehr hnlich sind Im Laufe der Zeit wurden immer neue Tools geschrieben die Verbesserungen gegen ber dem Vorg nger einf hrten die besseren Schutz vor Entdeckung bringen sollen oder die M glichkeiten des Tools erweitern Nach diesen klassischen Tools wird auf neuere Formen eingegangen die nie einen solchen Bekanntheitsgrad erreicht haben wie die Klassiker Hierzu werden vor allem die neuen Kommunikationsarten zwischen Maste
82. en Netzaktivi t ten braucht er nichts zu wissen Er braucht weder zu wissen wie viele 8 6 Viewer 101 Angriffe gleichzeitig erfolgen noch welche Aktion er welchem Angriff zu ordnen muss Er muss nur entscheiden k nnen ob eine Aktion zu seinem Angriff geh rt oder nicht 2 Um entscheiden zu k nnen ob eine Aktion zum Angriff seines Angreifers ge h rt muss der Viewer eine Art von Erkennungszeichen mit seinem Angreifer ausmachen mit dem bestimmte Aktionen gekennzeichnet werden Wiirde man eigenst ndige Viewer einsetzen aber nicht einen sondern so viele wie Angreifer vorhanden sind so w ren die Aushandlung der Zusammengeh rig keit zwischen Viewer und Angreifer und die Aushandlung des Erkennungs zeichens schwierig Hierfiir ware ein extra Federate notwendig der eine Ma nagementfunktion zur Kontrolle dieser Zuordnungen ausiibt um sicher zu stellen dass jeder Viewer genau einem Angreifer zugeordnet wird 3 Es stellt sich die Frage ob eine Simulation die dem Viewer zeitlich gese hen vorauseilt im Fall einer DoS Attacke tiberhaupt sinnvoll ist Denn bei dieser Simulation ist nicht das Ergebnis des Simulationslaufes das Wichtige sondern der Weg wie dieses Ziel erreicht wird Deshalb ist der Viewer Teil des Angreifer Federates So kann man den Status des Angriffs dieses Angreifers genau verfolgen Dabei ist der Viewer eine Klasse die vom Angreifer Federate benutzt wird Der Viewer zeigt einen Angreifer Status der die
83. en Zu stand online oder offline und kann so die Pakete ordnungsgem zustellen Wenn ein Server nicht existiert so kann es ein ICMP Host unreachable Paket zu r cksenden ansonsten wird das Paket beim Empf nger abgegeben bzw beim Rou ter wenn der Bestimmungsort au erhalb des eigenen Netzes ist F r die zentrale Steuerung der Zeitverwaltung ist die Funktion newTime time zust ndig mit der die Taktung des Intranets zentral ausge f hrt werden sollte Dadurch wird sichergestellt dass auch wirklich alle Server und Router des Netzwerks den Time Advance mitbekommen und damit unter anderem alle Pakete die im Zeitschritt vorher innerhalb des Intranets verschickt wurden auch bearbeitet werden und die Pakete die in dieser Runde verschickt werden auch wirklich erst im n chsten Zeitschritt bearbeitet werden und nicht zu fr h Weiterhin wird auf diesem Wege auch sichergestellt dass alle auf den Servern laufenden Programme ihren Aufgaben nachkommen k nnen Siehe hierzu die Beschreibung der doWork Funktion der Klasse Server 86 8 IMPLEMENTIERUNG EINES PROTOTYPS Dazu ruft das Netz zuerst von allen Servern die Funktion newTime auf Da bei regeln die Server ihre Paket Queues Der Router darf dann bei Aufruf seiner newTime Funktion neben der Umorganisation seiner Paket Queues auch schon seine Pakete verschicken Da alle sonst am Netz Beteiligten ihre Paket Listen schon aktualisiert haben kann keine Durchmischung neuer
84. en k nnen geht das Paket das von der Firewall akzeptiert wurde tats chlich nur an Rechner 1 1 New Time 10 0000000000 ROUGE ROUTER packets to handle 10 FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped les A 1 1 packets to handle 1 Bee ie Ses 1 2 packets to handle 0 Das Antwortpaket auf den korrekten Ping verl sst das Netzwerk unbehindert Von den 11 Paketen die der Router bearbeiten muss werden nur 10 blockiert New Time 11 0000000000 ROUTE ROUTER packets to handle 11 FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped 9 3 Verhinderter Smurf Angriff 123 aoe Zack as 1 1 packets to handle 0 Sao 142 1 2 packets to handle 0 Wir k nnen also sehen dass alle Pings auf
85. enauer wie dieser auf dem Server abl uft Zuerst wird durch das Netz die Serverfunktion newTime aufgerufen Diese verschiebt wie schon erw hnt den Inhalt der Li ste f r ankommende Pakete in die Liste der zu bearbeitenden Pakete Dadurch wird die Liste der ankommenden Pakete leer Als N chstes wird nun die Updatefunkti on vonTcon aufgerufen die die Verbindungsstatistik aktualisiert Dann wird die ICMP Liste geleert Der n chste Schritt des Zeitwechsels der beim Server ankommt ist die Aus f hrung der Funktion doWork Hier arbeitet der Server je nach seinem Zustand unterschiedlich Ist er offline so l scht er die Liste der zu bearbeitenden Pake te Diese sollte zwar schon leer sein aber wir wollen Fehler ausschlie en Dann wird eine Variable namens st il1Down berpr ft Diese wird z B gesetzt wenn eine Neuinstallation durchgef hrt wird und wir f r diese eine bestimmte Zeit veran schlagen nach der der Server wieder erreichbar wird also bootet Ist diese Variable gr er 0 so wird sie erniedrigt der Server bleibt offline Ist sie auf 0 so wird der Server gebootet er ist wieder online Nun folgen die Aktionen die ein Server der online ist durchf hrt dazu geh rt auch ein Server der gerade eben wieder gebootet wurde Der Server behandelt alle Pakete die in der toHandle Liste stehen bis zur Maximalzahl siehe oben Danach wird die Liste der installierten Programme durchgegangen Dort werden die Programme di
86. erbindung n tig das so genannte 3 Wege Handshake Abb 2 Der hier beschriebene Angriff nutzt 18 2 DENIAL OF SERVICE DOS m S ch SYN I SYN ACK ACK l l l l Client Server Abbildung 2 TCP Verbindungsaufbau Vollst ndiger 3 Wege Handshake genau dieses Handshake aus um dem Server die M glichkeit zu nehmen weitere Verbindungen von au en einzugehen Das 3 Wege Handshake funktioniert im Groben so Der Client beginnt mit dem Verbindungsaufbau indem er dem Server ein SYN Paket sendet Dieses wird dann vom Server mit einem SYN ACK Paket beantwortet Die Verbindung ist aber erst dann hergestellt wenn der Client das SYN ACK noch mit einem ACK Paket be st tigt Da in einem Netzwerk Verz gerungen auftreten k nnen muss der Server sich jede durch ein SYN Paket initialisierte Verbindungsanfrage solange merken bis der Client den Verbindungsaufbau durch sein ACK Paket best tigt Falls dies nicht geschieht oder zu lange dauert wird der Verbindungsaufbau durch Erreichen eines TimeOuts abgebrochen Wenn nun also ein Angreifer einen Server mit TCP Verbindungsanfragen ber h uft dabei aber z B eine falsche Absendeadresse angibt so kann kein Verbin dungsaufbau erfolgen Da das SYN Paket gef lscht ist sendet der Opfer Server ein SYN ACK an den Rechner der die Adresse besitzt von der das SYN Paket angeb lich kam Dieser kann mit dem SYN ACK aber nichts anfangen da es zu keinem seiner Verbindungaufbauversuche g
87. erbindungen zu welchem Zeitpunkt wieder frei werden und ob noch Verbindungen angenommen werden k nnen void reset Setzt die Anzahl der belegten Verbindungen auf 0 um z B bei einem Reboot nicht noch alte Verbindungen zu bernehmen B 10 Programm Klassen 141 int getAnz int inc Gibt die Anzahl der belegten Verbindungsressourcen an F gt einen neuen Verbindungsaufbauversuch hinzu int con_possible Liefert true 1 zur ck falls noch Verbindungen aufgebaut werden k nnen sonst false 0 void update RTIfedTime time Funktion die nach jedem TimeAdvance aufgerufen werden muss Sie l scht die Verbindungsversuche die in einen TimeOut laufen und gibt damit ihre Ressourcen wieder frei BIO Programm Klassen Bei den Programmklassen werden nur die neu implementierten Funktionen be schrieben Die Funktionen die schon in Program behandelt wurden werden nicht noch einmal beschrieben Alle in einer Programm Klasse nicht erw hnten Funktio nen die in Program als virtual deklariert sind haben keine Funktion Sie geben im Allgemeinen eine Fehlermeldung aus wenn sie aufgerufen werden B 10 1 Programm IDT IDT char Konstruktor der ein Objekt vom Typ IDT mit einem speziellen Namen er zeugt Der Server wird nicht gesetzt dies passiert bei Installation des Pro gramms auf dem Server durch Aufruf von set Server Die Referenzliste des IDTs ist leer Ordnet
88. eren dass die berz hligen Pakete nicht beim Server ankommen wird nach Erreichen der maximalen Paketzahl der Rest der Paket Queue weggeworfen Listenoperation clear Der Server wird dann gleichzeitig in den Zustand OUTOFORDER ver setzt Beim Zeitwechsel wird der Zahler wieder auf 0 gesetzt Der Server wird in den Zustand ONLINE versetzt und kann wieder Pakete annehmen Um diesen Angriff durchzuf hren wurde das Tool Smurf implementiert Die ses dient dem Angreifer zur Durchf hrung einer Smurf Attacke Das Opfer braucht keine Programme installiert zu haben damit der Angriff gelingen kann 100 8 IMPLEMENTIERUNG EINES PROTOTYPS 8 5 Gegenma nahmen Der Prototyp bietet drei Gegenma nahmen an Die Konfiguration einer Firewall mit Paketfilter das Simulieren eines read only Filesystems auf den Servern und die Installation eines einfachen Intrusion Detection Tools IDT Die Implementierung des Paketfilters ist schon im Abschnitt 8 2 4 ber den Rou ter erkl rt worden Diese Firewall ist noch sehr einfach aber man kann mit ihr schon offensichtlich gespoofte Pakete aus dem Netzverkehr herausfiltern siehe z B Re gelsatz des Beispiellaufs in 9 3 Das read only Filesystem wird mit Hilfe eines Flags in der Klasse Server im plementiert Dieses Flag muss vor jedem Installieren eines Programms berpr ft werden Gibt dieses Flag an dass der Server ein nicht schreibbares Filesystem be sitzt schl gt die Installation fehl Sonst f
89. erhalten falls jemand sie ver ffentlicht hat Objekte sind dabei dauerhaft angelegte Objekte bei denen die Federates ein zelne Attribute ver ndern k nnen und dann auch nur ber die Ver nderungen der Attribute informiert werden die sie interessieren Es darf immer nur ein Federate zu jeder Zeit die Erlaubnis besitzen ein Attribut zu ver ndern oder gar das gesam te Objekt zu l schen F r unseren Prototyp benutzen wir keine Objekte deshalb erkl ren wir sie hier nicht weiter Interaktionen sind immer eine Einheit Entweder m chte ein Federate eine In teraktion erhalten oder nicht Dabei kann auch eine Interaktion mehrere Parameter besitzen Mit der RTI Funktion receivelnteraction informiert man die RTI ber die Interaktions Klassen die man von ihr gemeldet bekommen m chte mit publish Interaction gibt man die Interaktions Klassen bekannt die man selbst erzeugt Alle Interaktionen und Objekte die in einer Simulation verwendet werden k n nen m ssen durch das FOM definiert werden Die hierzu definierten Klassen m s sen dabei immer von der Klasse InteractionRoot als Interaktion bzw ObjectRoot als Objekt oder einer Unterklasse dieser Root Klassen abstammen In Abbildung 8 ist die Definition der Interaktionen des Prototyps dargestellt Hierbei gibt es einmal die f r die Simulation speziell entwickelten Interaktionen aber auch schon von der RTI definierte Diese sind n tig damit die RTI auch an dere Events wie beisp
90. ese Funktionalit t bietet unsere Klasse IP Der String 2 steht hier f r alle IP Adressen mit der NetzID 2 Ebenso sind auch Kombi nationen m glich wie f r alle IP Adressen bzw 2 f r die HostID 2 aus allen Teilnetzen Mit den Funktionen isAnyNet undisAnyHost kann ab gefragt werden ob Netz bzw HostID auf einem bestimmten Wert n stehen oder unbestimmt sind CS Um eine IP mit entsprechendem Platzhalter zu erzeu gen kann auch wieder ein String verwendet werden indem als Platzhalter f r den unbelegten Wert verwendet wird oder man ruft den Konstruktor von IP nicht mit zwei Integern sondern mit dem char an der entsprechenden Stelle auf Die genaue Syntax der Konstruktoren ist der Funktionsreferenz zu entnehmen Kapitel B 1 8 2 2 Klasse der Server Die wichtigste Klasse in einem Netzwerk ist die Klasse der Server Bevor wir uns mit den genauen Funktionen dieser Klasse befassen erl utern wir zun chst ihren 70 8 IMPLEMENTIERUNG EINES PROTOTYPS Aufbau siehe hierzu auch Abb 22 sowie Funktionen mit denen dieser Aufbau manipuliert werden kann Ein Server besitzt als Identifikation nach au en eine IP Mit dieser ist er beim Netz bekannt mit dieser markiert er legitime Pakete damit der Absender erkennbar ist Um Pakete verschicken zu k nnen muss jeder Server eine Referenz auf sein Netz besitzen denn iiber dieses Netz wird er seine Pakete verschicken Auch wird er die
91. esg Funktion die bei Eintreffen eines Pakets auf einem Port auf dem das Pro gramm l uft aufgerufen wird virtual char stop Soll die Ausf hrung des Programms beenden und es in den Zustand STOPPED versetzen virtual void setVulnerabilities Mit dieser Funktion sollen die Standard Verwundbarkeiten des Programms festgelegt werden B 5 Klasse Router Router Net Erzeugt einen Router der defaultm ig allen Paketverkehr weiterleitet Router Net char Erzeugt einen Router mit dem Regelsatz der in dem File das als zweites Argument angegeben wird steht void newTime Gibt dem Router zu erkennen dass in der Zeit vorangeschritten wurde und er die neu eingetroffenen Pakete bearbeiten muss Policies getPolicy Gibt die Default Policy des Routers zuriick int setPolicy Policies Setzt die Default Regel auf den bergebenen Wert int loadRuleset char file L dt einen neuen Regelsatz aus dem angegebenen File ein Der alte Regelsatz wird komplett ersetzt int clearRuleset L scht alle Regeln des Regelsatzes Es wird nun immer die Default Policy verwendet bis neue Regeln eingegeben werden int listRuleset Gibt den Regelsatz mit Nummerierung der Regeln auf die Standardausgabe 136 int int int int int B FUNKTIONSREFERENZ dumpRuleset Gibt den aktuellen Regelsatz so auf der Standardausgabe aus wie er in einem Regelsatzfile zum Einlesen stehen miisste
92. et verwendeten Protokolle anzulehnen d h Unterscheidungen zwischen TCP UDP und ICMP zu machen Gerade wenn man Firewalls simulieren m chte sollte der Unterschied der Protokolle zum Tragen kommen k nnen Ebenso ist es schwierig eine TCP SYN Attacke ohne eine Repr sentierung des TCP Protokolls zu erm glichen Die n chste Frage die sich stellt ist wie diese Protokolle dargestellt werden sollen Der Ansatz die Kommunikation wie im realen Internet in Pakete einer ma ximalen Gr e zu unterteilen wird schnell verworfen da er gro e Probleme bei der zeitlichen Verwaltung der Simulation aufwirft und zu aufwendig erscheint um ihn hier umzusetzen Also wird pro Nachrichtenblock ein Paket verwendet 7 4 Konzept eines Servers 61 Damit ist die Konzeption fiir ICMP und UDP beendet Fiir die TCP Verbindung wurde zun chst der Ansatz verfolgt wie in der realen Welt die Pakete immer mit Riickpaketen zu best tigen Der Verbindungsaufbau Handshake k nnte so auch mit drei Paketen nachgebildet werden Die TCP Flags der Pakete der simulierten Verbindung w ren so wie beim realen TCP zu setzen Dieser Ansatz wurde wieder verworfen da er sich als nicht praktikabel heraus stellte Das Timing des Paketverkehrs war nicht mit dem der restlichen Simulation vereinbar eine TCP Verbindung w re so im Verh ltnis viel zu langsam geworden Aber auch ein zweiter Grund sprach gegen diesen Ansatz Er lief auf einen grofen Implementierungsaufwand hinaus weil
93. ete bearbeitet so darf er keine weiteren mehr bearbeiten Er ist berlastet und entleert die toHandle Liste als h tte er die weiteren Pakete gar nicht mehr erhalten Genaueres hierzu kann im Abschnitt 8 4 ber die Implementierung der Angriffe nachgelesen werden Bei UDP wird bei der Bearbeitung der Inhalt der Pakete an das auf dem Port laufende Programm bergeben Aufruf von run mit den Daten als Parameter Erzeugt dieser Programmlauf einen nicht leeren String als R ckgabe so wird die ser String in ein Antwortpaket gepackt und an den Sender des bearbeiteten Pa kets zur ckgeschickt L uft auf dem Port kein Programm so wird ein ICMP Port unreachable Paket generiert und an den Sender zur ckgeschickt Bei UDP ist die Behandlung des Pakets damit abgeschlossen bei TCP ist dies nicht ganz so einfach Hier muss eine Datenstruktur eingef hrt werden mit der wir SYN Attacken bearbeiten k nnen und mit der wir vor dem bermitteln der Daten an ein Programm berpr fen m ssen ob diese Aktion berhaupt durchgef hrt wer den darf Ebenso muss anhand der gesetzten TCP Flags ermittelt werden welchem Zweck das Paket dient und nur bei einer M glichkeit wird der Paketinhalt an ein Programm bergeben Erkl ren wir nun die f r die Bearbeitung der TCP Verbindungsanfragen existie rende Datenstruktur Diese verwaltet die Anzahl der Anfragen f r die der TimeOut im gleichen Zeitschritt erfolgen wird zusammen mit der Zeit zu der sie in den
94. fehls als Service mit den Parametern fiir das Opfer und das Netz welches gepingt werden soll Diesen Befehl l sst der Angreifer nun fiir 5 Zeitschritte laufen Dabei werden pro Zeit schritt 10 Ping Pakete mit der Absendeadresse des Opfers an die Broadcast Adresse des Amplifier Netzes gesendet Nach diesen 5 Zeiteinheiten stoppt der Angreifer den Angriff durch Stoppen des Smurf Tools Dann wartet er noch einmal 5 Zeiteinheiten ab bis er der Simula tion durch Senden der SimulationEnd Interaktion das Ende signalisiert und dann selbst seine Ausf hrung beendet Auch er meldet sich hierzu von der Federation Execution ab und versucht dann die Execution zu beenden Der Angreifer wartet deshalb noch eine Zeit lang bevor er das Simulationsende propagiert damit man in der Simulation auch noch sehen kann ob sich das Opfer nach Beendigung des Angriffs wieder erholt 8 8 Opfer Ein spezielles Opfer wird nicht implementiert Wie schon in der Konzeption erw hnt wird hier ein normales Subnetz die Funktion des Opfers bernehmen Dazu wurde jedem Server die Funktionalit t gegeben seinen Zustand ONLINE OFFLINE bzw OUTOFORDER an die RTI zu senden Dadurch dass jeder Server als Opfer agieren kann haben die Szenarien den Vorteil dass auch Reaktionen auf den Angriff wie z B ein Gegenangriff auf den vermeintlichen Angreifer und ihre Auswirkungen auf die Erreichbarkeit des Ser vers darstellbar sind ohne dazu noch zus tzliche Opfer ausw
95. fen zu k nnen bietet IP TEGES ER die Funktionen host ID und net ID Zip unsigned int die das Gew nschte zuriickliefern Um IP net int host int S g S us IP id char zwei Adressen einfach vergleichen zu k n An nen gibt es die Funktion isEqual IP SSe re ee int hosts EE die tiberpriift ob zwei IP Adressen identisch setAny mask int void S isAnyNet int sind Identisch hei t hierbei NetzID und isAnyHost int gt 3 E a g t isEqual other IP int HostID stimmen jeweils berein entweder sind sie bei beiden IPs unbestimmt Darge stellt wird dies mit oder sie sind auf denselben Wert festgelegt Anlegen kann man eine IP Adresse ber die Angabe von Netz und HostID oder ber die Anga be der IP Adresse als String Beispiel 1 2 Diese Schreibweise der IP Adresse die auch zum Ausgeben und Einlesen verwendet wird ist der in wirklichen Netz konfigurationen angepasst um einfacher verst ndlich zu sein Der gro e Unter schied ist nur dass reale IP Adressen aus 4 8Bit Bl cken bestehen w hrend wir uns auf 2 8Bit Bl cke beschr nken Das vereinfacht den Verwaltungsaufwand und scheint im Rahmen der Simulation vom Adressbereich her auszureichen Sollte die ser Adressbereich irgendwann nicht ausreichen kann er durch die Ver nderung der Klasse IP erweitert werden F r die Implementierung z B einer Firewall ist es wichtig auch IP Bereiche angeben zu k nnen Auch di
96. grammlauf einen nicht leeren String als Riickgabe so wird dieser String in ein Antwortpaket gepackt und an den Sender des bearbeiteten Pakets zuriickgeschickt L uft auf dem Port kein Programm so wird ein ICMP Port unreachable Paket generiert und an den Sender zuriickgeschickt 8 2 3 Programme Programme sind der aktive Teil eines Servers W hrend der Server nur Kommuni kationspakete erzeugen kann um einen unbelegten Port zu melden sind die Pro gramme in der Lage beliebig Pakete zur Kommunikation mit anderen Servern zu erstellen Dies miissen sie k nnen wollen sie z B die Funktionalit t eines Port scanners oder eines Tools fiir SYN Attacken implementieren Nat rlich k nnen die Programme auch rein serverinterne Aufgaben abarbeiten wie z B ein Intrusion Detection Tool welches berwacht ob sich die Konfiguration des Servers ver n dert hat und wenn dies der Fall ist eine Neuinstallation anst t Aber es sind auch hier rein reaktive Aufgaben wie z B bei einem Webserver m glich P enum Server rogram ServiceStates sendTo STOPPED connect RUNNING registerPort LISTENING unregisterPort Webserver Abbildung 28 Das Umfeld von Programmen Die Programme m ssen sich immer in einem definierten Zustand ServiceStates befinden M gliche Zust nde sind hier STOPPED RUNNING oder LISTENING STOPPED bedeutet das Programm ist nicht am Arbeiten es wird weder ausgef hrt noch ist es
97. gsans tze 1 Will man gleiche NetzIDs verhindern w rde es sich anbieten einen Federa te zu verwenden der Verwaltungsaufgaben erledigt Zu diesen k nnte dann auch die Verwaltung von NetzIDs geh ren Diese Verwaltung k nnte folgen derma en aussehen Wird ein Intranet Federate erzeugt so kann er bei dem Management Federate nach einer freien NetzID fragen die er dann verwen det Oder er kann einen Wunsch nach einer bestimmten NetzID u ern Ist diese frei so bekommt er sie ansonsten kann er eine andere ID zugeordnet bekommen oder seine Ausf hrung abbrechen 106 8 IMPLEMENTIERUNG EINES PROTOTYPS 2 Will man gleiche NetzIDs bewusst zulassen so m sste man dem Viewer ei ne andere M glichkeit geben die erhaltenen Meldungen zu ordnen Jedes Netzwerk br uchte eine eindeutige Identifizierung neben der eben nicht ein deutigen NetzID 8 10 3 Keine Festlegung von maximaler Bandbreite Jeder Server hat eine festgelegte maximale Anzahl von Paketen die er pro Zeitab schnitt empfangen und auch bearbeiten kann Senden kann ein Server in diesem Zeitabschnitt bisher aber eine beliebige Anzahl von Paketen Dieses Verhalten ist nicht realistisch Bei der Implementierung der Programme und des Angreifers muss daher darauf geachtet werden sinnvolles Verhalten zu konfigurieren Zu w nschen w re deshalb eine Beschr nkung der Sendebandbreite bei der der Server eine bestimmte Obergrenze bei der Paketgenerierung nicht berschrei ten kann
98. hat Der Schleifenz hler wird auf einen Start wert gesetzt char run Das Programm f hrt einmal das aus was inexec ausgef hrt wird benutzt aber die Argumente aus der dauerhaften Liste die durch start ihre Werte gesetzt bekommen hat Der Schleifenz hler wird dekrementiert Wird er 0 geht das Programm in den Zustand STOPPED ber int stop Setzt den Zustand des Programms auf STOPPED Weiter wird die dauerhafte Liste gel scht in der die Argumente f r den Angriff stehen B 10 4 Programm SynAttackTool SynAttackTool char Konstruktor der ein SynAttackToo1 Objekt mit einem speziellen Namen erzeugt Der Server wird nicht gesetzt SynAttackTool char Server Erzeugt ein Programm Objekt das einen Namen und einen Server zugewie sen bekommt int exec list lt char gt Startet eine SYN Attacke die ber 10 Zeitschritte l uft Die SYN Attacke versucht den Port 8 auf Opferseite f r die Attacke zu nutzen Dieses ist der Port auf dem im Normalfall Programme von Typ Webserver laufen exec setztden Status des Programms auf RUNNING damit das Programm auch in den folgenden Zeitschritten ausgef hrt wird Ein Z hler turns wird auf den Wert gesetzt wie lange das Programm laufen soll hier 10 144 B FUNKTIONSREFERENZ char run int F hrt das Programm weiter aus dekrementiert hierbei in jedem Zeitschritt den Z hler turns Ist dieser bei 0 angekommen geht das Programm in den Zustand STO
99. he der Systeme Master und welche Daemon werden e Daemoninstallation Die Daemons werden installiert Wenn s mtliche Daemons fertig eingerichtet sind geht der Angreifer zur Masterinstallation ber e Masterinstallation Nun werden die Master installiert Auch hier findet der n chste Zustands wechsel statt wenn alle Master installiert sind Der Angreifer ist dann An griffsbereit 50 6 MODELLE ZUR BESCHREIBUNG VON D DOS Start der Angreifersimulation Scannen eines Netzscan Rechners Genug Helfer gefunden Rechner bernahme Genug Rechner bernommen Aufteilung in Master Daemon bernahme von Rechnern Installation Daemoninstallation Sines Daemons Alle Daemons installiert Installation Masterinstallation cines Masters Alle Master installiert Angriffsbereit Ende der Angreifersimulation Angriff Abbildung 14 Grobes Zustandsdiagramm des Angreifers e Angriffsbereit In diesem Zustand ist das Netz fertig aufgebaut Der Angreifer f hrt DDoS Attacken auf die von ihm gew nschten Ziele aus Wenn das letzte seiner Ziele attackiert worden ist geht der Angreifer in den Endzustand ber Die einzelnen Angriffsziele m ssen nicht alle direkt im Anschluss aneinander an gegriffen werden Vielmehr kann eine zeitlich gesehen gro e Pause zwischen den einzelnen Attacken sein und Opfer k nnen auch mehrfach des Ziel einer Attacke werden Endzustand Der Angreifer hat sei
100. hen DoS Attacke schlecht brauchbar weil sie eben nicht st ndig verf gbar sind und man sie auch schlecht wiederfindet wenn sie eine neue IP zugewiesen be kommen haben Als Daemon w ren sie dennoch brauchbar aber dazu sind die meisten dieser Rechner zu kurzzeitig im Internet F r diese Arbeit ist diese Rechnergruppe aus obengenannten Gr nden un interessant ein Angreifer wird bei seiner Suche solche Rechner m glichst gleich auslassen In der Simulation werden wir Privatechner deshalb nicht ber cksichtigen Es gibt keine klaren Grenzen zwischen den eben angegebenen Klassen die berg nge k nnen sehr flie end sein Ebenso ist es auch gut m glich eine an dere Einteilung in Klassen zu finden Wir haben diese gew hlt da sie f r die Sicht des Angreifers zur Auswahl der potentiellen Helfer geeignet erscheint In unserem Modell unterscheiden sich die Rechner verschiedener Rechnerklas sen durch die Verweildauer in bestimmten Zust nden und durch die H ufigkeit von Zustands berg ngen Der Zustandsautomat von Rechnern verschiedener Klassen ist identisch Ein durchschnittlicher Server im Internet verh lt sich wie folgt Der Server ist die meiste Zeit online verf gbar und stellt seine Dienste zur Ver f gung Ab und zu muss er aus systemtechnischen Gr nden vom Netz genommen werden Ob dies durch einen Absturz eine Neuinstallation Hardwarearbeiten oder sonstiges bedingt wird spielt aus Netzsicht keine Rolle Der Effekt bleibt g
101. ht erreichbar Eventuell wird das System neuinstalliert dann wird es bei Verlassen des Offline Zustands in den Zustand saubere In stallation bergehen Ansonsten wird das System nach der Downtime wieder in den Zustand bergehen in dem es war bevor es Offline gegangen ist e saubere Installation Das System ist in einem Zustand in dem der Angreifer keinen Root Zugriff darauf besitzt e bernommen Der Angreifer besitzt Root Zugriff auf den Server und kann daher alles mit dem System machen was er will Dazu z hlt u a Programminstallation Be lauschen des Netzwerkverkehrs oder das ndern der Systemkonfiguration e installierter Master Auf dem Server sind die Programme zur Ausf hrung der Mastert tigkeit funktionsf hig Es l uft ein Programm das auf Befehle des Angreifers wartet um diese auszufihren Aus diesem Zustand kann den Server nur eine Downtime mit Neuinstallation herausbringen e installierter Daemon Auf dem Server sind die Daemon Programme installiert und einsatzbereit Der Daemon wartet auf Befehle des Masters Auch aus diesem Zustand kann der Server nur durch eine Neuinstallation herausgebracht werden Die Zust nde samt Uberg ngen sind in einem Diagramm in Abbildung 16 dar gestellt Hinweis Diese Zust nde beziehen sich immer auf die Sicht eines speziel len Angreifers denn im Normalfall sind die installierten Tools fiir die Angriffe z B Passwort geschiitzt damit kein anderer Angreifer sie benutzen kann Dur
102. ht wird In b ist dieser Z hler schon auf dem Maximum Daher wird dieses Angriffspaket nicht mehr bearbeitet Es f llt auch selbst dem Angriff zum Opfer Zum Testen der SYN Attacke wurden die Programmklassen SynAttackTool und Webserver geschrieben die in 8 3 4 und 8 3 5 beschrieben wurden Der Angreifer benutzt f r seinen Angriff das SynAttackTool das nur auf einem belegten Port eine erfolgreiche Attacke durchf hren kann Auf dem Opfer wurde deshalb ein webserver Objekt registriert und damit ein Port belegt 8 4 Implementierung der DoS Attacken 99 a tcp SYN Attack m1 Packet intranet Net from C to B create Protocol TCP ee m l sendPacket m1 flags 10 isSYN true isACK false tcp SYN Attack rome Cc i i i i to Protocol TCP create i i fromPort m 1 1 l toPort n sendPacket m1 i i fags 10 i i i i isSYN true sendPacket m1 isACK false sendPacketiml pi con_Possible l l l I 1 0 FALSE 1 I Abbildung 44 Zeitlicher Ablauf einer SYN Attacke Bei der Smurf Attacke ist das Verhalten sehr hnlich Zur Veranschaulichung des Serververhaltens verweisen wir hier auf die Darstellung des Modells der Smurf Attacke Abb 10 Die Maximalzahl der bearbeitbaren Pakete wird hierbei vom Server festgelegt wird sie berschritten wird kein weiteres Paket mehr bear beitet bis die Simulation zum n chsten Zeittakt weitergeht Um zu simuli
103. iche Abl ufe eines Connects 8 2 Netzwerk 91 RTI Aktionen des Anwendungsprogramms Der Federate muss sich zun chst bei einer Federation Execution anmelden Diese hat im Prototyp den Namen DoS Sim Damit diese Execution auch existiert ver sucht jeder Federate zun chst sie mit createFederationExecution neu einzurichten Entweder sie ist schon vorhanden oder sie wird neu angelegt beide F lle sind zul ssig und hindern den Federate nicht an weiterem Vorgehen Danach meldet er sich mit joinFederationExecution bel ihr an Diese Aktionen werden alle vom Anwendungsprogramm Intranet tibernom men ebenso wie die Ansage an die RTI tiber welche Interaktionen der Federate informiert werden m chte Trifft eine solche Interaktion ein so wird dies dem Federate Ambassador IntranetFedAmb gemeldet der der Ansprechpartner des Federates fiir die RTI ist Die Interaktionen die das Intranet an die RTI schicken m chte werden im RTIhandler an die RTI gemeldet Dort werden alle fiir die Statusmeldungen und das Verschicken von Paketen an das Internet n tigen Interaktionen behandelt Da das Intranet sonst keine weiteren Interaktionen zu verschicken braucht muss die Anwendungsklasse selbst keine Interaktionen anmelden Aber Interaktionen die man von anderen erhalten m chte m ssen bei der RTI gemeldet werden Deshalb meldet das Programm nun mittels subscribelnteractionClass an dass es die Interaktionen IPpacket Si mulationEnd Att
104. ie Program Variable startAtBoot markiert sind Der Server setzt sei nen Zustand auf online Beim Shut Down des Servers wird zuerst sein Zustand auf offline gesetzt bevor weitere Aktivit ten zum Shut Down ausgef hrt werden Diese bestehen dann aus Stoppen der Programme und Aufruf von bootstate Eine Neuinstallation f hrt zuerst einen Shut Down durch danach wird die Pro grammliste geleert Danach werden die im Konfigurationsfile angegebenen Pro gramme installiert Die Variable st il1lDown wird auf einen in server h de finierten Wert hier 3 gesetzt Damit soll der Server nach der in stillDown angegebenen Zeit wieder booten Um Programme auszuf hren k nnen die Funktionen execBefehl Auf ruf von exec eines Programms bzw start Service verwendet werden Von diesen Befehlen gibt es mehrere Versionen Eine dient zur Ausf hrung oh ne Parameter der Server erzeugt dann selbst eine leere Parameterliste die er an das Programm weitergibt Die andere wird fiir den Aufruf mit einer Parameterli ste verwendet Weiter gibt es noch die M glichkeit den Befehl mit einer UserID oder ohne auszuf hren Die Version mit der UserID stammt aus dem Versuch das Userkonzept 7 4 zu verwirklichen Mit dieser Funktion wird der Befehl nur aus gef hrt wenn die angegebene UserID zu einem am System angemeldeten User ge h rt Die Funktion stopService beendet die Ausf hrung eines als Dienst mit startService aufgerufenen Programms
105. ielsweise die Bekanntgabe des timeAdvance an den Federate bermitteln kann Obwohl die Interaktionen und Objekte Parameter und Attribute besitzen sind diese typlos Zumindest interessiert sich HLA nicht f r die Typen der Daten die ausgetauscht werden Die Interpretation liegt alleine bei den Federates Dass Datenklassen von einander erben k nnen hat auch einen Sinn Wird die Federation durch neue Federates erg nzt so k nnen diese mehr als die bisher de finierten Attribute oder Parameter ben tigen Erweitert man nun eine alte Klasse durch Vererbung um einige Attribute oder Parameter so k nnen die alten Federa tes noch den Teil der Daten der erbenden Klasse mitgeteilt bekommen der in der vererbenden Klasse schon definiert ist Bei Definition einer komplett neuen Klasse w re dies nicht m glich Beispiel Wird ein neuer Federate geschrieben der die Interaktion IPpacket um einen Parameter Gr e zur Klasse IPpacketMitGr e erweitert so k nnen die 44 5 SIMULATIONSUMGEBUNG RTIprivate Manager m E von der RTI gebrauchte Klassen V InteractionRoot A f r die Federates entwickelte Klassen SimulationEnd IPpacket srclp parameter destIp parameter protocol parameter fromPort parameter destPort parameter flags parameter ip parameter message parameter status parameter AttackerResign AttackerJoin ServerNewlnstall Abbildung 8 Die Hierarchie der Intera
106. illen haben Diese greifen auf Initiative des Angreifers das Opfer System an Das kann entweder durch Senden eines Befehls an ein laufendes Programm auf den Netzwerkrechnern oder durch Ausnutzen von unsicheren Konfigurationen geschehen Solche Netze stehen oft fertig bereit und k nnen vom Angreifer mit minimalem Aufwand als Hel fernetze missbraucht werden Ein Angriff der auf ein solches Netzwerk aufbaut ist der so genannte Smurf Angriff 2 4 1 F r den schematischen Aufbau dieses Netzwerks siehe Ab bildung 4 e Master Daemon Netzwerk Dieses Netzwerk besteht aus zwei Typen von Rechner Systemen Master Systeme und Daemon Systeme Ein Angriff erfolgt indem der Angreifer den 20 2 DENIAL OF SERVICE DOS Opfer Angreifer Router Helfer im Angriffsnetzwerk Abbildung 4 Beispiel Einfaches Netzwerk Master Systemen den Angriffsbefehl erteilt Diese senden daraufhin einen Angriffsbefehl an die Daemon Systeme die dann den eigentlichen Angriff auf das Opfer ausf hren siehe Abbildung 5 Dieses Netz muss immer vom Angreifer aufgebaut werden bevor er den Nut zen daraus ziehen kann Im weiteren Verlauf dieses Kapitels werden wir schwerpunktm ig auf den Auf bau und die Vorgehensweise bei Master Daemon Netzwerken eingehen Die Nut zung von einfachen Netzwerken f r DoS Attacken l sst sich daraus leicht ableiten 2 5 2 Aufbau eines Master Daemon Angriffsnetzwerks Wie schon erw hnt muss der Angreifer sein A
107. imulati on erh lt der Angreifer zusammen mit den Best tigungen ber das Erreichen seiner gew nschten Zeitverhalten timeRegulation und timeConstrained die initiale Si mulationszeit 6 gemeldet Der Angreifer erh lt von der RTI eine FederatelD 5 die nicht mit der NetzID 3 verwechselt werden darf ANGREIFER Creating Execution already existing Going on ANGREIFER Joining Execution Joined My ID 5 ANGREIFER timeRegulationEnabled New Time 6 0000000000 ANGREIFER timeConstrainedEnabled New Time 6 0000000000 Nach dem Startvorgang meldet sich nun der Angreifer mit seiner NetzID und best tigt dass er einen Rechner zum Arbeiten gefunden hat Es folgt die Ausga be der bestehenden Firewallregeln des Angreifernetzes welche in diesem Fall mit Ausgabe der Default Policy ACCEPT abschlie en 110 9 BEISPIELLAUF EINER DDOS SIMULATION Attacker Simulation for Subnet 3 OK i got an operating Basis 3 1 Firewall Ruleset ACCEPT Nun beginnt der Server mit der Arbeit Im Folgenden ist zu sehen dass der Router in diesem Zeitabschnitt keine Pakete zu bearbeiten hat Ebenso hat auch der Rechner des Angreifers 3 1 keine Pakete erhalten Zuerst f hrt der Angrei fer einen Ping auf die zwei Rechner 1 1 und 2 1 aus Dieser Ping ist bei dieser Simulation noch nicht so wichtig aber er wird bei einer Simulation mit Firewall regeln zeigen dass noch Pakete die Firewall passieren k nnen Dieser Ping wird nur dieses eine
108. in Router der berlastet ist an alle Router die ihm Pakete zusenden k nnen dass sie den Verkehr f r ihn beschr nken sollen da er ihn nicht mehr komplett bearbeiten kann Diese Router propagieren weiter dass Pakete die in Richtung des berlasteten Routers gesendet werden nur in beschr nktem Umfang an sie weitergeleitet werden Da mit werden auch legitime Pakete und nicht nur Angriffspakete ausgesondert aber Paketverkehr der ohnehin wegen berlastung nicht bearbeitet werden k nnte wird schon m glichst fr h ausgesondert damit das Internet weniger belastet wird Ei ne genauere Beschreibung dieses als Push Back bekannten Verfahrens erfolgt in 37 und 24 3 3 Als Routerbetreiber DoS Attacken verhindern 33 Andere Methoden versuchen gezielt DoS Pakete zu erkennen und zu verwer fen Dabei wird der durchgehende Paketverkehr je nach Methode anders klassifi ziert Mal wird eine berdurchschnittlich gro e Paketmenge als Angriff bewertet mal wird auf das proportionale Verh ltnis von Hin und R ckverkehr geachtet sie he hierzu 19 und mal wird ein Modell des normalen Traffics aufgestellt dessen Verletzung zu Filteraktionen des Routers f hrt siehe 32 34 4 DOS SIMULATION 4 DoS Simulation Simulationen versuchen ein Abbild der realen Welt zu schaffen Simulierte Hand lungen sollen in diesem Abbild der Umwelt daher auch vergleichbare Reaktionen hervorrufen wie sie in der Realit t stattfinden w rden Auf
109. ines Netzwerkes alle Rechner im Netz dieses Ping Paket ICMP Echo Request mit einem Echo Reply Paket beantworten Da bei erh lt man auf einfachem Wege eine Multiplizierung der Paketanzahl Wenn man nun als Absendeadresse die Adresse des Opfers angibt so kommen s mtliche Antworten beim Opfer an Abb 1 Das Angeben einer falschen Absendeadresse wird auch spoofing genannt Auch wenn sich das nicht so gravierend anh rt so wird ein einfaches Rechen beispiel vom Gegenteil berzeugen Wenn der Angreifer 1000 Echo Pakete an eine Broadcastadresse eines gro en Netzwerks schickt bei der dann 100 Rechner ant worten so macht das dann 100000 Pakete die das Opfer erh lt Das ganze in Bandbreite ausgedr ckt Sendet der Angreifer mit 128kb s DSL Upload Rate so erh lt das Opfer rechnerisch immerhin eine Auslastung von 12 8Mb s m gliche Download Rate bei DSL nur 768kb s An diesem Beispiel sieht man dass man mit einem einfachen DSL Anschluss schon einen anderen DSL Teilnehmer auslasten kann obwohl bei DSL mehr Band breite zum Empfangen als zum Senden bereitgestellt wird Wenn nun aber der An greifer vielleicht seinen Angriff von einem schlecht gesicherten Universit tsrechner startet der ber eine sehr hohe Bandbreite verf gt so kann man problemlos auch Server lahmlegen die ber einen besseren Anschluss als DSL verf gen 2 4 Beschreibung einiger wichtiger DoS Attacken 17 Rechner der Netzwerkes dessen Broadcastadresse angepi
110. ionen dieser Klasse gebraucht werden muss sich der Entwickler wohl oder bel doch mit der Aufrufsyntax der RTI zum Versenden von Interaktionen oder Objekten auseinander setzen das ist dann nicht zu vermei den Das Zeitverhalten der Simulation wird konservativ sein d h jeder Federate darf erst zu einer neuen Zeit voranschreiten wenn durch die RTI sichergestellt ist dass er keine Events mehr erhalten kann die vor dieser dann aktuellen Zeit stattfanden Auf das Benutzen von Synchronisationspunkten siehe 5 2 wird verzichtet Das Internet ist ein derart dynamisches und vitales Gebilde dass es nicht sinnvoll er scheint erst alle Federates an einem Punkt synchronisieren zu lassen bevor die Simulation beginnt Vielmehr soll es m glich sein dass ein Netzwerk l ngerfristig simuliert wird und w hrend dieser Simulation neue Teilnetze hinzugef gt oder alte entfernt werden k nnen z B kommende und gehende Angreifer 65 8 Implementierung eines Prototyps Nachdem in Kapitel 7 eine Gliederung der Gesamtsimulation konzipiert wurde und einige Anforderungen an die entstandenen Einzelkomponenten entwickelt wurden werden wir uns nun mit der Implementierung der einzelnen Glieder der Simulation befassen und auf weitere Notwendigkeiten und besondere Aspekte ihrer Implemen tierung eingehen F r die Implementierung wurde C 41 als Programmiersprache gew hlt 8 1 Beenden der Simulation Im Rahmen unseres Prototyps kann man sich
111. ise de newsticker data jk 15 08 02 003 Heise Zeitschriften Verlag DoS Angriffe ber Game Server gef hrden Internet Nutzer 2003 heise online news vom 18 01 2003 http www heise de newsticker data ju 18 01 03 001 Heise Zeitschriften Verlag Linux Keine Chance f r Buffer Overflows 2003 heise online news vom 4 05 2003 http www heise de newsticker data cgl 04 05 03 002 Heise Zeitschriften Verlag Trusted Debian mit versch rftem Sicherheitskon zept f r Linux 2003 heise online news vom 22 04 2003 http www heise de newsticker data ola 22 04 03 002 Marco Vogel Distributed Denial of Service DoS Vorgehen Gegenma nah men 2000 Seminar Datenverarbeitung SS2000 Verteilte Systeme Sicher heit im Internet Ruhr Universit t Bochum http www etdv ruhr uni bochum de dv lehre seminar syssec apr Tobias Winkelmann Systemsicherheit Angriffspunkte eines Rechners 2000 Seminar Datenverarbeitung SS2000 Verteilte Systeme Sicherheit im Inter net Ruhr Universit t Bochum http www etdv ruhr uni bochum de dv lehre seminar syssec apr
112. isory MK 001 Pivx Solutions http www pivx com kristovich adv mk001 Dr F Kuhl Dr R Weatherly and Dr J Dahmann Creating Computer Si mulation Systems An Introduction To The High Level Architecture Prentice Hall 1999 Ping Herng Denny Lin Survey of Denial of Service Countermeasures 2000 http www lasierra edu dlin classes cpsc433 cpsc433 htm Jelena Mirkovic Janice Martin and Peter Reiher A Taxonomy of DDoS Attacks and DDoS Defense Mechanisms Technical Report 020018 Computer Science Department University of California Los Angeles 2002 148 32 33 34 35 ey 36 37 38 39 40 41 42 43 LITERATUR Jelena Mirkovi Gregory Prier and Peter Reiher Attacking DDoS at the Source In Proceedings of ICNP 2002 pages 312 321 November 2002 Ingo Molnar announcement Exec Shield new Linux security feature 2003 http people redhat com mingo exec shield ANNOUNCE exec shield John R Mostow John D Roberts and John Bott Integration of an Internet Attack Simulator in an HLA Environment 2000 NN TCP IP Angriffe 1999 http www computec ch dokumente denial_of_service tcp ip angriffe tcp ip angriffe html Vern Paxson An Analysis of Using Reflectors for Distributed Denial of Service Attacks ACM Computer Communications Review CCR 31 July 2001 http www icir org vern papers reflectors CCR 01l ps gz Tao Peng Christopher Lec
113. it das Programm bei weiteren Aufrufen durch den Server noch Zugriff auf diese hat Weiter muss man dann der Funktion run die die weiteren Aktionen durchf hren muss eine Ab bruchbedingung z B einen dekrementierenden Z hler mitgeben die durch Aufruf von exec gesetzt wird 8 2 Netzwerk 81 Char startAtBoot int myServer Server state ServiceState myPort int vulnerability list lt char gt start argumente list lt char gt int SLNE char run message char char run fromIP IP fromPort IP message char char exec argumente list lt char gt int bootstate void setServer host Server void setVulnerabilities void setVulnerabilities problem char void patchVulnerabilities problem char void Abbildung 29 Program Interface Obwohl dieses eigentlich nicht geplant war stellte es sich doch als hilfreich heraus mit diesem Trick zu arbeiten So kann man beispielsweise durch Aufruf von exec des Programms Smurf einen Angriff tiber mehrere Zeitschritte hinweg starten und muss nicht zu jedem Zeitschritt den Befehl wieder neu aufrufen Um Exploits anwenden zu k nnen braucht man aber auch eine M glichkeit dem Programm Schwachstellen anzugeben die es besitzt Hierzu gibt es eine Funk tion setVulnerabilities mit der dem Programm eine von der Funktion fest vorgegebene Liste von Verwundbarkeiten angegeben wird Dazu muss diese in Program virtuell definierte Funktion von j
114. kete die eine bestehende Verbindung nutzen k nnen nur im direkten Anschluss an eine bermittlung der Gegenseite stattfinden da sich die Server bestehende Verbindungen nicht merken Wenn z B ein Server durch ein Paket einen Dienst ausgef hrt hat dann kann direkt im Anschluss dieser Ausf h rung ein Paket als Antwort gesendet werden Dabei sind die Flag Belegungen wie bei den verbindungsaufbauenden Paketen nur dass das SYN Bit ungesetzt bleibt Eine Antwort auf ein Connect hat also ACK und FIN gesetzt wenn ein belegter Port best tigt wird w hrend eine normale Antwort bermittlung eines Dienstes nur ein gesetztes ACK Bit hat icmp Packet Packet udp Packet Packet steht f r frei w hlbar ion om Die Belegung des flags Feldes z GEN ist bitweise angegeben Protocol ICMP Protocol UDP FIN RST fromPort ICMP Type fromPort E Eet toPort ICMP Code toPort gesetz flags ge flags data g frei w hlbar tcp SYN Attack Packet to Protocol TCP to Protocol TCP au TCP fromPort romPort toPort toPort eon on flags 111 flags 011 flags 10 isSYN true isSYN false isSYN true isACK true isACK true isACK false isFIN true isFIN true S tcp Verbindung Packet tcp Verbindungs Antwort Packet from from to to Protocol TCP Protocol TCP fromPort fromPort fromPert toPort flags 110 flags 010 isSYN
115. kete auch durch das Internet verschicken m ssen Bei Angriffen die auf gro en Datenmengen basieren w ren also auch Router auf dem Weg der Angriffs pakete und damit alle Internetnutzer die auch Pakete ber diese Router versenden betroffen Daher stellt sich die Frage ob man diese Gefahren nicht auf anderem Wege deutlich machen kann beispielsweise durch Simulation Durch eine Simulation k nnte man die bestehende Infrastruktur kosteng nstig abbilden und w rde weder Produktionssysteme noch andere Internetnutzer st ren Ziel dieser Arbeit ist deshalb einen Prototyp einer solchen Simulation zu ent wickeln und damit deren Machbarkeit zu zeigen Da das Feld der m glichen An griffe sehr weit gestreut ist wird sich der hier entwickelte Prototyp mit der Simula tion eines bestimmten Denial of Service Angriffs besch ftigen sowie mit einigen Ma nahmen um sich gegen DoS Angriffe zu wehren Die Arbeit ist wie folgend aufgebaut Kapitel 2 gibt einen berblick ber den Begriff des DoS Denial of Service und des Distributed Denial of Service DDoS Es werden Angriffstechniken er l utert und Probleme beschrieben die von DoS ausgenutzt werden Hier werden auch die Angriffe beschrieben die durch den entwickelten Prototyp simuliert wer den 13 In Kapitel 3 folgt ein berblick ber m gliche Techniken zur Abwehr von DoS Besonders wichtige Techniken werden genauer erl utert um ihre Wirkungsweise w hrend der Simulati
116. kie and Kotagiri Ramamohanarao Defending Against Distributed Denial of Service Attacks Using Selective Pushback 2002 Marc Ruef DoS Denial of Service 2000 http www computec ch dokumente denial_of_service denial_of_service denial_of_service html J Seemann and J W von Gudenberg Software Entwurf mit UML Springer 2000 Rob Simmonds Russell Bradford and Brian Unger Applying parallel dis crete event simulation to network emulation In Workshop on Parallel and Distributed Simulation pages 15 22 2000 Bjarne Stroustrup Die C Programmiersprache Addison Wesley 2000 Heise Zeitschriften Verlag Denial of Service bei Freemailer GMX 2000 heise online news vom 15 12 2000 http www heise de newsticker data hob 15 12 00 000 Heise Zeitschriften Verlag DoS Attacke auf Darmst dter Unternehmen 2000 heise online news vom 19 12 2000 http www heise de newsticker data hob 19 12 00 000 LITERATUR 149 44 45 46 47 48 49 50 51 Heise Zeitschriften Verlag DoS Attacke gegen Websites von Microsoft 2001 heise online news vom 26 01 2001 http www heise de newsticker data jk 26 01 01 000 Heise Zeitschriften Verlag Internet Wurm startet DoS Attacke 2001 heise online news vom 07 06 2001 http www heise de newsticker data r 07 06 01 000 Heise Zeitschriften Verlag Unruhe im DNS Alle Maschinen stop Gentle men 2002 heise online news vom 15 08 2002 http www he
117. ks 2000 Version 1 10 http www sans org dosstep roadmap php LITERATUR 147 23 24 SANS Institute Help Defeat Denial of Service Attacks Step by Step 2000 Revision 1 4 http www sans org dosstep index php John Ioannidis and Steven M Bellovin Implementing Pushback Router Based Defense Against DDoS Attacks In Proceedings of Network and Dis tributed System Security Symposium Catamaran Resort Hotel San Diego Ca lifornia 6 8 February 2002 1775 Wiehle Ave Suite 102 Reston VA 20190 Februar 2002 The Internet Society 25 ju onlinesicherheit de Internet Angriffe mit DDoS und DoS Strategien 26 27 28 29 30 31 2000 http www computec ch dokumente denial_of_service internet_angriffe_mit_ddos_und_dos internet_angriffe_mit_ddos_und_dos txt Stephan Kallnik Daniel Pape Daniel Schr ter and Stefan Strobel Das Sicherheitsloch Buffer Overflows und wie man sich davor sch tzt ct 23 2001 216 2001 http www heise de ct 01 23 216 HyungJong Kim KyungHee Koh DongHoon Shin and HongGeun Kim Vulnerability Assessment Simulation for Information Infrastructure Protec tion In Infrastructure Security International Conference InfraSec 2002 Bristol UK October 1 3 2002 Proceedings pages 145 161 2002 http www informatik uni trier de ley db conf infrasec infrasec2002 html Mike Kristovich Topic Multi vendor Game Server DDoS Vulnerability 2002 Security Adv
118. kt des Netzwerks gesammelt kann eine Durchmischung der Pakete erfolgen die zu einer zuf lligen Rei henfolge fiihrt dann erst werden Pakete an den Bestimmungsort Router bzw Server weitergereicht 2 Das Intranet wird auch als parallele Simulation aufgebaut bei der die Rei henfolge der Pakete dann also von der Simulation bestimmt wird 8 10 2 Teilnetze mit gleicher NetzID m glich Der bestehende Prototyp bietet keine M glichkeit die Erzeugung mehrerer Teilnet ze mit der selben NetzID zu verhindern An sich w re es vielleicht aus Gr nden vergleichender Simulation sogar w nschenswert zwei Netze mit gleicher NetzID zu haben aber f r diesen Prototyp sehen wir es als Konfigurationsfehler an Der Grund daf r ist dass der Angreifer Viewer des Prototyps zwei Server mit gleicher IP nicht unterscheiden kann da er von einer eindeutigen Benennung der erreichbaren Rechner ausgeht Daher w rde er die von den gleichbenannten Ser vern erhaltenen Statusmeldungen die lediglich nach IP Adressen verwaltet werden miteinander vermischen Der Unterschied der durch zwei gleichbenannte Netze si muliert werden sollte w re also mit dem bestehenden Viewer des Angreifers nicht darstellbar L sungen dieses Problems k nnen in zwei Richtungen gehen Entweder wird eine M glichkeit entwickelt die verhindert Teilnetze mit gleicher ID zu erzeugen oder man entwickelt einen Viewer der durch gleiche IPs nicht in Unordnung ger t M gliche L sun
119. ktionen bestehenden Federates immer noch die Interaktion als IPpacket zugestellt bekom men Noch ein Hinweis zur Benennung der Klassen Der offizielle Name ei ner Interaktion oder eines Objekts wird der Vererbungshierarchie nach gebil det Dabei wird der Vererbungsbaum von der Rootklasse an abgelaufen wo bei jede Ebene des Baums mit einem von der vorigen getrennt wird Da raus ergibt sich als offizieller Name der Interaktion IPpacket z B Interaction Root IPpacket die davon abgeleitete Klasse IPpacketMitGr e w rde Interac tionRoot IPpacket IPpacketMitGr e hei en 45 6 Modelle zur Beschreibung von D DoS Ehe man einen Prototyp fiir eine DoS Simulation schreiben kann muss geklart wer den welches Verhalten die Simulationsteilnehmer in bestimmten Situationen auf weisen sollten Dieses gewiinschte Verhalten wird durch Modelle beschrieben die jeweils einen bestimmten Aspekt der Simulation beleuchten Zur Beschreibung der Modelle wird unter anderem die UML Unified Modeling Language 3 39 verwendet 6 1 Verhaltensmodelle f r Angriffe Zuerst wird nun das Verhalten bei den Angriffen beschrieben die simuliert wer den sollen Sowohl die SYN Attacke als auch der Smurf Angriff beruhen auf der Auslastung des Opfers Untersucht werden muss also das Verhalten des Servers im Falle einer Attacke Weiter braucht der Angreifer eine Methode mit der er die Verteilung seiner Angriffs Tools erreichen kann Auch hierfiir
120. l der Verbindungsversuche um den Wert erniedrigt der in dem Listen element als Anzahl von Verbindungsversuchen angegeben ist Dann wird dieses Listenelement entfernt Ist das Element lter so wird es genauso behandelt wie 74 8 IMPLEMENTIERUNG EINES PROTOTYPS wenn die Zeit der aktuellen entspricht Dieser Fall sollte zwar nicht auftreten k n nen da die Server zu jedem Zeittakt ihre Arbeit erledigen m ssen und somit keine alten Listenelemente vorhanden sein sollten da sie zum vorhergehenden Zeittakt h tten bearbeitet werden m ssen Und Zeitspr nge sind in dieser Implementierung nicht m glich Sollte dies aber doch aus irgendeinem Grund auftreten so werden die Listen elemente von vorne solange berpr ft bearbeitet und entsorgt bis das neue erste Element eine Zeit in der Zukunft angibt Weitere Funktionen von Tcon bieten die M glichkeit die aktuelle Gesamtzahl der Verbindungsversuche abzufragen get Anz oder auch gezielt zu ermitteln ob noch weitere Verbindungen aufgebaut werden k nnen con_possible Dazu muss die Bedingung erf llt sein dass die Anzahl der Verbindungsversuche kleiner ist als der definierte Maximalwert MAX_CON Mittels reset kann die Liste geleert werden dabei wird auch die Gesamt zahl der Verbindungsversuche auf O gesetzt Dies ist z B bei einem Reboot des Servers n tig Bekommt ein Server ein Paket mit dem ein Verbindungsaufbauversuch gemacht wird z B ein Paket f r eine SYN Attacke s
121. lationszeit 22 wird das Zeichen zum Simulationsende empfangen der Federate beendet seine Ausf hrung Got end of simulation INTRANET Resigning Execution resigned INTRANET Destroying Execution Execution already destroyed 9 2 3 Opfernetz Nun fehlt uns nur noch wie der angegriffene Rechner die Simulation erlebt Das Opfernetz tritt der Simulation zur Zeit 4 bei und legt dann seine zwei Server an INTRANET Creating Execution already existing Going on INTRANET Joining Execution joined My ID 3 INTRANET timeRegulationEnabled New Time 4 0000000000 INTRANET timeConstrainedEnabled New Time 4 0000000000 Intranet Simulation for Subnet 2 Server 2 1 angelegt Server 2 2 angelegt W hrend der folgenden Zeit passiert in diesem Netz nichts Es gehen keine Pakete ein und alle Server sind online Dieser Zustand h lt bis zu Simulationszeit 8 an New Time 5 0000000000 Router ROUTER packets to handle 0 A Se 2 1 packets to handle 0 9 2 Erfolgreicher Smurf Angriff DOTES 2 2 packets to handle 0 Net finished 2 1 ONLINE 2 2 ONLINE 117 Zu Simulationszeit 9 trifft ein Ping Paket von Angreifer ein Erst passiert es den Router dann wird es vom Opfer beantwortet bei Zeit 11 verl sst die Antwort das Netz wieder ber den Router xxxx x New Time Router ROUTER packets to handle 1 A aS 2 1 packets to handle 0 222 2 2 packets
122. leich der Rechner wird f r andere Netzteilnehmer unerreichbar Was der Grund f r die Downtime war spielt nur f r den Zustand eine Rolle in den der Server eintritt wenn er wieder verf gbar wird Nach einer Neuinstallation z B ist das System in sauberem Zustand d h der Server ist online und eventuell vorher installierte Schadprogramme Viren Trojanische Pferde Hintert ren aber auch Master oder Daemonprogramme sind nun nicht mehr auf dem System zu finden Aber neben dem Normalbetrieb gibt es in Hinsicht auf DDoS Simulationen noch Zust nde in denen der Server weiter seiner Arbeit nachgeht aber eben nicht mehr sauber ist Der Server kann von einem Hacker bernommen worden sein 11 Als Downtime wird die Zeitspanne bezeichnet die der Server vom Netz getrennt ist 54 6 MODELLE ZUR BESCHREIBUNG VON D DOS Wenn dieser die Serverkonfiguration manipuliert hat z B eine Hintert re eingerich tet hat mit der er sich jederzeit mit Administratorrechten auf dem System einlog gen kann so ist der Rechner nicht mehr sauber Dieser Zustand wird im Modell bernommen genannt Aber auch durch die Installation von Programmen Viren W rmer Trojaner kann der Server in den Zustand bernommen gelangen Ein vom Angreifer bernommener Rechner unterscheidet sich dann noch darin ob die f r den Angriff n tigen Programme installiert sind Fassen wir also die Serverzust nde zusammen e offline Das System ist nic
123. lembereiche er kannt die fiir die grunds tzliche Funktion nicht relevant waren und deshalb im Rahmen dieser Arbeit nicht n her untersucht wurden Sie sollen hier jedoch kurz dargestellt werden wobei auch L sungsvorschl ge angegeben werden 8 10 1 Reihenfolge der Pakete abh ngig von HostID der Sender Pakete kommen nach Servern sortiert ins Netz daher erfolgt eine Benachteiligung der Server mit h herer HostID Dadurch ndern sich zwar nicht die Auswirkungen auf den Server er wird bei einer DoS Attacke auch so in die Knie gezwungen aber m gliche Sichten von au en auf das Opfer werden hierdurch beeinflusst Beispiel Der Angreifer hat eine h here HostID als der User der Anfragen an den Webserver stellt Die Pakete des Users werden immer dann beantwortet wenn der Webserver wieder neue Pakete empfangen kann weil einige Verbindun gen durch TimeOut freigeworden sind Erst nach der Bearbeitung der http Anfragen werden die Angriffspakete bearbeitet die wieder weitere Verbindungsw nsche ver hindern Hat der Angreifer die niedrigere HostID so werden zuerst die eben wieder freigewordenen Verbindungen belegt die Anfragen des Users an den Webserver 8 10 Schwachpunkte des Prototyps 105 fallen dem Angriff zum Opfer M gliche L sungsans tze 1 Die Pakete werden durchmischt Man k nnte sie z B im Net Objekt sam meln Nachdem alle Server aktiv waren doWork wurde ausgefiihrt die hierbei erzeugten Pakete werden im Net Obje
124. momentanen Aktionen des Angreifers darstellt und einen Netzwerk Status in dem der Zustand des Angriffsnetzes und des gewiinschten Opfers tiberwacht wer den k nnen Dazu miissen allgemeine Zust nde der beteiligten Server dargestellt werden online offline Uberlastung und Aktionen wie Neuinstallationen Da neben gibt es die fiir einen Viewer speziell gedachten Meldungen wie z B die dass sein Angreifer gerade ein Tool installiert hat oder dass der Server gerade An griffspakete verschickt etc Hierbei sollten auch die Auswirkungen auf das Opfer erkennbar sein Mehr Feedback als ein Opfer ist ausgefallen Opfer ist noch voll arbeitsf hig o wird von diesem Prototyp aber nicht dargestellt Der Vorteil dieses Ansatzes ist dass man kein spezielles Opfer zu simulieren braucht ein nor maler Netzwerkrechner als Opfer kann diese Meldungen auch schon erzeugen Will man auch die genaueren Auswirkungen auf ein Opfer darstellen so sollte ein spezielles Modell eines Opfers simuliert werden Dieses kann dann entweder einen eigenen Viewer besitzen der genauere Aussagen ber den Zustand des Opfers trifft oder es kann zus tzliche detaillierte Angaben ber seinen Zustand an die RTI schicken sodass irgendein Viewer der diese Aussagen interpretieren kann sie anzeigt F r eine Gesamtperspektive ber das Netzgeschehen wird aber doch ein von allen anderen Federates unabh ngiger Viewer empfohlen Dieser kann dann auch 102
125. myNet Net rulefile char getPolicy Policies setPolicy pol Policies int loadRuleset rulefile char int clearRuleset int listRuleset int dumpRuleset int dumpRuleset dumpfile char int tmvRuleUp nr int int mvRuleDown nr int int addRule regel Rule int delRule nr int int filter packet Packet Policies sendPacket packet Packet void handlePacket packet Packet void Abbildung 35 Klassendiagramm eines Routers 8 2 Netzwerk 85 8 2 5 Netz Das Netz dient als Steuereinheit fiir das Intranet Es beinhaltet sowohl die Funktion mit der das gesamte Netz in einem Zeitschritt seine routinem ige Arbeit erledigt als auch die Methode die die IP Pakete im Netzwerk zu ihrem Bestimmungsort leitet siehe hierzu auch Abb 36 Anwendung IntranetFederate Host Server A eee eae sendPacket packet Packet void Router Router A eee sendPacket packet Packet void Packet Packet Abbildung 36 Umfeld des Netzes Die Kommunikationspakete ber so ein gesondertes Netz zu verschicken hat gegeniiber der direkten Kommunikation der Server untereinander einen groBen Vor teil Die Server miissen sich untereinander nicht kennen sie miissen nicht wissen ob der Bestimmungsort des Pakets wirklich existiert und wie er zu erreichen ist Denn hierfiir ist das Netz zust ndig Es kennt alle Server seines Netzes ihr
126. n Mittlerweile gibt es viele Intrusion Detection Tools die auch sehr unterschied liche Ans tze verwenden um einen Einbruch in das System zu erkennen Die einfa cheren IDTs vergleichen beispielsweise nur ob das Dateisystem ver ndert wurde Dazu besitzen sie eine Datenbank in der Informationen ber statische Teile des Dateisystems enthalten sind Wenn bei einer berpr fung des aktuellen Dateisy stems mit den Informationen aus der Datenbank Unstimmigkeiten gefunden wer den so wird Alarm ausgel st Um berechtigte nderungen am System durchf hren zu k nnen gibt es eine Updatefunktion f r die Datenbank die aber leider auch vom Angreifer benutzt werden kann Die Datenbankdaten sollten also auch auf einem Medium gespeichert sein welches Manipulationen durch Unberechtigte verhindert Modernere IDTs versuchen deshalb nicht nur Dateistrukturen zu berwachen sondern generell das Verhalten des Servers Dabei w rden auch ungew hnlicher Netzwerkverkehr oder auff lliges Userverhalten bemerkt Da sich User und Netz werkverkehr aber nicht statisch verhalten m ssen diese Tools entweder einen sta tischen Bereich haben in dem das Systemverhalten als normal gilt und der bei Bedarf an neue Verhaltensweisen angepasst wird oder sie haben eine F higkeit neues Verhalten zu lernen Dabei werden nur schnelle Ver nderungen beim Ver halten bemerkt schleichende Ver nderungen w rden als neuer Normalzustand gelernt Damit k nnte ein Ang
127. n Konfigurationsfile in dem angegeben ist wel che Programme bei einer Neuinstallation auf diesem Rechner installiert werden Dieses kann durch den Befehl set Config ersetzt werden oder bei einer neuen Installation durch Angabe eines alternativen Konfigurationsfiles ausgetauscht wer den Dabei wird nur der Name des Files als String samt Pfad angegeben Dieser Pfad kann absolut angegeben werden oder auch relativ zu der Aufrufposition der Anwendung Neben den Programmen brauchen wir f r die Kommunikation eine M glich keit Programme an Ports zu binden ber die man die Programme dann ansprechen kann Dazu existieren zwei Vektoren deren L nge so festgelegt wird dass der letz te ansprechbare Index der h chsten existierenden Portnummer entspricht Dieser maximale Port ist durch einen festen Wert im Quellcode der Serverklasse bestimmt Einer dieser zwei Vektoren ist die Portliste f r TCP der andere f r UDP TCP Ports Vektor Liste der Programme Liste Abbildung 23 Programme werden auf Ports gelinkt Um Programme an einen Port zu binden wird eine Funktion namens registerPort verwendet der man die Adresse eines Programm Objektes die gew nschte Portnummer und das Protokoll mitgibt So wird dann falls der Port noch frei ist von ihm ein Verweis auf das entsprechende Programm gesetzt Das Programm ist dann durch den Port erreichbar Ein Beispiel f r eine solche Liste mit belegten Ports ist in Abbildung 23 zu sehen Dort sieht man
128. n beide je ein Interface das vom Anderen angesprochen werden kann Abb 7 Dazu stellt die RTI einen RTI Ambassador zur Verf gung an den der Federate seine Meldungen Events schicken kann Umgekehrt muss der Federate einen Federate Ambassador imple mentieren damit er die Events der RTI entgegennehmen kann Das Interface f r den Federate Ambassador ist durch HLA spezifiziert worden F r jede Simulation wird eine Federation Execution ben tigt Daher gibt es eine RTI Funktion mit der eine solche erzeugt werden kann createFederationExecuti on Bei der Erzeugung der Federation Execution werden die Angaben ber den Namen der Execution und das fed File fed federation execution data ben tigt in dem das FOM der Execution definiert ist Nach Ende der Simulation kann die Execution mit der Funktion deleteFederationExecution wieder beseitigt werden Sie wird nicht mehr gebraucht 5 3 Zeitverwaltung 41 Federate Federate Ambassador RTI Ambassador Abbildung 7 Kommunikation zwischen Federate und RTI Jeder Federate muss einer Federation angeh ren damit er Events tiber die RTI verschicken und erhalten kann Denn mit dieser Federation sind das FOM und die anderen Teilnehmer der Simulation festgelegt Das Beitreten zu einer Execution erfolgt ber den Befehl joinFederationExecution Hierbei muss der Federate der RTI seinen Federate Ambassador bekanntmachen damit die RTI diesen verwenden kann Der Federate kann n
129. n das Netz eingef gt werden Intranet Simulation for Subnet 1 Added server 1 1 to Intranet Added server 1 2 to Intranet Added server 1 3 to Intranet Added server 1 4 to Intranet Added server 1 5 to Intranet Added server 1 6 to Intranet Added server 1 7 to Intranet Added server 1 8 to Intranet Added server 1 9 to Intranet Added server 1 10 to Intranet 114 9 BEISPIELLAUF EINER DDOS SIMULATION Danach beginnt die Arbeit des Netzwerkes In diesem Fall besteht diese Arbeit daraus auf eingehende Pakete zu warten Der Output des Traces sieht deshalb von Simulationszeit O bis 8 folgenderma en aus Server 1 1 und 1 2 stehen stellvertretend fiir alle Rechner des Netze New Time 0 0000000000 Router ROUTER packets to handle 0 BAS E 1 1 packets to handle 0 ha 1 2 packets to handle 0 Am Ende jedes Zeittaktes gibt das Netz einen Status tiber seine Rechner aus Dieser ndert sich im Laufe der Simulation nicht da aus diesem Netz kein Rechner angegriffen wird 1 1 ONLINE 1 2 ONLINE 1 3 ONLINE 1 4 ONLINE 1 5 ONLINE 1 6 ONLINE 1 7 ONLINE 1 8 ONLINE 1 9 ONLINE 1 10 ONLINE Zu Simulationszeit 9 empfangt der Router dann die vom Angreifer gesendeten Pakete die Server sind immer noch unbesch ftigt New Time 9 0000000000 Router ROUTER packets to handle 11 Seen D N 1 1 p
130. n kann Durch die Zeitabh ngigkeit kann aber auch dieser Federate noch nicht in die Zukunft voranschreiten solange f r ihn noch Interaktionen und andere RTI Meldungen eintreffen k nnen Durch dieses Zeitverhalten und die Einhaltung von Regeln bei der Versendung von Meldungen an die RTI wird verhindert dass ein Federate in der Zeit den ande ren vorauseilt Dieses Verhalten nennt man bei verteilten Simulationen konserva tiv Ein anderes m gliches Verhalten w re dass jeder Federate m glichst schnell in der Zeit voranschreitet und dann bei Ereignissen die in der Vergangenheit auf treten diese entweder ignoriert oder seine Ausf hrung abbricht und ab dem Zeit punkt zu dem das Event eingetroffen ist wiederholt F r unseren Zweck scheint die konservative Vorgehensweise aber die sinnvollste zu sein Die Anwendung wartet auf die Best tigung dass die RTI f r sie die Zeiteigen schaften gesetzt hat dann kann sie mit ihrer eigentlichen Arbeit beginnen Diese besteht dann aus dem Zyklus Arbeit eines Zeitabschnittes erledigen und dann War ten auf den n chsten Zeitabschnitt Um zum n chsten Zeitabschnitt voranschreiten zu d rfen muss jeder Federate erst um die Erlaubnis daf r bei der RTI bitten Dies geschieht mittels des Aufrufs von timeAdvanceRequest Soll die Simulation beendet werden so muss Intranet seine Teilnahme an der Federation Execution beenden Dies geschieht ber resignFederationExecution Danach versu
131. n mittels ICMP Echo Reply Paketen aus damit ist diese Kommunikation sehr unauffallig Die Weiterentwicklung von TFN zu TEN2k 2 brachte im Wesentlichen eine Verschl sselung der Kommuni kationsdaten mit sich Das Stacheldraht Tool 12 f hrte gegen ber TFN neben Verschl sselung der Kommunikation noch eine automatische Updatem glichkeit der Daemons ein Die Master benutzen nun eine TCP Verbindung um Daten an den Daemon zu ber mitteln Weiter existieren die Tools Shaft 14 und mstream 15 die aber keine wirklichen Neuerungen mehr bringen Vielmehr wurde mit jedem neuen Tool ver sucht die Kommunikationssignaturen zu ver ndern damit das Tool nicht so schnell entdeckt wird 2 6 2 Neuere Methoden Neuere Methoden verzichten auf die direkte Kommunikation Damit IPs nicht im Quellcode festgelegt werden m ssen arbeiten diese Tools mit Vermittlungspunk ten z B IRC Servern So melden sich die auf den Helfern installierten DoS Tools beim Aktivwerden nicht bei einem Master sondern bei einem IRC Server an ber diesen erhalten sie auch die Befehle zum Angriff Die einzige IP die die Tools kennen m ssen ist also die des IRC Servers Auf diese Weise wird bei Entdeckung eines DoS Helfers nicht gleich die Auf deckung gro er Netzwerkteile erm glicht Ebenso ist die Kommunikation eines Rechners mit einem IRC Server nichts Ungew hnliches und normalerweise nicht sch dlich Daher wird die IRC Kommunikatio
132. n von den vielen Firewalls erlaubt Das aktive Ausfiltern der Kommunikation von DoS Tools wird damit sehr er schwert Eine Sammlung von Tools von DDoS Klassikern ber IRC Varianten von Analysen der Tools bis hin zu Programmen zum Aufsp ren installierter Tools ist unter http packetstormsecurity nl distributed zu finden 26 3 MASSNAHMEN GEGEN D DOS ATTACKEN 3 Ma nahmen gegen D DoS Attacken Um D DoS Attacken zu verhindern gibt es grunds tzlich verschiedene Ansatz punkte die man verfolgen kann Man kann versuchen zu verhindern selbst das Opfer einer Attacke zu werden Das ist allerdings nicht so einfach in manchen F llen wie z B bei Flooding Attacken sogar beinahe unm glich Weiterhin soll te man versuchen nicht als unfreiwilliger Helfer bei einer Attacke zu agieren Denn es ist einerseits f r eine Firma nicht gut wenn ihre Rechner andere Rechner angreifen und andererseits k nnte dieses Verhalten von anderen auch nicht zum Helfer zu werden einen Angriff auf die eigenen Server verhindern Oder zumin dest einen Angriff auf Server von denen auch das eigene Netzwerk bzw die eigene Au enkommunikation abh ngt Die letzte M glichkeit gegen DoS Attacken vor zugehen ist die Traffic Beobachtung im Netzwerk selbst die von den Betreibern der Router im Internet gemacht werden k nnte Diese k nnen auff llige Daten str me im Netz gleich herausfiltern und so die berlastung von benutzten Routern und damit auch ma
133. n wir uns um diesen Aspekt keine Gedanken zu machen da der Verkehr des simulierten Netzes nicht so hoch sein wird wie ihn stark frequen tierte Router im realen Internet bew ltigen m ssen Au erdem w rde es f r das Teilnetz welches als Ganzes durch einen Federate dargestellt wird keine Effizienz steigerung bringen diese Funktionen zu trennen Rechner Anbindung ans Internet Abbildung 20 Konzept eines Subnetzes Bei der Konzeption der Subnetze hat sich die Frage gestellt ob es sinnvoll ist das Netz nur aus den Servern und dem Router bestehen zu lassen oder ob zus tz lich eine die Netzstruktur Bussystem Kabel und Switch oder hnliches repr sen tierende Instanz eingef hrt werden soll Die Entscheidung fiel zu Gunsten einer Repr sentierung der Netzstruktur da so viele zus tzliche M glichkeiten simulier bar werden die sonst wegfielen Durch eine solche Instanz kann z B f r Bus Netze BNC eine Kollisionssimulation eingef hrt werden man kann Verz gerungen des 60 7 KONZEPT F R DIE IMPLEMENTIERUNG Netzverkehrs nachbilden etc Auch wenn diese M glichkeiten in dem Prototyp nicht ausgenutzt werden so stellen sie doch Anreize f r zuk nftige Erweiterungen dar Ein weiterer Grund f r diese Entscheidung war dass auf diese Art die Server sich untereinander nicht kennen und ansprechen k nnen m ssen Die Server k nnen also unabh ngiger voneinander agieren F r sie ist es so kein Unterschied ob sie mit einem
134. nachbilden Hierzu wurde ein Konzept angedacht welches einen User als 7 5 Weitere berlegungen 63 eigenst ndigen Federate simuliert Er w rde sich an einem Rechner einloggen und dort seine Arbeit erledigen Man w rde also in der gro en Netzwerksimulation kleine Simulationen f r die Usert tigkeit an Rechnern einbringen Ebenso K nnte man solche User sowohl lokal an einem Rechner simulieren als auch ihnen die M glichkeit geben remote an einem anderen Rechner zu arbeiten Zu diesem Zweck hat der Server einige user spezifische Funktionen erhalten wie einloggen ausloggen Passwort ndern u a Ebenso wurde vorgesehen dass Befehle mit einer UserID des Nutzers aufgerufen werden wobei die UserID 0 f r Systemaufrufe bzw Administrator T tigkeit reserviert war Dieser Ansatz wurde nach einiger Zeit verworfen da er in der verf gbaren Zeit nicht realisierbar war Selbst wenn man den User nicht als Simulation sondern stark vereinfacht als statisch in die Anwendung eingebundene Befehlsfolge pro grammiert ergeben sich daraus eine Vielzahl von Forderungen an den Server der dadurch einfach zu komplex wird Jedes Programm h tte erlaubte Ausf hrungs rechte beinhalten m ssen die sich dann auch noch danach richten wer das Pro gramm installiert hat Daher h tten diese Rechte w hrend der Installation auf dem Server beeinflusst werden m ssen Ein Einbrecher in das System h tte dann auch eine ID erhalten m ssen unter der er w hrend sei
135. nchen Angriff komplett verhindern Hierbei stellt sich nur leider die Frage warum die Routerbetreiber hierf r zus tzliche Kosten in Kauf nehmen sollten wenn sie selbst davon nicht wirklich auch einen Vorteil haben Die n chsten Abschnitte befassen sich mit den vorhandenen Methoden zur Ab wehr von DoS Angriffen Dabei werden zuerst Ma nahmen beschrieben die auf ei nem Rechner zu seinem eigenen Schutz getroffen werden k nnen Danach folgt ei ne Beschreibung wie man verhindern kann als unfreiwilliger Helfer andere Rech ner anzugreifen Zum Abschluss des Kapitels werden Ma nahmen beschrieben die auf Routern und Firewalls irgendwo im Internet oder auch im Heimatnetz des po tentiellen Opfers getroffen werden k nnen um Angriffe gar nicht erst beim Opfer ankommen zu lassen Trotz dieser Aufteilung der Ma nahmen nach ihrer Rolle bei einem Angriff wird einem Systemadministrator die Anwendung aller ihm m glichen Methoden des Schutzes empfohlen Es reicht nicht sich nur gegen eine der Rollen abzusi chern F r genauere Informationen wie man sich gegen SYN und Smurf Angriffe wehren kann wird f r SYN Abwehr auf 8 und f r Smurf Abwehr auf 28 9 und 21 verwiesen 3 1 Verhindern Opfer zu werden Will man verhindern zum Opfer einer DoS Attacke zu werden so gibt es nur we nige wirksame M glichkeiten Denn Protokollschw chen lassen sich im Endeffekt nur durch nderung des Protokolls selbst beheben F t das Handshake bei TC
136. ndung finden 40 5 SIMULATIONSUMGEBUNG 5 1 Begriffe Die Gesamtsimulation deren Teile ber die Laufzeitumgebung miteinander koope rieren nennt man Federation Die einzelnen Teile die zu einer Federation zusammengesetzt werden werden als Federate bezeichnet Diese Federates k nnen eigenst ndige oder auch verteilte Simulationen sein sie k nnen aber auch Interfaces zu Real world Komponenten oder passiven Datensammlern oder Visualisierungskomponenten sein Ein Simulationslauf bei dem eine Federation zur Simulation ausgef hrt wird ist eine Federation Execution Zu einem Simulationslauf braucht man neben einem Satz von Federates die RTI RunTime Infrastructure Laufzeitumgebung deren Spezifikation durch HLA ge geben wird Die RTI ist implementierungsabh ngig d h einzelne Details wie Auf rufparameter genaue Benennung von Funktionen etc k nnen sich von Implemen tierung zu Implementierung unterscheiden Hierzu sei ein Blick in die Referenz der verwendeten Implementierung empfohlen hier RTI NG 1 3 v6 des DMSO Defen se Modeling and Simulation Office Damit die RTI die Kommunikation der Federates verwalten kann muss ein Fe deration Object Model FOM erstellt werden Mit diesem werden die Daten und Events festgelegt die die Federates zum Datenaustausch verwenden k nnen Die ses FOM ist vom Entwickler der Simulation zu erstellen 5 2 Federation Management Damit RTI und Federate kommunizieren k nnen brauche
137. nem Port an so wird das Programm mit den empfangenen Daten benutzt Diese Program me m ssen explizit beendet werden wenn man nicht mehr m chte dass sie laufen 2 Ein Programm wird nachdem es gestartet wurde st ndig ausgef hrt F r un ser Szenario bedeutet dies dass das Programm in jedem Zeittakt vom Server einen Befehl erhalten muss damit es seine anfallende Arbeit erledigt Auch hier ist ein expliziter Befehl zum Abbrechen der Ausf hrung notwendig Zu dieser Sorte von Programm geh ren z B Intrusion Detection Tools 3 Andere Programme werden nur kurzzeitig ausgef hrt Man ruft sie auf sie brauchen eine gewisse Zeit bis sie ihre Arbeit erledigt haben dann beenden sie sich automatisch Dabei k nnen solche Programme regelm ig automa tisch zur Ausf hrung gebracht werden z B per cron unter Unix oder sie werden von einem User gestartet und damit unregelm ig benutzt Diese M glichkeiten sollte unser simulierter Server auch bieten W hrend die ersten beiden M glichkeiten in das Konzept des Servers einflie en ergibt sich bei der dritten ein Problem Wie sollen wir diese Interaktivit t nachbilden Die regelm ige Ausf hrung k nnte man durch ein Programm simulieren welches den erforderlichen Programmaufruf zu einer definierten Zeit hier m sste dann die Simulations Zeit als Referenz verwendet werden ausf hrt Aber wie k nnen wir das unregelm ige Ausf hren wie es ein User machen w rde
138. nen Angriff beendet Ein wirklicher Angreifer k nnte nat rlich weiterhin Angriffe f hren Im Rahmen dieser Arbeit scheint es aber sinnvoll die Simulation des Angreifers an diesem Punkt zu beenden 6 3 Opfermodell 51 Je nach Abstraktionstiefe kann gegebenenfalls noch eine Aufteilung der einzel nen Zust nde n tig werden Z B Angriff unterteilt sich in die Angriffsbefehle an die einzelnen Master Unterschied wenn Master online offline 6 3 Opfermodell Wir werden zun chst einmal ein einfaches allgemein anwendbares Modell eines Opfers aufstellen das nicht speziell auf die Situation des Opfers eingeht So k nnen die Auswirkungen auf die die Nutzer des Opfers sind also in Gegensatz zu Angrei fern legale Anfragen stellen nicht dargestellt werden Dazu sind die Informationen die das Opfer ber sich und seine Umwelt hat zu gering Es sollte daf r ein speziell auf einzelne Server bzw zumindest eindeutige Servergruppen Web Server Mail Server abgestimmtes Opfermodell oder gar ein Opfernetzwerkmodell erstellt werden dem seine Funktion bewusster ist als dem allgemeinen Modell Das Modell eines Opfers welches auf jeden Server eines Netzwerks anwendbar ist nennen wir auch Universal Opfer Das Modell des Universal Opfers ist noch einfacher als das des Angreifers da das Opfer nicht aktiv agiert sondern in unserem Fall nur als passives Element den Miss Erfolg des Angriffs veranschaulichen soll Ein universelles Opfe
139. nen DDoS Angriff durchzuf hren Angreifer Programm Daten geplante Aktion Programms Daten nutzen Schwachstelle aus l l l l l l Ausf hren des l l l l l l l Ausf hren der Aktion l Abbildung 11 Ablauf bei Anwendung eines Exploits 48 6 MODELLE ZUR BESCHREIBUNG VON D DOS 6 2 1 Smurf Angreifer Bei einem Smurf Angriff ist das Verhalten des Angreifers sehr einfach Er beginnt zu einem bestimmten Zeitpunkt mit dem Angriff auf sein Opfer und beendet ihn eine Zeit danach wieder Eventuell greift er auf diese Art mehr als ein Opfer an Wenn der Angreifer keine weiteren Angriffe mehr durchf hrt wird seine Betrach tung beendet Abbildung 12 Start der Angreifersimulation Angriff 0 auf ein Opfer Keine weiteren Angriffsziele Ende der Angreifersimulation Abbildung 12 Angreifer bei Smurf Zerlegen wir dieses Modell weiter Ein Angriff besteht aus der Auswahl eines Opfers und der Entsendung vieler Ping Pakete auf die Broadcastadresse eines m g lichst gro en Netzwerks welches Broadcast Pings beantwortet Dieses Netzwerk sollte der Angreifer also vor dem Angriff ausfindig machen Siehe hierzu Abbil dung 13 6 2 2 DDoS Angreifer mit Netzwerkaufbau Um den Angreifer sowohl beim Aufbau seines Netzwerkes als auch beim eigent lichen Angriff zu simulieren brauchen wir ein Modell das s mtliche Phasen die Aktivit ten im Internet beinhalten ber cksichtigt siehe 2 5 2 und sie sequentiell abarbei
140. nen soll das Interface Program Abb 29 implementieren Dazu geh ren Funktionen zum Starten start und zum Stoppen stop von Diensten Im Falle eines Servers sollte z B das Programm bei start auf einem bestimm ten Port des Servers registriert werden um es ansprechbar zu machen und es sollte in den Zustand LISTENING gebracht werden Denn ein Server kann nur so zur Ausf hrung gebracht werden Bei stop m sste der Port unregistriert werden und das Programm wieder den Zustand STOPPED erreichen Aber auch andere dauerhaft laufende Programme wie z B eines zur Eindringlingserkennung k nnen durch diese Funktionen gestartet und gestoppt werden Sie sollten aber als Nicht Serverdienst den Zustand RUNNING erhalten um zu jedem Zeittakt vom Server ausgef hrt zu werden Ist ein Programm nicht f r dauerhafte Ausf hrung gedacht so sollten die Funktionen start und stop einfach nichts ausf hren Die Funktion exec ist f r die Ausf hrung von Nicht Diensten gedacht Ei ne Exec Ausf hrung sollte das Programm automatisch nach einiger Zeit wieder den Zustand STOPPED erreichen lassen w hrend ein von start aufgerufenes Pro gramm nur durch einen Reboot oder stop wieder in diesen Zustand gelangt Man kann dieses System aber auch dazu missbrauchen eine l nger andauernde Ausf hrung des Programms zu simulieren Dazu m ssten in der Funktion exec die Parameter zur Ausf hrung dauerhaft gesetzt werden dam
141. nerreichbarkeits Problemen im Internet f hren k nnen Um die gestellte Aufgabe zu l sen haben wir uns zuerst mit dem Begriff der DoS Attacken vertraut gemacht und uns mit einigen M glichkeiten der Abwehr solcher Angriffe befasst Wir haben uns weiter mit den Grundlagen der Simula tion des Internets besch ftigt und mit den Problemen die eine Internetsimulation aufwirft F r die Programmierung des Simulations Prototyps steht eine Laufzeitumge bung gem der HLA Spezifikation zur Verf gung Wir haben einen berblick ber die Funktionalit ten gegeben die wir bei der Verwirklichung unserer verteil ten Simulation einsetzen k nnen Wir haben ihre M glichkeiten beschrieben und auch ihre praktische Verwendung erl utert Mit den so gewonnenen Erkenntnissen haben wir Modelle erstellt die ein Ab bild realer Netzwerkkomponenten und DoS Abl ufe darstellen Das Verhalten der Implementierung des Prototyps muss sich dann an diesen Modellen ausrichten Zur Darstellung der Modelle haben wir UML Diagramme verwendet Wir haben eine Konzeption f r die Simulation erstellt die als Basis f r die Implementierung des Prototyps in C dient Wir haben ein modulares System konzipiert damit Variabilit t und Erweiterbarkeit des entstehenden Prototyps nicht behindert werden Weiter sind wir auf konzeptuelle Fehlschl ge eingegangen und haben erkl rt warum wir welche Entscheidung in Bezug auf das Konzept gef llt haben Nach der Erl uterung des K
142. nes Einbruchs agieren kann Und es h tten alle Aktionen wie Installation Ausf hrung von Programmen immer wie der darauf berpr ft werden m ssen ob sie berhaupt stattfinden d rfen usw Daher wurde das Userkonzept verworfen und die Ausf hrung von Befehlen auch ohne eine Angabe der UserID erm glicht Die Server spiegeln so etwa ein Windows 98 System wider bei dem jeder User alles darf Allerdings kommen hier noch Serverf higkeiten hinzu 7 5 Weitere berlegungen Nachdem wir nun die Komponenten aus denen die Netzwerke bestehen sollen beschrieben haben kommen wir noch einmal auf die Gesamtsimulation zur ck Durch das Verwenden von Teilnetzen k nnen wir auch Angreifer und Opfer als solche Teilnetze darstellen Die Basis von der der Angreifer seinen Angriff ausf hrt ist ein Rechner wie jeder andere in den verschiedenen Teilnetzen Er hat nur andere Programme installiert aber er ist genauso angreifbar wie jeder andere Rechner auch Das Opfer brauchen wir gar nicht als spezielles Opfer zu entwerfen wenn wir mit jedem Netzrechner gleich die Funktionen bereitstellen die ein Angreifer f r seinen Angriff ben tigt Damit k nnen in der Simulation beliebige Rechner als Opfer ausgew hlt werden 64 7 KONZEPT F R DIE IMPLEMENTIERUNG Um die Aufrufdetails der RTI zu verstecken wird eine Klasse entworfen die den Servern Routern oder dem Netz diese Funktionalit t bietet Wenn allerdings mehr als die bereitgestellten Funkt
143. ngriffsnetzwerk oft selbst aufbau en Betrachten wir ein Master Daemon Netzwerk so erfolgt der Netzaufbau im Wesentlichen in sieben Schritten 1 Der Angreifer bernimmt auf einem Rechner mit vielen Usern einen Account den er als Basis f r die weitere Arbeit verwendet Wie er diesen Account er h lt ob er ihn legal als angemeldeter User er ffnet oder ob er den Account ei nes Anderen daf r missbraucht indem er sich fremde Passw rter erschleicht oder auf sonstigem Wege diesen Account knackt sei hier nicht von Interesse 2 5 Aufbau eines DDoS Angriffs 21 Angreifer Router Router Master Systeme Daemon Systeme Abbildung 5 Beispiel Master Daemon Netzwerk Auf diesem Rechner lagert er die verschiedenen Tools Skripte und Netzscan ner die er im weiteren Verlauf des Netzaufbaus braucht Damit die Aktio nen des Angreifers nicht auffallen sollte dieser Rechner m glichst eine hohe Bandbreite besitzen Die erh hten Netzwerk Aktivit ten eines Einzelnen fal len um so weniger auf je mehr auch andere Personen von dem Rechner aus im Internet besch ftigt sind Ebenso k nnte der Angreifer in vielen F llen mit seinem eigenen Rechner falls dieser WLAN M slichkeiten bietet sehr viele offene WLAN Netze fin den die ihm das Arbeiten im Internet erm glichen In diesem Fall w re es nicht einmal n tig sein Handeln besonders unauff llig zu gestalten da der Angreifer bei Bedarf oder auch zum Selbstsch
144. ngt wurde Ping Antwort E AA Ping Antwort p Angreifer Opfer Ping auf Broadcastadresse Ping Antwort Absendeadresse Opfer Ping Antwort er 732 gt S Ping Antwort ck Abbildung 1 Smurf Attacke Weitere Informationen zu Smurf betreffend Vorgehensweise und Abwehrma nahmen sind in 21 zu finden Heise Online berichtete k rzlich von einer modernen Variante dieses Smurf Angriffs bei der Online Gameserver f r eine Attacke hnlich der Smurf Attacke verwendet werden 47 Diese Server bearbeiten ber UDP normalerweise Infor mationsanfragen wie z B die nach der Zahl der angemeldeten Spieler Da sich bei UDP die Absendeadresse nicht berpr fen l sst Kann der Angreifer mittels Spoofing den Angriff auf sein Opfer lenken Durch Kombination verschiedener Befehle an den Server kann der Angreifer einen Verst rkungseffekt auf etwa das 400 fache seines Aufwands bekommen Somit gen gt eine einfache 56Kb s Mo demverbindung um zwei T1 Standleitungen mit jeweils 1 56Mb s auszulasten Sie he hierzu auch 28 2 4 2 SYN Flooding Das SYN Flooding ist ein Angriff der eine Schw che im TCP Protokoll ausnutzt TCP ist ein verbindungsorientiertes Protokoll Daher muss das Protokoll sicherstel len dass alle Pakete der Kommunikation auch wirklich beim Partner ankommen Aus diesem Grund best tigen die Kommunikationspartner immer welche Pakete sie erhalten haben Hierzu ist eine spezielle Initialisierung der V
145. nierte Modell der SYN Attacke ist in Abb 9 zu sehen 46 6 MODELLE ZUR BESCHREIBUNG VON D DOS SYN Attack Paket korrekte TCP Pakete weitere Ressourcen f r werden bearbeitet Verbindungsaufbau Anzahl freier Ressourcen f r werden belegt Verbindungsaufbau unver ndert Bereit SYN Attack Paket Durch Verbindungsaufbau alle Ressourcen f r neue oder TimeOut werden Ressourcen Verbindungen belegt f r neue Verbindungen frei SYN Attack Z weitere TCP Pakete werden nicht mehr bearbeitet Abbildung 9 Verhalten bei einer SYN Attacke Bei Smurf ist das Verhalten hnlich betrifft aber die gesamte eingehende Kom munikation unabh ngig von dem verwendeten Protokoll oder dem Status der Ver bindung F r die Modellherleitung werden folgende Annahmen getroffen die ein vereinfachtes Abbild der Realit t schaffen Die Bearbeitung eines eingehenden Pa kets beansprucht einen Server 1 n Sekunde Pro Sekunde kann dieser Rechner also n Pakete verarbeiten Kommen mehr als diese n Pakete an so k nnen nicht mehr alle bearbeitet werden Der Rechner ist ausgelastet Das Modell soll also festlegen dass ein Rechner pro Zeiteinheit h chstens n Pakete bearbeiten kann Alle weiteren Pakete werden nicht ber cksichtigt Ist die Zeiteinheit um so kann der Rechner wieder n Pakete bearbeiten bevor er die wei teren wegwirft usw F r das Modell der Smurf Attacke siehe Abb 10 In Kapitel 2 wurde erw hnt dass bei einer DDoS Attacke der Angreifer mit Hil fe
146. nsequenzen dieser Ver teilung etwas genauer Im Unterschied zum normalen DoS Angriff wird bei der DDoS Attacke das Op fer nicht direkt vom Angreifer attackiert sondern indirekt Der Angreifer gibt den Rechnern auf die er seinen Angriff verteilt hat ein Zeichen dass sie angreifen sol len und diese f hren dann je einen DoS Angriff auf das Opfer aus Hierzu benutzt der Angreifer ein Angriffsnetzwerk ber das der Angriff l uft Dies dient einerseits dazu die R ckverfolgung des Angriffs und damit die Entdeckung des Angreifers zu erschweren Aber es gibt noch einen anderen wichtigen Grund Durch dieses Netzwerk kann der Angreifer die Netzauslastung des Opfers erh hen ohne selbst eine hohe Bandbreite besitzen zu m ssen Es gibt mittlerweile viele M glichkeiten solche Netzwerke zu etablieren In dieser Arbeit wird allerdings mehr auf die klassischen Varianten der DDoS Angriffe eingegangen Zu diesen geh ren fertige Angriffs Tools wie Trinoo Tribe Flood 2 3 Angriffspunkte f r DoS Attacken 15 Network Stacheldraht oder Shaft siehe hierzu 2 6 die auch fiir Personen ohne spezielles Fachwissen anwendbar sind DDoS Attacken sind daher nicht auf Experten als Angreifer beschr nkt 2 3 Angriffspunkte f r DoS Attacken Es gibt f r den Angreifer drei Arten von Ansatzpunkten f r seinen Angriff mit denen er eine Auslastung des Opfers erreichen kann Diese beruhen auf folgenden Problemen e Programmfehler
147. nt int int int int int int int B FUNKTIONSREFERENZ execBefehl char n list lt char gt F hrt einen Befehl namens n aus mittels Programm exec und ber gibt diesem die angegebene Argumentliste execBefehl int id char list lt char gt F hrt den als zweites Argument angegebenen Befehl als User id aus und ber gibt ihm die Argumentliste startService char Startet einen Service Programm start des angegebenen Namens mit leerer Argumentliste startService char list lt char gt Startet einen Service des angegebenen Namens mit der angegebenen Argu mentliste startService int char Startet als User mit der ID des ersten Arguments den Service mit dem Namen aus Argument 2 startService int char list lt char gt Der User mit der ID aus Argument 1 startet das Programm mit dem Namen aus Argument 2 und der Parameterliste aus Argument 3 stopService char Ruft Programm stop des Programms auf das unter dem Namen der in Argument 1 angegeben wurde l uft login int char int B 9 Versucht den User mit der ID aus Argument 1 mit dem Passwort aus Argu ment 2 auf dem System einzuloggen logout int Meldet den User mit der angegebenen ID vom System ab Klasse Tcon Tcon Erzeugt ein Objekt vom Typ Tcon Dieses Objekt ist f r die Verwaltung der eingehenden Verbindungen zust ndig es merkt sich wieviele nicht vollst n dig aufgebaute V
148. o sollte man gerade bei diesen Ga meservern eine Legitimation der Nutzer verlangen Es k nnten z B nur am Game server gerade angemeldeten Usern die Statusabfragen erlaubt werden Wenn man f r eine Anmeldung eine TCP Verbindung verwendet w rde das den m glichen Opferbereich schon einschr nken Opfer k nnten dann nur aus dem Userkreis des Gameservers ausgew hlt werden Man sollte heutzutage auch daran denken dass man sich durch Unachtsamkeit selbst zum Helfer machen kann Sobald auf einem Rechner mit Internetverbindung aktive User erlaubt sind die Mails lesen und Dateien und Programme aus dem Internet auf den Rechner laden so sind diese User eine potentielle Gefahr f r die Sicherheit des Rechners Denn wenn ein Mailagent Viren verteilen und Dateien auf dem Rechner l schen oder ver ndern kann so kann er auch DoS Tools installieren Oder statt dem virenbehafteten Bildschirmschoner oder dem 0190 Dialer l dt man sich freiwillig ohne es zu wissen das DoS Tool eigenst ndig auf den Rechner Generell sollte man also Methoden verwenden mit denen man a verhindern kann dass unbeabsichtigt Programme installiert werden k nnen oder die b be wirken dass neue Programme und nderungen an Daten und Konfigurationen zu mindest sofort bemerkt werden Ein Verfahren f r a ist die Verwendung von read only Filesystemen Programme zur Einbruchs Erkennung Intrusion Detec tion Tools IDT versuchen an Punkt b zu greifen 30 3 MASSNAHMEN GEG
149. o wird die Funktion inc von Tcon benutzt um diesen richtig in die Liste einzusortieren und damit die Anzahl der Verbindungsversuche korrekt zu erh hen Dies wird aber nur gemacht solange der Maximalwert nicht berschritten wurde sonst hat die Funktion keine Wirkung Wird eine Verbindung in die Liste der Versuche aufgenommen so wird sie dem Listenelement mit der eingetragenen Zeit Zeitartue CON_TIMEOUT zugeordnet CON_TIMEOUT ist dabei ein in server h definierter Wert der angibt wielange ein Verbindungsaufbau dauert bevor er durch einen TimeOut beendet wird Exi stiert noch kein Listenelement mit dieser Zeit so wird es neu erzeugt Mit den Kenntnissen wie Tcon arbeitet k nnen wir nun genauer auf die Be arbeitung der TCP Pakete eingehen Wird ein TCP Paket bearbeitet so wird zu n chst gepr ft ob der geforderte Port belegt ist Wenn nein wird ein ICMP Port unreachable an den Sender zur ckgeschickt Wenn ja m ssen wir das Paket weiter untersuchen Dazu wird gepr ft ob das SYN Bit gesetzt ist Wenn ja m ssen wir mit der Tcon Funktion con_possible abfragen ob wir noch neue Verbindungen an nehmen d rfen Ist dies nicht der Fall so liegt eine SYN Attacke vor Das Paket wird nicht weiter bearbeitet das n chste Paket ist dran K nnen wir das Paket noch annehmen so unterscheiden wir Ist das ACK Bit nicht gesetzt so ist dieses Paket Teil einer SYN Attacke wir rufen die inc Funktion unseres Tcon Objektes
150. ob ein Programm STOPPED gerade ausgef hrt wird ob es an einem Port lauscht oder ob RUNNING LISTENING es nur installiert ist aber nicht benutzt wird Abgeschlossen werden die Aufz hlungstypen durch die De enum finition von TStates Damit werden die m glichen Zust nde TStates i Pee SURE definiert die ein Server annehmen kann Darunter sind die Nor OES DINE malzust nde wie Online und Offline aber auch der Zustand Out OUTOFORDER of order der angibt dass der Server auf irgendeine Art und Weise so ausgelastet ist dass er normale Anfragen nicht mehr beantworten kann Das kann durch eine SYN Attacke ausgel st werden aber auch durch eine komplette Auslastung der Bandbreite Wie hierbei zu erkennen ist sind diese Zust nde genau die die im einfachen Opfermodell verwendet werden Damit k nnen wir auch ohne ein spezielles Opfer zu simulieren einen Angriff auf jeden Rechner der Netzwerke verfolgen Der letzte Basistyp IP ist eine richtige Klasse die das in unserem Prototyp verwendete Aquivalent zu einer IP Adresse definiert Die IP Adresse wird dabei als int gespeichert wobei die letzten 8 Bit fiir die Hostadresse die 8 Bit davor fiir die NetID verwendet werden Dies gestattet unserem Prototyp theoretisch 256 8 2 Netzwerk 69 Teilnetze zu simulieren die jeweils bis zu 255 Hosts haben k nnen Die HostID 255 wird als Broadcast Adresse verwendet Um einfacher auf HostID und NetzID der IP Adresse zugrei
151. on nachvollziehen zu k nnen Kapitel 4 zeigt die Grundlagen auf die zur Simulation des Internets im Gene rellen und von DoS Angriffen im Speziellen gebraucht werden Kapitel 5 beschreibt die Laufzeitumgebung des HLA Tools die f r die Imple mentierung des Prototyps als Simulationsumgebung verwendet wird In Kapitel 6 werden die f r die Simulation entwickelten Modelle erl utert Diese beschreiben wie sich ein Angriff auf den angegriffenen Rechner auswirkt und wie sich die am Angriff Beteiligten verhalten Kapitel 7 entwickelt das Konzept nach dem die Implementierung erfolgt ist In Kapitel 8 erfolgt eine Beschreibung der Implementierung des Prototyps Ne ben Funktionsweisen der implementierten Klassen werden auch Designentschei dungen und konzeptuell bedingte Aspekte beschrieben die bei der Implementie rung ber cksichtigt werden mussten Kapitel 9 zeigt dann die mit dem Prototyp durchgef hrte Simulation von DoS Attacken Anhand dieses Simulationsbeispiels wird die Arbeitsweise des Prototyps deutlich gemacht Hier erfolgt auch eine Anleitung wie die dargestellten Meldun gen der laufenden Simulation zu interpretieren sind In Kapitel 10 geben wir Hinweise wie man den Prototyp weiterentwickeln k nnte Kapitel 11 fasst die Ergebnisse der gesamten Arbeit noch einmal zusammen Anhang A erl utert wie die Ausf hrung des Prototyps gestartet wird Anhang B beschreibt die im Prototyp verwendeten Klassen Es werden die Funkti
152. onen und ihre Anwendung genauer erl utert 14 2 DENIAL OF SERVICE DOS 2 Denial of Service DoS Um einen Angriff simulieren za k nnen muss man verstanden haben wie der An griff funktioniert Man sollte dazu sowohl den zeitlichen Ablauf des Angriffs ver standen haben als auch die Mechanismen die im Lauf der Attacke verwendet wer den Ebenso ist es wichtig sich das Ziel des Angriffs zu verinnerlichen also die beabsichtigten Auswirkungen des Angriffs auf das Opfer 2 1 Denial of Service Angriff Eine Denial of Service Attacke DoS Attacke hat zum Ziel die Verfiigbarkeit be stimmter Dienste eines Opfer Servers zu st ren Dies wird erreicht indem man z B den Opferrechner so mit falschen Anfragen auslastet dass die ordentlichen Anfragen nicht mehr oder nur noch sehr unzureichend abgearbeitet werden k nnen Dabei werden Ressourcen des Opfers wie Speicher oder Prozessor en tiberlastet Eine weitere M glichkeit ist dass man den Server gar zum Absturz bringt Auch dann sind seine Dienste nicht mehr verf gbar Die Sicherheit der auf dem Server gelagerten Daten zu untergraben sei es in Bezug auf Vertraulichkeit oder Integrit t ist nicht das Ziel von DoS Angriffen 2 2 Distributed Denial of Service DDoS Das englische Wort distributed hei t im deutschen verteilt Im Zusammenhang mit DoS bedeutet dies dass man den Angriff auf das Opfer auf mehrere Rechner verteilt die das Opfer attackieren Beleuchten wir die Ko
153. onzepts haben wir dann die Umsetzung dieses Kon zepts zu einer Implementierung beschrieben Es wurde gezeigt wie welche Design Entscheidungen in der Implementierung umgesetzt wurden und welche zus tzlichen Forderungen sich dabei f r die Implementierung ergeben haben Nach der Beschreibung der Implementierung haben wir anhand eines Beispiels gezeigt wie der Prototyp arbeitet wie er das Geschehen w hrend des Simulations laufes darstellt und wie man das Dargestellte interpretieren muss Wir haben Anregungen f r die Weiterentwicklung des Prototyps gegeben denen man in zuk nftigen Arbeiten nachgehen kann Diesen kann der hier entwickelte Prototyp als Grundbaustein dienen 127 A Ausf hrung des Prototyps A 1 Verwendete Software F r die Implementierung des Prototyps wurde folgende Software verwendet e Betriebssystem Linux Debian GNU 3 0 bzw SuSE 8 0 e Gnu C Compiler gcc version 3 0 4 e RTI 1 3NGv6 fiir RedHat7 2 1386 und gcc 3 0 2 optimiert fiir Multi Threading e GNU Make version 3 79 1 A 2 Hinweise zur Installation der RTI Das Installationsskript der RTI ist auf die RedHat Distribution 7 2 angepasst Um es unter SuSE installieren zu k nnen ist deshalb eine Ab nderung des Skriptes notwendig e Das Skript verwendet den Befehl uncompress d Dieser Befehl ist auf der verwendeten SuSE Distribution nicht vorhanden kann aber problemlos durch den Befehl compress d ersetzt werden der die gleiche Funktion ausfiihrt
154. poofed IP ping to 1 255 Spoofed IP ping to 1 255 Spoofed IP pin 1 255 Spoofed IP P E pin d FU pin N k k k k k k k N Q O OO OO a OO WQ ct O pin Net finished Zu Simulationszeit 9 bis 11 passieren nur noch die Angriffspakete den Router Bei Zeittakt 12 erh lt der Router dann wieder zwei Pakete mehr Neben den An griffspaketen treffen die Antworten auf die Ping Anfragen ein Diese werden zum Angreifer weitergeleitet und treffen zu Zeitpunkt 12 dort ein New Time 12 0000000000 Router ROUTER packets to handle 12 Kee ira 3 1 packets to handle 0 Befehl smurf wird ausgef hrt auf 3 1 ping to 1 255 Spoofed IP 2 ping to 1 255 Spoofed IP ping to 1 255 Spoofed IP ping to 1 255 Spoofed IP ping to 1 255 Spoofed IP N N DN NO 112 9 BEISPIELLAUF EINER DDOS SIMULATION ping to 1 255 Spoofed IP ping to 1 255 Spoofed IP ping to 1 255 Spoofed IP ping to 1 255 Spoofed IP ping to 1 255 Spoofed IP N N NN NH Net finished Attack finished Bei Zeitpunkt 12 sendet der Angreifer das letzte Mal Angriffspakete Zu Takt 13 zeigt er keine Aktivit ten mehr Der Router muss dennoch die Pakete die der Angreifer den Takt davor abgeschickt hat bearbeiten Die zwei Pakete die Rechner 3 1 erh lt sind die Ping Replys New Time 13 0000000000 Router ROUTER packe
155. poofings arbeiten bei der die Absendeadresse des Opfers anstatt der des wirklichen Absenders im Paket ange geben wird Eine Firewall die den Ausgangsverkehr aus dem Intranet berwacht sollte an dieser Stelle verhindern dass offensichtlich gef lschte Absendeadressen das Intranet verlassen Pakete die nicht aus dem eigenen Netz stammen k nnen da ihre IP Adresse nicht in das Netz passt sollten von der Firewall verworfen werden statt sie in das Internet weiterzuleiten Diese Technik wird als egress filtering z B 22 bezeichnet Gef lschte Adressen die innerhalb des Netzes g ltig sind kann man auf diese Weise nicht abfangen W hrend f r diese Art der Filterung schon ein einfacher Paketfilter ausreichend ist gibt es auch Filterkriterien die h here Anforderungen an eine Firewall stel len So kann man dann auch Pakete mit beispielsweise einer ung ltigen Kombina tion von TCP Flags ausfiltern Zustandsbasierte Filter oder auch Inhalte auf Sinn oder Protokolle bestimmter Dienste auf Korrektheit untersuchen application level gateway oder Proxies Genauere Informationen zu den M glichkeiten sind in g n giger aktueller Literatur zu Firewalls oder Netzwerksicherheit nachlesbar z B auch 6 Kapitel 4 16 Kapitel 11 1 Diese Techniken kann man auch auf das Zielnetz des Angriffs anwenden Hier bei wird allerdings aus egress filtering ingress filtering Statt ausgehendem http www trusteddebian org 32 3 M
156. r das Einhalten bestimmter Regeln notwendig Wie schon beim Schutz vor dem Opferwerden ist auch hier das Einspielen von Sicherheitsupdates und Bugfixes zum schnellstm glichen Zeitpunkt nach Erschei nen eine einfache M glichkeit das Risiko zu verkleinern Und auch hier sollte man sich bei problembehafteten Diensten und Programmen ohne Fix entscheiden ob man den Dienst nicht doch deaktivieren bzw das Programm deinstallieren kann W hrend die gef hrlichen Bugs f r DoS Opfer solche sind die DoS Attacken beg nstigen sind die zur Helferrekrutierung verwendeten eher Buffer Overflows 26 bei denen der Angreifer durch geschicktes Manipulieren des Stacks des Rech ners die M glichkeit erh lt Befehle auf dem Rechner auszuf hren oder auf Daten zuzugreifen auf die er sonst keinen Zugriff h tte Neben den Sicherheitspatches die solche Buffer Overflows in betroffenen Implementierungen von Programmen und Protokollen beheben gibt es aber noch M glichkeiten sich generell gegen die Auswirkungen von Buffer Overflows zu wehren Um zu verhindern dass der Angreifer die durch Manipulation auf dem Stack ab gelegten Daten ausf hren kann kann man den Zugriff auf den Stack mit bestimmten Bits einschr nken Es gibt ein Bit f r Stack lesbar und eines f r Stackcode darf ausgef hrt werden Wenn nun die Bereiche des Stacks in denen Daten und nicht 3 2 Schutz vor dem Helferwerden 29 Programmteile liegen als nicht ausfiihrbar markiert
157. r installiert sind Pakete an andere Rechner verschicken k nnen Es erfolgt die Angabe des Absende Ports der Ziel IP des Zielports des Protokolls und des Inhalts des Paketes Da keine Absendeadresse angegeben wird wird automatisch die korrekte IP des Rechners als Absende IP verwendet Selbst wenn das Datenfeld leer sein sollte wird hier eine Verbindung mit Datenaustausch angenommen Alterna tiv kann sonst die Funktion connect verwendet werden sendTo IP fip int fport IP int Protocol char Wie zuvor aber durch Angabe einer expliziten Absende IP erster Parameter kann so ein Paket mit gespooftem Absender erzeugt werden connect int fport IP ip int tport Mit dieser Funktion kann ein Connect auf einen Port eines anderen Rech ners gemacht werden Bei einem Connect ist keine falsche Absendeadresse B 8 int int Klasse Server 139 m glich Dazu k nnte aber sendTo mit Angabe einer falschen Adresse benutzt werden getHostID Liefert dem Aufrufer der Funktion die HostID des Rechners zur ck getNetID Gibt dem aufrufenden Programm die NetzID des Servers zur ck install Program Installiert das bergebene Programmobjekt als Programm auf dem Server install std string int Installiert ein Programm von Typ des bergebenen Strings auf dem Server Als Programmname wird hierbei der Klassenname des Programmes gew hlt install std string char in
158. r kann folgende Zust nde einnehmen e offline Der Rechner ist vom Netzwerk aus nicht erreichbar In der Regel ist dies w hrend Wartungsarbeiten oder nach einem Absturz der Fall e working Das Opfer befindet sich in funktionsfahigem Zustand d h es ist online und bietet seine Dienste an e out of order Der Opferrechner ist tiberlastet weil er gerade angegriffen wird Aus die sem Zustand kann das Opfer in den Working Zustand iibergehen wenn der Angriff beendet wird und das Opfer danach wieder normalen Betrieb errei chen kann Sollte das Opfer w hrend des Angriffs abstiirzen so wird es als n chstes in den Zustand Offline tibergehen um zu zeigen Dieser Rechner ist nicht mehr vom Netz aus zu erreichen Sollte das Opfer nach Beendigung des Angriffs nicht in den normalen Betrieb zuriickkehren k nnen weil Teile des Systems durch den Angriff ausgefallen sind so wird es solange in out of order bleiben bis ein Reboot erfolgt Durch diesen wird wieder Betriebsbe reitschaft hergestellt 52 6 MODELLE ZUR BESCHREIBUNG VON D DOS Das Diagramm zu diesem Universal Opfer Modell ist in Abbildung 15 darge stellt Start der Simulation Working Ende DoS Attacke kein Schaden am System Reboot DoS Attacke Systembedingte Reboot Downtime offline out of order Abbildung 15 Zustandsdiagramm des Opfers Absturz Solange man die Angriffsauswirkungen nicht genauer untersuchen will reicht dieses Modell vollkommen aus
159. r neuer Klasse mit Routerfunktion nicht zu wissen RTlhandler tellNewInstall ip IP int tellOffline ip IP int tellOnline ip IP int tellOutofOrder ip IP int 4 tellStatus sendPacket packet Packet int sendPacket to Internet Meldung an die RTI Abbildung 42 Der RTThandler wird von Server und Router gebraucht Die beiden anderen Interaktionen geben den Status der Netzwerkserver an die RTI weiter Dazu werden von den Servern die Handler Funktionen 8 3 Implementierte Programme 95 tellOnline tellOffline oder tell0utofOrder benutzt um eine Interaktion der Klasse ServerStatus zu versenden Diese hat als Inhalt die IP des aufrufenden Servers angegeben als Parameter der Funktion sowie seinen Zustand von Typ TStates als String Die Interaktion ServerNewinstall die ei ne Neu Installation eines Servers meldet und dabei die IP des neu installierten Ser vers als Mitteilung an die RTI schickt wird durch den Aufruf der Handler Funktion tellNewInstall eingeleitet 8 3 Implementierte Programme Es wurden zu Test und Simulationszwecken einige Programmklassen geschrieben die nun erl utert werden Diese Klassen sind alle Erben von Program 8 3 1 IDT Die Klasse IDT dient als Beispielimplementierung fiir ein Intrusion Detection Tool Beim ersten Start des Programms durch start wird eine Referenzliste mit den auf dem Server laufenden Programmen erzeugt und gespeichert Bei j
160. rbeiten Zahlreiche Sonderf lle die in wirklichen Netzwerken auftreten k nnen beispiels weise durch Race Conditions werden hierbei meist unber cksichtigt bleiben sind aber auch im Rahmen einer solch visualisierenden Simulation nicht von entschei dender Bedeutung Wer Simulationsziele verfolgt die genauere Darstellung von Protokollen und physikalischen Eigenschaften des Internets verlangen sollte auf bestehende Netz werksimulatoren zur ckgreifen Diese bieten oft schon Implementierungen der g n gigen Protokolle an so dass man sich auf die anderen Aspekte der Modellierung konzentrieren kann Bekannte Simulatoren sind der Netzwerksimulator ns oder das Simulationstool x Sim vgl 5 Diese bieten sogar die M glichkeit reale Hardware in die Simulation einzubeziehen Man k nnte also z B einen Angriff simulieren und ihn dann auf einen realen Server als Opfer anwenden Oder man k nnte ein echtes DoS Tool benutzen um einen Angriff in ein simuliertes Netz zu schicken So werden gute Analysem glichkeiten f r Effizienz und Unterschiede der Tools geboten F r unsere Simulation jedoch ist ein solcher Netzwerksimulator eher ungeeig net Protokollverhalten und Effizienzbestimmungen von Implementierungen sind mit einem Netzwerksimulator gut m glich aber schon die Interpretierung der Er gebnisse ist eine Kunst Eine gut verst ndliche Pr sentation die auch von Personen ohne gro es Fachwissen nachvollziehbar ist ist damit
161. reifer aber auch dem System seinen Angriff als nor males Verhalten beibringen In beiden F llen k nnte aber auch ein User Fehlalarm 3 3 Als Routerbetreiber DoS Attacken verhindern 31 ausl sen da er sich trotz legaler Arbeit anders verh lt als das System es vorher sieht Weitere Informationen k nnen 6 Kapitel 12 entnommen werden Anstatt diese vielen Einzelma nahmen anzuwenden gibt es auch Bestrebungen Sicherheitsfunktionalit t im Paket anzubieten Hierzu z hlt das Projekt Trusted Debian Linux das viele Sicherheitsfunktionen bietet unter anderem eingebaute Intrusion Detection Funktionalit t und Sicherheit gegen Buffer Overflows 49 3 3 Als Routerbetreiber DoS Attacken verhindern Ein wichtiger Teil der DoS Bek mpfung kommt der Analyse und Filterung von Durchgangsverkehr in Routern zu Hierbei gilt ein Prinzip Man sollte versuchen nicht legitimen Netztraffic so weit wie m glich an seiner Quelle abzufangen damit jeder weitere Router auf der Strecke zum DoS Opfer nicht unn tig belastet wird Der Weg eines IP Pakets beginnt beim Absender Dieser schickt das Paket sofern es nicht in seinem Intranet lokal versendet wird an einen Router Dieser Router bildet in der Regel den bergang des Intranets zum Internet An diesem bergang ist deshalb der Einsatz einer Firewall zu empfehlen Anhand der Beispiele der Smurf 2 4 1 und der SYN Attacke 2 4 2 ist zu er kennen dass viele DoS Angriffe mit der Technik des IP S
162. rem interpretieren lassen der unter dem Schlagwort Steigerung der Sicherheit sein Produkt vermarkten will Auch die Benutzerfreundlichkeit der Simulation kann noch verbessert werden Es sollte ein Framework entwickelt werden in dem man auf einfachem Wege ver schiedene Szenarien zusammenstellen kann Dazu w rde sich eine Oberfl che an bieten mit der die Netzwerke verwaltet werden k nnten Erst w rde man seine Net ze designen den Angreifer und das Opfer w hlen und verschiedene andere m gli che Entscheidungen ber die Konfiguration des Szenarios treffen Dann w rde man mit der Option Simulation starten die Ausf hrung der Simulation beginnen Gegen eine solche Anwendung spricht aber dass sie die verteilte Ausf hrung der Simulation behindern w rde Wie bringt man einfache Konfigurierbarkeit die M glichkeit der verteilten Simulation und das Starten der Federates auf einfache Weise unter eine Hut Wenn man jeden Federate mit einer eigenen Oberfl che f r die Konfiguration ausstattet die manuell bedient werden muss kann man kaum gro e Szenarien entwerfen Jeden Federate mit einer bestimmten Konfiguration zu versehen und so eine Sammlung von vielen statischen verschiedenen Teilen zu haben wird zu un bersichtlich Daher erscheint es sinnvoll Federates mit Konfigu rationsfiles aufrufen zu k nnen Eine interessante Anwendung w re ein interaktiver Federate z B ein interakti ver Angreifer oder ein interaktives Netzwerk
163. rewall zur Ver hinderung von Smurf zeigen Dazu werden wir zun chst ein Szenario erstellen das ohne Gegenma nahmen einen solchen Angriff erfolgreich zul sst 9 1 Die Beschreibung der Simulation erfolgt dazu in Abschnitt 9 2 In Abschnitt 9 3 wer den wir eine leicht abgewandelte Simulation durchf hren bei der wir mittels einer Firewallregel verhindern dass der Angreifer mit seiner Attacke erfolgreich ist Da bei werden wir die n tigen Firewallregeln darstellen und auf die Unterschiede zum ersten Simulationslauf eingehen 9 1 Szenario F r die Simulation des Smurf Angriffs ben tigen wir 3 Federates den Smurf Angreifer und zwei Intranet Federates eines als Opfernetz das andere als Amplifier Netz welches den vom Angreifer erzeugten Traffic verst rkt Wir beschreiben nun die Konfiguration des entworfenen Szenarios 9 1 1 Amplifier Netz Das Amplifier Netz wird mit der NetzID 1 initialisiert Da zu einem erfolgreichen Smurf Angriff das Opfer mindestens 100 Pakete erhalten muss und pro Zeiteinheit der Angreifer 10 mal die Broadcastadresse dieses Amplifier Netzes anpingt brau chen wir mindestens 10 Rechner die auf diesen Ping antworten Wir konfigurieren unser Amplifier Netz deshalb auf 10 Rechner Als Konfiguration f r den Router geben wir f r diesen Simulationslauf keine Firewallregel mit der Router wird deshalb jeglichen Netzwerktraffic weiterleiten sowohl in das Netz hinein als auch hinaus Auf den Rechnern dieses Net
164. rn und Daemons erl u tert da sonst nicht viele Analysen vorhanden sind 2 6 1 Klassiker Die klassischen Tools arbeiten alle nach dem Schema welches f r das Master Daemon Netzwerk angegeben wurde siehe Master Daemon Netzwerk in 2 5 1 Der Aufbau des f r den Angriff verwendeten Netzwerks erfolgt analog zu dem in 2 5 2 beschriebenen Vorgehen Die Klassiker arbeiten alle mit direkter Kommunikation d h der Angreifer redet direkt mit dem Master und die Master kommunizieren direkt mit den Daemons Das Tool Trinoo 11 nutzt f r die Kommunikation hohe UDP Ports ber die unverschl sselt gesendet wird Als einzige Angriffsart kann es UDP Flooding Attacken ausf hren Die Daemons sind nicht in der Lage ihre Absendeadresse zu f lschen daher kann man Angriffe gut zur ck verfolgen Hat man die Daemons ber ihre Absende IP entdeckt so kann man mit hoher Wahrscheinlichkeit das Daemon Tool finden In dieses sind die IP Adressen einiger Master eincodiert die man so auch aufsp ren kann Iribe Flood Network TEN siehe hierzu 13 bietet mehr M glichkei ten als Trinoo Als Angriffe sind neben UDP Flooding auch TCP SYN Flooding ICMP Echo Request Attacken und ICMP directed Broadcast Attacken wie Smurf durchf hrbar Zur Kommunikation mit dem Master kann der Angreifer verschiedene Remote Shells ber die Protokolle UDP TCP und ICMP benutzen 2 6 DDoS Tools in der Praxis 25 Master und Daemons tauschen Informatione
165. s Skriptes rtienv sh n tig Ein Aufruf des Intranets sollte aus dem Verzeichnis data erfolgen und wird auf folgende Art durchgef hrt data RTI config rtienv sh data intranet lt NetzID gt lt Anz Server gt Config Als Parameter kann man dem Intranet also seine NetzID und die Anzahl der im Intranet agierenden Server angeben Optional kann ein Configfile f r die Firewall Regeln angegeben werden mit dem der Router des Intranets initialisiert wird Der Angreifer f r den nicht verteilten SYN Angriff wird durch diesen Aufruf gestartet data RTI config rtienv sh data attacker lt NetzID gt und der Smurf Angreifer durch folgenden data RTI config rtienv sh data smurf lt NetzID gt lt Opfer IP gt lt Amplifier Netz gt Hier stehen lt NetzID gt fiir die Heimatnetz ID des Angreifernetzes lt Opfer IP gt fiir die Adress IP des Opfers und lt Amplifier Netz gt bei dem Smurf Angreifer fiir das Netzwerk dessen Broadcast Adresse gepingt werden soll Bei einem falschen Aufruf geben die Programme einen Hinweis wie sie richtig aufzurufen sind Hier erfolgt dann auch noch eine kurze Erkl rung der Parameter 130 A AUSF HRUNG DES PROTOTYPS A 5 Kompilieren der Federates Hinweis Das Makefile benutzt zum Aufruf des Compilers den Befehl g 3 Ist dieser Befehl nicht vorhanden so muss er entweder durch den auf dem System vorhandenen Aufruf f r den g Version3 ersetzt werden Bei Debian GNU 3 0 stable g
166. schon ein einziges Paket daf r ausgereicht hat d rfte schwer m glich sein Deshalb ist es wichtig solche 28 3 MASSNAHMEN GEGEN D DOS ATTACKEN Updates m glichst schnell durchzuf hren und sich auch ber andere Schwachstel len zu informieren fiir die es noch keine Fixes gibt Der Administrator sollte bei solchen ungefixten Programmen gut tiberlegen ob der Dienst nicht vielleicht ganz abgeschaltet werden kann wenn er nicht so wichtig ist oder das selbe Angebot auf anderem Wege zur Verfiigung gestellt werden kann Da viele Server nicht direkt im Internet h ngen sondern in kleineren Netzen die durch einen Router vom brigen Internet getrennt sind hat der Serverbetrei ber noch einige M glichkeiten Schutzmechanismen im Router einzusetzen Die hierfiir n tigen Einstellungen werden im Kapitel 3 3 erl utert da viele dieser Ein stellungen nicht nur fiir den letzten Router des Angriffspfades sondern generell fiir jeden Router im Netz sinnvoll w ren 3 2 Schutz vor dem Helferwerden Man muss sich nicht nur davor sch tzen selbst Opfer einer DoS Attacke zu werden Es ist beinahe noch wichtiger sich davor zu sch tzen sich von einem Angreifer als Helfer rekrutieren zu lassen Denn wenn der Angreifer es schafft DoS Tools auf einem fremden Server zu installieren so h tte er meist auch anderen Schaden anrichten k nnen Daten ver ndern oder l schen Programme zum Ausspionieren sensibler Daten installieren etc Deshalb ist auch hie
167. sem Netz in jedem Zeitschritt eine Meldung ber seinen eigenen Zustand schicken Tcon con_possible int tupdate void start Argumentliste int ELE char run message char char exec Argumentliste int bootstate void setServer host Server void myNet ID sendPacket packet Packet void setServer host Server state TStates int message char Cd Abbildung 22 Das Umfeld des Servers Der Server besitzt eine Liste in der die auf ihm installierten Programme ange geben sind Diese Liste kann von auBen dynamisch beeinflusst werden d h man kann Programme w hrend der Simulation installieren und deinstallieren Uber die se Liste wird der Server auch die Programme zur Ausf hrung bringen die w hrend eines Zeitschrittes als laufend markiert sind Um ein Read only Filesystem zu simulieren wird ein Flag namens read_only benutzt Ist das Flag gesetzt so ist das Filesystem read only sonst ist es schreibbar Dieses Flag muss bei der Installation und Deinstallation von Pro grammen ber cksichtigt werden Weiter muss es eine M glichkeit geben dieses Flag zu ver ndern um selbst bei einem read only Filesystem das Ver ndern der 8 2 Netzwerk 71 aktuellen Programmsituation des Servers zu erlauben Wir simulieren somit das Fi lesystem des Servers als ein schreibbar oder read only gemountetes Filesystem auf einem schreibbaren Speichermedium Weiterhin besitzt jeder Server ei
168. stand STOPPED an Alternativ kann man die Ausf hrung auch vorzeitig mit dem Befehl stop abbrechen Auch dann wird turns auf 0 gesetzt und das Programm geht in den Zustand STOPPED ber W hrend des Angriffs werden pro Zeittakt je 15 TCP Pakete an das Opfer ge sendet das als Argument des exec Befehls angegeben wurde Diese 15 Pakete besitzen unterschiedliche Absende IPs 8 4 Implementierung der DoS Attacken 97 8 3 5 Webserver Der Webserver wird mit dem Befehl start in den Zustand LISTENING ver setzt falls der Port den er verwenden will noch frei ist Standardport ist 8 per Auf ruf von setPort kann dieser Port aber ver ndert werden Erh lt der Webserver eine Anfrage so sendet er als Antwort den String Webseite an den Sender der Anfrage zur ck Mit stop wird die Ausf hrung des Webservers beendet er gibt den belegten Port frei und erreicht den Zustand STOPPED Dieses Programm wurde zum Testen des SYN Angriffs und des Serververhal tens bei TCP Verbindungen Connect Dienstausfiihrung geschrieben Daher hat der Webserver keine weiterentwickelte Funktion au er auf Anfragen zu reagieren und einen Port zu belegen den man connecten kann 8 4 Implementierung der DoS Attacken Wie aus der vorangegangenen Beschreibung der Netzwerk Implementierung er sichtlich ist stecken die zur Simulation einer DoS Attacke verwendeten Schwach stellen in der Implementierung des Servers Dies ist damit zu
169. stimmten Zeitpunkt Die Variabilit t des Netzzustands beschr nkt sich dann auf den Umfang den der Entwickler dem Modell noch gestattet Kann man aber als weitere Vereinfachung die Gr e des Netzes einfach verklei nern Kann man das Internet sozusagen einfach als Netz mit beispielsweise 100 Rechnern abbilden Diese Frage l sst sich nicht generell mit Ja oder Nein beantworten Es kommt auf Art und Ziel des Modells an und h ngt von vielen Details wie z B den Eigenschaften der Protokolle ab Manche Protokolle und Mechanismen funktionie ren in Netzwerken bis zu einer bestimmten Gr e wunderbar sobald das Netz aber noch gr er wird arbeiten sie nicht mehr ordentlich Will man solche Sachverhalte simulieren dann kann man das Netz nicht beliebig verkleinert darstellen Bei der Simulation des Internets muss man sich eines weiteren Sachverhalts bewusst sein Das heutige Internet ist nicht das Internet von Morgen Das Netz ver ndert sich dazu zu schnell Will man also neue Protokolle bertragungsarten etc f r das Internet testen kann sich der Simulationslauf von der Realit t dann doch unterscheiden weil sich die Randbedingungen ver ndert haben Man kann eben nur das Internet von heute oder fr her simulieren aber nicht das zuk nftige F r dieses kann man nur m gliche Entwicklungen zeigen auf deren Eintreten aber kein Verlass ist Generell kann man sagen Man muss sich zuerst dar ber im Klaren sein was man simulieren m ch
170. t int int Installiert ein Programm von Typ des angegebenen Strings auf dem Server Das Programm erh lt hierbei als Name den als 2 Argument tibergebenen String deinstall char Deinstalliert das Programm dessen Name als Argument angegeben wurde falls ein solches existiert adduser const char Legt einen Benutzer mit dem Argument als Passwort an Riickgabewert ist die UserID des neuen Benutzers deluser int L scht den User mit der angegebenen ID registerPort Program int port Protocol int int Versucht das Programm welches beim Aufruf bergeben wurde auf dem angegebenen Port des Protokolls zu registrieren Schl gt dieser Versuch fehl so wird ein negativer Wert zur ckgegeben 2 f r Port out of range 1 f r Port schon belegt bei Erfolg ist der R ckgabewert 0 unregisterPort Program int port Protocol Diese Funktion dient dazu dass ein Programm bei seiner Beendigung den von ihm belegten Port wieder freigeben kann R ckgabewerte sind 2 f r Port au erhalb der Portrange 1 wenn das Programm nicht auf dem Port l uft und O bei erfolgter Portfreigabe chpasswd int char char Diese Funktion dient dazu einem User das Wechseln des Passworts zu erlau ben Hierzu werden UserID altes Passwort und neues Passwort als Argumen te ben tigt Der Wechsel ist nur dann erfolgreich wenn das alte Passwort mit dem in der Serverliste angegebenen Passwort des Users bereinstimmt 140 i
171. t die Funktionen besser einzustufen und kann so das Kosten Nutzen Verh ltnis besser einsch tzen So werden bestimmt ei nige Ma nahmen trotz zus tzlicher Kosten als lohnend erkannt werden In unserem Prototyp wollen wir uns deshalb vorerst mit praktischen Abwehr methoden wie Paketfilter Firewalls befassen Ebenso sollen ein einfaches Intrusion Detektion Tool entwickelt und die M glichkeit von Read only Filesystemen vorge stellt werden Diese Verfahren werden hier in einer einfachen Variante vorgestellt Modernere praktische Anwendungen haben mehr Moglichkeiten als die simulier ten Aber es geht hier zun chst um einen Proof of Concept der die Machbarkeit darstellen soll und nicht ihre s mtlichen zuk nftigen M glichkeiten 39 5 Simulationsumgebung Eine Simulation kann aus mehreren voneinander unabh ngig arbeitenden Kompo nenten bestehen Jede der Komponenten ist schon eine eigenst ndige Simulation aber die gew nschte Gesamtsimulation besteht aus vielen dieser kleinen Simula tionen Das hat den Vorteil dass die Simulation einfacher zu variieren ist Da jede Komponente unabh ngig von den anderen ist k nnen Teilkomponenten ge geneinander ausgetauscht werden ohne Ver nderungen des Programmcodes n tig zu machen Eine solche Simulation nennt man verteilte Simulation wenn die Komponen ten auch noch auf unterschiedlichen Rechnern ausgef hrt werden Bei einer Simulation des Fluges eines Flugzeugs k nnte man b
172. t sich im Vergleich zum ersten Simulationslauf nicht Das Opfer brauchen wir auch nicht genauer zu untersuchen Bei Betrachtung des Traces kann man sehen dass der einzelne Ping des Angreifers wie bei der er sten Simulation ankommt bearbeitet wird und die Antwort zur ckgesendet wird Danach passiert gar nichts mehr da keine Angriffspakete mehr das Opfernetz errei chen Den Grund hierf r werden wir bei Betrachtung das Amplifier Netzes sehen Wie schon in der Simulation zuvor bearbeitet der Router zum Simulationszeit punkt 9 die Pakete des Angreifers Von den 11 erhaltenen Paketen werden 10 ver worfen Da der Angreifer 10 gleiche Angriffspakte und einen korrekten Ping ge sendet hat kann man davon ausgehen dass nur der Ping der direkt an Rechner 1 1 gesendet wurde durch die Firewall kommt Das entspricht dem Regelsatz der Firewall RER New Tames 90000000000 ee eech Router ROUTER packets to handle 11 FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped FILTER Packet rejected dropped Ses Eas 1 1 packets to handle 0 So alee 1 2 packets to handle 0 122 9 BEISPIELLAUF EINER DDOS SIMULATION Wie wir seh
173. te dann erst kann man eine geeignete Abbildung zu einem Modell finden Denn die Anforderungen an das System bestimmen den Grad an Abstraktion den ein Modell h chstens haben darf Genauer werden darf man im mer Betrachten wir als Beispiel eine Simulation die die Performance verschiede ner TCP Implementierungen testen soll Hier ist einsichtig dass man das Protokoll 100 bis in die kleinsten Details nachbilden muss Ebenso sind Anf lligkeiten ge gen Netzverz gerungen Paketverlust usw zu ber cksichtigen die n tigen Details hierf r werden also auch gebraucht 36 4 DOS SIMULATION Bei einer DoS Attacke hingegen kann man keine grunds tzliche Aussage tiber die notige Abstraktion machen Will man die Effizienz einzelner DoS Tools verglei chen oder die Effektivit t von Gegenma nahmen untersuchen so ist eine detaillierte Modellierung unumg nglich Bei einer Simulation die mehr Abl ufe veranschaulichen als Protokolldetails beachten soll ist eine solche Genauigkeit nicht angebracht Es kommt nur darauf an dass die auf Aktionen erwartete Reaktion eintrifft Genaues Timingverhalten oder interne technische Abl ufe k nnen vernachl ssigt werden Das Bild das die Modelle nach au en hin dem Betrachter zeigen ist das Wichtige Und nur dieses muss im Rahmen des M glichen realistisch sein Die Simulation soll zeigen wie sich Gegenma nahmen generell auf das An griffsverhalten auswirken und auch wie in etwa solche Gegenma nahmen a
174. te der die Option timeConstrained gesetzt hat nicht zur Zeit tn voranschreiten bevor nicht der letzte Federate mit der Option timeRegulati on zu dieser Zeit vorangeschritten ist Dies ist eine etwas vereinfacht Darstellung denn eigentlich muss an dieser Stelle noch der LookAhead beriicksichtigt werden Zum Verst ndnis der HLA fiir unsere Simulationszwecke reicht dieses vereinfachte Modell aber aus Die Erlaubnis zum Time Advance gibt die RTI dem Federate tiber die Federate Ambassador Funktion timeAdvanceGrant Der Federate erh lt von der RTI Events nur in der Zeit in der er auf den timeAd vanceGrant wartet Dieses Verhalten kann mit der Funktion enableAsynchronous Delivery verandert werden Dies ist in unserem Prototyp aber nicht der Fall 5 4 Datenaustausch zwischen den Federates Die Kommunikation der Federates soll ausschlie lich ber die RTI laufen denn sonst k nnten die HLA Mechanismen fiir Time Management und Synchronisation ausgehebelt werden Auch die m gliche Verteilung der Simulation w rde gef hrdet 5 4 Datenaustausch zwischen den Federates 43 Daher bietet HLA zwei verschiedene M glichkeiten des Datenaustauschs Uber Interaktionen und ber Objekte Der Datenaustausch erfolgt nach dem Erzeuger Verbraucher Prinzip Es gibt eine Federate Gruppe die Daten erzeugt und es gibt eine Gruppe die sie Konsu miert Dazu gibt es RTI Befehle mit denen man seine Absicht kundtun kann Daten zu ver ffentlichen bzw zu
175. tet Wenn wir das Modell einmal als Zustandsdiagramm Abbildung 14 darstellen dann haben die Zust nde folgende Bedeutung e Startzustand Unser Angreifer startet in einem Zustand in dem er ber keinerlei Wissen ber das Netz verf gt Er hat nur Zugriff auf das Benutzerkonto von dem aus er seine weiteren Aktionen durchf hren wird Dies ist der Startzustand der Simulation 6 2 Angreifermodell 49 Start der Angreifersimulation Angriff Suche des Verst rkernetzwerks geeignetes Netz gefunden Beenden des Angriffs Ping auf N Broadcastadresse Angriffsbereit laufender Angriff eines Netzwerks mit Opferadresse SS 7 als Absender Auswahl des Opfers Keine weiteren Angriffsziele O Ende der Angreifersimulation Abbildung 13 Genaueres Angreifermodell e Netzscan Der Angreifer scannt das Internet nach potentiellen Helfern fiir seinen An griff d h er sucht ganze Netzabschnitte nach Rechnern mit ihm bekannten Sicherheitsl cken ab Wenn er genug Systeme mit Schwachstellen gefunden hat kann er in den Zustand Rechner bernahme gehen e Rechner bernahme Nun beginnt der Angreifer damit sich Root Zugriff auf den beim Netzscan gefundenen Rechnern mit Sicherheitsl cken zu verschaffen Wenn er genug davon bernommen hat sp testens aber wenn er alle davon bernommen hat geht das Modell in den Zustand Daemoninstallation ber W hrend dieses bergangs zur Daemoninstallation legt der Angreifer fest welc
176. tierende IP ist n h IP char n int h Legt eine IP mit einer freien NetzID und der HostID h an Resultierende IP ist h IP int n char h Legt eine IP mit der NetzID n und einer freien HostID an Resultierende IP ist n IP char n char h Legt die IP an IP char Erzeugt aus einem String einer IP ein Objekt IP const char str Wandelt die IP in einen String um Der Pointer auf diesen String wird zuriick gegeben int hostID Gibt die HostID der IP zuriick int netID Gibt die NetzID der IP zur ck 132 B FUNKTIONSREFERENZ int isAnyNet Gibt 1 zuriick falls die NetzID nicht auf einen festen Wert gesetzt ist anson sten 0 int isAnyHost Gibt 1 zuriick wenn die HostID frei ist ansonsten 0 int isEqual IP n Vergleicht die IP mit der IP n Sind die Werte identisch wird 1 zur ckgege ben sonst 0 B 2 Klasse Net Net int Der Konstruktor der Klasse Damit wird die Klasse gleich mit einer NetzID initialisiert void newTime RTIfedTime int Sollte von der Anwendung jedesmal aufgerufen werden wenn der Federate von der RTI einen TimeGrant erhalten hat Durch diese Funktion wird die neue Zeit im Netzwerk zu allen Servern und dem Router propagiert getNetID Gibt die NetID zuriick Wichtig damit der Federate Ambassador die NetzID seines Federates bestimmen kann void dumpHostlist Gibt die Liste der dem Net
177. tributed denial of service attack tool 1999 http staff washington edu dittrich misc tfin analysis txt David Dittrich Sven Dietrich and Neil Long Analysing Distributed Denial of Service Attack Tools The Shaft Case In Proceedings of the 14th Systems Administration Conference LISA2000 2000 David Dittrich George Weaver Sven Dietrich and Neil Long The mstream distributed denial of service attack tool 2000 http staff washington edu dittrich misc mstrean analysis txt Claudia Eckert IT Sicherheit Konzepte Verfahren Protokolle Oldenbourg Wissenschaftsverlag GmbH 2001 P Ferguson Defeating Denial of Service Attacks which employ IP Source Address Spoofing 1998 rfc2267 S Floyd and V Paxson Difficulties in Simulating the Internet 2001 Thomer M Gil and Massimiliano Poletto MULTOPS a Data Structure for Bandwidth Attack Detection In Proceedings of the 10th USENIX Security Symposium pages 23 38 2001 Axel Hagedorn Distributed Denial of Service Angriffswerkzeuge und Ab wehrm glichkeiten 2003 Seminar Ausgew hlte Aspekte zum Thema IT Sicherheit Fachgebiet Sicherheit in der Informationstechnik TU Darmstadt Craig A Huegen The latest in Denial of Service Attacks Smurfing Des cription and Information to minimize Effects 2000 http www pentics net denial of service white papers smurf cgi SANS Institute Consensus Roadmap for Defeating Distributed Denial of Ser vice Attac
178. ts nicht als Ports sondern als ICMP Typ und Code zu verstehen Ansonsten sind bei ICMP und UDP keine bemerkenswerten nderungen vorge nommen worden Aber das Protokoll von TCP ist um einiges vereinfacht worden So entf llt das Best tigen der empfangenen Pakete da wir uns auf die Auslieferung der Pakete unter der RTI verlassen k nnen und sich sonst deutliche Probleme mit dem Zeitverhalten der Kommunikation ergeben w rden Weiterhin entf llt der eigentliche 3 Wege Handshake Dieser wurde aber sym bolisch so nachgebildet dass der SYN Angriff dargestellt werden kann So werden die f r TCP bekannten Flags wie SYN ACK FIN und RST in dem Paket Feld flags codiert F r jedes TCP Flag ist ein spezielles Bit von flags vorgesehen Durch spezielle Kombination der TCP Flags wird der Typ der TCP Verbindung festgelegt So ist bei jedem Paket welches einen Verbindungsaufbau beinhalten muss das SYN Bit gesetzt Wenn der Verbindungsaufbau korrekt ausgef hrt wer den kann also der Absender ihn bei einem TCP Handshake best tigen w rde so wird auch das ACK Bit gesetzt Ein Paket eines SYN Angriffs wird deshalb daran erkannt dass es ein gesetztes SYN aber kein gesetztes ACK Bit hat FIN und RST spielen hierbei keine Rolle Will man keine wirkliche Kommunikation betreiben sondern nur mit einem Connect testen ob ein Port belegt ist setzt man neben dem SYN und ACK noch das FIN Bit 88 8 IMPLEMENTIERUNG EINES PROTOTYPS Antwort Pakete also Pa
179. ts to handle 10 BSG roils ea 3 1 packets to handle 2 Net finished Noch einen Takt sp ter hat auch der Router keine Pakete mehr zu bearbeiten New Time 14 0000000000 Router ROUTER packets to handle 0 ie le eS 3 1 packets to handle 0 Net finished Das Verhalten des Angreifers ndert sich nicht mehr bis er zu Simulationszeit 22 die Ausf hrung der Simulation als beendet deklariert und dies den anderen Fe derates mitteilt Danach beendet er sich 9 2 Erfolgreicher Smurf Angriff 113 KERKE New Time 22 0000000000 Router ROUTER packets to handle 0 Sao Bia 3 1 packets to handle 0 Net finished Attack finished Telling others I ve finished ANGREIFER Resigning Execution resigned ANGREIFER Destroying Execution Execution already destroyed 9 2 2 Amplifier Netz Beschreiben wir nun welches Verhalten das Amplifier Netz w hrend unserer Si mulation zeigt Auch dieser Federate beginnt mit den Meldungen die schon vom Angreifer her bekannt sind Allerdings beginnt er bei Simulationszeit 0 da er als erstes der Execution beigetreten ist INTRANET Creating Execution created INTRANET Joining Execution joined My ID 1 INTRANET timeRegulationEnabled New Time 0 0000000000 INTRANET timeConstrainedEnabled New Time 0 0000000000 Nun k nnen wir die Netzinitialisierung verfolgen Wir sehen dabei wie Server 1 1 bis 1 10 angelegt und i
180. tz kann folgenderma en ver ndert werden Man kann einen Re gelsatz aus einem File einlesen loadRuleset filename wobei auch die Default Policy gesetzt wird oder man kann einzelne Regeln zum bestehenden Re gelsatz erg nzen addRule regel Man kann den Regelsatz in ein File schrei ben dumpRuleset filename welches man dann sp ter auch wieder als Re gelsatz laden kann man kann es mit Zeilenzahl 1istRuleset oder ohne dumpRuleset ausgeben Man kann einzelne Regeln l schen indem man ihre Nummer angibt delRule regel oder man kann alle Regeln l schen 84 8 IMPLEMENTIERUNG EINES PROTOTYPS clearRuleset Ein Beispiel f r ein Ruleset samt Erkl rung ist Abb 34 zu entnehmen Source Port Ziel Port Aktion der Firewall Default Policy 1 Regel Protokoll Ziel Addresse Quell Adresse Abbildung 34 Aussehen eines Firewall Regelsatzes Da neu hinzugef gte Regeln automatisch an das Ende des Regelsatzes geh ngt werden die Reihenfolge der Regeln f r die Wirkung der Firewall aber essenti ell ist muss man auch die Position der Regeln ndern k nnen Man kann eine Regel eine Position nach vorne mvRuleUp regel oder nach hinten r cken mvRuleDown regel Die Klassendefinition zu Router istin Abb 35 zu sehen myNetID int fw list lt Rule gt policy Policies intranet Net packetList list lt Packet gt Router myNet Net Router
181. uch sp ter durch Entwicklung eines neu en Typs von Teilnetz gezielter auf die Situation spezieller Gruppen wie z B ISPs Internet Service Provider eingehen die verhindern wollen dass ihre Nutzer DoS Angriffe auf Dritte f hren Angreifer Abbildung 18 Konzept im Kontext der realen Welt Der Prototyp wird sich aber zun chst neben Angreifer und Opfer auf einen Typ von Teilnetz beschr nken Ilustriert wird dieses Konzept in Abb 18 Das eigent liche Internet dient hier nur als Vermittler der die Kommunikation zwischen den einzelnen Teilnetzen Angreifer und Opfer erm glicht Im Gegensatz zum realen In ternet kann hier also jedes Teilnetz mit jedem Teilnetz direkt kommunizieren Bei dem Prototyp bernimmt diese Aufgabe die RTI Runtime Infrastructure die von HLA bereitgestellt wird Die Teilnetze sind dann ebenso wie Angreifer und Opfer eigenst ndige Federates Abb 19 7 2 Teilnetze Auch bei den Teilnetzen gehen wir davon aus dass jeder Rechner direkt mit jedem anderen Rechner des Teilnetzes verbunden ist Jede Kommunikation die mit Rech 7 2 Teilnetze 59 Tr a CD CSc o Runtime Infrastructure RTI Abbildung 19 Konzept im HLA Kontext nern au erhalb des eigenen Teilnetzes durchgef hrt wird l uft ber einen Router Dieser kann gleichzeitig als Firewall dienen W hrend im realen Internet die Funk tion von Router und Firewall manchmal aus Effizienzgr nden nicht auf demselben Rechner l uft brauche
182. und alter Pakete mehr stattfin den Alte Pakete sind hierbei Pakete die den Server Router im letzten Zeitschritt erreicht hatten und im aktuellen bearbeitet werden sollen w hrend neue Pakete diejenigen sind die erst im aktuellen Zeitschritt bei den Servern Routern ankom men Danach d rfen auch die Server der Reihe nach ihre Pakete bearbeiten dies geschieht inhandlePacket Der Ablauf der Funktion newTime und seine Unteraufrufe an Server und Router ist in Abbildung 37 dargestellt 1 H H I l 1 1 gt handlePackets H H l 1 D l l l I 1 newTime N I 1 1 l l H H H i newTime l i l l l I H I 1 1 newTime I I I l l H l newTime l l l i H H 1 1 1 I l I H H H 1 1 1 1 handlePackets 1 I I I I l io Wok y f 1 1 1 l 1 1 1 H l d a handlePackets 1 1 1 l i doWbrk l 1 I 1 j H 1 l l 1 i Server 1 1 und 1 2 stehen stellvertretend f r alle im Net befindlichen Server d h alle die Server die intranet Net bekannt sind Abbildung 37 Ablauf eines Time Updates im Netzwerk 8 2 6 Kommunikation im Netzwerk Die Kommunikation in diesem simulierten Netzwerk ist genauso wie im realen In ternet paketbasiert Allerdings gibt es einen entscheidenden Unterschied W hrend reale Protokolle daf r sorgen dass gr ere Datenmengen in Teilpakete mit einer maximalen Gr e zerlegt werden kann unser Netzwerk jede bertragung in einem 8 2
183. unktioniert sie wie in der Klasse Server beschrieben Das IDT siehe 8 3 1 ist eine von Program abgeleitete Klasse Beim ersten Start des IDTs wird eine Liste der installierten Programme erstellt Diese wird zu jedem Zeitschritt mit der aktuellen Liste der Programme verglichen bei Abwei chungen wird eine Neuinstallation des Servers ausgel st Um die Liste nach einer gewollten Installation auf den aktuellen Stand zu bringen ist eine Update Funktion eingebaut Aufruf von der exec Funktion mit speziellem Parameter die al lerdings im Zweifelsfall auch dem Einbrecher in das System zur Verf gung steht Dieser muss zur Verhinderung seines Entdecktwerdens aber wissen dass ein IDT installiert ist und wie die Datenbank des IDTs zu aktualisieren ist 8 6 Viewer Normalerweise ist die Visualisierungskomponente einer verteilten Simulation eine eigenst ndige Komponente Dies geschieht aus Effizienzgr nden Die Rechenzeit die der Viewer zur Darstellung der Ereignisse braucht soll den Ablauf der Simula tion nicht aufhalten Deshalb trennt man die passive Darstellungskomponente von den aktiven Simulationsteilen In diesem Prototyp ist der Viewer dennoch Teil einer aktiven Simulationskom ponente Hierf r gibt es mehrere Gr nde 1 Da es mehrere an der Simulation beteiligte Angreifer geben kann ist es ein facher jedem Angreifer seine Visualisierungskomponente gleich mitzugeben Jeder Viewer kiimmert sich so um seinen Angriff von ander
184. utz sich jederzeit ein neues of fenes WLAN Netz als Operationsbasis suchen k nnte 2 Der Angreifer scannt das Internet auf Rechner mit bekannten Sicherheits l cken Hierzu kann er z B ein Netzscantool verwenden das er frei aus dem Internet bezieht 3 Der Angreifer bernimmt Rechner indem er die zuvor gefundenen Sicher 22 2 DENIAL OF SERVICE DOS heitsl cken ausnutzt um Root Rechte auf den Systemen zu bekommen Hier bei werden m glichst fertige Exploits benutzt um den Aufwand gering zu halten Der Angreifer teilt die bernommenen Rechner in Master und Daemon Systeme ein Er nimmt die wichtigsten Rechner als Mastersysteme die rest lichen Rechner werden zu Daemons Die Master Systeme bilden nur einen geringen Anteil der gesamten Rechner des Angriffsnetzwerkes Die Installation der Daemon Systeme erfolgt in der Regel automatisiert d h skriptgesteuert Mit Installation ist hier Folgendes gemeint das In stallieren der n tigen Programme auf dem System sowie das Verstecken der auff lligen Aktivit ten die durch diese verursacht werden Die Installation der Programme erfolgt meist durch Kompilieren des Quelltextes und Hinter legen der ausf hrbaren Datei meist bei Unix Systemen an einer bestimmten Stelle oder durch Kopieren von fertigen Executables an den geeigneten Ort im Dateisystem Das f r die Installation verwendete Skript wird normaler weise als Teil der DoS Tools bereitgestellt Durch die M
185. weiligen Be st tigung auf den Wert 1 Das Voranschreiten in der Zeit wird ber die Federate Ambassador Funktion timeAdvanceGrant verwaltet Diese setzt die Variable grant Time auf die von der RTI zugewiesene neue Zeit Auch hier wird das Erreichen der Meldung ber das Setzen der Variablen t imeAdvGrant dem Hauptprogramm mitgeteilt Die anderen Funktionen die bei der Beschreibung von HLA f r den Federate Ambassador angegeben wurden sind f r das Intranet nicht von Bedeutung Ihre Funktionalit t wird nicht gebraucht also sollten sie von der RTI auch nicht auf gerufen werden Falls doch wird vom Federate Ambassador eine Fehlermeldung generiert RTIhandler Der RTIhandler ist fiir die RTI Aufrufe der Klassen aus dem Netzwerk zust n dig Dazu geh ren das Verschicken der Pakete vom Router an das Internet oder die Statusmeldungen die die Server tiber ihren Zustand geben Abb 42 Bei Erzeugen des RTIhandlers werden die Interaktionen die der Hand ler verschicken k nnen soll bei der RTI zur Ver ffentlichung angegeben publishInteractionClass Hierzu geh ren die Interaktionen IP packet ServerStatus und ServerNewinstall Die Interaktion IPpacket wird verwendet um die Pakete der Netzwerkkommu nikation ber die RTI zu versenden Dazu wird vom Router die Handler Funktion sendPacket aufgerufen Mehr als dass man mit dieser Funktion Pakete an die RTI sendet braucht der Benutzer von Router oder der Autor eine
186. werden so kann man zwar nicht verhindern dass durch einen Buffer Overflow der Stack korrumpiert wird aber die dort eingefiigten Daten k nnen ihre Schadfunktion nicht ausfihren da sie in nicht ausf hrbaren Speicherbereichen liegen Das Programm wird vielleicht abstiirzen aber es entsteht sonst kein Schaden Bei der im PC verwendeten x86 Architektur funktioniert dieser Ansatz nicht so einfach 33 Background Hier muss das Betriebssystem Unterst tzung lei sten damit die Nicht Ausf hrbarkeit des Stacks unumgehbar wird Implementie rungen daf r gibt es unter anderem f r Linux 48 Hierbei kann diese Funktiona lit t entweder ber einen Patch dem Betriebssystemkern hinzugef gt werden 33 oder man muss den Quellcode von Programmen die man verwenden m chte mit speziellen Bibliotheken neu bersetzen Dann erhalten die Programme selbst die M glichkeit die Sch dlichkeit von Buffer Overflows zu verhindern Aber auch f r Windows NT 2000 gibt es mit SecureStack von SecureWave einen entsprechenden Patch der unter 2000 allerdings zu erheblichen Performance Einbu en f hren soll Genaueres zu diesen Patches ist 26 Gegenma nahmen zu entnehmen Aber auch fehlerfreie Dienste m ssen auf sinnvolles Verhalten beschr nkt wer den Bei den in 2 4 1 erw hnten Gameservern die eine Verst rkerfunktion f r An greifer bereitstellen k nnte man z B maximale Bandbreiten festlegen mit denen die Pakete an Ziele verschickt werden Ebens
187. wischen den Federates Modelle zur Beschreibung von D DoS 6 1 Verhaltensmodelle f r Angriffe 6 2 Angr ifermodell 2 24224244 204 044 eee Boa a 6 2 1 Smurf Angreifer us oy ese See eee oe a 6 2 2 DDoS Angreifer mit Netzwerkaufbau 6 3 Optermodel lt cios i e 2 Ree Sb ek he ee ee SY 6 4 Modell der Netzwerkrechner INHALTSVERZEICHNIS 6 5 Netzwerkmodell 2 222 Cm Hmm Konzept f r die Implementierung Tal Netzwerktopolosie soe oes Hs oe si IR Br 1 2 2 Teilnetze a sa oe 8 5 vs A A A ae 7 3 Kommunikation im Netzwerk e 7A Konzept eines Servers ee be ra he eS 7 5 Weitere berlegungen Implementierung eines Prototyps 8 1 Beenden der Simulation lt 5 40 4 ra a a woes 8 2 Netzwerk das ya ea ae E Be yg o o 8 2 Bas sklassen LAA ALEA ALE Re 8 2 2 Klaseder Serv r e 43 ee ee oe ee ee 8 2 3 Programme 2 42 22 4 A sa Awe aA u 874 EE NEE E EEN E 82a NR AS E AA a 8 2 6 Kommunikation im Netzwerk 8 2 7 RTI Anbindung des Netzwerks 8 3 Implementierte Programme o rn Sd ADE Ca o a a Me OS 8 3 2 BINO e De A Soe A e A ae e er er Ae de BEI IM ce a EE 8 3 4 SynAttackTool 0 000 2 eee 9 3 3 WEHSEEVEE tt Be eg a a A 8 4 Implementierung der DoS Attacken 8 5 G genmiabnahmen os os A Ae ee AA 07 VIENE ea ek Dap wae ot Dae ii el p ola Ya He Sek y AABT po eG tee Soe ar y yoda o Wee wee RI 8 8
188. z bekannten Server samt ihrem Zustand auf der Standardausgabe aus RTIhandler getHandler Gibt einen Verweis auf den RTIhandler zur ck Auf diese Weise initialisieren sich die Serverobjekte ihren Zugriff auf den RTIhandler void setHandler RTIhandler int So erh lt das Netz die Adresse des RTIhandlers Der Aufruf dieser Funktion muss erfolgen bevor das Netz arbeiten kann und sollte daher unmittelbar nach dem Erzeugen des RTIhandler Objektes erfolgen setRouter Router Diese Funktion wird von Router benutzt um sich dem Netzwerk bekannt zu machen Als Antwort wird die NetzID zur ckgegeben void sendPacket Packet Dieser Befehl reicht ein Paket an das Netzwerk weiter B 3 Klasse Packet 133 int setServer Server ip TStates s Setzt den Status des Servers ip auf den Wert s R ckgabewert ist 0 bei Erfolg und 1 wenn ein Fehler aufgetreten ist Server addServer int i Bringt das Netzwerk dazu einen neuen Server mit der HostID i anzulegen Die Adresse des neuen Serverobjektes wird dann zur ckgegeben Server addServer int i char f Legt einen neuen Server mit der HostID i und dem Configfile f an Riickga bewert ist die Adresse des neuen Servers int addServer Server F gt einen Server dem Netzwerk hinzu falls dieser eine IP aus dem entspre chenden Netz hat Als Riickgabewert meldet O Erfolg und 1 gibt an dass der Server nicht ins Netz hinzugef gt werden konnte int delServer
189. zwerks ist kein Programm installiert da das zur Simulation eines Smurf Angriffs nicht n tig ist und wir aus Gr nden der Uber sichtlichkeit auf nicht Ben tigtes verzichten 108 9 BEISPIELLAUF EINER DDOS SIMULATION 9 1 2 Opfernetz Das Opfernetz erh lt die NetzID 2 Die Anzahl der Server dieses Netzes hat auf den Erfolg der Attacke keine Auswirkungen Daher werden wir das Netz m glichst klein gestalten dann bleibt es bersichtlicher f r die Auswertung Um zu zeigen dass der Angriff sich nur auf den angegriffenen Opferrechner auswirkt werden wir neben dem Opfer aber doch einen zweiten Rechner in diesem Netz betreiben Auch auf diesen beiden Rechnern installieren wir aus dem selben Grund wie beim Amplifier Netz keine Programme 9 1 3 Angreifer Das Netz in dem der Angreifer arbeitet erh lt die NetzID 3 Des weiteren bleibt die Konfiguration des Angreifernetzes wie schon in 8 7 beschrieben keine Fire wallregeln auf dem Router und nur ein Rechner im Netz 9 2 Erfolgreicher Smurf Angriff Um die Simulations Traces zu verstehen sollten wir zun chst einige Darstellungs punkte kl ren Sonst verliert man leicht den berblick welche Aktion zu welcher Zeit stattfindet wann genau der Zeitwechsel stattgefunden hat oder welche Mel dung von welchem Server erzeugt wurde Deshalb zum besseren Verst ndnis der folgenden Trace Ausz ge e Zeitwechsel Jeder Zeitwechsel wird durch Ausgabe der Zeile REESE New Time X 0000000000

2 Denial of Service (DoS)

Contents

Download Pdf Manuals

Related Search

Related Contents