El mail bombing es uno de los tipos más antiguos de ciberataques. En esencia, se parece a un ataque DoS regular, pero en lugar de una ola de solicitudes de diferentes direcciones IP, se envía una ola de correos electrónicos al servidor, que llegan en grandes cantidades a una de las direcciones de correo electrónico, por lo que la carga en él aumenta significativamente. Tal ataque puede conducir a la incapacidad de usar el buzón y, a veces, incluso provocar la falla de todo el servidor. La larga historia de este tipo de ciberataques ha dado lugar a una serie de consecuencias positivas y negativas para los administradores de sistemas. Los factores positivos incluyen el buen conocimiento del bombardeo por correo y la disponibilidad de formas simples de protegerse de dicho 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 de la detección.
Una característica importante de este ciberataque es que es casi imposible utilizarlo con fines lucrativos. Bueno, el atacante envió una ola 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 miles de cartas en masa a través de GAL, debido a que el servidor colapsó o comenzó a ralentizarse de modo que se hizo imposible usarlo, ¿y luego qué? Es casi imposible convertir dicho delito cibernético en dinero real, por lo que el bombardeo por correo electrónico es actualmente bastante raro y es posible que los administradores de sistemas simplemente no recuerden la necesidad de protegerse contra un ataque cibernético de este tipo al diseñar la infraestructura.
Sin embargo, a pesar de que el bombardeo por correo en sí mismo es una actividad sin sentido desde un punto de vista comercial, a menudo es una parte integral de otros ataques cibernéticos más complejos y de varias etapas. Por ejemplo, al hackear el correo y usarlo para secuestrar una cuenta en algún servicio público, los atacantes suelen “bombardear” el buzón de la víctima con cartas sin sentido para que la carta de confirmación se pierda en su flujo y pase desapercibida. El bombardeo por correo también se puede utilizar como medio de presión económica sobre una empresa. Por lo tanto, el bombardeo activo del buzón público de una empresa, que recibe solicitudes de clientes, puede complicar seriamente el trabajo con ellos y, como resultado, puede provocar tiempo de inactividad del equipo, pedidos no cumplidos, así como pérdida de reputación y lucro cesante.
Es por eso que el administrador del sistema no debe olvidarse de la posibilidad de un bombardeo de correo y tomar siempre las medidas necesarias para protegerse contra esta amenaza. Teniendo en cuenta que esto se puede hacer incluso en la etapa de construcción de la infraestructura de correo, y también que requiere muy poco tiempo y esfuerzo por parte del administrador del sistema, simplemente no hay razones objetivas para no proteger su infraestructura contra el bombardeo de correo. Echemos un vistazo a cómo se implementa la protección contra este ciberataque en Zimbra Collaboration Suite Open-Source Edition.
Zimbra se basa en Postfix, uno de los agentes de transferencia de correo de código abierto más fiables y funcionales del 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 del servidor de correo. Además de la protección contra correo no deseado y las listas blancas, negras y 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. Ambos pueden brindar una protección confiable contra el spam y los correos electrónicos de phishing, así como también proteger el servidor contra el bombardeo de correos electrónicos.
Lo primero que se requiere del administrador del sistema es la activación del módulo cbpolicyd, el cual viene preinstalado en el OSE de Zimbra Collaboration Suite 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 permitir las conexiones en el puerto web número 7780, cree un enlace simbólico usando el comando ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webuiy luego edite el archivo de configuración con el comando nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, donde debe escribir las siguientes líneas:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="raíz";
$DB_TABLE_PREFIX="";
Después de eso, solo queda reiniciar los servicios Zimbra y Zimbra Apache usando los comandos zmcontrol restart y zmapachectl restart. Después de eso, tendrá acceso a la interfaz web en :7780/webui/index.php. El matiz principal es que la entrada a esta interfaz web aún no está protegida de ninguna manera, y para evitar que personas no autorizadas ingresen, simplemente puede cerrar las conexiones en el puerto 7780 después de cada entrada a la interfaz web.
Para protegerse contra la avalancha de correos electrónicos provenientes de la red interna, puede usar cuotas para el envío de correos electrónicos, que se pueden configurar gracias a cbpolicyd. Estas cuotas le permiten establecer un límite en la cantidad máxima de cartas que se pueden enviar desde un buzón en una unidad de tiempo. Por ejemplo, si los gerentes de su empresa envían un promedio de 60 a 80 correos electrónicos por hora, podría establecer una cuota de 100 correos electrónicos por hora con un margen pequeño. Para agotar esta cuota, los gerentes deberán enviar una carta cada 36 segundos. Por un lado, esto es suficiente para que funcione completamente y, por otro lado, con esa cuota, los atacantes que hayan obtenido acceso al correo de uno de sus gerentes no organizarán un bombardeo de correo o un ataque masivo de spam en la empresa. .
Para establecer dicha cuota, debe crear una nueva política de restricción de envío de correo electrónico en la interfaz web y especificar que se aplica tanto a los correos electrónicos enviados dentro del dominio como a los correos electrónicos enviados a 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 ha excedido su límite. Después de eso, puede establecer la misma restricción para enviar cartas. Se puede configurar tanto como el número de mensajes salientes como el número de bytes de información transmitida. Al mismo tiempo, con las cartas que se envían en exceso del límite designado, actúe de manera diferente. Entonces, por ejemplo, puede simplemente eliminarlos de inmediato, o puede guardarlos para que se vayan inmediatamente después de que se actualice el límite de envío de mensajes. La segunda opción se puede utilizar al determinar el valor óptimo para el límite de envío de correos electrónicos a los empleados.
Además de enviar límites de correo electrónico, cbpolicyd le permite establecer un límite para recibir correos electrónicos. Tal límite, a primera vista, es una excelente solución para protegerse contra el bombardeo de correo, pero de hecho, establecer dicho límite, incluso si es grande, está plagado del hecho de que, bajo ciertas condiciones, es posible que no le llegue una carta importante. Es por eso que se desaconseja habilitar cualquier restricción para el correo entrante. Sin embargo, si aún decide arriesgarse, debe abordar la configuración del límite de mensajes entrantes con especial atención. Por ejemplo, puede limitar la cantidad de correos electrónicos entrantes de contrapartes confiables para que, si su servidor de correo se ve comprometido, no envíe spam a su empresa.
Para protegerse contra la avalancha de mensajes entrantes del bombardeo de correo, el administrador del sistema debería 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 funcionamiento es que en el primer intento de enviar un mensaje de un remitente poco confiable, la conexión con el servidor se interrumpe abruptamente, por lo que falla la entrega del mensaje. Sin embargo, si un servidor que no es de confianza intenta enviar el mismo correo electrónico nuevamente dentro de un período determinado, el servidor no interrumpe la conexión y la entrega se realiza correctamente.
El punto de todas estas acciones es que los programas automáticos de correo masivo generalmente no verifican el éxito 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 las 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, en función de esta política, crear una regla de lista gris, donde puede configurar el intervalo durante el cual esperará cbpolicyd para una segunda respuesta de un remitente desconocido. Por lo general, son 4-5 minutos. Al mismo tiempo, las listas grises se pueden configurar para que se tengan en cuenta todos los intentos exitosos y fallidos de entregar cartas de diferentes remitentes y, en función de su número, se toma la decisión de agregar automáticamente el 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ía mejor si el uso de esta tecnología va de la mano con el mantenimiento constante de listas blancas y negras para excluir la posibilidad de perder cartas que son realmente importantes para la empresa.
Además, agregar controles SPF, DMARC y DKIM puede ayudar a proteger contra el bombardeo de correo electrónico. A menudo, las cartas que llegan en el proceso de bombardeo de correo no pasan dichos controles. Se explicó cómo hacer esto. .
Por lo tanto, es bastante simple protegerse de una amenaza como el bombardeo por correo, 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 de usar dicha protección nunca superen los beneficios que recibe.
Fuente: habr.com