• Estoy lidiando con una empresa de hosting que tiene bloqueado el archivo xmlrpc.php de forma predetermina por motivos de seguridad. Me ha dado algún problema ese bloqueo y cuando le pido que me expliquen los problemas de seguridad específicos que justifiquen el bloqueo de ese archivo, me hablan de ataques DDoS y de fuerza bruta.

    Desde mi punto de vista, ese tipo de ataques son ataques genéricos, nada de específicos, que se pueden dirigir a cualquier parte de una aplicación dinámica que esté online. Ni es un problema de seguridad de WordPress ni es un problema de seguridad del archivo xmlrpc.php. En caso de un ataque de este tipo, en mi opinión, hay que detectar y bloquear el ataque, no el acceso a un archivo concreto que no tiene ninguna culpa. Otra cosa es que haya un ataque puntual a ese archivo, como podría ser a wp-login.php o cualquier otro, y se bloquee de forma temporal mientras se mitiga, pero bloquearlo de forma general y predeterminada no le veo justificación alguna.

    Con este argumento, la empresa de hosting, que se dice especializada en WordPress, me dice que vale, que los desbloquean pero que me lo pueden bloquear de nuevo si hay algún problema en la plataforma (es una cuenta de hosting compartido). Y yo vuelvo al comienzo: ¿que problema específico de seguridad tiene ese archivo para justificar tal cosa? Ninguno. Detectad y bloquead el ataque, no el archivo que no tiene culpa.

    Endless Loop.

    ¿Qué pensáis?

    • Este debate fue modificado hace 6 años, 9 meses por cybmeta.
    • Este debate fue modificado hace 6 años, 9 meses por cybmeta.
Viendo 6 respuestas - de la 1 a la 6 (de un total de 6)
  • Moderador Fernando Tellado

    (@fernandot)

    Es real y una de las más conocidas de WordPress

    https://ayudawp.com/como-proteger-wordpress-de-la-vulnerabilidad-pingback/#Que_es_la_8220vulnerabilidad_Pingback8221

    Si no eres amigo de códigos puedes controlar que dejas abierto o no con el plugin ithemes security, que tiene ajustes específicos para ello

    Moderador Fernando Tellado

    (@fernandot)

    Y si quieres saltarte la restricción del hosting puedes hacer esto

    https://ayudawp.com/como-solucionar-el-error-http-403-de-conexion-con-jetpack/

    Iniciador del debate cybmeta

    (@cybmeta)

    Fernando, esa vulnerabilidad especifica fue real hace unos cuantos años ya. En concreto, se solucionó hace 4 años: https://core.trac.wordpress.org/ticket/4137

    Hoy por hoy, más allá de genéricos DDoS y fuerza bruta, no parece que haya más. Si eso vale para bloquear xmlrpc.php, valdría para bloquear cualquier arvhivo PHP. Es ilógico para mí.

    • Esta respuesta fue modificada hace 6 años, 9 meses por cybmeta.

    Esa empresa de hosting tiene un buen argumento para bloquear el archivo wp-login.php según sus argumentaciones, o por ejemplo no permitir instalar el Revolution Slider por citar uno.

    He visto gracias a webalizer o awstats hasta 2 gb de peticiones en un mes al archivo xmlrpc.php , siendo la mayor url solicitada con diferencia (por eso está tan a la vista). Eso aunque no consigan el objetivo, consume muchos recursos y puede ser un pseudo DDOS.

    Aunque este sistema permite una conexión con aplicaciones móviles, o incluso con herramientas de blogging como Open Live Writer, si un cliente no lo usa… no veo razones para no bloquearlo si el servidor va mejor.

    A nivel ético, habría que consultar al cliente antes de bloquear. O si eres un hosting, avisar-preguntar.

    Iniciador del debate cybmeta

    (@cybmeta)

    @javiguembe efectivamente, no hay razones para NO bloquearlo si un cliente no lo utiliza y el cliente quiere bloquearlo. ¿Pero bloquearlo forma predeterminada en todo el servidor para todos los usuarios?

    Para casos como el que cuentas, creo que lo suyo es un firewall o una solución a ese nivel que solucione el problema de verdad y evite esas solicitudes «maliciosas» a cualquier parte susceptible, que en WordPress es la web entera, como lo es cualquier web dinámica, no es un problema específico del archivo xmlrpc.php, ni de wp-login.php, ni de wp-cron.php, etc etc.

    Notad que hago mucho hincapié en problemas «específicos» y «genéricos». No creo que sea útil bloquear un archivo concreto sin problemas específicos aduciendo ataques genéricos para justificarlo. Intentar corregir problemas genéricos a nivel de aplicación lo veo un poco fuera de lugar. Un parche muy flojo.

    • Esta respuesta fue modificada hace 6 años, 9 meses por cybmeta.
    • Esta respuesta fue modificada hace 6 años, 9 meses por cybmeta.
Viendo 6 respuestas - de la 1 a la 6 (de un total de 6)
  • El debate ‘Bloquear xmlrpc.php por seguridad, ¿si o no?’ está cerrado a nuevas respuestas.