Xmlrpc.php pod ostrzałem — jak sprawdzić i czy wyłączyć w WordPressie

W poprzednim artykule sprawdzałem logi 404 z highlab.pl i trafiłem na kilka wątków naraz: skanowanie /admin, ciche istnienie /wp-login.php i jeden, bardzo konkretny epizod na /xmlrpc.php — 60 żądań z jednego adresu w niecałe 11 minut, podszywających się pod Jetpacka. Tam był to jeden z kilku dowodów na ogólniejszą tezę. Tutaj jest jedynym tematem, potraktowanym praktycznie: nie „co się dzieje”, tylko „co ja, jako właściciel tej strony, mam z tym zrobić”.

Jeśli nie czytałeś poprzedniego artykułu, krótkie tło znajdziesz niżej — ale sedno tego wpisu jest inne: czy powinieneś wyłączyć xmlrpc.php na swojej stronie, i jak to sprawdzić, zamiast zgadywać.

Czym właściwie jest xmlrpc.php

xmlrpc.php to interfejs, przez który różne narzędzia mogą sterować Twoim WordPressem bez logowania się do panelu przez przeglądarkę. Korzystają z niego m.in.:

• aplikacja mobilna WordPress (publikowanie wpisów z telefonu),
• Jetpack — część jego funkcji (nie wszystkie; nowsze wersje coraz częściej przechodzą na REST API),
• pingbacki i trackbacki — mechanizm, w którym blogi informują się nawzajem o linkowaniu do siebie,
• starsze narzędzia do blogowania (np. Windows Live Writer) — dziś rzadkość, ale wciąż się zdarzają.

Ten plik jest włączony domyślnie w każdej instalacji WordPressa, niezależnie od tego, czy świadomie z niego korzystasz. To ważne, bo oznacza, że masz go „za darmo” razem z ryzykiem, nawet jeśli nigdy o nim nie słyszałeś.

Dlaczego akurat ten plik jest tak łakomym celem

W skrócie (pełne wyjaśnienie z przykładem z moich własnych logów jest w poprzednim artykule): xmlrpc.php obsługuje metodę system.multicall, która pozwala spakować wiele poleceń w jedno żądanie HTTP. Atakujący wykorzystują to do sprawdzenia setek par login/hasło w pojedynczym requeście — z punktu widzenia prostego monitoringu wygląda to jak jedno, niewinne zapytanie, a nie setki prób logowania. Ten sam plik bywa też wykorzystywany do pingback spamu i ataków DDoS reflection.

Jak sprawdzić, czy Twój xmlrpc.php jest celem ataków

Pierwsza pułapka: to się nie pojawi w typowym raporcie błędów 404. xmlrpc.php istnieje naprawdę, więc serwer nie mówi „nie znaleziono” — odpowiada normalnie (zwykle kodem 200), niezależnie od tego, czy podane hasło było poprawne. Żeby to zobaczyć, trzeba zajrzeć do surowych logów serwera (access.log), nie do wtyczki logującej 404.

grep "POST /xmlrpc.php" access.log

Na co zwracać uwagę w wyniku:

• dużo żądań z jednego adresu IP w krótkim czasie,
• User-Agent podszywający się pod Jetpacka/WordPress.com, ale z losową, nieistniejącą domeną w środku (np. http://site27117189.com),
• regularne, „maszynowe” odstępy między żądaniami — nie przypadkowe kliknięcia człowieka.

Tak wyglądał realny przykład z moich własnych logów, opisany szerzej w poprzednim artykule:

09:04:56  POST /xmlrpc.php  200  UA: Jetpack by WordPress.com (Jetpack 13.0; WordPress 6.3)
09:05:06  POST /xmlrpc.php  200  UA: WordPress.com; https://wordpress.com
09:05:17  POST /xmlrpc.php  200  UA: Jetpack/13.0; WordPress/6.3; http://site27117189.com
09:05:27  POST /xmlrpc.php  200  UA: WordPress.com; https://wordpress.com
09:05:37  POST /xmlrpc.php  200  UA: Jetpack/12.0; WordPress/6.4; http://site59128473.com
…w sumie 60 żądań, 32 różne warianty UA, odstępy ~10 sekund…

Prawdziwy Jetpack nie zmienia swojej tożsamości co dziesięć sekund i nie podpisuje się losową domeną.

Zanim wyłączysz: sprawdź, czy możesz sobie na to pozwolić

Wyłączenie xmlrpc.php „na wszelki wypadek” może zepsuć coś, z czego faktycznie korzystasz. Zanim ruszysz dalej, ustal:

• Czy używasz Jetpacka? Sprawdź, z których jego funkcji korzystasz — część (starsze wersje synchronizacji, niektóre widżety) nadal opiera się o XML-RPC, część już przeszła na REST API.
• Czy publikujesz z aplikacji mobilnej WordPress? Ona też korzysta z tego interfejsu.
• Czy zależy Ci na pingbackach/trackbackach? Jeśli nie wiesz, co to jest, prawdopodobnie ich nie potrzebujesz.
• Czy używasz starszego narzędzia do blogowania (Windows Live Writer i podobne)? Dziś rzadkość, ale warto wykluczyć.

Praktyczny sposób sprawdzenia: przejrzyj te same logi co wyżej i zobacz, czy oprócz podejrzanych wpisów są tam też żądania z Twoich własnych, znanych adresów IP albo z prawdziwego Jetpacka (bez losowej domeny w User-Agencie).

Jak wyłączyć (albo ograniczyć) xmlrpc.php

Trzy poziomy, od najprostszego do najbardziej precyzyjnego — wybierz jeden, nie wszystkie naraz.

1. Najprostszy: filtr w functions.php

Wyłącza XML-RPC funkcjonalnie — plik nadal odpowiada, ale nic nie robi. Dobry wybór, jeśli z niczego wymienionego wyżej nie korzystasz.

add_filter( 'xmlrpc_enabled', '__return_false' );

2. Twardszy: blokada na poziomie serwera

Serwer odrzuca żądanie, zanim w ogóle dotrze do WordPressa — mniejsze obciążenie przy większym ruchu ataku niż wariant z functions.php.

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

3. Selektywny: zablokuj tylko system.multicall

Najbezpieczniejszy kompromis, jeśli korzystasz z Jetpacka albo innej integracji opartej o XML-RPC — reszta interfejsu działa normalnie, znika tylko metoda odpowiedzialna za masowe zgadywanie haseł.

add_filter( 'xmlrpc_methods', function ( $methods ) {
	unset( $methods['system.multicall'] );
	return $methods;
} );

Wtyczki robiące to samo też istnieją — jeśli wolisz takie rozwiązanie, sprawdź datę ostatniej aktualizacji przed instalacją (nieaktualizowana wtyczka bezpieczeństwa to gorszy wybór niż jej brak).

Jak sprawdzić, czy wyłączenie zadziałało

Prosty test z terminala — kod odpowiedzi powinien się zmienić z 200 na 403 (blokada serwera) albo na komunikat o wyłączonym XML-RPC (filtr w functions.php):

curl -I -X POST https://twoja-domena.pl/xmlrpc.php

Potem obserwuj logi przez tydzień — sprawdź, czy ruch do tego adresu faktycznie zniknął, czy tylko przeniósł się gdzie indziej (najczęściej na /wp-login.php).

FAQ

Podsumowanie

xmlrpc.php to nie „zawsze wyłącz od razu”, tylko „sprawdź, z czego korzystasz, i podejmij świadomą decyzję”. Jeśli nic z wymienionego wyżej Cię nie dotyczy — pełne wyłączenie jest najprostsze i najbezpieczniejsze. Jeśli używasz Jetpacka albo podobnej integracji — wariant selektywny daje Ci ochronę bez ryzyka, że coś przestanie działać.

Pełniejszy kontekst tego, dlaczego w ogóle zacząłem to sprawdzać (i co jeszcze znalazłem w logach 404) — w poprzednim artykule.