Anatomia szumu internetowego na żywym organizmie. Co logi 404 mówią o botach, skanerach i rekonesansie sieciowym?

Wstęp

Istnieje zjawisko, którego nie widać z perspektywy zwykłego użytkownika, ale które doskonale widać w logach serwera: Internet Background Noise, czyli internetowy szum tła.

To stały, maszynowy ruch generowany przez skanery podatności, boty rekonesansowe, crawlery platform społecznościowych oraz automaty sprawdzające, czy publiczna domena nie wystawia znanych punktów wejścia.

Każda domena publicznie dostępna w sieci zaczyna dostawać taki ruch niemal natychmiast po delegacji DNS. Nie ma znaczenia, czy witryna jest mała, nowa czy niszowa. Wystarczy, że odpowiada na żądania HTTP. Resztę zrobią boty.

Poniżej analizuję realny wycinek logów 404 zbieranych przez mój własny router w Hummi CMS - bezbazodanowym frameworku/CMS typu flat-file. Router zapisuje każde nietrafione żądanie jako 404 INFO wraz z adresem IP i nagłówkiem User-Agent.

Próbka po filtracji

Po odrzuceniu zdarzeń systemowych, ruchu Google i własnych testów zostaje 50 zewnętrznych zdarzeń 404 z kilku dni. To bardzo mała próbka czasowa, a mimo to widać pełne spektrum zachowań charakterystycznych dla publicznej sieci.

• 9 zapytań do REST API WordPressa i wtyczki Gravity SMTP


• 13 prób odczytu plików .env oraz wariantów sendgrid.env


• 7 zapytań enumerujących strony kontaktowe w różnych językach


• 5 rozproszonych sond na /wp-login.php


• 3 próby wykrycia adminer.php


• 3 próby trafienia w ścieżkę /wp-content/plugins/fix/up.php


• 2 żądania rozpoznające technologię CMS: WordPress i Joomla


• pozostałe: ruch integracyjny Apple i Meta, pojedyncze sondy w inne pliki

Kod 404 Not Found wcale nie oznacza, że log jest nieistotny. W dobrze zaprojektowanym systemie 404 jest bardzo tanią, ale wartościową telemetrią. Pokazuje, czego internet aktualnie szuka.

Fragment logów

[2026-06-15 02:36:50] [404 INFO] Router: /wp-json/gravitysmtp/v1/settings | IP: 34.159.x.x
[2026-06-15 06:00:07] [404 INFO] Router: /sendgrid.env | IP: 35.228.x.x
[2026-06-16 20:38:58] [404 INFO] Router: /txets.php | IP: 68.66.x.x
[2026-06-17 14:51:31] [404 INFO] Router: /adminer.php | IP: 81.199.x.x
[2026-06-18 02:54:45] [404 INFO] Router: /wp-login.php | IP: 134.209.x.x
[2026-06-20 12:38:41] [404 INFO] Router: /wp-includes/css/buttons.css | IP: 35.88.x.x
[2026-06-20 12:38:42] [404 INFO] Router: /media/system/js/core.js | IP: 35.88.x.x

1. Rekonesans technologiczny: sondowanie endpointów CMS

Najbardziej oczywisty wzorzec to zapytania o ścieżki związane z WordPressem: /wp-login.php, /wp-json/wp/v2/settings, /wp-json/gravitysmtp/v1/*, /wp-content/plugins/fix/up.php.

To nie jest ruch użytkownika. To rekonesans technologiczny - faza, w której automat próbuje odpowiedzieć na jedno pytanie: jaki CMS stoi za tą domeną?

WordPress napędza bardzo dużą część internetu i właśnie dlatego jest najczęściej sondowaną platformą. To nie kwestia bezpieczeństwa samego WordPressa - to kwestia statystyki. Sondowanie pod najpopularniejszy CMS daje automatowi najwyższą szansę na trafienie.

Ścieżka /wp-login.php pojawia się pięć razy z różnych IP w odstępie kilkudziesięciu godzin. Serwis nie wystawia takiego endpointu i od razu zwraca 404. Ale właśnie tak wygląda typowy etap zerowy kampanii rekonesansowych - automat sprawdza, czy panel logowania istnieje. Jeśli dostaje 200 lub 302, cel trafia do kolejki dalszego przetwarzania.

Osobna warstwa to /wp-content/plugins/fix/up.php. Taka ścieżka nie jest typowym zasobem frontendu - bardziej przypomina artefakt po wcześniejszym incydencie, plik maskowany jako element katalogu wtyczki. Trzy żądania z dwóch IP w jednej minucie to czytelny sygnał sygnaturowego skanowania.

2. Polowanie na sekrety środowiskowe

Najbardziej agresywny mikrowzorzec w tej próbce to seria trzynastu zapytań z prefiksu 35.228.x.x wykonanych w ciągu kilku sekund:

[2026-06-15 06:00:06] [404 INFO] Router: /env.backup | IP: 35.228.x.x

[2026-06-15 06:00:07] [404 INFO] Router: /env.bak | IP: 35.228.x.x

[2026-06-15 06:00:07] [404 INFO] Router: /env | IP: 35.228.x.x

[2026-06-15 06:00:07] [404 INFO] Router: /sendgrid.env | IP: 35.228.x.x

[2026-06-15 06:00:07] [404 INFO] Router: /api/sendgrid.env | IP: 35.228.x.x

[2026-06-15 06:00:09] [404 INFO] Router: /backend/sendgrid.env | IP: 35.228.x.x

Książkowy przykład automatu szukającego wycieku sekretów: danych SMTP, tokenów SendGrid, haseł do bazy, kluczy API. Jeżeli aplikacja przez nieuwagę wystawi plik .env, atakujący nie potrzebuje żadnego zero-daya - dostaje gotowy zestaw poświadczeń.

Boty stosują tu własny cache-busting: rotują rozszerzenia (.bak, .old, .backup), katalogi (/api, /src, /backend) i nazwy plików. Nawet przy sensownym cache'u aplikacyjnym taka rotacja wymusza ciągłe nietrafienia i kosztowne przetwarzanie pustego wyniku.

3. Sondy w narzędzia operatora i obce CMS-y

/adminer.php pojawia się trzy razy z trzech różnych IP. Adminer jest wygodny dla developera, ale publicznie wystawiony bywa katastrofalny - skaner znajduje bezpośredni panel do bazy danych.

/txets.php odpytywane przez python-requests/2.34.2 to sygnaturowe sprawdzanie, czy w systemie nie istnieje plik pozostawiony po infekcji.

Ciekawy jest duet /wp-includes/css/buttons.css i /media/system/js/core.js odpytywany przez Go-http-client/2.0 z jednego IP. To klasyczny cross-CMS fingerprinting - bot sprawdza sygnatury WordPress i Joomla po kolei, szukając jakiegokolwiek trafienia.

Z kolei seria siedmiu ścieżek kontaktowych (/kontakt, /contact, /impressum, /contacto, /contatti...) wykonana w tej samej sekundzie z jednego IP to crawler harvestujący dane kontaktowe. Nie cały szum tła jest sondą techniczną, ale prawie cały jest ruchem nieludzkim.

4. User-Agent jako fałszywa flaga

Z adresu 34.159.x.x w odstępie kilkudziesięciu sekund przychodzą żądania z nagłówkami udającymi Chrome 62 na Windowsie, Mi Browser na Androidzie, Safari 8 na macOS, Iceweasel 3.6 na Linuksie, Firefox 20 i iTunes 4.2 na PowerPC. To statystycznie nierealne dla człowieka.

Rotacja User-Agent ma utrudnić proste reguły blokujące i upodobnić się do ruchu konsumenckiego. Wniosek: nie wolno budować logiki bezpieczeństwa na zaufaniu do User-Agenta. Sygnałem jest zachowanie - częstotliwość, entropia ścieżek, korelacja w czasie.

5. Zderzenie architektur: koszt obsługi szumu przez backend

Najciekawsza część tej historii nie dotyczy samych botów, tylko kosztu ich obsługi. Pytanie brzmi: ile CPU, I/O i czasu workerów kosztuje każde takie pudło?

W klasycznym CMS-ie z pełnym bootstrapem i warstwą SQL nietrafione żądanie bardzo często oznacza: przepisanie ruchu do front controllera, podniesienie silnika PHP, wczytanie konfiguracji i pluginów, odpytanie bazy danych, wyrenderowanie szablonu błędu. W wielu wdrożeniach dodatki inicjalizują również stan sesyjny. Przy większym wolumenie to już nie jest „niewinny 404", tylko cichy resource drain i presja na L7, która podbija średni Time to First Byte legalnym użytkownikom.

W Hummi CMS ścieżka jest znacznie krótsza. Anonimowe żądanie przechodzi przez idempotentny bootstrap: serwer buduje minimalny, typowany kontrakt danych, router działa agnostycznie wobec technologii oczekiwanej przez automat, a jeżeli ścieżki nie ma w mapie - system kończy przetwarzanie na krótkiej odpowiedzi 404. Do logu trafia wpis append-only. Brak SQL, brak ciężkich pluginów, brak sesji w ścieżce anonimowej.

To nie czyni aplikacji magicznie odporną na sieciowy DDoS. Ale na poziomie aplikacji taki model odcina większość niepotrzebnego marnowania zasobów. Lekki backend to realna pierwsza linia obrony przed niskointensywnym resource drain.

6. Jak prawidłowo utwardzać router i warstwę HTTP

• Rate Limiting na brzegu - najlepiej jeszcze przed PHP. Token bucket per IP i per klasa ścieżek ogranicza koszt automatu zanim dotknie aplikacji.


• Wczesne odrzucanie niemożliwych ścieżek - reguły dla /wp-*, /xmlrpc.php, /adminer.php, /.env mogą być ubijane już przez reverse proxy.


• Rygorystyczne typowanie kontraktu danych - router nie powinien pracować na surowym $_SERVER. Lepiej znormalizować URI, metodę i nagłówki do jawnego DTO.


• Brak efektów ubocznych w ścieżce anonimowej - żadnych sesji, zapisów do bazy ani ciężkich modułów dla zwykłego 404.


• Bezpieczne logowanie danych wejściowych - URL i User-Agent to dane wrogie. Trzeba je normalizować i escapować, żeby nie dopuścić do log poisoning.


• Statyczna analiza - router i parser URI powinny przechodzić przez PHPStan/Psalm. To są miejsca, gdzie powstają ukryte błędy brzegowe.

Wnioski

Ta próbka logów jest mała, ale reprezentatywna. W ciągu kilku dni publiczna domena przyciągnęła rekonesans pod popularne CMS-y, polowanie na wycieki .env, sondy pod narzędzia operatorskie i ruch platform społecznościowych. To jest normalny stan internetu. Wystarczy istnieć.

Najważniejszy wniosek jest architektoniczny: 404 nie powinno być drogie. Lekkość backendu, idempotentny bootstrap, agnostyczny routing i rygorystyczny kontrakt danych to elementy obrony - pierwsze, zanim w ogóle zaczniemy mówić o WAF-ach i blacklistach.

Publiczny serwer nigdy nie działa w ciszy. Pytanie nie brzmi, czy boty zapukają. Pytanie brzmi, ile zasobów stracisz na samo otwieranie drzwi.