Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Postfix Bannir les ip via iptable
Bonjour.
Je compte bannir les ip des serveur qui s'amuse a tenter d'envoyer ou simplement de ce connecter / déconnecter, etc, etc.
Il suffi donc de lire le log de postfix, de rechercher le mots clef ,par exemple : reject
de récupérer l'ip et de la bannir dans iptables.
Mais est-ce conforme ?
Est-ce que je risque de me retrouver sur les liste noire ?
Il y a une rfc quelque par (en français) sur le sujet ?
Merci de m'avoir lu.
Salut,
C'est quand même toi le propriétaire et l'admin de ce serveur, non ?
A ce titre, tu bannis qui tu veux
Steph
Suite avec une conversation autre que sur le forum, il faut bannir que les erreur de login, pas les serveur distant. car on peux effectivement ce trouver blaklister pour non respect de la rfc, car le serveur doit absolument indiquer pourquoi la connections est refusée, et permettre ainsi aux demandeur de fermer sa connections.Envoyé par IP_Steph
Salut,
C'est quand même toi le propriétaire et l'admin de ce serveur, non ?
A ce titre, tu bannis qui tu veux
Steph
On comprend donc mieux pourquoi les spam passe sans problème.. le seul moyen de lutter reste donc une liste grise ou les black list.
En plus bannir des fai (qui on donc des gros serveur de mail..) nous isole donc c'est pas la solution. je comptait cependant bannir juste 1 minute le temps que le spammeur passe son chemin.
donc non on peux pas bannir un serveur, par contre une mec qui tente un brute force en tentant de ce loguer pour envoyer du spam, c'est permis.
oui oui j'ai chercher
OK.
Alors envisageons le scenario suivant : je suis admin d'un serveur Postfix dans une société qui ne veut pas permettre à ses utilisateurs d'aller sur Yahoo, Gmail et compagnie. Parce que mon boss estime que c'est du mail perso et que les gens n'ont qu'à faire ça chez eux ou depuis leur pda.
Je vais donc bien devoir blacklister des serveurs, et même carrément des domaines ?
Steph
Tu doit rejeter les messages, et permettre la connections de ce terminer ,et indiquer pourquoi.
bannir avec iptable. tu n'indique pas pourquoi, et tu empêche de fermer la connections !
Si une RFC impose de dire en SMTP pourquoi on rejette un message, je comprends, OK...
En revanche, il est tout à fait possible de rejeter une connexion TCP entrante au travers des iptables "de façon propre" (on envoie un TCP FIN).
Steph
Vu que c'est lié à une activité "non conforme", tu peux dropper les trames sans problème et si j'ai bonne mémoire c'est préférable vu que le drop induit moins de charge pour le firewall que le reject.
As tu un exemple de syntaxe d'iptable, je sais insérer des règle , mai fouiner dans les paramétrer c'est pas ma tasse de thé.
ou est-ce que je pourrait posé la question de manière officiel , j'entends quelqu'un a bien l'autorité de contrôle ? (question certainement pas très perspicace mai bon.)
Merci de m'avoir lu.
même si c est non conforme , le coupable doit savoir le pourquoi. donc
Pour « non respect de la RFC », je ne crois pas qu'il y ait une RFC explicite qui traite de ce point en particulier (c'est quand même possible, cela dit, mais il y en a tellement). Pour « non respect de la netiquette », par contre, c'est tout-à-fait probable. La netiquette n'a jamais été formalisée nulle part à ma connaissance. Cela dit, il s'agit essentiellement de règles de bon sens et de bonne conduite.
L'essentiel à garder à l'esprit est qu'il faut préserver la neutralité du réseau, autant que possible. Donc bien faire le distingo entre les voies et les services disponibles, et ceux qui les utilisent potentiellement abusivement.
Non. Le problème du spam est essentiellement technique : il n'y a rien dans un mail indésirable qui nous indique qu'il s'agisse en soi d'un spam et pas d'un courrier légitime. Il faut donc « entraîner » un robot à les reconnaître mais cela ne restera que statistique : tu n'obtiendras jamais 100 % de réussite ni 0 % de faux positifs.On comprend donc mieux pourquoi les spam passe sans problème.. le seul moyen de lutter reste donc une liste grise ou les black list.
Le deuxième problème est qu'il y a une grande différence entre un fournisseur d'accès et son utilisateur. Ce n'est absolument pas au FAI de brider une connexion si l'utilisateur ne lui a pas demandé de le faire. Et ça, malheureusement, ce n'est pas clair chez tout le monde.
Côté utilisateur, il deux façons de voir les choses : soit tu considères que c'est un usager individuel et donc que tout ce qu'il y a derrière son adresse IP est privé, soit que c'est quelqu'un qui se relie au réseau et en fait donc partie intégrante, donc être public par définition. Dans les faits, ça ne change pas grand chose : s'il n'y a pas de serveur exécuté sur la machine en question, elle ne répondra de toutes façons pas.
Mettre en place des dispositifs de protection temporaire contre les gêneurs ou les situations anormales relève du bon sens, à mon avis. Les seules choses auxquelles il faut que tu veilles sont :En plus bannir des fai (qui on donc des gros serveur de mail..) nous isole donc c'est pas la solution. je comptait cependant bannir juste 1 minute le temps que le spammeur passe son chemin.
— Mettre en place une whitelist qui sera examinée en priorité. Sinon, tu risques de te faire auto-bannir par ta machine sans pouvoir y accéder pour y remédier ;
— S'assurer que toute exclusion automatique est temporaire et que chaque entrée de ta blacklist est accompagnée d'une date d'expiration. D'abord, parce qu'autrement, tu risques de te retrouver avec une blacklist vraiment très longue, ensuite parce que quelqu'un pourrait se servir de cette propriété pour faire blacklister des personnes légitimes, ce qui s'apparenterait à une attaque type déni de service, mais indirecte.
Ce dernier point est également important sur le plan éthique, d'abord parce qu'on a le droit à l'erreur. Une personne qui s'est mal conduite doit pouvoir rentrer dans le droit chemin, surtout si c'est involontaire et ensuite parce que le « refus de service » en soi est très mal perçu quelque soient les « sphères » concernées : du temps du Minitel, par exemple, France Télécom était assez sévère avec les services dont le code était référencé mais ne répondait pas.
Merci pour ces précisions.
Mon anglais est pas très bon ,
mai voila le lien:
http://www.ietf.org/rfc/rfc2821.txt
Le ban verrouille la réponse, donc c'est pas conforme.When an SMTP client has a message to transmit, it establishes a two-
way transmission channel to an SMTP server. The responsibility of an
SMTP client is to transfer mail messages to one or more SMTP servers,
or report its failure to do so.
il reste cependant possible a mon avis de bannir via l'ip si le gêneur insiste de manière temporaire. si la durée dure moins d'une 1-2 min sa ne devrai pas être trop gênant pour ceux qui ce serai pris dans les mail du filet suite a une fausse manip.
ça va surtout ralentir celui qui s'acharne sur le serveur qui a chaque tentative doit attendre 1 a 2 min
Ce sont les spécifications du SMTP, en particulier (le protocole d'envoi d'e-mails). La section que tu cites se traduit par :
Ça n'a donc rien à voir en soi avec le ban. En outre, un serveur SMTP peut très bien être lui-même dans l'incapacité de remplir la requête du client, par exemple parce qu'il est en maintenance, ou tout simplement parce que les adresses des destinataires sont invalides. Le serveur renvoie alors un code d'erreur et le client courrier doit en principe prévenir l'utilisateur que l'envoi n'a pas marché, ce qu'il fait.
Être banni fait tout-à-fait partie des raisons valables de ne pas transmettre un courrier. Le serveur SMTP a tout-à-fait le droit d'opposer au client un code d'erreur spécifique du style « 571 Casse-toi » au client.
Ensuite, ça, ce sont les spécifications du SMTP en particulier. Ouvrir une connexion fait partie du niveau juste en dessous. Et si tu n'as pas envie de voir quelqu'un se connecter à ta machine, tu es encore chez toi.
C'est de la même façon que personne ne t'oblige à répondre lorsque quelqu'un te téléphone.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager