Control de UCE (y malware) en Postfix (II)

Unos meses después de escribir la primera parte de un artículo sobre control de correo no deseado utilizando Postfix, tuve que diseñar e implementar un servicio integral de control de correo no deseado y malware en un entorno corporativo. Previamente se utilizaba una solución propietaria que funcionaba bien aunque había mucha incertidumbre en la gestión de rebotes, listas negras y mensajes denegados.

Esta solución está implementada en el MX de un dominio para el que se estiman entre 400 y 500 mil conexiones por día, con un 95% de incidencia de correo no deseado o malware. El plan inicial involucra hacer mucha denegación de correos a nivel SMTP, utilizar listas grises y sólo hacer el escaneo de contenido (con un filtro de contenidos y no con spamc, por ejemplo) al final de la depuración.

Componentes

  • Postfix, un MTA seguro, robusto y muy fácil de mantener. Lo utiliza mucha gente y hay bastante documentación, escrita por el propio Wietse, y muchos usuarios hispanoparlantes diespuestos a ayudar.
  • Postgrey, una implementación de greylists para Postfix que utiliza Berkeley DB.
  • SpamAssassin, el filtro anti-spam de código abierto más popular y probablemente el más avanzado también.
  • ClamAV, un escáner anti-virus con firmas actualizadas frecuentemente y capacidad de trabajar con archivadores.
  • Amavis, un filtro de contenidos escrito en Perl que puede ser visto como un wrapper sobre filtros anti-spam (i.e., SpamAssassin) y anti-virus (ClamAV et. al.)
  • MailZu, un gestor de la cuarentena de Amavis (vía SQL) que permite la autenticación con directorios LDAP, y permite que un usuario auto-gestione su cuarentena.

Configuración

Amavis requiere configurar dos servicios en master.cf, uno que será el filtro de contenidos (todos los correos se enviarán allí excepto si las restricciones tienen un permit antes del reject predeterminado) y otro que servirá para reinyectar correos a Postfix luego de que Amavis los procese, sin pasar de nuevo por las verificaciones.

amavis-smtp     unix    -       -       y       -       10      smtp
  -o smtp_data_done_timeout=1200s -o smtp_never_send_ehlo=yes -o disable_dns_lookups=yes

localhost:10025 inet    n       -       y       -       -       smtpd
  -o content_filter= -o local_recipient_maps= -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions= -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks=127.0.0.0/8

En este caso se crea un servicio SMTP llamado amavis-smtp, cuyo límite de procesos (maxproc) debe ser igual o menor al número de procesos amavisd que se estén ejecutando. Muchas de las configuraciones y recetas que se consiguen en Internet dejan el servicio amavis-smtp con solo dos procesos, lo que convierte al filtro de contenido en un cuello de botella, y en un servidor muy cargado provocará que los correos se encolen catastróficamente.

El servicio de reinyección de correos a Postfix tiene un límite predeterminado (100 procesos) y no tiene restricciones ya que no se va a gastar en volver a hacer verificaciones SMTP que se hicieron al recibir el correo por primera vez. Por seguridad, también se restringe el acceso a este servicio solo a localhost. Luego de reiniciar Postfix, telnet a ambos puertos con Amavis arriba ayuda a entender la situación.

Postfix recibirá los correos por el tradicional puerto TCP 25 y aplicará sus propias restricciones (incluyendo el servicio de listas grises, que en el caso de postgrey escucha en el puerto TCP 60000) para luego entregar el correo vía SMTP a Amavis por el puerto 10024.

smtpd_recipient_restrictions =
...
check_policy_service inet:127.0.0.1:60000
...

content_filter = amavis-smtp:localhost:10024

Amavis procesa el correo según su propia configuración: usa SpamAssassin y ClamAV; en Debian es muy fácil activar ClamAV en el archivo 15-av_scanners del directorio /etc/amavis/conf.d. También queremos tener ClamAV y SpamAssassin actualizados usando freshclam y sa-update, y utilizando Debian siempre es conveniente instalar desde el servicio volatile.

La configuración local debe ir en el archivo 50-user. Aquí nos interesan varios valores para configurar el comportamiento del filtro, entre ellos el nombre del dominio, el número de procesos, el mecanismo de reinyección, las políticas predeterminadas, el tamaño máximo del correo y las puntuaciones requeridas para actuar sobre un correo.

$mydomain = 'usd.sl.com.ve';

$max_servers=10;

$forward_method = 'smtp:127.0.0.1:10025'; 

$final_virus_destiny = D_DISCARD;
$final_spam_destiny = D_DISCARD;

$sa_mail_body_size_limit = 64*1024;

$sa_tag_level_deflt = 1.0;
$sa_tag2_level_deflt = 5.0;
$sa_kill_level_deflt = $sa_tag2_level_deflt;

De acuerdo a este snippet, Amavis descartará (es decir, guardará en cuarentena sin mayor notificación al remitente o al destinatario) aquellos correos que detecte como virus y spam. Reinyectará correos al puerto 10025 usando SMTP, correrá 10 procesos y solo utilizará SpamAssassin para revisar correos de menos de 64 KB, previendo que los spammers no suelen enviar UCE de gran tamaño.

También es importante saber que Amavis tiene dos umbrales de trabajo con SpamAssassin, el primero es la puntuación mínima que debe recibir el correo para escribir las cabeceras del anti-spam y el segundo es la puntuación mínima que debe tener el correo para que sea marcado como spam. El primero puede ser bajado sin problemas a un valor negativo si se desean cabeceras informativas en todos los correos.

Teniendo filtros de contenido de alto rendimiento como amavisd-new que pueden manejar staging de correos, pareciera lógico delegar las DNSBL al filtro de contenido y no hacerlo en el MTA, como recomendé en la primera parte. Esto evita gastar recursos en correo que puedes denegar con restricciones SMTP o con un breve análisis de contenidos.

Amavis puede reportar a bases de datos remotas que luego pueden ser utilizadas por aplicaciones como MailZu para delegar la gestión de cuarentena al usuario. Sin embargo, el reporte SQL de Amavis puede ser un cuello de botella, así que solo lo recomendaría si Amavis y Postfix están en máquinas distintas y el uso de recursos de Amavis no provocará un colapso de Postfix.

Estos pedazos de configuración no están de ninguna manera completos. Son referencias para ayudar al administrador de Postfix a implementar una solución de control de correo funcional. Es necesario ajustar todos estos valores dependiendo de los requerimientos de la organización, ya que no hay una solución única para todos los casos (AFAICT, Debian usa 4.0, CANTV usa 3.0 y CNTI usa 2.0)

¿Y luego?

Hay más tecnologías que explorar. Una de ellas es la denegación de correos a bloques de direcciones correspondientes a usuarios finales (S25R, en mi opinión demasiado injusto, pero que puede acercar teóricamente a una solución de 99.9% de eficiencia) y SPF, que ya había comentado en el primer post sobre el tema. En SpamAssassin hay algunas cosas más que tocar, sobre todo CRM114. SA, sin embargo, requiere mucho mantenimiento en comparación con el resto de las herramientas presentadas en esta solución.

Para poner en funcionamiento esta solución eché mano de la documentación de Postfix y la de Amavis, que está disponible en Internet, pero hay un documento en castellano publicado por CERT-UNAM que puede ayudar a entender muchas cosas sobre Postfix: Instalación de Postfix, Amavis y Spamassassin.

Performance

Con 2 GB. de RAM, el equipo puede levantar unos 25 procesos del filtro de contenidos, los 100 procesos SMTP de Postfix, postgrey, clamd y las herramientas de gestión del servicio. Note que Martinec afirma que tener más de 10 procesos de Amavis corriendo es overkill. Normalmente, incluso este servidor no tiene más de 10 correos en las colas incoming o active al mismo tiempo, y si los tuviera no quisiéramos agotar la memoria del equipo atendiendo más correos paralelamente cuando se puede escribir en disco y atender la cola más tarde.

Hay dos cuellos de botellas en esta solución, y ninguno es Postfix, o al menos no comunmente. El primero es la red, por un mal diseño de la conectividad cuando se instaló el servicio; lo recomendable es tener un canal dedicado para el ISP y otro para la red local. Es esencial tener un DNS-caché en el mismo equipo, y particularmente no me parece conveniente utilizar OpenDNS como forwarder (este servicio siempre devuelve un registro A aunque no exista el nombre)

También pueden ayudar unas reglas de iptables que limiten la tasa de conexiones por unidad de tiempo, quizás algo como (YMMV):

iptables -I INPUT -p tcp --dport 25 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 25 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP

El otro cuello de botella es el disco duro. Si bien se evita que Postfix trabaje con sus colas (normalmente este equipo puede manejar entre 200 y 500 correos en deferred) no hay forma de evitar (excepto eliminando los correos) que Amavis escriba varios miles de correos al día a la cuarentena en disco (peor aún, con reportes SQL a un equipo remoto) en el peor de los casos hasta 10 a la vez. Discos rápidos o RAID 0 podrían ayudar.

Outcome

Algunos números obtenidos en un período de 24 horas: de 430 mil conexiones SMTP recibidas por el servidor, unas 200 mil (~47%) son eliminadas por listas grises (es decir, nunca vuelven = spam), y otras 200 mil son eliminadas por Postfix (usuarios no existentes o dominio del remitente inexistente = spam o correo problemático) por lo cual solo 30 mil correos diarios se entregan a Amavis para su verificación con ClamAV y SpamAssassin.

Unos 4 mil correos al día son descartados por Amavis, y solo 26 mil correos (~6%) son distribuidos entre los MTA internos o hacia MXs externos. De estos, realmente muy pocos son UCE (en quince días unas cinco incidencias reportadas) y muy pocos son falsos positivos (cero incidencias reportadas) con ningún reporte de virus hasta el momento.

Showcasing LaTeX Beamer

Should you ever need to decide between the most common themes and color themes of LaTeX Beamer shipped with FOSS distributions, take a look at the following code:

for theme in AnnArbor Antibes Bergen Berkeley Berlin Boadilla boxes CambridgeUS Copenhagen Darmstadt default Dresden Frankfurt Goettingen Hannover Ilmenau JuanLesPins Luebeck Madrid Malmoe Marburg Montpellier PaloAlto Pittsburgh Rochester Singapore Szeged Warsaw
do

for color in albatross beaver beetle crane dolphin dove fly lily orchid rose seagull seahorse sidebartab structure whale wolverine
do

        mkdir work
        sed s/#theme#/$theme/ demo.tex | sed s/#color#/$color/ > work/$theme$color.tex
        cd work
        pdflatex -interaction batchmode -job $theme$color $theme$color.tex
        mv *pdf ../
        cd ..
        rm -rf work

done
done

With a demo LaTeX file such as:

\documentclass{beamer}

\usepackage[spanish]{babel}
\usepackage[T1]{fontenc}
\usepackage{ae,aecompl}
\usepackage{textcomp}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{ulem}

\usetheme{#theme#}
\usecolortheme{#color#}

\title{LaTeX Beamer Theme Demonstration}

\author{José Miguel Parrella Romero}

\begin{document}

\frame
{
        \titlepage
}

\frame
{
        \frametitle{UTF-8 Título}

        \begin{block}{A block}
                Looks like this.
        \end{block}

        \begin{block}{Another block}
                \begin{itemize}
                        \item This is a list.
                        \item Indeed!
                \end{itemize}
        \end{block}
}

\end{document}

LOL @ Obfuscated JavaScript!


eval(function(p,a,c,k,e,d){e=function(c){return(c d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new
RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('o ci={cj:\'1.11\'};k
$77(N){m(N!=9N)};k $F(N){B(!$77(N))m O;B(N.5i)m\'G\';o F=7c
N;B(F==\'2I\'&&N.ch){22(N.84){Y 1:m\'G\';Y
3:m(/\\S/).2v(N.ax)?\'cg\':\'cd\'}}B(F==\'2I\'||F==\'k\'){22(N.9C){Y
2t:m\'1z\';Y 7y:m\'5C\';Y 18:m\'4R\'}B(7c
N.V==\'4M\'){B(N.3r)m\'ce\';B(N.8t)m\'1b\'}}m F};k $2a(){o 54={};M(o
i=0;i<1b.V;i++){M(o K 1a 1b[i]){o ap=1b[i][K];o
6d=54[K];B(6d&&$F(ap)==\'2I\'&&$F(6d)==\'2I\')54[K]=$2a(6d,ap);14
54[K]=ap}}m 54};o $R=k(){o 1p=1b;B(!1p[1])1p=[c,1p[0]];M(o K 1a
1p[1])1p[0][K]=1p[1][K];m 1p[0]};o $5e=k(){M(o
...

5FMCL: Final

Del 19 al 23 de noviembre de 2007 se llevó a cabo en Ciudad Guayana el V Foro Mundial de Conocimiento Libre, evento que se lleva a cabo desde 2004 organizado por grupos de promotores de software y conocimiento libre, empresa privada, instituciones académicas y entes del Estado Venezolano, en particular este año por la Asociación Civil Software Libre de Venezuela (SOLVE) y Electrificación del Caroní (EDELCA)

Actividades

Este año no me involucré en el Comité Organizador como lo hice en la tercera y cuarta edición del evento, principalmente por estar ocupado en otras actividades académicas y sobre todo profesionales, pero de cierta manera me sentí como anfitrión del evento, en primer lugar porque durante el evento colaboré en muchos aspectos y en segundo lugar por tener una especial relación con EDELCA y Ciudad Guayana.

Aparte de esta actividad de pseudologística, realicé una presentación sobre la Distribución de Software Libre basada en Debian desarrollada y en producción actualmente en casi dos mil equipos de EDELCA, y participé en la presentación de los clusters de servicios corporativos que configuré en la misma compañía junto con el Ing. Víctor Oñate y el Ing. Edward Ortega.

También tuve la oportunidad de dictar un taller corto (cuatro horas) sobre Perl debido al retraso en el vuelo de Antonio Galindo. Participaron unas sesenta personas en un recorrido breve sobre las poderosas funcionalidades de Perl, sobre todo aquellas que resultan atractivas para los desarrolladores nóveles. Así mismo promoví con otros compañeros varios subeventos que se dieron, particularmente el firmado de llaves y la reunión de Debian Venezuela.

Mejoras

Mi balance general del evento es altamente positivo, en especial comparado con los eventos de Maturín y Maracaibo, siendo en esta ocasión muy superior el mecanismo de logística que activaron desde el Comité Organizador para revolucionar la manera en la que el país ve el Foro Mundial de Conocimiento Libre.

Por ejemplo, este año se esforzaron en que todas las actividades estuvieran en el mismo venue, incluyendo la mayor parte de los invitados y todas las ponencias y talleres, maximizando la participación del público y los invitados nacionales e internacionales en todas las actividades del Foro. Así mismo se llevó adelante una efectiva política de atención al invitado, incluyendo la alimentación y la recreación. Desde mi condición de ponente del evento, puedo decir con propiedad que este ha sido el FMCL donde mejor se ha tratado a todo el interesado en participar.

En esta ocasión cuajó muy bien la idea de los stands, de hecho fue una de las partes más movidas e interesantes del evento por la participación de personas de distintas organizaciones de promotores de software libre a nivel nacional, así como entes del estado y empresa privada.

Pude percatarme por la cercanía con el grupo organizador de algunos factores negativos que siempre viene al caso resaltar. Uno de ellos es el factor comportamiento, que desde 2005 resulta muy difícil de controlar y que pareciera que se debe a las condiciones personales de cada quien, y otro es el tema del exceso de responsabilidades de algunos colaboradores, quienes llegaron a tomarse atribuciones de designar costosos recursos según sus criterios personales sin pertenecer a la organización del evento.

Como siempre, son tópicos que conviene revisar para el siguiente evento, aunque con el tema del comportamiento quizás no ha habido suficiente decisión para remover un problema no solo logístico sino de imágen y de ética. En líneas generales, y de las opiniones que recabé en muchos participantes, no se sintió ruido producto de ninguno de los inconvenientes que suelen presentarse en este tipo de eventos.

Final

El FMCL es un evento único. Independientemente de quien lo organice cada año, o donde sea, tiene características que lo diferencian de todos los demás eventos de software libre y de código abierto que se hacen en el país. No en vano es el evento más grande que se hace en Venezuela. Por su duración, requiere que muchas personas le dediquen más tiempo de lo que normalmente le dedicarían a una conferencia de uno o dos días, y es en este semi-internado que realmente se avanzan muchas cosas.

Felicito a Ailé Filippi, Álvaro Hernández, Milton Mazzarri, Héctor Colina, José David Gutiérrez y a todo el personal de EDELCA y demás patrocinadores que trabajaron organizando este evento. Ha sido el FMCL con mejor organización y propósito al que he asistido.

Software libre, universidades y la LOCTI

Hace varios días estuve revisando por curiosidad los proyectos propuestos por distintos profesores y personal directivo de la Universidad Central de Venezuela para optar al financiamiento por el artículo 42 de la LOCTI, y entre algunas cosas realmente preocupantes (como los proyectos de actualización de licencias de software propietario y las multimillonarias cifras para la implementación de VoIP, probablemente bajo estándares cerrados) sobresalen algunas perlas.

William La Cruz es profesor agregado de la Escuela de Ingeniería Eléctrica, donde estudié casi dos años y tuve la oportunidad de cursar la asignatura de variable compleja y cálculo operacional con él. Veo con bastante agrado que uno de los proyectos está propuesto por él y consta de software libre que implemente métodos de computación paralela para la optimización y simulación de procesos en las áreas de energía y telecomunicaciones.

Otro de los proyectos de la Escuela de Ingeniería Eléctrica, en el que participan tanto el Prof. La Cruz como el Prof. Ebert Brea (quien es ahora Director de la EIE) es el de desarrollar software libre para transcribir música en cualquier formato a MIDI con la finalidad de imprimir partituras musicales para su uso por parte de discapacitados. Es realmente agradable ver como desde el mundo académico, sin proclamarse de la comunidad y sin tener un organigrama que se alinee con la retórica gubernamental puede obtenerse apoyo para proyectos de software libre.

Pero…

Por otra parte, sigue el bombardeo desde muchos frentes en contra del software libre, de código abierto, o como quieran llamar a esas importantes piezas de la informática que facilitan el intercambio y la aplicación de conocimientos. Desde proyectos de empresas de software privativo solicitando financiamiento gubernamental hasta artículos en revistas de circulación nacional, como el caso de un artículo sobre SL en Business, cuyo formato de revista para yuppies, escrita en ocasiones en un risible inglés y con un contenido realmente pobre, deja bastante que desear.

El artículo está aquí, y en él entrevistan nada más y nada menos que el Prof. Nelson McQuhae, quien en las discusiones de la Ley de Infogobierno se presentaba como profesor de la UCV, luego pasó a ser representante de la empresa privada y en la revista finalmente se destapa como representante de Microsoft Venezuela.

Aparte de los numerosos errores literales, atribuibles a los editores, McQuhae explota de forma baja, con argumentos ofuscados y sobre todo con mucho FUD muchas situaciones que se propician por la expectativa desmesurada que ha provocado el Decreto Presidencial 3390. Si bien es cierto que hoy en día el panorama de software libre en el Gobierno parece dominado por las influencias, falsas creencias, poco control, pobre desempeño técnico y escasa investigación, esto no significa que se estén perdiendo oportunidades para la integración de tecnologías, y sobre todo no significa que el software libre no sirva o que su implementación en Venezuela sea una catástrofe.

Quizás sería bueno que las empresas del sector de software propietario empiecen por reconocer que aún ejercen una fuerza mayoritoria en la academia, satanizando a las tecnologías de código abierto y produciendo rechazo en los futuros profesionales. El gobierno, como en muchos otros aspectos, solo tiene una cuota minoritaria en esta supuesta lucha de fuerzas para la satanización de tecnologías.

Si bien muchas cosas no están andando nada bien con respecto al Decreto, hay muchos casos de éxito que desbancan la idea de que el proceso de migración no está teniendo éxito en Venezuela. Allí están organismos completos, ministerios, empresas del Estado, academia y sector defensa utilizando software libre para procesos críticos, incluso colaborando en algunos contados casos con la mejora de lo que está disponible. So FOAD.

Reversión

Sin embargo, hay algunas cosas que McQuhae dice que sin duda llaman la atención, como por ejemplo su previsión de que en el futuro se reversará la migración, quedando con un híbrido natural. Es una de las cosas que aquellos que se preocupan por el dinero público quieren evitar a toda costa, a riesgo de que más de un talibán les diga que se están oponiendo al Decreto.

Esa estrategia es la que hay preparar, la de evitar que se implante la idea general de que la migración será reversada algún día, y que afecta tanto a los usuarios, como al Gobierno y a las comunidades, al menos aquellas que se desviven por una cuota de complacencia en el marco del Decreto, y que bien pudieran quedar sin piso si la estrategia del Estado cambia. Y si es así nos quedaríamos con muchos organismos migrados, otros a medio migrar, otros que no han hecho nada, mucho dinero invertido, mucho dinero por invertir, muchas comunidades sin sentido en la vida, casi nada de investigación y desarrollo (no basta con apoyar la migración, tienes que saber mucho), muchas influencias rotas, muchos proyectos sin concluir por incapacidad técnica y sobre todo mucha frustración.

Las soluciones se podrán encontrar cuando cada quien busque la respuesta a la eterna pregunta de si estás allí porque crees y te sientes productivo usando software libre, de código abierto, o si estás allí porque hay un boom laboral o de protagonismo que quieres aprovechar. De esto depende que siga habiendo voluntad en el país para hacer software de calidad, con proyección internacional y sentido social, que podrá resolver muchas de las necesidades en Venezuela con o sin apoyo gubernamental y que pueda realmente defender los ideales de independencia que tanto se exponen.