Contacter Assist MOA !
Si vous disposez d'une plate-forme de messagerie conséquente, n'hésitez pas à demander une vue extérieure pour des conseils ou un audit de situation : Assist MOA peut vous apporte r son expertise !
Détection des usages abusifs En 2001, il développe en C via des extractions de la console du produit de messagerie N-PLEX d'ISOCORE des logs d'activité en terme de connexions et via un moteur de règle, il déterminait en temps réel les mauvais usages (consommateurs de bande passante, émetteurs de virus, PC zombies, mail bomber, aspiration d'annuaire, attaques par rebond, syn flood attack, ...) et fournissait les premiers éléments à la cellule Abuse pour stopper les abonnés , les informer et les aider, et ce pour le bien de tous (pour eux comme pour la plate-forme). A la migration intégrale de la messagerie en infogérance début 2003 sur du Postfix/Cyrus, Wanadoo a fait constater à son prestataire l'importance majeure de la sécurisation et de la robustesse de la plate-forme de messagerie. En effet, avec la montée en gamme de l'ADSL et l'explosion des débits, quelques PC "vérolés" pouvaient chacun émettre bien plus de 100 000 messages par heure (128000 bits / 8 = 16 000 octects / sec => jusqu'à bien plus que 50 messages par seconde, 3000 messages / minute, 180 000 messages / heure ). En conjuguant alors plusieurs mauvais usages apparaît une possibilité d'atteindre une crête d'usage du serveur et de le bloquer (bourrage de la file d'attente , etc.). Il est donc nécessaire voire vital de stopper ces usages au plus tôt ou au pire, de savoir y résister. Plusieurs techniques existent : certains produits de messagerie permettent en temps réel une extraction de valeurs (nombre de connexions, messages / IP, etc.) mais ça n'est pas le cas de Postfix par exemple. Aussi, il ne reste plus que l'analyse des logs. En agrégeant dans les logs, un nombre conséquent de champs (IP, nombre de messages, temps de connexions, volume en octets, détecté comme spam ou pas, détecté comme virus ou pas, taux d'erreurs sur les destinataires, etc.), on peut définir une application qui appliquent des règles de détection. Architecture, paramétrage et robustesse L'architecture mise en oeuvre joue considérablement sur les capacités de traitement d'une plate-forme pour un même produit et un nombre donné de serveurs. Il y va aussi de sa robustesse aux reprises suite à incident ou aux attaques. La limitation manuelle ou idéalement automatisée du nombre de connexions par IP est une obligation en cas de reprises pour éviter d'avoir à gérer sur la plate-forme l'engorgement (le principe qui veut que les autres MTA auront conservé pour vous chacun une parcelle des messages qui vous sont destinés et chacun de ces MTA va bien sûr les envoyer dès qu'il en aura l'occasion, "bourrant" alors votre système !). Le paramètre TCP_keep_alive donne la durée de vie d'un paquet TCP. Nombres d'attaques proviennent de PC zombies qui rament et ont une connexion internet défaillante. En "tunant" le système, en abaissant notoirement ce délai à 10 secondes ou moins, on se prémunie contre toutes ces connexions pendantes inutilisées car ne mettant pas en oeuvre d'échanges réels mais consommant une ressource : une partie de la stack TCP/IP. Il faut surveiller les effets de bords sur les produits (bug postfix notamment). Pour éviter la propagation de messages à destination de BALs en over quota, il faut remonter au niveau des MTA frontaux, cet état de la BAL : en effet, nombre de BALs en over quota sont soit la cible de spam, soit utilisées en attaque par rebond; l'attaque par rebond consiste à "bourrer" des centaines de BALs avec des messages émis soi-disant à partir d'une BAL donnée (X par exemple). Comme le protocole SMTP et a fortiori les DSN (Delivery Status Notification) font qu'il y a un message retour obligatoire pour une erreur de transmission au destinataire, quand vous absorbez ces messages à destination d'une BAL en overquota... vous allez avec un système très performant renvoyer des avis de non remise à destination de la BAL x (il peut y en avoir plusieurs). Le système qui gère la BAL X risque de ne pas résister très longtemps si vous disposez d'une bande passante et d'un nombre de serveurs conséquents... le systèmes gérant la BAL x est souvent écroulé sous l'attaque et par rebond, vous vous retrouvez à gérer les messages à destination d'un système qui est "mort" et ne répond donc plus ! Il faut donc aussi trouver une parade à la gestion des messages à destination de systèmes ne répondant plus : les serveurs de déroutement. Vous transmettez idéalement automatiquement les DSN et les messages à destinations de domaines ne répondant pas vers un système tiers. Cela permet de nettoyer le flux des mauvais messages, ceux qui prennent beaucoup de temps à être tranmis (connexions pourries, systèmes plantés...) et qui, au final, représente un temps de traitement conséquent et consomment des ressources conséquentes aussi. Ainsi, si d'aventure, un Hotmail , un AOL ou on-ne-sait-qui est planté ou vous blackliste, vous ne pourrirez pas votre flux principal, mais l'aurez dérouté vers vos serveurs de déroutements qui seront paramétrés spécifiquement pour gérer des domaines en difficulté (TCP-keep-alive supérieurs, délais de retransmission réduit, taille des spool * 10 par rapport à un serveur habituel, etc.). Paramétrer un serveur selon son usage, et donc le spécialiser peut apporter une très forte capacité de traitement pour un type de flux donné : jouer sur les architectures, IN, OUT, les spécialisation et le paramétrage dédié permet d'éviter les intéractions et surtout de résister mieux en cas de surchage, d'attaques ou de plan de reprise. Il existe bien sûr nombre d'actions à mettre en oeuvre sur les systèmes de messagerie gros volumes ! Expertise, audit, Plan de Reprise d'Activité et suivi de plate-forme De par son expertise, Assist MOA est à même de vous assister en auditant votre système de messagerie et déterminer si ses pratiques peuvent s'appliquer et apporter une valeur ajoutée à votre plate-forme. Assist MOA peut déterminer des axes d'améliorations à plus ou moins long terme, en jouant sur les produits, les architectures, les paramétrages, les procédures de gestion et de PRA.
Expertise en messagerie SMTP
Plongé dans le monde de la messagerie SMTP dès 1999 au GIE SESAM-VITALE, Thomas FRALIN développe une expertise sur les RFC et fort heureusement, celles-ci n'ont que peu évolué ou pas évolué dans leurs bases sur les protocoles SMTP, POP3, DSN, etc. Il diagnostique alors nombre d'incidents sur les structures des messages et sur le non respect des protocoles (le réseau sésam-vitale véhicule les flux de santé sur de la simple messagerie SMTP avec le respect des RFC sur les Delivery Status Notifications / DSN). Ensuite, travailler au sein de Wanadoo de 2001 à 2005 lui a permis d'accéder à une vraie plate-forme de messagerie évoluant pour atteindre plusieurs dizaines de millions de BALs (Boîtes Aux Lettres).
Accueil Les prestations Présentation générale Assistance à maîtrise d'ouvrage Suivi de production Conseils sur les infogérances Expertise en messagerie SMTP Visibilité WEB CV et exp. professionnelle Liens partenaires ContactsRechercher sur le site :
Thomas FRALIN Freelance Informatique à votre service + de 10 ans d'expérience : assistance à maîtrise d'ouvrage, direction et gestion de projets, suivi de production, exploitation, expertise...
Assist MOA - freelance info
Copyright 2009
ASSIST MOA - SARL au capital de 300 euros - Freelance informatique
Contacts