unify markup for abreviated terms
This commit is contained in:
parent
706b3c670e
commit
6bb9bbe3f7
|
@ -24,7 +24,7 @@ In der darauf folgenden Konzeptphase werden zunächst grundlegende, lösungsunab
|
|||
|
||||
\chapter{Netzarchitektur der Abteilung Informatik} \label{cpt:netarchitecture}
|
||||
Das Netz der Abteilung Informatik wird durch eine Firewall vom Netz der Hochschule Hannover und dem Internet getrennt.
|
||||
An der Firewall sind zwei lokale Netze angeschlossen: Die Demilitarisierte Zone (DMZ) und das interne Abteilungsnetz, welches durch einen zentralen Switch in mehrere virtuelle Netze (VLANs) unterteilt wird.
|
||||
An der Firewall sind zwei lokale Netze angeschlossen: Die \textit{Demilitarisierte Zone} (DMZ) und das interne Abteilungsnetz, welches durch einen zentralen Switch in mehrere \textit{virtuelle Netze} (VLANs) unterteilt wird.
|
||||
Zusätzlich sind die Netze des Netzwerklabors und des IT-Sicherheitslabors über je einen eigenen Router an den Switch angeschlossen.
|
||||
Eine Skizze der Netztopologie mit den für diese Arbeit relevanten Teilen ist in Abbildung~\ref{fig:topology_simple} zu sehen.
|
||||
\begin{figure}[ht]
|
||||
|
@ -150,14 +150,14 @@ Das beinhaltet unter anderem Vertraulichkeit übertragener Daten durch den Einsa
|
|||
Mit IPsec können Richtlinien definiert werden, ob und wie Datenverkehr von einem Host zu einem anderen Host geschützt werden soll.
|
||||
Zum Schutz des Datenverkehrs können die Protokolle AH und ESP benutzt werden, die in den folgenden Absätzen kurz vorgestellt werden.
|
||||
|
||||
Das Protokoll \enquote{IP Authentication Header} (AH) ist in \cite[][]{RFC4302} definiert und ermöglicht den Versand von authentisierbaren Paketen an eine Gegenstelle.
|
||||
Das Protokoll \textit{IP Authentication Header} (AH) ist in \cite[][]{RFC4302} definiert und ermöglicht den Versand von authentisierbaren Paketen an eine Gegenstelle.
|
||||
Vor dem Versand wird über den Inhalt der beim Transport unveränderlichen Felder des IP-Pakets eine Prüf\-sum\-me gebildet.
|
||||
Die Gegenstelle kann die Prüfsumme des empfangenen Pakets berechnen und mit der im Paket enthaltenen Prüfsumme abgleichen \cite[Siehe][Kapitel 3.3.3]{RFC4302}.
|
||||
Die Funktion zur Berechnung der Prüfsumme wird nicht explizit definiert und kann daher anhand der zur Zeit aktuellen Vorgaben \cite[definiert in][]{RFC8221} gewählt werden.
|
||||
Abhängig von der gewählten Funktion fließen bereits im Vorfeld ausgehandelte gemeinsame Geheimnisse oder Signaturalgorithmen in die Berechnung der Prüfsumme ein, sodass eine korrekte Prüfsumme ein Paket authentisiert.
|
||||
Eine Verschlüsselung der Paketinhalte ist im AH-Protokoll nicht vorgesehen.
|
||||
|
||||
Das Protokoll \enquote{IP Encapsulating Security Payload} (ESP) ist in \cite[][]{RFC4303} definiert und ermöglicht den Versand von Paketen mit vertraulichen Inhalten an eine Gegenstelle.
|
||||
Das Protokoll \textit{IP Encapsulating Security Payload} (ESP) ist in \cite[][]{RFC4303} definiert und ermöglicht den Versand von Paketen mit vertraulichen Inhalten an eine Gegenstelle.
|
||||
Ähnlich wie bei dem AH-Protokoll ist auch im ESP-Protokoll die Authentisierung von Paketen mit einer Prüfsumme vorgesehen \cite[Siehe][Kapitel 2.8]{RFC4303}.
|
||||
Aktuell empfohlene Algorithmen zum Berechnen der Prüfsumme oder zum Verschlüsseln der Paketinhalte sind in \cite[][]{RFC8221} aufgeführt.
|
||||
Durch die Verschlüsselung der Paketinhalte vor dem Transport wird die Vertraulichkeit der übertragenen Inhalte gewährleistet.
|
||||
|
@ -201,7 +201,7 @@ Der Kontrollkanal wird zur Kommunikation zwischen zwei OpenVPN-Prozessen verwend
|
|||
|
||||
Im \enquote{TLS Mode} wird über den Kontrollkanal eine TLS-Sitzung aufgebaut, in der Chiffren und Schlüssel ausgetauscht werden, mit denen der Datenkanal geschützt werden soll.
|
||||
Dadurch ist die Authentisierung von Client und Server mit X.509-Public-Key-Zertifikaten\footnote{X.509-Public-Key-Zertifikate werden oft als \enquote{SSL-Zertifikate} bezeichnet} möglich.
|
||||
Zusätzlich kann Perfect Forward Secrecy durch Einsatz des Diffie-Hellman-Verfahren für den Schlüsselaustausch erreicht werden \cite[Vergleich][Abschnitt \enquote{TLS Mode Options}]{man:openvpn}.
|
||||
Zusätzlich kann \textit{Perfect Forward Secrecy} (PFS) durch Einsatz des Diffie-Hellman-Verfahren für den Schlüsselaustausch erreicht werden \cite[Vergleich][Abschnitt \enquote{TLS Mode Options}]{man:openvpn}.
|
||||
Außerdem können die zur Verschlüsselung des Datenkanals ausgehandelten Schlüssel während der Sitzung mehrfach erneuert werden.
|
||||
|
||||
Im \enquote{Static Key Mode} wird beiden Prozessen beim Start ein zuvor geteiltes gemeinsames Geheimnis als Parameter gegeben, mit dem der Datenkanal zwischen den beiden Prozessen symmetrisch verschlüsselt wird \cite[][\texttt{--secret}]{man:openvpn}.
|
||||
|
@ -228,7 +228,7 @@ Die zuvor vorgestellten VPN-Softwarelösungen werden nun in den folgenden Katego
|
|||
OpenVPN kommuniziert über ein eigenes Protokoll auf über UDP (oder in Ausnahmefällen über TCP) auf Port~1194.
|
||||
Eine Trennung zwischen Kontrollnachrichten und Datenübertragung erfolgt innerhalb der Software.
|
||||
|
||||
Strongswan kommuniziert mit kompatiblen Gegenstellen über das IKEv2-Protokoll, welches über UDP auf Port~500 (bei stattfindender Network Address Translation (NAT) auf Port~4500) übertragen wird.
|
||||
Strongswan kommuniziert mit kompatiblen Gegenstellen über das IKEv2-Protokoll, welches über UDP auf Port~500 (bei stattfindender \textit{Network Address Translation} (NAT) auf Port~4500) übertragen wird.
|
||||
Der durch IPsec geschützte Datenverkehr lässt sich daran erkennen, dass in den übertragenen IPv4- beziehungsweise IPv6-Paketen das Protokoll AH oder ESP enthalten ist.
|
||||
|
||||
Für die Freigabe von IPsec-Datenverkehr in einer Firewall sind somit mehrere Regeln notwendig, während die Freigabe von OpenVPN-Verkehr über UDP-Port~1194 übersichtlicher ausfällt.
|
||||
|
@ -328,7 +328,7 @@ Da die Abwesenheit von Schwachstellen in Quellcode nicht garantiert werden kann,
|
|||
Die Authentisierung von Benutzern anhand von Zertifikaten erfordert den Aufbau und die Verwaltung einer \textit{Public-Key-Infrastructure} (PKI) und bringt somit erst einmal eine Reihe Nachteile mit sich:
|
||||
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 Zertifizierungsstelle (CA) beschäftigt, nimmt die Zertifikatsanträge der Benutzer entgegen, prüft diese und stellt Benutzerzertifikate aus.
|
||||
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.
|
||||
|
||||
Dennoch gibt es eine Reihe von Vorteilen, die diesen zusätzlichen Aufwand rechtfertigen:
|
||||
|
@ -366,7 +366,7 @@ Die Notwendigkeit zum selbstständigen Entwickeln von Skripten zum Erreichen ein
|
|||
Das über Debian~9 beziehbare Paket enthält EasyRSA in Version~2.3.x.
|
||||
Die zum aktuellen Zeitpunkt (01.10.2018) über GitHub\footnote{\url{https://github.com/OpenVPN/easy-rsa/releases/tag/v3.0.5}} beziehbare Version von EasyRSA trägt die Nummer 3.0.5.
|
||||
EasyRSA wurde in Version~3 von Grund auf neu geschrieben und verfügt über ein im Vergleich zu EasyRSA Version~2 vereinfachtem Benutzerinterface, welches nun von einem einzigen Kommandozeilenbefehl zur Verfügung gestellt wird.
|
||||
Zusätzlich hinzugekommen sind neue Features wie etwa die Unterstützung des Elliptic-Curve-Kryptosystems, Unterstützung von UTF-8 oder die Verwendung von AES256 zum Verschlüsseln von privaten Schlüsseln\footnote{Vergleich \url{https://github.com/OpenVPN/easy-rsa/blob/v3.0.5/ChangeLog}}.
|
||||
Zusätzlich hinzugekommen sind neue Features wie etwa die Unterstützung des \textit{Elliptische-Kurven-Kryptosystems} (EKK), Unterstützung von UTF-8 oder die Verwendung von AES256 zum Verschlüsseln von privaten Schlüsseln\footnote{Vergleich \url{https://github.com/OpenVPN/easy-rsa/blob/v3.0.5/ChangeLog}}.
|
||||
|
||||
Die Installation von EasyRSA wird durch das Kopieren sämtlicher Dateien von EasyRSA in ein neues Verzeichnis durchgeführt.
|
||||
Eine auf diese Weise eingerichtete CA kann aus diesem Grund nicht durch den Debian-Paketmanager mit Updates versorgt werden.
|
||||
|
@ -423,7 +423,7 @@ Im Modus \enquote{org} wird ein \texttt{Distinguished Name} in dem \texttt{Subje
|
|||
Laut Vorgaben soll der volle Name und die Hochschul-E-Mail-Adresse der Benutzer in den Clientzertifikaten abgelegt werden.
|
||||
Somit muss EasyRSA auf den Modus \enquote{org} eingestellt werden.
|
||||
Für Clientzertifikate wird festgelegt, dass der volle Name im Feld \texttt{Common Name} abgelegt wird, und die E-Mail-Adresse im Feld \texttt{Email Address}.
|
||||
Für Serverzertifikate wird festgelegt, dass der vollqualifizierte Domainname (FQDN) im Feld \texttt{Common Name} abgelegt wird.
|
||||
Für Serverzertifikate wird festgelegt, dass der \textit{vollqualifizierte Domainname} (FQDN) im Feld \texttt{Common Name} abgelegt wird.
|
||||
Das Feld \texttt{Email Address} wird mit der Hochschul-E-Mail-Adresse der für den Server zuständigen Administratoren gefüllt.
|
||||
Für alle weiteren Felder werden folgende Vorgaben festgelegt:
|
||||
\texttt{Country}: \enquote{DE},
|
||||
|
|
Loading…
Reference in New Issue