Infos sur réglages sécurité d'un serveur de messagerie

[yulpocket]

Bonjour,

 

je sollicite dans ce sujet les compétences d'admins qui ont l’habitude de régler des serveurs de messagerie. Mes notions en la matière étant un peu éloignées, je ne sais pas trop comment aborder le problème.

 

Depuis un moment, les boîtes de mon entreprise se font spammer avec des méthodes vicieuses qui font que le utilisateurs se font avoir.

Grosso modo, les utilisateurs reçoivent des mails venant de boîtes paraissant légitimes prenom.nom@notrenomdedomaine.com

 

Le prestataire qui gère ce serveur tourne et vire sur le sujet sans vraiment m'apporter de solution. Je n'ai pas beaucoup de détails sur la solution que nous utilisons mais à priori c'est du libre :  dspam, dovecot, qmail

 

De mon côté je me suis amuser à faire des tests d'envoi "anonymes".

 

J'ai utilisé un blat.exe et là je suis un peu effrayé puisque en tapant directement le smtp, j'arrive à envoyer des mails à mes utilisateurs en utilisant l'adresse d'un autre. Seul le displayName change mais je comprend que les utilisateurs tombent dans le panneau. Pire, j'arrive à joindre des zip et des exe sans que cela dérange l'antispam.

 

Je ne veux pas me mettre ce prestataire à dos mais je souhaite lui exposer simplement les faits. Je pense qu'il va falloir que je le mette sur la voie...

Est ce que c'est normal que je puisse faire çà et quel réglage peut on faire pour que cela n'arrive plus ?

Est ce qu'à votre sens, ce genre de configuration est professionnelle en sachant qu'on a quand même 1000 boîtes ?

Ce prestataire héberge aussi notre nom de domaine, est ce qu'un paramétrage de spf pourrait limiter le problème ?

 

Merci de vos éclairages.

 

 

[Edtech]

Pour le blocage des exe ou ce genre de choses, c'est normalement faisable côté anti-spam. Rajouter un anti-virus (même si c'est un serveur Linux) peut aussi limiter pas mal les risques.

 

Pour ce qui est de l'usurpation d'adresse, bienvenue dans le monde du mail, ce protocole le plus pourri au monde et pas du tout sécurisé !

 

Seul moyen, chiffrer la connexion au serveur SMTP et interdire les connexions non-chiffrées. Seuls les clients mails ayant accès au certificat de chiffrement pourront envoyer des mails, certificat installé donc sur chaque poste de l'entreprise. Evidemment, si l'usurpation vient de l'intérieur, ça ne servira à rien.

 

Solution supplémentaire : fournir un certificat de sécurité avec chaque adresse et signer tous les mails. Dans ce cas, seuls les mails issues du client mail installé sur le poste de l'utilisateur porteront sa signature et seront donc légitimes. Par contre je ne sais pas si on peut bloquer automatiquement les mails non-signés émis avec une adresse usurpée.

[yulpocket]

Très bien, merci pour ces premières explications. Le déploiement de certificats çà va être un peu compliqué.

 

Donc sans aller jusque là, ne peut on pas exiger quand même une authentification smtp côté serveur (587 de mémoire). Parce que là dans mon blat, je tape juste le smtp de mon fournisseur, aucun login mot de passe, çà envoi direct sur le port 25.

[Edtech]

Ah, oui, c'est vraiment pas sécurisé là, je partais du principe que tu avais au moins ça. Bon, sans chiffrer, pas dur de chopper les accès en sniffant, mais ça serait déjà mieux que rien !

 

Je croyais que seuls les FAI étaient assez idiots pour ne rien demander pour s'identifier auprès du serveur SMTP

 

Que ce soit en 25 ou 587, tu peux demander une identification. Le port 587 est souvent utilisé pour justement contrer les FAI qui, faisant n'importe quoi avec le serveur SMTP, bloquent le port 25 sur leur réseau au lieu de mettre du chiffrement, de l'identification et de désactiver le mode RELAY du serveur SMTP...

[Soltek]

C'est peut-être parce que tu es sur le réseau interne qu'il ne demande pas d'identification car tu dois déjà être authentifié via un LDAP je suppose.

 

Sinon clairement le prestataire ne fait pas son boulot, un antispam ça filtre aussi les PJ.

[yulpocket]

Quand j'ai fait mes tests, j'étais connecté au net via mon smartphone pour justement exclure ce point. Il n'y a pas de liason entre notre annuaire AD interne et notre serveur de messagerie.

 

Si je comprend bien, j'ai donc un truc super basique ouvert aux 4 vents

 

Cà va pas être simple. Dans un premier temps, je vais donc demander un smtp auth obligatoire et une reconfiguration de l'antispam. Après, je pense qu'on va gentillement monter un projet de migration ailleurs....

 

Merci à vous deux.