Sicheres OpenVPN

From
Revision as of 07:26, 29 October 2018 by Baudisja (talk | contribs) (Minor Errorcorrections)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

OpenVPN ist eine bewährte und mächtige Virtual Private Network-Lösung. Dank zahlreicher Scripte[1][2][3][4][5] und Blogeinträge[6][7][8][9] ist die Inbetriebnahme eines OpenVPN-Servers in kurzer Zeit möglich. Die Einstellungen u.a. der verwendeten Kryptologie sind jedoch teilweise nicht aktuell und i.d.R. nicht optimal. Die folgenden Empfehlungen und Aussagen beziehen sich auf die im Oktober 2018 aktuelle Version (OpenVPN 2.4.6). Ebenso werden folgend überwiegend sicherheitsrelevante Aspekte betrachtet. Ein grundlegendes Wissen über OpenVPNs arbeitsweise und dessen Aufbau ist somit erforderlich/empfehlenswert. Zusätzlich kann der Zugriff durch MFA abgesichert werden. Zum Schutz der Nutzer könnte man zusätzlich einen DNS-Resolver mit DNSSEC verwenden oder einen Resolver verwenden welcher DNS-over-HTTPS unterstützt.

Grundsätzliches Wissen

OpenVPN kann für die Verschlüsselung entweder mit mbedTLS oder OpenSSL kompiliert werden. Beide Varianten unterstützen die für uns wünschenswerte Elliptic Curve Cryptography. Zur einfachen Erstellung von Zertifikatsbasierter Authentifikation wird EasyRSA empfohlen, welches OpenSSL (alle folgenden Aussagen beziehen sich auf die Version OpenSSL 1.1.1 11 Sep 2018) voraussetzt.

Empfehlenswertes Skript zur Installation

Folgendes Skript bietet einen sehr guten Ausgangspunkt. Die Standardeinstellungen sind bereits solide. Bei der Installation kann bereits trotzdem an vielen Stellen auf u.a. stärke Crypto umgeschaltet werden. Die Erstellung der PKI und der Client und Server Zertifikate gestaltet sich hiermit nochmal einfacher als nur mit EasyRSA. Ebenso werden die Konfigurationsdateien für den Server sowie die Clients erstellt. Eine einfache Möglichkeit zur Revocation der Zertifikate ist ebenfalls gegeben.

Zu beachten ist, dass das Skript u.a. FW-Regeln erstellt und das Forwarding aktiviert wird.

OpenVPN selbst kompilieren

Die Version von OpenVPN in den Repos der Distris kann unter Umständen etwas älter sein, so dass es Sinn machen kann OpenVPN selber zu kompilieren. OpenVPN kann dabei mit mbedTLS - welches der Standard für die Smartphone Apps ist - oder OpenSSL kompiliert werden. Für Easy-RSA (empfohlen) wird zwar immer OpenSSL benötigt, OpenVPN kann dennoch ohne Probleme mit mbedTLS kompiliert werden. Beachten muss man jedoch das man eine von mbedTLS unterstütze Cipher-Suite bzw. Kurve verwendet. OpenSSL sowie mbedTLS unterstützen ECC, hatten jedoch noch bis vor kurzem mit diversen Bugs zu kämpfen. Ebenso ist die Auswahl der Kurven im Zusammenhang mit OpenVPN noch eingeschränkt, so dass zur Zeit die Nist und die Brainpool Kurven am attraktivsten sind wobei es Unterschiede bei der Geschwindigkeit gibt.

OpenVPN mit mbedTLS

mbedTLS hieß ursprünglich PolarSSL und zielt auf eingebettete Systeme. Sowohl der iOS wie auch der Android Client verwenden mbedTLS. Eine Anleitung findet man dazu im OpenVPN-Forum.[10] Unter [11] und [12] findet man Informationen zu den Unterschieden bzw. nicht unterstützen Features.

OpenVPN mit OpenSSL(Standard)

OpenSSL ist die Standardbibliothek für SSL/TLS. In den letzten Jahren geriet diese jedoch zunehmend u.a. wegen Bugs wie Heartbleed in Kritik.

Mögliche Probleme

Folgend eine (unvollständige) Linkssammlung mit Problemen die mit Versionen 2017/Anfang 2018 auftreten können falls ECC verwendet wird. Gerade die nicht NIST Kurven können dabei zu Problemen führen.

In meinen Tests hielten sich jedoch die Probleme - bis auf kleinere, wenig schwere - stark in Grenzen. Eingesetz wurde ein Raspbian Stretch mit folgenden Versionen:

  • OpenVPN 2.4.0 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
  • library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08

Bzw.:

  • OpenVPN 2.4.6 armv6l-unknown-linux-gnueabihf [SSL (mbedTLS)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct9 2018
  • library versions: mbedTLS 2.13.1, LZO 2.08

Die erstere Konfiguration war die bei Raspbian ausgelieferte, welche eher ältere Versionen einsetzt. Dennoch traten keine nennenswerten Probleme auf. Im Test wurde Secp521r1 mit der letzteren Version eingesetzt, BrainpoolP512r1 sowie Secp521r1 mit obiger. Als Client kam die OpenVPN Connect App (Android) in der Version 3.0.5(1816) zum Einsatz sowie ein etwas älterer Windows Client: OpenVPN 2.4.1 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Mar 22 2017; library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.09. Dies wurde so gewählt da der Systemadministrator unter Umständen die Clientrechner nicht administriert und somit bei Änderungen der Servereinstellung Probleme wegen älteren Versionen beim Client auftreten können.

Easy-RSA

OpenVPN bietet mit EasyRSA ein Skript welches sich um das Anlegen einer CA sowie das Anlegen/Signieren von Client und Server Zertifikaten[13][14] kümmert. Es können dafür auch Elliptische Kurven verwendet werden. Ebenso bietet es eine einfache Möglichkeit um Zertifikate zu widerrufen. OpenVPN unterstützt seit der Version 2.4.0 ECC.[15]

ECC Diskurs

Asymetrische Kryptographie erforderte ursprünglich sehr große Schlüssel um ein entsprechendes Sicherheitsniveau zu erreichen. Mit Hilfe der Elliptischen Kurven konnte diese Anforderung deutlich gesenkt werden. Die Reduzierung der Schlüsselgröße ermöglicht performantere asymetrische Kryptographie. Eine gute Erklärung warum und wie das funktioniert, findet sich im Wiki von OpenSSL.[16]

Hinweis: Falls aus irgendwelchen Gründen alte OpenSSL Versionen verwendet werden müssen, welche bestimmte Kurven nicht kennen, kann man die Parameter explizit komplett inkludieren statt nur dem Namen. [17]

Empfehlungen des BSI

Das BSI gibt regelmässig Empfehlungen raus welche Kryptographie verwendet werden sollte. Z.B. genügt die Ciphersuite ECDHE_ECDSA_WITH_AES_256_CBC/GCM_SHA384 bis mindestens 2024 gehobeneren Sicherheitsansprüchen. Der ECDSA mit mindestens 250 Bit sowie der ECDH(E) ebenfalls mit min. 250 Bit wird ebenso bis mindestens 2024 für den Einsatz empfohlen. Als Kurven werden die u.a. von dem BSI entworfenen Brainpool-Kurven oder die NIST-Kurven (secp) mit mindestens 256 Bit empfohlen.

Auswahl der Kurve

Es gibt verschiedene Kurven welche in den letzten Jahren entworfen und vorgeschlagen wurden. Schwierig ist die Wahl der Parameter bzw. der Überprüfung ob ggfs. eine Hintertür in den Parametern ist. Unter anderem wird dies bei den NIST sowie bei den Brainpool Kurven stark diskutiert. Eine häufig empfohlene Alternative ist die Curve25519 von Daniel J. Bernstein - diese lässt sich aktuell jedoch nicht in OpenVPN einsetzen. Und da die Curve25519 nicht mit ECDSA verwendet werden kann, wurde hierfür EdDSA bzw. genauer Ed25519 entworfen. Da die OpenVPN Connect App auf mbedTLS aufsetzt, wird Curve25519 vermutlich für die meisten erst interessant wenn diese seitens mbedTLS unterstützt werden. Den aktuellen Status dazu erfährt man hier. Weitere Informationen zur Historie der in den letzten Jahren entstanden Kurven und die Diskussion um Standardkurven findet man u.a. auf den einschlägigen TechNews Seiten.[18][19][20] Interessant sind auch die Erklärungen der Parameterwahl der Brainpool-Kurven.

Wer sich tiefergehend mit der Materie auseinandersetzen will, dem seien folgende Links empfohlen:

Einstellungen für OpenVPN

Wir lassen die Diskussion um die NIST und Brainpool-Kurven jetzt mal aussen vor und verwenden secp521r1 welche ein hohes Schutzniveau verspricht. Die Betrachtung der Einstellungen erfolgt auf dem weiter oben vorgeschlagenem Skript wobei immer die stärksten Algorithmen gewählt wurden. Und es werden nur die Einstellungen betrachtet welche einen signifikaten Einfluss haben.

Serverkonfiguration

Im Folgenden betrachten wir zuerst die Serverkonfigurationsdatei wobei nur die für die Sicherheit relevanten Optionen betrachtet werden. Und beginnen mit den TLS-Einstellungen für Control Channel.

# Aktiviert TLS und teilt OpenVPN mit das es die Serverrolle beim TLS-Handshake einnehmen soll
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
tls-server

# Bestimmt die zu verwendende Kurve für den ECDH; mbedTLS unterstützt diese Option nicht
# Sollte ebenfalls bereits mit der passenden Kurve eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
ecdh-curve secp521r1

# Erzwingt das mindestens TLS 1.2 verwendet wird; dies kann zu Problemen führen falls Clients Version vor 2.3.3 einsetzen
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
tls-version-min 1.2

# Schränkt die erlaubte Ciphersuiteauswahl ein; Es ist möglich mehrere Ciphersuites einzutragen wobei diese per : separiert sein müssen; dies kann zu Problemen führen falls Clients OpenVPN Version vor 2.3.3 einsetzen
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

# Verschlüsselt und Authentifiziert alle Packete des Control Channels
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
# Anmerkung: Falls das Skript eine 0 nach dem Key setzt, kann diese entfernt werden
tls-crypt tls-crypt.key

# Der Server überprüft das Client Zertifikat und überprüft ob dieses als Client signiert wurde.
# Wird vom Skript nicht gesetzt und kann gesetzt werden
remote-cert-tls client

Nun betrachten wir die Einstellungen für den Data Channel:

# Normalerweise wird SHA1 für die Daten auf dem Data Channel zur Überprüfung der Authentizität verwendet; Dies kann auf SHA2 geändert werden
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Falls ein sehr hohes Schutzniveau gewünscht ist, sollte diese Option auf z.B. SHA512 gesetzt werden
# Zu beachten ist, dass diese Option nur greift falls kein AEAD (wie z.B. GCM) verwendet wird.
auth SHA512

# Hiermit setzt man die Cipher für den Datenkanal
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
cipher AES-256-GCM

# Falls man es ermöglichen möchte das der Client und der Server die Cipher selber aushandeln können, kann man folgende Option verwenden und dort die gewünschten Ciphers auflisten
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
# Es wird jedoch stark davon abgeraten Ciphers wie BF-CBC einzusetzen!
ncp-ciphers AES-256-GCM:AES-256-CBC

Nun folgen u.a. diverse Einstellungen um z.B. das System besser abzusichern falls OpenVPN verwundbar gegenüber z.B. Code Injection ist:

# OpenVPN kann nach der Initialisierung seine Systemrechte abgeben und andere Rechte verwenden
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
user nobody
group nogroup

# Damit es nicht zu Problemen nach dem Abgeben der Systemrechte kommt, wird unter anderem verhindert, dass das TUN/TAP-Device geschlossen und wieder geöffnet wird (dies ist i.d.R. nur mir Systemrechten möglich)
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
persist-key
persist-tun

# Falls ein Zertifikat zurückgezogen wird, wird dies hier eingetragen, wodurch sich dieser nicht mehr vebinden darf
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
crl-verify crl.pem

# Dem Client können u.a. DNS Server übergeben werden - dies ist besonders empfehlenswert in Kombination mit z.B. lokalen DNSSEC- oder DoH-Resolvern
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
push "dhcp-option DNS 1.0.0.1"
push "dhcp-option DNS 1.1.1.1"

# Sorgt dafür das der komplette Traffic vom Client über den OpenVPN-Server geroutet wird - unter iOS wird jedoch der Traffic von vielen Systemapps nicht über den VPN-Server geleitet
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
# Dies kann ggfs. umgangen werden, siehe dazu [21]
push "redirect-gateway def1 bypass-dhcp" 

# OpenVPN ermöglicht die Komprimierung der Daten - dies sollte jedoch auf Grund der VORACLE Attacke deaktiviert werden!
# Sollte vom Skript nicht hinzugefügt worden sein - bzw. dieses warnt sogar explizit davor
;comp-lzo

# Nach der Initialisierung kann der OpenVPN in ein Verzeichnis "eingesperrt" werden bzw. kann ein SELinux Kontext angewandt werden
# Sollte vom Skript nicht hinzugefügt worden sein; Kann hinzugefügt werden, jedoch sollte man sich sehr gut mit dem System und den Optionen auskennen, da dadurch ggfs. der Zugriff auf die Revocation List oder z.B. die Zufallsquelle unterbunden werden kann
;chroot jail
;setcon context

# OpenVPN bietet u.a. ein PAM Plugin an wodurch z.B. eine MFA ermöglicht werden kann
# Wird vom Skript nicht gesetzt; kann hinzugefügt werden - Details zur Verwendung siehe hier
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so openvpn

Clientkonfiguration

Nun betrachten wir die Konfiguration des Clients wobei wieder nur die für die Sicherheit relevanten Optionen betrachtet werden. Und beginnen ebenfalls wieder mit den TLS-Einstellungen für den Control Channel.

# Aktiviert TLS und teilt OpenVPN mit das es die Clientrolle beim TLS-Handshake einnehmen soll
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
tls-client

# Erzwingt das mindestens TLS 1.2 verwendet wird
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
tls-version-min 1.2

# Schränkt die erlaubte Ciphersuiteauswahl ein; Es ist möglich mehrere Ciphersuites einzutragen wobei diese per : separiert sein müssen;
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

# Der Client überprüft das Server Zertifikat und überprüft ob dieses als Server signiert wurde; Verhindert das sich andere Clients als Server ausgeben können
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
remote-cert-tls server

# Der Client kann das Server Zertifikat u.a. noch anhand von weiteren Kriterien prüfen
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten kann man dies ggfs. hinzufügen
verify-x509-name server_id name

# Verschlüsselt und Authentifiziert alle Pakete des Control Channels
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
# Anmerkung: Kann zur einfacheren Handhabung inline in die Datei eingefügt werden; Falls z.B. ein Smartphone verwendet wird, wird jedoch der import in die Keychain (Android bzw. iOS - iOS importiert nur das Clientzertifikat sowie den privaten Key und u.a. nicht die CA!) empfohlen (Bei der Verwendung von MFA führte dies jedoch bei mir zu Problemen)
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
.....
-----END OpenVPN Static key V1-----
</tls-crypt>

Nun betrachten wir die Einstellungen für den Data Channel:

# Normalerweise wird SHA1 für die Daten auf dem Data Channel zur Überprüfung der Authentizität verwendet; Dies kann auf SHA2 geändert werden
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Falls ein sehr hohes Schutzniveau gewünscht ist, sollte diese Option auf z.B. SHA512 gesetzt werden
# Zu beachten ist, dass diese Option nur greift falls kein AEAD (wie z.B. GCM) verwendet wird.
auth SHA512

# Hiermit setzt man die Cipher für den Datenkanal
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
cipher AES-256-GCM

# Sorgt dafür, dass der Username und das Passwort nicht im virtuellem Speicher gecached werden
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
auth-nocache

# Unter Windows 10 kann es vorkommen, dass trotz der vom Server ggfs. gepushten DNS Server Einstellungen, alle anderen verfügbaren DNS-Server ebenfalls angesprochen werden
# Sollte vom Skript bereits in die Konfigurationsdatei eingetragen worden sein; Ansonsten wird empfohlen dies hinzuzufügen
setenv opt block-outside-dns # Prevent Windows 10 DNS leak

# Falls ein Server-Zertifikat zurückgezogen wird, kann dies hier eingetragen werden
# Wird vom Skript nicht gesetzt; Bei hohen Sicherheitsanforderungen kann diese Option gesetzt werden, wobei sichergestellt werden sollte, das der Client stets eine aktuelle Revocation Liste hat
crl-verify crl.pem

Weitere Informationen sind auf den entsprechenden OpenVPN Connect Seiten zu finden(iOS und Android).

Details zum Protokoll von OpenVPN

Wer sich mit dem Protokoll von OpenVPN genauere beschäftigen möchte dem seien folgende Seiten empfohlen:

Quellen sowie weitere Details zum härten der OpenVPN Konfiguration

In manchen Fällen können bestimmte, eher speziellere Optionen von OpenVPN noch interessant sein bzw. die Sicherheit erhöhen. Folgend sind u.a. die Quellen für die obigen Konfigurationsdateien aufgeführt und ebenso findet man dort teilweise Optionen für eher exotischere Setups.

MFA mit OpenVPN

Das BSI empfiehlt für besonders kritische Bereiche z.B. einen zweiten Faktor zu verwenden. Dies kann in OpenVPN z.B. unter Zuhilfename des PAM Plugins realisiert werden. Wobei dann z.B. Googles PAM Plugin für z.B. TOTP verwendet werden kann. Es existiert auch ein Standalone 2FA Plugin, dieses wird jedoch wohl nicht mehr aktiv gepflegt und scheint diverse Probleme zu haben[22][23].

Einrichtung des Google Authenticators zur Nutzung von TOTP als zweiten Faktor

In der Besprechung der Serverkonfiguration wurde bereits das PAM-Plugin von OpenVPN angesprochen. Nach der Aktivierung kann z.B. das PAM Plugin vom Google Authenticator verwendet werden. Installationsdetails findet man direkt auf deren GitHub-Seite[24]. Dort sind ebenfalls die Optionen für das Modul aufgeführt. Der "normale" Weg ist es für jeden Benutzer ein Account anzulegen. Durch die Moduloptionen ist es jedoch z.B. möglich dies auch anders zu realisieren.

Anmerkung: Dies hat in Tests nicht ordentlich funktioniert, da es immer wieder zu Fehlermeldungen über unzureichende Rechte kam - selbst wenn dies z.B. deaktiviert wurde! Auch kann es durch Einstellungen von SELinux zu schwierig auffindbaren Fehlern kommen. Ebenfalls kam es bei mir zu Problemen falls die Zertifikate in der Android Keychain lagen - dies hätte an sich keine Auswirkung auf den zweiten Faktor haben sollen.

Die Installation ist ziemlich straight forward. Nichtsdestrotrotz folgen Links zu etwas detailierteren Beschreibungen welche jedoch überwiegend älter oder nicht ganz passend sind:

Ungünstige Serveroptionen mit MFA

Falls MFA verwendet wird, sollte darauf geachtet werden, das als Cipher BF-CBC (BF-CBC ist keine sichere Cipher mehr!) nicht aktiv ist. Falls dies aus z.B. Kompatibilitätsgründen für z.B. manche Accounts noch zugelassen wird, sollte für diese die MFA deaktiviert werden. OpenVPN aktiviert automatisch die Option reneg-bytes x, welche eine Schlüsselneuaushandlung nach x (meist ~64MB) des Datenkanals bewirkt, was wiederum zur einer erneuten Abfrage der Authentifizierungsdaten führt und somit zur erneuten Eingabe des z.B. zweiten Faktors. Ebenso sind mit der gleichen Begründung die Optionen reneg-sec/bytes/pkts n nicht empfehlenswert, falls MFA verwendet wird.

Diverses

OpenVPN durch HTTP-Proxy tunneln

OpenVPN kann sich durch ein HTTP-Proxy mit einem OpenVPN Server verbinden. Dies kann gerade aus Firmennetzen heraus nötig werden, da dort häufig sehr restriktive Firewallregeln angewendet werden. Details dazu gibt es hier:

Fail2Ban Einstellungen für OpenVPN

Auch kann das beliebte Tool Fail2Ban eingesetzt werden um übermässig häufige Verbindungsversuche von der Firewall automatisch blockieren zu lassen. [25]

DNS-Resolver mit DNSSEC oder/und DoH

Da dem Client DNS-Server gepusht werden können, kann es Sinn machen einen eigenen Resolver aufzusetzen, welcher z.B. DNSSEC ermöglicht oder die Anfragen selbst per DoH auflöst.

DNSMASQ mit aktiviertem DNSSEC

DNSMasq ist ein Resolver der sich sehr leicht installieren und einsetzen lässt. Tutorials gibt es im Internet genüge, z.B. hier. Die Aktivierung von DNSSEC ist dabei nicht weiter schwer. In der Konfigurationsdatei - welche normalerweise unter /etc/dnsmasq.conf liegt - müssen folgende Optionen aktiviert bzw. hinzugefügt werden:

# Diese Option aktiviert DNSSEC
dnssec

# Die aktuellen Trust Anchors können hier gefunden werden
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

# Falls für eine Zone keine DNSSEC Signaturen gefunden wurden, werden weitere Daten verschickt um zu überprüfen ob für diese Zone wirklich keine DNSSEC Signatur vorliegt oder ob es zu einem MITM-Angriff kam
dnssec-check-unsigned

Überprüfen lässt sich das ganze dann z.B. unter https://dnssec.vs.uni-due.de/

DNS over HTTPS

Der Argo Tunnel Client(cloudflared) wird von Cloudflare rausgegeben und ermöglicht die Abfrage der DoH Server von Cloudflare. Dabei kann cloudflared direkt als DoH Proxy Server eingesetzt werden - dies wird jedoch in älteren Blogeinträgen nicht empfohlen[26]. Eine weitere Möglichkeit ist DNSMasq einzusetzten und dort den DoH Proxy Server zu verwenden. Ein Tutorial dazu findet sich z.B. hier.

Anmerkung: Falls z.B. ein Raspberry Pi B eingesetzt wird, liefern neuere Versionen von cloudflared einen Segmentation Fault. Unter [27] findet sich ein Link zu eineren älteren Version welche funktioniert.