[English]Weltweit haben (On-Premises) Exchange Server seit dem 1. Januar ein Year 2022 Problem, weil Mails wegen eines "Datumsfehlers" nicht mehr transportiert werden. Inzwischen hat Microsoft diesen Sachverhalt in einem separaten Blog-Beitrag bestätigt. Die Entwickler arbeiten an einem Fix, der zeitnah ausgerollt werden soll. Ergänzung: Microsoft hat vorläufige Fixes vorgestellt.
Anzeige
Das Exchange Year 2022 Problem
Das Jahr 2022 fing für Administratoren von Exchange Servern (On-Premises) mit einem fetten Year 2022 Problem an, weil Mails wegen eines "Datumsfehlers" nicht mehr transportiert werden können. Die Microsoft Scan Engine FIP-FS kann nicht geladen werden – und in den Protokollen findet sich das Ereignis:
The FIP-FS "Microsoft" Scan Engine failed to load. PID: 39268, Error Code: 0x80004005. Error Description: Can't convert "2201010003" to long. / Event ID 5300
Hintergrund ist mutmaßlich, dass ein in einem signed long Integer codierter Datumswert mit 2022 einen Überlauf erzeugt, der dann den obigen Fehlerabbruch bedingt. Der Workaround besteht darin, den Malware-Scan bzw. die Malware-Filterung temporär auszusetzen. Ich hatte ja hier im Blog den Beitrag Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can't Convert "2201010001" to long (1.1.2022) mit zusätzlichen Erläuterungen dazu veröffentlicht.
Mein deutschsprachiger Blog-Beitrag und das englischsprachige Pendant war wohl weltweit der Erste, der das Problem samt Workaround zusammen fasste. Die Beiträge wurden binnen 12 Stunden gut 29.000 Mal abgerufen – und inzwischen habe ich bei heise das Thema auch kurz untergebracht – wobei dort mutmaßlich keine Betroffenen mitlesen – den Schluss ziehe ich, wenn ich die Kommentare zum Artikel verfolge.
Auf Twitter gab es auch die Diskussion, dass der 2021 neu eingeführte Microsoft Exchange Emergency Mitigation Service (siehe Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service) eigentlich eine automatische Korrektur durch Microsoft ermöglichen sollte.
Anzeige
Die Bereitstellung einer solchen Lösung benötigt aber Zeit, wie nachfolgend durch Microsoft erläutert wird.
Microsoft bestätigt den Bug
Blog-Leser DW weist in diesem Kommentar (danke dafür) auf den inzwischen von Microsoft veröffentlichten Techcommunity-Beitrag Email Stuck in Transport Queues hin. Dort heißt es, dass sich Microsoft sich eines Problems bewusst sei, das dazu führt, dass Nachrichten in den Transportwarteschlangen von Exchange Server 2016 und Exchange Server 2019 stecken bleiben. Dass dies meinen Informationen nach auch Exchange Sever 2013 betrifft, wird nicht erwähnt.
Das Problem bezieht sich auf einen Fehler bei der Datumsüberprüfung zum Jahreswechsel und nicht auf einen Fehler der AV-Engine selbst. Es handelt sich nicht um ein Problem mit dem Malware-Scanning oder der Malware-Engine, und es ist kein sicherheitsrelevantes Problem. Die Versionsprüfung der Signaturdatei führt zu einem Absturz der Malware-Engine, was dazu führt, dass die Nachrichten in den Transportwarteschlangen stecken bleiben. Also das, was ich vor einigen Stunden im oben verlinkten Blog-Beitrag beschrieben habe.
Microsoft arbeitet an der Behebung dieses Problems. Man will voraussichtlich im Laufe des Tages (beim Schreiben des Texts war dies noch nicht der Fall) Details zur Lösung dieses Problems veröffentlichen.
In der Zwischenzeit schlägt Microsoft vor, Malware-Scans von Nachrichten außerhalb des lokalen Exchange-Servers (z. B. durch Weiterleitung von E-Mails über Exchange Online oder durch Verwendung einer Nachrichtenhygienelösung eines Drittanbieters) durchzuführen, oder die Malware-Scans auf betroffenen Exchange-Servern zu deaktivieren und die Transportwarteschlangen zu löschen. Microsoft schreibt aber, dass man eine dieser Umgehungslösungen nur dann verwenden sollte, wenn Administratoren einen anderen Malwarescanner für E-Mails als die Engine in Exchange Server einsetzen. Weitere Informationen zum Deaktivieren oder Umgehen von Malware-Scans finden Sie in den folgenden Artikeln:
- Antimalware protection in Exchange Server | Microsoft Docs
- Procedures for antimalware protection in Exchange Server | Microsoft Docs
Zur oben angesprochenen Microsoft Exchange Emergency Mitigation Service-Problematik lese ich aus dem Microsoft-Beitrag folgendes: Deren Techniker arbeiteten zwar an einer Lösung, die ein Eingreifen des Kunden überflüssig machen würde. Aber man hat festgestellt, dass jede Änderung, die kein Eingreifen des Kunden erfordert, mehrere Tage für die Entwicklung und Bereitstellung benötigen würde.
Zur Zeit heißt es daher: Wir arbeiten derzeit an einer weiteren Aktualisierung, die sich in der abschließenden Testphase befindet. Das Update erfordert zwar ein Eingreifen des Kunden, aber es wird die schnellste Lösung bieten. Also heißt es abwarten, wann diese Lösung kommt.
Ein Fix von Microsoft
Ergänzung: Der Microsoft Techcommunity-Beitrag Email Stuck in Transport Queues wurde aktualisiert, es gibt ein Script und eine Anleitung zur Vorgehensweise. Details kann man im Beitrag nachlesen. Ich habe den Blog-Beitrag Temporärer Fix für Exchange Year 2022 Problem FIP-FS Scan Engine failed to load (1. Jan. 2022) mit einigen Informationen erstellt.
Ähnliche Artikel:
Exchange-Server 0-day-Exploits werden aktiv ausgenutzt, patchen!
Wichtige Hinweise Microsofts und des BSI zum Exchange-Server Sicherheitsupdate (März 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Microsoft MSERT hilft bei Exchange-Server-Scans
Exchange-Hack: Neue Patches und neue Erkenntnisse
Anatomie des ProxyLogon Hafinum-Exchange Server Hacks
Exchange-Hack: Neue Opfer, neue Patches, neue Angriffe
Neues zur ProxyLogon-Hafnium-Exchange-Problematik (12.3.2021)
Gab es beim Exchange-Massenhack ein Leck bei Microsoft?
ProxyLogon-Hack: Repository für betroffene Exchange-Administratoren
Microsoft Exchange (On-Premises) one-click Mitigation Tool (EOMT) freigegeben
Sicherheitsupdate für Exchange Server 2013 Service Pack 1 – Neue CUs für Exchange 2019 und 2016 (16.3.2021)
Microsoft Defender schließt automatisch CVE-2021-26855 auf Exchange Server
Exchange ProxyLogon News: Patch-Stand, neue Ransomware etc. (25.3.2021)
Neues zum Exchange-Hack: Wie schaut es mit dem Risiko aus? (1. April 2021)
Vorwarnung: 0-Day-Schwachstellen, ist das nächste Exchange-Drama im Anrollen?
Sicherheitsupdates für Exchange Server (Juli 2021)
Kumulative Exchange Updates Juni 2021 veröffentlicht
Exchange Server Security Update KB5001779 (13. April 2021)
Exchange-Schwachstellen: Droht Hafnium II?
Exchange Server: Neues zu den ProxyShell-Schwachstellen
Angriffe auf Exchange Server per ProxyShell-Schwachstelle rollen an (13.8.2021)
Angriffswelle, fast 2.000 Exchange-Server über ProxyShell gehackt
ProxyShell, ProxyLogon und Microsofts Exchange-Doku für Ausnahmen vom Virenschutz
Exchange und ProxyShell: Neues von Microsoft und Sicherheitsspezialisten
Tianfu Cup 2021: Exchange 2019 und iPhone gehackt
Babuk-Gang nutzt ProxyShell-Schwachstelle in Exchange für Ransomware-Angriffe
Exchange Server November 2021 Sicherheitsupdates schließen RCE-Schwachstelle CVE-2021-423
BSI/CERT-Warnung: Kompromittierte Exchange-Server werden für E-Mail-Angriffe missbraucht (Nov. 2021)
Warnung (CERT-Bund, USA, GB) vor Angriffen auf Exchange und Fortinet
ProxyNoShell: Mandiant warnt vor neuen Angriffsmethoden auf Exchange-Server (Nov. 2021)
Warnung: ProxyShell, Squirrelwaffle und ein PoC-Exploit, patcht endlich eure Exchange-Server
CERT-Bund-Warnung: 30% der deutschen Exchange Server mit offenem OWA angreifbar
Beispiele für Viren-Mails nach Übernahme eines Exchange-Servers
Anzeige
Inzwischen hat MS eine Lösung in ihrem Artikel
Update-Skript von MS: https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447
Unfassbar wie unterwürfig sich manche Menschen dann auch noch immer bei Microsoft bedanken natürlich stets ohne zu vergessen missionarisch auf Exchange Online hinzuweisen…..
Leider auch solche, von denen ich immer sehr viel gehalten habe, wie die beiden sehr kompetenten "Exchange Frank's"….sehr bedauerlich…..;-(
>>> Leider auch solche, von denen ich immer sehr viel gehalten habe, wie die beiden sehr kompetenten "Exchange Frank's"….sehr bedauerlich…..;-(
Ist doch normal! Die beiden Frank's oder wenn man auch andere Produkte außer Exchange nimmt die beiden Marc's und andere haben ihre Kompetenz bei Microsoft Produkten und damit verdienen sie ihr Geld. Die haben im Zweifel alle einen irren guten Kontakt zu Microsoft. Würden die also anfangen gegen MS zu reden, wären sie mal mindestens die guten Kontakte los und dann müssten sie Know How mit anderen Produkten aufbauen und dann auch noch den Kunden erklären warum doch jetzt bitte zu wechseln ist.
Dafür ist die Zeit bei den Kunden maximal seit 2021 reif, wenn überhaupt. Es gibt sicher immer noch genug Entscheider die immer noch nicht kapieren was für eine Katastrophe diese Abhängigkeit von US Herstellern tatsächlich bedeutet…
Und mal ganz ehrlich – die beinahe nahtlose Integration so vieler Produkte birgt zwar erhebliche Gefahren, wenn es aber läuft hat das auch schon ganz gewaltige Vorteile.
Da ist mir kürzlich auf FB ein Post um die Ohren geflogen, weil sich jemand angepasst fühlte, weil ich über die Fahrenheit Geschichte bei Neuigkeiten und Informationen berichtete. Nun ja, habe das laufen lassen und ignoriert. Jeder muss sich halt eine eigene Meinung bilden.
"Da ist mir kürzlich auf FB ein Post um die Ohren geflogen…"
Das ist ein riesiges Problem in der heutigen Zeit! Man traut sich wirklich nicht mehr, seine ehrliche Meinung zu sagen, man könnte ja eine 'Lawine' los treten, im schlimmsten Fall eine Klage an an den Hals bekommen… traurig! Freie Meinugsäußerung existiert bei uns tatsächlich nur auf dem Papier!
Habt ihr auch das Problem das der Download der EngineUpdates (179 MB) bei ca 92% hängen bleibt und dann das Script sich nach einem Timeout beendet.
mal abwarten. gibt schon erste stimmen die meinen, dass der fix nicht funktioniert. wir sind gerade am einspielen und testen.
Danke, lasse es mich wissen, wie es ausgegangen ist. Plane für Montag noch was, denn da kommen bestimmt einige Leute auf den Trichter, dass der Exchange kaputt ist. Schon cool, wie MS das gedeichselt hat. Da warnt das BSI über Monate vor ungepatchten Systemen. Und nun sind die futsch, da muss jetzt jemand drüber schauen.
Aber heute isch ja Sonntag …
"Danke, lasse es mich wissen, wie es ausgegangen ist."
Test-Server hat einwandfrei funktioniert, Patch des Production-Servers steht noch an… :)
Fix funktioniert also – so weit ich das erkennen konnte, besteht der Fix einzig und allein in einem Reset der Antimalware-Module und Signaturen. Werden also gelöscht und neu heruntergeladen. Anstelle einen 'echten' Fix zu liefern, hat man sich anscheinend darauf beschränkt, die Signaturen jetzt weiterhin mit 2112 beginnen zu lassen, also so: 2112330001 und zählt bei den Tagen einfach weiter, der 02.01. entspricht also der 33.
Wenn man die von Microsoft vorgeschlagenen Schritte für die manuelle Lösung durchführt, zeigt Get-EngineUpdateInformation zunächst noch UpdateVersion 2201010004 und UpdateStatus UpdateInProgress. Hier darf man nicht nervös werden. Bei mir hat der Download eine knappe halbe Stunde gedauert. Kontrollieren kann man mit Get-BitsTransfer -AllUsers | Where-Object { $_.DisplayName -like "Forefront_FPS*" } | fl. Da werden die Werte für BytesTotal (179030563) und BytesTransferred ausgegeben.
Auch weißt Microsoft leider nicht explizit darauf hin, dass man natürlich den Workaround mit Enable-AntimalwareScanning.ps1 und ggf. weiteren Schritten wieder rückgängig machen muss.
danke für die Ergänzung, das mit dem Rückgängig-machen, wollte ich im Folge-Beitrag am Montag aufgreifen – ging mir eben beim Spaziergang durch den Kopf.
Was sich bei mir bewährt hat, war dass ich nach dem Fix einspielen (Script laufen lassen) den Server erst komplett rebootet habe. Dann erst wieder ein Enable-AntimalwareScanning.ps1 durchgeführt und den Transport-Dienst neu gestartet.
Also immer irgendwie "im Dienst" – selbst beim Spazieren gehen … Kann u. U. gefährlich werden! Spreche aus Erfahrung, da 2010 acht Wochen Klinikaufenthalt und 2017 nochmals acht Wochen. Beides mal nach totalem psychischem Zusammenbruch in der Depression (neumodisch auch Burnout genannt) gelandet, da auch irgendwie immer – zumindest gedanklich – im Dienst gewesen … ;-) Frühdienst, Spätdienst, Wochenend-/Feiertagsdienst, Rufbereitschaft, Not- und Reservedienst auf Abruf bei Bedarf (…) Kann man natürlich nie eins zu eins auf jeden übertragen, aber "aufpassen" ist in diesem Zusammenhang trotzdem nie verkehrt … Deshalb:
Gutes Neues Jahr für Sie und natürlich auch für alle anderen Lesenden und Schreibenden – trotz des never ending MS-Horrors!
Hab heute auch einen netten Spaziergang gemacht, kennen Sie das, Klingenberg am Main, da gehts beinahe spektakulär eine Schlucht hinauf…?
Folgender Satz ist aber bei MS zu lesen:
„If you previously disabled or bypassed antimalware scanning as a mitigation for this issue, we recommend that you re-enable it after performing the steps below."
fix funktioniert nicht. neuer fehler
A FIP-FS Scan process returned error 0x84004003 PID: 9940 Msg: Scanning Process caught exception:
Stream ID:
ScanID: {B6F9C05C-C8E5-400A-9946-704413218158}
(0x84004003) Unknown error 2214608899. Failed to meet engine bias criteria (Available) for filter type (Malware):
Selected engine(s): Microsoft
Available engine(s):
Offline engine(s): ID: {b6f9c05c-c8e5-400a-9946-704413218158}
eventid 2203 quelle fipps
reboot behebt dieses problem
Es genügt auch den "FMS" Dienst neu zu starten, das startet den "MSExchangeTransport" gleich mit.
Bei mir hat es über 50 Server erwischt. Bunt gemischt Exchange Server Standard 2013, 2016 und 2019. Alle mit aktuellen CU und letzten Updates. Bei allen Servern hingen die E-Mails in der Queue.
Habe gestern (1.1.2022) Nacht bei allen den Mailware Agent abgeschaltet (Get-TransportAgent "Malware Agent" | Disable-TransportAgent) und den Dienst msexchangetransport restartet. Wie schon im vorigen Artikel von Günter Born berichtet. Das hat das Problem überall gelöst. Und den Agent lasse ich weiterhin deaktiviert, denn helfen tut der ohnehin nichts. Das ist wie eine USV mit leerer Batterie.
Warum hier Exchange Emergency Mitigation (EM) service nicht greift, bzw. Microsoft nichts ausrollt ist mir unerklärlich. Oder ist dies erneut die Absicht, um alle in die Cloud zu zwingen.
Liebe Grüße Tom
@Tom Carpenter
Warum lässt du den Agent weiterhin aus?
Weil du ein anderes System davor hast und der Malware Scan am Exchange dann „doppelt" ist?
Ich verstehe das so, dass der Exchange Emergency Mitigation (EM) dafür nicht gedacht ist.
Du musstest ja dafür auch das IIS Rewrite Modul installieren.
Daher denke ich, können sie dadurch gewisse Angriffe via IIS z.B. wie bei Hafnium abfangen, aber nicht irgendwelche Engines für andere Dienste tauschen.
Zumindest habe ich das so verstanden…
Hi,
da steht ohnehin überall eine Fortinet mit IPS , Antivirus und SPAM-Schutz davor. Ausserdem ist GEO-Blocking am Port 443 für deutschspachige Länder aktiviert. So findet der Shodan die IP sowieso einmal nicht. Ich denke das ist genug – und es ist nicht Microsoft!
"inzwischen habe ich bei heise das Thema auch kurz untergebracht – wobei dort mutmaßlich keine Betroffenen mitlesen – den Schluss ziehe ich, wenn ich die Kommentare zum Artikel verfolge."
Die wirklich betroffenen schreiben dort nicht mehr, weil sie von den Kommentaren der Linux-Fanboys in den Heise-Kommentaren zu genervt sind. In der realen Welt können sich erwachsene Leute auch nicht ernsthaft unterhalten, wenn ringsherum Kinder lärmen.
Stimmt. Im Heise Forum sind da einige unterwegs. Aber insgesamt findet man die leider auch in fast allen anderen Foren.
Jeder Hersteller hat seine Bugs. Nur bei einigen werden die verleugnet und/oder totgeschwiegen ;)
In Linux ist ein Long 64 Bit breit (LP64),
in Windows aber nur 32 Bit breit, auch auf einem 64-Bit-System (LLP64).
Also ist Linux technisch eben besser, weil dieser Fehler da nicht auftreten kann.
Leute die sich für "erwachsen" halten, sind vielleicht einfach nur betriebsblind oder arrogant.
Kann ich als ehmaliger heise Leser nur zustimmen. Für mich hat sich der Kommentarbereich zu einer Linuxblase entwickelt die einem Windows Anwender abschreckt. Aber auch bei anderen Themen sind Gedanken die nicht dem Mainstream entsprechen unerwünscht.
Scheint wohl nicht der einzige 2022er Fehler zu sein: https://www.reddit.com/r/sysadmin/comments/ru6v5c/sonicwall_y2k22_bug/
Jupp, das ist toll wenn man in seiner sonicwall E-Mail Appliance im log nachkucken will ob das Exchange noch was macht(Maleware agent war aus also waren wir vom exchange problem nicht wirklich betroffen) aber das log der Sonicwall nichts mehr anzeigt weil es das gleiche problem hat :D Wir haben dann mal ein case bei sonicwall aufgemacht :(
(schön das überall die gleichen leute mitlesen :D )
danke für den Link, und ich dachte schon 'Montag gehste in Rente, gibt ja keine Themen mehr ;-)'
Och, keine Sorge, das geht noch die nächsten 15 Jahre so weiter, dann ist es auch mir egal, falls man mich nicht vorher schon aussortiert…
Dann hier auch nochmal:
Fix, bzw. Script ausgeführt, MalwareAgent wieder aktiviert, Server komplett neu gestartet. Läuft bisher. Mails gehen durch und keine Einträge mehr im Eventlog.
Aus welchem Grund ist das Datum bei einem Malwarescan überhaupt relevant?
Den Anhang einer email kann man doch auch völlig losgelöst von anderen Daten analysieren.
Wie verhält sich der Malwarescan, wenn er zwei emails mit dem selben Datum und der selbe Uhrzeit zur Analyse bekommt?
Meint er dann bei der zweiten, er hätte diese bereits gescannt, weil das Datum ja 100 prozentig passt?
Falls nicht, dann gibt es da noch ein anderes Unterscheidungsmerkmal, dass man auch ausschließlich benutzen könnte, also unabhängig vom Datum und dann würde so ein Fehler gar nicht auftreten können.
Haben die Admins den Mitarbeitern auch mitgeteilt, dass die Anhänge jetzt verseucht sein könnten und wie reden sich die Admins heraus, wenn ein Mitarbeiter trotzdem einen verseuchten Anhang öffnet, den die Admins fahrlässigerweise ungefiltert durchließen?
Haben die Admins am Neujahrstag nichts besseres zu tun, als sich um die Bugs von Microsoft zu kümmern? Welche Firma arbeitet denn Feiertags oder Sonntags?
Bisschen übereifrig, was?
Wäre es nicht besser, wenn man jeden Arbeitsausfall aufgrund dieser Bugs Microsoft in Rechnung stellen würde? In jedem Einzelfall klagen und abkassieren.
Microsoft lernt es nur durch Geldfluss, aber nicht durch engagierte Admins, die Workaround um Workaround hervorzaubern, also herumfrickeln.
„Aus welchem Grund ist das Datum bei einem Malwarescan überhaupt relevant?
Den Anhang einer email kann man doch auch völlig losgelöst von anderen Daten analysieren."
Hast du dich überhaupt mit dem Problem beschäftigt oder bist du nur hier um zu motzen?
Wir sind leider auch betroffen und ich habe mir Neujahr was schöneres vorstellen können…
Aber das Linux gelobe und Microsoft Geschimpfe hilft uns hier allen nicht weiter…
Wo liegt denn deiner Meinung nach das Problem, wenn es ein Datumfehler bzw Überlauf aufgrund Datentypfehler ist und der durch Abschalten des Malwarescanners behoben wird?
Wenn man auf das Microsoftbashing hören würde, dann hätte man diese Probleme gar nicht.
Dann wäre man schon vor einigen Jahren aufgewacht und würde so einen gefährlichen Schrott nicht mehr einsetzen.
Als ob man für sowas simples wie emails unbedingt einen Microsoft Exchange Server brauchen würde.
Die prinzipielle Denkweise und Arbeitsweise ist offensichtlich falsch und das erkennt man daran, dass man an Sonntagen und Feiertagen im Müll eines US-Konzerns herumfrickeln muss, damit überhaupt noch eine email ankommt, also im Grund nicht viel mehr als ein Piss-ASCII-Text von hier nach da. lol. Mega lol.
Das ist doch für Normaledenkende ein echter Schenkelklopfer.
Aber zum Aufwachen reicht es bei den Meisten leider immer noch nicht, was Microsoft da in den letzten Jahren verkackt hat.
Wenn man in der weiten Welt unterwegs ist und jeder Tag tausende Euro kostet will man schon per Email zu Hause nachfragen können.
Und wenn man dann einen hirntot konfigurierten Mailserver hat, der meine Email annimmt und erst nach 2 Tagen sagt: "Unzustellbar"
Soweit ich das verstehe, ist nicht das Datum in der Email das Probmem, sondern das Datum in der Malware-Signatur-Datenbank.
"Never change a running system".
Doch dann fing irgend jemand an, das Datum zu ändern und riss dadurch den weltbesten Platzhirschen wo gibt in den Abgrund.
"Don't change anything"
"Just sit there and look how beautiful the colors are"
Das Problem des Definitionsbereichs wird bereits ab Klasse 7 im Matheunterricht besprochen.
Mit den verschiedenen Datentypen wird man ab der ersten Stunde konfrontiert, wenn man selber programmiert.
Die Qualität des Microsoft-Programmcodes ist also darunter anzusiedeln.
Maximal Klasse 6 und keinerlei Programmiererfahrung.
Es handelt sich also um Größenwahnsinnige, die durch reine Blendung zum Weltkonzern aufgestiegen sind.
Das bisschen Code, der noch funktioniert, den hatten sie von anderen eingekauft.
Stimmts oder habe ich recht?
Ich vermute mal das die irgendeinen Parser haben und der sich und das System vor bösem input schützen will.
Das Datum wird bei Emails schon gebraucht, zu mindestens der User möchte die Emails sortiert sehen.
Irgendwie scheint fem Programmier klar gewesen zu sein, das sein Datenraum begrenzt ist.
Warum sollte man denn auch Library funktionieren verwenden, die ja nicht ohne Grund einen offset
angezogen bekommen.
Als ich das gelesen habe musste ich herzlich lachen.
Anfänger Fehler.
Kann jedem Anfänger passieren.
MS hat aber wohl ein Validierung aller Parameter vorgeschrieben.
Die Meldung kam ja, nur die Reaktion war nicht ausreichend. Und wie gesagt :
Wie konnte das durch's Testbed gekommen sein.
Das Datum scheint nicht das Mail-Datum zu sein sondern das Versions-Datum der Library, oder?
Das erklärt warum der Konstruktions-Fehler bisher nicht aufgefallen ist… Man kann ja keine Rechner bei MS, die die Libraries erzeugen testweise mal ein halbes Jahr vor stellen und eine spezielle Version machen lassen.
Software, kann man nichts machen.
Also war das Signaturupdate das Problem und nicht das Datum der emails?
Warum benutzt man dann nicht einfach die vorherige letzte Signatur aus 2021 anstatt den Scanner komplett abzuschalten, damit man wenigstens noch etwas Schutz behält?
Der erste Workaround war dann zu fahrlässig und riss unnötige Löcher auf.
"Aber zum Aufwachen reicht es bei den Meisten leider immer noch nicht, was Microsoft da in den letzten Jahren verkackt hat."
MS will/muß alle in die Cloud ziehen.
Wovon will MS denn in 10 Jahren leben?
Wieso ist der Fehler denn nicht schon in den Cloud Systemen aufgefallen?
Gibt MS neue Versionen etwa erst an die nicht-cloud Kunden, damit sie sich dass testen ersparen können, und diese kostenlos Reklame für die Cloud Lösung machen (deren Admins hatten wieder mal ein ruhiges Wochenende.
.
Wir haben also laut Microsoft heute den 33.Dezember 2021:
2. Run Get-EngineUpdateInformation and verify the UpdateVersion information is 2112330001.
Die "21" am Anfang muss benutzt werden, um den Bug nicht erneut auszulösen.
Die "33" zeigt aber, dass die Validierung nicht vollständig ist.
Zitat:
"Es handelt sich nicht um ein Problem mit dem Malware-Scanning oder der Malware-Engine, und es ist kein sicherheitsrelevantes Problem."
Das ist eine wörtliche Übersetzung des MS-Artikels, aber meiner Meinung nach inhaltlich falsch.
Wenn die Malware-Engine die Signatur nicht laden kann und man als Workaround deswegen die Engine ganz abschaltet ("Disable or bypass anti-malware scanning"), dann ist das schon ein sicherheitsrelevantes Problem, denn dann kommen eventuell verseuchte Anhänge durch.
"it not a failure of the AV engine itself"
Wenn die Engine die Signatur nicht laden kann und deswegen den Betrieb einfach einstellt ist das kein Fehler der Engine?
Außerdem ist der Satz grammatisch falsch, denn da fehlt ein "is".
Wenn MS als neuen Workaround dann ein offensichtlich falsches Datum 33.12.2021 (für heute) reinfrickeln muss, dann scheint es doch ein Problem der Engine zu sein.
Warum ersetzen die nicht einfach in Exchange und der Engine und der Signatur alle long durch unsigned long long?
Search and replace im Quellcode, neu compilieren, Patch veröffentlichen ist wohl erheblich sauberer als einen 33.12. zu erfinden.
Ja, Datentyp ändern, neu kompilieren ist in der Tat der saubere Weg, Muss aber getestet werden, es könnte ja irgendwo weitere Abhängigkeiten geben, auch bei der Generierung der Signaturen, und nicht jeder Exchange-Server auf dieser Welt wird gleichzeitig auf das neue Kompilat umgestellt, das heißt übergangsweise müssen beide Varianten der Signatur zur Verfügung stehen, weil das Datumsformat nicht zueinander kompatibel ist, man denke an Drittprogramme im Zusammenhang mit Exchange die auch angepasst werden müssen, usw…
Habe gerade bei unserer Farm den Fix "manuell" ausgerollt.
Das Update der Engine hat tatsächlich einige Minuten (30?) in Anspruch genommen, aber lief dann durch.
Persönlich finde ich, dass 30min immer… Panik schüren, aber auch eine gute meditative Übung sind. Aus diesem Grund stirbt ziemlich sicher auch das Skript ab. Da das Skript bei meiner Farm gar nicht existent war, bin ich zum Glück nicht reingelaufen ;)
Stimme Dir voll zu.
Offensichtlich hat man es bei MS nicht für nötig gehalten, beim Scanner Modul die Eingangs Werte durchzufuzzen, resp. Man hat gesagt : die Signaturdatei erzeugen wir, und prüfen die. Der können wir trauen….
Das mit dem "einfach ersetzen" ist aber nicht so einfach.
Z. B. Gibt es bei if-abfragen u. U. einen implziten cast auf "int", das müsste man uberall umcasten. Das geht aber nicht per search and replace. Man muss sich das jeden Fall ansehen.
Ach, das mit dem 33.12.2021 finde ich fast lustig.
Morgen ist der 34.12. :-)
Nunja, letzendlich ist die Versionsnummer 2112330013 nur ein Versionsnummer, in die das Datum hineininterpretiert wird. :)
Der faux pas bleibt natürlich, immerhin hat MS jetzt zeit gewonnen und die Systeme können weiter "wie gewohnt" betrieben werden, bis das eigentliche Problem mit dem Long-Overflow behoben wurde.
Nochmal betont:
MS leert/löscht nach 48h die Queue.
(weil wer sonst den Server absaufen lassen könnte DOS)
Der Absender glaubt, daß seine Emails angekommen sind, da wohl die meisten User Emails für ein Echtzeit-Medium halten. MS spricht ja auch von Messages.
Heute Nacht bekommen, wenn man nichts tut, alle Absender die Nachricht das die Email nicht zugestellt werden konnte… Super..
Das mit der Queue ist do was von 90th. Fast wie mehrere Mailserver auf unterschiedlichen IPs als MX zu definieren.
In die Zeit, wo nicht jeder ein Standleitung hatte, und alle Mailserver offene Relays waren das Gute Ideen.
Damals hat man seine Emails irgendwo auf einem fremden Server abgelegt, und ließ diesen Queuen. Also darauf warten das der Empfänger online geht.
Aber heute?
Der Absender muss sofort Bescheid bekommen, wenn Emails nicht zu werden kann, als Reject, nicht Bounce.
Funktioniert das Script Update-MalwareFilteringServer.ps1 nicht, weil der Updateserver (forefrontdl[.]microsoft[.]com/server/scanengineupdate) gerade down oder überlastet ist?
Prognose, nächster "Bang" am 99.12.2021, aus dann wieder nochmal anderen Gründen…
Aus dem Bauch raus würde ich tippen:
Nach dem 99.12.2021 folgt der 01.13.2021
Super!
…und alle dachen, das Jahr 2021 sei jetzt vorbei ;)
Funktioniert hier nun auch wieder. Wir Admins arbeiten ja gerne Sonntags.
Wie konnte man aber ahnen, dass sich auch dieses Jahr nach Silvester die Jahreszahl ändert. :)
Irgendwie peinlich, nicht.
Habe die automatische Lösung mittels Reset-ScanEngineVersion.ps1 Script durchgeführt und die Mail-Warteschlange mit ca. 600 Mails wurde anschließend in 5min abgearbeitet.
Kein Reboot oder weitere Eingriffe nötig.
Man muss ein wenig Geduld mitbringen, der Download des Engine-Update erfolgt in einer Geschwindigkeit die an seelige ISDN Zeiten erinnert, so ca. 30min.
Gut das ich heute noch in den Blog reingeschaut habe, Danke Hr. Born! :)
@Kurt
MSFT wird vermutlich die QoS/Shaping aktiviert haben, damit die Server nicht in die Knie gehen. So viele Verbindungen wie in den letzten 24 Stunden werden vermutlich noch nie auf die Infrastruktur zugegriffen haben. Zumal es nicht nur ein paar MB sind.
> Gut das ich heute noch in den Blog reingeschaut habe, Danke Hr. Born! :)
Kein Monitoring im Einsatz, welches pro aktiv u.a. die Warteschlange(n) überwacht?
@DW
Monitoring der Server ja aber proaktiv die Wartenschlange(n) überwachen nein.
Aber hätte auch nicht viel gebracht da ich Urlaub hatte und da bin ich so gut wie es geht Offline ;)