Hace una década todavía era frecuente que las empresas (e incluso particulares) desplegasen su propio servidor de correo. Era una tarea terriblemente ingrata: parecía entonces que el spam, el phishing y el spoofing acabarían sepultando a este veterano servicio (hasta el 90% del tráfico llegó a ser no deseado). Hoy es cada vez más raro que una organización (no digamos ya un particular) disponga de su propio servidor de correo. También es cada vez menos frecuente encontrar técnicos con habilidad para desplegarlo de forma fiable (hay demasiados MTA mal configurados, sin registro MX, que no hacen resolución inversa, etc.), o empresas que ofrezcan este servicio a sus clientes pues, salvo para servicios de mailing masivo (una forma de spam encubierto) se trata de un servicio muy poco valorado (pese a su carácter todavía fundamental en las comunicaciones), con incidencias que pueden ser desastrosas si se pierde correo. Eso ha concentrado el servicio de correo en unos pocos proveedores gratuitos, y cuya prioridad no es ni la seguridad ni la privacidad de sus usuarios.
Un ecosistema de MTAs diversificado dificultaría estas prácticas. Pero la sofisticación de las herramientas de procesamiento de correo o la incorporación de algunos nuevos sistemas criptográficos o estrategias que utilizan el DNS ha complicado también el que organizaciones y empresas (man)tengan su propio servidor de correo, aunque toda esta sofisticación se ha hecho con un mismo fin: garantizar un ecosistema limpio de correo basura y de engaño. Esa dificultad en un servicio tan crítico y sensible a fallos es el motivo de que cada vez más empresas deleguen su infraestructura en servicios en la nube o en grandes proveedores gratuitos de correo. Sin embargo, la gratuidad tiene también un precio, y si se necesita tomar en serio la privacidad y seguridad de las comunicaciones, sigue siendo muy conveniente que una organización disponga de su propio servidor de correo. Uno de sus principales aliados será entonces el uso de listas grises que, siendo un recurso antiguo, requiere algunos ajustes para que sea eficaz frente al funcionamiento multi-host de los grandes proveedores de correo público, como Gmail, Yahoo, etc., que no disponen de un solo servidor de correo, sino muchos.
Qué son las listas grises
Cualquiera que haya administrado un servidor de correo en producción sabe que hay un antes y un después de las greylistings o "listas grises". Las listas grises fueron una estrategia anti-spam que surgió cuando parecía que los spammers estaban ganando la batalla. Consiste en aprovechar una característica del protocolo SMTP —los errores temporales (error 451)— que hacen que un servidor legítimo (MTA) vuelva a intentar la entrega de correo pasado un tiempo. Las herramientas de los spammers generalmente no encolan el correo ni reintentan los envíos tras recibir un error, pues esto exige gastar recursos: solo los servidores legítimos y que cumplen los RFCs lo intentan de nuevo. El MTA receptor del mensaje crea una tripleta con la IP de origen, el remitente y el destinatario del correo. Tras el error temporal y el posterior reintento, si coincide con la tripleta, se permite su paso y se entrega el correo al buzón del destinatario limpio de polvo y paja.
Este sencillo truco, que funciona de forma totalmente transparente para el usuario final, ha eliminado un porcentaje muy alto del spam, y es probablemente la mejor arma de un sysadmin contra esta plaga, sin exigirle configuraciones demasiado complejas ni tampoco un mayor gasto de recursos (las herramientas de análisis de virus o spam son generalmente muy costosas en términos de CPU). Y es perfectamente compatible con otras medidas anti-spam.
La problemática
Sin embargo, como era de esperar, no todo son ventajas. Uno de los inconvenientes del greylisting es que retrasa la entrega del correo durante un tiempo indefinido, que puede ser desde varios minutos a varias horas (depende del tiempo de reintento del MTA origen). Bien es cierto que este retardo solo se produce la primera vez que un remitente dado escribe a un determinado destinatario, ya que una vez que se cumple la tripleta, la IP pasará a una lista blanca y las veces sucesivas la entrega será inmediata. En general, es un coste asumible, aunque en determinados contextos esto es un precio que no se puede aceptar, en cuyo caso el sysadmin debería incluir directamente las IPs de servidores de correo que no pueden retrasarse en una lista blanca.
Pero hay un problema más, mucho más grave que el retardo inicial, y que es el objeto de este post: se trata de la forma en que funcionan los servidores de correo de Google y de algunos otros grandes proveedores de correo. Google tiene varios servidores de correo y, cuando envían un correo y el sistema de greylisting lo rechaza, el reintento lo puede hacer cualquier otro servidor del "pool" de servidores de Google. ¿Qué supone eso? Que no se cumple la tripleta, por lo cual ese mensaje puede ser rebotado de nuevo y, tras varios reintentos fallidos, descartado. Esto es un verdadero problema, grave, equivalente a dispararnos en el pie, pues podríamos estar perdiendo correo legítimo. Pero no todo está perdido y hay formas de adaptarse a esta nueva situación: hay workarounds para solucionar esto. Expondremos el método que tenemos implementado en FLOSSystems para evitarlo, usando spamdb y y PF (específicos de OpenBSD).
La solución
- Copiamos
/etc/nospamd a/etc/mail/nospamd.constant . En este fichero deberíamos tener la lista blanca de direcciones IP confiables para nosotros. - Extraemos con dig las IPs de los servidores de correo SPF que usa Google y las copiamos ordenadas en un fichero nuevo llamado
nospamd.dynamic . - Concatenamos la lista blanca de IPs (
nospamd.constant ) con las IPs dinámicas de Google que acabamos de extraer con dig en un único fichero/etc/nospamd . - Si no lo teníamos ya, configuramos adecuadamente
/etc/pf.conf (el cortafuegos Packet Filter): - Lo metemos todo junto en un cron semanal:
# cat /etc/weekly.local
next_part "Whitelisting Google mail servers:"
/usr/sbin/dig _netblocks.google.com TXT +short | tr "\ " "\n" | grep ip4 \
| cut -d: -f2 | sort -n > /etc/mail/nospamd.dynamic
cat /etc/mail/nospamd.constant /etc/mail/nospamd.dynamic > /etc/mail/nospamd
/sbin/pfctl -t whitelist -T replace -f /etc/mail/nospamd 2>&1 \
| grep -v 'no changes'
# /usr/sbin/dig _spf.google.com TXT +short
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
# /usr/sbin/dig _netblocks.google.com TXT +short | tr "\ " "\n" | grep ip4 \
| cut -d: -f2 | sort -n > /etc/mail/nospamd.dynamic
# cat /etc/mail/nospamd.constant /etc/mail/nospamd.dynamic > /etc/mail/nospamd
table <whitelist> persist file "/etc/mail/nospamd"
[...]
pass in log quick on egress proto tcp from <whitelist> to port smtp
Nota: El ejemplo anterior lo hemos hecho solo con los servidores de Google, pero podemos (y debemos) hacerlo con otros dominios de proveedores de correo que usen igualmente SPF y varios servidores de correo. Bastaría con hacer un bucle que ejecute dig con cada uno de dichos servidores SPF.
Publicado por flossystems el