Amavis et Sympa

Amavis, anti-virus messagerie:
expériences, intégration avec sympa
J.Beigbeder, 1 mars 2001

Ce document est basé sur mon expérience depuis juillet 2000 en tant qu'anti-virus de messagerie, et depuis janvier 2001, en tant qu'anti-virus en frontal de Sympa.

J'ai installé Amavis sur des Solaris 5.5, 5.7; et sur FreeBSD (3.3, 3.4). Je l'utilise avec la commande uvscan, prise dans les distributions nationales anti-virus dans /mcafee/NetShld/Unix: il existe des versions AIX, FreeBSD, HPUX, Linux, SCO, Solaris. Il semble qu'il n'y ait pas de problème de licenses.

Par endroits, je ne donne que les principes, mais pas mes programmes, trop lié à mon installation. Pour faire un configure; make; make install correct, je manque d'habitude... et de temps...

Ce qu'est Amavis

Amavis (http://www.amavis.org) est un shell, écrit en bash qui s'insère ainsi dans le trajet du courrier (voir ce qui est en rouge):

Installer Amavis

Essentiellement lire la documentation!

Sur une machine Linux ou FreeBSD, pas trop de soucis: les décompresseurs multiples existent. Sur Solaris, il faut aller à la pêche, mais la page a (en juillet 2000, en tout cas) tous les pointeurs.

Quelques remarques:

ici un source de id, qui comprend l'option -un; nécessaire à installer sur Solaris.
il faut vraiment la commande file ad hoc; à prendre ici.
il faut bien le make style GNU; un test simple est de taper make -v: le bon make se présente, les autres ralent.
j'ai installé le package maildrop-1.2.2, non pour maildrop, mais pour reformime, un remplaçant de metamail qui ne semble guère maintenu.

le configure de amavis-0.2.1-pre3 n'est pas à jour vs tnef-0.16. Ici les lignes numérotées avec en rouge les corrections:

  2638    $tnef -h 2>&1 | grep "\-C DIR" >/dev/null 2>&1
  2639    if test $? -eq 0
  2640    then
  2641       tnef_arg="-C"

Pour tester avant de mettre en vrai, on peut procéder ainsi:

premier test:

	date | /usr/sbin/scanmails -Y -a MYHOST -d MOI

créer un fichier /etc/mail/sendmail.cf.alt, où on a remplacé le mailer Mlocal comme indiqué.
second test:
```
	date | /usr/lib/sendmail -v -C/etc/mail/sendmail.cf.alt Moi
```
Si ce courrier arrive, on doit avoir juste. Et on peut passer en production.

Vous avez ici un fichier /usr/sbin/scanmails avec quelques modifications suggérées par l'expérience.
Ne pas installer ce fichier, il est personnalisé via mon installation des divers programmes, quelques choix, etc.
Ces modifications se reconnaissent via des tags <JB>. Ce sont:

ligne 253: un tag à moi
lignes 1128 et suivantes: à quoi bon mettre dans un mail les rapports (négatifs) de tous les anti-virus que je n'ai pas. Je commente tout sauf une ligne!
ligne 1191: afin de prévenir l'émetteur du virus qu'il a, créer une variable virusfound
lignes 1216 et suite: un mail en français! Avec en plus l'analyse.
lignes 1250 et suite: idem.

Commentaires

c'est un shell, qui lance plein de commandes. C'est donc lourd pour la machine: compter 20 à 30 programmes, donc autant de fork/exec, par mail délivré. Donc si un mail arrive vers 100 personnes, faites le compte!
Une idée pour s'en tirer sur les gros alias collectifs:
```
	tous: "| /une/variante/de/scanmails"
```
qui termine en lançant:
```
	wrapper_de_/usr/lib/sendmail -C/etc/autre.sendmail.cf -f sender user1 user2 user3 ...
```
Ce /etc/autre.sendmail.cf étant une copie du premier SANS passage déjà réalisé via scanmails. Le wrapper est nécessaire car pour passer un -C à sendmail, il faut quelques droits. Oui, cela fonctionne, je pratique.
La (future) version Perl de amavis n'est guère meilleure (je l'ai essayé). En fait, je pense qu'il faudrait le process Perl prêt en mémoire, process à qui l'on soumettrait le mail à traiter. Style Apache??? Un tel process pourrait-il repérer qu'on lui donne 100 fois le même travail à faire? Via le message-Id? Mais un pirate ne pourrait-il alors générer explicitement le même Message-Id?
Amavis fait du tout ou rien: le courrier arrive, ou il est mis au rebut. Parfois, un utilisateur, prévenu correctement par le message Amavis, aimerait bien demander son courrier: sachant qu'il sait ne pas être vulnérable, ou bien qu'il sait désinfecter. Il faudrait une commande supplémentaire dans le package amavis.
je me suis fait piégé par des soucis d'espace disque: le mail arrive dans /var/spool/mqueue, il est décompressé dans /var/tmp, puis il va vers /var/mail. J'ai perdu quelques heures de mail d'utilisateurs par débordement de /var/tmp, amavis ne testant pas le succès ou échec de ses écritures...
J'en ai tiré la conclusion suivante: mettre ces 3 répertoires dans la même partition, et laisser sendmail faire le travail via, dans le fichier sendmail.cf, des lignes style:
```
	O MaxMessageSize=3000000
        O MinFreeBlocks=15000
```
Limiter les messages à 3 Mo avec au moins 15 Mo libres devrait imposer une marge suffisante, non?

Mises à jour des signatures

Ayant installé McAfee, je vais les chercher à la source: ftp://ftp.nai.com/pub/antivirus/datfiles/4.x. Afin d'être à jour, une crontab la nuit se connecte sur ftp.nai.com et me génère un mail si la sortie de la commande ls a changé. En fait, elle change pour 4 raisons:

des fois ce serveur est un Windows, des fois c'est un Unix; donc la sortie est différente. GRRR!!!
des fois c'est planté là-bas;
des fois ils font des erreurs, et le contenu n'est pas génial;
et souvent c'est parce qu'il y a une nouvelle version. Quand même.

Dans ces conditions, une fois le mail lu:

je rapatrie le nouveau fichier dat-XXXX.tar
je le décompresse

et je copie dans /usr/local/uvscan les fichiers

	clean.dat
	names.dat
	internet.dat
	reseller.txt
	scan.dat
	readme.txt

Commentaires:

dans le paragraphe ci-dessus, "je" peut avantageusement être remplacé par un script (shell, Perl)...
en 9 mois, avec le trafic normal de 1.000 utilisateurs, il y a eu un seul plantage parce que l'antivirus travaillait au moment où je lui ai changé ses fichiers. Faut-il suspendre le trafic pendant le changement??
ma méthode (courrier + action manuelle) demande du suivi pendant mes vacances

Avec sympa

Attendu que scanmails est un shell, le modifier pour l'inclure ainsi dans le trajet n'est pas bien complexe:

Ici la version modifiée de scanmails, que j'ai moi mise dans /var/sympa/bin/scanmails. Les modifications ont le tag "<JB>".

ligne 150: c'est mon choix.
ligne 166: on ne prévient pas les destinataires d'une liste qu'ils n'ont pas reçu un message. En plus, il faudrait vraiment revoir ce shell.
ligne 257: un autre de mes choix
ligne 461: récupérer les bons arguments: le nom de la liste, qui a émis le message
lignes 1136 et suivantes: cf supra.
ligne 1198: comme maintenant on gère des listes, mettre un message correct!
ligne 1205: une variable permettant de dire à l'émetteur le nom du virus qu'il a émis
ligne 1213: comme maintenant on gère des listes, mettre un message correct!
ligne 1229 et suivantes: message bilingue, parlant de liste, avec le résultat de l'analyse
ligne 1305: donner enfin à sympa! Et on commente un paquet devenu inutile.

Pour mettre en service, il suffit de modifier dans le fichier des alias de mail:

test: "| /var/sympa/bin/queue test"

test: "| /var/sympa/bin/scanmails test"

ce qui vous montre la méthode de test non destructive... une liste de test puis, si on est satisfait...

Statistiques

Ces statistiques sont obtenues ainsi:

stocker avec un procmail ad hoc les mails
analyser ce perl le fichier

Nombre de virus interceptés par mois, population de 720 utilisateurs: (dont 4 virus dans les mailing-lists que je gère, 4 en un mois):

4 images pour les best-sellers: