diff --git a/MA-Erklaerung.tex b/MA-Erklaerung.tex new file mode 100644 index 0000000..29a2ae5 --- /dev/null +++ b/MA-Erklaerung.tex @@ -0,0 +1,30 @@ +% Seite mit Personen und Selbstständigkeitserklärung +\newpage \thispagestyle{empty} +\begin{tabular}{ll} +{\bfseries\sffamily Autor} & Jan Philipp Timme \\ + & Matrikelnummer 1433117 \\ + & Abteilung Informatik, Fakultät IV \\ + & Hochschule Hannover \\ + & jan.philipp@timme.it \\[5ex] +{\bfseries\sffamily Erstprüfer} & Prof. Dr. Stefan Wohlfeil \\ + & Abteilung Informatik, Fakultät IV \\ + & Hochschule Hannover \\ + & stefan.wohlfeil@hs-hannover.de \\[5ex] +{\bfseries\sffamily Zweitprüfer} & N.N. \\ + & Abteilung Informatik, Fakultät IV \\ + & Hochschule Hannover \\ + & N.N@hs-hannover.de +\end{tabular} + +\vfill + +% fett und zentriert in der Minipage +\begin{center} \sffamily\bfseries Selbständigkeitserklärung \end{center} + +Hiermit erkläre ich, dass ich die eingereichte Masterarbeit +selbständig und ohne fremde Hilfe verfasst, andere als die von mir angegebenen Quellen +und Hilfsmittel nicht benutzt und die den benutzten Werken wörtlich oder +inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. +\vspace*{7ex} + +Hannover, den \today \hfill Unterschrift \ No newline at end of file diff --git a/MA-Inhalt.tex b/MA-Inhalt.tex new file mode 100644 index 0000000..3eda996 --- /dev/null +++ b/MA-Inhalt.tex @@ -0,0 +1,260 @@ +\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} diff --git a/MA-Titelseite.tex b/MA-Titelseite.tex new file mode 100644 index 0000000..c2db980 --- /dev/null +++ b/MA-Titelseite.tex @@ -0,0 +1,19 @@ +% Titelseite +\thispagestyle{empty} +\includegraphics[width=0.2\textwidth]{res/Wortmarke_WI_schwarz.pdf} +{ ~ \sffamily + \vfill + {\Huge\bfseries Konzeption und Umsetzung eines IPv6-VPN für die Abteilung Informatik} + \bigskip + + {\Large Jan Philipp Timme + \\[2ex] + Masterarbeit im Studiengang "`Angewandte Informatik"' + \\[5ex] + \today + } +} +\vfill + ~ \hfill + \includegraphics[height=0.3\paperheight]{res/H_WI_Pantone1665.pdf} +\vspace*{-3cm} diff --git a/Masterarbeit.tex b/Masterarbeit.tex index 5989c4d..c9eaa69 100644 --- a/Masterarbeit.tex +++ b/Masterarbeit.tex @@ -92,346 +92,34 @@ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \begin{document} -% Titelseite -\thispagestyle{empty} -\includegraphics[width=0.2\textwidth]{res/Wortmarke_WI_schwarz.pdf} -{ ~ \sffamily - \vfill - {\Huge\bfseries Konzeption und Umsetzung eines IPv6-VPN für die Abteilung Informatik} - \bigskip +\input{MA-Titelseite.tex} +\input{MA-Erklaerung.tex} - {\Large Jan Philipp Timme - \\[2ex] - Masterarbeit im Studiengang "`Angewandte Informatik"' - \\[5ex] - \today - } -} -\vfill - ~ \hfill - \includegraphics[height=0.3\paperheight]{res/H_WI_Pantone1665.pdf} -\vspace*{-3cm} - -% Seite mit Personen und Selbstständigkeitserklärung -\newpage \thispagestyle{empty} -\begin{tabular}{ll} -{\bfseries\sffamily Autor} & Jan Philipp Timme \\ - & Matrikelnummer 1433117 \\ - & Abteilung Informatik, Fakultät IV \\ - & Hochschule Hannover \\ - & jan.philipp@timme.it \\[5ex] -{\bfseries\sffamily Erstprüfer} & Prof. Dr. Stefan Wohlfeil \\ - & Abteilung Informatik, Fakultät IV \\ - & Hochschule Hannover \\ - & stefan.wohlfeil@hs-hannover.de \\[5ex] -{\bfseries\sffamily Zweitprüfer} & N.N. \\ - & Abteilung Informatik, Fakultät IV \\ - & Hochschule Hannover \\ - & N.N@hs-hannover.de -\end{tabular} - -\vfill - -% fett und zentriert in der Minipage -\begin{center} \sffamily\bfseries Selbständigkeitserklärung \end{center} - -Hiermit erkläre ich, dass ich die eingereichte Masterarbeit -selbständig und ohne fremde Hilfe verfasst, andere als die von mir angegebenen Quellen -und Hilfsmittel nicht benutzt und die den benutzten Werken wörtlich oder -inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. -\vspace*{7ex} - -Hannover, den \today \hfill Unterschrift - -\pdfbookmark[0]{Inhalt}{contents} % Inhaltsverzeichnis +\pdfbookmark[0]{Inhalt}{contents} \tableofcontents % Abbildungsverzeichnis %\listoffigures + % Codeverzeichnis %\lstlistoflistings + % Tabellenverzeichnis %\listoftables \newpage -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -%%% Hier geht es richtig los mit dem Text! -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -\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} - - - -%%% Ende inhaltlicher Inhalt! %%% +% Inhalte +\input{MA-Inhalt.tex} % Literaturverzeichnis \clearpage - % Schlüssel als Buchstaben \bibliographystyle{alpha} \bibliography{Literaturverweise} % Und JETZT zum Inhaltsverzeichnis hinzufügen. Geil! \addcontentsline{toc}{chapter}{Literaturverweise} + \end{document} -% Nothing beyond this line! +% Nothing beyond this line! \ No newline at end of file