398 lines
32 KiB
TeX
398 lines
32 KiB
TeX
\chapter{Einleitung} \label{cpt:introduction}
|
|
Die Menge der noch verfügbaren IPv4-Adressen neigt sich dem Ende zu.
|
|
Laut Angaben des RIPE NCC\footnote{RIPE Network Coordination Centre} vom Juni 2018 sind noch ungefähr 8,63 Millionen IPv4-Adressen verfügbar\footnote{\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph}, abgerufen am 03.06.2018}.
|
|
Das entspricht etwa der Hälfte der nutzbaren Host-Adressen eines \texttt{/8}-Blocks.
|
|
Betrachtet man die Vergabegeschwindigkeit von IPv4-Adressen aus den letzten 3 Jahren, so könnte man den Zeitpunkt der Erschöpfung von IPv4-Adressen zwischen 2019 und 2021 vermuten\footnote{\url{https://ipv4.potaroo.net/}, abgerufen am 03.06.2018}.
|
|
|
|
Vor diesem Hintergrund findet die Verwendung von IPv6 eine zunehmende Verbreitung als Nachfolger von IPv4:
|
|
Immer mehr Internetdienste können über IPv6 erreicht werden, und auch die Internetanbieter stellen ihren Kunden IPv6-fähige Internetanschlüsse zur Verfügung.
|
|
Der Anteil von Suchanfragen, die über IPv6 an Google gestellt wurden, hat von 5,84\% am 1. Januar 2015 auf 21,11\% am 1. Juni 2018 zugenommen\footnote{\url{https://www.google.com/intl/en/ipv6/statistics.html}, abgerufen am 03.06.2018}.
|
|
Am AMS-IX\footnote{Amsterdam Internet Exchange}, dem Internet-Austauschpunkt in Amsterdam, hat sich der Durchfluss von IPv6-Verkehr in den letzten 12 Monaten im Durchschnitt von etwa 55 Gbit/s im August 2017 auf etwa 85 Gbit/s im Mai 2018 gesteigert\footnote{\url{https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic},\\abgerufen am 03.06.2018}.
|
|
|
|
Auch das Netz der Abteilung Informatik an der Hochschule Hannover ist Vorreiter in der Erprobung von IPv6: Seit Anfang 2015 ist das Netz schon über IPv6 an das Internet angebunden.
|
|
Damit ist die Voraussetzung gegeben, um Netzwerkgeräte für IPv6 zu konfigurieren und bestehende Netzwerkdienste auch über IPv6 anzubieten.
|
|
|
|
Mitarbeitern und Studenten der Abteilung Informatik steht ein VPN-Dienst zur Ver\-fü\-gung, um Zugang in das Netz der Abteilung aus dem Internet heraus zu erhalten.
|
|
Bisher ist dieser Dienst nur über IPv4 erreichbar und ermöglicht den Zugang in das Abteilungsnetz ausschließlich über IPv4.
|
|
\newpage
|
|
Im Rahmen dieser Masterarbeit soll ein neuer, IPv6-fähiger VPN-Dienst konzipiert werden, der die Idee des bisherigen IPv4-VPN-Dienst aufgreift.
|
|
Dafür wird zunächst die Netzarchitektur der Abteilung Informatik inklusive dem Firewallkonzept vorgestellt.
|
|
Anschließend werden alle Rahmenbedingungen und Anforderungen erfasst, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden sollen.
|
|
In der darauf folgenden Konzeptphase werden zunächst grundlegende, lösungsunabhängige Entscheidungen getroffen, auf Basis derer dann eine technischen Lösung ausgewählt wird.
|
|
\todo{Danach geht es weiter mit der Planung der konkreten Lösung, der Installation und der Dokumentation.}
|
|
|
|
|
|
\chapter{Netzarchitektur der Abteilung Informatik} \label{cpt:netarchitecture}
|
|
Das Netz der Abteilung Informatik wird durch eine Firewall vom Netz der Hochschule Hannover und dem Internet getrennt.
|
|
An der Firewall sind zwei lokale Netze angeschlossen: Die Demilitarisierte Zone (DMZ) und das interne Abteilungsnetz, welches durch einen zentralen Switch in mehrere virtuelle Netze (VLANs) unterteilt wird.
|
|
Zusätzlich sind die Netze des Netzwerklabors und des IT-Sicherheitslabors über je einen eigenen Router an den Switch angeschlossen.
|
|
Eine Skizze der Netztopologie mit den für diese Arbeit relevanten Teilen ist in Abbildung~\ref{fig:topology_simple} zu sehen.
|
|
\begin{figure}[ht]
|
|
\centering
|
|
% Trim, da diese Grafik als PDF auf DIN A4 vorliegt.
|
|
\frame{\includegraphics[trim=75 540 75 75,clip,width=\textwidth]{img/Netzwerktopologie_simpelv2_with_addresses.pdf}}
|
|
\caption{Skizze der Netztopologie der Abteilung Informatik}
|
|
\label{fig:topology_simple}
|
|
\end{figure}
|
|
|
|
|
|
\section{Firewallkonzept} \label{sct:firewall}
|
|
Die im Netz der Abteilung Informatik verwendeten LANs und VLANs werden im Firewallkonzept als verschiedene Sicherheitszonen betrachtet.
|
|
Im Rahmen dieser Arbeit sind die folgenden Zonen relevant:
|
|
|
|
\paragraph{Internet}
|
|
Das \enquote{Internet} bezeichnet den Bereich außerhalb des Netzes der Abteilung Informatik.
|
|
Diese Zone umfasst neben dem Internet auch das Netz der Hochschule Hannover.
|
|
Verbindungen in das Internet sind aus allen Zonen außer der DMZ erlaubt.
|
|
Verbindungen aus dem Internet werden nur zu Diensten in der DMZ (wie zum Beispiel VPN), sowie zu dem SSH-Dienst im Mitarbeiter-Netz zugelassen.
|
|
|
|
\paragraph{DMZ}
|
|
Von der Abteilung Informatik betriebenen Server stellen in diesem Netz Dienste zur Verfügung, die sowohl innerhalb der Abteilung als auch über das Internet erreichbar sind.
|
|
Verbindungen in die DMZ zu Diensten wie VPN sind aus allen anderen Zonen heraus erlaubt.
|
|
Verbindungen aus der DMZ in alle anderen Zonen sind verboten, um im Fall eines Sicherheitsvorfalls Angriffe auf alle anderen Zonen zu verhindern.
|
|
Eine Ausnahme für dieses Verbot sind Verbindungen vom VPN-Dienst, die in das Mitarbeiter-Netz aufgebaut werden dürfen.
|
|
|
|
\paragraph{Mitarbeiter-Netz}
|
|
Die Rechner aller Mitarbeiter der Abteilung Informatik sind an dieses Netz angeschlossen.
|
|
Verbindungen in das Mitarbeiter-Netz aus dem Pool-PC-Netz und den Labor-Netzen sind erlaubt.
|
|
Außerdem sind Verbindungen von dem VPN-Dienst aus der DMZ in das Mitarbeiter-Netz erlaubt.
|
|
Verbindungen aus dem Mitarbeiter-Netz sind in alle anderen Zonen erlaubt.
|
|
|
|
\paragraph{Pool-PC-Netz}
|
|
Enthält die Rechner aus allen Poolräumen.
|
|
Verbindungen in das Pool-PC-Netz sind aus dem Mitarbeiter-Netz und den Labor-Netzen erlaubt.
|
|
Verbindungen aus dem Pool-PC-Netz sind in alle anderen Zonen erlaubt.
|
|
|
|
\paragraph{Labor-Netze}
|
|
Das Netzwerklabor und das Labor für IT-Sicherheit werden für diese Arbeit unter der Zone \enquote{Labor-Netze} zusammengefasst.
|
|
Verbindungen aus den Labornetzen heraus sind in alle anderen Zonen erlaubt.
|
|
Verbindungen in die Labornetze sind aus dem Mitarbeiter-Netz und aus dem Pool-PC-Netz heraus erlaubt.
|
|
|
|
Ein Überblick der erlaubten Verbindungen zwischen den Sicherheitszonen ist in Tabelle~\ref{tab:firewall_zone_access} skizziert.
|
|
|
|
\begin{table}[ht]
|
|
\centering
|
|
\caption{Überblick über erlaubte Verbindungen zwischen Sicherheitszonen}
|
|
\begin{tabular}{ *{6}{|l}| }
|
|
\hline
|
|
& \multicolumn{5}{c|}{\dots in die Zone \dots} \\
|
|
Aus der Zone \dots & Internet & DMZ & Mitarbeiter-Netz & Pool-PC-Netz & Labor-Netze \\
|
|
\hline
|
|
Internet & --- & erlaubt & verboten & verboten & verboten \\
|
|
DMZ & verboten & --- & verboten & verboten & verboten \\
|
|
Mitarbeiter-Netz & erlaubt & erlaubt & --- & erlaubt & erlaubt \\
|
|
Pool-PC-Netz & erlaubt & erlaubt & erlaubt & --- & erlaubt \\
|
|
Labor-Netze & erlaubt & erlaubt & erlaubt & erlaubt & --- \\
|
|
\hline
|
|
\end{tabular}
|
|
\label{tab:firewall_zone_access}
|
|
\end{table}
|
|
|
|
|
|
\chapter{Anforderungsanalyse} \label{cpt:requirements}
|
|
In diesem Abschnitt werden alle Anforderungen und Rahmenbedingungen vorgestellt, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden müssen.
|
|
Es handelt sich hier um Vorgaben, die im persönlichen Gespräch mit dem Auftraggeber und Erstprüfer dieser Arbeit ermittelt wurden.
|
|
|
|
\begin{enumerate}[label=Anf\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 Betriebssysteme 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 Betriebssystemen lauffähig sein (\ref{req:clientos}).
|
|
|
|
Die Vorgabe von vertraulicher und authentisierter Kommunikation zwischen VPN-Client und VPN-Server (\ref{req:traffic}) impliziert, dass in der gesuchten Software Algorithmen zum Verschlüsseln und Signieren von Daten verwendet werden.
|
|
Deshalb soll Kerckhoffs' Prinzip bei der Wahl der VPN-Software angewendet werden, indem ausschließlich
|
|
quelloffene Software berücksichtigt wird.
|
|
Jedermann kann öffentlich lesbaren Quellcode auf mögliche Sicherheitslücken untersuchen; dadurch erhöht sich die Wahrscheinlichkeit bestehende Sicherheitslücken zu finden.
|
|
Außerdem werden gefundene und behobene Sicherheitslücken häufig besser kommuniziert, da alle Änderungen am Quellcode ohnehin sichtbar sind.
|
|
Das wirkt sich auch auf Reaktionszeiten der Software-Distributoren aus: Entsprechend aktualisierte Softwarepakete stehen in der Regel zeitnah bereit und können sofort installiert werden.
|
|
|
|
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 Anpassen 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[][Kapitel 6.5]{book:debian}.
|
|
|
|
Um den Wartungsaufwand des VPN-Servers zu reduzieren, kann die Installation von Updates durch den Debian-Paketmanager automatisiert werden\cite[][Kapitel 6.7 und 6.8]{book:debian}.
|
|
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.
|
|
|
|
|
|
\subsection{Strongswan} \label{ssct:strongswan}
|
|
Strongswan\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan},\\zuletzt abgerufen am 18.07.2018} ist eine quelloffene, modular aufgebaute Software, die unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebssystemen lauffähig ist.
|
|
Sie kann verwendet werden, um in Kombination mit IPsec-fähigen Betriebssystem-Kerneln geschützte Verbindungen zwischen zwei oder mehr Computern einzurichten.
|
|
Strongswan wird unter der Lizenz GPLv2 verbreitet\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/Contributions},\\ zuletzt abgerufen am 04.09.2018}.
|
|
|
|
IPsec ist ein Internetstandard, der kryptografische Sicherheit für IPv4 und IPv6 (sowie darüber übertragenen Daten) bieten soll.
|
|
Das beinhaltet unter anderem Vertraulichkeit übertragener Daten durch den Einsatz von Verschlüsselung, Authentisierung von Paketen durch Prüfung von Prüfsummen, und Schutz vor Replay-Angriffen\cite[Vergleich][Kapitel 2.1]{RFC4301}.
|
|
Mit IPsec können Richtlinien definiert werden, ob und wie Datenverkehr von einem Host zu einem anderen Host geschützt werden soll.
|
|
Zum Schutz des Datenverkehrs können die Protokolle AH und ESP benutzt werden, die in den folgenden Absätzen kurz vorgestellt werden.
|
|
|
|
Das Protokoll \enquote{IP Authentication Header} (AH) ist in \cite[][]{RFC4302} definiert und ermöglicht den Versand von authentisierbaren Paketen an eine Gegenstelle.
|
|
Vor dem Versand wird über den Inhalt der beim Transport unveränderlichen Felder des IP-Pakets eine Prüf\-sum\-me gebildet.
|
|
Die Gegenstelle kann die Prüfsumme des empfangenen Pakets berechnen und mit der im Paket enthaltenen Prüfsumme abgleichen\cite[Siehe][Kapitel 3.3.3]{RFC4302}.
|
|
Die Funktion zur Berechnung der Prüfsumme wird nicht explizit definiert und kann daher anhand der zur Zeit aktuellen Vorgaben\cite[definiert in][]{RFC8221} gewählt werden.
|
|
Abhängig von der gewählten Funktion fließen bereits im Vorfeld ausgehandelte gemeinsame Geheimnisse oder Signaturalgorithmen in die Berechnung der Prüfsumme ein, sodass eine korrekte Prüfsumme ein Paket authentisiert.
|
|
Eine Verschlüsselung der Paketinhalte ist im AH-Protokoll nicht vorgesehen.
|
|
|
|
Das Protokoll \enquote{IP Encapsulating Security Payload} (ESP) ist in \cite[][]{RFC4303} definiert und ermöglicht den Versand von Paketen mit vertraulichen Inhalten an eine Gegenstelle.
|
|
Ähnlich wie bei dem AH-Protokoll ist auch im ESP-Protokoll die Authentisierung von Paketen mit einer Prüfsumme vorgesehen\cite[Siehe][Kapitel 2.8]{RFC4303}.
|
|
Aktuell empfohlene Algorithmen zum Berechnen der Prüfsumme oder zum Verschlüsseln der Paketinhalte sind in \cite[][]{RFC8221} aufgeführt.
|
|
Durch die Verschlüsselung der Paketinhalte vor dem Transport wird die Vertraulichkeit der übertragenen Inhalte gewährleistet.
|
|
Als Schlüssel wird ein zwischen Sender und Empfänger im Vorfeld ausgehandeltes gemeinsames Geheimnis verwendet.
|
|
Auch die verwendeten Verschlüsselungsalgorithmen müssen zwischen Sender und Empfänger ausgehandelt werden.
|
|
|
|
IPsec kann im Transportmodus und im Tunnelmodus betrieben werden.
|
|
Im Transportmodus werden die Inhalte von IP-Paketen in AH- beziehungsweise ESP-Pakete gekapselt.
|
|
Da die Sender- und Empfängeradressen der IP-Pakete hierbei nicht verändert wird, kann dieser Modus nur für direkte Ende-zu-Ende-Kommunikation verwendet werden.
|
|
|
|
Im Tunnelmodus werden die IP-Paketen selbst in AH- beziehungsweise ESP-Pakete gekapselt.
|
|
Im Anschluss werden die AH- beziehungsweise ESP-Pakete dann in neue IP-Pakete gekapselt, deren Sender- und Empfängeradressen sich von denen des inneren IP-Paketes unterscheiden dürfen.
|
|
Somit ist der Tunnelmodus im Prinzip für die Umsetzung eines VPN geeignet.
|
|
|
|
Die Protokolle AH und ESP definieren selbst kein Verfahren zum Aushandeln von verwendeten Prüfsummenfunktionen, kryptografischen Algorithmen oder allgemeiner Konfigurationsparameter.
|
|
Auch der Austausch gemeinsamer Geheimnisse beziehungsweise Schlüsselmaterial wird nicht definiert.
|
|
Diese Aufgabe übernimmt Strongswan als IKEv2-Dienst.
|
|
|
|
Strongswan implementiert das Protokoll IKEv2\footnote{Internet Key Exchange Protokoll Version 2, definiert in \cite[][]{RFC7296}} und kann darüber authentisiert und verschlüsselt mit Gegenstellen kommunizieren.
|
|
Dabei werden mit der Gegenstelle Schlüssel- und Konfigurationsparameter ausgehandelt beziehungsweise ausgetauscht, anhand derer Strongswan IPsec-Verbindungen im Kernel des Host-Betriebssystems konfigurieren kann.
|
|
Die Verarbeitung des durch IPsec geschützten Da\-ten\-ver\-kehrs über die Protokolle AH oder ESP wird jedoch direkt im IPsec-Stack des Kernels abgewickelt.
|
|
Dadurch ist der Einsatz von IPsec für lokal ausgeführte Programme transparent.
|
|
|
|
|
|
\subsection{OpenVPN} \label{ssct:openvpn}
|
|
OpenVPN ist eine quelloffene Software zur Einrichtung von VPNs in Peer-to-Peer oder Client-Server-Architektur\cite[][Abschnitt \enquote{Server Mode}]{man:openvpn}.
|
|
Sie ist unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebssystemen lauffähig und wird unter der GPLv2-Lizenz verbreitet.
|
|
OpenVPN läuft vollständig im Benutzerkontext und unterstützt nach dem Programmstart den Wechsel in einen nicht-privilegierten Benutzerkontext\cite[Siehe][\texttt{--user}]{man:openvpn}.
|
|
Für die Bereitstellung einer virtuellen Netzwerkkarte als Schnittstelle zum VPN wird ein TUN/TAP-Treiber verwendet.
|
|
Kryptografische Operationen werden nur in OpenVPN durchgeführt, welches diese zu großen Teilen an die quelloffene Bibliothek openssl auslagert\cite[][Abschnitt \enquote{Introduction}]{man:openvpn}.
|
|
|
|
OpenVPN ist unterstützt IPv4 und IPv6 sowohl innerhalb eines VPN als auch zur Kommunikation zwischen den OpenVPN-Clients und -Servern.
|
|
|
|
|
|
\section{Auswahl einer VPN-Software}
|
|
Vorzüge von OpenVPN und IPsec im Vergleich.
|
|
Begründung der Auswahl.
|
|
|
|
Idee: Hier kommen Kategorien hinein: Lizenz, Komplett quelloffen/Abhängigkeiten?, Funktionsumfang, Firewallregeln, Trennung von Steuerdaten und Nutzdaten, Platformabhängigkeit, Komplexität der Konfiguration, Einheitliche Sicherheitsniveaus, Userspace vs Userspace+Kernel, Benutzerfreundlichkeit, Konfiguration bidirektional/unidirektional, Potential für Fehlkonfiguration, Flexibilität
|
|
|
|
IPsec:
|
|
Konfiguration der IPsec-Verbindungen findet im Kernel statt, es ist ein zusätzliches IKEv2-Dienstprogramm notwendig, um die Konfigurationsparameter auszuhandeln und Schlüssel auszutauschen.
|
|
Die im Kernel konfigurierten Verbindungen sind immer unidirektional, d.h. für den Schutz von Datenverkehr zwischen zwei Rechnern sind auf beiden Rechnern jeweils zwei konfigurierte Verbindungen notwendig.
|
|
|
|
Bei gegebenenfalls. entdeckten Sicherheitslücken ergeben sich je nach Betriebssystemkernel unterschiedliche Reaktionszeiten.
|
|
Je nach Betriebssystem werden im Kernel gegebenenfalls. nicht alle laut RFC empfohlenen Chiffren gleichermaßen angeboten, dadurch kann ein einheitliches Sicherheitsniveau nur schwer gewährleistet werden.
|
|
Strongswan ist zwar grundsätzlich auf allen in \ref{req:clientos} aufgeführten Betriebssystemen lauffähig, jedoch endet die Benutzerfreundlichkeit voraussichtlich dann, wenn man Strongswan unter Windows erst einmal kompilieren muss.
|
|
Verlässt man sich auf der Clientseite auf das gegebenenfalls. bereits im Betriebssystem enthaltene IKEv2-Dienstprogramm, so wird die Bedienung über alle Betriebssysteme unterschiedlich sein.
|
|
Auch darunter leidet die Benutzerfreundlichkeit.
|
|
Durch die insgesamt hohe Komplexität des IPsec-Standards ist eine Fehlersuche im Betrieb nicht unbedingt trivial.
|
|
Hinzu kommt, dass durch den hohen Funktionsumfang und die Flexibilität von IPsec Konfigurationen möglich sind, die zwar eine durch IPsec gekapselte Kommunikation ermöglichen, jedoch nicht das gewünschte Sicherheitsniveau herstellen.
|
|
|
|
OpenVPN hat nur einen Kommunikationskanäle (udp/1194), während für IPsec IKEv2 (udp/500 beziehungsweise udp/4500) und die Protokolle AH beziehungsweise ESP freigegeben werden müssen.
|
|
|
|
|
|
Sowohl Strongswan als auch OpenVPN sind vollständig quelloffen.
|
|
Da jedoch der Datenverkehr bei IPsec durch den Betriebssystemkernel verarbeitet wird, und dessen Quellcode bei Betriebssystemen von Microsoft oder Apple nicht zur Verfügung steht, scheidet Strongswan als Kandidat aus.
|
|
|
|
|
|
\section{Konzipierung der Benutzerverwaltung}
|
|
Anforderungen:
|
|
\begin{itemize}
|
|
\item Möglichst simpel für alle Beteiligten
|
|
\item Möglichst wenig personenbezogene Daten verarbeiten oder speichern
|
|
\item Zielgruppe des Dienstes sind Beschäftigte und Studenten der Abteilung Informatik (Größenordnung: 20-200 Personen)
|
|
\item Studenten sollen Zugriff für den zeitlichen Rahmen Ihres Studiums erhalten
|
|
\item Beschäftigte sollen Zugriff im zeitlichen Rahmen Ihrer Beschäftigung erhalten
|
|
\end{itemize}
|
|
|
|
Möglichkeiten: User+Passwort oder SSL-Zertifikate
|
|
|
|
Zertifikate:
|
|
\begin{itemize}
|
|
\item klare Laufzeit
|
|
\item kann nicht erraten werden
|
|
\item Können schlimmstenfalls via CRL gesperrt werden
|
|
\item Verschlüsselung des privaten Schlüssels verhindert Missbrauch bei gestohlenen Daten (Cert+Key)
|
|
\item Einrichtung von Benutzern geschieht durch Signatur eines Zertifikatsantrags
|
|
\item Erfolgreich gestohlenes Zertifikat kann nur für VPN-Dienst genutzt werden
|
|
\end{itemize}
|
|
|
|
Benutzer/Passwort:
|
|
\begin{itemize}
|
|
\item Bequemlichkeit: Kann über existierende Infrastruktur abgewickelt werden (Hochschulkonto)
|
|
\item Einrichtung von Benutzern kann quasi vollautomatisch oder durch eine Whitelist geschehen
|
|
\item Benutzerkonten werden automatisch deaktiviert
|
|
\item Nur Benutzername+Passwort reichen aus, gestohlene Zugangsdaten bedeuten großes Schadenspotential für betroffene Benutzer
|
|
\item Zugangsdaten müssen zur Authentisierung an entsprechende Dienste "durchgereicht" werden, daher größere Angriffsfläche
|
|
\end{itemize}
|
|
|
|
Gewinner: Zertifikate
|
|
Für Zertifikate wird eine Zertifizierungsstelle benötigt.
|
|
|
|
|
|
\section{Konzeption und Umsetzung einer Zertifizierungsstelle}
|
|
OpenSSL ist aufgrund der Abhängigkeit von OpenVPN bereits gegeben.
|
|
Mit OpenSSL kann man Schlüsselpaare erzeugen, Zertifikatsanträge erzeugen und Zertifikate ausstellen.
|
|
Allerdings erfordert das viel Detailwissen und die Verwaltung der ausgestellten Zertifikate mit puren openssl-Befehlen ist nicht einfach.
|
|
Da wir Zertifikate auch unbrauchbar machen wollen, muss es möglich sein Zertifikate zu widerrufen.
|
|
Eine CRL muss erzeugt werden können, damit diese im OpenVPN-Dienst für die Prüfung der Gültigkeit der Zertifikate verwendet werden kann.
|
|
|
|
Jetzt kann man viel Zeit investieren, die notwendigen Skripte selbst zu schreiben.
|
|
Allerdings hat OpenVPN bereits eine Abhängigkeit auf die Skriptesammlung EasyRSA, welche exakt für diesen Zweck gebaut wurde.
|
|
Die von Debian 9 mitgelieferte Version 2.3.x ist schon etwas älter, könnte aber verwendet werden.
|
|
Allerdings gibt es auch eine modernere Neuentwicklung in Version 3.0.5(Stand 17.09.2018, siehe github.com/openvpn/easyrsa), die langfristig vom OpenVPN-Team weiterentwickelt wird und einige Verbesserungen im Vergleich zur alten v2 mitbringt.
|
|
|
|
Kurz: EasyRSA2.2.3 aus Debian vs EasyRSA3.x direkt von Github vs irgendwie selbst Skripte schreiben (Wieso das Rad neu erfinden?) - Vorteile/Nachteile
|
|
Gegebenenfalls. kurz ein Blick darauf, was alles für Features benötigt werden.
|
|
EasyRSAv3 ist eine Neuentwicklung von EasyRSA2.
|
|
Die neue Version wird vom OpenVPN-Team weiter entwickelt werden.
|
|
Vereinfachte Benutzung der zur Verfügung gestellten Shellskripte
|
|
Viele Verbesserungen, wie z.B. Unterstützung für ECDSA (Siehe Changelog) oder UTF-8 ist jetzt standard, AES256 wird für die Verschlüsselung des CA-Keys verwendet, \dots
|
|
|
|
Da für die Anfertigung von Zertifikatsanträgen einige Details beachtet werden sollen und diverse Einstellungen durch die Zertifizierungsstelle vorgegeben bzw. vorausgesetzt werden, ist es sinnvoll, dass die CA durch das IT-Team auf Basis von EasyRSA3 kurz vorbereitet wird und dann als Paket für Benutzer bereitgestellt wird.
|
|
|
|
Danach: Wie funktioniert die CA mit EasyRSA? Das ist in einem separaten Dokument geklärt.
|
|
\todo{Gegebenenfalls kann man daraus noch eine kürzere Version für die VPN-Benutzer herausdampfen.}
|
|
|
|
Frage: Welche Einstellungen sind anzupassen?
|
|
|
|
Frage: RSA oder Elliptic Curve für die VPN-CA?
|
|
\begin{itemize}
|
|
\item Die Wahl der Algorithmen wirkt sich höchstens auf die Dauer der Authentisierung beim Verbindungsaufbau aus, der reguläre Betrieb wird davon nicht berührt.
|
|
\item Da OpenVPN-Clients für alle Plattformen den selben Code verwenden, sollte bei gleichbleibenden Versionen von OpenSSL (bzw. kompatiblen mbed-TLS-Bibliotheken) die Wahl sich nicht auf die Kompatibilität auswirken.
|
|
\item RSA ist lange erprobt, bestehende Patente sind ausgelaufen. Schlüssel sind etwas größer (2-4Kbit), nicht gegen Angriffe durch Quantencomputer beständig (Primfaktorzerlegung)
|
|
\item Elliptic Curve-Verfahren sind noch relativ neu (10 Jahre?). Schlüssel sind kleiner, es gab schon einen Fall mit einer Backdoor in einer Curve\todo{Citation needed für Dual\_EC\_DRBG}, nicht gegen Angriffe durch Quantencomputer beständig (diskreter Logarithmus).
|
|
\end{itemize}
|
|
RSA wird gewählt.
|
|
Weil es deutlich länger auf dem Markt ist.
|
|
Weil in einer Elliptic Curve schon eine Backdoor gezeigt wurde.
|
|
Weil RSA immer noch funktioniert und in naher Zukunft nicht geknackt werden wird.
|
|
Das BSI hat in seinen technischen Richtlinien keine Bedenken gegen den Einsatz von RSA in Szenarien, die über 2023 hinausgehen\cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
|
|
|
|
Ressourcen:
|
|
\begin{itemize}
|
|
\item Empfehlungen des BSI für kryptografische Algorithmen und Schlüssellängen\cite{bsi:tr-02102-1}
|
|
\item Empfehlungen des BSI für kryptografische Algorithmen und Schlüssellängen bezüglich IPsec\cite{bsi:tr-02102-3}
|
|
\end{itemize}
|
|
|
|
Wie groß soll der RSA-Schlüssel sein?
|
|
\begin{itemize}
|
|
\item OpenVPN empfiehlt RSA mit Schlüsseln länger als 2048 Bit: \enquote{OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.}\cite[][Option \texttt{--tls-cert-profile}]{man:openvpn}
|
|
\item Das BSI empfiehlt den Betrieb mit Schlüsseln länger als 3000 Bit über das Jahr 2023 hinaus\cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
|
|
\end{itemize}
|
|
|
|
Organisatorische Frage: Zertifikate nur mit CN oder volles Schema?
|
|
Volles Schema => Mehr Informationen darüber, wo der VPN-Dienst angesiedelt ist. Ändert nicht viel. Es spricht nichts gegen den Einsatz des vollen Schemas. Es gibt keine nennenswerten Vorteile oder Nachteile. Mehr Informationen können helfen, wenn man einen Eimer voller Zertifikate findet.
|
|
|
|
Welche Angaben werden für Benutzerzertifikate übernommen? Namen? Benutzerkennungen?
|
|
\begin{itemize}
|
|
\item Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier
|
|
\item Voller Name: Konflikte selten aber möglich, personenbezogene Daten
|
|
\item E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
|
|
\item Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin)
|
|
\item Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht.
|
|
\end{itemize}
|
|
Benutzername wäre eine eindeutige Angabe, ist garantiert eindeutig.
|
|
Gleichzeitig kann man argumentieren, dass diese häufig pseudonym sind und die Zuordnung von Benutzername zu Person nicht immer trivial ist.
|
|
Datenschutzrechtlich sollte das gerade so okay sein.
|
|
|
|
Veto von Herrn Wohlfeil: Voller Name und Hochschul-E-Mail-Adresse werden in die Zertifikate geschrieben.
|
|
|
|
Laufzeit für Serverzertifikate? 5 Jahre
|
|
Laufzeit für Clientzertifikate individuell oder je nach Zielgruppe?
|
|
Studenten bekommen 2 Jahre (4 Semester)
|
|
Mitarbeiter bekommen 5 Jahre
|
|
|
|
Laufzeit der CA - sinnvolle Werte?
|
|
20 Jahre. Wenn man die Laufzeit bestehender Zertifikate im Auge behält, kann der Wechsel einer CA zu einem Stichtag hin funktionieren.
|
|
Von der CA ausgestellte Zertifikate können nicht länger gültig sein als das Wurzelzertifikat der CA selbst.
|
|
|
|
Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (Cronjob oder so)
|
|
|
|
|
|
\section{Einrichtung des VPN-Servers}
|
|
|
|
\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
|
|
\begin{itemize}
|
|
\item IP-Adressen und Routing geklärt
|
|
\item Konzepte und Konfiguration des IT-Teams in das Konzept integriert
|
|
\item virtuelle IP als Alias auf Netzwerkkarte, über die der Dienst angestoßen wird
|
|
\item Voraussichtlich separate Maschine zur Verwaltung der CA
|
|
\item Koordination Firewallregeln
|
|
\begin{itemize}
|
|
\item Dienst bietet nur OpenVPN udp/1194 (Internetoffen) und SSH tcp/22 (mal gucken, wie offen das ist)
|
|
\item lokale Firewall auf VPN-Server verhindert Zugriffe vom VPN in die DMZ
|
|
\end{itemize}
|
|
\item Koordination Routing
|
|
\begin{itemize}
|
|
\item IPv6-Bereich für VPN-Clients wird an virtuelle IPv6-Adresse des VPN-Dienstes geroutet: manuelles Failover möglich
|
|
\item IPv4: VPN-Clients bekommen IP-Adressen aus 10.2.0.0/16 Block, für IPv4 wird auf NAT zurückgegriffen
|
|
\end{itemize}
|
|
\item Diverse Best-practices/Designpattern übernommen (Konfiguration durch Pakete, SSH-Konfiguration, ...)
|
|
\end{itemize}
|
|
|
|
\section{Erstellung der OpenVPN-Konfiguration}
|
|
Nachdem in den vorangegagenen Teilen der Arbeit alle für die Erstellung der OpenVPN-Konfiguration notwendigen Informationen ermittelt wurden, wird hier gezeigt und erklärt, wie sich die Client- und Serverkonfigurationen für OpenVPN ergeben.
|
|
Dabei werden alle vorgenommenen Entscheidungen beleuchtet.
|
|
|
|
Auf Kompression wird verzichtet, da es bereits am 03.06.2018 Hinweise in der Manpage hinzugefügt wurden\footnote{\url{https://github.com/OpenVPN/openvpn/commit/6795a5f3d55f658fc1a28eb9f3b11d1217e3329c}}, in denen vor der Verwendung von Kompression gewarnt wird.
|
|
Zum Vergleich: OpenVPN Version 2.4.6 wurde von den Entwicklern am 19.04.2018\footnote{\url{https://github.com/OpenVPN/openvpn/releases/tag/v2.4.6}} freigegeben.
|
|
Zusätzlich wird in einem RFC\cite[][Kapitel 3.3]{RFC7525} auch zur Deaktivierung von Kompression geraten.
|
|
|
|
Auf der DEFCON 26 wird mit \enquote{VORACLE} ein in dieser Richtung relevanter Angriff auf OpenVPN vorgestellt\footnote{\url{https://media.defcon.org/DEF\%20CON\%2026/DEF\%20CON\%2026\%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf}}.
|
|
|
|
Festlegung kryptografischer Parameter:
|
|
Wir sprechen nur TLS 1.2 oder höher.
|
|
\begin{lstlisting}
|
|
tls-version-min "1.2"
|
|
\end{lstlisting}
|
|
TLS-Chiffre \enquote{TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384} wird in \cite{bsi:tls-checkliste} und \cite{RFC7525} empfohlen.
|
|
\begin{lstlisting}
|
|
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
|
|
\end{lstlisting}
|
|
Verschlüsselung der Daten mit AES-256-GCM.
|
|
\begin{lstlisting}
|
|
cipher AES-256-GCM
|
|
\end{lstlisting}
|
|
Prüfen der Zertifikate mittels Hashfunktion SHA256.
|
|
\begin{lstlisting}
|
|
auth SHA256
|
|
\end{lstlisting}
|
|
|
|
\section{Erstellung eines Betriebskonzept}
|
|
\todo{Installation/Installationsanleitung: Separates Dokument}
|
|
Konfiguration
|
|
Inbetriebnahme
|
|
notwendige (regelmäßige) Wartungsarbeiten
|
|
|
|
|
|
\chapter{Fazit}
|
|
Wie ist es gelaufen, gab es Probleme? Wie macht sich OpenVPN als Lösung?
|
|
Gibt es vielleicht Szenarien, in denen sich IPsec doch lohnt?
|
|
Ja - eventuell. Sehr große Enterprise-Umgebungen, in denen die personellen Ressourcen für die korrekte Konfiguration vorhanden sind.
|
|
Da kann man in homogenen Umgebungen sinnvolle IPsec-Konfigurationen auf hunderten oder tausenden Geräte einrichten.
|
|
|
|
Der Einsatz von IPsec ist für die Umsetzung eines VPN in das Netzwerk einer Fakultätsabteilung ein Schuss mit einer Kanone auf Spatzen.
|
|
In großen Umgebungen eines Konzerns kann die Situation schon etwas anders aussehen: Sofern die IT-Landschaft in einem Konzern homogen aufgestellt ist, könnten auf IPsec spezialisierte Administratoren über Konfigurationsmanagement wie zum Beispiel das Active Directory von Microsoft eine Steigerung der Netzwerksicherheit erzielen oder Außendienstmitarbeitern einen nahtlosen Anschluss an das Firmennetzwerk bieten.
|
|
|
|
|
|
\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.
|