From e6032ba590527271b62ff3e1c4e75a75118d8f5b Mon Sep 17 00:00:00 2001 From: Jan Philipp Timme Date: Tue, 9 Oct 2018 13:37:38 +0200 Subject: [PATCH] Autosave --- MA-Inhalt.tex | 55 +++++++++++++++++++++++---------------------------- 1 file changed, 25 insertions(+), 30 deletions(-) diff --git a/MA-Inhalt.tex b/MA-Inhalt.tex index 4baf0d4..e8e53a1 100644 --- a/MA-Inhalt.tex +++ b/MA-Inhalt.tex @@ -437,7 +437,7 @@ Um auch bei manueller Installation der CRL einen unterbrechungsfreien Betrieb de \section{Betriebskonzept für die Zertifizierungsstelle} \label{sct:running_ca} -Für den Betrieb der Zertifizierungsstelle wird in Absprache mit dem IT-Team eine virtuelle Maschine exklusiv für diesen Zweck erzeugt. +Für den Betrieb der Zertifizierungsstelle wird in Absprache mit dem IT-Team eine virtuelle Maschine exklusiv für diesen Zweck erzeugt und im Mitarbeiter-Netz platziert. Unter Berücksichtigung der Anforderung \ref{req:serveros} aus Abschnitt~\ref{sct:requirements} wird Debian 9 nach den Vorgaben des IT-Teams auf der virtuellen Maschine installiert. Das EasyRSA-Paket wird unterhalb von \texttt{/root} ausgepackt und für den Einsatz als CA für den VPN-Dienst konfiguriert. @@ -465,39 +465,41 @@ Die Veröffentlichung von Konfigurationsdateien und Anleitungen für VPN-Benutze Damit der OpenVPN-Server immer Zugriff auf eine aktuelle CRL hat, wird ein Cronjob via \texttt{crontab -e} unter dem Benutzer \texttt{root} eingerichtet, der über die EasyRSA-Skripte eine neue CRL erzeugt und diese anschließend mit den zuvor erläuterten Dateirechten in \texttt{/public} platziert. -\chapter{Einrichtung des VPN-Servers} \label{cpt:setup_server} -Nachdem das Konzept für die Benutzerverwaltung für den VPN-Dienst fertiggestellt ist und die zu verwendende VPN-Software gewählt wurde, kann nun mit der Einrichtung des VPN-Servers begonnen werden. +\chapter{Konzeption des VPN-Servers} \label{cpt:concept_vpn_server} +In diesem Kapitel soll die Umsetzung des IPv6-VPN-Dienst mit OpenVPN konzipiert werden. -\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} +Absprachen mit IT-Team, Server nach Vorgaben installiert und in DMZ platziert. -\section{Erstellung der OpenVPN-Konfiguration} + +\paragraph{Netzwerkkonfiguration} +IP-Adressen für Maschine und für Dienst getrennt +Routing: Neues IPv6-Netz durch FW-INFORM an Dienst-Adresse geroutet +IPv4: VPN-Clients bekommen IP-Adressen aus 10.2.0.0/16 Block, für IPv4 wird auf NAT zurückgegriffen + +\paragraph{Failover} +Dienst-IP-Adresse wird manuell auf A deaktiviert und auf B aktiviert um ein simples Failover bei identischer Konfiguration von zwei Maschinen zu erreichen. +Alternativ wäre ein weiteres IPv6-Netz fällig, wenn beide Maschinen parallel betrieben werden sollen. In dem Fall würde der OpenVPN-Client das Failover durchführen. + +\paragraph{Firewall} +Lokale Firewall setzt folgende Regeln um +* Zugriffe über das DMZ-Netz nur über SSH (tcp/22) und OpenVPN (udp/1194) erlaubt. +* Der Server selbst darf alles nach außen +* NAT für IPv4-VPN-Clients +* Isolation von VPN-Clients untereinander + + +\section{Konfiguration von OpenVPN} 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. +\paragraph{Kompression} 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: +\paragraph{Absicherung der Kommunikation} Wir sprechen nur TLS~1.2 oder höher. \begin{lstlisting} tls-version-min "1.2" @@ -518,13 +520,6 @@ 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?