Ir al contenido 
Fail2Ban Plesk ofrece una protección eficaz contra ataques de fuerza bruta a su entorno de servidor Plesk con unos pocos clics y bloquea automáticamente las IPs sospechosas. Le mostraré paso a paso cómo instalar Fail2Ban, activar jaulas, personalizar reglas y configurar notificaciones para que su Servidor permanece permanentemente limpio.
Puntos centrales
Los siguientes puntos clave le darán una visión general compacta antes de entrar en detalles y mostrarle cómo implementarlos en el panel. Cómo configurar el Prioridades desde el principio.
- Instalación a través de Herramientas y Ajustes y activación inmediata
- Cárceles Uso específico para SSH, correo, panel Plesk y WordPress
- Parámetros como el tiempo de prohibición, la ventana de detección y los intentos fallidos
- Lista blanca Mantener para IPs de confianza y comprobar bloqueos
- Monitoreo de los registros para afinar y reducir las falsas alarmas.
Qué hace Fail2Ban - explicado brevemente
Análisis Fail2Ban Protocolos de servicios como SSH, correo, servidor web o el panel Plesk y reconoce los intentos fallidos recurrentes. Si una IP supera los umbrales definidos, la bloqueo automáticamente durante un periodo de tiempo determinado. De este modo, evito de forma fiable la fuerza bruta, los ataques de diccionario y los escaneos automáticos con un esfuerzo mínimo. Gastos. Plesk proporciona una interfaz clara en la que puedo activar o desactivar las jaulas y ajustar los parámetros. Para servidores productivos, esta protección es una de las medidas más rápidas con un efecto notable.
Instalación en Plesk: Requisitos previos e inicio
Yo uso un servidor Plesk actual en Linuxidealmente Obsidian, y primero compruebo si el componente Fail2Ban ya está presente. Si no está, abro Herramientas y Configuración en Plesk, voy a Actualizaciones y selecciono Agregar/Quitar Componentes. Allí activo la entrada Fail2Ban e inicio el componente Instalación. Una vez completado, aparece la sección Bloquear direcciones IP (Fail2Ban), en la que activo y controlo la función. Para una configuración completa, combino Fail2Ban con un cortafuegos bien configurado; los detalles se pueden encontrar en Configurar el Firewall de Plesk.
Configuración básica: seleccione valores por defecto razonables
Tras el encendido, compruebo los parámetros globales que determinan el efecto y las falsas alarmas. Con un equilibrado Tiempo de prohibición Mantengo fuera a los atacantes sin bloquear permanentemente a los usuarios legítimos. La ventana de detección controla durante cuánto tiempo Fail2Ban recopila los intentos fallidos, y el número máximo de intentos fallidos establece el umbral para el bloqueo. También introduzco una dirección de correo electrónico para las notificaciones, de modo que pueda ver inmediatamente los eventos críticos. La siguiente tabla muestra valores iniciales comunes que han demostrado su eficacia en muchas configuraciones y que pueden refinarse en cualquier momento.
| Parámetros | Recomendación | Efecto |
|---|---|---|
| Tiempo de prohibición | 600-1800 segundos | Bloquea notablemente a los atacantes sin bloquear permanentemente a los usuarios |
| Ventana de reconocimiento | 300-600 segundos | Pruebas agregadas en un plazo razonable |
| Max. Intentos fallidos | 3-5 | Reduce los falsos positivos y sigue siendo estricto |
| Notificación | Activar correo electrónico | Avisos de cierre y acontecimientos importantes |
Además, justo al principio defino un Ignorar lista (lista blanca) a nivel global. En Herramientas y configuración > Bloquear direcciones IP, introduzco las direcciones IP estáticas de la oficina, los puntos finales VPN o las redes de gestión. Para IPv6, utilizo prefijos coherentes (por ejemplo, /64) con precaución y mantengo la lista reducida para que no se debilite la protección. Para los alborotadores recurrentes, una Tiempo de prohibición incremental probada: Con parámetros como bantime.increment = true, bantime.factor y bantime.maxtime Prolongo automáticamente los bloqueos si se repiten, garantizando así un efecto duradero.
Cárceles: protección específica de los servicios
En la pestaña Cárceles, activo las reglas de protección para las más importantes Servicios: sshd, dovecot, proftpd, plesk-apache, plesk-panel y plesk-wordpress. Cada jaula supervisa los archivos de registro que coinciden, reconoce patrones y bloquea IPs llamativas. Para servidores con instancias de WordPress, activo plesk-wordpress para bloquear ataques de inicio de sesión en wp-login y xmlrpc. Si no se está ejecutando ningún FTP, desactivo la jaula asociada para que el servidor no realice comprobaciones innecesarias. A continuación, compruebo si los bloqueos funcionan de forma fiable y ajusto los valores umbral si hay demasiados falsos positivos.
A modo de orientación: sshd suele leer de /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL/Alma/Rocky), los inicios de sesión de correo terminan en /var/log/maillog respectivamente /var/log/mail.logel panel se conecta /var/log/plesk/panel.log. Para los ataques web, las jaulas de Plesk acceden a los registros de hosts virtuales bajo /var/www/vhosts/sistema//logs/ a. Si sólo está ejecutando NGINX o una configuración Apache+NGINX, los filtros de Plesk seguirán funcionando ya que las rutas apropiadas ya están almacenadas.
Cree sus propias jaulas y filtros de forma limpia
¿Necesito más Protección para una aplicación, creo una nueva jaula y consulto los registros asociados. Defino una ventana de tiempo clara, establezco el límite de fallos y determino el tiempo de prohibición deseado. Para aplicaciones especiales, escribo filtros con expresiones regulares que reconocen mensajes de error específicos. Tras activar la regla, la pruebo simulando un intento fallido y comprobando los registros. Si detecto un patrón que los atacantes pueden eludir, refino el filtro y registro el cambio para mi Documentación.
Para garantizar que las personalizaciones permanezcan a salvo de actualizaciones, creo Configuraciones propias en /etc/fail2ban/jail.d/ como archivos separados (por ejemplo custom-wordpress.local) en lugar de cambiar los archivos estándar. De esta forma, una actualización de Plesk o de un paquete no sobrescribe mis reglas. Pruebo las reglas de filtrado con fail2ban-regex contra los registros de muestra antes de cambiar una cárcel a productiva. Después de los cambios, un systemctl reload fail2banpara que se activen sin reiniciar el sistema.
Listas blancas, desbloqueo y comprensión de las IP bloqueadas
Si ocurre que me bloqueo a mí mismo o a un miembro del equipo, abro la lista de direcciones IP bloqueadas y vuelvo a desbloquear la dirección. Para las fuentes de confianza permanente, utilizo la lista blanca y así evito futuras Atascos. En la vista general, puedo ver qué jaula ha bloqueado una IP y para qué regla se ha detectado. Esta información me ayuda a reconocer aplicaciones mal configuradas o bots. Mantengo la lista blanca limpia y sólo mantengo entradas si hay una buena razón para hacerlo. Razón allí.
¿Trabaja detrás de un Proxy/CDNPresto especial atención a la lista blanca: Si los inicios de sesión y los accesos a la web están detrás de las IP del proxy inverso desde el punto de vista del servidor, una cárcel configurada de forma descuidada bloqueará, en el peor de los casos, al proxy en lugar de al atacante real. En este caso, me aseguro de que el servidor web escriba correctamente la IP "real" del cliente en los registros (mecanismo X-Forwarded-For/Actual Real-IP) y mantenga las redes proxy como de confianza. Esto garantiza que los bloqueos sigan siendo precisos.
Evitar errores: puesta a punto sensata desde la práctica
Empiezo con moderación Umbrales y sólo ajusto los valores una vez que conozco los perfiles típicos de carga y uso. Para hosts compartidos con muchos usuarios, el riesgo de falsos bloqueos aumenta, por lo que establezco MaxRetry más alto y controlo los registros más de cerca. Si los bots llegan a sus formularios, vale la pena echar un vistazo a los registros del servidor web y a las reglas adicionales en la jaula plesk-apache. He configurado 2FA para los inicios de sesión de administrador y así aliviar Fail2Ban porque menos intentos de inicio de sesión llegan al panel. Un vistazo regular a la lista de bloqueos me muestra si un individuo Fuente es especialmente llamativo y requiere más medidas.
Combinación de cortafuegos y endurecimiento de WordPress
Fail2Ban bloquea a los atacantes tras intentos fallidos, mientras que el cortafuegos reduce por adelantado la superficie de ataque. La combinación de ambos proporciona Seguridadespecialmente con SSH expuesto o puertos de correo. Para WordPress, restrinjo xmlrpc, establezco un límite de tasa de inicio de sesión a nivel de aplicación y dejo que plesk-wordpress haga el resto del trabajo. Esto te da una defensa en profundidad en lugar de una única barrera. Puedes encontrar una comparación más detallada en este artículo: Comparación entre Fail2Ban y el cortafuegosque le ayudará a coordinar las medidas.
Comprobación práctica para administradores de Plesk
Una vez configurado, compruebo que los bloqueos se producen dentro del plazo previsto y que llegan las notificaciones por correo electrónico. A continuación, pruebo SSH con contraseñas deliberadamente incorrectas y compruebo los registros para verificar la eficacia de la Cárceles para confirmar. Para el panel Plesk, simulo varios inicios de sesión fallidos y observo si la IP se bloquea rápidamente. Si aparecen demasiados bloqueos legítimos, aumento MaxRetry paso a paso y amplío moderadamente la ventana de detección. Este enfoque coherente reduce al mínimo las falsas alarmas y garantiza un funcionamiento silencioso. Operación.
Integración del alojamiento: en qué me fijo
Una configuración de alojamiento sólida proporciona Fail2Ban, cortafuegos, copias de seguridad y monitorización de forma coherente. Presto atención a la integración directa con Plesk, tiempos de respuesta cortos en soporte y claridad. Documentación. con contenedores de servicio aislados y actualizaciones constantes del núcleo me proporcionan seguridad adicional. Para los proyectos productivos, también confío en las copias de seguridad externas para poder volver a conectarme rápidamente en caso de emergencia. Esto crea un nivel de seguridad que dificulta mucho más los ataques y que puede realizarse con un nivel de seguridad razonable. Gastos puede mantenerse.
Supervisión y solución de problemas: cómo estar al tanto de todo
Analizo regularmente el resumen de Fail2Ban, compruebo los bloqueos Direcciones y reconozco las fuentes recurrentes. Si encuentro patrones, ajusto las reglas de filtrado y documento los cambios para poder rastrearlos más adelante. Si los registros muestran fuertes picos de carga, establezco límites adicionales en el servidor web y refuerzo el cortafuegos. Al mismo tiempo, mantengo Plesk, los paquetes del sistema y los plugins actualizados para minimizar las superficies de ataque; puede encontrar consejos probados en esta guía para Cerrar brechas de seguridad en Plesk. Esto mantiene su protección al día y Fail2Ban necesita menos Trabajo para actuar.
Protocolos backends y rutas en Plesk
Para que la detección sea fiable, es fundamental que Fail2Ban disponga de los datos correctos. Fuentes de protocolo lee. En Linux, utilizo registros de archivos o el backend systemd, dependiendo de la distribución. Las configuraciones modernas se benefician de backend = systemdya que Fail2Ban lee el diario directamente y genera menos E/S en los archivos de registro. Plesk ya tiene una configuración sensible por defecto para esto. No obstante, compruebo aleatoriamente si las rutas de registro en las jaulas coinciden con la realidad: SSH en /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL/Alma/Rocky), Mail in /var/log/maillog o /var/log/mail.logPanel Plesk en /var/log/plesk/panel.logWeb en los directorios vhost. Si las rutas o los nombres de los diarios no son correctos, corrijo las entradas en un .local-archivo. De este modo, evito puntos ciegos en los que los ataques pasan desapercibidos.
IPv6, banaction y backend de cortafuegos
Muchas instalaciones ya no filtran sólo IPv4. Me aseguro de que el Banactions son adecuados para IPv6 (por ejemplo, variantes multipuerto para iptables/firewalld). Si el sistema utiliza Firewalld, presto atención a acciones como firewallcmd-multiportpara configuraciones iptables clásicas a iptables-multiport o acciones basadas en ipset para un mejor rendimiento. Es importante que la acción utilizada en Fail2Ban coincida con el cortafuegos activo de Plesk - de lo contrario los bloqueos acaban en la cadena equivocada o no surten efecto en absoluto. Después de los cambios, hago pruebas específicas: intentos fallidos simulados desde una IP de prueba, consulta de estado de la jaula y, a continuación, una prueba de conexión. Si los bloqueos IPv6 funcionan de forma fiable, habré cerrado una brecha importante que a menudo se pasa por alto en las redes mixtas.
Encierros crecientes y bloqueos a largo plazo (reincidencia)
Con atacantes recurrentes, aumento la presión: con tiempos de prohibición incrementales (bantime.increment) los bloqueos se amplían automáticamente - aproximadamente el doble por bantime.factor = 2 - hasta un máximo razonable (bantime.maxtime). También utilizo recidive-Jail que detecta IPs que aparecen varias veces en diferentes jaulas dentro de una ventana más larga. Una configuración con encontrar la hora en el rango de horas a días y un periodo de prohibición de varios días ha demostrado su eficacia. Este nivel tiene un efecto duradero contra los bots que vuelven regularmente sin excluir permanentemente a los usuarios legítimos. Sigue siendo importante utilizar redes fiables a través de ignoreip y vigilar los efectos a través de la lista negra.
Flujo de trabajo CLI: comprobar, recargar, desbloquear
Aunque Plesk ofrece una interfaz cómoda, resuelvo muchos rápido a través de la consola. Con estado de fail2ban-client Veo cárceles activas, fail2ban-client estado lista las IPs bloqueadas y los contadores. Cargo nuevas reglas con systemctl reload fail2banSi es necesario, reinicio el servicio. Borro las IP individuales (fail2ban-client set unbanip) sin afectar a todo el sistema. Para solucionar problemas journalctl -u fail2banpara leer los últimos acontecimientos, incluida la información sobre filtros defectuosos. Esto me permite simplificar las operaciones, documentar brevemente las intervenciones e incorporar los resultados a las normas.
Funcionamiento detrás de proxy/CDN, ModSecurity y detalles de WordPress
Hoy en día, muchos sitios web Proxies inversos o CDNs. Para asegurarme de que Fail2Ban evalúa al cliente real, me aseguro de que el servidor web anota la IP correcta en el registro y de que las redes proxy están en la lista blanca. De lo contrario, corro el riesgo de bloquear involuntariamente redes de borde enteras. En Plesk también utilizo ModSecurity (WAF): ModSecurity bloquea los patrones de ataque conocidos a nivel HTTP, mientras que Fail2Ban sanciona los intentos fallidos de inicio de sesión o los patrones 4xx/5xx repetidos. Para WordPress, adopto un enfoque doble: restringir o asegurar xmlrpc, establecer límites de tasa de inicio de sesión a nivel de aplicación y utilizar el método plesk-wordpress-jail activo. De esta manera desactivo el ruido en el registro y dejo que Fail2Ban se centre en los casos difíciles.
Mantenimiento, copias de seguridad y estrategia de actualización
Para garantizar que los ajustes duren a largo plazo, guardo todos los normas propias en archivos separados bajo /etc/fail2ban/jail.d/ y documentar los cambios versionados. Antes de actualizaciones importantes de plesk o del sistema, creo una instantánea/copia de seguridad y luego compruebo aleatoriamente si las jaulas siguen activas y las rutas son correctas. También tengo en cuenta la rotación de los registros: después de una rotación (nuevo archivo de registro), el backend debe seguir leyendo de forma fiable; con systemd-Journal, esta preocupación desaparece en gran medida. Establezco breves procedimientos operativos normalizados para los equipos: cómo se desbanean las IP, se ajustan los umbrales y se comprueban las notificaciones. Esto garantiza que la gestión siga siendo coherente, aunque cambien las responsabilidades.
Sentencia judicial: protocolos y almacenamiento
La seguridad también necesita Dimensión. Sólo almaceno la información necesaria para la defensa y el diagnóstico, establezco periodos de retención claros y borro los datos antiguos con regularidad. Fail2Ban en sí no almacena ningún dato a largo plazo; la base son sus registros de sistema y web. Un nivel de registro reducido en el funcionamiento regular (por ejemplo, INFO) mantiene la cantidad de datos manejable, mientras que yo lo aumento temporalmente a DEBUG para los análisis y luego vuelvo a cambiarlo. Así combino una protección eficaz con un rastro de datos sencillo y rastreable.
En pocas palabras: implantación segura en unos pocos clics
Activo Fail2Ban a través de Plesk, establezco parámetros equilibrados, enciendo el adecuado Cárceles y mantengo una lista blanca ajustada. Con un cortafuegos complementario, 2FA y actualizaciones limpias, consigo un alto nivel de protección sin lastres. Los filtros personalizados me permiten controlar casos especiales, mientras que las notificaciones y los registros simplifican mi trabajo diario. Si sigue estos pasos al pie de la letra, reducirá notablemente los intentos de fuerza bruta y protegerá de forma eficiente los inicios de sesión de administrador, el correo y SSH. Cómo mantener seguro su servidor Plesk con Fail2Ban permanentemente resistente y fácil de administrar.
