Autor: Sebastian van de Meer (Seite 11 von 46)

DNS over TLS (DoT) mit BIND, Stunnel und Android 9 einrichten

16. Juli 2019 / Sebastian van de Meer / Keine Kommentare

Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.

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.

Screenshot der Konfigurationseinstellungen für DoT auf einem Android 9.

Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu.

Siehe auch: RFC 7858 – DNS over Transport Layer Security, DNS over TLS mit Stunnel und BIND9: Eigenen DoT-Server einrichten, DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server

Matrix Server Synapse: Erste Stable-Version 1 erschienen

12. Juni 2019 / Sebastian van de Meer / Keine Kommentare

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 🙂

Fragen? Einfach melden.

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

13. Mai 2019 / Sebastian van de Meer / Keine Kommentare

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.

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

Ersatz für www.dnsinspect.com: Alternatives DNS-Tool im Vergleich

26. April 2019 / Sebastian van de Meer / Keine Kommentare

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!

Fragen? Einfach melden.

FreeBSD: Native ZFS Encryption einrichten und nutzen

19. April 2019 / Sebastian van de Meer / Keine Kommentare

Seit FreeBSD 13 steht native ZFS Encryption zur Verfügung. Datasets lassen sich mit AES-256-GCM verschlüsseln, ohne dass der gesamte Pool verschlüsselt sein muss. Die Verschlüsselung greift pro Dataset und vererbt sich auf Kind-Datasets.

Verschlüsseltes Dataset anlegen

Ein neues Dataset mit Passphrase-Abfrage:

zfs create -o encryption=aes-256-gcm -o keyformat=passphrase usbpool/test01
Enter passphrase:
Re-enter passphrase:

Das Dataset wird sofort gemountet und ist einsatzbereit. Alles was hineingeschrieben wird, liegt verschlüsselt auf der Platte:

zfs list usbpool/test01
NAME             USED  AVAIL     REFER  MOUNTPOINT
usbpool/test01    99K   899G       99K  /usbpool/test01

zfs get encryption usbpool/test01
NAME            PROPERTY    VALUE        SOURCE
usbpool/test01  encryption  aes-256-gcm  -

Nach einem Reboot

Bei einem Passphrase-geschützten Dataset hat ZFS nach einem Reboot den Schlüssel nicht mehr. Das Dataset existiert, ist aber nicht gemountet:

zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   no       -

Mit zfs mount -l wird der Schlüssel geladen und das Dataset eingehängt:

zfs mount -l usbpool/test01
Enter passphrase for 'usbpool/test01':

zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   yes      -

Keyfile statt Passphrase

Statt einer Passphrase-Abfrage kann der Schlüssel auch in einer Datei liegen. Praktisch für Server die ohne Interaktion booten sollen:

zfs create -o encryption=aes-256-gcm \
  -o keyformat=passphrase \
  -o keylocation=file:///root/keys/pool.key \
  zroot/encrypted-data

Die Key-Datei enthält das Passphrase als Text. Wichtig: Die Datei muss beim Boot erreichbar sein, also auf einem unverschlüsselten Dataset liegen. Berechtigungen auf 0400 setzen.

Bestehende Datasets verschlüsseln

Verschlüsselung lässt sich nicht nachträglich auf ein bestehendes Dataset aktivieren. Man muss die Daten per zfs send | zfs receive in ein neues, verschlüsseltes Dataset migrieren. Die komplette Anleitung dafür steht im Beitrag ZFS-Dataset nachträglich verschlüsseln.

Eine Übersicht über alle ZFS-Funktionen gibt es im ZFS-Überblick. Wer sich für ZFS Encryption unter Solaris/OpenIndiana interessiert, findet die Anleitung unter ZFS Encryption unter Solaris. Fragen? Einfach melden.

Ich kann dir keine E-Mail schicken. Ich bekomme immer einen Fehler

13. April 2019 / Sebastian van de Meer / Keine Kommentare

Icon E-Mail Icon wird verdeckt von einem roten Kreis mit einem weißen Kreutz, welches verdeutlichen soll, dass E-Mail nicht funktioniert.

Einer der Vorteile eines eigenen Mailservers ist, dass man hier so restriktiv in seiner Konfiguration sein kann wie man es selbst für sich und seine Zwecke für richtig erachtet. So habe ich für mich entschieden, dass ich nur E-Mails annehmen möchte, welche über eine Transportverschlüsselung (TLS) bei mir eingeliefert werden. Wer also die folgende Meldung in seiner Errormail hat, dessen Mailserver hat sicher probiert die E-Mail bei mir ohne Transportverschlüsselung (also im Klartext) abzuliefern.

[...]
530-5.7.0 Must issue a STARTTLS command first
530 5.7.0 For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com
[...]

Transportverschlüsselung ist dabei bitte nicht zu verwechseln mit einer signierten oder gar verschlüsselten E-Mail. Ich nehme auch E-Mails an, welche weder signiert oder verschlüsselt sind. Die Transportverschlüsselung ist hier etwas wie das s bei httpS://. Das Mitlesen der E-Mail auf dem Weg zwischen eurem und meinem Mailserver soll damit nach Möglichkeit verhindert werden.

Möglichst verhindert werden? Ja, einen 100%tigen Schutz gibt es selbstverständlich nicht. Man kann nur versuchen sich diesem zu nähern. Dieses Nähern betrifft nun den zweiten Punkt welcher verhindern könnte, dass ihr mir eine E-Mail senden könnt. Die eingesetzte Transportverschlüsselung muss nämlich als „sicher“ gelten. Ich nehme also keine SSLv3 RC4 MD5 bla Verbindungen an. Wer also etwas wie das Folgende oder halt „Verbindung nicht möglich“ bekommt, dessen Mailserver ist nicht in der Lage eine „sichere“ TLS Verbindung aufzubauen.

warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared ciphe

warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol

warning: TLS library problem: error:142090FC:SSL routines:tls_early_post_process_client_hello:unknown protocol

Warum macht dieses nun nicht jeder so? Nun… Möchte man als Unternehmen Geld damit verdienen, dass man in irgendeiner Form Benutzer dazu bringt bei einem einen E-Mail Service zu nutzen, dann möchte man natürlich seinen Kunden einen möglichst reibungsfreien Austausch ermöglichen. Denn der normale Benutzer wird es kaum verstehen und sicher einfach einen Anbieter wählen bei dem es „funktioniert“. Dieses könnte man daher als Grund anführen warum nicht jeder so restriktiv in seinen Empfangseinstellungen ist. Davon abgesehen hindert es kein Unternehmen daran, seinem Mailserver für ausgehende E-Mails die Möglichkeit zu schaffen gutes TLS zu sprechen. Ok, es sei denn dieser Server steht in China oder Nordkorea. Mein Mailserver ist also weit davon entfernt etwas Unmögliches zu verlangen!!!

Sprecht also mal mit der zuständigen Person eures Mailservers und fragt aus welchem Grund euer Mailserver nicht in der Lage ist sicheres TLS zu sprechen und ob man dieses nicht vielleicht doch ändern könnte!

Um mich in der Zwischenzeit dennoch irgendwie zu erreichen gibt es verschiedene Möglichkeiten welche man >>hier<< findet. Am einfachsten sicher über Matrix/Riot: @kernel-error:kernel-error.com.

Bis dahin.

Siehe auch: SPF-Record einrichten | DKIM einrichten

Postfix: Eingehende E-Mails ohne TLS ablehnen

10. April 2019 / Sebastian van de Meer / Keine Kommentare

Standardmäßig nimmt Postfix E-Mails auch ohne Transportverschlüsselung an. Mit smtpd_tls_security_level = may bietet der Server TLS an, erzwingt es aber nicht. Das bedeutet: Wenn die Gegenseite kein STARTTLS kann oder will, wird die Mail trotzdem im Klartext übertragen.

Man kann das ändern und E-Mails ohne TLS komplett ablehnen. Die Frage ist ob man sich das leisten kann.

Konfiguration

# /usr/local/etc/postfix/main.cf
smtpd_tls_security_level = encrypt

Mit encrypt verweigert Postfix die Annahme wenn der sendende Server kein STARTTLS aushandelt. Die Gegenseite bekommt einen temporären Fehler (454) und kann es später nochmal versuchen. Im Log steht dann:

postfix/smtpd: NOQUEUE: reject: RCPT from mail.example.de[...]: 454 4.7.0 TLS is required but was not offered

Vorher prüfen

Bevor man TLS erzwingt, sollte man wissen wie viele Mails betroffen wären. Im Postfix-Log lässt sich das auswerten:

# Anteil TLS vs. Klartext bei eingehenden Verbindungen
grep "TLS connection established" /var/log/maillog | wc -l
grep "connect from" /var/log/maillog | wc -l

In der Praxis liegt der TLS-Anteil bei den meisten Mailservern über 95 Prozent. Die letzten paar Prozent sind oft schlecht gewartete Systeme, Onlineshop-Bestätigungen oder Geräte aus Asien die sich nie um TLS gekümmert haben. Ob das ein Problem ist, hängt davon ab wessen Mails man bereit ist zu verlieren.

Ausgehend erzwingen

Für ausgehende Mails ist die Situation anders. Mit smtp_tls_security_level = encrypt verweigert Postfix die Zustellung wenn die Gegenseite kein TLS anbietet. Das ist riskant, weil man keine Kontrolle darüber hat ob der Empfänger-Server TLS kann.

Der bessere Weg für ausgehende Mails: MTA-STS und DANE prüfen automatisch ob die Zieldomain TLS verlangt und welches Zertifikat erwartet wird. Damit erzwingt man TLS nur dort wo die Gegenseite es auch unterstützt und verifiziert gleichzeitig die Identität.

# Ausgehend: opportunistisch, aber DANE wenn verfügbar
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec

Mit dane als Security-Level nutzt Postfix DANE/TLSA-Records aus dem DNS. Ist ein TLSA-Record vorhanden, wird TLS erzwungen und das Zertifikat verifiziert. Ohne TLSA-Record bleibt es bei opportunistischem TLS. Zusammen mit dem Abschalten von TLS 1.0/1.1 ergibt das eine saubere Konfiguration. Fragen? Einfach melden.

Postfix: Client-Initiated Renegotiation sicher deaktivieren

10. April 2019 / Sebastian van de Meer / Keine Kommentare

client-initiated renegotiation beim SMTPD Server kann für DDoS Angriffe ausgenutzt werden. Die einzelnen TLS/SSL Optionen lassen sich über die recht gleichnamige Option im Postfix ein und ausschalten. Gibt es noch keinen mappenden Namen kann die jeweilige Option auch ein/ausgeschaltet werden mit dem jeweiligen Hexwert. Genau Infos findet man hier: http://www.postfix.org/postconf.5.html#tls_ssl_options

If the value of the parameter is a hexadecimal long integer starting with "0x", the options corresponding to the bits specified in its value are enabled (see openssl/ssl.h and SSL_CTX_set_options(3))

Für ein Postfix 3.3 und einem OpenSSL ab Version 1.1.1 ist der passende Hexwert 0x40000000.

Die Option setzt man wie so oft in der main.cf:

root@smtp:/ # postconf  tls_ssl_options
tls_ssl_options = 0x40000000

Ab Postfix >=3.4 gibt es: NO_RENEGOTIATION

Fragen? Dann fragen.

Fragen? Einfach melden.

FreeBSD als IPsec/L2TP-Client für Microsoft Windows Routing und RAS VPN

4. April 2019 / Sebastian van de Meer / Keine Kommentare

FreeBSD IPsec L2TP Client to Microsoft Windows Routing RAS Server Diagramm.

Einen FreeBSD-Desktop an einen Microsoft Windows Routing und RAS VPN-Server anbinden, per IPsec/L2TP. Klingt nach Qual, ist aber erstaunlich einfach. Ich nutze strongSwan für den IPsec-Tunnel und mpd5 für L2TP.

Ausgangslage

Der FreeBSD-Desktop hat die IP 192.168.10.57. Der Windows RRAS-Server steht unter vpnserver.domain.tld (88.88.88.88). Tunneltyp ist IPsec/L2TP mit Pre-Shared Key für IPsec und Active Directory-Anmeldung über L2TP. Die Firmennetze 172.16.0.0/12 und 10.0.0.0/8 sollen über den Tunnel erreichbar sein.

strongSwan: IPsec-Tunnel

/usr/local/etc/ipsec.conf:

config setup

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1
        authby=psk

conn vpnname
        type=transport
        leftfirewall=yes
        right=vpnserver.domain.tld
        rightid=%any
        rightsubnet=0.0.0.0/0
        auto=add
        left=%defaultroute
        leftprotoport=17/%any
        rightprotoport=17/1701
        ike=3des-sha1-modp1024!
        esp=3des-sha1
        modeconfig=push

Der Pre-Shared Key in /usr/local/etc/ipsec.secrets:

vpnserver.domain.tld %any : PSK "abcdefg1234567"

Tunnel aufbauen:

root@errortest:~ # ipsec up vpnname
initiating Main Mode IKE_SA vpnname[20] to 88.88.88.88
[...]
IKE_SA vpnname[20] established between 192.168.10.57[192.168.10.57]...88.88.88.88[88.88.88.88]
CHILD_SA vpnname{38} established with SPIs c387d93f_i 4720cab6_o
  and TS 192.168.10.57/32[udp] === 88.88.88.88/32[udp/l2f]
connection 'vpnname' established successfully

Status prüfen mit ipsec statusall. Wichtig ist die Zeile ESTABLISHED und dass die SPIs gesetzt sind.

mpd5: L2TP-Verbindung

/usr/local/etc/mpd5/mpd.conf:

startup:
    log +ALL +EVENTS -FRAME -ECHO

default:
    load L2TP_client

L2TP_client:
    create bundle static B1
    set iface up-script /home/kernel/vpnname-up.sh
    set iface down-script /home/kernel/vpnname-down.sh
    set bundle enable crypt-reqd
    set bundle enable compression
    set bundle enable ipv6cp
    set ccp yes mppc
    set mppc no e40 e56
    set mppc yes e128 stateless
    set ipcp ranges 0.0.0.0/0 0.0.0.0/0
    set ipcp enable req-pri-dns
    set ipcp enable req-sec-dns
    set iface route 172.16.0.0/12
    set iface route 10.0.0.0/8
    set iface enable tcpmssfix

    create link static L1 l2tp
    set link action bundle B1
    set auth authname "AD-USERNAME"
    set auth password "AD-PASSWORD"
    set link max-redial 0
    set link mtu 1400
    set link keep-alive 20 75
    set link accept chap-msv2
    set link no pap eap

    set l2tp peer vpnserver.domain.tld
    open

Starten mit mpd5. Wenn alles klappt, erscheint ein ng0 Interface:

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST>
    inet 10.16.100.34 --> 10.16.100.13 netmask 0xffffffff

Hinweise zur mpd5-Konfiguration

set ccp yes mppc aktiviert MPPC-Komprimierung und MPPE-Verschlüsselung. set mppc yes e128 stateless ist Pflicht für die Zusammenarbeit mit MS-CHAPv2 auf der Windows-Seite. Andere MPPE-Varianten (e40, e56) funktionieren mit MS-CHAPv2 nicht.

Der Windows VPN-Server übermittelt zwar Routen und DNS-Server, mpd5 übernimmt davon aber nicht alles automatisch. Deshalb die manuellen Routen mit set iface route. Die DNS-Server werden per IPCP abgefragt und an die Up/Down-Scripte übergeben. Da ich die DNS-Konfiguration kenne, kopiere ich in den Scripten einfach die passende /etc/resolv.conf.

Ich starte IPsec und dann mpd5 von Hand, wenn ich die Verbindung brauche. Man kann beides auch als Dienst konfigurieren.

Wer seinen Windows RRAS-Server mit sicheren Cipher Suites absichern will: In dem Beitrag geht es um die TLS-Seite der gleichen Infrastruktur.

Siehe auch: RRAS L2TP/IPsec VPN Cipher Suites

Fragen? Einfach melden.

Ausfall bei Telekom SmartHome

31. März 2019 / Sebastian van de Meer / Keine Kommentare

Das Telekom SmartHome System hat seit gestern am Morgen Probleme. Die automatischen Regeln tun was sie sollen und lokal kann man sich ebenfalls noch mit der Box verbinden und fast wie gewohnt steuern. Online ist aber kein Stich zu machen. Ebenfalls die Anbindung mit anderen Onlineservices ist damit tot.

https://community.qivicon.de/questions/ausfall-im-qivicon-rechenzentrum-homebases-aktuell-nicht-online

Ausfällt und Probleme kann es immer mal geben. Vor allem dieses Qivicon / Telekom „Ding“ ist mäßig stabil, tat aber in den letzten Monaten recht brauchbar seinen Dienst. Ein Ausfall von nun knapp 24Stunden ist dennoch echt heftig. Ich kann mir nicht viele Dinge vorstellen bei denen es zu so einem langen Ausfallen kommen kann, vor allem das die Herren so ja keinen besonderen Peak haben dürften. Hier hat wohl jemand echt massiv verkackt, sofern nicht gerade jemand die Jungs mit einem DDoS „warm“ hält. Das hätte man sicher schon über andere Wege erfahren.

Ob da wohl jemand die Datenbank kaputt gemacht hat? Vielleicht ist hier ja was out of sync, das wieder zusammen zu bekommen kann schon mal echt lange dauern. Fast alles andere ist: An der falschen Stelle gespart oder halt epic fail.