Exchange Y2K22 Bug
Mit dem Jahreswechsel 2021/2022 hat sich der in Exchange 2016/2019 eingebaute Malware-Scanner anscheinend an einer Versionsnummer verschluckt. Das ist nun kein Sicherheitsloch wie der Hafnium Exploit oder Exchange Fail Jan 2019 - CVE-2018-8581, aber Mails, die in einer Warteschlange gehalten und nicht zugestellt werden, können Festplatten volllaufen lassen und letztlich andere Business-Prozesse verzögern. Da hilft es auch wenig, wenn der Fehler an einem Feiertag (Neujahr) ist und der 2. Jan auf einen Sonntag fällt.
Diese Seite als Video erklärt
https://youtu.be/piKuMAxHtCE
(Stand 3. Jan 2022)
Bin ich betroffen?
Der beste Indikator: Ihre Kunden oder Mitarbeiter beschweren sich, dass keine Mails zugestellt werden. Aber auch wenn es noch scheinbar funktioniert, sollten sie nachschauen.
Folgende Voraussetzungen müssen nach meiner Analyse zutreffen.
- Exchange 2016 oder Exchange 2019 müssen
Mails routen
Exchange 2013 und Exchange Online sind nicht betroffen, wenn Sie nicht hinter Exchange 2016/2019-Servern versteckt sind (Hybrid Routing). - Malware Agent muss aktiviert wird
Sie müssen bei der Installation oder danach die Exchange Malware Transport Agenten aktiviert haben. - Malware Patternfile-Version ist größer 2112319999
Das erste Patternfile im Jahr 2022 hat die Versionsnummer 2201010001 und führt zu dem Fehler. Wer noch drunter ist, sollte beim nächsten Update automatisch die Version 2112330001 oder höher bekommen und hat kein Problem
Interessanterweise scheint es Server zu geben, die wider Erwartung immer noch Mails routen. Sie sollten dennoch die Korrekturen vornehmen oder zumindest kontrollieren.
Sie sollten umgehend handeln, wenn sie keine
Mails verlieren wollen.
Ohne Korrektur bleiben die Mails in
der "Submission-Queue" hängen und werden nicht zugestellt.
Exchange löscht per Default nach 2 Tagen nicht zugestellte Nachrichten!
Besondere Herausforderung: Wie informieren
sie ihre Kunden über ein Mail Problem, wenn die vielleicht
keine Mails mehr empfangen können?
-> Bitte folgt der MSXFAQ per
RSS-Feed
über
oder auf Twitter (https://twitter.com/msxfaq),
um zukünftig informiert zu sein.
Offizieller Fix
Am 02.01.2022 05:45MEZ (1. Jan 2022 10:45 PST) hat Microsoft ihren Blog-Artikel auf https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447 aktualisiert und mit einem Link auf ein PowerShell Skript ergänzt, welches den Malware-Scanner "zurücksetzt" und die aktuellsten Patterns und Scan-Engine herunterlädt. Die Schritte sind einfach, wenn ihr Exchange Server Internetzugriff hat.
Aktion | Erledigt |
---|---|
Patch-Script von Microsoft ladenHerunterladen des PowerShell Skripts von
https://aka.ms/ResetScanEngineVersion |
|
Admin PowerShell auf Exchange startenMelden Sie sich auf jedem Exchange Server an und starten Sie einer PowerShell als Administrator. |
|
Server MaintenanceAuch wenn Microsoft dies nicht explizit beschreibt, sollten sie ihre internen Prozesse zur "geplanten Wartung ausführen. Dies gilt insbesondere bei DAGs oder "selbst heilenden Systemen". Es gibt Systeme, die gestoppte Dienste ansonsten automatisch neu starten. |
|
Ausführen von ".\Reset-ScanEngineVersion.ps1"Das Skript stoppt und startet FIPS und
Transport-Dienste aber die Anwender sollten
davon nichts merken |
|
NacharbeitenAuch wenn Microsoft dies nicht gesondert beschreibt, sollten Sie danach kontrollieren, dass die Dienste laufen bzw. zur Sicherheit noch einmal neu gestartet werden. # Option1 Restart-Service fms -Force # Option2 Stop-Service MSExchangeTransport Stop-Service fms Start-Service fms Start-Service MSExchangeTransport Beim Ausführen von ".\Enable-AntimalwareScanning.ps1" wird ein Neustart der Dienste auch angemahnt aber vergisst den FMS-Dienst. |
|
Rückbau des temporären WorkaroundWenn Sie vorher einen Workaround umgesetzt haben, um das Mailrouting ohne Malware-Scan zu erlauben, dann sollten Sie dies wieder rückgängig machen |
|
MonitoringKontrollieren Sie das Eventlog, die Message Queues und das Messagetracking auf "hängende" Mails". Die Queues sollten wieder im normalen Zustand sein und Mails geroutet werden. |
|
NachbereitungMittlerweile sind 48h seit dem 1.1.2022 vergangen und wenn ihr Exchange Server noch "Default" konfiguriert ist, dann löscht er nicht zugestellte Mails nach 48h. Sie können versuchen, diese aus einem Backup der "queue.dat" aufwändig zu restaurieren. Aber sie können auch aus dem Messagetracking relativ einfach ermitteln, welche Mails von welchem Absender, Empfänger und Betreff gelöscht wurden und die Absender informieren. Meist reicht dies auch schon aus. |
Damit sollte ihr Exchange Server nun wieder sauber "scannen" und Nachrichten abarbeiten.
Achtung:
Das funktioniert nur, wenn ihr Exchange Server die Updates
aus dem Internet holen kann. Ansonsten müssen Sie die
Schritte auf jedem Server selbst durchführen bzw. die
Patterns verteilen.
Ich gehe davon aus, dass Microsoft diesen "Fehler" zum Anlass nimmt, ganz viele Codes dahingehend zu untersuchen, ob Sie auch damit Probleme haben oder den Fehler besser abfangen und in einem der nächsten CUs dann eine verbesserte Version installiert wird.
Zeitlicher Ablauf
Microsoft hat "relativ" schnell reagiert aber leider gibt es keinen Automatismus durch den EEMS - Exchange Emergency Mitigation Service.
Zeitpunkt (MEZ) | Aktivität |
---|---|
01.01.2022_00:00 |
Mit dem ersten Defender Pattern-Update im Jahr 2022 kommt die Versionsnummer "2201010001". Leider scheint ein Code diese nummer in einen "int32" zu konvertieren, um z.B.: zu vergleichen, ob die Version neuer ist also die vorhandene Version Das bricht aber mit einem Fehler ab, da ein [int32] maximal den Wert 2.147.483.647 annehmen kann. Mails werden zwar noch angenommen aber nicht mehr geroutet oder zugestellt, sondern füllen langsam die Warteschlange auf. Erste Meldungen im Internet erscheinen. |
01.01.2022_12:33 |
Die ersten Monitoring-Instanzen bei Net at Work Kunden schlagen Alarm, dass Queues anwachsen. Als Gegenmaßnahme wird der Bypass bei den Kunden aktiviert, die einen vorgeschalteten Virenscanner haben. Get-Transportservice | Set-MalwareFilteringServer -BypassFiltering:$true |
01.01.2022_15:50 |
Nach ersten Analysen und Prüfungen in meinen Testumgebungen ist klar: Das Problem ist weitreichend und ich addiere einen ersten Hinweis direkt auf der Homepage der MSXFAQ. Auch weitere Webseiten thematisieren das Problem.
|
01.01.2022_20:38 |
Es dauert schon etwas, die verschiedenen Versionen und Umgebungen zu prüfen, mögliche alternative Lösungsvorschläge zu analysieren und das Risiko abzuschätzen. Aber am Abend des1. Jan 202 geht diese ausführlichere Seite der MSXFAQ online. Erstmals auch mit dem Hinweis auf das Datenverlustrisiko nach 2 Tagen Inaktivität. |
01.01.2022_20:39 |
Die erste offizielle Meldung (01.01.2022 11:39 PST) in Form eines Blog-Artikels von Microsoft wird veröffentlicht:
Microsoft rät zur ersten Abhilfe hier die Abschaltung des Mailware Scanners. |
02.01.2022_05:45 |
Microsoft hat ihren Blog-Artikel (https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447) am 1/1/22 @10:45pm PST aktualisiert Durch ein "Zurücksetzen" des Malwarescanners kann der Administrator das Problem beseitigen. Es gibt ein
PowerShell-Script, welches alle Aktionen alleine
macht. Bitte in einer normalen administrativen PowerShell auf dem Exchange Server starten. Der Download der neuen "Scanengines" ist ca. 180 Megabyte groß und kann einige Minuten dauern.
Vergessen Sie danach nicht einen eventuell vorher temporär deaktivierten Malware-Scanner wieder zu aktivieren. |
Offen |
Ich vermute, dass das manuelle Update auch den fehlerhaften Code beseitigt. Allerdings habe ich noch keine Information, ob das nicht auch durch das reguläre Updates funktionieren würde. Wenn nicht, haben wir die kommende Woche ein hohes Supportaufkommen und vermutlich von Exchange nach 2 Tagen gelöschte Mails. Ich lasse mal einen Server "ohne" Patch um zu sehen, ob er sich selbst fängt. |
Die Thematik mit solchen "Datums-Problemen" ist übrigens nicht neu. Die "Endlichkeit" von Zahlen hat die IT schon in der Vergangenheit beschäftigt und wird auch 2038 das nächste mal sicher für Unsicherheit sorgen.
- Jahr 2000 Problem
https://de.wikipedia.org/wiki/Jahr-2000-Problem
- Jahr 2038 Problem
https://de.wikipedia.org/wiki/Jahr-2038-Problem
Dann erreichen nämlich die Anzahl der Sekunden seit 1.1.1970 den magischen Wert 2.147.483.647 und springen auf -2.147.483.648.
Bis dahin können sie aber den fehlerhaften "Malware TransportAgent" temporär deaktivieren.
Achtung: Wenn Sie ansonsten keinen Malwarefilter zwischen Exchange und Internet oder auf dem Clients haben, erhöhen Sie ihr Risiko, einen Virus nicht zu entdecken.
# Option1: Agent deaktivieren. Er bleibt aber installiert und kann schnell wieder aktiviert werden. Get-TransportAgent "Malware Agent" | Disable-TransportAgent Restart-service msexchangetransport #Option2: Filterung auf allen Transportdiensten deaktivieren. Hier ist kein Neustart des Transport Diensts erforderlich Get-Transportservice | Set-MalwareFilteringServer -BypassFiltering:$true #Option3: Agent komplett deinstallieren. Sicher die radikalste Methode, wenn Sie eh eine andere Lösung nutzen. Disable-AntiMalwareScanning.ps1
Alle drei Optionen deaktivieren den "Attachment Scan" und umgehen damit FIPS. Das bedeutet nicht, dass die Fehlermeldungen im Eventlog weg sind aber das Mailrouting funktioniert wieder, wenn gleich dann der Microsoft Malware-Scanner nicht mehr aktiv ist.
Da die meisten Firmen aber sowieso Scanner auf den Endgeräten haben und meist einen besseren Spam/Malwarefilter davor betreiben, ist das Risiko für einige Zeit vertretbar.
Betroffene Server
Aktuell ist die Liste noch sehr unvollständig und ich kann nur die Feedbacks meiner eigenen Kunden, Server und Lesern sammeln.
Exchange Version | Windows Version | Betroffen | Fix |
---|---|---|---|
Exchange 2013 |
Any |
Noch keine Meldungen |
entfällt |
Exchange 2016 CU22 |
Windows 2012R2 |
Betroffen |
1/2/3 |
Exchange 2019 |
Windows 2019 |
Es gibt Meldungen, dass kein Problem vorliegt aber auch betroffene Server. |
1/2/3 |
Exchange Online |
Entfällt |
Sie sind nicht betroffen, wenn Sie eingehende und ausgehende Mails über Exchange Online direkt senden. Wenn ihr MX-Record aber noch auf den On-Premises-Server verweist oder sie ausgehende Mails per Hybrid Centralized Mail Transport versenden. dann müssen Sie auf dem lokalen Server aktiv werden | Nein |
Die Aussagekraft ist aber sehr beschränkt, denn es kann sein, dass Server noch kein Update bekommen haben oder schon das neueste Update haben, welches den Fehler korrigieren sollte.
Nächster Ablauf
Wenn Sie sich die Versionsnummern genau anschauen, dann sehen Sie, was Microsoft eigentlich gemacht hat:
Versionsnummern alt |
Versionsnummern Neu |
---|---|
2112310005 2112310006 2201010001 2201010002 |
2112310005 2112310006 2112330001 2112330002 |
Sie haben einfach die Stelle mit dem Tag von 31 nicht auf 01 gesetzt sondern weiterlaufen lassen. der 1 Jan 2022 ist also nicht 220101 sondern 211233. Ich weiß nun nicht, wie genau Microsoft zukünftig die Pattern durchnummeriert, aber wenn die letzten 4 Stellen weiterhin jeden Tag von 0001 bis maximal 9999 hochzählen und nun die bisherige "Tagesstelle" bis 99 läuft und dann der Monat von 12 auf 13 wechselt, dann hätten wir 214748-211231=3517 Tage oder 9,6 Jahre Zeit.
Update:
Am 4. Jan hatte ich die Version 2112330013 und nicht
2112340001. Insofern zählt Microsoft nun wohl einfach hoch.
Damit reicht der Nummernpool dann für 2147483647 -
2112330013 = 35153634 Updates. Auch wenn mehrere Updates/Tag
kommen würden, dann haben wir viele Jahrhunderte Ruhe.
Damit ist aber auch klar, warum man ein "RESET" machen muss, denn der Update-Prozess wird die Version 2112330001 nicht als Update der bislang schon heruntergeladenen Versionen 2201010001 und folgende ansehen. Der "Download" der neuer Versionen funktionierte ja schon die ganze Zeit. Das dürfte aber auch bedeuten, dass Exchange Server mit einer Patternversion unter 2112330001 das Problem nicht haben. Das gilt für Umgebungen, bei denen das Update anderweitig verteilt werden oder über den Jahreswechsel ausgesetzt wurde.
Workaround
Der Workaround ist nicht mehr erforderlich, seit dem es von Microsoft einen offiziellen Fix gibt. Ich lasse ihn aber hier stehen, denn er ist sehr schnell umgesetzt, auch wenn der Virenschutz temporär abgeschwächt ist.
Aktuell gibt es erste Gerüchte über ein Updates aber wenn es aber soweit ist, dann könnte manuelles Update des Servers erforderlich sind. Dazu benötigen Sie eine administrative PowerShell.
# Erforderliches Snapin laden Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell # Aktuelle Version ausgeben Get-EngineUpdateInformation # Update-Script von Exchange starten & $env:ExchangeInstallPath\Scripts\Update-MalwareFilteringServer.ps1 -Identity ($env:computername) # Das Skript startet den Update-Prozess aber wartet nicht auf dessen Abschluss # Ergebnisse vergleichen Get-EngineUpdateInformation
Mein letzter Stand (1. Jan 2022 20:09) war folgender und hat noch KEINE Lösung gebracht.
Engine : Microsoft LastChecked : 01.01.2022 08:02:44 +01:00 LastUpdated : 01.01.2022 05:57:14 +01:00 EngineVersion : 1.1.18800.4 SignatureVersion : 1.355.1247.0 SignatureDateTime : 01.01.2022 12:29:06 +01:00 UpdateVersion : 2201010009 UpdateStatus : UpdateAttemptNoUpdate
- Manually update scan engines in Exchange Server
https://docs.microsoft.com/en-us/exchange/troubleshoot/setup/manually-update-scan-engines
Auswirkung
Die betroffenen Exchange Server nehmen weiterhin Mails entgegen aber Sie werden nicht mehr weiter geroutet oder lokal zugestellt. Die Auswirkungen sind:
- Die "Submission" Warteschlange wird
immer größer
Das können Sie sehr schnell mit "Get-Queue" feststellen. Der "Message Count" ist ja wohl
[PS] C:\>get-queue Identity DeliveryType Status MessageCount Velocity RiskLevel OutboundIPPool NextHopDomain -------- ------------ ------ ------------ -------- --------- -------------- ------------- EX16\Submission Undefined Ready 723 -7 Normal 0 Submission
- Messagetracking
Auch in Blick auf die EventIDs im Messagetracking der letzten Stunden zeigt, dass es hier keine "SEND" Einträge und stattdessen viele "DEFER" und "AGENTINFO"-Meldungen gibt. Letzere sind die "Verzögerungsmeldungen" an den internen Absender, die aber natürlich auch nicht zugestellt werden.
[PS] C:\>Get-MessageTrackingLog -start (get-date).addhours(-1) | group eventid -NoElement WARNING: There are more results available than are currently displayed. To view them, increase the value of the ResultSize parameter. Count Name ----- ---- 34 RECEIVE 467 AGENTINFO 467 DEFER 26 DSN 3 NOTIFYMAPI 3 SUBMIT [PS] C:\>Get-MessageTrackingLog -start (get-date).addhours(-1) -EventId DEFER 01.01.2022 18:18:35 DEFER AGENT prtg.service@msxfaq... {naw.prtg.service@... PRTG Roundtrip... 01.01.2022 18:18:42 DEFER AGENT MicrosoftExchange3... {prtg.service@msxf... Verzögerte Zustell...
- Im Extremfall kann die Partition mit
der Queue.dat voll laufen
Exchange beendet die Dienste. Die meisten Mailserver versuchen Nachrichten weitere 24h zuzustellen aber dies ist nicht garantiert. - Mitarbeiter bekommen keine Mai
Das wird aber dann wohl eher am Montag den 3. Jan wieder interessant, wenn die Anwender als "lebendige Systemmonitore" dann beim Administrator Alarm schlagen - Automatische Prozesse können Mails einliefern aber Sie werden nicht weiter
geroutet
Das ist dann ein Problem, wenn eingehende Mails von Exchange wegen "Überalterung" verworfen werden und ein NDR an den Absender geht, der aber ebenfalls nicht geroutet wird. - Mailverlust
Normalerweise löscht Exchange eine nicht zugestellte Nachricht nach 48 Stunden. Ich weiß nicht, ob das auch hier in der Submission Queue der Fall ist. Wenn dies aber zutrifft, dann ist Gefahr im Verzug, denn am Montag morgen den 3.1.2022 sind die ersten Mails schon älter als 48h.
Use the Exchange Management Shell to configure the message expiration timeout interval on Mailbox servers or Edge Transport servers
https://docs.microsoft.com/en-us/exchange/mail-flow/queues/configure-message-intervals?view=exchserver-2019#use-the-exchange-management-shell-to-configure-the-message-expiration-timeout-interval-on-mailbox-servers-or-edge-transport-servers
# Optional kann man die Expiration Time mal hochsetzen
Get-Transportservice | Set-Transportservice -MessageExpirationTimeOut 5.00:00:00 - Es ist KEIN Sicherheitsloch
Es gibt keine Anzeigen, dass dieses Problem irgendwie ihre Umgebung direkt gefährdet. Allerdings möchten Sie ja die Funktion schnell wieder bereitstellen. Dazu können Sie den internen Scanner deaktivieren. Dann könnte Malware durchschlüpfen, wenn Sie keine weiteren Produkte davor (Mailrelay) und danach (Auf dem Client) einsetzen.
Sie können also nun darauf warten, ob Microsoft ein Update schnell bereitstellt oder sie temporär.
Analyse
Seit Exchange 2013 (E2013:MalwareScan/Ex2016 Antimalware und AntiSpam) liefert Microsoft kostenfrei einen Malware-Scanner mit, der auf dem Exchange Transport nach Viren und anderem Schadcode sucht. Es ist im wesentlichen ein Transport Agent, der bei der Installation oder nachträglich aktiviert werden kann und jede geroutete Mails mit den klassischen Defender-Patterns untersucht. Wie üblich kommen die Pattern-Dateien regelmäßig als Update und haben natürlich eine Versionsnummer, so dass die Scanengine erkennen kann, ob eine neue Version vorliegt. Ein Versionsvergleich ist üblicherweise ein Größer/Kleiner-Vergleich von Zahlen. Wenn die Pattern-Dateien aber ein String sind, muss dieser erst in eine Zahl konvertiert werden. Das ist auch der erste Anhaltspunkt im Eventlog. Im System Eventlog habe ich das auf meinem Server das erste mal gegen 02:11 gefunden. Anhand der Zeitzone wäre das dann 01:11 UTC und nicht direkt nach Mitternacht.
Log Name: System Source: Service Control Manager Date: 01.01.2022 02:11:25 Event ID: 7034 Task Category: None Level: Error Keywords: Classic User: N/A Computer: NAWEX16.netatwork.de Description: The Microsoft Filtering Management Service service terminated unexpectedly. It has done this 2 time(s).
Die Meldung im System-Eventlog wiederholt sich, da der Service ja wieder gestartet und abgebrochen wird. Im Applicationseventlog finde ich dann die FIPS-Meldungen
Die Fehlermeldung im Eventlog mit der EventID 5300 ist schon ein guter Hinweis:
Event Id 5300 The FIP-FS „Microsoft“ Scan Engine failed to load. PID: 21744, Error Code: 0x80004005. Error Description: Can’t convert „2201010001“ to long.
Die Scan-Engine versucht den String "2201010001" in einen "long"-Wert zu konvertieren. In einer 64bit oder 32bit PowerShell ist das aber kein Problem:
PS C:\> [long]"2201010001" 2201010001
Aber das gilt nicht für C++. Hier ist die Obergrenze leider 2147483647
Quelle: Limits on Integer Constants
https://docs.microsoft.com/en-us/cpp/cpp/integer-limits?view=msvc-170#limits-on-integer-constants
Hätte Microsoft damals einfach "Unsigned int" genutzt, wäre diese Umrechnung vermutlich nie aufgefallen.
Defender Updates
Natürlich wollte ich nun sehen, wie es um die Forefont Patterns aussieht. Über die normale PowerShell kann ich den aktuellen Stand anzeigen lassen.
PS C:\> Add-PSSnapin Microsoft.Forefront.Filtering.Management.PowerShell PS C:\> Get-EngineUpdateInformation Engine : Microsoft LastChecked : 01.01.2022 06:31:50 +01:00 LastUpdated : 01.01.2022 05:57:14 +01:00 EngineVersion : 1.1.18800.4 SignatureVersion : 1.355.1247.0 SignatureDateTime : 01.01.2022 12:29:06 +01:00 UpdateVersion : 2201010009 UpdateStatus : UpdateAttemptFailed
Hier ist zwar der letzte Update fehlgeschlagen, aber das kann ja mal passieren. Aber die Version ist hier (1.Jan 2022 18:58) schon auf 2201010009 angestiegen. Entsprechend finde ich auch den Fehler im Eventlog.
Log Name: Application Source: Microsoft-Filtering-FIPFS Date: 01.01.2022 18:54:41 Event ID: 5300 Task Category: None Level: Error Keywords: User: LOCAL SERVICE Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 18104, Error Code: 0x80004005. Error Description: Can't convert "2201010009" to long.
Die eigentlichen Updates der Pattern-Dateien laufen also weiter und auch in der Update-Konfiguration steht alles sauber drin:
C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\UpdateInformation.xml
<?xml version="1.0" encoding="utf-16"?> <UpdateInformation xmlns="http://schemas.microsoft.com/forefront/2010/1/fs-updateinformation"> <Properties> <ProductGUID>{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}</ProductGUID> </Properties> <Engines> <EngineStatus id="Microsoft"> <ID>1</ID> <Name>Microsoft</Name> <LastChecked>2022-01-01T18:01:55Z</LastChecked> <LastUpdated>2022-01-01T16:57:14Z</LastUpdated> <LastDefinitionsUpdate>2022-01-01T11:29:06Z</LastDefinitionsUpdate> <EngineVersion>1.1.18800.4</EngineVersion> <SignatureVersion>1.355.1247.0</SignatureVersion> <UpdateVersion>2201010009</UpdateVersion> <EngineUpdateStatus>UpdateAttemptNoUpdate</EngineUpdateStatus> <LastUpdateStreamId>{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}</LastUpdateStreamId> <AdditionalEngineInformation></AdditionalEngineInformation> </EngineStatus> </Engines> </UpdateInformation>
Genau genommen könnte ich de Update-Prozess anhalten und ein Rollback auf eine frühere Version der Pattern-Datei machen. Dann wäre mein Schutz nicht aktuell, aber ich hätte zumindest eine Erkennung aller bis 31. Dez 2021 bekannten Schadprogramme. Für kleine Firmen, die tatsächlich nur auf den eingebauten Virenscanner in Exchange bauen, wäre das wohl besser.
Leider habe ich auf meinem Server nur die aktuellste Version gefunden.:
Quelle: C:\Program Files\Microsoft\Exchange
Server\V15\FIP-FS\Data\Engines\amd64\Microsoft\Package
Hier gibt es zumindest bei mir keine "vorherige Version".
Monitoring
Diese "Störung" ist wieder ein gutes Beispiel, wie wichtig die Überwachung von Servers ist. In dem Fall ist in den ersten zwei Tagen erst einmal kein Datenverlust zu befürchten aber durchaus eine Störung, die ein einzelnen Fällen auch schnell sehr teuer werden kann. Denken Sie an eingehende Bestellungen, den Versand von Frachtbriefen an eine Spedition oder auch nur ein elektronisches Bahn/Flug-Ticket oder eine Covid19-Testbestätigung. Auch wenn die Wichtigkeit von Mails oft kleingeredet wird um vielleicht Kosten zu sparen, so darf Mail natürlich "nie" ausfallen und muss "ganz schnell" sein. Solche Aussagen kennt sicher jeder Administrator, wenn es um die nächsten Budgetgespräche und Festlegung von SLAs geht.
Der "günstige" Ansatz ist natürlich ein Monitoring ihrer Umgebung, die sowohl Kennzahlen auswertet aber auch End2End-Tests durchführt. Können Sie alle drei Punkte mit ruhigem Gewissen als erledigt kennzeichnen?
Punkt | Beschreibung | Erledigt |
---|---|---|
Eventlog |
Der Y2K22-Fehler hat sich sehr schnell und wiederkehrend im Eventlog als Fehlermeldung gezeigt. Das macht es einfach, diesen ansonsten "nie gesehenen" Fehler als "neu" zu melden. |
|
Queues |
Die Exchange Warteschlangen können Sie recht einfach per PowerShell und eingeschränkt auch per Performance Counter überwachen. Über so eine Überwachung können Sie zum einen den "Füllstand" von Warteschlangen sehen aber auch die Zunahme/Abnahme und die "Velocity". Diese Werte sind sehr hilfreich um diverse Situationen sehr früh zu erkennen, z.B.:
Bei dem Y2K22-Bug wäre so sehr schnell aufgefallen, dass die "Submission Queue" laufend zunimmt, d.h. es wäre sicher der "absolute" als auch der "differenzielle" Warn-Wert erreicht worden. |
|
End2End-Mail |
Queues und Eventlog sagen aber wenige aus, wenn wie an einem Feiertag eher wenig Mails übertragen werden oder die Fehlermeldungen erst mal auf "später" zurückgestellt werden. Daher ist es immer ratsam auch ein paar echte Applikationstests zu machen, z.B. indem Sie alle 10 Minuten eine Testnachricht an die verschiedenen Gegenstellen senden und die Rückantwort (Zugestellt-Quittung als auch NDR-Quittung) auswerten. Bleibt die Meldung aus, dann klemmt es irgendwo.
|
|
Exchange Health |
Exchange hat auch ein "Selbst Monitoring". Allerdings hat beidem Fehler kein Report angeschlagen. Der Status meines Servers ist "Healthy" und der letzte Wechsel ist schon fast 18 Monate her. [PS] C:\>Get-HealthReport nawex16 -HealthSet fips Server State HealthSet AlertValue LastTransitionTime MonitorCount ------ ----- --------- ---------- ------------------ ------------ ex16 NotApplicable FIPS Healthy 11.03.2020 22:11:47 6 Auch wenn hier der Report nicht geholfen hat, sollten Sie die Funktionen von Exchange nutzen, die "Gesundheit" auszuwerten. |
|
FIPS |
Zuletzt sollten Sie auch noch prüfen, wie aktuell ihr Patternfile ist. Es könnte ja sein, dass die Updates gar nicht mehr funktionieren. Am einfachsten geht das mit einer administrativen PowerShell. Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell Get-EngineUpdateInformation Die Rückgabe liefert nicht nur die Version sondern auch den letzten Updatestatus und das Datum.
Hinweis: Die laufende Nummer des "UpdateStatus" folgt nicht mehr dem Schema YYMMDDxxxx. |
Diese Möglichkeiten der Überwachung sollen nun aber nicht davon ablenken, dass das Problem bei Microsoft zu suchen ist und von dort auch eine Lösung kommen muss. Aber Monitoring hilft sehr schnell den Start, die Existenz und das Ausmaß einer Störung zu erfassen und auch die erfolgreiche Entstörung schnell erkennen zu können.
Auf der anderen Seite haben die Firmen, die mangels 24x7-Operating schon Exchange Online mit direkten Ein/Ausgang über die Cloud (Kein Hybrid Centralized Mail Transport) natürlich dieses Problem nicht.
Beifang
Auf der Seite Alte OWA-Dateien löschen habe ich ja schon einmal beschrieben, dass man ältere Versionen von Dateien auch entfernen kann. Bei der Suche nach den Engine-Updates bin ich auf folgendes Verzeichnis gestoßen.
C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS\Data\ProgramLogArchive
Es hat ca. 1 GB alte ETL-Traces, die anscheinend auch niemand wegräumt.
Schauen Sie vielleicht einmal, ob sich bei ihnen hier auch große Datenmengen angesammelt haben.
Nach dem Spiel ist vor dem Spiel
Nachdem wir nun das "Jahr 2000"-Problem und nun auch das Januar 2022-Problem überstanden haben, sollten wir uns nicht so früh freuen. Wenn nichts passiert, dann erlebe ich auch noch die nächste Schaltschwelle, die uns Programmierer in den Weg gelegt haben.
"Many network protocols and filesystems store timestamps in
the original UNIX format: a signed 32-bit integer
representing the number of seconds since the beginning of
1970. This format will expire in 2038. Other protocols store
timestamps as unsigned 32-bit integers representing the
number of seconds since 1900; this format will expire in
2036."
Quelle:
https://cr.yp.to/libtai/tai64.html
WireGuard als relativ junges Protokoll nutzt daher schon TAI64
Weitere Links
- EEMS - Exchange Emergency Mitigation Service
- Exchange Fail Jan 2019 - CVE-2018-8581
- Hafnium Exploit
- Ex2016 Antimalware und AntiSpam
- E2013:MalwareScan
- End2EnEnd2End-SMTPFlow
- Hybrid Centralized Mail Transport
- EEMS - Exchange Emergency Mitigation Service
-
Email Stuck in Transport Queues
https://techcommunity.microsoft.com/t5/ge-team-blog/email-stuck-in-transport-queues/ba-p/3049447 -
Limits on Integer Constants
https://docs.microsoft.com/en-us/cpp/cpp/integer-limits?view=msvc-170#limits-on-integer-constants - Antispam and antimalware protection in
Exchange 2016
https://technet.microsoft.com/en-us/library/jj150481(v=exchg.160).aspx - The FIP-FS Scan Process failed initialization. Error: 0x80010105 AND
Faulting application name: scanningprocess.exe
https://docs.microsoft.com/en-us/answers/questions/302892/the-fip-fs-scan-process-failed-initialization-erro.html - Use the Exchange Management Shell to configure the message expiration
timeout interval on Mailbox servers or Edge Transport servers
https://docs.microsoft.com/en-us/exchange/mail-flow/queues/configure-message-intervals?view=exchserver-2019#use-the-exchange-management-shell-to-configure-the-message-expiration-timeout-interval-on-mailbox-servers-or-edge-transport-servers - Disable or bypass anti-malware scanning
https://docs.microsoft.com/en-us/exchange/disable-or-bypass-anti-malware-scanning-exchange-2013-help - Manually update scan engines in Exchange Server
https://docs.microsoft.com/en-us/exchange/troubleshoot/setup/manually-update-scan-engines - Jahr-2022-Problem
https://de.wikipedia.org/wiki/Jahr-2022-Problem
Sogar Exchange hat es schon in Wikipedia "geschafft". Die MSXFAQ ist da noch nicht drin. - Exchange Server Warteschlange wächst –
FIPFS-Service Fehler
https://exusg.de/2022/01/01/exchange-server-warteschlange-waechst-fipfs-service-fehler/ - Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can’t
Convert “2201010001” to long (1.1.2022)
https://www.borncity.com/blog/2022/01/01/exchange-fip-fs-scan-engine-failed-to-load-cant-convert-2201010001-to-long-1-1-2022/ - Y2K22-Bug stoppt Exchange-Mailzustellung: Antimalware-Engine stolpert über
2022
https://www.heise.de/news/Y2K22-Bug-stoppt-Exchange-Mailzustellung-Antimalware-Engine-stolpert-ueber-2022-6315605.html - Exchange mail flow breaks (Disable AntiMalwareScanning)
https://www.alitajran.com/exchange-mail-flow-breaks/#h-latest-updates - The FIP-FS Scan Process failed
initialisation. Mail is queued on Exchange
servers.
https://jaapwesselius.com/2022/01/01/the-fip-fs-scan-process-failed-initialisation-mail-is-queued-on-exchange-servers/amp/ - Message Deferred by categorizer
https://social.technet.microsoft.com/Forums/exchange/en-US/136b0705-6326-42c0-bff0-a6412fc84fb2/message-deferred-by-categorizer?forum=exchangesvrsecuremessaging - Y2K22-Bug legt Stromanschluss lahm –
Kärntner ohne Warmwasser
https://www.heise.de/news/Y2K22-Bug-legt-Stromanschluss-lahm-Kaerntner-ohne-Warmwasser-6317000.html
Auch Schaltuhren hatten mit 22 Probleme. Aber das hat nichts mit Exchange zu tun