Le mail bombing est l'une des plus anciennes formes de cyberattaques. En substance, cela ressemble à une attaque DoS classique, sauf qu'au lieu d'une vague de requêtes provenant de différentes adresses IP, un flot de courriels est envoyé à un serveur, ce qui augmente considérablement la charge sur une adresse électronique particulière. Une telle attaque peut entraîner l'impossibilité d'utiliser la boîte aux lettres, et parfois même provoquer l'échec complet du serveur. L'histoire longue de ce type de cyberattaque a conduit à une série de conséquences positives et négatives pour les administrateurs système. Parmi les facteurs positifs, on peut citer la bonne connaissance du mail bombing et la disponibilité de moyens simples pour se protéger contre ce type d'attaque. En revanche, parmi les facteurs négatifs, on note le grand nombre de solutions logicielles accessibles au public pour mener ces types d'attaques et la possibilité pour les malfaiteurs de se protéger efficacement contre la détection.
Une caractéristique non négligeable de cette cyberattaque est qu'elle est pratiquement impossible à utiliser pour en tirer un profit. Un malfaiteur a peut-être inondé une boîte aux lettres avec un flot de courriels, cela a empêché une personne d'utiliser normalement sa messagerie électronique, ou encore, un malfaiteur a piraté une messagerie professionnelle et a commencé à envoyer massivement des milliers de courriels sur tout le GAL, ce qui a provoqué un crash du serveur ou un ralentissement tel qu'il est devenu impossible de l'utiliser, et après ? Convertir ce type de cybercriminalité en argent liquide est presque impossible, c'est pourquoi le mail bombing est aujourd'hui un phénomène assez rare et les administrateurs système, lors de la conception de l'infrastructure, peuvent simplement ne pas se rappeler de la nécessité de se protéger contre ce type de cyberattaque.
Cependant, bien que le mail bombing soit en soi une activité assez insensée d'un point de vue commercial, il constitue souvent une composante d'autres cyberattaques plus complexes et à plusieurs niveaux. Par exemple, lors du piratage d'une boîte mail et de son utilisation pour usurper un compte sur un service public, les cybercriminels bombardent souvent la boîte de réception de la victime avec des courriers sans intérêt pour que l'e-mail de confirmation se perde dans le flot et passe inaperçu. De plus, le mail bombing peut être utilisé comme un moyen de pression économique sur une entreprise. Ainsi, une attaque active sur une boîte mail publique de l'entreprise, où sont reçues les demandes des clients, peut sérieusement entraver le travail avec eux, et, par conséquent, conduire à un arrêt des équipements, des commandes non honorées, ainsi qu'à une perte de réputation et de profits.
C'est pourquoi il est crucial pour l'administrateur système de ne pas oublier la probabilité d'une attaque de mail bombing et de toujours prendre les mesures nécessaires pour se protéger contre cette menace. Étant donné qu'il est possible de le faire dès la construction de l'infrastructure de messagerie, et que cela demande peu de temps et d'efforts à l'administrateur système, il n'y a objectivement aucune raison de ne pas sécuriser son infrastructure contre le mail bombing. Voyons comment la protection contre cette cyberattaque est mise en œuvre dans le Zimbra Collaboration Suite Open-Source Edition.
Au cœur de Zimbra se trouve Postfix, l'un des agents de transfert de mail les plus fiables et performants en open source à ce jour. L'un des principaux avantages de sa nature open source est qu'il prend en charge une grande variété de solutions tierces pour étendre ses fonctionnalités. En particulier, Postfix prend pleinement en charge cbpolicyd, un outil avancé pour assurer la cybersécurité du serveur de messagerie. En plus de la protection contre le spam et la création de listes blanches, noires et grises, cbpolicyd permet à l'administrateur Zimbra de configurer la vérification des signatures SPF, ainsi que d'établir des restrictions sur la réception et l'envoi d'e-mails ou de données. Cela peut non seulement offrir une protection fiable contre les spams et les courriers de phishing, mais aussi protéger le serveur contre le mail bombing.
La première chose requise d'un administrateur système est l'activation du module cbpolicyd, préinstallé dans Zimbra Collaboration Suite OSE sur le serveur MTA de l'infrastructure. Cela se fait à l'aide de la commande zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Ensuite, il sera nécessaire d'activer l'interface web pour pouvoir gérer cbpolicyd confortablement. Pour cela, il faut autoriser les connexions sur le port web numéro 7780, créer un lien symbolique à l'aide de la commande ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, puis éditer le fichier de configuration à l'aide de la commande nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, où il faudra inscrire les lignes suivantes :
$DB_DSN='sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb';
$DB_USER='root';
$DB_TABLE_PREFIX='';
Après cela, il ne restera plus qu'à redémarrer les services Zimbra et Zimbra Apache à l'aide des commandes zmcontrol restart et zmapachectl restart. Vous aurez alors accès à l'interface web à l'adresse :7780/webui/index.php. L'un des principaux points à noter est que l'accès à cette interface web n'est pas encore sécurisé. Pour éviter que des intrus y aient accès, vous pouvez simplement fermer les connexions sur le port 7780 après chaque connexion à l'interface web.
Les quotas d'envoi d'emails permettent de se protéger contre le flot d'emails provenant du réseau interne, et peuvent être définis grâce à cbpolicyd. Ces quotas permettent de limiter le nombre maximum d'emails pouvant être envoyés depuis une seule boîte aux lettres à un moment donné. Par exemple, si vos managers envoient en moyenne entre 60 et 80 emails par heure, vous pouvez, en tenant compte d'une petite marge de sécurité, leur attribuer un quota de 100 emails par heure. Pour épuiser ce quota, les managers devront envoyer un email toutes les 36 secondes. Cela est suffisant pour un travail efficace, mais en même temps, avec un tel quota, des malfaiteurs ayant accès à la boîte email d'un de vos managers ne pourront pas provoquer une attaque par mail-bombing ou un envoi massif de spam au sein de l'entreprise.
Pour établir un tel quota, il est nécessaire de créer une nouvelle politique de limitation de l'envoi d'emails dans l'interface web et d'indiquer qu'elle s'applique tant aux emails envoyés à l'intérieur du domaine qu'à ceux envoyés vers des adresses externes. Cela se fait de la manière suivante :
Après cela, il sera possible de préciser plus en détail les restrictions liées à l'envoi d'e-mails, notamment de définir l'intervalle de temps après lequel les restrictions seront mises à jour, ainsi que le message que recevra l'utilisateur ayant dépassé sa limite. Ensuite, vous pourrez définir la restriction elle-même sur l'envoi d'e-mails. Elle peut être établie soit sous forme de nombre d'e-mails sortants, soit de quantité de données transmises. Il existe différentes options concernant les e-mails envoyés au-delà de cette limite. Par exemple, vous pouvez les supprimer immédiatement ou les conserver afin qu'ils soient envoyés immédiatement après la mise à jour de la limite d'envoi des messages. La deuxième option peut être utilisée lors de la recherche de la valeur optimale de la limite d'envoi d'e-mails par les employés.
En plus des restrictions sur l'envoi d'e-mails, cbpolicyd permet de configurer une limite sur la réception des e-mails. Une telle restriction, à première vue, semble être une excellente solution pour se protéger contre le mail bombing, cependant, mettre en place une telle limite, même si elle est grande, peut entraîner des situations où des e-mails importants peuvent ne pas vous parvenir. C'est pourquoi il est fortement déconseillé d'appliquer des restrictions pour les courriers entrants. Toutefois, si vous décidez de prendre ce risque, vous devez aborder la configuration de la limite des messages entrants avec une attention particulière. Par exemple, vous pouvez limiter le nombre d'e-mails entrants provenant de partenaires de confiance, afin que, si leur serveur de messagerie est compromis, il ne puisse pas lancer une attaque par spam contre votre entreprise.
Pour se protéger d'une vague de messages entrants lors d'un mail bombing, l'administrateur système doit envisager des solutions plus intelligentes qu'une simple restriction des e-mails entrants. Une telle solution peut être l'utilisation de listes grises. Leur principe de fonctionnement est le suivant : lors de la première tentative de livraison d'un message par un expéditeur non fiable, la connexion avec le serveur est brutalement interrompue, ce qui empêche la livraison de l'e-mail. Cependant, si, dans un certain délai, le serveur non fiable tente à nouveau d'envoyer le même message, le serveur ne coupe pas la connexion et la livraison se passe avec succès.
Le sens de toutes ces actions est que les programmes d'envoi automatique de courriers électroniques en masse ne vérifient généralement pas le succès de la livraison du message envoyé et n'essaient pas de le renvoyer, tandis qu'une personne s'assurera certainement que son courrier a bien été envoyé à l'adresse correcte ou non.
Les listes grises peuvent également être activées dans l'interface web de cbpolicyd. Pour que tout fonctionne, il est nécessaire de créer une politique incluant tous les courriers entrants adressés aux utilisateurs de notre serveur, puis de créer une règle de Greylisting basée sur cette politique, où il est possible de configurer l'intervalle pendant lequel cbpolicyd attendra une réponse de la part d'un expéditeur inconnu. En général, cet intervalle est de 4 à 5 minutes. Par ailleurs, les listes grises peuvent être configurées de manière à ce que toutes les tentatives de livraison réussies et échouées des courriers de différents expéditeurs soient prises en compte, et en fonction de leur nombre, une décision d'ajout automatique de l'expéditeur dans les listes blanches ou noires soit prise.
Nous attirons votre attention sur le fait qu'il est important d'aborder l'utilisation des listes grises avec la plus grande responsabilité. Il est préférable que l'utilisation de cette technologie soit accompagnée de la gestion continue des listes blanches et noires, afin d'éviter la perte de courriers réellement importants pour l'entreprise.
De plus, il peut être utile de se protéger contre le mail bombing en ajoutant des vérifications SPF, DMARC et DKIM. Souvent, les courriers reçus lors d'un mail bombing ne passent pas ces vérifications. Il a été question de la manière de procéder .
Ainsi, se protéger contre une menace telle que le mail bombing est assez simple, et cela peut être fait dès la phase de construction de l'infrastructure Zimbra pour votre entreprise. Cependant, il est important de surveiller en permanence pour s'assurer que les risques liés à l'utilisation de cette protection ne dépassent jamais les avantages que vous en tirez.
Source : habr.com
