IT-Blog von Sebastian van de Meer

Kategorie: IT-Security (Seite 6 von 15)

Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.

Da hat jemand SSLv3 bei Bechtle abgeschaltet….

Erinnert ihr euch noch an meine Onlinetool Empfehlung und den dort verwiesenen Mailserver der Domain bechtle.com/de? Auf meine Frage hin hat mir ja leider niemand richtig geantwortet, nicht mal der Postmaster 🙁 Aber inzwischen ist SSLv3 abgeschaltet!

Es hätte ja zumindest mal jemand etwas anders sagen können als: „Geh weg du bist privat, dafür haben wir hier so nen anderen…“ Aber naja… Nun gibt es am Mailserver von Bechtle zumindest kein SSLv3 mehr 😀 Ich stelle mir einfach weiterhin vor, dass es durch meinen Hinweiß abgeschaltet wurde.

In diesem Sinne…

Postfix MTA-STS Resolver für FreeBSD mit Logfile einrichten

Ich habe heute auch mal den postfix-mta-sts-resolver auf meinem privaten System zugeschaltet. Einfach um es mal zu „probieren“.

Tut einfach und wie beschrieben, ist so aber sicher nicht für größeren und produktiven Betrieb gedacht. So wie der resolver kommt schreibt er alle Meldungen leider nur in die Konsole, es gibt keinen File-Logger. Ich ähm will/brauch den aber!

Also habe ich einen Fork erstellt und ihn überredet in eine Datei zu loggen und direkt noch ein sehr rudimentäres rc.d init script beigelegt: https://github.com/Kernel-Error/postfix-mta-sts-resolver

Wer es also ebenfalls mal probieren möchte, viel Spaß.

Der mta-sts-daemon loggt nun per default in /var/log/mta-sts.log. Config über yml ist ebenfalls nun drin genau wie die Konfiguration per Startparameter. Das rc.d script für FreeBSD könnte sicher schöner sein und hätte gerne im default den Benutzer mta-sts im System. Wir wollen es ja nicht als Root laufen lassen, hm?

Das einzelne Programm mta-sts-query greift auf den gleichen Logger zu, gibt damit also nichts mehr in der Konsole aus sondern auch im Logfile. Vielleicht passe ich dieses noch an, wenn dann mache ich auch einen pull request. Sonst gehe ich mal davon aus, dass es eh bald im postifx ist *daumen-drück*


Update

Habe ich jetzt gemacht. Pullrequest wurde angenommen und das neue Release ist auch schon gemacht. Jetzt also mit Logfile und rc.d script für FreeBSD.

Fragen? Dann fragen 🙂

SMTP MTA-STS: Strict Transport Security für deinen Mailserver

Haben wir uns schon über MTA STS / RFC 8461 unterhalten? Nicht? Dann dann wird es aber Zeit 🙂

MTA STS ist ein RFC von Ende 2018. So kann man eine Policy veröffentlichen um anderen Mailservern mitzuteilen, dass man seine E-Mails bitte nur per TLS (also mit Transportverschlüsselung) erhalten möchte und an welchen MX…

Eine ganz nette Idee nur…. Wenn man keine E-Mail ohne Transportverschlüsselung erhalten möchte, dann könnte man ja einfach keine E-Mails ohne Transportverschlüsselung annehmen?!?!? Natürlich sagt man anderen Mailservern zusätzlich noch an welchen sie bitte die Mails zustellen sollen, das es eine Transportverschlüsselung geben muss und alles nur mit einem gültigen Zertifikat ablaufen kann.

Fehlt da nicht noch etwas? Klar reporting… Dazu gibt es im Moment ein RFC: SMTP TLS Reportingdraft-ietf-uta-smtp-tlsrpt-23

Ein einfaches Onlinetool zum Testen gibt es ebenfalls: MTA-STS validator

Was muss man dafür nun tun? Ohne Frage muss der eigene Mailserver sauber TLS sprechen… Dann wirfst man einen TXT RR in die jeweilige DNS Zone:

$ dig IN TXT _mta-sts.kernel-error.de +short
"v=STSv1;id=20190202111557Z;"

Die eigentliche Policy veröffentlich man nun per Webserver jeweils für die Zone unter: mta-sts.domain.tld https://mta-sts.kernel-error.de/.well-known/mta-sts.txt

Das Reporting lässt sich ebenfalls schnell per TXT RR in der DNS Zone einrichten:

$ dig IN TXT _smtp._tls.kernel-error.de +short
"v=TLSRPTv1;rua=mailto:postmaster@kernel-error.de"

Beides ist sehr schnell und einfach eingerichtet. Postfix selbst berücksichtigt dieses leider noch nicht. Es gibt natürlich schon eine Implementierung, welche ich persönlich noch nicht ganz glücklich finde. Wer schon mal schauen will: https://github.com/Snawoot/postfix-mta-sts-resolver

Fragen? Dann einfach mal fragen 🙂

Mailserver Test aus Holland

In den Niederlanden gibt es eine staatliche Initiative um das Internet Sicherer zu machen. Dazu gehören ebenfalls verschiedene Onlinetools zum Testen seiner Systeme.

Ganz gelungen finde ich dabei das Tool zum Testen seines Mailserver. Wenn ich da einfach mal eine Domain eintrage: https://en.internet.nl/mail/bechtle.de/201507/ Fällt mir auf, dass ich da mal fragen sollte warum SSLv3 mit RC4 hier anscheinend noch OK ist.

Viele Spaß beim Selbstscan! Bei Fragen natürlich wie immer einfach fragen 🙂


Als kleines Update… Die Jungs haben auf meine Frag/Hinweiß geantwortet:

Guten Tag,

vielen Dank für Ihre Anfrage und das damit verbundene Vertrauen in unser Unternehmen.

In der Bechtle Gruppe sind die Kundensegmente zwischen Bechtle direct GmbH und der ARP GmbH so aufgeteilt, das jeder Kunde gemäß seinen Bedürfnissen optimal betreut werden kann.

Während sich die BechtleAC direct GmbH ausschließlich auf Großkunden und Konzerne konzentriert, bietet die ARP GmbH allen Kundensegmenten ein großes Sortiment von IT-Hard- und Software sowie individuellen IT-Lösungen an. Neben der persönlichen Betreuung verfügt die ARP GmbH über einen preisgekrönten Online-Shop, der auf die individuellen Bedürfnisse jedes Kunden anpassbar ist.

Bitte wenden Sie sich mit Ihrem Anliegen direkt an die ARP GmbH. 

Hm… Ob sie das RFC beachten und ich den Postmaster erreiche?

*trommelwirbel*

Mar  6 08:14:49 smtp postfix/smtp[97730]: 5193FB4292: to=<postmaster@bechtle.com>, relay=mx.bechtle.com[178.249.84.24]:25, delay=17, delays=0.41/0.02/15/1.2, dsn=2.0.0, status=sent (250 2.0.0 2qygs8tdp2-1 Message accepted for delivery)

Zumindest nicht sofort abgewiesen 🙂

E-Mail Adressen

Das ist eine Kontaktliste mit E-Mail Adressen, an welche man unbedingt Angebote schicken muss. Wer fragen zur Kontaktliste hat, bitte einfach melden!

wurstmann@kernel-error.org

kleinmann@kernel-error.org

hundebauch.balem@kernel-error.org

info@kernel-error.org

buchhaltung@kernel-error.org

management@kernel-error.org

ceo@kernel-error.org

wurstmann@tagesmutter-rheinbach.de

kleinmann@tagesmutter-rheinbach.de

hundebauch.balem@tagesmutter-rheinbach.de

info@tagesmutter-rheinbach.de

buchhaltung@tagesmutter-rheinbach.de

management@tagesmutter-rheinbach.de

ceo@tagesmutter-rheinbach.de

wurstmann@van-alst.de

kleinmann@van-alst.de

hundebauch.balem@van-alst.de

info@van-alst.de

buchhaltung@van-alst.de

management@van-alst.de

ceo@van-alst.de

wurstmann@linux-rheinbach.de

kleinmann@linux-rheinbach.de

hundebauch.balem@linux-rheinbach.de

info@linux-rheinbach.de

buchhaltung@linux-rheinbach.de

management@linux-rheinbach.de

ceo@linux-rheinbach.de

wurstmann@kindertagespflege-sprockhoevel.de

kleinmann@kindertagespflege-sprockhoevel.de

hundebauch.balem@kindertagespflege-sprockhoevel.de

info@kindertagespflege-sprockhoevel.de

buchhaltung@kindertagespflege-sprockhoevel.de

management@kindertagespflege-sprockhoevel.de

ceo@kindertagespflege-sprockhoevel.de

wurstmann@geekbundle.de

kleinmann@geekbundle.de

hundebauch.balem@geekbundle.de

info@geekbundle.de

buchhaltung@geekbundle.de

management@geekbundle.de

ceo@geekbundle.de

TLS 1.3 für Postfix & Dovecot: Einrichtung und Konfiguration​

TLS 1.3 ist im Mailbetrieb kein Sonderfall mehr, sondern der Normalzustand. Voraussetzung ist lediglich, dass Postfix und Dovecot gegen eine aktuelle OpenSSL-Version gelinkt sind. Sobald OpenSSL TLS 1.3 unterstützt, wird es automatisch verwendet. Eine explizite Aktivierung in der Applikation ist nicht erforderlich.

Die eigentliche Aufgabe der Konfiguration besteht daher nicht darin, TLS 1.3 „einzuschalten“, sondern darin, alte Protokollversionen sauber zu deaktivieren und für den verbleibenden TLS-1.2-Fallback eine kontrollierte Cipher-Policy zu definieren.

Illustration zu TLS 1.3 im Mailbetrieb: Symbolische Darstellung von Postfix und Dovecot mit Schloss und Schlüssel vor Server-Hintergrund, steht für verschlüsselte SMTP- und IMAP-Verbindungen mit modernen TLS-Standards.

Voraussetzungen

Postfix und Dovecot müssen gegen OpenSSL ≥ 1.1.1 gebaut sein. OpenSSL 3.x funktioniert ebenfalls ohne Einschränkungen. Welche Version tatsächlich genutzt wird, lässt sich eindeutig prüfen:

postconf -a | grep -i tls
dovecot --version
ldd $(which dovecot) | grep ssl
openssl version

Wenn hier OpenSSL 1.1.1 oder neuer auftaucht, ist TLS 1.3 verfügbar.

Postfix

Postfix verwendet TLS 1.3 automatisch, sofern der Client es anbietet. Entscheidend ist, welche Protokollversionen minimal erlaubt werden. TLS 1.0 und TLS 1.1 gelten als kryptographisch überholt und sollten nicht mehr akzeptiert werden.

Die folgende Konfiguration beschränkt Postfix auf TLS 1.2 und neuer. TLS 1.3 wird dabei bevorzugt ausgehandelt, TLS 1.2 dient nur noch als Fallback.

smtpd_tls_protocols = >=TLSv1.2
smtp_tls_protocols  = >=TLSv1.2

smtpd_tls_security_level = may
smtp_tls_security_level  = may

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/DOMAIN/privkey.pem

Cipher-Optionen in Postfix gelten ausschließlich für TLS 1.2 und ältere Protokolle. TLS 1.3 verwendet fest definierte Cipher-Suites und ignoriert diese Einstellungen vollständig. Dennoch ist es sinnvoll, für den TLS-1.2-Fallback eine saubere Policy zu setzen.

tls_preempt_cipherlist = yes

smtpd_tls_ciphers = high
smtp_tls_ciphers  = high

Damit werden nur moderne Cipher mit Forward Secrecy genutzt, abhängig von den OpenSSL-Defaults der jeweiligen Distribution.

Session-Caching reduziert Handshake-Overhead und sollte aktiv sein:

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database  = btree:${data_directory}/smtp_scache

Dovecot

Auch Dovecot nutzt TLS 1.3 automatisch, sofern OpenSSL es bereitstellt. Die relevante Einstellung ist die minimale Protokollversion. Alles darunter wird explizit ausgeschlossen.

ssl = required
ssl_min_protocol = TLSv1.2

Die Cipher-Liste in Dovecot betrifft ebenfalls nur TLS 1.2 und älter. TLS 1.3 wird davon nicht beeinflusst. Eine explizite, restriktive Cipher-Liste verhindert jedoch unsaubere Fallbacks bei älteren Clients.

ssl_cipher_list = \
ECDHE-ECDSA-CHACHA20-POLY1305:\
ECDHE-RSA-CHACHA20-POLY1305:\
ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES256-GCM-SHA384

ssl_prefer_server_ciphers = yes

Die Zertifikate werden wie gewohnt eingebunden:

ssl_cert = </etc/letsencrypt/live/DOMAIN/fullchain.pem
ssl_key  = </etc/letsencrypt/live/DOMAIN/privkey.pem

TLS 1.3 und Cipher-Suites

TLS 1.3 unterscheidet sich grundlegend von älteren Versionen. Die Cipher-Suites sind fest definiert und bestehen ausschließlich aus modernen AEAD-Verfahren mit integrierter Authentifizierung und Forward Secrecy. Typische Cipher sind AES-GCM und CHACHA20-POLY1305.

Postfix und Dovecot bieten keine Möglichkeit, diese Cipher direkt zu konfigurieren. Die Auswahl erfolgt intern durch OpenSSL während des Handshakes. Das ist beabsichtigt und reduziert Fehlkonfigurationen erheblich.

Wer versucht, TLS-1.3-Cipher über Applikationsoptionen zu beeinflussen, konfiguriert faktisch nur TLS 1.2.

Verifikation

Ob TLS 1.3 tatsächlich genutzt wird, lässt sich eindeutig prüfen.

SMTP mit STARTTLS:

openssl s_client -starttls smtp -connect mail.example.com:25 -tls1_3

IMAPS:

openssl s_client -connect mail.example.com:993 -tls1_3

Wird der Handshake erfolgreich aufgebaut und ein moderner AEAD-Cipher angezeigt, ist TLS 1.3 aktiv. Fällt die Verbindung auf TLS 1.2 zurück, greift die konfigurierte Cipher-Liste.

Fazit

TLS 1.3 erfordert in Postfix und Dovecot keine Sonderbehandlung. Entscheidend ist eine aktuelle OpenSSL-Version, eine klare Mindest-TLS-Policy und eine saubere Cipher-Konfiguration für den unvermeidbaren TLS-1.2-Fallback.

Alles andere erledigt der TLS-Stack selbst.

Kein Feature-Flag.
Keine Magie.
Nur korrekte Defaults, bewusst begrenzt.

Hardenize ein Security-Scanner für die Domain

Mir ist ein weiteres Onlinetool zum scannen seiner Domain durch den Browser gerutscht. https://www.hardenize.com/

Wie immer darf man nicht bild jedem Tool trauen und sich ohne denken darauf verlassen! Die Ergebnisse müssen immer mit dem nötigen Hintergrundwissen und Feingefühl interpretiert werden…. Hardenize testet nach der Eingabe einer Domain etwas umfassender. Es schaut sich die TLS Konfiguration der Webseite, sowie des Mailservers an. Prüft auf wichtige Policys, schaut in den DNS und bewertet somit etwas das Gesamtbild.

Vielleicht interessant für einen von euch.

Geht deine Domain am 01.02.2019 noch oder ist dein DNS kaputt?

Hey,

viele übersehen wohl gerade das es in drei Tagen ein Problem mit ihrem DNS und vor allem der Erreichbarkeit ihrer Zone geben könnte.

Testet doch einfach mal ob eure Domain/Zone ein Problem bekommt oder nicht >>klick<<

Es dreht sich alles darum, dass man entlich mal die „alten“ DNS Server aus dem Internet schieben möchte. Heise hat das ganz fein zusammengeschrieben: >>heise-klick<<

Oder halt direkt bei: https://dnsflagday.net/

Spannend wird es ab dem 01.02.2019. Wer also ab dann keine Stress habe möchte sollte vielleicht noch mal nachsehen?

Viel Spaß 😀

TLS 1.3 ist da!

Im August wurde TLS 1.3 auf der IETFE-Tagung als fertig beschlossen 😀 Damit haben sich aber alle wirklich Zeit gelassen! OpenSSL hat am 11.09.2018 die Version 1.1.1 (LTS) freigegeben. Am 12.09.2018 ist diese in die FreeBSD Ports gekommen und:

root@www:/ # /usr/local/bin/openssl version
OpenSSL 1.1.1 11 Sep 2018

Fehlt also nur noch ein Eintrag in der make.conf und schon lässt sich nginx sauber dagegen bauen und alles automatisch mit portmaster auf dem neusten Stand halten 🙂

/etc/make.conf
DEFAULT_VERSIONS+= ssl=openssl111

Schaut mal nach, die meisten machen wohl jetzt schon TLS 1.3 beim lesen dieser Zeilen ^^

Qualys und SSL Labs hängen leider noch etwas nach, hier wird noch auf/gegen die Draft Version geprüft (For TLS 1.3 tests, we currently support draft version 28.). Aber ich wette das wird nicht mehr lange dauern!

Kleines Update, die HIGH-TECH Bridge Jungs testen sauber auf TLS 1.3.

Ich wurde gerade drauf hingewiesen, dass die Developer Version von ssllabs TLS 1.3 schon sauber testet. Danke Jost 😀

https://dev.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&s=2a01%3a4f8%3a161%3a3ec%3a0%3a0%3a0%3a443&hideResults=on&latest

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑