Ataques de fuerza bruta en WordPress: cómo detectar, contener y recuperar
Una oleada de intentos de login no significa automáticamente que el atacante haya entrado. Pero tampoco conviene descartarla: el objetivo es distinguir ruido de un acceso logrado, bajar la carga y proteger las cuentas sin dejar afuera a usuarios legítimos.
Qué mirar antes de bloquear
Reuní logs del servidor, WAF o hosting y anotá hora de inicio, volumen de peticiones, rutas atacadas, códigos de respuesta y cuentas objetivo. Las rutas habituales incluyen el inicio de sesión y, según el sitio, interfaces remotas. La guía oficial de WordPress sobre ataques de fuerza bruta propone combinar prevención y limitación de intentos.
Un pico de errores de autenticación puede ser un bot que prueba credenciales sin éxito; una sesión administrativa nueva, cambios inesperados de usuarios o archivos modificados exige tratar el caso como posible compromiso. No confundas una solicitud HTTP exitosa con un login correcto: necesitás registros de autenticación o evidencia equivalente.
Primeros 30 minutos: contención ordenada
- Conservá los registros antes de rotarlos o borrar archivos: fecha, zona horaria, origen y ruta son necesarios para reconstruir el incidente.
- Verificá el acceso del equipo por una conexión confiable y prepará una forma de revertir reglas.
- Aplicá limitación de intentos o desafíos en la capa de red si la tenés disponible; evitá bloquear países enteros por intuición.
- Activá MFA para administradores y revisá cuentas con permisos elevados.
- Si hay sospecha de acceso logrado, cambiá credenciales desde dispositivos confiables y cerrá sesiones activas.
Bloquear cada IP manualmente puede ser interminable si el tráfico rota entre redes. Una regla basada en tasa, ruta y comportamiento suele ser más sostenible. Ajustala con cuidado si el sitio tiene una aplicación móvil, integraciones o muchos usuarios que inician sesión desde una misma red empresarial.
Cómo reforzar el acceso después del pico
Exigí contraseñas únicas para cada cuenta y, especialmente, para administradores. MFA añade una barrera si una contraseña se filtra, aunque no corrige un plugin vulnerable ni una sesión robada. Reducí cuentas administradoras a las personas que realmente lo necesitan y quitá usuarios de exempleados o proveedores inactivos.
Configurá limitación progresiva de intentos y alertas por patrones anómalos. Una política demasiado estricta puede dejar fuera a usuarios reales o permitir que un atacante provoque bloqueos de cuentas ajenas. Probá varios intentos fallidos con una cuenta de ensayo y luego un acceso legítimo. Documentá quién puede desbloquear y cómo.
Actualizá núcleo, plugins y temas desde fuentes confiables. El manual de seguridad de WordPress recomienda mantener el software al día, aplicar permisos adecuados y contar con copias de seguridad. Un ataque al login puede coexistir con una extensión vulnerable; no reduzcas toda la revisión a contraseñas.
Si sospechás que alguien entró
Revisá usuarios nuevos, cambios de rol, entradas editadas, tareas programadas, plugins activados y archivos modificados. Comprobá si aparecieron redirecciones, contenido ajeno o formularios que capturan datos. Conservá evidencia antes de restaurar. Si hay datos personales o pagos, involucrá al responsable técnico y legal para evaluar obligaciones de notificación.
Restaurar un backup sin cerrar la puerta de entrada sólo repite el incidente. Identificá versión y extensión comprometida, rotá claves y tokens relevantes, y verificá que el respaldo provenga de antes del acceso. Después de limpiar, controlá logs y funcionamiento durante varios días. Un escaneo sin alertas no demuestra por sí solo que todo quedó resuelto.
Errores frecuentes
- Cambiar sólo la URL de login: reduce ruido simple, pero no impide otros vectores ni sustituye MFA.
- Bloquear todas las IP de un país: puede afectar usuarios legítimos y no frena proxies distribuidos.
- Instalar varias suites a la vez: dificulta distinguir qué regla bloquea y puede sobrecargar el servidor.
- No probar la recuperación: una copia de seguridad sin restauración ensayada es una hipótesis, no un plan.
Qué registrar para saber si mejoró
Compará períodos equivalentes antes y después de la mitigación: peticiones por minuto al login, respuestas bloqueadas en el borde, autenticaciones fallidas y exitosas, carga del servidor y quejas de usuarios legítimos. Una baja de peticiones que llegan a PHP puede liberar recursos; una caída de intentos fallidos dentro de WordPress puede ser simplemente que ahora el firewall los frena antes. No atribuyas ambos indicadores a una reducción de ataques en internet.
Guardá ejemplos de eventos, pero no vuelques contraseñas, tokens o datos personales a un informe compartido. Si detectás un origen persistente, podés ajustar reglas temporales; mantené una fecha de revisión para no acumular bloqueos que nadie recuerda. Si el ataque se desplaza a otra ruta, investigá el nuevo patrón antes de ampliar la regla.
El cierre del incidente debe incluir una cronología, cambios realizados, cuentas revisadas, evidencia de recuperación y medidas preventivas pendientes. Ese registro evita repetir la misma investigación ante el próximo pico y permite distinguir un problema resuelto de uno que sólo dejó de ser visible.
Preguntas frecuentes
¿Miles de intentos significan que mi web fue hackeada?
No necesariamente. Confirmá si hubo autenticaciones exitosas, cambios de cuentas o archivos y otras señales de compromiso. El volumen por sí solo describe presión, no el resultado.
¿Un CAPTCHA alcanza?
Puede frenar bots simples, pero debe combinarse con MFA, contraseñas únicas, límites y mantenimiento. También puede perjudicar accesibilidad o usuarios reales si está mal configurado.
¿Cuándo necesito ayuda especializada?
Si hay una cuenta administrativa desconocida, archivos alterados, fuga potencial de datos, pagos afectados o no podés reconstruir qué pasó, tratá el caso como incidente y buscá respuesta técnica especializada.
Alcance: esta guía es informativa. La configuración y respuesta a incidentes dependen del sitio, el proveedor y sus registros. Revisá la documentación y probá los cambios antes de aplicarlos en producción.