Black et White listing

[tomtom]

Bien sur qu'il y a un moyen.

Tous les mailers (dignes de ce nom) utilisent une directive permettant de définir les réseaux autorisés à "relayer" (ie envoyer un mail à une adresse d'un domaine non géré par le serveur). Il suffit soit de supprimer le réseau local de la liste de ces réseaux, et activer l'authentification, soit d'obliger l'authentification y compris sur les réseaux autorisés...

A voir sur le smtp de SME mais c'est obligatoirement possible

t.

[Mael]

En fait, la contrib smeserver-fetchmail te permet d'impose r le passage par le serveur SMTP de SME (elle bloque l'accès au port 25 depuis le LAN vers Internet.

Mais dans le cas qui nous préoccupe, elle n'empêche en rien un poste local d'utiliser SME en tant que serveur SMTP.

A+,
Pascal

D'accord mais dans le cas ou un poste est infecté, le plus souvent le malware inclut son propre mécanisme smtp
et n'a pas besoin du SMTP de la SME, d'ou l'utilité de ton option.
Free l'a bien compris en proposant par défaut de bloquer l'accès à tout autre SMTP que le sien pour ses clients. Et non pas en imposant une authentification.

Et dans le cas ou le malware utilise le SMTP de la SME c'est qu'il a récupéré les infos sur le client infecté et là authentification ou pas, il aura accès à tous les paramètres pour se connecter. Certains malwares comportent un proxy SMTP pour remplacer le champ DATA des mails échangés entre le client et le serveur.
Dans ce cas il n'y a pas de parade

Ce qu'il serait intéressant de déterminer dans le cas de pbordere, c'est si les 3000 mails ont été envoyés directement à la SME ou si ils ont juste transité par le proxy SMTP de la SME.

Pour finir dans le cas d'un poste infecté connecté sur le réseau lors d'un dépannage, si l'option de bloquer le port 25 (contrib Sibsib) est activée, je ne vois pas comment le virus/malware peut deviner qu'il peut utiliser le SMTP de la SME, celui-ci étant inconnu au client. Me trompe-je ?

Après en complétant avec une restriction du nombre de mails émis /heure/par client sur la SME ça doit
limiter la casse.

Mael

[jibe]

Salut,

Pour finir dans le cas d'un poste infecté connecté sur le réseau lors d'un dépannage, si l'option de bloquer le port 25 (contrib Sibsib) est activée, je ne vois pas comment le virus/malware peut deviner qu'il peut utiliser le SMTP de la SME, celui-ci étant inconnu au client. Me trompe-je ?

Tiens, ça j'y pensais justement hier soir...

Détaillons mon cas (pour le peu que j'en sais, assez identique à celui de pbordère... il précisera au besoin en ce qui le concerne) :

- Le port 25 n'est pas bloqué : je viens de tester par un telnet smtp.free.fr 25, le smtp de free me répond bien. Je ne savais pas d'ailleurs que la contrib de sibsib pouvait faire ce blocage, et ne sais pas comment le faire (mais bon, doit suffire de lire la doc !)...

- Les mails ne sont pourtant pas partis directement, je pense à cause du proxy transparent de la SME ? J'avais bien 17000 et quelques mails dans la queue de qmail de SME.

- Comme cela me saturait complètement mon serveur et le faisait planter (le proc atteignait des températures record !), je n'ai ni pu ni voulu trop chercher à comprendre. L'urgent était de remettre ma SME en route pour que je puisse bosser... De plus, comme j'avais des mails utiles qui attendaient leur tout pour partir, il fallait au moins que j'identifie ceux déjà partis et ceux encore coincés...

- J'ai supprimé les 17000 mails, presque tous du spam, et tout est rentré dans l'ordre. SME7admin me prévient si j'ai plus de 4 mails en attente, et je n'ai eu depuis qu'une seule alerte suite à un message diffusé par mailman, donc tout est absolument normal.

- Je n'ai aucune preuve que tout ce spam venait de ce poste vérolé, mais tout porte à le croire...

Et dans le cas ou le malware utilise le SMTP de la SME c'est qu'il a récupéré les infos sur le client infecté et là authentification ou pas, il aura accès à tous les paramètres pour se connecter. Certains malwares comportent un proxy SMTP pour remplacer le champ DATA des mails échangés entre le client et le serveur.
Dans ce cas il n'y a pas de parade

Ce que tu dis là m'inquiète beaucoup... Mais je comprends quand même mal comment cela est possible... Le poste infecté étant sous XP, et configuré "normalement", il a obtenu une adresse IP par DHCP, et a ainsi obtenu par la même occasion l'adresse du serveur DNS et de la passerelle. Ok. Mais rien concernant le serveur SMTP ? Les mails ont transité par lui par la fonction proxy transparent, non ? Et dans ce cas, le forçage d'une authentification ne pourrait pas résoudre le problème ? (me restera à trouver comment forcer cette authentification sur SME, mais bon, à partir du moment où je serai sûr qu'elle soit efficace, je devrais bien trouver !

Et cette idée de blacklist ? Il n'y a pas moyen de dire à qmail qu'il ne doit en aucun cas envoyer un mail dont l'expéditeur ne fait pas partie du domaine ? Je pensais d'ailleurs que c'était fait d'office... On refuse le relaying depuis l'extérieur (encore heureux ), mais non seulement on l'autorise de l'intérieur, mais en plus on ne peut pas l'empêcher autrement que par des moyens sophistiqués ? Alors qu'il suffirait d'une règle simple : si la partie d'adresse d'expéditeur après @ n'est pas "mondomaine.tld", le mail part directement vers /dev/nul !

[Mael]

Ce que tu dis là m'inquiète beaucoup... Mais je comprends quand même mal comment cela est possible... Le poste infecté étant sous XP, et configuré "normalement", il a obtenu une adresse IP par DHCP, et a ainsi obtenu par la même occasion l'adresse du serveur DNS et de la passerelle. Ok. Mais rien concernant le serveur SMTP ?

Je parlais du cas ou un client "officiel" du réseau serait infecté, les paramètres d'Outlook express ou Thunderbird étant alors accessible au virus. Dans le cas d'une machine de passage sur le réseau, je suis d'accord avec toi, je me demande bien comment le virus pourrait deviner l'existence du SMTP de la SME.

Les mails ont transité par lui par la fonction proxy transparent, non ? Et dans ce cas, le forçage d'une authentification ne pourrait pas résoudre le problème ?

Ben justement si les mails ont transité par le proxy transparent de la SME, si tu avais activé le blocage
de la contrib de Sibsib, les mails auraient été bloqués par la SME au niveau du poste client vérolé et ne seraient jamais arrivé jusqu'à la queue de la SME. Nul besoin d'authentification.

edité: reformulé

Et cette idée de blacklist ? Il n'y a pas moyen de dire à qmail qu'il ne doit en aucun cas envoyer un mail dont l'expéditeur ne fait pas partie du domaine ? Je pensais d'ailleurs que c'était fait d'office... On refuse le relaying depuis l'extérieur (encore heureux Rolling Eyes ), mais non seulement on l'autorise de l'intérieur, mais en plus on ne peut pas l'empêcher autrement que par des moyens sophistiqués ? Alors qu'il suffirait d'une règle simple : si la partie d'adresse d'expéditeur après @ n'est pas "mondomaine.tld", le mail part directement vers /dev/nul !

C'est pénalisant dans le cas ou tu utilises aussi une autre adresse que celle de ton domaine ( par ex Free, Orange ou autres) et ça n'empeche pas la sortie des spams émis avec ton nom de domaine, les
virus mailer piochant dans le carnet d'adresse, il y a quand meme des chances que celui-ci s'y trouve.

Mael

[jibe]

Ok, je commence à y voir un peu plus clair. Encore une question cependant :

Si j'avais activé le blocage de sibsib, les mails du poste vérolé auraient été bloqués et n'auraient pas rempli la queue de qmail. Je pense que c'est parce que l'envoi se faisait en fait par un SMTP externe ? Mais alors, qu'en serait-il des éventuelles adresses @monfai.tld ? En quoi ce blocage par sme-fetchmail serait moins handicapant qu'un blacklistage ? D'autant que si blacklistage il y a, il pourrait y avoir aussi whitelistage des adresses "extérieures" éventuelles ?

Bon, quoi qu'il en soit, en ce qui me concerne je n'utilise pas d'adresses externes. Donc, je n'ai plus qu'à trouver comment faire le "blocage de sibsib" pour résoudre mon problème ?

[Mael]

Mais alors, qu'en serait-il des éventuelles adresses @monfai.tld ? En quoi ce blocage par sme-fetchmail serait moins handicapant qu'un blacklistage ?

Ton mail de moi@monfai.tld, tu peux l'envoyer avec le SMTP de la SME, rien ne t'oblige à l'envoyer par le SMTP du FAI.

Par contre je viens de refaire des tests sur SME 7.3 avec la contrib de Sibsib et l'option de blocage des SMTP externes a l'air de ne pas s'activer quand on l'applique ???
Ce n'était pas le cas quand j'ai fait des tests il y a quelques temps.

Et par contre la désactivation du STMP proxy par la meme contrib a pour effet de bloquer l'accès
au port 25 excepté pour la SME (but recherché par la précédente option) quel soit le status de la précédente option

Donc Sibsib si tu as infos complémentaires à donner sur le fonctionnement de ta contrib ...


Mael

[sibsib]

Ben en fait, tu as parfaitement décris le comportement de la contrib, et ce depuis le début :

1) Si tu bloques l'accès aux serveurs SMTP externes, seul le serveur SME peut envoyer des mails,

mais

2) Si tu laisses le serveur SME en proxy SMTP transparent, l'effet 1 disparait ! En effet, si un poste interne essaye de connecter un SMTP externe, le flux s'arrête à SME, et c'est ensuite SME qui l'envoie de manière 'digne'.

La combinaison peut choquer. En fait, la contrib permet toute combinaisons, je n'ai pas assez d'imagination pour envisager toutes les idées des utilisateurs

A+,
Pascal

[pbordere]

Bonjour,

Je viens de faire quelques tests depuis un PC connecté sur le réseau local mais "inconnu" de la SME.

Pour cela, j'ai utilisé l'outils "Blat" en ligne de commande.

La configuration de la SME lors du test est :

Code: Tout sélectionner

Le service Proxy SMTP transparent permet de réduire le trafic lié aux virus à partir des hôtes infectés en forçant tout le traffic SMTP sortant à traverser ce serveur. Si vous souhaitez utiliser un autre serveur SMTP, et que ce serveur est votre passerelle vers celui-ci, désactivez ce Proxy.
État du service Proxy SMTP | Activé |


et

Code: Tout sélectionner

Authentification SMTP | Autoriser uniquement SSMTP (securisé) en accès privé et public |

Je n'ai installé aucune contribution relative au mail.

La commande Blat utilisée :

Code: Tout sélectionner

blat mail.txt -to moi@gmail.com -subject Test -server smedubureau -f pbordere@toto.fr -u toto -pw pipo -debug


renvoi :

Code: Tout sélectionner

Blat v2.6.2 w/GSS encryption (build : Feb 25 2007 12:06:19)

<<<getline<<< 220 smeperso.fr ESMTP
>>>putline>>> EHLO P-PBORDERE2
<<<getline<<< 250-smeperso.fr Hi pc-00001 [10.16.95.1]
<<<getline<<< 250-PIPELINING
<<<getline<<< 250-8BITMIME
<<<getline<<< 250 SIZE 15000000
Sending mail.txt to moi@gmail.com
Subject: Test
Login name is pbordere@toto.fr
>>>putline>>> AUTH LOGIN
<<<getline<<< 500 Unrecognized command
The SMTP server does not require AUTH LOGIN.
Are you sure server supports AUTH?
>>>putline>>> MAIL FROM:<pbordere@toto.fr>
<<<getline<<< 250 <pbordere@toto.fr>, sender OK - how exciting to get mail from you!
>>>putline>>> RCPT TO:<moi@gmail.com>
<<<getline<<< 250 <moi@gmail.com>, recipient ok
>>>putline>>> DATA
<<<getline<<< 354 go ahead
<<<getline<<< 250 Queued! 1205074500 qp 12120 <01c881f5$Blat.v2.6.2$dec35cd8$1984e007604@smedubureau
>
>>>putline>>> QUIT
<<<getline<<< 221 smeperso closing connection. Have a wonderful day.


Le mail est bien intercepté par ma smeperso.
L'adresse d'expéditeur bidon (pbordere@toto.fr) ne lui pose aucun problème.
Un envoi d'identifiant et de pwd bidon ne la gène aucunement.

Bizarre, voir même embétant non

[jibe]

Salut,

Oui, pbordere, c'est bien ce que j'ai moi aussi constaté. Seule petite différence, je n'ai pas mis SSMTP mais (parce que...) n'autorise que l'accès privé.

Je ne comprends pas bien ta réponse, sibsib (surtout en constatant ce que pbordere et moi constatons) : cela voudrait-il dire que pour éviter cette situation, nous devrions supprimer le proxy transparent et bloquer l'accès aux SMTP externes ? (qui au passage est trop simple à trouver pour que je puisse le voir Faut que je reprenne rendez-vous chez mon ophtalmo En plein milieu de la page server-manager de ta contrib!!!... Peux-tu le mettre en rouge blinking à la prochaine version pour les bigleux dans mon genre ? )

[sibsib]

Hello,

On est dans le monde du libre : il ne 'faut' rien

Disons que le seul moyen (disponible) d'obliger le passage explicite par le smtp de SME, c'est effectivement de désactiver le proxy transparent, et d'interdire l'accès à d'autres serveurs SMTP.

Mais pour autant, le serveur SMTP de SME ne sera toujours pas en authentification obligatoire.

Ce serait pourtant facile à mettre en œuvre : un seul fichier à modifier, et il est déjà templatisé.

Je pense que la modification du fichier (templatisé, sinon c'est pas drôle)

Code: Tout sélectionner

/service/qpsmtpd/config/relayclients

devrait être la réponse à toutes vos reqûetes.

(Mais alors j'ai pas vraiment les moyens de tester actuellement , désolé).

A+,
Pascal

[jibe]

Salut,

Merci pour tes explications, sibsib. Je crois que je reste bloqué sur un truc : il me parait vraiment inconcevable que SME (distrib parait-il sécurisée !) laisse partir sans broncher 17000 mails de spam et que la seule façon de l'en empêcher soit de mettre les mains dans le cambouis...

Bon, je testerai la modif de ce fichier...

[fred-info]

Salut,

j'ai déjà évoqué ce cas ici http://forums.ixus.fr/viewtopic.php?t=38413&highlight=

et visiblement depuis sme 6 ou 7.3 c'est pareil.

Je ne trouve pas ça normal (sain) non plus. Comme à l'époque seul Pabze avait répondu (au passage merci à lui) je m'étais dit que ça n'intéressait pas grand monde ...

A+

PS: Si j'étais un virus que je récupèrais la config réseau du poste que je vérole j'enverrai directement les mails sur la dite passerelle et dans bien des cas ça passera.

[Mael]

Salut;

Merci pour les détails Sibsib,

Je vais aussi regarder du coté de /service/qpsmtpd/config/relayclients


Mael

[unnilennium]

par defaut la SME mets dans les relay clients tous les postes des reseaux connus, cela authorise la receptions d emails meme sans authentification du client.


pour mes SME sur des sevreurs hebergés j'ai du supprimer le contenu de ce fichier poru eviter de servir de relais spam a tous les autre serveurs de l'hebergeur.

donc c'est bien al bonne cible si vous voulez interdir totu envoie non authentifié via le SMTP de vos machines clientes via le SMTP de la SME.

reste comme precisé plus haut : arreter le proxy smtp et interdire le passage par le port 25... une petite regle iptables .

cependant de cette facon vos client utilisant un smtp tiers avec authentif mais devant passer par ce smtp pour des raison de SPF du domaine seront bloqués, et s'ils passent par le SME verront leur mails noté en SPAM.....

JPP

[jibe]

Salut,

j'ai du supprimer le contenu de ce fichier poru eviter de servir de relais spam a tous les autre serveurs de l'hebergeur.

arreter le proxy smtp et interdire le passage par le port 25... une petite regle iptables .

cependant de cette facon...

si j'étais un virus... ...dans bien des cas ça passera.

etc. etc...

Soit il y a un truc qui m'échappe, soit SME me semble de moins en moins être un bon serveur pour le courrier... Surtout un serveur cencé être "clé en mains" où le firewall est autoconfiguré...