Intro y problema
Me avisaron de que una de las máquinas virtuales que tenemos corriendo en un proxmox iba especialmente lenta. De hecho, se veía afectado el tráfico a otro servidor virtual del mismo nivel que el proxmox. Revisando la página de diagnóstico del proxmox vi que el uso de CPU y de memoria era especialmente elevado. Revisé uno a uno los containers hasta que detecté que el que estaba causando el atasco era el de wordpress.
Al revisar los logs de apache del contenedor observé que estaba teniendo unos tres o cuatro (a veces más) accesos al script xmlrpc.php por segundo. Entonces traté de encontrar la solución al ataque.
La solución
No voy a explicar los ataques al xmlrpc.php en wordpress. Una búsqueda rápida en google da toda la información necesaria. Lo que si que voy a explicar es la solución que adopté frente a uno de estos ataques.
Una de las soluciones propuestas para estos ataques es desactivar el servicio xmlrpc en wp-config.php añadiendo la siguiente línea tras require_once(ABSPATH . 'wp-settings.php');
add_filter('xmlrpc_enabled', '__return_false');
Lamentablemente éso no evitaba que la cpu de mi máquina virtual se mantuviese por encima del 70% cuando su uso normal está en torno al 5%. Parece que este sistema no es eficiente para evitar el ataque.
El log del servidor apache mostraba el motivo. Se estaba respondiendo con el siguiente código de salida a la petición:
"POST /xmlrpc.php HTTP/1.0" 200 595 "-"
Lo que si que resultó ser efectivo para evitar el abuso de CPU de la máquina fue filtrar el acceso al script xmlrpc.php en .htaccess con las siguientes líneas:
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
allow from 147.156.56.1
</Files>
El uso de la CPU bajó drásticamente y la salida del log de apache mostraba que se estaba denegando el acceso al script:
"POST /xmlrpc.php HTTP/1.0" 403 495 "-"
Por ese motivo decidí emplear este sistema como defensa por defecto frente a ataques de abuso a xmlrpc.php
Por último, como los ataques provenían de máquinas de una red de clase C y me molestaba tener que gastar espacio en los logs del servidor con tres o cuatro denegaciones de acceso por segundo, impedí el acceso de las IPs de la clase C del atacante al puerto 80 de la máquina virtual que corre wordpress empleando el firewall de proxmox.
