Podsumowanie trwającej tydzień operacji usunięcia luki w całej infrastrukturze KVM. Priorytetem kampanii wdrożenia poprawki było ograniczenie wpływu interwencji technicznej na działanie usług klientów.

Podatność w podsystemie wirtualizacji

We wtorek 7 lipca, we wczesnych godzinach popołudniowych, otrzymaliśmy alert bezpieczeństwa dotyczący CVE-2026-53359 - podatności typu use-after-free w podsystemie shadow paging mechanizmu KVM x86 w jądrze systemu Linux. Luka istniała od kilku lat, ale informacje o niej upubliczniono dopiero 6 lipca. Już następnego dnia na blogach różnych dostawców usług chmurowych zaczęły pojawiać się pierwsze publikacje na jej temat.

KVM jest mechanizmem wirtualizacji wykorzystywanym przez zdecydowaną większość instancji działających w OVHcloud. Mechanizm działa w następujący sposób: gdy Page Directory Entry (PDE) zostanie zmodyfikowany z zewnątrz, RMAP może nadal wskazywać stronę pamięci, która została już zwolniona. Jądro systemu odwołuje się następnie do tej nieaktualnej strony, co może doprowadzić do awarii hiperwizora, a w skrajnym przypadku także do eskalacji uprawnień po stronie hosta. Potwierdziły to wewnętrzne testy - na hoście bez wdrożonych poprawek awarię udało się wywołać w około dwie minuty.

Podatność dotyczy wszystkich jąder Linux x86 starszych niż commit zawierający poprawkę, niezależnie od używanej dystrybucji. Oficjalny patch został wdrożony w produkcyjnych jądrach Debiana.

Przed rozpoczęciem operacji zidentyfikowaliśmy trzy główne zagrożenia:

• Klient korzystający z usługi VPS może wykorzystać exploit i spowodować awarię hosta, na którym działa jego maszyna wirtualna, a w konsekwencji niekontrolowane ponowne uruchomienie kilkuset maszyn wirtualnych klientów.
• Analogiczny scenariusz dotyczy instancji Public Cloud. Skutki byłyby podobne, jednak na jednym hoście działa mniej maszyn wirtualnych. Są one bardziej wydajne i obsługują bardziej wrażliwe systemy (bazy danych, managery kolejek czy load balancery). Systemy te często są elementem złożonych architektur aplikacyjnych z wieloma zależnościami.
• Istnieje prawdopodobieństwo, że w najbliższym czasie zostanie opublikowany exploit umożliwiający przejęcie kontroli nad hostem. Natychmiast zwiększyłoby to poziom zagrożenia do nieakceptowalnego, ponieważ stwarzałoby ryzyko naruszenia poufności danych klientów oraz integralności infrastruktury.

W przypadku OVHcloud operacja obejmowała dziesiątki tysięcy serwerów hostów pełniących rolę hiperwizorów, na których działa około miliona maszyn wirtualnych. Pytanie nie brzmiało więc, czy wdrożyć poprawkę, lecz jak przeprowadzić tak szeroko zakrojoną akcję, mając świadomość, że całkowite wyeliminowanie wpływu na klientów nie będzie możliwe.

Rozważane opcje ograniczenia ryzyka

1. Oczekiwanie na oficjalne wydanie poprawki

To rozwiązanie uzależniałoby nas od harmonogramu podmiotu zewnętrznego i pozostawiałoby nas w sytuacji podwyższonego ryzyka przez nieokreślony czas. Ze względu na skalę zagrożenia szybko je odrzuciliśmy.

2. Live patch

Zastosowanie mechanizmu live patch wymaga włączenia go w konfiguracji jądra. Z założenia umożliwia modyfikowanie działania jądra w trakcie jego pracy, co obniża poziom bezpieczeństwa i ogranicza możliwości wykrycia ewentualnego przejęcia kontroli nad jądrem. Ponadto zastosowanie mechanizmu live patch wiąże się z podwyższonym ryzykiem i może prowadzić do niestabilności w skali całego środowiska. Jest to rozwiązanie, które pozwala zyskać czas do momentu wdrożenia docelowej poprawki. Zrezygnowaliśmy z niego, ponieważ w przypadku opublikowania exploita umożliwiającego przejęcie kontroli nad hostem znacząco zwiększyłoby poziom ryzyka.

3. Ograniczenie ryzyka poprzez wyłączenie zagnieżdżonej wirtualizacji

Wyłączenie wirtualizacji zagnieżdżonej na hostach uniemożliwia wykorzystanie exploita. Nie mamy informacji o tym, w jakim zakresie nasi klienci korzystają z tej funkcji, dlatego nie jesteśmy w stanie ocenić wpływu takiej zmiany na świadczone usługi. Ponadto funkcja ta jest niezbędna do zachowania możliwości migracji instancji na żywo między hostami fizycznymi. Z tego względu szybko odrzuciliśmy również to rozwiązanie.

4. Live migration

Live migration to migracja na żywo maszyn wirtualnych z hostów wymagających wdrożenia poprawki na hosty z wdrożoną poprawką. Ta opcja pozwala zachować ciągłość działania usług, ponieważ nie powoduje przerw w pracy maszyn wirtualnych. W trakcie migracji może jedynie dojść do czasowego spadku ich wydajności. Jej minusem jest jednak czasochłonność, ponieważ wymaga kopiowania maszyn wirtualnych host po hoście. W praktyce nie da się jej zastosować w całej infrastrukturze, jeśli chcemy zapewnić ochronę wszystkim klientom w ciągu kilku dni, a nie kilku miesięcy. Dlatego zdecydowaliśmy się zachować tę opcję wyłącznie dla wybranych krytycznych maszyn wirtualnych, ponieważ każda migracja na żywo znacząco opóźnia wykonywanie zadań wsadowych.

5. Wdrożenie poprawki w jądrach systemu oraz ponowne uruchomienie wszystkich hostów

Ostatecznie zdecydowaliśmy się na tę opcję. Szczegółowo opisujemy ją w dalszej części artykułu.

Wtorek po południu: powołanie sztabu kryzysowego

Gdy potwierdziliśmy podatność, priorytetem stało się przygotowanie skoordynowanej akcji. Analitycy bardzo szybko ocenili skalę wyzwań, z którymi mieliśmy zmierzyć się w kolejnych dniach. We wczesnych godzinach popołudniowych przekazaliśmy informacje wewnątrz firmy. Uruchomiliśmy też kilka kanałów: do koordynacji technicznej, zarządzania kryzysem, działań w Stanach Zjednoczonych oraz komunikacji z klientami i wsparcia technicznego. Równocześnie zespoły Kernel przygotowały patch i wykonały jego backport.

Wieczorem udostępniły pierwszą wersję jądra z wdrożoną poprawką, przeprowadziły testy walidacyjne i potwierdziły skuteczność rozwiązania. Exploit nie powodował już awarii hiperwizorów, a testy QA zakończyły się pomyślnie.

Po zakończeniu testów sztab kryzysowy skupił się na nadzorowaniu wdrożenia. Następnie koordynację przejął NOC (Network Operations Center). Monitorował postępy prac, ustalał priorytety dla poszczególnych regionów i usług oraz czuwał nad przebiegiem całej operacji. Za ponowne uruchamianie hostów, live migration i egzekwowanie reguł anti-affinity odpowiadali eksperci Public Cloud i VPS. Taki podział ról był celowy: NOC koordynował działania, a zespoły operacyjne wykonywały wszystkie prace oraz przekazywały dane o postępach i zdarzeniach technicznych niezbędne do dalszej koordynacji.

Na bieżąco synchronizowaliśmy również działania z działem wsparcia, który informował klientów o postępach, oraz z zespołami ds. bezpieczeństwa odpowiedzialnymi za monitorowanie podatności, weryfikację zakresu działań i ocenę gotowości do zakończenia operacji.

Ze względu na organizację działań w modelu „follow the sun” komórka operacyjna działała 24/7, z rotacją zespołów pomiędzy strefami geograficznymi. Trzy razy dziennie odbywały się spotkania synchronizacyjne związane z przekazywaniem działań między strefami. Uczestniczyli w nich przedstawiciele NOC, zespołów operacyjnych, działu wsparcia i zespołów ds. bezpieczeństwa. Omawiali oni postępy w poszczególnych regionach, przekazywali informacje o przebiegu działań (w tym o sprawdzonych rozwiązaniach oraz zmianach w procedurach) i ustalali priorytety na kolejny etap operacji.

W skład komórki operacyjnej, działającej rotacyjnie 24/7, wchodzili przedstawiciele zespołów Kernel & Virtualization (analiza poprawek, backport, walidacja), VPS i Public Cloud (wdrażanie), NOC (koordynacja działań), Run & SRE (orkiestracja, anti-affinity, live migration), Datacenter Operations (prace na sprzęcie), Wsparcia (obsługa zgłoszeń klientów), Bezpieczeństwa (monitorowanie podatności, określanie zakresu działań, zakończenia operacji) oraz Komunikacji (zapewnienie transparentności i kierowanie powiadomień do właściwych odbiorców).

Naszym celem było wdrożenie poprawek, restart hostów, jak najszybsze usunięcie podatności i ograniczenie wpływu naszej operacji na usługi.

Dużym wyzwaniem była jednak skala przedsięwzięcia - należało objąć działaniem dziesiątki tysięcy maszyn rozmieszczonych na wszystkich kontynentach, a przeprowadzanie operacji dla każdej z nich osobno nie wchodziło w grę.

Na tym etapie największym zagrożeniem było wykorzystanie podatności, które mogło doprowadzić do awarii hostów bez zainstalowanej poprawki. Dlatego sztab kryzysowy podjął decyzję o wdrożeniu poprawki na wszystkich hostach jeszcze przed rozpoczęciem ich restartu. Jeśli podatność zostałaby wykorzystana, awaria hosta spowodowałaby jego ponowne uruchomienie, a poprawka zostałaby zastosowana automatycznie. Istniało również ryzyko wykorzystania podatności CVE do przejęcia kontroli nad hostem. Choć kod umożliwiający jej wykorzystanie nie był jeszcze publicznie dostępny, było dla nas jasne, że w krótkim czasie ktoś go opracuje. Taki scenariusz miałby katastrofalne skutki, dlatego liczyła się każda minuta.

Decyzja: jednostronne wdrożenie poprawki przy kontrolowanym wpływie na usługi

Wieczorem Komitet Wykonawczy podjął decyzję „Go/No-Go”: pierwszy region zostanie objęty operacją następnego dnia rano. Przy takiej liczbie maszyn nie istniał scenariusz całkowicie pozbawiony wpływu na działanie usług. Uzgodnienie okna serwisowego z każdym klientem, sprawdzenie wszystkich zależności i indywidualne zaplanowanie restartu każdego hosta były po prostu niewykonalne ze względu na bardzo ograniczony czas wynikający z ryzyka związanego z podatnością.

Sztab kryzysowy podjął więc decyzję o jednostronnym wdrożeniu poprawki przy kontrolowanym wpływie na usługi. Operację rozpoczęliśmy bez oczekiwania na indywidualną zgodę każdego klienta, mając świadomość, że część usług zostanie czasowo przerwana.

Decyzja wynikała z trzech przesłanek:

• brak wdrożenia poprawek narażał całą infrastrukturę na podatność o wysokim poziomie ryzyka;
• indywidualne podejście do każdego przypadku wydłużyłoby operację i pozostawiło większość hostów podatnych przez wiele tygodni;
• szybkie i globalne wdrożenie poprawek zapewniało ochronę największej liczbie systemów, nawet jeśli oznaczało tymczasowe zakłócenia części usług.

Priorytetem nie było już uniknięcie wpływu operacji na usługi, lecz ograniczenie jego skali oraz takie zaplanowanie działań, aby akcja była jak najmniej odczuwalna. Temu celowi podporządkowaliśmy całą operację - od modelu „follow the sun”, przez priorytetyzację regionów, po planowanie z uwzględnieniem reguł anti-affinity.

Środa, 8 lipca: start operacji w Sydney

Wybór Sydney do przetestowania wdrożenia nie był przypadkowy: liczba hostów była tam ograniczona, a godziny prowadzenia prac (noc) pokrywały się z godzinami pracy zespołów w Europie. Rozpoczęcie działań od regionu najbardziej wysuniętego na wschód umożliwiło:

• przeprowadzenie operacji w regionie o najmniejszym obciążeniu;
• weryfikację procedury w rzeczywistych warunkach, na niewielką skalę, przed wdrożeniem jej w pozostałych regionach;
• zebranie pierwszych informacji zwrotnych przed rozpoczęciem działań w Europie i Ameryce Północnej.

Pierwsza seria patch + reboot objęła hosty VPS w Australii. Prace w regionie SYD2 zakończyły się we wczesnych godzinach popołudniowych (czasu paryskiego), bez żadnych incydentów. Na podstawie pierwszych informacji z terenu wprowadziliśmy korekty do procedur.

Od tego momentu pracowaliśmy już w modelu „follow the sun”: gdy w kolejnym regionie rozpoczynał się dzień, lokalny zespół wdrażał działania na podstawie informacji przekazanych przez zespół kończący pracę. Jeszcze tego samego wieczoru, o godzinie 18:30 czasu paryskiego, rozpoczęliśmy pierwszy etap działań w Europie (RBX, GRA6, WAW, DE, SBG, MIL i UK).

Dwa środowiska, dwa poziomy ryzyka: najpierw VPS, potem Public Cloud

Wdrożenie nie przebiegało jednakowo w obu środowiskach. VPS i Public Cloud różnią się zarówno architekturą, jak i poziomem ryzyka dla klientów. Na hostach VPS działa więcej maszyn wirtualnych, a wiele firm i użytkowników indywidualnych wykorzystuje VPS-y do tworzenia środowisk testowych. Istniało więc duże ryzyko, że exploit zostanie szybko wykorzystany. Ze względu na dużą liczbę maszyn wirtualnych działających na każdym hoście skutki takiego ataku mogłyby być bardzo poważne.

Z drugiej strony w środowisku VPS wpływ restartu pojedynczego hosta na klientów pozostawał ograniczony. Dzięki temu mogliśmy szybko realizować kolejne partie prac i zabezpieczyć znaczną część infrastruktury już w ciągu pierwszych 24 godzin.

W przypadku Public Cloud poziom ryzyka był zupełnie inny. Jeden region obsługuje tysiące klientów, a na pojedynczym hoście mogą działać instancje o krytycznym znaczeniu. Największe regiony liczą setki, a nawet tysiące hostów wykorzystywanych przez złożone środowiska wirtualne klientów. Dlatego ustaliliśmy następujące priorytety:

• według wielkości regionu: w pierwszej kolejności aktualizowaliśmy mniejsze regiony, aby potwierdzić, że procedura sprawdza się również przy wdrożeniach na większą skalę;
• według liczby narażonych klientów: regiony obsługujące największą liczbę klientów dzieliliśmy na mniejsze partie i aktualizowaliśmy je etapami, aby ograniczyć ryzyko.

Progi wstrzymania operacji i kontrola tempa

Dla każdej serii restartów określiliśmy próg, po którego przekroczeniu wstrzymywaliśmy operację. Jeśli liczba hostów, które jednocześnie uległy awarii, przekraczała ustalony limit, wstrzymywaliśmy kolejną serię restartów. Próg ten wynosił 15 hostów w regionach o największej koncentracji infrastruktury (GRA, RBX, BHS) oraz 5 hostów w pozostałych regionach. Operację wstrzymywaliśmy również o godzinie 6:00 lub na prośbę lokalnego centrum danych.

Dzięki temu nie pogłębialiśmy skutków awarii sprzętowych, ponieważ nie kontynuowaliśmy restartów hostów, którymi technicy centrum danych nie zdążyli się jeszcze zająć. Mechanizm ten pozwalał dostosować przebieg operacji do rzeczywistej sytuacji w centrach danych.

Anti-affinity - ochrona przed jednoczesnym restartem instancji tego samego projektu

Największym zagrożeniem dla klientów podczas takiej operacji nie był sam restart, lecz jednoczesne przerwanie działania kilku instancji tego samego projektu, zapewniających odporność aplikacji na awarię po stronie dostawcy. Właśnie dzięki rozmieszczeniu ich na wielu hostach aplikacja zachowuje wysoką dostępność nawet w przypadku awarii po stronie dostawcy. Dlatego nie można dopuścić do jednoczesnego restartu wszystkich instancji takiego projektu. Postanowiliśmy zatem pójść o krok dalej niż reguły anti-affinity skonfigurowane przez klientów w ich środowiskach.

Dla projektów z instancjami rozmieszczonymi na wielu hostach stosowaliśmy mechanizm oparty na grafie współlokalizacji. Dzięki temu dwa hosty z instancjami tego samego projektu nigdy nie były restartowane w tym samym oknie serwisowym. Zamiast tego planowaliśmy restarty w taki sposób, aby wzajemnie się wykluczały, a kolejny host w tej samej klasie anti-affinity uruchamialiśmy dopiero po przywróceniu poprzedniego do działania.

Reguły anti-affinity stosowaliśmy zgodnie z zasadą best effort. W większości przypadków były one przestrzegane, jednak nie mogliśmy zagwarantować ich zachowania w całej infrastrukturze. Celem było takie rozłożenie restartów w czasie, aby ich wpływ na aplikacje był jak najmniejszy. Jeśli wszystkie instancje projektu działały na jednym hoście, podczas wcześniej zapowiedzianego okna serwisowego dochodziło do krótkiej przerwy w działaniu usług.

Priorytetowa migracja na żywo krytycznych usług i obciążeń

Każda instancja klienta jest powiązana z kontrolerami, interfejsami API, płaszczyznami danych i wewnętrznymi bazami danych. Niekontrolowany restart hostów obsługujących te usługi mógłby doprowadzić do zakleszczenia zależności (deadlock): niedostępność jednej z usług wewnętrznych blokowałaby kolejne restarty, a tym samym również proces wdrożenia poprawki. Dodatkowo część usług OVHcloud działa na maszynach wirtualnych hostowanych w środowisku Public Cloud. Uwzględnienie tych zależności było niezbędne, aby ograniczyć wpływ operacji na klientów.

Aby uniknąć efektu domina, odwróciliśmy kolejność działań. Przed restartem każdego regionu szczegółowo analizowaliśmy zależności między usługami wewnętrznymi. Wybrane usługi wewnętrzne migrowaliśmy na żywo. Powiązane z nimi maszyny wirtualne przenosiliśmy bez przerywania pracy na hosty, które zostały już zaktualizowane. Pozwalało to zachować ciągłość łańcucha zależności i zwolnić host do restartu.

Procedura ta jest czasochłonna i wymaga znacznych zasobów sprzętowych oraz zaangażowania zespołów. Dlatego ograniczyliśmy ją do niewielkiej liczby maszyn wirtualnych, aby cały proces migracji zamknąć w założonych ramach czasowych.

Niektóre obciążenia wymagały szczególnej uwagi. Dotyczyło to przede wszystkim usług Cloud Databases (DBaaS), wewnętrznego Data Lake oraz funkcji Observability. Maszyny wirtualne migrowaliśmy pojedynczo, dbając o to, aby w danym momencie wyłączona była najwyżej jedna. Aktualizację hostów opóźnialiśmy tak długo, jak było to możliwe. Taka stopniowa migracja pozwoliła uniknąć kaskadowych awarii usług i zapewniła dostępność narzędzi wspierających realizację całej operacji.

Incydenty techniczne i korekty w trakcie operacji

Operacje na taką skalę nigdy nie przebiegają bez incydentów. W trakcie pojawiło się kilka problemów technicznych, które na bieżąco rozwiązywaliśmy.

Trudności z ponownym uruchamianiem maszyn wirtualnych po restarcie hosta

Pierwszy poważny problem pojawił się już podczas pierwszej serii aktualizacji w Europie. Część maszyn wirtualnych nie uruchamiała się ponownie po restarcie hosta z hiperwizorem. Usługa „nova-compute” zgłaszała komunikat „Instance shutdown by itself”, przy czym stan maszyn nie był synchronizowany z interfejsem API. Drugiego dnia udało się zidentyfikować przyczynę problemu. Usługa „libvirt-guests” wchodziła w konflikt z „nova-compute” i podczas restartu hosta zatrzymywała instancje, nie synchronizując ich stanu z API. Rozwiązaniem było wyłączenie i zamaskowanie usługi „libvirt-guests.service” na hostach przed ich restartem. Po wdrożeniu tej zmiany maszyny wirtualne ponownie uruchamiały się już automatycznie.

Uszkodzenie danych w usługach synchronicznych

Wieczorem drugiego dnia wewnętrzny system monitoringu wykrył uszkodzone dane na kilku maszynach wirtualnych rozmieszczonych w trzech klastrach. Najbardziej prawdopodobną przyczyną było wymuszenie restartu w trakcie zapisu danych na dysk. Dlatego wydłużyliśmy czas „graceful shutdown” do 60 sekund przed wymuszonym zatrzymaniem, aby umożliwić dokończenie operacji zapisu. Dodatkowo wdrożyliśmy skrypt automatycznie uruchamiający ponownie maszyny wirtualne, które pozostały wyłączone.

Deadlock API w Paryżu

Drugiej nocy operacji interfejsy API Nova i Neutron w Paryżu wzajemnie się zablokowały (deadlock): Interfejs API Neutron, ograniczony do 10 procesów roboczych, został przeciążony gwałtownym napływem żądań z Nova i przez około dwie godziny zwracał błędy HTTP 503. Rozwiązaniem było zwiększenie liczby workerów Neutron z 10 do 30 oraz liczby procesów Apache z 10 do 32. Aktualizację stref B w Paryżu i Mediolanie odłożyliśmy do czasu przywrócenia stabilności.

Przeciążenie Panelu klienta i kanałów wsparcia w BHS

W centrum danych BHS (Kanada) ruch kierowany do interfejsów API osiągnął poziom dziesięciokrotnie wyższy od dotychczasowego maksimum, przeciążając zarówno Panel klienta, jak i kanały wsparcia. Część klientów odczuła skutki operacji, zanim otrzymała informację o prowadzonych pracach. Ten przypadek dobrze pokazuje, jak w złożonej infrastrukturze powstaje efekt domina. Wszystkie zidentyfikowane błędy i problemy zostały rozwiązane i posłużą do wdrożenia trwałych usprawnień.

Restarty i interwencje sprzętowe

Restart dziesiątek tysięcy serwerów to duże wyzwanie związane ze sprzętem. Z każdym restartem serwera wiąże się określone ryzyko awarii. Już pierwszej nocy około 20-30 z 6000 hostów nie uruchomiło się ponownie. Było to spowodowane m.in. uszkodzonymi modułami pamięci, nieprawidłową konfiguracją BIOS-u lub nieaktywnym interfejsem sieciowym. W Stanach Zjednoczonych kilka hostów wymagało wyjęcia baterii CMOS i resetu zasilania przed ponownym uruchomieniem. Był to powtarzający się scenariusz dla tej konfiguracji sprzętowej.

Na potrzeby całej operacji w każdym centrum danych wsparcie zapewniali dodatkowi technicy. Ich zadania obejmowały:

• natychmiastowe interwencje przy hostach, które nie uruchomiły się ponownie i zostały wskazane przez systemy orkiestracji;
• wymianę uszkodzonych części (dysków, modułów pamięci i zasilaczy);
• czynności wymagające fizycznej obecności, których nie da się zautomatyzować, takie jak wymuszony restart serwera, weryfikacja kontrolek czy interwencja przy szafie serwerowej.

Technicy centrów danych w pierwszej kolejności interweniowali przy hostach, które nie uruchomiły się ponownie. Działali w ścisłej współpracy z zespołami Run i SRE, które ustalały priorytety na podstawie wpływu awarii danego hosta na klientów. Jeśli host obsługujący krytyczne instancje nie wznowił pracy po restarcie, otrzymywał wyższy priorytet niż host bez aktywnych instancji. Skoordynowane ustalanie priorytetów na poziomie oprogramowania i infrastruktury fizycznej pozwalało utrzymać tempo operacji.

Komunikacja i wsparcie klientów

Operacja aktualizacji prowadzona jednostronnie, nawet przy kontrolowanym wpływie na usługi, wymaga odpowiedniej komunikacji z klientami.

Komunikacja dostosowana do odbiorców i etapów operacji

W modelu „follow the sun” jednakowa komunikacja dla wszystkich klientów jest bezzasadna. Dlatego informacje przekazywaliśmy stopniowo i wyłącznie tym klientom, których dotyczyły planowane działania. Wiadomości wysyłaliśmy wraz z postępem operacji - region po regionie, seria po serii.

Początkowo nie korzystaliśmy ze strony ze statusami prac, aby nie ujawniać publicznie kolejności wdrażania poprawki. Zamiast tego kierowaliśmy indywidualne komunikaty za pośrednictwem naszego portalu Support oraz wysyłaliśmy wiadomości e-mail do klientów korzystających z poziomów wsparcia Business i Enterprise.

Ograniczenia narzędzi komunikacyjnych

Narzędzia wykorzystywane do komunikacji mają swoje ograniczenia techniczne. W regionach obsługujących bardzo dużą liczbę klientów, takich jak GRA6 informacji nie otrzymało bezpośrednim kanałem blisko 90 000 klientów, ponieważ masowa wysyłka wiadomości e-mail mogłaby doprowadzić do lawinowego wzrostu liczby zgłoszeń do działu wsparcia.

Drugiego dnia operacji podjęliśmy decyzję o wdrożeniu warunkowego banera w Panelu klienta z wykorzystaniem mechanizmu „feature flipping”. Jeśli zalogowany użytkownik figurował na liście klientów (NIC), których dotyczyły planowane działania, wyświetlana była stosowna informacja. Mechanizm opracowaliśmy jeszcze tego samego dnia, a baner wdrożyliśmy trzeciego dnia operacji.W tym samym czasie utworzyliśmy również stronę ze statusami Public Cloud.

Mimo zastosowania tych rozwiązań nie wszystkie komunikaty dotarły do odbiorców. Powodem były nieaktualne adresy kontaktowe, filtrowanie powiadomień oraz rozbieżność między planowaną godziną restartu a godziną wysłania komunikatu. Niektórzy klienci odczuli skutki operacji, nie otrzymawszy wcześniej powiadomienia. Problemy te zidentyfikowaliśmy jako priorytetowe obszary wymagające poprawy po zakończeniu pierwszego etapu operacji.

Szczególna rola działu wsparcia

Aby zapewnić wsparcie klientom, którzy nie otrzymali powiadomienia lub potrzebowali dodatkowych wyjaśnień, podjęliśmy specjalne działania w zespołach wsparcia: przekazaliśmy im informacje o kontekście operacji, zapewniliśmy dostęp w czasie rzeczywistym do danych o postępie prac w poszczególnych regionach i na poszczególnych hostach oraz wdrożyliśmy dedykowaną ścieżkę przyspieszonej obsługi zgłoszeń związanych z tą operacją.

Dział wsparcia uzupełniał komunikację z klientami w przypadkach, w których automatyczne powiadomienia okazały się niewystarczające.

Kalendarium operacji

Podsumowanie i kolejne kroki

Podatność CVE-2026-53359 stanowiła zagrożenie zarówno dla naszych klientów, jak i dla naszej infrastruktury. Nasza operacja nie pozostała bez wpływu na klientów, był on jednak ograniczony i rozłożony w czasie. Przekazywanie bardziej szczegółowych informacji w trakcie realizacji planu, zanim poprawki zostały wdrożone w całej infrastrukturze, znacząco zwiększyłoby ryzyko dla naszych klientów. Mogłoby bowiem skłonić część z nich do wypróbowania publicznie dostępnego exploitu.

Restart globalnej infrastruktury bez jakichkolwiek zakłóceń nie był możliwy. Naszym priorytetem było zatem zminimalizowanie ich skali i zapewnienie maksymalnego bezpieczeństwa.

Nigdy wcześniej nie wdrażaliśmy poprawek i nie restartowaliśmy wszystkich hostów Public Cloud oraz VPS w tak krótkim czasie, jednak skala ryzyka związanego z wykrytą podatnością wymagała pilnego zastosowania tej wyjątkowej procedury. We wszystkich wcześniejszych przypadkach restarty były realizowane stopniowo, z wykorzystaniem naturalnej rotacji maszyn wirtualnych w infrastrukturze oraz planowanych, rozłożonych w czasie migracji na żywo.

Zespoły zaangażowane w tę operację zrealizowały przedsięwzięcie o bezprecedensowej skali, utrzymując liczbę awarii i ich konsekwencje dla klientów na możliwie najniższym poziomie. Jednocześnie mamy świadomość, że w nadchodzących miesiącach mogą zostać ujawnione kolejne podatności jądra systemu, dlatego podobne działania mogą okazać się konieczne również w przyszłości. Przy kolejnej takiej operacji chcemy jeszcze bardziej ograniczyć jej wpływ na klientów - ulepszając procedury, komunikację i wsparcie. W najbliższych dniach i tygodniach przeanalizujemy przypadki klientów, którzy najbardziej odczuli skutki operacji. Jednocześnie poddamy dokładnej analizie nasze działania, aby je na przyszłość usprawnić.