Correo: Fuerza bruta en IMAP/SMTP — protégelo sin dejarte fuera

Saber contra qué luchas: fuerza bruta vs spraying vs credential stuffing

Fuerza bruta

La fuerza bruta clásica son intentos repetidos contra una cuenta (o un conjunto pequeño) hasta que algo cede. En IMAP/SMTP,
suele apuntar a nombres de usuario comunes como admin, info, sales, además de direcciones reales
raspadas de tu web. Estos ataques son ruidosos: muchas fallas, a menudo desde un número reducido de IPs, a veces
desde botnets que rotan por rangos de VPS baratos.

Password spraying

El spraying es el primo “sutil”: probar una o pocas contraseñas comunes contra muchas cuentas. Evita bloqueos de cuenta
y parece menos un colapso, más como radiación de fondo—hasta que choca con una contraseña reutilizada y pasa a ser tu incidente.
El spraying es especialmente común en IMAP porque está ampliamente expuesto y el bucle de retroalimentación es rápido.

Credential stuffing

El stuffing ocurre cuando los atacantes usan pares usuario/contraseña filtrados de otros sitios. El servidor de correo es solo el destino;
la filtración ocurrió en otro lugar. Este ataque suele tener una tasa de éxito mayor que la fuerza bruta. Los patrones en los logs pueden parecer
“válidos”: un intento por cuenta, a veces exitoso, seguido de actividad inmediata en el buzón o envíos por SMTP AUTH.

Por qué IMAP/SMTP son objetivos tan tentadores

El correo sigue siendo la llave maestra en la vida corporativa: restablecimiento de contraseñas, facturas de proveedores, documentos de RR. HH.
y conversaciones de “por favor, transfiere dinero ahora” viven allí. Un buzón comprometido suele convertirse en palanca interna y plataforma de fraude, no solo un problema de privacidad.
Además: muchas pilas de correo son antiguas, muy personalizadas y tratadas como “appliances” hasta que arden.

Una regla práctica: no trates “fuerza bruta en IMAP/SMTP” como un problema solo de perímetro. Es un problema de autenticación, de monitorización
y de gestión de cambios. Puedes bloquear mil IPs y aún perder por una contraseña reutilizada.

Broma #1: A los atacantes les encanta IMAP porque siempre está ahí—como esa impresora en contabilidad que se niega a jubilarse.

Algunos datos y contexto histórico (porque el correo nunca muere)

• SMTP es anterior a Internet moderna. SMTP se estandarizó a principios de los 80 y asumía una red más amigable. “Autenticación hostil a escala” no estaba en el pliego de diseño.
• IMAP es más viejo que muchas estrategias “cloud first”. IMAP surgió en los 80 también, optimizado para acceso remoto a buzones mucho antes de que los smartphones lo convirtieran en un problema de todos.
• El puerto 25 no estaba pensado para login de usuarios. SMTP en 25 es para transporte servidor a servidor; la presentación autenticada pasó a 587 para separar responsabilidades y políticas.
• Las “apps menos seguras” crearon una larga cola de autenticación débil. Durante años, clientes iniciaban sesión con contraseñas en claro para recuperar correo; MFA y contraseñas de aplicación modernas llegaron tarde y de forma desigual.
• El password spraying aumentó con las políticas de bloqueo. Cuando las empresas empezaron a bloquear cuentas tras N fallos, los atacantes se adaptaron a patrones bajos y lentos a través de muchos usuarios.
• Los botnets abarataron la fuerza bruta. Intentos distribuidos desde miles de IPs convierten el bloqueo por IP en un juego de Whac-A-Mole a menos que limites tasas y endurezcas la autenticación.
• Los logs de correo son inusualmente ricos. Postfix/Dovecot pueden decirte quién lo intentó, desde dónde y con qué frecuencia—si almacenas logs el tiempo suficiente y no te ahogas en ruido.
• “TLS en todas partes” ayudó, pero no contra la adivinación. Encriptar el canal evita el sniffing; no hace nada contra un atacante que ya tiene listas de contraseñas.

Guion de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Cuando estás bajo ataque activo, tu trabajo es (1) mantener el correo para usuarios legítimos, (2) detener la hemorragia,
y (3) preservar suficiente evidencia para aprender algo. Aquí está el orden que te mantiene honesto.

Primero: confirma qué está fallando y dónde

• ¿Los usuarios fallan al autenticarse o fallan al conectar? Los fallos de autenticación aparecen como auth failed; los fallos de conexión aparecen como timeouts/rechazos.
• ¿Es IMAP, submission (587), SMTPS (465) u otra cosa? No “arregles SMTP” si es IMAP, y no bloquees 587 si tus usuarios dependen de él.
• ¿La máquina está limitada por CPU, I/O o por la tabla de conexiones? Bajo fuerza bruta, puedes saturar CPU (TLS + auth), I/O (logs + backends de auth) o conntrack de red.

Segundo: identifica el patrón de ataque dominante

• Pocas IPs golpeando? Los baneos por IP y límites en el firewall funcionan bien.
• Muchas IPs, muchos usuarios, baja tasa? Eso es spraying/stuffing. Necesitas throttling por usuario, auth más fuerte y detección de anomalías.
• ¿Están ocurriendo accesos exitosos? Si sí, entras en territorio de compromiso: deshabilita cuentas, resetea credenciales, revisa correo saliente y MFA/contraseñas de aplicación.

Tercero: aplica la mitigación de cambio mínimo

• Activa o ajusta límites existentes (penalizaciones de auth de Dovecot, límites SASL de Postfix, fail2ban) antes de desplegar nuevas herramientas en medio del incidente.
• Whitelist tu vía de vida administrativa (egreso VPN, bastión, IP de oficina) antes de bloqueos agresivos. Quieres una puerta controlada que aún puedas abrir.
• No “reinicies hasta que funcione”. Los reinicios pueden borrar logs, rotar el estado de iptables y darte una falsa sensación de progreso mientras el ataque vuelve de inmediato.

“Esperanza no es estrategia” es una frase común en ops, pero la idea encaja: prepara los modos de fallo antes de que se conviertan en tu cola de tickets.

Una cita para tener en la cabeza: Idea parafraseada: “Los sistemas fallan de formas complejas; la fiabilidad viene de preparar y aprender, no de fingir que las fallas no ocurrirán.” — Richard Cook (para frase)

Tareas prácticas: comandos, salidas y la decisión que tomas

Esto no son “encantamientos mágicos para ejecutar”. Son los ejercicios exactos que quiero en un runbook: comando, salida de ejemplo,
qué significa y qué haces después. Ajusta rutas y nombres de servicio para tu distro, pero mantén la lógica.

Tarea 1: Confirma qué puertos están expuestos (y por qué servicio)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|110|143|465|587|993|995)\s'
LISTEN 0      100          0.0.0.0:25       0.0.0.0:*    users:(("master",pid=1123,fd=13))
LISTEN 0      100          0.0.0.0:587      0.0.0.0:*    users:(("master",pid=1123,fd=15))
LISTEN 0      100          0.0.0.0:465      0.0.0.0:*    users:(("master",pid=1123,fd=16))
LISTEN 0      128          0.0.0.0:993      0.0.0.0:*    users:(("dovecot",pid=998,fd=41))
LISTEN 0      128          0.0.0.0:143      0.0.0.0:*    users:(("dovecot",pid=998,fd=40))

Qué significa: Los servicios escuchan en interfaces públicas para SMTP (25), submission (587/465) e IMAP (143/993).

Decisión: Si no necesitas IMAP en texto plano (143) en Internet, deja de exponerlo. Si 465 existe pero no se usa, considera desactivarlo para reducir la superficie.

Tarea 2: Comprobar la presión de conexiones actual (¿te están inundando?)

cr0x@server:~$ sudo ss -ant state established '( sport = :993 or sport = :587 )' | wc -l
842

Qué significa: 842 conexiones establecidas en IMAPS/submission. Puede ser normal para una organización grande, o catastrófico para una pequeña.

Decisión: Compáralo con la línea base. Si es 10x lo normal, pasa a desglosar IPs atacantes y aplicar limitación de tasa.

Tarea 3: Encontrar las IPs origen principales que están golpeando IMAPS ahora mismo

cr0x@server:~$ sudo ss -ant '( dport = :993 )' | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  210 203.0.113.77
  198 198.51.100.22
   95 192.0.2.14
   41 203.0.113.19

Qué significa: Unas pocas IPs dominan. Este es el modo fácil para bloquear.

Decisión: Si no son tus egress NAT o sondas de monitorización conocidas, bloquéalas o limita su tasa en el firewall. Si son “muchas IPs con recuentos bajos”, cambia a controles por usuario.

Tarea 4: Contar fallos de autenticación en los últimos 10 minutos (Dovecot)

cr0x@server:~$ sudo journalctl -u dovecot --since "10 min ago" | egrep -i 'auth failed|authentication failure' | wc -l
12458

Qué significa: Esto está activo e intenso. A este ritmo, vas a quemar CPU, logs y posiblemente tu backend de auth.

Decisión: Habilita throttling inmediatamente (penalizaciones de auth de Dovecot) y verifica que fail2ban realmente esté baneanado.

Tarea 5: Extraer los nombres de usuario más atacados (pista de spraying vs brute force)

cr0x@server:~$ sudo journalctl -u dovecot --since "30 min ago" | egrep -o 'user=<[^>]+' | cut -d'<' -f2 | sort | uniq -c | sort -nr | head
  611 user=info@example.com
  588 user=admin@example.com
  512 user=support@example.com
  498 user=sales@example.com

Qué significa: Altos recuentos en unos pocos buzones apuntan a fuerza bruta. Si vieras cientos de usuarios distintos con cuentas pequeñas, eso es spraying.

Decisión: Para buzones compartidos de alto valor (info@, support@), aplica MFA/contraseñas de aplicación o deshabilita acceso IMAP por completo si es posible.

Tarea 6: Confirmar que fail2ban está corriendo y tiene una cárcel para Dovecot

cr0x@server:~$ sudo fail2ban-client status
Status
|- Number of jail:      3
`- Jail list:          dovecot, postfix-sasl, sshd

Qué significa: Tienes cárceles relevantes. Bien. Ahora ve si son efectivas.

Decisión: Si no hay dovecot o postfix-sasl, dependes de la suerte y del volumen de logs.

Tarea 7: Comprobar cuántas IPs están actualmente baneadas y si los baneos aumentan

cr0x@server:~$ sudo fail2ban-client status dovecot
Status for the jail: dovecot
|- Filter
|  |- Currently failed: 128
|  |- Total failed:     54122
|  `- File list:        /var/log/mail.log
`- Actions
   |- Currently banned: 317
   |- Total banned:     2901
   `- Banned IP list:   203.0.113.77 198.51.100.22 192.0.2.14

Qué significa: Se están produciendo baneos. El número “Currently failed” te dice que la cárcel sigue viendo intentos.

Decisión: Si Currently banned está cerca de cero durante un ataque obvio, tu regex del filtro está mal, la ruta de logs está mal, o estás registrando solo en journald.

Tarea 8: Verificar que tus logs de correo realmente se escriben donde crees

cr0x@server:~$ sudo ls -lh /var/log/mail.log
-rw-r----- 1 syslog adm 1.8G Jan  4 01:11 /var/log/mail.log

Qué significa: El archivo de log existe y es grande. Bajo ataque, el I/O de logs puede convertirse en un cuello de botella.

Decisión: Si el log está explotando y estás I/O-bound, considera limitar temporalmente la tasa y asegúrate de que logrotate sea sensato. No desactives el logging en medio del incidente a menos que se acabe el disco.

Tarea 9: Comprobar espacio en disco (porque “correo caído” puede ser “disco lleno” disfrazado)

cr0x@server:~$ df -h /var /var/log
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       100G   96G  4.0G  97% /var
/dev/sda2       100G   96G  4.0G  97% /var/log

Qué significa: Estás al 97%. A 3% de un fallo auto infligido. Bajo fuerza bruta, los logs pueden empujarte por encima.

Decisión: Libera espacio de forma segura (rotar/comprimir, archivar), luego reduce la amplificación de logs deteniendo intentos repetidos (throttles/bans).

Tarea 10: Confirmar que Postfix ve fallos SASL en submission

cr0x@server:~$ sudo journalctl -u postfix --since "15 min ago" | egrep -i 'SASL.*authentication failed|warning: SASL' | head
Jan 04 01:02:11 mx1 postfix/smtpd[22103]: warning: unknown[203.0.113.77]: SASL LOGIN authentication failed: authentication failure
Jan 04 01:02:12 mx1 postfix/smtpd[22105]: warning: unknown[203.0.113.77]: SASL PLAIN authentication failed: authentication failure

Qué significa: El ataque también apunta a SMTP AUTH. Es común: los atacantes prueban IMAP y submission.

Decisión: Asegura que la cárcel postfix-sasl de fail2ban coincida con estas líneas y aplica límites de tasa en smtpd si es necesario.

Tarea 11: Inspeccionar contadores de nftables/iptables para puertos de correo

cr0x@server:~$ sudo nft list ruleset | egrep -n 'dport (25|587|465|993|143)'
42: tcp dport { 25, 587, 465, 993 } ct state new accept

Qué significa: Aceptas nuevas conexiones sin ningún rate limiting. Bajo ataque, eso puede desbordar procesos y conntrack.

Decisión: Añade limitación de tasa para nuevas conexiones a los puertos de autenticación IMAP/SMTP, con umbrales cuidadosos y whitelisting.

Tarea 12: Comprobar utilización de conntrack (asesino silencioso durante floods)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 247812
net.netfilter.nf_conntrack_max = 262144

Qué significa: Estás cerca del máximo de conntrack. Cuando lo alcanzas, conexiones legítimas empiezan a fallar de formas extrañas.

Decisión: Limita nuevas conexiones, considera aumentar el máximo de conntrack (con conciencia de memoria) y descarta fuentes obviamente abusivas antes.

Tarea 13: Identificar si estás limitado por CPU en TLS/auth

cr0x@server:~$ top -b -n 1 | head -20
top - 01:04:33 up 21 days,  2:11,  1 user,  load average: 18.42, 17.90, 14.20
%Cpu(s): 86.5 us,  9.2 sy,  0.0 ni,  1.1 id,  0.0 wa,  0.0 hi,  3.2 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
998 dovecot   20   0  786972  41280  12624 R  215.0   0.5  52:10.11 dovecot/auth
1123 root     20   0  145772  12204   8560 S   85.0   0.1  31:02.24 master

Qué significa: Dovecot auth está consumiendo CPU. Podría ser verificación de hashes costosos (bcrypt/sha512-crypt) bajo ataque (esperado), o latencia LDAP causando reintentos (peor).

Decisión: Añade throttling de auth y revisa la salud del backend de autenticación. No “optimices” los hashes reduciendo su coste; así intercambias seguridad por tranquilidad temporal.

Tarea 14: Comprobar si tu backend de auth (LDAP) es el verdadero cuello de botella

cr0x@server:~$ sudo journalctl -u dovecot --since "10 min ago" | egrep -i 'ldap|connect\(\) failed|timed out' | tail -5
Jan 04 01:00:17 mx1 dovecot: auth: Error: ldap(example.com): Connection timed out
Jan 04 01:00:21 mx1 dovecot: auth: Error: ldap(example.com): Unable to connect to server: Can't contact LDAP server

Qué significa: El ataque ahora es un DoS al backend de auth. Incluso los inicios de sesión legítimos pueden fallar porque LDAP está saturado o inaccesible.

Decisión: Pon throttles agresivos frente a LDAP (política de auth de Dovecot, fail2ban), y considera caching o auth local para cuentas críticas.

Tarea 15: Confirmar que no permites logins en texto plano por accidente

cr0x@server:~$ sudo dovecot -n | egrep -i 'disable_plaintext_auth|auth_mechanisms|ssl'
disable_plaintext_auth = yes
auth_mechanisms = plain login
ssl = required

Qué significa: TLS es obligatorio, la autenticación en claro está deshabilitada, pero aún permites PLAIN/LOGIN sobre TLS (aceptable). Si ssl = yes y disable_plaintext_auth = no, tienes riesgo.

Decisión: Mantén TLS obligatorio. Si clientes legacy necesitan no-TLS, arregla los clientes; no degrades el servidor.

Tarea 16: Verificar restricciones del servicio submission de Postfix (evitar abuso tras compromiso)

cr0x@server:~$ sudo postconf -n | egrep -i 'smtpd_tls_auth_only|smtpd_recipient_restrictions|smtpd_client_message_rate_limit'
smtpd_tls_auth_only = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,reject_unauth_destination
smtpd_client_message_rate_limit = 200

Qué significa: Auth solo sobre TLS está habilitado, el relay no autenticado está bloqueado, y hay un límite de mensajes por cliente.

Decisión: Si no hay límite de envío, una cuenta comprometida puede mandar mucho antes de que lo notes. Añade throttles razonables y alerta sobre picos.

Controles en capas que funcionan en producción

1) Reducir la superficie expuesta (sin romper clientes)

Cada puerto abierto es un contrato con Internet. Mantén los contratos que necesitas; cierra los que no.
La mayoría de organizaciones pueden hacer todo esto:

• Expón IMAPS (993) y submission (587). Considera deshabilitar IMAP en texto plano (143) en interfaces públicas.
• Mantén el puerto 25 para SMTP servidor-a-servidor, pero no permitas autenticación de usuarios ahí. Los usuarios deberían autenticarse en 587 (o 465 si debes).
• Si publicas autodiscover/autoconfig, asegúrate de que apunte solo a los puertos seguros.

Cuantos más protocolos expongas, más política necesitas para mantener la coherencia. En la práctica, “política coherente” es donde nacen los incidentes.

2) Limitar nuevas conexiones en el borde de red

Este es el palanca más rápida cuando estás bajo carga. Limitar tasa compra tiempo y protege conntrack y tablas de procesos.
No resuelve el spraying, pero evita el martilleo.

Pon límites en nuevas conexiones a 993 y 587, por IP origen. Sé conservador: estás moldeando Internet, no castigándolo.
También: añade en la lista blanca el egress de tu VPN y las sondas de monitorización.

3) Usa fail2ban, pero trátalo como código

fail2ban es efectivo cuando:

• Tus logs están donde fail2ban los lee.
• La regex coincide con tu formato exacto de logs.
• Bantime/findtime/maxretry coinciden con el patrón del atacante.
• No banea tu propio NAT ni tu scanner de seguridad.

En spraying, maxretry puede ser irrelevante: los atacantes pueden hacer un intento por IP. Por eso importa el throttling por usuario.

4) Limitar autenticación por usuario, no solo por IP

Los controles por IP fracasan contra botnets. Los controles por usuario fallan contra adivinación distribuida si no tienes buena protección contra enumeración de usuarios.
Aun así, los throttles por usuario marcan la diferencia entre “ruido de ataque” y “LDAP en llamas”.

Con Dovecot puedes introducir penalizaciones de auth y limitar concurrencia de peticiones de auth. El objetivo no es detener cada intento; es hacer el ataque caro
mientras mantienes a los usuarios reales funcionales.

5) Endurecer la autenticación: MFA cuando sea posible, contraseñas de aplicación cuando haga falta

Si puedes aplicar MFA para IMAP/SMTP, hazlo. En la práctica, muchos clientes “tradicionales” no manejan MFA interactiva,
así que usarás contraseñas específicas de aplicación o mecanismos OAuth según tu ecosistema.

Si tu entorno es autohospedado y no está integrado con un proveedor de identidad moderno, la movida pragmática es:

• Política de contraseñas fuerte, aplicada en el servidor (longitud y rechazo de contraseñas comunes).
• Deshabilitar login para buzones compartidos cuando sea factible; usa delegación en su lugar.
• Requerir TLS, deshabilitar autenticación legacy cuando sea posible.

6) Detectar compromiso vigilando lo que pasa después de un login exitoso

Los inicios de sesión exitosos durante un ataque son la verdadera emergencia. Tu monitorización debe marcar:

• IPs nuevas para un usuario, especialmente desde geografías inusuales.
• Picos súbitos en envíos SMTP AUTH desde un buzón que normalmente solo recibe.
• Login IMAP exitoso seguido de descargas grandes inmediatas (los patrones de exfiltración varían, pero los picos de volumen son indicativos).

7) Mantén seguros a los administradores: crea una vía de acceso que “siempre funcione”

El trabajo de lockdown es donde los equipos se bloquean a sí mismos. La solución no es valentía; es diseño:

• Tener una VPN con egress IPs estables y añadirlas a la lista blanca para gestión y (opcionalmente) puertos de correo.
• Mantener una ruta de consola fuera de banda (consola serial cloud, iDRAC/iLO) probada mensualmente.
• Almacenar procedimientos de recuperación en un lugar accesible cuando el servidor de correo esté caído. Si tu runbook vive en el correo, te mereces la noche que te espera.

Broma #2: La forma más fácil de demostrar que no tienes acceso fuera de banda es bloquear tu propia IP y luego “SSH con más ganas”.

Tres mini-historias corporativas desde el frente

Incidente #1: La suposición equivocada que tumbó “solo IMAP”

Una empresa mediana ejecutaba la clásica pila Postfix + Dovecot. La fuerza bruta en IMAP empezó a subir durante la noche.
El on-call vio lo obvio: miles de fallos por minuto. La suposición fue: “Es solo IMAP, SMTP estará bien.”
Bloquearon un puñado de IPs y volvieron a intentar dormir.

A la mañana, los ejecutivos no podían enviar correo. El problema no era SMTP. Era la autenticación.
Dovecot estaba configurado para consultar LDAP en cada intento de auth, y la fuerza bruta era efectivamente una prueba de carga sostenida para LDAP.
La latencia de LDAP subió, las peticiones de auth se acumularon, y el mismo servicio LDAP también soportaba SMTP AUTH (submission). Así que submission empezó a timeoutear también.

La segunda suposición del equipo fue peor: “Si reiniciamos Dovecot y Postfix, se limpiará la cola.” Limpiaron algo de estado local,
pero los atacantes siguieron. El reinicio también causó una breve oleada de reconexiones legítimas de clientes móviles.
Ese estallido legítimo junto con el ataque empeoró la sobrecarga de LDAP.

La solución no fue heroica. Aplicaron throttling de auth en Dovecot y un límite en el firewall para nuevas conexiones IMAPS,
luego ajustaron fail2ban para banear más rápido por fallos repetidos. LDAP se recuperó en minutos.
Una vez estable, revisaron qué cuentas fueron objetivo, forzaron restablecimientos de contraseña en algunos buzones compartidos e introdujeron contraseñas de aplicación.

La lección: no mentalices los protocolos por separado cuando comparten el mismo backend de auth. Bajo ataque, todo lo que toca auth se convierte en un solo sistema.

Incidente #2: La optimización que salió mal (demasiado lista para los baneos)

Otra organización decidió que fail2ban era “demasiado lento” porque esperaba a las entradas de log y luego ejecutaba una acción de firewall.
Un ingeniero implementó una regla de firewall agresiva que descartaba nuevas conexiones a IMAPS si una IP origen abría más de unas pocas conexiones por segundo.
Fue rápido y elegante. También asumió que el mundo se parecía al portátil del ingeniero.

La compañía tenía trabajadores remotos detrás de grandes ISP de consumo y un concentrador VPN corporativo.
Cuando cien usuarios se reconectaron tras un corte de Wi‑Fi, aparecían como un pequeño número de IPs origen (NAT y egress de VPN).
La nueva regla interpretó “cientos de usuarios legítimos” como “un atacante muy entusiasta”.
IMAP se volvió inestable justo cuando la gente más lo necesitaba.

Peor: la regla de rate-limit que descartaba no tenía logging. El helpdesk reportó “correo caído”, las métricas parecían normales, y el propio servidor de correo
no mostraba errores. El firewall estaba haciendo su trabajo en silencio—contra el objetivo equivocado.

Se recuperaron añadiendo listas blancas explícitas para egress de VPN y rangos NAT de oficina, cambiando de “conexiones por segundo”
a “fallos de auth por unidad de tiempo” donde fue posible, y añadiendo logging en la regla de drop con muestreo cuidadoso.
También documentaron el comportamiento de clientes: los clientes móviles IMAP pueden abrir múltiples conexiones paralelas y reconectarse agresivamente.

La lección: las optimizaciones en el borde de la red necesitan empatía por el comportamiento del cliente, no solo desprecio por los atacantes.
Y los descartes silenciosos son geniales hasta que necesitas depurar la realidad a las 03:00.

Incidente #3: La práctica aburrida que salvó el día (línea base + whitelist segura)

Un equipo de servicios financieros tenía una costumbre aburrida: cada trimestre registraban rangos “normales” de conexiones IMAP, fallos de auth,
y throughput de submission. También mantenían una pequeña whitelist revisada: IPs egress de VPN, su sistema de monitorización,
y un rango bastión break-glass. Nadie lo presumía. Nunca hizo una diapositiva.

Cuando la fuerza bruta golpeó, el on-call comparó estadísticas en vivo con la línea base y vio la diferencia de inmediato: los fallos de auth eran 50x lo normal,
pero los logins exitosos estaban planos. Eso sugería fuerza bruta más que una cuenta comprometida enviando spam.
Activaron un cambio de incidente preaprobado: endurecer penalizaciones de Dovecot y reducir la tasa de nuevas conexiones permitidas a IMAPS.

El detalle clave: la whitelist ya estaba en su lugar y probada. El acceso admin continuó. La monitorización siguió activa.
Pudieron iterar sobre baneos sin miedo a perder el control de la máquina.

Tras el ataque, revisaron cuentas objetivo e implementaron una política: los buzones compartidos no deben usarse para login, solo delegación.
Los restablecimientos de contraseña fueron focalizados, no impulsivos. Nadie quedó bloqueado fuera de su propio runbook, porque el runbook vivía fuera del correo.

La lección: líneas base aburridas y whitelists aburridas son la forma de convertir un evento de seguridad en un día operativo rutinario.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: IMAP funciona para algunos usuarios, falla aleatoriamente para otros

Causa raíz: Limitación por IP o fail2ban está baneando egress NAT/VPN. Muchos usuarios comparten una misma IP origen.

Solución: Añadir a la lista blanca egress de VPN/oficina. Preferir throttling por usuario para fallos de auth. Añadir logging/muestreo en drops del firewall para ver qué se bloquea.

2) Síntoma: Carga alta en servidor de correo, pero el tráfico de red no es exagerado

Causa raíz: CPU quemándose en handshakes TLS y verificación de hashes de contraseñas; los atacantes no necesitan mucho ancho de banda.

Solución: Limitar nuevas conexiones, habilitar penalizaciones de auth, y asegurar que la reutilización de sesiones TLS esté configurada adecuadamente. Mantén hashes fuertes; limita intentos en vez de debilitar hashes.

3) Síntoma: Picos de “Authentication failed”, luego alertas LDAP/AD

Causa raíz: El backend de auth es el cuello de botella; la fuerza bruta se vuelve un DoS de autenticación.

Solución: Colocar throttles en el servidor de correo, considerar caching cuando proceda, y asegurar que el directorio tenga límites de conexión sensatos y monitorización.

4) Síntoma: fail2ban muestra cero baneos durante un ataque evidente

Causa raíz: Ruta de logs incorrecta, mismatch journald vs archivo, o el filtro regex no coincide con tu formato de logs Dovecot/Postfix.

Solución: Validar la entrada de logs. Ejecutar fail2ban-regex contra tus líneas reales de log. Confirmar que la cárcel referencia los archivos reales.

5) Síntoma: Disco se llena de madrugada, luego fallan servicios

Causa raíz: Amplificación de logs bajo ataque + logrotate débil + /var pequeño. A veces combinado con debug de auth dejado activado.

Solución: Arreglar logrotate, comprimir agresivamente, almacenar logs en filesystem separado si puedes, y detener la avalancha de auth con throttling/bans.

6) Síntoma: Quejas de spam saliente, listas negras y clientes enfadados

Causa raíz: Credential stuffing exitoso o contraseñas débiles en SMTP AUTH. Los atacantes usan tu servidor como relay autenticándose legítimamente.

Solución: Resetear credenciales de cuentas afectadas, habilitar MFA/contraseñas de aplicación cuando sea posible, añadir límites de envío por usuario y alertar sobre patrones de envío anómalos.

7) Síntoma: Bloqueas “a los atacantes”, pero el ataque continúa igual

Causa raíz: Distribución por botnet o atacantes usando grandes pools de IP; el bloqueo por IP no da abasto.

Solución: Añadir throttles por usuario, exigir autenticación más fuerte y centrarte en detección y respuesta rápida en lugar de listas infinitas de baneos.

8) Síntoma: Tras “endurecer la seguridad”, clientes legítimos no pueden conectar

Causa raíz: Protocolos/puertos deshabilitados sin inventario de clientes (dispositivos antiguos, impresoras, monitorización, aplicaciones críticas).

Solución: Inventariar clientes, publicar configuraciones soportadas (993/587, TLS obligatorio), y dar una ventana de migración. Bloquea el acceso legacy por etapas, no con un cambio un viernes por la tarde.

Listas de verificación / plan paso a paso

Fase 0: No te bloquees (haz esto antes de tocar los baneos)

1. Confirma que el acceso fuera de banda funciona (consola cloud, IPMI, serial). Prueba el login, no solo “existe”.
2. Añade a la whitelist el egress de gestión (VPN, bastión, oficina) en firewall y listas de ignore de fail2ban.
3. Haz snapshot de la configuración actual (copia configs relevantes; registra reglas de firewall actuales y settings de cárceles fail2ban).
4. Comprobar cabida de disco en /var y /var/log. Bajo ataque, los logs pueden ser la caída.

Fase 1: Estabilizar servicio durante fuerza bruta activa (15–60 minutos)

1. Confirma el alcance del ataque: ¿solo IMAP, solo SMTP AUTH o ambos? Usa journald o recuentos en mail.log.
2. Aplica limitación de tasa en red para nuevas conexiones a 993/587 (con cuidado; pon en lista blanca orígenes compartidos conocidos).
3. Habilita/verifica baneos de fail2ban en Dovecot y postfix-sasl. Asegura que la fuente de logs sea correcta.
4. Habilita penalizaciones de auth en Dovecot para proteger el backend de auth y la CPU.
5. Vigila conntrack y límites de proceso. Si estás cerca del máximo, el modelado de conexiones no es opcional.

Fase 2: Reducir radio de impacto (mismo día)

1. Identifica cuentas objetivo (buzones compartidos, ejecutivos, finanzas). Trátalas como alto riesgo.
2. Resetea credenciales para cuentas con logins sospechosos exitosos, no para todos “por si acaso”. Los resets masivos crean incidentes de soporte.
3. Deshabilita login IMAP para buzones compartidos donde sea posible; usa acceso delegado en su lugar.
4. Forzar TLS-only y puertos modernos: IMAPS 993, submission 587. Elimina 143 público si es factible.
5. Añadir límites de envío para SMTP AUTH y contener cuentas comprometidas.

Fase 3: Hacerlo permanente (siguiente sprint)

1. Registrar la conducta normal: fallos de auth/min, conexiones, regiones origen típicas, tasas de envío habituales.
2. Alertar sobre anomalías importantes: login exitoso desde ASN/país nuevo, picos de fallos por usuario, picos de volumen saliente por usuario.
3. Endurecer contraseñas: longitud, contraseñas prohibidas y política de rotación alineada con tu plataforma de identidad.
4. Planear auth moderna si tu ecosistema lo soporta. Si no, planear contraseñas de aplicación y alcance limitado.
5. Ejecutar game days: simular fuerza bruta, verificar baneos, comprobar whitelists, verificar que aún puedes administrar el servidor.

Preguntas frecuentes

1) ¿Debería bloquear todos los países excepto el nuestro?

Si tus usuarios nunca viajan y no tienes proveedores globales, puede ayudar. En la realidad, el geo-bloqueo es una medida paliativa.
Los atacantes también pueden usar IPs domésticas. Úsalo como una capa, no como tu plan único.

2) Políticas de bloqueo de cuenta: ¿buena idea o dedo en la batalla?

Los bloqueos pueden detener la fuerza bruta pero también habilitar denegación de servicio contra usuarios (atacantes activamente provocan bloqueos).
Prefiere throttling y reglas de riesgo adaptativas cuando sea posible; si bloqueas, hazlo por poco tiempo y monitorizado.

3) ¿Es fail2ban suficiente?

No por sí sola. fail2ban es genial contra fallos repetidos desde la misma IP. Es débil contra spraying distribuido y stuffing.
Combínalo con throttling por usuario, autenticación fuerte y detección de anomalías en logins exitosos.

4) ¿Por qué no deshabilitar IMAP por completo?

A veces puedes, y es glorioso. A menudo no puedes por clientes legacy, flujos compartidos o apps que leen IMAP.
Si debes mantener IMAP, mantenlo solo en 993, exige TLS y restringe quién puede usarlo.

5) ¿Debería bajar el coste del hash de contraseñas para reducir CPU durante ataques?

No. Eso es intercambiar seguridad a largo plazo por comodidad temporal. Arregla la vía de ataque con throttles y limitación de tasa.
Mantén hashes fuertes; son uno de los pocos controles que aún importan tras una filtración de base de datos.

6) ¿Cómo evito banear nuestra propia VPN o NAT de oficina?

Mantén una lista blanca pequeña y revisada, y documentada como código de producción. Añade esas IPs a ignore lists de fail2ban y a reglas accept del firewall.
Luego pruébalo trimestralmente. “Creemos que el egress VPN sigue siendo esa IP” no es una prueba.

7) ¿Cuál es la señal más clara de que las cuentas están realmente comprometidas?

Logins exitosos desde IPs inusuales seguidos de picos en envío saliente, cambios en reglas de buzón (si aplica), o grandes/rápidas descargas IMAP.
También: usuarios reportando “envíos que no hice” es el sistema de monitorización humano que no querías ignorar.

8) ¿Deberíamos mover submission a 465 o 587?

587 es el estándar moderno para submission; 465 existe y funciona pero puede confundir política y monitorización si ejecutas ambos.
Elige uno como ruta cliente soportada, documéntalo y monitorízalo bien.

9) ¿Puedo bloquear 25 de forma segura para parar ataques?

Bloquear 25 entrante rompe la entrega de correo de otros servidores a menos que pases por un gateway. Si tienes un gateway de correo, genial—bloquea 25 en el backend.
Si este host es tu MX, el puerto 25 debe permanecer abierto. Enfócate en prevenir abuso y proteger recursos.

10) ¿Y si el ataque está desestabilizando el servidor y necesito alivio inmediato?

Aplica límites de conexión para nuevas conexiones a 993/587 y baneos temporales para las IPs principales, luego verifica que tu acceso administrativo siga funcionando.
Estabiliza primero, y después afina. No hagas cinco cambios arquitectónicos durante la misma ventana de incidente.

Próximos pasos que no te morderán después

Si solo haces unas pocas acciones, haz estas. Son del tipo fiable—del tipo que puedes defender en una revisión post-incidente sin sonar como si negocias con la física:

• Reduce la superficie: IMAPS (993) y submission (587) son tus por defecto; deja de exponer IMAP en texto plano (143) públicamente salvo que tengas un requisito estricto.
• Estabiliza bajo carga: limita nuevas conexiones, protege conntrack y aplica throttling de autenticación antes de que tu servicio de directorio sea daño colateral.
• Haz real a fail2ban: logs correctos, regex correctos, ventanas de baneo sensatas y whitelists explícitas para egress compartidos.
• Planifica los casos de éxito: vigila logins exitosos durante ataques y recorta envíos salientes para reducir fraude y riesgo de listas negras.
• Protege tu propio acceso: consola fuera de banda probada y una whitelist documentada no son “agradables de tener.” Son cómo arreglas producción con seguridad.

Luego programa el trabajo poco glamuroso: registrar la conducta normal, inventariar clientes y migrar fuera de autenticación legacy cuando puedas.
Los atacantes no son creativos aquí. Son consistentes. Tú también puedes ser consistente—solo con mejores resultados.