Seguridad en WordPress: proteger xmlrpc.php

Hablaremos de una vulnerabilidad específica de WordPress y que aunque es muy fácil de solucionar, nos puede provocar un buen quebradero de cabeza. Me refiero a ataques dirigidos contra el archivo xmlrpc.php.

Ante todo ¿que es el archivo xmlrpc.php? Este archivo implementa el protocolo XMLRPC que permite el intercambio de datos mediante HTTP, en otras palabras permite interactuar con una instalación de WordPress desde programas o servicios externos. Es decir tenemos un punto de entrada, suceptible de ataques desde el exterior. Estos ataques pueden tener como objetivo obtener contraseñas mediante fuerza bruta, escanear la red interna del servidor web, denegación de servicios, etc. Las consecuencias pueder ir desde una ralentización de nuestro servidor debido a un consumo excesivo de recursos, caidas y paradas de servicio;  hasta la infección por malware y el uso de nuestra máquina para fines ilícitos.

En las versiones de WordPress anteriores a la 3.5, este protocolo estaba desactivado por defecto y el administrador decidía cuando activarlo. Actualmente esta funcionalidad viene activada de serie, por lo que muchos de nosotros tenemos una entrada habilitada que posiblemente no tengamos en cuenta y por tanto no vigilemos.

Ahora bien ¿es realmente necesario tener habilitado xmlrpc? Aunque la respuesta en la mayoria de los casos es no, debemos tener en cuenta que xmlrpc.php es necesario para ciertas funciones del nucleo de wordpress como pingbacks y trackbacks, además algunos plugins como Jetpack para WordPress necesitan que esté habilitado este protocolo, así que la decisión final depende de las características de nuestra intalación (por ejemplo si gestionamos nuestro blog desde una app en  nuestro smartphone, casi seguro necesitemos tener el protocolo activo).

Los ataques al XMLRPC.PHP pueden llegar a consumir muchos recursos ya que todas las peticiones deben procesarse, los sintomas habituales en este tipo de ataque suelen ser lentitud de respuesta, caidas del servidor, errores de conexión con la base de datos, consumo excesivo de recursos, etc.; con idependencia de nuestra web pueda ser comprometida. Con frecuencia, la primera reacción ante estos síntomas suele ser ampliar recursos, optimizar nuesto código para intentar reducir el consumo de recursos  Sin embargo con esto estamos intentando solucionar los síntomas, no la causa del problema y casi siempre.después de un tiempo no volvemos a encontrar en la misma situación.

¿Como saber si sufriendo un ataque de este tipo? Debemos revisar los registros de acceso al servidor en busca de líneas como de este tipo:

103.81.236.83 - - [13/Dec/2017:10:59:31 +0000] "POST /xmlrpc.php HTTP/1.1" 301 612 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
103.81.236.83 - - [13/Dec/2017:10:59:32 +0000] "GET /xmlrpc.php HTTP/1.1" 405 3524 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"

Si ese es el caso nos encontramos ante un ataque xmlrpc.

¿Como podemos solucionar esta situación?

• Método 1
  Este método deshabilita por completo el protocolo XMLRPC. Eliminamos el archivo xmlrpc.php y reconfiguramos nuestro Worpress para evitar errores con las funciones que pudiesen utilizarlo. Debemos tener en cuenta que las actualizaciones de WordPress pueden volver a copiar el archivo y no podremos utilizar este método si algun plugin que tengamos instalado lo necesita (aunque tratándose de WordPress, posiblemente exista otro plugin que realize las mismas funciones sin XMLRPC)
  • Eliminamos o cambiarmos el nombre al archivo xmlrpc.php
  • Añadimos al final de nuestro wp-config.php las siguiente línea: add_filter('xmlrpc_enabled', '__return_false');
  • Añadimos al archivo functions.php de nuestro tema
    add_filter( ‘xmlrpc_methods’, function( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );

    
• Método 2
  Bloqueamos el acceso al archivo xmlrpc.php. La directiva <Files> nos permite si es necesario autorizar el acceso desde IPs predefinidas. Es útil si necesitamos utilizar el protocolo XMLRPC y no podemos utilizar el método anterior
  
  • Añadimos a nuestro .htaccess
    # proteger xmlrpc
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
También es podemos responder con un error 404
    <IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule /xmlrpc.php - [R=404,L]
</IfModule>
  • En caso de necesidad, podemos conceder acceso a las IP que consideremos confiables, en ese caso la modificación serà similiar a
    # proteger xmlrpc
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from xxx.xxx.xxx.xxx
</Files>
Sustituiremos xxx.xxx.xxx.xxx por las IP a la que vamos a permitir el acceso. Debemos incluir una línea por cada IP
• Método 3
  Tratándose de WordPress, lógicamente existen numerosos plugins que realizan estas funciones, por ejemplo
  • :XMLRPC Attacks Blocker, un plugin gratuito que puede ser descargado desde el repositorio de plugins de WordPress. Este plugin permite seleccionar un usuario al que le permitiremos acceder mediante el protocolo XMLRPC, y además  bloquear mediante el .htaccess las direcciones IP que intenten utilizar nuestro archivo xmlrpc.php una vez se haya desactivado el protocolo.
  • Stop XML-RPC Attack, bloquea todo el tráfico entrante al archivo XMLRPC.PHP excepto el tráfico que entra desde rangos de direcciones IP pertenecientes a los servidores de Jetpack.

Solo nos queda implementar el método que mejor se adapte a nuestras necesidades y estaremos mejor protegidos, hasta que el equipo de desarrollo de Worpress solucione esta vulnerabilidad.