XMLRPC.PHP de WordPress ¿que es y como protegerlo?

Fecha: 09/10/2015
Aprovechando que el impacto que están teniendo los ataques contra el XMLRPC.PHP de WordPress, me gustaría aclarar ciertos conceptos relacionados con este archivo que forma parte de Wordpress y de paso explicar paso a paso como protegerse contra posibles ataques de fuerza bruta y denegación de servicio contra este archivo en una instalación de Wordpress. Como ya hemos hablado bastantes veces en este blog últimamente, muchas instalaciones de WordPress están siendo víctimas de ataques variados de diferentes formas: por un lado están las infecciones de malware o inyecciones de código y por el otro lado están los ataques externos contra algunas partes de WordPress como el archivo xmlrpc.php o el wp-login.php. En este artículo vamos a ir por partes, vamos a ir explicando ciertos aspectos básicos e interesantes sobre el tema, ya que muchos hablan en sus blogs sobre los ataques al XMLRPC.PHP pero muy pocos saben lo que es el protocolo XMLRPC o la función que hace el archivo XMLRPC.PHP en WordPress. [elementor-template id="80835"]

Qué es el XMLRPC

El protocolo XMLRPC es un protocolo que utiliza XML para estructurar datos y el protocolo HTTP para la transmisión de esos datos estructurados en XML. El protocolo XMLRPC fue desarrollado en 1998 por la empresa UserLand Software en colaboración con Microsoft, finalmente Microsoft considero que el protocolo XMLRPC era muy simple y lo convirtió en lo que ahora mismo se llama SOAP. En Wordpress, el protocolo XMLRPC actual como interfaz que actúa como API para aplicaciones externas y que nos permite interactuar con una instalación de Wordpress utilizando aplicaciones o servicios externos. Al funcionar como una interfaz externa es casi como una “puerta de entrada” por lo que esta puerta puede ser atacada fácilmente desde el exterior causando un alto consumo de recursos al ejecutarse una y otra vez el proceso de autentificación.

Wordpress y el XMLRPC.PHP

Como hemos dicho anteriormente, en Wordpress el protocolo XMLRPC está gestionado por el archivo XMLRPC.PHP que puedes encontrar en la raíz de la instalación de Wordpress: XMLRPC.PHP Wordpress Para comunicarse con una instalación de Wordpress utilizando el protocolo XMLRPC debemos enviar peticiones HTTP mediante POST al archivo xmlrpc.php situado en la raíz de la instalación, con esto obtendremos una respuesta. Si todo ha ido bien normalmente la respuesta obtenida es HTTP/1.1 200 OK. Hasta la versión 3.5 Wordpress traía de forma predeterminada el protocolo XMLRPC desactivado, desde la versión 3.5 viene activado por defecto, y ahí está el problema, ya que todas las instalaciones traen el protocolo XMLRPC activado y por defecto son vulnerables a ataques de denegación de servicio y fuerza bruta contra este protocolo. Vamos a poner varios ejemplos de funciones REALES que hace el protocolo XMLRPC en Wordpress:
  • El protocolo XMLRPC permite que programas de escritorio como Microsoft Word, Textmate o Mozilla Thunderbird se comuniquen con nuestra instalación de Wordpress.
  • El protocolo XMLRPC permite la comunicación mediante pingbacks y trackbacks con otros blogs u otras instalaciones de Wordpress.
  • El protocolo XMLRPC es el que permite que funcionen ciertas funciones del plugin Jetpack para Wordpress que tiene comunicación directa con los servidores de Automattic.
Posiblemente se me quede alguna cosa más en el tintero que se puede hacer con el XMLRPC.PHP, pero en principio las nombradas anteriormente son las principales.

Ataques al XMLRPC.PHP

Desde hace algún tiempo (desde que el XMLRPC viene activado por defecto en Wordpress) los ataques contra el XMLRPC ocurren de forma habitual, el problema es que estos ataques a veces son difíciles de detectar ya que pueden venir desde cientos de direcciones IP al mismo tiempo. El problema de los ataques al XMLRPC.PHP ya no es solo que puedan encontrar la contraseña y entrar mediante fuerza bruta, sino que estos intentos de autentificación pueden llegar a consumir muchos recursos ya que todas las peticiones deben procesarse, ahí es donde aparece el problema, ya que en planes de hosting compartido con los recursos limitados, esto puede ser realmente un problema. A diferencia de otro tipo de ataques, el ataque DDOS al archivo XMLRPC.PHP de Wordpress es realmente fácil y solo tenemos que tener un ordenador con un sistema operativo Linux y algo de soltura en la consola de comandos de Linux para ejecutar la siguiente línea y atacar a quien nosotros queramos: XMLRPC.PHP Wordpress El código está incompleto, más que nada para que a ningún gracioso se le ocurra empezar a atacar sitios web Wordpress utilizando el ejemplo, el código anterior simplemente lo he puesto como ejemplo para que se vea lo fácil que es realizar un ataque al XMLRPC.PHP de cualquier instalación de Wordpress. Cuando una instalación de Wordpress está bajo ataque al XMLRPC.PHP lo normal es que el uso de recursos de CPU se ponga a tope y el uso de memoria RAM sea también bastante alto: XMLRPC.PHP Wordpress En este caso, cuando la web se encuentra bajo ataque, la web carga muy lenta y en ocasiones puede mostrar un error 500 – Internal Server Error como este: XMLRPC.PHP Wordpress En el caso de un servidor VPS con recursos reducidos también puede ser que el servicio MySQL se pare al consumirse todos los recursos de RAM, en estos casos debemos tener extremo cuidado ya que puede dañarse la base de datos al “crashear” el proceso de MySQL.

Protección contra ataques al XMLRPC - Método 1

Existen varios métodos para protegernos contra ataques XMLRPC, y aunque ninguno de los métodos es 100% efectivo, sí que ayudan a mantener la estabilidad de la instalación aunque nos ataquen, evidentemente cuantos más recursos tengamos disponibles en nuestro servidor o en nuestro plan de hosting, más margen de maniobra tendremos en caso de que nos ataquen ya que dispondremos de más recursos. El primer método de protección consiste en realizar varias modificaciones en varios archivos de Wordpress para que no se encuentre el archivo XMLRPC.PHP y también para desactivar las funcionalidades de XMLRPC para que Wordpress no muestre ningún error por ello. Lo primero que vamos a hacer es borrar o cambiar el nombre del archivo XMLRPC.PHP que encontraremos en la raíz de nuestra instalación: XMLRPC.PHP Wordpress Lo siguiente que debemos hacer es dirigirnos a nuestro archivo wp-config.php de Wordpress (también se encuentra en la raíz de la instalación) y debajo de la última línea colocamos lo siguiente:
add_filter('xmlrpc_enabled', '__return_false');
Tal y como se muestra en la siguiente imagen: XMLRPC.PHP Wordpress Lo siguiente que debemos hacer es dirigirnos al archivo funcions.php del theme que tenemos activado y al final debemos añadir el siguiente código:
add_filter( ‘xmlrpc_methods’, function( $methods ) {
   unset( $methods['pingback.ping'] );
   return $methods;
} );
Este método es bastante simple, pero para usuarios poco acostumbrados a Wordpress y al mundo web puede ser algo difícil, por esa razón existen otros métodos para desactivar el XMLRPC.PHP y evitar que nos puedan atacar.

Protección contra los ataques al XMLRPC - Método 2

El segundo método es mucho más simple desde el punto de vista de un usuario principiante en Wordpress, pero yo cuando lo uso, hasta me quedo algo intranquilo a pesar de que sé que es efectivo y que realmente hace lo mismo que en el método 1 pero de forma automatizada y aprovechando un poco las posibilidades que tienen los plugins en una instalación de Wordpress. XMLRPC.PHP Wordpress En este método 2 usaremos el plugin XMLRPC Attacks Blocker, un plugin gratuito que puede ser descargado desde el repositorio de plugins de Wordpress y que permite desactivar el XMLRPC.PHP casi por completo. Puedes encontrar más información acerca de este plugin para Wordpress en la siguiente dirección URL: https://es.wordpress.org/plugins/xmlrpc-attacks-blocker/ La ventaja que tiene usar este plugin es que podríamos incluso seleccionar un único usuario al que le permitiremos acceder mediante el protocolo XMLRPC, además, nos permite bloquear mediante el .htaccess a todas las direcciones IP que intenten utilizar nuestro archivo XMLRPC.PHP una vez desactivado el protocolo. Sin duda, esta última funcionalidad nombrada es lo que realmente distingue este método del método 1.

Protección contra ataques al XMLRPC - método 3

El método 3 de protección contra ataques XMLRPC en Wordpress es realmente rudimentario, es más, se basa en bloquear el acceso al XMLRPC.PHP usando el archivo .htaccess, haciendo una redirección a un error 403. Primero introducimos lo siguiente en el .htaccess del sitio web (en caso de usar un servidor web compatible con archivos .htaccess):
RedirectMatch 403 /xmlrpc.php
Lo siguiente que debemos hacer es añadir el siguiente código al funcions.php del theme activo en la instalación de Wordpress:
function removeHeadLinks() {  
    remove_action('wp_head', 'rsd_link');
    remove_action('wp_head', 'wlwmanifest_link');
}
add_action('init', 'removeHeadLinks');
De los cuatro métodos aquí mencionados, este es el único método que yo personalmente no utilizaría.

Protección contra ataques al XMLRPC - Método 4

Este método también es mediante plugin, pero la técnica utilizada por el plugin cambia, de hecho, es bastante curiosa. El plugin Stop XML-RPC Attack es un plugin que añade unas líneas al .htaccess del sitio web que simplemente bloquean 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 Automattic, es decir, que de esta forma funciona Jetpack. Sin duda, un método simple, pero bastante curioso, ya que nos permite seguir utilizando el plugin Jetpack for Wordpress sin ningún problema. Puedes encontrar más información acerca de este plugin para Wordpress en la siguiente dirección URL: https://es.wordpress.org/plugins/stop-xmlrpc-attack/

¿Tienes una web bajo ataque?

¿Estas alojado con nosotros? ¿Crees que tu Wordpress está siendo atacado? Si eres cliente nuestro contacta con nosotros sin compromiso y te intentaremos ayudar de la mejor forma posible. ¿No tienes tu web alojada con nosotros? Si buscas un hosting que te ayude con los ataques XMLRPC.PHP contacta con nosotros sin compromiso e intentaremos ayudarte.
Alvaro Fontela
Alvaro Fontela

Mi nombre es Alvaro Fontela, soy consultor Wordpress y blogger activo desde hace años. CEO y co-Fundador de Raiola Networks, escribiendo sobre WordPress, hosting y WPO en este blog desde 2014.

Artículos relacionados

Si te ha gustado este post, aquí tienes otros que pueden ser de tu interés. ¡No dejes de aprender!

Tenemos 52 comentarios en "XMLRPC.PHP de WordPress ¿que es y como protegerlo?"
Avatar del autor del comentario

Chris

11/10/2015 a las 22:24

Mu bien explicado todo. Gracias.

Responder
Avatar del autor del comentario

Alvaro Fontela

11/10/2015 a las 23:46

Muchas gracias Chris, me alegro de que te guste.

Un saludo.

Responder
Avatar del autor del comentario

David García-Pascual Albares

23/01/2016 a las 11:13

Hola Álvaro, sobre incluir el código en el archivo functions.php, cuando trabajas con un tema child, es en éste donde hay que incluirlo ? Gracias !!

Responder
Avatar del autor del comentario

Alvaro Fontela

23/01/2016 a las 18:29

Exactamente David, en el functions.php del tema activo.

Un saludo.

Responder
Avatar del autor del comentario

tiendasenchina

28/01/2016 a las 00:07

Muchas gracias por el tutorial Alvaro. Ahora solo me queda hacer las modificaciones pertinentes.

Un saludo!

Responder
Avatar del autor del comentario

Alvaro Fontela

28/01/2016 a las 00:51

Nada, me alegro de que te sirva.

Un saludo.

Responder
Avatar del autor del comentario

frank

17/07/2016 a las 03:20

Hola, gracias por el dato, voy a probarlo. Solo una duda, en el instructivo indica modificar el archivo wp-config.php y en la imagen están modificando el archivo wp-config-sample.php
Cual es entonces? O hay que modificar ambos?
Saludos y gracias de nuevo!

Responder
Avatar del autor del comentario

Alvaro Fontela

21/07/2016 a las 17:18

No, tienes que modificar solo el wp-config.php, lo que ocurre es que en el preciso momento no podíamos modificar el wp-config.php.
Corregiremos eso para que nadie se lie con esto.

Un saludo.

Responder
Avatar del autor del comentario

ESPORA

20/07/2016 a las 17:37

El metodo 1 me funcionó perfecto, gracias Alvaro :D

Responder
Avatar del autor del comentario

Alvaro Fontela

21/07/2016 a las 17:17

Nada, gracias a ti, me alegro de que te sirviera esta información.

Un saludo.

Responder
Avatar del autor del comentario

Santiago Gonzalez

17/08/2016 a las 14:25

Muchas gracias por este tutorial, esta explicado de forma clara y sencilla. Gracias por el aporte. saludos!

Responder
Avatar del autor del comentario

Alvaro Fontela

22/08/2016 a las 18:55

Gracias a ti Santiago.

Un saludo.

Responder
Avatar del autor del comentario

Antonio Pulido

17/08/2016 a las 23:20

Muchas gracias por el tutorial, me sirvió de mucho!

Responder
Avatar del autor del comentario

Alvaro Fontela

22/08/2016 a las 18:56

Gracias a ti Antonio.

Un saludo.

Responder
Avatar del autor del comentario

Modesto Cabral

03/09/2016 a las 05:49

Bloqueando ese archivo en robots.txt no sería otra opción?
Saludos

Responder
Avatar del autor del comentario

Alvaro Fontela

05/09/2016 a las 00:04

Hola Modesto, con el robots.txt solo bloquearías a los buscadores, no a los bots malintencionados.

Un saludo.

Responder
Avatar del autor del comentario

ZfrenzyTv

06/09/2016 a las 06:25

Hola he usado el método 4 ya que estaba teniendo ataques y de hecho, aún usando el plugin, el consumo de cpu del server es bestial. También he bloqueado el rango de ips atacante. Alguna forma de evitar los ataques al servidor y que la cpu no se vea afectada?
Por cierto, estoy usando el Wordfence, que opinas de este plugin?

Responder
Avatar del autor del comentario

Alvaro Fontela

06/09/2016 a las 18:49

Hola, para mi Wordfence es el mejor plugin de seguridad para Wordpress y mas ahora que le han añadido el WAF.

Si quieres que los ataques no afecten al servidor, debes bloquear los ataques en el firewall del servidor (CSF por ejemplo) o en el firewall de red si tienes esa posibilidad.

Un saludo.

Responder
Avatar del autor del comentario

sinEntradas

11/09/2016 a las 18:34

Hola, llevo unas semanas que cada día se cae el servidor una o dos veces debido a este problema. He utilizado diferentes métodos y aun habiendo deshabilitado el fichero xmlrpc.php, encuentro en el log de apache peticiones "random" a ficheros inexistentes que terminan por tirar el servidor.

Y aún devolviendo un 500 las peticiones a xmlrpc.php el uso de cpu se disparaba por lo que volvía a caerse el servidor.

Estoy utilizando un vps en digitalocean y seguido varios de sus tutoriales pero sigo sin poder mitigar la amenza. También vengo utilizando cloudflare y creo que, a raíz de que llegara al tope en la tabla que tienen en su versión gratuita donde añaden ips amenzantes en su firewall, ha sido cuando he empezado a tener este tipo de problemas, a pesar de haber quitado bastantes reglas para que puedan volver a añadirse de forma automática como hasta ahora venía haciendo y habiendo metido estas de forma manual con ufw.

Voy a probar ese plugin a ver que tal es

Responder
Avatar del autor del comentario

Alvaro Fontela

12/09/2016 a las 15:35

Hola, si el servidor se cae en esta situación puede que el ataque sea muy fuerte o que el servidor no este correctamente optimizado.
Nosotros trabajamos con fail2ban y con reglas propias para mitigar este tipo de ataques, de esta forma los ataques no llegan a ejecutar PHP y por lo tanto no saturan el servidor.

Un saludo.

Responder
Avatar del autor del comentario

Fabián Baptista

19/09/2016 a las 17:12

Capos!

Responder
Avatar del autor del comentario

Alvaro Fontela

22/09/2016 a las 16:11

Gracias Fabian.

Un saludo.

Responder
Avatar del autor del comentario

Luca Paltrinieri

21/09/2016 a las 08:20

Muy interesante. Pero qué se puede hacer si se quiere utilizar un servicio - que no es jetpack - que necesita conectarse con este archivo? Quiero conectar mi blog con Postable (postable.io) y no puedo justamente porque en el hosting (raiola claramente ) hay una redirección puesta al archivo /xmlrpc.php

Responder
Avatar del autor del comentario

Alvaro Fontela

22/09/2016 a las 16:12

Hola Luca, contacta con soporte tecnico, creo que te podrán dar una solución basada en añadir una regla al WAF del servidor.

Un saludo.

Responder
Avatar del autor del comentario

Luca Paltrinieri

22/09/2016 a las 16:17

Gracias Álvaro.
De momento he quitado la redirección y he añadido uno de los plugins que comentas, dejando el acceso al archivo sólo para la cuenta del administrador. Y ahora el enlace con Postable funciona. Espero que la web siga siendo segura, aunque creo que sí...

Responder
Avatar del autor del comentario

Alvaro Fontela

22/09/2016 a las 16:38

Hola Luca, no te preocupes, seguira siendo segura, de todas formas si detectamos ataques los bloqueamos manualmente.

Un saludo.

Responder
Avatar del autor del comentario

ceci

29/09/2016 a las 12:47

xmlrpc.php
Me dice una herramienta de análisis que tengo este enlaçe roto. es decir... que la url no lleva a ninguna parte: Method Not Allowed405

Alguien sabe como puedo solucionar esto.

Muchas gracias

Responder
Avatar del autor del comentario

Alvaro Fontela

02/10/2016 a las 15:39

Hola Ceci, debes contactar con tu proveedor de hosting para solucionar el problema, también debes revisar si tienes algo bloqueando el XMLRPC.PHP para peticiones externas.

Responder
Avatar del autor del comentario

Romina Lima

27/10/2016 a las 12:08

Muchas gracias, muy bueno todos los artículos, realmente muy interesantes y siempre aportando contenido de forma accesible.
Me queda una duda sobre la protección a XMLRPC ¿Sólo con el método 4 se puede utilizar jetpack?
Además, los plugin dicen no recibir actualizaciones desde hace unos dos años ¿aún serán efectivos?

Responder
Avatar del autor del comentario

Alvaro Fontela

30/10/2016 a las 01:47

Hola Romina, el plugin del método 4 teóricamente debería dejar funcionar Jetpack, pero no lo he probado últimamente, en todo caso, si provoca un error, te enteras rápido, ya que va a aparecer un error de conexión con los servidores de Automattic en el panel de Jetpack.

Un saludo.

Responder
Avatar del autor del comentario

Romina Lima

01/11/2016 a las 19:58

Gracias!

Responder
Avatar del autor del comentario

Dany Aguilar

09/12/2016 a las 21:47

excelente articulo! instale el plugin y hace lo del .htaccess y coloca en allow las ip de jetpack asi que sigue funcionando sin problemas

Responder
Avatar del autor del comentario

Alvaro Hernández Hernández

16/12/2016 a las 14:52

Hola!!
Que opinas sobre bloquear xmlrpc.php desde mismo apache? El sitio que administro no usa xmlrpc en absoluto y después de un par de ataques que tiraron el sitio lo desactive mediante "deny from all" en la configuración del virtual host de apache. Fue la solución más rápida que pude ejecutar al momento (aunque sigue escribiendo logs en el fichero de apache que ya no afectan el performance del server) en lo que configuro fail2ban para bannear las ips atacantes.
Saludos!!

Responder
Avatar del autor del comentario

Alvaro Fontela

21/12/2016 a las 11:08

Hola Alvaro, si tienes acceso a la configuración de Apache es una opcion mas, y hasta mas afectiva, ya que cuanto mas "de raiz" es la solución, menos impacta en el rendimiento del servidor, aunque no todos los usuarios tienen los conocimientos o la posibilidad de implementar este tipo de soluciones.

Un saludo.

Responder
Avatar del autor del comentario

Ivan Arturo Jauregui

24/03/2018 a las 06:40

Hola me interesa implementarlo en Apache, cual serian los pasos a seguir?

Muchas gracias!

Responder
Avatar del autor del comentario

Héctor Luaces

08/05/2018 a las 08:59

Hola, Iván:

Puedes optar por usar el siguiente código para bloquear todo:



Order Allow,Deny
Deny from all

Si quieres usar algo más refinado, complicado pero con más control puedes usar ModSecurity.

Un saludo!

Responder
Avatar del autor del comentario

Franklin

26/05/2017 a las 11:31

Alvaro, me han gustado el método 2 ya que te da la opción de bloquer la ip de quien te ataca , pero aun me preocupa que quede bloqueado API que utilizo para comunicarme con otros servicios como Twitter, ¿no sé si estos se afectarían? te consulto antes de proceder. Ha ademas se que he recibido ataque pero hasta el momento no veo mayor afectación solo que mi hosting me dice que quien me ataca y ademas he visto que mi trafico incrementa, pero no se lo puedo atribuir al ataque porque esta dentro de mi crecimiento normal de trafico.

Responder
Avatar del autor del comentario

Alvaro Fontela

06/06/2017 a las 18:32

Hola Franklin, ¿lo notas a nivel rendimiento o en algo en especial? Si los ataques no te afectan, creo que puedes omitir los ataques.

Un saludo.

Responder
Avatar del autor del comentario

bloghws

16/08/2017 a las 19:25

Excelente dato, ese error me apareció recientemente en uno de mis sitios, no soy programador pero voy a intentar la primera opcion que la veo mas segura, porque estuve revisando los plugins pero no me parece buna idea cargar el sitio con plugins. Muchas gracias nuevamente por el dato, lo voy a poner en práctica.

Responder
Avatar del autor del comentario

Alvaro Fontela

11/09/2017 a las 00:41

Muchas gracias por tus palabras y espero que te haya servido.

Un saludo.

Responder
Avatar del autor del comentario

javiesfer

28/08/2017 a las 00:14

Hola!, vaya tema. Tengo instalado el Pluguin Redirection, ya que hice la migracion desde Blogger, y en los reportes de errores 404s me aparece 1 intento de entrada a /xmlrpc.php, esto quiere decir que el pluguien redirection lo identifico como url no existente. Por eso me aventure a buscar de que se trataba este archivo, y me encontre con toda esta informacion que brindas en tu post.

Invetsigando un poco mas, encontre otra opcion que propone eliminarlo directamente al archivo /xmlrpc.php y agregar las siguientes lineas de codigo en el archivo functions.php

function removeHeadLinks() {
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
}
add_action('init', 'removeHeadLinks');

y deshabilitar la funcionalidad XML-RPC de las opciones de Wordpress

Quisiera saber que tan efectiva y recomendable puede ser esta opcion, si el archivo no es utilizado para sacarle provecho.

Responder
Avatar del autor del comentario

Alvaro Fontela

11/09/2017 a las 00:42

El problema es que si eliminas el archivo xmlrpc.php y bloqueas su funcionamiento, algunas funcionalidades de WordPress van a quedar descolgadas y no podrás instalar algunos plugins como Jetpack.

Un saludo.

Responder
Avatar del autor del comentario

Artur

05/05/2018 a las 03:29

Es mucho mejor plugin:

https://wordpress.org/plugi...

otro es deprecado...

Responder
Avatar del autor del comentario

Héctor Luaces

08/05/2018 a las 08:50

Hola, Artur:

En efecto, mucho mejor, ¡gracias por la recomendación!

Ahora mismo optamos por usar modSecurity para proteger nuestros hostings sin necesidad de plugins.

Un saludo.

Responder
Avatar del autor del comentario

Erickson Vásquez

26/06/2018 a las 19:29

Excelente explicación, yo no uso pingback y trackbacks, tampoco el plugin jetpack ¿Cual método me recomiendas?

Responder
Avatar del autor del comentario

Héctor Luaces

27/06/2018 a las 08:40

Hola, Erickson:

te recomiendo el primer método. Es rápido de usar y se mantendrá si en el futuro migras de hosting, cambias de tema o usas un servidor web distinto.

¡Cualquier cosa nos dices!

Un saludo.

Responder
Avatar del autor del comentario

Alex Vidal

31/03/2020 a las 17:21
Que método o plugin recomendais actualmente para bloquear los ataques por fuerza "bruta" y que siga funcionando las actualizaciones de los plugins por Automattic
Responder
Avatar del autor del comentario

Alvaro Fontela

01/04/2020 a las 18:36
Hola Alex, pues la verdad es que creo que para este tipo de cosas el único que sigue en pie y que no ha cambiado mucho es Ninja Firewall.
Responder
Avatar del autor del comentario

Hugo Vidal

17/08/2020 a las 01:40
Hola Alvaro, Excelente artículo, ya vi que no pasa de moda. Yo uso el tema Newspaper con Divi, desde hace como un mes el uso de CPU y Mmemoria se disparó, he instalado un par de plugins y aún así no bajan los parametros. Aunque han disminuido algo los errores HTTP 5xx. El que más ocurre es el 503 Tengo instalados los plugins -Anti-Malware Security and Brute-Force Firewall y el WP-Cerber security, este segundo tiene una opción Desactivar XML-RPC - Bloquear el acceso al servidor XML-RPC (incluyendo pingbacks y trackbacks). Eso ayudaría a reducir los ataques? Probaría pero no sé si el tema utiliza el XML-RPC o el mismo servidor. Qué me aconsejas?
Responder
Avatar del autor del comentario

Alvaro Fontela

17/08/2020 a las 09:24
Hola Hugo, y....la pregunta es...¿sabes seguro que es por el XMLRPC? Porque si no es de eso, igual lo estas empeorando con tantos plugins de seguridad... Lo digo porque...actualmente los ataques al XMLRPC son casi inexistentes, hubo un BOOM, pero ahora han bajado mucho y los WAF de los servers los detectan al instante.
Responder
Avatar del autor del comentario

Natalia

01/03/2021 a las 16:09
Hola! Muchas gracias por el tutorial! Tengo una duda que igual es un poco tonta pero, en el método 1 primero hay que cambiar el nombre del archivo xmlrpc, por tanto en el código siguiente que hay que añadir a wp-config y al functions hay que modificar el nombre por el que hemos cambiado o hay que dejarlo tal cual lo has puesto? Es que me aparecen el siguiente error: Use of undefined constant ‘xmlrpc_methods’ - assumed '‘xmlrpc_methods’' (this will throw an Error in a future version of PHP)
Responder
Avatar del autor del comentario

Alvaro Fontela

03/03/2021 a las 13:48
Hola Natalia, la verdad es que nunca he visto ese error, aunque tampoco te puedo garantizar que este código este funcionando, ya que es un post antiguo. Te recomiendo un plugin como este: https://wordpress.org/plugins/disable-xml-rpc-api/
Responder

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

¿Vienes desde otro proveedor?

¡Sin problema! Te migramos gratis y sin cortes
Migraciones de hosting gratis