NASZ NEWS: Awaria pod kontrolą? Kulisy tajemniczego „ataku” na strony PO i PSL w ostatnich godzinach kampanii

Awaria czy atak? Strony partii wyłączone w kluczowym momencie

W piątek 16 maja 2025 r., na finiszu kampanii prezydenckiej i tuż przed rozpoczęciem ciszy wyborczej, przestały działać oficjalne strony internetowe Platformy Obywatelskiej oraz Polskiego Stronnictwa Ludowego. Rządowi przedstawiciele ogłosili, że doszło do zmasowanego ataku hakerskiego. Oficjalna narracja sugerowała więc poważny zewnętrzny cyberatak wymierzony w stronę partii koalicji 13 grudnia na ostatniej prostej kampanii.

Niepokojące sygnały i szybkie „rozwiązanie”

Mimo alarmujących komunikatów, przebieg zdarzeń wzbudził wątpliwości wielu obserwatorów i ekspertów IT. Strony Platformy Obywatelskiej (platforma.org) i PSL faktycznie były niedostępne dla zwykłych użytkowników przez pewien czas. Jednak analiza techniczna zachowania ich serwerów wskazuje, że mogło nie dojść do żadnego prawdziwego przeciążenia ani zewnętrznej infiltracji, a zamiast tego mieliśmy do czynienia z działaniami administracyjnymi na serwerach. Co więcej, strony wróciły do normalnego działania stosunkowo szybko, jeszcze przed ciszą wyborczą, co również każe zadać pytanie, czy incydent na pewno był poza kontrolą administratorów. Przyjrzyjmy się kluczowym faktom technicznym krok po kroku.

Serwery odpowiadały – brak śladów przeciążenia sieciowego

Całkowita niedostępność usług wskutek ataku DDoS zwykle objawia się brakiem odpowiedzi serwera na jakiekolwiek żądania, nawet te najprostsze, takie jak polecenie ping (sprawdzenie, czy maszynę da się osiągnąć w sieci). W tym przypadku jednak serwery Platformy Obywatelskiej i PSL przez cały incydent pozostały osiągalne w internecie. Globalne testy łączności pokazały, że host odpowiadał na ping ze wszystkich badanych lokalizacji – od Sydney i Tokio, po Warszawę i Moskwę – z typowymi czasami odpowiedzi. We wszystkich przypadkach pakiety docierały bez strat (wynik 4/4). Również serwer PSL (adres IP 185.105.143.6) reagował na zapytania sieciowe z różnych zakątków świata bez oznak opóźnień czy utraty pakietów. Brak jakichkolwiek przerw w łączności sugeruje, że infrastruktura sieciowa nie była pod zmasowanym obciążeniem, jakie towarzyszyłoby prawdziwemu atakowi typu DDoS. Innymi słowy – serwery fizycznie działały i miały kontakt z siecią przez cały czas trwania rzekomego „ataku”.

Dostępne usługi poza stroną WWW

Co ciekawe, awaria dotyczyła wyłącznie usług WWW (stron internetowych) – pozostałe funkcje serwerów działały normalnie. W przypadku serwera PSL zaobserwowano, że porty 80 i 443 (służące do obsługi stron WWW) zostały zablokowane, natomiast inne porty – m.in. związane z pocztą elektroniczną – pozostały aktywne. Oznacza to, że sam serwer PSL działał (odpowiadał na ping i obsługiwał pocztę), a jedynie celowo wyłączono dostęp do strony internetowej. Taka selektywna niedostępność jest mało typowa dla skutków ataku DDoS, który zazwyczaj albo przeciąża całe łącze sieciowe serwera, albo unieruchamia go kompletnie. Tutaj natomiast wyraźnie wygląda to na decyzję administracyjną – wyłączenie serwisu WWW, prawdopodobnie w celu zabezpieczenia go lub… upozorowania awarii. Warto dodać, że jeszcze rano 16 maja strona PSL działała bez zarzutu, po czym nagle została „ścięta” około południa. To wskazuje, że ingerencja nastąpiła w konkretnym momencie, zbieżnym z ogłoszeniem informacji o ataku.

Dziwne przekierowania i kody statusu HTTP

Najbardziej znamiennym sygnałem, że mogliśmy mieć do czynienia z kontrolowanym wyłączeniem stron, jest zaobserwowane zachowanie serwera HTTP witryny Platformy Obywatelskiej (platforma.org). Serwer ten w trakcie incydentu nie milczał całkowicie – wręcz przeciwnie, odpowiadał komunikatami HTTP, które trudno uznać za typowe dla serwera przytłoczonego atakiem.

Na początku kryzysu serwer platforma.org zaczął zwracać nietypową sekwencję kodów HTTP przy próbie otwarcia strony. Pierwszy kod to 302 „temporarily removed”, oznaczający przekierowanie – czyli serwer nie serwował właściwej zawartości strony, tylko wysyłał przeglądarkę na inny adres. Po przekierowaniu następował kod 503 „Service Unavailable”, czyli komunikat informujący o chwilowej niedostępności usługi. Innymi słowy, zamiast np. strony głównej, użytkownik otrzymywał informację o awarii serwisu. Taki układ – najpierw 302, potem 503 – sugeruje celowe działanie: serwer mógł zostać skonfigurowany, aby przekierować ruch na specjalną stronę informującą o niedostępności (błąd 503). Administratorzy często stosują kod 302, by tymczasowo przenieść użytkowników na stronę komunikatu o przerwie technicznej lub przeciążeniu. Nie jest to jednak zachowanie, które samoistnie generuje się podczas ataku – to raczej rezultat świadomej konfiguracji.

Powyższy zrzut ekranu przedstawia wynik polecenia curl -I -L (pobranie nagłówków HTTP z opcją podążania za przekierowaniami) dla zasobu na stronie platforma.org. Widzimy tu dokładnie opisaną sekwencję: najpierw kod „HTTP/1.1 302 Found” wraz z nagłówkiem „Location” wskazującym inny URL, a następnie – po przekierowaniu – kod „HTTP/1.1 503 Service Unavailable”. Taki rezultat potwierdza, że serwer Platformy przekierowywał ruch na stronę z komunikatem o niedostępności (503). Warto podkreślić, że kody te zostały zarejestrowane w trakcie trwania domniemanego ataku (w piątek po południu). Gdyby serwer był naprawdę sparaliżowany nadmiernym ruchem, prawdopodobnie w ogóle nie udałoby się uzyskać takiej odpowiedzi (żądania mogłyby wygasać z powodu braku odpowiedzi). Tutaj zaś serwer nie tylko odpowiadał, ale wręcz grzecznie informował, że usługa jest chwilowo niedostępna – co wygląda jak kontrolowany komunikat, a nie chaos typowy dla prawdziwego cyberataku.

Błyskawiczna zmiana konfiguracji i powrót do normalności

Jeszcze ciekawszy zwrot akcji nastąpił wkrótce po tym, jak część ekspertów nagłośniła podejrzane objawy w mediach społecznościowych. Po publicznym zwróceniu uwagi na niezgodności techniczne, konfiguracja serwera platforma.org została nagle zmieniona. Zamiast opisanej wyżej sekwencji 302→503, strona zaczęła zwracać inny kod odpowiedzi.

Kolejny zrzut z narzędzia curl ukazuje stan serwera Platformy kilkanaście minut po poprzednim teście. Widać, że przy próbie pobrania tego samego zasobu serwer nadal początkowo odpowiada kodem 302 (przekierowanie), jednak następnie zwraca już kod „200 OK”. Kod 200 oznacza prawidłowe dostarczenie zawartości – w tym przypadku zamiast komunikatu błędu 503 serwer podawał użytkownikowi jakąś stronę (zapewne prostą stronę z informacją o problemach technicznych, lecz istotne jest, że robił to już z kodem sukcesu). Taka zmiana jest istotna, ponieważ nastąpiła bardzo szybko i wyraźnie w reakcji na ujawnienie szczegółów technicznych. Innymi słowy, administratorzy prawdopodobnie zauważyli, że ktoś wychwycił ich sztuczkę z kodami i przekierowaniem, po czym dokonali korekty konfiguracji, by dalej nie zdradzać tych nietypowych oznak. Sam fakt tak sprawnego przywrócenia normalnego działania serwisu (lub przynajmniej zmiany sposobu prezentacji błędu) świadczy o tym, że pełna kontrola nad serwerem przez cały czas leżała po stronie administratorów. Gdyby rzeczywiście trwał poważny atak zewnętrzny, naprawa sytuacji nie byłaby taka szybka i prosta – zazwyczaj neutralizacja ataku DDoS wymaga współpracy z dostawcami usług internetowych, filtrowania ruchu, czasem mija wiele godzin, nim wszystko wróci do normy. Tutaj natomiast problem zniknął jak ręką odjął, akurat gdy stał się tematem publicznej dyskusji.

Pozorowany atak na potrzeby polityczne?

Suma powyższych obserwacji stawia wiarygodność wersji o „zewnętrznym cyberataku” pod dużym znakiem zapytania. Serwery nie wykazały objawów prawdziwej walki z przeciążeniem – pozostawały dostępne, reagowały na polecenia, a ich zachowanie nosiło cechy świadomej konfiguracji. Wszystko to prowadzi ekspertów do wniosku, że incydent mógł być pozorowany. Jak ujął to jeden z komentatorów branżowych, „tłumacząc z języka IT na polski: ten rzekomy atak rosyjskich służb albo przeprowadziło 7-letnie dziecko, albo żadnego ataku nie było – mieliśmy żałosną próbę administratorów udawania, że jest atak. Nie ma trzeciej opcji”. Oczywiście taka opinia jest dosadna, jednak dobrze oddaje skalę nieprawdopodobieństwa oficjalnej narracji w świetle zgromadzonych danych technicznych.

Motywacja dla upozorowania ataku tuż przed wyborami może być przedmiotem spekulacji. Możliwe, że celem było wzbudzenie współczucia dla zaatakowanych partii koalicji 13 grudnia lub stworzenie wrażenia, że także one padają ofiarą wrogich sił zewnętrznych ingerujących w polskie wybory. Należy podkreślić, że nie formułujemy tu kategorycznych oskarżeń – nie da się na podstawie samych danych technicznych jednoznacznie stwierdzić intencji administratorów. Fakty jednak pozostają faktami: sposób, w jaki wyłączono i przywrócono strony Platformy i PSL, dużo bardziej przypomina zaplanowaną przerwę techniczną (albo wręcz inscenizację na potrzeby medialne) niż skutki nagłego, zewnętrznego ataku hakerskiego. W interesie przejrzystości życia publicznego warto, by odpowiednie służby dokładnie zbadały ten incydent. Tymczasem obserwatorzy sieciowi już dziś wyciągają własne wnioski, a cała sytuacja stanowi ciekawy przykład, jak elementy techniczne (kody serwera, logi, dostępność portów) mogą zdradzić kulisy zdarzeń, odbiegając od oficjalnych komunikatów.

Źródła: Republika na podstawie:

• Globalne testy ping dla platforma.org – zrzut ekranu wyników (16.05.2025) pokazujący odpowiedzi serwera z różnych lokalizacji (bez strat, niski czas opóźnień).
• Globalne testy ping dla serwera PSL – zrzut ekranu wyników (16.05.2025) dla adresu IP 185.105.143.6, potwierdzający pełną osiągalność maszyny w trakcie incydentu.
• Nagłówki HTTP z serwera platforma.org (etap 302→503) – zrzut ekranu polecenia curl (16.05.2025, godz. ~17:26) ukazujący przekierowanie 302 i odpowiedź 503 Service Unavailable.
• Nagłówki HTTP z serwera platforma.org (zmiana na 200) – zrzut ekranu polecenia curl (16.05.2025, ok. 17:42) pokazujący kod 200 OK zamiast 503, po zmianie konfiguracji.
• Wpis Jakuba Krysiewicza (Twitter/X) – analiza techniczna incydentu opublikowana 16.05.2025, zawierająca m.in. informacje o dostępności serwerów i zmianach kodów odpowiedzi
• Wypowiedzi premiera i administracji – wpis Donalda Tuska na X informujący o ataku (16.05.2025) oraz komunikat Jana Grabca o rzekomym DDoS i wyłączeniu stron

Dziękujemy, że przeczytałaś/eś nasz artykuł do końca.

Bądź na bieżąco! Obserwuj nas w Wiadomościach Google. 

Jesteśmy na Youtube: Bądź z nami na Youtube

Jesteśmy na Facebooku: Bądź z nami na FB

Jesteśmy na platformie X: Bądź z nami na X