El bombardeo por correo electrónico es uno de los tipos de ataques cibernéticos más antiguos. En esencia, se asemeja a un ataque DoS regular, pero en lugar de una ola de solicitudes de diferentes direcciones IP, se envía un correo electrónico al servidor, que en grandes cantidades llega a una de las direcciones de correo, por lo que la carga aumenta significativamente. Tal ataque puede conducir a la incapacidad de usar el buzón y, a veces, incluso puede provocar la falla de todo el servidor. La larga historia de este tipo de ciberataque ha dado lugar a una serie de consecuencias positivas y negativas para los administradores del sistema. Los factores positivos incluyen un buen conocimiento de los bombardeos por correo electrónico y la disponibilidad de formas simples de defenderse contra tal ataque. Los factores negativos incluyen una gran cantidad de soluciones de software disponibles públicamente para llevar a cabo este tipo de ataques y la capacidad de un atacante para protegerse de manera confiable contra la detección.
Una característica importante de este ciberataque es que es casi imposible de usar con fines de lucro. Bueno, el atacante envió una gran cantidad de correos electrónicos a uno de los buzones, bueno, no permitió que la persona usara el correo electrónico normalmente, bueno, el atacante pirateó el correo corporativo de alguien y comenzó a enviar correos masivos a miles de correos electrónicos en todo el GAL, por lo que el servidor se bloqueó o comenzó a ralentizarse para que sea imposible usarlo, y ¿qué sigue? Convertir tal delito cibernético en dinero real es casi imposible, por lo que actualmente el bombardeo de correo electrónico es bastante raro y los administradores del sistema al diseñar la infraestructura pueden no recordar la necesidad de protegerse contra tal ataque cibernético.
Sin embargo, a pesar de que el bombardeo de correo electrónico en sí mismo es una actividad comercial bastante insensata, a menudo es una parte integral de otros ataques cibernéticos más complejos y de etapas múltiples. Por ejemplo, al piratear el correo y usarlo para secuestrar una cuenta en un servicio público, los atacantes a menudo "bombardean" el buzón de la víctima con letras sin sentido para que el mensaje de confirmación se pierda en su transmisión y pase desapercibido. El bombardeo por correo electrónico también se puede utilizar como un medio de presión económica sobre la empresa. Por lo tanto, el bombardeo activo del buzón público de una empresa, para el cual se reciben solicitudes de clientes, puede complicar seriamente el trabajo con ellos y, como resultado, puede ocasionar tiempo de inactividad del equipo, pedidos pendientes, así como pérdida de reputación y pérdida de ganancias.
Es por eso que el administrador del sistema no debe olvidarse de la probabilidad de realizar bombardeos por correo electrónico y siempre tomar las medidas necesarias para protegerse contra esta amenaza. Dado que esto se puede hacer incluso en la etapa de construcción de la infraestructura de correo, así como el hecho de que al administrador del sistema le toma muy poco tiempo y trabajo, razones objetivas para no proporcionar a su infraestructura protección contra el bombardeo de correo electrónico, simplemente no queda . Echemos un vistazo a cómo se implementa la protección contra este ciberataque en la edición de código abierto Zimbra Collaboration Suite.
En el corazón de Zimbra se encuentra Postfix, uno de los agentes de transferencia de correo de código abierto más confiables y funcionales en este momento. Y una de las principales ventajas de su apertura es que admite una amplia variedad de soluciones de terceros para ampliar la funcionalidad. En particular, Postfix es totalmente compatible con cbpolicyd, una utilidad avanzada de ciberseguridad para el servidor de correo. Además de proteger contra el spam y crear listas blancas, listas negras y listas grises, cbpolicyd permite al administrador de Zimbra configurar la verificación de firma SPF, así como establecer límites para recibir y enviar correos electrónicos o datos. Pueden proporcionar una protección confiable contra correos electrónicos no deseados y de phishing, así como proteger al servidor de los bombardeos de correo electrónico.
Lo primero que requiere el administrador del sistema es la activación del módulo cbpolicyd, que está preinstalado en Zimbra Collaboration Suite OSE en el servidor MTA de infraestructura. Esto se hace usando el comando zmprov ms `zmhostname` + zimbraServiceEnabled cbpolicyd. Después de eso, deberá activar la interfaz web para poder administrar cómodamente cbpolicyd. Para hacer esto, debe habilitar las conexiones en el número de puerto web 7780, crear un enlace simbólico usando el comando
ln -s / opt / zimbra / common / share / webui / opt / zimbra / data / httpd / htdocs / webui , y luego edite el archivo de configuración usando el comando nano
/opt/zimbra/data/httpd/htdocs/webui/includes/config.php , donde debe registrar las siguientes líneas:
$ DB_DSN = "sqlite: /opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$ DB_USER = "root";
$ DB_TABLE_PREFIX = "";
Después de eso, solo queda reiniciar los servicios Zimbra y Zimbra Apache utilizando los comandos zmcontrol restart y zmapachectl restart. Después de eso, tendrá acceso a la interfaz web en
example.com : 7780 / webui / index.php . El matiz principal es que la entrada a esta interfaz web no está protegida de ninguna manera, y para evitar que personas no autorizadas ingresen a ella, simplemente puede cerrar las conexiones en el puerto 7780 después de cada entrada a la interfaz web.
Las cuotas para enviar correos electrónicos, que se pueden establecer gracias a cbpolicyd, le permiten protegerse del flujo de cartas que provienen de la red interna. Dichas cuotas le permiten establecer un límite en el número máximo de cartas que se pueden enviar desde un buzón a una unidad de tiempo. Por ejemplo, si los gerentes de su empresa envían un promedio de 60-80 correos electrónicos por hora, entonces, dado el pequeño margen, puede establecer una cuota de 100 correos electrónicos por hora. Para agotar dicha cuota, los gerentes deberán enviar una carta cada 36 segundos. Por un lado, esto es suficiente para funcionar completamente, y por otro lado, con tal cuota, los atacantes que obtienen acceso al correo de uno de sus gerentes no organizarán bombardeos de correo electrónico o ataques masivos de spam en la empresa.
Para establecer dicha cuota, es necesario crear una nueva política de restricción para enviar cartas en la interfaz web y especificar que actúe tanto en las cartas enviadas dentro del dominio como en las cartas que actúan en direcciones externas. Esto se hace de la siguiente manera:
Después de eso, será posible especificar con más detalle las restricciones asociadas con el envío de cartas, en particular, establecer el intervalo de tiempo después del cual se actualizarán las restricciones, así como el mensaje que recibirá el usuario que exceda su límite. Después de eso, puede establecer la restricción en el envío de cartas. Se puede establecer tanto como el número de letras salientes como el número de bytes de información transmitida. En este caso, con las cartas que se envían en exceso del límite designado, hazlo de manera diferente. Entonces, por ejemplo, puede simplemente eliminarlos inmediatamente, o puede guardarlos para que desaparezcan inmediatamente después de actualizar el límite para enviar mensajes. La segunda opción se puede utilizar al identificar el límite óptimo para el envío de correos electrónicos por parte de los empleados.
Además de las restricciones sobre el envío de cartas, cbpolicyd le permite configurar un límite para recibir cartas. Dicha restricción, a primera vista, es una excelente solución para la protección contra el bombardeo de correo electrónico, pero de hecho, el establecimiento de dicho límite, incluso si es grande, está plagado del hecho de que, bajo ciertas condiciones, una carta importante puede no llegar a usted. Es por eso que no se recomienda incluir ninguna restricción para el correo entrante. Sin embargo, si aún decide arriesgarse, debe acercarse al establecimiento del límite de mensajes entrantes con especial atención. Por ejemplo, puede limitar la cantidad de cartas entrantes de contrapartes confiables para que si su servidor de correo se viera comprometido, no llevaría a cabo un ataque de spam en su empresa.
Para protegerse del flujo de mensajes entrantes durante el bombardeo de correo electrónico, el administrador del sistema debe hacer algo más inteligente que simplemente restringir el correo entrante. Tal solución podría ser el uso de listas grises. El principio de su acción es que el primer intento de entregar un mensaje de un remitente poco confiable, la conexión al servidor se interrumpe abruptamente, por lo que la entrega del mensaje falla. Sin embargo, si en un período determinado el servidor no confiable intenta nuevamente enviar el mismo mensaje, el servidor no se desconecta y su entrega es exitosa.
El significado de todas estas acciones es que los programas para el envío masivo automático de correos electrónicos generalmente no verifican el éxito de la entrega del mensaje enviado y no intentan enviarlo por segunda vez, mientras que la persona seguramente se asegurará de si su carta fue enviada a la dirección o no.
También puede habilitar listas grises en la interfaz web de cbpolicyd. Para que todo funcione, debe crear una política que incluya todas las cartas entrantes dirigidas a los usuarios en nuestro servidor, y luego crear una regla de Greylisting basada en esta política, donde puede configurar el intervalo durante el cual cbpolicyd esperará una respuesta repetida de un desconocido remitente Por lo general, es de 4-5 minutos. Al mismo tiempo, las listas grises se pueden configurar para que se tengan en cuenta todos los intentos exitosos y no exitosos de entregar cartas de diferentes remitentes y, según su número, se toma la decisión de agregar automáticamente al remitente a las listas blancas o negras.
Llamamos su atención sobre el hecho de que el uso de listas grises debe abordarse con la máxima responsabilidad. Será mejor si el uso de esta tecnología va de la mano con el mantenimiento constante de las listas blancas y negras para excluir la posibilidad de perder letras que son realmente importantes para la empresa.
Además, agregar controles SPF, DMARC y DKIM puede ayudar a proteger contra el bombardeo de correo. A menudo, las cartas recibidas durante el proceso de bombardeo por correo no pasan dichos controles. Cómo hacer esto se describió
en uno de nuestros artículos anteriores .
Por lo tanto, protegerse de amenazas como el bombardeo de correo electrónico es bastante simple, y puede hacerlo incluso en la etapa de construcción de la infraestructura de Zimbra para su empresa. Sin embargo, es importante asegurarse constantemente de que los riesgos del uso de dicha protección nunca excedan los beneficios que recibe.
Para todas las preguntas relacionadas con la Suite Zextras, puede contactar al representante de la compañía "Zextras" Katerina Triandafilidi por correo electrónico katerina@zextras.com