Bachelorarbeit. Rene Rose. Proprietärer VPN-Proxy für ein weltweites Content Management System unter Verwendung von Socks 5 und C++

Transkript

1 Bachelorarbeit Rene Rose Proprietärer VPN-Proxy für ein weltweites Content Management System unter Verwendung von Socks 5 und C++ Fakultät Technik und Informatik Studiendepartment Informatik Faculty of Engineering and Computer Science Department of Computer Science

2 Rene Rose Proprietärer VPN-Proxy für ein weltweites Content Management System unter Verwendung von Socks 5 und C++ Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung im Studiengang Bachelor of Science Technische Informatik am Department Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer: Prof. Dr. Hans Heinrich Heitmann Zweitgutachter: Prof. Dr.-Ing. Andreas Meisel Eingereicht am: 19. Mai 2014

3 Rene Rose Thema der Arbeit Proprietärer VPN-Proxy für ein weltweites Content Management System unter Verwendung von Socks 5 und C++ Stichworte C++, Socks 5, VPN, Proxy Kurzzusammenfassung In dieser Bachelorarbeit wird ein Proxy für ein bestehendes System entwickelt. Dieser Proxy soll sich transparent verwenden lassen. Ebenso soll eine Verwendung unter zur Hilfenahme des Socks5-Protokolls möglich sein. Des Weiteren soll die Kommunikation welche über den Proxy stattfindet verschlüsselt werden. Rene Rose Title of the paper Proprietärer VPN-Proxy für ein weltweites Content Management System unter Verwendung von Socks 5 und C++ Keywords C++, Socks 5, VPN, Proxy Abstract In this thesis a proxy for an existing system is being developed. This proxy should be possible to use transparent. Also to be possible under the aid of the Socks5 protocol use. In addition to the communications which are encrypted via the proxy occurs.

4 Inhaltsverzeichnis 1. Einleitung Motivation und Zielsetzung Das ShowTime-Systems Anforderungsspezifikation Analyse der Zielsetzung Anforderung Erreichbarkeit der Clients Sicherheit der Clients Sicherheit der Kommunikation Vertrauenswürdigkeit der Erweiterung Keine zusätzlichen laufenden Kosten Einfache Linux-Portierung Vergleich verschiedener Lösungsmöglichkeiten Virtual Private Network (VPN) Beschreibung Dynamisches DNS (DynDNS) Beschreibung Proprietärer VPN-Proxy Abschließender Vergleich der verschiedenen Möglichkeiten Socks Einsatzzweck Beschreibung Ablauf der Anmeldung eines Socks-Clients an einen Socks-Server Ablauf eines direkten Verbindungsaufbau Ablauf einer Bereitstellung eines Ports Nachrichten des Socks5 Protokolls Identifier Nachrichten Authentication Nachrichten Request Nachrichten Auswahl und Bewertung von Verschlüsselungsverfahren Bewertung symmetrischer Verschlüsselungsverfahren Bewertung asymmetrischer Verschlüsselungsverfahren iv

5 Inhaltsverzeichnis 5.3. Schlüsselaustauschverfahren Auswahl geeigneter Verfahren für den Proxy Konzept Grundsätzlicher Aufbau und Begriffsdefinition des Proxy-Systems Änderungen am Ablauf der Datenübertragung im bestehendem System Erste Erweiterung des bestehenden Systems Zweite Erweiterung des bestehende Systems Abschließende Erweiterung des bestehende Systems Protokolle Kommunikation zwischen Proxy Management Dienst und Proxy Watch/Start Dienst Kommunikation zwischen VPN-Proxy und Proxy Management Dienst Kommunikation zwischen VPN-Proxy und VPN-Proxy Eigenschaften der Protokolle Aufbau der Protokoll Nachrichten Anmeldung VPN-Proxy Client an VPN-Proxy Server Verbindungsaufbau von der Seite des VPN-Proxy im Client- Modus Verbindungsaufbau von der Seite des VPN-Proxy im Server- Modus Ping Protokoll Connection Id Austauschprotokoll Datenübertragungsprotokoll Komponenten Aufbau des Proxy Management Dienstes Aufbau des Proxy Watch/Start Dienst Aufbau des VPN-Proxys CallBack interface Listener Socks Mapper Management Communication-Handler Worker Umsetzung und Implementierung Eingesetzte Werkzeuge Zusätzliche Libarys Zusätzliche Klassen Service Host HTTP-Dispatcher v

6 Inhaltsverzeichnis Quazar Crypt Libary C++ Quazar Crypt Libary Quazar Crypt Libary DLL C# Quazar Crypt Libary Umsetzung des Proxy Management Dienstes und des Proxy Watch/Start Dienstes Proxy Management Dienst Proxy Watch/Start Dienst Umsetzung des VPN-Proxys VPN Proxy Komponenten Listener Socks Management / Mapper Communication-Handler Worker Testen und Auswerten des Systems Funktionstest Proxy Komponenten VPN-Proxy Auswertung der Sicherheit des Proxy-Systems Sicherheit der Kommuniktaion des Proxy-Systems Sicherheit der Komponenten des Proxy-Systems Zusammenfassung Mögliche Erweiterungen A. Implementierung 86 A.1. VPN Proxy Helfer Klassen B. Testsuiten und Testfälle des Testprogramms 96 B.1. Testsuiten für den VPN-Proxy im Server-Modus B.1.1. Beschreibung B.1.2. Testsuiten für den Anmeldevorgang B.1.3. Testsuiten für den Verbindungsaufbau initialisiert von einer externen B.1.4. Anwendung Testsuiten für den Verbindungsaufbau initialisiert von einem VPN- Proxy im Client-Modus B.2. Testsuiten für den VPN-Proxy im Client-Modus B.2.1. Beschreibung B.2.2. Testsuiten für den Anmeldevorgang B.2.3. Testsuiten für den Verbindungsaufbau initialisiert von einer externen Anwendung vi

7 Inhaltsverzeichnis B.2.4. Testsuiten für den Verbindungsaufbau initialisiert von einem VPN- Proxy im Server-Modus Abkürzungsverzeichnis 103 Tabellenverzeichnis 104 Abbildungsverzeichnis 107 Quellen 109 vii

8 1. Einleitung 1.1. Motivation und Zielsetzung Die Firma Quazar Softwareentwicklungsgesellschaft mbh hat für den stetig wachsenden Markt des digital signage ein System namens Showtime entwickelt. Dieses System besteht aus einer Serverkomponente und diversen Clientkomponenten. Ein Client, auch Display genannt, besteht aus einem Rechner mit einem oder mehreren angeschlossenen Bildschirmen. Die Serverkomponente versorgt die Clients mit Content. Dieser Content kann statischer Natur sein, wie z.b. Filme, Bilder oder Powerpointpräsentationen, oder auch dynamischer, wie z.b. Wetter oder Aktienkurse. Eine Kombination aus statischem und dynamischem Content ist ebenfalls möglich. Gerade für kleinere Unternehmen ist das Showtime-System hinsichtlich der Funktionalität, des Verwaltungsaufwands und der Kosten zu groß. Um auch diesen Unternehmen die Verwendung des Showtime-Systems zu ermöglichen, wird darüber nachgedacht den Server für einen Mehrbenutzerbetrieb zu erweitern. Die Clients würden dann in dem LAN des Kunden betrieben und über einen zentralen Server verwaltet werden. Da in diesem Fall die Kommunikation nicht wie bisher über ein sicheres LAN, sondern über das Internet abläuft, ergeben sich einige Probleme, da sämtliche Komponenten des Systems nicht für den Einsatz im Internet ausgelegt sind: Der Client besitzt unter anderem eine HTTP-Schnittstelle, welche ohne Authentifizierung direkt aufgerufen werden kann. Mit dieser ist es möglich das Verhalten des Clients zu manipulieren. Ebenso besitzt der Client einen FTP-Server, welcher nur das reine FTP Protokoll beherrscht, kein FTPs oder sftp. Zu diesen sicherheitsrelevanten Problemen kommen noch Schwierigkeiten mit dem Kommunikationsaufbau. Aktuell wird ein Kommunikationsaufbau vom Server initialisiert. Dieser kennt die IP-Adresse des Clients im LAN und spricht diesen direkt an. Im Internet wäre dieses Vorgehen in der Form nicht möglich, da sich die IP-Adressen der Clients dynamisch ändern. Die Lösung dieser Probleme, wie z.b. des Verbindungsaufbaus und der Sicherheit, welche beim Betrieb des Showtime-Systems über das Internet auftreten, ist Aufgabe dieser Bachelorthesis. 1

9 1. Einleitung Aus Kompatibilitätsgründen zu bereits bestehenden Installationen darf die Richtung des Verbindungsaufbaus im System nicht verändert werden. Im Idealfall ist die Lösung transparent für das Showtime-System. Da der Client aktuell mit Windows XP betrieben wird, welches nicht mehr weiter von Microsoft gepflegt wird, existieren Überlegungen diesen nun mit Linux zu betreiben, da eine Umstellung auf Windows 7 eine leistungsfähigere Hardware voraussetzen würde und bei der Verwendung von Linux keine Lizenzgebühren anfallen. Daher ist bei der Auswahl einer Lösung auch darauf zu achten, dass diese ohne großen Mehraufwand unter Linux verwendet werden kann. Eine ideale Lösung beschränkt sich nicht nur auf das Showtime-System, sondern kann auch für andere Produkte der Firma Quazar Softwareentwicklungsgesellschaft mbh eingesetzt werden Das ShowTime-Systems Abbildung 1.1.: Aufbau des ShowTime-Systems Wie in Abbildung 1.1 dargestellt, besteht das aktuelle ShowTime-System aus drei wesentlichen Komponenten. 2

10 1. Einleitung Die Datenbank verwaltet sämtliche für den Betrieb relevanten Informationen, wie z.b. den Namen und die URL des Displays. Der Server erzeugt und versendet Inhalte an die Clients. Ebenso bietet er Schnittstellen, um seine Arbeit zu überwachen oder um neue Inhalte zu erstellen. Der Client ist im Gegensatz zum Server aus der Netzwerksicht eine passive Komponente. Er stellt seinen Inhalt grafisch dar. Ebenso wie der Server bietet der Client einige Schnittstellen, über welche er überwacht und gesteuert werden kann. Die Server- und Clientkomponenten beherbergen einige Anwendungen, die untereinander kommunizieren können bzw. müssen, z.b. wird der Inhalt per FTP an die Clients gesendet. Dazu muss es auf Seite des Servers einen FTP-Client und auf der Seite des Clients einen FTP-Server geben. Auf dem Server werden folgende Anwendungen betrieben, um diverse Clients mit Inhalten zu versorgen: Eine Administrationsanwendung, welche zur Überwachung des Servers und der Clients verwendet wird. Über diese kann auch neuer Inhalt an die Clients gesendet werden. Der Anwendungsserver beinhaltet einige Tasks, welche Inhalte für den Client erstellen und versenden. Das Webinterface stellt definierte Schnittstellen zur Verfügung, um Inhalte für unterschiedliche Clients zu erstellen. Das Senden dieser Inhalte an die Clients geschieht über einen Task, welcher in dem Anwendungsserver betrieben wird. Der FTP-Client übernimmt das abschließende Senden der Inhalte an die Clients. Die unterschiedlichen Clients werden direkt über eine in der Datenbank hinterlegte IP-Adresse über das lokale LAN angesprochen. Auf einem Client laufen ebenfalls einige Anwendungen, welche für die unterschiedlichen Aufgaben benötigt werden: Der Presenter übernimmt das Darstellen von Inhalten auf dem Display. Der Scheduler ist das Herz des Clients. Er steuert unterschiedliche Presenter und weist diesen Inhalte zu, die darzustellen sind. Des Weiteren stellt er eine HTTP-Schnittstelle zur Verfügung, über die der Client gesteuert werden kann. 3

11 1. Einleitung Der FTP-Server empfängt die Inhalte von einem FTP-Client und benachrichtigt nach Abschluss der Übertragung den Presenter. Diesem wird mitgeteilt, dass neue Inhalte empfangen wurden. 4

12 2. Anforderungsspezifikation 2.1. Analyse der Zielsetzung Aus der Zielsetzung kann man folgende Anforderungen herleiten: Erreichbarkeit der Clients Sicherheit der Clients Sicherheit der Kommunikation Vertrauenswürdigkeit der Erweiterung Keine laufenden Kosten Einfache Linux-Portierung Auf diese Anforderungen wird nun in den folgenden Kapiteln eingegangen Anforderung Erreichbarkeit der Clients Da die Clients im Regelfall im Internet mit dynamischen IP-Adressen betrieben werden, können die Clients nicht wie bisher direkt über die IP-Adresse angesprochen werden Sicherheit der Clients Im aktuellem ShowTime-System wird die Sicherheit durch den Betrieb im LAN gewährleistet. Der Client besitzt keinen weiteren Schutz gegen einen unbefugten Zugriff. Die Abschirmung gegen den unbefugten Zugriff muss, sobald das ShowTime-System über das Internet betrieben wird, hinzugefügt werden. 5

13 2. Anforderungsspezifikation Sicherheit der Kommunikation Das aktuelle ShowTime-System wird im LAN betrieben. Hier ist das Risiko einer böswilligen Manipulation oder Störung der Kommunikation der Systemkomponenten minimal. Daher wird bisher auf eine Verschlüsselung der Kommunikation verzichtet, es wird z.b. FTP und nicht FTPs oder sftp eingesetzt. Dieses bisherige Vorgehen ist im Internet zwar möglich, jedoch ist dringend von der Verwendung abzuraten. Um die Kommunikation zu schützen, muss sie verschlüsselt werden Vertrauenswürdigkeit der Erweiterung Die Erweiterung des Systems darf die Sicherheit des aktuellen Systems nicht beeinträchtigen. Daher muss sie, falls sie nicht selber entwickelt wird, aus einer vertrauenswürdigen Quelle stammen und der Code muss OpenSource sein Keine zusätzlichen laufenden Kosten Aktuell entstehen durch den Betrieb des ShowTime-Systems nur die laufenden Kosten, die durch den Betrieb des Servers anfallen. Diese sollen mit der Einführung weiterer Komponenten nicht steigen. Lizenzgebühren etc. sind nicht hinnehmbar Einfache Linux-Portierung Die aktuelle Version des ShowTime-Systems wird auf Rechnern mit dem Betriebssystem Windows betrieben. Daher wird primär für dieses Betriebssystem entwickelt. Es sollte allerdings darauf geachtet werden, eine mögliche spätere Portierung in Richtung eines Linux-Betriebssystems so einfach wie möglich zu gestalten. 6

14 3. Vergleich verschiedener Lösungsmöglichkeiten In diesem Kapitel werden drei mögliche Lösungen für die benötigte Komponente vorgestellt. Um diese Lösungen zu bewerten, werden die Anforderung in eine tabellarische Form gebracht Virtual Private Network (VPN) Beschreibung Ein VPN realisiert im Internet ein privates Netzwerk ähnlich einem LAN. In diesem können jegliche angemeldeten Partner direkt miteinander kommunizieren. Dafür werden zwei Komponenten benötigt: 1. Ein Server, bei dem sich sämtliche VPN Teilnehmer anmelden. 2. Ein Client Programm, welches die Anmeldung am Server vornimmt. Die Verbindung wird in der Regel per IPSec oder SSL verschlüsselt. Die Kommunikation zwischen Anwendungen auf Client und Server Seite wird durch die VPN-Software geleitet und mit dieser ver- bzw. entschlüsselt. Allerdings kam es in der Vergangenheit dazu, dass in einer VPN-Software Schadcode gefunden wurde 1. Daher muss vor jedem Update der Code des VPN Clients überprüft werden, um auszuschließen, dass dort Schadcode enthalten ist. Dieses ist nicht immer möglich, gerade wenn es um Sicherheitsupdates geht, die möglichst schnell eingespielt werden müssen, z.b. wie bei dem sogenannten Heartbleed 2 Bug. Durch diesen, in der freien OpenSSL Libary aufgetretenen, Bug ist es möglich von außen den privaten Schlüssel des Servers auszulesen. Da die betroffene Libary auch von einigen VPN Programmen verwendet wird, z.b. OpenVPN 3, muss ein schneller Austausch erfolgen. Die Zeitspanne, welche für die Analyse des VPN Programm Quellcodes benötigt wird, ist in diesem Fall definitiv zu lang. 1 [6] 2 [7] 3 [12] 7

15 3. Vergleich verschiedener Lösungsmöglichkeiten Während der Zeit der Analyse würde im Heartbleed -Fall gelten, dass die Verschlüsselung gebrochen und damit die Sicherheit der Anwendung nicht mehr gewährleistet wäre. Die Tabelle 3.1 zeigt die Anforderungen an eine Lösung und wie sich der hier erläuterte Lösungsvorschlag zu diesen verhält: Tabelle 3.1.: Bewertung des Virtual Private Network (VPN) Anforderung Erfüllt Erreichbarkeit des Clients J Sicherheit des Clients J Sicherheit der Kommunikation J Vertrauenswürdigkeit der Erweiterung N Keine laufenden Kosten N Einfache Linux-Portierung J 8

16 3. Vergleich verschiedener Lösungsmöglichkeiten 3.2. Dynamisches DNS (DynDNS) Beschreibung Hinter dem DynDNS steht ein dynamisches System, um URLs in IP-Adressen zu übersetzen. Im Regelfall bekommen die meisten Internetanschlüsse im 24-Stundentakt von ihrem Provider eine neue öffentliche IP Adresse zugewiesen. Um solchen Anschlüssen trotzdem die Möglichkeit zu geben über eine feste Adresse erreichbar zu sein, gibt es DynDNS Dienste. Diese Dienste vergeben URLs, hinter denen sich die dynamische IP Adresse eines Internetanschlusses verbirgt. Damit diese immer korrekt ist, muss sie bei jeder Änderung der öffentlichen IP-Adresse aktualisiert werden. Dieses geschieht durch ein System, welches einen IP-Adressenwechsel feststellt. Im Regelfall kann das der vom Internetprovider mitgelieferte Router erledigen. Dieser muss für die Verwendung eines DynDNS Dienstes entsprechend eingerichtet werden. Über die bei DynDNS hinterlegte IP-Adresse kann man lediglich auf das System zugreifen, welches sich hinter dieser IP-Adresse verbirgt. Im Regelfall ist dieses allerdings nicht das eigentliche Zielsystem, sondern ein Router. Um auf ein bestimmtes System des gerouteten LANs zuzugreifen, muss in dem Router eine Port Forwarding Regel hinterlegt werden. Diese Regel leitet eine Anfrage am Router Port X an den Port Y von System Z weiter. Die Tabelle 3.2 zeigt die Anforderungen an eine Lösung und wie sich der hier erläuterte Lösungsvorschlag zu diesen verhält. Tabelle 3.2.: Bewertung des Dynamisches DNS (DynDNS) Anforderung Erfüllt Erreichbarkeit des Clients J Sicherheit des Clients N Sicherheit der Kommunikation N Vertrauenswürdigkeit der Erweiterung J Keine laufenden Kosten J Einfache Linux-Portierung J 3.3. Proprietärer VPN-Proxy Eine proprietäre Lösung soll die Nachteile der beiden vorherigen Verfahren minimieren und ihre Vorteile vereinen. Um eine möglichst einfache Wartung der Komponente zu gewährleisten, sollte der proprietäre VPN-Proxy auf dem Layer 5 des OSI Models betrieben werden. Dieser Layer hat den Vorteil der Verwendung des TCP Protokolls. Durch Verwendung dieses Proto- 9

17 3. Vergleich verschiedener Lösungsmöglichkeiten kolls ist den verschlüsselten Daten nicht anzusehen, ob sie verschlüsselt sind oder nicht. Dieser Lösungsansatz hat einen hohen Entwicklungsaufwand und es wird eine eigene Qualitätssicherung benötigt, um zu garantieren, dass diese Lösung sicher ist. Auf der anderen Seite existiert die komplette Kontrolle über den Code. Das Einschleusen von Schadcode ist damit nahezu ausgeschlossen. Daher kann beim Auftreten von Sicherheitslücken wesentlich schneller ein Update des VPN-Proxys durchgeführt werden. Die Tabelle 3.3 zeigt die Anforderungen an eine Lösung und wie sich der hier erläuterte Lösungsvorschlag zu diesen verhält. Tabelle 3.3.: Bewertung des Proprietärer VPN-Proxys Anforderung Erfüllt Erreichbarkeit des Clients J Sicherheit des Clients J Sicherheit der Kommunikation J Vertrauenswürdigkeit der Erweiterung J Keine laufenden Kosten J Einfache Linux-Portierung J 3.4. Abschließender Vergleich der verschiedenen Möglichkeiten Tabelle 3.4.: Vergleich der vorgestellten Lösungen Anforderung VPN DynDns Propritär Erreichbarkeit des Clients J J J Sicherheit des Clients J N J Sicherheit der Kommunikation J N J Vertrauenswürdigkeit der Erweiterung N J J Keine laufenden Kosten N J J Einfache Linux-Portierung J J J Wie aus der Tabelle 3.4 zu entnehmen, erfüllt nur die proprietäre Lösung alle Anforderungen. Daher fällt die Wahl auf eine proprietäre Lösung. 10

18 4. Socks Einsatzzweck Das Sock5-Protokoll, welches in diesem Kapitel beschrieben wird, wird aus folgenden Gründen in dem Proxy-System eingesetzt: Flexibilität: Die Verwendung des Socks5-Protokolls ermöglicht es anderen Anwendungen, ohne das große Anpassungen vorgenommen werden müssen, das Proxy-System zu verwenden, da die Kommunikation mit diesem standardisiert ist. Sicherheit: Da das Socks5-Protokoll verschiedene Anmeldeverfahren anbietet, kann der Verbindungsaufbau über solch ein Verfahren verifiziert werden Beschreibung Das Socks5-Protokoll wurde im März 1996 im RFC 1928 vorgestellt. Dieses Protokoll wird verwendet, um eine einheitliche Kommunikation von Anwendungen mit unterschiedlichen Proxy-Servern zu ermöglichen. Über das Socks5-Protokoll kann sich ein Client an einem Proxy- Server anmelden und diesem mitteilen, wie die Verbindung zu einem Ziel aufgebaut werden soll. Ebenso wird dem Proxy-Server über das Socks5 Protokoll mitgeteilt, mit welchem Ziel die Verbindung hergestellt werden soll. Im RFC wurde nur das Socks5-Protokoll spezifiziert, keine Details zu möglichen Implementierungen der anschließenden Datenübertragung. Da in dem ShowTime-System nur TCP-Verbindungen verwendet werden, wird im Rahmen dieser Bachelorthesis auf eine Erläuterung des UDP-Verbindungsaufbaus verzichtet. Bei einer TCP-Verbindung existieren folgende Möglichkeiten eines Verbindungsaufbaus: Der direkte Aufbau einer Verbindung zum Ziel. Das Bereitstellen eines Ports zum Annehmen und Weiterleiten einer Verbindung. Es werden im RFC 1928 zwei mögliche Authentifizierungsarten für die Anmeldung an einem Proxy-Server vorgeschlagen. Des Weiteren ist es auch möglich, einen Socks5-Proxy ohne 11

19 4. Socks5 Authentifizeriung zu betreiben. Es folgt die Vorstellung der zwei im RFC definierten Anmeldungsmethoden: Anmeldung über die GSSAPI. Die Erweiterung des Socks5 Protokoll für diese Anmeldung ist definiert im RFC Die GSSAPI in Version 2.1 ist im RFC 2743 definiert. Sie wird unter anderem von dem Authentifizierungsdienst Kerberos 1 unterstützt. Diese Methode muss, laut dem RFC 1928, unterstützt werden, um als eine Compliant implementations zu gelten. Da im Showtime-System kein auf GSSAPI basiertes Authentifikationsystem existiert und der propritäre VPN-Proxy nicht außerhalb dieses Systems betrieben wird, wird im Rahmen dieser Bachelorthesis auf eine Erläuterung der GSSAPI-Anmeldung sowie der späteren Implementation verzichtet. Anmeldung über Benutzername und Passwort. Die Erweiterung des Socks5 Protokoll für diese Anmeldung ist im RFC definiert. Für die Kommunikation zwischen dem Socks-Server und dem Socks-Client ist keine Verschlüsselung vorgeschrieben. Daher ist eine sichere Verbindung ohne Verschlüsselung nur im LAN gegeben. Ansonsten muss ein SSL/TLS Verbindung zum Socks-Server aufgebaut werden. 1 [11] 2 [9] 12

20 4. Socks Ablauf der Anmeldung eines Socks-Clients an einen Socks-Server Abbildung 4.1.: Anmeldevorgang des Socks5 Protokolls In Abbildung 4.1 wird der Ablauf einer Socks5 Anmeldung dargestellt. Da bei sämtlichen Möglichkeiten des Socks5-Verbindungsaufbau der Anmeldevorgang identisch ist, wird dieser hier exemplarisch für die folgenden Kapitel erläutert. Der Socks5-Client baut eine Verbindung zum Socks5-Server auf und sendet diesem eine Identifier Nachricht. Diese Nachricht enthält neben der Version des Socks Protokolls eine Liste von Anmeldemethoden die der Socks5-Client unterstützt. Der Socks5-Server überprüft die Nachricht auf die richtige Versionsnummer. Aus den Anmeldemethoden wählt er eine Methode aus, dieses geschieht nach Vorgaben innerhalb des Socks5-Servers. Die Antwort des Sock5-Servers an den Client enthält die Versionsnummer und die ausgewählte Anmeldemethode. Sollte keine Anmeldemethode den Parametern des Socks5-Servers entsprechen, enthält die Antwort einen 13

21 4. Socks5 Fehlercode. Sollte keine Anmeldung erforderlich sein, ist der Anmeldevorgang an den Socks5-Server beendet und es wird mit dem Aufbau einer Verbindung begonnen. Wenn als Anmeldemethode die Benutzernamen und Passwort Anmeldung ausgewählt wurde sendet der Socks5-Client nun eine Nachricht, welche die benötigten Daten, Benutzername und Passwort, für die Anmeldung enthält. Der Socks5-Server überprüft diese Daten und sendet eine entsprechende Antwort. Für weitere Details siehe RFC Ablauf eines direkten Verbindungsaufbau Abbildung 4.2.: Ablauf des direkten Verbindungsaufbaus unter Verwendung des Socks5 Protokolls In Abbildung 4.2 wird der direkte Aufbau einer Verbindung zu dem Zielrechner dargestellt. Nach erfolgreicher Anmeldung, siehe Kapitel 4.3, sendet der Socks5-Client eine Request Nachricht an den Socks5-Server. In dieser Nachricht stehen unter anderem die Adresse und der Port des Zielrechners. Der Socks5-Server überprüft diese Daten auf ihre Gültigkeit und erstellt daraufhin eine Verbindung zum Zielrechner. Im Anschluss wird eine Antwort an den Socks5-Client gesendet. In dieser werden außer einem Antwortcode die Adresse und der Port des Ziels mit geteilt. Sollte der Verbindungsaufbau erfolgreich gewesen sein, können nun 14

22 4. Socks5 vom Socks5-Client Daten an den Socks5-Server gesendet werden, welche an den Zielrechner weitergeleitet werden. Dieses ist natürlich auch vom Zielrechner aus möglich Ablauf einer Bereitstellung eines Ports Abbildung 4.3.: Ablauf der Bereitstellung eines Ports für einen Verbindungsaufbau im Socks5 Protokoll In Abbildung 4.3 wird die Bereitstellung eines Ports für die Weiterleitung einer eingehenden Verbindung auf dem Socks5-Server dargestellt. Der Socks5-Client sendet eine Request Nachricht an den Socks5-Server. Dieser erstellt daraufhin einen Port und sendet die Portnummer sowie seine externe IP-Adresse als Antwort an den Socks5-Client. Der Socks5-Client wartet nun auf eine weitere Antwort des Socks5-Servers, welche bei einer eingehenden Verbindung auf dem erstellten Port versendet wird. In dieser Nachricht wird dem Sock5-Client die IP-Adresse und der Port des Zielrechners mitgeteilt. 15

23 4. Socks5 Im Anschluss können Socks5-Client und Zielrechner Daten an den Socks5-Server senden, welcher diese Daten weiterleitet Nachrichten des Socks5 Protokolls In diesem Kapitel werden die einzelnen Nachrichten und ihre möglichen Werte im Detail beschrieben. Sämtliche Informationen über die Nachrichten wurden aus den RFCs 1929 und 1928 entnommen Identifier Nachrichten Tabelle 4.1.: Aufbau der identifier/method selection Nachricht Feldname Größe in Byte Version 1 Anzahl der Authentifizierungsmethoden 1 Authentifizierungsmethoden 1 bis 255 Quelle: [9] Tabelle 4.2.: Aufbau der Antwort auf die identifier/method selection Nachricht Feldname Größe in Byte Version 1 gewählte Methode 1 Quelle: [9] Die in der Tabelle 4.1 dargestellten Werte repräsentieren den Aufbau einer identifier/method selection Nachricht, welche als erste Nachricht an den Socks5-Server gesendet wird. In dem Feld Version hat der Wert 0x05 zu stehen. Das Feld Anzahl der Authentifizierungsmethoden gibt an, wie viele Authentifizierungsmethoden darauf folgen. Die möglichen Werte für das Feld Authentifizierungsmethoden werden im Folgenden erläutert: 0x00: Keine Authentifizerung benötigt. 0x01: GSSAPI Authentifizierung. 0x02: Benutzername/Passwort Authentifizierung. 0x03 bis 0x7E: Reservierter Bereich, wird von der IANA verwaltet. 16

24 4. Socks5 0x80 bis 0XFE: Reservierter Bereich zur freien privaten Verwendung. 0xFF: Fehlercode, keine akzeptierte Methode vorhanden. Die Antwort des Socks5-Servers, dessen Aufbau in Tabelle 4.2 dargestellt ist, enthält ebenfalls ein Feld Version sowie das Feld gewählte Methode. Mit diesem Feld teilt der Socks5-Server dem Client mit, welche Authentifizierungsmethode aus seinen Vorschlägen ausgewählt wurde Authentication Nachrichten Tabelle 4.3.: Aufbau der Initial negotiation Nachricht Feldname Größe in Byte Version 1 Länge des Benutzernamens 1 Benutzername 1 bis 255 Länge des Passworts 1 Passwort 1 bis 255 Quelle: [8] Tabelle 4.4.: Aufbau der Antwort auf die Initial negotiation Nachricht Feldname Größe in Byte Version 1 Status 1 Quelle: [8] Wenn bei der Anmeldung die Methode Benutzername/Passwort gewählt wurde, wird eine Initial negotiation Nachricht Socks5-Client an den Socks5-Server gesendet. Der Aufbau dieser Nachricht ist in Tabelle 4.3 dargestellt. Die Antwort des Socks5-Servers ist in Tabelle 4.4 dargestellt. Werte im Feld Status der Antwort haben folgende Bedeutung: 0x00: Anmeldung erfolgreich. 0x01 bis 0xFF: Anmeldung war nicht erfolgreich Request Nachrichten Die request Nachricht, der Aufbau ist in Tabelle 4.5 dargestellt, wird zum Initiieren des 17

25 4. Socks5 Tabelle 4.5.: Aufbau der request Nachricht Feldname Größe in Byte Version 1 Kommando 1 Reserviert 1 Adresstyp 1 Adresse 4 bis 255 Port 2 Quelle: [9] Tabelle 4.6.: Aufbau der Antwort auf die request Nachricht Feldname Größe in Byte Version 1 Antwort 1 Reserviert 1 Adresstyp 1 Adresse 4 bis 255 Port 2 Quelle: [9] Verbindungsaufbaus verwendet. Sie enthält ein Kommando, welches angibt wie die Verbindung aufgebaut werden soll sowie die Zieladresse und den Zielport. Die Antwort auf eine solche Nachricht enthält anstelle des Kommandos eine Antwort. Bei der Antwort haben je nach gewähltem Kommando die Adresse und der Port unterschiedliche Bedeutungen, siehe dazu Kapitel 4.4 und 4.5. Folgende Kommandos sind im RFC 1928 definiert: 0x01: Verbindung direkt aufbauen. 0x02: Port zur Verfügung stellen und auf eingehende Verbindung warten. 0x03: UDP Verbindung aufbauen. Folgende Adresstypen sind im RFC 1928 definiert: 0x01: IPv4 Adresse. 0x03: DNS Name. Das erste Byte der Adresse gibt die Länge des Namens an. 0x04: IPv6 Adresse. 18

26 4. Socks5 Folgende Antworten sind im RFC 1928 definiert: 0x00: Erfolgreich. 0x01: Genereller Socks5-Server Fehler. 0x02: Verbindung nicht erlaubt. 0x03: Netzwerk nicht zu erreichen. 0x04: Ziel nicht zu erreichen. 0x05: Verbindung abgelehnt. 0x06: Time to life abgelaufen. 0x07: Kommando nicht unterstützt. 0x08: Adresstyp nicht unterstützt 0x09 bis 0xFF: nicht zu gewiesen. 19

27 5. Auswahl und Bewertung von Verschlüsselungsverfahren Es existieren im Wesentlichem zwei Kategorien von Verschlüsselungsverfahren: Symmetrische Verfahren Asymmetrische Verfahren Diese beiden unterschieden sich grundsätzlich in ihrer Funktionsweise und haben dadurch in der Regel jeweils unterschiedliche Einsatzgebiete Bewertung symmetrischer Verschlüsselungsverfahren Definition Ein symmetrisches Verfahren zur Ver- bzw. Entschlüsselung basiert im Wesentlichen auf dem Einsatz des selben Algorithmus mit einem identischem Schlüssel. Ein einfacher symmetrischer Verschlüsselungsalgorithmus ist z.b. die XOR Funktion: OriginalDaten = 0x90, Schlüssel(K) = 0x08 0x90 K = 0x98 0x98 K = 0x90 Die symmetrischen Verfahren zeichnen sich im Vergleich zu den asymmetrischen Verfahren in den folgende Punkten aus: Sicherheit: Asymmetrische Verfahren sind nur bei ausreichender Schlüssellänge sicher (aktuell 2000 Bit Schlüssellänge laut dem Bundesamt für Sicherheit in der Datentechnik (BSI)) 1. Bei symmetrischen Verfahren ist die Sicherheit durch den Algorithmus, der zur Verschlüsselung eingesetzt wird, ausschlaggebend für die Sicherheit der Daten. 1 [3] 20

28 5. Auswahl und Bewertung von Verschlüsselungsverfahren Performance: Aufgrund der verwendeten Algorithmen brauchen symmetrische Verfahren wesentlich weniger Rechenleistung als asymmetrische Verfahren. Allerdings haben symmetrische Verfahren einen erheblichen Nachteil. Im Gegensatz zu den asymmetrischen Verfahren wird auf beiden Seiten ein geheimer Schlüssel benötigt. Des Weiteren sollte, um die Sicherheit zu erhöhen, bei jeder Verbindung ein anderer Schlüssel verwendet werden. Gerade dieser Austausch von Schlüsseln ist in einem öffentlichem Netz wie dem Internet sehr problematisch. Für dieses Problem gibt es allerdings einige Lösungsmöglichkeiten, welche in Kapitel 4.3 beschrieben werden. DES Der Data Encryption Standard (DES) Algorithmus wurde von IBM Anfang der 70er Jahre entwickelt und 1977 für die US-Regierung als Standard bestätigt 2. Durch den vergleichsweise kurzen Schlüssel gelang es erstmals im Jahr 1997 eine DES Nachricht zu brechen benötigte das Deep Crack System der Electronic Frontier Foundation (EFF) während der RSA DES Challenge II-2 weniger als drei Wochen, um einen DES Schlüssel zu brechen 4. Daher sollte DES nicht mehr eingesetzt werden. 3DES 3DES, auch Triple-DES genannt, ist DES dreimal mit unterschiedlichen Schlüsseln hintereinander ausgeführt. Er wurde im Jahr 1981 vorgestellt, um den schon damals als zu kurz bemängelten DES Schlüssel zu verlängern 5. 3DES gilt heute immer noch als genauso sicher wie aktuellere Verfahren mit einem 128 Bit Schlüssel, allerdings ist die Performance durch das dreimalige Ausführen des DES Algorithmus im Vergleich zu den aktuelleren Verfahren vergleichsweise gering 6. Advanced Encryption Standard (AES) Der AES Algorithmus wurde durch ein Auswahlverfahren des National Institute of Standards and Technology (NIST) im Jahre 1998 gefunden. Zur Auswahl standen in der letzten Runde diese Algorithmen: Rijndael, TwoFish, RC6, MARS und Serpent. Den Wettbewerb hat der Rijndael Algorithmus, durch seine hohe Performance in Hardware sowie Software Implementierung 7 2 [14, S.81 ff.] 3 [14, S.81 ff.] 4 [5] 5 [16] 6 [1] 7 [14, S. 362] 21

29 5. Auswahl und Bewertung von Verschlüsselungsverfahren für sich entschieden. AES unterstützt Schlüssel mit folgenden Längen: 128, 192 und 256 Bit. Daher wird auch von AES-128, AES-192 und AES-256 gesprochen. Seit seiner Zertifizierung im Jahr 2000 ist er in den USA in den Formen AES-192 und AES-256 für Dokumente der höchsten Geheimhaltungsstufe zugelassen 8. Twofish Twofish ist ein sehr moderner Algorithmus, der wie Rijndael ebenfalls zur Auswahl zum AES Algorithmus stand. Er wurde im Zuge des Auswahlverfahrens gründlich in Hinsicht auf Sicherheit und benötigte Rechenleistung überprüft. Er verlor in der Runde der letzten Fünf, mit RC6, MARS und Serpent gegen den Rijndael Algorithmus. Das BSI gibt für den Twofish Algorithmus nur aus folgendem Grund keine Empfehlung mehr: In Version 1.0 dieser Technischen Richtlinie wurden auch die Blockchiffren Serpent und Twofish empfohlen. Es liegen keine negativen Erkenntnisse zu diesen Blockchiffren vor, allerdings wurde die Sicherheit von Serpent und Twofish seit dem Ende des AES-Wettbewerbs deutlich weniger intensiv untersucht als die des AES. 9 Vergleich der vorgestellten Verfahren Tabelle 5.1.: Vergleich verschiedener symmetrischer Verschlüsselungsverfahren Algorithmus max. Schlüssellänge in Bit Veröffentlicht Sicher BSI Empfehlung AES Ja Ja Twofisih Ja Nein DES Nein Nein 3DES 168 (effektiv 112) 1981 Ja Nein Quellen: [3], [16] und [14] Die Tabelle 5.1 zeigt die Fakten der vorgestellten symmetrischen Verschlüsselungsalgorithmen. Wie dort zu erkennen, wird nur ein Algorithmus vom BSI empfohlen Bewertung asymmetrischer Verschlüsselungsverfahren Definition Unter asymmetrischen Verschlüsselungsverfahren versteht man im Allgemeinen Verfahren, 8 [4] 9 [3] 22

30 5. Auswahl und Bewertung von Verschlüsselungsverfahren die keinen vorherigen Schlüsselaustausch benötigen (Public Key Verfahren). Diese haben gegenüber den symmetrischen Verfahren den großen Nachteil, nicht sehr performant und nur für kleinere Datenmengen geeignet zu sein. Daher werden sie in der Regel nur für den Austausch privater Schlüssel der symmetrischen Verfahren verwendet. Es gibt einige asymmetrische Verfahren wie z.b. Rivest, Shamir und Adleman (RSA), Elliptic Curve Integrated Encryption Sheme oder das Discrete Logarithm Integrated Encryption Sheme. Allerdings spielt in der Praxis nur das RSA Verfahren eine relevante Rolle, daher wird im Rahmen dieser Arbeit auf eine genauere Erklärung anderer asymmetrischer Verfahren verzichtet. RSA Dieses Verfahren basiert auf mathematischen Einwegfunktionen. Dieses sind Funktionen, die in eine Richtung relativ einfach zu berechnen sind, deren Berechnung der Umkehrfunktion allerdings sehr aufwendig ist. Ein Beispiel für so eine Funktion ist die Zerlegung einer Zahl in ihre Primfaktoren. Dieses ist wesentlich aufwendiger, als das Erzeugen einer Zahl aus einzelnen Primzahlen per Multiplikation. Auf solchen Funktionen basiert das RSA Verfahren. Um eine solche mathematische Funktion effizient zu verwenden, wird mit zwei Schlüsseln gearbeitet: ein privater Schlüssel, der zum Entschlüsseln der Nachrichten verwendet wird, ein öffentlicher Schlüssel, der zum Verschlüsseln genutzt wird. Beide Schlüssel hängen voneinander ab und werden einmalig erstellt. Da zum Erstellen der Schlüssel große Primzahlen gefunden werden müssen, ist dieses sehr rechenaufwendig. Gerade der öffentliche Schlüssel sollte sehr groß gewählt werden, die Empfehlung des BSI beträgt im Moment 2000 Bit 10. Zusätzlich wird das RSA Verfahren auch für digitale Signaturen verwendet. Es bietet außer der Verschlüsselung auch die Verifizierung von Daten an Schlüsselaustauschverfahren Für den Schlüsselaustausch gibt es im Wesentlichen folgende Möglichkeiten: Direkt über eine sichere Verbindung. Hierfür eignet sich z.b. das RSA Verfahren, da kein vorheriger Schlüsselaustausch notwendig ist. Per sogenannter Perfect Forward Security (PFS). Mit dieser werden nur mathematische Faktoren übertragen. Aus diesen wird daraufhin der geheime Schlüssel berechnet. 10 [3] 23

31 5. Auswahl und Bewertung von Verschlüsselungsverfahren Der aktuelle Stand der Technik und auch das BSI empfehlen, einen Perfect Forward Schlüsselaustausch zu verwenden 11. Im Folgenden werden zwei dieser Verfahren vorgestellt. Diffie-Hellman-Schlüsselaustausch (DH) Mit diesem Verfahren können zwei Partner sicher einen geheimen Schlüssel austauschen, welcher niemals direkt übertragen wird. Selbst das Abfangen der Nachrichten für den Austausch lässt keinen Rückschluss auf den übertragenen Schlüssel zu. Die einzige Schwachstelle ist ein Man-in-the-middle-Angriff (MITM-Angriff), bei welchem der Angreifer mit den jeweiligen Partnern eigene Schlüssel austauscht. Daher sollte der DH niemals ohne Authentifizierung der einzelnen Nachrichten durchgeführt werden. Für diese ist das RSA Verfahren sehr geeignet, da man durch die Verschlüsselung die Sicherheit des DH noch zusätzlich erhöht. Ein beispielhafter Ablauf eines DH ist in Abbildung 5.1 dargestellt und beschrieben. Die Werte p = 13 und g = 2 werden zwischen Bob und Alice ausgetauscht. Bob und Alice wählen jeweils eine zufällig Zahl (b = 7, a = 4) die zwischen 0 und p-2 liegt Bob und Alice berechnen nun B = 11 = 2 7 mod13 bzw. A = 3 = 2 4 mod13. Abbildung 5.1.: Ablauf des Diffie-Hellmann Quelle: [15] Schlüsselaustausches Im folgenden Schritt werden B und A ausgetauscht, die Reihenfolge dieses Austauschs ist dabei irrelevant. Bob und Alice berechnen nun jeweils den geheimen Schlüssel K ab = 3 = 3 7 mod13 bzw. K ab = 3 = 11 4 mod13 11 [3] 24

32 5. Auswahl und Bewertung von Verschlüsselungsverfahren Elliptic Curve Diffie-Hellman-Schlüsselaustausch (ECDH) Das ECDH ist eine Erweiterung des DHs. Anstatt mit Primzahlen und Modulo Operationen wird hier mit elliptischen Kurven gerechnet. Ansonsten verhält sich der ECDH genauso wie der DH. Der Vorteil des ECDH ist die Verwendung von kürzeren Schlüsseln bei gleicher oder gar höherer Sicherheit im Vergleich zum DH. Ebenso ist die Performance besser. 12 Siehe dazu die folgenden Abbildungen 5.2 und 5.3. Quelle: [10] Abbildung 5.2.: Von der NIST empfohlene Schlüssellängen Abbildung 5.3.: Vergleich der benötigten Rechenleistung zwischen DH und ECDH Quelle: [10] 12 [10] 25

33 5. Auswahl und Bewertung von Verschlüsselungsverfahren In der Abbildung 5.2 wird dargestellt, welche Schlüssellängen bei den Verfahren DH und ECDH benötigt werden, um die selbe Sicherheit wie bei einem symmetrischem Verfahren zu erreichen. Die Abbildung 5.3 zeigt auf, in welchem Verhältnis sich der Rechenaufwand des DH zum ECDH Verfahren verhält, um ein bestimmtes Sicherheitslevel zu erreichen. Unter Sicherheitslevel wird in diesem Fall die Schlüssellänge eines symmetrischen Verfahrens verstanden Auswahl geeigneter Verfahren für den Proxy Für die Übertragung der zu verschlüsselnden Daten zwischen den verschiedenen Komponenten des Systems sollte insbesondere hinsichtlich der Performance ein symmetrisches Verfahren gewählt werden. Von diesen vorgestellten Verfahren wird der AES eingesetzt, da die Empfehlung des BSI dieses vorschlägt. Eine Alternative zum AES stellt das Twofish Verfahren dar. Für den Austausch der privaten Schlüssel des AES Verfahrens wird ein PFS Algorithmus eingesetzt. Von den hier vorgestellten Verfahren wird ECDH verwendet. Dieser wird aufgrund der besseren Performance gegenüber dem DH bevorzugt. 26

34 6. Konzept 6.1. Grundsätzlicher Aufbau und Begriffsdefinition des Proxy-Systems In diesem Kapitel wird der grundsätzliche Aufbau des Proxy-Systems, welches als Lösung für die Problemstellung entwickelt wurde, in vier Schritten erklärt. Während dieser Erklärung werden Begriffe definiert, welche in den nachfolgenden Kapiteln, in denen dieses Konzept im Detail behandelt wird, verwendet werden. 27

35 6. Konzept Änderungen am Ablauf der Datenübertragung im bestehendem System Abbildung 6.1.: Änderungen im Ablauf der Datenübertragung 28

36 6. Konzept Abbildung 6.2.: Beispielhafter Ablauf einer HTTP-Anfrage über die VPN-Proxys Zur Verdeutlichung der Funktionsweise des VPN-Proxys wird in diesem Kapitel von einem Server mit nur einem Client ausgegangen. Dieses System mit der vereinfachten Annahme wird in Abbildung 6.1 dargestellt. In dieser Abbildung wird ebenfalls die nötige Erweiterung des bestehenden Systems dargestellt. Diese Erweiterung besteht aus einem VPN-Proxy, welcher auf den beteiligten Systemen (Server sowie Client) betrieben wird. Im Gegensatz zu dem aktuellen System kommunizieren die einzelnen Anwendungen mit dieser Erweiterung nicht mehr direkt untereinander, sondern nur lokal mit dem VPN-Proxy. Der VPN-Proxy verschlüsselt die Daten, welche über die einzelnen Verbindung der Anwendungen gesendet werden und sendet diese an den anderen, an dieser Verbindung beteiligten VPN-Proxy, welcher die Daten entschlüsselt und an die Anwendung weiterleitet. Dieser Kommunikationsablauf wird in Abbildung 6.2 dargestellt. 29

37 6. Konzept Erste Erweiterung des bestehenden Systems Abbildung 6.3.: Erste Erweiterung des bestehenden Systems 30

38 6. Konzept Abbildung 6.4.: Vereinfachte Darstellung eines Verbindungsaufbau zu einem Client 31

39 6. Konzept Abbildung 6.5.: Vereinfachte Darstellung einer Anmeldung zwischen einem VPN-Proxy im Server-Modus und einem VPN-Proxy im Client-Modus Während im vorherigen Kapitel der einfache Funktionsablauf des VPN-Proxys bei einem vorhandenen Client für den Server erläutert wurde, wird nun dieses Konzept dahingehend erweitert, die Kommunikation mit mehreren Clients zu ermöglichen. Diese Erweiterung ist in Abbildung 6.3 dargestellt. An der grundlegenden Aufgabe des VPN-Proxys hat sich nichts 32

40 6. Konzept geändert. Die Datenübertragung verhält sich weiterhin wie in Abbildung 6.2 dargestellt. Die VPN-Proxys auf Server- und Client- Seite unterscheiden sich nun hinsichtlich des Verbindungsaufbaus zu einem Ziel. Während es bei den Clients nur ein Verbindungsziel existiert, ein Ziel für eingehende Verbindungsanfragen, ist es beim Server anders. Dieser muss zwischen mehreren vorhandenen Verbindungszielen unterscheiden. Um diesem Umstand Rechnung zu tragen wird der VPN-Proxy in zwei Konfigurationen betrieben. VPN-Proxy im Server-Modus (VPN-Server): Dieser wird auf dem Server betrieben und verwaltet mehrere Verbindungsziele. VPN-Proxy im Client-Modus (VPN-Client): Dieser wird auf dem Client betrieben und besitzt nur ein Verbindungsziel. Der Aufbau einer Verbindung zu einem Verbindungsziel, aus Sicht des VPN-Servers, ist in Abbildung 6.4 in vereinfachter Form dargestellt. Im Unterschied zum VPN-Client existiert bei diesem Verbindungsaufbau ein Auswahlverfahren, um den benötigten Client herauszufinden. Für dieses Auswahlverfahren gibt es mehrere Möglichkeiten, welche später noch im Detail erläutert werden. Der VPN-Client besitzt zur eindeutigen Identifizierung in dem Proxy-System eine ID. Mit dieser ID kann sich der VPN-Client an einem VPN-Server anmelden. Dem VPN-Server muss dazu die ID des VPN-Clients bekannt gegeben werden. Dieser Anmeldevorgang wird in Abbildung 6.5 vereinfacht dargestellt. 33

41 6. Konzept Zweite Erweiterung des bestehende Systems Abbildung 6.6.: Zweite Erweiterung des bestehenden Systems 34

42 6. Konzept Abbildung 6.7.: Vereinfachte Darstellung der Anmeldung eines VPN-Clients an einen Proxy Management Dienst unter Verwendung eines Proxy Watch/Start Dienstes Da das bestehende System aus einem Server mit mehreren Clients besteht, muss dem VPN-Server bekannt gegeben werden, welche VPN-Clients sich bei ihm anmelden dürfen. Dieses ist notwendig, um einen Missbrauch dieses Dienstes zu vermeiden. In Abbildung 6.4 werden zwei neue Komponenten dargestellt, die dem bestehenden System zum Lösen dieses Problems hinzugefügt wurden. Der Proxy Watch/Start Dienst (Proxy-WSD), welcher auf sämtlichen Komponenten betrieben wird, die den VPN-Proxy einsetzen, übernimmt das Starten des VPN- Proxys. Dieser Proxy-WSD überwacht des Weiteren den Prozess des VPN-Proxys, um einen eventuellen Ausfall zu erkennen. In diesem Fall wird durch den Proxy-WSD ein Neustart des VPN-Proxys initiiert. Des Weiteren meldet der Proxy-WSD den VPN-Client bei einem Proxy Management Dienst (Proxy-MD) an. Der Proxy-MD übernimmt die Überprüfung 35

43 6. Konzept der sich über den Proxy-WSD anmeldenden VPN-Clients und leitet die ID sowie weitere für den Verbindungsaufbau benötigte Daten bei erfolgreicher Überprüfung an den VPN-Server weiter. Der Ablauf einer solchen Anmeldung ist in Abbildung 6.7 dargestellt Abschließende Erweiterung des bestehende Systems Abbildung 6.8.: Abschließende Erweiterung des bestehenden Systems 36

44 6. Konzept Abbildung 6.9.: Vereinfachte Darstellung einer Anmeldung eines VPN-Servers an einen Proxy-MD mit einem Proxy-WSD In Abbildung 6.8 ist das bestehende System mit der Erweiterung des Proxy-Systems abgebildet. Wie dort zu erkennen ist, kann mehr als ein VPN-Server eingesetzt werden. Mit dieser Erweiterung des Systems kann eine Lastverteilung über mehrere VPN-Server realisiert werden. Um diese zu realisieren, müssen sich die VPN-Server beim Proxy-MD anmelden, siehe hierzu Abbildung 6.9. Der Proxy-MD überwacht nun durch regelmäßige Nachrichten an die bekannten VPN-Server die Auslastung der einzelnen VPN-Server und verteilt sich anmeldende VPN-Clients gleichmäßig auf die VPN-Server. Da nun mehrere VPN-Server in einem Proxy- System existieren können, müssen diese, wie die VPN-Clients, über eine ID eindeutig in diesem System identifizierbar sein. 37

45 6. Konzept 6.2. Protokolle Im Folgenden werden die Protokolle für die Kommunikation der Komponenten untereinander vorgestellt und erklärt. Sämtliche Daten werden per TCP übertragen Kommunikation zwischen Proxy Management Dienst und Proxy Watch/Start Dienst Die komplette Kommunikation zwischen den Proxy Diensten Proxy-MD und Proxy-WSD wird mit RSA verschlüsselt und beschränkt sich auf den Anmeldevorgang. Proxy im Server-Modus Abbildung 6.10.: Kommunikation des Proxy Management Dienstes mit einem Proxy im Server- Modus In Abbildung 6.10 wird der Anmeldevorgang eines Proxy-WSDs an dem Proxy-MD gezeigt, in 38

46 6. Konzept diesem Fall befindet sich der Proxy-WSD im Server-Modus. Die Anmeldung läuft wie folgt ab: Wenn der Proxy-MD bereits im Betrieb ist, meldet sich der Proxy-WSD bei ihm an. Beim Anmeldevorgang werden sämtliche für den weiteren Betrieb des VPN-Proxys benötigte Daten ausgetauscht. Während dieses Vorgangs wird mit den Daten des anmeldenden Proxy-WSD ein Abgleich mit den hinterlegten Daten durchgeführt, um zu überprüfen, ob es sich um einen berechtigten Proxy handelt. Danach findet zwischen dem Proxy-WSD und dem Proxy-MD keine weitere Kommunikation statt, außer wenn der Proxy-MD neu gestartet wird. Wenn der Proxy-MD gestartet wurde, schickt er an alle ihm bekannten VPN-Proxys eine Nachricht, welche einen neuen Anmeldevorgang bei diesen beginnen lässt. Proxy im Client-Modus Abbildung 6.11.: Kommunikation des Proxy Management Diensts mit einem Proxy im Client- Modus In Abbildung 6.11 wird wie in Abbildung 6.10 der Anmeldevorgang eines Proxy-WSDs an den Proxy-MD erläutert. Allerdings befindet sich der Proxy-WSD in diesem Fall im Client-Modus. Daher läuft der Anmeldevorgang nun wie folgt ab: Der Proxy-WSD sendet eine Loginanfrage an den Proxy-MD. Dieser Proxy-MD überprüft anhand der hinterlegten Daten, ob es sich um einen berechtigten Proxy-WSD handelt. Sollte das der Fall sein, so wählt er einen freien VPN-Proxy aus und leitet die Daten des Client an diesen weiter. Nach dem Erhalt der Antwort des Servers werden die in diesem Paket gespei- 39

47 6. Konzept cherten Daten (der ECDH Schlüsselpart und der Initialization Vector (IV)) an den Client weiter gesendet Kommunikation zwischen VPN-Proxy und Proxy Management Dienst Beim Vergleich der Abbildung 6.10 und 6.11 fällt auf, dass nur eine Kommunikation zwischen den beiden Komponenten stattfindet, wenn der VPN-Proxy im Server-Modus arbeitet. Wenn der Proxy-MD eine Anmeldung von einem Client bekommt, wird dem ausgewählten VPN- Proxy mitgeteilt, dass es einen neuen Client für ihn gibt. Um eine Lastverteilung mit mehreren VPN-Proxys zu ermöglichen, muss der Proxy-MD regelmäßig sämtliche ihm bekannten VPN-Server nach ihrer aktuellen Auslastung befragen Kommunikation zwischen VPN-Proxy und VPN-Proxy Für die Kommunikation von zwei VPN-Proxys untereinander werden diverse Protokolle benötigt. Diese werden anhand der zu übertragenden Daten in zwei Kategorien gegliedert: Managementprotokolle: Diese regeln die allgemeine Kommunikation zwischen den beiden Partnern, z.b. der Aufbau einer neuen Verbindung zum Datenaustausch oder den Anmeldevorgang. Datenaustauschprotokoll: Dieses wird für die Datenübertragung benötigt, um Datenpakete zwischen den beiden Partnern auszutauschen. Bei diesen Daten handelt es sich um die Daten, welche über die sichere Verbindung von einer Anwendung zu einer anderen transportiert werden sollen. Der größte Unterschied zwischen diesen beiden Kategorien besteht in den ausgetauschten Nachrichten. Die Nachrichten vom Datenaustauschprotokoll haben eine dynamische Länge, während beim Managementprotokoll alle Nachrichten die gleiche Länge haben und ähnlich aufgebaut sind Eigenschaften der Protokolle Die Protokolle für die Kommunikation zwischen den VPN-Proxys müssen folgende Eigenschaften erfüllen, um einen den sicheren Betrieb des VPN-Systems zu ermöglichen: Information Hiding Unter dem Begriff des Information Hidings, zu Deutsch Datenkapselung, versteht man: 40

48 6. Konzept Als Datenkapselung... bezeichnet man in der Programmierung das Verbergen von Daten oder Informationen vor dem Zugriff von außen. 1 Bei Protokollen kann man nicht verbergen, wann Nachrichten ausgetauscht werden. Allerdings kann verhindert werden, das Nachrichten mit identischem Inhalt ausgetauscht werden. Somit kann ein möglicher Angreifer zwar erkennen, wann Nachrichten ausgetauscht werden, allerdings kann er keine Rückschlüsse auf den Inhalt ziehen. Ressourcenverbrauch Da sämtliche Nachrichten verschlüsselt werden und der Rechenaufwand zum Ver- bzw. Entschlüsseln relativ hoch ist, sollten die Nachrichten möglichst klein sein, idealerweise kleiner als die Blockgröße des AES Verfahrens. Unter der Blockgröße versteht man die Anzahl der Bits, welche bei einmaliger Ausführung des Verschlüsselungsverfahrens verschlüsselt werden. Bei dem AES Verfahren beträgt die Blockgröße 128 Bit 2. 1 [17] 2 [14, S. 128] 41

49 6. Konzept Aufbau der Protokoll Nachrichten Tabelle 6.1.: Nachrichtengrößen in Byte Name Managementprotokoll Datenaustauschprotokoll Typ Header Daten Größe in byte max Tabelle 6.2.: Aufbau einer Managementprotokollnachricht Bedeutung Größe in Byte Kommando 4 Zeitstempel 8 Payload 16 Tabelle 6.3.: Header Aufbau des Datenaustauschprotokolls Bedeutung Größe in Byte Fortlaufende Nummer 8 Länge des nächsten Pakets 4 ID 4 In der Tabelle 6.1 wird die Größe bzw. die maximale Größe der Nachrichten des Management sowie des Datenaustauschprotokolls dargestellt. Wie zu erkennen ist, weicht die Größe der Managementnachrichten von der idealen Größe von 16 Byte ab. Dieses geschieht aus den Gründen des Information Hiddings und der Fehlererkennung. Des Weiteren ist in dieser Tabelle zu erkennen, dass bei dem Managementprotokoll eine Nachricht mit einer festen Größe verwendet wird, während beim Datenaustauschprotokoll eine Nachricht eine variable Größe hat. In Tabelle 6.2 wird der Aufbau einer Management Protokoll Nachricht gezeigt. Das Kommando enthält einen nummerischen Wert, welcher nur bestimmte Werte annehmen darf. Dieser Wert wird dafür genutzt, um die Nachricht einem bestimmten Protokoll zuzuordnen. Der Zeitstempel bei der Managementprotokollnachricht wird für das Information Hidding verwendet. Der garantiert, dass niemals zwei gleiche Nachrichten übertragen werden. Die Payload enthält je nach Kommando unterschiedliche Werte. Bytes, die in der Payload nicht 42

50 6. Konzept verwendet werden, müssen den Wert null enthalten. Von diesem Schema weicht nur eine Nachricht ab. Dieses ist die erste Nachricht, die ein VPN-Client an einen VPN-Server sendet. Sie enthält ein Kommando, jedoch keinen Zeitstempel und keine Payload, dafür eine ID, die sich über die restliche Nachrichtengröße erstrecken kann. Wie bei der Payload gilt, dass nicht benutzte Bytes den Wert null haben. Tabelle 6.3 zeigt den Aufbau einer Header Nachricht des Datenaustauschprotokolls. Die Werte in den Feldern Fortlaufende Nummer und ID verifizieren, dass die Reihenfolge der Nachrichten eingehalten wird und diese auch zu der aktuellen Übertragung gehören. Im Feld Länge des nächsten Pakets wird die Länge der nun zu empfangenen Daten angegeben. Das Information Hidding wird durch die Kombination der Felder Fortlaufende Nummer und ID gewährleistet. Dieses allerdings nur, da sich die ID bei jedem Verbindungsaufbau ändert und sich mit jeder versendeten Nachricht auch die fortlaufende Nummer ändert. Bei jedem neuen Verbindungsaufbau der VPN-Proxys untereinander wird ein neuer Schlüssel generiert. Somit sind keine gleichen Nachrichten möglich, obwohl sich ID und fortlaufende Nummer wiederholen könnten. 43

51 6. Konzept Anmeldung VPN-Proxy Client an VPN-Proxy Server Abbildung 6.12.: Ablauf einer Anmeldung eines VPN-Clients an einen VPN-Server Das in Abbildung 6.12 beschriebene Protokoll wird für die Anmeldung eines VPN-Clients bei einem VPN-Server verwendet. Der Client sendet zuerst seinen Identifyer, eine in diesem Proxy-System einmalige Zeichenkette, an den Server. Dieses geschieht unverschlüsselt, damit er die Nachricht einem VPN-Client zuweisen kann. Der Identifyer wird auf Bekanntheit überprüft. Danach kennt der Server den geheimen Schlüssel für diese Verbindung und kann die nächste Nachricht entschlüsseln. Sollte der Client nicht bekannt sein, so schließt der Server die Verbindung. In der zweiten Nachricht sendet der Client eine Challenge an den VPN-Server, 44

52 6. Konzept um zu überprüfen, ob dieser der Richtige ist und die Nachricht erfolgreich entschlüsselt werden konnte. Die Antwort des Servers enthält die Challenge vom Client und eine eigene Challenge. Sollte die Challenge, die beim Client ankommt, nicht korrekt sein, sendet er eine Failure Nachricht an den Server. Ansonsten wird eine Authorized Nachricht mit der Challenge vom Server gesendet. Der Server überprüft nun seinerseits die zurückgekommene Challenge. Sollte diese falsch sein, wird wie beim Client eine Failure Nachricht gesendet. Ansonsten wird eine Accept Nachricht gesendet. Danach ist der Anmeldevorgang abgeschlossen Verbindungsaufbau von der Seite des VPN-Proxy im Client-Modus Abbildung 6.13.: Verbindungsaufbau von der Seite des VPN-Clients Der Ablauf eines Verbindungsaufbaus zwischen zwei externen Anwendungen wird in Abbildung 6.13 dargestellt. Dieser läuft wie folgt ab: Wenn beim VPN-Client eine externe Anwendung mit dem VPN-Server kommunizieren möchte, verbindet diese sich über einen Port mit dem lokalen VPN-Proxy. Dieser sendet eine Nachricht vom Typ Connection an den Server. Diese enthält den Port, mit dem eine Verbindung hergestellt werden soll sowie einen Typ der angibt, ob ein Protokollinterpreter verwendet werden soll und eine eindeutige ID. Wenn der Server diese Nachricht erhält, versucht er sich lokal auf den übertragenden Port zu verbinden. Wenn dieses erfolgreich war, erstellt er einen Listener, 45

53 6. Konzept der auf einem Port auf eine eingehende Verbindung wartet. Dieser Port wird in der Finish Nachricht dem Client mitgeteilt. Auf diesen Port verbindet sich nun der Client. Anschließend können die Anwendungen auf Seite des Clients und des Servers über die jeweiligen lokalen VPN-Proxys kommunizieren. Wenn keine erfolgreiche Verbindung vom Server auf den lokalen Port hergestellt werden kann, wird ein Failure übertragen Verbindungsaufbau von der Seite des VPN-Proxy im Server-Modus Abbildung 6.14.: Verbindungsaufbau von der Seite des VPN-Server Der Aufbau einer Verbindung vom Server in Richtung des VPN-Clients wird in Abbildung 6.14 dargestellt. Dieses läuft ähnlich ab wie der in Kapitel beschriebene Verbindungsaufbau. Der wesentliche Unterschied liegt in den Parametern der Nachrichten. Der Client bekommt bei einer Connection Nachricht bereits beide benötigten Ports mitgeteilt, den der 46

54 6. Konzept externen Anwendung und den des Listeners auf Serverseite. Der Ablauf der Nachrichten und die Bedeutung ist in beiden Fällen gleich Ping Protokoll Abbildung 6.15.: Ping Protokoll Dieses Protokoll, siehe Abbildung 6.15, wird dazu benutzt, um zu überprüfen, ob beide Teilnehmer noch reagieren. Dazu schickt der VPN-Server eine Ping Nachricht an den VPN-Client. Antwortet dieser nicht in einer definierten Zeitspanne mit einer Nachricht, welche das Kommando Pong enthält, schließt der Server die Verbindung, da davon auszugehen ist, dass der Client nicht mehr reagiert. Der VPN-Client erwartet auch regelmäßig Ping Nachrichten. Sollte eine ausbleiben, wird die bestehende Verbindung geschlossen und ein Reconnect auf den VPN-Proxy versucht. Wenn dieses nach einer definierten Anzahl von Versuchen nicht erfolgreich war, wird über den Proxy-WSD versucht den Proxy-MD zu erreichen Connection Id Austauschprotokoll Abbildung 6.16.: Connection Id Austauschprotokoll Da die IDs für den Verbindungsaufbau eindeutig sein müssen, verwaltet der VPN-Server diese, 47

55 6. Konzept d.h. wenn der VPN-Client eine solche ID für einen Verbindungsaufbau benötigt, muss er sich an den Server wenden. Dies geschieht durch Anwendung des in Abbildung 6.16 dargestellten Protokolls. Das Protokoll wird mit dem Senden einer Nachricht vom Typ: GetConnectionIds initialisiert. In dieser gibt der Client zusätzlich an, wie viele Connection IDs er benötigt, um sich einen Vorrat anzulegen. Der Server antwortet mit Nachrichten vom Typ: ConnectionIds. Die Anzahl der Nachrichten, die der VPN-Server an den VPN-Client sendet, ergibt sich aus der Anzahl der vom VPN-Client abgeforderten Connection IDs. Allerdings ist grundsätzlich die komplette Payload der Nachricht mit Connection IDs gefüllt Datenübertragungsprotokoll Die Datenübertragung für die Anwendungen läuft auf beiden Seiten (VPN-Client und VPN-Server) symmetrisch ab. Empfangen der Daten: Die Daten der Anwendung werden empfangen und durch einen Protokollinterpreter interpretiert. Aus diesen Daten wird nun eine Header Nachricht generiert (siehe Tabelle 6.3). Diese wird verschlüsselt und an die Gegenstelle gesendet. Anschließend werden auch die interpretierten Daten der Anwendung verschlüsselt, womit sie eine Datennachricht sind, und an die Gegenstelle gesendet. Weiterleiten der Daten: Im ersten Schritt wird eine Header Nachricht empfangen, entschlüsselt und ausgewertet (siehe Tabelle 6.3). Mit den Werten aus dem Header werden nun die Daten empfangen. Nach dem Empfang werden diese entschlüsselt und durch einen Protokollinterpreter interpretiert. Sobald dieses erledigt ist, werden die Daten an die Anwendung weitergeleitet. Besonderheiten bei FTP-Verbindungen Bei FTP-Verbindungen besteht das Problem des aktiven 3 und passiven 4 nachträglichen Verbindungsaufbaus von Seiten des FTP-Clients bzw. des FTP-Servers. Um diese Verbindungen ohne Anpassung der FTP-Anwendungen trotzdem über den VPN-Proxy zu leiten, muss das FTP-Protokoll interpretiert und die FTP-Nachrichten angepasst werden. Das FTP-Protokoll wird nun nach folgenden Kommandos abgehört: 227, PORT und PASV. Nach den Kommandos 227 und PORT wird in den Daten, welche an die FTP-Anwendung weitergeleitet werden, gesucht. Nach dem Kommando 227 wird erst gesucht, wenn bei den Daten, die von der FTP-Anwendung kommen, das PASV Kommando gefunden wurde. Wenn eines dieser 3 [13] 4 [13] 48

56 6. Konzept Kommandos entdeckt wurde, wird für den darauf folgenden Verbindungsaufbau ein Listener auf einem freien Port gestartet. Diese Portnummer wird nun in das FTP-Protokoll eingefügt, damit die FTP-Anwendung sich auf den Listener verbindet. Die neue Verbindung wird, wie in den vorherigen Punkten beschrieben, aufgebaut. Allerdings muss diese nicht mehr interpretiert werden, da über diese nur FTP-Nutzdaten und keine Kommandos übertragen werden Komponenten Aufbau des Proxy Management Dienstes Abbildung 6.17.: Ablaufdiagramm des Proxy-MD Wie in Abbildung 6.17 zu erkennen, kann der Proxy-MD grob in vier Komponenten unterteilt werden. Diese Komponenten sollten als ein Windows Dienst erstellt werden, damit ein reibungsloser Ablauf im Hintergrund sowie ein automatisches Starten gewährleistet wird. 49

57 6. Konzept Sie verfügen ebenfalls über ein HTTPs Interface, über welches XML Dokumente empfangen werden. Diese enthalten die Kommandos sowie die benötigten Parameter, auf welche der Proxy-MD reagiert. Der Startup Thread, welcher die Konfiguration liest und an sämtliche bekannten VPN-Server eine Nachricht sendet. Diese Nachricht löst bei den VPN-Servern einen neuen Anmeldevorgang aus. Im Anschluss reagiert dieser Thread auf das Ablaufen eines Timers oder auf eingehende Nachrichten. Der Check VPN-Proxy Thread wird vom Startup Thread beim Ablaufen eines Timers notifiziert. Er schickt daraufhin sequenziell an alle VPN-Proxys eine Nachricht. In der Antwort steht die Anzahl der bekannten und der gerade angemeldeten VPN-Clients. Mit diesen Daten wird eine interne Liste gepflegt, über die eine Lastverteilung realisiert wird. Der Add Server Thread wird mit Eingang eines LoginServer Kommandos gestartet und regelt den Anmeldevorgang mit einem VPN-Server. Für jede eingehende Nachricht wird ein weiterer Add Server Thread gestartet. Als Parameter wird ein ECDH Austauschparameter erwartet. Der VPN-Server wird mit einer Liste bekannter VPN-Server abgeglichen. Sollte er nicht in dieser Liste stehen, wird ein Fehler zurückgegeben. Wenn er allerdings in dieser Liste steht, so werden seine internen Daten aktualisiert. Ebenso wird mit dem übergebenden Austauschparameter ein geheimer Schlüssel sowie ein IV für die interne Kommunikation mit dem Server generiert. In der Antwort für den Anmeldevorgang wird der IV sowie der eigene ECDH Austauschparameter übertragen. Nun steht dieser VPN-Server für den Anmeldevorgang der VPN-Clients zur Verfügung. Der Add Client Thread regelt im Gegensatz zum Add Server Thread die Anmeldung der VPN-Clients. Er wird durch das Kommando LoginClient gestartet. Ebenso wie beim LoginServer wird für jeden Aufruf ein weiterer Thread gestartet. Als Parameter werden die ID und ein ECDH Austauschparameter erwartet. Im ersten Schritt wird einer Datenschnittstelle die ID des Clients zur Verifizierung übergeben. Nach Validierung dieser ID wird aus der internen VPN-Server Liste der VPN-Server mit den wenigsten aktiven Clients ausgewählt, welcher online ist. Sollte kein VPN-Server gefunden werden oder die übertragene ID ist unbekannt, wird ein Fehler als Antwort gesendet. Ansonsten wird nun der ausgewählte VPN-Server mit dem AddClient Kommando benachrichtigt, bei welchem die beiden Eingangsparameter sowie sonstige evtl. vorhandene Parameter mitgegeben werden. Die Antwort enthält nun den anderen ECDH Austauschparameter 50

58 6. Konzept vom VPN-Server sowie den IV. Diese beiden Werte sowie die Adresse des VPN-Server werden dem VPN-Client als Antwort auf den Anmeldevorgang mitgeteilt, ebenso wird in der internen Liste dem VPN-Server ein aktiver VPN-Client hinzugefügt Aufbau des Proxy Watch/Start Dienst Abbildung 6.18.: Ablaufdiagramm des Proxy-WSD Im Gegensatz zum Proxy-MD ist der Aufbau und die Funktion des Proxy-WSD absichtlich unkompliziert gehalten. Eine seiner Aufgaben besteht in der Anmeldung der VPN-Proxys an den Proxy-MD. Beim Starten des Anmeldevorgangs wird aus der Konfiguration des VPN-Proxys die ID gelesen. Welches Kommando ( LoginClient oder LoginServer ) für den Anmeldevorgang verwendet werden soll, wird aus der Konfiguration des Proxy-WSDs gelesen. Mit diesen Informationen kann der Proxy-WSD die Anmeldung am Proxy-MD vornehmen. Zusätzlich wird ein ECDH Schlüsselteil generiert. Diese Daten werden in einer Nachricht und mit dem jeweiligen Kommando an den Proxy-MD geschickt. Sollte ein Fehler zurückkommen, wird dieser Vorgang nach einer definierten Zeitspanne wiederholt. Andernfalls wird aus dem, in der Antwort enthaltenen ECDH Schlüsselteil ein vollständiger Schlüssel generiert und mit diesem sowie mit dem IV, welcher ebenfalls in der Antwort enthalten ist, der VPN-Proxy gestartet. Sollte der VPN-Proxy ein VPN-Client sein, wird in seine Konfiguration vor dem Starten noch die VPN-Server Adresse hinzugefügt. Nach erfolgreichem Starten überwacht der Proxy-WSD regelmäßig den gestarteten VPN-Proxy, indem er den Zustand des Prozesses abfragt. Sollte der gestartete Prozess nicht mehr aktiv sein, wird ein neuer Anmeldevorgang beim Proxy-MD 51

59 6. Konzept eingeleitet, dieses passiert ebenfalls, wenn beim Starten des VPN-Proxys ein Fehler auftritt oder vom Proxy-MD ein InitCommand empfangen wird. Hierbei wird zuerst ein evtl. laufender VPN-Proxy beendet. Wenn der Proxy-WSD beendet wird und ein VPN-Proxy gestartet wurde, wird dieser ebenfalls beendet Aufbau des VPN-Proxys CallBack interface Die Kommunikation der Komponenten untereinander wird über dieses CallBack Interface abgewickelt. Daher besitzen die meisten Komponenten eine Instanz dieses Interfaces oder implementieren es Listener Abbildung 6.19.: Ablaufdiagramm des Listeners Der Listener besitzt als einzige Aufgabe das Annehmen von Verbindungen an einem Port, siehe Abbildung Beim Erstellen eines Listeners wird der entsprechende Port und ein CallBack Interface übergeben. Der Listener besitzt zwei Betriebsmodi, welche angeben, wie oft neue Verbindungen ohne zusätzliche Aktion weiter delegiert werden, zum einen das endlose Delegieren und zum anderen das einmalige Delegieren. Beim einmaligen Delegieren werden im Anschluss alle eingehenden Verbindungen geschlossen. Eine Verbindung wird an ein CallBack Interface weiter delegiert und dort abgearbeitet. Listener haben außerdem einen bestimmten Typ, den sie beim erstmaligen Starten zugeteilt bekommen. Im späteren Verlauf regelt dieser Typ den Umgang mit einer eingehenden Verbindung von diesem Listener und welcher Mapper 52

60 6. Konzept verwendet werden soll. Im Moment gibt es folgende Typen: MultiAdrListener: Dieser gibt die Verwendung eines IP Mapper an. CommunicationListener: Verbindungen von diesem Typ werden von der Mangement Komponente dazu verwendet, einen neuen Communicationhandler zu erstellen. WorkingListener: Dieser ist für den internen Gebrauch gedacht und wird z.b. vom FTP-Parser verwendet, um einen neuen Listener zu erstellen. ServiceListener: Dieser Listener wird für die Kommunikation mit dem Proxy-MD verwendet. Socks5Listener: Dieser Typ bestimmt, dass der Socks5 Mapper verwendet wird. 53

61 6. Konzept Socks5 Abbildung 6.20.: Ablaufdiagramm des Socks5Handlers Da der VPN-Proxy sowohl ohne Verschlüsselung als auch mit für dieses Protokoll genutzt werden soll, muss eine Fallentscheidung während des Verbindungsaufbaus getroffen werden. Dieses geschieht über die Authentifizierung. Während dieser werden nicht nur die Zugangsdaten validiert, sondern auch an eine Datenschnittstelle übergeben. Diese gibt an, ob die Verschlüsselung genutzt werden soll. Wenn das der Fall sein sollte, wird die Verbindung nicht direkt, sondern über den VPN-Proxy aufgebaut. Das geschieht durch einfaches Benachrichti- 54

62 6. Konzept gen der Management Komponente, welche nun den Verbindungsaufbau zum Ziel übernimmt. Wenn dieser erfolgreich beendet wurde, sendet der Server noch eine letzte Antwort an den Client. Danach ist dieser Thread beendet. Wenn der VPN-Proxy nicht benutzt werden soll, startet der Server einen Worker, welcher den Verbindungsaufbau zum Ziel sowie die spätere Kommunikation des Clients mit dem Ziel übernimmt. Der Thread beendet sich in diesem Fall erst, wenn die Kommunikation zwischen den Anwendungen beendet ist Mapper Abbildung 6.21.: Genereller Ablaufdiagramm eines Mappers Der Mapper ist eine Alternative zum Socks5 Protokoll. Diese Komponente übersetzt z.b. die IP-Adresse der eingehenden Verbindung in eine ID. Sie kann für verschiedene Anwendungsfälle bzw. Übersetzungsansprüche ausgetauscht werden, allerdings funktioniert der Mapper grundsätzlich nach dem in Abbildung 6.21 dargestellten Schema: Reagieren auf den Connection callback von einem Listener. Übersetzen der Verbindung zu einer ID. Weiterleiten des Connection callbacks mit der übersetzten ID an einen CallBack Handler. 55

63 6. Konzept Management Abbildung 6.22.: Ablaufdiagramm der Management Komponente Die Management Komponente, welche in Abbildung 6.22 dargestellt ist, übernimmt die Verwaltung aller Listener sowie Communicationhandler. Im Betrieb als VPN-Server fungiert diese Komponente als Mapper zwischen den Listenern und den Communicationhandlern. Für die eingehenden Verbindungen wählt die Management Komponente anhand der vom Mapper ermittelten ID den richtigen Communicationhandler aus. Falls keiner vorhanden ist, beendet die Management Komponente die Verbindung. Für eingehende Verbindungen von einem Listener des Typs CommunicationListener erstellt diese Komponente einen neuen Communicationhandler, falls es keinen bestehenden mit der selben ID und aktiver Verbindung 56

64 6. Konzept gibt. Sollte es einen solchen Communicationhandler bereits geben, wird die neue Verbindung beendet. Wenn eine Nachricht vom Proxy-MD empfangen wird, wird diese interpretiert sowie eine Antwort erstellt und verschickt. Für diese Verbindung wurde beim Anmelden an den Proxy-MD ein privater Schlüssel vereinbart, mit dem die Nachrichten ver- bzw. entschlüsselt werden. Als VPN-Client entfallen diese Aufgaben. Da es nur einen Communication Handler gibt, delegieren die Listener direkt ihre Verbindungen an diesen. Ebenso werden keine neuen Communicationhandler benötigt. Daher ist diese Komponente in diesem Fall nur für den einmaligen Start der Listener und des Communicationhandlers verantwortlich. Wie in Abbildung 6.22 zu sehen, verwaltet diese Komponente auch das Erstellen von neuen Listenern. Per Callback wird geprüft, ob ein aktuell verfügbarer Listener bereitsteht. Wenn dieses der Fall ist, wird dieser zurückgegeben. Ansonsten wird ein Neuer erstellt. 57

65 6. Konzept Communication-Handler Abbildung 6.23.: Ablaufdiagramm des Communication-Handlers Die in Abbildung 6.23 dargestellte Komponente verwaltet die Kommunikation mit einem VPN-Proxy. Die Unterschiede zwischen VPN-Client und VPN-Server sind nur in den unter- 58

66 6. Konzept schiedlichen Protokollen zu finden. Der Aufbau ist identisch. Es gibt zwei Threads, den CallBack und den Readthread. Der Readthread reagiert auf eingehende Nachrichten von dem anderen VPN-Proxy und interpretiert diese, während der CallBack Thread auf sämtliche CallBacks reagiert, welche er bekommt. Der Communication-Handler erwartet CallBacks von Listenern, der Management Komponente, WorkerThreads ebenso wie von den Threads, die für einen Verbindungsaufbau zuständig sind. Diese CallBacks werden entweder weiter delegiert oder direkt abgehandelt. Aufwendige bzw. zeitintensive Aufgaben werden bei beiden Threads in einen eigenen Thread ausgelagert, wie z.b. das Aufbauen einer neuen Verbindung. Unterschiede zwischen VPN-Client und VPN-Server Die Unterschiede zwischen diesen beiden Betriebsmodi liegen in dem unterschiedlichen Ablauf der zugrundeliegenden Protokolle. Wie z.b. beim Ping Protokoll: der VPN-Server wird eine eingehende Ping Nachricht als Fehler auffassen, während der VPN-Client darauf mit einem Pong antwortet. Ablauf des Verbindungsaufbau bei unterschiedlichen Betriebsmodi Abbildung 6.24.: Ablaufdiagramm einer Verbindungsanfrage von einer Anwendung Abbildung 6.25.: Ablaufdiagramm einer Verbindungsanfrage von einem VPN-Proxy 59

67 6. Konzept Wie in den Abbildung 6.24 und 6.25 zu sehen, unterscheidet sich der Verbindungsaufbau in den verschieden Betriebsmodi. Der größte Unterschied liegt darin, dass der VPN-Client eine neue Verbindung zum VPN-Server aufbaut, damit über diese die Kommunikation ablaufen kann. Den Port für diesen Aufbau bekommt er, je nach Verbindungsaufbau, entweder in der Connection- (Verbindung initiiert vom VPN-Server) oder in der Finish- (Verbindung initiiert vom VPN-Client) Nachricht. Fehlerbehandlung Sollten Nachrichten empfangen werden, die nicht interpretiert oder erwartet sind, wird der Communication-Handler die Verbindung beenden. Die erwarteten Nachrichten unterscheiden sich je nach Betriebsmodus und dem Zustand des Communication-Handlers, z.b.: Während des Anmeldevorgangs werden nur Nachrichten für den Anmeldevorgang in der richtigen Reihenfolge erwartet. Nach dem Anmeldevorgang wird keine weitere Nachricht vom Anmeldevorgang erwartet. Betriebsmodus Server: Es wird keine Ping- oder ConnectionId- Nachricht erwartet. Betriebsmodus Client: Es wird keine Pong- oder GetConnectionId- Nachricht erwartet. 60

68 6. Konzept Worker Abbildung 6.26.: Ablaufdiagramm des Workers Der Worker besteht wie in Abbildung 6.26 dargestellt aus drei Threads: Der Initthread wird direkt gestartet. Wenn es noch keine Verbindung zu einer externen Anwendung gibt, d.h. der Verbindungsaufbau von einem VPN-Proxy initiert wurde, versucht er eine Verbindung zu der gewünschten Anwendung aufzubauen. War dieses erfolgreich, wird wenn es sich um einen VPN-Client handelt, eine Verbindung zum VPN-Server hergestellt. Als VPN-Server schickt der Thread ein CallBack mit dem Kom- 61

69 6. Konzept mando NeedListener. Der Empfänger des CallBacks (die Management Komponente) erstellt einen neuen Listener und setzt den sendenden Worker als CallBack Empfänger ein. Wenn in einem definierten Zeitraum ein Connection CallBack empfangen wurde bzw. die Verbindung erfolgreich hergestellt wurde, befindet sich die Worker Komponente im Besitz von zwei unabhängigen Verbindungen. Über diese Verbindungen wird die Kommunikation der beiden externen Anwendungen durch zwei weitere Threads, welche nun gestartet werden, abgewickelt. Wenn die definierte Zeitspanne für den Verbindungsaufbau abläuft oder die Verbindung zum angegeben Port nicht möglich ist (externe Anwendung bzw. anderer VPN-Proxy), wird ein CallBack vom Typ Error gesendet. Nach dem Starten der beiden Threads oder dem Auftreten eines Fehlers beendet sich der Initthread, wobei er alle bestehenden Verbindungen schließt. Der Listener Thread reagiert auf der durch den Initthread erstellten Verbindung zum anderen VPN-Proxy auf eingehende Nachrichten. Die erste erwartete Nachricht ist ein verschlüsselter Header. Nach Empfang eines solchen wird dieser entschlüsselt und seine folgenden Werte überprüft. Die ID muss identisch mit der im Worker hinterlegten sein und die Nummer muss die erwartete sein. Wenn diese Werte übereinstimmen, wird im Folgenden auf ein verschlüsseltes Datenpaket mit der im Header gesendeten Länge gewartet. Nach Erhalt dieses Pakets wird es entschlüsselt und durch einen evtl. vorhanden Protokollinterpreter gesendet. Diese Daten werden an die externe Anwendung gesendet. Danach wird von Neuem auf den Empfang eines Headers gewartet. Der Sender Thread reagiert ebenfalls auf der durch den Initthread erstellten Verbindung zur externen Anwendung auf den Empfang von Daten. Sobald Daten empfangen wurden, werden diese an den Protokoll Parser übergeben und aus den daraus resultierenden Daten wird ein Header (siehe Tabelle 6.3) erstellt. Dieser wird verschlüsselt und zum VPN-Proxy gesendet. Im Anschluss werden die Daten ebenfalls verschlüsselt und an den VPN-Proxy der Gegenseite gesendet. Sobald diese gesendet wurden, wird von Neuem auf den Empfang von Daten gewartet. 62

70 7. Umsetzung und Implementierung 7.1. Eingesetzte Werkzeuge Für die Umsetzung des Konzepts wurden folgende Werkzeuge verwendet: UML-Werkzeug: Sparx Systems Enterprise Architect Version 10 Entwicklungsumgebung: Microsoft VisualStudio 2012,.Net Framework Version 4.0 C++ Compiler: Visual C++ Version 110 Externe Libaries: Boost Libary in Version 1.54 und Crypt++ Libary in Version 5.62 Interne Libaries: qstd10.lib (C++) und qbaselib (C#) Die externen Libaries wurden aufgrund ihres Lizenzmodels gewählt. Sie stehen beide unter der Boost Software License Zusätzliche Libarys Wie im vorherigen Punkt gezeigt, wird für die Implementierung des Proxy-Systems auf bereits vorhandene Libarys zurückgegriffen. In diesem Abschnitt wird erläutert, warum dieses nötig ist. Die Boost Libary wird aufgrund der Portierbarkeit des fertigen VPN-Proxys eingesetzt. Diese wird durch die von der Libary bereitgestellte Abstraktion des Sockets erhöht. Ebenfalls werden der boost::thread und die entsprechenden Kontrollobjekte für die Verwaltung von Threads, Locks, ConditionVariablen usw. eingesetzt. Dieses geschieht aus dem Grund der Portierbarkeit gegenüber des Compilers, da je nach verwendetem Compiler entweder auf die std::thread, pthread und den Windows Thread zurückgegriffen wird. 1 [2] 63

71 7. Umsetzung und Implementierung Die OpenSource Crypto++ Libary stellt sämtliche Verschlüsselungsfunktionen bereit, auf Windows wie auch auf Linux. Die Verwendung dieser Libary steht nicht im Widerspruch zu der Anforderung der vertrauenswürdigen Erweiterung 2. Diese Anforderung hat unter anderem gegen die Verwendung eines VPN-Programms gesprochen 3. Da die Komplexität dieser Libary wesentlich geringer ist als die einer fertigen VPN Lösung, ist es mit relativ geringem Aufwand möglich, die Libary in angemessener Zeit für eine Aktualisierung zu überprüfen. Hinzu kommt, dass die Wahrscheinlichkeit durch eine eigene Implementierung der Verschlüsselungsalgorithmen Fehler zu produzieren, die Angriffe möglich machen, sehr hoch ist. Diese Fehler werden durch den Einsatz der Crypto++ Libary ausgeschlossen. Die QBase Libary wird zum einfachen Erstellen eines Windows Dienstes unter Verwendung der Sprache C# verwendet. Von der qstd10 Libary wird vor allem der firmeninterne Loggingmechanismus sowie diverse Hilfsfunktionen für Strings verwendet Zusätzliche Klassen Service Host Der Service Host ist eine firmeninterne Komponente. Die einzige Aufgabe dieser Komponente ist es DLL s, sogenannte Tasks, die in einer XML Datei hinterlegt sind, durch definierte Einsprungpunkte zu starten. Diese Komponente läuft standardmäßig als Windows Dienst. Ein Betrieb als Konsolenanwendung ist dennoch möglich HTTP-Dispatcher Der HTTP-Dispatcher ist ein Task für den Service Host. Er verwaltet den HTTP-Zugriff auf einen bestimmten Port. Sämtliche Anfragen werden an die entsprechenden Tasks weitergeleitet. Für jede Anfrage wird ein eigener Thread gestartet. Ein Aufruf dieser Funktion erfolgt nach folgenden Schema: Die Parameter werden per HTTP-Post übergeben und bestehen aus einer XML Datei. 2 siehe Kapitel siehe Kapitel

72 7. Umsetzung und Implementierung Quazar Crypt Libary Im Zuge der Entwicklung ist eine neuen Libary für C++ und C# entstanden, die Quazar Crypt Libary (QCryptLib). Diese bietet aktuell den Zugriff auf Verschlüsselungsfunktionen für die beiden verwendeten Programmiersprachen C# und C++ an. Das Erstellen dieser zusätzlichen Libary wurde durch die Verwendung von zwei unterschiedlichen Programmiersprachen nötig, damit beide Sprachen die gleichen Funktionen, vor allem hinsichtlich des ECDH Schlüsselaustausches, verwenden C++ Quazar Crypt Libary Abbildung 7.1.: Klassendiagramm der Quazar Crypt Libary in C++ Diese in C++ geschriebene Libary vereinfacht den Zugriff auf die externe Crypto++ Liba- 65

73 7. Umsetzung und Implementierung ry. Wie in Abbildung 7.1 ersichtlich, werden im Moment folgende Funktionen durch diese Libary bereit gestellt: Schlüsselaustausch (DiffiHellman_EC) per ECDH Verschlüsselung (AES) mit dem AES Algorithmus Konvertierungsfunktionen : Konvertierung von einem char Array in einen Hex- String (ConvertToHexString) und umgekehrt (ConvertFromHexString) Hashfunktion (SHA256): Bildung von einem String über SHA256 Zufallszahlengenerator (RandomNumberGenerator) zum Genieren eines IV für den AES Algorithmus sowie Erstellen eines 256 Bit langen Schlüssels Quazar Crypt Libary DLL Abbildung 7.2.: Quazar Crypt Libary DLL Klassendiagramm Diese DLL bietet über extern deklarierte C-Funktionen Zugriff auf die C++ QCryptLib an. Dieses ist vor allem für eine Verwendung der Sprache C# nötig. Bei Verwendung von C++ kann die Libary direkt eingebunden werden. Der Umweg über diese DLL ist in diesem Fall 66

74 7. Umsetzung und Implementierung nicht nötig. Die Abbildung 7.2 zeigt diese exportierten Funktionen sowie die Deklaration von zwei Handles, die für den Zugriff auf einige dieser Funktionen nötig sind. Zum Erstellen und Zerstören dieser Handles werden Create- und Destroy-Funktionen bereitgestellt C# Quazar Crypt Libary Abbildung 7.3.: Klassendiagramm der C# Quazar Crypt Libary Diese Libary stellt in C# Funktionen der in C++ geschrieben QCryptLib zur Verfügung. Diese Funktionen sind nahezu identisch mit der C++ Libary. Wie aus Abbildung 7.3 ersichtlich, gibt es kein Äquivalent für die Konvertierungsfunktionen. Diese werden in C# nicht benötigt Umsetzung des Proxy Management Dienstes und des Proxy Watch/Start Dienstes Der Proxy Management Dienst und der Proxy Watch/Start Dienst wurden in C# geschrieben, da bereits ein firmeninternes System besteht, um Windows Dienste zu erstellen. Dieses stellt auch kein Problem hinsichtlich der Migration des bestehenden Client/Presenter System auf ein Linux Betriebssystem dar, denn der C# Code des Proxy-WSD kann problemlos in Java oder C++ übersetzt werden. Dafür sind nur minimale Anpassungen nötig. Diese Anpassungen bestehen vor allem im Erstellen eines HTTP-Listeners Äquivalents unter Linux. 67

75 7. Umsetzung und Implementierung Proxy Management Dienst Abbildung 7.4.: Klassendiagramm des Proxy Management Dienst Der Proxy-MD ist eine DLL, welche von einem ServiceHost geladen und gestartet wird. Außer 68

76 7. Umsetzung und Implementierung dieser DLL wird auch ein HTTP-Dispatcher Task gestartet, welcher die HTTP-Aufrufe auf einem Port an den Proxy-MD Task weiterleitet. Die in Abbildung 7.4 dargestellten Klassen haben folgende Funktionen: ProxyAppTaskConfig: Liest die Konfiguration des Tasks aus einer XML-Datei. Des Weiteren enthält sie eine Referenz auf ein Interface des Typs IDataProvider. IDataProvider: Abstrahiert den Zugriff auf die benötigten Daten. Dieses ist nötig, um das Proxy-System portabel hinsichtlich der Arbeit mit unterschiedlichen Datenbankdesigns und Datenquellen zu halten. ProxyServer: Diese Klasse stellt sämtliche Daten, welche für die Verwaltung eines VPN-Server notwendig sind, zur Verfügung. Des Weiteren werden diese Daten über klassenspezifische Funktionen aktualisiert. Die Verbindungen des VPN-Servers stehen zusammengefasst in einer ProxyServerConnection Klasse ebenfalls zur Verfügung. ProxyAppTask: Den eigentliche Ablauf sowie die Aufgaben des Tasks regelt diese Klasse. Es gibt für den ServiceHost Einsprungpunkte, um den Task zu starten bzw. zu beenden. Ebenso ist solch ein Punkt für den HTTP-Dispatcher Dienst vorhanden. 69

77 7. Umsetzung und Implementierung Beispiel eines IDataProviders Abbildung 7.5.: Beispiel eines IDataProviders Eine beispielhafte Implementierung des Interface vom Typ IDataProvider ist in Abbildung 7.5 dargestellt. Diese Implementierung übernimmt den Zugriff auf eine bestehende Datenbank, wie z.b. die Datenbank des ShowTime-Systems. Der Proxy-MD bekommt auf diesem Wege eine Klasse in seiner Konfiguration übergeben und lädt diese, wie der Service Host, beim Starten dynamisch nach. 70

78 7. Umsetzung und Implementierung Proxy Watch/Start Dienst Abbildung 7.6.: Klassendiagramm des Proxy Watch/Start Dienstes Der Proxy-WSD ist ebenso wie der Proxy-MD eine DLL für einen Service Host. In Abbildung 7.6 sind folgende zwei Klassen zu erkennen: ProxyManagementTaskConfig: Repräsentiert die Konfiguration des Proxy-WSD. ProxyManagementTask: Enthält die Business Logik. Wie beim Proxy-MD wird auch hier ein HTTP-Dispatcher Task verwendet. Der Proxy-WSD reagiert nur auf ein Kommando, welches einen bestehenden VPN-Proxy stoppt und einen neuen Anmeldevorgang beim Proxy-MD startet Umsetzung des VPN-Proxys Der VPN-Proxy wurde komplett in C++ unter Verwendung der boost Libaray, der qstd10 Libary sowie der QCrypt Libary geschrieben. 71

79 7. Umsetzung und Implementierung VPN Proxy Komponenten Listener Abbildung 7.7.: Klassendiagramm des Listeners In Abbildung 7.7 ist der implementierte Listener dargestellt. Diese enthält unter anderem einen WorkerType, welcher definiert, ob ein Worker mit einem Protokollparser gestartet werden soll sowie ein Interface vom Typ ICallBack. Bei einer eingehenden Verbindung wird dem ICallBack-Empfänger durch Funktionsaufruf ein Callback mitgeteilt. Jeder Listener läuft in einem separaten Thread. 72

80 7. Umsetzung und Implementierung Socks5 Abbildung 7.8.: Klassendiagramm der Implementierung des Socks5-Protokolls Die Klassen Socks5Factory und Socks5Handler, welche in Abbildung 7.8 dargestellt sind, implementieren das Socks5-Protokoll. Der Socks5Handler ist die Implementierung der in Punkt 5.5 erläuterten Komponente. Diese Klasse übernimmt damit die komplette Verwaltung des Socks5-Protokolls. Die Socks5HandlerFactory Klasse wird einem Listener mit dem Wert Socks5Listener des ListenerTypes Enumeration (Enum) als Callback Empfänger übergeben. Bei jedem eingehenden Callback eines Listeners wird ein neuer Socks5Handler erstellt, welcher nur diese Verbindung verwaltet. Beide Klassen implementieren das ICallBack-Interface und besitzen einen Empfänger für Callbacks. Bei der Socks5Handler-Klasse ist dieses eine Socks5HandlerFactory-Klasse. 73

81 7. Umsetzung und Implementierung Management / Mapper Abbildung 7.9.: Klassendiagramm der Management Komponente mit integrierter Mapper- Komponente Die in Abbildung 7.9 dargestellten Klassen repräsentieren die Management Komponente mit integriertem Mapper. In diesem Diagramm ist die MainThread-Klasse der Hauptbestandteil. Diese Klasse implementiert das ICallBack-Interface sowie indirekt über die QThread- Klasse das IQThread-Interface. Der Mapper verbirgt sich in der MainThread-Klasse unter der Funktion handleconnectioncallback. Wenn von einem Listener ein Callback erzeugt 74

82 7. Umsetzung und Implementierung wird, übersetzt die MainThread-Klasse die Ziel IP-Adresse der Verbindung zu einer ID. Bei einer Connection von einem Mapper muss ein anderer Callback erzeugt werden. In der MainThread-Klasse wird für das Behandeln von einigen Callbacks, z.b. bei einer Connection, ein eigener Thread gestartet. Bei anderen Callbacks, z.b. der Anfrage nach einem Listener, erledigt der Thread, welcher die Callback-Funktion aufgerufen hat, die Abarbeitung des Callbacks selbst. 75

83 7. Umsetzung und Implementierung Communication-Handler Abbildung 7.10.: Klassendiagramm des Communication-Handlers sowie der für Server- und Client- Modus benötigten Implementierungen In Abbildung 7.10 ist zu erkennen, dass die abstrakte Klasse Communication-Handler das Herzstück dieser Komponente ist. Diese Klasse implementiert das ICallBack-Interface sowie das ITimerExpired-Interface. Diese Klasse bekommt im Server-Modus eine Verbindung zu 76

84 7. Umsetzung und Implementierung einem VPN-Client übergeben. Im Client-Modus erstellt diese Klasse eine Verbindung zum VPN-Server. Es existieren mindestens drei Threads in dieser Klasse: Read Thread: Dieser baut im Client-Modus die Verbindung zum VPN-Server auf und sendet die erste Nachricht für das Anmeldeprotokoll. Ansonsten empfängt dieser Thread durch die Verbindung zum VPN-Proxy Nachrichten. Diese werden entschlüsselt und analysiert. Im Anschluss an die Analyse wird, je nach Aufwand der mit dieser Nachricht verbunden Reaktion, diese selbst oder in einem separaten Thread ausgeführt. Callback Thread: Callbacks, die über im ICallback-Interface definierten Funktionen empfangen werden, werden in einer Liste zwischengespeichert und im Anschluss durch diesen Thread abgearbeitet. Damit sind die im ICallBack-Interface definierten Funktionen nicht blockierend solange kein Rückgabewert erwartet wird. Wie beim Read Thread wird, je nach Aufwand des Callbacks, die Ausführung durch diesen Thread oder einen separaten Thread erledigt. QProxyTimer: Dieser läuft ab, wenn auf eine gesendete Nachricht in einer gewissen Zeit keine Reaktion erfolgt. In diesem Fall wird die Funktion TimerExpired des ITimerExpired-Interfaces aufgerufen. Für die beiden Betriebsmodi, Client und Server, existieren zwei Implementierungen der Klasse vom Typ Communication-Handler. Diese beiden implementieren die für einen Modus spezifischen Managementprotokolle: Der CommunicationHandlerClient wird für den Betrieb als VPN-Client verwendet. Diese Klasse implementiert nur die entsprechenden Managementprotokolle. Der CommunicationHandlerServer wird für den Betrieb als VPN-Server verwendet. Innerhalb dieser Klasse existiert eine private Implementierung eines QProxyTimers. Diese Implementierung, CHSPingTimer genannt, sendet beim Auslösen eine Ping Nachricht an den VPN-Client. Dieser Timer ist ein Endlostimer. Die CommunicationHandlerServer- Klasse implementiert des Weiteren die entsprechenden Managementprotokolle. In der Abbildung 7.10 ist zusätzlich eine CHWaitForFinishTimer-Klasse dargestellt. Dieser Timer wird verwendet, um einen Timeout auszulösen, falls eine Nachricht vom Typ Finish für eine Verbindung ausbleibt. 77

85 7. Umsetzung und Implementierung Worker Abbildung 7.11.: Klassendiagramm der Worker-Komponenten-Implementierung 78

86 7. Umsetzung und Implementierung In der Abbildung 7.11 ist zu erkennen, dass die Klasse WorkerThread, wie die Klasse Communication-Handler (siehe ), die beiden Interfaces ITimerExpired und ICall- Back implementiert. In dieser Klasse befinden sich die im Konzept unter Kapitel erläuterten drei Threads. Die Klassen WorkerThreadNormal und WorkerThreadFTP sind Protokollparser. WorkerThreadNormal ist ein dummy Parser. Daten, die zum Analysieren übergeben wurden, werden direkt ohne Änderung zurückgegeben. WorkerThreadFTP ist ein Parser, welcher bei FTP-Verbindungen eingesetzt wird. Die Funktionsweise wurde in Abschnitt unter dem Punkt Besonderheiten bei FTP- Verbindungen erläutert. 79

87 8. Testen und Auswerten des Systems 8.1. Funktionstest Proxy Komponenten Die Funktion der Komponenten des VPN-Systems wurden während eines Probebetriebs getestet. Für diesen Testbetrieb wurde ein System bestehend aus vier Rechnern verwendet. Auf zwei dieser Rechner wurde der VPN-Client betrieben, während auf den anderen beiden Rechnern jeweils der Proxy-MD bzw. der VPN-Server betrieben wurde. Durch manuelles Eingreifen in dieses Testsystem wurden unterschiedliche Situationen simuliert, z.b. Neustart des Proxy-MD. Das Zusammenspiel und die Sicherstellung der Funktion des Proxy-Systems wurde auf diese Weise getestet. Ebenso wurde regelmäßig die in Anspruchnahme von Betriebssystemressourcen, z.b. Threads und Arbeitsspeicher, überwacht, um evtl. vorhandene leaks zu erkennen. Des Weiteren wurden auf den Rechnern, auf welchen der Proxy-MD oder der VPN-Server ausgeführt wird, der Netzwerkverkehr mit dem Programm Wireshark, welches für die Analyse von Netzwerk-Kommunikationsverbindungen erstellt wurde, überwacht. Durch diese Überwachung konnte verifiziert werden, dass eine Verschlüsselung der Kommunikation der einzelnen Komponenten vorhanden ist. 80

88 8. Testen und Auswerten des Systems VPN-Proxy Abbildung 8.1.: Funktion des Testprogramms Zusätzlich zu dem Funktionstest wurde der VPN-Proxy durch ein separates Testprogramm in 81

89 8. Testen und Auswerten des Systems definierten Situationen auf Zuverlässigkeit und Fehlertoleranz getestet. Dieses Testprogramm besteht aus diversen Testsuiten, welche den definierten Zustand des VPN-Proxys beschreiben. Auf diesen Testsuiten werden unterschiedliche Testfälle angewendet. Nach jedem Ausführen eines Testfalls muss der in der Testsuite definierte Zustand von neuem hergestellt werden. In Abbildung 8.1 wird die Funktionsweise des Testprogramms dargestellt. Der VPN-Proxy wird grob in vier Kategorien getestet: Anmeldung Verbindungsaufbau von einem anderen VPN-Proxy Verbindungsaufbau von einer externen Anwendung Testen einer bestehenden Verbindung Das Testprogramm kann vollautomatisch ausgeführt werden. Ebenso ist es möglich das Testprogramm in einem manuellen Modus, bei welchem nach dem Ausführen einer Testsuite ein Benutzereingriff für die Fortführung des Programms nötig ist, ausgeführt werden. Dieser manuelle Modus ist dafür gedacht, den Zustand des VPN-Proxys nach jeder Testsuite überprüfen zu können. Die Ausführung des Testprogramms benötigt einige Zeit. Diese ist von der Konfiguration des VPN-Proxys abhängig, da unter anderem auch die Timeouts überprüft werden, was bei einer hohen Einstellung in der Konfiguration des VPN-Proxy durchaus mehrere Minuten dauern kann. Eine detaillierte Auflistung der vorhanden Testsuiten und der darin enthaltenen Testfälle ist im Anhang B zu finden Auswertung der Sicherheit des Proxy-Systems Sicherheit der Kommuniktaion des Proxy-Systems Die Sicherheit der Kommunikation der Komponenten des Proxy-System wird durch den Einsatz von sicheren Verschlüsselungsalgorithmen erreicht. Die eingesetzten Algorithmen werden vom BSI empfohlen und gelten aktuell als sicher. Um Fehler zu vermeiden, wurden die eingesetzten Verschlüsselungsalgorithmen nicht selbst implementiert. Es wurden offene Libaries bzw. Bestandteile des.net Frameworks verwendet. Das Vorhandensein einer Verschlüsselung wurde mit dem Programm Wireshark überprüft. In Abbildung 8.2 und 8.3 sind Auszüge aus der Analyse der Netzwerkkommunikation mit Wireshark dargestellt. Abbildung 8.2 zeigt eine FTP-Verbindung ohne Einsatz von VPN-Proxys. Abbildung 8.3 zeigt ebenfalls eine FTP- Verbindung, allerdings unter Verwendung von VPN-Proxys. Aus diesen beiden Abbildungen 82

90 8. Testen und Auswerten des Systems geht hervor, dass die Kommunikation unter Verwendung von VPN-Proxys verschlüsselt wird. Abbildung 8.2.: Auszug aus der Aufzeichnung der Netzwerkkommunikation mit Wireshark bei einer FTP-Übertragung ohne Verwendung des VPN-Proxys Abbildung 8.3.: Auszug aus der Aufzeichnung der Netzwerkkommunikation mit Wireshark bei einer FTP-Übertragung unter Verwendung des VPN-Proxys Sicherheit der Komponenten des Proxy-Systems Die einzig effektiven Angriffspunkte des Proxy-Systems sind der VPN-Server sowie der Proxy-MD, da diese beiden Komponenten direkt von außen zu erreichen sind. Diese Komponenten müssen im Rahmen eines Sicherheitsaudit von einer externen Firma überprüft werden. Diese Überprüfung muss vor dem produktiven Einsatz erfolgen. Im Rahmen dieser Bachelorthesis ist kein Sicherheitsaudit vorgenommen worden. 83

91 9. Zusammenfassung Im Rahmen dieser Bachelorarbeit wurde ein Proxy-System für die Firma Quazar Softwareentwicklungsgesellschaft mbh geschaffen, welches vollkommen transparent in jedes bestehende System integriert werden kann. Durch die Verwendung des Proxy-Systems müssen bestehende Systeme, welche auf feste IP-Adressen angewiesen sind, nicht angepasst werden, um im Internet betrieben werden zu können. Das Proxy-System übernimmt für diese Systeme das Übersetzen von statischen zu dynamischen IP-Adressen. Ebenso wird durch das Proxy-System die Sicherheit und Vertrauenswürdigkeit der Kommunikation gewährleistet. Das Proxy-System kann über ein Multiaddressinterface ein LAN simulieren. In diesem Fall müssen sich die VPN-Clients am VPN-Server anmelden. Diese Anmeldeverbindung wird daraufhin aufrechterhalten und als Managementverbindung für die Steuerung und Kontrolle des Proxy-Systems verwendet. Für diese Simulation muss vorher festgelegt werden, welche IP-Adresse zu welchem VPN-Client gehört. Mit dieser LAN Simulation ist das transparente Einbinden in ein bestehendes System ohne Probleme möglich. Des Weiteren unterstützt das Proxy-System das Socks5-Protokoll. Mit diesem ist es möglich auf die Simulation eines LANs zu verzichten und damit auch auf ein Multiadressinterface. Für das Socks5-Protokoll müssen dennoch, um eine Verschlüsselung zu ermöglichen, die VPN-Clients bekannt sein. Die Verschlüsselung und die Verifikation der Vertrauenswürdigkeit der Kommunikation von Anwendungen ist ebenfalls Aufgabe des Proxy-Systems. Die Anwendungen, welche unter Verwendung des Proxy-Systems kommunizieren, müssen keine separaten Maßnahmen zur Sicherung ihrer Kommunikation ergreifen. Die Vertrauenswürdigkeit der Kommunikation wird vom Proxy-System durch einen Abgleich mit hinterlegten Daten bei der Anmeldung eines VPN-Clients an das System gewährleistet. Der Anmeldeserver setzt für seine Verifikation gegenüber den VPN-Clients ein Zertifikat ein. Mit diesen Methoden können sich Client und Server gegenseitig verifizieren. Die Verschlüsselung der Daten wird mit dem AES realisiert. Nach dem Austausch der privaten Schlüssel über das ECDH Verfahren und dem Senden der Initialisierungsnachricht des VPN-Clients an den VPN-Server findet die Kommunikation zwischen den VPN-Client und VPN-Server ausschließlich verschlüsselt statt. Die Daten werden durch das eingesetzte Protokoll und die Verschlüsselung vor Manipulation geschützt. Da die 84

92 9. Zusammenfassung Daten nur verschlüsselt manipuliert werden können, wird beim Entschlüsseln und Auswerten der empfangen Daten eine Verletzung des Protokolls festgestellt Mögliche Erweiterungen Das Proxy-System bietet Potenzial für diverse Erweiterungen. Eine mögliche Erweiterung wäre es, dem Proxy-MD weitere Schnittstellen zur Abfrage von Informationen oder zur Steuerung hinzu zu fügen. Mit diesen Schnittellen kann einem System, welches das Proxy-System verwenden möchte, die Möglichkeit geben das Proxy-System effizienter zu verwenden, wie z.b. alle aktuell angemeldeten Clients abzufragen um einen Onlinestatus darzustellen. Eine andere mögliche Erweiterung wäre es, dem VPN-Client die Möglichkeit zu geben gegenüber anderen VPN-Clients als VPN-Server aufzutreten. Dieses würde zu einer Entlastung der VPN-Server beitragen. 85

93 A. Implementierung A.1. VPN Proxy Helfer Klassen In diesem Abschnitt werden die unterschiedlichen Helferklassen, welche während der Implementierung der einzelnen Komponenten entstanden sind, erläutert. 86

94 A. Implementierung AppTask-Klassen Abbildung A.1.: Klassendiagramm mit den Hilfsklassen für die Kommunikation mit einem Task eines Service Hosts In Abbildung A.1 werden die Klassen, welche die Kommunikation mit dem Proxy-MD vereinfachen, dargestellt. Aus dieser Abbildung wird ersichtlich, dass für das Empfangen und Versenden von Nachrichten vom bzw. zum Proxy-MD zwei unterschiedliche Klassen existieren. Die Klasse AppTaskResult ist für das Senden zuständig, während die Klasse AppTaskCommand für das Empfangen zuständig ist. Beide Klassen enthalten einen AESPtr für die Verbzw. Entschlüsselung. 87

95 A. Implementierung Callback Parameter Klasse Abbildung A.2.: Klassendiagramm des Callback-Interfaces In Abbildung A.2 wird das ICallBack-Interface dargestellt. Dieses Interface definiert die Funktionen, über welche eine Klasse Callbacks empfangen kann. Allen Funktionen des ICallBack- Interfaces wird ein CallBackType als Parameter übergeben. Die CallBack-Funktionen haben als weitere Parameter Objekte vom Typ CallBackParam, diese sind entweder als Input oder Output Parameter definiert. Wie in Abbildung A.2 darüber hinaus zu erkennen ist, besteht die CallBackParam-Klasse aus diversen Propertys und entsprechenden Konstruktoren. Diese Klasse wird als Parameter für das ICallBack-Interface verwendet. 88

96 A. Implementierung Konfiguration Abbildung A.3.: Klassendiagramm der Konfiguration Die Konfiguration des VPN-Proxys ist in Abbildung A.3 dargestellt. Diese Klasse wird mit Hilfe einer Konfigurationsdatei erstellt. Für die Konfiguration des VPN-Client oder des VPN-Server wird die Basisklasse Config_Main um spezifische Parameter erweitert. 89

97 A. Implementierung Data abstraction layer Abbildung A.4.: Klassendiagramm der DAL Der Data abstraction Layer (DAL) wird in Abbildung A.4 dargestellt. Diese Klasse abstrahiert für den VPN-Proxy den Zugriff auf die benötigten Daten. Mit dieser Abstraktion ist es möglich, unterschiedliche Datenquellen zu verwenden ohne Teile des VPN-Proxys zu verändern. 90

98 A. Implementierung Message-Klasse Abbildung A.5.: Klassendiagramm der Message-Klasse In Abbildung A.5 wird eine Message-Klasse für das Managementprotokoll dargestellt. Diese Klasse kann aus den von einem VPN-Proxy empfangen und entschlüsselten Daten erstellt werden und bietet definierte Schnittstellen zu dem Inhalt der empfangenen Daten. Ebenfalls ist es möglich, eine neue Instanz der Message-Klasse zu erstellen, ohne Daten von einem VPN-Proxy empfangen zu haben. Dieses wird verwendet, um Daten zum Versenden an einen VPN-Proxy zu erstellen. In diesem Fall übernimmt die Message-Klasse das Konvertieren in die, für das Senden benötigte, Datenstruktur. Allerdings übernimmt diese Klasse nicht die Ver- bzw. Entschlüsselung der generierten bzw. empfangenen Daten. Dies geschieht an anderer Stelle. 91

99 A. Implementierung In Abbildung A.5 ist ebenfalls der Enum MessageCommands dargestellt. Dieser definiert alle bekannten Kommandos, welche über das Managementprotokoll ausgetauscht werden, mit Ausnahme des Wertes SIZE_OF_ENUM. Dieser wird ausschließlich dazu verwendet, die Anzahl der in der Enum definierten Werte zu erhalten. Timer-Klasse Abbildung A.6.: Klassendiagramm der Timer-Klasse In Abbildung A.6 wird die im VPN-Proxy verwendete QProxyTimer-Klasse dargestellt. Dieser Timer kapselt einen boost::asio::deadline_timer. Mit der QProxyTimer-Klasse ist es möglich, einen Deadlinetimer zu erstellen, welcher nur einmalig auslöst. Ebenso ist es möglich, einen endlosen Timer zu erstellen, welcher alle X Zeiteinheiten auslöst. Nachdem der Timer ausgelöst 92

100 A. Implementierung hat, wird in dem ITimerExpired-Interface die Funktion TimerExpired aufgerufen. Dem QProxyTimer wird beim Erstellen eine Instanz des ITimerExpired-Interfaces übergeben. In der Abbildung A.6 ist des Weiteren dargestellt, dass der QProxyTimer das ICallback-Interface implementiert. Durch dieses Interface ist es dem QProxyTimer möglich, CallBacks zu empfangen und zu verarbeiten. SocketObj-Klasse Abbildung A.7.: Klassendiagramm der SocketObj-Klasse 93

101 A. Implementierung Diese in Abbildung A.7 dargestellte Klasse beinhaltet die für einen Verbindungsaufbau relevanten Daten, wie z.b. den WorkerType oder den SocketPointer. Diese Informationen werden in einer Instanz der SocketObj-Klasse zusammengefasst. Dieses Objekt stellt getter und setter für die hinterlegten Daten zur Verfügung. Des Weiteren wird es für den Aufbau einer Verbindung verwendet. In der Abbildung A.7 sind außerdem noch folgende Typedefs dargestellt: SocketObjPointer repräsentiert einen std::shared_ptr, welcher ein SocketObj beinhaltet. SocketObjPair repräsentiert ein std::pair, welches aus zwei SocketObjPointern besteht. Dieser Typedef repräsentiert die beiden Seiten einer durch den VPN-Proxy geleiteten Verbindung zweier Anwendungen. 94

102 A. Implementierung Sonstige Helfer Klasse Abbildung A.8.: Klassendiagramm der unter Sonstige zusammengefassten Klassen In Abbildung A.8 sind folgende Klassen dargestellt: XmlHelper: Diese Klasse konvertiert einen boost::property_tree, welcher für das Erstellen und Bearbeiten einer XML-Datei verwendet wird in einen String. DateTime: Diese Klasse generiert einen Zeitstempel der aktuellen Uhrzeit. Das Format dieses Zeitstempels ist folgendes: CCYYMMDDTHHmmSS, z.b. wird aus dem :40: T