Jak wyłączyć XML-RPC w WordPressie dla bezpieczeństwa

XML-RPC to stary interfejs w WordPressie – plik xmlrpc.php leżący w głównym katalogu strony. Kiedyś służył do łączenia się ze stroną z zewnątrz, na przykład ze starej aplikacji mobilnej WordPress albo z wtyczki Jetpack. Dziś większość tych funkcji WordPress obsługuje za pomocą nowszego REST API, więc u wielu właścicieli stron XML-RPC został tylko jako otwarta furtka, z której nikt już nie korzysta. Problem w tym, że metoda system.multicall pozwala w jednym żądaniu sprawdzić setki haseł naraz, więc XML-RPC to ulubione narzędzie botów do ataków brute-force na logowanie. Bywa też wykorzystywany do ataków DDoS typu pingback, w których Twoja strona bez Twojej wiedzy rozsyła żądania do innych serwerów. Jeśli nie korzystasz z Jetpacka opartego o XML-RPC ani ze starej aplikacji mobilnej, możesz ten interfejs bezpiecznie wyłączyć. Ten poradnik pokazuje, jak to zrobić trzema różnymi sposobami – wybierz ten, który pasuje do Twojej strony i poziomu wygody.

1. Sprawdź, czy na pewno nie potrzebujesz XML-RPC. Zanim cokolwiek wyłączysz, upewnij się, że nie korzystasz z niczego, co go wymaga. Najczęstsze przypadki to: stara aplikacja mobilna WordPress (logowanie do panelu przez telefon w wersji sprzed kilku lat), wtyczka Jetpack skonfigurowana w starszy sposób – przez XML-RPC zamiast tokenu – oraz publikowanie wpisów zdalnie z zewnętrznych programów, na przykład niektórych klientów blogowych. Jeśli żadna z tych sytuacji Cię nie dotyczy, przejdź do kolejnego kroku.
2. Sprawdź, czy XML-RPC jest obecnie aktywny na Twojej stronie. Wpisz w przeglądarce adres swojej strony z dopiskiem /xmlrpc.php, na przykład twojadomena.pl/xmlrpc.php. Jeśli zobaczysz komunikat „XML-RPC server accepts POST requests only.”, interfejs działa i jest dostępny publicznie. Jeśli zamiast tego pojawi się błąd 403 (Forbidden) lub 404 (Not Found), XML-RPC jest już zablokowany i dalsze kroki nie są konieczne.
3. Zainstaluj wtyczkę bezpieczeństwa i wyłącz przez nią XML-RPC – to najprostsza metoda, szczególnie jeśli nie czujesz się pewnie w plikach serwera. W panelu wp-admin przejdź do Wtyczki → Dodaj nową, zainstaluj i aktywuj jedną z popularnych wtyczek bezpieczeństwa (na przykład Wordfence lub podobną o zbliżonej funkcji). W jej ustawieniach poszukaj sekcji dotyczącej firewalla albo ochrony WordPressa i zaznacz tam opcję blokowania lub wyłączenia XML-RPC. Zapisz ustawienia.
4. Jeśli wolisz nie instalować dodatkowej wtyczki, zrób kopię zapasową pliku .htaccess przed ręczną edycją. Zaloguj się do panelu hostingowego, otwórz menedżer plików (albo połącz się przez FTP) i znajdź plik .htaccess w głównym katalogu strony – tam, gdzie znajdują się foldery wp-admin, wp-content i wp-includes. Pobierz kopię tego pliku na dysk, zanim zaczniesz go zmieniać, żeby móc łatwo wrócić do poprzedniej wersji.
5. Dodaj do pliku .htaccess regułę blokującą dostęp do xmlrpc.php. Otwórz plik w edytorze tekstu z panelu hostingowego (lub lokalnie, jeśli pobrałeś go przez FTP) i dopisz na końcu, po sekcji reguł WordPressa, następujący fragment:
   

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

   Zapisz plik i wgraj go z powrotem na serwer, jeśli edytowałeś go lokalnie.
6. Sprawdź w panelu hostingowym, czy jest dostępna wbudowana opcja blokowania XML-RPC na poziomie serwera. Część firm hostingowych ma w panelu klienta (na przykład cPanel, DirectAdmin lub własnym panelu) sekcję związaną z zaporą aplikacji (WAF) albo dodatkową ochroną WordPressa, gdzie blokadę XML-RPC włącza się jednym przełącznikiem, niezależnie od ustawień w samym WordPressie. Jeśli nie wiesz, czy taka opcja istnieje na Twoim hostingu, sprawdź dział pomocy albo napisz wprost do supportu z pytaniem o blokadę XML-RPC.
7. Wyczyść cache strony i cache po stronie hostingu. Jeśli masz aktywną wtyczkę do cache'owania albo Twój hosting stosuje własny cache po stronie serwera, wyczyść go zaraz po wprowadzeniu zmian. Bez tego przeglądarka albo serwer mogą jeszcze przez jakiś czas pokazywać starą, niezablokowaną wersję strony, co utrudni sprawdzenie, czy blokada zadziałała.
8. Zweryfikuj, że XML-RPC jest faktycznie zablokowany. Wróć do adresu twojadomena.pl/xmlrpc.php i otwórz go ponownie, najlepiej w oknie incognito, żeby mieć pewność, że nie patrzysz na wersję z cache przeglądarki. Tym razem powinieneś zobaczyć błąd 403 (Forbidden) zamiast komunikatu o serwerze XML-RPC – to znak, że blokada działa poprawnie.

Co zrobić, gdy coś pójdzie nie tak

Po zablokowaniu XML-RPC przestał działać Jetpack – statystyki, powiadomienia albo publikowanie z aplikacji mobilnej Jetpack nagle się wysypują. Część starszych funkcji Jetpacka faktycznie potrzebuje XML-RPC do komunikacji z serwerami WordPress.com. Jeśli korzystasz z Jetpacka i po blokadzie coś przestało działać, cofnij zmianę – wyłącz regułę w .htaccess (usuń dodany fragment) albo wyłącz blokadę w ustawieniach wtyczki bezpieczeństwa – i zostaw XML-RPC włączony, dopóki nie znajdziesz sposobu, żeby Jetpack łączył się bez niego.

Stara aplikacja mobilna WordPress przestała się łączyć ze stroną – logowanie w aplikacji kończy się błędem połączenia. Starsze wersje aplikacji WordPress na telefon rzeczywiście korzystają z XML-RPC do logowania i publikowania. Jeśli używasz takiej aplikacji, masz dwie opcje: zaktualizować ją do najnowszej wersji korzystającej z REST API, albo cofnąć blokadę XML-RPC i zamiast tego zabezpieczyć się innymi metodami, na przykład ograniczeniem liczby prób logowania.

Reguła w .htaccess spowodowała błąd 500 (Internal Server Error) na całej stronie – strona przestała się wczytywać zaraz po zapisaniu pliku. Zwykle oznacza to literówkę w regule albo że Twój hosting nie działa na serwerze Apache (reguły .htaccess nie zadziałają np. na czystym Nginx). W takiej sytuacji wgraj z powrotem kopię zapasową pliku .htaccess, którą zrobiłeś w kroku 4, żeby strona natychmiast wróciła do działania, a następnie sprawdź w panelu hostingowym lub u supportu, czy Twój serwer w ogóle obsługuje reguły .htaccess – jeśli nie, użyj zamiast tego metody z wtyczką bezpieczeństwa albo opcji w panelu hostingowym.