Split Masterarbeit.tex into logical components
This commit is contained in:
parent
c385e93169
commit
8e00578084
|
|
@ -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
|
||||
|
|
@ -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}
|
||||
|
|
@ -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}
|
||||
|
||||
% 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!
|
||||
Loading…
Reference in New Issue