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…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user