Le bombardement de courrier est l’un des types de cyberattaques les plus anciens. À la base, cela ressemble à une attaque DoS classique, mais au lieu d'une vague de requêtes provenant de différentes adresses IP, une vague d'e-mails est envoyée au serveur, qui arrivent en quantités énormes à l'une des adresses e-mail, grâce à quoi la charge là-dessus augmente considérablement. Une telle attaque peut conduire à l'impossibilité d'utiliser la boîte aux lettres, et parfois même conduire à la panne de l'ensemble du serveur. La longue histoire de ce type de cyberattaque a entraîné un certain nombre de conséquences positives et négatives pour les administrateurs système. Les facteurs positifs incluent une bonne connaissance du mail bombing et la disponibilité de moyens simples de vous protéger contre une telle attaque. Les facteurs négatifs incluent un grand nombre de solutions logicielles accessibles au public pour mener à bien ce type d'attaques et la capacité d'un attaquant à se protéger de manière fiable contre la détection.
Une caractéristique importante de cette cyberattaque est qu’il est presque impossible de l’utiliser à des fins lucratives. Eh bien, l'attaquant a envoyé une vague d'e-mails à l'une des boîtes aux lettres, eh bien, il n'a pas permis à la personne d'utiliser le courrier électronique normalement, eh bien, l'attaquant a piraté la messagerie d'entreprise de quelqu'un et a commencé à envoyer en masse des milliers de lettres dans toute la GAL, ce qui est pourquoi le serveur est tombé en panne ou a commencé à ralentir au point qu'il est devenu impossible de l'utiliser, et que se passe-t-il ensuite ? Il est presque impossible de convertir un tel cybercrime en argent réel, c'est pourquoi le simple bombardement de courrier est actuellement un phénomène plutôt rare et les administrateurs système, lors de la conception de l'infrastructure, peuvent tout simplement ne pas se souvenir de la nécessité de se protéger contre une telle cyberattaque.
Cependant, même si le bombardement d’e-mails constitue en soi un exercice plutôt inutile d’un point de vue commercial, il s’inscrit souvent dans le cadre d’autres cyberattaques plus complexes et à plusieurs étapes. Par exemple, lorsqu'ils piratent le courrier et l'utilisent pour détourner un compte dans un service public, les attaquants « bombardent » souvent la boîte aux lettres de la victime avec des lettres dénuées de sens, de sorte que la lettre de confirmation se perd dans leur flux et passe inaperçue. Les bombardements postaux peuvent également être utilisés comme moyen de pression économique sur une entreprise. Ainsi, le bombardement actif de la boîte aux lettres publique d'une entreprise, qui reçoit les demandes des clients, peut sérieusement compliquer le travail avec eux et, par conséquent, entraîner des temps d'arrêt des équipements, des commandes non exécutées, ainsi qu'une perte de réputation et une perte de profits.
C'est pourquoi l'administrateur système ne doit pas oublier la probabilité d'un bombardement d'e-mails et toujours prendre les mesures nécessaires pour se protéger contre cette menace. Étant donné que cela peut être fait au stade de la construction de l'infrastructure de messagerie et que cela prend très peu de temps et de travail de la part de l'administrateur système, il n'y a tout simplement aucune raison objective de ne pas protéger votre infrastructure contre les bombardements de courrier. Voyons comment la protection contre cette cyberattaque est mise en œuvre dans Zimbra Collaboration Suite Open-Source Edition.
Zimbra est basé sur Postfix, l'un des agents de transfert de courrier open source les plus fiables et fonctionnels disponibles aujourd'hui. Et l’un des principaux avantages de son ouverture est qu’il prend en charge une grande variété de solutions tierces pour étendre les fonctionnalités. En particulier, Postfix prend entièrement en charge cbpolicyd, un utilitaire avancé permettant d'assurer la cybersécurité des serveurs de messagerie. En plus de la protection anti-spam et de la création de listes blanches, noires et grises, cbpolicyd permet à l'administrateur Zimbra de configurer la vérification de signature SPF, ainsi que de définir des restrictions sur la réception et l'envoi d'e-mails ou de données. Ils peuvent à la fois fournir une protection fiable contre le spam et les e-mails de phishing, et protéger le serveur contre les bombardements d'e-mails.
La première chose qui est demandée à l'administrateur système est d'activer le module cbpolicyd, qui est 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. Après cela, vous devrez activer l’interface web afin de pouvoir gérer confortablement cbpolicyd. Pour ce faire, vous devez 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 modifiez le fichier de paramètres à l'aide de la commande nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, où vous devez écrire les lignes suivantes :
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="racine";
$DB_TABLE_PREFIX="";
Après cela, il ne reste plus qu'à redémarrer les services Zimbra et Zimbra Apache à l'aide des commandes zmcontrol restart et zmapachectl restart. Après cela, vous aurez accès à l'interface Web à l'adresse :7780/webui/index.php. La principale nuance est que l'entrée de cette interface web n'est pas encore protégée d'aucune manière et afin d'empêcher les personnes non autorisées d'y accéder, vous pouvez simplement fermer les connexions sur le port 7780 après chaque entrée dans l'interface web.
Vous pouvez vous protéger du flot d'emails provenant du réseau interne en utilisant des quotas d'envoi d'emails, paramétrables grâce à cbpolicyd. De tels quotas vous permettent de fixer une limite au nombre maximum de lettres pouvant être envoyées depuis une boîte aux lettres par unité de temps. Par exemple, si vos chefs d’entreprise envoient en moyenne 60 à 80 emails par heure, alors vous pouvez fixer un quota de 100 emails par heure, en prenant en compte une petite marge. Afin d'atteindre ce quota, les managers devront envoyer un email toutes les 36 secondes. D'une part, cela suffit pour fonctionner pleinement, et d'autre part, avec un tel quota, les attaquants qui ont eu accès au courrier d'un de vos managers ne lanceront pas de mail bombing ou d'attaque massive de spam sur l'entreprise.
Afin de définir un tel quota, vous devez créer une nouvelle politique de restriction d'envoi d'e-mails dans l'interface Web et préciser qu'elle s'applique à la fois aux lettres envoyées au sein du domaine et aux lettres envoyées à des adresses externes. Cela se fait comme suit:
Après cela, vous pourrez préciser plus en détail les restrictions liées à l'envoi de lettres, notamment définir l'intervalle de temps après lequel les restrictions seront mises à jour, ainsi que le message que recevra un utilisateur ayant dépassé sa limite. Après cela, vous pouvez définir une restriction sur l'envoi de lettres. Il peut être défini à la fois comme le nombre de lettres sortantes et comme le nombre d'octets d'informations transmises. Dans le même temps, les lettres envoyées au-delà de la limite indiquée doivent être traitées différemment. Ainsi, par exemple, vous pouvez simplement les supprimer immédiatement ou les enregistrer afin qu'ils soient envoyés immédiatement après la mise à jour de la limite d'envoi de messages. La deuxième option peut être utilisée pour déterminer la valeur optimale de la limite d'envoi d'e-mails par les salariés.
En plus des restrictions d'envoi de lettres, cbpolicyd vous permet de définir une limite de réception de lettres. Une telle limitation, à première vue, est une excellente solution pour se protéger contre les bombardements de courrier, mais en fait, fixer une telle limite, même importante, se heurte au fait que dans certaines conditions, une lettre importante peut ne pas vous parvenir. C'est pourquoi il est fortement déconseillé d'activer des restrictions pour le courrier entrant. Cependant, si vous décidez quand même de prendre le risque, vous devez aborder la définition de la limite de messages entrants avec une attention particulière. Par exemple, vous pouvez limiter le nombre d'e-mails entrants provenant de contreparties de confiance afin que si leur serveur de messagerie est compromis, il ne lancera pas d'attaque de spam contre votre entreprise.
Afin de se protéger contre l'afflux de messages entrants lors du bombardement de courriers électroniques, l'administrateur système doit faire quelque chose de plus intelligent que de simplement limiter le courrier entrant. Cette solution pourrait être l'utilisation de listes grises. Le principe de leur fonctionnement est qu'à la première tentative de livraison d'un message provenant d'un expéditeur peu fiable, la connexion au serveur est brusquement interrompue, raison pour laquelle la livraison de la lettre échoue. Cependant, si, à un certain moment, un serveur non fiable tente d'envoyer à nouveau la même lettre, le serveur ne ferme pas la connexion et sa livraison réussit.
Le point de toutes ces actions est que les programmes d'envoi automatique d'e-mails en masse ne vérifient généralement pas le succès de la livraison du message envoyé et n'essaient pas de l'envoyer une deuxième fois, alors qu'une personne s'assurera certainement si sa lettre a été envoyée à l'adresse ou non.
Vous pouvez également activer la liste grise dans l'interface Web de cbpolicyd. Pour que tout fonctionne, vous devez créer une politique qui inclurait toutes les lettres entrantes adressées aux utilisateurs sur notre serveur, puis, sur la base de cette politique, créer une règle de liste grise, où vous pourrez configurer l'intervalle pendant lequel cbpolicyd attendra pour une réponse répétée d’un expéditeur inconnu. Habituellement, cela dure 4 à 5 minutes. Dans le même temps, des listes grises peuvent être configurées de manière à ce que toutes les tentatives réussies et infructueuses de livraison de lettres de différents expéditeurs soient prises en compte et, en fonction de leur nombre, une décision soit prise d'ajouter automatiquement l'expéditeur aux listes blanches ou noires.
Nous attirons votre attention sur le fait que l’utilisation des listes grises doit se faire avec la plus grande responsabilité. Il serait préférable que l'utilisation de cette technologie s'accompagne de la maintenance constante de listes blanches et noires pour éliminer la possibilité de perdre des e-mails vraiment importants pour l'entreprise.
De plus, l'ajout de contrôles SPF, DMARC et DKIM peut aider à vous protéger contre les attentats par e-mail. Souvent, les lettres qui arrivent via le processus de bombardement de courrier ne passent pas ces contrôles. Comment faire cela a été discuté .
Ainsi, se protéger contre une menace telle que le bombardement d'e-mails est assez simple, et vous pouvez le faire même au stade de la construction de l'infrastructure Zimbra pour votre entreprise. Cependant, il est important de veiller en permanence à ce que les risques liés à l’utilisation d’une telle protection ne dépassent jamais les avantages dont vous bénéficiez.
Source: habr.com