Robot AI Meta zajął cały procesor serwera z 20 stronami WordPress

Klient trafił do nas z serwerem, na którym działało około 20 stron WordPress: strony firmowe i sklep internetowy z aukcjami. Procesor był stale zajęty w 100%. Restart pomagał na chwilę. Przed stronami stała zapora, a jej limity były już kilka razy zaostrzane, bez żadnego efektu.

Po restarcie najwięcej zasobów brał sklep: 1,7 rdzenia procesora i 2,3 GB pamięci. Wspólna baza danych pracowała na 74%, dwie inne strony po 60–70%. W logach sklepu powtarzał się jeden podpis: meta-externalagent, czyli robot firmy Meta (Facebook, Instagram), który według Meta zbiera treści m.in. do trenowania sztucznej inteligencji.

Odtworzyliśmy serwer klienta w mniejszej skali: ten sam rodzaj bazy danych, sklep WooCommerce z listą życzeń i 3 000 produktów, dwie strony firmowe obok i ta sama zapora z ustawieniami domyślnymi. Program udawał robota Meta: te same adresy, z których robot korzystał u klienta, z 60 adresów sieci Meta, coraz szybciej.

Mierzyliśmy obciążenie, czas ładowania stron i błędy, a każdą poprawkę sprawdzaliśmy tym samym testem.

Robot nie oglądał produktów, tylko przyciski: „dodaj do koszyka”, „dodaj do listy życzeń”, „sortuj po cenie”, „pokaż 48 produktów”. Każde kliknięcie tworzy nowy adres strony, a kombinacji jest nieskończenie wiele. Dla serwera każdy taki adres to pełna praca: sklep musi przygotować stronę od zera, a „dodanie do koszyka” zapisuje jeszcze nowy koszyk w bazie danych.

Zapora powinna takiego robota spowolnić albo zatrzymać. Nie robiła tego, bo w ustawieniach domyślnych ma listę „zaufanych” sieci, a na tej liście jest sieć Meta. Ruch z zaufanej sieci omija limity, czarne listy i automatyczne blokady.

1. Zapora sama przepuszczała robota. Sieć Meta jest w domyślnych ustawieniach zapory oznaczona jako zaufana. Zaostrzanie limitów nic nie dawało, bo do tego robota limity w ogóle nie miały zastosowania.
2. Lista „złych robotów” w zaporze nie zna tego robota. Blokuje roboty AI innych firm, ale nie ten od Meta.
3. Jeden sklep psuje wszystkie strony. Strony dzieliły jedną bazę danych. Gdy sklep pod robotem zajął wszystkie połączenia, inne strony firmowe pokazywały błąd, choć nikt ich nie atakował.
4. „Nie podążaj za tym linkiem” nie działa. Przyciski „dodaj do koszyka” mają oznaczenie, że roboty nie powinny ich klikać. Ten robot klikał je mimo to.
5. WordPress w szczycie sam dokłada sobie pracy. Przy przeciążeniu strona kilkadziesiąt razy na sekundę uruchamiała swoje zadania w tle, zamiast raz na minutę.
6. Zablokowanie tego robota nie psuje Facebooka. Podgląd linku przy udostępnianiu robi inny robot Meta. Po zmianie podgląd dalej działa.

• Zapora zatrzymuje robota meta-externalagent na wejściu i nie traktuje już całej sieci Meta jako zaufanej. Podgląd linków na Facebooku działa dalej.
• Jedna strona nie może zająć całej bazy danych, a zadania w tle WordPressa uruchamia zegar systemowy, a nie ruch na stronie. To zabezpieczenie na wypadek kolejnego robota, którego jeszcze nikt nie zna.

• Zapora, która „jest”, to nie to samo co zapora, która chroni. Ustawienia domyślne mogą przepuszczać właśnie ten ruch, który robi szkodę.
• Roboty sztucznej inteligencji to nowy rodzaj ruchu. Są uprzejme w nazwie, ale potrafią obciążyć serwer bardziej niż wszyscy klienci razem.
• Wiele stron na jednym serwerze potrzebuje przegród: jedna strona pod obciążeniem nie może zabrać bazy pozostałym. Jak wygląda sklep, któremu zabrakło połączeń z bazą, pokazujemy w teście sklepu WooCommerce pod obciążeniem.
• Hosting powinien patrzeć w logi, a nie tylko zaostrzać limity. Tu jedna linia w logu zapory wyjaśniła miesiące problemów.

Twój serwer albo sklep stoi, a restart pomaga tylko na chwilę? Opisz objawy w formularzu, a sprawdzimy logi i konfigurację. Więcej o tym, jak prowadzimy hosting stron WordPress, budujemy sklepy internetowe i jak przebiega naprawa strony WordPress.