feed-image -=Kernel-Error=- BlogFeed

DoT DNS over TLS mit Bind, stunnel und Android 9

Die eigenen DNS Anfragen über eine Verschlüsselte Verbindung an einen DNS Server zu schicken welchem man vertraut, dieses liest sich schon gut oder? Keiner verfolgt mein Surfverhalten und zusammen mit DNSSEC schiebt mir so schnell keiner falsche Records unter :-)

Am ehesten vertraue ich meinem eigenen DNS Server (ns1.kernel-error.de). Auf diesem arbeitet ein Bind und vor diesen habe ich für DoT stunnel gestellt. Die Konfiguration vom stunnel sieht dabei grob wie folgt aus:

[dns4]
accept = 853
connect = 127.0.0.1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt
ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
options = NO_SSLv2
options = NO_SSLv3
options = NO_TLSv1
options = NO_TLSv1.1
options = CIPHER_SERVER_PREFERENCE
options = DONT_INSERT_EMPTY_FRAGMENTS
renegotiation = no
TIMEOUTclose = 0

[dns6]
accept = 2a03:4000:38:20e::53:853
connect = ::1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt
ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
options = NO_SSLv2
options = NO_SSLv3
options = NO_TLSv1
options = NO_TLSv1.1
options = CIPHER_SERVER_PREFERENCE
options = DONT_INSERT_EMPTY_FRAGMENTS
renegotiation = no

Die TLS Konfiguration ergibt dabei nun folgendes Bild: https://tls.imirhil.fr/tls/ns1.kernel-error.de:853

Auf einem Android 9 Gerät kann ich also nun unter den Einstellungen ==> Netzwerk & Internet ==> Erweitert ==> Privates DNS meinen Nameserver eintragen.

DoT Android 9

Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu :-D

Der Matrix Server Synapse ist in der ersten Stable Version 1 erschienen

Es hat einige Zeit gedauert aber gestern ist Synapse in Version 1.0.0 erschienen.

https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-and-the-matrix-org-foundation
https://matrix.org/blog/2019/06/11/synapse-1-0-0-released
https://github.com/matrix-org/synapse/releases/tag/v1.0.0

Eine ganz wichtige Änderung der Version ist, dass Zertifikate anderer Server ab jetzt gültig sein müssen.

Wer seinen Server mittels pip auf den letzten Stand bringen möchte:

$ pip install --upgrade matrix-synapse

"Meldet" euch doch mal wenn es klappt :)

Ersatz für www.dnsinspect.com

Lange Zeit war dnsinspect eine wunderbare Anlaufstelle um "mal eben" eine DNS Zone sowie deren Nameserver auf die gröbsten Probleme hinsichtlich ihrer Konfiguration zu prüfen. Schon vor Monaten ging dann dnsinspect in threatintelligenceplatform auf... Hier kann man (mit Account) zwar noch immer prüfen, es ist für mich nur nicht mehr so flüssig, simpel und detailreich wie ich es gerne hätte. Daher musste ein Ersatz hier und dieser ist https://zonemaster.net/

Dieses erfüllt alle meine Wünsche und hat genau einen Zweck und Nutzen. Schaut einfach mal drauf!

Tool der europäischen Kommission zur E-Mail Sicherheit MECSA

Die Europäische Kommission hat ein online Tool veröffentlicht, welches jedem Benutzer eines E-Mail Dienstes ermöglichen soll den eingesetzten E-Mail Dienst zu "prüfen".

Natürlich kann man sich nicht blind auf so einen Test verlassen aber dieses Tool gibt einem eine ganz gute Übersicht. Diese wird dabei in drei Bereiche unterteilt:

1. Confidential Delivery
2. Phishing and Identity Theft
3. Integrity of Messages

Dazu habe ich für euch sogar ein >>Youtube Video<<.

Zum Tool selbst geht es hier lang: https://mecsa.jrc.ec.europa.eu/en/

Dort kann man nun seine E-Mail Adresse eintragen, zu dieser sendet das Tool nun eine E-Mail und bittet darum auf die Mail zu antworten. Hat man dies erledigt bekommt man seinen Code zur Auswertung. Diesen kann man nun auf der gleichen Seite eintragen und sich seine Auswertung anschauen.

Mein Identifier vom Report heute ist zum Beispiel: 19a837a05e4b7e04a3dea8cea29bd355

Prüft also ruhig einmal euer eingesetztes Mailsystem und fragt ggf. bei eurem Anbieter/Admin nach, wenn ich beim Ergebnis unsicher seit.

FreeBSD und native ZFS Encryption

FreeBSD portierte bisher seinen ZFS Zweig von Illumos. Dieses wechselt nun zu ZFS on Linux. Was es für mich so spannend macht ist der Verschlüsselungssupport. ZFS on Linux bietet diesen bereits und somit wird er wohl auch bald für FreeBSD zur Verfügung stehen :-)

Gerade eben lese ich eine E-Mail von Kris Moore auf der FreeBSD-Current Mailingliste. In der E-Mail werden zwei ISO Images genannt welche es ermöglichen FreeBSD mit ZFS on Linux zu testen. \o/ Natürlich ist es nicht die Version welche am Ende "drin" sein wird und es ist nichts was man auch nur im Ansatz produktiv einsetzten kann/sollte. ABER testen soll man es ja und ich möchte unbedingt mal die Verschlüsselung sehen!

Daher habe mich mir die gepatchte FreeBSD13 Version einmal herunter geladen: https://pkg.trueos.org/iso/freebsd13-zol/FreeBSD13-ZoL-20190418-x64.iso

Zuletzt habe ich den Einsatz unter Solaris beschrieben. Nun also einmal ganz kurz und knapp in FreeBSD :-)

Erstellen eines neuen Datasets:

root@freebsd13-zol:~ # zfs create -o encryption=aes-256-gcm -o keyformat=passphrase usbpool/test01
Enter passphrase:
Re-enter passphrase:

Als Art der Verschlüsselung habe ich hier aes-256-gcm gewählt und der Schlüssel soll als passphrase von mir eingegeben werden. Nachdem ich mein passphrase eingegeben habe wird das neue Dataset erstellt und direkt für mich ein gehangen, wie man es gewohnt ist:

root@freebsd13-zol:~ # zfs list usbpool/test01
NAME             USED  AVAIL     REFER  MOUNTPOINT
usbpool/test01    99K   899G       99K  /usbpool/test01
root@freebsd13-zol:~ # zfs get encryption usbpool/test01
NAME            PROPERTY    VALUE        SOURCE
usbpool/test01  encryption  aes-256-gcm  -
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   yes      -

Da ein passphrase von mir jeweils eingegeben werden muss, kann dieses Dataset bei einem reboot oder impot/export nicht automatisch eingehangen werden.

root@freebsd13-zol:~ # zpool export usbpool
root@freebsd13-zol:~ # zpool import usbpool
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   no       -

Daher muss ich dieses von Hand anstoßen.

root@freebsd13-zol:~ # zfs mount -l usbpool/test01
Enter passphrase for 'usbpool/test01':
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   yes      -

Genau so habe ich es mir gewünscht. Schnell, einfach und unkompliziert. Ob es ebenfalls über Snapshots send/recv und mit Keyfiles usw. so arbeitet wie ich es mir wünsche, werde ich nun probieren können!

Ein verschlüsseltes Dataset anlegen zu können, erfreut mich aber jetzt schon sehr!

Fragen? Dann fragen :)


Update

Um Fragen zu beantworten. Ja, die Userland Tools und das Kernelmodul sind bereits in den Ports. Will man es auf einem FreeBSD 12.x RELEASE bauen funktioniert dieses nicht:

root@test:/usr/ports/sysutils/zol-kmod # make install clean
===>  zol-kmod-2019041800 needs FreeBSD 12/13 with AES-CCM support.
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/zol-kmod

Es funktioniert sauber mit FreeBSD 13 CURRENT und dem FreeBSD 12 STABLE. CURRENT ist bei FreeBSD immer die nächste Version. Die RELEASE Versionen sind die stabilen Versionen welche auch nur noch Security und Bugfixes bekommen. Die STABLE Verstion bekommt zudem noch "Veränderungen" mit. Ganz grob kann man es also mit Stable, Testing, Unstable bei Debian vergleichen :-)

Der AES-CCM Support ist also nur in FreeBSD 13 CURRENT und in FreeBSD 12 STABLE im Kernel aktiviert. Man kann also nun zum Testen auf die 13 wechseln, auf die 12 Stable gehen, auf das nächste RELEASE warten, seinen Kernel neu bauen oder eines der ISOs oben probieren. Jetzt ist auch klar, warum ich die ISOs so empfehlenswert fand/finde :-D Vor allem da das FreeBSD 12 ISO das FreeBSD 12.0-RELEASE-p3 ist und man so schon seine Produktivumgebung testen kann!