J’ai mis en place BlueMind afin de tester la solution
Je suis dans un environnement KVM avec plusieurs solutions type Postfix/Exim/SME/Qmail etc…
J’ai donc joyeusement mis en place mon BlueMind qui ne comporte pas, par défaut, d’Antispam ni de règles de checks avancées Posftix.
Résultat : Activation dans la nuit de l’antispam d’urgence de mon netblockowner. Après libération de l’antispam, routage du flux du port 25 vers ma passerelle antispam.
Résultat:plus de 10 000 rejects en 8 minutes, je n’ai plus qu’a passer par le 587.
Conclusion, il serait judicieux d’avertir que même a des fins de tests, BlueMind n’assure aucune protection concernant les attaques smtp/port 25 dans un environnement dédié et exposé.
Certes j’aurais du faire du domain relay sur ma passerelle antispam avant, mais le résultat est que je me suis fait éclater mon port 25 en quelques heures et que je dois désormais dropper depuis iptables. Sachant que je n’ai rencontré aucun problème de ce type avant la mise en place de BlueMind.
Au vu des problématiques de spams de notre ère, je pense que le Postfix de BlueMind devrait être durcit
L’absence d’antivirus et antispam dans BlueMind est connue.
(L’occupation mémoire et les partenariats en sont peut-être des causes ?)
De facto, il est très logique de prévoir un ‘smtp relay’ pour la réception des mails en exploitation (et c’est aussi vrai avec d’autres solutions de messagerie).
Au niveau firewall, on renverra 443/tcp=https vers le serveur BlueMind pour le webmail et la synchronisation des smartphones, et 25/tcp=smtp vers le serveur smtp-relay.
Depuis déjà longtemps, les clients lourds doivent utiliser 587/tcp=smtp-auth pour traverser les box, donc le firewall renverra aussi 587/tcp sur le serveur BlueMind.
Je ne connais pas la définition de ‘postfix durci’ mais on peut aisément intégrer le greylisting, l’antivirus, l’antispam voire les RBL à un serveur smtp-relay.
Nous ne souhaitons pas intégrer nativement d’anti-spam, principalement car ce n’est pas notre métier, et maintenir un anti-spam pertinent est très consommateur en temps.
Par contre nous laissons la possibilité de greffer l’anti-spam que vous souhaitez, local ou en ligne (altospam, mxguardog, mxproxy, … par exemple), ainsi que tous les outils pour durcir les règles (greylisting, blacklists…).
D’origine, BlueMind n’est pas un relais ouvert, il accepte uniquement les mails destinés à un de ses domaines, ou vers n’importe qui a condition de fournir un login et mot de passe valide, ou de faire parti de la plage d’adresse définie dans la console d’administration, section Gestion du système, menu Configuration système, onglet Messagerie, champs Mes réseaux.
Il n’est pas exclus que nous ajoutions dans l’interface d’administration des options permettant la gestion de certains aspects (DKIM, règles de blacklists…). N’hésitez pas à ouvrir des demandes de fonctionnalités dans notre jira.
S’il est possible de contribuer, je suis bien sur preneur.
En une seule nuit j’ai cumulé 378 000 mails en queue, et mon netblockowner et moi même avons diagnostiqué de l’open relay. (yahoo.com, yahoo.coM.tw etc…) c’est étrange car s’il y a de l’auth SASL cela n’a pas fonctionné.
Je suis aussi d’accord avec vous sur le fait de ne pas intégrer un antispam si cela n’est pas votre métier.
En revanche, il est possible de durcir les règles Postfix afin d’éviter certaines attaque notamment des checks headers/body. En ce qui me concerne la totalité de l’attaque concernait des emails dont les HELO ne respectaient pas les RFC, ils ont été automatiquement bloqués lors du routage vers ma passerelle antispam.
Le Postfix de ma gateway a donc été capable de rejecter l’ensemble de ces emails ne respectant pas les headers HELO. Je pense qu’il serait possible d’intégrer ces règles natives à Postfix dans votre solution.
Je n’ai eu aucuns messages d’avertissements sur l’absence de solution antispam a l’installation de BLueMind ou dans la doc …
Postfix par défaut ne sert pas a grand chose (en terme de sécurité) il y a un large panel de conf a faire dans Postfix pour qu’il rejette les mails/spams/forge etc… avant le traitement de l’antispam ce qui permet de ne pas solliciter les ressources ram et cpu
c’est dans ce sens qu’il faut travailler et “durcir” Postfix. Pourquoi laisser passer du pourriel qui va consommer de la ressource alors qu’il peut etre bloqué avant…?
Il faudrait voir les logs, mais si vous avez laissé les mots de passes d’origine, il y a de fortes chances que admin@domain.tld ait été utilisé.
Le postfix de BlueMind est configuré par défaut de façon à passer les principaux tests. Il est possible par la suite de modifier sa configuration pour la durcir comme vous le souhaitez.
Le problème qui se présente si on configure postfix de façon trop dure d’origine, est que beaucoup de mails légitimes mais plus ou moins mal formés se trouvent rejetés (cas de beaucoup de logiciels métier générant du mail par exemple). Ce qui, pour beaucoup de personnes, amènent à penser que c’est la solution qui ne fonctionne pas bien.
Actuellement il faut modifier la configuration de postfix à la main, mais on peut imaginer ajouter le paramétrage depuis la console d’administration.
Par défaut, Postfix n’est pas openrelay.
Un serveur BM fraichement installé ne me semble pas l’être non plus : le main.cf est réécrit durant le setup.php, et mon intégrateur m’a indiqué qu’il n’y a aucune garantie si j’ajoute quelque chose que cela y reste !
En parcourant le site BlueMind, il n’y a pas de mention d’antivirus/d’antispam, et c’est une question à se poser de base.
Le lien indiqué est très instructif (merci), et je retrouve un certain nombre de règles minimales que je mets dans ‘mes’ smtp-relay (p.e. les smtp_sender_restrictions)
Je suis assez d’accord pour que BlueMind augmente un peu certaines règles assez basiques, mais trouver la limite où s’arrêter n’est pas simple …
Concernant la ré-écriture du main.cf, une fois l’installation réalisée, vous pouvez adapter les directives.
Seules celles gérables depuis l’interface d’administration peuvent-être ré-écrites (relayhost et mynetworks principalement pour l’instant).
Une fois l’installation de BlueMind faites, le mains.cf n’est jamais ré-écrit totalement, il est maintenu à jour via la commande postconf, vous pouvez donc ajouter toutes les directives que vous souhaitez.
Vous pouvez aussi ajouter des maps de transport par exemple, simplement il ne faut pas dé-référencer celles existantes.
Bien sûr, si vous avez un relais de messagerie, il est sûrement plus pertinent que les règles de filtrages soient sur ce dernier.
Il est possible, en déclarant un hôte avec le rôle Relais de messagerie de contôler certains paramètres du relais, notamment en maintenant à jour les map afin de pouvoir rejeter un courrier destiné à un utilisateur inconnu le plus tôt possible.
