Jak wyłączyć xmlrpc w WordPress?

Aktywne xmlrpc.php może ułatwiać ataki brute-force przez system.multicall oraz nadużycia pingbacków. Jeśli nie korzystasz z aplikacji mobilnej WordPress, Jetpacka ani integracji wymagającej XML-RPC, najlepiej zablokować ten punkt końcowy. Najwydajniejsza jest blokada na poziomie serwera, a nie przez PHP lub wtyczkę.

Kiedy nie wyłączać XML-RPC?

XML-RPC służy do zdalnego wykonywania operacji w WordPressie, między innymi publikowania wpisów, obsługi komentarzy i komunikacji z wybranymi usługami. Nowsze integracje mogą korzystać z WordPress REST API, ale nie każda starsza aplikacja została na nie przeniesiona.

Przed wprowadzeniem blokady sprawdź, czy Twoja witryna nie zależy od któregoś z tych rozwiązań:

• oficjalna aplikacja mobilna WordPress używana do zarządzania samodzielnie hostowaną witryną,
• Jetpack lub jego moduły komunikujące się z witryną przez XML-RPC,
• starsze aplikacje do zdalnego publikowania treści,
• zewnętrzne automatyzacje, skrypty i narzędzia, które nie obsługują REST API.

Jeżeli XML-RPC jest potrzebne, rozważ ograniczenie jego funkcji, na przykład wyłączenie pingbacków i metody system.multicall, zamiast blokowania całego pliku.

Którą metodę wyłączenia wybrać?

Blokada na poziomie Apache lub Nginx odrzuca żądanie przed uruchomieniem WordPressa i PHP. Wtyczka oraz filtr w functions.php są łatwiejsze do wdrożenia, ale nadal obciążają aplikację obsługą przychodzącego żądania.

Nie używaj reguł .htaccess na serwerze Nginx, ponieważ Nginx nie odczytuje tego pliku. W takim środowisku zmianę trzeba wprowadzić w konfiguracji bloku server.

Jak wyłączyć xmlrpc.php?

Wtyczka

To najprostsza metoda na hostingu współdzielonym. Nie wymaga edycji konfiguracji serwera, ale blokada działa dopiero po uruchomieniu WordPressa.

1. Otwórz w panelu WordPress sekcję Wtyczki → Dodaj nową.
2. Wyszukaj sprawdzoną wtyczkę przeznaczoną do wyłączania XML-RPC.
3. Zainstaluj ją i aktywuj.
4. Jeśli wtyczka ma osobne ustawienia, włącz całkowite blokowanie XML-RPC i zapisz zmiany.

Przed instalacją sprawdź autora, datę ostatniej aktualizacji i zgodność z używaną wersją WordPressa. Wtyczka jest wygodna, lecz podczas dużego ataku nie chroni zasobów serwera tak dobrze jak reguła Apache lub Nginx.

Apache i plik .htaccess

Ta metoda blokuje dostęp do xmlrpc.php przed przekazaniem żądania do PHP. Przed edycją wykonaj kopię zapasową pliku .htaccess, ponieważ błąd składni może spowodować błąd 500.

1. Połącz się z serwerem przez SFTP, FTP albo menedżer plików hostingu.
2. Otwórz plik .htaccess w katalogu głównym WordPressa, zwykle obok wp-config.php.
3. Dodaj regułę blokującą dostęp do pliku.
4. Zapisz zmiany i sprawdź działanie strony oraz panelu administracyjnego.

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

Składnia Order Deny,Allow jest typowa dla starszych konfiguracji Apache. Na serwerach korzystających z Apache 2.4 reguły mogą wymagać składni opartej na dyrektywie Require, zależnie od konfiguracji hostingu:

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

Nginx

Na Nginx regułę dodaje się bezpośrednio w konfiguracji witryny, wewnątrz bloku server. Nie edytuj w tym celu .htaccess.

1. Otwórz konfigurację serwera dla swojej domeny, na przykład plik w katalogu /etc/nginx/sites-available/.
2. W bloku server {} dodaj lokalizację wskazującą dokładnie plik xmlrpc.php.
3. Sprawdź konfigurację poleceniem testowym.
4. Przeładuj Nginx bez zatrzymywania serwera.

location = /xmlrpc.php {
    access_log off;
    log_not_found off;
    return 444;
}

sudo nginx -t && sudo systemctl reload nginx

Kod 444 jest charakterystyczny dla Nginx i oznacza zamknięcie połączenia bez standardowej odpowiedzi HTTP. Jeśli wolisz czytelny komunikat dla klienta, możesz użyć deny all, co zwykle kończy się odpowiedzią 403:

location = /xmlrpc.php {
    deny all;
}

Filtr w functions.php

Jeżeli nie masz dostępu do konfiguracji serwera, możesz wyłączyć XML-RPC na poziomie WordPressa. Najbezpieczniej dodać kod do motywu potomnego albo do wtyczki przeznaczonej dla konkretnej witryny. Zmiany w motywie nadrzędnym mogą zostać utracone podczas aktualizacji.

1. Otwórz plik functions.php motywu potomnego lub użyj narzędzia do zarządzania własnymi fragmentami kodu.
2. Dodaj filtr wyłączający XML-RPC.
3. Zapisz zmiany i sprawdź stronę.
4. Jeśli wystąpi błąd, usuń dodany fragment przez SFTP lub panel hostingu.

add_filter( 'xmlrpc_enabled', '__return_false' );

Filtr działa w warstwie aplikacji. Serwer nadal przyjmuje żądanie i uruchamia część WordPressa, dlatego podczas intensywnego ruchu blokada jest mniej wydajna niż reguła Apache lub Nginx.

Selektywne wyłączenie pingbacków

Jeśli musisz zachować XML-RPC na potrzeby Jetpacka lub zdalnego publikowania, możesz wyłączyć funkcje pingbacków. Kod dodaj do motywu potomnego albo wtyczki specyficznej dla witryny:

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Takie rozwiązanie ogranicza część zagrożeń, ale nie zastępuje pełnej blokady XML-RPC. Przy pozostawionym punkcie końcowym nadal trzeba stosować HTTPS, ograniczanie żądań i monitoring logów.

Jak sprawdzić, czy blokada działa?

Uruchom w terminalu poniższą komendę, zastępując domenę własnym adresem:

curl -s -o /dev/null -w "%{http_code}\n" \
-X POST https://example.com/xmlrpc.php

Odpowiedź 403 potwierdza blokadę HTTP. W konfiguracji Nginx z return 444 połączenie może zostać zamknięte bez kodu HTTP, a cURL często zwróci 000. Kod 200 oznacza, że punkt końcowy nadal odpowiada i reguła nie działa tak, jak zakładano.

Po zmianie sprawdź także działanie strony, logowanie do panelu i integracje. Blokada xmlrpc.php nie wyłącza WordPress REST API dostępnego zwykle pod ścieżką /wp-json/. Oba mechanizmy są od siebie niezależne.

Co sprawdzić po wyłączeniu?

Przed zakończeniem konfiguracji przejdź przez krótką listę kontrolną:

• Sprawdź, czy witryna nie korzysta z aplikacji mobilnej WordPress, Jetpacka ani automatyzacji wymagającej XML-RPC.
• Zweryfikuj blokadę poleceniem cURL i sprawdź oczekiwany kod odpowiedzi.
• Upewnij się, że nowe integracje korzystają z REST API, haseł aplikacji lub innego kontrolowanego mechanizmu uwierzytelniania.
• Wymuś HTTPS i monitoruj logi pod kątem powtarzających się żądań POST do xmlrpc.php.
• Jeśli atak ma dużą skalę, zastosuj WAF lub reguły ograniczania ruchu na poziomie serwera i CDN.

Dla większości stron WordPress najlepszym wyborem jest blokada na poziomie Apache lub Nginx. Wtyczka albo filtr PHP sprawdzą się wtedy, gdy nie masz dostępu do serwera. Jeżeli XML-RPC jest potrzebne, ogranicz jego funkcje i migruj integracje do REST API zamiast pozostawiać cały punkt końcowy bez dodatkowych zabezpieczeń.