Autosave

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}
+\chapter{Konzeption des VPN-Servers} \label{cpt:concept_vpn_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.
+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}
+Absprachen mit IT-Team, Server nach Vorgaben installiert und in DMZ platziert.
-\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}
+
+\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?