Czym jest xmlrpc.php i jak wyłączyć XML-RPC w WordPressie?

Dlaczego to ważne

XML-RPC to stary interfejs do zdalnego sterowania WordPressem. Zanim powstało REST API, właśnie przez niego edytory desktopowe i aplikacje mobilne publikowały wpisy. Nadal jest dostarczany z każdą witryną WordPress pod adresem /xmlrpc.php i nadal przyjmuje nazwę użytkownika i hasło z każdym żądaniem.

To sprawia, że jest drugimi drzwiami logowania. Ukrycie wp-login.php w ogóle go nie dotyka. Kod limitujący logowanie, który obserwuje tylko formularz logowania, go nie widzi. A dzięki system.multicall jedno żądanie HTTP może zawierać setki prób haseł. Limit liczący żądania widzi jedną próbę tam, gdzie było ich pięćset.

To nie teoria. Zbudowaliśmy tę warstwę po tym, jak sklep wciąż otrzymywał próby haseł przez XML-RPC, choć jego strona logowania była już ukryta.

Czy używasz XML-RPC? Prawdopodobnie nie, jeśli nic z poniższych Cię nie dotyczy:

• Łączysz witrynę z Jetpackiem.
• Publikujesz lub moderujesz z oficjalnej aplikacji mobilnej WordPress.
• Używasz starszego desktopowego narzędzia blogowego albo usługi, która prosi o Twoją nazwę użytkownika i hasło WordPress (zamiast hasła aplikacji), aby publikować w Twoim imieniu.
• Zależy Ci na pingbackach z innych blogów.

Jeśli nie masz pewności, zamknij tylko logowanie i zachowaj pingbacki. To usuwa ryzyko zgadywania haseł i zostawia nieszkodliwe elementy. Zawsze możesz później zaostrzyć ustawienia.

Częste błędy

• Ukrycie logowania i poprzestanie na tym. Zgadywanie haseł po prostu przenosi się do xmlrpc.php.
• Blokowanie całego pliku bez sprawdzenia. Jetpack i oficjalna aplikacja mobilna WordPress łączą się przez XML-RPC. Jeśli z nich korzystasz, zamknij tylko metody logowania albo dokładnie przetestuj.
• Ufanie przełącznikowi bez testu. Niektóre metody zostawiają część XML-RPC aktywną. Zawsze sprawdzaj efekt prawdziwym żądaniem (zobacz krok 4 albo sprawdź, co ujawnia Twoja witryna).
• Zapomnienie o warstwie cache. Jeśli reguła CDN już blokuje xmlrpc.php, ustawienie na poziomie WordPressa nie da widocznego efektu. To nic złego — po prostu wiedz, która warstwa wykonuje pracę.

Bez wtyczki

Opcja 1: filtr xmlrpc_enabled. Dodaj to do małej wtyczki obowiązkowej (wp-content/mu-plugins/no-xmlrpc-login.php) albo do functions.php motywu potomnego:

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

To wyłącza metody XML-RPC wymagające logowania. Pingbacki działają dalej, bo go nie potrzebują. Sam filtr nie usuwa jednak system.multicall, a plik nadal odpowiada na żądania. Aby usunąć także metodę multicall:

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

Opcja 2: zablokuj plik na serwerze. Na Apache, w .htaccess:

<Files xmlrpc.php>
  Require all denied
</Files>

Na Nginx: location = /xmlrpc.php { deny all; }. To najsurowsza opcja i nic nie kosztuje serwera, ale wyłącza też pingbacki, Jetpacka i aplikację mobilną, a do tego działa poza WordPressem, więc łatwo o niej zapomnieć przy przenosinach na inny hosting.

Jeśli coś pójdzie nie tak

• Jetpack pokazuje błąd połączenia. Jetpack potrzebuje XML-RPC. Zmień „Wyłącz całkowicie” na „Wyłącz logowanie, zachowaj pingbacki” albo usuń regułę z serwera.
• Aplikacja mobilna WordPress nie może się zalogować. Ta sama przyczyna. Korzystaj z przeglądarki na telefonie albo zezwól na logowanie przez XML-RPC i polegaj na limitach logowania oraz uwierzytelnianiu dwuskładnikowym.
• Narzędzie do publikowania przestało publikować. Sprawdź, czy korzysta z XML-RPC. Większość nowoczesnych narzędzi przeszła na REST API z hasłami aplikacji.

Z Hushfort

Blokada tylnych drzwi należy do Hushfort Pro. Skan powierzchni ataku, który pokazuje, czy XML-RPC jest otwarty, jest w Hushfort Security, darmowej wtyczce bezpieczeństwa WordPress.

Blokada tylnych drzwi jest częścią warstwy Redukcja powierzchni ataku w Hushfort. Daje cztery opcje:

• Wyłącz logowanie, zachowaj pingbacki (zalecane): zgadywanie haseł przez XML-RPC staje się niemożliwe, a pingbacki i trackbacki działają dalej. Dobry wybór dla sklepów.
• Wyłącz całkowicie: najsurowsza opcja. Jetpack i oficjalna aplikacja mobilna nie mogą się połączyć.
• Wyłącz tylko system.multicall: zamyka masowe zgadywanie, resztę zostawia bez zmian.
• Nie zmieniaj: domyślne ustawienie WordPressa.

Skan powierzchni ataku sprawdza potem efekt prawdziwymi żądaniami, więc widzisz to, co widzi ktoś z zewnątrz. Ochrona przed przeciążeniem dodatkowo wycenia żądania do xmlrpc.php wyżej niż zwykłe wyświetlenie strony, co spowalnia pozostały szum.