Seguridad de WordPress: apague la interfaz XML-RPC

Desde la versión 3.5 de WordPress, la interfaz XML-RPC está activada por defecto. Eso no sería tan malo si WordPress no fuera el sistema de administración de contenido más popular del mundo. La interfaz no solo proporciona funciones útiles, sino que también es un objetivo importante para los piratas informáticos. Los invasores usan xmlrpc.php para sus ataques de fuerza bruta contra WordPress cada vez con más frecuencia, ya que atacar esta interfaz es significativamente más eficiente y se puede hacer con mucho menos esfuerzo que otros métodos.

Esta es la razón por la que existe la interfaz XML-RPC

La interfaz es una herramienta útil para la gestión de contenidos. Se utiliza para permitirle administrar el sitio web y escribir artículos utilizando las aplicaciones de escritorio y teléfono inteligente. También se encarga de los pingbacks. La API de Pingback permite una especie de «conexión» entre los blogs y, al mismo tiempo, es una interfaz para administrar WordPress mediante programas externos. No solo el API de WordPresspero también el API de Bloggerlos API de metaWebloglos API de tipos móvilesy el API de pingback son compatibles. Sin embargo, la mayoría de los usuarios no necesitan esta interfaz, ya que escriben sus artículos directamente en WordPress. Además, los pingbacks de otros blogs no son obligatoriamente necesarios.

Por qué xmlrpc.php es un riesgo de seguridad

Las áreas protegidas por contraseña son un objetivo atractivo. El xmlrpc.php es uno de ellos. A medida que cada vez más bloggers protegen el área de administración de sus sitios web, los atacantes ahora se enfocan en la interfaz de administración y dejan que sus ataques de fuerza bruta se dirijan a ella. El problema es que los ataques a la interfaz XML-RPC se pueden ejecutar de manera mucho más eficiente, como sería el caso de los ataques al área de administración de WordPress. Con la herramienta de ajuste, una solicitud a la interfaz puede cubrir la increíble cantidad de 500 contraseñas. El archivo permite a los atacantes descubrir combinaciones de nombres de usuario y contraseñas mediante llamadas a funciones para wp.getUsersBlogs o wp.getComments. Tan pronto como un pirata informático envíe un nombre de usuario y una contraseña, xmlrpc.php responderá e informará si la combinación es correcta o no. Esto hace que hackear una instalación de WordPress sea mucho más efectivo y prometedor. Eso convierte la interfaz en su mayoría no utilizada en un grave riesgo de seguridad y, por lo tanto, debe desactivarse lo antes posible. Otra ventaja, más general, de apagarlo es el aumento del rendimiento del sitio web.

Desactivación de la interfaz XML-RPC

Desde la versión 3.5 de WordPress, la interfaz XML-RPC está activada por defecto. Entonces era muy fácil desactivarlo, mientras que hoy en día esto solo es posible a través de desvíos. Pero los desvíos no son demasiado complicados. En general, son necesarios tres pasos para apagar la interfaz y evitar que se acceda a ella.

Primera parte: Desactivar la interfaz usando un filtro

El siguiente código tiene que ser pegado en el tema funciones.php.

Al hacer clic en el gráfico, se abre GitHub Gist

La interfaz ahora está completamente desactivada. Sin embargo, todavía aparece en el encabezado HTTP del sitio web.

Parte 2: Desactivar la entrada del encabezado HTTP

Si aún se muestra, aún se puede acceder a él. Si bien es posible que esto ya no sea un riesgo para la seguridad, aún puede tener un impacto en el rendimiento del sitio web. Es por eso que la entrada debe eliminarse. Este fragmento de código también debe colocarse en el funciones.php de tu tema Aquí puedes encontrar el código completo con el filtro de la primera parte incluido:

Al hacer clic en el gráfico, se abre GitHub Gist

Parte 3: Bloqueo de xmlrpc.php a través de .htaccess

Siempre que WordPress tenga acceso a xmlrpc.php, existirá un acceso oculto al archivo. Esto no ayuda con el rendimiento del sitio web, por lo que el archivo .htaccess debería bloquear el archivo una vez más.

Una cosa importante antes de comenzar: ¡Cree una copia de seguridad del archivo cada vez que modifique .htaccess!

Un error durante la edición del archivo puede hacer que su sitio web ya no funcione. También debe tener en cuenta que, debido al punto delante del nombre del archivo, el .htaccess se trata como un archivo del sistema en Mac OS X. Esto hace que el archivo no se muestre tan pronto como esté en el escritorio. Puede utilizar el terminal o un widget de tablero para encontrar archivos ocultos. Pegue la siguiente entrada en el archivo .htaccess en el Índice principal de instalación de WordPress. La entrada debe estar por encima de #Comenzar WordPress. El archivo se puede abrir y editar usando un editor de texto como Notepad o TextEdit.

El índice principal de una instalación de WordPress
Al hacer clic en el gráfico, se abre GitHub Gist

Conclusión

Estos tres pequeños pasos han hecho que su WordPress sea significativamente más seguro. Un ataque a xmlrpc.php ahora es imposible, e incluso las llamadas a este archivo ya no se responden, lo que ayuda con el rendimiento. Sin embargo, debe tener en cuenta que WordPress ya no recibe pingbacks y tampoco puede administrar su contenido en aplicaciones de ningún tipo. Sin embargo, esto solo debería ser una pequeña decepción que no compense la ganancia de seguridad.

(dpe)