262 lines
21 KiB
TeX
262 lines
21 KiB
TeX
\chapter{Einleitung} \label{cpt:introduction}
|
|
Die Menge der noch verfügbaren IPv4-Adressen neigt sich dem Ende zu.
|
|
Laut Angaben des RIPE NCC\footnote{RIPE Network Coordination Centre} vom Juni 2018 sind noch ungefähr 8,63 Millionen IPv4-Adressen verfügbar\footnote{\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph}, abgerufen am 03.06.2018}.
|
|
Das entspricht etwa der Hälfte der nutzbaren Host-Adressen eines \texttt{/8}-Blocks.
|
|
Betrachtet man die Vergabegeschwindigkeit von IPv4-Adressen aus den letzten 3 Jahren, so könnte man den Zeitpunkt der Erschöpfung von IPv4-Adressen zwischen 2019 und 2021 vermuten\footnote{\url{https://ipv4.potaroo.net/}, abgerufen am 03.06.2018}.
|
|
|
|
Vor diesem Hintergrund findet die Verwendung von IPv6 eine zunehmende Verbreitung als Nachfolger von IPv4:
|
|
Immer mehr Internetdienste können über IPv6 erreicht werden, und auch die Internetanbieter stellen ihren Kunden IPv6-fähige Internetanschlüsse zur Verfügung.
|
|
Der Anteil von Suchanfragen, die über IPv6 an Google gestellt wurden, hat von 5,84\% am 1. Januar 2015 auf 21,11\% am 1. Juni 2018 zugenommen\footnote{\url{https://www.google.com/intl/en/ipv6/statistics.html}, abgerufen am 03.06.2018}.
|
|
Am AMS-IX\footnote{Amsterdam Internet Exchange}, dem Internet-Austauschpunkt in Amsterdam, hat sich der Durchfluss von IPv6-Verkehr in den letzten 12 Monaten im Durchschnitt von etwa 55 Gbit/s im August 2017 auf etwa 85 Gbit/s im Mai 2018 gesteigert\footnote{\url{https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic},\\abgerufen am 03.06.2018}.
|
|
|
|
Auch das Netz der Abteilung Informatik an der Hochschule Hannover ist Vorreiter in der Erprobung von IPv6: Seit Anfang 2015 ist das Netz schon über IPv6 an das Internet angebunden.
|
|
Damit ist die Voraussetzung gegeben, um Netzwerkgeräte für IPv6 zu konfigurieren und bestehende Netzwerkdienste auch über IPv6 anzubieten.
|
|
|
|
Mitarbeitern und Studenten der Abteilung Informatik steht ein VPN-Dienst zur Ver\-fü\-gung, um Zugang in das Netz der Abteilung aus dem Internet heraus zu erhalten.
|
|
Bisher ist dieser Dienst nur über IPv4 erreichbar und ermöglicht den Zugang in das Abteilungsnetz ausschließlich über IPv4.
|
|
\newpage
|
|
Im Rahmen dieser Masterarbeit soll ein neuer, IPv6-fähiger VPN-Dienst konzipiert werden, der die Idee des bisherigen IPv4-VPN-Dienst aufgreift.
|
|
Dafür wird zunächst die Netzarchitektur der Abteilung Informatik inklusive dem Firewallkonzept vorgestellt.
|
|
Anschließend werden alle Rahmenbedingungen und Anforderungen erfasst, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden sollen.
|
|
In der darauf folgenden Konzeptphase werden zunächst grundlegende, lösungsunabhängige Entscheidungen getroffen, auf Basis derer dann eine technischen Lösung ausgewählt wird.
|
|
\todo{Danach geht es weiter mit der Planung der konkreten Lösung, der Installation und der Dokumentation.}
|
|
|
|
|
|
\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.
|
|
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]
|
|
\centering
|
|
% Trim, da diese Grafik als PDF auf DIN A4 vorliegt.
|
|
\frame{\includegraphics[trim=75 540 75 75,clip,width=\textwidth]{img/Netzwerktopologie_simpelv2_with_addresses.pdf}}
|
|
\caption{Skizze der Netztopologie der Abteilung Informatik}
|
|
\label{fig:topology_simple}
|
|
\end{figure}
|
|
|
|
|
|
\section{Firewallkonzept} \label{sct:firewall}
|
|
Die im Netz der Abteilung Informatik verwendeten LANs und VLANs werden im Firewallkonzept als verschiedene Sicherheitszonen betrachtet.
|
|
Im Rahmen dieser Arbeit sind die folgenden Zonen relevant:
|
|
|
|
\paragraph{Internet}
|
|
Das \enquote{Internet} bezeichnet den Bereich außerhalb des Netzes der Abteilung Informatik.
|
|
Diese Zone umfasst neben dem Internet auch das Netz der Hochschule Hannover.
|
|
Verbindungen in das Internet sind aus allen Zonen außer der DMZ erlaubt.
|
|
Verbindungen aus dem Internet werden nur zu Diensten in der DMZ (wie zum Beispiel VPN), sowie zu dem SSH-Dienst im Mitarbeiter-Netz zugelassen.
|
|
|
|
\paragraph{DMZ}
|
|
Von der Abteilung Informatik betriebenen Server stellen in diesem Netz Dienste zur Verfügung, die sowohl innerhalb der Abteilung als auch über das Internet erreichbar sind.
|
|
Verbindungen in die DMZ zu Diensten wie VPN sind aus allen anderen Zonen heraus erlaubt.
|
|
Verbindungen aus der DMZ in alle anderen Zonen sind verboten, um im Fall eines Sicherheitsvorfalls Angriffe auf alle anderen Zonen zu verhindern.
|
|
Eine Ausnahme für dieses Verbot sind Verbindungen vom VPN-Dienst, die in das Mitarbeiter-Netz aufgebaut werden dürfen.
|
|
|
|
\paragraph{Mitarbeiter-Netz}
|
|
Die Rechner aller Mitarbeiter der Abteilung Informatik sind an dieses Netz angeschlossen.
|
|
Verbindungen in das Mitarbeiter-Netz aus dem Pool-PC-Netz und den Labor-Netzen sind erlaubt.
|
|
Außerdem sind Verbindungen von dem VPN-Dienst aus der DMZ in das Mitarbeiter-Netz erlaubt.
|
|
Verbindungen aus dem Mitarbeiter-Netz sind in alle anderen Zonen erlaubt.
|
|
|
|
\paragraph{Pool-PC-Netz}
|
|
Enthält die Rechner aus allen Poolräumen.
|
|
Verbindungen in das Pool-PC-Netz sind aus dem Mitarbeiter-Netz und den Labor-Netzen erlaubt.
|
|
Verbindungen aus dem Pool-PC-Netz sind in alle anderen Zonen erlaubt.
|
|
|
|
\paragraph{Labor-Netze}
|
|
Das Netzwerklabor und das Labor für IT-Sicherheit werden für diese Arbeit unter der Zone \enquote{Labor-Netze} zusammengefasst.
|
|
Verbindungen aus den Labornetzen heraus sind in alle anderen Zonen erlaubt.
|
|
Verbindungen in die Labornetze sind aus dem Mitarbeiter-Netz und aus dem Pool-PC-Netz heraus erlaubt.
|
|
|
|
Ein Überblick der erlaubten Verbindungen zwischen den Sicherheitszonen ist in Tabelle~\ref{tab:firewall_zone_access} skizziert.
|
|
|
|
\begin{table}[ht]
|
|
\centering
|
|
\caption{Überblick über erlaubte Verbindungen zwischen Sicherheitszonen}
|
|
\begin{tabular}{ *{6}{|l}| }
|
|
\hline
|
|
& \multicolumn{5}{c|}{\dots in die Zone \dots} \\
|
|
Aus der Zone \dots & Internet & DMZ & Mitarbeiter-Netz & Pool-PC-Netz & Labor-Netze \\
|
|
\hline
|
|
Internet & --- & erlaubt & verboten & verboten & verboten \\
|
|
DMZ & verboten & --- & verboten & verboten & verboten \\
|
|
Mitarbeiter-Netz & erlaubt & erlaubt & --- & erlaubt & erlaubt \\
|
|
Pool-PC-Netz & erlaubt & erlaubt & erlaubt & --- & erlaubt \\
|
|
Labor-Netze & erlaubt & erlaubt & erlaubt & erlaubt & --- \\
|
|
\hline
|
|
\end{tabular}
|
|
\label{tab:firewall_zone_access}
|
|
\end{table}
|
|
|
|
|
|
\chapter{Anforderungsanalyse} \label{cpt:requirements}
|
|
In diesem Abschnitt werden alle Anforderungen und Rahmenbedingungen vorgestellt, die bei der Konzeption des neuen VPN-Dienst berücksichtigt werden müssen.
|
|
Es handelt sich hier um Vorgaben, die im persönlichen Gespräch mit dem Auftraggeber und Erstprüfer dieser Arbeit ermittelt wurden.
|
|
|
|
\begin{enumerate}[label=Anf\arabic*]
|
|
\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.
|
|
\item \label{req:traffic} \textbf{VPN-externer Datenverkehr:} Die Kommunikation zwischen VPN-Client und VPN-Server soll authentisiert und vertraulich stattfinden.
|
|
\item \label{req:users} \textbf{Benutzer:} Der VPN-Dienst soll von autorisierten Mitarbeitern und Studenten aus der Abteilung Informatik benutzt werden können.
|
|
Die Benutzer des VPN-Dienst sollen durch die Administratoren des VPN-Dienst einfach verwaltet werden können.
|
|
\item \label{req:serveros} \textbf{Betrieb des VPN-Servers:} Die Serverkomponente des VPN-Dienst soll auf einer aktuellen Version von Debian (9 oder höher) betrieben werden.
|
|
\item \label{req:clientos} \textbf{Betrieb der VPN-Clients:} Die VPN-Clientsoftware soll für aktuelle Versionen gängiger Betriebsysteme zur Verfügung stehen.
|
|
Darunter fallen Microsoft Windows 10 (Version 1709 oder höher), Apple MAC OS (ab Version 10.13) und Linux-Distributionen (ab Kernel Version 3.10).
|
|
\item \label{req:logging} \textbf{Betriebsprotokoll:} Während des Betrieb des VPN-Dienst sollen keine Daten protokolliert werden, die Rückschlüsse auf das Benutzerverhalten zulassen. Im Rahmen einer laufenden Fehlersuche soll es möglich sein, mehr Daten zu protokollieren.
|
|
\item \label{req:finance} \textbf{Finanzieller Rahmen:} Es stehen keine finanziellen Mittel für den Erwerb einer VPN-Lösung zur Verfügung.
|
|
\end{enumerate}
|
|
|
|
Anhand der Anforderungen~\ref{req:dualstack} bis \ref{req:finance} werden vorhandene Programme ermittelt, die sich als Kandidat zur Umsetzung des VPN-Dienstes eignen.
|
|
Aufgrund des finanziellen Rahmens (\ref{req:finance}) kommt nur kostenfreie Software in Frage, deren Serverkomponente mit aktuellem Debian (\ref{req:serveros}) kompatibel ist.
|
|
Die Clientkomponenten der gesuchten Software müssen unter den aktuellen Betriebsystemen lauffähig sein (\ref{req:clientos}).
|
|
|
|
Die Vorgabe von vertraulicher und authentisierter Kommunikation zwischen VPN-Client und VPN-Server (\ref{req:traffic}) impliziert, dass die gesuchte Software Algorithmen zum Verschlüsseln und Signieren von Daten verwendet.
|
|
Deshalb soll Kerckhoffs' Prinzip bei der Wahl der VPN-Software angewendet werden, indem ausschließlich
|
|
quelloffene Software berücksichtigt wird.
|
|
Weiterhin soll die gesuchte Software IPv4 und IPv6 unterstützen (\ref{req:dualstack}), die Routingtabellen der VPN-Clients (\ref{req:routing}) anpassen können und in Bezug auf Protokollierung (\ref{req:logging}) konfigurierbar sein.
|
|
|
|
|
|
\section{Suche nach VPN-Serversoftware} \label{sct:software_candidates}
|
|
Ausgangspunkt für die Suche nach passender VPN-Software ist die Wahl der Serverkomponente: Sie soll quelloffen sein und auf einem Server mit aktuellem Debian 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 Patchen und Kompilieren des Quellcodes, sowie Tests und das Paketieren 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}.
|
|
Somit muss der Systemadministrator lediglich Upgrades zur nächsthöheren Debian-Version durchführen, da dabei Anpassungen an der Systemkonfiguration notwendig werden.
|
|
|
|
Im Folgenden werden mögliche Software-Kandidaten aus den Debian-Paketquellen vorgestellt.
|
|
|
|
|
|
\subsection{Strongswan} \label{ssct:strongswan}
|
|
Strongswan\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan},\\zuletzt abgerufen am 18.07.2018} ist eine quelloffene, modular aufgebaute Software, die unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebsystemen lauffähig ist.
|
|
Sie kann verwendet werden, um in Kombination mit IPsec-fähigen Betriebsystem-Kerneln geschützte Verbindungen zwischen zwei oder mehr Computern einzurichten.
|
|
Strongswan wird unter der Lizenz GPLv2 verbreitet\footnote{\url{https://wiki.strongswan.org/projects/strongswan/wiki/Contributions},\\ zuletzt abgerufen am 04.09.2018}.
|
|
|
|
IPsec ist ein Internetstandard, der kryptografische Sicherheit für IPv4 und IPv6 (sowie darüber übertragenen Daten) bieten soll.
|
|
Das beinhaltet unter anderem Vertraulichkeit übertragener Daten durch den Einsatz von Verschlüsselung, Authentisierung von Paketen durch Prüfung von Prüfsummen, und Schutz vor Replay-Angriffen\cite[Vergleich][Kapitel 2.1]{RFC4301}.
|
|
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.
|
|
Vor dem Versand wird über den Inhalt und einige Felder des IP-Pakets eine Prüfsumme gebildet.
|
|
Die Gegenstelle kann nun 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.
|
|
Je nach gewählter Funktion fließen gemeinsame Geheimnisse oder Signaturalgorithmen in die Berechnung der Prüfsumme ein, sodass eine korrekte Prüfsumme ein Paket wirklich authentisieren kann.
|
|
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.
|
|
Ä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.
|
|
|
|
IPsec definiert zwei Betriebsvarianten: Den Transportmodus und den Tunnelmodus.
|
|
Im Transportmodus werden die Inhalte von IP-Paketen in AH- bzw. 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.
|
|
|
|
Im Tunnelmodus werden die IP-Paketen selbst in AH- bzw. ESP-Pakete gekapselt.
|
|
Im Anschluss werden die AH- bzw. ESP-Pakete dann in neue IP-Pakete gekapselt, deren Sender- und Empfängeradressen sich von denen des inneren IP-Paketes unterscheiden dürfen.
|
|
Somit ist der Tunnelmodus im Prinzip für die Umsetzung eines VPN geeignet.
|
|
|
|
Strongswan implementiert das Protokoll IKEv2\footnote{Internet Key Exchange Protokoll Version 2, definiert in \cite[][]{RFC7296}} und kann darüber authentisiert und verschlüsselt mit Gegenstellen kommunizieren.
|
|
Dabei werden mit der Gegenstelle Schlüssel- und Konfigurationsparameter ausgehandelt beziehungsweise ausgetauscht, anhand derer Strongswan IPsec-Verbindungen im Kernel des Host-Betriebsystems konfigurieren kann.
|
|
Die Verarbeitung des durch IPsec geschützten Da\-ten\-ver\-kehrs über die Protokolle AH oder ESP wird jedoch direkt im IPsec-Stack des Kernels abgewickelt.
|
|
Für lokal ausgeführte Programme ist der Einsatz von IPsec transparent.
|
|
|
|
|
|
\subsection{OpenVPN} \label{ssct:openvpn}
|
|
OpenVPN\cite[][]{man:openvpn} ist eine quelloffene Software zur Einrichtung von VPNs in Peer-to-Peer oder Client-Server-Architektur.
|
|
Sie ist unter den in \ref{req:serveros} und \ref{req:clientos} genannten Betriebsystemen lauffähig und wird unter der GPLv2-Lizenz verbreitet.
|
|
OpenVPN läuft vollständig im Benutzerkontext und unterstützt den Wechsel zu einem nicht-privilegierten Benutzer\cite[Siehe][\texttt{--user}]{man:openvpn}.
|
|
Für die Bereitstellung einer virtuellen Netzwerkkarte als Schnittstelle zum VPN wird ein TUN/TAP-Treiber verwendet.
|
|
Kryptografische Operationen lagert OpenVPN zu großen Teilen an die quelloffene Bibliothek openssl aus\cite[][]{man:openvpn}.
|
|
|
|
|
|
\section{Auswahl einer VPN-Software}
|
|
Vorzüge von OpenVPN und IPsec im Vergleich.
|
|
Begründung der Auswahl.
|
|
|
|
|
|
\section{Konzipierung der Benutzerverwaltung}
|
|
Anforderungen:
|
|
* Soll möglichst "einfach" sein
|
|
* Möglichst wenig personenbezogene Daten verarbeiten oder speichern
|
|
* Zielgruppe des Dienstes sind Beschäftigte und Studenten der Abteilung Informatik (Größenordnung: 20-200 Personen)
|
|
* Studenten sollen immer für ein (laufendes?) Semester Zugriff erhalten
|
|
|
|
Möglichkeiten: User+Passwort oder SSL-Zertifikate
|
|
|
|
Zertifikate:
|
|
* klare Laufzeit
|
|
* kann nicht erraten werden
|
|
* Können schlimmstenfalls via CRL gesperrt werden
|
|
* Verschlüsselung des privaten Schlüssels verhindert Missbrauch bei gestohlenen Daten (Cert+Key)
|
|
* Einrichtung von Benutzern geschieht durch Signatur eines Zertifikatsantrags
|
|
* Erfolgreich gestohlenes Zertifikat kann nur für VPN-Dienst genutzt werden
|
|
|
|
Benutzer/Passwort:
|
|
* Bequemlichkeit: Kann über existierende Infrastruktur abgewickelt werden (Hochschulaccount)
|
|
* Einrichung von Benutzern kann quasi vollautomatisch oder durch eine Whitelist geschehen
|
|
* Benutzerkonten werden automatisch deaktiviert
|
|
* Nur Benutzername+Passwort reichen aus, gestohlene Zugangsdaten bedeuten großes Schadenspotential
|
|
* Zugangsdaten müssen zur Authentisierung an entsprechende Dienste "durchgereicht" werden, daher größere Angriffsfläche
|
|
|
|
Gewinner: Zertifikate
|
|
|
|
|
|
\section{Umsetzung einer Zertifizierungsstelle}
|
|
OpenSSL ist aufgrund der Abhängigkeit von OpenVPN bereits gegeben.
|
|
Mit OpenSSL kann man Schlüsselpaare erzeugen, Zertifikatsanträge erzeugen und Zertifikate ausstellen.
|
|
Allerdings erfordert das viel Detailwissen und die Verwaltung der ausgestellten Zertifikate ist nicht einfach.
|
|
Da wir Zertifikate auch unbrauchbar machen wollen, müssen Revocations ebenfalls möglich sein.
|
|
Eine CRL muss erzeugt werden können, damit diese im OpenVPN-Dienst für die Prüfung der Gültigkeit der Zertifikate verwendet werden kann.
|
|
|
|
Jetzt kann man viel Zeit investieren, die notwendigen Skripte selbst zu schreiben.
|
|
Allerdings hat OpenVPN bereits eine Abhängigkeit auf die Skriptesammlung EasyRSA, welche exakt für diesen Zweck gebaut wurde.
|
|
Die von Debian 9 mitgelieferte Version 2.3.x ist schon etwas älter, könnte aber verwendet werden.
|
|
Allerdings gibt es auch eine modernere Neuentwicklung in Version 3.0.5, die langfristig vom OpenVPN-Team weiterentwickelt wird und einige Verbesserungen im Vergleich zur alten v2 mitbringt.
|
|
|
|
Kurz: EasyRSA2.2.3 aus Debian vs EasyRSA3.x direkt von Github vs irgendwie selbst Skripte schreiben (Wieso das Rad neu erfinden?) - Vorteile/Nachteile
|
|
Ggf. kurz ein Blick darauf, was alles für Features benötigt werden.
|
|
EasyRSAv3 ist eine Neuentwicklung von EasyRSAv2.
|
|
Die neue Version wird vom OpenVPN-Team weiter entwickelt werden.
|
|
Vereinfachte Benutzung der zur Verfügung gestellten Shellskripte
|
|
Viele Verbesserungen, wie z.B. Unterstützung für ECDSA (Siehe Changelog) oder UTF-8 ist jetzt standard, AES256 wird für die Verschlüsselung des CA-Keys verwendet, \dots
|
|
|
|
Da für die Anfertigung von Zertifikatsanträgen eine korrekte Konfiguration von OpenSSL benötigt wird und diverse Einstellungen vorgegeben werden sollen, ist es sinnvoll, dass die CA durch das IT-Team auf Basis von EasyRSA v3.0.5 kurz vorbereitet wird und dann als Paket für Benutzer bereitgestellt wird.
|
|
|
|
Danach: Wie funktioniert die CA mit EasyRSA?
|
|
--> Dokumente: Benutzerdokumentation, CA-Admin-Dokumentation, Serverdokumentation
|
|
|
|
\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
|
|
* IP-Adressen und Routing geklärt
|
|
* Konzepte und Konfiguration des IT-Teams in das Konzept integriert
|
|
* virtuelle IP als Alias auf Netzwerkkarte, über die der Dienst angestoßen wird
|
|
* Voraussichtlich separate Maschine zur Verwaltung der CA
|
|
* Koordination Firewallregeln
|
|
** Dienst bietet nur OpenVPN udp/1194 (Internetoffen) und SSH tcp/22 (mal gucken, wie offen das ist)
|
|
** lokale Firewall auf VPN-Server verhindert Zugriffe vom VPN in die DMZ
|
|
* Koordination Routing
|
|
** IPv6-Bereich für VPN-Clients wird an virtuelle IPv6-Adresse des VPN-Dienstes geroutet -> manuelles Failover möglich
|
|
** IPv4: VPN-Clients bekommen IP-Adressen aus 10.2.0.0/16 Block, für IPv4 wird auf NAT zurückgegriffen
|
|
* Diverse Best-practices/Designpattern übernommen (Konfiguration durch Pakete, SSH-Konfiguration, ...)
|
|
|
|
|
|
\section{Erstellung eines Betriebskonzept}
|
|
Installation/Installationsanleitung
|
|
Konfiguration
|
|
Inbetriebnahme
|
|
notwendige (regelmäßige) Wartungsarbeiten
|
|
|
|
|
|
\chapter{Fazit}
|
|
Wie ist es gelaufen, gab es Probleme? Wie macht sich OpenVPN als Lösung?
|
|
Gibt es vielleicht Szenarien, in denen sich IPsec doch lohnt?
|
|
Ja - eventuell. Sehr große Enterprise-Umgebungen, in denen die personellen Ressourcen für die korrekte Konfiguration vorhanden sind.
|
|
Da kann man in homogenen Umgebungen sinnvolle IPsec-Konfigurationen auf hunderten oder tausenden Geräte einrichten.
|
|
|
|
|
|
\section{Ausblick}
|
|
Es gibt da noch etwas mit dem schönen Namen Wireguard. Mit gewollt geringer Komplexität und einem aktuellen Umfang von ca. 4000 Zeilen Code ist es eine würdige Alternative zu IPsec.
|
|
Auch OpenVPN in Version 3 ist schon in der Beta - das könnte man auch im Auge behalten. |