\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} \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 geschützte Verbindungen zwischen zwei oder mehr Computern einzurichten. IPsec ist ein Internetstandard, der kryptografische Sicherheit für IPv4 und IPv6 (sowie darüber übertragenen Daten) bieten soll. Das beinhaltet unter anderem Vertraulichkeit übertragener Daten durch den Einsatz von Verschlüsselung, Authentisierung von Paketen durch Prüfung von Prüfsummen, und Schutz vor Replay-Angriffen\cite{RFC4301}[Vergleich Kapitel 2.1]. Mit IPsec können Richtlinien definiert werden, ob und wie Datenverkehr von einem Host zu einem anderen Host geschützt werden soll. Zum Schutz des Datenverkehrs können die Protokolle AH und ESP benutzt werden, die in den folgenden Absätzen kurz vorgestellt werden. Das Protokoll \enquote{IP Authentication Header} (AH) ist in \cite{RFC4302} definiert und ermöglicht den Versand von authentisierbaren Paketen an eine Gegenstelle. Vor dem Versand wird über den Inhalt und einige Felder des IP-Pakets eine Prüfsumme gebildet. Die Gegenstelle kann nun die Prüfsumme des empfangenen Pakets berechnen und mit der im Paket enthaltenen Prüfsumme abgleichen\cite{RFC4302}[Siehe Kapitel 3.3.3]. Die Funktion zur Berechnung der Prüfsumme wird nicht explizit definiert und kann daher anhand der zur Zeit aktuellen Vorgaben\cite{RFC8221}[in diesem Dokument definiert] gewählt werden. Je nach gewählter Funktion fließen gemeinsame Geheimnisse oder Signaturalgorithmen in die Berechnung der Prüfsumme ein, sodass eine korrekte Prüfsumme ein Paket wirklich authentisieren kann. Eine Verschlüsselung der Paketinhalte ist im AH-Protokoll nicht vorgesehen. Das Protokoll \enquote{IP Encapsulating Security Payload} (ESP) ist in \cite{RFC4303} definiert und ermöglicht den Versand von Paketen mit vertraulichen Inhalten an eine Gegenstelle. Ähnlich wie bei dem AH-Protokoll ist auch im ESP-Protokoll die Authentisierung von Paketen mit einer Prüfsumme vorgesehen\cite{RFC4303}[Siehe Kapitel 2.8]. Aktuell empfohlene Algorithmen zum Berechnen der Prüfsumme oder zum Verschlüsseln der Paketinhalte sind \cite{RFC8221}[hier] aufgeführt. IPsec definiert zwei Betriebsvarianten: Den Transportmodus und den Tunnelmodus. Im Transportmodus werden die Inhalte von IP-Paketen in AH- bzw. ESP-Pakete gekapselt. Da die Sender- und Empfängeradressen der IP-Pakete hierbei nicht verändert wird, kann dieser Modus nur für direkte Ende-zu-Ende-Kommunikation verwendet werden. Im Tunnelmodus werden die IP-Paketen selbst in AH- bzw. ESP-Pakete gekapselt. Im Anschluss werden die AH- bzw. ESP-Pakete dann in neue IP-Pakete gekapselt, deren Sender- und Empfängeradressen sich von denen des inneren IP-Paketes unterscheiden dürfen. Somit ist der Tunnelmodus im Prinzip für die Umsetzung eines VPN geeignet. Strongswan implementiert das Protokoll IKEv2\footnote{Internet Key Exchange Protokoll Version 2, definiert in \cite{RFC7296}} und kann authentisiert und verschlüsselt mit Gegenstellen 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. \paragraph{OpenVPN} Hier wird OpenVPN beschrieben. \section{Auswahl einer VPN-Software} Vorzüge von OpenVPN und IPsec im Vergleich. Begründung der Auswahl. \section{Konzipierung der 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 \section{Umsetzung einer Zertifizierungsstelle} \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 \section{Erstellung eines Betriebskonzept} Installation, Inbetriebnahme, notwendige (regelmäßige) Wartungsarbeiten \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.