Solución Completa de Servidor de Correo con Dominios y Usuarios Virtuales (Debian Etch, Postfix, Mysql, Dovecot, DSpam, ClamAV, Postgrey, RBL) - Página 10

VII. Correo Electrónico Seguro

En un mundo ideal, nuestros usuarios podrían enviar/recibir correos electrónicos siempre que estuvieran en la red, desde cualquier lugar del mundo. Desafortunadamente, eso es increíblemente inseguro… las contraseñas se envían de un lado a otro en texto claro a través de los protocolos SMTP e IMAP, y eso significa que cualquiera que quiera podría simplemente ‘espiar’ la contraseña.

Si tus usuarios no necesitan acceso directo a la solución de correo, ¡entonces no se lo des! No tiene sentido estresarse por una configuración de correo electrónico seguro si todo lo que necesitan tus usuarios es Webmail. Simplemente haz que su conexión al servidor de webmail sea segura, y asegúrate de que el servidor de webmail use una conexión de red segura al comunicarse con tus servidores de correo. ¡Problema resuelto! Si, por otro lado, tus usuarios requieren la capacidad de enviar/recibir correo a través de internet sin usar webmail, bueno, eso solo hace que las cosas sean más difíciles. No imposibles, solo difíciles.

Así que, aquí está tu problema: SMTP e IMAP envían contraseñas en texto claro. Puedes hacer que envíen contraseñas usando MD5, pero el MD5 básico puede ser hackeado. Puedes hacer que envíen contraseñas usando MD5CRYPT, pero entonces estarás lidiando con múltiples implementaciones (sin mencionar el hecho de que no todos los clientes de correo admiten contraseñas MD5). ¿La solución? TLS (Seguridad de la Capa de Transporte). Vamos a configurar nuestra solución para soportar una conexión encriptada a través de internet. Aunque podríamos modificar algunos de nuestros servidores existentes para manejar esto, no tiene sentido complicar sus configuraciones. Simplemente vamos a ejecutar un servidor separado para manejar todo esto: secure-mail.example.com

NOTA: En el escenario original, la pequeña empresa tenía múltiples direcciones IP estáticas. Dado que este es el caso, pudimos ejecutar SMTP+TLS en el puerto 25, si no tienes múltiples direcciones IP, entonces eso no es posible. La razón es bastante simple: Mientras que IMAPS (IMAP seguro) ejecuta un puerto diferente (993) que el IMAP estándar (143), SMTP+TLS se ejecuta en el MISMO puerto que SMTP (25). Así que, usar un firewall para enrutar basado en puertos te permite ejecutar servidores IMAP e IMAPS separados, pero ningún firewall en el mundo puede enrutar el puerto 25 a dos máquinas diferentes. Aun con todo eso, siempre podrías ejecutar SMTP+TLS en un puerto no estándar… de hecho, sería aún más seguro.

Así que, con todo eso en mente, vamos a configurar un servidor de correo seguro, que utiliza SMTP+TLS para enviar correo, e IMAPS para recibirlo.

A. Certificados SSL

La forma más simple de encriptación es tener un certificado autofirmado simple en el servidor. Esto generará un mensaje de advertencia cuando los clientes se conecten por primera vez, pero deberían poder guardarlo para su uso posterior. No es realmente seguro, ya que cualquiera puede ejecutar un ataque de hombre en el medio si no guardas el certificado.

El siguiente nivel es usar un certificado de servidor firmado por una Autoridad de Certificación (CA), ya sea una comercial, o quizás la CA interna de la empresa. De esta manera, el certificado del servidor será de confianza, y si ahora recibes una advertencia, hay potencialmente algo malo sucediendo.

Por último, pero definitivamente no menos importante, es usar certificados de cliente para iniciar sesión en el servidor, y usar un certificado de servidor para autenticar el servidor a los clientes. Esto es bastante seguro, pero no es compatible con todos los clientes de correo. Thunderbird, entre otros, sí tiene soporte para ello.

1. Certificado de servidor autofirmado

Primero crea los directorios, crea la clave privada, y por último crea el certificado.

# mkdir -p /etc/ssl/example.com/mailserver/  
# cd /etc/ssl/example.com/mailserver/  
# openssl genrsa 1024 > mail-key.pem  
# chmod 400 mail-key.pem  
# openssl req -new -x509 -nodes -sha1 -days 365 -key mail-key.pem > mail-cert.pem

Ten en cuenta que “Nombre Común (por ejemplo, TU nombre)” DEBE coincidir con el nombre del servidor, que en este caso es secure-mail.example.com

2. Certificado Firmado por CA

Usar un certificado firmado por una CA real no es diferente de usar uno autofirmado. Es solo otro paso en la creación del par de claves. Si tu empresa tiene su propia CA, entonces deberían emitir un certificado para el servidor de correo. Una búsqueda en Google para ser tu propia CA te dará suficientes respuestas para crear uno tú mismo, si lo necesitas.