Archiv der Kategorie: Exchange

Office 365: Ausführbare Anhänge blockieren

Das ist nun schon das zweite Mal, dass uns Malware per Mail erreicht.

Auch dieses Mal befindet sich die Malware in einem Zip-Archiv. Die Absenderadresse ist gefälscht und kann aber durchaus eine sein, die man kennt. Scheinbar kommen Absender und Empfänger aus einem infizierten Adressbuch, so dass die Chance gross ist, dass der Empfänger den Absender kennt und für vertrauenswürdig hält.

image

Wenn man das angehängte “Report.zip” (oder ähnlich) herunterlädt, handelt es sich um eine ausführbare “exe” Datei, die aber durch ein falsches Symbol (z.B. PDF) vertrauenswürdig erscheinen möchte.

image

Bei beiden Malen war es so, dass der Virenscanner die Datei noch nicht als Virus oder Trojaner erkennt. Auch bei diesem Mal wird die Datei auf www.virustotal.com nur von 3 aus total 57 Scannern als Malware erkannt wird.

image

Erfahrungen vom letzten Mal haben gezeigt, dass die gleiche Datei am nächsten Tag von allen 57 Scannern erkannt wird. Aber in dieser Zeit kann ein Befall stattfinden. Wir setzen Endpoint Protection von Microsoft ein. Um zu erreichen, dass der Scanner noch schneller angepasst wird, kann man ein “sample” an Microsoft schicken. Dazu verpackt man die Datei in ein mit dem Passwort “infected” geschütztes Archiv.

image

Dieses kann man über diese Seite an Microsoft zur Überprüfung senden, damit der Virenscanner möglichst schnell angepasst wird.

image

Eine Möglichkeit ist es, die Anwender per Mail zu informieren. Zum einen weiss ich aber, dass meine Mails oft nicht oder nicht richtig gelesen werden Zwinkerndes Smiley und zum anderen haben wir auch noch Schüler/-innen, die nach einer solchen Mitteilung vielleicht erst recht die Datei ausführen.

Es gibt aber nicht viele Gründe, wieso ausführbare Dateien überhaupt per Mail geschickt werden müssten. Besser ist es also, wenn man diese schon blockiert, bevor sie beim Benutzer ankommen.

Dazu wählt man im “Exchange Admin Center” –> “Nachrichtenfluss” –> “Regeln”.

image

Durch einen Klick auf das Plus kann man eine neue Regel erstellen.

image

Nun wählt man zuerst “weitere Optionen…”

image

Der Regel muss man einen Namen geben und dann wählt man “Mindestens eine Anlage hat ausführbaren Inhalt” und “Die Nachricht ohne Benachrichtigung anderer Benutzer löschen”. Man könnte die Nachricht auch an den Absender zurückschicken mit einer Meldung, dass wir keine angehängten ausführbaren Dateien akzeptieren. Aber bei gefälschten Absenderadressen ist das eher kontraproduktiv (am Schluss meint man noch wir seien die Virenversender).

image

Gemäss diversen Internetressourcen dauert es eine gewisse Zeit, bis die neue Regel aktiviert ist. Danach sollte man die Regel unbedingt mit einem Testdokument von einer externen Adresse überprüfen.

Hier findet sich ein entsprechender Blogbeitrag auf MSDN und hier auf dem Technet. Falls es zu Problemen kommt, findet man hier einen Beitrag, der allenfalls eine Lösung bietet.

Nachtrag

Schon kurze Zeit später werden Mails mit ausführbaren Anhängen korrekt gelöscht. Es wurde sogar erkannt, dass ein umbenanntes Worddokument keine ausführbare Datei ist. Ich musste eine richtige exe nehmen um zu testen…

image

zurück zur Übersicht

Probleme mit Winmail.dat

Outlook kennt 3 Möglichkeiten, wie ein Mail formatiert werden kann: “Nur Text”, “Rich Text”, “HTML”.

“Rich Text” ist ein proprietäres Format von Microsoft. Wenn ein Mail mit diesem Format verschickt wird, kommt technisch TNEF (Transport Neutral Encapsulation Format) zum Einsatz.

Einige Mailclients wie das Mailprogramm von Apple können aber mit dem TNEF Protokoll versendete Mails nicht lesen und bekommen ein Mail mit einem Winmail.dat Anhang, den sie ohne zusätzliche Programme oder Onlinedienste nicht öffnen können.

Obwohl es zu Problemen mit TNEF auf Empfängerseite kommen kann, sollte man es nicht ganz deaktivieren, da TNEF für Zusatzfunktionen wie Besprechungseinladungen, Abstimmungsschaltflächen oder Mailformulare verwendet wird.

Für Mails an externe Empfänger, die keine solchen Zusatzfunktionen verwenden, sollte man also nie das “Rich-Text” Format verwenden, sondern immer nur “Nur Text” oder “HTML”. Dies erreicht man, indem man bei der Registerkarte “TEXT FORMATIEREN” überprüft, was ausgewählt ist.

image

Standardmässig sollte hier ausgewählt sein, was man unter “Datei” –> “Optionen” –> “E-Mail” eingestellt hat.

image

Nun kann aber auch noch jede Mailadresse separate Einstellungen aufweisen. Dies kann man überprüfen, indem man z.B. in Outlook 2013 einen Rechtsklick auf die Mailadresse macht und “Outlook-Eigenschaften öffnen” auswählt. Wenn dort “Outlook wählt das optimale Sendeformat” ausgewählt ist, kann man hier auch “Als Nur-Text senden” erzwingen.

image

Diese Hintergrundinformationen interessieren die meisten Benutzer aber nicht und werden von vielen auch nicht verstanden. Für die Benutzer sollte das Mailsystem einfach funktionieren. Daher kann es sinnvoll sein, als Administrator für einzelne Empfänger oder ganze Domänennamen den Versand mit TNEF zu deaktivieren, wenn z.B. die Empfänger mit Apple Mail arbeiten und die oben erwähnten zusätzlichen Funktionen gar nicht nutzen können.

Um eine ganze Domäne zu konfigurieren, muss man sich zuerst mit Exchange Online über Powershell verbinden. Danach kann man eine neue Remotedomain erstellen, die man in einem weiteren Schritt konfiguriert:

New-RemoteDomain –Name Beispielschule –DomainName beispielschule.ch

Set-RemoteDomain –Identity Beispielschule -TNEFEnabled $false

image

In diesem Technet-Artikel ist zusätzlich noch beschrieben, wie man die Einstellung für einen einzelnen Kontakt ändert.

Komisch ist, dass wir auch einen Empfänger hatten, der mit Outlook und einem lokalen Exchangeserver einen Winmail.dat Anhang erhalten hat. Darüber habe ich im Internet aber nichts gefunden und kann es mir auch nicht wirklich erklären. Vielleicht ist da bei der lokalen Installation des Exchangeservers etwas eingestellt, das dieses Problem verursacht. Ich bin dem aber nicht weiter nachgegangen, sondern habe auch in diesem Fall einfach die Remotedomäne für TNEF deaktiviert.

Apple Mail Problem mit Exchange Reverse Proxy

Wir haben unseren ISA Server durch eine Sophos UTM ersetzt. Statt den Exchangeserver über die Firewall direkt ins Internet zu stellen, kann die Sophos UTM als Reverse Proxy auftreten, der die Anfragen aus dem Internet entgegen nimmt und dann an Exchange im internen Netzwerk weitergibt. ISA konnte dies auch und war mit ein Grund, wieso wir vorher ISA eingesetzt haben.

Sophos macht Werbung damit, dass sich die UTM als Ersatz für TMG (Nachfolger von ISA) eignen würde:
image

Im Zusammenhang mit Exchange hat auch alles gut ausgesehen, die Einrichtung war einfach, das Forum gibt schnell und kompetent Antwort, Outlook Web Access, Outlook Anywhere und ActiveSync funktionieren ohne Probleme.

Leider gibt es doch ein Problem. Wir haben einige Lehrkräfte, die sich von zuhause mit ihrem Mac auf den Exchangeserver verbinden. Wenn eine Lehrkraft über Apple Mail eine Mail verschickt, kann es vorkommen (nur manchmal), dass die Absenderadresse vertauscht wird. Das grösste Problem dabei ist, dass der vertauschte Absender die Mail unter seinen gesendeten Objekten findet, was natürlich ein absolutes No-Go ist. Wenn plötzlich Mails von anderen gelesen werden können, ist das Vertrauen in das schuleigene Mailsystem schnell dahin.

Ich habe dann recherchiert und eine Anfrage an das Sophos Forum gestellt. Auf den Technet Seiten von Microsoft bin ich dann auf ein ähnliches Problem gestossen. Auch da war das Problem der Reverse Proxy, aber als Reverse Proxy wurde ein Apache Webserver eingesetzt. Daher konnte ich den dort beschriebenen Workaround nicht bei uns einsetzen. Hier muss ich warten, bis Sophos das gelöst hat. Bei einem so grossen Problem kann ich aber nicht einfach abwarten. Also musste ich eine andere “Lösung” des Problems suchen.

Der einzig sinnvolle Weg im Moment war, die Kommunikation mit Apple Mail zu unterbinden. Wir bieten ja auch noch Outlook Web Access und ActiveSync für unsere Lehrpersonen an, um die Mails von zuhause zu bearbeiten. Dazu kommt sogar noch ein Zugang über einen Remotedesktopserver, um von zuhause aus zu arbeiten, was auch mit der neuen MacOS App funktioniert. Apple Mail kommuniziert mit Exchange über EWS und nicht über Mapi wie bei Outlook Anywhere. EWS wird aber auch sonst benötigt und kann nicht einfach deaktiviert werden. Mit set-organizationconfig lässt sich ab Exchange 2010 SP1 der Zugang zu EWS detaillierter konfigurieren. Leider funktioniert das unter Exchange 2007 noch nicht. Da musste ich noch was anderes suchen. Microsoft hat im Technet einen Artikel “Using URL Rewrite to block certain clients from Exchange” veröffentlicht. Damit kann man erreichen, dass der IIS, der die Seiten für den Exchangeserver ausliefert, für gewisse Bedingungen eine Fehlermeldung statt der Seite ausliefert. 

Nach der Installation vom URL Rewrite Module 2.0 findet man im IIS Manager einen neuen Eintrag “URL Rewrite”. Weil Apple Mail ja auf EWS zugreift, muss man dieses Verzeichnis auswählen (ansonsten könnte man ja mit einem Mac z.B. auch nicht mehr auf Outlook Web Access kommen) und eine neue Anforderungsblockierungsregel hinzufügen. 

image

Unter Protokollierung findet man den Speicherort der Logfiles vom IIS. Standardmässig ist das %SystemDrive%\inetpub\logs\LogFiles. Dort sieht man, dass sich der User-Agent mal als Mac+OS+X und manchmal als Mac_OS_X zu erkennen gibt.
image

Somit kann man in der Anforderungsblockierungsregel den Zugriff aufgrund des Benutzer-Agent-Header blockieren, wenn er dem Muster *Mac* entspricht. Falls sich nun ein Mac mit Apple Mail mit dem Exchange Server verbinden möchte, bekommt er HTTP 403 als Antwort und kann sich somit nicht verbinden.

image

Im IIS Log findet man weiterhin die Anfragen von Apple Mail Clients, aber neu mit der Antwort 403.
image

Trotzdem hoffe ich natürlich, dass Sophos das Problem mit dem Reverse Proxy bald lösen kann.

Nachtrag
Gemäss diesem Forumsbeitrag arbeitet Sophos an einem Fix. “We are working on a fix. Mantis 27287: Outlook anywhere connection with WAF didn’t work for Mac Clients
At the moment, we do not support Outlook Anywhere connections for Mac clients”

Nachtrag 2
In diesem Forumsbeitrag gibt es noch weitere Informationen. Da wird auch bestätigt, dass es im Moment keine WAF Unterstützung für Mac gibt, unabhängig vom Client.