CONFIGURACIÓN DE UNA PLATAFORMA DE CORREO SEGURA

EN LINUX CENTOS 6.2

POR:

Anderson Herrera Duran

INSTRUCTOR A CARGO:

Mauricio Ortiz Morales

SENA

MEDELLÍN

INTRODUCCIÓN

En el trascurso de los años, el hombre ha sentido la necesidad de comunicarse, de ahí que la

humanidad haya desarrollado distintas formas de comunicación para poder llevar a cabo muchos

procesos de forma más rápida y sencilla. El correo electrónico es una herramienta con la cual

podemos comunicarnos y enviar y recibir archivos a grandes distancias, esto se hace por medio

de la red y sistemas de comunicación electrónica.

Para que ese proceso de comunicación se lleve a cabo son necesarios varios elementos que

intervienen en dicha comunicación; hacen parte del proceso de comunicación por correo

electrónico los siguientes elementos: MTA, MDA, MUA. (A continuación se explicaran estos

elementos).

CONCEPTOS CLAVE

MUA: (Mail User Agent, Agente de Usuario de Correo), es el sistema que se encarga de recibir y enviar emails usando los protocolos STMP (para el envío) y POP3 o IMAP (para la recepción). Ejemplos de MUA son evolution, kmail, squirrelmail (los webmails).

MTA: (Mail Transfer Agent, Agente de Transferencia de Correo), es el sistema que se encarga de distribuir y tomar el email de un MUA o de otro MTA y entregarlo a otro MTA o a un MDA, lo más común es que funcione integradamente con un DNS que cuente con un registro MX para poder intercambiar correo entre varios MTA. Ejemplos de MTA son postfix, qmail, cyrus.

MDA: (Mail Delivery Agent, Agente de Entrega de Correo), es el sistema que se encarga de la recepción del email por parte de un MTA, y lo almacena de la forma que tenga configurada, el MDA se encarga de gestionar los buzones de los usuarios. Los MDA pueden almacenar en disco, base de datos o llamar a otro programa para hacer el procesado de emails (ejemplo: listas de correo, sistemas de control de incidencias, etc.). Ejemplos de MDA son procmail, cyrus y dovecot; hay programas que son a la vez MTA y MDA.

DNS: sistema de nombres de dominio, es un servicio utilizado para resolver nombres de identificadores binarios (ip) esto con el propósito de poder localizar y direccionar de forma fácil estos equipos mundialmente.

Un registro MX o Mail Xchange record (registro de intercambio de correo) es un tipo de registro, un recurso DNS que especifica cómo debe ser encaminado un correo electrónico en internet. Los registros MX apuntan a los servidores a los cuales envían un correo electrónico, y a cuál de ellos debería ser enviado en primer lugar, por prioridad.

OpenLDAP es una implementación libre y de código abierto del protocolo Lightweight Directory Access Protocol (LDAP) desarrollada por el proyecto OpenLDAP.

Está liberada bajo su propia licencia OpenLDAP Public License. LDAP es un protocolo de comunicación independiente de la plataforma.

Muchas distribuciones GNU/Linux incluyen el software OpenLDAP para el soporte LDAP. Este software también corre en plataformas BSD, AIX, HP-UX, Mac OS X, Solaris, Microsoft Windows (NT y derivados, incluyendo 2000, XP, Vista), y z/OS.

Postfix es un servidor de correo de software libre / código abierto, un programa informático para el

enrutamiento y envío de correo electrónico, creado con la intención de que sea una alternativa

más rápida, fácil de administrar y segura al ampliamente utilizadoSendmail. Anteriormente

conocido como VMailer e IBM Secure Mailer, fue originalmente escrito por Wietse

Venema durante su estancia en el Thomas J. Watson Research Center de IBM, y continúa siendo

desarrollado activamente.

Postfix es el agente de transporte por omisión en diversas distribuciones de Linux y en las últimas

versiones del Mac OS X.

Dovecot es un servidor de IMAP y POP3 de código abierto para sistemas GNU/Linux / UNIX-like,

escrito fundamentalmente pensando en la seguridad. Desarrollado por Timo Sirainen, Dovecot fue

publicado por primera vez en julio del año 2002. Dovecot apunta fundamentalmente a ser un

servidor de correo de código abierto ligero, rápido, fácil de instalar y sobre todo seguro.

Transport Layer Security

Para otros usos de este término, véase TLS.

Secure Sockets Layer (SSL; en español «capa de conexión segura») y su sucesor Transport

Layer Security (TLS; en español «seguridad de la capa de transporte») son protocolos

criptográficos que proporcionan comunicaciones seguras por una red, comúnmente Internet.

SSL proporciona autenticación y privacidad de la información entre extremos

sobre Internet mediante el uso de criptografía. Habitualmente, sólo el servidor es autenticado (es

decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar.

SSL implica una serie de fases básicas:

Negociar entre las partes el algoritmo que se usará en la comunicación

Intercambio de claves públicas y autenticación basada en certificados digitales

Cifrado del tráfico basado en cifrado simétrico

SpamAssassin es un programa informático publicado bajo la licencia Apache 2.0 usa para correo

electrónico no deseadofiltrado basado en la coincidencia de contenidos reglas. Ahora es parte de

la Fundación Apache .

SpamAssassin utiliza una variedad de técnicas de detección de spam, que incluye DNS de

detección de spam basado en lógica difusa y la suma de comprobación basados, filtrado

bayesiano , programas externos, listas negras y bases de datos en línea.

El programa puede ser integrado con el servidor de correo de filtrar automáticamente todo el

correo para un sitio. También se puede ejecutar por los usuarios individuales en su propio buzón

y se integra con varios programas de correo .SpamAssassin es altamente configurable, si se

utiliza como un filtro de todo el sistema todavía puede ser configurado para soportar por las

preferencias del usuario.

En informática los antivirus son programas cuyo objetivo es detectar y/o eliminar virus

informáticos. Nacieron durante la década de 1980.

ClamAV es un software antivirus open source (de licencia GPL) para las

plataformas Windows, Linux y otros sistemas operativossemejantes a Unix.

El proyecto ClamAv Antivirus fue fundado en el año 2001 por Tomasz Kojm. Actualmente tiene

una implantación superior a los 500 000 servidores en todo el mundo. ClamAV nació como un

proyecto opensource que pretende identificar y bloquear virusen el sistema. El primer objetivo de

ClamAv fue combatir el correo electrónico malware. Como consecuencia de ello, ClamAv se está

usando en un número elevado de email servers.

Gracias a la colaboración de varias compañías, universidades y otras organizaciones le ha sido

posible al proyecto ClamAV poseer una red extensa de distribución mirror rápida y fiable en todo

el mundo.

Webmail

Un correo web es un cliente de correo electrónico, que provee una interfaz web por la que

acceder al correo electrónico. Otras formas de acceder al correo electrónico pueden ser:

Conectándose con un cliente de correo local a un servidor de correo remoto utilizando un

protocolo ad hoc de transporte de correo, como IMAP o POP, descargar los correos y

almacenarlos localmente.

Utilizando un cliente de correo por consola, por ejemplo Mutt.

El webmail permite listar, desplegar y borrar vía un navegador web los correos almacenados en el

servidor remoto. Los correos pueden ser consultados posteriormente desde otro computador

conectado a la misma red (por ejemplo Internet) y que disponga de un navegador web.

Cuota

Backend cuota especifica el método de cómo Dovecot sigue la pista del uso de la cuota actual. No (por lo general) especificar límites de cuotas de los usuarios, que se hace mediante la devolución de campos adicionales de userdb. Existen diferentes sistemas de apoyo cuotas que Dovecot puede utilizar:

fs : cuota del sistema de archivos.

dirsize : El backend cuota más simple y más lento, pero funciona bastante bien con mboxes.

dict : El uso de la tienda de cuotas en un diccionario (por ejemplo SQL).

maildir : El uso de la tienda de cuotas en Maildir + + archivos maildirsize. Esto es la cuota más comúnmente utilizado para los usuarios virtuales.

Habilitación de plugins de cuotas

Actualmente hay dos plugins para implementar cuotas:

cuota: implementa el manejo cuota real e incluye también todos los backends cuotas. imap_quota: Para presentar la información de cuota a través de IMAP.

La configuración del servidor de correo se hará usando como backend el ldap (openladap 2.4),

para poder tener acceso a los atributos relacionados con el correo se agregara el siguiente

esquema a la configuración del openldap.

Seguir este link para copiar el esquema:

http://mds.mandriva.org/svn/mmc-projects/mmc-core/trunk/agent/contrib/ldap/mail.schema

Editamos un archivo cualquiera el cual llevara los esquemas que incluiremos en el openldap, en

este caso el archivo se llama “misesquemas.conf”, lo podemos crear en cualquier parte (en este

caso se crea en el root).

Ahora se creará un directorio para alojar los esquemas LDIF.

Con el comando slaptest se crea la estructura en el directorio creado.

Con el comando tree verificaremos la estructura, primero se debe instalar el tree.

Hacemos un tree al directorio.

Ahora se copiará el archivo ldif relacionado con el mail a una ruta especifica (cualquier ruta, en

este caso se copia en el root).

Ediotamos el archivo d ela siguiente forma.

Al final del archivo se borran las últimas líneas dejandolo de la siguiente forma.

Ahora se agregara el archivo ldif editado a la estructura del ldap (se supone que el archivo debe

estar en el lugar desde donde estamos ejecutando el comando, si no es este el caso entonces se

debe especificar la ruta).

Como vemos al intertar agregarlo nos ha arrojado un error, el cual nos dice que hay un atributo

que se esta repitiendo, esto lo arreglaremos editando el archivo y buscando el atributo mailhost

que nos dice el error.

Ahora lo renommbraremos con un nombre diferente para que no halla problema.

Vemos que ya se ha agregado correctamente.

Con el comando tree podemos verificar que ya esta presente la estructura mail en el openldap.

Ahora se creara una nueva entrada (clic derecho – new entry), añadiendo los siguientes atributos.

Le damos un UID para crear un usuario, el cual sera un usuario de correo.

Llenamos los datos correspondientes, luego nos dirigimos a la parte superior y damos clic en

nuevo atributo.

Ahora agregaremos el atributo mailbox, el cual especifica el buzón de un usuario.

También se agregara el atributo mailenable, para saber si el correo esta activo o no.

Se llenan los campos de la siguiente forma.

Luego de agregar todos los atributos correcpondietes, el usuario quedará con los siguientes

atributos.

Lo siguiente será configurar la zona directa en el DNS, para que nuestro correo trabaje de la

mejor forma posible, en la configuración del Registro MX lo más aconsejable es que apunte a un

registro de tipo A que tenga como nombre “smtp”, también es lo mas adecuado configurarle

CNAMES que lleven por nombre “mail, imap, pop3”, esto según los protocolos que se vallan a

utilizar, en este caso se configurará el correo para que trabaje con el protocolo imap.

Para terminar la confiuración de las zonas del DNS, se debe configurar la inversa de la siguiente

forma.

Cabe aclarar que se debe confiurar el archivo principal del DNS “/etc/named.conf”, asociandolo

con las zonas directas e inversa, la configuracion del DNS esta disponible en mi blog en otras

publicaciones http://andersongestionredes.blogspot.com/, para que los cambios surtan efecto

debemos reiniciar el DNS, luego con el comando host seguido del dominio se comprobara si el

registro MX esta funcionando.

Ahora se procederá a instalar el servidor de correo, el MDA y MTA se instalaran por separado,

primero se instalará el MTA, en este caso e el postfix, si no esta instalado se puede instalar con el

comando yum, ene ste caso ya esta instalado en su versión 2.6, luego con el comando rpm –qc

se pueden identificar los archivos de configuración del postfix.

Ahora se configurara el archivo principal del postfix “main.cf”, de la siguiente forma.

En esta parte debemos comentar las interfaces locales, y des comentar el “all”.

La línea de mydestination puede estar des comentada por el momento, pero lo mejor sería

comentarla de una vez.

Agregamos las redes presentes en el servidor.

Para la gestión del buzón, se eligió el Maildir, puesto a que tiene mas ventajas que el formato

Mailbox.

Con el comando alternatives, vamos a ver si el postfix se encuentra como MTA.

También verificaremos que el postfix es el servidor MTA que se esta utilizando.

Miraremos si el puerto por el cual el postfix se relaciona con otros archivos esta abierto.

Ahora enviaremos un correo de prueba con el mandato mail, el cual viene instalado por defecto a

un usuario local del sistema, en este caso usuario sena.

Miraremos los logs del correo para ver como se realiza la entrega y si tuvo éxito, al final se

muestra que el correo fue enviado y entregado a su destino.

Ahora revisare el correo desde el usuario sena.

En el archivo main.cf, se comentará siguiente la línea.

Al final del archivo main.cf agregaremos las sentencias virtuales, las cuales nos conectarán los

usuarios del ldap con el postfix.

Se creará un usuario el cual manejara todos los enlaces virtuales entre el postfix y el ldap,,

añadiéndolo a un directorio.

Se debe crear un archivo en el directorio del postfix “/etc/postfix” el cual indique como debe

buscar el postfix a los usuarios del ldap.

Reiniciamos el servicio postfix para que los cambios surtan efecto, luego con el comando

postmap agregaremos los usuarios a la configuración virtual, luego de ejecutar el comando

postmap, se debe mostrar el directorio de dicho usuario, si no se muestra es porque algo anda

mal, como en este caso que no se mostro.

Ahora miraremos que aún no se pueden enviar correos, puesto a que hay un problema.

Como con anterioridad se tiene configurada una acl para el openldap, esta acl esta denegando

que el postfix tenga acceso a algunos atributos que se necesitan para poder verificar y crear el

directorio a los usuarios, agregaremos estos atributos a una acl que permita leerlos.

Luego reiniciamos el servidor ldap.

Con el comando “postconf –n” podemos ver toda la configuración actual del postfix.

Ahora volveremos a integrar un usuario con el comando postmap, en este caso se puede ver que

ya esta bien configurado, puesto a que nos muestra el directorio.

Enviaremos un mensaje para ver que todo este bien, y como se puede observar el mensaje fue

enviado y entregado a su destino.

Con el comando tree podemos verificar los nuevos correos, además s epuede ver que existen

tres directorios (cur, new, tmp), los cuales hacen parte de la estructura del buzón Maildir.

Ahora se instalara el agente MDA, en este caso se eligió el dovecot, si no esta instalado se puede

instalar con el comando yum, se puede ver que ya esta instalado en su versión 2.0.9.

Ahora se configurara el archivo principal del dovecot, el cual esta en la ruta “/etc/dovecot/”, por el

momento se incluirán los protocolos imap y pop3.

En esta versión del dovecot, existe un directorio el cual contiene varios archivos, que hacen parte

esencial de la configuración del dovecot y que se dividen en varios temas, tales como protocolos,

autenticación, cuotas, entre otros.

Nos dirigiremos al directorio “/etc/dovecot/conf.d/”, allí editaremos el archivo referente al mail, y

daremos la ubicación del directorio virtual de los usuarios del ldap.

También pondremos la identificación del usuario y grupo que manejara las cuentas virtuales, lo

cual había sido creado con anterioridad.

Ahora en el archivo de autenticación, se configurara para que trabaje con el LDAP.

Se comentara la línea de autenticación local, y se des comentará la línea de autenticación con el

LDAP.

Lo siguiente será buscar el archivo de ejemplo que el dovecot trae por defecto para conectar el

LDAP con el dovecot, luego lo copiaremos teniendo en cuenta que el nombre debe ser el mismo

que se incluyo anteriormente en el archivo de autenticación.

Se editara el archivo del LDAP, poniendo la IP ó nombre del host que va a utilizar, en este caso

como todo está en la misma máquina será la dirección de loopback, también se puede dar un

nombre (FQDN), si es que lo tenemos configurado.

No se utilizará la SASL bind, puesto a que no esta configurada en el LDAP.

No se utilizará tampoco TLS.

La autenticación bind tampoco se habilitará.

Daremos la base, en la cual se realizarán las consultas que requiera el dovecot en el LDAP, junto

con la versión del protocolo LDAP.

Le diremos que la búsqueda se hará en todas las ramificaciones.

Se configurará para que use atributos del LDAP, para realizar consultas, por el momento se

dejará en blanco, luego esta línea será de mucha importancia para configuración de cuotas.

Se utilizará un filtrado para que realice de la mejor manera las búsquedas de los usuarios en el

LDAP que tengan habilitada la estructura para utilizar el correo.

Se especificará como será la autenticación para utilizar el correo.

Se utilizará un filtrado para tener acceso a los usuarios de correo en el LDAP.

Se reinicia el servicio dovecot, y miramos si el servicio telnet está instalado en el sistema.

NOTA: Para que los servicios postfix y dovecot permanezcan encendidos aún cuando el sistema

se reinicie, lo que se hará será ejecutar el comando chkconfig de la siguiente forma:

“chkconfig postfix on”, ó si se quiere tenerlo prendido por niveles utilizamos “chkconfig --

level 23456 postfix on”.

“chkconfig dovecot on”, ó si se quiere tenerlo prendido por niveles utilizamos “chkconfig --

level 23456 dovecot on”.

Los niveles se pueden poner de acuerdo con el requerimiento que se necesite.

Se agregará el atributo userpassword a la acl configurada previamente en el openldap, puesto

que si no se agrega, no será posible autenticar los usuarios con los protocolos imap y pop3 a

través del telnet.

Para probar que el protocolo pop3, este funcionando, accederemos a el via telnet, nos

loguearemos con un usuario del ldap que tenga el correo habilitado, y procederemos a realizar

tareas básicas desde dicho usuario.

En la imagen se muestran los comando básicos para el protocolo pop3

Se procederá a hacer lo mismo con el protocolo imap, el cual trabaja por el puerto 143

En la imagen se muestran los comandos básicos para el imap, es importante poner un

identificador inicial, tal como se hace en la imagen con una letra y números (A001, A002, A003,

…).

INSTALACIÓN MUA

En los sistemas operativos Linux, se cuenta con varias opciones de agentes MUA, tales como son

e thunderbir, kmail, gnome entre otros, en la siguiente imagen se muestra como instalar el

thunderbird, el thunderbird también se puede instalar en sistemas Windows.

Luego de instalado, lo buscaremos en la siguiente ruta.

Ahora se configurará para trabajar con los protocolos IMAP y SMTP.

S configurará en esta ocasión de forma manual, puesto que las configuraciones aún no son aptas

para hacerlas de forma automática.

Se redactará y se enviará un mensaje para probar que si este funcionando de forma correcta.

Escribimos el asunto y el cuerpo del mensaje y lo enviamos.

Ahora se revisara el correo para ver si ha llegado.

GRUPOS DE DISTRIBUCIÓN

Los grupos de distribución o listas de distribución sirven para mandar correos a un grupo

determinado de usuarios por medio una sola dirección de correo, esto hace que ahorremos

procedimientos innecesarios para enviar un correo a varias personas.

En plataformas de correo que utilicen como backend el LDAP, se debe crear una estructura que

contenga este tipo de atributos para grupos de distribución, sabiendo esto se procederá a crear

un grupo de distribución.

Nos dirigiremos a la administración gráfica del openldap, con el apache Directory studio,

crearemos una nueva entrada.

Se agregarán los esquemas mostrados en la imagen.

El RDN de identificación debe ser mail, y damos una dirección de correo el cual identificará la lista

de correo.

Luego de que se a agregado la lista, se procederá a agregar los usuarios que pertenecerán a ella,

esto se hace con el atributo maildrop.

Luego en el archivo principal del postfix, se hará un mapeo virtual, hacia donde esta la conexión

con las listas o grupos del ldap.

Se debe crear un archivo en el directorio principal del postfix (“/etc/postfix/”), el cual en su

contenido debe saber como realizar las búsquedas necesarias.

Ahora se agregará en la acl configurada anteriormente en el openldap, el atributo maildrop, para

que pueda ser leído.

Con el comando postmap, se realiza la comprobación de que el directorio existe, y si no es así se

crea automáticamente.

Se puede observar en la imagen los usuarios que pertenecen al grupo.

Se realizará una prueba para comprobar que si funcionan las listas.

Vemos que a los usuarios que pertenecen a la lista les ha llegado el mensaje.

WEBMAIL

El webmail, nos permite acceder por medio de un explorador de internet a nuestro correo

electrónico, y por ende acceder al buzón.

En esta parte se mostrará como instalar squirremail, el cual es un webmail muy tradicional pero

que es muy completo.

Lo descargamos desde la página oficial, se descomprime (si es tar.gztar zxvf, si es

.zipunzip), luego nos dirigimos al archivo de configuración, y allí ejecutamos el script “conf.pl”.

Se despliega un menú de opciones, tecleamos la opción 2.

Luego digitamos opción 1, damos el nombre del dominio, previamente configurado en el DNS.

Luego damos “s” para salvar los cambios.

“r” para volver al menú principal.

Digitamos la opción 6, para cambiar el modo en que se conectará con un backend.

Opcion 1, para el modo servidor LDAP, luego tecleamos “?” para saber que debemos hacer,

luego damos “+” para agregar un host.

A continuación se muestra como agregar un host.

Luego salvamos la configuración dando “s”.

Por último salimos del asistente.

Ahora se deben crear una carpetas y cambiarle los permisos para que el webmail pueda

funcionar de forma correcta.

Ahora podemos acceder vía web, con cualquier usuario de correo del openldap.

Enviaremos un correo de prueba para ver si todo anda bien.

Vemos que ha llegado al usuario destinatario.

TLS/SASL

Para configurar autenticación el cifrado del canal, una de las mejores opciones es configurar tlsv1

(s lo mismo que sslv3) con el sasl, en las siguientes imágenes podemos ver como es una

comunicación de correo sin el cifrado ni la autenticación.

Con el capturador de paquetes Wireshark se puede ver que toda la información esta visible.

Haciendo una conexón telnet por el puerto del imap (143).

Se puede ver que la información de los usuarios es totalmente vulnerable.

Sabiendo que el canal debe asegurarse, se procederá primero que todo a leer el manual del

SASL.

En este manual se explica como debe ser la configuración, y que servicios interactúan con el

SASL.

Luego de visto el manual, procedemos a prender los servicios saslauthd, y como dicen allí

encender estos servicios en los niveles 345.

Miraremos que el sistema tenga instalados los paquetes necesarios para SASL.

Se harán las excepciones, o se deshabilitará el firewall.

Iremos a la ruta “/etc/pki/tls/”, allí se creará una firma digital DSA de 1024 octetos, lo cual es

compatible con el postfix y con el dovecot.

A partir del archivo creado anteriormente, se creará una llave con algoritmo DSA, y estructura

x509 con su correspondiente certificado, se establecerá una validez por tres años (1095 días)

para el certificado, luego se debe dar la información necesaria para crear dicho certificado.

Luego de que se crea el certificado, se puede proceder a borrar el archivo DSA, luego se

comprueba que los certificados se encuentren en sus respectivas rutas.

Se dará, solo permisos de lectura para el usuario root de los certificados.

Durante la instalación se crean unos certificados de prueba, esto hace que sea inseguro el

dovecot, por lo cual procedemos a borrar estos certificados.

Para la creación de la firma digital y el certificado para dovecot se requiere utilizar algoritmo RSA

de 1024 octetos con estructura x509.

Se cambian los permisos a solo lectura.

Para unir completamente el dovecot con el postfix para poder realizar la autenticación con los

certificados TLS y con SASL, la única forma en la que se integran servicios al postfix es por medio

del master.cf, por lo cual lo debemos agregar en el master.cf, se debe tener muy en cuenta que

este archivo es muy sensible con espacios y sentencias, por lo que se deberá tener la mayor

precisión posible con este archivo.

Se procede a descomentar las líneas de TLS y SASL.

El usuario y grupo con el cual se relacionará el postfix es el vmails, si anteriormente se creó el

usuario vmail entonces se pone el usuario vmail, se debe poner el mismo usuario creado

anteriormente.

Al final del archivo principal del postfix (main.cf), se agregan las líneas correspondientes al TLS y

SASL.

A continuación para más seguridad en el sistema, se cambiará la forma en que se distribuyen los

correos de los usuarios, a parir de un usuario sin privilegios.

Se pone cualquier usuario sin privilegios en la persona que recibe los correos.

Por último se ejecuta el comando postalias para generar la base de datos “/etc/aliases.db” que

será utilizada por el postfix.

Ahora en el archivo relacionado con ssl del dovecot se realizarán los siguientes cambios, y se

comprobarán la existencia de los certificados.

Reiniciamos el servicio sasl, el postfix y dovecot, luego se configuran con el comando chkconfig

para encenderlos en los niveles 2345.

Para realizar la prueba de que la autentcación este funcionando, haremos un elnet con el

protocolo SMTP (puerto 25), luego con el mandato “EHLO”, se verán las nuevas funciones

agregadas, entre ellas soporte para STARTTLS, si luego se ejecuta STARTTLS, se podrá

observar que ya existe autenticación.

Mirando los logs del mail, se puede ver como esta activado el TLS.

Ahora se probará la autenticación desde un gestor MUA, en este caso desde el Evolution.

A continuación se muestra paso a paso la configuración del Evolution.

Se da una cuenta de correo configurada en el ldap.

Prefiero utilizar el protocolo IMAP para recibir correo, además ya puedo usarla conexión segura

con cifrado TLS.

Para el envío de correo se utiliza el protocolo SMTP, y utilizo encripcion TLS, el tipo de

autenticación será plain.

Luego de terminada la configuración, accederemos a la interfaz del Evolution, nos arroja una

alerta con respecto que si aceptaremos los certificados, le daremos en OK.

Damos la contraseña del usuario, le decimos que nos recuerde y aceptamos.

Enviaremos un mensaje desde el thunderbird para ver como se esta cifrando y asegurando el

canal.

Agregamos la contraseña y decimos que nos recuerde, esto pasa porque hemos configurado la

enciptación.

Vemos que ha llegado.

En los logs del mail, podemos ver como interactúa el SASL.

Ahora se configurará el thunderbird para que actué con cifrado y autenticación, de igual forma ya

se podrán configurar cuentas para que detecte la configuración de forma automática.

En la configuración del servidor de salda también se procede a realizar la configuración.

Nos arroja la ventana para añadir el certificado de seguridad, le decimos que confirme la

excepción.

Ahora se enviará un mensaje para probar la configuración.

Se confirma la excepción de seguridad.

A través del Wireshark se capturan los paquetes para verificar que la comunicación sea cifrada, y

que el canal este asegurado.

A continuación explicare como es la comunicación a través de tlsv1.

Funcionamiento tlsv1 (sslv3): El protocolo SSL intercambia registros; opcionalmente, cada

registro puede ser comprimido, cifrado y empaquetado con un código de autenticación del

mensaje (MAC). Cada registro tiene un campo de content_type que especifica el protocolo de

nivel superior que se está usando.

Cuando se inicia la conexión, el nivel de registro encapsula otro protocolo, el

protocolo handshake, que tiene el content_type 22.

El cliente envía y recibe varias estructuras handshake:

Envía un mensaje ClientHello especificando una lista de conjunto de cifrados, métodos de

compresión y la versión del protocolo SSL más alta permitida. Éste también envía bytes

aleatorios que serán usados más tarde (llamados Challenge de Cliente o Reto). Además

puede incluir el identificador de la sesión.

Después, recibe un registro ServerHello, en el que el servidor elige los parámetros de

conexión a partir de las opciones ofertadas con anterioridad por el cliente.

Cuando los parámetros de la conexión son conocidos, cliente y servidor intercambian

certificados (dependiendo de las claves públicas de cifrado seleccionadas). Estos certificados

son actualmente X.509, pero hay también un borrador especificando el uso de certificados

basados en OpenPGP1 .

Cliente y servidor negocian una clave secreta (simétrica) común llamada master secret,

posiblemente usando el resultado de un intercambio Diffie-Hellman, o simplemente cifrando

una clave secreta con una clave pública que es descifrada con la clave privada de cada uno.

Todos los datos de claves restantes son derivados a partir de este master secret (y los valores

aleatorios generados en el cliente y el servidor), que son pasados a través

una función pseudoaleatoria cuidadosamente elegida.

Revisaremos un paquete tls, para ver la información que contiene.

Se puede observar que el mandato que ejecuta es “EHLO”, y que lego se establece el cifrado

STARTTLS.

Vemos que ya ha llegado el correo que se había enviado anteriormente.

Mirando los logs del mail, se puede observar que la comunicación ahora incluye STARTTLS.

CUOTAS

Configuración de cuotas básicas de almacenamiento en el MDA (dovecot 2.0)

Primero iremos al archivo “/etc/dovecot/conf.d/20-pop3.conf”, y allí agregaremos el plugin de

cuota.

En el archivo “/etc/dovecot/conf.d/20-imap.conf”, agregaremos el plugin de cuota.

En el archivo “/etc/dovecot/conf.d/15-lda.conf”, agregaremos la dirección del postmaster, puede

ser cualquier dirección de correo que deseemos.

En este mismo archivo agregaremos el parche para el envío de correos, se debe verificar que la

ruta exista.

Por último en el archivo “/etc/dovecot/conf.d/90-quota.conf”, se agregaran las reglas de

almacenamiento.

En este mismo archivo se deben descomentar las líneas las cuales son los plugin para las cuotas

del tamaño del directorio para el usuario y del maildir para el usuario, en este caso usare os dos

tipos de plugin, se recomienda usar el plugin maildir.

Por ultimo iremos a nuestro cliente MUA, en este caso es el thunderbird, vamos a cualquier

carpeta del correo del usuario, damos clic derecho, propiedades.

Elegimos cuotas, y vemos que la cantidad de espacio de almacenamiento que se tiene es igual a

la cantidad de espacio que se definió en el archivo de quotas.

NOTA: No es aconsejable darle tan poco espacio a los usuarios de correo, en este caso se hizo

con 20M de espacio de almacenamiento solo por cuestiones educativas de prueba.

CONFIGURACIÓN DE QUOTAS CON OPENLDAP 2.4 Y DOVECOT 2.0.9

Para una configuración mas avanzada de las cuotas, se integrarán las cuotas del correo para que

funcionen por medio del openldap.

Primero iremos al archivo principal de las cuotas, allí se agregaran las reglas para las quotas.

Se utilizará el plugin maildir.

Para que las reglas y cuotas funcionen perfectamente, se debe configurar el agente LDA, el cual

ayuda a entregar localmente el correo, para más información sigue este link

http://wiki.dovecot.org/LDA.

Se debe agregar el plugin para que utilice las cuotas, además agregaré otras líneas que pueden

ayudar a la gestión de los buzones.

En el archivo master del dovecot, agregare el servicio de autenticación a través del usuario vmails

el cual se creó con anterioridad, esto para que sea mas segura y rápida la plataforma.

En el archivo mail, se agregará la ubicación del buzón (mailbox).

Se debe agregar el plugin para utilizar cuotas.

En los demás protocolos IMAP, POP3, LMTP también se debe habilitar el plugin para utilizar

cuotas, esto según el protocolo que se valla a utilizar, en este caso se configurarán los tres

protocolos de una ves.

Ahora en el archivo principal del dovecot, habilitaré los tres protocolos, esto para que la

plataforma sea mas robusta y rápida, puesto a que el protocolo LMTP, ayuda a la entrega local

cuando hay muchos correos en cola.

Verificamos que en directorio “/conf.d” este incluido para la configuración del dovecot.

Ahora en el archivo que conecta el dovecot con el openldap, se habilitará la autenticación bind

(LDAP).

Ahora se agregará lo mas importante para la conexión con el ldap, lo cual son los atributos

(user_attrs), que se usaran para la conexión, y además en la misma línea se especificará como

se usará la cuota, este caso se utilizará el plugin quota, y la cuota será establecida en MB.

Por medio del apache directory studio, podemos agregar el atributo “mailuserquota” (la estructura

desde un principio agregada contiene este atributo).

Le daremos 35 MB de cuota para este usuario.

Ahora desde el thunderbird verificamos la cuota, desde las propiedades de cualquier carpeta del

usuario, y vemos que la cuota es la asignada desde el openldap.

A partir de la imagen se puede intuir que los mensajes enviados son ignorados, esto se debe a la

configuración anterior de las reglas de quota, en esta configuración solo se tiene en cuenta el

espacio en la bandeja de entrada de cada usuario.

INSTALACIÓN WEBMAIL (ROUNDCUBE 0.8.2) EN CENTOS 6.2

Para tener un mejor acceso vía web, a continuación mostraré como instalar el webmail roundcube

en su última versión, y el cual es gratuito.

Instalaremos dependencias que son necesarias para el óptimo funcionamiento de roundcube.

Desde la web oficial descargamos el paquete.

Copiamos el paquete al directorio principal del servidor web, luego se descomprime.

Lo renombraremos para que sea más fácil de identificar.

Cmbiamos el usuario y grupo propietario y también los permisos de algunos archivos y carpetas.

Ahora se utilizará como backen del webmail mysql, si mysql no esta instalado se debe instalar,

luego accedeos a mysql y creamos la base de datos para roundcube, además se creará un

usuario y se le otorgarán los permisos necesarios para la base de datos.

Con el siguiente comando se inicializará la base de datos, esto se hace cuando algunas veces no

tenemos conectividad con la base de datos.

Agregamos un nombre, en este caso un CNAME, para acceder al roundcube.

Se debe reiniciar el DNS para que tome los cambios.

Hacemos las priebas necesarias para ver si hay conectividad con el host agregado.

Ahora se debe crear el host virtual que nos conectará con el directorio principal de roundcube.

Se debe reiniciar el servidor web para que tome los cambios.

Nos debemos dirigir a la ruta “/var/www/html/roundcube/config”, allí copiaremos o renobraremos

los archivos de ejemplo a los siguientes nombres: “main.inc.php – db.inc.php”.

Ahora le cambiaremos de usuario y grupo propietario, para que sea el apache el dueño de estos.

Ahora en el archivo correspondiente a la base de datos, se debe dar la innformacion de la base

de datos, usuario y contraseña.

Ahora ya podremos acceder vía web al correo de un usuario anteriormente configurado en el

LDAP para utilizar correo.

Podemos ver que la interfaz gráfica es muy amigable, para cambiar el idioma daremos clic en

configuración.

Elegimos “user interface”.

Seleccionamos las opciones correcpondientes y salvamos la configuración.

Enviaremos un correo a otro usuario para ver que el webmail este funcionando correctamente.

Vemos que el correo ha llegado.

Y con esto quedo lista nuestra plataforma web mail, si lo que se quiere es que la plataforma web

mail soporte trabajo colaborativo, calendario, agenta entre otras aplicaciones, pueden instalar la

plataforma egroupware, aunque hay muchas otras mas, pero yo recomiendo esta plataforma

puesto a que es muy completa y estable, la instalación la pueden encontrar en mi blog

http://andersongestionredes.blogspot.com/.

ANTISPAM CON SPAMASSASSIN

Para asegurar nuestro correo con un fitro antispam, se optó por utilizar spamassassin

Lo que primero se debe hacer es leer el manual.

A continuación se comprobará si ya esta instalado en el sistema, si no es así se debe instalar.

Con el comando which veremos cual es el nombre del servicio y que su directorio, luego se

procederá a reiniciar el servicio, con el comando chkconfig, podremos encender el servicio

también.

Una vez iniciado el servicio spamassassin vemos en los logs del mail, que el servicio antispam

esta cargando.

En los archivos local.cf del spamassassin, se encuentran algunos mandatos que hacen parte

esencial de la configuración de este servicio.

El archivo local.cf que se encuentra en la ruta “/etc/mail/spamassassin/local.cf”, es el que contiene

lo relacionado sobre como se va a filtrar el spam.

Cuando se hace un cambio en un archivo se debe reiniciar el servicio.

A continuación se meustra como crear un usuario cualquiera el cual será el encargado de la

gestión del spamassassin.

En el archivo master.cf del postfix se debe integrar el servicio antispam de la siguiente forma.

En la parte inferior del archivo master.cf, se incluirán las líneas que permitiran al spamassassin

manejar el correo por medio del usuario creado y luego reenviarselo al postfix.

NOTA: Nose puede utilizar un usuario que se este utilizando para otra función en el master.cf

para manejar un servicio.

Luego de esto reiniciamos el postfix.

A continuación se descargará un spam, y luego se enviara al antispam, lo que debera efectuar

que lo identifique como spam el servicio spamassassin.

Mirando los logs del mail, se puede como el spamassassin identifica el spam.

Ahora que el antispam esta configurado, iremos al gestor MUA thunderbird y lo configuraremos

para que trabaje junto con el spamassassin.

En el archivo local.cf ubicado en “/etc/mail/spamassassin/local.cf”, se configura el puntaje (hits) el

cual nos indicará como se debe procesra un spam luego de ser identificado, hasta el puntaje 5 se

procesa y se envia como spam, pero si damos un puntaje mas alto el correo que se identifique

como spam puede ser eliminado automáticamente.

En este archvio también se configuran las reglas para el filtro de palabras que deseamos incluir

como spam, la estructura debe ser tal y como se muestra en la imagen.

También se pueden agregar bayes en este archivo para agregar mas funciones de comprobación

antispam al sistema:

use_bayes 1 bayes_auto_learn 1

Luego de realizar los cambios se debe reiniciar el servicio para que pueda tomar dichoes

cambios.

Ahora se enviará un correo que contiene palabras configuradas como spam anteriormente para

probar la configuración.

Vemos que el correo ha sido entregado, y se ha recibido como correo no deseado.

Mirando los logs del mail, se puede observar que detecto 2 de los nombres de las reglas que se

configurarron en el archivo local.cf.

ANTIVIRUS

Para la configuración del antivirus se eligió utilizar clamav, procedemos a instalarlo de la siguiente

forma.

Miramos donde se encuentran los principales archivos de configuración del clamav.

En el archivo principal del clamav, procedemos a especificar el puerto por el cual va a escuchar, y

el cual se integrará con el postfix, por defecto viene el puerto 10025, el cual hace alución al puerto

25 del protocolo SMTP, lo que hace que sea más identificable, verificamos tambien que el puerto

de escucha este configurado correctamente “OutAddress”.

Ahora iremos al archivo principal del postfix, y agregaremos las líneas que mapearan y nos diran

como se debe escanear el correo.

Utilizamos el comando freshclam para actualizar el antivirus.

Si queremos que el antivirus se actualice una vez al día ejecutamos: crontab –e

Para analizar e inyectar el correo una vez escaneado de nuevo al postfix añadimos las siguientes

lineas al inicio del archivo master.cf del postfix.

Ahora se deben iniciar los tres daemons que maneja el servicio antivirus.

Con el comando chkconfig se aconceja encender los tres servicios.

Luego reiniciamos el servicio postfix.

Desde la siguiente página http://www.eicar.org/85-0-Download.html se puede descargar un viruas

d epreba, aconcejo descargar el que tiene extensión txt.

Luego enviaremos un correo con el virus adjunto para probar el antivirus.

Mirando los logs del mail, podemos ver como el antivirus detecta la amenaza, luego lo remueve, y

por ende el correo no se envía.

Podemos observar qu e el correo no ha llegado, puesto que contenia un virus.

CONCLUSIONES

Las plataformas de correo son muy útiles para cualquier sector en el que se deseen implementar,

por este motivo se deben implementar con la rubostocidad y seguridad mas alta posibles, para

que de esta forma los mensajes viajen de forma segura y sin ningun inconveniente por la red.

A la hora de configurar un MTA, lo más conveniente y aconsejable es asociarlo con un registro

MX previamente configurado en el DNS que se este utilizando, para que de esta forma no surjan

inconvenientes a la hora de enviar o recibir correos a otros dominios.

CIBERGRAFIA

www.alcancelibre.org

https://informatica.iessanclemente.net/manuais/index.php/Instalaci%C3%B3n_y_administraci%C3

%B3n_de_Servicio_de_Correo_Electr%C3%B3nico_en_Debian

También se tomaron como apoyo los documentos otorgados por la plataforma cursos.redsena.net