Servidor de correo con Postfix+Dovecot+RainLoop+Mailman2 y auth LDAP para usuarios del AD DC [Debian 10] – PART II

ÍNDICE

La documentación abarcará lo siguiente:

1.Implementación de un servidor de correo con buzones.

1.1.Datos de interés.

1.2.Sincronización de tiempo.

1.3. Implementación y configuración de ESMTP Postfix.

1.3.1. Selección de cifrados.

1.3.2. Configurando Postfix.

1.3.3. Creando los archivos de controles para Postfix-LDAP.

1.3.4. Comprobando la integración con LDAP y mapeos de aliases.

1.4.Implementación y configuración de Dovecot.

1.4.1.Configurando Dovecot

1.4.2.Creando archivo de control para Dovecot-LDAP

1.4.3.Script “quota-warnings.sh”

2. Implementación del cliente de correo web

2.1. Instalación de RainLoop

2.2. Fortaleciendo la seguridad del cliente de correo web

2.3. Configuraciones desde la WebGUI de RainLoop

3. Clientes de correo externo

3.1. Outlook 2016

3.2. Outlook 2019

3.3. Thunderbird 78.8.0

4. Filtrado de correos

4.1. Filtrado de correos por categorías

4.2. Filtrado para el remitente y destinatario

4.3. Filtrado para encabezado, adjuntos y cuerpo del correo

5. Copias de Carbón Ocultas

6. Listas de distribución con Mailman 2

6.1. Configuración de Nginx para Mailman 2

6.2. Instalación y configuración de Mailman 2

6.3. Integración de Mailman 2 a Postfix

6.4. Creando otras listas en Mailman 2

7. Rotación de logs y envío de reportes

8. Comprobando la encriptación TLS

9. Iptables

 

1.2. Sincronización de tiempo

La mayoría de las veces los servidores desplegados usan la zona horaria UTC (Coordinated Universal Time) o lo que es lo mismo, el tiempo en los cero grados de longitud. Consistentemente al usar el UTC como zona horaria se reduce la confusión cuando nuestra infraestructura sufre cambios de horarios por las múltiples zonas horarias que pueda atravesar (horario de verano y horario normal de cada región).

Para la sincronización del tiempo se analizará la variante por “timesyncd”, el cual es un cliente para sincronizar el tiempo más ligero que ntpd y que es usado en los sistemas actuales. Primero desinstalamos otras soluciones para sincronización de tiempo, que no serán requeridas:

En este caso se usará como zona horaria la de America/Havana:

Habilitamos la sincronización por ntp:

Editar el fichero de configuración, no sin antes hacerle una salva:

Reiniciamos el servicio:

Verificamos que este sincronizado:

Debe devolver, algo como lo siguiente:

Vemos los logs del servicio:

Debe devolver, algo como lo siguiente:

Para obtener mas informacion de la sincronización con el servidor NTP, corremos el siguiente comando:

Debe devolver lo siguiente:

NOTA: Debe contarse con un servidor NTP funcional o al menos la dirección de uno que este disponible.

1.3. Implementación y configuración de ESMTP Postfix

Crear el archivo “/etc/mailname”, agregándole el dominio de correo:

Eliminando “sendmail”, “exim” y demás variantes de MTA:

Instalando Postfix, Dovecot, Sasl y paquetes asociados adicionales:

El proceso de instalación de Postfix, realiza una pregunta, a la cual debe seleccionar según el roll que tendrá su servidor:

• Sin configuración (Mantiene la configuración actual intacta).
• Sitio de internet (su servidor gestiona el correo entrante y saliente directamente desde internet).
• Internet con <> (Su servidor gestiona el correo entrante directamente desde internet o mediante fetchmail, el correo saliente mediante otro servidor de correo que actúa como smarthost).
• Local (Su servidor de correos solamente gestiona correos relacionados con su dominio, es decir a modo local).

Usted por el momento puede seleccionar la opción “Sitio de internet”, puesto que más adelante va a cambiar todo lo relacionado con el comportamiento de su servidor de correos mediante el archivo de configuración.

Posteriormente debe aparecer el nombre del dominio al que va a responder su servidor de correo, por ejemplo “empresa.midominio.cu”, el que usted debe confirmar.

Editando “/etc/default/saslauthd”:

Busque las coincidencias que aparecen a continuación y cámbielas como se representa en el fragmento siguiente:

Creando los archivos de control para “saslauthd”:

Agregando el usuario “postfix” al grupo “sasl”:

Reiniciando saslauthd:

Crear grupos y usuarios asociados a la integración con el AD DC:

Creando los certificados SSL:

Los certificados SSL que se generan a continuación se encuentran en función del FQDN del servidor en cuestión, donde al ejecutar los siguientes comandos relacionados con el certificado SSL usted debe cambiar el valor “empresa.midominio.cu” por el nombre de su dominio.

Al ejecutar el siguiente comando debe solicitar una clave, queda a su criterio cual usar, al escribir la contraseña y presionar la tecla “ENTER” le solicita que escriba nuevamente la contraseña a modo de verificación de la misma.

-Pide una contraseña: 123456
-Confirmamos la contraseña: 123456

Al ejecutar el siguiente comando le va a solicitar una contraseña la cual debe coincidir con la contraseña que utilizo en el comando anterior, además de una serie de datos los cuales van a estar contenidos en su certificado (SSL), como ejemplo se toma el FQDN perteneciente a los datos que se siguen en esta guía, “smtp”, y a continuación se representan las respuestas, las cuales usted debe adecuar según su red, si su servicio de correo cuenta con acceso desde una red WAN y una red LAN usted debe crear los certificados pertenecientes a cada una, en este ejemplo solo se lleva a cabo el certificado perteneciente a la red LAN, por las características de la red de este tutorial:

Debe devolver lo siguiente:

Al finalizar el proceso vuelve a solicitar una contraseña la cual debe coincidir con la contraseña que ha utilizado anteriormente en el proceso de generación del certificado, dicha contraseña al ser escrita se va a visualizar en texto plano en su consola, al presionar la tecla “ENTER” solicita el nombre de la compañía.

Posteriormente debe generar el certificado con la llave emisora, por 2 años en este ejemplo, donde al ejecutar el siguiente comando vuelve a solicitar la misma contraseña:

Cada vez que un servicio con un certificado SSL valla a ser iniciado, debería pedir una contraseña, para asegurar que el legítimo operador de servicio ha sido quien le ordenó la arrancada. Pero poner una contraseña cada vez que inicia Postfix, sería algo tedioso. Por tanto, la solución a esta problemática pudiera ser quitar la clave. Al ejecutar el siguiente comando debe solicitar nuevamente la clave, usted debe utilizar la misma contraseña que ha utilizado en todo el proceso de generación del certificado SSL:

Cambiamos el nombre de la llave recién generada:

Emitiendo una autoridad de raíz, donde nuevamente debe solicitar una contraseña y los mismos datos que anteriormente usted aportó:

Como podrá observar le solicita los mismos datos que usted aporto anteriormente, los cuales deben coincidir:

Asignando permisos y posicionando los certificados correctamente:

NOTA: Debe contarse con un servidor NTP funcional o al menos la dirección de uno que este disponible.

1.3.1. Selección de cifrados

Seleccionar una suite de cifrados puede ser todo un desafío en Postfix. Muchas consideraciones se han de tener en cuenta a la hora de tomar la decisión correcta. Algunas de ellas pudieran citarse, como son: las capacidades del servidor y el cliente, certificado de autoridad con requerida compatibilidad. La suite de cifrados debe ser lo suficientemente flexible con otros servidores, de lo contrario problemas de compatibilidad pudieran ocurrir. Si no se soporta en alguno de los extremos (cliente o servidor) ocurrirán errores durante el intercambio de llaves.

Para cumplir con los requerimientos establecidos al inicio del ejemplo, los autores de este tutorial tienen como requisito el uso de cifrados que sean AEAD o PFS (Perfect Frorward Secrecy). Se entiende por PFS, como la propiedad de los sistemas criptográficos que garantiza que el descubrimiento de las claves utilizadas actualmente no compromete la seguridad de las claves usadas con anterioridad (no las revela), por tanto, la seguridad de lo que se hizo usando claves antiguas persiste. Cuando un sistema tiene cifrados PFS se dice que el sistema es seguro hacia adelante.

Los cifrados que serán autorizados a usarse en “submission”, serán los siguientes:

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256

Los cifrados de TLSv1.3 siempre serán utilizados, mientras se soporte el protocolo y no se excluya su uso en la configuración. Lo que hay que lograr ahora, es que solamente se puedan usar para TLSv1.2 los especificados en la lista anterior. Esto lo podremos lograr redefiniendo la lista de cifrados “high” para TLS en Postfix, siempre y cuando especifiquemos el patrón que los diferencia. Con un poco de observación, podemos crear un filtro que nos de los cifrados ECDHE requeridos (los de TLSv1.3 no es necesario filtrarlos): ECDHE+AESGCM:-ECDSA:@STRENGTH

Para el caso de los cifrados aNULL, estos son usados para autenticación anónima en un canal encriptado. Al inicio del tutorial no había ningun requisito para usar los cifrados de autenticación anónima, pero haremos el procedimiento para obtener los mas seguros de TLSv1.2, ya que en TLSv1.3, todos son seguros.

Este tipo de cifrados es muy útil en conexiones “servidor-servidor”, donde no se quiera autenticar a un host definido como confiable, pero que tampoco se quiere que la comunicación entre ambos vaya a través de un canal inseguro. Es normal que la comunicación entre servidores MTA viaje a través de una red de transporte, que puede no pertenecer a la propia empresa, sino al proveedor de servicios o Internet. Por tanto, mejor usar un canal encriptado sin autenticación, que uno sin encriptar.

Los cifrados para auntenticacion anónima a utilizar, los obtendremos del siguiente comando:

La línea anterior indica a OpenSSL que se listen todos los cifrados que usan autenticación anónima (aNULL).

El comando nos devuelve una lista de cifrados, de los cuales nos quedamos con los mas fuertes de TLSv1.3 y los dos más seguros de TLSv1.2:

Si hubiésemos listado por la expresión ‘aNULL:@STRENGTH’ nos hubieses listado los cifrados mas fuertes sin tener en cuenta la versión del protoclo como una prioridad y no se cumplirían con algunas restricciones de nuestro servidor. O sea, aun cuando los siguientes cifrados son mas fuertes que uno de nuestros candidatos finales, quedan excluidos:

  • ADH-AES256-SHA256 (usa cifrado CBC, vulnerable).
  • AECDH-AES256-SHA (usa un protocolo TLSv1, no autorizado).
  • ADH-AES256-SHA (usa un protocolo SSLv3, no autorizado).
  • ADH-CAMELLIA256-SHA (usa un protocolo SSLv3, no autorizado).

Por tanto, para autenticación la anónima, estarán disponibles los siguientes cifrados:

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • ADH-AES256-GCM-SHA384
  • ADH-AES128-GCM-SHA256

La combinanción que buscamos para ser usada en Postfix, que sea la equivalente a los cifrados de arriba, sería: ADH+AESGCM:@STRENGTH

1.3.2. Configurando Postfix

Haciendo una copia del archivo de configuración de Postfix:

Creamos el fichero de configuración de mayor prioridad en Postfix:

Procuramos que las siguientes opciones se encuentren como se muestran, a continuación:

Agregue al final del archivo lo siguiente:

Haciendo una copia del archivo de configuración de Postfix:

Creando un nuevo archivo de configuración principal para Postfix:

Agregue el siguiente contenido adaptando, según sus datos de red:

Creamos el fichero “/etc/postfix/reglas/esmtp_access.cidr” para decidir a qué CIDR anunciar STARTTLS y otras opciones. Esto puede ser útil en caso de que el relayhost no esté en nuestras manos poder configurarlo y se trate de un servidor no actualizado a nuestros tiempos, que no soporta el protocolo mínimo de TLSv1.2, indicado por nuestro servidor y que al serle anunciado STARTTLS, intentará escalar a la conexión cifrada terminando en un error por imcomatabilidad de protocolos o cifrados.

Agregamos lo siguiente:

1.3.3. Creando los archivos de controles para Postfix-LDAP

Se crea el directorio que contendrá las configuraciones para los mapeos de usuarios virtuales de LDAP:

  • Mapeo de usuarios virtuales de correo:

Agregue el siguiente contenido adaptando a su red:

NOTA: Las consultas LDAP entre el servidor de correo y el AD DC no serán encriptadas, pues el servidor MTA se encuentra en la misma subred del AD DC y el tráfico broadcast de dicha red está separado del segmento de los usuarios. No existe posibilidad de un ataque MITM.

  • Mapeo de buzones virtuales de correo:

Agregue el siguiente contenido modificando lo que se encuentra resaltado en blanco, según sus datos de red:

  • Mapeo de alias para grupos del AD:

Se crea el directorio que contendrá las configuraciones para los mapeos de los aliases:

Editamos el siguiente fichero:

Agregue el siguiente contenido adaptando a su red:

  • Mapeo de alias personales o de correción de errores:

Ahora es necesario declarar el fichero que contendrá los alias de los usuarios virtuales, ya que “/etc/aliases” sólo funciona para usuarios locales:

En este caso, agregamos los siguientes ejemplos:

NOTA: Especificamos el dominio solo si se trata de una cuenta de correo de otro dominio.

Generamos el mapa del fichero:

Recargamos Postfix:

Chequear si Postfix tiene algún error en la configuración

NOTA: Omitir el siguiente WARNING:

1.3.4. Comprobando la integración con LDAP y mapeos de aliases

Verificamos los usuarios por defecto del DC:

Luego de especificar correctamente la contraseña, debe devolver los usuarios del contenedor “Users”.

Verificamos los usuarios del DC, que se encuentran en el OU=»Usuarios»:

Luego de especificar correctamente la contraseña, debe devolver los usuarios de la empresa, los de la unidad organizativa “Usuarios”.

Digamos que se tiene el siguiente caso:

  • Usuario de correo “[email protected]” con nombre usuario igual a la cuenta del dominio, que pertenece al grupo de “Redes” con dirección de correo propia “[email protected]” y forma parte de un alias de especifico para usuarios “[email protected]”.
  • Usuario de correo “[email protected]” con nombre de usuario distinto a la cuenta del dominio (usuario2.apellido), que pertenece al grupo de “Redes” y forma parte de un especifico para usuarios, que corrige el destino de los correos que se escriban a la dirección de correo, teniendo en cuenta su nombre de la cuenta del dominio y no del correo.
  • Usuario de correo “[email protected]” con nombre de usuario distinto a la cuenta del dominio (usuario3.apellido) y que también tiene un alias especifico para corregir errores.

Probando usuarios válidos para autenticación:

Debe devolver algo, como lo siguiente:

Probando el buzón de usuario:

Debe devolver algo, como lo siguiente:

La dirección física del buzon se encuentra en la siguiente ruta:

Probando alias para grupos del AD:

Debe devolver algo, como lo siguiente:

Probando alias personales:

Debe devolver algo, como lo siguiente:

Probando alias personales para grupos de usuarios que no son del dominio:

Debe devolver algo, como lo siguiente:

Si algún cliente SMTP remoto intenta iniciar una conexión con el servidor por el puerto 25, no podrá autenticarse en el mismo:

Hasta este punto se tiene implementado un servidor con soporte para SMTP y submission.

¿De cuánta utilidad te ha parecido este contenido?

¡Haz clic en una estrella para puntuar!

Promedio de puntuación 5 / 5. Recuento de votos: 1

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Ing. Telecomunicaciones y Electrónica; 1er Especialista en Redes de ECASA Nivel Central

4 comentarios

  1. Firefox 87.0 Firefox 87.0 Windows 10 x64 Edition Windows 10 x64 Edition
    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

    postmap -q [email protected] ldap:/etc/postfix/aliases/group_alias.cf

    Me devuelve:
    postmap: warning: dict_ldap_lookup: /etc/postfix/aliases/group_alias.cf: Search base ‘OU=Grupos,DC=empresa,DC=midominio,DC=cu’ not found: 32: No such object
    postmap: fatal: table ldap:/etc/postfix/aliases/group_alias.cf: query error: Success

    • Firefox 87.0 Firefox 87.0 Windows 10 x64 Edition Windows 10 x64 Edition
      Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

      Adapta a tu estructura LDAP, la que pones es la de mi ejemplo, mi dominio, mi estructura del arbol LDAP

      • Firefox 87.0 Firefox 87.0 Windows 10 x64 Edition Windows 10 x64 Edition
        Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

        Sï, lo adapté a mi estructura LDAP, lo que en el comentario lo reflejé con tu estructura, de todas formas seguiré probando. Saludos

  2. Firefox 89.0 Firefox 89.0 Mac OS X  10.12 Mac OS X 10.12
    Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:89.0) Gecko/20100101 Firefox/89.0

    Te felicito Franco, muy buen artículo y muy necesario, para nosotros los aprendices. Agradecido, una pequeña errata:

    Al inicio de 1.3.2. Configurando Postfix

    Dice cp /etc/postfix/main.cf{,.orig}
    Y en ese caso creo debe decir: cp /etc/postfix/master.cf{,.orig}
    Ya que es el archivo que a continuación editas.

    Al final de ese archivo (master.cf) dices debe añadirse la línea «flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}» pero a esa línea le fantan dos espacios delante, debe ser » flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}»

    En la viñeta · Mapeo de alias personales o de correción de errores:

    Dice: nano /etc/postfix/users_alias

    Debe decir: nano /etc/postfix/aliases/user_alias

    Si es posible arreglar y borrar este comentario.

    Y de nuevo, ¡¡¡¡MUY AGRADECIDO, MUY BUEN TUTO!!!!

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*