Pflogsumm, comment savoir de quelle façon et par quoi la boite mail a été piratée?

Support Debian
#1

Bonsoir,
Aujourd’hui on m’a signalé que tous les e-mail envoyés du serveur d’entreprise (Debian 8, postfix, dovecot) étaient bloqués par les autres providers. Après un test en ligne, la réputation de l’adresse ip n’était pas au top.

Sachant que postfix n’est pas en mode open relay, que fail2ban est installé et configuré, j’ai à tout hasard fait un mailq, qui m’a affiché plus de 1000 e-mail en attente d’être envoyés depuis l’adresse d’un employé.

Après une recherche, je tombe sur pflogsumm , grâce à lui j’ai pu confirmer qu’il y avait bien un problème avec ce compte mail, cependant, c’est dans la section « Recipients by message count » que je trouve 1926 email pour l’adresse en question et rien dans la section « Senders by message count ». Alors que mailgraph m’affiche bien 11704 e-mail envoyés depuis le début de la semaine, et 2817 rien que pour hier, le 06 avril.

Alors, est-ce que le rapport le pflogsumm est normal?

D’un autre côté, est-il possible de savoir comment ça a pu se produire, pour sécuriser le serveur de messagerie d’avatange?

Merci

#2

Je suppose qu’on ne manquera pas de te le rappeler, mais un serveur accessible à l’extérieur doit être mis à jour, et en particulier à jour des correctifs de sécurité. Laisser un serveur d’entreprise accessible sur Debian 8 c’est tendre le bâton, surtout un serveur mail.
Je ne sais même pas quelle est la dernière version de postfix supportée sur Jessie, vu qu’elle a été archivée. Du coup je n’ai pas d’idée précise sur le nombre de patchs que ton postfix n’a pas reçu, mais il y en a probablement un paquet.

#3

Bonjour, oui effectivement, je suis d’accord. Cependant, ne sachant pas comment debian 8 réagirait à une mise à jour vers le 10, je n’ai pas voulu prendre de risque. Ce serveur héberge non seulement le serveur de messagerie, mais aussi le siteweb et plusieurs applications métiers. Une mise à jour hasardeuse risque de causer des incompatibilité, des « deprecations », des suppression de dossiers de fichiersn de paquets, que je ne saurais corriger directement. Il faudra tout refaire à zéro mais ça plongera l’entreprise dans le noir durant des semaines. Le mieux c’est d’essayer sur une VM de passer du 8 au 10.

La version actuelle de postfix est 2.11.3, un problème similaire s’est produit il y a 3 ans, car une personne avait mis un mot de passe très faible. Je suppose que c’est le même scénario.

Je dois m’assurer que c’est une simple intrusion par bruteforcing d’un bot, et non un accès d’autre part ou même un script malveillant qui serait sur le serveur. Il y a clamav installé depuis le début, je suppose qu’il fait son travail correctement.

#4

Je vous conseillerais d’utiliser de la virtualisation ou des conteneurs pour éviter ce genre de problèmes: 1 appli = 1 VM ou conteneur.

A la limite, trouvez un deuxième serveur pour y cloner l’actuel quelques semaines, pendant ce temps installez un OS spécialisé virtualisation (genre Proxmox) ou au moins faites la MàJ de l’OS.

La version stable actuelle est Debian 11 (ce sera Debian 12 probablement à la fin de l’été), quitte à mettre à jour l’OS, autant le faire sur la version stable (enfin vu le nombre de versions, ce serait plus simple de faire une réinstallation au propre).

La version actuelle de Postfix est la 3.5 dans Debian 11. Je te laisse compter sur cette page le nombre de correctifs que ta version a raté.
Les correctifs de sécurité sont là pour corriger des failles de sécurité. Les failles de sécurité c’est (notamment) quand ton service / logiciel peut être compromis / piraté même sans qu’un utilisateur choisisse un mot de passe trop faible. Tu ne peux pas pointer a priori la responsabilité sur les utilisateurs alors que le service de messagerie n’a reçu aucun patch de sécurité depuis des années.

ClamAV c’est bien pour vérifier les PJ échangées par email, mais là il faut passer à une autre catégorie. Utilise un détecteur de malwares du style rkhunter pour scanner tout le serveur.

Trouvez un deuxième serveur sur lequel faire tourner vos applis le temps de mettre le premier au propre. Gardez le même après d’ailleurs, vous serez contents d’avoir un serveur de sauvegarde / secours quand un disque dur du serveur 1 lâchera, par exemple.
Au pire vous subissez une interruption de service pendant 2 jours (en étant très généreux) le temps de passer sur un deuxième serveur.
Se faire pirater tout le serveur d’entreprise et toutes les données dessus, ça peut coûter beaucoup plus cher à une entreprise que 2 jours d’interruption.

1 J'aime