453 lines
22 KiB
TeX
453 lines
22 KiB
TeX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% Setup des Dokuments
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\documentclass[12pt,a4paper,twoside,parskip=half-,headsepline,headinclude]{scrreprt} % Grundgröße 12pt, zweiseitig
|
|
% Packages from template
|
|
\usepackage[headsepline,automark]{scrlayer-scrpage} % Seitenköpfe automatisch
|
|
\KOMAoptions{headinclude} % Fix
|
|
\usepackage[german]{babel} % Sprachpaket für Deutsch (Umlaute, Trennung,deutsche Überschriften)
|
|
\usepackage{graphicx} % Graphikeinbindung
|
|
\usepackage{hyperref} % Hyperref (alles klickbar, Bookmarks)
|
|
\usepackage{amssymb} % Math. Symbole aus AmsTeX
|
|
\usepackage[utf8]{inputenc} % Umlaute
|
|
% Custom packages
|
|
\usepackage[autostyle=true,german=quotes]{csquotes} % Anführungszeichen mit \enquote{}
|
|
\usepackage{textcomp} % Zusätzliches Package für °C
|
|
\usepackage{listings} % Codesnippets
|
|
\usepackage{scrhack} % Hack for lstlisting i suspect :-/
|
|
\usepackage{xcolor}
|
|
\usepackage{float}
|
|
\usepackage{soul}
|
|
\usepackage{verbatim} % für comment-environment
|
|
\usepackage{amsmath}
|
|
\usepackage{enumitem} % enumerate mit benutzerdefinierten Labels
|
|
\usepackage{caption}
|
|
\captionsetup[table]{skip=8pt}
|
|
% Setup für Codeblocks
|
|
\lstset{
|
|
% Optionen
|
|
breaklines=true,
|
|
breakatwhitespace=true,
|
|
breakautoindent=true,
|
|
frame=single,
|
|
%framexleftmargin=19pt,
|
|
inputencoding=utf8,
|
|
%language=awk,
|
|
%numbers=left,
|
|
%numbersep=8pt,
|
|
showspaces=false,
|
|
showstringspaces=false,
|
|
tabsize=1,
|
|
%xleftmargin=19pt,
|
|
captionpos=b,
|
|
% Styling
|
|
basicstyle=\footnotesize\ttfamily,
|
|
commentstyle=\footnotesize,
|
|
keywordstyle=\footnotesize\ttfamily,
|
|
numberstyle=\footnotesize,
|
|
stringstyle=\footnotesize\ttfamily,
|
|
}
|
|
% Hack für Sonderzeichen in Codeblocks
|
|
\lstset{literate=%
|
|
{Ö}{{\"O}}1
|
|
{Ä}{{\"A}}1
|
|
{Ü}{{\"U}}1
|
|
{ß}{{\ss}}1
|
|
{ü}{{\"u}}1
|
|
{ä}{{\"a}}1
|
|
{ö}{{\"o}}1
|
|
{°}{{${^\circ}$}}1
|
|
}
|
|
|
|
% Befehl für TODO-Markierungen
|
|
\newcommand{\todo}[1]{\textcolor{blue}{\emph{TODO: #1}}}
|
|
|
|
% Befehl für Entwürfe und grobe Pläne
|
|
%\newenvironment{draft}{\par\color{orange}\begin{center}Entwurf / Konzept\end{center}\hrule}{\hrule\par}
|
|
|
|
% Broken citation needs broken command
|
|
\newcommand\mathplus{+}
|
|
|
|
% Festlegung Kopf- und Fußzeile
|
|
\defpagestyle{meinstil}{%
|
|
{\headmark \hfill}
|
|
{\hfill \headmark}
|
|
{\hfill \headmark\hfill}
|
|
(\textwidth,.4pt)
|
|
}{%
|
|
(\textwidth,.4pt)
|
|
{\pagemark\hfill Jan Philipp Timme}
|
|
{Version 1.0 vom \today \hfill \pagemark}
|
|
{Version 1.0 vom \today \hfill \pagemark}
|
|
}
|
|
\pagestyle{meinstil}
|
|
|
|
\raggedbottom
|
|
|
|
\renewcommand{\topfraction}{1}
|
|
\renewcommand{\bottomfraction}{1}
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% Beginn des Dokuments (Titelseite und der ganze Krempel)
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\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
|
|
|
|
{\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
|
|
\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{Dokumentation-CA.tex}
|
|
|
|
|
|
|
|
%%% Ende inhaltlicher Inhalt! %%%
|
|
|
|
% 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!
|
|
|
|
|
|
% Referenz auf Bibtex mit Kommentar
|
|
% \cite{robbins:gawk}[Siehe ab S.95]
|
|
|
|
% Einbinden von Tex-Files
|
|
%\input{abkuerz.tex}
|
|
%\input{einfuehrung.tex}
|
|
|
|
% Einbinden von größeren Tex-Files, z.B. Kapiteln
|
|
%\include{normen}
|
|
%\include{aufbau}
|
|
%\include{zitieren}
|
|
%\include{form}
|
|
%\include{allgtips}
|