> Mobilité > Optimiser le filtrage du spam sous Exchange 2003

Optimiser le filtrage du spam sous Exchange 2003

Mobilité - Par Thierry Deman - Publié le 24 juin 2010
email

En effet, la plupart des administrateurs ne configurent pas ce filtrage ou se reposent uniquement sur des outils complémentaires payants. Ces outils sont très efficaces, mais fonctionnent souvent après coup, c'est-à-dire après avoir reçu les messages. Nous allons donc passer en revue les différentes possibilités de filtrages que l’on peut utiliser d’origine.Le filtrage des messages peut s’effectuer sur différents points.

• La zone « Expéditeur » vide
• Les expéditeurs en fonction de leurs adresses de messagerie
• Les domaines DNS sources.
• Les adresses IP et réseaux IP
• L’objet et le contenu des messages ne pourront pas être testés directement, mais serviront à l’outil IMF afin d’évaluer chaque message.

La première étape permet de régler les 3 premiers points.

• dans le gestionnaire système, les paramètres globaux, choisir propriétés sur les remises des messages.
• Cocher la case « filtrer les messages sans expéditeurs »
• Utiliser le bouton « Ajouter » pour insérer toutes les adresses connues ou détectées comme émettrice de messages inutiles ou dangereux.
• De la même manière, ajouter les domaines DNS complets sous la forme « *@Domaine.extension ».

L’ajout des domaines de fournisseur Internet n’est pas une bonne idée (*@free.fr , *@yahoo.fr, par exemple) car il serait étonnant qu’aucun contact existant ou à venir de l’entreprise n’ait sa messagerie chez l’un de ces fournisseurs. Voir figure 1.

Il est important d’avoir activé les filtres au niveau de chaque serveur virtuel SMTP qui connecté à Internet. Cette première étape ne filtre les messages qu’après la remise des messages. La 2ème étape du filtrage consiste à filtrer les messages au moment de la connexion.

En effet, si certains sites provoquent des problèmes trop gênants pour l’utilisation normale par l’engorgement et le quasi-blocage, il est important de bloquer dès la connexion les serveurs émetteurs posant problème. Au niveau des serveurs virtuels SMTP recevant les connexions externes, il est possible de bloquer les adresses IP et les domaines desquels on ne veut plus recevoir aucun message. Dans les propriétés du serveur virtuel SMTP, aller sur l’onglet « Accès » puis cliquer sur le bouton « connexion. Le mode « Tous sauf » permet d’accepter les connexions anonymes sauf pour les sites précisés ! Voir figure 2.

Indiquez les adresses IP, et les étendues de réseau ou domaine dont il faut refuser la connexion. Veillez à ne pas filtrer une adresse IP dynamique ou un domaine d’un fournisseur d’accès. Filtrer les connexions de cette manière suppose que l’on a subi une gène « avérée » provenant d’une source identifiée.

Une méthode complémentaire plus douce, complète et surtout dynamique consiste à configurer le filtrage en temps réels, c'est-à-dire basé sur les fournisseurs de listes noires (RBL).

Optimiser le filtrage du spam sous Exchange 2003

Le filtrage des connexions permet d’interdire les connexions en fonction du domaine ou de l’adresse IP du site émetteur.

Le fait d’interdire la connexion signifie que l’on ne pourra plus recevoir aucun message (bon ou mauvais) provenant de l’adresse IP du domaine indiqué. Cette dernière solution (extrémité) ne doit être prise que lorsque le site émetteur est manifestement la cause de vos problèmes, et que l’adresse IP appartient bien à ce domaine.

Il est inutile de bloquer une adresse IP dynamique (obtenue par DHCP) ou tout un domaine précis (style hotmail.com, msn.com,…). En effet, ceci a généralement pour effet de bloquer globalement (et sans que cela se voit) une quantité de messages « normaux ». Les utilisateurs s’aperçoivent généralement très vite de ce genre de problème!!! De même, bloquer l’adresse IP d’un serveur de relais SMTP est aussi une très mauvaise idée.

Pour résoudre ce type de problème, la solution est de se baser sur des fournisseurs de « listes noires » (Blacks lists dites « RBL »). Différentes solutions gratuites et payantes existent sur Internet, permettant d’interroger par DNS des serveurs qui mettent régulièrement à jour 2 types de listes :
• les serveurs « reconnus » comme étant source/responsable de SPAM
• les serveurs « suspectés » de SPAM

La configuration du serveur virtuel SMTP de Exchange permet de définir l’utilisation de un ou plusieurs fournisseurs de RBL. Selon le fournisseur, il est possible de configurer le refus de connexion pour l’un ou les 2 types de serveurs.

• La configuration principale s’effectue dans les paramètres globaux du gestionnaire système d’Exchange. Dans les propriétés de la Remise de message, sur l’onglet Filtre de connexion, vous pouvez ajouter un ou plusieurs fournisseurs de « listes noires ». Nous allons utiliser le fournisseur http://sbl.spamhaus.org qui est un bon exemple. Indiquer son nom SpamHaus, son suffixe de domaine sbl-xbl.spamhaus. org. Par défaut, tout code de retour « anormal » indique que le site sera filtré et que la connexion sera refusée. Le code se présente sous la forme d’une adresse IP, certains fournisseurs peuvent prévoir un code spécifique : 127.0.0.2 à 127.0.0.4 pour SpamHaus.org. Il se peut que certains fournisseurs nécessitent la configuration d’un code de retour précis Configurer plusieurs fournisseurs ne pose pas de problème, mais attention à la baisse de performance possible, et au fait que tous les fournisseurs ne sont pas gratuits. Le site http://www.spam-blockers.com/ SPAM-blacklists.htm en propose un certain nombre. Pour éviter les problèmes de filtrage inutile, il est prudent d’ajouter les réseaux IP et/ou les domaines à partir desquels celui-ci est inutile.

• La suite de la configuration consiste à activer le filtrage au niveau de chaque serveur virtuel SMTP. À partir de l’onglet Général, cliquer sur le bouton Options avancées, cliquer ensuite le bouton Modifier et cocher la case Appliquer le filtre de connexion. Si le serveur virtuel SMTP fonctionne sur plusieurs cartes réseaux ou adresses IP, il est possible de différencier le filtrage. Dans ce cas, le conseil est d’activer le filtrage sur une carte réseau réservée à la communication Internet, et de le désactiver sur les autres. Comme pour la plupart des modifications de configuration, il est prudent de réinitialiser le service SMTP pour s’assurer de l’utilisation des nouveaux paramètres. Pour vérifier le filtrage mis en place, il suffit d’envoyer un message à l’adresse nelson-sbl-test@crynwr.com. Il s’agit d’un robot qui vous enverra un message de test. Si vous ne recevez qu’un seul message, le filtrage est correctement mis en place. Le message contiendra notamment la ligne suivante : “has been blocked by spamhaus.org”. Si vous recevez 2 messages dont un qui contient Uh-oh, your SBL block is not working!, la configuration n’est pas correcte (vérifier les activations et l’adresse DNS utilisée). Ce test NE VERIFIE PAS l’aspect RELAIS qui lui peut très bien rester ouvert. Attention, ceci ne veut pas dire qu’il n’y aura aucun « SPAM » et encore moins aucun virus, mais cela permettra de diminuer de manière significative (et pour tous les utilisateurs) un certain nombre de messages non sollicités. À noter que pour les organisations importantes, il est possible de demander la synchronisation du DNS contenant les « listes noires » afin d’accélérer les recherches DNS (se renseigner chez les fournisseurs d’accès à Internet !).

Ces filtrages de connexions fonctionnent principalement lorsque c’est le serveur virtuel SMTP qui reçoit la connexion depuis Internet ou que ISA est utilisé avec l’option « garder l’adresse initiale ». Si vous avez un relais SMTP sur votre réseau, c’est au niveau de ce relais que doivent être configurées ces restrictions.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Mobilité - Par Thierry Deman - Publié le 24 juin 2010