Bloquear xmlrpc.php por seguridad, ¿si o no?
-
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?
-
Es real y una de las más conocidas de WordPress
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
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í.
@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.
- El debate ‘Bloquear xmlrpc.php por seguridad, ¿si o no?’ está cerrado a nuevas respuestas.