Desde la última parte en el mes de noviembre he tenido un poco abandonada la serie de artículos que completan la solución integral de nuestro Anti-SPAM Gateway. Este artículo será breve, pero servirá para volver a retomar el ritmo de estas entregas.

En esta entrega vamos a ver como con la lista blanca vamos a permitir recibir correos de ciertos dominios o direcciones IPs sin que tengan que pasar los diferentes filtros de nuestra solución.

Hay ocasiones en las que "tenemos problemas" para recibir correos de ciertos dominios, pero el mayor número de veces no es NUESTRO PROBLEMA.

Consultamos nuestros logs y vemos que por ejemplo la persona remitente está siendo rechazada por nuestro filtro SPF, el cual manda al remitente un correo informándole del problema que se ha encontrado. Estos correos casi el 99% de las veces no es leído por el usuario y se lo remite a su mantenimiento informático, el cual en un alto porcentaje antes de solucionar SU problema dirá que es problema del destinatario.

Igual que hemos hablado de SPF nos puede pasar con empresas que tienen sus servidores SMTP en direcciones públicas dinámicas, en continuo cambio lo que es muy probable que lo agreguen como spammers en las diferentes listas negras (también es problema nuestro por PROTEGERNOS).

Es un proceso fácil, sólo necesitamos crear un nuevo fichero donde declararemos dominios, direcciones, redes o clientes y después será referenciado en el fichero main.cf en el apartado smtpd_recipient_restrictions.

Lo primero que vamos a hacer es crear el fichero donde declarar los datos descritos anteriormente y después compilarlo para que sea legible por Postfix. Para ello ejecutamos los siguientes comandos como usuario root:

cd /etc/postfix

echo 'X.X.X.X OK # Descripcion' >> whitelist

postmap whitelist

El primer comando nos sitúa en el directorio de Postfix. En el siguiente comando hay que sustituir X.X.X.X por la dirección IP o dominio del remitente y agregar una descripción. El último comando compila el fichero para ser legible por Postfix.

El último paso es agregar un parámetro en el fichero main.cf para que consulte la lista blanca cuando llegue un correo. Para ello como root ejecutamos los siguientes comandos:

vi main.cf

smtpd_recipient_restrictions =

[...]

reject_unauth_destination,

check_client_access hash:/etc/postfix/whitelist,

[...]

/etc/init.d/postfix reload

En el primer comando editamos el fichero main.cf. A continuación en el apartado smtpd_recipient_restrictions después del parámetro reject_unauth_destination agregamos la sentencia que comprueba el fichero de lista blanca. Para terminar una vez salvados los cambios en main.cf se recarga la configuración en Postfix.

En esta entrega vamos a centrarnos en si nuestro servidor está siendo efectivo a través de gráficas. Para nuestro objetivo vamos a usar Mailgraph, una aplicación sencilla pero potente y que cumple nuestras expectativas.

Para poder consultar Mailgraph es necesario disponer de un servidor Web, ya que esta aplicación muestra los valores recolectados a través de un CGI.

Las etapas a seguir para la puesta en marcha de Mailgraph son las siguientes:

1. Requisitos previos.
2. Mailgraph.
   1. Descarga.
   2. Instalación.
   3. Configuración.
3. Pruebas.

Requisitos previos

Mailgraph necesita de RRD para poder realizar las gráficas, además de su módulo perl y también File::Tail. Para instalar estos requisitos ejecutamos los siguientes comandos como root aceptando todos los mensajes:

apt-get install rrdtool librrds-perl

perl -MCPAN -e shell

install File::Tail

exit

Ahora vamos a poner en marcha el servicio Web, el cual vamos a proporcionarlo con Apache2. Para ello ejecutamos el siguiente comando como root y aceptamos los mensajes que aparezcan:

apt-get install apache2

Mailgraph

Con Mailgraph podremos observar los correos recibidos y enviados, además de los bloqueados como SPAM (cuando existe SpamAssassin o Amavisd), los rechazados y bloqueados. Todas estas opciones está disponibles con la versión oficial de Mailgraph. Adicionalmente podemos optar por usar una versión modificada que también grafica el Greylisting, en nuestro caso también bastante interesante.

El método de instalación para cualquiera de las dos aplicaciones es el mismo, nosotros vamos a usar el que tiene soporte para Greylisting, así matamos dos pájaros de un solo tiro.

Descarga

El paquete que vamos a usar lo vamos a descargar desde http://www.bakarasse.de/pages/en/linux/mailgraph.php?lang=EN. Si deseamos el paquete original de Mailgraph sin la opción de Greylisting podemos obtenerlo de http://mailgraph.schweikert.ch/. Ejecutamos los siguientes comando como usuario root:

cd /usr/local/src

wget 'http://www.bakarasse.de/modules/download_gallery/dlc.php?file=10&id=1253923327' -O mailgraph-1.14g3.tar.gz

Instalación

Ya con el paquete descargado es hora de descomprimirlo para realizar su instalación. Como usuario root ejecutamos el siguiente comando para su descompresión:

tar xzf mailgraph-1.14g3.tar.gz

Ahora vamos a acceder al directorio y copiar los diferentes ficheros en las ubicaciones correspondientes. Ejecutamos los siguientes comandos como usuario root:

cd mailgraph-1.14g3

cp mailgraph-init /etc/init.d/mailgraph #Script de inicio

cp mailgraph.cgi /usr/lib/cgi-bin #Aplicación Web CGI

cp mailgraph.pl /usr/local/bin #Aplicación que realiza las estadísticas

Configuración

Ahora vamos a crear el directorio donde se almacenarán las bases de datos que se crean. Para ello ejecutamos como root el comando:

mkdir /var/lib/mailgraph

chown -R www-data:www-data /var/lib/mailgraph

Ahora vamos a editar el script de inicio, donde vamos a modificar los valores del fichero de logs de nuestro servidor de correos y donde se almacenan las bases de datos generadas por Mailgraph. Además, adicionalmente asignamos permisos de ejecución al script, todo ello ejecutando los siguientes comandos como root:

chmod 755 /etc/init.d/mailgraph

vi /etc/init.d/mailgraph

MAIL_LOG=/var/log/mail.log

RRD_DIR=/var/lib/mailgraph

Ahora sólo nos falta configurar nuestro Mailgraph para que arranque al iniciar el sistema. Ejecutamos como root el siguiente comando:

chkconfig mailgraph on

Por último vas a iniciar nuestro Mailgraph para que comienza a recopilar datos, como root ejecutamos:

/etc/init.d/mailgraph start

Pruebas

Para comprobar que Mailgraph está funcionando accedemos a través de nuestro explorador a la dirección http://IP_SERVIDOR/cgi-bin/mailgraph.cgi

Espero que os haya resultado de utilidad esta nueva herramienta, pronto iremos mejorando nuestro Anti-SPAM Gateway con más mejoras.

]]> http://blog.e2h.net/2010/11/07/construyendo-un-anti-spam-gateway-parte-6-mailgraph/feed/ 2 http://blog.e2h.net/2010/09/14/construyendo-un-anti-spam-gateway-parte-5-greylisting/ http://blog.e2h.net/2010/09/14/construyendo-un-anti-spam-gateway-parte-5-greylisting/#comments Tue, 14 Sep 2010 18:56:55 +0000 José Luis Gómez Ferrer de Couto http://blog.e2h.net/?p=2100 Hola una vez más, perdonad la tardanza pero NO he estado de vacaciones , sino he estado estudiando para obtener el VCP410 de VMware y actualmente estoy estudiando para sacar el CCNA... así que hasta pasado el mes de octubre, los artículos irán a cuenta gotas. También quiero compartir con vosotros, que tomaré tan merecidas vacaciones el próximo día 11 de octubre, donde viajaré con mi pareja a la costa este de USA hasta el 1 de noviembre (tremendas ganas que tenemos).

Bueno, voy a dejarme de rollos que sino nos liamos. En este nuevo artículo, donde seguimos con el objetivo de construir un Anti-SPAM Gateway eficiente y sin grandes esfuerzos, nos vamos a centrar en el Greylisting. Esta técnica desde un punto de vista general, se encarga en realizar una demora de 5 minutos al menos antes de recibir el correo electrónico. Se basa en dirección IP del remitente, dirección de correo electrónico del remitente y dirección de correo electrónico del destinatario; informando al servidor origen con el error 450 (No puedo atender tu petición ahora, por favor inténtalo más tarde).

Esta técnica resulta útil porque los spammers normalmente no reenvían los correos que han fallado, ya que eso generaría la necesidad de tener grandes líneas y servidores para procesar todos los reenvíos de los correos fallidos. De este modo, si el correo NO es spam, SEGURO que intentará ser enviado una, dos, tres, hasta un periodo de caducidad configurado por el servidor origen.

Como anteriormente hemos mencionado, la técnica de Greylisting se basa en tres parámetros como la IP del remitente y su dirección de correo electrónico, y la dirección de correo del receptor. A partir de ahí, cuando un correo llega por primera vez a nuestro Anti-SPAM Gateway, éste consultará si dispone alguna información en su base de datos, de no ser así él la agregará incluyendo la hora y fecha de la recepción. Desde ese momento, hasta cinco minutos más tarde (tiempo predeterminado), todo reintento no será aceptado.

Una vez hayan pasado los cinco minutos, cuando el servidor origen vuelva a reintentar el envío, nuestro Anti-SPAM Gateway permitirá dicho correo y dejará almacenado durante 35 días (tiempo predeterminado) los datos requeridos para comprobar el correo electrónico, es decir, IP del remitente, dirección de correo electrónico del remitente y dirección de correo electrónico del receptor. De esto modo, dentro de esos 35 días, todo correo que cumpla esa regla almacenada será directamente aceptado por nuestro Greylisting.

Para conseguir este valor añadido en nuestro Anti-SPAM Gateway, vamos a utilizar la herramienta más extendida que se encuentra para esta técnica, la cual se llama Postgrey. Se da por hecho, que ya contamos con nuestro Anti-SPAM Gateway instalado habiendo seguido los artículos previos.

Los pasos que vamos a seguir para esta instalación son los siguientes:

1. Instalar requisitos previos.
2. Crear grupo, usuario y directorio para Postgrey.
3. Descargar, instalar y configurar Postgrey.
4. Configurar Postfix.
5. Probar Postgrey.

Instalar requisitos previos

Postgrey requiere Perl >= 5.6.0, Net::Server, IO::Multiplex y BerkeleyDB. Para ello vamos a ejecutar los siguientes comandos como usuario root (aceptando todos los mensajes con yes o y):

perl -MCPAN -e shell

install Net::Server IO::Multiplex BerkeleyDB

exit

Crear grupo, usuario y directorio para Postgrey

Vamos a crear estos objetos ya que son necesarios para que Postgrey pueda correr como servicio y almacene los datos en su base de datos. Para ello como usuario root ejecutamos los siguientes comandos:

groupadd -g 1982 postgrey

useradd -m -u 1982 -g postgrey -s /bin/false -d /var/spool/postfix/postgrey postgrey

Descargar, instalar y configurar Postgrey

Para realizar la instalación nos vamos a descargar las últimas fuentes de la aplicación, para ello como siempre copiaremos la URL del paquete para posteriormente descargarlo en nuestro servidor. Como usuario root ejecutamos los siguientes comandos:

cd /usr/local/src

wget http://postgrey.schweikert.ch/pub/postgrey-1.33.tar.gz

Ahora vamos a instalar Postgrey, es un paso muy sencillo, ya que únicamente tenemos que copiar unos ficheros. Para ello vamos a ejecutar los siguientes comandos como root:

tar xzf postgrey-1.33.tar.gz

cd postgrey-1.33.tar.gz

cp postgrey /usr/sbin

cp postgrey_whitelist_* /etc/postfix

Ahora vamos a configurar nuestro Postgrey, para que pueda ser arrancado como servicio. Para conseguirlo, vamos a copiar un script de ejemplo que viene en el directorio contrib del paquete descomprimido y vamos a crear un fichero en /etc/default para que lea de ahí los parámetros adicionales. Como root vamos a ejecutar los siguientes comandos:

cp contrib/postgrey.init /etc/init.d/postgrey

chmod 755 /etc/init.d/postgrey

chkconfig postgrey on

vi /etc/default/postgrey

POSTGREY_OPTS="--inet=10023"

Si deseamos arrancar Postgrey con otros parámetros, como en vez de cinco minutos poner diez; o en vez de 35 días poner más o menos, podemos consultar su documentación ejecutando el siguiente comando:

perldoc postgrey

Ahora vamos a dejar arrancado Postgrey, para ello ejecutamos el siguiente comando como root:

/etc/init.d/postgrey start

Configurar Postfix

Para que Postfix remita los correo a Postgrey debemos agregar una línea en el fichero main.cf después de la línea reject_unauth_destination. Para ello ejecutamos los siguientes comandos como root:

vi /etc/postfix/main.cf

smtpd_recipient_restrictions =

...

reject_unauth_destination

check_policy_service inet:127.0.0.1:10023

postfix reload

Si ejecutamos el comando tail -f /var/log/mail.log podremos observar que postgrey ha sido reconocido satisfactoriamente.

Probar Postgrey

Para probar nuestro Postgrey vamos a realizar cuatro envíos de correo desde la misma IP y con las mismas direcciones de correo. Ell segundo será enviado un minuto después del primero, el tercero será enviado cuatro minutos después del segundo y el cuarto será enviado inmediatamente después del tercero.

Para monitorizar nuestro Postfix, dejamos ejecutado el comando tail -f /var/log/mail.log, donde irá apareciendo todo lo que suceda en el servidor en referencia al servicio MTA.

Con el primer envío lo que hacemos es que Postgrey esté en ALERTA por si se produce sucesivos intentos permitir su entrega. Para ello vamos a ejecutar los siguientes comandos (los mismos para todas las pruebas) con un cliente telnet atacando a nuestro Anti-SPAM Gateway.

• Prueba primera

• Prueba segunda. Casi dos minutos después del primer intento, se puede comprobar que aparece el tiempo en la segunda captura.

• Prueba tercera. El correo es aceptado y aparece cuanto tiempo ha pasado desde el primer envío en la segunda captura.

• Prueba cuarta. Se comprueba que ya no aparece cuanto tiempo ha pasado, pero si aparece que cumple la triple condición como se observa en la segunda captura.

Espero que este artículo os resulte de ayuda y dentro de poco tengamos nuestro Anti-SPAM Gateway ideal.

]]> http://blog.e2h.net/2010/09/14/construyendo-un-anti-spam-gateway-parte-5-greylisting/feed/ 2 http://blog.e2h.net/2010/08/17/construyendo-un-anti-spam-gateway-parte-4-rbl/ http://blog.e2h.net/2010/08/17/construyendo-un-anti-spam-gateway-parte-4-rbl/#comments Tue, 17 Aug 2010 21:16:18 +0000 José Luis Gómez Ferrer de Couto http://blog.e2h.net/?p=2066 Estamos aquí nuevamente en nuestra cuarta entrega donde seguiremos protegiéndonos del correo no deseado que llega día a día a nuestros buzones. En la tercera entrega vimos como identificar los correos legítimos gracias a SPF, en esta entrega vamos a usar RBL (Realtime Blackhole List) para bloquear un gran número de correos que llegan de servidores open relay entre otros.

Como base de datos RBL vamos a usar la proporcionada de forma gratuita por Spamhaus, la cual se mantiene ya desde hace unos años mientras que otras han sido cerradas y no continuado su mantenimiento.

Spamhaus cuenta con varias listas para usarla como RBL, pero aconsejan usar la lista ZEN. La configuración es bastante simple, por lo que no vamos a extender mucho el artículo ya que únicamente es incluir una línea en nuestro fichero main.cf.

Vamos a editar nuestro fichero main.cf y en el apartado smtpd_recipient_restrictions añadiremos la línea que va a controlar RBL. Esta línea deberá estar la última antes del permit, para ello ejecutamos los siguientes comandos como usuario root:

vi /etc/postfix/main.cf

smtpd_recipient_restrictions

...

reject_rbl_client zen.spamhaus.org

permit

postfix reload

Una vez introducida la línea mostrada, recargamos la configuración de Postfix con el comando mostrado arriba. Si dejamos monitorizando el fichero de logs /var/logs/mail.log veremos que comenzará a funcionar el bloqueo de correos mostrando líneas donde se diferencian las consultas a zen.spamhaus.org.

Para esta funcionalidad vamos a usar SPF (Sender Policy Framework), que integraremos a nuestro Postfix para conseguir el objetivo buscado.

Hemos de diferenciar SPF desde dos puntos de vista, proteger nuestro dominio para poder ser usado con SPF y protegernos de dominios falsos gracias a SPF. Explicándolo de un modo más sencillo, tenemos que registrar nuestro MX del dominio con una IP válida en los DNS (como si se tratase de una guía de teléfonos con el nombre de una persona y su teléfono) y para protegernos de los dominios falsos tenemos que tener un complemento que nos permita consultar esa "guía".

Partimos de que ya tenemos nuestro servidor montado y funcionando como se ha explicado en los artículos anteriores. Los pasos que vamos a seguir durante este artículo son los siguientes:

1. Configurar SPF en nuestro DNS.
2. Configurar SPF en Postfix.
   1. Instalar componentes requeridos.
   2. Descargar SPF.
   3. Instalar SPF.
   4. Configurar SPF.
3. Probar SPF.

Configurar SPF en nuestro DNS

SPF se apoya en nuestro DNS, es decir, se declara con un registro del tipo TXT. La sintaxis de este registro la vamos a explicar a continuación.

Existen cuatro calificadores que se usan en la sintaxis, "+" Pass, "-" Fail, "~" SoftFail y "?" Neutral.

• "+" Pass --> El registro SPF designa que ese host tiene permiso para enviar. Este calificador es el usado de forma predeterminado si no se declara ninguno. Acción mostrada --> accept.
• "-" Fail --> El registro SPF ha designado que ese host no tiene permiso para enviar. Acción mostrada --> reject.
• "~" SoftFail --> El registro SPF ha designado que ese host no tiene permiso para enviar pero lo deja pasar. Acción mostrada --> accept but mark.
• "?" Neutral --> El registro SPF especifica que nada puede decirse sobre su validez. Acción mostrada --> accept.

Si una sintaxis resulta coincidente, su calificador se usa. Como hemos dicho de modo predeterminado el calificador es "+" Pass. Por ejemplo:

"v=spf1 -all"

"v=spf1 a -all"

"v=spf1 a mx -all"

"v=spf1 +a +mx -all"

Las sintaxis son evaluadas en orden, si no existen coincidencias el resultado es "Neutral". Si el dominio no dispone de un registro SPF el resultado es "None", por lo que su acción es accept.

El mecanismo "all" siempre coincide. Normalmente es usado siempre al final de la sintaxis. A continuación mostramos unos ejemplos:

"v=spf1 mx -all" Permite todos los registros MX del dominio a enviar email y todos los demás se rechazan.

"v=spf1 -all" Se rechazan todos los envíos.

"v=spf1 +all" Se aceptan todos los envíos, no usar nunca o hacerlo con cuidado.

El mecanismo "ip4" se refiere a una dirección de red, si no se establece una máscara se entiende que es /32 (un equipo individual). A continuación unos ejemplos de su uso:

"v=spf1 ip4:192.168.0.1/16 -all" Permite el envío desde cualquier IP entre 192.168.0.1 y 192.168.255.255.

Existen otros mecanismos como "mx", "a", "ptr", .... Puedes encontrar más información sobre las sintaxis en la web de openspf.

Vamos a mostrar un ejemplo real con el dominio e2h.net. Para esta prueba vamos a usar nslookup, consultando el registro TXT declarado. Ejecutamos los siguientes comandos bien en Windows o Linux.

nslookup

set type=txt

e2h.net

Podemos ver en este ejemplo que se aceptan envíos desde cualquier registro declarado en nuestro DNS como A, MX y desde la dirección IP 94.23.229.13; todo lo demás es rechazado.

En definitiva, todo esto nos sirve para ayudar a servidores de correos que disponen de consulta SPF informarles quien tiene permiso a realizar envíos EN NUESTRO NOMBRE (dominio). El servidor realizará una consulta SPF, comprobará que desde el dominio e2h.net sólo tienen derecho a enviar los registros A, MX y la IP mostrada, si resulta que están enviando desde cualquier otro sitio que no está declarado, el servidor de correo lo rechazará.

Es aconsejable no usar "-all", ya que no es totalmente funcional cuando por medio existen reenviadores a nivel de buzón o servidores MX de respaldo. Si enviamos un correo a un usuario y este tiene hecha una redirección a otro buzón y tiene activado SPF dará como envío no permitido, ya que aparece como remitente la IP desde el servidor que se reenvía asociado al dominio registrado con SPF. Lo mismo ocurre con un servidor MX de backup, cuando este devuelva todos los correos al primario aparecerá su IP como el remitente, asociada al dominio registrado con SPF.

Por lo tanto, su mejor uso es con "~all". Nos avisará, dejando pasar el correo y con otros mecanismos como Spamassassin ya controlaremos si es válido o no.

Configurar SPF en Postfix

Una vez registrado nuestro SPF y permitiendo así que servidores de correos puedan comprobar la autenticidad de nuestro dominio en los envíos recibidos, ahora le toca el turno a nuestro servidor. Vamos a preparar nuestro Postfix para que él también pueda consultar si los correos que reciben son legítimos gracias a los registros SPF que deberán haber declarado los dominios desde los cuales recibimos correo.

Instalar componentes requeridos

El primer paso es preparar nuestro servidor para que pueda ser instalado SPF. Para ello necesitamos instalar el componente Mail::SPF. Como root ejecutamos los siguientes comandos:

perl -MCPAN -e shell

Yes (si es la primera vez que ejecutamos CPAN)

install Mail::SPF (responder a todas las preguntas que nos haga con yes o y)

Cuando se muestre las siguientes líneas el proceso habrá terminado

JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz

./Build install  -- OK

quit

Descargar SPF

Existen dos aplicaciones para realizar las comprobaciones SPF, una escrita en Perl (para servidores sin altas exigencias) y otra en Python (para servidores con altas exigencias). A nosotros nos vale con el escrito en Perl, en su página web copiamos el enlace para posteriormente descargarlo en nuestro servidor.

Una vez hemos copiado el enlace del fichero ejecutamos los siguientes comandos como root en nuestro servidor:

cd /usr/local/src

wget http://launchpad.net/postfix-policyd-spf-perl/trunk/2.007/+download/postfix-policyd-spf-perl-2.007.tar.gz

Instalar SPF

Una vez hemos descargado el paquete, lo vamos a descomprimir y copiar su contenido. Para ello ejecutamos los siguientes comandos como root:

tar xzf postfix-policyd-spf-perl-2.007.tar.gz

cd postfix-policyd-spf-perl-2.007

cp postfix-policyd-spf-perl /usr/libexec/postfix/policyd-spf-perl

Configurar SPF

Para que SPF sea lanzado cuando llegue un correo elecrónico es necesario crear un servicio en el fichero master.cf de nuestro Postfix. Este servicio lo que hará es lanzar el script que hemos instalado y comprobar el dominio del remitente con su dirección IP de conexión. Para crear este servicio en el fichero master.cf vamos a agregar unas líneas al final, ejecutamos los siguientes comandos como root:

vi /etc/postfix/master.cf

policy unix - n n - - spawn

user=nobody argv=/usr/bin/perl /usr/libexec/postfix/policyd-spf-perl

Ahora vamos a configurar nuestro main.cf para que lance el servicio cuando llegue un correo y pase por todo el proceso de comprobación. Esta línea ha de colocarse siempre después de reject_unauth_destination. Ejecutamos los siguientes comandos como root:

vi /etc/postfix/main.cf

check_policy_service unix:private/policy

Para que los cambios surtan efecto, necesitamos recargar la configuración Postfix. Ejecutamos el siguiente comando como root:

postfix reload

Probar SPF

El método más rápido de probar nuestro SPF es realizando una conexión local a nuestro AntiSPAM Gateway. Mientras hacemos la prueba vamos a monitorizar el fichero de logs de nuestro AntiSPAM. Primero vamos a dejar monitorizando nuestro fichero de logs, para ello ejecutamos el siguiente comando como root:

tail -f /var/log/mail.log

Ahora vamos a conectar desde nuestro cliente al servidor, ejecutamos los siguientes comandos:

telnet IP_AntiSPAM 25

ehlo <dominio>

mail from:usuario@dominio.com

rcpt to:usuario@example.com

Podemos observar en las imágenes superiores primero el log de nuestro AntiSPAM, detectando el intento de envío inválido que estamos realizando desde el cliente (captura inferior). Se puede observar que aparece una dirección Web la cual podemos visitar y nos informará el porque ha fallado el envío. Esta dirección sirve de ayuda para el cliente, así sabrá porque no ha podido enviar el correo.