Protección contra ataques de recolección de directorios en servidores de correo

La recolección de directorios (directory harvest attack, DHA) es una técnica utilizada por atacantes para descubrir direcciones de correo válidas probando grandes volúmenes de destinatarios en servidores SMTP. Este artículo, dirigido a administradores y especialistas en infraestructura, explica cómo identificar ataques de recolección, medidas concretas para mitigarlos en servidores como Postfix/Exim/Exchange, ejemplos de configuración, y prácticas de monitoreo y respuesta.

¿Qué es un ataque de recolección de directorios y por qué es peligroso?

En un DHA el atacante envía múltiples mensajes con distintas variantes de usuarios (user@domain.com) o utiliza comandos SMTP como VRFY/EXPN para averiguar qué cuentas existen. Los riesgos principales son:

  • Incremento de la carga del MTA y congestión en la cola de correo.
  • Mayor exposición a campañas de phishing y spear-phishing al contar con listas de direcciones válidas.
  • Posible bypass de filtros si el atacante prueba patrones válidos.

Cómo detectar ataques de recolección

Detectar un DHA requiere correlacionar patrones en logs y métricas. Señales habituales:

  • Tasa elevada de conexiones SMTP desde pocas IPs con muchos destinatarios distintos.
  • Altísimo ratio de RCPT TO rechazados o de rebotes.
  • Crecimiento súbito de la cola de correo con mensajes hacia direcciones no existentes.
  • Uso de VRFY/EXPN o intentos de enumeración mediante SMTP pipelining.

Herramientas útiles para detección: análisis de logs con pflogsumm, archivos de logs en /var/log/mail.log, y detección basada en reglas con fail2ban o soluciones SIEM. Documentación sobre amenazas relacionadas con enumeración de usuarios puede consultarse en el proyecto OWASP.

Medidas preventivas y de mitigación

La defensa contra DHA debe ser multicapa: configuración del MTA, mecanismos de rate limiting, tarpitting y filtros basados en reputación.

1) Requerir autenticación en el puerto de envío

  • Forzar SMTP Submission (puerto 587) con STARTTLS y autenticación (SMTP AUTH). Así se separa el servicio de entrega autenticada del servicio de recepción pública (puerto 25).
  • Configurar políticas que permitan enviar sólo a usuarios autenticados para evitar el relaying abierto.

2) Desactivar comandos de enumeración (VRFY/EXPN)

Los servidores modernos suelen deshabilitar por defecto VRFY/EXPN; asegúrate de que tu MTA no responda con información sobre la existencia de cuentas. En Postfix esto se controla implícitamente; para Exim puedes añadir reglas que respondan con 252 o con rechazo genérico.

3) Rechazo temprano y validación de destinatarios

  • Rechaza durante la fase RCPT TO cuando el destinatario no existe (reject_unlisted_recipient en Postfix), en vez de aceptar y generar bounce. Esto evita cargas innecesarias en la cola.
  • Usa listas locales de destinatarios (DB de usuarios) para respuestas rápidas.

4) Rate limiting y conexión por cliente

Limitar conexiones, mensajes por minuto y destinatarios por conexión reduce la efectividad de un DHA.

Ejemplo (Postfix, main.cf):

smtpd_client_connection_count_limit = 20
smtpd_client_message_rate_limit = 30
smtpd_client_recipient_rate_limit = 100
smtpd_recipient_limit = 50
smtpd_client_connection_rate_limit = 60

Nota: las directivas pueden variar según la versión del MTA; revisa la documentación específica del proveedor.

5) Tarpitting y greylisting

  • Tarpitting (retrasar respuestas SMTP) complica los ataques automatizados al incrementar el tiempo por intento. Herramientas como Postfix postscreen o políticas de tarpit ayudan.
  • Greylisting (por ejemplo con postgrey) rechaza temporalmente la primera entrega de un triplete (IP, remitente, destinatario), lo que frustra a muchos spammers o bots mal configurados.

6) Filtros de reputación y listas negras

Usa DNSBLs y servicios de reputación para bloquear IPs conocidas por abuso. Configure check_policy_service o check_client_access en tu MTA y añade RBLs con cuidado para evitar falsos positivos. Recursos como la documentación de Cloudflare pueden inspirar políticas de limitación y respuesta.

7) Uso de policy daemons y controles avanzados

Policyd, postfwd o policy servers permiten aplicar reglas complejas (por ejemplo, número total de destinatarios por día por IP). Implementa políticas que combinen reputación, tasas y comportamiento para decidir si aceptar, tarpit o bloquear.

Ejemplos prácticos

Configuración recomendada mínima para Postfix

Fragmento para main.cf (ejemplo conservador):

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    reject_unlisted_recipient,
    check_client_access hash:/etc/postfix/client_access,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org

smtpd_client_connection_count_limit = 20
smtpd_client_message_rate_limit = 30
smtpd_client_recipient_rate_limit = 100
postscreen_greet_action = enforce
postscreen_dnsbl_sites = zen.spamhaus.org

Combínalo con un daemon policyd en el puerto 10023 para reglas adicionales.

Ejemplo simple de regla fail2ban

Un filtro que detecte muchos rechazos por RCPT TO puede bloquear la IP fuente temporalmente. Configura un filter.d/postfix-dha.conf con patrones de rechazo y una jail que bloquee tras N eventos en X minutos.

Monitoreo, alertas y respuesta

Detectar y mitigar es un ciclo continuo:

  • Implementa alertas sobre incrementos en rechazos RCPT TO, crecimiento de la cola y picos de conexiones SMTP.
  • Analiza tendencias: si un cliente legítimo dispara límites, crea excepciones controladas (por red o certs).
  • Registra todas las decisiones de rechazo/tarpit para auditoría e investigación forense.

Buenas prácticas operativas

  • Segregar servicios: entrega (port 25), envío autenticado (port 587) y webmail en hosts o containers separados para contener fallos.
  • Higiene de cuentas: aplicar expiración de direcciones temporales y revisar listas internas de alias.
  • Protege el transporte con TLS y certificados de confianza (por ejemplo, automatización con Let\’s Encrypt) para mitigar inspección pasiva de tráfico.
  • Documenta tus políticas y publica límites de envío para usuarios para reducir problemas de soporte.

Consideraciones legales y éticas

Los intentos de recolección pueden ser evidencia de actividad maliciosa; conserva logs y coordina con el equipo de seguridad y, si procede, con las autoridades. No realices respuestas activas que puedan violar políticas o leyes (por ejemplo, retaliación o bloqueo global sin justificación).

Conclusión

La protección contra ataques de recolección de directorios requiere una estrategia en capas: bloquear la enumeración por comandos SMTP, exigir autenticación para envíos, aplicar rate limiting y tarpitting, usar listas de reputación y monitorizar activamente. Implementando reglas concretas en tu MTA (rechazo temprano de destinatarios no listados, límites por cliente, postscreen/postgrey y políticas de rate limiting) reducirás la eficacia de los DHA y mantendrás la disponibilidad del servicio. Combina estas medidas con alertas y revisión periódica para mantener la protección actualizada frente a nuevas técnicas.

Para profundizar en técnicas de defensa y buenas prácticas complementarias consulta recursos como OWASP sobre enumeración de usuarios, la documentación de Cloudflare sobre limitación de tasa y recomendaciones de cifrado y automatización de certificados en Let\’s Encrypt.