masterthesis/MA-Inhalt.tex

\chapter{Einleitung} \label{cpt:introduction}
Die Menge der noch verfügbaren IPv4-Adressen neigt sich dem Ende zu.
Laut Angaben des RIPE NCC\footnote{RIPE Network Coordination Centre} vom Juni 2018 sind noch ungefähr 8,63 Millionen IPv4-Adressen verfügbar\footnote{\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph}, abgerufen am 03.06.2018}.
Das entspricht etwa der Hälfte der nutzbaren Host-Adressen eines \texttt{/8}-Blocks.
Betrachtet man die Vergabegeschwindigkeit von IPv4-Adressen aus den letzten 3 Jahren, so könnte man den Zeitpunkt der Erschöpfung von IPv4-Adressen zwischen 2019 und 2021 vermuten\footnote{\url{https://ipv4.potaroo.net/}, abgerufen am 03.06.2018}.

Vor diesem Hintergrund findet die Verwendung von IPv6 eine zunehmende Verbreitung als Nachfolger von IPv4:
Immer mehr Internetdienste können über IPv6 erreicht werden, und auch die Internetanbieter stellen ihren Kunden IPv6-fähige Internetanschlüsse zur Verfügung.
Der Anteil von Suchanfragen, die über IPv6 an Google gestellt wurden, hat von 5,84\% am 1. Januar 2015 auf 21,11\% am 1. Juni 2018 zugenommen\footnote{\url{https://www.google.com/intl/en/ipv6/statistics.html}, abgerufen am 03.06.2018}.
Am AMS-IX\footnote{Amsterdam Internet Exchange}, dem Internet-Austauschpunkt in Amsterdam, hat sich der Durchfluss von IPv6-Verkehr in den letzten 12 Monaten im Durchschnitt von etwa 55 Gbit/s im August 2017 auf etwa 85 Gbit/s im Mai 2018 gesteigert\footnote{\url{https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic},\\abgerufen am 03.06.2018}.

Auch das Netz der Abteilung Informatik an der Hochschule Hannover ist Vorreiter in der Erprobung von IPv6: Seit Anfang 2015 ist das Netz schon über IPv6 an das Internet angebunden.
Damit ist die Voraussetzung gegeben, um Netzwerkgeräte für IPV6 zu konfigurieren und bestehende Netzwerkdienste auch über IPv6 anzubieten.

Mitarbeitern und Studenten der Abteilung Informatik steht ein VPN-Dienst zur Ver\-fü\-gung, um Zugang in das Netz der Abteilung aus dem Internet heraus zu erhalten.
Bisher ist dieser Dienst nur über IPv4 erreichbar und ermöglicht den Zugang in das Abteilungsnetz ausschließlich über IPv4.
\newpage
Im Rahmen dieser Masterarbeit soll ein neuer, IPv6-fähiger VPN-Dienst konzipiert werden, der die Idee des bisherigen IPv4-VPN-Dienst aufgreift.
Dafür wird zunächst die Netzarchitektur der Abteilung Informatik inklusive dem Firewallkonzept vorgestellt.
Anschließend werden alle Rahmenbedingungen und Anforderungen erfasst, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden sollen.
In der darauf folgenden Konzeptphase werden zunächst grundlegende, lösungsunabhängige Entscheidungen getroffen, auf Basis derer dann eine technischen Lösung ausgewählt wird.
\todo{Danach geht es weiter mit der Planung der konkreten Lösung, der Installation und der Dokumentation.}


\chapter{Netzarchitektur der Abteilung Informatik} \label{cpt:netarchitecture}
Das Netz der Abteilung Informatik wird durch eine Firewall vom Netz der Hochschule Hannover und dem Internet getrennt.
An der Firewall sind zwei lokale Netze angeschlossen: Die Demilitarisierte Zone (DMZ) und das interne Abteilungsnetz, welches durch einen zentralen Switch in mehrere virtuelle Netze (VLANs) unterteilt wird.
Zusätzlich sind die Netze des Netzwerklabors und des IT-Sicherheitslabors über je einen eigenen Router an den Switch angeschlossen.
Eine Skizze der Netztopologie mit den für diese Arbeit relevanten Teilen ist in Abbildung~\ref{fig:topology_simple} zu sehen.
\begin{figure}[ht]
\centering
% Trim, da diese Grafik als PDF auf DIN A4 vorliegt.
\frame{\includegraphics[trim=75 540 75 75,clip,width=\textwidth]{img/Netzwerktopologie_simpelv2_with_addresses.pdf}}
\caption{Skizze der Netztopologie der Abteilung Informatik}
\label{fig:topology_simple}
\end{figure}

\begin{comment}
In Tabelle~\ref{tab:net_ip_addresses} sind die IPv4- und IPv6-Netzadressen der Netzsegmente aufgeführt.
\todo{Diese Tabelle in Abbildung oben integrieren!}
\begin{table}[ht]
\centering
\caption{IP-Adressbereiche der relevanten Netzsegmente}
\begin{tabular}{ *{3}{|l}| }
\hline
Netzsegment		& IPv4				& IPv6						\\
\hline
Internet			& ---				& ---						\\
DMZ					& 141.71.38.0/24	& 2001:638:614:1780::/64	\\
Mitarbeiter-Netz	& 141.71.30.0/23	& 2001:638:614:1720::/64	\\
Pool-PC-Netz		& 192.168.99.0/24	& 2001:638:614:1721::/64	\\
Labor-Netze 		& 10.3.1.0/24,		& 2001:638:614:1742::/64,	\\
					& 10.0.0.0/24		& 2001:638:614:1741::/64	\\
\hline
\end{tabular}
\label{tab:net_ip_addresses}
\end{table}
\end{comment}


\section{Firewallkonzept} \label{sct:firewall}
Die im Netz der Abteilung Informatik verwendeten LANs und VLANs werden im Firewallkonzept als verschiedene Sicherheitszonen betrachtet.
Im Rahmen dieser Arbeit sind die folgenden Zonen relevant:

\paragraph{Internet}
Das \enquote{Internet} bezeichnet den Bereich außerhalb des Netzes der Abteilung Informatik.
Diese Zone umfasst neben dem Internet auch das Netz der Hochschule Hannover.
Verbindungen in das Internet sind aus allen Zonen außer der DMZ erlaubt.
Verbindungen aus dem Internet werden nur zu Diensten in der DMZ (wie zum Beispiel VPN), sowie zu dem SSH-Dienst im Mitarbeiter-Netz zugelassen.

\paragraph{DMZ}
Von der Abteilung Informatik betriebenen Server stellen in diesem Netz Dienste zur Verfügung, die sowohl innerhalb der Abteilung als auch über das Internet erreichbar sind.
Verbindungen in die DMZ zu Diensten wie VPN sind aus allen anderen Zonen heraus erlaubt.
Verbindungen aus der DMZ in alle anderen Zonen sind verboten, um im Fall eines Sicherheitsvorfalls Angriffe auf alle anderen Zonen zu verhindern.
Eine Ausnahme für dieses Verbot sind Verbindungen vom VPN-Dienst, die in das Mitarbeiter-Netz aufgebaut werden dürfen.

\paragraph{Mitarbeiter-Netz}
Die Rechner aller Mitarbeiter der Abteilung Informatik sind an dieses Netz angeschlossen.
Verbindungen in das Mitarbeiter-Netz aus dem Pool-PC-Netz und den Labor-Netzen sind erlaubt.
Außerdem sind Verbindungen von dem VPN-Dienst aus der DMZ in das Mitarbeiter-Netz erlaubt.
Verbindungen aus dem Mitarbeiter-Netz sind in alle anderen Zonen erlaubt.

\paragraph{Pool-PC-Netz}
Enthält die Rechner aus allen Poolräumen.
Verbindungen in das Pool-PC-Netz sind aus dem Mitarbeiter-Netz und den Labor-Netzen erlaubt.
Verbindungen aus dem Pool-PC-Netz sind in alle anderen Zonen erlaubt.

\paragraph{Labor-Netze}
Das Netzwerklabor und das Labor für IT-Sicherheit werden für diese Arbeit unter der Zone \enquote{Labor-Netze} zusammengefasst.
Verbindungen aus den Labornetzen heraus sind in alle anderen Zonen erlaubt.
Verbindungen in die Labornetze sind aus dem Mitarbeiter-Netz und aus dem Pool-PC-Netz heraus erlaubt.

Ein Überblick der erlaubten Verbindungen zwischen den Sicherheitszonen ist in Tabelle~\ref{tab:firewall_zone_access} skizziert.

\begin{table}[ht]
\centering
\caption{Überblick über erlaubte Verbindungen zwischen Sicherheitszonen}
\begin{tabular}{ *{6}{|l}| }
\hline
 & \multicolumn{5}{c|}{\dots in die Zone \dots} \\
Aus der Zone \dots & Internet & DMZ & Mitarbeiter-Netz & Pool-PC-Netz & Labor-Netze \\
\hline
Internet			& --- 	& erlaubt	& verboten	& verboten	& verboten	\\
DMZ					& verboten	& ---	& verboten	& verboten	& verboten	\\
Mitarbeiter-Netz	& erlaubt	& erlaubt	& ---	& erlaubt	& erlaubt	\\
Pool-PC-Netz		& erlaubt	& erlaubt	& erlaubt	& ---	& erlaubt	\\
Labor-Netze			& erlaubt	& erlaubt	& erlaubt	& erlaubt	& ---	\\
\hline
\end{tabular}
\label{tab:firewall_zone_access}
\end{table}


\chapter{Anforderungsanalyse} \label{cpt:requirements}
In diesem Abschnitt werden alle Anforderungen und Rahmenbedingungen vorgestellt, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden müssen.
Es handelt sich hier um Vorgaben, die im persönlichen Gespräch mit dem Auftraggeber (und Erstprüfer dieser Arbeit) ermittelt wurden.

\begin{enumerate}[label=A\arabic*]
\item \label{req:dualstack} \textbf{Dual-Stack-Betrieb:} Der VPN-Dienst soll aus dem Internet über IPv4 und IPv6 erreichbar sein und auch innerhalb des VPN diese beiden Protokolle anbieten.
\item \label{req:routing} \textbf{VPN-interner Datenverkehr:} Nur die internen Netzbereiche der Abteilung Informatik sollen für Benutzer über das VPN erreichbar sein.
Das betrifft alle Sicherheitszonen außer dem Internet.
\item \label{req:traffic} \textbf{VPN-externer Datenverkehr:} Die Kommunikation zwischen VPN-Client und VPN-Server soll authentisiert und vertraulich stattfinden.
\item \label{req:users} \textbf{Benutzer:} Der VPN-Dienst soll von autorisierten Mitarbeitern und Studenten aus der Abteilung Informatik benutzt werden können.
Die Benutzer des VPN-Dienst sollen durch die Administratoren des VPN-Dienst einfach verwaltet werden können.
\item \label{req:serveros} \textbf{Betrieb des VPN-Servers:} Die Serverkomponente des VPN-Dienst soll auf einer aktuellen Version von Debian (9 oder höher) betrieben werden.
\item \label{req:clientos} \textbf{Betrieb der VPN-Clients:} Die VPN-Clientsoftware soll für aktuelle Versionen gängiger Betriebsysteme zur Verfügung stehen.
Darunter fallen Microsoft Windows 10 (Version 1709 oder höher), Apple MAC OS (ab Version 10.13) und Linux-Distributionen (ab Kernel Version 3.10).
\item \label{req:logging} \textbf{Betriebsprotokoll:} Während des Betrieb des VPN-Dienst sollen keine Daten protokolliert werden, die Rückschlüsse auf das Benutzerverhalten zulassen. Im Rahmen einer laufenden Fehlersuche soll es möglich sein, mehr Daten zu protokollieren.
\item \label{req:finance} \textbf{Finanzieller Rahmen:} Es stehen keine finanziellen Mittel für den Erwerb einer VPN-Lösung zur Verfügung.
\end{enumerate}

Anhand der Anforderungen~\ref{req:dualstack} bis \ref{req:finance} werden vorhandene Programme ermittelt, die sich als Kandidat zur Umsetzung des VPN-Dienstes eignen.
Aufgrund des finanziellen Rahmens (\ref{req:finance}) kommt nur kostenfreie Software in Frage, deren Serverkomponente mit aktuellem Debian (\ref{req:serveros}) kompatibel ist.
Die Clientkomponenten der gesuchten Software müssen unter den aktuellen Betriebsystemen lauffähig sein (\ref{req:clientos}).

Die Vorgabe von vertraulicher und authentisierter Kommunikation zwischen VPN-Client und VPN-Server (\ref{req:traffic}) impliziert, dass die gesuchte Software Algorithmen zum Verschlüsseln und Signieren von Daten verwendet.
Deshalb soll Kerckhoffs' Prinzip bei der Wahl der VPN-Software angewendet werden, indem ausschließlich quelloffene Software berücksichtigt wird.
Weiterhin soll die gesuchte Software IPv4 und IPv6 unterstützen (\ref{req:dualstack}), die Routingtabellen der VPN-Clients (\ref{req:routing}) anpassen können und in Bezug auf Protokollierung (\ref{req:logging}) konfigurierbar sein.


\section{Suche nach VPN-Serversoftware} \label{sct:software_candidates}
Ausgangspunkt für die Suche nach passender VPN-Software ist die Wahl der Serverkomponente: Sie soll quelloffen sein und auf einem Server mit aktuellem Debian eingesetzt werden können.
Deshalb sind die Debian-Paketquellen die erste Anlaufstelle für die Suche.
Durch die Nutzung der Paketquellen ist das Installieren von Sicherheitsaktualisierungen über den Debian-Paketmanager möglich.
Arbeitsschritte wie das Patchen und Kompilieren des Quellcodes, sowie Tests und das Paketieren der Software werden von den Verwaltern der Debian-Pakete ausgeführt.
Die Authentizität der Pakete wird anhand von GPG-Signaturen durch den Paketmanager vor der Installation überprüft\cite{book:debian}[Siehe Kapitel 6.5].

Um den Wartungsaufwand des VPN-Servers zu reduzieren, kann die Installation von Updates durch den Debian-Paketmanager automatisiert werden\cite{book:debian}[Siehe Kapitel 6.7 und 6.8].
Somit muss der Systemadministrator lediglich Upgrades zur nächsthöheren Debian-Version durchführen, da dabei Anpassungen an der Systemkonfiguration notwendig werden.

Im Folgenden werden mögliche Software-Kandidaten aus den Debian-Paketquellen vorgestellt.

\paragraph{Strongswan}
Strongswan\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan},\\zuletzt abgerufen am 18.07.2018} ist eine modular aufgebaute Software, die unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebsystemen lauffähig ist.
Sie kann verwendet werden, um in Kombination mit IPsec-fähigen Betriebsystem-Kerneln ein VPN zwischen zwei Computern auf Basis von IPsec einzurichten.

Mit IPsec können Richtlinien definiert werden, die den Datenverkehr von einem Host zu einem anderen Host betreffen\cite{RFC4301}.


Sie kann über IKEv2\footnote{Internet Key Exchange Protokoll Version 2, definiert in \cite{RFC7296}} authentisiert und verschlüsselt mit einer Gegenstelle kommunizieren.
Dabei werden mit der Gegenstelle Schlüssel und Konfigurationsparameter ausgehandelt beziehungsweise ausgetauscht, anhand derer im Betriebsystem-Kernel IPsec-Verbindungen konfiguriert werden.
Die Verarbeitung des IPsec-Da\-ten\-ver\-kehrs über die Protokolle AH oder ESP wird über den IPsec-Stack im Kernel abgewickelt.

Transportmodus vs Tunnelmodus?

* Vertraulichkeit, Integrität übertragener Daten, Zugriffskontrolle und Authentisierung
* Security Policy Database (stateless) enthält "grundsätzliche" Konfiguration
* Security Association Database (stateful) enthält die einzelnen Security Associations (SA), quasi die einzelnen Verbindungen


Das Protokoll \enquote{IP Authentication Header} (AH) ist in \cite{RFC4302} definiert und ermöglicht den Versand von authentisierbaren Paketen an eine Gegenstelle.
Bestimmte Felder ... werden dabei signiert und können so nach Empfang authentisiert werden.

Das Protokoll \enquote{IP Encapsulating Security Payload} (ESP) ist in \cite{RFC4303} definiert und ermöglicht den Versand von vertraulichen Paketen an eine Gegenstelle.
Nach Empfang werden die Pakete entschlüsselt.


\paragraph{OpenVPN}
Hier wird OpenVPN beschrieben.


\paragraph{Auswahl einer VPN-Software}
Vorzüge von OpenVPN und IPsec im Vergleich.

Begründung der Auswahl.


\paragraph{Erstellung eines Konzepts für die Benutzerverwaltung}
Anforderungen:
* Soll möglichst "einfach" sein
* Möglichst wenig personenbezogene Daten verarbeiten oder speichern
* Zielgruppe des Dienstes sind Beschäftigte und Studenten der Abteilung Informatik (Größenordnung: 20-200 Personen)
* Studenten sollen immer für ein (laufendes?) Semester Zugriff erhalten

Möglichkeiten: User+Passwort oder SSL-Zertifikate

Zertifikate:
* klare Laufzeit
* kann nicht erraten werden
* Können schlimmstenfalls via CRL gesperrt werden
* Verschlüsselung des privaten Schlüssels verhindert Missbrauch bei gestohlenen Daten (Cert+Key)
* Einrichtung von Benutzern geschieht durch Signatur eines Zertifikatsantrags
* Erfolgreich gestohlenes Zertifikat kann nur für VPN-Dienst genutzt werden

Benutzer/Passwort:
* Bequemlichkeit: Kann über existierende Infrastruktur abgewickelt werden (Hochschulaccount)
* Einrichung von Benutzern kann quasi vollautomatisch oder durch eine Whitelist geschehen
* Benutzerkonten werden automatisch deaktiviert
* Nur Benutzername+Passwort reichen aus, gestohlene Zugangsdaten bedeuten großes Schadenspotential
* Zugangsdaten müssen zur Authentisierung an entsprechende Dienste "durchgereicht" werden, daher größere Angriffsfläche

Gewinner: Zertifikate


\paragraph{Einrichtung einer SSL-CA mit EasyRSA}
Kurz: EasyRSA2.2.3 aus Debian vs EasyRSA3.x direkt von Github - Vorteile/Nachteile
Danach: Wie funktioniert die CA mit EasyRSA?
--> Dokumente: Benutzerdokumentation, CA-Admin-Dokumentation, Serverdokumentation


\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
* IP-Adressen und Routing geklärt
* Konzepte und Konfiguration des IT-Teams in das Konzept integriert
* virtuelle IP als Alias auf Netzwerkkarte, über die der Dienst angestoßen wird
* Voraussichtlich separate Maschine zur Verwaltung der CA
* Koordination Firewallregeln
** Dienst bietet nur OpenVPN udp/1194 (Internetoffen) und SSH tcp/22 (mal gucken, wie offen das ist)
** lokale Firewall auf VPN-Server verhindert Zugriffe vom VPN in die DMZ
* Koordination Routing
** IPv6-Bereich für VPN-Clients wird an virtuelle IPv6-Adresse des VPN-Dienstes geroutet -> manuelles Failover möglich
** IPv4: VPN-Clients bekommen IP-Adressen aus 10.2.0.0/16 Block, für IPv4 wird auf NAT zurückgegriffen


\paragraph{Erstellung eines Betriebskonzept}
TODO

\chapter{Fazit}
Wie ist es gelaufen, gab es Probleme? Wie macht sich OpenVPN als Lösung?
Gibt es vielleicht Szenarien, in denen sich IPsec doch lohnt?
Ja - eventuell. Sehr große Enterprise-Umgebungen, in denen die personellen Ressourcen für die korrekte Konfiguration vorhanden sind.
Da kann man in homogenen Umgebungen sinnvolle IPsec-Konfigurationen auf hunderten oder tausenden Geräte einrichten.


\section{Ausblick}
Es gibt da noch etwas mit dem schönen Namen Wireguard. Mit gewollt geringer Komplexität und einem aktuellen Umfang von ca. 4000 Zeilen Code ist es eine würdige Alternative zu IPsec.
Auch OpenVPN in Version 3 ist schon in der Beta - das könnte man auch im Auge behalten.


\chapter*{Anhang}
\addcontentsline{toc}{chapter}{Anhang}

\begin{figure*}[ht]
\centering
\frame{\includegraphics[trim=0 120 0 20,clip,width=\textwidth]{img/Abt-I-Architektur-2018.pdf}}
\caption{Dokumentation Netzarchitektur der Abteilung Informatik}
\label{fig:topology_provided_full}
\end{figure*}

% Input the existing documentation of the CA which may also be compiled seperately (soon(tm))
\input{./Dokumentation-CA.tex}