Italiano
Română
Русский¿Cómo desactivo la capacidad de iniciar sesión?
Durante un gran ataque de fuerza bruta, me gustaría desactivar por completo la capacidad de iniciar sesión en WordPress. La única cuenta en el sitio es la mía, así que no hay razón para que los visitantes inicien sesión y no afectaría su experiencia en el sitio.
Cuando necesite iniciar sesión, puedo eliminar el código. Alternativamente, puedo limitar los inicios de sesión solo a mi dirección IP.
Estoy intentando lograr esto capturando un intento de inicio de sesión lo antes posible con el siguiente código:
if (isset($_POST['pwd']) || isset($_GET['pwd'])) {
header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found");
echo 'los inicios de sesión están deshabilitados en este sitio';
die();
}
Esto es rudimentario pero debería funcionar. Sin embargo, todavía hay algunos intentos de inicio de sesión que logran pasar y no sé de dónde podrían venir.
¿De qué otra manera WordPress acepta inicios de sesión, si no es con el campo 'pwd'?
¿Existe alguna convención existente para desactivar los inicios de sesión?
Edición: además de detener wp-login.php, eliminé xmlrpc.php que se estaba utilizando como otra entrada para forzar inicios de sesión. Mi configuración actual no lo necesita, pero la tuya podría. Asegúrate de no necesitarlo antes de deshabilitarlo.
Eso es útil, pero estoy buscando una forma de cortocircuitar el inicio de sesión desde el principio. Tengo Sucuri y otro plugin instalados que me alertan sobre ataques de fuerza bruta. Me preocupa que esto aún active las acciones en esos plugins.
Michael Khalili
@MichaelKhalili, realmente no puedes hacer eso ya que los intentos de inicio de sesión pueden provenir de todo tipo de fuentes. Si estás interesado en bloquear solo wp-login.php o xmlrpc.php, deberías hacerlo a nivel de configuración del servidor web (htaccess en Apache puede hacer el truco también) y no dejar que se ejecute PHP en absoluto. El único código PHP comparable (en términos de rendimiento) necesitaría una modificación de wp-config.php, que es un archivo que deberías evitar tocar tanto como sea posible. Cualquier otra solución basada en PHP no será mejor en términos de rendimiento que la respuesta.
Mark Kaplun
Lo he resuelto desde que publiqué la pregunta y actualicé mi publicación. Puedo colocar el código que busca $_POST['pwd'] en un plugin de uso obligatorio (mu-plugins) y deshabilitar xmlrpc.php. Eso parece estar funcionando. Detuve la mayoría de los ataques con $_POST['pwd'] y el resto se detuvo después de deshabilitar xmlrpc.php.
Michael Khalili
El problema con eliminar archivos es que volverán cuando actualices. Es mejor bloquearlos en el htaccess si no usas xmlrpc
Mark Kaplun
Excelente observación Mark. Creo que también hay una configuración para desactivar el soporte de xmlrpc dentro de WordPress. Necesito reservar tiempo para probar eso. Ni siquiera estoy seguro de cuál es el mecanismo de inicio de sesión dentro de ese archivo.
Michael Khalili
Lo siento, pero es una muy mala idea poner el código en el archivo wp-config.php. Además, no veo en qué se diferencia tu código de la otra respuesta.
Johansson
La respuesta anterior de Mark K fue actualizada por ti, Jack, ayer, corrigiendo el error tipográfico que yo había arreglado.
Es mala idea poner código en wp-config, esto fue para un escenario de emergencia para alguien que sabe lo que está haciendo. Cuanto antes intervengamos, menos recursos necesita cargar WP para bloquear inicios de sesión.
Branndon
Cualquiera que esté considerando esto debe recordar que las solicitudes ajax públicas aún se hacen al directorio wp-admin. Si tu sitio usa ajax, deberías desbloquear la ruta a admin-ajax.php
Michael Khalili
Y como WP usa AJAX en el núcleo, esto no debería hacerse en ningún lugar.
kaiser
Estoy de acuerdo en que no es la solución para "deshabilitar" el registro de usuarios/login, que es la pregunta aquí. Pero @kaiser, ¿por qué dices que esto no debería hacerse? Lo hago en dos sitios web que administro personalmente donde no hay registro de usuarios habilitado. También uso protección con contraseña en .htaccess para el archivo wp-login.php. Si está configurado correctamente, las solicitudes Ajax y otras cosas de wp-admin (JS, CSS, imágenes) no son un problema en absoluto y puede reducir drásticamente las posibilidades de éxito de ataques de fuerza bruta.
cybmeta
@cybmeta ¿renombraste wp-admin?
kaiser
No, no lo hice. Esa es otra opción pero es menos segura, la URL de administración del sitio puede descubrirse fácilmente, sin importar qué nombre le hayas dado. De cualquier forma, eso no explica por qué bloquear el acceso a esa ubicación no debería hacerse en absoluto. Además, no veo cómo cambiar el nombre es mejor que bloquear el acceso a cierta ubicación. Ten en cuenta que el contexto es que nadie excepto tú va a acceder allí, ¿por qué bloquear el acceso a cualquier otro es malo? Actualmente, en el caso de que solo tú tengas permitido acceder a wp-admin, bloquearía wp-admin con .htaccess incluso si el nombre está cambiado.
cybmeta