-=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: MailServer (Seite 2 von 7)

Postfix-Fehlerantworten anpassen: So gehst du vor

27. März 2019 / / Keine Kommentare

Wieder wurde ich gefragt wie ich bei meinem Postfix den Error Reply für rejected 5xx E-Mails geändert habe. Nun ja, das habe ich überhaupt nicht.

Postfix hat seit vielen Jahren die Option: smtpd_reject_footer diese wurde in 2011 beim „Aufräumen“ umbenannt in: smtpd_reject_footer

Cleanup: smtpd_reject_contact_information is renamed to smtpd_reject_footer, because it can be used for non-contact information.

Beide Optionen sind anscheinend eher unbekannt. Was ich gut verstehen kann. Denn setzt man nun in seiner main.cf den smtpd_reject_footer wird diese zwar brav angehangen und taucht sogar beim Absender im Postfach auf, nur welcher Benutzer liest diese schon und folgt dann noch dem jeweiligen Hinweis? Bisher ist diese Rückmeldung meines Systems nur sehr wenigen überhaupt aufgefallen ;-P

Vor ~12 Jahren habe ich sie wohl zum ersten Mal gesetzt. Ich meine da auf die Adresse vom Postmaster verwiesen zu haben, damit die Nutzer sich dort hin melden können. Später hatte ich mal einen Link auf eine zweisprachige Hilfeseite bei mir und noch später etwas wie: „Das Problem ist zu 99% dein Mailserver, frag DEINEN Admin!“. Dieses war es bis heute, denn heute habe ich die erneute Frage zum Anlass genommen, dieses hier zu schreiben und natürlich direkt auf riot.im zu verlinken. Dann kann man mich direkt anschreiben. Sicher etwas freundlicher als: „geh weg du bist eh das Problem“ und einfacher als noch eine E-Mail an den Postmaster zu schreiben. Sicher werde ich nun durch diese Nachricht 1 oder 2 mal im Jahr angeschrieben, wenn es dieses überhaupt wird.

Achja, so sieht der Eintrag in der main.cf von Postfix aus:

root@smtp:/usr/local/etc/postfix # postconf smtpd_reject_footer
smtpd_reject_footer = For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com

Damit lässt sich nun dieses Ergebnis erzielen:

banane@bsd03:~ # telnet smtp.kernel-error.de 25
Trying 2a01:4f8:150:1095::25...
Connected to smtp.kernel-error.de.
Escape character is '^]'.
220 smtp.kernel-error.de ESMTP Postfix
helo asdf
250 smtp.kernel-error.de
mail from: <test@spam.de>
250 2.1.0 Ok
rcpt to: <spamlover@kernel-error.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
subject: test
.test
.
554-5.7.1 Spam message rejected
554 5.7.1 For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com
Connection closed by foreign host.

Fragen? Dann wie immer bitte fragen…

Siehe auch: E-Mails ohne TLS ablehnen

Fragen? Einfach melden.

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

25. März 2019 / / Keine Kommentare

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.

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

MTA-STS einrichten: Transportverschlüsselung für E-Mail erzwingen

8. März 2019 / / Keine Kommentare

Siehe auch: internet.nl: Mailserver-Sicherheit testen mit dem niederländischen Standard, TLS 1.3 für Postfix & Dovecot: Einrichtung und Konfiguration, internet.nl verschärft die TLS-Anforderungen für Mailserver

SMTP überträgt E-Mails standardmäßig im Klartext. Mit STARTTLS lässt sich die Verbindung verschlüsseln, aber kein sendender Server ist gezwungen das auch zu tun. Schlimmer noch: Ein Angreifer im Netzwerk kann die STARTTLS-Antwort einfach unterdrücken und die Verbindung bleibt unverschlüsselt. MTA-STS (RFC 8461) löst dieses Problem: Der Empfänger veröffentlicht eine Policy, die sendenden Servern sagt „hier wird nur verschlüsselt zugestellt, mit gültigem Zertifikat, an genau diesen MX“.

MTA-STS vs. DANE

Es gibt zwei Wege, Transportverschlüsselung für E-Mail zu erzwingen: DANE und MTA-STS. DANE nutzt DNSSEC und TLSA-Records im DNS. Das ist technisch sauberer, setzt aber DNSSEC auf der Empfängerseite voraus. Viele große Provider (Google, Microsoft) haben kein DNSSEC. MTA-STS funktioniert ohne DNSSEC: Die Policy liegt als Textdatei auf einem Webserver, abgesichert durch ein normales TLS-Zertifikat. Wer beides kann, sollte beides einsetzen. DANE für die Server die DNSSEC können, MTA-STS für den Rest.

Die drei Komponenten

MTA-STS besteht aus drei Teilen: einem DNS-Record, einer Policy-Datei auf einem Webserver und optional TLS Reporting.

1. DNS TXT-Record

Ein TXT-Record unter _mta-sts.domain.de signalisiert, dass eine Policy existiert:

_mta-sts.kernel-error.de.  IN TXT  "v=STSv1;id=20260115130000Z;"

Die id ist ein beliebiger String. Sendende Server cachen die Policy und prüfen über die ID ob sich etwas geändert hat. Bei jeder Policy-Änderung muss die ID aktualisiert werden. Ich verwende dafür einen Zeitstempel, das macht es nachvollziehbar.

2. Policy-Datei

Die eigentliche Policy liegt unter https://mta-sts.domain.de/.well-known/mta-sts.txt. Wichtig: Der Webserver muss ein gültiges TLS-Zertifikat haben und unter genau diesem Hostnamen erreichbar sein.

version: STSv1
mode: enforce
mx: smtp.kernel-error.de
max_age: 2419200
modeenforce = nur verschlüsselt zustellen. testing = wie enforce, aber bei Fehlern trotzdem zustellen (gut zum Einstieg). none = Policy deaktiviert.
mxAn welche MX-Server zugestellt werden darf. Mehrere Einträge möglich (je eine Zeile). Wildcards gehen: *.kernel-error.de
max_ageWie lange die Policy gecacht wird, in Sekunden. 2419200 = 28 Tage.

Der empfohlene Weg: Mit mode: testing anfangen und die TLS-Reports auswerten. Wenn alles sauber ist, auf enforce umstellen.

3. TLS Reporting

Wie bei DMARC gibt es auch für MTA-STS ein Reporting-System: SMTP TLS Reporting (RFC 8460). Ein weiterer DNS TXT-Record teilt Absendern mit, wohin sie Berichte über TLS-Verbindungsprobleme schicken sollen:

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

Die Reports kommen als JSON per Mail und enthalten Informationen über fehlgeschlagene TLS-Verbindungen, ungültige Zertifikate oder MX-Mismatches. Google und Microsoft schicken diese Reports zuverlässig.

Postfix und MTA-STS

Postfix prüft von Haus aus keine MTA-STS-Policies. Für die ausgehende Seite braucht es postfix-mta-sts-resolver, ein Policy-Daemon der sich als smtp_tls_policy_maps in Postfix einhängt. Der Daemon cached die Policies und liefert Postfix die passende TLS-Konfiguration pro Zieldomain.

# /usr/local/etc/postfix/main.cf
smtp_tls_policy_maps = socketmap:unix:/var/run/mta-sts-daemon/mta-sts-daemon.sock:postfix

Die eingehende Seite braucht keine Software. Die drei DNS-Records und die Policy-Datei auf dem Webserver reichen aus. Sendende Server wie Gmail, Outlook oder Yahoo werten die Policy selbständig aus.

Testen

# DNS-Records prüfen
dig TXT _mta-sts.kernel-error.de +short
dig TXT _smtp._tls.kernel-error.de +short

# Policy abrufen
curl https://mta-sts.kernel-error.de/.well-known/mta-sts.txt

Zusammen mit SPF, DKIM, DMARC und DANE ergibt MTA-STS eine lückenlose Absicherung: Authentifizierung (wer darf senden), Integrität (DKIM-Signatur) und Transportverschlüsselung (DANE/MTA-STS). Fragen? Einfach melden.

internet.nl: Mailserver-Sicherheit testen mit dem niederländischen Standard

5. März 2019 / / Keine Kommentare

Die niederländische Regierung betreibt mit internet.nl ein kostenloses Testtool für Webserver und Mailserver. Im Gegensatz zu Qualys SSL Labs, das sich auf TLS-Konfiguration konzentriert, prüft internet.nl das gesamte E-Mail-Sicherheitsbild einer Domain.

Was getestet wird

Der Mailserver-Test prüft:

STARTTLSOb der MX TLS anbietet und welche Protokollversionen und Cipher unterstützt werden
ZertifikatGültigkeit, Kette, Hostname-Match
DANE/TLSAOb TLSA-Records im DNS vorhanden und korrekt sind
SPFOb ein SPF-Record existiert und syntaktisch korrekt ist
DKIMOb ausgehende Mails DKIM-signiert sind
DMARCOb eine DMARC-Policy veröffentlicht ist und welche Einstellung sie hat
MTA-STSOb MTA-STS konfiguriert ist und die Policy konsistent ist
DNSSECOb die Domain mit DNSSEC gesichert ist

Für jede Kategorie gibt es Punkte. 100 Prozent erreicht man nur wenn alles korrekt konfiguriert ist. Domains die sowohl beim Web- als auch beim Mailtest 100 Prozent erreichen, landen in der Hall of Fame.

Strenge Anforderungen

internet.nl ist strenger als die meisten anderen Testtools. TLS 1.0 und 1.1 geben Abzug. Ohne DANE ist kein voller Score möglich. Die Cipher-Anforderungen orientieren sich an den niederländischen IT-Sicherheitsrichtlinien, die auch für Behörden gelten.

Das macht den Test besonders nützlich als Benchmark. Wer dort 100 Prozent hat, hat sein E-Mail-Setup nach aktuellem Stand abgesichert. Wer Abzüge bekommt, sieht genau wo es hakt.

Fremde Domains testen

Man kann beliebige Domains testen, nicht nur die eigene. Das ist praktisch um Dienstleister, Geschäftspartner oder den eigenen Provider zu prüfen. Ein kurzer Test zeigt schnell ob der Mailserver auf der anderen Seite zeitgemäß konfiguriert ist oder ob dort noch SSLv3 mit RC4 läuft.

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

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

15. Februar 2019 / / 3 Kommentare

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. Wer zusätzlich sicherstellen will, dass ausgehende Verbindungen verschlüsselt bleiben, sollte sich MTA-STS ansehen.

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. Wer noch einen Schritt weiter gehen will, findet im Beitrag zu Post-Quantum TLS für E-Mail die nächste Stufe.

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

Fragen? Einfach melden.

Anruf bei der G Data Hotline: Ein Erfahrungsbericht

7. Februar 2017 / / Keine Kommentare

Ich: tuuuuut…… tuuuuuut
Hotline: Bla gdata Hotline bla
Ich: Pffffhhhh
Hotline: *laala* (mucke)
Ich: Pffffhhhh
Hotline: Willkommen an der Hotline, mein Name ist Mann, was kann ich für sie tun?
Ich: Sie brauchen sicher meinen Benutzernamen, oder?

Das scheint da so etwas wie die Kundennummer in anderen Unternehmen zu sein….

Hotline: Oh ja, den nehme ich gerne.
Ich: Konrad-5-Julius-Heinrich-97- [Hotlinemann unterbricht mich]
Hotline: Konrad ausgeschrieben?
Ich: Öhm ähh ne also öh der Buchstabe?!?
Hotline: OK
Ich: Kundenummer…
Hotline: und was kann ich nun für sie tun?
Ich: Wir testen gerade die Amavis Integration eurer G DATA Business Lösung und das läuft nicht ganz rund.
Hotline: uhhaaa ohh
Ich: Warum uhaaa ohh?
Hotline: Öhm (hehe) also ähh, da bekommen wir eher weniger Anfragen. Wird nicht so oft benutzt.
Ich: Na aber ihr verkauft das ja.
Hotline: Ja aber ähh gut.

Dann wurden Version und OS abgefragt und ein Ticket angelegt. Ich sollte mal Auszüge aus dem Maillog senden. irgendwie habe ich das Gefühl als wenn das gerade nix wird.

Für Spaß auch mal die Logfiles:

Feb  7 08:27:54 mx amavis[27217]: (21323-04-4) (!)run_command: child process [27217]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)collect_results from [27217] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-21323-gFK_Ofar
Feb  7 08:27:54 mx postfix/smtp[27003]: EFA15C0A13: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=85234, delays=85181/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=21323-04-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:54 mx amavis[27219]: (21323-04-5) (!)run_command: child process [27219]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output=""
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="" at (eval 97) line 905.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)WARN: all primary virus scanners failed, considering backups Feb  7 08:27:54 mx amavis[27221]: (20783-09-4) (!)run_command: child process [27221]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)collect_results from [27221] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-20783-75UHo67I
Feb  7 08:27:54 mx postfix/smtp[27159]: D74F7C00F4: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=342238, delays=342185/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=20783-09-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:55 mx amavis[20783]: (20783-09-5) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.3.4]:44419 [1.2.3.4] <type@domain.de> -> <type@domain.de>, Queue-ID: 6D65CC0A33, Message-ID: <62734015.3835.1486452455492.JavaMail@domain.de>, mail_id: lsOZOYNAIa3o, Hits: 0, size: 44774, queued_as: 57B04C0A40, 471 ms

Feb  7 09:55:25 mx amavis[22893]: (22893-07) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.32.4]:36945 [1.5.7.98] <type@domain.de> -> <type@domain.de>, Queue-ID: E7592C0071, Message-ID: <20170207085513.B8A52340881@domain.de>, mail_id: 3lhpfBFnyuAI, Hits: 0, size: 4172, queued_as: 1F499C00F7, 10166 ms Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output="SKIP"
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="SKIP" at (eval 97) line 905.
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)WARN: all primary virus scanners failed, considering backups

Fragen? Einfach melden.

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.

Testtool Liste für schnelle und einfache Tests

2. Juli 2015 / / Keine Kommentare

Ich bin schon ein paar mal darum gebeten worden, doch bitte eine gesammelte Liste der verschiedenen Testtools zu erstellen.

Hiermit möchte ich dieser Bitte nachkommen.

Bitte beachtet aber, dass diese Tests/Checks in den meisten Fällen grob sind und nur verlässlich mitteilen können, ob etwas klappt oder nicht. Dennoch ist es hier und da eine schnelle und einfache Hilfe für Experimente und/oder um zu prüfen ob eine Änderungen greift!

So long….

Tests für Mail Server

SSL/TLS/TLSA/DANE/DNSSEC/SMTP Tests:
https://de.ssl-tools.net/mailservers/kernel-error.de

SSL/TLS/SMTP/POP/IMAP Tests:
http://www.checktls.com/

DANE SMTP Validator:
https://dane.sys4.de/smtp/kernel-error.de

DMARC TEST:
https://dmarcian.com/dmarc-inspector/kernel-error.de

SPF TEST:
https://dmarcian.com/spf-survey/kernel-error.de

http://www.kitterman.com/spf/validate.html

Mailserver Blacklist check:
http://mxtoolbox.com/blacklists.aspx

https://talosintelligence.com/

http://www.barracudacentral.org/lookups

DKIM / SPF / DMARC E-Mail Testadresse:
check-auth@verifier.port25.com

check-auth2@verifier.port25.com

Microsoft Tests:

https://testconnectivity.microsoft.com

Tests für Web Server

SSL/TLS Test:
https://www.ssllabs.com/ssltest/analyze.html?d=kernel-error.de

https://de.ssl-tools.net/webservers/www.kernel-error.de

SPDY Test:
https://spdycheck.org/#www.kernel-error.de

Tests für DNS Server

DNSserver:
http://www.dnsinspect.com/kernel-error.de

DNSSEC:
http://dnssec-debugger.verisignlabs.com/www.kernel-error.de

http://dnsviz.net/d/kernel-error.de/dnssec/

Tests für Jabber/XMPP Server

Jabber/XMMPP-Security Test:
http://www.xmpp.net/

Tests für Clients

IPv6 Client-Test:
http://test-ipv6.com

Webbrowser Test:
https://www.ssllabs.com/ssltest/viewMyClient.html

OPENGPGKEY RR:
https://openpgpkey.info/?email=kernel-error%40kernel-error.com

Siehe auch: Hardenize Security Scanner

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.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑