Instalación de Postfix, Amavis y Spamassassin

22/06/2011

pdf

Servidor de correo

Introducción

El término Spam se define como el "Correo electrónico no deseado" que llega a la bandeja de entrada del correo electrónico. Este correo proviene de un remitente desconocido y contiene información no solicitada por el usuario, es decir no existe relación ni motivo por el cual deba recibirlo, generalmente es con fines comerciales aunque pueden existir otros motivos, los cuales orillen a los denominados spammers al envío, uno de ellos puede ser la propagación de un virus, ataques de denegación de servicio, etc.

El Spam se caracteriza por ser enviado a miles o millones de usuarios de la red, sin embargo aún cuando el correo no deseado sea enviado a un sólo usuario, se considerará así.

Existen servicios en la red, como subastas, listas de correo, grupos de usuarios, etc., los cuales suelen enviar avisos sobre novedades en su servicio. Si el usuario pertenece o tiene alguna cuenta en sus servidores, es muy probable que reciba algún correo de este tipo. Prestar un servicio eficiente de correo, significa lidiar con este problema, y qué mejor que contar con herramientas que ayuden a limitar la cantidad de Spam recibido en el servidor de correo.

Este documento tiene como finalidad explicar la implementación de un servidor de correo Postfix, en conjunto con el filtro Anti-Spam Amavis-New para limitar la cantidad de correo no deseado en el mismo. Las pruebas y configuraciones aquí mostradas, fueron realizadas en un sistema Linux Gentoo 2004.1con un kernel 2.4.25.

Postfix

Llamado anteriormente IBM Secure Mailer, fue desarrollado en los laboratorios de IBM y declarado Open Source en Diciembre de 1998 por Wietse Zweitze Venema, célebre en el mundo de la seguridad en cómputo, por sus trabajos basados en la protección de intrusiones en los sistemas informáticos. Desde entonces, existía una alternativa al ya tan nombrado Sendmail, la cual prometía rapidez, facilidad de configuración y sobre todo, lo heredado por su creador, seguridad.

Arquitectura

La arquitectura de Postfix es muy diferente a un sistema monolítico como Sendmail, el cual tradicionalmente utiliza un simple programa muy grande para manipular los mensajes de correo. Postfix delega su funcionamiento en pequeños módulos que realizan una tarea específica. La mayoría de ellos son demonios*, los cuales son procesos que corren en background en nuestro sistema. Uno de ellos es Master, el cual es el que inicia primero, he invoca a los demás procesos conforme son necesarios, muy al estilo de init en GNU/Linux. Master, obtiene las opciones de configuración de dos archivos: main.cf y master.cf al iniciarse.

En pocas palabras, el funcionamiento de Postfix es el siguiente: recibe los mensajes, los encola y finalmente los entrega. Cada una estas etapas, es realizada por componentes diferentes, lo que permite una configuración por separado, en cada una de ellas. Después de que el mensaje es recibido y encolado, el administrador de la cola de mensajes invoca al agente de entrega adecuado para la fase final. Los mensajes llegan al servidor con Postfix de la siguiente manera:

  • Un mensaje puede ser aceptado por Postfix localmente, es decir, aquel que ha sido enviado por un usuario en la máquina local.

  • Un mensaje puede ser aceptado por Postfix desde la red.

  • Un mensaje que ya ha sido aceptado por Postfix a través de los métodos ya mencionados y es preparado para su reenvío a otra dirección.

  • Un mensaje puede ser generado por el mismo Postfix, cuando sea necesario entregar una notificación.

Como se mencionó antes, son varios los componentes que trabajan en conjunto con la cola de mensajes. El administrador de éstos es el encargado de gestionarlos y alertar a un componente cuando tiene tarea por hacer. El camino que sigue un mensaje local al entrar a Postfix es el siguiente: los mensajes locales son depositados en el directorio maildrop de la cola de Postfix por el comando postdrop. El demonio pickup lee el mensaje de la cola y lo pasa al demonio cleanup. Algunos mensajes llegan sin información necesaria para un mensaje válido, de manera que además de una revisión del mensaje, el demonio cleanup en conjunto con el demonio trivial-rewrite, insertan las cabeceras faltantes, convierten las direcciones al formato userdomain.tld esperado por los programas de Postfix, y posiblemente transforma direcciones basadas en tablas canónicas o virtuales.

Proceso informático ejecutado en segundo plano, en vez de ser controlado directamente por el usuario, no tiene interfaz ni hace uso de entradas y salidas.

Figura 1.1: Diagrama de flujo Postfix

Después de este proceso, el demonio cleanup notifica al administrador de la cola que el mensaje ha sido procesado. Posteriormente se procede a la invocación del agente de entrega para entregrarloa su destino final. Este proceso se mantiene casi intacto en el análisis que realizaremos posteriormente, sólo se agregará a la parte en la que actúa Amavis-New en el análisis y clasificación del mensaje.

Instalación

Antes de iniciar la instalación del servidor de correo Postfix, instalaremos algunos de los módulos que nos podrían ser útiles en la tarea Anti-Spam que estamos emprendiendo. Uno de ellos es el Perl Compatible Regular Expressions PCRE; éste se compone de una serie de librerías que implementan el reconocimiento de patrones utilizando expresiones regulares, y la sintaxis y semántica de Perl 5, actualmente ha sido utilizado en proyectos de software libre como: Apache, PHP, KDE y por supuesto Postfix.

Para la instalación de PCRE, obtendremos la última versión del sitio http://www.pcre.org. Y para su instalación se ejecutarán los siguientes comandos:

# tar -zxvf pcre-4.5.tar.gz
# cd pcre-4.5
# ./configure
# make
# make install

Después de esto, continuamos con la instalación de Postfix. En esta sección, se instalará la versión 2.1.0 de Postfix, desde el código fuente. Para obtener esta versión sólo hay que dirigirnos a la página http://www.postfix.org/download.html y descargarla.

Ahora que tenemos el código fuente de Postfix, vamos a instalarlo con los siguientes comandos:

# mv postfix-2.1.0.tar.gz /usr/local/src
# cd /usr/local/src
# tar -zxvf postfix-2.1.0.tar.gz

Ya hemos desempaquetado el código, resta compilarlo con soporte para el PCRE:

# cd postfix-2.1.0
#make -f Makefile.init makefiles 1#1
"CCARGS=-DHAS_PCRE -I/usr/local/include" 1#1
"AUXLIBS=-L/usr/local/lib lpcre"
# make
# make install

Ahora necesitamos crear una cuenta de usuario y un grupo, esto sólo es necesario durante la primera instalación. Crearemos el usuario Postfix con un userid y un groupid que no esté siendo utilizado por otro usuario, ésta debe de ser una cuenta en la que nadie pueda obtener un shell y necesita un home directory inexistente, nuestras líneas en /etc/passwdy /etc/group lucen de la siguiente manera:

postfix:x:207:207:Postfix:/var/spool/postfix:/bin/false
postfix:x:207:

También necesitamos un grupo llamado postdrop con un groupid que no sea utilizado por ningún otro grupo.

Configuración

La configuración de Postfix se realiza por medio de 2 archivos principalmente, main.cf y master.cf, los cuales se encuentran por default en /etc/postfix. A continuación describiremos las opciones de configuración más importantes utilizadas en este documento, tanto para el main.cf como para el master.cf respectivamente.

La primera opción que configuraremos en nuestro servidor es la ruta de la cola de mensajes de Postfix. Generalmente cuando Postfix se ejecuta en un ambiente chroot ésta suele ser la raíz de Postfix.

queue_directory = /var/spool/postfix

La ruta de todos los comandos de Postfix y los demonios (algunos de los cuales están listados en main.cf) están dados por las siguientes líneas:

command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix

Cabe resaltar que la ruta que especifica la localización de los demonios, debe pertenecer a root. Un parámetro importante es el propietario de la cola de mensajes y de la mayoría de los demonios de Postfix:

mail_owner = postfix

Ahora debemos especificar el nombre del host, así como el nombre del dominio al que pertenece, en este caso tenemos:

myhostname = forense.seguridad.unam.mx
mydomain = seguridad.unam.mx

Estos parámetros son muy importantes así que comentaremos más sobre ellos. Si el parámetro myhostname no se especifica Postfix utilizará la función gethostname para determinar el nombre del host. Si el sistema reporta correctamente el nombre del sistema, este parámetro se puede pasar por alto. Si el parámetro mydomain es especificado, Postfix genera el nombre completo del host en conjunto con el nombre del dominio.

Cuando los usuarios envían o reciben correo a través de Postfix sin ningún dominio especificado, el parámetro myorigin especifica el dominio a concatenar a las cabeceras del mensaje. El valor por default es el siguiente:

myorigin = $myhostname

También tenemos que indicarle a Postfix, por qué medio va a recibir mensajes, en este caso las interfaces activas del sistema con el parámetro:

inet_interfaces = all

El siguiente parámetro a configurar, es mydestination, éste lista todos los dominios de los cuales Postfix va a aceptar la entrega o el envío de los usuarios locales, nuestra configuración es la siguiente:

mydestination = $myhostname, localhost.$mydomain, localhost

Además de recibir y enviar mensajes de usuarios locales, Postfix también puede reenviar correo a otros sistemas. Es muy importante restringir quién puede hacerlo. Los sistemas en nuestra red deben de tener la posibilidad de reenviar correo, sin embargo no se necesita el mismo servicio a todo el mundo. Por default Postfix no es un OpenRelay, los parámetros mynetworks_style y mynetworks determinan si otros sistemas pueden usar el nuestro para enviar correo. La configuración por default es permitir sólo aquellos equipos que estén conectados a la misma red que nuestro servidor. Nosotros hemos elegido limitar el mail relay sólo a la máquina local, con la siguiente opción:

mynetworks_style = host

Una de las líneas que agregaremos a nuestro archivo main.cf, es la que indica la existencia de Amavis-New, la cual es la siguiente:

content_filter = smtp-amavis:[127.0.0.1]:10024

Esto indica que Amavis-New trabajará sobre el puerto 10024 en la máquina local, que como explicaremos a la postre, Postfix se encargará de enviar los mensajes a Amavis para su validación como Spam, y Amavis lo regresará a Postfix para su entrega final si es el caso. Además, le indicamos a Postfix en dónde se encuentra la tabla de aliases a utilizar:

Alias_database = hash:/etc/postfix/aliases

La última línea, indica algunas restricciones propias de Postfix que nos ayudarán a detener el Spam antes de pase a otra etapa dentro del proceso de los mensajes en el sistema, estas opciones las discutiremos posteriormente:

smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_maps_rbl

Hasta ahora nuestro archivo de configuración main.cfluce de la siguiente manera:

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
myhostname = forense.seguridad.unam.mx
mydomain = seguridad.unam.mx
myorigin = $myhostname
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost
unknown_local_recipient_reject_code = 500
mynetworks_style = host
relay_domains =
relayhost =
mail_spool_directory = /var/spool/mail
mailbox_command = /usr/bin/procmail
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/local/man
sample_directory = /etc/postfix
readme_directory = no
content_filter = smtp-amavis:[127.0.0.1]:10024
ALias_database = hash:/etc/postfix/aliases
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_maps_rbl

Filtrando Spam desde Postfix

La operación de un servidor de correo sobre Internet, implica la responsabilidad de no permitir el open relay, con el cual los Spammers puedan utilizar nuestros recursos para realizar sus operaciones. Un servidor de open relay es un sistema de correo que permite el envío de mensajes de sistemas externos a otros sistemas externos por medio de nuestro servidor.

Detección de Spam

Una vez resguardado nuestro servidor, lo próximo a realizar es reducir la cantidad de Spam recibido por nuestros usuarios. Debemos elegir un método eficiente que permita eliminar el correo Spam. Sin embargo la existencia de falsos positivos hará difícil nuestra decisión, debido a que la mala clasificación del correo deseado por nuestros usuarios, es un problema común en la clasificación de correo Spam.

Existen dos métodos principales para la detección de Spam: la identificación del origen del Spam y mediante el análisis del contenido del mensaje en busca de frases que revelen características clásicas o no del Spam.

Detección basada en información del origen

Al utilizar información como direcciones IP, nombres de host así como direcciones de correo suministradas por los clientes cuando envían algún mensaje, esta técnica compara estas piezas con datos conocidos sobre sistemas empleados para el envío de Spam. Sin embargo la utilización de recursos ajenos a los Spammers para el envío de Spam, como puede ser el manejo de Open Relays, puede retrasar el proceso de investigación del verdadero origen del correo basura. Además, que toda la información obtenida mediante los encabezados de algún mensaje, puede ser generalmente, fácilmente alterada por los Spammers.

Listas negras de DNS

En un esfuerzo por detener el Spam, han sido desarrollados varios servicios Anti-Spam generalmente denominados listas negras basadas en DNSo listas negras en tiempo real. Estos servicios mantienen bases de datos en las cuales se encuentran registrados host que son conocidos como open relays, o que han sido utilizados para el envío de Spam. Algunos de los ataques más comunes en contra de estos equipos, es la instalación de un proxy propio del spammer el cual no sólo podría ser utilizado para enviar Spam, sino también para generar ataques de denegación de servicio.

Detección basada en contenido

Además de identificar clientes que permiten el envío de Spam desde sus equipos, también se puede detectar Spam por medio de su contenido. Ciertas cadenas de texto marcan significativamente el nivel de posibilidad de que un correo sea Spam o no, por ejemplo ''Make more Money''. Sin embargo este tipo de análisis puede llegar a ser muy problemático por los falsos positivos que pueden generar una mala clasificación.

Configuración Anti-Spam de Postfix

Existen 4 diferentes formas de detección de Spam en Postfix:

Reglas de detección de clientes Spam:

Reglas que trabajan con la identidad del cliente. Cada una es una lista asignada de una o más restricciones que pueden aceptar o rechazar un mensaje. Por ejemplo, podemos incluir una regla que rechace mensajes de una dirección IP en particular.

Parámetros de verificación de sintaxis:

Son parámetros que verifican el apego a los estándares actuales en la composición del mensaje. Debido a que varios Spammers no siguen al pie de la letra aquellos que rigen el correo electrónico, nuestro sistema puede estar configurado para rechazar mensajes que vienen de sistemas mal o pobremente configurados.

Verificación de contenido:

Se puede realizar una verificación de las cabeceras y del cuerpo del mensaje por medio de expresiones regulares, las cuales señalarán un mensaje que probablemente sea Spam.

Clases de restricción:

Se pueden definir reglas complejas para la detección de clientes Spam por medio de clases de restricción. Éstas permiten combinar restricciones en grupos para formar otras nuevas.

Cuando se configura Postfix con características Anti-Spam, también se puede especificar qué hacer con los mensajes clasificados como Spam. En general, Postfix puede rechazarlos , separarlos en una cola diferente, o entregarlos a un filtro externo.

Reglas restrictivas contra el Spam

Postfix proporciona las siguientes reglas de restricción basadas en la información del cliente:

  • smtpd_client_restrictions

  • smtpd_helo_restrictions

  • smtpd_sender_restrictions

  • smtpd_recipient_restrictions

  • smtpd_data_restrictions

Cada una corresponde a una etapa en una transacción por medio del protocolo SMTP. En cada una , el cliente proporciona piezas de información. Con ella, Postfix aplica las restricciones que se le hayan configurado. En la siguiente imagen se muestra una conversación SMTP, podemos ver en qué etapa encaja cada regla. Se observa que las reglas mencionadas anteriormente nos permiten verificar las cabeceras y el cuerpo del mensaje, también en estos pasos se ilustran estas reglas, las cuales se discutirán posteriormente.

Figura 2.1: Comunicación por medio de SMTP

Como podemos ver en la imagen, el cliente tiene que realizar ciertas tareas antes de que su mensaje sea entregado. Primero tiene que conectarse por medio de un socket al servidor, con esto Postfix puede aceptar o rechazar mensajes de una dirección IP en específico, aunque en la imagen ésta no aparece, Postfix conoce la dirección IP de cualquier cliente que se conecte. Después él tiene que ejecutar una llamada al comando HELO, con la cual identifica al equipo en el que se encuentra, y así bloquear correo por medio del nombre del equipo o del dominio del mismo. Si el mensaje llega a pasar hasta la etapa de DATA, se puede considerar que ha pasado la primera revisión Anti-Spam de Postfix, se realizará una revisión de las cabeceras del mensaje así como del cuerpo del mismo.

Por default, la configuración de reglas de restricción en Postfix (si no se especificaron algunas en main.cf) son:

smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks, reject_unauth_destination

Esta configuración permite únicamente el relaying de aquellos equipos dentro de la red del servidor de correo y rechaza todos los demás, exceptuando a los que envíen mensajes a uno de nuestros usuarios.

Una de estas reglas, las definimos en el main.cf, y fue la última línea de nuestro archivo:

smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_maps_rbl

El parámetro permit_mynetworks hará que la petición se realice cuando la dirección IP del cliente se encuentre dentro del parámetro mynetworks, el segundo parámetro reject_invalid_hostnamerechazará la petición en el momento que el nombre del equipo indicado en el comando HELO sea invalidado. El último parámetro reject_maps_rbl rechazará la petición al tiempo que la dirección del cliente se encuentre listada en algún servidor de RBLs o en el parámetro maps_rbl_domains. Sin embargo la búsqueda inversa sobre un servidor de RBLs es una propiedad que hemos dejado desactivada.

Parámetros de verificación de sintaxis

Existen dos parámetros que requieren de un estricto apego a los estándares del correo electrónico. Declarando la regla:

smtpd_helo_required = yes

Implica que cada cliente tendrá que iniciar la conversación SMTP con el comando HELO/EHLO, descrito en el RFC 821 del SMTP. Así, cualquier cliente que no inicie apropiadamente el envío del mensaje, sera rechazado por Postfix. Existe otro parámetro en el RFC 821, el cual indica las direcciones a seguir en un formato predeterminado, generalmente Postfix acepta direcciones semejantes al formato predeterminado, sin embargo si se especifica la regla:

strict_rfc821_envelopes = yes

Postfix rechazará cualquier intento de envío de un mensaje con una dirección de formato incorrecto.

Verificación de contenido

La verificación de contenido es la última etapa en la que Postfix puede tomar una decisión sobre el destino del mensaje. Postfix ofrece 4 parámetros que nos permiten especificar el tipo de análisis a realizar:

header_checks:

Análisis de las cabeceras del mensaje.

mime_header_checks:

Análisis de las cabeceras MIME del mensaje.

nested_header_checks:

Análisis de las cabeceras de los datos adjuntos al mensaje.

body_checks:

Análisis del cuerpo del mensaje.

Cuando se especifica un parámetro, se indica en la tabla de búsqueda, las expresiones regulares a utilizar en el análisis del mensaje:

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

Un archivo ejemplo, el cual contenga expresiones regulares para evaluar las cabeceras del mensaje podría ser:

/Make Money/ REJECT
/VIAGRA/ REJECT
/Marketing/ REJECT

También se puede utilizar este tipo de verificación para analizar los archivos adjuntos en el mensaje, por ejemplo, aquellos con ejecutables sospechosos, pueden ser evitados desde la entrada:

/name ?=''?.*1#1.(bat|com|dll|exe|hta|pif|vbs)''?/ REJECT

Instalación de Amavis-new sobre Postfix

Una vez configurado y puesto en marcha el servidor Postfix, instalaremos el filtro Anti-Spam amavis-new, pero antes, necesitamos algunas configuraciones adicionales, las cuales se explican más adelante en esta sección.

La versión utilizada en esta ocasión fue amavisd-new-20030616-p9, la cual puede ser descargada desde el sitio http://www.ijs.si/software/amavisd/. Existen diferentes versiones de amavis, la cuales se describen a continuación:

Amavis:

Es un scanner de virus de correo electrónico, realizado en Perl, incluye algunas características sobre el rendimiento del mismo. Para su configuración, se debe de estar familiarizado con Perl y la configuración utilizada del MTA.

Amavisd:

Es la versión en demonio de amavis, y su integración con el MTA puede ser diferente a la original.

Amavisd-new:

Es una interfaz entre el MTA y algún verificador de contenido como scanners de virus y/o SpamAssassin, el cual ayuda a identificar el posible spam recibido en el servidor.

Amavis-ng:

Es una versión script de amavis, la cual requiere además de ciertos módulos de Perl instalados, algunas herramientas en el sistema, funciona como interfaz entre un MTA y un verificador de contenido.

Antes de iniciar con la instalación de amavis-new, existen algunos programas y módulos que son requisito para poder continuar con la instalación:

  • Herramienta file

  • Herramienta gzip

  • Herramienta bzip2

  • Herramienta compress

  • Herramienta cpio

  • Modulo Archive::Tar

  • Modulo Archive::Zip

  • Modulo Compress::Zlib

  • Modulo Convert::TNEF

  • Modulo Convert::UUlib

  • Modulo MIME::Base64

  • Modulo MIME::Parser

  • Modulo Mail::Internet

  • Modulo Net::Server

  • Modulo Net::SMTP

  • Modulo Digest::MD5

  • Modulo IO::Stringy

  • Modulo Time:HiRes

  • Modulo Unix::Syslog

Todos estos módulos pueden ser descargados de la página del CPAN Comprehensive Perl Archive Network, y la instalación requiere de los siguientes comandos:

# tar -zxvf MODULO.tgz
# cd moduloDir
# perl Makefile.PL
# make
# make test
# make install

Las capacidades de filtrado de contenido, dependerán en parte, de la existencia o no de herramientas de este tipo. Los módulos pueden llegar a ser obligatorios para el funcionamiento de amavis.

Instalación

Para la instalación de amavis necesitamos la versión 5.8.2 o superior de Perl, además de la creación de un grupo dedicado al demonio de amavis. Este grupo no debe ser compartido ni con los usuarios ni con el MTA, su nombre bien podría ser amavis.

Además necesitamos una cuenta de usuario dedicada a la ejecución del demonio de amavis, ésta no puede ser una regular del sistema, ni compartida con el MTA, el nombre de este usuario podrá ser amavis por ejemplo. Debemos de escoger un directorio home para este usuario, que en este ejemplo se ha decidido por /var/amavis. La creación del directorio home del usuario amavis y de los permisos podrán realizarse con los siguientes comandos:

# mkdir /var/amavis
# chown amavis:amavis /var/amavis
# chmod 750 /var/amavis

Descomprimimos el paquete de amavis-new en la ruta que se desee, por ejemplo /usr/local/src y nos cambiamos a ese directorio. Copiamos el archivo amavisda donde se desee que resida, por ejemplo /usr/local/sbin, y cercioramos que sus permisos admitan ejecutarlo, pero no borrarlo por usuarios no autorizados:

# cp amavisd /usr/local/sbin
# chown root /usr/local/sbin/amavisd
# chmod 755 /usr/local/sbin/amavisd

Copiamos el archivo amavis.conf a donde deseemos que resida, por ejemplo /etc, y le asignamos los permisos para impedir la escritura por parte de usuarios no autorizados:

# cp amavisd.conf /etc/
# chown root /etc/amavisd.conf
# chmod 644 /etc/amavisd.conf

Creamos un directorio llamado /var/viruspam/el cual será utilizado por amavis-new como área de cuarentena, sólo si ésta es deseada ya sea para virus o para posible Spam:

# mkdir /var/viruspam
# chown amavis:amavis /var/viruspam
# chmod 750 /var/viruspam

Ahora podemos instalar los módulos como SpamAssassin, el cual nos permitirá realizar un análisis en los mensajes que llegan a nuestro servidor, para poder clasificarlos como Spam o no.

Integrando amavis a Postfix

Ahora sí tenemos que editar nuestro archivo master.cf, y agregar las siguientes líneas al final del archivo:

smtp-amavis unix - - y/n - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes

127.0.0.1:10025 inet n - y/n - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000

Las opciones y/n deben de cambiarse dependiendo si se desea que smtp y postfix trabajen en un ambiente chroot o no. Para las opciones aquí listadas, bastará con colocar la misma opción que las ya existentes en ese archivo. Para cargar la configuración de Postfix al vuelo, ejecutamos el siguiente comando:

# postfix reload

y verificamos si realmente está funcionando Postfix, ahora sobre el puerto 10025 (Esto no significa que deje de funcionar por el 25):

$ telnet 127.0.0.1 10025
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^ ]'.
220 forense.seguridad.unam.mx ESMTP Postfix
quit
221 Bye
Connection closed by foreign host.

Como vimos en 1.4, tenemos que indicarle a Postfix que reenvíe todo el correo que recibe a amavis-new, (como lo muestra 3.1) para una inspección basada en contenido, esto es con la siguiente línea en el archivo main.cf:

content_filter=smtp-amavis:[127.0.0.1]:10024

Figura 3.1: Diagrama de flujo Postfix-Amavis

también podemos usar un comando en el shell para agregar esta línea:

# postconf -e 'content_filter=smtp-amavis:[127.0.0.1]:10024'

esta opción afecta de manera global al sistema de entrada de Postfix (smtp y pickup), si se requiriese una configuración más selecta, la opción:

-o content_filter=smtp-amavis:[127.0.0.1]:10024

debe ser proporcionada al servicio que se desee que realice la inspección de contenido.

Otra opción interesante es la utilización del protocolo LMTP en vez de SMTP cuando Postfix envía mensajes a amavis, esto nos brinda la capacidad de contar con transacciones multi-sesión además de que las respuestas de status se generaran por recipiente. Para contar con esta funcionalidad, debemos modificar las siguientes líneas:

smtp-amavis unix - - y/n - 2 lmtp
-o lmtp_data_done_timeout=1200
-o lmtp_send_xforward_command=yes

Esto funciona en versiones recientes de Postfix, sin embargo existen 2 bugs en el código del cliente LMTP de Postfix, los cuales aparecen al realizar un análisis del número de puerto de LMTP y la conversión de direcciones. Así que, si se utiliza esta opción, es recomendable tener al día la versión del servidor Postfix.

Después de esto, cargamos la configuración de Postfix al vuelo con el comando antes visto.

 

Configuración de amavis-new

Ahora editaremos el archivo amavis.confel cual copiamos a /etc, este archivo está dividido en varias secciones, en las cuales se describen las opciones de configuración más importantes, para al final resultar en un archivo de configuración ejemplo.

Sección I: Configuración del demonio y del MTA

Aquí ajustaremos los valores de las variables $daemon_groupy $daemon_useral nombre de usuario y grupo que creamos anteriormente. Además establecemos los valores de $MYHOMEy $TEMPBASE, la dirección del home de amavis, así como las variables $mydomainy $myhostnamecon los valores que asignamos en el main.cf de Postfix:

$MYHOME = '/var/amavis';
$mydomain = 'seguridad.unam.mx';
$myhostname = 'forense.seguridad.unam.mx';
$daemon_user = 'amavis';
$daemon_group = 'amavis';
$TEMPBASE = $MYHOME;

Como vemos en 3.1, Amavis necesita regresar por algún medio los mensajes que verifica y notificaciones necesarias a Postfix, esto se lo indicamos por medio de las variables $forward_methody $notify_method:

$forward_method = 'smtp:127.0.0.1:10025';
$notify_method = $forward_method;

Podemos indicarle a Amavis, el numero de procesos que leerán el pipe que el MTA mantiene con amavisd, éste podemos sacarlo de la línea que agregamos en master.cf:

smtp-amavis unix - - y/n - 2 smtp

Con esto, desde nuestro archivo de configuración podemos decirle a amavis, el número de procesos hijo a ejecutar, así como cuantas peticiones puede manejar cada uno como máximo, y el tiempo máximo que tiene el proceso hijo para terminar cada tarea, esto lo hacemos con los parámetros $max_servers,$max_requestsy $child_timeoutrespectivamente:

$max_servers = 2;
$max_requests = 10;
$child_timeout=5*60;

Desde el archivo de configuración de amavis, también podemos especificar parámetros que nos permitan realizar el análisis de los mensajes por medio de una herramienta antivirus, sin embargo esta característica no fue utilizada en este documento, de manera que deshabilitaremos esta característica con la siguiente línea:

@bypass_virus_checks_acl = qw( . );

Amavis necesita determinar, si un mensaje es local o no, o en otras palabras, si es externo o no. Esto es muy útil para reducir el número de notificaciones que podrían generarse por el correo local, esto si consideramos que localmente no se genera Spam para nosotros mismos =|. Esta configuración la especificamos en el parámetro @local_domains_aclde la siguiente manera:

@local_domains_acl=( ''.$mydomain");

Sección II: Valores específicos para el MTA

Ahora como lo hemos manejado antes, se tienen que especificar los parámetros necesarios para que la comunicación con el MTA se realize con éxito, asignaremos el nombre al archivo socket que utilizará en la comunicación, así como el puerto y la interfaz que manejará, esto por medio de los siguientes parámetros:

$unix_socketname = "$MYHOME/amavisd.sock";
$inet_socket_port = 10024;
@inet_acl = qw( 127.0.0.1 );

Sección III: Bitácora

La configuración en esta sección es muy sencilla, podemos especificarle a amavis si deseamos que la bitácora la maneje SYSLOGo si deseamos mandarla a un archivo de texto, para este ejemplo utilizamos las siguientes opciones:

$DO_SYSLOG = 0;
$LOGFILE = "$MYHOME/logs/amavis.log";
$log_level = 4;

Con el primer parámetro, amavis entenderá el uso de un archivo de texto como bitácora, la ruta de éste está indicada por el segundo parámetro. Si se quisiera llevar la bitácora por medio de syslog, el parámetro DO_SYSLOGdebería ser establecido a 1. El parámetro log_leveldenota el nivel de detalle de la bitácora, existen 6 niveles los cuales podemos usar en este parámetro:

0: Mensajes de inicio/salida/falla, detección de virus.

1: Argumentos pasados por el cliente, además de algunos mensajes interesantes.

2: Salida del herramienta antivirus, tiempos.

3: Servidor, cliente.

4: Partes separadas.

5: Detalles adicionales de depurado.

Sección IV: Notificaciones, destino, cuarentena

Ahora le indicaremos a amavis qué hacer con el correo clasificado como Spam, así como las posibles notificaciones a enviar por parte del MTA o por el mismo amavis al destino del mensaje. Existen varias opciones por utilizar dependiendo del tipo de análisis, por ejemplo, definir que se envíe una notificación al origen del mensaje, si se determinó que éste contenía algún virus en sus cuerpo, y otra acción para el origen del Spam, en este caso no es recomendable enviar una notificación al origen, de que su mensaje ha sido clasificado como Spam, debido a que no sabemos quién está del otro lado, y podemos indicarle al Spammer información que no debería de conocer. Las posibles opciones a utilizar en el parámetro final_spam_destinyson:

D_PASS:

El mensaje será entregado aún sin importar la clasificación de su contenido.

D_DISCARD:

El mensaje no será entregado, y no se enviará ninguna notificación al origen del mensaje.

D_BOUNCE:

El mensaje no será entregado, y una notificación non-deliveryserá enviada al origen del mensaje por Amavis. Sin embargo no se enviara dicha notificación, si algún nombre de virus que se encuentra en el parámetro $viruses_that_fake_sender_rese encuentra en el mensaje, o para aquellos mensajes que son de listas de correo (Precedencia: bulk, list o junk ).

D_REJECT:

El mensaje no será entregado, el origen debería de ser notificado con una respuesta de rechazo permanente, o con una respuesta non-deliverydesde el MTA.

Para indicarle a nuestro filtro que el mensaje que ha sido clasificado como Spam no sea entregado, y que no se envíe ninguna notificación al origen del mensaje, utilizaremos la siguiente entrada:

$final_spam_destiny = D_DISCARD;

Amavis tiene la capacidad en enviar notificaciones al administrador de una posible alerta ya sea de detección de virus o de la recepción de Spam. Para esta última, el siguiente parámetro denota de que dirección saldrán esas notificaciones:

$spam_admin = "spamalert1#1@forense.seguridad.unam.mx";

Sin embargo los reportes de las notificaciones pueden ser enviadas por otro usuario, con el siguiente parámetro, asignamos a postmaster:

$mailfrom_notify_spamadmin = "postmaster1#1@forense.seguridad.unam.mx";

Para los mensajes de cuarentena, es muy importante mantener la dirección de origen inicial, o sea, que amavis no modifique esta cabecera, utilizaremos este parámetro:

$mailfrom_to_quarantine = '';

Los mensajes que han sido clasificados como Spam, se colocarían en cuarentena para un análisis posterior, por ello se elige enviar por correo el mensaje a una cuenta de usuario, para esto utilizamos el parámetro:

$spam_quarantine_to = "spam-quarantine1#1@forense.seguridad.unam.mx";

Si por algún motivo, el análisis de algún mensaje no se completó, una cadena puede ser concatenada en la cabecera de asunto, para hacer esta indicación, con la variable $undecipherable_subject_tagse configura este mensaje:

$undecipherable_subject_tag = '***UNCHECKED*** ';

Sección V: Administración por recipiente u origen

En esta sección, podemos definir algunas reglas para que aquellos usuarios que no requieran del filtrado tanto de correo spam, como de virus, puedan recibir su correo sin ningún problema. Existen parámetros como %virus_lovers, @virus_lovers_acly $virus_lovers_redonde podremos especificar qué usuarios pueden recibir correo aún si éste contiene algún virus. De igual manera, existe este tipo de configuración para Spam, con %spam_lovers, @spam_lovers_acl, $spam_lovers_re. Esta configuración no se utilizó en este ejemplo, debido a las características del uso del servidor de correo.

Listas blancas

Son utilizadas para asegurar la entrega de los mensajes de un remitente, el cual forma parte de estas listas, aún si el mensaje ha sido reconocido como Spam. Los mensajes que provengan de remitentes de este tipo de listas, no serán editados con la etiqueta de ****POSIBLE SPAM****, además de que algunas tareas como la cuarentena no aplicarán a éstos. Un ejemplo de la declaración de listas blancas es el siguiente:

%whitelist_sender, @whitelist_sender_acl, $whitelist_sender_re
@whitelist_sender_acl = qw( .example.com );

Listas negras

Para los mensajes cuyo remitente se encuentre en este tipo de parámetro, el nivel de probabilidad de que sea Spam es automáticamente puesto en un valor alto, el resultado de esto es una clasificación como Spam automática y el mensaje será tratado como tal.

Uso de recursos

Aquí podemos asignar valores a las tareas de extracción y decodificación, para definir el número de archivos, así como el nivel de recursión en la extracción de archivos. Los valores utilizados en este documento, se listarán en el archivo de configuración de muestra.

Programas externos, analizadores de virus

En esta sección podemos asignar la ruta en la cual se encuentran la mayoría de las herramientas que instalamos al inicio de este capítulo, además de especificar una cadena de PATHque funciona para la localización de los programas externos a amavis.

$path = '/usr/local/sbin:/usr/local/bin:/usr/sbin:/sbin:/usr/bin:/bin';

Configuración de SpamAssassin (amavis.conf)

Esta sección no es la única en la cual podamos configurar nuestro SpamAssassin, ni la más recomendable. Sin embargo, podemos indicar las configuraciones básicas de SpamAssassin sobre Amavis. Los parámetros configurables en esta sección son los niveles en los cuales, SpamAssassin se basará para clasificar un mensaje como SPAM, posible Spam o lo que denomina HAM (correo que no es Spam), estos valores fueron establecidos a los siguientes valores:

$sa_tag_level_deflt = -999;
$sa_tag2_level_deflt = 3.0;
$sa_kill_level_deflt = 5.0;

El valor del parámetro $sa_tag_level_defltnos indica que cualquier mensaje que tenga un puntaje arriba del indicado por éste se le agregaran las cabeceras de SpamAssassin, con el valor que le hemos asignado, aseguramos que cualquier mensaje contendrá estas cabeceras. El parámetro $sa_tag2_level_defltnos muestra que si un mensaje alcanza este puntaje, se adicionará al asunto del mensaje, la cadena descrita por el valor del parámetro $sa_spam_subject_tagla cual en nuestro ejemplo tiene el siguiente valor:

$sa_spam_subject_tag = '***Posible SPAM*** ';

Este parámetro es también configurable en el archivo local.cf de SpamAssassin, sin embargo, el valor contenido en amavis.conf, anulará el posible valor en el archivo de configuración local.cf. Los mensajes que caigan en este caso, llegarán al destinatario, sin embargo la cabecera de asunto le indicara al usuario la posibilidad de que sea un falso negativo o un falso positivo, será tarea del usuario clasificar este tipo de mensajes. El valor del parámetro $sa_kill_level_defltnos revelará que un mensaje que alcance este puntaje pasara a cuarentena (si es el caso) y se mandará la alerta correspondiente.

Ahora podemos iniciar nuestro filtro amavis con la opción

debug

, para ver en tiempo real, las tareas que realiza al iniciar:

# amavisd debug

Desde otra consola, podemos verificar que efectivamente está trabajando como debería de ser, por el puerto 10024:

# $ telnet 127.0.0.1 10024
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^ ]'.

220 [127.0.0.1] ESMTP amavisd-new service ready

quit

221 Bye
Connection closed by foreign host.

Liberación original: Miércoles, 22 Junio 2011
Última revisión: Lunes, 24 Septiembre 2012

La Coordinación de Seguridad de la Información/UNAM-CERT agradece el apoyo en la elaboración y revisión de este documento a:

David Jiménez Domínguez

Para mayor información acerca de este documento contactar a:

UNAM-CERT: Equipo de Respuesta a Incidentes UNAM 
Coordinación de Seguridad de la Información 
Dirección General de Cómputo y Tecnologías de Información y Comunicación 
Universidad Nacional Autónoma de México 
E-Mail: incidentes@cert.unam.mx 
http://www.cert.org.mx
http://www.seguridad.unam.mx
ftp://ftp.seguridad.unam.mx
Tel: 56 22 81 69