El fail2ban integrado de mailcow hace bien una cosa: detecta los ataques más ruidosos. Diez inicios de sesión fallidos en diez minutos se traducen en un bloqueo de treinta minutos. Después los olvida.
Todo lo más silencioso se cuela. Una dirección que prueba una contraseña cada pocos minutos, todo el día. Una botnet que reparte sus intentos entre cientos de direcciones para que ninguna active el umbral. Un escáner que recorre tu webmail buscando /.env o wp-login.php. Un buzón cuya contraseña se adivinó y que ahora envía spam. Una buena protección contra la fuerza bruta en mailcow tiene que ver todo eso, recordarlo y actuar solo cuando se lo indiques.
Eso es lo que hace Security para mailcow. Lee lo que mailcow ya registra, guarda el historial en la base de datos de mailcow, aplica 13 reglas para lo que fail2ban no detecta y bloquea a través del propio netfilter de mailcow, diseñado para que no puedas quedarte fuera. Este tutorial te lleva desde la instalación hasta una configuración ajustada y automática.
Requisitos previos
Antes de empezar, comprueba que tienes:
- mailcow-dockerized en Linux con docker compose y systemd.
- El mailcow Toolkit 0.6.0 o posterior — este producto es uno de los módulos de ese paquete, con su propia licencia.
- Acceso root en el host para ejecutar
install.sh. - HTTPS saliente desde el servidor hacia
medialab.workspara la comprobación de la licencia. - El contenedor netfilter de mailcow en ejecución — es lo que aplica los bloqueos. Si Manage external está activado en los ajustes de fail2ban de mailcow, netfilter no toca el cortafuegos y es tu propio cortafuegos el que tiene que aplicar la lista de mailcow.
- Opcional: un token de Cloudflare con Account → Account Firewall Access Rules → Edit, y un token de bot de Telegram si quieres alertas por Telegram.
Paso 1 — Instala el Toolkit y abre Sistema > Seguridad
En el host de mailcow, como root, ejecuta el instalador del Toolkit como de costumbre:
sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized --name <instance>
Si ya usas el Toolkit, actualízalo desde Sistema > Actualizaciones (Toolkit).
El instalador copia data/web/mlw-security/, crea las tablas del módulo en la base de datos de mailcow, añade el elemento de menú y el temporizador que se ejecuta cada minuto mlw-mailcow-security-<instance>.timer, y recarga php-fpm. Después abre Sistema > Seguridad en el menú de administración de mailcow.
Paso 2 — Activa la licencia
Abre Sistema > Actualizaciones (Toolkit) y busca la tarjeta Security para mailcow: pega la clave y actívala, o inicia la prueba de 30 días. En la shell, dentro de php-fpm-mailcow:
php /web/mlw-toolkit/cli.php activate mailcow-security <KEY>
Sin una licencia válida no se lee, detecta, bloquea ni envía nada — pero los bloqueos existentes se levantan igualmente cuando caducan, y no se borra nada. Los detalles están en la guía de usuario.
Paso 3 — Entiende qué se está leyendo
La primera ejecución importa lo que mailcow aún conserva en sus registros (normalmente las últimas horas) y no bloquea ni alerta. A partir de ahí, la tarea lee solo las líneas nuevas, cada minuto, de fuentes que mailcow ya escribe:
- dovecot — inicios de sesión fallidos de IMAP / POP3 / ManageSieve con recuento de intentos, conexiones que nunca inician sesión, inicios de sesión correctos.
- postfix — AUTH SMTP fallido, envíos autenticados, rechazos de rspamd y de listas de bloqueo DNS, intentos de relay, sondeos de protocolo.
- SOGo — inicios de sesión fallidos y correctos del webmail.
- fail2ban — cada bloqueo que hace el propio fail2ban de mailcow.
- servidor web — respuestas 4xx, incluidas rutas de exploits conocidas y otros 404.
- php-fpm — inicios de sesión fallidos en la interfaz y la API de mailcow.
Se descartan los registros de direcciones privadas (los propios contenedores de mailcow, un proxy inverso delante de mailcow) y de las redes que ignores. El historial se conserva 90 días por defecto. Si Vista general > Estado indica que se perdieron líneas, mailcow recortó sus registros antes de leerlos — sube LOG_LINES en mailcow.conf.
Paso 4 — Lee el historial de ataques
Ve a Vista general. Verás los totales de las últimas 24 horas por tipo, un gráfico de 14 días de inicios de sesión fallidos, escaneos y spam por día, las direcciones más activas con un botón Bloquear, los buzones atacados y los incidentes activos. Un escudo rojo junto al menú Sistema muestra los incidentes graves abiertos en todas las páginas de administración, para que los veas sin tener que buscarlos.
Dedica unos minutos a esto antes de cambiar nada. Te dirá si tu servidor ve sobre todo ruido de fondo o una campaña real.
Paso 5 — Revisa las 13 reglas
Cada regla cuenta registros en una ventana deslizante y abre un incidente cuando se alcanza el umbral. Mientras el ataque continúa, el mismo incidente se amplía, no se repite. Los valores por defecto:
| Regla | Cuenta | Por defecto |
|---|---|---|
| Fuerza bruta en el acceso web | inicios de sesión fallidos en SOGo / interfaz / API por dirección | 5 en 15 min → bloqueo de 24 h |
| Fuerza bruta lenta | inicios de sesión fallidos por dirección a lo largo de un día | 20 en 24 h → bloqueo de 24 h |
| Password spraying | buzones distintos en los que falló una dirección | 5 en 60 min → bloqueo de 7 días |
| Reincidentes | bloqueos del fail2ban de mailcow de una dirección | 3 en 7 días → bloqueo de 30 días |
| Escaneo de exploits web | peticiones a rutas de exploits / filtraciones | 3 en 30 min → bloqueo de 7 días |
| Escaneo de 404 web | respuestas 404 por dirección | 40 en 30 min → alerta |
| Intentos de relay | «Relay access denied» por dirección | 3 en 60 min → bloqueo de 7 días |
| Escaneo de protocolo | conexiones que nunca inician sesión o rompen el protocolo | 30 en 60 min → alerta |
| Oleada de spam | rechazos de rspamd y de listas de bloqueo por dirección | 20 en 60 min → alerta |
| Buzón atacado | fallos en un buzón desde al menos 5 direcciones | 30 en 60 min → alerta |
| Pico de envío | mensajes enviados por un buzón | 300 en 60 min → alerta |
| Accesos desde muchas direcciones | direcciones distintas desde las que inicia sesión un buzón | 8 en 60 min → alerta |
| Acceso tras fallos | un primer acceso desde una dirección que falló en el buzón | 3 fallos en 24 h → alerta (crítica) |
En Reglas puedes desactivar cada regla y cambiar su umbral, ventana, acción y duración del bloqueo (0 = permanente). Las reglas de dirección pueden alertar o bloquear; las reglas de buzón pueden alertar, limitar el envío o impedir el inicio de sesión. Restablecer valores por defecto las devuelve todas.
Las últimas cuatro filas son tu detección de buzones comprometidos: un pico de envío, accesos desde muchas direcciones, fallos repartidos entre muchas direcciones en un mismo buzón y — la más precisa — un acceso desde una dirección que antes falló en ese buzón. Esa es una contraseña que probablemente se adivinó.
Paso 6 — Observa primero en modo de solo supervisión
El interruptor de la parte superior de Reglas está desactivado al principio. Cada incidente indica lo que se habría hecho («would ban»). Déjalo así unos días, revisa los incidentes, ajusta los umbrales y luego actívalo. Los incidentes cuyo ataque sigue en curso se actúan en la siguiente ejecución.
Cuando revises incidentes, usa Falso positivo cuando corresponda: pone la dirección en la lista de excepciones y levanta sus bloqueos.
Paso 7 — Activa las acciones automáticas
Con las acciones automáticas activadas, un bloqueo va a la lista negra fail2ban de mailcow durante lo que dure la regla. El netfilter de mailcow lo aplica en todos los puertos de mailcow en menos de un minuto, y lo ves en la propia página Fail2ban de mailcow. El módulo lo levanta cuando caduca; un bloqueo que borres en la página Fail2ban de mailcow cuenta como levantado.
Nunca se bloquean automáticamente:
- direcciones privadas y reservadas;
- la lista de excepciones del módulo (Ajustes) y la lista de excepciones de fail2ban de mailcow (Configuración > Fail2ban);
- las direcciones públicas del propio servidor;
- con proteger direcciones conocidas activado (por defecto), las direcciones que iniciaron sesión con éxito en un buzón en los últimos 30 días — así un compañero que se equivoca al escribir la contraseña no se queda fuera.
Paso 8 — Actúa sobre las cuentas a través del propio mailcow
Para un buzón que parece comprometido, las acciones sobre la cuenta pasan por las funciones propias de mailcow: impedir el inicio de sesión (el buzón sigue recibiendo correo), cerrar las sesiones de IMAP / POP3, exigir un cambio de contraseña, limitar el envío. Puedes hacerlo desde la vista de una dirección o de un buzón, que muestra de un vistazo fallos, accesos, envíos, incidentes y bloqueos. Cada acción — tuya o del módulo — queda registrada en el registro de auditoría.
Paso 9 — Bloqueos manuales y Cloudflare
Bloqueos muestra los bloqueos del módulo (motivo, quién, hasta cuándo, estado en Cloudflare), los bloqueos temporales propios de fail2ban de mailcow con Levantar o Hacerlo más largo, y el resto de la lista negra de mailcow. El formulario de la parte superior bloquea una dirección o una red (CIDR) de 1 hora a 30 días, o de forma permanente; se rechaza tu propia dirección actual.
Si la interfaz de mailcow y el webmail están detrás del proxy de Cloudflare, los ataques web llegan a mailcow desde las direcciones de Cloudflare y netfilter no puede detenerlos. En Ajustes > Cloudflare, elige bloqueos de las reglas web y bloqueos manuales marcados o todos los bloqueos: cada bloqueo pasa entonces también a ser una regla de acceso IP de Cloudflare a nivel de cuenta, que se elimina junto con el bloqueo.
Paso 10 — Alertas
Configura alertas por correo y Telegram a partir de la gravedad que elijas, con un límite por hora y, opcionalmente, un resumen diario. Las alertas van solo a la dirección y el chat que configures. Todo lo demás — registros, direcciones, nombres de buzones, historial — se queda en tu base de datos de mailcow y nunca se envía a medialab.works.
Una cosa más que conviene saber: cuando aparece una vulnerabilidad grave en PHP, nginx, SOGo u otro componente de mailcow, con la comprobación de la licencia puede llegar un parche virtual — una mitigación precisa, que se aplica automáticamente en las críticas. Reduce el riesgo hasta que actualices; no sustituye a la actualización.
Consejos y solución de problemas
- Los bloqueos no aparecen en el cortafuegos. Comprueba que el contenedor netfilter de mailcow está en ejecución. Si Manage external está activado, netfilter deja el cortafuegos en paz y es tu propio cortafuegos el que tiene que aplicar la lista de mailcow — la página Bloqueos te avisa de ello.
- Te has quedado fuera. El formulario de bloqueo manual rechaza tu dirección actual, y las direcciones conocidas están protegidas por defecto. Si aun así te alcanza, elimina el bloqueo en la página Fail2ban de mailcow — cuenta como levantado.
- Demasiadas alertas. Sube los umbrales o las gravedades por regla, o confía en el límite por hora y el resumen diario.
- Siguen llegando ataques web. Si estás detrás del proxy de Cloudflare, configura Cloudflare en Ajustes; netfilter por sí solo no puede ver al cliente real.
- Se perdieron líneas. Sube
LOG_LINESenmailcow.confen un servidor muy ocupado.
Conclusión
fail2ban sigue siendo la primera línea, y deberías mantenerlo. Security para mailcow es la segunda: un historial que se recuerda, 13 reglas para los ataques lentos y distribuidos, detección de buzones comprometidos y bloqueos que pasan por el cortafuegos en el que mailcow ya confía. Empieza en modo de solo supervisión, observa unos días y luego déjalo actuar. La página del producto tiene la lista de funciones, la guía cubre cada pantalla y el changelog registra lo que ha cambiado. Si algo no encaja con tu configuración, la base de conocimiento y las preguntas frecuentes son una buena siguiente parada, o contacta con nosotros.