TLS 1.3 am Horizont gesichtet

Seit  dem 15. Januar gibt es openssl1.1.1a für Fedora 29 und Fedora 30 und damit die neue TLS 1.3 Version. Leider bleibt Fedora 28 auf der Strecke, da der Maintainer bei Red Hat keine Lust hat, es auf Fedora 28 zu kompilieren, auch wenn .. Zitat: „nur triviale Anpassungen am Securitypolicyblock nötig wären“.

Das kann ich so natürlich nicht hinnehmen 😀

Wir brauchen :

Einen Exim 4.91 Mailserver und folgende Koji Paketevon Fedora 29 :

-rw-r–r– 1 root root 46760 26. Okt 11:46 crypto-policies-20181026-1.gitd42aaa6.fc29.noarch.rpm
-rw-r–r– 1 root root 625824 15. Jan 15:43 openssl-1.1.1a-1.fc29.x86_64.rpm
-rw-r–r– 1 root root 1395348 15. Jan 15:43 openssl-libs-1.1.1a-1.fc29.x86_64.rpm

dann „dnf update ./*fc29*rpm“  und den Exim danach neustarten und …

[000.099]Connected to server
[000.201]<–220 s113.resellerdesktop.de ESMTP Exim 4.91 Mon, 28 Jan 2019 22:49:51 +0100
[000.201]We are allowed to connect
[000.201] –>EHLO www6.CheckTLS.com
[000.299]<–250-s113.resellerdesktop.de Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250-STARTTLS
250 HELP
[000.300]We can use this server
[000.300]TLS is an option on this server
[000.300] –>STARTTLS
[000.425]<–220 TLS go ahead
[000.425]STARTTLS command works on this server
[000.557]Connection converted to SSL
SSLVersion in use: TLSv1_3
Cipher in use: TLS_AES_256_GCM_SHA384
Certificate 1 of 3 in chain: Cert VALIDATED: ok
Cert Hostname VERIFIED (s113.resellerdesktop.de = s113.resellerdesktop.de | DNS:gesperrt.s113.resellerdesktop.de | DNS:mailpwd.s113.resellerdesktop.de | DNS:pma.s113.resellerdesktop.de | DNS:s113.resellerdesktop.de | DNS:webmail.s113.resellerdesktop.de | DNS:www.s113.resellerdesktop.de)
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=03:06:78:2c:10:74:ad:f3:10:91:27:d2:92:a5:a1:8b:81:38
subject= /CN=s113.resellerdesktop.de
issuer= /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3

Wenn es doch immer nur so einfach wäre 😉

Koji Pakete gibt es hier:

https://koji.fedoraproject.org/koji/packages?start=400&order=package_name&prefix=o&inherited=1

Exim – Wie man TLS erzwingt II

Im letzten Beitrag Exim – Wie man TLS erzwingt war das Blockieren von ausgehenden Verbindungen ohne TLS Thema. Heute befassen wir uns mit dem Gegenteil : Wie verhindern wir, daß wir eine Email bekommen, die unsicher übertragen wurde?

Exim ’s Access Control Lists

Exim als Mailserver erlaubt es uns, in jede Phase der Übertragung von Emails per SMTP einzugreifen und Emails aufgrund von Mustern und Bedingungen abzulehnen. Die ACL genannten Bedingungsketten sind universell einsetzbar, hier ein Beispiel:

acl_check_helo:

drop condition = ${if eq{$sender_helo_name}{ylmf-pc} {1}}
     message = Your a naugthy boy

accept

Die Helo-ACL prüft ob, sich der anfragende Mailserver mit einem bestimmten Namenskürzel meldet, hier „ylmf-pc„. Das ist so ziemlich todsicher ein Bot aus einem asiatischen Netzwerk. Zur Erklärung :

drop ist das Ziel der Aktion, wenn die condition greift. Hier der Vergleich (if eq) von dem was der „Client“ gesendet hat und dem ylmf-pc Text. Übersetzt heißt das : if ( „sender_helo_name“  == „ylmf-pc“ )  { log.message = „Your a naugthy boy“; message.drop(); }

So sieht das dann im SMTP aus :

220 irgendeinserver.de ESMTP Exim 4.89 Sun, 03 Dec 2017 14:33:48 +0100
HELO ylmf-pc
550 Your a naugthy boy

Ansonsten akzeptiere ( accept ) die Email. Natürlich könnte man hier auch schon DNS IP Blacklisten eintragen, oder andere Abfragen, die keinen Empfänger / Sender benötigen. Die meisten ACls werden aber genau bei der Sender- und Empfängerprüfung eingesetzt. Genau das werden wir in der ACL acl_check_rcpt tun.

Zum Glück sind die nötigen Anweisungen extrem übersichtlich :

acl_check_rcpt:
 ...
 deny condition = ${if eq{$tls_cipher}{}{1}{0}}
      message   = Sender did not use TLS secured connection.

Meint:

If ( tls_cipher ==  „“ ) { log.message = „Sender did not use TLS secured connection. „; message.deny() }

Das war es schon. Damit kommen nur noch Emails weiter, die über eine TLS gesicherte Verbindung gesendet werden. Ob das Spam ist oder nicht, muß man natürlich trotzdem prüfen, wenn die Mail erst einmal übertragen wurde.

Analyse

Da erst einmal nur der Empfänger in der SMTP Phase genannt wurde, ist der Inhalt der Email noch aus dem sendenen Server, denn der wird erst mit dem DATA Block übertragen. In die HELO ACL kann man das nicht einbauen, da SMTP verlangt, daß ein netter Server erstmal HELO  oder EHLO sagt, bevor er weiter macht.

Die übliche SMTP-Befehlsreihenfolge dürfte daher :

HELO
STARTTLS
MAIL FROM:
RCPT TO:
DATA

sein. Man kann es natürlich auch bereits in der mail_from ACL machen, ob das einen großen Unterschied machen wird, ist fraglich.

 

Exim – Wie man TLS erzwingt

Exim ist einer der vielseitigsten Mailserver die man auf einem Server haben kann, fast Nichts ist unmöglich. In einer Zeit, in der immer mehr abgehört wird und die Kommunikation von Personen, Firmen und Behörden geschützt werden muß, finden sich immer noch Mailserver, die kein TLS sprechen.

Mailtransportverschlüsselung

TLS wurde vor fast 19 Jahren per RFC als Nachfolger von SSL geboren und hat dies erfolgreich abgelöst. Sollte man jedenfalls meinen. Tatsächlich habe ich erst heute eine Rechnung von 1und1 bekommen, ja, Name & Shame in progress, die mit einem gebrochenen TLS 1.0 aka. „SSLv3 modified“ übertragen wurde :

H=mbulk.1and1.com [212.227.126.220] P=esmtps X=TLSv1:DHE-RSA-AES256-SHA:256

Da unser Server TLS1.2 spricht und anbietet, kann man von einem Konfigurationsfehler ausgehen. Wenigsten wurde hier TLS gesprochen. Andere Mailserver können nicht mal SSL, die senden und empfangen unverschlüsselt, nicht wahr liebe Admins von faller.de 😉

Wie man TLS erzwingt

Im letzteren Fall kann man Exim dazu bewegen, daß er keine Emails ohne TLS sendet. Damit kann verhindert werden, daß Geheimnisse abgehört werden können. Exim ist von Haus aus mit den nötigen Funktionen ausgestattet und daher extrem leicht dafür zu begeistern 🙂

Der in praktisch jeder Eximconfig vorkommende Transporttreiber „remote_smtp“ muß nur um zwei Befehle erweitert werden:

remote_smtp:
 driver = smtp
 hosts_require_tls = *
 tls_tempfail_tryclear = false

Das zwingt Exim dazu, ohne TLS Verbindung abzubrechen und auf keinen Fall auf Klartext zurückzufallen. Das wäre ja auch selten dämlich, oder ? Tja, wie sich herausstellte, ist sich immer einer in der Welt nicht zu blöd, genau das zu machen 😀 Mein Name & Shame Beispiel für diesen Fail, hat sich allerdings bekehren lassen und sendet jetzt vorbildlich in TLSv1.2 \o/

Der ewige Optimist Exim

Exim sieht einen Fail beim TLS leider als temporären Fehler an. Er geht also davon aus, daß der empfangende Mailserver irgendwann in der Retryzeit seine Meinung ändert 😀 Aus Erfahrung kann ich sagen, nein, tun die empfangenden Mailserver nicht 🙂

Daher müssen wir die Retryzeit für diesen Fall auf 0 setzen, so daß sofort eine Delivery Message erzeugt wird.  Das erledigen wir so :

begin retry

*          refused
*           quota
*        tls_required
*             *         F,2h,15m; G,16h,1h,1.5; F,4d,6h

Das war es bis auf einen kleinen Schönheitsfehler schon: die Delivery Message macht für den Leser derselben keinen Sinn, da ein falscher Fehlergrund ausgegeben wird, aber das ist Euer Problem 😉

 

Das Anastasia Botnetz

Spams gibt ja immer und meisten steckt heute ein Botnetz dahinter. Das Netzwerk, das unsere Mailserver derzeit am meisten nervt, ist das von mir so genannte Anastasia Botnetz.

Es ist allerdings leicht am Absender zu identifizieren, der immer das Wort Anastasia am Anfang hat:

2017-08-02 01:44:59 H=(ip-38-239.tricom.net) [186.150.38.239] rejected MAIL <Anastasiabj@tricom.net>: identified as Anatasia Botnet
2017-08-02 01:45:43 H=(ocit-41.189.55.239.aviso.ci) [41.207.201.171] rejected MAIL <Anastasiafab@aviso.ci>: identified as Anatasia Botnet
2017-08-02 01:45:46 H=([115.164.85.255]) [115.164.85.255] rejected MAIL <Anastasiabcbr@puretechnutrition.com>: identified as Anatasia Botnet
2017-08-02 01:47:05 H=([51.36.222.115]) [51.36.222.115] rejected MAIL <Anastasiacoe@incco.com.gt>: identified as Anatasia Botnet
2017-08-02 01:47:27 H=(131-108-125-254.infortek.net.br) [131.108.125.254] rejected MAIL <Anastasiarcae@infortek.net.br>: identified as Anatasia Botnet
2017-08-02 01:47:32 H=160.red-81-39-134.dynamicip.rima-tde.net [81.39.134.160] rejected MAIL <Anastasiaxte@woburnapartments.co.nz>: identified as Anatasia Botnet
2017-08-02 01:47:54 H=([161.132.100.51]) [161.132.100.51] rejected MAIL <Anastasiamm@rhinohandyman.com>: identified as Anatasia Botnet
2017-08-02 01:48:56 H=([186.235.188.234]) [186.235.188.234] rejected MAIL <Anastasiacljgf@pedicur.ru>: identified as Anatasia Botnet
2017-08-02 01:49:06 H=([202.90.136.58]) [202.90.136.58] rejected MAIL <Anastasiaxw@directiva.com.br>: identified as Anatasia Botnet
2017-08-02 01:49:44 H=([175.101.251.27]) [175.101.251.27] rejected MAIL <Anastasiadihu@it-is-it.com>: identified as Anatasia Botnet
2017-08-02 01:50:25 H=(host-177-232-80-119.static.metrored.net.mx) [177.232.80.119] rejected MAIL <Anastasiaazy@metrored.net.mx>: identified as Anatasia Botnet
2017-08-02 01:50:31 H=([27.123.171.127]) [27.123.171.127] rejected MAIL <Anastasiabviyu@hrcbmdfw.org>: identified as Anatasia Botnet
2017-08-02 01:50:32 H=85.233.11.37.dynamic.jazztel.es [37.11.233.85] rejected MAIL <Anastasiayurg@jazztel.es>: identified as Anatasia Botnet
2017-08-02 01:51:18 H=(static.vnpt.vn) [113.161.8.21] rejected MAIL <Anastasiafir@static.vnpt.vn>: identified as Anatasia Botnet
2017-08-02 01:52:20 H=fixed-187-189-92-55.totalplay.net [187.189.92.55] rejected MAIL <Anastasiahw@fixed-187-189-92-55.totalplay.net>: identified as Anatasia Botnet
2017-08-02 01:52:26 H=(static.vnpt.vn) [14.183.242.229] rejected MAIL <Anastasiaud@static.vnpt.vn>: identified as Anatasia Botnet
2017-08-02 01:52:34 H=(static-ip-cr18152012787.cable.net.co) [181.52.127.87] rejected MAIL <Anastasiaxcs@cable.net.co>: identified as Anatasia Botnet
2017-08-02 01:53:09 H=(host-177-232-87-110.static.metrored.net.mx) [177.232.87.110] rejected MAIL <Anastasiarclg@metrored.net.mx>: identified as Anatasia Botnet
2017-08-02 01:53:20 H=red.connectbd.com [202.79.16.10] rejected MAIL <Anastasiavpuup@red.connectbd.com>: identified as Anatasia Botnet
2017-08-02 01:53:42 H=([161.132.100.51]) [161.132.100.51] rejected MAIL <Anastasiaualik@grouptower.com>: identified as Anatasia Botnet
2017-08-02 01:54:30 H=([123.23.241.122]) [123.23.241.122] rejected MAIL <Anastasianwz@ubsystems.com>: identified as Anatasia Botnet
2017-08-02 01:55:05 H=(187.253.122.253.cable.dyn.cableonline.com.mx) [187.253.122.253] rejected MAIL <Anastasiadabgp@cableonline.com.mx>: identified as Anatasia Botnet
2017-08-02 01:57:59 H=(static.vdc.com.vn) [113.190.40.226] rejected MAIL <Anastasiailk@vdc.com.vn>: identified as Anatasia Botnet
2017-08-02 01:58:21 H=([191.99.126.26]) [191.99.126.26] rejected MAIL <Anastasiafsg@zarlock.com>: identified as Anatasia Botnet
2017-08-02 01:59:32 H=([41.216.32.42]) [41.216.32.42] rejected MAIL <Anastasiaecous@vertexconsultancy.co.in>: identified as Anatasia Botnet
2017-08-02 01:59:42 H=(181-174-59-224.telebucaramanga.net.co) [181.174.59.224] rejected MAIL <Anastasiajinv@simtecno.com.br>: identified as Anatasia Botnet
2017-08-02 02:00:19 H=([31.145.75.194]) [31.145.75.194] rejected MAIL <Anastasiaonl@juste.com.tw>: identified as Anatasia Botnet

Das dies nur ein kleiner Ausschnitt von nur einer einzigen Maschine ist, deutet das Ausmaß des Botnetzes an.

Für alle die einen EXIM Mailserver betreiben, hier die Regel um die Spams gezielt auszufiltern:

acl_check_mail:

# Hosts are required to say HELO (or EHLO) before sending mail.
...
drop message = identified as Anastasia Botnet
     condition = ${if match{$sender_address}{\N^Anastasia.*\N}{1}{0}}

Natürlich ist die Regel sehr grob, auch eine echte Anastasia.Kulikovwa@mail.ru würde ausgefiltert werden, aber im Gegensatz zu zum Botnetz, könnte die Dame zum Telefon greifen und einfach anrufen, daß die Mails nicht ankommen. Davon abgesehen sind 0.01% falsche Treffer eine echt gute Quote, mit der ich persönlich leben kann 🙂

Selbstverständlich könnte man die Regeln entsprechend verfeinern:

 condition = ${if match{$sender_address}{\N^Anastasia.{2,5}@.*\N}{1}{0}}

Diese Anpassung entspricht dem Muster, daß nach Anastasia noch bis zu 5 zufällige Zeichen kommen vor dem @.

Da es ähnliche Regelsätze für andere Mailserver gibt, könnt Ihr da natürlich jetzt Eure eigenen Anpassungen machen.

Lets Encrypt: Zertifikatsprobleme auf iOS Geräten

Seit Dezember 2015 stellt Lets Encrypt kostenlose Zertifikate zur Verfügung. Damit kann man Webseiten und Mailserver schützen, wenn da nicht die liebe Realität in Form von iOS wäre.

Bei unserem hausinternen Versuch, die Mailserver von einem kommerziellen Comodozertifikat auf Lets Encrypt umzustellen, was für Webseiten überhaupt kein Problem war, stellte sich raus, das sofort alle iOS Endgeräte, egal ob iPhone 5,6,7 oder iOS 9,10 keine Emails mehr empfangen konnten. Entäuschenderweise war auch Thunderbird betroffen 🙁

Daraufhin haben wir auf ein Comodozertifikat umgestellt und die Lage beruhigte sich, bis einige iOS Geräte anfinden, nur noch Emails zu senden, aber keine mehr zu empfangen. Wohlgemerkt, mit dem gleichen SSL-Zertifikat 😉

Nach derzeitigen Erkenntnissen seitens Comodo und unseren Technikern, liegt das Problem beim iOS Gerät selbst. Mal sehen was Apple dazu meint.

Auflösung: Mail.APP ist buggy, denn jedes andere installierte Emailprogramm auf einem betroffenen IPhone hat das Zertifikat einwandfrei akzeptiert. Aber der Witz kommt jetzt, dem Kunden hat das neue Mailprogramm „My Mail“  viel besser gefallen als die original App 😀