Exchange 2013 Malware

Eine große Neuerung bei Exchange 2013 ist der "eingebaute" Malwarescanner. Microsoft hat ja das Produkt "Forefront für Exchange" abgekündigt. Diese Seite beschreibt die neuen und fehlenden Funktionen von Exchange 2013 im Bereich Antivirus.

Am 1. Jan 2022 bringt die Nummerierung der Patterndateien den Malware Transport Agent aus dem Tritt und die Mailzustellung istblockiert. Siehe Fips Y22 Bug.

Aus meiner Sicht ist der "eingebaute" Virenscanner keine adäquate Lösung mehr. Sie benötigen immer einen zusätzlichen Schutz.

Geschichtsunterricht

Erinnern sie sich noch, also die ersten Viren per Mail ( iLoveYou etc.) die Exchange 5.0 Server überrascht haben? Damals hat die Firma Sybari mit dem Produkt Antigen eine DLL gebaut hat, die sich vor den Exchange Store gemogelt hat um Mails in der Mailboxdatenbank in Realtime zu prüfen. Sybari hatte diesen speziellen Weg entwickelt, der sie zu einem Big Player im Exchange Antivirenkampf werden liest, obwohl sie sich bei den Scan-Engines der Mitbewerber bedienen musste. Microsoft hat später mit der VSAPI eine offizielle Schnittstelle mit Exchange 5.5 eingebaut, damit auch andere Hersteller den Postfachspeicher in Realtime scannen konnten. Vorher war es nur möglich, quasi per MAPI mit einem privilegierten Konto regelmäßig die Elemente zu prüfen, was sehr CPU-Intensiv, IO-intensiv und letztlich langsam war

Im Februar 2005 wurde Sybari wurde von Microsoft gekauft und der Virenscanner wurde als "Forefront für Exchange" angeboten.

Auch im AntiSpam-Bereich, der nahe mit dem Antivirenkampf verbunden ist, hat Microsoft sich durch den Zukauf von FrontBridge im Sommer 2005 verstärkt.

Das Angebot ist nun in Office 365 als "Forefront Online Protection" für Exchange aufgegangen und bietet einen hosted Spamschutz und natürlich Virenfilter.

Forefront und VSAPI sind tot !

Mit Exchange 2013 gibt es ganz große und wichtige Änderungen . Informationen für den Vertrieb weisen erst mal darauf hin, dass "Forefront für Exchange 2010", d.h. der Virenscanner auf dem Exchange Mailboxserver und dem HubTransport Server nicht mehr weiter gepflegt wird.

Es gibt also definitiv kein "Forefront für Exchange 2013". Wichtiger ist aber eine zweite Information, die so deutlich gar nicht kommuniziert wird:

VSAPI entfällt mit Exchange 2013 !
D.h. es gibt auch für Dritthersteller keine Möglichkeit mehr, entsprechende Add-on-Produkte für den Exchange Mailbox Store zu integrieren.

Nur auf dem Transport kann demnach noch "Realtime" nach Viren gesucht werden. Entsprechend haben die verschiedenen Anbieter schon Artikel online gestellt, in der Sie die Notwendigkeit betonen und Alternativen anbieten.

The retirement of the VSAPI means that PME 4.0 now provides background scanning (scanning the information store after every virus identity, or IDE, Update) of Exchange private and public information stores using the Exchange Web Services API (EWS API)
Quelle: PureMessage für Microsoft Exchange 2013 (PME 4.0) now available (http://blogs.sophos.com/2013/07/23/puremessage-for-microsoft-exchange-2013-pme-4-0-now-available/)

VSAPI is removed from Exchange Server 2013. Therefore, Mail Security provides an alternate solution für continuous protection in the form of a scheduled scan
Quelle: What's new in Mail Security (http://www.symantec.com/docs/HOWTO83121)

.. works with On-Prem Exchange servers and can filter Exchange 2013 email traffic in real-time and stored in the mailstore (even though VSAPI was removed from Exchange 2013).
Quelle: Microsoft’s Changes to FPE 2010 and How it Affected Exchange 2013 (http://blog.trendmicro.com/smex-11/)

Ist ein Transportscanner genug ?

Microsoft lässt sie natürlich nicht "ungeschützt" sondern integriert den Virenscanner direkt ins Produkt. Allerdings arbeitet dieser nur auf dem Transport. Reicht das ?

Dazu müssen Sie wissen, das es immer eine „Lücke“ zwischen „neuer Virus“ und „Erkennung“ durch Software als Schadcode geben wird. Gehen Sie daher einfach davon aus, dass neue Viren unerkannt in einem Datenspeicher liegen. Zudem gilt diese Lücke nicht nur für „gängige Viren“, die oft genug zum Einsatz kommen, damit Sie in einem Patternfile wirklich erkannt werden. Die Lücke ist ungleich größer für „Zielgruppenoptimierten“ Schadcode von Geheimdiensten, Spionen, Kriminellen etc.

Ein „OnAccess“-Scanner auf der Datenbank bzw. ein „geplanter Scan“ mit einem neueren File kann also immer nur die Viren aufstöbert, die durch ein neueres Patternfile mittlerweile erkannt werden, die beim der Übertragung nocht nicht bekannt waren. Ein neueres Pattern kann aktuellere Viren erkennen aber auch hier bleiben immer unerkannte Schadkomponenten zurück. Lohnt es sich daher jede Nacht oder jede Woche durch den ganzen Store zu laufen? ist natürlich auch eine Frage der Ressourcen und damit Kosten. Zudem ist auch ein Virenscanner auf der Datenbank oft eine Quelle für Fehler, die nicht immer einfach zu finden sind.

Meines Wissens macht der „eingebaute Virenscanner“ von Exchange 2013 nur noch einen Transport Scan. Also bleibt ein "blinder Fleck". Ein Virenscanner auf dem Client, idealerweise mit schneller Aktualisierung und ggfs. Verhaltenskontrolle ist daher unverzichtbar. Die Aufgabe ist hier natürlich möglichst alle Clients zu erwischen, was in Zeichen von Mobilgeräten, Tablets, und OWA auf Privatcomputern nicht immer einfach ist.

Auf der anderen Seite kann ein Scanner auf dem Server in der Regel nur "ungeschützte" Inhalte prüfen. Verschlüsselte Mails (S/MIME oder PGP) oder auch nur mit Kennwort geschützte Dokumente und Archive kann nur ein Scanner auf dem Client nach dem Decodieren oder Auspacken erwischen. Hier sollten Sie also auch ihre Mitarbeiter sensibilisieren.

Ich empfehle daher die Überprüfung auf unerwünschte Mails auf dem Server durchzuführen, der per MX-Record von extern erreicht wird. Diese Software sollte auch SMIME/PGP decodieren können um die Verbindung mit einem Feler abzulehnen. So umgeht man auch die Quarantäne. Weiterhin muss der Client als aktive Schutzkomponente betrachtet werden. Das betrifft sowohl Software (Virenscanner), Betriebssystem und natürlich den Anwender.
Die Exchange Transport Scanfunktion von Exchange 2013 ist ein zusätzlicher Schutz um die Ausbreitung von Viren bei interner Kommunikation zu unterbinden, der aber nicht allzu viel Ressourcen kostet.

Auf der anderen Seite war natürlich VSAPI und daran angekoppelte Virenscanner immer auch ein Risiko für den Server selbst.

Malware Scanner Setup

Statt dessen werden Sie nun schon bei der Installation gefragt:

Mehr kann bei der Installation gar nicht konfiguriert werden.

Info:
Wenn man den Malware Scanner installiert, scheint das Setup auch gleich die AntiSpam Agents mit zu aktivieren, die eigentlich ein Transport Agent sind.

Konfiguration

Die Verwaltung erfolgt per Webbrowser auf /ECP und dann bei Schutz. Mehr als das eine "Default"-Element gibt es nicht.

Über den "Bleistift" können die die Einstellungen ändern. Die Karteikarte "Allgemein" erlaubt nur eine Beschreibung

Erst unter Einstellungen können einige wenige Daten konfiguriert werden: Die Liste erscheint zwar lange aber sie enthält auch alle möglichen Einstellungen. 

Wenn Sie sich diese Einstellungen genau ansehen, dann erkennen Sie, dass es z.B. keine Quarantäne gibt. Wenn die Software glaubt einen Schadcode entdeckt zu haben, dann gibt es keine Option die Anlage wieder zu erhalten. Das geht eigentlich nur mit unrealistischen 0% False Positive. Ich bin wirklich nicht sicher, ob allein dieses Verhalten die Einsatzfähigkeit reduziert. Auch sonst sind die Benachrichtigungsfunktionen sehr beschränkt.

Achtung:
Per Default geht Microsoft wohl davon aus, dass Sie eine 0% False Postive Rate haben. Diese Annahme ist falsch, wie eine durch den Scanner gelöschte "gute" Mail in meiner eigenen Umgebung gezeigt hat. Sie sollten also uNBEDINGT die Konfiguration anpassen, dass zumindest interne Sender eine Information erhalten. Und die Mail dann ohne Anlagen weiter gesendet wird.

Wenn Sie diese Einstellung nicht per GUI machen wollen, dürften Sie natürlich auch die PowerShell verwenden.

Set-MalwareFilterPolicy `
   -Identity=Default `
   -ExternalSenderAdminAddress=support@msxfaq.de `
   -EnableInternalSenderNotifications=$True `
   -InternalSenderAdminAddress=support@msxfaq.de `
   -CustomAlertText="Exchange 2013 Malwarefilter hat eine Anlage mit Schadcode gelöscht." `
   -EnableExternalSenderAdminNotifications=$True `
   -Action=DeleteAttachmentAndUseCustomAlertText `
   -EnableInternalSenderAdminNotifications=$True
 
Set-ContentFilterConfig `
   -SCLRejectEnabled=$False

Wenn Sie nach einem solchen Vorfall" suchen wollen, dann ist das Messagetracking eine gute Quelle. Hier der Datensatz mit den relevanten Einträgen:

SourceContext           : Malware Agent
Source                  : AGENT
EventId                 : FAIL
RecipientStatus         : {550 4.3.2 QUEUE.TransportAgent; message deleted by transport agent}
MessageInfo             : 2013-07-18T11:54:15.592Z;SRV=E2013.msxfaq.de:TOTAL=0;SRV=E2013.msxfaq.de:
                          TOTAL=0;SRV=E2013.msxfaq.de:TOTAL=3;CAT|CATSM|CATSM-Malware Agent

3rd Party -Hersteller

Wenn Microsoft bereits einen "Malwarescanner" mitliefert, dann wird die Luft natürlich dünn für 3rd-Party Hersteller, die bislang mit ihren Exchange Lösungen durchaus gutes Geld verdient haben. Aber auch hier wird es im Bezug auf einen MailboxScan schwer

Exchange 2013 has a changed infrastructure with less roles, no VSAPI on which malware protection suites can latch on and already has a built-in malware scanning module. This is so different and new, that will probably warrant a blog post on it's own
Quelle: http://blogs.dirteam.com/blogs/davestork/archive/2012/12/06/exchange-and-malware-protection.aspx

Allerdings steht diese Aussage einer Beschreibung der Exchange 2013 entgegen.

Third-party anti-malware protection
You can also use a third-party anti-malware protection program. In this case, you may want to disable the built-in anti-malware protection;
Quelle: http://technet.microsoft.com/en-us/library/jj150547(v=exchg.150).aspx

Ohne die Möglichkeit eines Echtzeitscans beim Zugriff durch den Anwender wäre es natürlich unmöglich, Schadcode im Postfach zu erkennen, der früher durch den Transportscanner geschlüpft ist. Dieser Fall ist gar nicht mal ungewöhnlich, wenn ein neuer Schadcode so frisch ist, dass ihn die Virenscanner erst mit einem Pattern-Update erkennen. Aber auch die früher beliebte Funktion bestimmte Dateien, z.B. ausführbare Programme, mit Hilfe des Virenscanners zu blocken, bietet der in Exchange 2013 eingebaute Malware-Schutz nicht. Ein Scanner für die CAS-Rolle ist aktuell nicht vorgesehen.

Insofern bleibt neben einem Scan auf dem Transport, um einen Großteil des Schadcode beim Empfang oder später bei der Weiterverbreitung zu erwischen und vielleicht ein regelmäßiger "FullScan" per EWS. Mittlerweile haben erste Hersteller diesen Wink aufgegriffen und ihre Produkte wieder um eine entsprechende Funktion erweitert:

PowerShell für Malwarescanner

Die Verwaltung des Malware-Scanners erfolgt über das Snapin "Add-PSSnapin Microsoft.Forefront.Filtering.Management.PowerShell". Allerdings gibt es von Microsoft einige PowerShell-Skript im Skripts-Verzeichnis, die die wesentlichen Funktionen vereinfachen:

# Skripte liegen in C:\Program Files\Microsoft\Exchange Server\V15\Scripts
#
# Virenscanner deaktivieren, z.B. fuer OEM Produkte
Disable-AntimalwareScanning.ps1

# Virenscanner aktivieren
Enable-AntimalwareScanning.ps1

# Update der Patterndatei anstoßen
& $env:ExchangeInstallPath\Scripts\Update-MalwareFilteringServer.ps1 -Identity $env:COMPUTERNAME

Die Kontrolle der Updates erfolgt übrigens über das Application Eventlog mit dem Filter auf "FIPFS". Hier ein erfolgreiches Update

Log Name:      Application
Source:        Microsoft-Filtering-FIPFS
Date:          7/3/2013 3:53:04 PM
Event ID:      6033
Task Category: None
Level:         Information
Keywords: User:          NETWORK SERVICE
Computer:      msx2013.netatwork.de
Description:
MS Filtering Engine Update process performed a successful scan engine Update.
 Scan Engine: Microsoft Update Path: http://forefrontdl.microsoft.com/server/scanengineupdate
 Last Update time:‎2013‎-‎07‎-‎03T13:53:04.000Z
 Engine Version:1.1.9607.0
 Signature Version: 1.153.1162.0

Per PowerShell können Sie auch den Filter nachträglich komplett abschalten. Das geht einmal temporär oder gleich komplett.

# Filterung deaktivieren
Set-MalwareFilteringServer <ServerIdentity> -BypassFiltering $false

# Filterung wieder aktivieren
Set-MalwareFilteringServer <ServerIdentity> -BypassFiltering $false

# Filteragent und Update der Datenbanken komplett abschalten
& $env:ExchangeInstallPath\Scripts\Disable-Antimalwarescanning.ps1

Sie können über die Exchange ECP unter "Schutz" auch Regeln anlegen, um bestimmte Empfänger von der Filterung auszuschließen. Eine Quarantäne gibt es aber weiterhin nicht.

Exchange 2013 Antispam

Auch die schon mit Exchange 2010/2007 vorhandenen "Antispam Agents" sind in Exchange 2013 weiter vorhanden und werden anscheinend bei der Installation mit aktiviert, wenn Sie den Malware-Scanner aktivieren. Und es dauert nicht lange und dann ist ihr Hubtransport "Degraded" 

[PS] C:\>Get-HealthReport msx2013 | ? alertvalue -ne healthy
 
Server              State               HealthSet           AlertValue          LastTransitionTime  MonitorCount
------              -----               ---------           ----------          ------------------  ------------
msx2013             Online              FrontendTransport   Degraded            7/3/2013 9:55:24 PM 11
msx2013             NotApplicable       MailboxTransport    Degraded            7/3/2013 9:08:38 PM 57
msx2013             NotApplicable       MSExchangeCertif... Disabled            1/1/0001 1:00:00 AM 2

Kurz darauf bin ich auf folgenden Eventlog-Eintrag gestoßen:

Log Name:      Application
Source:        MSExchangeFrontEndTransport
Date:          7/3/2013 9:49:28 PM
Event ID:      1022
Task Category: SmtpReceive
Level:         Warning
Keywords:      Classic User:          N/A
Computer:      msx2013.netatwork.de
Description:
Anti-spam agents are enabled, but the list of internal SMTP servers is empty. 
If there are any MTAs between this server and the Internet, populate this list 
by using the Set-TransportConfig cmdlet in the Exchange Management Shell.

Nun ja da ich keinen Exchange Spamfilter nutze, sondern das vorgelagertes NoSpamProxy--Gateway den Schrott viel besser abhalten kann, wurden die Agenten natürlich schnellstens deaktiviert

# Abschalten der AntiSpam Transport Agenten
C:\Program Files\Microsoft\Exchange Server\V15\Scripts\uninstall-AntispamAgents.ps1

Und wenige Sekunden später war dann wieder Ruhe und alles "Healthy".

Weitere Links