-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Postfix (Seite 2 von 5)

Eigene DNS-Blocklisten in Postfix: DNSRBL und RHSBL einrichten

30. Januar 2017 / / Keine Kommentare

Postfix kann eingehende Mails anhand von DNS-basierten Blocklisten ablehnen. Zwei Typen sind relevant: DNSRBL (IP-basiert) prüft ob die sendende IP-Adresse auf einer Blockliste steht. RHSBL (Domain-basiert) prüft ob die Absenderdomain gelistet ist. Beides passiert in Echtzeit während der SMTP-Sitzung, noch bevor die Mail angenommen wird.

Öffentliche Listen

Es gibt dutzende öffentliche Blocklisten. Nicht alle sind gleich zuverlässig. Diese hier laufen bei mir seit Jahren ohne nennenswerte False Positives:

# /etc/postfix/main.cf (Auszug)
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client bl.spamcop.net,
   reject_rbl_client b.barracudacentral.org,
   reject_rbl_client ix.dnsbl.manitu.net,
   permit

zen.spamhaus.org ist die Kombiliste von Spamhaus (SBL + XBL + PBL). ix.dnsbl.manitu.net wird in Deutschland gepflegt und erwischt deutschsprachigen Spam den internationale Listen übersehen.

Eigene Listen

Zusätzlich betreibe ich eigene Blocklisten unter kernel-error.de. Die werden teils von Hand gepflegt, teils automatisch aus einem Honeypot-Postfach befüllt. Einträge bleiben mindestens sechs Monate drin:

# Eigene Listen (RHSBL + RBL)
reject_rhsbl_sender abuse.rhsbl.kernel-error.de,
reject_rhsbl_sender postmaster.rhsbl.kernel-error.de,
reject_rhsbl_sender spam.rhsbl.kernel-error.de,
reject_rbl_client spam.rbl.kernel-error.de,

Die RHSBL-Listen prüfen die Absenderdomain: abuse listet Domains ohne funktionierende abuse-Adresse, postmaster solche ohne postmaster-Adresse, spam bekannte Spam-Domains. Die RBL-Liste prüft die IP-Adresse des sendenden Servers.

Warnung

Das sind meine privaten Listen. Ich pflege sie nach meiner persönlichen Einschätzung. Wer sie produktiv einsetzt, macht das auf eigene Verantwortung. Es wird zu False Positives kommen, weil meine Kriterien nicht mit den eigenen übereinstimmen müssen. Für den eigenen Mailserver sind sie ein nützlicher Baustein neben den öffentlichen Listen. Für fremde Mailserver würde ich sie nicht empfehlen.

Wer seinen Postfix weiter absichern will: Die HELO-Prüfung fängt einen erstaunlichen Anteil an Spam ab, bevor die RBL-Abfrage überhaupt nötig wird. Fragen? Einfach melden.

Apache 2.4 und Diffie-Hellman DHE mit 4096bit

6. Juli 2015 / / Keine Kommentare

Kaum geht mein Artikel zur erweiterten Sicherheit meiner Webseite online >>TLS Sicherheit weiter verschärft….<< schon kommen Fragen. Eine habe ich nun schon vier mal bekomme, daher hier direkt die Antwort. Ach ja, die Frage:

Wie habe ich meinen Apache dazu überredet DHE-Keys mit 4096bit zu benutzen?

Also… Der Apache beherrscht seit Version 2.4 Diffie Hellman mit mehr als 1024bit. Um dieses nutzen zu können, muss der Apache die passenden dh-params haben. Der Apache nutzt dabei automatisch die ihm gegebene Key stärke.

Ich generiere den DH Teil gerne direkt mit dem jeweiligen Zertifikat und verbinde dieses. Beschrieben habe ich es hier: >>Sicheres SSL / TLS Zertifikat<<

Wer gerne nachträglich generieren möchte macht es mir:

$ openssl gendh 4096 > dh_4096.pem

Dieses lässt sich nun einfach wie ein normales Zertifikat mit in die Konfiguration des Apachen einbinden. Im Grunde nichts besonders und nachdem man es gelesen und absolut einleuchtend, man sucht aber dann doch zuerst etwas.

Viele andere Dienste (Postfix usw…) bringen ja meist einen eigenen Konfigurationspunkt dafür mit. Im Apache liegt es ohne große Konfiguration in Zertifikatsnähe.

easy

So long….

Fragen? Einfach melden.

Postfix und DANE: „Server certificate not verified“ debuggen

2. Februar 2015 / / Keine Kommentare

Eine Mail kommt als unzustellbar zurück. Im Bounce steht Server certificate not verified, im Postfix-Log sieht es so aus:

smtp[1520]: Trusted TLS connection established to example.de[...]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
smtp[1520]: 30E4E7461347: Server certificate not verified
smtp[1520]: 30E4E7461347: to=, dsn=4.7.5, status=deferred (Server certificate not verified)

Erst „Trusted TLS connection“, dann „Server certificate not verified“. Das klingt widersprüchlich, hat aber eine klare Ursache.

Ursache: DANE/TLSA-Prüfung fehlgeschlagen

Ohne DANE würde Postfix die Mail trotzdem zustellen, auch wenn das Zertifikat nicht verifizierbar ist. Aber wenn der Empfänger einen TLSA-Record im DNS veröffentlicht hat, prüft Postfix das Zertifikat gegen diesen Record. Stimmt der Hash nicht überein, verweigert Postfix die Zustellung. Das ist gewolltes Verhalten: Entweder der Empfänger hat seinen TLSA-Record nicht aktualisiert (z.B. nach einem Zertifikatstausch), oder jemand versucht sich dazwischen zu drängen.

Debugging mit posttls-finger

posttls-finger (Teil von Postfix) prüft den kompletten DANE-Ablauf für eine Domain:

posttls-finger -t30 -T180 -c -L verbose,summary example.de

In der Ausgabe steht am Ende entweder Verified TLS connection established (alles OK) oder Untrusted TLS connection established (TLSA-Prüfung fehlgeschlagen). Zusätzlich zeigt das Tool den TLSA-Record aus dem DNS und den Fingerprint des Zertifikats. Stimmen die beiden nicht überein, liegt das Problem beim Empfänger.

Was Postfix dann macht

Eine fehlgeschlagene DANE-Prüfung erzeugt einen temporären Fehler (4.7.5). Postfix behält die Mail in der Queue und versucht es über mehrere Tage erneut. Wenn der Empfänger seinen TLSA-Record in der Zwischenzeit korrigiert, geht die Mail durch. Passiert das nicht, kommt die Mail als Bounce zurück.

Das ist genau das richtige Verhalten. Lieber eine Mail verzögern als sie über eine möglicherweise kompromittierte Verbindung zuzustellen. Wer TLSA-Records manuell prüfen will, findet dazu eine Anleitung mit OpenSSL. Die Grundlagen zu DANE und Postfix stehen im Beitrag Postfix mit DANE und DNSSEC absichern. Fragen? Einfach melden.

DNSSEC, DANE und TLSA mit Postfix: Hintergründe und aktuelle Probleme

16. Januar 2015 / / Keine Kommentare

Seit ein paar Tagen scheint das Thema DNSSEC, DANE und TLSA im Zusammenhang mit Postfix im Internet besonders aktiv zu sein. Ich bekomme täglich Anfragen dazu und einige scheinen zu testen — E-Mails mit Random-Empfängern an meine Domains. Gegen Tests habe ich nichts, aber grob abgesprochen wäre schön, mein Monitoring wird sonst immer so wuschig.

Kurz zusammengefasst:

  1. Basis von allem ist DNSSEC.
  2. TLSA-Records sind DANE.
  3. Postfix kann TLSA-Records auswerten, ohne selbst welche für sein System zu haben.

Weiterführend:

Fragen? Einfach melden.

Postfix: TLS-Protokoll und Cipher-Infos im E-Mail-Header anzeigen​

17. Dezember 2014 / / Keine Kommentare

Als kleiner Postfix Tipp am Rande…. Wenn man gerade mit seinen TLS Einstellungen „herumspielt“, kann es helfen die groben Informationen für jede E-Mail nicht immer aus dem Logfile sammeln zu müssen.

Postfix bietet die schnelle Möglichkeit, genau diese Informationen einfach mit in den Mail Header zu packen.

Folgende Konfigurationserweiterung ist dafür nötig:

/etc/postfix/main.cf:
smtpd_tls_received_header = yes

Ab diesem Moment finden sich Informationen wie die unten stehende in eingehenden E-Mails.

So long….

Received: from mx01.domain.de (mx01.domain.de [1.2.3.4])
    (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by smtp.kernel-error.de (Postfix) with ESMTPS id 245478112D9
    for <kernel-error@kernel-error.com>; Wed, 17 Dec 2014 05:15:10 +0100 (CET)

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

Postfix: EECDH mit 2048-Bit DH und spezifischen Kurven konfigurieren​

17. Dezember 2014 / / Keine Kommentare

Kex exchange basierend auf EECDH (diese elliptischen Kurven nach DH Diffie-Hellmann), sollte ja inzwischen ein alter Hut sein. Ich gehe also mal von einer aktivieten und funktionsfähigen Konfiguration aus (irgendwo habe ich das wohl auch schon mal beschrieben).

Im Standard läuft dieses nun bei 1024bit also EECDH mit ca. 128bit (smtpd_tls_eecdh_grade=strong). Möchte man alles auf 2048bit EECDH mit ca. 192bit aufbohren… Was ca. die doppelte „Sicherheit“ zu EECDH mit 128bit bedeutet, dann ist folgendes zu erledigen.

Zuerst benötigen für eine große prime group:

$ cd /etc/postfix
$ openssl dhparam -out dh_2048.tmp 2048 && mv dh_2048.tmp dh_2048.pem
$ chmod 644 dh_2048.pem

Dann Postifix mitteilen, dass er sie bitte nutzten soll (ist kein Typo, gehört zur Option „smtpd_tls_dh1024_param_file„). 

/etc/postfix/main.cf:
    smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
    smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

Nun wechselt smtpd_tls_eecdh_grade von strong zu ultra und ich setzte noch die zu verwendende „Kurve“ fest.

/etc/postfix/main.cf:
    smtpd_tls_eecdh_grade = ultra
    tls_eecdh_strong_curve = prime256v1
    tls_eecdh_ultra_curve = secp384r1

Diese Aktion könne nicht ganz Schmerzfrei sein. Für privat und mein Testsystem sicher zu verantworten. Manche MSA (Mail SUbmission Agent) könnten damit Probleme bekommen. Hat also jemand ein Problem mit E-Mail zu senden, bitte melden.

So long….

Siehe auch: Perfect Forward Secrecy

Fragen? Einfach melden.

TLS_FALLBACK_SCSV Debian 7 Wheezy OpenSSL 1.0.1e to 1.0.1j Upgrade

9. Dezember 2014 / / Keine Kommentare

Veraltet: Debian 7 (Wheezy) hat seit 2018 keinerlei Support mehr. TLS_FALLBACK_SCSV ist seit Jahren in allen aktuellen OpenSSL-Versionen enthalten und muss nicht mehr manuell kompiliert werden.

Wer bei seinem Debian TLS_FALLBACK_SCSV im Apache nutzen möchte, muss im Grunde nur auf eine OpenSSL Version >=1.0.1j wechseln.

Einen direkten Backport gibt es dafür leider nicht, also selbst übersetzten. Dazu nutzt man einfachsten direkt den „Debian-Weg“.

Vorbereiten fürs Kompilieren:

$ cd /usr/src
$ apt-get install build-essential fakeroot
$ apt-get build-dep openssl

Herunterladen der aktuellen Version:

$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.dsc
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j.orig.tar.gz
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.debian.tar.xz

Auspacken des Archives und mit den Patchen „verknüpfen“:

$ dpkg-source -x openssl_1.0.1j-1.dsc

Ins neue Verzeichnis wechseln:

$ cd openssl-1.0.1j

Kompilieren und deb Pakete erstellen:

$ dpkg-buildpackage -us -uc -rfakeroot

Die neuen Pakete installieren:

$ cd ..
$ dpkg -i libssl1.0.0_1.0.1j-1_amd64.deb libssl1.0.0-dbg_1.0.1j-1_amd64.deb libssl-dev_1.0.1j-1_amd64.deb libssl-doc_1.0.1j-1_all.deb openssl_1.0.1j-1_amd64.deb

Kontrolle der Version:

$ openssl version
OpenSSL 1.0.1j 15 Oct 2014

ACHTUNG… Ab diesem Moment ist man natürlich selbst dafür verantwortlich Pachte zu installieren.

So long…..

Selbstverständlich profitieren damit alle Anwendungen, die auf OpenSSL aufbauen, so auch Postfix, Dovecot usw:

$ openssl s_client -connect smtp.kernel-error.de:465 -fallback_scsv -no_tls1_2
CONNECTED(00000003)
140410198378152:error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback:s23_clnt.c:770:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 215 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

U-P-D-A-T-E

Denkt an die Updates.

$ openssl version
OpenSSL 1.0.1k 8 Jan 2015

IP Reverse Map Delegation: Einrichtung und Fehlerbehebung

17. Oktober 2014 / / Keine Kommentare

Reverse Map Delegation nach RFC 2317 klingt komplizierter als es ist. Es löst ein konkretes Problem: Wer ein kleines IP-Netz hat (kleiner als /24), kann normalerweise keine eigene PTR-Zone betreiben. Mit Reverse Map Delegation geht es doch.

Warum man es braucht

In der guten alten Zeit bekam man ein /24 (256 Adressen). Da legt man einfach eine Zone 3.2.1.in-addr.arpa. an und fertig. Heute bekommt man, wenn überhaupt, ein /29 (8 Adressen). Und da liegt das Problem: DNS-Zonen werden am Punkt getrennt. Bei einem /24 passt das, bei einem /29 gibt es keinen Punkt an dem man die Zone aufteilen kann.

Der Provider behält also die /24-Zone und richtet für das kleine Subnetz CNAMEs ein, die auf eine „Sub-Zone“ des Kunden zeigen. Der Kunde kann dann seine PTR-Records selbst verwalten.

Die Provider-Seite

In der /24-Zone des Providers wird für das Subnetz 1.2.3.0/29 eine Delegation eingerichtet. Jede IP-Adresse bekommt einen CNAME in die Sub-Zone des Kunden:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.kernel-error.de.
         IN NS  ns2.kernel-error.org.

; Delegation für 1.2.3.0/29 an den Kunden
0/29     IN NS    ns1.vandemeer.de.
0/29     IN NS    ns2.vandemeer.de.
0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Die Kunden-Seite

Der Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.vandemeer.de.
         IN NS  ns2.vandemeer.de.

0        IN PTR netzadresse.vandemeer.de.
1        IN PTR router.vandemeer.de.
2        IN PTR mailin.vandemeer.de.
3        IN PTR imap.vandemeer.de.
4        IN PTR webserver.vandemeer.de.
5        IN PTR frei.vandemeer.de.
6        IN PTR frei.vandemeer.de.
7        IN PTR broadcastadresse.vandemeer.de.

Ergebnis

Eine Reverse-Lookup-Abfrage für 1.2.3.4 läuft jetzt über den CNAME zum DNS des Kunden und liefert den gewünschten PTR-Record:

dig -x 1.2.3.4 +short
4.0/29.3.2.1.in-addr.arpa.
webserver.vandemeer.de.

Probleme

Wäre ja zu schön, wenn es keine gäbe.

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein, außer in genau diesem Fall. Das RFC ist von 1998, aber es hat sich nicht überall herumgesprochen. Man muss seinem Gegenüber gelegentlich RFC 2317 erklären, bevor die Diskussion weitergeht.

Außerdem macht Postfix Ärger, wenn man reject_unknown_client in den smtpd_restrictions hat. Diese Prüfung erwartet, dass PTR und A/AAAA-Record zueinander passen. Bei Reverse Map Delegation tun sie das nicht, weil der CNAME dazwischen steht:

450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]

Wer einen größeren Mailserver betreibt, sollte auf der Mail-IP kein Reverse Map Delegation einsetzen, sondern den PTR direkt beim Provider setzen lassen. Spart Arbeit und Ärger.

Fragen? Einfach melden.

SSLv3 ist tot…

15. Oktober 2014 / / Keine Kommentare

Veraltet: Dieser Beitrag ist eine Momentaufnahme von 2014. SSLv3 ist seit dem POODLE-Angriff in allen Browsern und Servern deaktiviert. TLS 1.0 und 1.1 wurden ebenfalls inzwischen aus allen Browsern entfernt.

Nein, ich habe es nicht überlesen. SSLv3 ist damit wohl hoffentlich tot!

Es ist ja nicht so als wenn man nicht schon davor gewarnt hätte. Oh was hat diese Meldung bei mir für gute Laune geführt! Wieder mal ein richtiger „Told you so“ Moment für mich.

Oh ja, was zum Lesen gefällig?

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Bäääähhhhmmmm! Das schreit nach einem GIF!

Told you so reaction GIF about SSLv3 deprecation

Auf die schnell böse Dinge deaktivieren…

Postfix:

smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

Dovecot:

ssl_cipher_list = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
ssl_protocols = !SSLv2 !SSLv3

Apache2:

SSLEngine on
SSLProtocol +ALL -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
SSLCompression off
Header always set Strict-Transport-Security "max-age=15552000"

mailgraph Graphen um DANE erweitern

9. August 2014 / / Keine Kommentare

Wie sich die grafische Logfile Auswertung für, unter anderem, Postfix um Dinge wie SPF, DKIM und DMARC erweitern lässt, habe ich ja bereits vor kurzem hier gezeigt: mailgraph Graphen um SPF, DMARC und DKIM erweitern

Seit ein paar Monaten ist an meinem Mailserver DANE aktiviert, sprich es lassen sich die TLSA RECORDS für die Zertifikate am Postfix gegen einen DNSSEC gesicherten DNS Server abgleichen.

In diesem Zuge habe ich selbstverständlich die ausgehende Prüfung am Postfix aktiviert. Mein Postfix nutzt nun also auch DANE um die Verbindung zu anderen Mailserver zu prüfen. Dabei gibt es im Grunde nur vier mögliche Ergebnisse einer Prüfung der TLS Verbindung:

Verified

Der bisher seltenste aber beste Fall. Denn die ausgehende Verbindung zum anderen Server ist per DANE gesichert. Das Zertifikat ist also nicht nur gültig sondern konnte auch mit den TLSA-RECORDS abgeglichen werden.

Trusted

Der OK Fall… Das Zertifikat ist gültig.

Anonymous

Na ja… Es gibt ein Zertifikat und dieses ist passend zum Hostname, es konnte aber keine Vertrauenskette gebildet werden.

Untrusted

Schlecht! Es gibt zwar ein Zertifikat und somit auch eine verschlüsselte Verbindung, denn noch stimmt etwas mit dem Zertifikat nicht. Es ist abgelaufen, passt nicht zum Hostname oder ähnliches.

Im Logfile findet es sich wie folgt:

Aug  3 18:34:08 servername postfix/smtp[1234]: Verified TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  9 12:07:28 servername postfix/smtp[1234]: Trusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Aug  8 22:15:34 servername postfix/smtp[1234]: Anonymous TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)

Aug  7 21:48:48 servername postfix/smtp[1234]: Untrusted TLS connection established to mx01.domain.tld[1.2.3.4]:25: TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)

Was mich nun interessiert, ist die Tendenz der einzelnen Prüfungen. Wie sicher ist die Kommunikation zu anderen Mailservern wirklich, rein bezogen auf die Vertrauenswürdigkeit der eingesetzten Zertifikate. Eine schnelle Übersicht soll mir hier wieder der mailgraph liefern.

Den Mailgraph habe ich also, wie mit SPF, DKIM und DMARC ebenfalls, erweitert. Das nötige Patchset gibt es natürlich wieder unten. Dieses Mal habe ich darauf geachtet für die TLS Auswertung ein eigenes File für die RRD-Daten anzulegen. So kann ein bestehender Mailgraph einfach erweitert werden, ohne die vorhandenen Daten zu verlieren.

Heraus kommt am Ende dieser Graph.

Für interessiere finden sich die beiden nötigen Patchfiles hier:

/usr/sbin/mailgrapht

/usr/lib/cgi-bin/mailgraph.cgi

Viel Spaß! Bei Fragen, fragen.

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑