HTBLVA Villach. Höhere Lehranstalt für Informationstechnologie Ausbildungsschwerpunkt Netzwerktechnik DIPLOMARBEIT

Transkript

1 HTBLVA Villach Höhere Lehranstalt für Informationstechnologie Ausbildungsschwerpunkt Netzwerktechnik DIPLOMARBEIT Gesamtprojekt pinx Generate, Penetrate, Anonymize Konzeption, Planung und Realisierung der Software Christian Lepuschitz 5AHITN Betreuer: Dipl.-Ing. Hermann Jessner Betreuer: Dipl.-Ing. Harald Wolf ausgeführt im Schuljahr 2015/16 Abgabevermerk:

2 1 Eidesstattliche Erklärung Hiermit erkläre ich, dass ich die vorliegende Diplomarbeit selbständig und ohne fremde Hilfe angefertigt habe. Es wurden nur die in der Arbeit ausdrücklich benannten Quellen und Hilfsmittel benutzt. Wörtlich oder sinngemäß übernommenes Gedankengut habe ich als solches kenntlich gemacht. Villach, am Christian Lepuschitz

3 2 Danksagung In erster Linie möchte ich mich bei all denjenigen bedanken, die mir vor- und während der Projektzeit immer zur Verfügung standen und konstruktive Kritik lieferten. Einen besonderen Dank möchte ich folgenden Personen aussprechen: HTL Villach: Prof. Dipl.-Ing. Hermann Jessner für die Grundidee einer solchen Software und die Ermöglichung dieser Diplomarbeit durch die Vermittlung zur Fachhochschule Kärnten. Ohne seine einzigartige Motivation und sein technisches Know-how hätte diese Software nie entwickelt werden können. Zusätzlich stellte er bei spezifischen technischen Fragen direkten Kontakt mit Cisco Systems Austria GmbH her. Prof. Dipl.-Ing. Harald Wolf für die ständige Unterstützung, die Verbesserungs- und Erweiterungsvorschläge und für die kompetente, softwaretechnische Beratung während des Entwicklungsprozesses. Vor allem während schwierigen Projektphasen waren seine Ratschläge ein wesentlicher Bestandteil der Fortführung des Projektes. FH Kärnten: Dr. Jürgen Schussmann für die externe Betreuung dieser Diplomarbeit und das Bereitstellen der technischen Komponenten und der Labors der FH-Kärnten. Cisco Systems Austria GmbH: Dipl.-Ing. (FH) August Sarkany für den Kontaktaufbau zu mehreren Technikern und die Informationsbeschaffung über den genauen Aufbau eines proprietären Cisco- Protokolls. Projektpartner: Johannes Thomas Tratnik für die anfängliche Unterstützung, die Mithilfe beim Design der Softwarearchitektur, die Entwicklung wesentlicher Funktionen und Methoden zur Konvertierung, und für den technischen Support bei Herausforderungen beim Programmieren. Weiterer Dank gilt meinen Kollegen aus der HTL-Villach, welche maßgeblich dazu beigetragen haben, dass diese Diplomarbeit nun in dieser Form vorliegt. DANKSAGUNG 3

4 3 Inhaltsverzeichnis 1 EIDESSTATTLICHE ERKLÄRUNG DANKSAGUNG INHALTSVERZEICHNIS ABSTRACT DEUTSCH ENGLISH PROJEKTÜBERSICHT AUFGABENSTELLUNG ZIELE Finden geeigneter Frameworks Auswahl und Analyse diverser Netzwerkprotokolle Implementieren der Software PROJEKTBETREUER PROJEKTPHASEN ARBEITSPAKETE RECHTLICHES FUNKTIONSUMFANG DER SOFTWARE NETZWERKPROTOKOLLE FUNKTIONEN ANSTEUERN DER NETZWERKKARTE WINPCAP Einschränkungen Monitor Mode Promiscuous Mode Air-Pcap GRUNDSTRUKTUR DER SOFTWARE KLASSENDIAGRAMM INTERFACE ITOBYTE NETZWERKPROTOKOLLE VARIABLEN KONSTRUKTOR(EN) PROPERTIES TOBYTE METHODE PROPRIETÄRE METHODEN HELPER GV (GLOBALE VARIABLEN) PAKETGENERATION (PACKAL) Funktionsweise NETWORKTRAFFIC Senden von Datenpaketen Empfangen von Datenpaketen INHALTSVERZEICHNIS 4

5 9.13 PROGRAM KONVERTIERUNG OBJEKTE IN BYTEARRAYS KONVERTIEREN Strings Integer MAC-Adressen IP-Adressen (IPv4) Flags BYTEARRAYS IN OBJEKTE KONVERTIEREN BIG-ENDIAN / LITTLE-ENDIAN ARCHITEKTUREN DAS PROGRAMM AUSWÄHLEN DER NETZWERKSCHNITTSTELLE NAVIGATION ZWISCHEN AUSWAHLMENÜS EINGABEMASKEN PROGRAMMFUNKTIONEN NETZWERKSCAN / PORTSCAN Implementierung TRUNK-LINK AKTIVIEREN STP ANGRIFF CDP FLOOD DHCP STARVATION WAKE-ON-LAN DDOS TCP SYN-FLOOD HTTP PAYLOAD-SNIFFING Reassemblierung von segmentiertem TCP-Payload MIME-Sniffing STEGANOGRAPHIE Netzwerkprotokolle Least-Significant-Bit ENTWICKLUNG EINER ZEICHENORIENTIERTEN BENUTZERSCHNITTSTELLE FRAMEWORK - TUIBASE DAS PINX-PROTOKOLL FUNKTIONSWEISE Typ: Flags: Checksum: Connection: Reserved: Sequence Number: pinxdata: DAS PROTOKOLL IM EINSATZ HERAUSFORDERUNGEN SYSLOG / SNMP INHALTSVERZEICHNIS 5

6 15.2 ZYKLISCHE REDUNDANZPRÜFUNG (CRC-16 CHECKSUMME) VERWENDETE UND ÄHNLICHE PROGRAMME NMAP YERSINIA PACKETH WIRESHARK RESÜMEE AUSBLICK ANHANG QUELLENVERZEICHNIS ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS INHALTSVERZEICHNIS 6

7 4 Abstract 4.1 Deutsch IT-Sicherheit ist in der heutigen Zeit mitunter einer der wichtigsten Aspekte eines Unternehmens. Um die Sicherheit einer Netzwerkinfrastruktur zu testen und bestimmte Vorkehrungen zu treffen, ist spezielle Software notwendig. Die Aufgabenstellung dieser Diplomarbeit ist ein Softwarepaket mit drei wesentlichen Kernkompetenzen: GENERATE - Generieren und Senden von beliebigen Datenpaketen PENETRATE - Finden und Ausnützen von Sicherheitslücken in Netzwerken ANONYMIZE - Anonymisierter Informationsaustausch mit optionaler Verschlüsselung Aufgrund 119a des österreichischen Strafgesetzbuches darf diese Software nur innerhalb eines Testsystems, beziehungsweise innerhalb des eigenen Netzwerks zu Testzwecken verwendet werden. 4.2 English IT security is nowadays one of the most important aspects of a company. To test the security of a network infrastructure and to take certain precautions, special software is needed. The aim of this diploma thesis is a software package with three main core competencies: GENERATE Generating and sending arbitrary data packets PENETRATE Finding and exploiting vulnerabilities in networks ANONYMIZE Anonymized information exchange with optional encryption Due to 119a of the Austrian Criminal Code, this software may only be used within a test system, or within your own network. ABSTRACT 7

8 5 Projektübersicht 5.1 Aufgabenstellung Die Aufgabe dieser Diplomarbeit besteht darin, ein umfangreiches Softwarepaket für Sicherheitsexperten und Schulungseinrichtungen bereitzustellen. Die verschiedenen Funktionen lassen sich in drei verschiedene Themengebiete kategorisieren: GENERATE: Die Software soll für eine Vielzahl von unterschiedlichen Netzwerkprotokollen Eingabemasken bieten, über diese ein Benutzer die verschiedenen Parameter selbstständig ändern kann. Hierbei sollen Netzwerkprotokolle von der Schicht 2 bis 7 im OSI-Modell verfügbar sein. Die Software soll die vom Benutzer definierten Werte in ein Datenpaket konvertieren, und über eine gewünschte WinPcap-fähige Netzwerkschnittstelle senden. PENETRATE: Um die Sicherheit eines Netzwerkes zu testen, sollen bekannte Angriffe ohne großen Aufwand durchgeführt werden können. Die Benutzerinteraktion hierbei soll minimal gehalten werden. Unterstützt werden sollen Angriffe und Netzwerkscans auf verschiedenen Schichten im OSI-Modell. ANONYMIZE: In dieser Kategorie sollen unterschiedliche Verfahren implementiert werden, mit welchen zwei Clients der Software anonym Daten austauschen können. Hierbei gibt es zwei Lösungsansätze. Einerseits sollen Informationen mittels LSB- Verfahren in eine Multimediadatei geschrieben werden können, andererseits soll ein neues Verfahren entwickelt werden, mit dem es möglich sein soll, Informationen in Netzwerkprotokollen zu verstecken welche nicht für Informationsaustausch dieser Art vorgesehen sind. 5.2 Ziele Finden geeigneter Frameworks Es ist zu analysieren, welche Frameworks für die gewünschte Software am besten geeignet sind. Es sollen mehrere Subprojekte erstellt werden, in denen die verschiedenen Funktionen diverser Frameworks getestet werden können. Benötigt werden im Wesentlichen lediglich eine Methode zum Senden, und eine Methode zum Empfangen von selbst konzipierten Datenpaketen (in Form von Bytearrays) Auswahl und Analyse diverser Netzwerkprotokolle Es gibt eine Vielzahl verschiedener Netzwerkprotokolle. Im Rahmen einer ausführlichen Recherche sollen einige Netzwerkprotokolle ausgewählt und analysiert werden. Die Auswahlkriterien beschränken sich hierbei auf den möglichen Nutzen für den Benutzer und die geschätzte Komplexität bei der Entwicklung. Es soll möglich sein die implementierten Netzwerkprotokolle als Objekte, so genau wie jeweils erforderlich, anpassen zu können. PROJEKTÜBERSICHT 8

9 5.2.3 Implementieren der Software Sind die diversen Netzwerkprotokolle ausgewählt und die jeweiligen Funktionen definiert, können mehrere Prototypen zum Testen einzelner Funktionen entwickelt werden. In diesen werden die Grundfunktionalitäten und die optimale Integration in die Software getestet. Im Wesentlichen gibt es folgende Prototypen: Prototyp 1 Konvertieren und Senden: Es sollen im ersten Schritt einzelne Variablen verschiedener Datentypen in Bytearrays konvertiert werden. Das Resultat ist ein Bytestream in hexadezimaler Repräsentation, welches mit den gewünschten Ergebnissen verglichen wird. Ist diese Funktion gewährleistet, wird derselbe Versuch mit einzelnen Klassen durchgeführt. Jede Klasse verfügt über mehrere Variablen. Eine spezielle Methode konvertiert diese in definierter Reihenfolge, konkateniert sie zu einem einzelnen Bytearray und übergibt dieses per Rückgabeparameter der Programm-Klasse. Die Programm-Klasse übergibt das Bytearray dem ausgewählten Framework, welches die Daten über eine vom Benutzer ausgewählte Netzwerkschnittstelle sendet. Prototyp 2 Empfangen und Rückkonvertieren: Der Bytestream mehrerer Datenpakete wird analysiert und auf spezielle Merkmale untersucht. Der Ethernet-Anteil wird aus einem Datenpaket extrahiert, konvertiert und in einem C#-Objekt der Klasse Ethernet gespeichert. Der Erfolg des Vorgangs kann mittels Wireshark überprüft werden. Prototyp 3 Benutzerschnittstelle: Bei diesem Prototyp werden einerseits mehrere mögliche Lösungswege getestet, andererseits für die verschiedenen Bereiche der Software mehrere Templates entworfen und ein Standard definiert. PROJEKTÜBERSICHT 9

10 5.3 Projektbetreuer Christian Lepuschitz HTL - Villach Hauptbetreuer: Dipl. Ing. Hermann Jessner FH-Kärnten Betreuer: Dr. Jürgen Schussmann Nebenbetreuer: Dipl. Ing. Harald Wolf Abbildung 1 - Projektorganisation 5.4 Projektphasen Fachliche und technische Konzeption Entwicklung einer Testsoftware Entwicklung der Software Testen der Software Abbildung 2 - Projektphasen PROJEKTÜBERSICHT 10

11 5.5 Arbeitspakete Die einzelnen Arbeitspakete werden in einer Excel-Datei erfasst und den entsprechenden Teammitgliedern zugeteilt. Täglich wird der prozentuelle Fortschritt pro Arbeitspaket aktualisiert und die Dokumentation über die erledigte Arbeit erweitert. Hier befindet sich eine Übersicht über die einzelnen Arbeitspakete: Technische und fachliche Konzeption Entwicklung einer Testsoftware Entwicklung der Software Testen der Software Tabelle 1 - Projektphasen und Arbeitspakete Definition des gewünschten Endproduktes Testen bestehender, ähnlicher Programme Entwurf einer Softwarearchitektur Recherche über verfügbare Frameworks Einarbeitung in SharpPcap Konvertierung verschiedener Datentypen Senden von Bytearrays Erstellung eines Grundgerüstes Interfaces Einbindung der Frameworks Wesentliche Methoden Definition der Netzwerkprotokolle in Softwareklassen Layer 2 Protokolle Layer 3 Protokolle Layer 4 Protokolle Layer 5-7 Protokolle Entwicklung der Paketgeneration Sukzessive Konkatenation und Konvertierung Dynamisches Berechnen zyklischer Redundanzprüfungen Implementierung der Funktionen Senden und Empfangen von Datenpaketen Netzwerklogik diverser Protokolle Penetrationtesting Tools Steganographie Entwicklung einer textbasierten Benutzerschnittstelle Testen und auswählen verschiedener Frameworks Einbindung von TUIBase in die Software Codeanpassungen Codeoptimierungen Fehlerbehebungen Performanceverbesserungen Wireshark Netzwerkgeräte Testnetzwerk PROJEKTÜBERSICHT 11

12 6 Rechtliches Da die Software zum Abhören und Mitschneiden fremder Netzwerkkommunikation fähig ist, ist die Software nur innerhalb eines Testsystems beziehungsweise innerhalb des eigenen Netzwerkes zu verwenden. Anderenfalls liegt ein Verstoß gegen $ 119a des österreichischen Strafgesetzbuches vor. 119a. (1) Wer in der Absicht, sich oder einem anderen Unbefugten von im Wege eines Computersystems übermittelten und nicht für ihn bestimmten Daten Kenntnis zu verschaffen und dadurch, dass er die Daten selbst benützt, einem anderen, für den sie nicht bestimmt sind, zugänglich macht oder veröffentlicht, sich oder einem anderen einen Vermögensvorteil zuzuwenden oder einem anderen einen Nachteil zuzufügen, eine Vorrichtung, die an dem Computersystem angebracht oder sonst empfangsbereit gemacht wurde, benützt oder die elektromagnetische Abstrahlung eines Computersystems auffängt, ist, wenn die Tat nicht nach 119 mit Strafe bedroht ist, mit Freiheitsstrafe bis zu sechs Monaten oder mit Geldstrafe bis zu 360 Tagessätzen zu bestrafen. (2) Der Täter ist nur mit Ermächtigung des Verletzten zu verfolgen. [1] RECHTLICHES 12

13 7 Funktionsumfang der Software Der Funktionsumfang der Software lässt sich in zwei Kategorien darstellen Netzwerkprotokolle und Funktionen. 7.1 Netzwerkprotokolle Da diese Diplomarbeit ursprünglich für zwei Projektmitglieder ausgerichtet war, konnten nicht alle in der folgenden Tabelle gelisteten Netzwerkprotokolle vollständig ausprogrammiert und in die Benutzerschnittstelle integriert werden. Datenpakete folgender Netzwerkprotokolle können mit der Software gesendet werden: ARP CDP DHCP DNS 1 DTP EIGRP 2 Ethernet HDLC HSRP HTTP 2 ICMP 2 IPv4 IPX 2 LLC OSPF 2 pinx RTP 1 SSL 1 STP Syslog 1 TCP UDP VTP 2 Tabelle 2 - Unterstützte Netzwerkprotokolle in der Software 1) Nur beschränkt nutzbar 2) Implementiert, aber nicht in die Benutzerschnittstelle integriert 7.2 Funktionen Die einzelnen Funktionen der Software werden in folgender Tabelle nach deren zugehörigen Netzwerkprotokollen aufgelistet: DTP STP CDP DHCP WOL TCP ARP JPEG, PNG, GIF ICMP IPv4 pinx DNS LSB Trunk-Link aktivieren Computer zur Rootbridge im Netzwerk machen Die CDP-Tabelle eines Cisco-Gerätes fluten Starvation-Attack Per Wake-On-LAN eine kompatible Netzwerkkomponente einschalten Syn-Flood Reset-Attack Reassemblierung der Payload-Daten Portscan Scannen eines definierten IP-Adressbereichs MIME-Sniffing und Dateiexport Datentransfer Datentransfer Datentransfer Sniffing und Auflisten von Domainnamen Steganographie in Bilddaten Tabelle 3 - Unterstützte zusätzliche Funktionen in der Software FUNKTIONSUMFANG DER SOFTWARE 13

14 8 Ansteuern der Netzwerkkarte Da mit der Programmiersprache C# auf Windows-Systemen standardmäßig keine Bytearrays gesendet werden können, verwendet pinx über ein spezielles Framework den Netzwerktreiber von WinPcap. 8.1 WinPcap WinPcap ist eine Programmbibliothek für Windows, welche von vielen bekannten Netzwerk- Tools, zum Beispiel Wireshark oder NMAP, verwendet wird. Neben den verschiedenen Programmbibliotheken bietet WinPcap einen Netzwerktreiber, welcher von der Software pinx zum Senden und Empfangen von einzelnen Bytearrays verwendet wird. [2] Einschränkungen Funktionen der Netzwerkkarte Da WinPcap selbst als Protokoll implementiert ist, ist es nicht möglich empfangene Pakete zu stoppen, bevor sie die Applikation erreichen, oder Pakete anderer Applikationen zu manipulieren, bevor sie geschickt werden. Aus diesem Grund sind die Möglichkeiten beim Steuern der Netzwerkkarte auf das reine Senden und Empfangen beschränkt. Unterstützte Compiler Aufgrund der alleinigen Unterstützung des Microsoft Visual C++ Compilers ist ein entsprechendes C#-Framework für die Entwicklung der Software notwendig (SharpPcap). Betriebssysteme Die Benutzung von WinPcap ist ab Windows 95 möglich [3]. Welche WinPcap-Versionen auf welchen Betriebssystemen benötigt werden, kann auf folgender Website nachgelesen werden: Monitor Mode In Netzwerken kommen zwei verschiedene Filter zum Einsatz (Channel- und SSID/ESSID-Filter). Channel / Frequenz Im europäischen Bereich wird der Frequenzbereich auf 11 verschiedene Kanäle mit verschiedenen Frequenzen aufgeteilt. Da sich aneinander liegende Kanäle in ihrer Frequenz überlappen, wird häufig das Kanalschema 1, 6, 11 verwendet. Wird ein Access-Point aktiviert, wird diesem ein bestimmter Kanal zugewiesen. Um eine Kommunikation zwischen einem Client und dem Access-Point zu gewährleisten, müssen die Kanäle vom Client und dem Access-Point übereinstimmen. Nur auf diesem festgelegten Port ist eine bidirektionale Kommunikation möglich. ANSTEUERN DER NETZWERKKARTE 14

15 Dieser Filter kann aus hardwaretechnischen Gründen nicht deaktiviert werden, außer ein Netzwerkadapter unterstützt mehrere Kanäle zur selben Zeit. SSID / ESSID Ein Netzwerk hat eine bestimmte SSID (Service Set Identifier), mit dem sich ein Client verbinden kann. Verwenden mehrere Access-Points dieselbe SSID, spricht man von einer ESSID (Extended Service Set Identifier). Im Normalfall verbindet sich ein Client mit einer gewünschten SSID und empfängt in diesem Netzwerk alle Datenpakete, die für ihn adressiert sind (ähnlich einem Ethernet-Netzwerk). Mit dem Monitor-Modus kann dieser Filter deaktiviert werden. Ein Client kann in diesem Fall sämtliche Datenpakete abfangen, welche auf dem eingestellten Kanal gesendet werden. Abhängig vom Netzwerkadapter und dem verwendeten Treiber, können zwei Fälle unterschieden werden: 1. Client ist mit SSID verbunden Eine Netzwerkkommunikation ist möglich. Dies kann bei weiterer Informationsbeschaffung der Netzwerkkomponenten von wesentlichem Vorteil sein. 2. Client agiert rein passiv Eine Netzwerkkommunikation ist nicht möglich, außer über einen separaten Netzwerkadapter. Der Monitor-Modus kann ohne Weiteres mit WinPcap nicht aktiviert werden. Hierzu sind spezielle Adapter, wie beispielsweise der AirPcap-Adapter, notwendig. [4] Promiscuous Mode Beim reinen Promiscuous Modus muss ein Client bereits mit einer spezifischen SSID und einem fixen Kanal verbunden sein. Im Normalfall ist ein sogenannter MAC-Filter aktiv, welcher dafür sorgt, dass ein Client nur jene Pakete auswertet, welche für ihn adressiert sind. Gefiltert wird anhand der Destination MAC-Adresse auf Layer 2 (OSI). Bei den Destination MAC- Adressen kann es sich wie im Ethernet-Netzwerk um Unicast, Multicast und Broadcast Adressen handeln. Der Promiscuous Modus deaktiviert diesen Filter und fängt alle Pakete ab, die der Client auf dieser SSID in diesem Kanal empfängt. Kommt bei einem Netzwerk Verschlüsselung zum Einsatz, kann keine Datenkommunikation zwischen zwei fremden Hosts mitgeschnitten werden. Der Promiscuous Modus verhält sich in diesem Fall gleich wie bei deaktiviertem Promiscuous Modus. Der Client empfängt also nur jene Datenpakete, die für ihn per Unicast, Multicast oder Broadcast adressiert sind. [4] Sind Computer über einen Switch verbunden, können mit dem Promiscuous Modus keine Unicast-Pakete fremder Verbindungen empfangen werden, da diese das Netzwerkinterface des Computers mit aktiviertem Promiscuous Modus nicht erreichen. [5] ANSTEUERN DER NETZWERKKARTE 15

16 8.1.4 Air-Pcap Da der Monitor Modus, wie in Punkt Monitor-Modus schon erwähnt, mit WinPcap nicht ohne weiteres verwendbar ist, werden hierfür spezielle Netzwerkadapter benötigt. Die Firma Riverbed Technology bietet sogenannte AirPcap-Adapter in drei verschiedenen Ausführungen an: AirPcap Classic, AirPcap Tx und AirPcap Nx [6]. Die kostentechnisch günstigste Variante ist der AirPcap Tx USB b/g Adapter für $ auf der Herstellerwebsite (Stand ). Diese werden vom C#-Framework SharpPcap unterstützt, welches bei pinx verwendet wird. Aus finanziellen Gründen wurde im Rahmen der Diplomarbeit kein solcher Adapter gekauft, weshalb auch keine ordnungsmäßige Kompatibilität mit der Software garantiert werden kann. ANSTEUERN DER NETZWERKKARTE 16

17 9 Grundstruktur der Software Da die Software über eine Vielfalt von verschiedenen Netzwerkprotokollen und Funktionen verfügt, ist eine streng objektorientierte Grundstruktur höchste Priorität. Softwaretechnisch ist pinx bis auf wenige Ausnahmen modular aufgebaut. Das heißt, verschiedene Netzwerkprotokolle können nach Belieben hinzugefügt oder gelöscht werden, insofern sie nie als Grundlage für andere Protokolle dienen, wie beispielsweise häufig verwendete Layer 2 Protokolle wie Ethernet. Vor Beginn der Entwicklung wurde in mehreren Meetings ein Standard definiert, der in den nächsten Unterpunkten ausführlich erklärt wird. Im Wesentlichen gibt es pro Netzwerkprotokoll eine Hauptklasse mit eventuellen Unterklassen, Helferklassen mit häufig verwendeten Methoden, Klassen mit häufig verwendeten Variablen, eine Klasse für das Konvertieren und Konkatenieren von Bytearrays und eine Klasse zum Regeln des Netzwerkverkehrs. GRUNDSTRUKTUR DER SOFTWARE 17

18 9.1 Klassendiagramm Abbildung 3 - Klassendiagramm der Software GRUNDSTRUKTUR DER SOFTWARE 18

19 9.2 Interface ITOBYTE Dieses Interface stellt sicher, dass jedes Objekt, welches einem Netzwerkprotokoll entspricht, vollständig in ein Bytearray konvertierbar ist. Dies ist nötig, da die Netzwerkkarte über das Framework SharpPcap nur auf diese Art und Weise angesteuert werden kann. Technische Implementierung 1. internal interface ITOBYTE 2. { 3. byte[] tobyte(); 4. } 9.3 Netzwerkprotokolle Der Grundaufbau der Protokoll-Klassen ist immer gleich und besteht aus vier wesentlichen Komponenten: 1. Variablen 2. Konstruktor(en) 3. Properties 4. ToByte Methode 5. benötigte proprietäre Methoden 9.4 Variablen Jedes Feld im Protokoll wird in der Software als eigene Variable abgebildet. Je nach Größe und Inhalt werden verschiedene C#-Typen verwendet. Ein einzelnes Feld beinhaltet entweder einen Bit Code, einen Text, eine Zahl oder eine Checksumme, welche als Zahl dargestellt wird. Typ Länge C#-Klasse Text Beliebig String Zahl 1 Byte Byte Zahl (Checksumme) 2 Byte Int16 Zahl 4 Byte Int32 Boolean 1 n Bits Bool BitArray Tabelle 4 - Variablentypen und dazugehörige C#-Klassen Besteht ein Byte im Protokoll aus mehreren Feldern, werden die einzelnen Werte in separaten Variablen gespeichert. Während der Konvertierung in der ToByte-Methode wird das jeweilige Byte mittels Bitverschiebung (Addition und Subtraktion) aufgefüllt. Wenn eine Zahl in einem Feld nur im positiven Bereich ist, werden unsignierte Integer verwendet (UInt). Benannt wird in vollen Namen mit kleingeschriebenem Anfangsbuchstaben und CamelCase. GRUNDSTRUKTUR DER SOFTWARE 19

20 Beispiel aus dem OSPF-Protokoll: 1. private byte version; 2. private byte messagetype; 3. private UInt16 packetlength; 4. private string sourceospfrouter; 5. private string areaid; 6. private UInt16 checksumheader = 0; 7. private UInt16 authtype; 8. private UInt64 authdata; 9. private bool checksumcalculated = false; 9.5 Konstruktor(en) Jede Protokollklasse verfügt über mindestens einen Konstruktor, welcher zum Erzeugen eines neuen Objektes verwendet wird. Welche Parameter ein Konstruktor beinhaltet, hängt von der Größe und Komplexität der jeweiligen Klasse ab. Bestimmte Protokolle verfügen über Felder die nur bestimmte Werte annehmen können, beispielsweise Portnummern. In diesem Fall wird als Parametertyp eine Enumeration angegeben, die das Erstellen von Objekten erheblich erleichtern kann. Beispiel Ethernet - Enumeration 1. public enum Types 2. { 3. IPv4 = 0x800, 4. ARP = 0x806, 5. WakeOnLan = 0x842, 6. AppleTalk_Ethertalk = 0x809b, 7. AppleTalkAARP = 0x70f3, } Beispiel Ethernet - Konstruktor 1. public EthernetII(string destinationmacaddress, string sourcemacaddress, Typ es type) : base(destinationmacaddress, sourcemacaddress) 2. { 3. this.type = int.parse(type.tostring("d")); 4. } Ein Objekt kann dadurch wie folgt erzeugt werden: 1. new EthernetII("A6-E A7-8F", " A6-E6-87", EthernetII.Types.IPv4); GRUNDSTRUKTUR DER SOFTWARE 20

21 9.6 Properties Der Wert jeder Variable kann mittels einer Property ausgelesen beziehungsweise geändert werden. In speziellen Fällen muss die Integrität eines Wertes überprüft oder abgeändert werden. Dies ist der Fall, wenn nur spezielle Fälle auftreten dürfen, da anderenfalls ein Logikproblem existiert. Beispielsweise kann die Bridge-Priorität im STP-Protokoll nur in Vielfachen der Zahl 4096 angegeben werden. Die dazugehörige Property in leicht gekürzter Form sieht also wie folgt aus: 1. public int BridgePriority 2. { 3. get 4. { 5. int truevalue = bridgepriority + 0x4fb0; 6. return truevalue; 7. } 8. set 9. { 10. if (value == 0) bridgepriority = 0x00; 11. else if (value == 4096) bridgepriority = 0x10; 12. else if (value == 8192) bridgepriority = 0x20; else if (value == 57344) bridgepriority = 0xe0; 15. else if (value == 61440) bridgepriority = 0xf0; 16. else bridgepriority = 0x10; 17. } 18. } 9.7 ToByte Methode Da die Netzwerkkarte keine einfachen C#-Objekte senden kann, müssen diese zuerst in sogenannte Bytearrays konvertiert werden. Auf diesen Prozess wird im Kapitel Konvertierung näher eingegangen. 9.8 Proprietäre Methoden Je nach Aufbau verschiedener Klassen sind spezielle Vorgänge notwendig. Einige Protokolle können aufgrund ihrer Dynamik auf mehrere Klassen aufgeteilt sein, wobei die einzelnen Komponenten über spezielle Methoden miteinander verbunden werden. Einfacher zu verstehen sind beispielsweise Berechnungen von Checksummen, welche vor dem Senden eines Datenpaketes berechnet werden müssen. 9.9 Helper Aufgrund der wiederkehrenden Verwendung bestimmter Methoden, wurden diese an einen zentralen Ort transferiert, von wo aus sie programmintern global abrufbar sind. Diese Methoden sind vorwiegend für die Konvertierung spezieller Datentypen, wie beispielsweise von MAC- oder IP-Adressen, oder für grundlegende Dateioperationen, wie das Speichern von GRUNDSTRUKTUR DER SOFTWARE 21

22 beliebigen Objekten auf einem lokalen Datenträger. Die Klasse besteht nur aus einer Sammlung von statischen Methoden, welche global verfügbar sind. Beispielmethoden: 1. public static byte [] convertiptobyte(string ip) {... } 2. public static bool IPIsInArea(string min, string mid, string max) {... } 3. public static string generaterandomip() {... } 4. public static string httptypechecker(byte[] rawbytes) {... } 9.10 GV (Globale Variablen) Ähnlich wie die Helper-Klasse dient die abstrakte GV-Klasse als Sammlung. Allerdings keine Sammlung von Methoden, sondern von Variablen mit langer Gültigkeit. Unter langer Gültigkeit versteht man grundlegend Werte, welche sich während der Laufzeit kaum, beziehungsweise nur selten ändern. Ein gutes Exempel hierfür ist die Interfacenummer, die beim Starten des Programms definiert wird. Vor jedem Sende- bzw. Empfangsvorgang wird das jeweilige Interface definiert. Da diese Nummer in der GV-Klasse zentral verfügbar ist, werden im Falle einer Änderung automatisch alle neuen Vorgänge auf dem neuen Interface durchgeführt. Weitere wichtige Werte sind die MAC- und IP-Adressen der verwendeten Netzwerkschnittstelle, eine Liste der Geräte im lokalen Netzwerk und beispielsweise auch eine Liste der geöffneten Ports eines bestimmten Zielcomputers nach einem TCP-Portscan. Die Variablen werden statisch deklariert und können daher einfach über den Methodennamen abgerufen werden. Beispiel: GV-Variablen 1. public static string localmacaddress = ""; 2. public static string localipaddress = ""; Beispiel: Externer Zugriff 1. // Wert setzen 2. GV.localMACAddress = nwint[gv.interfacenumber].getphysicaladdress() 3..ToString(); 4. // Werte abrufen 5. var etn = new EthernetII(GV.destinationMACAddress, GV.localMACAddress, Eth GRUNDSTRUKTUR DER SOFTWARE 22

23 9.11 Paketgeneration (Packal) Während in der normalen Netzwerktechnik das Verfahren der Datenkapselung verwendet wird, verfolgt pinx einen vollständig anderen Ansatz. Bei einer normalen Datenübertragung wird die zu sendende Information sukzessive eingekapselt und mit den dementsprechenden Headerdaten versehen. Beim Generieren eines Datenpaketes durchlauft ein Datenstrom demnach die Schichten des OSI-Modells beginnend von den höheren, hin zu den niedrigeren Schichten [7]. Da pinx als Paketgenerator entwickelt wurde, ist die Reihenfolge komplett entgegengesetzt. Wird beispielsweise ein HTTP-Paket gesendet, werden zuerst die unteren und danach die oberen Layer des OSI-Modells generiert. Folgende Tabelle demonstriert jene Netzwerkprotokolle, welche von der Software schrittweise generiert werden (v. l. n. r.): Beispiel: (Ethernet-Netzwerk) Datenpaket OSI-Layer 2 OSI-Layer 3 OSI-Layer 4 OSI-Layer 7 Ethernet (Typ 2) IP TCP HTTP Tabelle 5 - Softwaretechnischer Aufbau eines HTTP-Datenpaketes Jedes dieser Protokolle wird in der Software als autonomes Objekt dargestellt. Da die Klasse der Netzwerkprotokolle vom Interface ITOBYTE erben, verfügen sie über eine Methode, welche das Objekt vollständig in ein Bytearray konvertieren kann. Diese Methode ist aufgrund der verschiedenen Variablen von Klasse zu Klasse unterschiedlich. Da ein einzelnes Datenpaket alle verwendeten Netzwerkprotokolle beinhaltet, ist es erforderlich, die Resultate der jeweiligen Konvertierungsmethoden zu konkatenieren Funktionsweise Die Klasse beinhaltet eine Liste von ITOBYTE-Objekten. Der Konstruktor nimmt eine Liste mit gewünschten Objekten entgegen und fügt sie aufeinanderfolgend der Liste hinzu. Die Generation des Datenpakets wird über die Methode ListToBytes gestartet. Schritt 1: Ein Algorithmus berechnet die Länge der einzelnen ToByte-Resultate und speichert den finalen Wert in einer dafür vorgesehenen Variablen. Ein neues Bytearray wird mit der zuvor berechneten Größe deklariert. Ist die berechnete Länge zu klein, wird das Bytearray mit der Minimallänge von 60 Bytes deklariert. Die minimale Ethernet Paketlänge beträgt 64 Bytes. Da das vollständige Datenpaket die Frame Check Sequence (FCS) beinhaltet und diese vom Netzwerkinterface berechnet wird, müssen die restlichen vier Bytes nicht weiter berücksichtigt werden [8]. Alle nicht initialisierten Stellen im Array beinhalten die Zahl 0 und werden infolgedessen als Padding interpretiert. GRUNDSTRUKTUR DER SOFTWARE 23

24 Schritt 2: Schritt 3: Die Typen der einzelnen Objekte werden überprüft und bestimmte Werte, wenn erforderlich, reinitialisiert. Dies ist zur Veranschaulichung dann der Fall, wenn der Inhalt einiger Protokollfelder erst bei Generation des Datenpakets bekannt ist. Ein gutes Beispiel hierfür ist das Feld Total Length im IP-Protokoll. Erst wenn die Länge der Nutzdaten auf höheren Schichten bekannt ist, kann der Wert berechnet werden. Die Länge der OSI-Schicht 2 wird bei der Berechnung nicht berücksichtigt, weshalb der Wert noch nicht im ersten Schritt berechnet werden kann. Bei TCP wird die Checksumme sowohl aus dem TCP-Anteil als auch aus der nachfolgenden Payload berechnet. Folglich wird die Checksumme mit der Information der Nutzdaten neu berechnet. Die ITOBYTE-Liste wird sukzessive ausgelesen und die ToByte-Methoden der beinhalteten Objekte aufgerufen. Die Resultate der Methoden werden dem im Schritt 1 deklarierten Bytearray hinzugefügt. Dieser Vorgang führt zu einer Konkatenation der separaten Protokolle zu einem vollständigen Datenpaket. Schlussendlich wird das vollständige Datenpaket über den Return-Parameter zurückgegeben, und es kann zum Senden verwendet werden. Beispiel: Verwendung im Code 1. // Netzwerkprotokolle deklarieren und initialisieren 2. EthernetII etn = new Ethernet(...); 3. IPv4 ip = new IPv4(...); 4. TCP tcp = new TCP(...); 5. HTTP http = new HTTP(...); // Objekt erzeugen 8. Packal packet = new Packal( new List<ITOBYTE>() { etn, ip, tcp, http } ); // Fertiges Datenpaket generieren 11. byte[] datapacket = packet.listtobytes(); 9.12 NetworkTraffic Jegliche Netzwerkkommunikation findet in dieser Klasse statt. Hier befindet sich die Logik für sämtliche Netzwerkabläufe. Im Wesentlichen lässt sich der Aufbau in drei Kernteile klassifizieren: Variablen, Netzwerklogik und die Steuerung der Netzwerkschnittstelle Senden von Datenpaketen Das Senden zählt mitunter zu den leichteren Netzwerkoperationen. Als erstes wird das gewünschte Netzwerkinterface definiert und infolgedessen für den Sendevorgang gestartet. GRUNDSTRUKTUR DER SOFTWARE 24

25 Über eine Methode wird das zuvor generierte Datenpaket schlussendlich gesendet. Dieser Vorgang ist innerhalb eines Try-Catch Blockes, sodass der Benutzer über etwaige Fehler informiert wird. Für diesen Prozess wurde folgende Methode entwickelt: 1. public static void sendpacket(byte[] packetbytes) 2. { 3. var devices = CaptureDeviceList.Instance; 4. var device = devices[interfacenumber]; // Interface definieren device.open(); // Interface bereitstellen try 9. { 10. device.sendpacket(packetbytes); // Datenpaket senden 11. } 12. catch (Exception e) 13. { 14. Console.WriteLine("-- Fehler beim Senden: " + e.message); 15. throw; // Fehlermeldung ausgeben 16. } 17. } Empfangen von Datenpaketen Während des Empfangens von Netzwerkpaketen soll das Programm für den Benutzer weiterhin verwendbar sein. Aus diesem Grund findet der Empfangsprozess immer in einem Hintergrundthread statt. Der Thread wird auf eine Methode definiert, welche solange ausgeführt wird, bis der Thread beendet wird. Es gibt für jede vorgefertigte Funktion eine eigene Methode, da der Vorgang hierbei immer anders ist. In dieser Methode befindet sich meist die Logik, in der die Pakete analysiert, und eventuell Antworten generiert und gesendet werden. Ist der Thread definiert, muss die Netzwerkschnittstelle auf das Empfangen vorbereitet werden. Die Klasse NetworkTraffic beinhaltet einen Handler (device_receive), welcher nach jedem empfangenen Datenpaket aufgerufen wird und die soeben empfangenen Daten einer Liste (PacketQueue) hinzufügt. Im Prinzip wird dieser Handler immer dann verwendet, wenn Pakete in einem bestimmten Zeitraum aufgezeichnet werden müssen. 1. device.onpacketarrival += new PacketArrivalEventHandler(device_Receive); Anschließend wird der Gerätemodus definiert, mit welchem die Daten empfangen werden sollen. Da pinx auch Pakete von anderen Netzwerkteilnehmern empfängt und auswertet, wird der Promiscuous-Modus verwendet. 1. device.open(devicemode.promiscuous); Wenn all diese Parameter festgelegt sind, wird der Vorgang auf dem Netzwerkinterface gestartet: 1. device.startcapture(); GRUNDSTRUKTUR DER SOFTWARE 25

26 Der anfangs definierte Thread prüft nach individuell definierten Zeitintervallen, ob die PacketQueue-Liste neue Einträge beinhaltet. Ist dies der Fall, wird eine temporäre Liste der neuen Pakete erstellt, mit der die beinhalteten Objekte, welche in Bytearrays abrufbar sind, verarbeitet werden können. Werden in dem definierten Zeitintervall keine Datenpakete empfangen, wird die Abfrage für eine kurze Zeit pausiert. PacketQueue-Liste: Temporäre Liste: - Beinhaltet alle Pakete, welche vom Zeitpunkt des Startens bis zum Terminieren des Prozesses empfangen worden sind. - Um die beinhalteten Daten konsistent zu halten, wird bei Lese-/Schreibzugriff die Liste mittels lock für andere Threads gesperrt. - Wird nach definiertem Zeitintervall reinitialisiert - Beinhaltet nur neue Pakete aus dem Zeitraum des definierten Intervalls. Jeder Thread verfügt über einen speziellen Bool-Wert, mit dem der gesamte Empfangsprozess jederzeit von anderen Klassen aus terminiert werden kann Program Die gesamten Softwarefunktionen werden während der Entwicklung in der Program-Klasse gesteuert. Da die Klassen und ein Großteil der Logik Benutzerschnittstellen-unabhängig sind, wurde aus Gründen der Einfachheit eine Konsolenanwendung entwickelt. Verschiedene Programmfunktionen sind auf mehrere Methoden innerhalb der Klasse aufgeteilt, auf welche über ein Konsolenmenü zugegriffen werden kann. Während des Entwicklungsprozesses wurde eine einfachere Benutzerschnittstelle entworfen, um beim Programmieren den Fokus auf die Funktionalität der Software zu setzen. Da die Bedienung dabei sehr umständlich war, wurde die Benutzerschnittstelle neu entwickelt, um mehr Flexibilität zu bieten. GRUNDSTRUKTUR DER SOFTWARE 26

27 Alte Benutzerschnittstelle: Abbildung 4 - Programmmenü (Konsole: ) Neue Benutzerschnittstelle: Abbildung 5 - Programmmenü (Konsole: ) GRUNDSTRUKTUR DER SOFTWARE 27

28 10 Konvertierung Es gibt verschiedene Vorgehensweisen, wie die einzelnen Felder der Netzwerkprotokolle in Bytearrays konvertiert werden können. Bei Zeichenketten (Strings) werden von Textzeichen die dazugehörigen Binärwerte der verwendeten Zeichenkodierung als Bytearray übertragen. Numerische Werte werden direkt in binärer Repräsentation, meist unsigniert, übertragen. In einigen Protokollen, wie beispielsweise TCP, kommen verschiedene, klar definierte Bitmuster zum Einsatz. Entspricht die Größe einem Byte, kann jedes der 8 Bit mit einer bestimmten Funktion versehen werden Objekte in Bytearrays konvertieren Unabhängig vom Aufbau verschiedener Netzwerkprotokolle ist die Vorgehensweise beim Konvertieren der verwendeten Datentypen immer gleich. Um den Programmieraufwand und die möglichen Fehlervektoren zu verringern, sind wesentliche Konvertier-Methoden in der Helper-Klasse. In den dementsprechenden ToByte-Methoden gibt es jeweils mindestens zwei verschiedene Bytearrays. Das Erste (OperatorBytes) dient als temporärer Speicher für das berechnete Byte- Resultat einer Variable und wird verwendet, um das zweite Bytearray (ReturnBytes), welches das gesamte Netzwerkprotokoll in Binärform repräsentiert, aufzufüllen Strings Der überwiegende Großteil der Netzwerkprotokolle verwendet bei Zeichenketten die 7-Bit- Zeichenkodierung ASCII. Diese beinhaltet Zeichen des lateinischen Alphabets, die zehn arabischen Ziffern sowie einige Satzzeichen [9]. Die definierten 128 Zeichen sind deckungsgleich mit den ersten 128 Zeichen der UTF-8 Kodierung, weshalb UTF-8 standartgemäß bei der Konvertierung bei pinx verwendet wird. Helper-Methode: 1. public static byte[] convertstringtobyte(string input) 2. { 3. var encoding = new UTF8Encoding(); 4. return encoding.getbytes(input); 5. } Integer Ganzzahlen werden je nach Größe der deklarierten Variablen mit verschiedenen.net- Methoden konvertiert. Bei pinx werden Zahlen mit der Größe von 8, 16, 32 und 64 Bit verwendet. Beträgt die Größe einer Variable lediglich 8 Bit (1 Byte), wird der Datentyp Byte verwendet und muss nicht extra für den weiteren Gebrauch konvertiert werden. Größere Werte werden direkt mit der dementsprechenden Größe deklariert (Int16, Int32, Int64). Da die Werte größtenteils im positiven Zahlenbereich sind, werden die Integer unsigniert deklariert (UInt16, UInt32, UInt64). KONVERTIERUNG 28

29 Beispiel: Byte 1. // Deklarieren und Initialisieren der Variable 2. Bytes number = // Konvertieren 5. returnbytes[0] = number; Der Datentyp Byte muss nicht extra konvertiert werden, da das Array vom selben Typ ist. Beispiel: Integer (16 Bit) 1. // Deklarieren und Initialisieren der Variable 2. UInt16 number = 4242; // Konvertieren 5. operatorbytes = new Byte[2]; 6. operatorbytes = BitConverter.GetBytes(number); returnbytes[0] = operatorbytes[0]; 9. returnbytes[1] = operatorbytes[1]; Die Methode GetBytes liefert als Rückgabewert ein Bytearray, welches kurzzeitig in der Variable operatorbytes zum Bearbeiten (dazu später mehr) gespeichert wird. Der Unterschied zu größeren Integer-Typen besteht grundsätzlich nur darin, dass mehrere Indexe des Rückgabearrays befüllt werden müssen MAC-Adressen Eine MAC-Adresse verfügt über eine Länge von sechs Bytes, wobei die einzelnen Bytes in der Regel hexadezimal dargestellt werden. Eine typische MAC-Adresse wäre beispielsweise: F-DA-4E. Eine Methode zur Konvertierung von MAC-Adressen in Bytearrays befindet sich in der Helper- Klasse. Diese benötigt als Parameter lediglich ein Objekt vom Datentyp String, welches die MAC-Adresse beinhaltet. Es werden folgende Formate bei der Eingabe unterstützt: F-DA-4E 08:00:27:6F:DA:4E FDA4E Die Konvertierungsmethode trennt die Zeichenkette in mehrere Teile, und konvertiert diese in Zahlen entsprechend ihrer numerischen Repräsentation. Folgende Tabelle demonstriert dies mit drei verschiedenen Zahlensystemen: KONVERTIERUNG 29

30 Hexadezimal Dezimal Binär F DA E Tabelle 6 - MAC-Adresse in hexadezialer, dezimaler und binärer Darstellung IP-Adressen (IPv4) Die Konvertierung von IP-Adressen in Bytearrays ähnelt jener von MAC-Adressen stark. Die einzigen Unterschiede liegen in der Darstellung und der Länge. Eine IP-Adresse verfügt über eine Länge von vier Bytes, wobei die einzelnen Bytes dezimal und mit Punkten getrennt dargestellt werden. Als Beispiel dient hier folgende IP-Adresse aus einem privaten Adressbereich: Eine Methode zum Konvertieren befindet sich wiederum in der Helper-Klasse, da diese global erreichbar ist. Als Eingabeformat wird nur oben beschriebenes unterstützt. Folgende Tabelle demonstriert wieder eine IP-Adresse, dargestellt in verschiedenen Zahlensystemen: Dezimal Hexadezimal Binär 192 C A Tabelle 7 - IP-Adresse in dezimaler, hexadezimaler und binärer Darstellung Wie bereits erklärt, arbeitet pinx mit Bytearrays. Da die optimale Darstellung von Bytearrays Hexadezimal ist, wird in der Software die IP-Adresse wie folgt dargestellt: 0xC0 0xA8 0x01 0x Flags Einige Netzwerkprotokolle verfügen über sogenannte Kontroll-Flags. Ein einzelnes Kontroll- Flag kann die Zustände [1] oder [0] haben, also gesetzt oder nicht gesetzt. Mehrere Kontroll- Flags sind aufgrund ihrer Größe direkt nebeneinander. Ein gutes Beispiel sind die Kontroll- Flags im TCP-Protokoll (Abbildung 4). Ist das jeweilige Bit gesetzt, in diesem Fall das Acknowledgment-Flag, so beinhaltet das dazugehörige Bit den Zustand [1]. KONVERTIERUNG 30

31 Abbildung 6 - TCP-Flags (Wireshark) Im Programmcode gibt es für das Setzen von Bits, abhängig von der Anzahl, zwei verschiedene Lösungsansätze. Der erste Ansatz verwendet die numerische Wertigkeit der einzelnen Bits, und addiert bzw. subtrahiert diese bei Änderung. Im zweiten Ansatz wird ein vollständiges Byte in ein separates Bit-Array konvertiert, sodass die Werte der einzelnen Bits direkt per Zugriff auf den entsprechenden Index geändert werden können Bytearrays in Objekte konvertieren Das Rückkonvertieren von Bytearrays in Objekte erfolgt ziemlich ähnlich. Nicht jedes implementierte Netzwerkprotokoll kann wieder rückkonvertiert werden, sondern nur jene, welche es aufgrund verschiedener Netzwerkoperationen zwingend erfordern. Erforderlich ist es bei verschiedenen Netzwerkoperationen, welche bidirektionale Kommunikation erfordern (Beispiel: TCP-Handshake). Die entsprechenden C#-Klassen der Protokolle verfügen in diesem Fall über einen zusätzlichen Konstruktor, welcher ein Bytearray entgegennimmt. Da ein solches Bytearray das gesamte Datenpaket beinhaltet, ist es notwendig den protokollspezifischen Anteil mit verschiedenen Algorithmen herauszufiltern. Protokolle wie IP und TCP haben spezielle Felder, welche die Information über die Header-Länge beinhalten. Aufgrund dieser Felder ist es möglich das richtige Intervall zu konvertieren. KONVERTIERUNG 31

32 Abbildung 7 - Darstellung des IP-Protokolls (Wireshark) Für die Rückkonvertierung wurden wieder verschiedenste Methoden entwickelt, auf die aber in diesem Dokument nicht weiter eingegangen wird, da sie stark den Methoden zum einfachen Konvertieren ähneln Big-Endian / Little-Endian Architekturen Da es Rechnerarchitekturen mit Big-Endian und Little-Endian Architekturen gibt, ist es essentiell bei Konvertierungen jeglicher Art die entsprechende Architektur zu überprüfen und dementsprechend zu handeln. Der Unterschied zwischen den beiden Architekturen ist, in welcher Reihenfolge die verschiedenen Bytes gespeichert werden. Bei Big-Endian Architekturen werden beispielsweise die höherwertigen Bytes, und bei Little-Endian Architekturen die niederwertigen Bytes zuerst gespeichert. So kann ein bestimmter Wert auf einer Big-Endian Architektur als 0x32 0xA5 und auf einer Little-Endian Architektur als 0xA5 0x32 dargestellt werden. Mit einer einfachen Abfrage kann die Architektur eines Systems überprüft und ein komplettes Bytearray invertiert werden. 1. if (BitConverter.IsLittleEndian) Array.Reverse(operatorBytes); KONVERTIERUNG 32

33 11 Das Programm Aus Gründen der Einfachheit wurde für die Benutzerinteraktion eine zeichenorientierte Benutzerschnittstelle entworfen (Konsolenapplikation). Dies bringt einige Vorteile mit sich. Da die Aus- und Eingabe rein textbasiert ist, kann die Software auch problemlos über einen Shell-Zugriff bedient werden. Somit kann die Software auch auf Geräten installiert werden, zu denen gewöhnlich kein physikalischer Zugriff möglich ist. Ein möglicher Einsatzzweck in diesem Fall wäre beispielsweise der sichere Datenaustausch zwischen den verwendeten Komponenten. Um die Bedienbarkeit zu erleichtern, wird für die zeichenorientierte Darstellung das.net Framework TUI verwendet ( ). Wird die Software gestartet, erscheint direkt das Hauptmenü. Die einzelnen Unterpunkte sind über die Pfeiltasten [Up / Down] erreichbar, und können mit [Enter] ausgewählt werden. Mit dem Menüpunkt Exit wird das Programm beendet. Abbildung 8 - pinx: Hauptmenü, Auswählen der Netzwerkschnittstelle Um Datenpakete zu senden oder empfangen, muss zuerst die entsprechende Netzwerkschnittstelle bekanntgegeben werden. Hierfür genügt ein Klick [Enter] auf den Auswahlpunkt Select Interface. Sofern WinPcap auf dem Rechner installiert ist und die kompatiblen Adapter in den Windows-Einstellungen aktiviert sind, erscheint ein Auswahlfeld in dem die gewünschte Schnittstelle wiederum mit den Pfeiltasten erreichbar ist. DAS PROGRAMM 33

34 Abbildung 9 - pinx: Schnittstellenauswahl, Ist die Schnittstelle gewählt, erscheint ein kleines Info-Fenster mit einigen Informationen. Abbildung 10 - pinx: Informationsfenster, Einige der angezeigten Werte werden direkt in der GV-Klasse gespeichert, um dem Benutzer einige Felder schon automatisch auszufüllen Navigation zwischen Auswahlmenüs Einige Auswahlpunkte beinhalten aufgrund der Vielzahl an Funktionen eigene Untermenüs. Untermenüs werden über die Enter-Taste gestartet, und über den Menüpunkt BACK wieder geschlossen. Die Navigation erfolgt gleich wie bei dem Hauptmenü. DAS PROGRAMM 34

35 Beispiel: Packetgenerator Abbildung 11 - pinx: Untermenü 'Packetgenerator', Eingabemasken Vor allem beim Generieren von Datenpaketen gibt es mehrere Eingabemasken. Diese bestehen in der Regel aus drei verschiedenen Eingabetypen. Textbox Checkbox Combobox Um zwischen den verschiedenen Eingabefeldern zu navigieren, wird die Tabulator-Taste gedrückt. Um in die entgegengesetzte Richtung zu navigieren, wird als Zusatz lediglich die Umschalt-Taste gedrückt. Textbox: Eine Textbox kann mit beliebigen ASCII-Zeichen befüllt werden. Welche Eingabewerte akzeptiert werden, hängt vom entsprechendem Einsatzzweck ab. Bei Netzwerkprotokollen müssen bestimmte Felder gewisse Voraussetzungen erfüllen, da sonst keine ordnungsgemäße Initialisierung eines Objekts gewährleistet werden kann. Um den Benutzer der Software die möglichen Eingabewerte zu veranschaulichen, verfügt jede Feldbeschreibung über entsprechende Hinweise. Die Hinweise beinhalten eine Information über die Länge des Feldes und den Eingabetyp. Die Länge wird als Zahl angegeben, welche die Anzahl der Bits repräsentiert. Der Eingabetyp wird als [N] oder [S] angegeben. [N] steht für einen numerischen Wert, und [S] für eine Zeichenfolge. Eingabefelder, welche mit [N] gekennzeichnet sind, dürfen folglich nur mit Zahlen befüllt werden. Wird ein Eingabefeld vom Benutzer falsch befüllt, können die eingegebenen Daten nicht konvertiert werden und es wird eine entsprechende Fehlermeldung ausgegeben. DAS PROGRAMM 35

36 Beispiel: Identification [16N] Checkbox: Der Eingabewert ist numerisch und verfügt über einen Speicherbereich von 16Bit (2 Bytes). Gültige Eingabewerte sind daher Zahlen im Bereich von 0 bis Dabei ist zu beachten, dass die Protokollfelder stets unsigniert sind (keine negativen Zahlen möglich). Eine Checkbox kann lediglich zwei Werte beinhalten (0 oder 1). Die Verwendung liegt häufig in der Abfrage von bestimmten Abläufen oder bei Netzwerkprotokollen beim Setzen einzelner Bits (Flags). Der Wert einer Checkbox kann geändert werden, indem die Leertaste gedrückt wird. Combobox: Um das Generieren von Datenpaketen einfacher zu gestalten, wurden in einigen Fällen bewusst Comboboxen eingesetzt. Ein Benutzer muss daher beispielsweise nicht alle gängigen Protokollnummern auswendig wissen, sondern kann aus einer Liste die gewünschte wählen. Ein anschauliches Beispiel ist die Eingabemaske für das IP-Protokoll, da diese alle erklärten Eingabefelder beinhaltet: Abbildung 12 - pinx: Eingabemaske 'Configuring Internet Protocol', DAS PROGRAMM 36

37 12 Programmfunktionen Im Menüpunkt Penetrationtesting stehen verschiedene Programmfunktionen zur Auswahl. Für die Durchführung der einzelnen Funktionen muss bereits die gewünschte Netzwerkschnittstelle ausgewählt sein. Da die einzelnen Funktionen vollständig unabhängig voneinander sind, können diese in Zukunft problemlos erweitert werden. In den folgenden Punkten wird erklärt, wie die verschiedenen Funktionen der Software bedient werden, und wie sie bei der Entwicklung realisiert wurden Netzwerkscan / Portscan Die beiden Scanfunktionen Netzwerkscan und Portscan dienen dazu, schnell einen Überblick über ein Netzwerk zu erhalten. Beide Funktionen sind über dieselbe Eingabemaske aufrufbar. Als Eingabeparameter werden lediglich die gewünschte Start- und End-IP-Adresse benötigt, und falls ein Portscan durchgeführt werden soll, auch die gewünschten Start- und End-Ports. Ist ein Portscan gewünscht, so muss die Checkbox perform portscan gesetzt werden. Beispiel: Ein Computer verfügt über folgende IP-Konfiguration: Abbildung 13 ipconfig unter Windows 10 Da der Netzwerkscan auf dem ARP-Protokoll basiert, ist dieser nur innerhalb des verwendeten Subnetzes möglich. In diesem Beispiel kann der IP-Adressbereich von bis gewählt werden. Im Programm werden folgende Parameter gesetzt: Abbildung 14 - Eingabemaske 'Scan your network', Beim Drücken der Enter-Taste erscheint ein Info-Fenster, welches dem Benutzer darüber informiert, dass der Vorgang eine gewisse Zeit in Anspruch nehmen kann. Während des PROGRAMMFUNKTIONEN 37

38 Vorgangs gibt es keine Rückmeldung von der Software. Wurden Geräte im Netzwerk gefunden, so werden diese im folgenden Fenster aufgelistet: Abbildung 15 Auswertung 'Networkscan' Wenn die benötigten Parameter für einen Portscan gesetzt wurden, so kann dieser über erneutes Drücken der Enter-Taste gestartet werden. Aufgrund der Dauer dieses Prozesses, erscheint nach jedem gescanntem Client ein separates Fenster mit einer Übersicht über die offenen Ports. Ist der Vorgang beendet, erscheint eine Übersicht über die gesamten gescannten Geräte, welche mit einem erneuten Drücken der Enter-Taste wieder geschlossen werden kann: Abbildung 16 - Auswertung 'Portscan' Implementierung Softwaretechnisch wurde diese Funktion in zwei voneinander unabhängigen Methoden entwickelt. Da der Portscan die MAC-Adressen der Zielgeräte benötigt, wurde dieser direkt mit der Funktion Netzwerkscan verknüpft. PROGRAMMFUNKTIONEN 38

39 Netzwerkscan: Im angegebenen Adressbereich wird pro IP-Adresse ein ARP-Request gesendet. Im Ethernet- Header wird als Destination-Adresse, da diese unbekannt ist, die Broadcast-Adresse verwendet. Im ARP-Protokoll befinden sich die lokale IP- und MAC-Adresse, die IP-Adresse des derzeitigen Ziels, und die Information, dass es sich um eine Anfrage handelt (Opcode: 1). Abbildung 17 - ARP Request (Wireshark) Ist unter einer angefragten IP-Adresse ein Client im Netzwerk erreichbar, so antwortet dieser mit einem ARP-Paket vom Typ Reply (Opcode: 2) und die darin enthaltenen Informationen über die IP- und MAC-Adresse. Abbildung 18 - ARP Reply (Wireshark) Die erhaltenen Informationen werden zentral in einer Liste für spätere Verwendung, beispielsweise dem Portscan, gespeichert. Portscan: Der Portscan basiert rein auf TCP-Pakete, welche auf das jeweilige Ziel adressiert sind und das Flag [SYN] gesetzt haben. Das Flag informiert den Zielcomputer über einen gewünschten Verbindungsaufbau (TCP-Handshake). Dieser kann die Anfrage entweder per [SYN] und [ACK]- Flag akzeptieren, per [RST]-Flag ablehnen oder den gewünschten Verbindungsaufbau PROGRAMMFUNKTIONEN 39

40 vollständig ignorieren. In folgender Abbildung hat ein Client einen Verbindungsaufbau auf Port 631 akzeptiert. Da das Programm aufgrund dieser Information weiß, dass Port 631 geöffnet ist, sendet es ein weiteres TCP-Paket mit dem Flag [RST], um den Verbindungsaufbau vorzeitig abzubrechen. Abbildung 19 - Offener Port (Wireshark) Die nächste Abbildung zeigt die negativen Rückmeldungen eines Clients, da die gescannten Ports geschlossen sind. Abbildung 20 - Geschlossene Ports (Wireshark) Die Ports an denen ein Verbindungsaufbau zugelassen wurde, werden in Assoziation mit dem gescannten Client wiederum in der GV-Klasse gespeichert. Bei häufig verwendeten Ports befindet sich der Name des dazugehörigen Protokolls in einer Enumeration. Befindet sich ein gescannter Port in dieser Enumeration, so wird der Name in der Zusammenfassung angezeigt. Anderenfalls steht dort lediglich die entsprechende Portnummer. PROGRAMMFUNKTIONEN 40

41 12.2 Trunk-Link aktivieren Unterstützt ein Switch das DTP-Protokoll, und ist dieses aktiviert, so kann pinx dem Switch vortäuschen, dass der verwendete Computer ebenfalls ein Switch ist. Wenn dieser Angriff erfolgreich ist, hat der Computer Zugriff auf alle VLANs. Abbildung 21 - Eingabemaske 'Enable Trunk Link', Die Durchführung eines solchen Angriffes ist mit der Software relativ einfach. Die einzige benötigte Information ist der Domainname. Die MAC-Adressen werden automatisch gesetzt, sofern beim Starten der Software eine Schnittstelle gewählt wurde. Mit der Enter-Taste wird folgendes DTP-Paket mit den konfigurierten Parametern gesendet: Abbildung 22 - DTP-Paket (Wireshark) PROGRAMMFUNKTIONEN 41

42 12.3 STP Angriff Um in Switch-Infrastrukturen eine Schleifenfreiheit zu gewährleisten, wird das Spanning Tree Protocol (STP) verwendet. Am Anfang eines STP-Prozesses wird der Switch mit der niedrigsten Bridge-ID als Root Bridge gewählt. Die Bridge-ID setzt sich aus der Bridge Priorität und der MAC-Adresse zusammen und wird mittels Bridge Protocol Data Unit (BPDU) untereinander ausgetauscht. Die MAC-Adresse wird bei der Wahl der Root Bridge erst berücksichtigt, wenn die Priorität mehrerer Komponenten gleich ist. Da die Root Bridge Priorität im Netzwerkprotokoll nur über 4 einzelne Bits am Anfang eines 2 Bytes großen Feldes dargestellt wird, ist diese nur in Vielfachen der Zahl 4096 anzugeben. Die Bridge Priorität ist im Übrigen die einzige Information, welche in der Software für den Angriff benötigt wird. Beim Starten der Funktion wird ein Hintergrundthread gestartet, welcher alle 2 Sekunden BPDUs schickt, sodass die von der Software geänderte Konfiguration auch erhalten bleibt. Abbildung 23 - Eingabemaske 'Become ROOT-Bridge (STP)', PROGRAMMFUNKTIONEN 42

43 Im Protokoll selbst gibt es zwei separate Felder (Root Identifier & Bridge Identifier), welche aus der Priorität, einer Extension und der MAC-Adresse zusammengesetzt sind. Beide beinhalten die gewählte Priorität und die lokale MAC-Adresse des verwendeten Rechners. Abbildung 24 - STP Protokollfelder (Wireshark) Für den Vorgang werden vom Benutzer keine weiteren Informationen benötigt, da STP auf dem Data Link Layer im OSI-Modell agiert. Beim Ziel handelt es sich um eine Multicast- Adresse, welche eindeutig definiert ist. In folgender Abbildung sind mehrere STP- Datenpakete mit zeitlichen Abständen von 2 Sekunden und der Aufbau der verschiedenen Datenpakete ersichtlich: Abbildung 25 - STP Datenpakete (Wireshark) 12.4 CDP Flood Das Cisco Discovery Protocol dient dazu, eine Liste direkt angeschlossener Geräte zu erzeugen. Ebenso wie STP agiert auch CDP am Data Link Layer im OSI-Modell [10]. Da die vorgetäuschten Geräte per Zufallsgenerator generiert werden, wird lediglich eine Anzahl der zu sendenden Geräte benötigt. Der Benutzer kann entweder einen spezifischen Wert eingeben, oder das entsprechende Eingabefeld leer lassen und den Vorgang mittels [Enter] nach einer gewünschten Zeit abbrechen. PROGRAMMFUNKTIONEN 43

44 Abbildung 26 - Eingabemaske 'Flood CDP-Table', In folgendem Screenshot ersichtlich sind die verschiedenen Kategorien der Protokollfelder. Bestimmte Werte wie beispielsweise die IP-Adresse und die Device-ID werden mittels Zufallsgenerator generiert. Andere Werte sind von Paket zu Paket gleich, da sie nicht zum Erfolg des Angriffes beitragen. So beinhaltet jedes CDP-Paket die Information, dass es von der Software pinx-gpa gesendet worden ist. Abbildung 27 CDP Datenpakete mit Protokollfelder (Wireshark) 12.5 DHCP Starvation Über das Dynamic Host Configuration Protocol (DHCP) können neue Netzwerkkomponenten von einem DHCP-Server eine IP-Konfiguration beantragen. Ein DHCP-Server verfügt über einen vom Administrator konfigurierten IP-Adressbereich, aus dem er einzelnen Clients PROGRAMMFUNKTIONEN 44

45 bestimmte IP-Adressen zuweisen kann. Da ein Client beim Senden einer DHCP Discover Nachricht im Normalfall über keine IP-Konfiguration verfügt und auch nicht weiß, unter welcher Adresse der DHCP-Server erreichbar ist, sendet dieser die Anfrage an die Broadcast Adressen im Data Link- und Network Layer (OSI Modell Schicht 2 und 3). Da die Datenpakete vollständig automatisch erzeugt werden, ist keine weitere Benutzerinteraktion erforderlich. Bei der Wahl des Menüpunktes erscheint lediglich die Information, dass der Prozess ausgeführt wird. Wie bereits bei anderen Funktionen erklärt, kann der Vorgang mittels [Enter]-Taste abgebrochen werden. Abbildung 28 - Information 'Flooding DHCP-Requests', Die MAC-Adresse des vermeintlichen Absenders wird bei jedem Datenpaket neu generiert. Dies hat zur Folge, dass ein Netzwerkgerät, welches sich zwischen Client und Server befindet, die generierte MAC-Adresse in die lokale ARP-Tabelle aufnimmt. Der DHCP-Anteil der gesendeten Datenpakete ist bis auf die beinhaltete MAC-Adresse immer gleich, und sieht wie folgt aus: Abbildung 29 - DHCP Protokoll (Wireshark) PROGRAMMFUNKTIONEN 45

46 Mit dieser Funktion kann der gesamte IP-Adressbereich auf einem DHCP-Server reserviert werden, sodass dieser zukünftig keine neuen IP-Konfigurationen zuweisen kann. Ein neuer Client im Netzwerk erhält in diesem Fall keine IP-Adresse und ist daher nicht in der Lage, eine IP-Verbindung zu anderen Netzwerkgeräten aufzubauen. Zusätzlich kann bei neuen Anfragen eine gefälschte DHCP-Antwort gesendet werden, wobei der Rechner des Angreifers als Default-Gateway eingetragen ist. Somit würde ein großer Teil der Netzwerkkommunikation über den Rechner des Angreifers gesendet werden, und dieser könnte problemlos eine Manin-the-Middle Attacke ausführen Wake-On-LAN Mittels Wake on LAN (WOL) kann ein Netzwerkgerät, welches diese Funktion unterstützt, über die eingebaute Netzwerkkarte eingeschaltet werden. Das Datenpaket ist sehr einfach gehalten und kann per Unicast und Broadcast an das Ziel geschickt werden. Die Eingabemaske für diese Funktion benötigt die MAC-Adresse des Zielcomputers und, falls konfiguriert, auch ein Passwort. Abbildung 30 - Eingabemaske 'Send Wake-On-Lan Message', verwendet in Schicht 2 und 3 des OSI-Modelles die jeweiligen Broadcast Adressen. Der Wake On LAN-Anteil besteht aus dem sogenanntem Sync stream, welcher 6 Bytes lang ist und den hexadezimalen Wert FF beinhaltet. Anschließend befindet sich eine 16-malige Wiederholung der Ziel MAC-Adresse und, falls gesetzt, das jeweilige Passwort. Tabelle 8 - Hexadezimale Darstellung eines WOL-Datenpakets im Wireshark PROGRAMMFUNKTIONEN 46

47 12.7 DDOS TCP Syn-Flood Der Verbindungsaufbau beim TCP-Protokoll findet über den sogenannten Three-Way- Handshake statt. Dieser beruht auf drei Datenpaketen, welche zwischen zwei Komponenten ausgetauscht werden. Der Ablauf eines vollständigen Three-Way-Handshakes ist wie folgt: 1) Ein Client sendet ein TCP-Paket an den Server, welches den gewünschten Ziel- Port enthält, und das SYN-Flag gesetzt hat. 2) Der Server antwortet dem Client mittels SYN- und ACK-Flag. 3) Der Client bestätigt den Verbindungsaufbau mittels Flag ACK. Bei einem TCP Syn-Flood wird die letzte Bestätigungsnachricht vom Client unterschlagen. Am Server existiert somit eine halboffene Verbindung welche einige Ressourcen benötigt. Werden viele halb offene Verbindungen aufgebaut, können die Ressourcen am Server schnell aufgebraucht werden, und dieser kann auf neue Verbindungen nicht mehr antworten. Dies führt zu einer Zugriffsverweigerung (Denial of Service). Die Software benötigt für diesen Angriff die MAC- und IP-Adresse des Zielgerätes. Befindet sich das gewünschte Ziel außerhalb des eigenen Subnetzes, so muss im Eingabefeld Destination MAC-Address: die MAC-Adresse des Default-Gateways angegeben werden. Abbildung 31 - Eingabemaske 'DDOS - TCP Syn-Flood', PROGRAMMFUNKTIONEN 47

48 Da die Absenderadressen dynamisch generiert werden, können die entsprechenden Antworten vom Server nicht empfangen werden. Wird der Datenverkehr während einer solchen Attacke mitgeschnitten, werden schnell die ARP-Anfragen der anderen Netzwerkteilnehmer ersichtlich, da diese die generierten IP-Adressen für Geräte im lokalen Netzwerk halten. Abbildung 32 - Datenverkehr während einer DDOS-Attacke (Wireshark) 12.8 HTTP Payload-Sniffing Beim Übertragen von größeren Dateien werden diese meist auf mehrere einzelne Datenpakete aufgeteilt. In einer typischen Client-Server Kommunikation, wie beispielsweise beim Aufrufen einer Website, geschieht der Datenaustausch in den meisten Fällen über das verbindungsorientierte Netzwerkprotokoll TCP. Für zusätzliche Informationen wie das Dateiformat oder den Dateinamen wird im Normalfall das HTTP-Protokoll verwendet. Im folgenden Beispiel wird der Ablauf einer Dateiübertragung über einen Internetbrowser erklärt: Schritt 1: Zwischen Server und Client besteht eine TCP Verbindung. Der Client sendet einen HTTP GET-Request an den Server mit der Information der gewünschten Datei. Abbildung 33 - HTTP GET-Request (Wireshark) Schritt 2: Der Server erhält die Anfrage und überprüft, ob die Datei existiert. Ist dies der Fall, sendet er die Datei über das HTTP-Protokoll mit dem Statuscode 200. Im ersten Datenpaket befinden sich auch einige zusätzliche Informationen, welche dem HTTP-Header entnommen werden können. PROGRAMMFUNKTIONEN 48

49 Abbildung 34 - HTTP OK (Wireshark) Nach dem http-header beginnt direkt der Abschnitt für die Datei, welche ebenfalls als Bytearray übertragen wird. Abbildung 35 - GIF-Datei (Wireshark) Schritt 3: Da die Dateigröße in den meisten Fällen größer als die maximale Paketgröße ist, wird die Datei in mehreren Datenpaketen, sogenannten TCP-Segmenten, gesendet. Abbildung 36 - TCP Segmente (Wireshark) Die Aufgabe des Clients besteht darin, die zueinander gehörenden TCP-Segmente zu finden, sortieren, validieren und reassemblieren. Unter einer Reassemblierung wird in diesem Dokument das Zusammenfügen von mehreren Datenpaketen verstanden. Die Funktion HTTP-Payload Sniffing ist dazu in der Lage, Dateien, welche über den erklärten Mechanismus gesendet werden, abzufangen und auf der Festplatte zu speichern. Mit diesem Feature kann ein Benutzer auf eine schnelle Art und Weise herausfinden, ob kritische Dateien unverschlüsselt übertragen werden, um im Nachhinein entsprechende Vorkehrungen zu treffen. Der Prozess wird gestartet, sobald der entsprechende Menüpunkt gewählt wurde. PROGRAMMFUNKTIONEN 49

50 Abbildung 37 - Message 'Sniffing pictures from local network!', Wird nun eine Website aufgerufen auf der sich Bilder befinden, werden die dazugehörigen Datenpakete abgefangen, zusammengefügt und schlussendlich als Datei exportiert. Im Rahmen dieser Diplomarbeit wurden die Dateiformate PNG, JPEG und GIF für diese Funktion implementiert. Abbildung 38 - HTTP Payload-Sniffing / Ergebnis Reassemblierung von segmentiertem TCP-Payload Die Implementierung dieser Funktion war mitunter eine der herausforderndsten Aufgaben der gesamten Diplomarbeit. Der Hauptaufwand hierbei lag in der Analyse der genauen Funktionsweise von TCP. Zur Überprüfung, ob ein einzelnes Datenpaket eine vollständige Datei beinhaltet, oder ob es nur ein einzelnes Segment einer längeren TCP-Kommunikation PROGRAMMFUNKTIONEN 50

51 ist, wurden mehrere Abfragen entwickelt. Ob eine Datei übertragen wird, erkennt die Software anhand der GET-Anfrage vom Client. In dieser GET-Anfrage befinden sich Informationen über den Dateityp und den Dateinamen. Wird eine solche Abfrage von der Software erkannt, werden wesentliche Informationen in eine Liste unvollständiger Dateien aufgenommen. Ob ein Server auf die Anfrage antwortet, kann mittels Sequence- und Acknowledgmentnumber im TCP-Header erkannt werden. Die Sequencenumber wird bei jedem Datenpaket neu berechnet und ergibt sich aus der Sequenznummer des vorherigen Datenpaketes und der Datenpaketgröße. Die Acknowledgmentnumber beinhaltet die letzte erhaltene Sequencenumber des Kommunikationspartners. Eine korrekte Serverantwort ist für das Programm demnach ein Datenpaket, welches an den Client mit den spezifischen Portnummern adressiert ist, die Sequencenumber des letzten Datenpaketes vom Client im Protokollfeld Acknowledgmentnumber beinhaltet und auf Schicht 7 im OSI-Modell das HTTP Protokoll mit der Statusnummer 200 beinhaltet. Der HTTP-Header endet mit dem Bytecode 0x0D 0x0A 0x0D 0x0A. Die nachfolgenden Daten beinhalten die Binärdaten der gesendeten Datei. Ist diese auf mehrere TCP-Segmente aufgeteilt, geschieht die Zuordnung wiederum über die Sequence- und Acknowledgmentnumber. Nach jedem Datenpaket werden die letzten zwei Bytes analysiert. Mithilfe von MIME-Sniffing kann auf diese Weise erkannt werden, ob eine Datei vollständig übertragen worden ist. Wurde eine Datei vollständig übertragen, wird der Bytestream in einen bestimmten Ordner auf die Festplatte geschrieben. Der Dateiname wurde während der GET-Anfrage vom Client gespeichert und kann somit in Assoziation mit den reinen Daten gespeichert werden MIME-Sniffing Jeder der implementierten Dateitypen verfügt über eine eindeutige Dateiendung. Wird diese Dateiendung zum Schluss eines Datenpaketes erkannt, wird davon ausgegangen, dass die Datei vollständig übertragen worden ist Steganographie Steganographie ist ein Verfahren, mit dem Informationen verborgen ausgetauscht werden können. In der Software gibt es zwei verschiedene Implementierungen, welche auch zusammen verwendet werden können. Beim ersten Ansatz werden Informationen innerhalb einer Multimediadatei gespeichert (LSB-Transmission), beim zweiten Ansatz werden die Informationen mit Netzwerkprotokollen übertragen, welche für Datenaustausch prinzipiell ungeeignet sind. PROGRAMMFUNKTIONEN 51

52 Netzwerkprotokolle Der Grundgedanke bei dieser Funktion ist es, Datenaustausch transparent zu gestalten. Dateien sollen somit über Protokolle gesendet werden, welche nicht dafür ausgelegt sind. Prinzipiell ist diese Funktion mit jedem Protokoll möglich, allerdings zeigen Netzwerksniffer wie Wireshark einige dieser Protokolle aufgrund sämtlicher Parameter als ungültig an. Im Rahmen dieser Diplomarbeit wurden vier wesentliche Protokolle implementiert, mit denen ein Datenaustausch über den Payload möglich ist. Die Protokolle sind IP, ICMP, UDP und das selbstentwickelte Netzwerkprotokoll pinx. Der Ablauf dieses Prozesses ist bei jedem verwendetem Netzwerkprotokoll derselbe. Anfangs wird ein Initialisierungspaket gesendet, sodass der Empfänger der Nachricht weiß, dass eine Datenübertragung beginnt. Nach dem Initialisierungspaket folgen die Binärdaten der gesendeten Datei. Wenn die Übertragung der Datei beendet ist, wird ein sogenanntes Endpaket gesendet. Die Initialisierungs- und Endpaketsignaturen sind unabhängig vom Erfolg des Prozesses und wurden auf die Byte- Repräsentationen der Zeichenketten >>pinxinit<< und >>pinxend<< definiert. In folgender Abbildung wurde ein Initialisierungspaket mit den Eigenschaften des OSPF- Protokolls gesendet. Aufgrund der beinhalteten Informationen wird das Paket im Wireshark als ungültig deklariert, da es aufgrund der beinhalteten Daten auch nicht dem OSPF-Standard entspricht. Abbildung 39 - Initialisierungspaket 'pinxinit' über OSPF (Wireshark) Eine Validitätsprüfung kann ebenfalls ohne großen Aufwand durchgeführt werden, indem das typische Netzwerkverhalten hierfür genutzt wird. Sendet ein Client einen Echo-Request zu einem bestimmten Zielgerät, beinhaltet dieses eine gewisse Anzahl von Daten. Das Zielgerät überprüft die Checksumme und sendet bei Richtigkeit dieselben Daten als Echo-Reply wieder zum Client zurück. Der Client weiß somit, dass das Zielgerät die Anfrage korrekt erhalten hat und interpretiert den Vorgang als erfolgreichen ping. PROGRAMMFUNKTIONEN 52

53 Abbildung 40 - Datenübertragung per Echo-Request (Wireshark) Least-Significant-Bit PinX verfügt über die Möglichkeit, Text innerhalb eines Bildes zu verstecken und auszulesen. Der Text wird hierbei in ein Bitarray konvertiert und die Pixelanzahl des Bildes bestimmt. Mithilfe von zwei Schleifen wird die für die Information benötigte Pixelanzahl eingelesen und das jeweilige letzte Bit so verändert, dass es mit dem Array übereinstimmt. Die Grundidee dieser Funktion wurde nicht selbstständig entwickelt. Es wurde lediglich das Verfahren für einen sicheren Informationsaustausch implementiert. PROGRAMMFUNKTIONEN 53

54 13 Entwicklung einer zeichenorientierten Benutzerschnittstelle Die vollständige Umsetzung der Software als Konsolenapplikation bringt viele Vorteile mit sich. Es gibt nur wenige bedienbare Elemente und die Navigation bleibt immer gleich. Die Lernphase für einen neuen Benutzer gestaltet sich somit sehr kurz. Die Navigation im Menü geschieht mit den Pfeiltasten, Menüpunkte können mittels [Enter]-Taste aufgerufen werden, der Wert von Checkboxen kann mit der [Leertaste] geändert werden und Infonachrichten können mittels [Esc]-Taste geschlossen werden. Anfangs bestand das Design aus entwicklungstechnischen Gründen aus einem einfachen Zahlenmenü. Jeder Menüpunkt hatte eine eindeutige ID über welche er aufgerufen wurde. Die Abfrage geschah in einem Switch- Case Block. Abbildung 41 - ID-basierte Menüoberfläche Die Bedienung war allerdings sehr umständlich und unflexibel. Aus diesen Gründen des Bedienkomforts wurde die Entscheidung getroffen, eine interaktive Benutzerschnittstelle zu entwickeln, welche mit wenigen Tasten bedient werden kann und ein Hauptmenü beinhaltet, welches ohne großen Aufwand erreichbar ist. Die Suche nach einem passendem TUI- Framework (Text-based user interface) gestaltete sich relativ schwierig. Nach einer dreitägigen Test- und Lernphase wurde das Framework TuiBase gewählt ( ). ENTWICKLUNG EINER ZEICHENORIENTIERTEN BENUTZERSCHNITTSTELLE 54

55 13.1 Framework - TuiBase Das Framework beinhaltet pro verfügbarem Element eine eigene C#-Klasse. Alle Softwareklassen, welche ein TUI-Interface benötigen, müssen von verschiedenen Schnittstellen erben. Beim Starten der Software werden die Größe und der Titel der Konsole definiert und die TUI-Laufzeitumgebung initialisiert. Anschließend wird das Hauptmenü erstellt, welches danach direkt gestartet wird. Jedem Menüpunkt wird eine spezielle Funktion zugewiesen, welche aufgerufen wird, sobald ein Menüpunkt gewählt wird. Einem Menü kann zusätzlich eine Größe, Position und eine Farbe zugewiesen werden. 1. Console.WindowWidth = 120; 2. Console.WindowHeight = 40; 3. Console.Title = "pinx"; 4. TuiBase.WindowRuntime.Initialize(); TuiBase.PopUpMenu mainmenu = null; 7. mainmenu = new TuiBase.PopUpMenu("Hauptmenü", new TuiBase.PopUpMenuItem[] { 8. new TuiBase.PopUpMenuItem("Menüpunkt", PUM_Function1), 9. new TuiBase.PopUpMenuItem("Exit",() => mainmenu.close()) 10. }); 11. mainmenu.size = new TuiBase.Console.Coordinates(45, 5); 12. mainmenu.location = new Coordinates(1, 1); TuiBase.WindowRuntime.Run(new ConsoleImpl(), mainmenu); In den ersten drei Zeilen des angegebenen Code-Exemplars wird die Größe der Konsole und der Titel definiert, in den Zeilen sieben bis neun werden der Name des Menüs gesetzt und die Menüpunkte hinzugefügt und in den Zeilen elf bis zwölf werden die Größe und Position des Menüs gesetzt. Der angegebene Code erzeugt somit ein Menü mit der horizontalen Größe von 45 Zeichen und der vertikalen Größe von 5 Zeilen. Abbildung 42 - Demonstration eines Menüfensters Window: Ein Fenster ist ein selbstständiger Bereich mit definierter Größe und Position. Die einzelnen Attribute und der Inhalt werden in einer eigenen Klasse definiert. Der Inhalt eines Fensters kann aus mehreren Elementen bestehen. Typisch hierfür sind Textboxen, Checkboxen, Comboboxen und einfacher Text. Jedes dieser Elemente verfügt wiederum über eine Vielzahl von Attributen, welche pro Element definiert werden können. In der Software werden solche Fenster vorwiegend für Eingabemasken verwendet. ENTWICKLUNG EINER ZEICHENORIENTIERTEN BENUTZERSCHNITTSTELLE 55

56 Ist der Aufbau eines Fensters erstmals definiert, kann dieses über den Konstruktor der Klasse gestartet werden: 1. WIN_WakeOnLan win_wol = new WIN_WakeOnLan(); 2. win_wol.showdialog(); Der Aufbau einer Fenster-Klasse ist wie folgt: 1. class WIN_WakeOnLan : TuiBase.Window 2. { 3. // Deklaration der einzelnen Elemente 4. public TextPanel _info; 5. public TextBox _destinationmac; 6. public TextBox _password; public WIN_WakeOnLan() 9. { 10. Text = " Send Wake-On-Lan Message "; 11. Size = new Coordinates(100, 7); 12. Location = new Coordinates(10, 5); 13. Foreground = ConsColor.White; 14. Background = ConsColor.Blue; _destinationmac = new TextBox("Destination MAC- 17. Address: "); 18. _destinationmac.location = new Coordinates(1, 3); 19. _destinationmac.size = new Coordinates(45, 1); 20. SetActiveControl(_destinationMac); 21. AddControl(_destinationMac); } 24. } Abbildung 43 - TuiBase - Window Ein Fenster wird geschlossen, sobald die [Enter]- oder [Esc]-Taste gedrückt wird. Auf die vom Benutzer gesetzten Attribute kann mit dem Objekt zugegriffen werden, von welchem aus das Fenster gestartet wurde: 1. string destinationmacaddress = win_wol._destinationmac.text; ENTWICKLUNG EINER ZEICHENORIENTIERTEN BENUTZERSCHNITTSTELLE 56

57 Message-Box: Eine Message-Box ist optisch betrachtet einem Fenster sehr ähnlich. Der Unterschied besteht darin, dass eine Message-Box nur Text beinhaltet und daher keine eigene Klasse benötigt. Die einzelnen Textzeilen werden über ein String-Array übergeben. Standardattribute wie Größe, Farbe und Position können auch hierbei gesetzt werden. 1. TuiBase.MessageBox example = new TuiBase.MessageBox(" Interface: ", 2. new string[] { 3. " -> Mit [ESC] konnen Sie diese Information wieder schliessen." 4. }); mb_selectedinterface.location = new Coordinates(20, 3); 7. mb_selectedinterface.size = new Coordinates(80, 9); 8. mb_selectedinterface.showdialog(); ENTWICKLUNG EINER ZEICHENORIENTIERTEN BENUTZERSCHNITTSTELLE 57

58 14 Das pinx-protokoll Das pinx-protokoll ist ein eigenständig entwickeltes Netzwerkprotokoll mit Hauptverwendung in der Datenübertragung. Eine weitere Verwendung ist der Shell-Zugriff auf Zielgeräte. Aufgrund Zeitmangels wurde im Rahmen der Diplomarbeit das gesamte Konzept geplant, allerdings nur der reine Datenaustausch implementiert. Der Vorteil des Protokolls liegt in der Einfachheit und der Individualität. Da dieses Protokoll nur von der Software pinx verwendet wird, fällt es den gängigen Netzwerkanalysetools schwer, die abgefangenen Daten auszuwerten. Das pinx-protokoll bietet Funktionen zum Testen der Datenintegrität, verschiedene Pakettypen für unterschiedliche Einsatzbereiche, Empfangsbestätigungen und die Anfrage zur erneuten Übertragung bei Misserfolg und die Möglichkeit, mehrere Daten gleichzeitig in separaten Kanälen zu übertragen. Im IP-Header wird als Information für die nächsthöhere Schicht die Protokollnummer 253 verwendet. Diese Protokollnummer ist für experimentelle Zwecke reserviert und wird in der Netzwerkanalysesoftware Wireshark als Unknown angezeigt Funktionsweise Der Header des Protokolls besteht aus sechs Feldern, welche insgesamt eine Größe von 64 Bits in Anspruch nehmen Typ Flags CRC16 Checksum Connection Reserved Sequence Number = >>pinxdata: = Abbildung 44 - Aufbau des pinx-protokolls Typ: Das Typenfeld verfügt über eine Länge von acht Bits. Das Feld definiert, um welchen Pakettyp es sich handelt. Dabei gibt es fünf standarisierte Werte, alle weiteren sind für experimentelle Zwecke reserviert. Typ: 0... Initialisierungspaket 1... Finalisierungspaket 2... Benutzerdatenpaket 3... Kontrollpaket (RemoteControl) 4... Bestätigungspaket 5... Prüfsummenpaket (Mit Hashwert) >5... Reserviert Abbildung 45 - Auflistung verschiedener pinx-pakettypen DAS PINX-PROTOKOLL 58

59 Initialisierungspaket: Das Initialisierungspaket wird verwendet, um das Zielgerät über eine zukünftige Datenübertragung zu informieren. Finalisierungspaket: Ist eine Datenübertragung abgeschlossen, wird ein Finalisierungspaket gesendet. Das Zielgerät weiß somit, dass keine weiteren Datenpakete folgen und wertet die erhaltenen Daten aus. Benutzerdatenpaket: Beinhaltet ein Datenpaket eine Datei, beziehungsweise ein Segment davon, wird dieses als Benutzerdatenpaket initialisiert. Kontrolldatenpaket: Ein Kontrolldatenpaket beinhaltet im Wesentlichen Befehle, welche am Zielgerät in der Shell ausgeführt werden sollen. Bestätigungspaket: Bestätigungspakete werden vom Zielgerät gesendet, um dem Sender über den Erfolg einer Datenübertragung zu informieren. Prüfsummenpaket: Ein Prüfsummenpaket beinhaltet einen Hashwert der Gesamtdatei, um die Datenintegrität beim Empfänger zu gewährleisten Flags: Die Flags verfügen wie das Typenfeld über eine Länge von acht Bit. Es sind fünf Flags standardisiert, die restlichen drei dienen zu Testzwecken. Die Sinnhaftigkeit hierbei ist es, den Kommunikationspartner über gewünschte Einstellungen zu informieren oder von ihm gewisse Pakete anzufordern. Flags: COD - confirmation desired HAF - hash follows DTS - data transmission successfully DTF - data transfer failed RET - retransmission Reserviert Reserviert Reserviert Abbildung 46 - Flags im pinx-protokoll DAS PINX-PROTOKOLL 59

60 COD Fordert vom Zielgerät eine Empfangsbestätigung an. HAF Informiert über die Übertragung eines Hashwertes nach dem Finalisierungspaket. DTS Informiert über Gültigkeit bei Integritätsprüfung (Nur bei Hashüberprüfung). DTF Informiert über Ungültigkeit bei Integritätsprüfung (Nur bei Hashüberprüfung). RET Fordert eine erneute Übertragung an. Tabelle 9 - Übersicht über die Flags im pinx-protokoll Checksum: Über die gesendeten Nutzdaten (Payload) wird eine CRC16-Checksumme berechnet. Entspricht die Länge der Nutzdaten einer ungeraden Zahl, so wird das Bytearray um ein Byte erweitert. Die Wertigkeit des letzten Bytes wird somit um den dezimalen Wert 256 multipliziert. Beinhaltet das jeweils letzte Byte in den Nutzdaten den hexadezimalen Wert 0xa7, so wird dieser nach dem Vorgang um den Wert 256 größer. Der neue Wert der letzten zwei Bytes beträgt somit: 0xa Connection: Wenn zur gleichen Zeit mehrere Dateien zwischen zwei Komponenten übertragen werden, so können 254 separate Kanäle dafür verwendet werden. Während einer Datenübertragung bleibt die Kanalnummer immer gleich. Der Lösungsansatz ist an die Funktionsweise der verschiedenen Ports von TCP angelehnt Reserved: Dieses Protokollfeld ist für Testzwecke geeignet, um die Funktionsweise des Protokolls bei Experimenten nicht zu verändern Sequence Number: Während einer Datenübertragung werden mehrere Datenpakete gesendet. Die Sequenznummer dient hierbei der Sortierung auf Empfängerseite, da es in einem IP-Netzwerk vorkommen kann, dass Datenpakete, welche später übertragen wurden, früher empfangen werden. Der Wert dieses Feldes beginnt mit dem Initialisierungspaket bei 0 und dient zur Reassemblierung der einzelnen Datenpakete pinxdata: Dieses Feld hat eine variable Größe, welche von der Länge der Daten und der maximalen Paketgröße abhängt. In jedem Datenpaket werden die Nutzdaten mit einer standardisierten Signatur versehen. Der Empfänger weiß somit, um welche Daten es sich handelt. Eine pinx- Signatur ist eine kurze Zeichenkette, welche auch für einen Menschen in ASCII- Repräsentation leicht lesbar ist. Unterschieden werden fünf verschiedene Datentypen: DAS PINX-PROTOKOLL 60

61 >>pinxinit<< Beinhaltet den Dateinamen der zukünftigen Datensegmente >>pinxdat: Beinhaltet die Datenbytes >>pinxhash: Beinhaltet einen Hash-Wert >>pinxcont: Beinhaltet Kommandozeilenbefehle, welche ausgeführt werden sollen >>pinxend<< Kennzeichnet das Ende einer Übertragung Tabelle 10 - Übersicht über die verschiedenen pinx-signaturen 14.2 Das Protokoll im Einsatz Im folgenden Beispiel wird eine PNG-Datei mit einer Größe von Bytes übertragen. Die maximale Dateigröße wurde für diese Übertragung auf 1000 Payload-Bytes pro Datenpaket beschränkt. Die Größe des Headers beträgt 8 Byte. Der String-Header bei der Payload- Spezifikation beträgt bei Datenpaketen mit Bildinformation 10 Byte. Die Gesamtlänge berechnet sich somit auf 1018 Byte pro Datenpaket (pinxdat). Initialisierungspaket: Der Sender definiert die gewünschte Ziel IP-Adresse und wählt eine Datei, welche gesendet werden soll. Beim Starten des Vorgangs sendet die Software einen ARP-Request, um die MAC- Adresse des Zielgerätes ausfindig zu machen. Sobald die MAC-Adresse bekannt ist, wird das erste Initialisierungspaket gesendet. Die String-Spezifikation ist in folgender Abbildung im unteren rechten Bereich der ASCII-Darstellung der Bytearrays zu sehen. Abbildung 47 - pinx Initialisierungspaket (Wireshark) Da die minimale Paketlänge bei diesem Initialisierungspaket nicht erreicht wird, wird der restliche Bereich mit einer Reihe von Nullen aufgefüllt (Padding). Benutzerdatenpakete: Da die Dateigröße der PNG-Datei größer als die definierte maximale Datenpaketgröße ist, wird die Übertragung in mehrere Segmente aufgeteilt. Es werden 16 Datenpakete mit einer Payloadgröße von 1052 Bytes, und ein letztes Datenpaket mit einer Größe von 469 Bytes gesendet (inklusive Protokoll-Header). DAS PINX-PROTOKOLL 61

62 Abbildung 48 - Anzahl gesendeter Benutzerdatenpakete des pinx-protokolls (Wireshark) Die einzelnen Benutzerdatenpakete beinhalten wiederum nach dem Header die jeweilige String-Spezifikation. Direkt nach dieser folgen die Byte-Informationen der PNG-Datei. Im ersten Benutzerdatenpaket sind in der ASCII-Darstellung für einen erfahrenen Benutzer somit auch die Header-Informationen der Bilddatei ersichtlich. Abbildung 49 - Benutzerdatenpaket des pinx-protokolls (Wireshark) DAS PINX-PROTOKOLL 62

63 Finalisierungspaket: Die Datenübertragung ist nach insgesamt 21 Datenpaketen (inklusive ARP-Messages) abgeschlossen. Das letzte Datenpaket ist das Finalisierungspaket. Ebenso wie das Initialisierungspaket beinhaltet es im Payload-Bereich lediglich die reine String-Spezifikation. Abbildung 50 - Finalisierungspaket des pinx-protokolls (Wireshark) DAS PINX-PROTOKOLL 63

64 15 Herausforderungen Während des Entwicklungsprozesses gab es eine Reihe von Herausforderungen, welche zum Großteil vollständig bewältigt wurden. In den verschiedenen Projektphasen mussten teilweise mehrere Meetings ausgemacht werden, um den weiteren Projektverlauf und die verschiedenen Lösungsansätze zu diskutieren. In der Anfangszeit kam es vermehrt zu Meinungsverschiedenheiten zwischen den Teammitgliedern, welche allerdings im Rahmen der Meetings behoben wurden. Eine große Herausforderung und zugleich auch ein wesentlicher Meilenstein in der Projektplanung war die Erstellung der Softwarearchitektur. Als diese eindeutig definiert war, waren das Hinzufügen der einzelnen Klassen und die Erweiterung der Programmfunktionen aufgrund des modularen Aufbaus kein großes Problem mehr Syslog / SNMP Zu den schwierigsten Aufgaben bei der weiteren Entwicklung zählen Netzwerkprotokolle, zu denen keine ausreichend informative Dokumentation in den zur Verfügung stehenden Quellen stand (Syslog, SNMP, VTP). Des Weiteren konnte trotz ausreichender Analyse im Wireshark bei Netzwerkprotokollen wie beispielsweise Syslog nicht herausgefunden werden, welche Parameter einen bestimmten Zustand hervorrufen. Syslog verfügt über ein Datenfeld, welches den Typ einer Message anhand einer Zahl zwischen zwei Klammern definiert. Das Problem hierbei ist, dass keine Information über den Bit-genauen Aufbau des Protokollfeldes gefunden werden konnte. Zusätzlich konnte im Wireshark keine Assoziation zwischen der lesbaren Auswertung des Netzwerkprotokolls und des Bit-Streams gefunden werden. In folgender Abbildung ist ersichtlich, dass die in der Auswertung angezeigten Bits (Facility und Level) in keiner Weise den dazugehörigen blau markierten Bits im unteren Bereich entsprechen. Auch nach ausführlicher Recherche und zahlreichen Misserfolgen konnte aufgrund mangelnder Dokumentation des Netzwerkprotokolls keine Lösung für dieses Problem gefunden werden. Abbildung 51 Syslog (Beispielmitschnitt - Wireshark) HERAUSFORDERUNGEN 64