Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book

Problem roku 2022 – użytkownicy Microsoft Exchange zgłaszają problemy działaniem poczty. Winna wartość: 2147483647…

01 stycznia 2022, 19:00 | W biegu | komentarzy 10

Mogłoby się wydawać, że błędy w systemach informatycznych związane ze zmianą roku to domena przeszłości (np. znany problem roku 2000). Tymczasem nie do końca, bo użytkownicy Microsoft Exchange, czyli rozwiązania pocztowego stosowanego głównie w firmach, zgłaszają dziś takie błędy:

The FIP-FS „Microsoft” Scan Engine failed to load. PID: ХХХХХ, Error Code: 0x80004005. Error Description: Can’t convert „2201010001” to long.

(…)

Since the service is interconnected with the transport service, mail stops coming in and out, respectively.

FIP-FS to skaner antywirusowy dołączony po raz pierwszy do Exchange w wersji 2013. Zapewnia przynajmniej podstawową ochronę skrzynek, skanując zawartość poczty w poszukiwaniu różnego malware. Z powodu cytowanego wyżej błędu niemożliwe jest jego załadowanie do pamięci, tym samym blokuje on działanie poczty elektronicznej w środowiskach wykorzystujących Exchange. O ile w okresie świątecznym w wielu przypadkach nie jest to poważny problem, to w pewnych branżach produkcja musi działać praktycznie bez przerwy. Z drugiej strony kluczowe usługi powinny mieć zapewnione HA, jednak utrzymanie poczty jest generalnie skompilowanym zagadnieniem.

Jak zauważono w tym tweecie, maksymalna wartość typu long wynosi 2147483647, co niekoniecznie sprawdza się jako typ zmiennej przechowującej czas, szczególnie w formacie zastosowanym w Exchange. Data 1 stycznia 2022 roku „wyskoczyła” poza ten zakres, powodując dość poważny błąd (jego wystąpienie spowodowało „wysypanie” całości).

Nie istnieje jeszcze oficjalne rozwiązanie problemu, natomiast skutecznym obejściem według wielu użytkowników jest po prostu chwilowe wyłączenie skanera skryptem Disable-AntiMalwareScanning.ps1 i restart usługi MSExchangeTransport (teoretycznie samo użycie skryptu powinno wymusić restart).

Twórcy podobnych rozwiązań powinni zwracać uwagę na takie przypadki. W tej sytuacji należałoby rozważyć użycie zmiennej innego typu, ale warto testować różne scenariusze (w tym reakcje programu na zmianę roku), ponieważ dzięki temu można wykryć również inne, pewnie bardziej skomplikowane błędy. Sam Exchange zawierał już poważną podatność o nazwie ProxyLogon umożliwiającą RCE.

Testowanie różnych scenariuszy w odseparowanych środowiskach jest też ważnym zadaniem administratorów. Nie powinno się na pewno polegać na jednym dostawcy, raczej starać się używać różnych komponentów. W przypadku poczty można też rozważyć utrzymywanie jej na zewnątrz, zamiast we własnej infrastrukturze, co potrafi zaoszczędzić wiele czasu i często jest również opłacalne. Dobrym rozwiązaniem jest zastosowanie HA, czyli zapewnienie ciągłości działania (SLA) systemu, kiedy jeden z jego elementów nie działa. Nie oznacza to awarii danego komponentu środowiska, ale również standardowe prace administracyjne, które w idealnej sytuacji nie powinny mieć wpływu na działanie systemu. Zdecydowanie nie powinno być SPOF, pojedynczych punktów awarii, tj. elementu, którego niedostępność powoduje przerwanie działania całości.

–Michał Giza

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Zygi....

    Oj tak… To byl pracowity poranek w nowym roku….

    Odpowiedz
  2. _k

    „jednak utrzymanie poczty jest generalnie skompilowanym zagadnieniem”.

    Odpowiedz
    • Ja kiedyś widząc w Windowsie skompilowane pliki pomocy przeczytałem jako… skomplikowane :P

      Odpowiedz
  3. Grzegorz

    „Maksymalna wartosc typu int” powinno być, long ma dużo większy zakres :)

    Odpowiedz
  4. A w jak sposób można uzyskać HA dla klasycznej poczty?

    Odpowiedz
    • Oczywiście, chodzi mi przy korzystaniu z usług zewnętrznych (hostingów).

      Odpowiedz
  5. Krzysztof

    Ciekawe, ze ten składnik antymalwareowy wprowadzony został w wersji Exchange 2013, jednak w wersji 2013 nie ma tego problemu.

    A uwagi na temat HA w tym kontekście są nietrafione – problem i tak dotknąłby obu węzłów i całe to HA nie zdałoby się psu na budę.

    Odpowiedz
  6. Czy ktoś może wie, dlaczego w NTFSie czas liczy się od 1.01.1601?

    Odpowiedz
    • epoch tajm

      Wikipodła podaje ten powód:

      „1601 was the first year of the 400-year Gregorian calendar cycle at the time Windows NT was made”.

      Powołuje się na:

      devblogs.microsoft.com/oldnewthing/20090306-00/?p=18913 :

      „The Gregorian calendar operates on a 400-year cycle, and 1601 is the first year of the cycle that was active at the time Windows NT was being designed. In other words, it was chosen to make the math come out nicely.

      I actually have the email from Dave Cutler confirming this.”

      Odpowiedz
    • Rado

      Coś z kalendarzem gregoriańskim i zasadą liczenia lat przestępnych, które są niepodzielne przez 400 – 1601 otwierał tą epokę w której powstawał system NT i żeby coś im się łatwiej liczyło

      Odpowiedz

Odpowiedz