MAIL : 6ème Etape - Installation AMAVISD
DEBIANLINUXPOSTFIXAMAVISDAlors, 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.