En resumen: una protección eficaz contra la fuerza bruta en un login se compone de varias capas: autenticación de dos factores para todos los administradores, un freno a los intentos de inicio de sesión en el servidor web, bloqueos automáticos a nivel de red y un almacenamiento seguro de contraseñas en el código. Donde sea posible, el área de administración solo debería ser accesible desde redes conocidas.
Cómo se desarrollan los ataques de fuerza bruta a los logins
Toda página de inicio de sesión accesible públicamente es atacada de forma automatizada tarde o temprano. Afecta a los logins de CMS, los backends de tiendas, los paneles de hosting, el webmail y SSH. Los atacantes no necesitan saber de quién es el sitio web; sus herramientas rastrean Internet en busca de direcciones de login conocidas.
Hay tres variantes extendidas. En la fuerza bruta clásica se prueban muchas contraseñas contra una cuenta. En el password spraying se prueba una contraseña frecuente contra muchas cuentas para eludir los bloqueos. En el credential stuffing se usan credenciales robadas en otros servicios.
Para la dirección y los propietarios, la situación se resume fácilmente: una cuenta de administrador tomada es tan peligrosa como una vulnerabilidad en el servidor. Quien es administrador puede instalar extensiones, modificar código y exportar datos.
Estos ataques se reconocen por una acumulación de inicios de sesión fallidos, por peticiones POST a la dirección de login desde muchas direcciones IP distintas y por intentos de inicio de sesión con nombres de usuario como «admin» o nombres del aviso legal. También una carga del servidor claramente mayor a horas inusuales puede ser un indicio, porque cada inicio de sesión cuesta tiempo de cálculo para comprobar la contraseña.
Protección contra fuerza bruta en el login: las medidas más eficaces
No toda medida encaja con todo sistema. El orden siguiente ha dado buen resultado, porque los primeros puntos combinan el mayor efecto con poco esfuerzo:
- Autenticación de dos factores para todas las cuentas con permisos de administrador. Entonces ni siquiera una contraseña adivinada basta. Los detalles, en la guía Autenticación de dos factores para accesos de administración.
- Contraseñas únicas y largas de un gestor de contraseñas, sin cuentas compartidas.
- Limitación de tasa en el servidor web, para que por dirección solo sean posibles pocos intentos por minuto.
- Bloqueos automáticos de direcciones repetidamente sospechosas a nivel de red, por ejemplo con Fail2ban.
- Reducir el área de administración: acceso solo desde la red de la empresa o por VPN, desactivar las interfaces que no se necesiten.
- Mensajes de error uniformes, que no revelen si el nombre de usuario existe.
- Supervisión de los inicios de sesión fallidos y notificación ante anomalías.
Limitación de tasa en el servidor web
Con Nginx se puede limitar por dirección IP el número de peticiones a una dirección de login. El ejemplo muestra una página de inicio de sesión de WordPress; adapte la ruta y el traspaso a PHP a su sistema.
# en el bloque http
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# en el bloque server
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
# incluir aquí el traspaso habitual a PHP de su servidor
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
En Apache, restringir el área de administración a direcciones conocidas ofrece una protección sencilla y eficaz:
<Location "/admin">
Require ip 192.0.2.0/24
</Location>
La dirección 192.0.2.0/24 es un marcador del ámbito reservado a la documentación; ponga la red de su empresa o la dirección de su VPN. Si su sitio web está detrás de un proxy o CDN, el servidor debe conocer la dirección real del visitante; de lo contrario, la regla no funciona como se desea.
Fail2ban y bloqueos a nivel de red
Fail2ban lee archivos de registro y bloquea en el cortafuegos, durante un tiempo determinado, las direcciones que llaman la atención de forma repetida. Para la limitación de tasa de Nginx, Fail2ban ya incorpora un filtro adecuado:
# /etc/fail2ban/jail.local
[nginx-limit-req]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 10m
bantime = 1h
[sshd]
enabled = true
maxretry = 5
bantime = 1h
Tras el reinicio, compruebe con fail2ban-client status si las jails están activas. Cuide de excluir sus propias direcciones fijas mediante ignoreip, para no bloquearse a sí mismo. Para las páginas de inicio de sesión de CMS concretos son posibles filtros propios, pero deben encajar con el formato real del registro y probarse antes.
Si delante del servidor hay un CDN o proxy, Fail2ban sin más ajustes solo ve sus direcciones. Un bloqueo afectaría entonces a todos los visitantes. En ese caso, el servidor web debe tomar la dirección real del visitante de la cabecera del servicio antepuesto, y los bloqueos se establecen mejor directamente en el CDN.
Los bloqueos a nivel de red son una herramienta contra el volumen, no contra los ataques dirigidos. Los ataques distribuidos desde muchísimas direcciones con pocos intentos por dirección burlan cualquier umbral. Por eso el segundo factor sigue siendo la capa más importante, y Fail2ban reduce sobre todo la carga y el ruido en los registros.
Guardar bien las contraseñas en software propio
Quien programa inicios de sesión propios nunca debería guardar contraseñas en texto claro ni con funciones hash rápidas como MD5 o SHA-1. PHP incorpora con password_hash() una solución segura que gestiona automáticamente la sal y el procedimiento.
<?php
declare(strict_types=1);
// En el registro o al cambiar la contraseña
$hash = password_hash($passwort, PASSWORD_DEFAULT);
// En el inicio de sesión
if (password_verify($eingabe, $hashAusDatenbank)) {
if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
$neu = password_hash($eingabe, PASSWORD_DEFAULT);
// guardar $neu en la base de datos
}
// Inicio de sesión correcto, renovar el ID de sesión
} else {
usleep(random_int(200000, 400000)); // tiempo de respuesta uniforme
// mostrar un mensaje de error uniforme
}
password_needs_rehash() hace que los hashes antiguos se migren automáticamente al procedimiento actual en el siguiente inicio de sesión. Registre los intentos fallidos con hora, cuenta y dirección, para que se noten los patrones. Encontrará indicaciones para el análisis en la guía Analizar los registros del servidor web tras un ataque.
Particularidades de CMS, tiendas y paneles
Muchos sistemas tienen, además de la página de inicio de sesión visible, otras vías por las que se comprueban credenciales. Estas entradas secundarias se olvidan a menudo en la protección.
- WordPress: la interfaz
xmlrpc.phptambién acepta inicios de sesión. Si no se necesita, por ejemplo para aplicaciones antiguas, bloquéela en el servidor web. Compruebe además si los nombres de usuario son visibles a través de las páginas de autor o de la interfaz REST, y use para los administradores nombres que no aparezcan públicamente. - Tiendas: además del área de administración, las cuentas de clientes son un objetivo, sobre todo para el credential stuffing. Aquí ayudan la limitación de tasa, las notificaciones de nuevos inicios de sesión y un segundo factor opcional para los clientes.
- Paneles de hosting y webmail: estas interfaces suelen ser accesibles desde todo el mundo y protegen el servidor entero. Solo deberían ser accesibles desde redes conocidas o por VPN.
- SSH: iniciar sesión con clave en lugar de contraseña vuelve inútil la adivinación clásica.
Qué funciones de protección incorpora su propio sistema figura en la documentación del fabricante. Las extensiones de terceros deberían mantenerse activamente; de lo contrario, se convierten en un riesgo. Para los responsables de WordPress, la página WordPress y PHP2Shell resume las prioridades actuales.
¿Cómo ayuda PHP SOS en concreto?
- Registramos todas las páginas de inicio de sesión accesibles de sus servidores, del CMS al panel de hosting, y valoramos su protección.
- Configuramos la limitación de tasa, Fail2ban y las restricciones de acceso en el marco del refuerzo del servidor y las probamos.
- Acompañamos la introducción de la autenticación de dos factores para administradores y documentamos los accesos de emergencia.
- Con la monitorización de seguridad mantenemos bajo vigilancia constante los inicios de sesión fallidos y las nuevas cuentas de administrador.
Preguntas frecuentes
¿Cómo reconozco un ataque de fuerza bruta?
Lo típico son muchos inicios de sesión fallidos en poco tiempo, a menudo contra la misma página de inicio de sesión y con nombres de usuario cambiantes. En el registro de acceso se ve como una acumulación de peticiones POST a la dirección de login, con frecuencia desde muchas direcciones IP distintas.
¿Debería bloquearse una cuenta tras varios intentos fallidos?
Cuidado: los bloqueos duros pueden ser aprovechados por los atacantes para dejar fuera a usuarios legítimos. Es mejor aplicar retrasos crecientes, bloqueos temporales por dirección IP y una notificación al titular de la cuenta.
¿Ayuda cambiar el nombre de la dirección de login?
Reduce el ruido automatizado en los registros, pero no es una protección real. Quien conozca o encuentre la dirección puede seguir atacando. Son eficaces la autenticación de dos factores, la limitación de tasa y una restricción del área de administración.
¿Qué es el credential stuffing?
Los atacantes prueban combinaciones de correo y contraseña robadas en otros servicios. Funciona cuando los usuarios emplean la misma contraseña varias veces. Las contraseñas únicas y un segundo factor quitan la base a este método.