Forum Linux.général Postfix : limiter le nombre d'adresse mail source par adresse IP

Posté par .
1
1
mar.
2011

Bonjour faux rhum,

J'ai un serveur dont le rôle est (entre autres) d'intercepter les connexions SMTP sortantes des utilisateurs, et qui fait tourner un Postfix pour ensuite relayer les mails vers leur destination.

Le but est de permettre à ces utilisateurs d'envoyer des mail, mais d'appliquer un filtrage anti-spam pour éviter que l'adresse IP se trouve blacklistée.

Il y a déjà des limites configurées dans Postfix pour restreindre le nombre de mails et de destinataires pour une période de temps donnée. Cependant, ces limites (que je ne peux pas abaisser, sinon elles bloqueront le trafic légitime) font que tous les processus spamd (spamassassin) sont parfois utilisés et les messages en trop passent à travers les mailles du filet.

Une idée de restriction à laquelle j'ai pensé est de limiter pour une adresse IP donnée le nombre d'adresse mail source qu'elle peut utiliser (un client légitime n'utilisera jamais plus de 2 adresses mail sources différentes). Cela aurait pour effet de soulager l'utilisation des processus spamd.

J'ai bien cherché dans la doc de Postfix, celle de postfwd, mais je n'ai pas trouvé comment implémenté un tel filtre.

Quelqu'un a une idée de la marche à suivre pour atteindre ce but ?

Merci d'avance.

  • # un bout de solution

    Posté par . Évalué à 4.

    Cependant, ces limites (que je ne peux pas abaisser, sinon elles bloqueront le trafic légitime) font que tous les processus spamd (spamassassin) sont parfois utilisés et les messages en trop passent à travers les mailles du filet.

    ben augmente les capacités allouées à spamassassin, ou configure le comme il faut comme ca il ne laissera pas filer les emails non scannés

    sinon, ben il te faut coder un smtp, qui va decouper ton email en plusieurs morceaux et les traiter separement

    • [^] # Re: un bout de solution

      Posté par (page perso) . Évalué à 4.

      C'est une blague ?

      J'espère que spamassassin est un processus muni d'une queue, sinon, il suffirait en gros d'envoyer plus de mails d'un coup qu'il y a de processus spamd pour garantir qu'un mail ne sera pas traité par l'antispam ! Et ça, je doute que ce soit le cas…

      • [^] # Re: un bout de solution

        Posté par (page perso) . Évalué à 2.

        Avec dspam, j'ai un problème qui ressemble; si le processus qui qualifie le message -i.e. spam ou non - met trop de temps à repondre, le mail est tout de même délivré sans l'étiquette "spam" ou "ham".

        J'ai partiellement résolu ce problème en déportant la charge SGBD sur une autre machine et je n'ai plus le problème.

        • [^] # Re: un bout de solution

          Posté par (page perso) . Évalué à 3.

          Euh, je te suggère de changer de logiciel alors.
          C'est un comportement que je trouve inacceptable !

          T'imagines un antivirus qui dit "oh, vous faites chier, le fichier est trop gros, je le scanne pas" ? ou « y a trop de fichiers, alors on va dire qu'ils sont tous clean » ?

          • [^] # Re: un bout de solution

            Posté par (page perso) . Évalué à 2.

            Hum je ne pense pas que dspam soit fautif (ni même le MTA) tout simplement un problème de configuration (un timeout à modifier). J'ai préféré changer mon architecture plutôt que passer en mode "trial and error" pour trouver les bonnes valeurs pour les timeout (et/ou le pool de connexions au SGBD).

      • [^] # Re: un bout de solution

        Posté par . Évalué à 1.

        J'ai déjà passé le nombre de processus spamd de 5 à 10. Mais comme tu l'indiques, il suffit d'envoyer plus de mails que ce que peut traiter le serveur pour contourner le filtre anti-spam.

        Postfix utilise un pool de processus spamd pour faire mouliner les mails. D'après ce que j'ai vu c'est le mécanisme habituel, mais je n'ai pas encore fouillé assez pour savoir s'il est possible de mettre les mails dans une queue. Mais cela pourrait ralentir considérablement le délai de livraison des mails.

        Je ne peux pas changer la politique par défaut pour refuser les mails non scannés. En effet, je dois éviter le plus possible de passer à la trappe des mails légitimes (clients business, donc potentiellement susceptibles et exigeant un service mail fonctionnel). De plus, un tel changement ferait qu'un PC infecté envoyant une grosse quantité de spam ferait un dénis de service aux autres utilisateurs légitime du réseau (dont les mails qui n'ont pu être scannés seraient droppés). Le but est donc d'appliquer la restriction en amont de l'anti-spam qui est coûteux.

        Merci.

        • [^] # Re: un bout de solution

          Posté par (page perso) . Évalué à 3.

          il suffit d'envoyer plus de mails que ce que peut traiter le serveur pour contourner le filtre anti-spam.

          Change de logiciel alors. Un filtre qui ne filtre pas, c'est inutile.

          Mais cela pourrait ralentir considérablement le délai de livraison des mails.

          Ça tombe bien, la délivrance d'emails est asynchrone est non-garantie : un email peut mettre deux jours pour arriver, ou même ne jamais arriver, et ça serait complétement normal et acceptable.
          Si tu as des contraintes plus fortes en terme de délais et garantie de livraison, il te faut un autre moyen de communication. Va jeter un œil aux solutions comme AMQP par exemple.

  • # utilise postfwd

    Posté par . Évalué à 3.

    Il offre plein de solution pour limiter le nombre d'envois par heure
    http://postfwd.org/ je l'utilise depuis plusieurs années, il marche trés bien

    • [^] # Re: utilise postfwd

      Posté par . Évalué à 1.

      Justement, j'ai jeté un coup d'oeil à la doc de postfwd, mais j'ai pas trouvé comment limiter le nombre d'adresse mail source par IP.

      Si tu as une suggestion pour la règle à écrire, je t'en serais très reconnaissant.

      • [^] # Re: utilise postfwd

        Posté par . Évalué à 1.

        voici un exemple
        je suis pas sur qu'il corresponde
        on gros je limite le nombre de mail, un mail avec deux adresse (êgale 2 mailz)

        id=RATE01 ; protocol_state==RCPT ; action==rate($$client_address/560/21600/521 Levez les mains de votre clavier vous avez depasse le quota de 450 mails par 6 heures, vous avez un gage!) id=SIZE01 ; protocol_state==END_OF_DATA ; action==size($$client_address/15728640/600/521 Vous envoyez des messages trop gros)

  • # Identification SASL plus vérification

    Posté par (page perso) . Évalué à 3.

    Puisque ton serveur sert en somme de relais, à ta place, je ferais plutôt de l'identification SASL obligatoire. À partir de là, on peut vérifier la correspondance entre le login SASL et l'adresse d'expéditeur, et refuser le message sinon.

    • [^] # Re: Identification SASL plus vérification

      Posté par . Évalué à 0.

      Impossible de mettre un mécanisme d'authentification, je n'ai pas la possibilité d'imposer quoi que ce soit au niveau de la configuration des clients. C'est un serveur SMTP qui se trouve entre des hotspots wifi et internet.

  • # Solution

    Posté par . Évalué à 0.

    Au cas où quelqu'un passerait dans le coin et trouverait cette entrée du forum, voici la solution que j'ai finalement retenue.

    Comme je n'ai pas trouvé de mécanisme dans postfix pour limiter le nombre de connexions par IP, j'ai regardé du côté de Netfilter et c'est là que j'ai trouvé mon bonheur, à savoir le module ipt_recent.

    Ce module me permet de compter le nombre d'établissement de session dans la table conntrack, et d'activer une règle si une même adresse IP la déclenche un certain nombre de fois dans un intervalle donné.

    Voici donc l'ensemble de règles que j'ai appliquées :

    iptables -t nat -A PREROUTING -p tcp -d \! 1.2.3.4 --dport 25 -m state --state NEW -m recent --name spammer --update --seconds 10 --hitcount 3 -j DROP
    iptables -t nat -A PREROUTING -p tcp -d \! 1.2.3.4 --dport 25 -m state --state NEW -m recent --name spammer --set
    iptables -t nat -A PREROUTING -p tcp -d \! 1.2.3.4 --dport 25 -j REDIRECT
    

    Traduction : - je jette tous les paquets initiant une connexion vers le port 25 d'une machine autre que mon serveur, si l'adresse source a initié plus de 3 connexions en 10 secondes (compteur "spammer") - toutes les nouvelles connexions vers le port 25 à destination d'une IP autre que le serveur incrémentent le compteur "spammer" - les paquets vers le port 25 sont redirigés vers le Postfix en local, qui appliquera maintenant tranquillement le filtre anti-spam sans être surchargé.

    Merci à tous pour les suggestions.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.