22,5 godziny. Brak haseł.
Ślady sabotażu w logach.

Kiedy Wi-Fi w dużym obiekcie hotelowym przestaje działać, pierwsze co odczuwają goście to brak Internetu w pokoju. Ale to tylko widoczna warstwa problemu. W nowoczesnym hotelu na tym samym środowisku sieciowym działa system BMS - Building Management System, który zarządza ogrzewaniem, klimatyzacją, wentylacją i optymalnym zużyciem energii. Awaria sieci oznacza utratę kontroli nad temperaturą w pokojach, pracą central wentylacyjnych, warunkami w SPA i basenie.

Recepcja zostaje zalana skargami, których nie może rozwiązać - bo narzędzie jest poza zasięgiem.

To był dokładny scenariusz tej nocy. I do tego z dodatkowym utrudnieniem: Engave przejmowało właśnie obsługę IT obiektu. Poprzedni administrator nie przekazał haseł, dokumentacji ani listy kont. Zaczynaliśmy od zera - w środku aktywnego incydentu.

Reset fabryczny byłby najszybszą drogą do odzyskania kontroli nad urządzeniami. Ale był jednocześnie drogą do zniszczenia logów - jedynego dowodu na to, co się wydarzyło i kto to zrobił. Celowo go wykluczyliśmy.

Jedynym pewnym punktem zaczepienia była skrzynka pocztowa. Klient posiadał hasło do hostingu poczty - to wystarczyło. Zmieniliśmy hasło do skrzynki powiązanej z kontem poprzedniego administratora i uruchomiliśmy procedurę odzyskiwania hasła do panelu UniFi. Link resetu trafił na skrzynkę - odzyskaliśmy dostęp do kontrolera.

Dodatkowe utrudnienie techniczne: kontroler UniFi miał połączenie z Internetem tylko przez 1-3 sekundy, po czym połączenie zanikało - klasyczny objaw flapowania interfejsu. Reset hasła przez konsolę chmurową nie zmieniał hasła lokalnie na urządzeniu. Musieliśmy wpasować się w te kilka sekund okna połączenia, żeby zsynchronizować hasła z poziomu konsoli chmurowej i uzyskać dostęp z sieci wewnętrznej.

Udało się. 

Po uzyskaniu dostępu do logów UniFi mogliśmy odtworzyć sekwencję zdarzeń. Logi wskazywały, że konto o strukturze 'Imię Nazwisko' wykonywało zdalne modyfikacje w obszarach, które mają bezpośredni wpływ na działanie całej infrastruktury sieciowej.

Trzy kategorie zmian były szczególnie istotne:

Objawem, który pojawił się w panelu UniFi od początku incydentu, był komunikat: 'Gateway configuration changes could not be applied'. Brama internetowa dostawała konfigurację z kontrolera, ale nie była w stanie jej wdrożyć. Alert pojawiał się wielokrotnie w krótkich odstępach - klasyczny sygnał zapętlenia.

Przyczyna była precyzyjnie ukryta. W obszarze konfiguracji RADIUS utworzono dodatkowy element o nazwie 'system' - podczas gdy taki element już istniał. Powstał duplikat wywołujący konflikt. Kontroler rozgłaszał konfigurację, której brama nie mogła poprawnie zastosować - i wpadała w pętlę kolejnych prób, z których żadna się nie kończyła.

Efekt: cały hotel bez Internetu i Wi-Fi przez 22,5 godziny.

Rozwiązanie wymagało precyzji: nie skasowania problematycznego wpisu (usunęłoby to ślad w logach), ale zmiany jego nazwy - z 'system' na 'system1'. Konflikt zniknął. Konfiguracja została poprawnie rozgłoszona. Brama zakończyła pętlę, poprawnie się zainicjalizowała, Wi-Fi wróciło do działania. Równolegle przywrócono pierwotną konfigurację VLAN - odzyskując tym samym dostęp do systemu BMS.

Hotel odzyskał działające Wi-Fi, działający BMS i pełną kontrolę nad infrastrukturą. Ale ważniejsze od szybkości przywrócenia jest to, co zostało zachowane: logi z pełną sekwencją zdarzeń, jako dokumentacja tego, co się wydarzyło i kto to zrobił.

Po incydencie środowisko zostało natychmiast uszczelnione: backup konfiguracji ponownie włączony, MFA wdrożone jako wymóg dla wszystkich paneli administracyjnych, konta powiązane z poprzednim administratorem zablokowane, dostępy chmurowe uporządkowane. Zamknięto typowy wektor 'ktoś wraca później, bo nadal ma dostęp'.

Ten incydent jest skrajnym przykładem konsekwencji braku kontrolowanego offboardingu. Jeden człowiek z pełnymi uprawnieniami do infrastruktury sieciowej - bez procedury przekazania przy zakończeniu współpracy - może skutecznie unieruchomić obiekt. I może to zrobić tak, żeby powrót był jak najtrudniejszy: wyłączając backup, wyłączając logi, wprowadzając zmiany w miejscach, które nie są widoczne na pierwszy rzut oka.

Rekomendowana lista działań przy rozstaniu z osobą odpowiedzialną za IT: