Forum général.cherche-logiciel Probléme de flooding ?

Posté par  .
Étiquettes :
0
22
août
2006
Bonjour à tous,

Depuis plus d’une semaine nous galérons sur un problème majeur sur notre plateforme externe (hébergée en DMZ) de messagerie. Nous travaillons sur une debian sarge 3.01 [2.4.27-2-386]. Nous avons suivi la procédure : http://workaround.org/articles/ispmail-sarge/ qui fonctionne parfaitement. Ce serveur de messagerie reçoit des mails en provenance d’internet (MX hébergé chez Cegetel) et de l’intranet au travers d’une passerelle. Celle-ci centralise les demandes SMTP, POPS et IMAPS qui sont envoyées vers le serveur de messagerie externe. En externe, chaque PC effectue ces demandes lui-même en utilisant un client de messagerie. Aucun problème sur les clients externes qu’ils soient Outlook ou autres.
En revanche, toutes les environ 11 minutes, le serveur de messagerie refuse les demandes en provenance de la passerelle pendant 1 minute ; en fonction du traffic intense entre la passerelle et le serveur de messagerie le délai de 11 minutes décroit et la durée de blocage passe à 2 voire 3 minutes.
Une analyse des paquets transitant entre la passerelle et le serveur de messagerie nous apprends qu’il refuse systématiquement tout le traffic IP en provenance de la passerelle (SSH, SMTP, SMTPS, POP3, POP3S, IMAP, IMAPS) seul le protocole ICMP est opérationnel. Chaque demande de SYN de la passerelle se solde par un RST ACK de la part du serveur de messagerie.
Pendant le blocage sur le serveur de messagerie, en effectuant un TCPDump nous ne voyons pas passer les demandes en provenance de la passerelle par contre celle en provenance des autres clients tout est OK.
Ce problème n’est visiblement pas au niveau applicatif (PostFix) puisqu’il répond parfaitement aux demandes externes, le filtrage s’effectue uniquement sur la passerelle qui est le concentrateur de l’ensemble des requêtes TCP du LAN (300 users).
Nous pensons que le problème ce situe au niveau de la couche réseau (/etc/network/option spoofprotect = no), les flags sysctl (rp_filter et tcp_syncookies) sont à 0. Le nombre de paquets SYN en provenance de la passerelle à un instant donné peut être relativement très important (20/s).
L’IPTable est provisoirement désactivé en policy access.


Comment activer les logs sur la fonctionnalité de spoofing de la carte réseau ?
Quelle variable doit-on modifier pour inhiber l’option de spoofing en provenance d’une adresse (par exemple la passerelle) ?


Merci pour votre aide.
  • # chiffres exacts

    Posté par  . Évalué à -2.

    Et pendant le blocage, le serveur de mail donne quoi pour :

    netstat -an | grep ESTA | wc -l

    netstat -an | grep WAIT | wc -l

    netstat -an | grep SYN_RECEIVED | wc -l
    • [^] # Re: chiffres exacts

      Posté par  . Évalué à 1.

      Avant la coupure :

      14:35:23
      WAIT :
      13
      ESTA :
      7
      SYN :
      0


      A la coupure :

      14:35:29
      WAIT :
      13
      ESTA :
      8
      SYN :
      0


      Donc rien de bien spéciale ....
      • [^] # Re: chiffres exacts

        Posté par  . Évalué à -2.

        Faudrait vérifier si c'est du FIN_WAITx ou du CLOSE_WAIT, mais on peut supposer que les ressources des sockets sont bloquées en CLOSE_WAIT et le nombre de childs pour postfix est à 20. (Firewall mal configuré sur les clients ? Clients qui plantent ?) D'ou le passage à 19 et le rejet au dessus de 20 connexions ESTA + WAIT.

        Soit augmenter default_process_limit dans /etc/postfix/main.cf
        Soit passer postfix via inetd / xinetd avec l'option nowait

        Voir aussi en diminuant le tcp_keepalive_intvl.

Suivre le flux des commentaires

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