El servicio de correo electrónico en el CIFP Tartanga LHII se realiza mediante la suite de colaboración Zimbra. En el instituto entendemos que el uso de esta solución open source aporta una serie de ventajas indiscutibles, como son las siguientes:
- Plena integración con Active Directory: el nombre de usuario y contraseña que los usuarios deben introducir para acceder al cliente web de correo electrónico se validan contra el Active Directory en el controlador de dominio del instituto. Por lo tanto y al igual que sucede con la mayoría de las aplicaciones del instituto, los usuarios no se ven obligados a utilizar nombres de usuario y contraseñas distintos para cada aplicación.
- Control total por parte de la organización del servicio de correo electrónico: la organización crea las cuentas y listas del correo con total flexibilidad, realiza las copias de seguridad de todos los buzones de correo y, en cualquier momento, es capaz de recuperar o restaurar para cualquier usuario, correos electrónicos borrados o perdidos de forma accidental.
- Gestión eficaz de las cuentas de correo corporativas: de la misma forma, es la organización quien crea los correos corporativos que utilizan los diferentes profesores o personal administrativo, evitando el uso de cuentas de correo particulares que el propio usuario “se lleva consigo” cuando abandona el centro.
- Integración con otros servicios del centro, como las agendas para la reserva de uso de locales y aulas de reuniones en el centro o los calendarios compartidos.
No obstante, en nuestro centro Zimbra también ha sido una fuente continua de problemas, unas veces por ataques de denegación de servicio, que impiden el acceso al correo electrónico de los usuarios legítimos y, otras veces, por ataques de phishing o de “suplantación de identidad”. Estos ataques se han venido sufriendo de forma creciente en los últimos años y la mayoría de ellos intentan conseguir, mediante diferentes engaños más o menos burdos, la contraseña de acceso al correo electrónico del usuario.
Ejemplo de ataque de phishing recibido en nuestro instituto
Otro ejemplo de ataque de phishing recibido en nuestro instituto
Una vez que un usuario cae en un ataque de estos y los atacantes consiguen la información deseada, el proceso que se desarrolla es el siguiente:
- Desde una máquina zombi y a través de la cuenta de correo capturada, se empieza a enviar spam de forma incontrolada. Este correo es un correo electrónico legítimo enviado desde el servidor de correo del instituto (posta.tartanga.eus) ya que se lleva a cabo desde una cuenta de usuario autorizada.
- En un breve plazo de tiempo la dirección IP desde la cual enviamos el correo electrónico es incluida en una o varias listas negras. Como consecuencia de ello, los correos legítimos enviados a nuestros destinatarios son enviados a la carpeta de spam por parte de sus servidores de correo o directamente son rechazados por provenir de una dirección IP de “baja reputación”.
- Tan pronto como se detecta el problema, se procede a bloquear la cuenta de correo capturada y a cambiar su contraseña, pero a veces, para cuando hacemos esto, ya estamos incluidos en varias listas negras y entonces hay que iniciar el proceso de salida de dichas listas.
- En algunas de ellas el proceso de salida es relativamente sencillo, normalmente mediante el envío de un formulario donde se certifica que el problema causante del envío del spam ha sido solucionado. En otras en cambio, como por ejemplo las listas negras de Gmail (Google) o de Outlook (Microsoft), el proceso de salida es muy dificultoso. En ambos casos aunque se solicite por escrito la salida de sus listas negras, es necesario esperar un tiempo importante, normalmente un mes en el caso de Gmail y un plazo de tiempo aun superior en el caso de Outlook.
- El estar tanto tiempo dentro de una de estas listas negras ocasiona un perjuicio muy importante en la dinámica de funcionamiento del instituto, ya que la mayoría de nuestros alumnos tienen cuentas de correo electrónico de Gmail o de Outlook.
Ejemplo de correo bloqueado por Gmail por ser el remitente de muy baja reputación
Durante años hemos invertido un buen número de horas de trabajo para corregir o, al menos, minimizar el impacto de esos ataques, utilizando estrategias como las siguientes:
- Actualización de la plataforma Zimbra a las nuevas versiones, ya que cada nueva versión contiene una mejor protección contra los ataques de spam.
Versión de Zimbra instalada en la actualidad
- Configuración del cortafuegos del instituto mediante el bloqueo de las conexiones al correo electrónico desde diferentes países que, habitualmente, han sido fuente de los ataques.
Ejemplo de ataques rechazados en el cortafuegos del instituto
- Activación del filtrado de direcciones IP mediante Fail2ban en el servidor de correo. Mediante este sistema se ha conseguido minimizar en gran medida los ataques provenientes de intentos de conexiones a través de sasl (Simple Authentication and Security Layer)
Fail2ban en el server de Zimbra
- Establecimiento de una política estricta de “fallos de inicios de sesión” en el servidor de correo, con bloqueo de la cuenta de correo cuando se sobrepasan 5 intentos erróneos en un periodo de 6 minutos. En esos casos la cuenta permanece bloqueada durante los siguientes 1o minutos.
Configuración de la política de fallos de inicio de sesión
- Monitorización continua de las colas de correo en la consola de administración de Zimbra, para detectar posibles envíos masivos de spam.
Colas de correo
Como curiosidad, cada vez que la cuenta de un usuario es “capturada” mediante un ataque de phishing y se comienza a enviar spam desde ella, es habitual encontrar miles de correos de spam retenidos en la cola de “diferidos”, esperando para ser enviados a sus destinos, tal y como se puede observar en la siguiente imagen, obtenida de una captura de pantalla en un reciente ataque como los indicados. Este elevado número de correos en la cola de salida provoca al mismo tiempo una elevada lentitud en la respuesta al correo electrónico para el resto de usuarios, comportándose como un auténtico ataque de “denegación de servicio”.
Ejemplo de cola de correo de mensajes “diferidos” en una situación de envío de spam
- Limitación del número de correos que se pueden enviar en un determinado intervalo de tiempo, y vigilancia en la consola de administración de Zimbra del número de correos enviados, en busca de algún comportamiento irregular sospechoso de estar provocado por una cuenta capturada.
Consola de administración de Zimbra mostrando el número de mensajes en diferentes intervalos de tiempo
La limitación del número de correos que se pueden enviar durante un periodo de tiempo, aunque es una táctica exitosa pues contribuye a limitar el envío de spam en el caso de que una cuenta resulte capturada, tiene el inconveniente de ser difícil de ajustar a todas las situaciones y momentos. Un límite pequeño en el envío de correos sin duda contribuye a minimizar el impacto de envío de spam e incluso a evitar el entrar en listas negras, pero dificulta el normal funcionamiento de la organización, en nuestro caso un instituto con más de 100 profesores y 1000 alumnos, y donde, en determinados momentos, es necesario enviar un elevado número de correos. Por contra, un límite demasiado alto en el envío de correos puede ser totalmente no operativo, ya que es posible que el spam enviado dentro de ese límite, sea suficiente para ser incluidos en alguna lista negra.
Ejemplo del caracter “discontinuo” de los mensajes enviados en los últimos 60 días y mensajes enviados el 13 de agosto de 2020, desde una cuenta capturada
En la imagen anterior se observa ese carácter discontinuo de los mensajes enviados desde el servidor de correo del instituto, y en la parte inferior de la imagen ser observa el número de mensajes enviados el pasado 13 de agosto de 2020, donde coincidió que un usuario fue víctima de un ataque de phishing y, simultáneamente, como consecuencia de una reciente actualización de Zimbra, todavía estaba sin activar el límite de mensajes a enviar en un determinado periodo de tiempo.
- Comprobación contra listas negras del correo entrante, a fin de rechazar aquellos correos que provienen de sitios incluidos en dichas listas negras y que pueden ser de tipo spam o de tipo phishing.
Listas negras utilizadas para verificar el correo entrante
Entre otros procedimientos que también se han utilizado para securizar y mantener a Zimbra en un funcionamiento correcto se incluye la edición de reglas específicas o “rules” en spamassassin. La función de esas reglas es detectar en los correos entrantes determinadas palabras clave sospechosas de ser correo spam o correo phishing. Estas “rules” son expresiones regulares que están escritas en Perl y se encuentran dentro del directorio /opt/zimbra/data/spamassassin/rules.
“Rules” por defecto de spamassassin
Ejemplo del contenido de una “rule”
Como se puede observar, el mantenimiento de una plataforma de colaboración como es Zimbra lleva un trabajo considerable y ofrece también una cierta dificultad, por lo que sin una adecuada dedicación y una monitorización continua, no es posible garantizar un correcto funcionamiento. Por si esto fuera poco, existe otro problema aun mayor, y que es el comportamiento no siempre correcto de los usuarios, unas veces por desconocimiento y otras, las más de ellas, por una relajación excesiva en el uso en general de las aplicaciones informáticas. De muy poco sirve todo lo anterior si, cuando entra un correo de spam que Zimbra no ha sido capaz de detectar automáticamente, el usuario no lo marca como tal y lo deja en su bandeja de entrada. El mecanismo de detección de spam por parte de Zimbra se basa en unas reglas prefijadas y también en el autoaprendizaje, de tal manera que se asigna una puntuación a ciertos elementos de cada correo electrónico entrante. Cuando se sobrepasa una determinada puntuación, el correo es enviado automáticamente a la carpeta de spam. Si varios usuarios marcan correctamente como spam un correo que es spam, el sistema “aprende” y los correos sucesivos serán enviados automáticamente a spam, pero si por el contrario los usuarios no realizan correctamente esta tarea y dan por buenos correos que en realidad son spam, el sistema actuará en consecuencia y ante una posterior entrada de correos similares, también los dará por buenos.
Ejemplo de asignación de puntuación en un correo electrónico
La dificultad en el mantenimiento de Zimbra y el elevado número de horas de trabajo que esta tarea requiere, ha motivado que CIFP Tartanga LHII cuente con la colaboración de la empresa Irekisoft para las principales labores de mantenimiento, actualización y detección de fallos en Zimbra.
A propuesta de los técnicos de Irekisoft, el CIFP Tartanga LHII ha decidido mejorar aun más la seguridad de la plataforma colaborativa Zimbra con el servicio de Relay ofrecido por la empresa Sarenet.
Este servicio de Relay, que Sarenet ofrece tanto en la modalidad de relay de entrada como de salida, está dedicado a empresas que tienen su propio servidor de correo electrónico, como es el caso del CIFP Tartanga LHII, y entre sus ventajas se pueden citar las siguientes:
- El servidor de correo de la empresa está más protegido y está descargado de las tareas de filtrado en la recepción (relay de entrada) y en la gestión de la cola de envío (relay de salida).
- Se garantiza la recepción de un correo depurado, libre de spam y de todo tipo de correos indeseados (relay de entrada).
- Se minimizan los retrasos en el envío de correo y los rechazos por estar incluidos en listas negras.
Para ello Sarenet lleva a cabo las siguientes estrategias:
- Filtrado por listas negras como Spamhaus y Commtouch, y también listas negras de elaboración propia de Sarenet en base a los logs de su propia plataforma.
- Filtrado por contenidos con listas de remitentes aceptados y remitentes rechazados.
- Filtrado por buzones inexistentes, comprobando para cada correo recibido que el usuario o buzón existe en el servidor de correo.
- Sofisticado filtrado antivirus con una combinación de los antivirus AV, ClamAV y Commtouch.
- Monitorización de la posible entrada en listas negras, advirtiendo de ello al administrador del servidor.
El CIFP Tartanga LHII ha contratado, inicialmente, el servicio de relay de salida y, además de las ventajas citadas anteriormente, ahora disponemos de una ventana de cliente donde podemos monitorizar fácilmente todo el correo saliente desde nuestro servidor, cosa que desde la propia plataforma de Zimbra no es fácil de hacer.
Ventana de cliente del servicio de “relay de salida” en Sarenet
Monitorización detallada de todos los correos enviados
La configuración a realizar en nuestro servidor de correo es sencilla, ya que tan solo es necesario redirigir el correo saliente a través de relay.sarenet.es.
Redirección del correo saliente a través de relay.sarenet.es
Lógicamente no cualquiera puede hacer esta redirección, ya que Sarenet solo espera recibir correo a su servicio de relay desde determinadas direcciones IP públicas, siendo una de ellas la utilizada por el servidor de correo del CIFP Tartanga LHII.
En la configuración también es necesario modificar el valor del registro SPF en nuestro servidor de DNS al valor necesario para el servicio relay de Sarenet. El protocolo SPF es, junto con DKIM y DMARC, uno de los protocolos de autenticación utilizados habitualmente en los servidores de correo electrónico.
- SPF: corresponde con Sender Policy Framework y su función es permitir que el receptor de un mensaje de correo electrónico pueda verificar que la dirección IP desde la que proviene dicho correo corresponde con el nombre de dominio del mismo.
Diagrama de funcionamiento de SPF (Blog de Irontec)
Configuración en el servidor de DNS del registro SPF
- DKIM: corresponde con DomainKeys Identified Mail y su función es que el servidor de correo saliente pueda firmar el correo que envía con una clave privada, de tal forma que el destinatario pueda verificar con la correspondiente clave pública que dicho correo es auténtico y que no ha sido interceptado ni reenviado desde otro servidor de correo no autorizado. Este sistema corresponde con el habitual funcionamiento del sistema de criptografía asimétrica basada en el uso de claves públicas y privadas, utilizado tanto para el cifrado como para la autenticación. En el cifrado, cuando un usuario A cifra un mensaje con la clave pública de otro usuario B, solo este usuario B con su clave privada podrá descrifrar el mensaje. En la autenticación cuando un usuario A cifra su identidad con su clave privada, cualquier usuario que conozca su clave pública podrá verificar que efectivamente la identidad del usuario A es la indicada. En el caso del protocolo DKIM, el servidor que envía el correo almacena su clave pública en un registro DKIM dentro del servidor de DNS, y el servidor que recibe el correo puede consultar en cualquier momento dicha clave pública y verificar la autenticidad del correo recibido.
Diagrama de funcionamiento de DKIM (Blog de Irontec)
Ejemplo de un registro DKIM en el servidor DNS
- DMARC: corresponde a Domain-based Message Authentication, Reporting and Conformance y su función es complementar a SPF y DKIM estandarizando el uso de estos protocolos para que la respuesta sea consistente con cualquier servidor de correo electrónico que utilice DMARC, como Gmail, Hotmail, Yahoo, AOL y otros más.
Diagrama de funcionamiento de DMARC (wiki de Zimbra)
Ejemplo de un registro DMARC en el servidor DNS
Con todo lo anterior correctamente configurado, cuando enviamos un correo a través del relay de salida de Sarenet, el receptor recibirá una cabecera como la siguiente:
Cabecera de un correo enviado a una cuenta de Gmail
En esta cabecera de correo se encuentra información como la siguiente:
- Cabeceras ARC-Seal, ARC-Message-Signature y ARC-Authentication-Results. ARC es el acrónimo de Authenticated Received Chain y es un nuevo protocolo definido en la RFC 8617 en julio de 2019 como “experimental”. ARC está creado para corregir los problemas que pueden suceder con SPF, DKIM y DMARC cuando un correo enviado pasa a través de otro servidor que puede hacer que SPF falle, porque el correo proviene de un remitente no autorizado, o bien porque dicho nuevo servidor modifica de alguna manera la cabecera del mensaje y provoca entonces que la comprobación de DKIM en el receptor falle al detectar que el mensaje recibido no es el original, sino que ha sido modificado. De forma muy resumida, lo que hace ARC es que un servidor de correo intermedio pueda validar la autenticación inicial del mensaje (SPF, DKIM y DMARC) y añadir nuevas cadenas de autenticación, incluyendo en ellas el resultado de la validación de las cadenas originales. Es decir, los servidores intermedios pueden añadir contenido al mensaje siempre que generen una nueva firma DKIM.
- Resultados originales de SPF, DKIM y DMARC
- Información acerca del paso del mensaje por el relay de salida de Sarenet y dirección IP desde la que ha sido enviado dicho mensaje.
Actualmente ARC es implementado por los principales proveedores de correo electrónico como Gmail, pero no todavía por otros como Microsoft, tal y como se puede ver en la cabecera de este otro mensaje enviado a una cuenta de Outlook.
Cabecera de un correo enviado a una cuenta de Outlook (Microsoft)
Como resumen final, es un hecho que la plataforma colaborativa Zimbra es una herramienta de comunicación muy potente para cualquier empresa, pero es también un hecho que su gestión y mantenimiento es una tarea compleja y delicada. Por todo ello es muy recomendable requerir la colaboración de empresas especializadas en dicho mantenimiento y también, cuando sea necesario, contratar aquellos servicios que ayuden a garantizar el correcto funcionamiento de la plataforma, como es el caso del servicio Relay de Sarenet. Solo en esas condiciones, la experiencia de trabajo con Zimbra será totalmente satisfactoria, al mismo nivel o superior que con otras conocidas soluciones de correo electrónico.