Corrections
This commit is contained in:
parent
de1dd8bb53
commit
0f08add744
|
@ -333,9 +333,9 @@ Diese Kommunikation zwischen Clientcomputern im Internet und dem VPN-Server im D
|
|||
|
||||
\chapter{Softwareauswahl} \label{cpt:choosing_software}
|
||||
Das Umfeld, in dem der VPN-Dienst errichtet werden soll, wurde in Kapitel~\ref{cpt:netarchitecture} bereits vorgestellt.
|
||||
In diesem Kapitel wird die Software ausgesucht, mit der der VPN-Dienst umgesetzt werden soll.
|
||||
In diesem Kapitel wird die Software ausgesucht, mit welcher der VPN-Dienst umgesetzt werden soll.
|
||||
Die bereits in Kapitel~\ref{cpt:the_task} ermittelten Anforderungen und Rahmenbedingungen sollen dabei berücksichtigt werden.
|
||||
Dann werden passende Softwarekandidaten vorgestellt und für die Auswahl der in dieser Arbeit zu verwendenden Software gegenübergestellt.
|
||||
Dann werden passende Softwarekandidaten vorgestellt, und für die Auswahl der in dieser Arbeit zu verwendenden Software gegenübergestellt.
|
||||
Im Anschluss soll auf Basis der gewählten VPN-Software gegebenenfalls noch benötigte Software zur Umsetzung der Benutzerverwaltung ausgewählt werden.
|
||||
|
||||
\paragraph{Anforderungsprofil:} \label{p:software_req_profile}
|
||||
|
@ -344,7 +344,7 @@ Die Clientkomponenten der gesuchten Software müssen unter den aktuellen Betrieb
|
|||
|
||||
Die Vorgabe von vertraulicher und authentisierter Kommunikation zwischen VPN-Client und VPN-Server (\ref{req:traffic}) impliziert, dass in der gesuchten Software Algorithmen zum Verschlüsseln und Signieren von Daten verwendet werden.
|
||||
Damit die Implementation dieser kryptografischen Algorithmen von jedermann nachvollzogen werden kann, soll ausschließlich quelloffene Software für den VPN-Dienst verwendet werden.
|
||||
Dadurch sind unabhängige Untersuchungen der Software auf mögliche Sicherheitslücken von Jedermann jederzeit möglich.
|
||||
Dadurch sind unabhängige Untersuchungen der Software auf mögliche Sicherheitslücken von jedermann jederzeit möglich.
|
||||
Dadurch erhöht sich die Wahrscheinlichkeit bestehende Sicherheitslücken zu finden, und die Implementation der kryptografischen Algorithmen kann auf Korrektheit überprüft werden.
|
||||
|
||||
Außerdem kann vermutet werden, dass gefundene und behobene Sicherheitslücken besser kommuniziert werden, da alle Änderungen am Quellcode der Software öffentlich sichtbar sind.
|
||||
|
@ -357,7 +357,7 @@ Weiterhin soll die gesuchte Software IPv4 und IPv6 unterstützen (\ref{req:duals
|
|||
Ausgangspunkt für die Suche nach passender VPN-Software ist die Wahl der Serverkomponente: Sie soll quelloffen sein und auf einem Server mit Debian~9 eingesetzt werden können.
|
||||
Deshalb sind die Debian-Paketquellen die erste Anlaufstelle für die Suche.
|
||||
Durch die Nutzung der Paketquellen ist das Installieren von Sicherheitsaktualisierungen über den Debian-Paketmanager möglich.
|
||||
Arbeitsschritte wie das Anpassen und Kompilieren des Quellcodes, sowie Tests und das Packen der Software werden von den Verwaltern der Debian-Pakete ausgeführt.
|
||||
Arbeitsschritte, wie das Anpassen und Kompilieren des Quellcodes, sowie Tests und das Packen der Software, werden von den Verwaltern der Debian-Pakete ausgeführt.
|
||||
Die Authentizität der Pakete wird anhand von GPG-Signaturen durch den Paketmanager vor der Installation überprüft \cite[][Kapitel 6.5]{book:debian}.
|
||||
|
||||
Um den Wartungsaufwand des VPN-Servers zu reduzieren, kann die Installation von Updates durch den Debian-Paketmanager automatisiert werden \cite[][Kapitel 6.7 und 6.8]{book:debian}.
|
||||
|
@ -380,7 +380,7 @@ Das Protokoll \textit{IP Authentication Header} (AH) ist in \cite[][]{RFC4302} d
|
|||
Vor dem Versand wird über den Inhalt der beim Transport unveränderlichen Felder des IP-Pakets eine Prüfsumme 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.
|
||||
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 \textit{IP Encapsulating Security Payload} (ESP) ist in \cite[][]{RFC4303} definiert und ermöglicht den Versand von Paketen mit vertraulichen Inhalten an eine Gegenstelle.
|
||||
|
@ -392,7 +392,8 @@ Auch die verwendeten Verschlüsselungsalgorithmen müssen zwischen Sender und Em
|
|||
|
||||
IPsec kann im Transportmodus und im Tunnelmodus betrieben werden.
|
||||
Im Transportmodus werden die Inhalte von IP-Paketen in AH- beziehungsweise ESP-Pakete gekapselt.
|
||||
Da die Sender- und Empfängeradressen der IP-Pakete hierbei nicht verändert wird, kann dieser Modus nur für direkte Ende-zu-Ende-Kommunikation verwendet werden.
|
||||
Da die Sender- und Empfängeradressen der IP-Pakete hierbei nicht verändert werden, kann dieser Modus nur für direkte Ende-zu-Ende-Kommunikation der beteiligten Sender und Empfänger verwendet werden.
|
||||
Der Schutz von zu routendem Datenverkehr zwischen zwei Routern ist damit nicht möglich.
|
||||
|
||||
Im Tunnelmodus werden die IP-Paketen selbst in AH- beziehungsweise ESP-Pakete gekapselt.
|
||||
Im Anschluss werden die AH- beziehungsweise ESP-Pakete dann in neue IP-Pakete gekapselt, deren Sender- und Empfängeradressen sich von denen des inneren IP-Paketes unterscheiden dürfen.
|
||||
|
|
Loading…
Reference in New Issue