Black et White listing

[unnilennium]

euh preciser quand meme que j'utilise SME chez OVH donc sur un dédié qui a comme seule et unique adresse ip une ip publique.... donc les customisations que j'ai faite ne concernent pas le commun des admins.



et là on est parti sur une demande particuliere qui est empecher tous maisl sortant sans que le client mails soit configuré spécifiquement pour le SME. Ce qui est plsu restrictif que la politique de base SME.

JE n'en vois pas personnellement l'utilité, même avec 450 étudiants derrière le serveur passerelle, et des portables de ces mêmes étudiants. Donc au sein d'une entreprise plutot que de chercher a bloquer les mailbomb eventuelles sur un hypothetique poste en bridant totalement les utilisateurs lambda.. au lieu de chercher la machine fautive quand cela arrive et de l'eradiquer ou de deployer une solution antivirus fiable......

[jibe]

Salut,

JE n'en vois pas personnellement l'utilité, même avec 450 étudiants derrière le serveur passerelle, et des portables de ces mêmes étudiants. Donc au sein d'une entreprise plutot que de chercher a bloquer les mailbomb eventuelles sur un hypothetique poste en bridant totalement les utilisateurs lambda.. au lieu de chercher la machine fautive quand cela arrive et de l'eradiquer ou de deployer une solution antivirus fiable......

Là, je ne comprends vraiment pas ? Bien sûr qu'il vaut mieux traiter le mal à la racine que ses conséquences. Mais c'était bien mon cas : une machine vérolée dans le réseau, non configurée pour SME (comme aurait pu l'être un portable d'un étudiant...) que je cherchais à désinfecter (donc, traitement du mal à la racine). N'empêche que le temps que je trouve la sale bête qui bouffait une bonne partie de son temps CPU, je me suis retrouvé avec 17000 spams bloquant ma SME...

Je suis aussi d'accord qu'il faudrait prendre les choses encore plus à la racine et dire aux gens : f**tez moi cette m*** à la poubelle, et installez Linux. Mais ce n'est pas toujours possible...

Donc, AMHA, on n'a pas d'alternative : un bon serveur de mail ne doit pas laisser partir le spam, au moins pas faire du relaying incontrôlé, qu'il soit interne ou externe. Si on admet comme normal le relaying interne, pourquoi pas alors l'externe ? Il vaudrait là aussi mieux rechercher et éliminer les spammeurs !

[unnilennium]

la machine se connecte au reseau , SME doit faire le dhcp donc elle est configurée pour SME.
en epluchant les logs tu as du trouver l'ip et donc la mac de la fautive, avant de trouver le matos physiquement un ti iptables drop sur la mac et le tour est joué.

[jibe]

Ai-je dit que c'était impossible, voire difficile à trouver ?

Non. J'ai dit que SME est un serveur prêt à l'emploi, que l'esprit SME est que c'est un serveur installable sans connaissances particulières et que les règles Iptables (que l'utilisateur lambda de SME n'est pas cencé connaitre) sont préconfigurées.

Alors, il faut plutôt dire que SME est un serveur réservé à une élite sachant non seulement configurer un firewall, mais faire cela via un système complexe de templates. Donc, en fait, que SME est un bien mauvais serveur, et qu'il faut lui préférer une Debian bien plus simple à mettre en oeuvre et à sécuriser.

De plus, dans mon cas, je fais comment le "drop sur la mac" quand ce sont des machines que je prends en dépannage, et donc qui n'ont jamais la même @mac ? Je leur reconfigure l'@mac, ou je les passe en IP fixe préalablement ? Ou j'adapte mes templates iptables à chaque fois ?

Pas de relaying interne incontrôlé me parait une bien meilleure solution, non ? Si j'ai quelques postes qui doivent pouvoir faire du relaying sur la SME, ils sont connus et donc faciles à déclarer sur la SME, et les autres ne peuvent envoyer de mail que par le SMTP de SME, et donc être dûment configurés...

[unnilennium]

mouai en meme temps tu as une utilisation specifique. Dans la plupart des cas la demande sera j'ai un client qui se connecte avec son laptop et je veux qu'il puisse envoyer ses mails en smtp sans toucher a sa config:

- si habituellement il s'authentifie pour envoyer son mail le proxy joue son job
- si le pc est configuré sans authentif et que le FAI est different que son FAI habituel SME jouele role du SMTP.

dans ton cas ces comportements ne sont pas ouhaitable mais cela ne veut pas dire que c'est le cas des autres.

Et oui effectivementla simplicité /stabilité de certains entraine la complexité pour d'autres. LEs templates entrainent des complication pour customiser. Mais le temps passé dans les templates penses tu qu'il est si important par rapport à un server debian from scratch ?

pour ma part le choix est vite fait !


JPP

[jibe]

Salut,

Oui, je suis bien un peu de ton avis (sinon, que ferais-je chez FreeEOS ? ). Tu sais bien que je joue toujours l'avocat du diable

N'empêche que ton laptop sous W$ est presque inévitablement plein de spywares et autres sales bêtes, et donc mon cas n'est pas si exceptionnel que ça...

Et je ne parle pas de ceux qui mettent de la wifi dans leur LAN et se font pirater leur connexion par leurs voisins...

[sibsib]

Hi, l'avocat du diable

En fait, tu as raison, mais...

By design, SME n'est pas un firewall sortant : SME considère que à l'intérieur, tout il est beau, tout il est gentil.

Donc au niveau client de mail, c'est le même principe.

Maintenant, ta position n'est pas non plus absurde. Mais si la devteam de SME accepte l'idée qu'on peut être amené à fermer des ports dans le sens sortant, ils vont peut-être éviter de le faire pour une seule application : Paraitrait pas non plus débile de bloquer le http, dans ce cas là ! Puis forcément, il va y avoir des raisons -valables !- pour bloquer tout le monde sauf... / pour laisser tout le monde sauf...

Bref, il me semble que ta demande passe par l'intégration dune interface de gestion du firewall, ce qui n'est pas "vite simple et bien".

Maintenant, je pourrais peut-être intégrer ceci à smeserver-fetchmail ? J'ai déjà une règle iptables filtrante en sortie pour SME, il suffirait de simplifier le filtre pour que plus aucune connexion ne soit acceptée sur le port 25 de l'interface interne.

J'enfile ma barbe d'ermite (très peu dispo en ce moment !), et je vais méditer çà...

A+,
Pascal

[unnilennium]

ou une contrib firewall pour ajouter ce types d'options. Y'en a t il pa sune chez dungog dureste ?


JPP

[jibe]

Salut,

Mais si la devteam de SME accepte l'idée qu'on peut être amené à fermer des ports dans le sens sortant...

Je n'ai pas parlé de blocage de port

D'accord avec toi que quand on y met le doigt...

Je pense malgré tout qu'entre n'avoir plus de limite (firewall configurable...) et laisser passer ce qui a rarement besoin de l'être, il y a peut-être un juste milieu... Et je ne pense pas, d'ailleurs, qu'une règle iptables soit le mieux adapté (pas du tout dans mon esprit...).

En effet, depuis le début, je parle d'empêcher de sortir les mails dont l'émetteur n'est pas un utilisateur déclaré sur SME. C'est tout ! Cela n'empêcherait pas le spam sortant s'il a pour expéditeur un utilisateur connu, ce qui est effectivement le cas assez fréquemment lors d'attaques virales. Mais ça limiterait déjà bien les dégats.

Je n'ai pas fait de recherche parmi mes 17000 mails sortants pour voir si certains étaient émis par un utilisateur connu de la bécane que j'avais en dépannage. Mais je suis catégorique sur le fait qu'un bon nombre avaient des expéditeurs totalement inconnus, et je suis assez convaincu qu'il s'agissait là d'une assez grande majorité...

Et, vu qu'il y a beaucoup de postes W$ derrière des SME, je reste persuadé que ce type de filtrage que je réclame serait très utile...

Certes, dans certains cas cela peut être utile que des utilisateurs non connus de la SME puissent envoyer des mails... Mais outre qu'on pourrait désactiver le filtre ou établir une sorte de white list pour les courriers sortants, il y a quelques possibilités de résoudre ou contourner ce problème... C'est ce cas qui est relativement exceptionnel, pas l'envoi de spam !

Bon, je sens qu'il va falloir que j'ajoute sur ma liste de todo la réalisation d'un tel filtre, puisque personne n'a l'air trop convaincu de son utilité. Si j'y parviens (il faut déjà résoudre le plus gros problème : le temps !) je vous donnerai les stats de download et on verra si c'est si inutile que ça

[pbordere]

Salut Jibe,

Mais non tu n'es pas tout seul...
Ayant eu exactement le même problème (l'envoi de mail depuis des comptes inconnus), je pense également que ce genre de fonctionnalité est utile.
Je ne suis pas spécialistes des ptit's sal..eries qui bombardent de mails alors je ne sais pas si la meilleure solution serait d'obliger les clients mail à s'authentifier ou si une white/blacklist d'expéditeurs serait préférable.
Ce qui est certains par contre c'est que je suis intéressé par cette fonctionnalité.

Merci d'avance à celui (ceux) qui nous permettrons d'aller dans ce sens... (à défaut de contrib, comment ont fait à la paluche ?).

[Muzo]

ou une contrib firewall pour ajouter ce types d'options. Y'en a t il pa sune chez dungog dureste ?


JPP

Ca eu existé ... et c'était chez muzo à l'époque ou il avait le temps ...
Par contre les sources sont toujours dispo, pour ceux qui voudrait l'adapter au nouveau script de firewall de SME 7.

/Muzo