| Formulario de acceso |
|---|
| Anuncios |
|---|
|
|
| Sistema de correo con Postfix, Cyrus y MySQL (XI - Filtrado) |
|
|
| domingo, 30 de abril de 2006 | |
|
Tres son las herramientas fundamentales que habremos de configurar para obtener un filtrado de los correos de nuestro servidor. Sieve, lenguaje con el cual compondremos filtros en la entrega final del correo, SpamAssassin, programa con el que filtraremos el correo no deseado y ClamAV, potente antivirus que evitará la entrega de correo infectado. Al final de este extenso capítulo, probaremos el filtrado con el envío de mensajes infectados y con cabeceras que simularán spam. El uso de Sieve Aunque la forma más sencilla de utilizar Sieve es mediante algún tipo de interfaz que nos facilite la tarea y componga el script por nosotros (de hecho, en el siguiente capítulo atenderemos, entre otras cosas, a la instalación y la configuración de una interfaz que nos permita una generación de estos filtros mucho más amena.), no está de más acercarnos, aunque sea de manera somera, al uso de este lenguaje para la composición de filtros. $ sieveshell -user info -authname usuario001 localhost El uso de la consola de sieveshell es muy sencillo, no llegando a la decena el número de comandos a nuestra disposición. Para tener una idea más clara de cuáles y para qué sirven estos comandos, ejecutaremos man sieveshell en la consola del sistema. A continuación, adjuntaremos un ejemplo del uso del lenguaje utilizado por Sieve en los scripts de filtrado. Dicho ejemplo atiende a la cabecera de los mensajes para filtrar según el remitente o el asunto del mensaje: #Script de Sieve SpamAssassin Tanto SpamAssassin como ClamAV serán utilizados desde Postfix y a través de Amavisd-new, que hará de interfaz entre los programas y el servidor. En un sistema con una distribución de Fedora Core, la simple instalación del paquete RPM correspondiente a SpamAssassin dejará este programa completamente instalado y configurado para su uso. Sin embargo, hay que aclarar un punto que puede ser modificado a gusto del usuario y que optimizará el funcionamiento del programa: No es necesaria la ejecución del servidor spamd sobre nuestro sistema, por lo que evitaremos la misma mediante el siguiente comando: #chkconfig --del spamassassin La principal ventaja de spamd es su eficiencia, ya que las comunicaciones se establecen a través del puerto 783 y evitan el tener que cargar un ejecutable cada vez que se hagan las comprobaciones referentes al spam. El principal inconveniente es relativo a la seguridad: aunque bajo, el riesgo de tener corriendo un servidor en un puerto siempre está sujeto a posibles vulnerabilidades por errores en el código. En nuestro caso, cargaremos SpamAssassin a través de Amavisd-new, que llamará al programa mediante el módulo de Perl Mail::SpamAssassin. Con esto conseguiremos que el motor con las reglas siempre quede cargado en memoria, obteniendo una eficiencia similar a la de la ejecución de spamd. No obstante, como hemos dicho anteriormente, esto no es más que una recomendación, quedando a gusto del usuario su aplicación. Para tener un elevado número de aciertos con el filtrado de spam, utilizaremos los llamados filtros bayesianos. Este tipo de filtrado requiere un entrenamiento para que sea eficaz en un alto porcentaje de los casos. Para ello, habremos de proporcionar a SpamAssassin un elevado número de mensajes, tanto de spam como de ham (no-spam), y esto lo conseguiremos mediante el uso de la herramienta sa-learn (ejecutaremos man sa-learn para documentarnos adecuadamente a cerca de este programa). Básicamente, ejecutaremos sa-learn --spam <directorio> para la recolección de mensajes que sabemos a ciencia cierta son spam. Con sa-learn --ham <directorio> haremos todo lo contrario: instruiremos al programa en la recolección de correo que no es spam. Es necesario leerse las páginas del manual para ejecutar otras opciones, como la lectura de directorios por lotes. Como SpamAssassin será llamado por Amavisd-new, la ejecución de sa-learn preferiblemente tendrá que ser a través del usuario amavis. ClamAV Al igual que nos ocurría con SpamAssassin, la configuración por defecto de ClamAV es más que suficiente para el filtrado de virus sobre el servidor. En un sistema con Fedora Core y para nuestros propósitos, tendremos que asegurarnos de que el demonio clamd.amavisd se ejecuta correctamente al inicio del sistema. Ejecutaremos los comandos siguientes para conseguir nuestros propósitos: #chkconfig clamd.amavisd on De esta forma evitaremos el siguiente error registrado en /var/log/maillog : ClamAV-clamd av-scanner FAILED: El demonio freshclam-sleep, incluido con el paquete clamav-update será el encargado de actualizar el antivirus mediante cron. La configuración por defecto puede verse en /etc/cron.d/clamav-update. Si necesitamos realizar modificaciones a la configuración de freshclam, lo haremos desde el fichero /etc/freshclam.conf, aunque no es recomendable. Amavisd-new El fichero de configuración de Amavisd-new se encuentra en la ruta /etc/amavisd/amavisd.conf y tiene alrededor de quinientas líneas. Para nuestros propósitos solamente será necesario cambiar una decena de ellas. La idea para el procesamiento de los correos es la siguiente: Un correo se marca como spam o como contenedor no deseado (virus, archivos exe, etc.) y se deja llegar a su destino, lugar donde, a través de un filtro con Sieve, será redirigido hacia un contenedor que alojará todos estos correos. Periódicamente, el usuario revisará el contenedor en busca de falsos positivos y borrará el resto. En caso de encontrarnos con falsos positivos, instruiremos a SpamAssassin mediante la opción forget de sa-learn. Veamos ahora las líneas del fichero /etc/amavisd/amavisd.conf que hemos cambiado para adaptarlo a los propósitos de este manual: $mydomain = 'dominio.net'; Obviamente, el fichero final dependerá de las necesidades de cada administrador, siendo lo anterior un mero ejemplo que adapta unas necesidades concretas. En principio, los cambios más importantes a realizar son los siguientes:
Cuando hagamos algún cambio al fichero de Amavisd-new, habremos de reiniciar el servicio con /etc/init.d/amavisd restart y será bastante recomendable observar su carga en el fichero /var/log/maillog, donde veremos los módulos cargados y los posibles errores. Modificaciones en Postfix En primer lugar, añadiremos las líneas siguientes al fichero /etc/postfix/master.cf: # Amavisd-New filtrado Y al fichero /etc/postfix/main.cf le añadiremos la siguiente línea: #Amavisd-New Con estas modificaciones haremos que Postfix redirija el tráfico hacia el puerto de loopback de Amavisd-new, que procesará el mensaje y lo redigirá hacia el puerto 10025, donde hemos habilitado smtpd. Una vez hechas las modificaciones, reiniciaremos Postfix con /etc/init.d/postfix restart. Filtrado de correo sobre Postfix (anti-UCE) Vamos a habilitar una serie de mecanismos sobre el servidor Postfix que nos permitirán filtrar usos abusivos o malintencionados del mismo. Intentaremos denegar el uso del servidor a todo aquello que creamos que no ha sido solicitado. smtpd_helo_required = yes Tal y como hicimos anteriormente con SpamAssassin, las restricciones aquí mencionadas deberán ser ajustadas a las necesidades de cada servidor de correo. Expliquemos con algo de detalle qué se pretende con las líneas adjuntadas, teniendo en cuenta que el orden de las instrucciones es siempre relevante:
El fichero /etc/postfix/recipient_checks.pcre contendrá parámetros para revisar la sintaxis de las direcciones a revisar. Es necesario tener activado el soporte PCRE (Perl Compatible Regular Expressions) en Postfix para su correcto funcionemiento (por defecto en los sistemas con Fedora Core): # Soporte PCRE requerido en Postfix El contenido de /etc/postfix/helo_checks, cuyo cometido es comprobar que el comando HELO/EHLO no utilice ni nuestro dominio ni localhost al conectarse, será el siguiente: #Comprobaciones de HELO/EHLO Este y todos los ficheros de tipo hash, serán compilados, una vez escritos, con el comando postmap <fichero> , que creará la base de datos Berkeley DB correspondiente. En /etc/postfix/sender_checks se incluyen los remitentes a rechazar. Veamos un ejemplo: # A compilar con postmap ... El fichero /etc/postfix/client_checks contiene clientes no deseados. Un ejemplo válido sería el siguiente: # A compilar con postmap ... Lo mismo para /etc/postfix/client_checks.pcre : # Soporte PCRE requerido en Postfix Como hemos hecho hasta ahora, reiniciaremos Postfix para aplicar cualquier cambio con /etc/init.d/postfix restart. Comprobaciones finales Para comprobar el correcto funcionamiento de nuestros filtros de contenido, mandaremos dos mensajes de correo: uno con spam y otro con el virus de muestra EICAR. Para empezar, mandaremos, preferiblemente desde una cuenta ajena a nuestro dominio, un mensaje que contendrá lo siguiente en el cuerpo del mismo (el asunto es de libre elección y el destinatario, una cuenta del dominio): This is the GTUBE, the El correo, si hemos dejado en la configuración de Amavisd-new la línea $final_spam_destiny = D_PASS, se recibirá con el siguiente contenido en su cabecera (variando según los servidores y el gestor de correo utilizado): Return-Path: <
Esta dirección de correo electrónico está protegida contra los robots de spam, necesita tener Javascript activado para poder verla
> Observemos las líneas marcadas en azul, donde se puede comprobar cómo se ha modificado el asunto del mensaje, se le ha dado un valor de 1005.278 al análisis (contra un valor requerido de 6.31 para ser considerado spam), tiene un nivel de spam bastante largo (****) y se ha adjuntado la cabecera X-Spam-Flag: YES para orientar al gestor de correo sobre su naturaleza. Continuaremos con el envío de un archivo adjunto que contendrá la cadena de comprobación EICAR, una simulación de virus que probará la correcta configuración de ClamAV. Para el correcto funcionamiento de esta prueba, crearemos un archivo de texto plano con esta única línea en su interior: X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* Que guardaremos con el nombre probe_av.txt y adjuntaremos en un correo nuevo que se enviará a una cuenta de nuestro dominio. Como hemos configurado Amavisd-new con $final_virus_destiny = D_DISCARD, el mensaje nunca llegará a su destino. En vez de eso, quedará guardado en la ruta del parámetro $QUARANTINEDIR, que, en nuestro caso, será /var/virusmails, con el nombre virus-<cadenaID>. Atendamos al fichero /var/log/maillog para observar qué ha pasado cuando Amavisd-new ha terminado de procesar un mensaje con un virus en su interior: Apr 30 18:28:15 pegasus amavis[12544]: (12544-05) local delivery: <> -> <virus-quarantine>, mbx=/var/virusmails/virus-ijhiU5Tsb3nO Y observemos alguna de las cabeceras de ese mismo mensaje guardado en /var/virusmails: Return-Path: <> Como la prueba del funcionamiento de Sieve es bastante personal y depende de los contenedores creados para cada usuario, dejaremos que cada administrador haga las pruebas pertinentes o esperaremos al siguiente capítulo, donde configuraremos Squirrelmail y, entre otras cosas, el front-end avelsieve.
Sólo los usuarios registrados pueden escribir comentarios. Powered by AkoComment 2.0! |
| < Anterior | Siguiente > |
|---|
