JPT
/
masterthesis
0
0
Fork 0
Code Issues Pull Requests Activity

Corrections

This commit is contained in:
Jan Philipp Timme 2018-11-06 13:03:19 +01:00
parent 7d5b52f967
commit 51bab1a3ba
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
MA-Inhalt.tex
View File

@ -33,7 +33,7 @@ Die während der Durchführung dieser Arbeit erzeugten Dokumente sind dem Anhang
\chapter{Arbeitsauftrag} \label{cpt:the_task}
Die Abteilung Informatik betreibt einen VPN-Dienst auf Basis von OpenVPN, der von Beschäftigten und Studierenden benutzt werden kann, um über das Internet auf das Netz der Abteilung Informatik zuzugreifen.
Dieser Dienst ist bisher nur über IPv4 erreichbar und ermöglicht auch nur über IPv4 den Zugriff auf das Netz der Abteilung Informatik durch das VPN.
Dieser Dienst ist bisher nur über IPv4 erreichbar, und ermöglicht auch nur über IPv4 den Zugriff auf das Netz der Abteilung Informatik durch das VPN.
\paragraph{VPN:} \label{par:explain_vpn}
Hinter der Abkürzung \enquote{VPN} verbirgt sich der Begriff \textit{Virtual Private Network}.
@ -66,6 +66,7 @@ Es handelt sich hier um Vorgaben, die im persönlichen Gespräch mit dem Auftrag
\item \label{req:dualstack} \textbf{Dual-Stack-Betrieb:} Der VPN-Dienst soll aus dem Internet über IPv4 und IPv6 erreichbar sein und auch innerhalb des VPN diese beiden Protokolle anbieten.
\item \label{req:routing} \textbf{VPN-interner Datenverkehr:} Nur die internen Netzbereiche der Abteilung Informatik sollen für Benutzer über das VPN erreichbar sein.
Das betrifft alle Sicherheitszonen außer dem Internet.
Neue Verbindungen aus allen Sicherheitszonen in das VPN-Netz sind verboten.
VPN-Clients dürfen nicht im VPN untereinander kommunizieren.
VPN-Clients dürfen durch das VPN nicht auf NFS\footnote{\textit{Network File System} (NFS) ist ein Dienst für netzwerkübergreifenden Dateiaustausch}-Dienste zugreifen.
\item \label{req:traffic} \textbf{VPN-externer Datenverkehr:} Die Kommunikation zwischen VPN-Client und VPN-Server soll authentisiert und vertraulich stattfinden.
@ -168,7 +169,7 @@ Damit nur Benutzer den VPN-Zugang benutzen können, die als Beschäftigte oder S
Die Details zur Authentisierung von Benutzern und der Verwaltung autorisierter Benutzer werden in Kapitel~\ref{sct:user_concept} behandelt.
Vor der Benutherauthentisierung muss sich der VPN-Server gegenüber dem VPN-Client authentisieren, damit bei der Benutzerauthentisierung übertragene Zugangsdaten nur durch den VPN-Server der Abteilung Informatik empfangen und verarbeitet werden.
Das Ausspähen von VPN-Zugangsdaten durch einen Angreifer wird somit verhindert, weil sich ein Angreifer gegenüber VPN-Clients nicht mehr als VPN-Server der Abteilung Informatik ausgeben kann.
Das Ausspähen von VPN-Zugangsdaten durch einen Angreifer wird somit verhindert, weil sich ein Angreifer gegenüber VPN-Clients nicht mehr als VPN-Server der Abteilung Informatik ausgeben kann, ohne sich vorher erfolgreich als VPN-Server zu authentisieren.
Zusätzlich verhindert diese Maßnahme, dass VPN-Clients eine VPN-Sitzung zu dem VPN-Server eines Angreifers aufbauen können - Angriffe gegen Clientrechner durch den VPN-Tunnel stellen in diesem Kontext keine Bedrohung dar.
Die Authentisierung des VPN-Servers könnte über ein zuvor geteiltes, gemeinsames Geheimnis durchgeführt werden.
@ -176,9 +177,9 @@ Diese Vorgehensweise ist jedoch nicht sinnvoll, da der VPN-Dienst für mindesten
Unter diesem Umstand ist ein allen Benutzern bekanntes, gemeinsames Geheimnis für einen Angreifer leichter in Erfahrung zu bringen, je mehr Benutzer dieses Geheimnis kennen.
Deshalb soll die Authentisierung des VPN-Servers gegenüber den VPN-Clients mit X.509-Public-Key-Zertifikaten durchgeführt werden.
Die Kommunikation innerhalb des VPN soll auf OSI-Schicht~3 stattfinden, da lediglich IPv4- und IPv6-Datenverkehr durch das VPN übertragen werden soll (\ref{req:routing}).
Die Kommunikation innerhalb des VPNs soll auf OSI-Schicht~3 stattfinden, da lediglich IPv4- und IPv6-Datenverkehr durch das VPN übertragen werden soll (\ref{req:routing}).
Sonstige Protokolle auf OSI-Schicht~2 und 3 werden nicht benötigt.
Die Übertragung von Ethernet-Frames durch den VPN-Tunnel ist nicht notwendig, und würde durch unnötige Datenübertragung nur Netzwerkauslastung verursachen.
Die Übertragung von Ethernet-Frames durch den VPN-Tunnel ist nicht notwendig, und würde durch unnötige Datenübertragung nur zusätzliche Netzwerklast verursachen.
Für die IP-Netze der Abteilung Informatik, die über das VPN erreichbar sein sollen (\ref{req:routing}), werden für die Dauer der VPN-Sitzung Einträge in der Routingtabelle des Clients erzeugt.
IP-Pakete, die der Client an Computer im Abteilungsnetz schickt, sollen so durch den VPN-Tunnel geroutet werden.
@ -189,22 +190,22 @@ Da diese Konfiguration nur durch die Administratoren der Router vorgenommen wird
Deshalb werden in Absprache mit dem IT-Team der Abteilung Informatik ein IPv4- und ein IPv6-Netz gewählt, aus denen die Clients VPN-interne IP-Adressen vom Server erhalten.
Die Konfiguration von Routen für die beiden IP-Netze ist dadurch unabhängig von individuellen VPN-Sitzungen und kann einmalig vorgenommen werden.
Da keine öffentliche IPv4-Netze für diesen Zweck verfügbar sind, wird ein Netz aus dem privaten Adressbereich \texttt{10.0.0.0/8} gewählt.
Da keine öffentlichen IPv4-Netze für diesen Zweck verfügbar sind, wird ein Netz aus dem privaten Adressbereich \texttt{10.0.0.0/8} gewählt.
Weil IP-Adressen aus diesem privaten Bereich nicht geroutet werden sollen, führt der VPN-Server \textit{Network Address Translation} (NAT) durch.
IPv4-Datenverkehr von VPN-Clients ins Abteilungsnetz trägt somit die öffentliche IPv4-Adresse des VPN-Servers.
Dazugehörige Antwortpakete können dadurch zurück zum VPN-Server geroutet werden, welche diese nach der NAT-Übersetzung an den richtigen VPN-Client weiterleitet.
Dazugehörige Antwortpakete können dadurch zurück zum VPN-Server geroutet werden, welcher diese nach der NAT-Übersetzung an den richtigen VPN-Client weiterleitet.
Für IPv6 wurde ein \texttt{/64}-Netz aus dem Bereich \texttt{2001:638:614:1700::/56} gewählt.
Die Router im Abteilungsnetz wurden konfiguriert, Pakete an Hosts in diesem Netz an die öffentliche IPv6-Adresse des VPN-Servers weiterleiten.
Damit die VPN-Clients über das VPN nicht untereinander kommunizieren können, und der NFS-Dienst über das VPN nicht benutzt werden kann (\ref{req:routing}), soll eine lokale Firewall auf dem VPN-Server eingerichtet werden, die diese Regeln umsetzt.
Damit keine Verbindungen aus allen Sicherheitszonen zu VPN-Clients möglich sind, die VPN-Clients über das VPN nicht untereinander kommunizieren können, und der NFS-Dienst über das VPN nicht benutzt werden kann (\ref{req:routing}), soll eine lokale Firewall auf dem VPN-Server eingerichtet werden, die alle Regeln aus \ref{req:routing} umsetzt.
Damit die Kommunikation zwischen VPN-Clients und VPN-Server vertraulich bleibt (\ref{req:traffic}), soll der Datenverkehr zwischen Client und Server mit modernen Chiffren verschlüsselt werden.
Um \textit{Perfect Forward Secrecy} (PFS) zu errreichen, soll beim Aufbau der VPN-Sitzung ein entsprechend geeignetes Verfahren zum Schlüsselaustausch verwendet werden, sodass die ausgehandelten Sitzungsschlüssel im Nachhinein nicht rekonstruiert werden können.
Die Protokolleinstellungen des VPN-Servers sollen vor der Inbetriebnahme so angepasst werden, dass nach DSGVO keine personenbezogenen Daten protokolliert werden (\ref{req:logging}).
Um die Wartbarkeit des VPN-Dienst zu erhöhen, sollen bei der Installation und Konfiguration des VPN-Servers (und gegebenenfalls zusätzlicher Server) die existierenden Konzepte des IT-Teams zum Betrieb von Servern berücksichtigt werden.
Um die Wartbarkeit des VPN-Dienstes zu erhöhen, sollen bei der Installation und Konfiguration des VPN-Servers (und gegebenenfalls zusätzlicher Server) die existierenden Konzepte des IT-Teams zum Betrieb von Servern berücksichtigt werden.
Um das in diesem Abschnitt beschriebene Konzept umzusetzen, soll eine passende VPN-Software gewählt werden, deren Serverkomponente auf Debian~9 läuft (\ref{req:serveros}), und für die kompatible Clientkomponenten auf allen gängigen Betriebssystemen (\ref{req:clientos}) verfügbar sind.