diff --git a/MA-Inhalt.tex b/MA-Inhalt.tex index 44aa62e..aa75c9e 100644 --- a/MA-Inhalt.tex +++ b/MA-Inhalt.tex @@ -218,7 +218,7 @@ Alle kryptografische Operationen zur Verarbeitung des VPN-Datenverkehrs, sowie z \todo{Wenn Zeit übrig ist.} \subsection{OpenSSH} -\todo{Wenn Zeit übrig ist; TCP in TCP ist ein Problem wegen ECN, könnte unter Window nicht funktionieren?} +\todo{Wenn Zeit übrig ist; TCP in TCP ist ein Problem wegen ECN, könnte unter Windows nicht funktionieren?} \end{comment} @@ -330,7 +330,7 @@ Die Authentisierung von Benutzern anhand von Zertifikaten erfordert den Aufbau u Für die Benutzer ergibt sich ein zusätzlicher Aufwand durch das regelmäßige Beantragen von neuen Zertifikaten, sowie die Notwendigkeit der Anpassung der OpenVPN-Clientkonfiguration. Auch für den Systemadministrator ergibt sich dieser zusätzliche Aufwand in Bezug auf die regelmäßige Erneuerung des Serverzertifikats und der \textit{Certificate Revocation List} (CRL). Zusätzlich ist der Systemadministrator mit der Betreuung der \textit{Zertifizierungsstelle} (CA) beschäftigt, nimmt die Zertifikatsanträge der Benutzer entgegen, prüft diese und stellt Benutzerzertifikate aus. -Der daraus resultierende Aufwand erhöhts sich proportional zu der Anzahl der VPN-Benutzer. +Der daraus resultierende Aufwand erhöht sich proportional zu der Anzahl der VPN-Benutzer. Dennoch gibt es eine Reihe von Vorteilen, die diesen zusätzlichen Aufwand rechtfertigen: Zertifikate haben eine klar definierte Laufzeit, die bei Ausstellung des Zertifikates festgelegt wird. @@ -348,7 +348,7 @@ Unter Abwägung dieser Vor- und Nachteile werden im Rahmen dieser Arbeit Zertifi \section{Zertifikatgestützte Benutzerauthentisierung} \label{sct:ca_concept} Die VPN-Software OpenVPN bringt OpenSSL als Abhängigkeit mit. -OpenSSL stellt eine Menge von Funktionen als Kommandozeilenwerkzeug zur Verfügung, mit denen alle Basisfunktionen einer Zertifizierungsstelle wie zum Beipiel die Erzeugung von Schlüssel\-paaren und Zertifikatsanträgen, sowie das Ausstellen von Zertifikaten auf Basis von Zertifikatsanträgen möglich ist. +OpenSSL stellt eine Menge von Funktionen als Kommandozeilenwerkzeug zur Verfügung, mit denen alle Basisfunktionen einer Zertifizierungsstelle wie zum Beispiel die Erzeugung von Schlüssel\-paaren und Zertifikatsanträgen, sowie das Ausstellen von Zertifikaten auf Basis von Zertifikatsanträgen möglich ist. Im Prinzip ist es möglich, durch manuelle Bedienung von OpenSSL eine \textit{Zertifizierungsstelle} (CA) zu betreiben. Diese Vorgehensweise verlangt jedoch Fachwissen und Sorgfalt von den Betreibern der CA und eignet sich aufgrund des hohen Aufwands nur für die Verwaltung weniger Benutzer oder zu Zwecken der Lehre. @@ -465,8 +465,8 @@ Neben dem Wurzelzertifikat der CA und der aktuellen CRL benötigen Benutzer eine Um diese Daten zur Verfügung zu stellen, wird auf der virtuellen Maschine der Webserver \texttt{apache2} installiert, welcher ausschließlich das für diesen Zweck erzeugte Verzeichnis \texttt{/public} über HTTP ausliefern soll. Alle in \texttt{/public} platzierten Dateien und Verzeichnisse gehören dem Benutzer \texttt{root} und der Gruppe \texttt{root}. -Alle Dateien werden mit den Dateirechten \texttt{444} versehen, Verzeichnisse erhalten die Rechtemaske \texttt{555}. -Dadurch werden Manipulationen durch nichtprivilegierte, lokale Benutzer verhindert. +Alle Dateien werden mit den Dateirechten \texttt{444} versehen, Verzeichnisse erhalten die Dateirechte \texttt{555}. +Dadurch werden Manipulationen durch nicht privilegierte, lokale Benutzer verhindert. Gleichzeitig signalisieren die Dateirechte, dass die Inhalte unter \texttt{/public} nur durch \texttt{root} verändert werden dürfen und für alle anderen lediglich lesbar zur Verfügung stehen sollen. Die Veröffentlichung von Konfigurationsdateien und Anleitungen für VPN-Benutzer kann über diesen Webserver ebenfalls stattfinden. @@ -488,13 +488,13 @@ Aus diesen Gründen fällt die Wahl auf VPN-Tunnel auf OSI-Layer~3. \paragraph{Netzwerkkonfiguration} Da der OpenVPN-Dienst aus dem Internet heraus erreichbar sein soll, wird der Server an das DMZ-Netz angeschlossen. Das IT-Team hat dafür insgesamt vier IPv4- und IPv6-Adressen vergeben, um den Server und den darauf existierenden Dienst logisch zu trennen. -Über die vergebenen IPv4- und IPv6-Hostadressen kann der phyische Server angesprochen werden, um zum Beispiel für administrative Aufgaben eine SSH-Sitzung zu dem Server aufzubauen. +Über die vergebenen IPv4- und IPv6-Hostadressen kann der physische Server angesprochen werden, um zum Beispiel für administrative Aufgaben eine SSH-Sitzung zu dem Server aufzubauen. Über ein weiteres Paar von IP-Dienstadressen wird der eigentliche OpenVPN-Dienst zur Verfügung gestellt. Um Datenverkehr zwischen den VPN-Clients und dem Netz der Abteilung Informatik routen zu können, wird für IPv4 und IPv6 jeweils ein IP-Adressbereich benötigt, aus dem die VPN-Clients ihre Clientadressen zugewiesen bekommen können. Für IPv4 wurde das private Netz \texttt{10.2.0.0/16} durch das IT-Team vergeben. Für IPv6 wurde das Netz \texttt{2001:638:614:1750::/64} vergeben, welches durch die Firewall der Abteilung Informatik an die zuvor vergebene IPv6-Dienstadresse geroutet wird. -Damit VPN-Clients über IPv4 mit dem Abteilungsnetz kommunizieren können, wird der private IPv4-Adressebereich für die VPN-Clients durch den VPN-Server via \textit{Network Address Translation} (NAT) auf die IPv4-Dienstadresse übersetzt. +Damit VPN-Clients über IPv4 mit dem Abteilungsnetz kommunizieren können, wird der private IPv4-Adressbereich für die VPN-Clients durch den VPN-Server via \textit{Network Address Translation} (NAT) auf die IPv4-Dienstadresse übersetzt. \paragraph{Failover} Durch die Unterscheidung zwischen physischem Server und Dienst bezüglich der vergebenen IP-Adressen kann ein manuelles Failover zwischen zwei identisch konfigurierten Servern (in diesem Beispiel A und B genannt) durchgeführt werden. @@ -608,7 +608,7 @@ Um die in Kapitel~\ref{cpt:user_concept} konzipierte Zertifizierungsstelle zur B In der \textbf{Clientkonfiguration} wird dafür der Parameter \texttt{tls-client} gesetzt, in der \textbf{Serverkonfiguration} wird analog dazu der Parameter \texttt{tls-server} verwendet. Anschließend werden in der \textbf{Client- und Serverkonfiguration} über die Parameter \texttt{ca}, \texttt{cert} und \texttt{key} Dateipfade konfiguriert, unter denen das Wurzelzertifikat, das Client- beziehungsweise Serverzertifikat und der dazugehörige private Schlüssel abgelegt sind. -In der \textbf{Serverkonfiguration} werden zusätzlich über die Parameter \texttt{dh} und \texttt{crl-verify} Dateipfade angegeben, unter dene die im Voraus berechneten Parameter für den Diffie-Hellman-Schlüsselaustausch und die aktuelle Kopie der von der CA herausgegebenen CRL abgespeichert sind. +In der \textbf{Serverkonfiguration} werden zusätzlich über die Parameter \texttt{dh} und \texttt{crl-verify} Dateipfade angegeben, unter denen die im Voraus berechneten Parameter für den Diffie-Hellman-Schlüsselaustausch und die aktuelle Kopie der von der CA herausgegebenen CRL abgespeichert sind. \begin{lstlisting} ca inform/ca.crt cert inform/aither.inform.hs-hannover.de.crt @@ -639,7 +639,7 @@ tls-version-min "1.2" \end{lstlisting} Aus der Liste der in RFC~7525 empfohlenen Chiffren \cite[][Abschnitt 4.2]{RFC7525} wird die TLS-Chiffre TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 gewählt. -Diese Chiffre verwendet \textit{Ephemeral Diffie Hellman} (DHE) für den Schlüsselaustausch \cite[][Abschnitt A.5]{RFC5246}, RSA als Signaturalgorithmus zur Authentisierung \cite[][Abschnitt A.5]{RFC5246}, AES-256-GCM für die Verschlüsselung und SHA384 als Funktion für Peudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC) \cite[][Kapitel 5]{RFC5246}. +Diese Chiffre verwendet \textit{Ephemeral Diffie Hellman} (DHE) für den Schlüsselaustausch \cite[][Abschnitt A.5]{RFC5246}, RSA als Signaturalgorithmus zur Authentisierung \cite[][Abschnitt A.5]{RFC5246}, AES-256-GCM für die Verschlüsselung und SHA384 als Funktion für Pseudozufallszahlen für den \textit{Keyed-Hash Message Authentication Code} (HMAC) \cite[][Kapitel 5]{RFC5246}. Durch die Verwendung von DHE kann \textit{Perfect Forward Secrecy} (PFS) gewährleistet werden \cite[][Abschnitt F.1.1.2]{RFC5246}. @@ -654,7 +654,7 @@ Somit wird die zuvor genannte TLS-Chiffre mit DHE-Verfahren verwendet: tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 \end{lstlisting} -OpenVPN verwendet einen HMAC mit einem zuvor ausgetauschen, gemeinsamen Geheimnis um für Daten- und Kontrollkanal eingehende Datenpakete vor ihrer Verarbeitung zu authentisieren. +OpenVPN verwendet einen HMAC mit einem zuvor ausgetauschtem, gemeinsamen Geheimnis um für Daten- und Kontrollkanal eingehende Datenpakete vor ihrer Verarbeitung zu authentisieren. Die im HMAC als Quelle für Pseudozufallszahlen verwendete Hashfunktion wird auf SHA-256 festgelegt, weil SHA-1, trotz seiner weiterhin bestehenden theoretischen Eignung zur Verwendung in einem HMAC, laut BSI nicht mehr verwendet werden sollte \cite[][Abschnitt 1.4, Punkt 3]{bsi:tr-02102-1}. \begin{lstlisting} @@ -722,17 +722,17 @@ group nogroup \end{lstlisting} Für die \textbf{Clientkonfiguration} kann es sinnvoll sein, dass OpenVPN das Passwort, mit dem ein privater Schlüssel geschützt wurde, nicht im Speicher behält. -Mit der folgenden Option kann OpenVPN gezwungen werden, ein solches Passwort nicht im Spicher zu halten. +Mit der folgenden Option kann OpenVPN gezwungen werden, ein solches Passwort nicht im Speicher zu halten. \begin{lstlisting} auth-nocache \end{lstlisting} \paragraph{Protokollierung} Um die Gesprächigkeit von OpenVPN zu steuern, können in der \textbf{Client- und Serverkonfiguration} die Parameter \texttt{verb} und \texttt{mute} verwendet werden. -Der Parameter \texttt{verb} steuert dabei den Detailgrad der protokollierten Meldungen über einen Bereit von 0 (keine Meldungen) über 1-4 (normale Meldungen), 5 (Für jedes verarbeitete Paket wird ein Buchstabe in das Log geschrieben) bis hin zu 6-11 (Für Debugging in der Entwicklung). +Der Parameter \texttt{verb} steuert dabei den Detailgrad der protokollierten Meldungen über einen Bereit von 0 (keine Meldungen) über 1-4 (normale Meldungen), 5 (Für jedes verarbeitete Paket wird ein Buchstabe in das Log geschrieben) bis hin zu 6-11 (Für Fehlersuche in der Entwicklung). Standardmäßig wird der Wert 1 verwendet; der Wert 3 wird für übersichtliche Protokolle mit mehr Informationen empfohlen. Der Parameter \texttt{mute} gibt an, wie viele aufeinander folgende Nachrichten aus der selben Kategorie protokolliert werden sollen. -Damit können aufeinanderfolgende, ähnliche Nachrichten unterdrückt werden, die sich wiederholen. +Damit können aufeinander folgende, ähnliche Nachrichten unterdrückt werden, die sich wiederholen. Um einen guten Überblick zu erhalten, werden die folgenden Parameter gewählt: \begin{lstlisting} verb 3