mastercolloquium/MA-KO-Inhalt.tex

\section{Einleitung}

\subsection{Situation von IPv4 und IPv6}
\begin{frame}{Situation von IPv4 und IPv6}
Allgemein:
\begin{itemize}
\item Öffentliche IPv4-Adressen sind fast vollständig erschöpft
\begin{itemize}
\item Internetanbieter setzen stellenweise auf Carrier-grade NAT\footnote{\textit{Network Address Translation} (NAT)}
\end{itemize}
\item Immer mehr Internetanschlüsse werden auch mit IPv6 versorgt
\end{itemize}
In der Abteilung Informatik:
\begin{itemize}
\item IPv6 wird seit wenigen Jahren erprobt
\item Seit Anfang 2018 besteht Versorgung durch natives IPv6-Routing
\item Existierende Dienste werden um IPv6 erweitert
\end{itemize}
\ \newline
$\rightarrow$ IPv6-fähiger VPN-Dienst soll bisherigen IPv4-VPN-Dienst ablösen
\end{frame}

\subsection{Definition: \textit{Virtual Private Network} (VPN)}
\begin{frame}{Definition: \textit{Virtual Private Network} (VPN)}

\begin{itemize}
\item \textit{Virtual}: Es existiert nur logisch, nicht physisch
\item \textit{Private}: Nur die VPN-Teilnehmer wissen davon
\item \textit{Network}: VPN-Teilnehmer können über VPN Nachrichten versenden und empfangen
\end{itemize}

\begin{block}{\textbf{Beispiel} Pen-\&-Paper-Rollenspiel}
Spielteilnehmer tauschen Informationen über Zettel aus, als säßen sie gemeinsam an einem Tisch. \\
Die Zettel werden aber im Umschlag per Post zwischen den Teilnehmern transportiert.
\end{block}
\end{frame}

\subsection{Beispiel: Funktionsweise eines VPNs}
\begin{frame}{Beispiel: Funktionsweise eines VPNs}
\begin{figure}[ht]
\centering
\includegraphics[trim=75 610 135 75,clip,width=\textwidth]{img/VPN-Skizze.pdf}
\caption{Beispielszenario: VPN-Verbindung zwischen Alice und Bob}
\end{figure}
\end{frame}


\section{Arbeitsauftrag}

\subsection{Arbeitsauftrag}
\begin{frame}{Arbeitsauftrag}
Ein IPv6-fähiger VPN-Dienst soll konzipiert und umgesetzt werden, um den existierenden IPv4-VPN-Dienst abzulösen. \\
\ \\
Ziel: Beschäftigte und Studierende der Abteilung Informatik sollen mit dem VPN arbeiten können, als wären Sie vor Ort.
\end{frame}

\subsection{Anforderungen}
\begin{frame}{Anforderungen (1/3)}
\begin{itemize}
\item \textbf{Dual-Stack-Betrieb}: Erreichbar über IPv6 und IPv4, Unterstützung von IPv6 und IPv4 innerhalb des VPNs
\item \textbf{VPN-interner Datenverkehr}: Interne Abteilungsnetze sollen über VPN erreichbar sein, VPN-Clients dürfen nicht mit anderen VPN-Clients kommunizieren, NFS\footnote{\textit{Network File System} (NFS)} muss blockiert werden
\item \textbf{VPN-externer Datenverkehr}: Authentisierte, vertrauliche Kommunikation zwischen VPN-Clients und -Server
\end{itemize}
\end{frame}

\begin{frame}{Anforderungen (2/3)}
\begin{itemize}
\item \textbf{Benutzer}: Beschäftigte und Studierende der Abteilung Informatik, Kapazität für 50-500 Benutzer
\item \textbf{Betrieb des VPN-Servers}: Debian~9 (oder höher) wird als Serverbetriebssystem vorgegeben
\item \textbf{Betrieb der VPN-Clients}: Moderne Versionen von Linux, MacOS und Windows sollen unterstützt werden
\end{itemize}
\end{frame}

\begin{frame}{Anforderungen (3/3)}
\begin{itemize}
\item \textbf{Betriebsprotokoll}: VPN-Dienst soll im Regelbetrieb DSGVO-konform protokollieren
\item \textbf{Finanzieller Rahmen}: Es steht kein Geld zur Verfügung
\end{itemize}
\end{frame}

\subsection{Überblick: Netzwerk der Abteilung Informatik}
\begin{frame}{Überblick: Netzwerk der Abteilung Informatik}
\begin{figure}[ht]
\centering
\includegraphics[width=\textwidth]{img/Netzwerktopologie_simpelv2_with_addresses.pdf}
\caption{Topologie des Abteilungsnetzes (vereinfachte Skizze)}
\end{figure}
\end{frame}


\section{Konzept}

\subsection{Entwurf der Architektur}
\begin{frame}{Entwurf der Architektur (1/2)}
\begin{itemize}
\item VPN-Server wird in DMZ-Netz platziert
\item VPN-Server ist Router zwischen VPN-Clients und Abteilungsnetz
\item VPN-Tunnel auf OSI-Schicht~3, transportiert IP-Pakete
\item IP-Adressen für VPN-Clients
\begin{itemize}
\item Private Adressen mit NAT für IPv4
\item Öffentliches Netz für IPv6
\end{itemize}
\item Lokale Firewall wird auf VPN-Server installiert
\end{itemize}
\end{frame}

\begin{frame}{Entwurf der Architektur (2/2)}
\begin{itemize}
\item VPN-Server und -Benutzer authentisieren sich mit Zertifikaten
\item PKI für Zertifikate wird auf separatem Server eingerichtet
\item VPN-Server blockiert gesperrte Benutzer mit Hilfe der CRL\footnote{\textit{Certificate Revocation List} (CRL)} der PKI
\item PKI-Server stellt CRL über Webserver zur Verfügung
\item Administratoren des VPN-Dienst erhalten SSH-Zugang zum PKI-Server
\item PKI-Server wird in Mitarbeiter-Netz platziert
\end{itemize}
\end{frame}

\subsection{Überblick: Geplante Architektur}
\begin{frame}{Überblick: Geplante Architektur}
\begin{figure}[ht]
\centering
\includegraphics[width=\textwidth]{img/VPN-Service-Concept.pdf}
\caption{Konzept zur Installation des VPN-Dienstes}
\end{figure}
\end{frame}


\section{Auswahl der VPN-Software}

\subsection{Betrachtete Kandidaten für VPN-Software}
\begin{frame}{Betrachtete Kandidaten für VPN-Software}
Als Serverbetriebssystem wurde Debian~9 vorgegeben. \\
$\rightarrow$ Debian-Paketquellen sind erste Anlaufstelle. \\
Einsatz von Kryptografie \\
$\rightarrow$ Implementation von kryptografischen Algorithmen soll quelloffen sein. \\
\ \\
Folgende Kandidaten wurden näher betrachtet:
\begin{itemize}
\item OpenVPN
\item StrongSwan (für IPsec-VPN)
\item Wireguard (zur Zeit experimentell, mehr dazu im Ausblick)
\end{itemize}
\end{frame}

\begin{frame}{OpenVPN}
\begin{itemize}
\item Läuft komplett im Benutzerkontext
\item Benutzt OpenSSL für kryptografische Operationen
\item Stellt VPN über virtuelle Netzwerkkarte zur 
Verfügung
\item Ist vollständig quelloffen
\item VPN-Clients für alle drei Betriebssysteme kompiliert verfügbar
\item Für Einsteiger leicht verständliche Konfiguration
\end{itemize}
\end{frame}

\begin{frame}{StrongSwan}
\begin{itemize}
\item Dienst für IKE\footnote{\textit{Internet Key Exchange Protocol} (IKE)}
\item Ermöglicht ein VPN auf Basis von IPsec
\item Ist vollständig quelloffen; IPsec wird aber im Kernel verarbeitet!
\item Installation und Einrichtung je nach Plattform unterschiedlich schwierig
\item Installation auf Windows mit Einschränkungen verbunden
\item Zu viel Flexibilität/Komplexität ermöglicht unsichere Konfigurationen
\end{itemize}
\end{frame}

\subsection{Auswahl der VPN-Software}
\begin{frame}{Auswahl der VPN-Software}
OpenVPN wird zur Umsetzung des VPN-Dienstes gewählt.
\begin{itemize}
\item Einfache Konfiguration im Vergleich zu IPsec/Strongswan
\item Vollständig quelloffene Verarbeitung des VPN-Verkehrs
\item Einheitliches Sicherheitsniveau über alle Plattformen garantierbar
\item Plattformübergreifend identische Konfiguration und Benutzbarkeit\footnote{Auf der Kommandozeile}
\item Zusätzliche grafische Oberflächen optional benutzbar
\end{itemize}
\end{frame}


\section{Installation und Konfiguration}

\subsection{Aspekte der OpenVPN-Konfiguration}
\begin{frame}{Aspekte der OpenVPN-Konfiguration}
\begin{itemize}
\item OpenVPN-Server gibt Routen für Netze der Abteilung vor
\item OpenVPN unterscheidet Kontrollkanal und Datenkanal 
\begin{itemize}
\item Beide sind für Vertraulichkeit gleichermaßen wichtig
\end{itemize}
\item Fest vorgegebene Kryptografie reduziert Fehleranfälligkeit durch Komplexität
\begin{itemize}
\item Nur korrekte Konfiguration führt zu einer VPN-Sitzung
\item Ungeschützte Sitzungen werden ausgeschlossen
\end{itemize}
\item CRL zum Blocken gesperrter Zertifikate wird über Cronjob aktualisiert
\end{itemize}
\end{frame}

\subsection{Überblick: Konkrete Architektur mit OpenVPN}
\begin{frame}{Überblick: Konkrete Architektur mit OpenVPN}
\begin{figure}[ht]
\centering
\includegraphics[width=\textwidth]{img/OpenVPN-Deployment.pdf}
\caption{Installation des IPv6-VPN mit OpenVPN und EasyRSA}
\label{fig:vpn_service_concept}
\end{figure}
\end{frame}


\section{Abschluss}

\subsection{Fazit}
\begin{frame}{Fazit}
\begin{itemize}
\item Der neue IPv6-VPN-Dienst kann benutzt werden (Testbetrieb)
\item Dokumentation für Installation und Administration ermöglichen Produktivbetrieb
\item Problemlose Erweiterbarkeit in Hinblick auf lokale Firewall und Routing neuer Netze
\item Fest vorgegebene Kryptografie verhindert unsichere Sitzungen bei Fehlkonfiguration
\item Gebrochene Kryptografie erfordert neue Konfiguration von VPN-Server und -Clients
\begin{itemize}
\item Wahrscheinlichkeit dafür wird als gering eingestuft
\end{itemize}
\end{itemize}
\end{frame}

\subsection{Ausblick}
\begin{frame}{Ausblick}
\begin{itemize}
\item OpenVPN~3 befindet sich in Entwicklung
\begin{itemize}
\item Modulare Ansatz in der Softwarearchitektur reduziert Risiken durch Sicherheitslücken
\item Kryptografie auf Basis elliptischer Kurven wird besser unterstützt
\end{itemize}
\item TLS~1.3 kann erprobt werden, sobald VPN-Server und -Clients es unterstützen
\begin{itemize}
\item Vollständiger Umstieg erfordert Unterstützung bei allen verwendeten VPN-Clients
\end{itemize}
\end{itemize}
\dots und dann gibt es noch Wireguard.
\end{frame}

\subsection{Wireguard: VPN-Software der Zukunft?}
\begin{frame}{Wireguard: VPN-Software der Zukunft?}
\begin{itemize}
\item Zur Zeit noch experimentelle Software
\item Implementation umfasst etwa 4000 Zeilen Quellcode als Linux-Kernelmodul
\item Implementationen in Go und Rust können auf anderen Betriebssystemen benutzt werden
\item Kryptografie im Quellcode fest vorgeschrieben
\item Unkomplizierte Administration
\item Effiziente Verarbeitung von VPN-Verkehr liefert hohen Datendurchsatz bei geringer CPU-Auslastung
\end{itemize}
\end{frame}

% The end.