Jak wyłączyć XML-RPC w WordPress

XML-RPC to protokół zdalnego wywoływania procedur, który WordPress wspiera od swoich wczesnych dni. Plik xmlrpc.php znajduje się w głównym katalogu WordPress i zapewnia API umożliwiające komunikację zewnętrznych aplikacji z witryną. Choć w 2008 było to autentycznie przydatne, gdy nie istniały lepsze alternatywy, REST API (wprowadzone w WordPress 4.7 w grudniu 2016) całkowicie je zastąpiło w legalnych przypadkach użycia. Dziś XML-RPC jest głównie wykorzystywany przez atakujących do prób logowania brute force i ataków wzmacniających DDoS. Jeśli nie używasz Jetpack ani przestarzałego narzędzia do publikowania mobilnego, powinieneś go wyłączyć.

Historia XML-RPC w WordPress

Wsparcie XML-RPC jest częścią WordPress od wersji 1.5 (2005), ale było domyślnie wyłączone. Właściciele witryn musieli ręcznie włączyć je w Ustawieniach, jeśli chcieli używać klientów blogowych na desktop, takich jak Windows Live Writer lub MarsEdit. W WordPress 3.5 (grudzień 2012) interfejs XML-RPC został włączony domyślnie, a opcja wyłączenia go przez interfejs administratora została usunięta. Uzasadnieniem było to, że aplikacje mobilne i usługi zewnętrzne coraz bardziej na nim polegały. Jednak ta decyzja oznaczała również, że każda instalacja WordPress miała teraz otwarty punkt końcowy API, który atakujący mogli atakować.

W WordPress 4.7 (grudzień 2016) REST API stało się częścią rdzenia WordPress. REST API zapewnia nowoczesny, oparty na JSON interfejs, który jest bardziej elastyczny, lepiej udokumentowany i łatwiejszy do zabezpieczenia niż XML-RPC. Aplikacja mobilna WordPress przeszła z XML-RPC na REST API w 2019. W tym momencie jedyną dużą usługą nadal wymagającą XML-RPC był Jetpack, a nawet Jetpack zmniejszył swoją zależność od XML-RPC z czasem.

Jak działa atak brute force system.multicall

Najniebezpieczniejszym aspektem XML-RPC jest metoda system.multicall. Normalne ataki brute force na stronę logowania WordPress próbują jednej kombinacji nazwa użytkownika/hasło na żądanie HTTP. Ograniczanie częstotliwości i wtyczki takie jak Limit Login Attempts mogą skutecznie blokować te ataki, ponieważ każda próba generuje osobne żądanie.

Metoda system.multicall XML-RPC całkowicie zmienia równanie. Atakujący może zgrupować setki, a nawet tysiące prób uwierzytelniania wp.getUsersBlogs w jedno żądanie HTTP. Z perspektywy serwera wygląda to jak jedno żądanie. Z perspektywy atakującego właśnie przetestowali 500 haseł. Wtyczki ograniczające próby logowania działające na poziomie aplikacji często nie wychwytują tych prób, ponieważ widzą tylko jedno przychodzące żądanie.

Oto jak wygląda ładunek multicall brute force:

<?xml version="1.0"?>
<methodCall>
  <methodName>system.multicall</methodName>
  <params>
    <param>
      <value><array><data>
        <value><struct>
          <member>
            <name>methodName</name>
            <value><string>wp.getUsersBlogs</string></value>
          </member>
          <member>
            <name>params</name>
            <value><array><data>
              <value><string>admin</string></value>
              <value><string>password123</string></value>
            </data></array></value>
          </member>
        </struct></value>
        <!-- jeszcze setki prób -->
      </data></array></value>
    </param>
  </params>
</methodCall>

Wzmacnianie DDoS przez pingbacki

Drugim głównym wektorem ataku jest funkcja pingback XML-RPC. Pingbacki to powiadomienia wysyłane między witrynami WordPress, gdy jedna witryna linkuje do innej. Atakujący nadużywają tego, wysyłając sfałszowane żądania pingback do tysięcy witryn WordPress, wszystkie skierowane na jeden docelowy URL. Każda witryna WordPress wysyła następnie żądanie weryfikacyjne do celu, skutecznie przekształcając tysiące instalacji WordPress w rozproszony botnet typu denial-of-service (DDoS). Serwer docelowy jest zalewany przychodzącymi żądaniami od legalnych witryn WordPress, co utrudnia jego blokowanie.

Jak sprawdzić, czy XML-RPC jest obecnie włączony

Przed wprowadzeniem zmian sprawdź, czy XML-RPC jest aktywny w Twojej witrynie. Możesz użyć curl z linii poleceń:

curl -X POST https://yoursite.com/xmlrpc.php   -H "Content-Type: text/xml"   -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Jeśli XML-RPC jest włączony, otrzymasz odpowiedź XML zawierającą wszystkie dostępne metody (zwykle 80+ metod). Jeśli jest wyłączony lub zablokowany, otrzymasz błąd 403 Forbidden, błąd connection refused lub komunikat "XML-RPC server accepts POST requests only" (w zależności od sposobu wyłączenia).

Sprawdzanie logów serwera pod kątem ataków XML-RPC

Przed wyłączeniem XML-RPC warto sprawdzić logi dostępu, aby zobaczyć, czy już jesteś atakowany. Poszukaj żądań POST do xmlrpc.php:

# Log dostępu Apache
grep "xmlrpc.php" /var/log/apache2/access.log | tail -50

# Log dostępu Nginx
grep "xmlrpc.php" /var/log/nginx/access.log | tail -50

# Policz żądania na IP
grep "xmlrpc.php" /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Jeśli widzisz setki lub tysiące żądań POST do xmlrpc.php z różnych adresów IP, Twoja witryna jest aktywnie atakowana. Jest to niezwykle powszechne i kolejny powód, aby całkowicie wyłączyć ten punkt końcowy.

Metoda 1: Blokowanie na poziomie serwera (zalecane)

Blokowanie XML-RPC na poziomie serwera webowego jest najskuteczniejszym podejściem, ponieważ żądanie jest odrzucane, zanim PHP zostanie nawet załadowane. Oszczędza to zasoby serwera i jest podejściem, które powinieneś preferować nad filtrowaniem na poziomie PHP.

Apache (.htaccess)

Dodaj to do pliku .htaccess w katalogu głównym WordPress:

# Blokuj cały dostęp do xmlrpc.php
<Files xmlrpc.php>
    Order deny,allow
    Deny from all
</Files>

Jeśli musisz zezwolić na określone adresy IP (np. jeśli używasz Jetpack), możesz dodać wyjątki:

<Files xmlrpc.php>
    Order deny,allow
    Deny from all
    Allow from 122.248.245.244
    Allow from 54.217.201.243
</Files>

Nginx

Dodaj to w bloku server w konfiguracji Nginx:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

Dyrektywy access_log off i log_not_found off zapobiegają zapełnianiu plików logów zablokowanymi próbami XML-RPC, które na witrynach mocno atakowanych mogą urosnąć do gigabajtów.

Metoda 2: Wyłączenie przez filtr WordPress (poziom PHP)

Jeśli nie możesz modyfikować plików konfiguracyjnych serwera (typowe na hostingu współdzielonym), możesz wyłączyć XML-RPC na poziomie PHP. Dodaj to do functions.php swojego motywu lub, lepiej, do niestandardowej wtyczki must-use:

// Całkowicie wyłącz XML-RPC
add_filter('xmlrpc_enabled', '__return_false');

// Usuń link wykrywania XML-RPC z nagłówka HTML
remove_action('wp_head', 'rsd_link');

// Usuń nagłówek HTTP X-Pingback
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

Ważne: Filtr xmlrpc_enabled wyłącza tylko metody XML-RPC oparte na uwierzytelnianiu. Plik xmlrpc.php nadal się ładuje, PHP nadal jest wykonywane, a metody nieuwierzytelnione (jak pingbacki) mogą nadal działać. Dlatego preferowane jest blokowanie na poziomie serwera. Podejście filtrowe nadal zużywa zasoby serwera do przetwarzania żądania, zanim zostanie ono ostatecznie odrzucone.

Tworzenie wtyczki must-use (zalecane zamiast functions.php)

Zamiast dodawać kod do functions.php (który jest nadpisywany podczas aktualizacji motywu), utwórz wtyczkę must-use. Utwórz plik wp-content/mu-plugins/disable-xmlrpc.php:

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Całkowicie wyłącza funkcjonalność XML-RPC
 */
add_filter('xmlrpc_enabled', '__return_false');
remove_action('wp_head', 'rsd_link');
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

Wtyczki must-use są ładowane przed zwykłymi wtyczkami i nie mogą zostać przypadkowo dezaktywowane przez interfejs administratora.

Metoda 3: Konfiguracja wtyczki bezpieczeństwa

Jeśli używasz wtyczki bezpieczeństwa, takiej jak Wordfence, Sucuri lub iThemes Security, oferują one wbudowane opcje wyłączenia XML-RPC:

• Wordfence: Przejdź do Wordfence > All Options > Brute Force Protection. Firewall automatycznie ogranicza częstotliwość prób uwierzytelniania XML-RPC. Dla pełnego blokowania użyj metody na poziomie serwera powyżej.
• iThemes Security: Przejdź do Security > Settings > WordPress Tweaks. Włącz "Disable XML-RPC", aby całkowicie zablokować, lub wybierz "Disable Pingbacks", aby zablokować tylko wektor nadużyć pingback, zachowując funkcjonalność innych metod XML-RPC.
• Sucuri: Sucuri Web Application Firewall (oparta na chmurze) może blokować XML-RPC na poziomie CDN, zanim żądania w ogóle dotrą do Twojego serwera.

Reguły WAF Cloudflare dla ochrony XML-RPC

Jeśli używasz Cloudflare, możesz utworzyć regułę WAF, która blokuje żądania XML-RPC na krawędzi, zanim w ogóle dotrą do Twojego serwera. Przejdź do Security > WAF > Custom Rules i utwórz regułę:

• Nazwa reguły: Block XML-RPC
• Wyrażenie: (http.request.uri.path contains "/xmlrpc.php")
• Akcja: Block

To najskuteczniejsza metoda blokowania, ponieważ Cloudflare obsługuje żądanie na swoich serwerach edge. Twój serwer origin nigdy nie widzi ruchu. Jeśli musisz zezwolić Jetpack, dodaj wyjątek dla zakresów IP Automattic.

Konfiguracja fail2ban dla XML-RPC brute force

Jeśli zarządzasz własnym serwerem (VPS lub dedykowany), możesz użyć fail2ban, aby automatycznie banować adresy IP wielokrotnie uzyskujące dostęp do xmlrpc.php. Utwórz plik filtra w /etc/fail2ban/filter.d/wordpress-xmlrpc.conf:

[Definition]
failregex = ^<HOST> .* "POST .*xmlrpc.php.*" (200|403)
ignoreregex =

Następnie dodaj jail w /etc/fail2ban/jail.local:

[wordpress-xmlrpc]
enabled = true
port = http,https
filter = wordpress-xmlrpc
logpath = /var/log/apache2/access.log
maxretry = 5
findtime = 60
bantime = 3600

Ta konfiguracja banuje każdy adres IP, który wykonuje więcej niż 5 żądań do xmlrpc.php w ciągu 60 sekund, i blokuje go na godzinę. Dostosuj wartości na podstawie wzorców ruchu.

XML-RPC vs. REST API: porównanie bezpieczeństwa

Zrozumienie, dlaczego REST API jest bezpieczniejsze, pomaga wyjaśnić, dlaczego XML-RPC powinno przejść na emeryturę:

• Uwierzytelnianie: REST API obsługuje wiele metod uwierzytelniania (cookie auth, application passwords, OAuth) i ma wbudowaną weryfikację nonce. XML-RPC wysyła dane uwierzytelniające w postaci tekstu jawnego w ciele XML przy każdym żądaniu.
• Ograniczanie częstotliwości: Żądania REST API mogą być ograniczane per punkt końcowy. Metoda multicall XML-RPC sprawia, że ograniczanie częstotliwości per żądanie jest nieskuteczne.
• Uprawnienia: REST API respektuje kontrole uprawnień WordPress i zapewnia szczegółowe callbacki uprawnień dla każdego punktu końcowego. XML-RPC ma grubsze kontrole dostępu.
• Walidacja wejścia: Punkty końcowe REST API używają walidacji wejścia opartej na schemacie. XML-RPC polega na implementacjach poszczególnych metod do walidacji.
• Brak odpowiednika multicall: REST API nie ma punktu końcowego batch pozwalającego na grupowanie setek prób uwierzytelniania w jedno żądanie.

Sprawdź, czy nadal potrzebujesz XML-RPC przed jego wyłączeniem

Przed wyłączeniem XML-RPC sprawdź, czy żadna z Twoich aktywnych usług go nie wymaga:

• Jetpack: Niektóre funkcje Jetpack nadal komunikują się przez XML-RPC. Jeśli używasz Jetpack, przetestuj witrynę po wyłączeniu XML-RPC. Jeśli funkcje się zepsują, możesz potrzebować zezwolić na adresy IP Automattic lub użyć metody allow-list na poziomie serwera pokazanej powyżej.
• Aplikacja mobilna WordPress: Aktualne wersje aplikacji mobilnej WordPress używają REST API. Tylko bardzo stare wersje (sprzed 2019) używały XML-RPC. Jeśli Twoja aplikacja działa dobrze, nie potrzebujesz XML-RPC.
• Integracje IFTTT lub Zapier: Niektóre przestarzałe integracje z usługami automatyzacji używały XML-RPC. Sprawdź, czy Twoje automatyzacje nadal działają po wyłączeniu.
• Windows Live Writer lub inne edytory desktopowe: Te przestarzałe narzędzia używały XML-RPC do publikowania. Jeśli nadal używasz któregoś, rozważ przejście na edytor blokowy WordPress lub alternatywę opartą na REST API.

Weryfikacja, że XML-RPC jest wyłączony

Po zastosowaniu wybranej metody zweryfikuj, że XML-RPC jest rzeczywiście zablokowany:

# Powinno zwrócić 403 Forbidden lub connection refused
curl -s -o /dev/null -w "%{http_code}" -X POST   https://yoursite.com/xmlrpc.php   -H "Content-Type: text/xml"   -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Jeśli otrzymasz kod statusu 403, XML-RPC jest zablokowane. Jeśli nadal otrzymujesz 200, Twoja metoda blokowania nie działa poprawnie. Sprawdź konfigurację i upewnij się, że serwer został zrestartowany (dla Nginx) lub że zmiany .htaccess są odczytywane (dla Apache upewnij się, że AllowOverride jest włączone).

Możesz również uruchomić skan InspectWP. Sekcja bezpieczeństwa wykrywa, czy XML-RPC jest dostępny i oznacza to jako potencjalne ryzyko, jeśli odpowiada na żądania.