Split Masterarbeit.tex into logical components
This commit is contained in:
parent
c385e93169
commit
8e00578084
30
MA-Erklaerung.tex
Normal file
30
MA-Erklaerung.tex
Normal file
@ -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
|
||||||
260
MA-Inhalt.tex
Normal file
260
MA-Inhalt.tex
Normal file
@ -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}
|
||||||
19
MA-Titelseite.tex
Normal file
19
MA-Titelseite.tex
Normal file
@ -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}
|
||||||
330
Masterarbeit.tex
330
Masterarbeit.tex
@ -92,346 +92,34 @@
|
|||||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
\begin{document}
|
\begin{document}
|
||||||
|
|
||||||
% Titelseite
|
\input{MA-Titelseite.tex}
|
||||||
\thispagestyle{empty}
|
\input{MA-Erklaerung.tex}
|
||||||
\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}
|
|
||||||
|
|
||||||
% 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
|
% Inhaltsverzeichnis
|
||||||
|
\pdfbookmark[0]{Inhalt}{contents}
|
||||||
\tableofcontents
|
\tableofcontents
|
||||||
|
|
||||||
% Abbildungsverzeichnis
|
% Abbildungsverzeichnis
|
||||||
%\listoffigures
|
%\listoffigures
|
||||||
|
|
||||||
% Codeverzeichnis
|
% Codeverzeichnis
|
||||||
%\lstlistoflistings
|
%\lstlistoflistings
|
||||||
|
|
||||||
% Tabellenverzeichnis
|
% Tabellenverzeichnis
|
||||||
%\listoftables
|
%\listoftables
|
||||||
|
|
||||||
\newpage
|
\newpage
|
||||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
||||||
%%% Hier geht es richtig los mit dem Text!
|
|
||||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
||||||
|
|
||||||
|
% Inhalte
|
||||||
\chapter{Einleitung} \label{cpt:introduction}
|
\input{MA-Inhalt.tex}
|
||||||
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! %%%
|
|
||||||
|
|
||||||
% Literaturverzeichnis
|
% Literaturverzeichnis
|
||||||
\clearpage
|
\clearpage
|
||||||
|
|
||||||
% Schlüssel als Buchstaben
|
% Schlüssel als Buchstaben
|
||||||
\bibliographystyle{alpha}
|
\bibliographystyle{alpha}
|
||||||
\bibliography{Literaturverweise}
|
\bibliography{Literaturverweise}
|
||||||
% Und JETZT zum Inhaltsverzeichnis hinzufügen. Geil!
|
% Und JETZT zum Inhaltsverzeichnis hinzufügen. Geil!
|
||||||
\addcontentsline{toc}{chapter}{Literaturverweise}
|
\addcontentsline{toc}{chapter}{Literaturverweise}
|
||||||
|
|
||||||
\end{document}
|
\end{document}
|
||||||
% Nothing beyond this line!
|
% Nothing beyond this line!
|
||||||
Loading…
x
Reference in New Issue
Block a user