Y2K22 – Eine kleine Neujahrsgeschichte

05.01.2022 / Daniel Gilliam

giliam-daniel

Beim Jahreswechsel 21/22 hat ein datumsbezogener Bug dazu geführt, dass bei Mircrosoft Exchange die Malware-Scan Engine in vielen Fällen nicht mehr funktionierte und infolgedessen das Empfangen von E-Mails nicht mehr möglich war.

Was ist passiert?

Während ich durch das Corona-bedingte Verkaufsverbot von Feuerwerk einen eher ruhigen (vom Knallen der Korken einmal abgesehen) Jahreswechsel erleben durfte, war dieses Glück leider nicht allen von uns vergönnt.

Als Exchange-Admin mit Bereitschaft über Silvester dürfte der eine oder andere doch eine Art nicht feuerwerks-induzierten Knall miterlebt haben. Um Mitternacht (UTC), bei uns in Deutschland also um 01:00 morgens, ereignet sich auf vielen Exchange-Servern folgendes:

Die „FIP-FS Microsoft Scan Engine“ erhält ein Signaturupdate, soweit erstmal nicht ungewöhnlich. Das Problem jedoch entsteht mit dem in der Signaturdatei codierten, neuen Datum, welches beim Konvertieren in einen signed-long-Integer einen Fehlerfall hervorruft, der das weitere Ausführen der Engine behindert. Dieses Fehlverhalten führt im Folgenden dazu, dass Nachrichten in den sogenannten „Transport-Queues“ hängen bleiben, da sie sich vor der nicht mehr funktionierenden Malware-Scan-Engine stapeln.

Und dann?

In vielen, in den darauf folgenden Stunden veröffentlichten, Blog-Beiträgen findet sich die Empfehlung den Malware-Scan-Service temporär abzuschalten um das Empfangen von E-Mails wieder zu ermöglichen. Interessanterweise waren auf Twitter die ersten Meldungen und Lösungsansätze zu lesen. Da kommt fast ein bisschen „Open-Source-Feeling“ auf.

Bis zum offiziellen Statement Microsofts, inklusive Anleitung zum Beheben des Problems dauerte es noch bis zum Vormittag. Am 01.01.22 um 11:39 postete das Exchange Team den zum jetzigen Zeitpunkt über 300.000 Mal aufgerufenen Blogpost mit Anleitung zur Fehlerbehebung.

Fazit

Für mich zeigt die Geschichte, dass eine große und kompetente Community in solchen Fehlerfällen sehr hilfreich sein kann, um kurzfristig an Lösungsvorschläge zu kommen (oder diese im Sinne der Community auch weiterzugeben und zu diskutieren!). So gab es ca. 3 Stunden nach dem erstmaligen Auftreten des Bugs bereits Lösungsansätze aus der Community, welche große Ähnlichkeit zu den später von Microsoft geposteten Handlungsanweisungen zeigten.

Auf der anderen Seite ist es in der Situation natürlich eine Herausforderung, die Richtigkeit einer noch nicht offiziell empfohlenen Maßnahme abzuwägen. Gerade bei einem oftmals geschäftskritischen System wie Exchange würde ich als Admin bei innerhalb von 3 Stunden erdachten Hilfsmaßnahmen aus der Community, trotz grundsätzlichem Vertrauen in dieselbe, Vorsicht walten lassen.

Hier hilft es, eine nicht produktive Testumgebung an der Hand zu haben, in der sich solche Emergency-Changes direkt testen lassen. Wenn der Change dann ohne Probleme in der Testumgebung gelingt, lässt er sich mit deutlich besserem Gefühl und geringerem Risiko auch produktiv umsetzen.

Sicherheit trotz oder wegen der Cloud

Grundlagen der IT-Sicherheit
04.06.-05.06.2024 in Siegburg | online

Netzsegmentierung: Aufbau und Management
14.05.-16.05.2024 in Köln oder online

Der Netzwerk Insider gehört mit seinen Produkt- und Markt-Bewertungen rund um IT-Infrastrukturen zu den führenden deutschen Technologie-Magazinen. Der Bezug des Netzwerk Insiders ist kostenlos.