Imprimer

Policy Daemon

.

Policy Daemon est, comme son nom l'indique, un gestionnaire de politique de messagerie pour Postfix. Il offre les possibilités suivantes :

  • listes grises, blanches ou noires,
  • contrôle du volume par émetteur
  • contrôle de la volumétrie par destinataire
  • prise en compte de pièges à spam
  • prise en compte des données HELO invalides

Cet outil permet donc de limiter le volume des spams et autres virus reçus sur un serveur de messagerie. Une autre note a présenté le principe des listes grises.

Le présent article décrit la version 1 de Policy Daemon. 

Installation de Policy Daemon

La compilation ne pose pas de problème particulier, sauf si MySQL est installé dans un répertoire inhabituel. Dans ce cas, il faut modifier manuellement les premières lignes du fichier Makefile afin de désigner les bons répertoires pour les entêtes de MySQL ainsi que pour les bibliothèques.

Compilation : make build
Installation : make install
Note : il faut être root; le répertoire d'installation par défaut est /usr/local/policyd.
Création de la base MySQL : mysql < DATABASE.mysql
La base créée porte le nom policyd. Si vous souhaitez un autre nom, il faut modifier les deux premières lignes du fichier DATABASE.mysql. Créer un utilisateur ayant tous les droits sur cette base. Nous vous conseillons vivement d'utiliser un autre compte et mot de passe que ceux par défaut présents dans le fichier policyd.conf.


 Configuration du processus

Modifier le fichier /usr/local/policyd/policyd.conf. Les paramètres importants sont

  • l'emplacement de la base MySQL : MYSQLHOST, MYSQLDBASE, MYSQLUSER, MYSQLPASS
  • accessibilité du démon de gestion : BINDHOST, BINDPORT, CONN_ACL
  • mise en cage du démon et limitation de privilèges : CHROOT, UID, GID
  • configuration des fonctionnalités de filtrage : WHITELISTING, BLACKLISTING, BLACKLIST_HELO, BLACKLIST_SENDER, HELO_CHECK, SPAMTRAPPING, GREYLISTING, SENDERTHROTTLE, RECIPIENTTHROTTLE

Mise en exploitation

Il suffit de lancer le processus policyd :

/usr/local/policyd/policyd -c /usr/local/policyd/policyd.conf

Configuration de Postfix

Il suffit d'activer le gestionnaire de politique :

smtpd_recipient_restrictions =
                ...
                reject_unauth_destination
                check_policy_service inet:127.0.0.1:10001
                ...

Dans l'exemple ci-dessus, le démon de gestion de la politique s'exécute sur la machine locale et écoute sur le port 10001 (BINDHOST = 127.0.0.1 et BINDPORT = 10001).

Nettoyage automatique

Policy Daemon insère ses informations dans la base de données. Pour des raisons de performances, il ne fait aucun nettoyage de celle-ci (expiration de données, etc.). Le nettoyage doit être exécuté par un programme annexe, généralement lancé via crontab, par exemple :

0 * * * * /usr/local/policyd/cleanup -c /usr/local/policyd/policyd.conf

pour que le programme de nettoyage soit exécuté toutes les heures.


 

Gestion des listes grises

Voici une note présentant les listes grises de messagerie.

Le comportement des listes grises avec Policy Daemon est contrôlé par les paramètres suivants (définis dans le fichier policyd.conf) :

  • GREYLISTING : activation de la fonctionnalité (1) ou non (0).
  • GREYLIST_REJECTION : message transmis au MTA en cas de rejet pour cause de liste grise.
  • GREYLIST_X_HEADER : ajout (1) ou non (0) d'un entête spécifique dans les messages passant la liste grise.
  • GREYLIST_HOSTADDR : nombre d'octets à prendre en compte dans l'adresse IP du MTA qui dialogue avec nous. La valeur par défaut (3) revient à regrouper tous les MTA d'une même classe C. Nous conseillons d'utiliser la valeur 4 (contrôle sur l'adresse IP complète).
  • TRIPLET_TIME : délai minimal après lequel un triplet sera accepté. Les diverses études et statistiques faites tendent à montrer que 4 ou 5 minutes suffisent.
  • TRIPLET_AUTH_TIMEOUT : durée de validité (en jours, usuellement) d'un triplet accepté, si aucun nouveau message ne vient le rafraîchir. Nous conseillons de lui donner une valeur légèrement supérieure à 30 afin de prendre en compte les listes d'information qui, une fois par mois, envoient un rappel de l'abonnement à la liste.
  • TRIPLET_UNAUTH_TIMEOUT : durée (en jours) au-delà de laquelle un triplet qui n'a pas été validé sera effacé de la base.

Le paramètre GREYLIST_HOSTADDR mérite que l'on se penche un peu dessus. Il définit la longueur (en octets) de l'adresse IP du système émetteur que l'on va utiliser pour contrôler la présence d'un triplet dans la base. Le fonctionnement classique des listes grises procède à un contrôle sur l'adresse IP complète. Imaginons que le domaine émetteur dispose de trois serveurs d'émission, qui se partagent les files d'attente. Un message mis en attente peut dont être réémis par l'un des trois serveurs. Si vous n'avez pas de change, il sera successivement émis par SERVEUR1 (IP1), SERVEUR2 (IP2) et SERVEUR3 (IP3). Chaque fois, le triplet sera différent, puisque l'adresse IP du serveur d'émission ne sera pas la même. Le message sera donc temporisé bien plus longtemps que nécessaire.

GREYLIST_HOSTADDR permet de limiter ce problème, dans l'unique cas où les serveurs d'émission partagent une racine d'adresse IP commune. Il permet de ne faire porter le test non plus sur les adresses IP complète, mais sur les N premiers octets seulement (N étant compris entre 0 et 4). Si les adresses IP des trois serveurs précédents sont, respectivement, 1.2.3.11, 1.2.3.22 et 1.2.3.33, et si GREYLIST_HOSTADDR vaut 3 :

  1. le MX reçoit un message de Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. pour Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser., émis par SERVEUR1. Le message est repoussé, et le triplet (1.2.3.11, Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser., Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.) est mémorisé dans la base.
  2. après un certain temps, le message est réémis par SERVEUR3. Le triplet associé est normalement (1.2.3.33, Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser., Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.). Mais le test ne porte que sur les trois premiers octets de l'adresse IP. Les deux triplets sont donc "identiques", au quatrième octet de l'adresse IP près.
  3. le message est accepté.

Malgré l'intérêt apparent de ce comportement, nous conseillons de maintenir les tests sur les adresses IP complètes, et donc de définir GREYLIST_HOSTADDR à 4 et non pas à la valeur par défaut de 3. Cela pour les raisons suivantes :

  • Le nombre de sites disposant de plusieurs serveurs d'émission est limité. Ce sont généralement de très gros fournisseurs de messagerie (et d'autres services).
  • Dans le cas où un site dispose de plusieurs serveurs d'émission, ils ne sont que peu souvent tous sur des racines d'adresses IP communes.
  • Si plusieurs systèmes d'un même sous-réseau (par exemple les clients d'un fournisseur d'accès) sont infectés du même zombie spammeur, ce qui est une situation loin d'être exceptionnelle, et si chaque zombie émet les mêmes messages (du point de vue des adresses de l'émetteur et du destinataire), votre MX acceptera tous les spams provenant des "voisins" du premier spammeur.

Cela dit... Rien ne vaut une analyse fine des journaux de votre messagerie pour juger de l'intérêt de ce paramètre et de la valeur à lui attribuer.

La fonction de liste grise de Policy Daemon a été activée le mardi de la semaine 34 à 15:30.

Statistiques hebdomadaires

Statistiques mensuelles

Il n'y a guère de doute quant à l'efficacité des listes grises (qu'elles soient gérées via Policy Daemon ou par un autre outil).


Gestion des listes blanches

Les listes blanches permettent d'accepter immédiatement tout message provenant d'un serveur, domaine ou émetteur particuliers. Il va sans dire que ce doit être une fonctionnalité activée avec prudence, notamment si elle porte sur des adresses électroniques.

Les listes blanches reposent sur trois tables différentes :

  • une table d'adresses IP : whitelist,
  • une table de noms de serveurs : whitelist_dnsname, et
  • une table d'adresses électroniques ou de domaines : whitelist_sender.

Chacune de ces tables comporte deux colonnes, la première définissant l'élément discriminant pour la liste blanche, la seconde étant un commentaire libre.

Liste blanche d'adresses IP

La table whitelist permet de définir des adresses IP auxquelles vous faites confiance. Il s'agit de la meilleure utilisation d'une liste blanche (sous réserve que l'adresse IP ne soit pas réaffectée à un autre système que celui auquel vous pensez) :

INSERT INTO whitelist (_whitelist,_description) 
   VALUES ('127.%.%.%','# localhost');
INSERT INTO whitelist (_whitelist,_description) 
   VALUES ('192.168.2.10','# mon serveur');

Les caractères %, dans l'adresse IP, jouent le rôle d'un joker. Dans l'exemple précédent, toutes les adresses du réseau 127.0.0.0/8 (la boucle locale de l'ordinateur) seront traitées de la même manière.

Liste blanche de noms de machines

Il n'est pas toujours facile de connaître les adresses IP exactes des serveurs de messagerie avec lesquels vous correspondez souvent et dont vous êtes certain de l'innocuité du trafic, surtout s'il s'agit des systèmes de sites disposant de nombreux serveurs de messagerie. La liste blanche whitelist_dnsname permet de résoudre efficacement cette difficulté, en indiquant les noms des serveurs et non plus leurs adresses IP.

INSERT INTO whitelist_dnsname (_whitelist,_description)
   VALUES ('n10.bulk.dcn.yahoo.com', '# Un serveur'); 
INSERT INTO whitelist_dnsname (_whitelist,_description)
   VALUES ('%.mweb.co.za','# Tout *.mweb.co.za');

Le premier exemple, ci-dessus, revient à accepter tous les messages émis par n10.bulk.dcn.yahoo.com. Le second exemple utilise un joker, et revient à accepter tout message émis par un système du domaine mweb.co.za. Policyd exécute un contrôle du DNS avant de décider qu'un serveur est ainsi en liste blanche : il est nécessaire que le DNS soit cohérent entre les résolutions directes (nom vers adresse IP) et les résolutions inverses (adresse IP vers nom). En d'autres termes, si un système se présente sous serveur.domaine.tld, policyd fait une résolution de ce nom en une adresse IP puis une résolution inverse de l'adresse ainsi obtenue. Il doit obtenir serveur.domaine.tld, auquel cas seulement il examine la table whitelist_dnsname.

Liste blanche d'adresses électroniques

Cette troisième forme de liste blanche (table whitelist_sender) est la plus risquée, du fait de la facilité à falsifier l'enveloppe d'un message électronique. Elle permet d'accepter tous les messages émis par une certaine personne ou un certain domaine.

INSERT INTO whitelist_sender (_whitelist,_description) 
   VALUES ('camis @ mweb.co.za','# Une addresse');
INSERT INTO whitelist_sender (_whitelist,_description) 
   VALUES ('@mweb.co.za','# Un domaine');

Tout message se présentant comme émis par camis @ mweb.co.za (premier cas) ou par une adresse @mweb.co.za (second cas) sera accepté immédiatement. N'oubliez pas qu'il s'agit d'informations faciles à falsifier.


Contrôle de la validité des bannières HELO/EHLO

Policy Daemon permet de réaliser plusieurs types de tests que la bannière HELO transmise par un serveur de messagerie :

  • contrôle d'une bannière changeante pour un même serveur (Helo Randomization Prevention)
  • contrôle d'usurpation apparente de l'identité de votre serveur (Blacklist Helo)

La phase HELO est la première d'une transaction SMTP. Les deux serveurs en communication se présentent l'un à l'autre :

S: 220 www.exemple.com ESMTP Postfix
C: HELO mon-domaine.com
S: 250 Hello mon-domaine.com

Helo Randomization Prevention

La première fonctionnalité (Helo Randomization Prevention, ou HRP) permet de détecter et de bloquer les serveurs qui se présentent sous des identités différentes.

Un serveur de messagerie est rarement schizophrène, et se présente donc toujours sous la même identité. Il peut arriver qu'il change d'identité suite à une modification du DNS, une réorganisation du réseau de l'émetteur ou d'autres événements de ce genre, mais ce sont des situations rares. Il se peut aussi que l'émetteur dispose de plusieurs serveurs d'émission de messages qui tous vont se présenter sous le même nom. Dans ce cas, vous aurez plusieurs adresses IP différentes associées au même nom, mais chaque serveur (identifié par son adresse IP) n'utilisera qu'un seul nom.

Par contre, les spammeurs peuvent utiliser les mêmes machines (mêmes adresses IP) en leur donnant des noms plus ou moins aléatoires. HRP détectera ce type de situation, et les bloquera rapidement.

  • HELO_CHECK : active (1) ou désactive (0) la fonctionnalité HRP
  • HELO_MAX_COUNT (10 par défaut) : nombre maximal d'identités différentes (chaînes HELO différentes) tolérées pour une même adresse IP. Au-delà de cette valeur, le système émetteur sera bloqué.
  • HELO_BLACKLIST_AUTO_EXPIRE (14d par défaut) : durée de blocage d'une adresse IP ayant présenté plus de HELO_MAX_COUNT identités différentes. Cette durée est comptée à partir de la dernière tentative d'envoi d'un message par le système concerné. Si cette durée vaut 0, l'information n'expire jamais.
  • HELO_AUTO_EXPIRE (7d par défaut) : délai au-delà duquel une adresse IP sera retirée de la table de vérification. Comme pour le paramètre précédent, ce délai est décompté à partir du dernier message reçu depuis cette adresse. Si ce paramètre vaut 0, le délai est infini.

Nous vous conseillons, du moins dans un premier temps, de laisser le paramètre HELO_MAX_COUNT à sa valeur par défaut (10), même si celle-ci paraît élevée. Elle ne doit en aucun cas être inférieure au nombre d'identités différentes qu'un serveur légitime avec lequel vous communiquez peut utiliser. Après quelques temps d'utilisation, vous pourrez déterminer la valeur la plus appropriée pour vous.

Helo Blacklist

Cette fonctionnalité de liste noire permet de bloquer immédiatement les systèmes se présentant sous l'identité de vos propres serveurs. Si votre serveur se nomme par exemple emetteur.mon-domaine.tld, aucun autre MX ne doit se connecter à votre serveur en se présentant sous l'identité emetteur.mon-domaine.tld. Pour être plus précis, tout système se connectant à votre serveur de messagerie en se présentant comme votre serveur de messagerie est très certainement un émetteur de spam ou un système piraté.

  • BLACKLIST_HELO : active (1) ou désactive (0, par défaut) la liste noire d'identités
  • BLACKLIST_HELO_AUTO_EXPIRE : durée de blocage d'un système s'étant présenté sous l'une des identités interdites. Si ce paramètre vaut 0, le blocage est définitif.

La liste noire d'identités doit être définie à l'aide de la table blacklist_helo. Chaque élément de cette table ne contient qu'un seul champ (_helo), indiquant une identité proscrite (en cela qu'il s'agit de l'identité de votre propre serveur). Il est nécessaire de remplir cette table avec les informations appropriées, par exemple :

INSERT INTO blacklist_helo (_helo) VALUES ('192.168.1.25');
INSERT INTO blacklist_helo (_helo) VALUES ('[192.168.1.25]');
INSERT INTO blacklist_helo (_helo) VALUES ('localhost.machine.com');
INSERT INTO blacklist_helo (_helo) VALUES ('localhost');

Avec ce qui précède, tout serveur se présentant, durant la phase HELO, comme 192.168.1.25, [192.168.1.25], localhost.machine.com ou localhost sera automatiquement bloqué.