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
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.
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.
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.
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.
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:
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.
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.
Jede E-Mail enthält Header, die Informationen über den Absender preisgeben: Die IP-Adresse des Clients (Received), den verwendeten Mailclient samt Version (User-Agent, X-Mailer) und manchmal die originale IP (X-Originating-IP). Für einen Angreifer ist das nützlich. Er sieht welche Software in welcher Version läuft und kann gezielt nach bekannten Schwachstellen suchen. Die IP-Adresse verrät die interne Netzwerktopologie oder ermöglicht Tracking über verschiedene Netze.
Postfix kann diese Header beim Versand per Regex umschreiben oder entfernen.
REPLACE ersetzt die Zeile, IGNORE löscht sie komplett. Die erste Regel tauscht die echte Client-IP im Received-Header gegen localhost aus. Die restlichen Regeln entfernen Mailclient-Informationen.
smtp_header_checks vs. header_checks
Postfix kennt zwei Stellen für Header-Manipulation: header_checks greift bei der Annahme (Cleanup-Daemon), smtp_header_checks greift beim Versand (SMTP-Client). Für die Verschleierung eigener Absender-Daten ist smtp_header_checks die richtige Wahl. Die Header werden erst beim Versand umgeschrieben, nicht bei der internen Verarbeitung. So bleiben die originalen Header in den lokalen Logs erhalten.
DKIM-Kompatibilität
Die DKIM-Signatur wird nicht gebrochen. DKIM signiert standardmäßig den Body und ausgewählte Header wie From, To, Subject und Date. Die Received-, User-Agent– und X-Mailer-Header sind nicht Teil der Signatur. Außerdem greift smtp_header_checks nach dem Signing, der Cleanup-Daemon hat die DKIM-Signatur zu diesem Zeitpunkt bereits erstellt.
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.
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!
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.
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.
enforce = nur verschlüsselt zustellen. testing = wie enforce, aber bei Fehlern trotzdem zustellen (gut zum Einstieg). none = Policy deaktiviert.
mx
An welche MX-Server zugestellt werden darf. Mehrere Einträge möglich (je eine Zeile). Wildcards gehen: *.kernel-error.de
max_age
Wie 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.
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.
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.
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:
STARTTLS
Ob der MX TLS anbietet und welche Protokollversionen und Cipher unterstützt werden
Ob MTA-STS konfiguriert ist und die Policy konsistent ist
DNSSEC
Ob 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.
Ich bin absolut überrascht. Das gesammte Thema war für mich nach der letzten Kommunikation „erledigt“. In den nächsten Jahren hätte ich nicht mehr mit einer Veränderung gerechnet…
Da kam heute aus dem Nichts folgende E-Mail:
Hallo Herr van de Meer,
manchmal geschehen noch kleine Wunder. Ich habe heute ein .par File für unsere IPv6 Herausforderung bekommen und erfolgreich bei meiner Maschine testen können.
Es ist jetzt also auch mit Samsung Maschinen möglich, eine „saubere und korrekte IP Adresse“ zuzuweisen.
Wenn noch Bedarf besteht, stelle ich ihnen gerne ein Link zum Download zur Verfügung.
Beste Grüße nach Bonn
Ich habe natürlich diesen Patch angefragt, blitzartig bekommen und eingespielt.
macbook-s-meer:~ kernel$ ping6 -c3 fd00:118f:335:62::253
PING6(56=40+8+8 bytes) fd00:118f:335:42:c3:51f8:2949:1641 --> fd00:118f:335:62::253
16 bytes from fd00:118f:335:62::253, icmp_seq=0 hlim=63 time=0.884 ms
16 bytes from fd00:118f:335:62::253, icmp_seq=1 hlim=63 time=0.703 ms
16 bytes from fd00:118f:335:62::253, icmp_seq=2 hlim=63 time=0.718 ms
--- fd00:118f:335:62::253 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.703/0.768/0.884/0.082 ms
Das geht jetzt einfach! Das geht wirklich. Ich kann dem Drucker eine feste IP Adresse meiner Wahl geben.
