Recherche de site Web

Comment ajouter une protection antivirus et anti-spam au serveur de messagerie Postfix avec ClamAV et SpamAssassin - Partie 3


Dans les deux articles précédents de cette série Postfix, vous avez appris comment configurer et gérer la base de données du serveur de messagerie via phpMyAdmin, et comment configurer Postfix et Dovecot pour gérer le courrier entrant et sortant. De plus, nous avons expliqué comment configurer un client de messagerie, tel que Thunderbird, pour les comptes virtuels que nous avons créés précédemment.

  1. Configurer le serveur de messagerie Postfix et Dovecot avec MariaDB – Partie 1
  2. Comment configurer Postfix et Dovecot avec des utilisateurs de domaine virtuel – Partie 2
  3. Installer et configurer le client Webmail RoundCube avec des utilisateurs virtuels dans Postfix – Partie 4
  4. Utilisez Sagator, une passerelle antivirus/antispam pour protéger votre serveur de messagerie – Partie 5

Puisqu'aucune configuration de serveur de messagerie ne peut être complète sans prendre des précautions contre les virus et le spam, nous allons aborder ce sujet dans l'article actuel.

Veuillez garder à l'esprit que même si les systèmes d'exploitation de type *nix sont généralement considérés comme exempts de virus, il est probable que les clients utilisant d'autres systèmes d'exploitation se connecteront également à votre serveur de messagerie.

Pour cette raison, vous devez leur assurer que vous avez pris les mesures nécessaires pour les protéger dans la mesure du possible contre de telles menaces.

Configuration de SpamAssassin pour Postfix

Lors du processus de réception d'e-mails, spamassassin se situera entre le monde extérieur et les services de messagerie exécutés sur votre serveur lui-même. S'il constate, selon ses règles de définition et sa configuration, qu'un message entrant est du spam, il réécrira la ligne d'objet pour l'identifier clairement comme tel. Voyons comment.

Le fichier de configuration principal est /etc/mail/spamassassin/local.cf, et nous devons nous assurer que les options suivantes sont disponibles (ajoutez-les si elles ne sont pas présentes ou décommentez si nécessaire) :

report_safe 0
required_score 8.0
rewrite_header Subject [SPAM]
  1. Lorsque report_safe est défini sur 0 (valeur recommandée), le spam entrant n'est modifié qu'en modifiant les en-têtes des e-mails conformément à rewrite_header. S'il est défini sur 1, le message sera supprimé.
  2. Pour définir l'agressivité du filtre anti-spam, required_score doit être suivi d'un nombre entier ou décimal. Plus le nombre est petit, plus le filtre devient sensible. Il est recommandé de définir required_score sur une valeur comprise entre 8,0 et 10,0 pour un grand système desservant plusieurs (~ 100). comptes mail.

Une fois que vous avez enregistré ces modifications, activez et démarrez le service de filtrage anti-spam, puis mettez à jour les règles anti-spam :

systemctl enable spamassassin
systemctl start spamassassin
sa-update

Pour plus d'options de configuration, vous souhaiterez peut-être vous référer à la documentation en exécutant perldoc Mail::SpamAssassin::Conf dans la ligne de commande.

Intégration de Postfix et SpamAssassin

Afin d'intégrer efficacement Postfix et spamassassin, nous devrons créer un utilisateur et un groupe dédiés pour exécuter le démon de filtre anti-spam :

useradd spamd -s /bin/false -d /var/log/spamassassin

Ensuite, ajoutez la ligne suivante au bas de /etc/postfix/master.cf :

spamassassin unix - n n - - pipe flags=R user=spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Et indiquez (en haut) que spamassassin fera office de content_filter :

-o content_filter=spamassassin

Enfin, redémarrez Postfix pour appliquer les modifications :

systemctl restart postfix

Pour vérifier que SpamAssassin fonctionne correctement et détecte le spam entrant, un test appelé GTUBE (Test générique pour les e-mails en masse non sollicités) est fourni.

Pour effectuer ce test, envoyez un e-mail depuis un domaine extérieur à votre réseau (tel que Yahoo!, Hotmail ou Gmail) vers un compte résidant sur votre serveur de messagerie. Définissez la ligne Objet comme vous le souhaitez et incluez le texte suivant dans le corps du message :

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

Par exemple, l'envoi du texte ci-dessus dans un corps de message depuis mon compte Gmail produit le résultat suivant :

Et affiche l'avis correspondant dans les journaux :

journalctl | grep spam

Comme vous pouvez le voir dans l'image ci-dessus, cet e-mail a obtenu un score de spam de 1 002,3. De plus, vous pouvez tester spamassassin directement depuis la ligne de commande :

spamassassin -D < /usr/share/doc/spamassassin-3.4.0/sample-spam.txt

La commande ci-dessus produira une sortie très détaillée qui devrait inclure les éléments suivants :

Si ces tests échouent, vous pouvez vous référer au guide d'intégration de spamassassin.

Démarrage de ClamAV et mise à jour des définitions de virus

Pour commencer, nous devrons éditer /etc/clamd.d/scan.conf. Décommentez la ligne suivante :

LocalSocket /var/run/clamd.scan/clamd.sock

et commentez ou supprimez la ligne :

Example

Ensuite, activez et démarrez le démon du scanner clamav :

systemctl enable [email 
systemctl start [email 

et n'oubliez pas de définir le booléen antivirus_can_scan_system SELinux sur 1 :

setsebool -P antivirus_can_scan_system 1

À ce stade, il vaut la peine de vérifier l’état du service :

Comme vous pouvez le voir sur l'image ci-dessus, nos signatures virales datent de plus de 7 jours. Pour les mettre à jour, nous utiliserons un outil appelé freshclam qui a été installé dans le cadre du package clamav-update.

Le moyen le plus simple de mettre à jour les définitions de virus consiste à effectuer une tâche cron qui s'exécute aussi souvent que vous le souhaitez (une fois par jour par exemple, à 1 heure du matin, l'heure du serveur comme indiqué dans l'exemple suivant est considérée comme suffisante) :

00 01 * * * root /usr/share/clamav/freshclam-sleep

Vous pouvez également mettre à jour les définitions de virus manuellement, mais avant vous devrez également supprimer ou commenter la ligne suivante dans /etc/freshclam.conf.

Example

Vous devriez maintenant pouvoir exécuter :

freshclam

qui mettra à jour les définitions de virus comme vous le souhaitez :

Test de ClamAV pour les virus dans les e-mails

Pour vérifier que ClamAV fonctionne correctement, téléchargeons un virus test (que nous pouvons obtenir sur http://www.eicar.org/download/eicar.com) dans le répertoire Mail de [email  ( qui se trouve dans /home/vmail/linuxnewz.com/tecmint/Maildir) pour simuler un fichier infecté reçu en pièce jointe :

cd /home/vmail/linuxnewz.com/tecmint/Maildir
wget http://www.eicar.org/download/eicar.com

Et puis analysez le répertoire /home/vmail/linuxnewz.com de manière récursive :

clamscan --infected --remove --recursive /home/vmail/linuxnewz.com

Maintenant, n'hésitez pas à configurer cette analyse pour qu'elle exécute une tâche cron. Créez un fichier nommé /etc/cron.daily/dailyclamscan, insérez les lignes suivantes :

#!/bin/bash
SCAN_DIR="/home/vmail/linuxnewz.com"
LOG_FILE="/var/log/clamav/dailyclamscan.log"
touch $LOG_FILE
/usr/bin/clamscan --infected --remove --recursive $SCAN_DIR >> $LOG_FILE

et accordez les autorisations d'exécution :

chmod +x /etc/cron.daily/dailyclamscan

Le cronjob ci-dessus analysera le répertoire du serveur de messagerie de manière récursive et laissera un journal de son fonctionnement dans /var/log/clamav/dailyclamscan.log (assurez-vous que le /var/log/clamav existe).

Voyons ce qui se passe lorsque nous envoyons le fichier eicar.com de [email  à [email  :

Résumé

Si vous avez suivi les étapes décrites dans ce didacticiel et dans les deux articles précédents de cette série, vous disposez désormais d'un serveur de messagerie Postfix fonctionnel avec protection anti-spam et antivirus.

AVIS DE NON-RESPONSABILITÉ : veuillez noter que la sécurité des serveurs est un vaste sujet et ne peut pas être abordé de manière adéquate dans une courte série comme celle-ci.

Pour cette raison, je vous encourage fortement à vous familiariser avec les outils utilisés dans cette série et leurs pages de manuel. Bien que j'aie fait de mon mieux pour aborder les concepts essentiels associés à ce sujet, ne présumez pas qu'après avoir parcouru cette série, vous êtes pleinement qualifié pour configurer et maintenir un serveur de messagerie dans un environnement de production.

Cette série est conçue comme un point de départ et non comme un guide exhaustif sur l'administration des serveurs de messagerie sous Linux.

Vous penserez probablement à d’autres idées qui pourront enrichir cette série. Si tel est le cas, n'hésitez pas à nous envoyer une note en utilisant le formulaire de commentaires ci-dessous. Les questions et autres suggestions sont également appréciées – nous sommes impatients de vous entendre !