Ostatnio do jednego z klientów (strona WWW na WordPressie) przyszedł e-mail od „jednego z wiodących dostawców hostingu”, że zmuszeni byli administracyjnie zmienić nazwę jednego z plików (xmlrpc.php) ze względu na „realizujących nieautoryzowaną wysyłkę wiadomości spamowych na Państwa serwerze”.

Nie wiem czy faktycznie na podstawie jakich logów im wyszło, że za wysyłkę SPAMu odpowiada plik xmlrpc.php (usługa XML-RPC), ale niezależnie od tego jest to dobra okazja, by wspomnieć o usłudze XML-RPC w WordPressie, i pokazać jak ją zablokować.

WordPress i XML-RPC

W sporym skrócie dzięki usłudze XML-RPC możemy m.in. zdanie (za pomocą WordPress API) komunikować się z naszą stroną – np. za pomocą aplikacji mobilnych możemy zarządzać treściami na stronie (wpisy, strony, komentarze). Wygodne…

Wygodna i ryzyko

Niestety możliwości jakie daje usługa cały czas próbują wykorzystać „źli chłopcy” piszący swoje „złe boty”, które przeczesują internet w poszukiwaniu stron korzystających m.in. z usługi XML-RPC i próbują to wykorzystać do swoich niecnych celów.

Chyba najpopularniejsze/najpowszechniejsze ataki to próby (często udane) przeciążenia serwera na którym stoi strona (DDoS), oraz próby odgadnięcia loginu i hasła (głównie hasła) użytkownika, dzięki czemu będzie można wykorzystać stronę do dalszych działań/ataków.

Można też trafić na przykłady wykorzystania mechanizmów XML-RPC (trackback/pingback) do generowania pewnej formy SPAMu.

Choć akurat mniej zdziwiłbym się, gdyby np. przyszła wiadomość, że zablokowali plik bo generował za duże obciążenie serwera na którym znajduje się strona (atak DDoS), niż to:

Pragnę poinformować, iż analiza logów FTP oraz otrzymywane drogą mailową zgłoszenia, świadczą o obecności na serwerze FTP skryptów realizujących nieautoryzowaną wysyłkę wiadomości spamowych na Państwa serwerze (…).

(…)

Ze względu na liczne zgłoszenia o szkodliwej działalności umieszczonych na Państwa koncie skryptów zmuszeni byliśmy administracyjnie zmienić nazwy wspomnianych plików (’/.xmlrpc.php.blocked’).

Oczywiście analiza plików (w tym ich porównanie z plikami będącego w kopiach zapasowych i repozytorium WordPress.org) też nie wykazała niczego nietypowego/podejrzanego.

Dodatkowo pingbacki/trackbacki wyłączone – na stronie nie ma aktualności, nikt też nie bloguje… ;-)

Blokujemy XML-RTC

Z racji tego, że w przypadku tej strony nikt nie korzysta z XML-RTC najprościej – bez wdawania się w zbyteczną wymianę korespondencji – będzie prewencyjnie zablokować usługę, która w nowych wersjach WordPressa (chyba od 3.8 lub 3.9 w górę) jest domyślnie aktywna, i nie ma możliwości jej wyłączenia za pomocą standardowych ustawień.

Własna wtyczka lub wpis w pliku functions.php

Kiedyś już pisałem bardziej szczegółowo o tym, jak możemy dodawać własne funkcje/skrypty do WordPressa, i osoby bardziej początkujące odsyłam ew. do tamtego wpisu – tu skupimy się na konkretach.

By całkowicie zablokować XML-RPC na naszej stronie wystarczy skorzystać z takiego polecenia:

add_filter('xmlrpc_enabled', '__return_false');

Nie ma w tym przypadku miejsca na wyjątki – blokujemy wszystko.

Można również – gdy korzystamy z XML-RPC – zablokować tylko pingbacki, które ew. mogłyby posłużyć do próby wykorzystania naszej strony do pewnej formy SPAMu:

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

W tym przypadku inne usługi związane z XML-RTC powinny działać normalnie.

Można też pokusić się o ukrycie adresu naszego pliku xmlrtc.php:

function webinsider_remove_xpingback( $headers ) {
unset( $headers['X-Pingback'] );
return $headers;
}
add_filter( 'wp_headers', 'webinsider_remove_xpingback' );

Blokada po stronie webserwera

Natomiast jeśli usługa XML-RTC wykorzystywana jest do próby przeciążenia Waszego serwera (atak DDoS) to dużo lepszym sposobem będzie zablokowanie dostępu do usługi już za pomocą samego webserwera (np. Apache, Nginx).

Apache2 i .htaccess

W przypadku webserwera Apache2 najprościej w tym celu skorzystać z pliku .htaccess, w którym wystarczy dodać taki wpis:

<files xmlrpc.php>
Order allow,deny
Deny from all
</files>

Można go też rozbudować np. o adresy IP serwerów usług, z których korzystamy – tak, by one mogły korzystać z usługi.

Nginx i plik hosta

W przypadku webserwera Nginx nie mamy do dyspozycji plików .htaccess (oczywiście możemy taki plik utworzyć, ale on nie zadziała), więc musimy odpowiednią regułkę dodać do pliku w którym zdefiniowaliśmy wybraną domenę/stronę:

location = /xmlrpc.php {
deny all;
}

Kod dodajemy w sekcji „server”:

server {
[tu będzie nasz kod]
}

Pamiętajcie tylko, by później zrestartować usługę (Nginx) lub odświeżyć jej ustawienia.