Apple Mail mit Exchange 2016 auf Windows Server 2016

Bei einem Projekt wurde aus Gründen in einer reinen Mac-Client-Umgebung (macOS 10.13 Sierra) ein Exchange-Server installiert. Hier haben wir den Exchange 2016 CU5 auch direkt auf dem Windows Server 2016 installiert. Die Clients können problemlos auf OWA zugreifen, eine Exchange-Verbindung via Apple Mail kommt jedoch nicht zustande. Angeblich sollen Benutzername und Passwort falsch sein. Die /EWS/Exchange.asmx kann ebenfalls mit dem Safari nicht aufgerufen werden (Authentifizierung scheint fehlzuschlagen).

Nach einiger Recherche habe ich die Lösung gefunden. Man muss auf dem Exchange Server die Nutzung von HTTP/2 deaktivieren, da es offenbar Schwierigkeiten mit NTLM-Authentifizierung und HTTP/2 unter Mac OS X gibt. Durch den Fallback auf HTTP/1.1 klappt auch NTLM wieder richtig und Apple Mail (und die anderen Apps) können Exchange nutzen.

Dazu einfach in der Registry unter HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters folgende Einträge erstellen:

REG_DWORD EnableHttp2Tls 0
REG_DWORD EnableHttp2Cleartext 0

Der erste Eintrag sollte eigentlich schon ausreichern, der zweite ist nur als Fallback gedacht.

Das Problem betrifft meiner Kenntnis nach nur Mac OS X, iOS-Geräte sind davon nicht betroffen (die nutzen ja auch mit ActiveSync eine andere Verbindungsmethode).

Quelle: https://social.technet.microsoft.com/Forums/en-US/dab47b34-84a0-43fa-b1fa-2c0999aac165/exchange-2016-ews-401-unauthorized-apple-mail-and-safari-only?forum=Exch2016CM

OS X möchte Änderungen vornehmen

Nachdem der Mail-Account bei einem Kollegen in Apple Mail neu eingerichtet wurde, erhielt er jedesmal beim Versuch, eine E-Mail zu versenden, den Hinweis „OS X möchte Änderungen vornehmen. Geben Sie Name und Passwort eines Administrators ein, um dies zu erlauben.“ mit dem weiteren Hinweis „OS X möchte den Schlüsselbund System verwenden.“. Die üblichen Schritte zur Fehlerbeseitigung, also Neustart des MacBooks, Prüfung/Reparatur des Schlüsselbundes, die Zugriffsrechte-Prüfung/Reparatur mit dem Festplattendienstprogramm sowie die Holzhammermethode, das Löschen des Anmeldeschlüssels unter ~/Library/Keychains, brachten nicht den gewünschten Erfolg. Ein Blick in die Kosole sagte zumindest, dass die Rules-Datei nicht geöffnet werden konnte und dass die Sandbox verhindert, dass Mail.app auf den Schlüsselbund zugreifen kann.

Mit Hilfe eines in Apple-Fragen versierteren Kollegen ließ sich dann feststellen, dass Apple Mail beim Versand von E-Mails diese mit dem Zertifikat, welches eigentlich für das VPN gedacht ist, verschlüsseln möchte. Nachdem wir den Haken für die S/MIME-Verschlüsselung in Apple Mail entfernt hatten, ging der Versand von E-Mails wieder Problemlos. Na ja, E-Mails werden jetzt mit dem Zertifikat signiert, aber das ist ja nicht weiter schlimm und verursacht keine Probleme. Apple Mail merkt sich zum Glück die zuletzt verwendete Einstellung und würde erst wieder verschlüsseln wollen, wenn man das Häkchen wieder aktiv setzt.

Wie konnte es nun dazu kommen? Initial wurde der Mac nur mit dem Mail-Konto eingerichtet. VPN kam erst einige Zeit später hinzu. Mail hat also die ganze Zeit sowieso nicht auf das Zertifikat zugegriffen. Erst nachdem es aufgrund eines Fehlers im Mail-Konto nötig war, das Mail-Konto neu einzurichten, hat Apple Mail nachgeschaut, ob es ein Zertifikat im System findet, welches die Identität des angemeldeten Nutzers nachweist, mit dem es E-Mails verschlüsseln kann. Da es fündig wurde, hat es also als Standardeinstellung dieses eigentlich für VPN gedachte Zertifikat genommen. Und da das Zertifikat im System-Speicher liegt, ist dafür ein administrativer Zugriff nötig.

Kerio Connect und fail2ban

Wer einen Mailserver betreibt, kennt das Problem, dass man neben den normalen E-Mails auch irgendwann höhere Mengen an Spam erhält. Bei dem von mir verwalteten Webserver mit Kerio Connect sind es so ungefähr 98% aller SMTP-Anfragen, die mit Spam zu tun haben.

Natürlich bietet Kerio Connect hier schon eine Auswahl an Antispam-Mechanismen an. So greift ein Spamassassin ein sowie verschiedene individuell zu gestaltende Spamfilter und Blacklist-Abfragen. Diese Möglichkeiten sollte man auf jeden Fall auch nutzen.

Das ändert aber nichts daran, dass der Mailserver immer wieder die gleichen Anfragen von den denselben Spam-Servern annehmen und verarbeiten muss. Hinzu kommen noch Script-Kiddies, die irgendwann auf den Webmailer aufmerksam werden und dort mit Exploit-Scripts versuchen, irgendwie Zugriff zu erlangen.

An dieser Stelle kommt dann das Tool fail2ban ins Spiel. Jedenfalls wenn man den Kerio Connect Server nicht unter Windows, sondern unter einem Linux laufen lässt.

Weiterlesen

Die Zahlen sprechen dagegen

Unsere Forensoftware versendet E-Mails von einer individuell generierten E-Mail-Adresse. Das Format ist re-xxxxxxx-xxxxxxx-xxxxxxx@service.domain.tld. Die „x“ sind alle Zeichen von [a-z] und [0-9]. Weil immer mal wieder einzelne Nutzer ihr Adressbuch mit Sozialen Netzwerken wie LinkedIn, Xing oder Facebook synchronisieren und alle gefundenen Kontakte einladen, werden auch diese Adressen eingeladen. Reagiert man nicht auf die Einladung, kommt kurze Zeit später eine Erinnerung.

Jetzt kann ich natürlich in jede Mail, die hier im Sammelbecken ankommt, auf den Unsubscribe-Link klicken. Wenn dann aber irgendwann jeder der 2,4 Millionen Nutzer auf die Idee kommt, die Adressen zu LinkedIn etc. zu importieren, hätte ich ne ganze Menge zu tun. Und eine Blockade allein für die Service-Domain am Mailserver einzurichten kann ich leider nicht, sondern nur global für alle vom Mailserver verwaltete Domains.

Also habe ich erstmal LinkedIn darum gebeten, unsere Service-Domain generell zu blockieren. Als Antwort kam, dass man keine Domains blockieren könne, sondern nur einzelne E-Mail-Adressen. Aber ich könnte ja eine Liste der zu blockierenden E-Mail-Adressen zuschicken, man würde die dann einzeln in die Blockliste eintragen.

An der Stelle bin ich ins Rechnen gekommen. [a-z] + [0-9] sind 36 mögliche Zeichen. Der individuelle Teil der E-Mail-Adressen besteht aus drei Blöcken á sieben Zeichen. Daraus ergibt sich eine Anzahl aus 36^21 möglichen Kombinationen. Das ist eine Zahl mit 33 Stellen. Namentlich 481,2… Quintillionen. Das ist wahnsinnig viel.

Aber davon mal abgesehen: eine Adresse besteht insgesamt aus 50 Zeichen (statischer und individueller Teil inkl. Domain), was 50 Bytes in einer simplen Textdatei entspricht. Bei (36^21)*50 Bytes wäre ich sehr sehr lange Zeit damit beschäftigt, bei voller Ausnutzung unserer 100MBit-Leitung, die Adress-Liste an LinkedIn zu übertragen. Nämlich ca. 60 Trilliarden Jahre. Da könnte ich den Urknall rund 4,4 Millionen Mal erleben.

Die Frage ist nun, LinkedIn grundsätzlich am Mailserver zu blockieren (vermutlich keine gute Option) oder eine Filterregel einzurichten, die alle LinkedIn-Einladungsmails an die Service-Domain direkt zur Support-Adresse von LinkedIn weiterleitet (verführerisch!). Ich muss da nochmal drüber nachdenken.

Viren-Mails erkennen

IMG_0006Ein immer wieder beliebtes Thema ist, wie man Viren-Mails erkennt. Darunter gibt es zwei Kategorien: 1. die Schadsoftware kommt direkt als Anhang mit und 2. man wird dazu verleitet, auf einen Link zu klicken, hinter dem sich Schadsoftware verbirgt.

Die erste Methode hat den „Nachteil“, dass die Viren erst gar nicht beim Empfänger ankommen könnten, weil sie möglicherweise von einem Anti-Virus-Gateway, der dem Mailserver vorgeschaltet ist, erkannt und entfernt werden. Der Vorteil ist, dass man dem User auf direktem Wege die Schadsoftware unterjubeln kann, ohne dass er durch einen weiteren Download vielleicht misstrauischer wird. Bei Methode zwei ist es dann quasi genau anders herum.

Ich gehe aber mal von der Situation aus, dass die Schadsoftware nicht erkannt wurde und bei dem Benutzer nun im Postfach liegt. Da so eine Schadsoftware im Anhang ja nicht direkt als solche erkannt werden soll, heißt sie natürlich nicht „ichbineinvirusalsoklickmich.exe“, sondern der Dateiname wird verschleiert. Dann wird daraus eben „Rechnung_08154711.exe“ oder – in Anlehnung an das Format digitaler Kameras „IMG_000234.jpg.exe“. Gerne wird eine solche ausführbare Datei dann auch mit einem üblichen Icon von Adobe PDF, Microsoft Word Dokument, Bilddateien oder einem anderen, dem vorgetäuschten Format entsprechenden Icon, versehen. Dass die Dateiendung .exe lautet, übersehen dann viele Benutzer oder – weil unter Windows die Anzeige von bekannten Dateierweiterungen standardmäßig nicht angeschaltet ist – sehen es erst gar nicht. Im guten Glauben, dass es sich dabei um den suggerierten Dokumententyp handelt, wird die Schadsoftware dann ausgeführt. Häufig kommt es auch vor, dass doppelte Dateiendungen verwendet werden. So wird aus unserem Beispiel dann „Rechnung_08154711.pdf.exe“. Das hat natürlich auch was mit der Standardeinstellung von Windows zu tun, soll und könnte aber auch bei aktivierter Anzeige von bekannten Dateiendungen den nicht so versierten Benutzer in die Irre führen. Da viele Mailprogramme, zumindest die aktuellen Generationen, aber .exe-Dateien selbständig als potentiell gefährlich blockieren und dem Benutzer dann nicht ohne Weiteres Zugriff auf den Anhang gewähren, sind die Virenschreiber dazu übergangen, die .exe-Datei in einer Zip-Datei zu verpacken. Dann kommt eine E-Mail mit dem Anhang „Rechnung_08154711.pdf.zip“, in der sich jedoch die schadhafte .exe-Datei befindet.

Solche Viren-Mails setzen darauf, dass der Empfänger entweder aufgrund seiner täglichen Arbeit (z.B. Buchhaltung), Neugierde („hier guck mal, das Foto von dir“) oder Angst (Mahnungen oder horrende Rechnungsbeträge) den Anhang öffnet oder einen bösartigen Link anklickt. Gerade weil auch manche Unternehmen keine Rechnungen als Anhang versenden, sondern in ihren echten E-Mails den Benutzer dazu auffordern, sich die Rechnung im jeweiligen Kundencenter herunter zu laden (am besten mit direktem Link zur Rechnung), können die Virenschreiber die Empfänger relativ einfach dazu verleiten, den bösartigen Link aufzurufen. Dahinter verbirgt sich dann direkt eine schadhafte Datei oder ein Exploit. Zum Beispiel könnte die aus dem vorherigen Abschnitt bekannte Schadsoftware unter dem Namen „Rechnung_08154711.pdf.exe“ dort direkt als Download starten. Oder aber eine manipulierte Dokumentendatei, die eine Sicherheitslücke (entweder eine alte oder eine Zero-Day-Lücke) ausnutzt, um Schadsoftware zu installieren. Und selbstverständlich eine Webseite, die versucht, mit Exploits den Browser zu kompromittieren und darüber die Schadsoftware in das System zu bringen.

Und auch wenn Nutzer von Linux-Systemen oder MacOS X weniger selbst gefährdet sind, sich eine Schadsoftware einzufangen, so habe ich es dennoch erlebt, dass diese solche E-Mails stumpf, ohne nachzudenken, an die Buchhaltung oder Geschäftsführung ihres Unternehmens weiterleiten, wo wiederum Windows eingesetzt wird. Auch solche Nutzer sollten also sensibilisiert werden, um Gefährdung anderer Nutzer vermeiden.

Die Zeiten, in denen böswillige E-Mails oft noch leicht zu erkennen waren, sind vorbei. Die Virenschreiber geben sich beim Verfassen und Versenden der Viren-Mails immer mehr Mühe, so dass es auch versierten Nutzern immer schwerer fällt, eine bösartige Mail von einer legitimen Mail zu unterscheiden.

Dennoch gelten nachfolgende Regeln nach wie vor:

  1. Begrüßung
    Wird man mit Namen gegrüßt, wie es die meisten Unternehmen machen, oder steht dort nur sowas unpersönliches wie „Guten Tag“ oder „Sehr geehrter Kunde“? Da die Virenschreiber in eigentlich keinem Fall die Namen der Empfänger wissen (Achtung, es gibt hier natürlich auch Ausnahmen!), wird keine persönliche Anrede genutzt, sondern man versucht sich allgemein zu halten.
  2. Rechtschreibung und Grammatik
    Zwar wird es immer besser, aber viele Viren-Mails sind in einem so grausamen Deutsch verfasst, dass der Empfänger, so er denn nicht selbst über sehr eingeschränkte Deutsch-Kenntnisse verfügt, stutzig werden sollte. Wer bei „Wolle kucke rechnung dan du klicke hierr!!!!“ immer noch glaubt, dass sich dahinter was seriöses verbirgt, dem sollte man den Zugang zu einem Computer verbieten. Verlässlich ist dieses Kriterium natürlich nicht. In letzter Zeit habe ich etliche E-Mails gesehen, deren Rechtschreibung und Grammatik zwar nicht tadellos war, aber für viele wohl auch nicht auf den ersten Blick auffällig.
  3. Neugierde oder Angst weckend
    Wenn wildfremde Leute dir ein Foto schicken, auf dem du angeblich drauf bist. Oder ein Video verlinken, in dem du vorkommen sollst. Oder du eine Mahnung erhälst, wo du richtig viel Ascha abdrücken sollst. Oder eine solche Rechnung. Dann überleg doch mal: kann das überhaupt sein? Ist das, was behauptet wird, schlüssig? T-Mobile verschickt zum Beispiel ihre Rechungen immer nur für den vorausgegangenen Monat. Wenn ich also am 15. Januar eine Rechnung über 325,76 € für Januar erhalten soll, dann kann ich sicher sein, dass diese Rechnung nicht wirklich von T-Mobile kommt.
  4. Dubiose Server
    Ein Link ist nicht immer so, wie er scheint. Unter dem Link http://www.bing.de habe ich die Suchmaschine Google versteckt. Das gleiche Prinzip wird auch bei Viren-Mails verwendet. Dort wird augenscheinlich eine legitime Adresse angegeben, stattdessen wird aber, weil der Link-Text unabhängig vom verlinkten Inhalt ist, auf einen dubiosen Server im Ausland verlinkt. Wer ein gutes E-Mail-Programm einsetzt, dem wird auf irgendeine Weise (bspw. unten im Status oder als PopUp-Information) die Adresse angezeigt, auf die tatsächlich verlinkt wird, wenn man den Mauszeiger über den Link bewegt. Doch auch hier sollte man aufpassen. Ist eine Adresse wie http://kjdhgnkkk67rdnizu7.au.br/telekom/ noch recht auffällig, so könnte man sich von http://www.telekom.de.security-server.djmhbgsz.au.br/ eher in die Irre führen lassen. Ganz wichtig zu wissen ist also, dass eine Server-Adresse erst nach dem ersten Slash endet. Die Server der Telekom wäre http://www.telekom.de/ und im oben genannten Beispiel wäre der tatsächliche Server http://djmhbgsz.au.br/ (der Teil „www.telekom.de.security-server.“ ist nur eine Subdomain und die kann man sich selbst so anlegen, wie man gerade möchte).
  5. Absender
    Ist der Absender wirklich der, für den er sich ausgibt? Den Absender einer E-Mail-Adresse zu fälschen ist leicht. Das ist von technischer Seite sogar so gewollt, auch wenn man sich damals, als das SMTP-Protokoll erschaffen wurde, noch nicht so viele Gedanken über Missbrauch gemacht hat. Aber letztendlich kann man ja auch auf einen Briefumschlag einen falschen Absender drauf schreiben. Manche Virenschreiber geben sich Mühe und spiegeln dem Empfänger vor, die falsche Telekom-Rechnung komme tatsächlich von rechnung@telekom.de. Manche machen es eher halbherzig und bringen es nur fertig, dass als Absendername bspw. „Telekom Kundenservice“ steht, als Adresse ist dann aber info@waldorfschule-pankow.de eingetragen. Jedes vernünftige E-Mail-Programm zeigt die (wenn auch gefälschte) Absenderadresse an. Wer hier jedoch bei einer plausiblen Absenderadresse herausfinden möchte, ob die E-Mail legitim ist, kommt um eine Prüfung des E-Mail-Headers und der übrigen Kriterien nicht herum.
  6. Empfängeradresse
    In Unternehmen gehen Rechungen in aller Regel an entsprechend eingerichtete Buchhaltungs-Adressen. Wer in einem Unternehmen unerwartet eine Rechnung erhält, obwohl er bisher noch nie Rechungen erhalten hat und auch gar nicht dafür zuständig ist, der muss sich dann auch in der Regel gar keine Gedanken darüber machen, ob er die E-Mail an die Buchhaltung weiterleiten oder lieber direkt löschen sollte. Und wer in der Buchhaltung arbeitet, sollte prüfen, ob die E-Mail wie gewohnt an die Service-Adresse gegangen ist oder ungewöhlich an die eigene. Aber auch im privaten Rahmen sollte man sich fragen, ob es plausibel ist, dass man an seine E-Mail-Adresse die Rechnung erhält. Hatte man zum Beispiel noch nie irgendeinen Kundenkontakt zu T-Mobile, weil man möglicherweise Vodafone-Kunde ist, braucht man einer angeblichen T-Mobile-Rechnung auch keine Aufmerksamkeit zu schenken.

Ich hoffe, ich konnte mit dieser kurzen Erklärung es etwas vereinfachen, auch gut gemachte Viren-Mails zu erkennen. Um einige Sachen besser zu verstehen und nachzuvollziehen, müsste ich womöglich viel weiter ins Detail gehen. Das kann ich gerne auch machen, hier in diesem Beitrag würde das jedoch den Rahmen sprengen. Und ich glaube auch, das zu viele technische Hintergründe für weniger versierte Nutzer eher ermüdend und langweilig sind oder zu Resignation führen, obwohl das gar nicht nötig wäre.