Krótko: Po ostrzeżeniu przed PHP2Shell w Niemczech wyłączono strony internetowe, w tym według mediów portal internetowy miasta Moguncja oraz strony rządu krajowego Hesji i BKA (niemieckiego Federalnego Urzędu Kryminalnego). Była to prewencja zgodna z zaleceniem BSI, a nie potwierdzone ataki. Firmy mogą się z tego nauczyć: wyłączenie jest uprawnioną opcją, gdy poprawka nie jest możliwa od razu, i najlepiej udaje się wtedy, gdy zostało przygotowane z wyprzedzeniem.
Strony wyłączone z powodu PHP: co wydarzyło się 21 października
W dniu publikacji aktualizacji bezpieczeństwa PHP w Niemczech wiele publicznych stron internetowych było niedostępnych. Według doniesień medialnych miasto Moguncja prewencyjnie wyłączyło swój centralny portal internetowy. Urzędy pozostały osiągalne telefonicznie i mailowo.
W Hesji były według hessenschau czasowo offline między innymi strony rządu krajowego, Bundeskriminalamt oraz miast Kassel i Wiesbaden. Kancelaria premiera mówiła o dostosowaniach technicznych i nie zgłosiła ataku. Strony rządu krajowego były wieczorem znów dostępne. Kolejne gminy, uczelnie i kliniki również prewencyjnie odłączyły według doniesień swoje oferty od sieci.
Tłem jest zalecenie BSI (niemieckiego Federalnego Urzędu ds. Bezpieczeństwa w Technice Informatycznej) w sprawie PHP2Shell: natychmiast zaktualizować, a jeśli nie da się tego zrobić od razu, czasowo odłączyć dotknięte serwery WWW od sieci. Co dokładnie radzi BSI, podsumowuje strona Co BSI zaleca w sprawie PHP2Shell.
Wyłączony nie znaczy zhakowany
W komentarzach i sieciach społecznościowych „offline” szybko zamieniło się w „zhakowany”. Według wszystkiego, co wiadomo, jest to nieprawda. Wyłączenia były środkiem ochronnym w chwili, gdy wielu operatorów nie znało jeszcze pewnie stanu poprawek swoich serwerów.
Dla firm to rozróżnienie jest ważne podwójnie. Po pierwsze na zewnątrz: kto sam wyłącza prewencyjnie, powinien to tak nazwać, a nie milczeć. Po drugie wewnątrz: wyłączenie nie odpowiada na pytanie, czy serwer był wcześniej atakowany. Zatrzymuje tylko dalsze próby. Sprawdzenie śladów pozostaje konieczne.
Trzeci punkt bywa pomijany: wyłączenie nie może niszczyć śladów. Kto na potrzeby wyłączenia po prostu instaluje serwer od nowa lub usuwa logi, aby zwolnić miejsce, odbiera sobie możliwość późniejszego wyjaśnienia, co działo się przed wyłączeniem. Lepiej przekierować serwer WWW na stronę awaryjną lub zablokować dostęp z zewnątrz, a sam serwer ze wszystkimi logami pozostawić bez zmian.
Dlaczego tak zareagowały akurat instytucje publiczne
Urzędy często prowadzą obok siebie wiele stron: portal główny, portale branżowe, usługi formularzy, strony poszczególnych wydziałów i placówek. Często uczestniczy w tym kilku usługodawców. W dniu ostrzeżenia wielu administracjom po prostu nie udało się w ciągu godzin uzyskać udokumentowanego stanu poprawek dla każdego systemu. Prewencyjne wyłączenie było w tej sytuacji najszybszą drogą wykonania zalecenia BSI.
Dla firm z rozrośniętym krajobrazem IT sytuacja bywa podobna. Pytanie „Czy wszystko jest załatane?” nie zawodzi z powodu techniki, lecz braku przeglądu.
Godne uwagi jest też to, jak szybko strony rządu krajowego Hesji wróciły według doniesień: jeszcze wieczorem tego samego dnia. Pokazuje to, że prewencyjne wyłączenie nie musi trwać wiele dni. Kto zna swoje systemy i opanował ścieżkę aktualizacji, może w ciągu kilku godzin załatać, sprawdzić i wrócić online. Wyłączenie pokrywa wtedy tylko czas do uzyskania jasności.
Kiedy prewencyjne wyłączenie ma sens dla firm
Urzędy mają szczególną sytuację: wiele stron, często rozproszona opieka i duża widoczność publiczna. Rozważenie, przed którym stanęły, jest jednak takie samo jak w każdej firmie. Poniższe zestawienie pomaga w decyzji:
| Sytuacja | Raczej wyłączyć | Raczej zostawić online |
|---|---|---|
| Stan poprawek | niejasny lub niepotwierdzony | naprawiony i udokumentowany, procesy zrestartowane |
| Wersja PHP | 8.1 lub starsza bez potwierdzonego backportu | wspierana gałąź w aktualnym stanie |
| Tryb pracy | Apache z mod_php | załatane PHP-FPM z ustawionymi środkami przejściowymi |
| Dane na serwerze | dane klientów, loginy, dane płatnicze | wyłącznie treści statyczne |
| Dostępność usługodawcy | poprawka możliwa dopiero za kilka dni | poprawka zaplanowana w krótkim czasie |
Rozważanie między łataniem, wyłączeniem a czekaniem pogłębia artykuł Łatać, wyłączyć czy czekać?. Co technicznie jest możliwe jako rozwiązanie przejściowe, gdy brakuje jeszcze aktualizacji, opisano na stronie Środki doraźne bez poprawki.
Czasowe wyłączenie sklepu lub portalu klienta kosztuje obrót. Skompromitowany serwer z danymi klientów może kosztować znacznie więcej, aż po obowiązki zgłoszeniowe. Decyzję należy podjąć świadomie i zapisać ją na piśmie.
Jak przygotować wyłączenie
Moguncja pokazała, na czym polega sedno: administracja pozostała osiągalna innymi kanałami. Udaje się to tylko wtedy, gdy zostało przygotowane. Te kroki warto wykonać, zanim nadejdzie następny poważny przypadek:
- Mieć gotową stronę awaryjną: statyczna strona HTML bez PHP, z krótkim wyjaśnieniem, kontaktem telefonicznym i mailowym oraz, w razie potrzeby, informacjami o trwających zamówieniach lub terminach.
- Ustalić drogę przełączenia: Kto może przekierować stronę na stronę awaryjną przez serwer WWW, DNS lub usługę przed serwerem? Jak długo to trwa?
- Wyjaśnić uprawnienie do decyzji: Kto może zarządzić wyłączenie, także poza godzinami pracy?
- Znać usługi zależne: Czy od strony zależą interfejsy, aplikacje lub partnerzy? Kogo trzeba poinformować wcześniej?
- Określić kryteria powrotu: poprawka udokumentowana, restart wykonany, pierwsze sprawdzenie śladów bez wyniku.
- Przygotować komunikat: dwa do trzech zdań dla klientów, partnerów i prasy.
Jak komunikować się na zewnątrz w takiej sytuacji, opisuje poradnik o komunikacji kryzysowej.
Jak konkretnie pomaga PHP SOS?
- Podstawa decyzji: Ustalamy stan poprawek, tryb pracy i sytuację danych na Państwa serwerach i dajemy jasną ocenę, czy wyłączenie jest wskazane.
- Uporządkowane wyłączenie: Przełączamy na statyczną stronę awaryjną, nie tracąc logów ani śladów.
- Poprawka i sprawdzenie: Aktualizujemy PHP, restartujemy wszystkie procesy i sprawdzamy nieprawidłowości.
- Kontrolowany powrót: Stronę przywracamy online dopiero wtedy, gdy uzgodnione kryteria są spełnione i udokumentowane.
Przebieg opisuje natychmiastowa pomoc przy PHP2Shell.
Podsumowanie
Wyłączenia przez urzędy nie były oznaką utraty kontroli, lecz świadomym środkiem ostrożności. Dla firm to właściwa lekcja: przejście w tryb offline jest uprawnioną decyzją, gdy stan poprawek jest niejasny. Kto przygotował stronę awaryjną, odpowiedzialność i kryteria powrotu, podejmuje ją w minuty, a nie w godziny.
Częste pytania
Dlaczego strony urzędów wyłączono z powodu PHP?
BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca w przypadku PHP2Shell natychmiastową aktualizację, a jeśli nie jest to możliwe od razu, czasowe odłączenie serwerów WWW od sieci. Kilka urzędów zastosowało się do tego zalecenia prewencyjnie, dopóki ich systemy nie zostały sprawdzone i zaktualizowane.
Czy wyłączona strona oznacza, że została zhakowana?
Nie. Prewencyjne wyłączenie jest środkiem ochronnym. Kancelaria premiera Hesji zgłosiła na przykład według hessenschau wyraźnie, że nie doszło do ataku. Czy serwer był dotknięty przed wyłączeniem, rozstrzyga dopiero sprawdzenie.
Jak długo strona powinna pozostawać offline?
Do czasu, aż PHP będzie w naprawionym stanie, wszystkie procesy PHP zostaną zrestartowane, a pierwsze sprawdzenie śladów nie wykaże nieprawidłowości. Stałego czasu nie ma; strony rządu krajowego Hesji były według doniesień ponownie dostępne wieczorem tego samego dnia.
Co pokazać odwiedzającym, gdy strona jest offline?
Najlepiej prostą, statyczną stronę awaryjną bez PHP, z krótkim wyjaśnieniem i danymi kontaktowymi, pod którymi pozostają Państwo osiągalni. Powinna być przygotowana, zanim będzie potrzebna.