El correo electrónico se ha consolidado como el estándar de la comunicación empresariales. Gracias a la alta eficiencia económica de los correos electrónicos, así como a una serie de características relacionadas con la citación de texto y la adjunción de archivos, los correos electrónicos son el medio ideal para el intercambio de documentos y la comunicación empresarial cortés. Estas mismas características han llevado a que los spammers amen tanto el correo electrónico. Como resultado, hoy en día el correo electrónico representa un vasto océano tempestuoso de spam, en cuyas aguas solo de vez en cuando se encuentran mensajes empresariales. Por eso, una de las principales tareas de cualquier administrador de servidor de correo es la protección contra el envío masivo de spam. Veamos qué se puede hacer al respecto en Zimbra Collaboration Suite Open-Source Edition.
A pesar de ser una solución gratuita, Zimbra OSE puede proporcionar al administrador del sistema una gran cantidad de herramientas altamente efectivas para abordar el problema de recibir correos no deseados. Ya hemos hablado de utilidades como Amavis, SpamAssassin, ClamAV y cbpolicyd, que permiten filtrar de forma confiable el correo entrante, eliminando los envíos de spam, así como mensajes infectados y de phishing. Sin embargo, su principal desventaja es que todos ellos operan con los mensajes de correo ya recibidos y consumen recursos del sistema en filtrar mensajes inútiles, recursos que siempre se pueden utilizar de mejor manera. Pero, ¿qué pasa si su empresa está bajo la mira de un gran botnet que envía constantemente a su servidor de correo cantidades tan grandes de mensajes basura que la filtración de estos ocupa la mayor parte de la potencia del servidor MTA?
Teóricamente, se puede proteger contra esto mediante la conexión a un servicio en la nube para filtrar el correo entrante; sin embargo, en la práctica, este método de protección no es adecuado para todas las empresas, ya que en este caso se tendría que confiar a terceros el procesamiento no solo del spam, sino también de la correspondencia comercial, lo que no siempre es seguro y a menudo contradice la política de seguridad de la empresa. Además, surgen riesgos relacionados con la fiabilidad del funcionamiento del filtro de spam en la nube. Una solución a esta situación puede ser organizar la protección del servidor de manera interna. Para estos fines, Zimbra ha integrado la herramienta Postscreen, que está diseñada para proteger el servidor de correo de los mensajes enviados por botnets sin sobrecargar el servidor de correo.
La esencia del funcionamiento de Postscreen es que esta herramienta revisa todas las solicitudes de conexión al correo electrónico servidor y no permite que se conecten al servidor aquellos clientes que le parezcan sospechosos. Según las estadísticas, aproximadamente el 90% del spam en el mundo es enviado precisamente por botnets, por lo que Postscreen se utiliza a menudo como una primera línea de defensa del servidor de correo contra correos no deseados. Gracias a esto, el servidor de correo puede funcionar de manera estable sin sobrecargas incluso en condiciones de ataques masivos de spam por parte de grandes botnets.
El principio de funcionamiento de Postscreen es bastante simple; la herramienta puede realizar una serie de verificaciones simples sobre los correos entrantes antes de enviarlos al servidor de correo u otros servicios que realizan un análisis más profundo y detallado de los correos entrantes. Cada una de las verificaciones puede ser aprobada o no. Basándose en los resultados de cada verificación, Postscreen puede aplicar una de las tres acciones elegidas por el administrador de Zimbra: Rechazar, Ignorar o Aplicar. La acción Rechazar interrumpe la conexión con el cliente si la verificación no es aprobada; la acción Ignorar permite ignorar los resultados de la verificación al tomar una decisión final, pero recopila información y estadísticas sobre las verificaciones realizadas, y la acción Aplicar permite tener en cuenta los resultados de las verificaciones realizadas al tomar la decisión final, pero al mismo tiempo continuar realizando todas las pruebas programadas por el administrador del sistema.
El principio de funcionamiento simple no significa que sea fácil de usar y configurar. Lo cierto es que una configuración incorrecta de Postscreen puede ser la razón por la cual varios correos importantes para la empresa no lleguen al destinatario. Por esta razón, la configuración de una herramienta tan potente como Postscreen debe abordarse con gran precaución y probarse constantemente en diferentes situaciones.
Postscreen está habilitado por defecto en Zimbra, sin embargo, a muchos puede desagradarlos la configuración inicial. Ahora revisaremos la mejor opción en términos de seguridad y ausencia de riesgos para la configuración de Postscreen. La esencia de esto radica en que, tras el fallo de alguna de las verificaciones, Postscreen no cortará la conexión con el cliente sin más, sino que realizará todas las comprobaciones hasta el final y, en caso de que estas verificaciones fallen, emitirá un mensaje de error. Esto permitirá notificar al remitente real sobre la falta de entrega del correo en caso de que Postscreen lo clasifique como spam. Esto se logra estableciendo el valor enforce en los parámetros de las verificaciones. Este valor permite completar las verificaciones iniciadas hasta el final, sin cortar la conexión con el cliente en el primer fallo, pero, al finalizar, aún bloquear el correo spam, sin entregarlo al servidor.
Para habilitar las verificaciones necesarias, se deben introducir los siguientes comandos:
zmprov mcf zimbraMtaPostscreenDnsblSites ‘b.barracudacentral.org=127.0.0.2*7’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[10;11]*8’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[4..7]*6’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.3*4’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.2*3’
Este comando permite añadir la verificación DNS de las conexiones entrantes en dos de las bases de datos de spam públicas más populares y clasificar los correos según en cuál de las bases se encuentre la dirección del remitente. Cuantas más «estrellas» de penalización acumule el cliente, más probable es que sea un spammer.
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
Este comando determina la acción que se realiza tras la verificación DNS. En este caso, el resultado de la verificación se recuerda, y el correo continúa pasando otras pruebas.
zmprov mcf zimbraMtaPostscreenGreetAction enforce
Dado que en el protocolo SMTP, tras la conexión directa, el servidor inicia la comunicación con el cliente, Postscreen puede enviar un saludo al cliente. Debido a que muchos clientes de spam comienzan a enviar comandos sin esperar a que termine el saludo, se pueden identificar fácilmente. Este comando permite considerar los resultados de esta verificación, pero al mismo tiempo continuar realizando más pruebas.
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
Con esta verificación, Postscreen permite filtrar aquellas conexiones que no provienen de clientes de correo electrónico. Dado que no envían correos, se pueden desconectar del servidor sin ningún temor.
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
Esta verificación se basa en que, por defecto, en el protocolo SMTP, el cliente puede enviar solo un comando a la vez y luego esperar una respuesta del servidor a ese comando. Sin embargo, muchos bots de spam se comportan de manera diferente, enviando múltiples comandos sin esperar la respuesta del servidor. Esto permite identificar al bot de spam casi sin errores.
En principio, estas verificaciones para Postscreen serán más que suficientes para filtrar la mayoría de los bots de spam del servidor y lograr una reducción significativa de la carga en su servidor de correo. Al mismo tiempo, las personas reales recibirán un mensaje de que su correo no fue entregado, lo que reduce considerablemente el riesgo de perder correos importantes debido a la configuración de Postscreen. En el caso de que esto ocurra, puede agregar al remitente confiable a la lista blanca de Postscreen. Para crear listas blancas y negras en Postscreen, primero debe crear un archivo. /opt/zimbra/conf/postfix/postscreen_wblist.
En él, agregaremos una lista de direcciones IP y subredes permitidas y prohibidas en formato CIDR. Por ejemplo, bloquearemos la subred 121.144.169.*, pero permitiremos la conexión a una sola. dirección IP de esta subred:
# Rules are evaluated in the order as specified.
# Blacklist 121.144.169.* except 121.144.169.196.
121.144.169.196/32 permit
121.144.169.0/24 reject
Queremos llamar su atención sobre la importancia del orden de las entradas. La cuestión es que Postscreen escaneará el archivo de listas blancas y negras hasta encontrar la primera coincidencia, y si la subred bloqueada se encuentra antes que la dirección IP permitida, la verificación simplemente no llegará a la entrada que indica que esta dirección IP está en la lista blanca y no se establecerá la conexión con el servidor.
Una vez que se haya editado y guardado el archivo con las listas blancas y negras, se puede activar la verificación correspondiente mediante los siguientes comandos:
zmprov mcf zimbraMtaPostscreenAccessList «permit_mynetworks, cidr:/opt/zimbra/conf/postfix/postscreen_wblist»
zmprov mcf zimbraMtaPostscreenBlacklistAction enforce
Ahora Postscreen, además de las verificaciones que ya hemos configurado, también hará referencia al archivo con las listas blancas y negras, lo que permitirá al administrador resolver con facilidad los problemas de conectividad con los remitentes confiables.
Fuente: habr.com
