złośliwe boty

Złośliwe boty to zautomatyzowany ruch, który nie służy ani ludziom, ani wyszukiwarkom, tylko nadużywa strony: szuka w niej luk, zgaduje hasła, kopiuje treści, wysyła spam przez formularze. OWASP opisuje to zjawisko jako niechciane automatyczne użycie aplikacji webowych, które zwykle polega na nadużyciu jej zwykłych, poprawnie działających funkcji, a nie na wykorzystaniu podatności ^[1]. Według raportu Thales Bad Bot Report 2026, przytoczonego przez Polski Przemysł, boty generują 53 procent ruchu w internecie, a 40 procent ruchu to złe boty ^[8].

Jak działa

Bot to program, który wysyła żądania HTTP bez udziału człowieka. Dobry bot, na przykład robot wyszukiwarki, przedstawia się w nagłówku User-Agent i respektuje plik robots.txt. Złośliwy bot robi jedno albo drugie tylko wtedy, gdy mu się to opłaca. Standard RFC 9309 mówi wprost, że reguły z pliku robots.txt nie są formą autoryzacji dostępu i nie zastępują zabezpieczeń treści ^[5]. Dodaje też, że wypisanie ścieżek w tym pliku czyni je publicznie znanymi ^[5].

Złośliwe boty często podszywają się pod roboty wyszukiwarek, bo te rzadko są blokowane. Google ostrzega, że spamerzy odwiedzają strony, podając się za Google, i zaleca sprawdzenie adresu IP odwrotnym zapytaniem DNS, a potem zapytaniem w przód, albo porównanie go z publikowanymi listami adresów ^[6]. Sama nazwa w User-Agent niczego więc nie dowodzi.

Typowa kampania botów przeciw stronie WordPress przebiega etapami, jak na schemacie poniżej.

RYS. 1Kampania botów przeciw stronie

Duża część ruchu pochodzi z botnetów, czyli przejętych komputerów i serwerów sterowanych centralnie. Każdy węzeł wysyła niewiele żądań, więc prosta blokada pojedynczych adresów IP działa słabo.

Rodzaje

Katalog OWASP nadaje zautomatyzowanym zagrożeniom kody OAT i nazwy, żeby różne zespoły opisywały je tym samym językiem ^[1]. Dla strony firmowej albo sklepu na WordPressie najważniejsze są poniższe.

Skanowanie podatności według OWASP polega na przeszukiwaniu i testowaniu aplikacji w celu znalezienia słabości ^[2]; szerzej opisuje je hasło skanowanie podatności. W sklepach pojawia się też testowanie kart, a w komentarzach i formularzach spam w komentarzach.

W WordPressie

WordPress ma kilka stałych adresów, które boty znają na pamięć. Najczęściej odpytywane są strona logowania wp-login.php, plik xmlrpc.php i ścieżki do katalogów wtyczek. Dokumentacja WordPressa wskazuje, że XML-RPC jest częstym celem ataków siłowych, zwłaszcza przez metodę system.multicall, i zaleca jego wyłączenie, jeśli strona go nie używa ^[7].

Atak siłowy (brute force) to według tej samej dokumentacji najprostszy sposób włamania: powtarzanie kombinacji loginu i hasła, aż któraś zadziała ^[7]. Ponieważ próby są zautomatyzowane i często rozproszone między botnety, nawet nieudany atak może przeciążyć stronę żądaniami ^[7]. Wtyczki broniące logowania działają wewnątrz PHP, więc przy silnym ataku same zużywają zasoby serwera ^[7].

Boty zbierają też nazwy kont, co opisuje hasło enumeracja użytkowników. Skanery sprawdzają wersje wtyczek i motywów, a potem porównują je z bazami znanych luk.

Zagrożenia i skutki

• Przejęcie konta. Udane zgadnięcie hasła albo trafienie parą z wycieku daje dostęp do panelu; zob. przejęcie konta.
• Obciążenie serwera. Tysiące żądań na minutę spowalniają stronę, a w skrajnym przypadku działają jak DDoS.
• Kradzież treści i cen. Scraping pozwala konkurencji albo oszustom kopiować opisy, cenniki i całe strony ^[3].
• Zafałszowane statystyki. Ruch botów zawyża liczbę odwiedzin i psuje dane o konwersji.
• Wejście dla dalszego ataku. Skaner, który znajdzie nieaktualną wtyczkę, przekazuje adres do właściwego ataku.

Raport Thales, według omówienia w Polskim Przemyśle, podaje, że w 2025 roku zablokowano 17,2 biliona żądań złośliwych botów, a liczba codziennych ataków opartych na AI wzrosła z 2 do 25 milionów ^[8].

Jak się bronić

Najlepiej zatrzymywać boty przed serwerem aplikacji. Dokumentacja WordPressa zaleca ograniczanie liczby prób logowania na brzegu sieci albo na poziomie serwera i podaje przykład reguły Nginx z limitem rate=10r/m ^[7]. Zapora aplikacyjna albo sieć CDN blokuje ruch, zanim dotrze do serwera, co oszczędza jego zasoby przy dużym ataku ^[7]. Dokumentacja poleca też uwierzytelnianie dwuskładnikowe zamiast starszych reguł w .htaccess ^[7].

• rate limiting i limit prób logowania na serwerze albo w reverse proxy.
• WAF i CDN z regułami dla znanych botów.
• CAPTCHA na formularzach, gdzie boty wysyłają spam.
• uwierzytelnianie dwuskładnikowe dla kont z uprawnieniami administratora.
• fail2ban albo podobne narzędzie, które blokuje adresy po serii błędów w logach.
• Wyłączenie XML-RPC, jeśli nie jest potrzebny ^[7].

Weryfikację robotów wyszukiwarek warto oprzeć na DNS i listach adresów, nie na nazwie w User-Agent ^[6]. Pliku robots.txt nie należy traktować jako zabezpieczenia: nie blokuje dostępu, a może wskazać ukryte ścieżki ^[5].

Historia i przykłady

Projekt OWASP Automated Threats powstał, bo zautomatyzowane nadużycia często były źle nazywane i niedostatecznie zgłaszane, a nie mieszczą się na listach podatności takich jak OWASP Top 10 ^[1]. Katalog OAT daje im wspólne kody, od OAT-001 do OAT-021 ^[2]. Coroczne raporty o ruchu botów, takie jak raport Thales opisany przez Polski Przemysł w maju 2026 roku, pokazują, że automatyczny ruch przewyższa już ruch ludzi ^[8].