Bug de Scan Messages en MailScanner

Unas de las cosas que más gustan de MailScanner es la feature de que cada una de las directivas de configuración, en su gran mayoría, pueden ser un archivo de reglas o una llamada a una función. Esto permite que para cada configuración típica de un sistema antispam pueda diferenciarse en base a cuenta origen/destino, IP origen, dominio origen/destino…etc, lo cuál, permite la personalización absoluta del sistema.

Por ejemplo, a la hora de decidir si un mensaje va a ser escaneado o no, en vez de tener un valor de “yes” o “no” para la directiva de configuración que lo controla, que se aplicaría a todos los mensajes, puede hacerse mediante un archivo de reglas externo:

Scan Messages = %rules-dir%/scanmessages.rules

donde se establecerán las reglas que se deseen, por ejemplo:

From: origen@confiable.com no
From: 192.168.1.10 no
From: /^192\.168\.13[4567]\./ no
FromOrTo: default yes

evitando que se escaneen los mensajes de un determinado FROM, de una determinada IP o de un conjunto de IPs que cumplan la expresión regular. Con el resto de mensajes, se hará lo que el “default” diga, en este caso, “yes” (escanearse).

Sigue leyendo

Postfix con DKIM y múltiples dominios

Tras pruebas varias e integraciones con otros sistemas de la plataforma, ya estamos firmando, desde hace unos meses, correos salientes con DKIM (RFC 5585).

¿Y qué es DKIM? Es una idea desarrollada a partir de DomainKeys e IdentifiedMail que
garantiza que un mensaje procede de un determinado sitio. Es usado por grandes proveedores como Yahoo, Gmail, Hotmail…etc.

DKIM usa claves públicas/privadas para certificar el origen de un email a través de DNS. Se crean dos claves, la pública se publica en un registro TXT del DNS del dominio cuyos mensajes se quieren firmar y la privada se usa para crear la firma digital de los mensajes añadiendo el resultado en una cabecera del propio mensaje a enviar.

El servidor destino, consultará la clave pública y chequeará que se corresponde con la clave que ha firmado el mensaje.

Sigue leyendo

Desaparición de mensajes en Postfix

He tenido dudas a la hora de poner un título a este post. El concepto “desaparición” puede que sea algo amarillista, quizás “pérdida de rastro de mensajes” pudiese hacer más justicia a lo que voy a comentar, pero bueno, queda más “Expediente X” el actual ;-)

Todo esto viene debido a que buscando en los logs un determinado mensaje enviado, no se sabía (a priori) qué había pasado con él. Esto es lo que creo (y supongo que todo el mundo cree) que no debe hacer un log, no dejar evidencias de lo que pasa.

Juntar MailScanner con Postfix siempre ha sido muy criticado, sobre todo en la lista de usuarios de Postfix. No hay una interfaz que pase los mensajes recibidos en el demonio smtpd de Postfix a MailScanner, como sucede con otras pasarelas de correo como amavids-new, sino que cuando llegan los mensajes vía SMTP, pasan a la cola hold donde quedan retenidos y MailScanner, con un proceso batch, procede a recogerlos de ahí regularmente para analizarlos.

Sigue leyendo

Greylisting II

Ya hablábamos hace algunos años (¡cómo pasa el tiempo!) sobre Greylisting y la efectividad que tenía al rechazar temporalmente conexiones de ciertas IPs (rangos dinámicos y residenciales). Gracias a esto, todos esos mensajes de spam que envían los bots (que no tienen un sistema de gestión de rechazos (sistema de colas, básicamente) como exige el RFC), son rechazados en primera instancia y no se vuelven a intentar entregar.

Un paso más es combinar esto con la geolocalización de IPs. Gracias a GeoIP, disponemos de una base de datos que guarda el país al que pertenece cada IP de Internet. En Debian por ejemplo, basta hacer:

apt-get install geoip-bin geoip-database

y disponemos ya de un comando que hace la consulta correspondiente:

# geoiplookup 81.12.209.54
GeoIP Country Edition: RO, Romania

¿Y qué podemos hacer con esto? Pues juntarlo con la idea de Greylisting y poder rechazar temporalmente, aparte de las IP dinámicas/residenciales, las conexiones realizadas desde ciertos países que son conocidos por el envío masivo de spam. Podemos sacar un listado de la web de SpamHaus:

Por ejemplo, podemos rechazar temporalmente, las conexiones que tengan como origen IPs de Rumanía, Polonia, China y Brasil. Si decidimos hacer esto, sería conveniente saber si los clientes suelen intercambiar correos con otros usuarios de dichos países, para evaluar el impacto que tendría. No obstante, los servidores legítimos de dichos países, reintentarán el envío del mensaje una vez recibido el rechazo temporal (como exige el RFC), por lo que no habrá problemas de pérdida de correos.

Si lo comentado anteriormente es aplicable para el correo entrante, algo parecido se puede hacer para el correo saliente (el que los clientes nos entregan para hacer relay y entregarlo al destino). Aplicar RBLs sobre los clientes directamente, suele provocar bastantes falsos positivos (con IPs dinámicas sobretodo) así que puede combinarse estas consultas con la geolocalización. La idea podría ser “rechazar los envíos de clientes cuya IP origen esté en una o más RBLs y además el país origen sea poco habitual o sospechoso”.

En nuestros servidores de salida, en el día de ayer por ejemplo, estos son algunos de los países al que pertenecen las IPs cuyas conexiones fueron rechazadas por la política anteriormente mencionada:

Vietnam
Rusia
Polonia
Taiwan
Turquía
Rumanía
Kazajistán
Omán

mensajes que no tenían pinta de ser legítimos.

Por tanto, vemos como la combinación de varias herramientas, puede proporcionarnos funcionalidades que podemos aplicar en diferentes ámbitos y de diferentes formas en nuestras plataformas de correo.

Greylisting 2010

En el mes de Mayo del pasado 2010, puse en marcha un nuevo milter en los relays de correo de entrada de Hostalia.
Dicho milter se encarga de hacer greylisting selectivo a determinadas IPs (rangos dinámicos, fundamentalmente) y el resultado ha sido ciertamente, muy efectivo.

En el siguiente gráfico, vemos como el número de mensajes que se procesan por el motor antispam (en este punto, se han pasado ya todas las RBLs y tests SMTP, por lo que son mensajes que pasan a ser procesados por MailScanner y SpamAssassin) da un bajón importante a partir de la puesta en marcha de dicho milter.

Greylisting

Todo esto sin un solo falso positivo :-)

Está claro, como el tiempo ha ido demostrando, que las formas de lucha contra el spam deben pasar por este tipo de soluciones. De hecho, habrá que empezar a probar seriamente PostScreen, una nueva funcionalidad que ya está presente en Postfix (a partir de su versión 2.8) y que permitirá tener una protección por delante del demonio smtpd. Prometo post sobre ello :-)

Whitelisting basado en DNS en Postfix 2.8

En base a un hilo de la lista de de correo postfix-users, Wietse Venema, el creador de Postfix, ha dado soporte a listas blancas basadas en DNS.

Hasta ahora, solo estaba implementado el soporte para RBLs (listas negras) así que cualquier lista blanca de IPs que se quisiese implementar, había que hacerlo con un archivo de texto con el listado de IPs en el propio servidor. Ahora, con esta nueva feature, se puede indicar a Postfix que si la consulta DNS (preguntar por el registro A de la IP a la inversa seguida del dominio, normalmente) para una determinada IP contra una lista blanca basada en DNS, devuelve una IP concreta, pueda evitarse que sigan otros chequeos antispam (como RBLs).

El propio ChangeLog de Postfix 2.8 (versión de desarrollo) ya indica dicha mejora:

20101105

Feature: DNS whitelist support in the Postfix SMTP server.
permit_dnswl_client whitelists a client by IP address, and
permit_rhswl_client whitelists a client by its hostname.
The syntax is the same as reject_rbl_client etc., but the
result is PERMIT instead of REJECT. For safety reasons,
permit_xxx_client are silently ignored when they would
override reject_unauth_destination. The result is
DEFER_IF_REJECT when DNSWL lookup fails. The implementation
is based on a design documented by Noel Jones (August 2010).
File: smtpd/smtpd_check.c.

La documentación también hace referencia a ello.

Eso sí, habrá que esperar algún tiempo hasta que entre en la rama estable actual, la 2.6.

Protección en el kernel de FreeBSD contra DoS a SMTP

En la pasada EuroBSDCon 2009 celebrada en Septiembre, un congreso de los hackers de FreeBSD, hubo una charla cuyo título rezaba “FreeBSD kernel protection measures against SMTP DDoS attacks”, por Martin Blapp.

El paper de aquella charla se puede encontrar en:

http://www.ukuug.org/events/eurobsdcon2009/papers/BSDCON09-SMTP-DDoS-Final.pdf

Como el propio título hace suponer, se trata de un módulo (llamado accf_smtp para el kernel de FreeBSD capaz de gestionar las conexiones SMTP entrantes al servidor y prevenir cierto tipo de ataques (comunes entre las botnes). Con dichas conexiones, puede realizar diversas funciones como hacer una pausa antes de entregar el banner del servicio SMTP, rechazar conexiones que no envíen primeramente el comando HELO/EHLO, establecer número máximo de caracteres en parámetros de comandos…etc.

Soy de la opinión de Wietse Venema que comentaba que esas funciones no son para hacerlas en el kernel sino en userland, como ya hacen numerosos servidores de correo electrónico, por lo que en realidad no supone nada nuevo.

Esta idea está basada en el ya existente accf_http, que gestiona las conexiones HTTP entrantes.

Habrá que esperar a ver qué opinan los que puedan probarlo en sus FreeBSDs.

Los planes de Wietse Venema (Postfix)

En la lista de distribución de postfix-users, alguien ha comentado la existencia de un proyecto llamado OpenSMTPD creado por los chicos de OpenBSD. De hecho, en LWN se habla sobre ello y anuncia una pronta primera release del software.

¿Para qué reinventar la rueda? “Simplemente” por cuestiones de licencia; parece que en OpenBSD no les gusta excesivamente la licencia pública de IBM que tiene Postfix, por ello han decidido desarrollar otro servidor SMTP.

Wietse Venema, el creador de Postfix, ya decía que no le apetecía mucho andar con jaleos de licencias con los abogados de IBM, y el bueno de él comenta:

Apart from that, if they come up with a decent MTA then I welcome
some competition. More motivation for me to look into postfix-lite.

Por lo que parece, Wietse tiene prevista hacer una limpieza de código importante, sobre todo evitando código de compatibilidad con versiones antiguas y demás:

Fully-featured as far as RFCs are concerned, but not necessarily
drop-in compatible with earlier Postfix configurations or file
formats.

Ideally this means eliminating thousands of lines of non-obvious
code, either by removing the feature or workaround altogether, or
by replacing it with code that is easier to maintain but not 100%
compatible. This will be a slow process.

Veremos cómo avanza OpenSMTPD, pero realmente lo tienen bastante difícil para desbancar no solo a Postfix, sino a otros proyectos ya muy maduros como Exim, Qmail, Sendmail…etc.
Tienen MUCHO trabajo por delante…suerte!

Microsoft usando Postfix

Ayer hablando con un ex-compañero, Imanol, ya me lo decía y justamente leyendo la lista de postfix-users salía un mensaje que lo comentaba:

$ dig mx microsoft.com +short
 10 mail.global.frontbridge.com.

$ telnet mail.global.frontbridge.com 25
Trying 65.55.88.22...
Connected to mail.global.frontbridge.com.
Escape character is '^]'.
220 mail156-tx2.bigfish.com ESMTP Postfix EGGS and Butter

Y así lo confirmaba el propio Victor Duchovni, que se podría decir que es la mano derecha de Wietse Venema, diciendo que Microsoft compró Frontbridge hace tiempo y que éstos usaban por aquél entonces Postfix en su versión 1.1. Parece entonces que lo siguen usando y seguramente, Microsoft tendrá una primera frontera de servidores con Postfix para hacer frente a todo el tráfico entrante, dada la excelente capacidad de este MTA de gestionar grandes cantidades de conexiones concurrentes como las que puede recibir Microsoft en sus MX.

Como fijarse en el banner es algo banal, haciendo alguna prueba con comandos no existentes y demás, sí parece tener las respuestas de Postfix. Pasando smtpscan obtenemos:

$ /usr/local/bin/smtpscan  mail.global.frontbridge.com
smtpscan version 0.5

  15 tests available
  3184 fingerprints in the database

Scanning mail.global.frontbridge.com (216.32.180.22) port 25
 15/15

Result --
503:501:501:250:501:250:450:502:502:502:502:502:502:250:250

Banner :
220 mail153-va3.bigfish.com ESMTP Postfix EGGS and Butter

No exact match. Nearest matches :
  - Postfix 1.1.11 (1)
  - Postfix (1)

Que es justamente lo que decía Viktor, un Postfix v1.1 modificado.

Parece que esto coincide además con el reciente lanzamiento de Hosted Exchange, algo que no ha sentado muy bien entre sus clientes ya que hacen clara competencia a sus partners.