El mail bombing es una de las variantes más antiguas de ciberataques. En su esencia, se asemeja a un ataque DoS convencional, solo que en lugar de una oleada de solicitudes desde diferentes direcciones IP, se envía una avalancha de correos electrónicos a un solo buzón, lo que provoca un aumento significativo de la carga en él. Este tipo de ataque puede resultar en la imposibilidad de utilizar la bandeja de entrada, e incluso puede llevar a la caída de todo el servidor. La larga historia de este tipo de ciberataques ha tenido tanto consecuencias positivas como negativas para los administradores de sistemas. Entre los factores positivos se encuentran el buen conocimiento del mail bombing y la existencia de formas sencillas de defenderse de dicho ataque. Por otro lado, dentro de los factores negativos, se encuentra la gran cantidad de soluciones de software disponibles públicamente para llevar a cabo este tipo de ataques y la posibilidad de que el atacante se proteja eficazmente de ser detectado.
Una característica importante de este ciberataque es que es prácticamente imposible utilizarlo para obtener ganancias. Bien, un atacante envió una avalancha de correos electrónicos a una de las bandejas de entrada, no permitió que la persona utilizara el correo electrónico normalmente, hackeó el correo electrónico corporativo de alguien y comenzó a enviar miles de correos por todo el GAL, lo que provocó que el servidor se cayera o comenzara a funcionar tan lento que resultara imposible de usar, ¿y luego qué? Convertir este tipo de cibercrimen en dinero real es casi imposible, por lo que el mail bombing en sí mismo se ha convertido en un fenómeno bastante raro en la actualidad, y los administradores de sistemas al diseñar la infraestructura pueden simplemente no recordar la necesidad de protegerse contra este tipo de ciberataque.
Sin embargo, a pesar de que el mail bombing en sí mismo es una actividad bastante absurda desde el punto de vista comercial, a menudo es parte de otros ciberataques más complejos y en múltiples etapas. Por ejemplo, al hackear un correo y utilizarlo para tomar el control de una cuenta en algún servicio público, los atacantes suelen "bombardear" la bandeja de entrada de la víctima con correos sin sentido, para que un correo de confirmación se pierda en su flujo y pase desapercibido. Además, el mail bombing puede utilizarse como un medio de presión económica sobre una empresa. Así, un bombardeo activo del buzón público de la empresa, donde llegan las solicitudes de los clientes, puede complicar seriamente la atención a estas solicitudes y, como consecuencia, puede llevar a inactividad del equipo, pedidos no cumplidos, así como a la pérdida de reputación y oportunidades de ganancias.
Es por eso que el administrador del sistema no debe olvidar la probabilidad de un mail bombing y siempre tomar las medidas necesarias para protegerse de esta amenaza. Teniendo en cuenta que esto se puede hacer desde la etapa de construcción de la infraestructura de correo, y que solo requiere un poco de tiempo y esfuerzo por parte del administrador, no quedan razones objetivas para no garantizar la protección de su infraestructura contra el mail bombing. Veamos 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 Mail Transfer Agents más fiables y funcionales de código abierto en la actualidad. Y uno de los principales beneficios de su apertura es que admite una variedad de soluciones externas para ampliar su funcionalidad. En particular, Postfix soporta completamente cbpolicyd, una herramienta avanzada para garantizar la ciberseguridad del servidor de correo. Además de la protección contra spam y la creación de listas blancas, negras y grises, cbpolicyd permite al administrador de Zimbra configurar la verificación de firmas SPF y establecer restricciones en la recepción y envío de correos electrónicos o datos. Pueden proporcionar una sólida protección contra spam y correos de phishing, así como proteger el servidor contra el mail bombing.
Lo primero que necesitará un administrador de sistemas es activar el módulo cbpolicyd, que está preinstalado en Zimbra Collaboration Suite OSE en el servidor MTA de la infraestructura. Esto se hace con el comando zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Después de esto, será necesario activar la interfaz web para poder gestionar cómodamente cbpolicyd. Para ello, es necesario permitir conexiones en el puerto web número 7780, crear un enlace simbólico mediante el comando ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, y luego editar el archivo de configuración usando el comando nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, donde se deben incluir las siguientes líneas:
$DB_DSN='sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb';
$DB_USER='root';
$DB_TABLE_PREFIX='';
Después de esto, solo quedará reiniciar los servicios de Zimbra y Zimbra Apache usando los comandos zmcontrol restart y zmapachectl restart. Después de esto, podrá acceder a la interfaz web en la dirección :7780/webui/index.php. Lo principal a tener en cuenta es que el acceso a esta interfaz web no está protegido por el momento, y para evitar que personas no autorizadas entren, puede cerrar las conexiones en el puerto 7780 después de cada acceso a la interfaz web.
Las cuotas de envío de correos electrónicos, que se pueden establecer gracias a cbpolicyd, permiten protegerse de la avalancha de correos que proviene de la red interna. Estas cuotas permiten establecer un límite en el número máximo de correos que se pueden enviar desde una bandeja de entrada en un período de tiempo determinado. Por ejemplo, si los gerentes de su empresa envían en promedio entre 60 y 80 correos electrónicos por hora, se puede, considerando un pequeño margen, establecer una cuota de 100 correos electrónicos por hora. Para agotar tal cuota, los gerentes tendrían que enviar un correo cada 36 segundos. Por un lado, esto es suficiente para poder trabajar de manera efectiva, y por otro, con tal cuota, los delincuentes que hayan obtenido acceso al correo de uno de sus gerentes no podrán llevar a cabo un bombardeo de correos ni un ataque masivo de spam en la empresa.
Para establecer una cuota así, es necesario crear una nueva política de limitación del envío de correos en la interfaz web e indicar que esta política debe aplicarse tanto a los correos enviados dentro del dominio como a los correos enviados a direcciones externas. Esto se hace de la siguiente manera:
Después de eso, se podrá especificar con más detalle las restricciones relacionadas con el envío de correos, en particular establecer un intervalo de tiempo después del cual las restricciones se actualizarán, así como el mensaje que recibirá el usuario que haya superado su límite. Después de eso, se puede establecer la propia restricción sobre el envío de correos. Esta puede definirse tanto como una cantidad de correos salientes como en términos de la cantidad de bytes de información transmitida. Al mismo tiempo, se pueden manejar los correos que se envían más allá del límite establecido de diferentes maneras. Por ejemplo, se pueden eliminar de inmediato o guardarse para que se envíen una vez que se actualice el límite de envío de mensajes. La segunda opción puede utilizarse durante la identificación del valor óptimo del límite de envío de correos electrónicos por parte de los empleados.
Además de las restricciones sobre el envío de correos, cbpolicyd permite configurar un límite sobre la recepción de correos. Esta restricción, a primera vista, parece ser una excelente solución para protegerse contra el mail bombing, sin embargo, de hecho, establecer un límite, aunque sea grande, puede resultar en que, en ciertas circunstancias, no llegue un correo importante. Por esta razón, no se recomienda incluir ninguna restricción para el correo entrante. Sin embargo, si decides arriesgarte, es crucial abordar la configuración del límite de mensajes entrantes con especial cuidado. Por ejemplo, se podría limitar la cantidad de correos entrantes de contrapartes confiables, para que, en caso de que su servidor de correo haya sido comprometido, no se lleve a cabo un ataque de spam contra tu empresa.
Para protegerse de la avalancha de mensajes entrantes durante el mail bombing, el administrador del sistema debe tomar una medida más inteligente que simplemente limitar el correo entrante. Una solución podría ser el uso de listas grises. Su principio de funcionamiento es que, en el primer intento de entregar un mensaje de un remitente no confiable, la conexión con el servidor se interrumpe bruscamente, lo que resulta en un fallo en la entrega del correo. Sin embargo, si en un cierto período un servidor no confiable intenta nuevamente enviar el mismo correo, el servidor no corta la conexión y la entrega se realiza con éxito.
El objetivo de todas estas acciones es que los programas de envío automático masivo de correos electrónicos suelen no verificar el éxito de entrega del mensaje enviado y no intentan enviarlo nuevamente, mientras que una persona se aseguraría de saber si su correo fue enviado a la dirección indicada o no.
Se pueden habilitar las listas grises también en la interfaz web de cbpolicyd. Para que todo funcione, es necesario crear una política que incluya todos los correos entrantes dirigidos a los usuarios en nuestro servidor, y luego, basándose en esta política, crear una regla de Greylisting, donde se puede ajustar el intervalo durante el cual cbpolicyd esperará una respuesta de reenvío del remitente desconocido. Normalmente, este intervalo es de 4-5 minutos. Además, las listas grises se pueden configurar para que todas las intentos exitosos y no exitosos de entrega de correos de diferentes remitentes sean contabilizados y, en base a su número, se tome una decisión sobre la inclusión automática del remitente en las listas blancas o negras.
Es importante abordar el uso de listas grises con la máxima responsabilidad. Lo ideal sería que el uso de esta tecnología se combinara con un mantenimiento constante de listas blancas y negras para evitar la posibilidad de perder correos realmente importantes para la empresa.
Además, protegerse contra el mail bombing puede ayudar añadiendo verificaciones SPF, DMARC y DKIM. A menudo, los correos que llegan en el proceso de mail bombing no superan estas comprobaciones. Se explicó cómo hacerlo .
Así, protegerse contra una amenaza como el mail bombing es bastante simple, y se puede hacer incluso en la fase de construcción de la infraestructura Zimbra para su empresa. Sin embargo, es importante supervisar constantemente que los riesgos de utilizar tal protección nunca superen los beneficios que usted obtiene.
Fuente: habr.com
