MAIL : 6ème Etape - Installation AMAVISD

DEBIANLINUXPOSTFIXAMAVISD

Alors, là attention ! Préparez la cafetière !...

Article quasi-littéralement tiré du très célèbre et excellent site starbridge, aussi sous licence creative commons.

Pour cette partie et pour éviter de se "prendre la tête" (très long), il faut faire le maximum de commandes décrites ci-dessous, pour réfléchir
après.

Aussi, l’article est tellement long qu’il vaut mieux le parcourir, page après page, et ne pas se servir de l’index...

AMAVISD - Installation

AMAVISD, que vous pouvez consulter, pour les amoureux de la langue de Shakespeare, est un moteur antispam.

Nous allons installer Amavisd :

aptitude install libdb4.4-dev file libcompress-bzip2-perl nomarch arc p7zip-full arj zoo lzop tnef pax cabextract libarchive-tar-perl libarchive-zip-perl libberkeleydb-perl libcompress-zlib-perl libconvert-tnef-perl libconvert-uulib-perl libdigest-md5-perl libio-stringy-perl libmailtools-perl libmime-base64-perl libmime-perl libnet-perl perl-modules libnet-server-perl libtime-hires-perl libunix-syslog-perl libmail-dkim-perl

Puis on télécharge les sources chez amavisd :

cd 
wget http://www.ijs.si/software/amavisd/amavisd-new-2.6.1.tar.gz
tar xvzf amavisd-new-2.6.1.tar.gz
cd amavisd-new-2.6.1

Nous créons l’utilisateur et le groupe amavis :

groupadd -g 1009 amavis
useradd -g amavis -u 1009 amavis -d /var/amavis -m

Si le système répond "groupadd : l’identifiant de groupe (GID) 1009 n’est pas unique", il faut aller voir dans /etc/passwd un numéro de groupe qui n’est pas utilisé, pour l’insérer dans la commande.

Créer les sous-répertoires dans le home d’amavis :

mkdir /var/amavis/tmp /var/amavis/var /var/amavis/db /var/amavis/home
chown -R amavis : /var/amavis

On crée 2 lecteur tmpfs pour héberger les répertoires db et tmp d’amavis. Cela accroît notablement les performances de traitement :

Modifier /etc/fstab :

nano /etc/fstab

et ajouter, à la fin du fichier :

Note : La taille de ces lecteurs tmpfs est à modifier selon la charge du serveur, la configuration et bien sur la quantité de RAM disponible.

Pour simplifier /var/amavis/tmp est dépendant du nombre d’instances d’amavisd et de la taille maximale d’un message. Les paramètres mis ici sont ok pour 5 instances et un message_size_limit de 10 Mo, ce qui est largement suffisant dans la config par défaut d’amavisd (2 instances)

Puis :

mount /var/amavis/tmp
mount /var/amavis/db

on vérifie par un mount -l

Copier l’exécutable :

cp amavisd /usr/sbin/
chown root /usr/sbin/amavisd
chmod 755 /usr/sbin/amavisd

Copier le fichier de conf :

cd /etc/
touch /etc/amavisd.conf
chown root:amavis /etc/amavisd.conf
chmod 640 /etc/amavisd.conf

Créer la quarantaine :

mkdir /var/virusmails
chown amavis:amavis /var/virusmails
chmod 750 /var/virusmails

Le fichier de configuration /etc/amavisd.conf fourni ici est modifié pour coller à nos besoins :

nano /etc/amavisd.conf

Évidemment, il faut éditer tout de même ce fichier pour préciser :

Insérer le contenu du fichier détaillé ci-dessous, et adapter les variables suivantes :

Notre réseau local dans @mynetworks,
Notre domaine avec $mydomain = ’Mondomaine.com’
et notre hostname avec $myhostname = ’MonServeur.Mondomaine.com’

On désactive temporairement l’antispam et l’antivirus pour tester :

Nous avons décommenté pour cela les lignes (au début du fichier de conf) :

Démarrer amavisd en console pour voir si il manque des prérequis :

/usr/sbin/amavisd debug

La commande de lancement amavisd est amavisd debug, ’debug’ n’est pas un lancement particulier d’amavisd. Amavisd doit TOUJOURS être lancé en mode debug.

Noter les erreurs éventuelles. Si amavisd ne démarre pas, arrêtez vous et résolvez les problèmes.

Si c’est ok, arrêter amavisd debug par CTRL + C.


Il faut ensuite configurer Postfix :

On ajoute à la fin du master.cf :

nano /etc/postfix/master.cf

et on modifie toujours dans le master.cf la section sur le port 587 comme ceci :

(on ajoute en fait la ligne sur le content_filter) Cette dernière modification permettra d’utiliser une configuration distincte dans

Relancer postfix :

postfix reload

Surveiller les logs :

tail -f /var/log/mail.log

Si tout est ok, lancer à nouveau amavisd debug

/usr/sbin/amavisd debug

et taper en console :

telnet 127.0.0.1 10024

Il doit répondre :

quit pour sortir

Pareil pour tester le retour de Postfix :

telnet 127.0.0.1 10025

Il doit répondre un truc du style :

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’^]’.
220 MonServeur.MonDomaine.com ESMTP Postfix (Debian/GNU)

QUIT pour sortir (en majuscules)

Ensuite, si les connections sont ok :

Tester le fonctionnement de base (ce qu’il faut taper est précédé de ---> , le reste c’est le retour du serveur) :

L’aller-retour postfix/amavisd fonctionne bien !

(on peut arrêter le debug d’amavisd par un CTRL + C)


CLAMAV - Installation

Clamav est l’antivirus serveur complémentaire de notre solution.

Prérequis :

aptitude install zlib1g zlib1g-dev libgmpxx4ldbl libgmp3-dev

Note : Sous Etch, si aptitude signale qu’aucun paquet ne correspond à « libgmpxx4ldbl ». C’est normal, il s’agit d’un paquet Lenny. Ne pas en tenir compte

On compile depuis les sources :

On met a jour les fichiers de configuration :

cd /etc

mv clamd.conf clamd.conf.orig

mv freshclam.conf freshclam.conf.orig

wget http://www.starbridge.org/spip/doc/Procmail/clamd.conf

wget http://www.starbridge.org/spip/doc/Procmail/freshclam.conf

On modifie la crontab de l’utilisateur amavis pour planifier la mise à jour de la base antivirale :

crontab -e -u amavis

et on ajoute :

Créer :

mkdir /var/log/clamav

chown -R amavis:amavis /var/log/clamav

Créer un fichier /etc/init.d/clamd

cd /etc/init.d/

wget http://www.starbridge.org/spip/doc/Procmail/clamd

chmod 755 /etc/init.d/clamd

update-rc.d clamd defaults

On fait la mise à jour de la base virale :

freshclam

On vérifie que les fichiers soient bien présents dans le répertoire :

ls -la /var/lib/clamav

On lance clamd :

/etc/init.d/clamd start

Et on vérifie les logs :

tail -f /var/log/clamav/clamd.log

Et on vérifie bien que Clam tourne :

ps aux | grep clam

On teste le fonctionnement (le dossier "test" est dans le répertoire clamav-0.93.3) :

cd /root/clamav-0.93.3/test/

clamdscan -l scan.txt clam-x.yz

clamav-x.yz est un des fichiers de test présents dans le répertoire test

Installation des signatures additionnelles pour Clam (détection du spam, phising...)

Il s’agit de fichiers supplémentaires que l’on place dans le dossier /var/lib/clamav

On lance le script :

su -c ’/usr/sbin/UpdateSaneSecurity.sh’ amavis

Attention le script peut mettre 5 minutes pour se lancer

On vérifie que les fichiers sont bien présents dans le répertoire de Clam :

ls -l /var/lib/clamav

On doit trouver les fichiers suivants en plus des fichiers classiques :

On crée une tache cron pour mettre à jour ces fichiers :

crontab -e -u amavis

Installation de ClamdMon pour la surveillance du demon clam :

installer le script de surveillance clamdmon :

Editer la crontab de root

crontab -e

puis on colle :


SPAMASSASSIN - Installation

On installe les dépendances

aptitude install libhtml-parser-perl libnet-dns-resolver-programmable-perl liberror-perl libmail-spf-perl libmail-sendmail-perl libnetaddr-ip-perl libdbi-perl libdbd-mysql-perl liblocale-subcountry-perl libwww-perl libimage-base-bundle-perl libimage-base-perl libimage-info-perl libnet-cidr-lite-perl

On installe SpamAssassin depuis aptitude de Debian :

aptitude install spamassassin

SA est installé. Sa config de base se fait dans le fichier /etc/mail/spamassassin/local.cf mais pour la plupart des paramètres, c’est le fichier amavisd.conf qui sera prioritaire.

Lorsqu’on utilise Amavisd pour appeler SA il est inutile de lancer spamd.

On remplace le /etc/mail/spamassassin/local.cf par celui ci :

mkdir /etc/mail/

mkdir /etc/mail/spamassassin/

cd /etc/mail/spamassassin/

mv local.cf local.cf-orig

wget http://www.starbridge.org/spip/doc/Procmail/spamassassin/local.cf

nano /etc/mail/spamassassin/local.cf

On édite le fichier pour adapter les parametres internal_networks et trusted_networks.

internal_networks et trusted_networks sont des paramètres très importants pour la pertinence de la détection. Il faut absolument les configurer correctement. (ils doivent contenir les même réseaux et être identiques.)

On sécurise :

chown amavis : /etc/mail/spamassassin/local.cf

chmod 640 /etc/mail/spamassassin/local.cf

SA fonctionne sur 2 types de tests :

* Heuristiques (ensemble de règles)
* Bayesiens (apprentissage et statistiques)

Pour le filtre bayesien, on va installer directement la base dans une base Mysql. Les performances sont supérieures et on s’affranchit de diverses limitations :

On crée la base :

mysql -u root -p

create database spam ;

GRANT SELECT, INSERT, UPDATE, DELETE ON spam.* TO ’spam’@’localhost’ IDENTIFIED BY ’Mot_De_Passe’ ;

FLUSH PRIVILEGES ;

quit

On modifie le password dans le local.cf à l’identique (ici votre password serait toto) :

sed -i ’s/******/toto/g’ /etc/mail/spamassassin/local.cf

(ne pas oublier de remplacer toto par votre mot de passe avant de valider la ligne)

on importe la base sql :

wget http://starbridge.org/spip/doc/Procmail/spamassassin/bayes_awl.sql

wget http://spamassassin.apache.org/gtube/gtube.txt

mysql -u root -p spam < bayes_awl.sql

On initialise la base :

su amavis -c ’sa-learn -D —spam gtube.txt’

On peut vérifier avec phpmyadmin que la base s’est bien remplie.

Il faut donc créer une tache cron quotidienne pour effectuer l’expiration :

Un crontab de l’user amavis fera l’affaire :

crontab -e -u amavis

et on ajoute :

On a activé l’Auto-Whitelist dans SA. Contrairement a Bayes, l’AWL n’a pas de mécanisme d’expiration qui évite à la base de grossir indéfiniment.

Pour cela on crée un script qui nettoira les tables régulierement :

cd /etc/

wget http://www.starbridge.org/spip/doc/Procmail/spamassassin/SA-awl-purgesql

puis on crée une tache cron

crontab -e -u amavis

et on ajoute :

Mise à jour des Rules de SA et ajout des Rules SARE :

On va mettre tout de suite à jour les règles de SA et en installer de nouvelles depuis le site de SARE :

On lance l’update des règles de SA :

sa-update -D

Cela aura pour effet de télécharger les règles à jour. Elles seront installés dans un dossier différent des règles d’origine : /var/lib/spamassassin/3.002005. (ce qui correspond à la version 3.2.5 de SA)

SA considèrera désormais ce dossier comme celui par défaut.

On vérifie que tout soit OK :

su -c "spamassassin -D —lint" amavis

Il ne doit pas il y a voir de message d’erreur à la fin de l’exécution.

On prépare l’installation des rules SARE :

cd /etc/mail/spamassassin/

wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY

sa-update —import GPG.KEY

on installe le fichier contenant la liste des Rules :

wget http://www.starbridge.org/spip/doc/Procmail/spamassassin/sare-sa-update-channels.txt

On pourra modifier ce fichier pour ne sélectionner que les RULES que l’on désire.

On met à jour :

sa-update —channelfile /etc/mail/spamassassin/sare-sa-update-channels.txt —gpgkey 856AA88A

Les fichiers seront placés dans /var/lib/spamassassin :

ls -la /var/lib/spamassassin/3.002005/

On vérifie à nouveau que tout soit OK :

su -c "spamassassin -D —lint" amavis

Pour une mise à jour régulière (1 fois par jour maximum) on pourra créer une tache cron en n’oubliant pas de relancer amavisd à la fin du script.

Pour cela, on crée un fichier sa-update.sh :

cd /etc/

wget http://www.starbridge.org/spip/doc/Procmail/spamassassin/sa-update.sh

chmod 755 /etc/sa-update.sh

On édite la crontab :

crontab -e

et on ajoute la ligne :

Activation du plugin DKIM

 Il faut maintenant activer SA dans amavisd :

On édite /etc/amavisd.conf et on commente la ligne :

nano /etc/amavisd.conf

On démarre en debug-sa :

/usr/sbin/amavisd debug-sa

On envoie un mail et on doit voir dans le debug le bon fonctionnement (on peut utiliser un client comme thunderbird ou outlook en paramétrant le compte en IMAP.)

On arrête amavisd par un CTRL + C.

Par défaut Amavisd mets les spams en quarantaine, mais ce n’est pas le comportement que nous désirons.

Le amavisd.conf fourni dans ce tuto intègre les modifications nécessaires.

Pour infos voici les paramètres modifiés :

Avec cette modification, on dit à amavisd de laisser passer le spam mais de le tagguer dans le header du mail. La limite Spam est fixée à un score de 4.3

On traitera le mail plus loin par Maildrop.

On crée un fichier /etc/init.d/amavis :

cd /etc/init.d/

wget http://www.starbridge.org/spip/doc/Procmail/init.d/amavis

chmod 755 /etc/init.d/amavis

update-rc.d amavis defaults

on lance amavisd :

/etc/init.d/amavis start

On regarde les logs.

On envoie un mail et on regarde l’entête de celui ci. on doit voir les X-Spam- headers.

On paramètre Maildrop pour déposer le courier détecté comme spam dans le dossier spam de chaque utilisateur :

On édite /home/virtual/.mailfilter et on le modifie comme ceci :

 Explications :

Le premier If permet d’envoyer le spam dont le score est au dessus de 10 dans une boite spécifique spamtrap@mondomaine.com qu’il faut créer (on peut utiliser postfixadmin pour ca).

Le deuxième If permet d’envoyer le spam en dessous de 10 dans le dossier Spam de l’utilisateur.

Le 3eme permet d’intercepter les mails avec l’extension +spam, qui peuvent être utilisés par amavisd (pour Mailzu par exemple)

* Pour améliorer l’apprentissage, on crée une tache qui scanne la boîte spamtrap et les 2 dossiers d’apprentissage SpamToLearn et SpamFalse des boîtes des utilisateurs (Dossiers crées automatiquement par maildrop à la première livraison) puis envoit leur contenu vers le filtre bayesien :

On crée d’abord deux répertoires spéciaux de transit :

on crée un fichier /etc/sa-learn :

cd /etc/

wget http://www.starbridge.org/spip/doc/Procmail/spamassassin/sa-learn

chmod 755 /etc/sa-learn

On crée une tache cron qu’on lance par root : (une fois par jour ou plus suivant la puissance de la machine, cette tache étant très gourmande en ressources)

crontab -e

et on ajoute (on change la fréquence si nécessaire) :

Tout sera automatique. Il suffira d’indiquer aux utilisateurs de déplacer les emails non détectés comme Spam dans le dossier SpamToLearn et de copier les email légitimes détectés à tort comme Spam dans le Dossier SpamFalse. Le script déplacera lors de son exécution tous ces emails et en fera l’apprentissage soit comme spam soit comme ham (non spam).

Attention : TOUS les mails déposés dans les dossiers SpamTolearn et SpamFalse sont déplacés c’est à dire qu’il seront EFFACES de ces dossiers.

Par sécurité on peut conserver les mails de la boite spamtrap (non consultables par les utilisateurs) un certain temps. Pour cela il suffira de changer les 2 premières lignes en copie au lieu d’un déplacement (cp). On verra plus loin pour un script de nettoyage basé sur l’âge des fichiers.

On peut également enlever le -D des 2 lignes sa-learn pour limiter la sortie du script (debug). Cron envoie un mail à l’exécution de la commande, contenant la sortie.


Activation de Clam dans Amavisd

Le fichier amavisd.conf fourni dans ce tuto est modifié pour ne prendre en charge que l’antivirus Clamav.

Pour info voici les paramètres modifiés (à la fin du fichier) :

Pour activer Clam on commente au début du fichier :

On relance amavisd :

/etc/init.d/amavis stop && /etc/init.d/amavis start

L’antivirus est chargé.

On crée l’alias email : virusalert@mondomaine.com vers admin@mondomaine.com. (passer par postfixadmin)

On teste le fonctionnement :

On doit voir dans les logs :

On peut aussi tester l’envoi d’un mail infecté dans une archive (pour tester le travail de décompression) en récupérant des fichiers de test sur eicar.com et en les envoyant par email.

Maintenance de Clam et de Spamassassin :

Il faut penser à purger régulièrement le contenu de la boite spamtrap et la quarantaine de clam, c’est à dire le dossier /home/virtual/spamtrap@mondomaine.com/new/. et le /var/virusmails.

Pour cela on peut utiliser un outil du genre tmpreaper.

Il se configure très simplement dans /etc/tmpreaper.conf

On modifie la ligne suivante comme ceci :

nano /etc/tmpreaper.conf


DSPAM - Installation

Beaucoup considère Dspam comme une alternative plus performante de SA.

Je trouve qu’ils sont plutôt complémentaires.

Amavisd permet de gérer les 2 en parallèle.

Créer la base sql :

On importe la base sql :

mysql -u root -p dspam < /root/dspam-3.8.0/src/tools.mysql_drv/mysql_objects-4.1.sql

On modifie le fichier de conf dspam.conf original (toto étant votre password d’acces a la base sql dspam que vous venez de paramétrer) :

cd /etc/

mv dspam.conf dspam.conf-orig

wget http://www.starbridge.org/spip/doc/Procmail/dspam.conf

sed -i ’s/******/toto/g’ dspam.conf

Modifier les droits sur les exécutables (même user qu’amavisd) et le dspam.conf :

chown amavis : /usr/bin/dspam*

chown amavis : /etc/dspam.conf

chmod 750 /usr/bin/dspam*

chmod 640 /etc/dspam.conf

Créer le répertoire de dspam dans le home d’amavisd :

mkdir /var/amavis/dspam

chown -R amavis : /var/amavis/dspam

Pour activer dspam, il faut décommenter la ligne suivante dans amavisd.conf :

nano /etc/amavisd.conf

On relance amavisd :

/etc/init.d/amavis stop && /etc/init.d/amavis start

On vérifie les logs. On doit voir :

On envoie un email :

On vérifie les logs, les headers des email pour les tags X-DSPAM et le remplissage de la base de données.

Principe de fonctionnement :

Dans cette configuration, Dspam marque simplement les mails (il ajoute un tag dans le header). Pour que le filtrage devienne effectif, il faut donc indiquer à Spamassasssin le score à attribuer en fonction de la valeur du tag X-DSPAM dans le header.

De préférence, il vaut mieux attendre quelques jours après l’installation de dspam afin de le laisser apprendre sur un volume de mail conséquent, avant d’activer ces rules SA.

Dès que l’on estime que les tags sont pertinents dans les headers (c’est à dire que Dspam détecte bien du spam et du non-spam (ham) correctement), on peut ajouter ceci au /etc/mail/spamassassin/local.cf :

nano /etc/mail/spamassassin/local.cf

On peut améliorer les performances de la base en changeant le moteur en InnoDB

On crée les taches de maintenance de dspam :

On crée un fichier /etc/dspam-purge-4.1.sql

cd /etc/

wget http://www.starbridge.org/spip/doc/Procmail/dspam-purge-4.1.sql

Puis on crée une tache cron avec le user amavis :

crontab -e -u amavis

et on ajoute :

On crée une tache cron de purge des log avec le user amavis :

crontab -e -u amavis

on ajoute :

Filtrage par extensions et type mime dans amavisd

On peut également renforcer le blocage des fichiers par extension et type mime dans amavisd, indépendamment de l’antivirus.

Ce blocage est très efficace et peut être complémentaire du premier blocage par Postfix sur ces fichiers (headers, body, type mime), car il utilise cette fois les capacités de décodage et de décompression d’Amavisd.

Par exemple, on pourra facilement bloquer un fichier exe à l’intérieur d’un fichier zip.

Voir mon fichier amavisd.conf pour des exemples de type mime et d’extensions de fichiers.

@@@@@ JOINDRE FICHIER

Voila le serveur de mail et le filtrage sont configurés !


AMAVISD - Maintenance Bases MySQL

Les tables vont grossir au fur et à mesure des réceptions, il faut donc regulièrement les purger.

On crée un fichier amavis-purgesql :

cd /etc/

wget http://www.starbridge.org/spip/doc/Procmail/amavisd/amavis-purgesql

puis on crée une tache cron

crontab -e -u amavis

et on ajoute :

ATTENTION : Bien vérifier, dans le CRON, que toutes les étoiles (****), passées en paramètre -p ’******’, soient bien remplacées par MonMotdePasse.

Vérification et signatures des messages par DKIM

Cette technique a tendance a se développer, et depuis la version 2.6, amavisd propose désormais d’exécuter l’intégralité des tâches DKIM : Vérification des messages reçus et signatures des messages sortants.

Depuis la version 2.6 d’amavisd, celui ci est capable de générer une signature DKIM

La vérification DKIM des mails recus et faites par defaut dans amavisd.

On génére la clé :

mkdir /var/amavis/dkim

cd /var/amavis/dkim

amavisd genrsa /var/amavis/dkim/domaine.key.pem

les droits du fichier sont mis correctement par amavisd.

Si l’on a plusieurs domaines on répète la procédure pour chaque.

On ajoute ceci au /etc/amavisd.conf :

A partir d’ici Amavisd est capable de signer les messages sortants. Mais le serveur destinataire ne sera pas capable de les vérifier, car il faut publier la clé publique dans les DNS :

Pour cela, on lance la commande suivante pour afficher la clé publique du ou des domaines que l’on a parametré plus haut.

amavisd showkeys

on fait un copier/coller du résultat pour le domaine et on le colle tel quel dans la zone DNS.

Le serveur DNS Bind gère bien sûr cet enregistrement (TXT) et il suffira de l’enregistrer dans le fichier de zone et de recharger bind.

Si les DNS sont gérés par l’hébergeur, la plupart propose de modifier les champs TXT, mais ce n’est pas le cas de tous. Il faudra donc vérifier ce point.

On teste l’enregistrement avec une commande d’amavisd :

amavisd testkeys

On relance amavisd.

Pour pouvoir signer les messages il faut que ceux ci proviennent pour amavisd d’une source de confiance, c’est à dire en provenance du réseau spécifié dans amavisd comme étant local (policy bank MYNETS), ou bien depuis le port 587 dans postfix en TLS + SASL (policy bank ORIGINATING).

On teste en envoyant un mail et on vérifie dans les logs que la signature s’applique bien.

On retrouvera cette signature dans les headers du message envoyé.

Notes :

 On peut aller plus loin dans la configuration d’Amavisd mais pour ne pas surcharger le tuto nous n’aborderons pas ces points ici.

 La configuration d’amavisd doit également être modifiée en fonction de la charge du serveur. Par défaut 2 instances sont actives ($max_servers = 2 ;). Le calcul du nombre d’instances nécessaires demande certains ajustements à l’usage et doit être considéré comme un prérequis sur la mise en production d’un serveur susceptible de traiter des volumes conséquents. On peut consulter la doc d’amavisd sur ce point.

 Dans notre configuration on filtre (antispam, antivirus) sur les mails entrants ET sortants. On peut économiser des ressources systèmes en désactivant l’antispam sur les mails sortants en provenance d’utilisateurs authentifiés. Voir la configuration dans cet article

Pour info, les mails soumis localement (pickup) bypassent tous les tests : spams, AV, header/body. C’est le cas pour les mails système comme ceux de cron, logwatch ou autres. Cette configuration a été faite dans la partie pickup en début de tuto.