Autosave
This commit is contained in:
parent
a274b8c33a
commit
e6032ba590
|
|
@ -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?
|
||||
|
|
|
|||
Loading…
Reference in New Issue