Ex2016 Antimalware und AntiSpam

Im September 2015 ist Exchange 2016 veröffentlicht worden und auch Exchange 2016 enthält genauso wie Exchange 2013 (E2013:MalwareScan) schon einen Schadcode-Scanner im Produkt.

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

Hinweis:
Microsoft hat die Funktion "Smartscreen für Exchange" zum 1. Nov 2016 abgekündigt. Es gibt seit dem Tag keinen neuen Patternupdates zur Erkennung von Spam beim SMTP-Empfang. Das hat am Ende eh nicht mehr gut funktioniert und die meisten Kunden werden sowieso einen eigenen Spamfilter wie z.B. NoSpamProxy davor installieren oder Cloud-Lösungen wie Exchange Online Protection nutzen.
Quelle: Deprecating support for SmartScreen in Outlook and Exchange
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Deprecating-support-for-SmartScreen-in-Outlook-and-Exchange/ba-p/605332

Diese Abkündigung betrifft aber NICHT die SmartScreen-Funktion in Outlook, Edge oder Windows und es betrifft auch nicht die Antivirus-Funktion von Exchange 2016. Der in Exchange eingebaute Virenscanner auf der Transportebene ist weiterhin funktionsfähig und es werden auch weiter Patternupdates verteilt.

Lassen Sie sich aber nicht von den Angaben verwirren, dass der Spamschutz per Default nur auf dem Edge aktiv ist und auf dem Mailbox-Server aktiviert werden kann. Der Antimalware-Agent, der natürlich auch Viren blocken soll, ist per Default nur auf den Mailbox-Servern aktiv. Dazu sollten Sie aber wissen, dass Exchange 2016 nur noch Mailbox-Server kennt, die aber alle vier Services (CAS, HT, MB, UM) betreiben können. Die frühere Unterscheidung in Rollen (Siehe Rollen und E2013:Rollen) ist mit Exchange 2016 entfallen.

Der Malware-Scanner beschränkt sich auf die Transport-Rolle, d.h. Mails, die sich "bewegen", werden geprüft aber nicht Mails, die im Postfach lagern oder durch einen Client abgelegt werden. Aber wie schon bei Exchange 2013 ist dies für die meisten Firmen ausreichend. Ein Virenscanner auf dem Client, auf dem ein Virus aktiviert werden könnte, ist ja sowieso Pflicht und sobald sich der Virus per Mail weiter verteilen will, wird er auf der Transportebene doch wieder eingefangen.

Installation

Schon bei der Installation von Exchange 2016 werden Sie gefragt, ob sie den Schutz abschalten wollen. Per Default ist er auf "No", d.h. er ist "NICHT DEAKTIVIERT". Lassen Sie sich also nicht durch die doppelte Verneinung irre machen:

Sonst sehen sie von dem Schutzprogramm nicht mehr viel. Es ist einfach aktiv aber nicht weiter konfigurierbar.

Funktionstest

Ein Schutz eines Mailsystems besteht natürlich aus erst mehr als nur ein Virenscanner. Wobei Microsoft diesen Begriff gar nicht benutzt, sondern umfassender von "Malware" spricht. Es gibt ja durchaus auch unerwünschte Anlagen, die aber kein klassischer Virus mit Schadfunktion ist, sondern vielleicht nur Werbebanner einblendet, Trackingdaten verrät etc.

Da Microsoft mit Exchange 2013 und höher die AVAPI-Schnittstelle auf dem Postfachspeicher deaktiviert hat, bleibt nur noch das Scannen auf dem Transport.

Wenn Sie bei der Installation nichts abweichend gemacht haben, dann reicht es folgende Eingaben per "TELNET <fqdn des Mailservers> 25" einfach in ihre Postfach zu senden:

Einige Proxy Server (z.B. ZScaler) suchen in HTML-Dateien nach "Schadocde" und finden dann den EICAR und die MSXFAQ würde ggfls. geblockt.


Daher müssen Sie im Beispiel den Teilstring "MSXFAQ" entfernen, damit das zuverlässig Sample erkannt wird

HELO sender.de
MAIL FROM: <sender@exampled.com>
RCPT TO: <ihre.mailadresse@ihredomain>
DATA
SUBJECT: Eicar test

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-MSXFAQSTANDARD-ANTIVIRUS-TEST-FILE!$H+H*

.

Auch ohne aktuelle Pattern-Dateien sollte Exchange diese Mail erkennen und behandeln: Am einfachsten die Suche im Messagetracking:

[PS] C:\>Get-MessageTrackingLog -Start (get-date).addhours(-1) -MessageSubject "Eicar test"

EventId  Source   Sender                            Recipients                        MessageSubject
-------  ------   ------                            ----------                        --------------
RECEIVE  SMTP     sender@exampled.com               {ihre.mailadresse@ihredomain}     Eicar test
AGENT... AGENT    sender@exampled.com               {ihre.mailadresse@ihredomain}     Eicar test
FAIL     AGENT    sender@exampled.com               {ihre.mailadresse@ihredomain}     Eicar test

Der erste Event ist noch ein RECEIVE SMTP. aber schon die beiden nächsten Events berichten den Schadcode und sind hier verkürzt:

SourceContext           : AgentDelete
Source                  : AGENT
EventId                 : AGENTINFO
TotalBytes              : 1721
RecipientCount          : 1
MessageSubject          : Eicar test
Sender                  : sender@exampled.com
ReturnPath              : sender@exampled.com
Directionality          : Incoming
MessageLatencyType      : None
EventData               : {[AMA, SUM|v=1|action=b|error=|atch=0], [AMA,
                          EV|engine=M|v=1|sig=1.225.1983.0|name=DOS/EICAR_Test_File|file=Message Body], [CompCost,
                          |AMA=0], [DeliveryPriority, Normal], [AccountForest, netatwork.de]}
TransportTrafficType    : Email

SourceContext           : Malware Agent
Source                  : AGENT
EventId                 : FAIL
RecipientStatus         : {[{LRT=};{LED=550 4.3.2 QUEUE.TransportAgent; message deleted by transport
                          agent};{FQDN=};{IP=}]}
TotalBytes              : 1721
MessageSubject          : Eicar test
Sender                  : sender@exampled.com
ReturnPath              : sender@exampled.com
Directionality          : Incoming
MessageInfo             : 2016-07-21T07:39:36.531Z;SRV=EX01.netatwork.de:TOTAL-FE=31.016|SMR=0.029(SMRPI=0.018(SMRPI
                          -FrontendProxyAgent=0.018))|SMS=0.016;SRV=EX01.netatwork.de:TOTAL-HUB=2.203|SMR=1.013(SMRD
                          E=0.912|SMRC=0.100(SMRCL=0.100))|CAT-PEN=1.193(CATOS=1.191(CATSM-INC=1.190(CATSM-Malware
                          Agent-INC=1.190)))
EventData               : {[E2ELatency, 2.250], [DeliveryPriority, Normal], [AccountForest, netatwork.de]}
TransportTrafficType    : Email

Damit ist zumindest belegt, dass die Scanfunktion aktiv ist und die Nachrichten auch den Weg laufen. Eine Benachrichtigung bekommt der interne Empfänger nicht. Über die Policy können die maximal den "Sender" informieren und ggfls. einen Admin: (Gekürzt)

[PS] C:\>Get-MalwareFilterPolicy | fl

ustomAlertText                        : Malwarefilter hat eine Anlage mit Schadcode erkannt und gelöscht.
InternalSenderAdminAddress             : malware@example.com
ExternalSenderAdminAddress             : malware@example.com
Action                                 : DeleteAttachmentAndUseCustomAlertText
IsDefault                              : True
CustomNotifications                    : False
EnableInternalSenderNotifications      : True
EnableExternalSenderNotifications      : False
EnableInternalSenderAdminNotifications : True
EnableExternalSenderAdminNotifications : True
FileTypes                              : {ace, ani, app, docm, exe, jar, reg, scr, vbe, vbs}
Name                                   : Default
DistinguishedName                      : CN=Default,CN=Malware Filter,CN=Transport Settings,CN=Net at Work
                                         GmbH,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de
Identity                               : Default

Genau genommen will das aber auch niemand. Eine Information an den internen Absender ist noch ok aber nie nach extern. Aber bei einer eingehenden Virenflut helfen diese Mails auch nicht weiter. Eine Überwachung sollte sich also eher anders darstellen. Bei Viren gibt es nun mal wenig "False Positive" und selbst wenn, dann wurde die Mail nicht zugestellt. Das kann beim Brief (ohne Einschreiben) ja auch passieren.

Wer mag, kann aber über das Message Tracking Log gezielt nach den "Agent Delete" suchen und den Mitarbeitern einen "Filter-Report" generieren und zusenden.

Wenn ihnen der Versand per Telnet zu kompliziert ist, können Sie natürlich auch das Programm auf Eicarsender verwenden.

Richtlinien und Scope

Die Meldungen und der Umgang mit enthaltenem Schadcode können Sie über die Richtlinien konfigurieren. Das geht sehr einfach per ECP aber natürlich auch per Powershell. Hier gibt es immer eine "Default Policy", die für alle Mails angewendet wird, die durch den Transport-Service laufen. Sie können aber noch weitere Richtlinien anlegen. Die Steuerung, auf welche Elemente die entsprechende Richtlinie angewendet wird, ist aber nicht an die Mailbox gebunden und wird auch nicht über eine Transportregel ausgewählt sondern an der Richtlinie selbst gibt es eine Möglichkeit der Filterung nach bestimmten Bedingungen.

Dieses Auswahl haben sie nicht bei der "Default Richtlinie".

Funktionsweise

Auf der Seite "Antispam protection in Exchange 2016" (https://technet.microsoft.com/en-us/library/jj218660.aspx) hat Microsoft etwas mehr beschrieben, wie der Filter in Exchange 2016 funktioniert. Im wesentlichen wird zwischen der Funktion auf dem Edge-Server und der Funktion auf einem internen Transport-Service unterschieden.

  • Auf der Mailbox Rolle
    • Absenderfilterung auf der Domain
    • Absenderfilterung mit SenderID
    • Content Filter (SCL)
    • Protokoll Verhalten
  • Edge Rolle
    • IP-Adressen als Block/Allow-Liste
    • Empfängerfilter, d.h. ungültige Empfänger werden abgelehnt
    • Attachment Filter (Name, Extension, MIME-Typ)
    • Protokoll Analyse (SRL, Sender Reputation Level)
      u.a. Test des HELO Namens mit DNS, Reverse Lookup, OpenProxy Test

Viel tiefer will ich hier gar nicht einsteigen. Sie können die Funktion nur auf dem Server ein oder einschalten

# Einschalten
& $env:ExchangeInstallPath\Scripts\Enable-Antimalwarescanning.ps1

# Abschalten
& $env:ExchangeInstallPath\Scripts\Disable-Antimalwarescanning.ps1

Beachten Sie, dass sowohl das Ein- als auch Abschalten einen Neustart des Transportdiensts erfordert.

Technisch ist auch die Exchange 2016 Malware Funktion auf zwei Teile aufgespittet. Es gibt:

  • Transport Agent
    Der Transport Agent wird pro Server aktiviert und fängt die Mails quasi ab. Damit der Agent aber "klein" bleibt und nicht durch die Analyse selbst vielleicht zu einer Schwachstelle wird, analysiert er nicht selbst.
[PS] C:\>Get-TransportAgent
 
Identity                                           Enabled         Priority
--------                                           -------         --------
Transport Rule Agent                               True            1
DLP Policy Agent                                   True            2
Malware Agent                                      True            3
Text Messaging Routing Agent                       True            4
Text Messaging Delivery Agent                      True            5
System Probe Drop Smtp Agent                       True            6
System Probe Drop Routing Agent                    True            7


[PS] C:\Program Files\Microsoft\Exchange Server\V15\Scripts>Get-TransportAgent "malware agent" | fl
 
RunspaceId            : f4854a43-45d9-4bde-8f5b-bd74759ee8cd
Enabled               : True
Priority              : 3
TransportAgentFactory : Microsoft.Exchange.Transport.Agent.Malware.MalwareAgentFactory
AssemblyPath          : C:\Program Files\Microsoft\Exchange
                        Server\V15\TransportRoles\agents\Antimalware\Microsoft.Exchange.Transport.Agent.Malware.dll
Identity              : Malware Agent
IsValid               : True
ObjectState           : New
 

Verwaltung per Powershell

Anders als Forefront für Exchange 2010 gibt es für die Exchange 2016 Malware-Tools keine GUI mehr und auch keine zentrale Verwaltung für mehrere Server. Eine Steuerung erfolgt quasi nur per Powershell. Allerdings ist dies keine Exchange Powershell sondern einfach eine Windows Powershell, in die man ein weiteres Snapin einlädt:

# Load Forefront PowerShell

Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell

Beachten Sie, dass Sie die Powershell "als Administrator" starten müssen, da ansonsten Assemblies nicht geladen werden können.

Add-PSSnapin : Cannot load Windows PowerShell snap-in Microsoft.Forefront.Filtering.Management.Powershell because of
  the following error: Could not load file or assembly 'file:///C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Bin\
  Microsoft.Forefront.Filtering.Management.PowerShell.dll' or one of its dependencies. Access is denied.

Über eine weitere Abfrage können sie alle Commandlets dieses Snapins erhalten. Es sind eine gante Menge Befehle, die leider wieder nicht mit einem bekannten Präfix beginnen. Während die meisten anderen Produktgruppen ein <verb>-<prefix><command> nutzen, scheint es sich zum Exchange Team immer noch nicht herumgesprochen zu haben. So sind Konflikte schon fast vorprogrammiert, z.B.: bei „Get-TraceSettings oder Get-ProxySettings.

Get-Command -Module Microsoft.Forefront.Filtering.Management.Powershell
 
CommandType     Name
-----------     ----
Cmdlet          Export-ScanSettings
Cmdlet          Export-SystemSettings
Cmdlet          Get-AntivirusScanSettings
Cmdlet          Get-ClassificationEngineSettings
Cmdlet          Get-ClassificationScanSettings
Cmdlet          Get-ConfigurationValue
Cmdlet          Get-EngineUpdateCommonSettings
Cmdlet          Get-EngineUpdateInformation
Cmdlet          Get-EngineUpdateSpecificSettings
Cmdlet          Get-GeneralScanSettings
Cmdlet          Get-LoggingSettings
Cmdlet          Get-PolicyViolationAction
Cmdlet          Get-PolicyViolationThresholdAndAction
Cmdlet          Get-ProxySettings
Cmdlet          Get-SecurityPolicyViolationThresholdAndAction
Cmdlet          Get-ServerSettings
Cmdlet          Get-TextExtractionScanSettings
Cmdlet          Get-TraceSettings
Cmdlet          Get-ValidEngines
Cmdlet          Import-ScanSettings
Cmdlet          Import-SystemSettings
Cmdlet          Set-AntivirusScanSettings
Cmdlet          Set-ClassificationEngineSettings
Cmdlet          Set-ClassificationScanSettings
Cmdlet          Set-ConfigurationValue
Cmdlet          Set-EngineUpdateCommonSettings
Cmdlet          Set-EngineUpdateSpecificSettings
Cmdlet          Set-GeneralScanSettings
Cmdlet          Set-LoggingSettings
Cmdlet          Set-PolicyViolationAction
Cmdlet          Set-PolicyViolationThresholdAndAction
Cmdlet          Set-ProxySettings
Cmdlet          Set-SecurityPolicyViolationThresholdAndAction
Cmdlet          Set-ServerSettings
Cmdlet          Set-TextExtractionScanSettings
Cmdlet          Set-TraceSettings
Cmdlet          Start-Diagnostics
Cmdlet          Start-EngineUpdate

Ich hätte mir wirklich ein "*-FIPFS*" gewünscht.

Aktuelle Patternfiles

Wer mit Wireshark oder anderen Programmen mal nachschaut, findet recht einfach die Update-URLs. Sie werden nämlich unverschlüsselt per HTTP statt HTTPS übertragen. Sicher sind es keine Geheimnisse, die da übertragen werden. Da bleibt zu hoffen, dass die Updates selbst zumindest passend digital signiert werden. Nicht das da jemand so eine ungesicherte Verbindung nutzt, um unwirksame Patterns einzubinden.

Folgende URLs habe ich an dem Tag gefunden. Die letzte URL ist natürlich nur indirekt mit den Patternfiles zu verbinden.

http://forefrontdl.microsoft.com/server/scanengineupdate/metadata/UniversalManifest.cab
http://forefrontdl.microsoft.com/server/scanengineupdate/metadata/201107070001/EngineInfo.cab
http://forefrontdl.microsoft.com/server/scanengineupdate/amd64/Microsoft/Package/manifest.%7B8B2xx5B1CB%7D.cab
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab?93db011f539dd889

Interessanterweise kommen diese Updates NICHT über Windows Update. Das ist natürlich sinnvoll, wenn die Patterns sehr zeitnah ausgeliefert werden. Allerdings muss der Administrator sich nun Gedanken machen, wie die Update auf den Exchange Server kommen. Die wenigsten Exchange Server werden direkt per HTTP in das Internet kommen. In den meisten Fällen ist dazu zumindest ein HTTP-Proxy-Server erforderlich.

Hier nutzt der Exchange 2016 Malware Scanner aber weder die Einstellungen des Betriebssystem (WinHTTP) noch die des Internet Explorers noch die Einstellungen von Exchange. Über die Powershell kann die Konfiguration eines Proxy erfolgen.

Add-PsSnapin Microsoft.Forefront.Filtering.Management.Powershell
Set-ProxySettings `
   -Enabled $true `
   -Server proxy.msxfaq.de `
   -Port 8080

Wenn kein Proxy eintragen ist, sieht man im NetMon die DNS-Abfragen an den Hostnamen "forefrontdl.microsoft.com" vom Typ "Host Addr". Anscheinend nutzt der Update-Prozesse weder WPAD noch die WinHTTP oder IE-Einstellungen, sondern erwartet eine eigene Konfiguration. Ich habe mir auf dem Proxy den Zugang auf die Source-IP oder die Ziel-URLs ohne weitere Authentifizierung freischalten lassen. Ob FMS eine Authentifizierung unterstützt, habe ich noch nicht weiter analysieren müssen.

Die Updates können manuell aktualisiert werden:

[PS] C:\>Start-EngineUpdate -Verbose
VERBOSE: [08:24:47.367 GMT] Start-EngineUpdate : Beginning processing
VERBOSE: [08:24:47.961 GMT] Start-EngineUpdate : Initiating engine Update für the following engines: Microsoft
VERBOSE: [08:24:48.149 GMT] Start-EngineUpdate : Ending processing

Auch im Scripts-Verzeichnis gibt es ein Powershell-Skript, welches aber letztlich per Remote Powershell auf dem Zielserver das Update anstartet:

C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Update-MalwareFilteringServer.ps1 -identity EX2016.msxfaq.net

In der Powershell gibt es aber auch ein Commandlet um den Status zu ermitteln.

PS C:\> Get-EngineUpdateInformation

Engine            : Microsoft
LastChecked       : 12/01/2015 08:24:15 PM +01:00
LastUpdated       :
EngineVersion     : 1.1.8800.0
SignatureVersion  : 1.137.1393.0
SignatureDateTime :
UpdateVersion     : 1210090002
UpdateStatus      : UpdateAttemptFailed

Das System versucht auch alleine immer wieder ein Update durchzuführen. Im Eventlog sind der Start, Fehler und der Erfolg zu sehen. Bei mir hat der Prozess alle 4 Minuten einen Download versucht

Start steht im Eventlog
Log Name:      Application
Source:        Microsoft-Filtering-FIPFS
Date:          11/25/2015 9:59:59 AM
Event ID:      6030
Task Category: None
Level:         Information
Keywords: User:          NETWORK SERVICE
Computer:      EX2016.msxfaq.net
Description:
MS Filtering Engine Update process is attempting to download a scan engine Update.
Scan Engine: Microsoft
Update Path: http://forefrontdl.microsoft.com/server/scanengineupdate.

Fehler beim Update ist ein Eventlog Fehler

Log Name:      Application
Source:        Microsoft-Filtering-FIPFS
Date:          11/25/2015 10:03:53 AM
Event ID:      6027
Task Category: None
Level:         Error
Keywords: User:          NETWORK SERVICE
Computer:      EX2016.msxfaq.net
Description:
MS Filtering Engine Update process was unsuccessful in contacting the primary Update Path. 
  Update Path: http://forefrontdl.microsoft.com/server/scanengineupdate

Den aktuellen Status können Sie auch per PowerShell anfragen 

[PS] C:\>Get-EngineUpdateInformation
 
Engine            : Microsoft
LastChecked       : 11/25/2015 09:23:11 AM +01:00
LastUpdated       :
EngineVersion     : 1.1.8800.0
SignatureVersion  : 1.137.1393.0
SignatureDateTime :
UpdateVersion     : 1210090002
UpdateStatus      : UpdateAttemptFailed

Logging und Tracing

Kein Produkt ist perfekt und damit stellt sich die Frage, wie Fehler beim eingebauten Virenschutz analysiert werden können. Hier gibt es zwei interessante Commandlets.

[PS] C:\>Get-LoggingSettings
 
CustomerExperienceImprovementProgramEnabled : False
 
[PS] C:\>Get-TraceSettings
 
FlushFrequency     : 0
MaxLogSize         : 1024
TraceFileDirectory : C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data
Level              : Information
Flags              : {Default}

Änderungen werden anscheinend in einer Konfigurationsdatei abgelegt.

C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\Configuration.xml

Sehr viele Dinge sind hier hinterlegt, z.B. auch eine Weiterverteilung der Updates zu anderen Servern, Attachment-Klassen,
Aber auch hier würde ich auf die Powershell verweisen. So liefern Commandlets die Daten und auch ein „SET-* Commandlet ist vorhanden.

[PS] C:\>Get-EngineUpdateCommonSettings
 
 
DefaultUpdateFrequency           : 01:00:00
PrimaryUpdatePath                : http://forefrontdl.microsoft.com/server/scanengineupdate
SecondaryUpdatePath              :
EnableUpdates                    : True
UpdateFrequency                  : 00:30:00
RedistributionServer             : False
RedistributionServerMode         : Coresident
RedistributionPackageCount       : 2
EngineDownloadTimeout            : 150
GetHttpFileTimeout               : 0
ScanEngineLoadTimeout            : 150
EngineLockTimeout                : 300
DisableScanEngineTimeout         : 600
MinimumDownloadProgressThreshold : 4096
[PS] C:\>Get-ServerSettings
 
ScanTimeout                     : 900
ServerTimeout                   : 150
ShutdownTimeout                 : 90
AutoConfigure                   : True
StandbyScanProcesses            : 1
ConcurrentScanProcesses         : 1
ScannerConcurrencyLevel         : 4
MaxScanRetries                  : 3
QueueMaxSize                    : 0
ScanProcessMaxScanRequestsCount : 864000
ScanProcessMemoryMax            : 2048

Auch im Eventlog können Sie Meldungen sehen bzw den Level hoch schrauben. Das ist dann aber wieder eine Exchange Powershell

[PS] C:\>Get-EventLogLevel "MSExchange Antimalware"
 
Identity                                                                                                     EventLevel
--------                                                                                                     ----------
MSExchange Antimalware\General                                                                               Lowest
MSExchange Antimalware\Init                                                                                  Lowest
MSExchange Antimalware\ScanResults                                                                           Lowest
MSExchange Antimalware\ScanError                                                                             Lowest


[PS] C:\>Get-EventLogLevel "MSExchange Antimalware" | Set-EventLogLevel -level high

Allerdings habe ich nicht immer entsprechende Meldungen im Eventlog gesehen. Das kann aber auch meiner Test-VM geschuldet sein. Auf jeden Fall gibt es im Eventlog eine entsprechende Quelle:

Ein Eventlogeintrag könne wie folgt aussehen:

Log Name:      Application
Source:        MSExchange Antimalware
Date:          12/20/2015 12:35:12 PM
Event ID:      3810
Task Category: ScanResults
Level:         Information
Keywords:      Classic User:          N/A
Computer:      E2016.msxfaq.de
Description:
The anti-malware agent has detected malware. MessageId: xxx@yyy.zz Message sent: 12/20/2015 11:05:08 AM 
  From: xx@yyyy.zzz Size: 1926 KB Engine: Microsoft : Antimalware Engine (1.137.1393.0)
  Malware name: DOS/EICAR_Test_File Action taken: DeleteMessage

FPSDiag

Bei der Analyse der auf den Server installierten Komponenten bin ich auf ein Programm FPSDIAG gestoßen. Auch wenn die in Exchange 2016 eingebauten Virenfilter nicht mehr den Namen "Forefront" tragen, sind die Wurzeln natürlich nicht zu leugnen.

C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Bin>.\FPSDiag.exe
 
Forefront Diagnostic Utility
 
Starting collection of diagnostic information. This can take a while.
 
Forefront configuration files.............................success
Forefront installation logs...............................success
Forefront program log.....................................success
Archived Forefront program logs...........................success
Forefront trace message formats...........................success
Forefront modules versions................................success
Forefront registry settings...............................success
Forefront performance counters............................success
Performance object names..................................success
Process information.......................................success
Windows Error Reporting (WER) files.......................success
Windows Event Logs........................................success
System information........................................success
Exchange setup logs.......................................success
Forefront SPVSAPI installation log........................success
  Compressing AppEvent.evt
  Compressing Configuration.xml
  Compressing ConfigurationServer.xml
  Compressing Diagnostics.log
  Compressing ExchangeSetup.log
  Compressing ExchangeSetup.msilog
  Compressing ModuleVersions.csv
  Compressing PerformanceCounters.txt
  Compressing PerformanceObjects.txt
  Compressing ProcessList.txt
  Compressing ProgramLog-20151124130302119.etl
  Compressing ProgramLog.etl
  Compressing RegistrySettings.txt
  Compressing SecEvent.evt
  Compressing SysEvent.evt
  Compressing SystemInformation.txt
  Compressing tmfs.zip
 
Created "C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\Log\EX2016_20151025083055895.ZIP".

Das Gleiche macht übrigens ein “Start-Diagnostics“. Das ist keineswegs ein „Einschalten“ eines Trace, sondern eher ein Sammeln von Konfigurationsdaten für einen Support Case.

Eignung?

Microsoft tut viel daran, um seine Produkte sicher und einfach zu machen. Die Integration einer Schutzfunktion gegen Viren und Schadcode ist eine wichtige Komponente. Allerdings gibt es natürlich schon lange ein gut funktionierendes Eco-System von Drittherstellern mit entsprechenden kommerziellen Produkten für Server und auch Exchange. Das Problem dabei ist natürlich, dass viele Hersteller auch immer wieder unterschiedliche Probleme in das System gebracht haben und letztlich wohl der Microsoft Support sich damit rumschlagen durfte. Zudem scheuen viele Firmen die Kosten für einen vollständigen Schutz, vertrauen auf die Scanner auf den Clients und fahren Exchange ohne eigenen Virenscanner. Speziell im Consumer-Umfeld ist es sicherlich von Vorteil, einen Basisschutz (Windows Defender, Windows Security Essentials etc.) gleich mit einzubauen. Mit Exchange 2016 fällte die AVAPI weg, so dass alle 3rd-Party Produkte als auch Microsoft sich nur noch auf den Transport beschränken. Und hier ist es wichtig, schnell mit aktuellen Patterns zu arbeiten.

Es wird sich zeigen, ob Microsoft mit seinem Ansatz hier mit den Drittherstellern gleichziehen kann. Microsoft propagiert ja FOPE 0 Forefront Online Protection für Exchange, d.h. dass die erste Verteidigung durch einen Scanner in der Cloud erfolgt und der interne Scanner dann nur noch die Schädlinge erwischen muss, die für den Cloud-Scanner zu "neu" waren.

Ich nutze persönlich auch den Exchange 2016 Scanner aber habe davor natürlich einen NoSpamProxy (https://www.nospamproxy.de/de/produkt/nospamproxy-protection/) als Relay stehen, der sehr gut den Schadcode abhält. Daher hat mein interner Scanner noch nicht einmal zuschlagen müssen. Das deckt sich wohl mit den Erfahrungen bei Microsoft, dass speziell die Postfachscanner mehr "Kosten" durch CPU und RAM-Belastung und sonstige Probleme verursachen als sie durch erkannte Schädlinge einsparen. Verschlüsselte (SMIME/PGP) oder mit RMS geschützte Mails kann nur ein ClientScanner erreichen und wie Sie auf Crypto Trojaner lesen, sind sich Anwender ja auch nicht zu schade ein umbenanntes und mit Kennwort gepacktes Archiv zu öffnen und den Schadcode darin auszuführen.
Aus meiner Sicht bietet Microsoft mit dem eingebauten Software einen Basisschutz aber nicht mehr. Drittprodukte als Ersatz oder  vorgeschaltete Lösung sind ratsam, zumal das Management und die Updates durchaus etwas einfacher sein könnten. Auf einem kleinen Server, der per NAT direkt ins Internet kommt, kann das Update funktionieren.

Wenn Sie nun einen Exchange 2016 Transport-Services in ihre Umgebung einbauen, um auch Exchange 2010 Server zu schützen, dann sollten Sie bedenken, dass Sie zwar eingehende und ausgehende Mails über diese neuen Transport-Services routen und damit scannen können. Es ist aber kein Schutz für interne Nachrichten, die heute von Exchange 2010 Postfach zu Exchange 2010 Postfach nicht über die Exchange 2106 Transport-Services gehen.

Weitere Links