Projet

Général

Profil

Sécuriser un serveur de mail

Présentation des différents systèmes

Antivirus

Bon...linux, pas de virus, tout ça tout ça...m'enfin, ça ne coûte pas grand chose de filtrer ses propres messages à l'envoi pour s'assurer qu'on ne forwarde pas un PPT plein de chatons qui jouent du piano et de virus. Et puis quitte à filtrer dans un sens, autant filtrer dans l'autre.

Il n'y a pas 50000 antivirus sous linux, ClamAV est l'un des plus complet, mis à jour et performant. Appelé depuis ClamSMTP, il s'intègre très bien à postfix.

Spamassassin

Spamassassin est un programme en perl développé par la fondation Apache. Ce programme regroupe plusieurs méthodes de détection de spams telles que :

  • DNSBL (DNS BlackList) : blocage d'adresses IP (voir RBL plus loin) par interrogation de DNS.
  • SURBL (URL BlackList) : idem mais par interrogation d'URI.
  • Hashcash : Système en DoS se basant sur la consommation CPU utilisée par l'émetteur lors de l'envoi de mail.

D'autres sont disponibles via l'installation et l'activation de plug'ins.

De plus, SpamAssassin, propose la détection de spams via l'application de filtres bayesiens permettant de différencier les spams des hams (les « pas spams »).

Greylisting

Le greylisting est un procédé permettant de refuser la réception de spams en provenance de spambots. Ce procédé se base sur le fait que certains spams ne sont pas émis depuis de « vrais » serveurs de mail.
Un « vrai » serveur de mail dispose d'une file de messages dans laquelle il stocke les messages dont l'émission a été refusée par une erreur 4xx (généralement, 450) alors qu'un spambot émets des mails sans se soucier du succès de l'envoi ou pas.

Ainsi, un daemon de greylisting refuse systématiquement les mails en provenance d'un serveur en retournant un code d'erreur 450. Dans le même temps, il mémorise les informations de ce serveur (IP, nom, etc.). Étant donné que le code d'erreur n'est pas un refus catégorique (5xx), le serveur émetteur retente un envoi régulièrement, généralement toutes les 5 ou 10 minutes, jusqu'à la fin d'un timeout défini, généralement plusieurs jours. Si le même message a été émis 3 fois d'affilé, le daemon de greylisting l'accepte et place le serveur émetteur dans une « whitelist » temporaire pendant un temps défini.

Un des daemons de greylisting célèbre et fonctionnant bien avec postfix est postgrey.

Realtime Black Lists ou Domain Name Server based BlackLists

Les RBL ou DNSBL sont des listes mises à jour en temps réel d'adresses IP réputées pour être émettrices de spams. L'interrogation de ces listes se fait grâce au protocole DNS.

Par exemple, pour savoir si l'adresse IP 91.224.149.142 est classée comme émettrice de spams, d'abord, retournons là : 142.149.224.91. Puis ajoutons le nom d'une RBL, par exemple sbl-xbl.spamhaus.org. Et regardons si une adresse IP correspond à ce « nom de domaine » :

$ host 142.149.224.91.sbl-xbl.spamhaus.org
Host 142.149.224.91.sbl-xbl.spamhaus.org not found: 3(NXDOMAIN)

Pas d'adresse IP associée à ce nom de domaine, l'adresse IP 91.224.149.142 est clean !

Même exercice pour l'adresse IP 114.37.70.152 :

# host 152.70.37.114.sbl-xbl.spamhaus.org                                                                                        
152.70.37.114.sbl-xbl.spamhaus.org has address 127.0.0.4

L'adresse IP 127.0.0.4 est retournée et selon la documentation de spamhaus.org, 127.0.0.4 veut dire que cette IP est notée comme étant une machine infectée par un virus émetteur de spam.

L'utilisation de RBL pour bloquer les mails est souvent soumise à controverse car le remplissage et la maintenance de ces listes sont généralement obscurs. Il en existe même qui demande une rémunération pour la suppression d'adresse IP. Bref, libre à chacun d'utiliser ces listes ou pas tant que c'est en tout connaissance de cause.

SPF

SPF ou « Sender Policy Framework », est un système anti « spoofing ». C'est à dire qu'il permet de valider que le serveur émetteur du mail est bien le serveur qui gère les mails de ce domaine.

Ce système se base sur la mise en place d'un champ TXT (ou SPF) dans le nom de domaine émetteur. Ce champs ne peut être ajouté que par le gestionnaire du domaine et donc sûrement le gestionnaire du serveur de mail émetteur (en tout cas, lui seul peut valider que l'un est associé à l'autre).

Ce champ TXT permet de valider que le nom de domaine de l'adresse mail émettrice, l'adresse IP du serveur émetteur et son reverse sont valides.

Exemple de champs SPF pour le domaine kafe-in.net :

$ dig +short spf kafe-in.net
"v=spf1 mx ptr:muscat.kafe-in.net ptr:fdn.le.fai.avec.les.bulles.qui.vont.vers.le.bas.kafe-in.net mx:mail.kafe-in.net mx:mail2.kafe-in.net ip6:2a01:6600:8081:8e00::fab ip6:2001:910:109c:2::25 ip4:91.224.149.142 ip4:80.67.176.156 include:dupont.eu.org -all" 

DKIM

DKIM, ou « DomainKeys Identified Mail », est une autre méthode pour associer un nom de domaine à un mail. Cette validation se base sur l'ajout d'un header contenant une clé, cette clé permet de signer le mail. Cette signature est validée en interrogeant un champ TXT du nom de domaine émetteur du mail.

Exemple de champs TXT pour le domaine kafe-in.net et de signature :

dig +short txt default._domainkey.kafe-in.net
"v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCh2cOuv5Tb+oFElVq3sf837oclBXoiHcMDjlWxpjCfjyYq1fSZNyMxXG/CKqLRx/bqyI/Bcl6n30pR8Okp8ItjBvUXQJwh6fczyKdto69Z2DrGf495ANghUtPxKFOe98PXuEa0OmvhOD45VOKeHU9TW32SgxHy6kxur/WMaJMbDwIDAQAB" 
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kafe-in.net;
        s=default; t=1344852664;
        bh=fdkeB/A0FkbVP2k4J4pNPoeWH6vqBm9+b0C3OY87Cw8=;
        h=From:Date:To:Subject;
        b=DqT32ZzqUgRPm9PGYwfB7nxJiyaTLxT6yoeIPLqPnxwgMJ933nYLxQpMimSsaKZdT
         iGo68RBhgFFXe+6zJCWPZbCye8ptW8awCHfwsogYAzvRs0wk9rF/r78CWZXAn6dCeH
         cCMomFWcBOzTdbqQ/ZKizBCOdgLsT/aPDVBV00Eo=

Enchaînement des différents systèmes

Il existe plusieurs moyens pour postfix de vérifier la validité du mail, ou pas :

  • Les content filters : Ce sont des programmes recevant un mail selon le protocole SMTP et le renvoyant, ou pas, à postfix selon le même protocole après ajout de headers. Exemple : ClamSMTP et SpamAssassin.
  • Les milters : ce sont des programmes dialoguant avec postfix sur un port TCP donné en suivant un protocole défini. Exemple : OpenDKIM.
  • Les policy services : Ce sont des programmes au fonctionnement proche des milters. Ils permettent de valider ou non le passage d'un mail selon ses paramètres. Exemple : PostGrey et postfix-policyd-spf-python.
  • Les RBL : Voir plus haut, la gestion des RBL est gérée directement par postfix. Elle peut également être intégrée à SpamAssassin ou à des services de policyd (comme http://www.policyd-weight.org/ ) pour aider à classer les mails.

Voilà rapidement l'enchaînement des validations faites à l'arrivée d'un mail :

  • Émetteur : Ouverture d'une connexion sur le port 25 (SMTP).
  • Récepteur : Vérification de la validité de l'adresse IP source et consultation des RBL (smtpd_client_restrictions).
  • Émetteur : HELO sondomaine.tld
  • Récepteur : Vérification de la validité du domaine et du reverse (smtpd_helo_restrictions).
  • Émetteur : MAIL from : "Marvin the paranoid android" <>
  • Récepteur : Vérification de la validité de l'adresse émettrice (smtpd_sender_restrictions).
  • Émetteur : RCPT to : "Fabien Dupont" <>
  • Récepteur : Vérification de la validité de l'adresse destinataire (smtpd_recipient_restrictions).
    • Interrogation du « policy service » postgrey sur le port 10023
    • Interrogation du « policy service » python-spf via la socket unix private/policyd-spf
  • Récepteur : Envoi du code de retour au serveur émetteur (RFC3463) :
    • 3xx : OK pour la suite
    • 4xx : Erreur temporaire (exemple: postgrey).
    • 5xx : Erreur permanente (Adresse émettrice ou réceptrice non valide).
  • Émetteur : DATA puis le contenu du mail (headers compris).
  • Récepteur : Transfert du mail au « content filters » :
    • ClamSMTP reçoit le mail sur le port 10025 et si le mail est valide...
    • SpamAssassin reçoit le mail sur le port 10026 et si le mail est valide...
    • Postfix récupère le mail validé sur le port 10028
  • Récepteur : Validation du mail via le milter OpenDKIM sur le port 10028
  • Récepteur : Envoi du code de retour au serveur émetteur (RFC3463) :
    • 2xx : OK pour l'envoi
    • 5xx : Erreur permanente (exemple: spam détecté par SpamAssassin, virus par ClamAV, etc.).
  • Émetteur : Fermeture de la connexion.

Installation et configuration

Postfix

Configuration de base

Ce tutoriel part du principe que postfix est déjà correctement installé et configuré pour l'émission et la réception de mails.

La configuration de postfix sera modifiée au fur et à mesure de l'installation des différents services.

Postfix, s'il est configuré en tant que serveur de mail visible depuis internet, doit être configuré pour autoriser la réception de messages depuis n'importe où et l'émission uniquement depuis le réseau local. Si ce n'est pas le cas, le serveur de mail sera configuré en mode open relay. Bien évidemment un tel serveur serait une plateforme d'envoi de spams ou autres saletés. Il serait très vite blacklisté auprès des différentes RBL.

Pour ce tutoriel, le serveur de mail nommé ve-mail hébergera des adresses du domaine kafe-in.net et le réseau local sera composé de 192.168.2.0/24 en IPv4 et 2001:910:109c::/48 en IPv6.

main.cf :

mydomain = kafe-in.net
mydestination = ve-mail, ve-mail.kafe-in.net, localhost.localdomain, localhost, kafe-in.net
mynetworks = 127.0.0.0/8, [::1]/128, 192.168.2.125/32, [2001:910:109c::]/48

Restrictions de base

Dans un premier temps, il faut indiquer à postfix qu'il faut délayer le rejet d'un mail à la fin du dialogue avec dialogue avec le serveur SMTP distant. C'est le paramètre smtpd_delay_reject. Ceci permet 3 choses :

  • certains serveurs SMTP ne prennent pas en compte les rejets pendant l'émission d'un mail et essaient donc de finir de l'envoyer même s'il a été refusé,
  • postfix peut ainsi logger plusieurs informations intéressantes relatives à l'émetteur et au destinataire du mail,
  • une adresse émettrice peut être rejetée selon le destinataire du mail (ex: greylisting), il faut donc avoir tous les paramètres du mail avant de prendre une décision.

Le paramètre smtpd_helo_required permet de n'autoriser la réception de mail que si le serveur distant s'est présenté (HELO). Cela permet d'introduire des restrictions par rapport à cette commande SMTP (voir plus bas).

Le paramètre strict_rfc821_envelopes permet de refuser la réception de mail si le serveur distant ne respecte pas strictement la rfc821, celle qui décrit le protocole SMTP.

main.cf, restrictions de base :

# Basics Restrictions 
smtpd_delay_reject = yes
smtpd_helo_required = yes
strict_rfc821_envelopes = yes

Postfix applique ensuite des restrictions selon les paramètres du mail, dans l'ordre suivant :

  • restrictions sur le client, c'est à dire sur l'adresse IP du serveur émetteur,
  • restrictions sur le mot clé HELO lors du dialogue avec ce serveur,
  • restrictions sur le mot clé MAIL from, c'est à dire sur l'adresse mail de l'émetteur,
  • restrictions sur le mot clé RCPT to, c'est à dire sur l'adresse mail du destinataire,

Une liste de restrictions, dans postfix, est définie avec la syntaxe suivante :

smtpd_*nom*_restrictions = restriction 1, restriction 2, ..., restriction n

Elles sont parcourues dans l'ordre, jusqu'à ce que l'une d'entre elle accepte ou rejette le mail. La dernière restriction est permit, ainsi le mail est accepté si rien n'a indiqué explicitement son rejet ou sa validation.

Restrictions sur le client

Ici, notre serveur est public, il doit donc accepter les connexions entrantes depuis n'importe quelle adresse IP.

main.cf, restrictions sur le client :

# Requirements for the connecting server 
smtpd_client_restrictions =
        permit

Restrictions sur HELO

Comme on n'est pas des sauvages, on ne positionne aucunes restrictions si l'émetteur se situe sur notre réseau local (paramètre mynetwork, voir plus haut). Par contre, pour toutes les autres adresses IP source, on vérifie que le domaine indiqué après la commande HELO correspond à un FQDN et que celui-ci correspond à un nom d'hôte valide.

main.cf, restrictions sur le mot clé HELO :

# Requirements for the HELO statement 
smtpd_helo_restrictions =
        permit_mynetworks,
        reject_non_fqdn_hostname,
        reject_invalid_hostname,
        permit

Restrictions sur l'adresse de l'émetteur

De la même façon, il est préférable de refuser des mails ayant un domaine inexistant ou mal formé, sauf pour notre réseau local.

main.cf, restriction sur l'émetteur (sender) :

# Requirements for the sender address 
smtpd_sender_restrictions =
        permit_mynetworks,
        reject_non_fqdn_sender,
        reject_unknown_sender_domain,
        permit

Restrictions sur l'adresse du destinataire

On autorise notre LAN à envoyer des mails à destination de n'importe quelle adresse. Par contre, pour les autres, on refuse les mails à destination d'une adresse mal formée (reject_non_fqdn_recipient et reject_unknown_recipient_domain) ou bien inconnue du serveur (reject_unauth_destination). C'est à dire dont la partie domaine de l'adresse n'est pas listée dans les variables mydestination ou relay_domains. Le refuser si la boite n'existe pas sera le travail du LDA (Local Delivery Agent), c'est à dire le programme qui délivre le mail dans la boite maildir ou mbox du destinataire.

# Requirement for the recipient address 
smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_non_fqdn_recipient,
        reject_unknown_recipient_domain,
        reject_unauth_destination,
        permit

Content filters

Les content filters sont des mini-serveurs SMTP analysant les mails entrants et les renvoyants ou pas sur un autre serveur SMTP. Postfix est donc le serveur source pour les content filters ainsi que le serveur de destination. Si un mail revient des content filters sans encombres, il est valide.

Les content filters peuvent être chaînés. Le premier écoute sur un port (ex: 10025) puis le passe au second sur un autre port (ex: 10026) qui le retransmet au serveur postfix de départ sur un port défini (ex: 10027). En cas de problème sur le second content filter, il retourne une erreur 5xx au premier content filter qui retourne donc cette erreur au serveur postfix de départ. Les refus sont ainsi transmis en cascade et pris en compte par postfix au final.

main.cf, content filters :

# Content filtering
content_filter = scan:127.0.0.1:10025
receive_override_options = no_address_mappings

Le port de destination des contents filters est écouté par un simple smtpd mais avec aucune restrictions ni autre content filters définis. Si ce n'était pas le cas, les mails entrant partirait en boucle dans le serveur de mail et serait refusés au final. Ce port est ouvert uniquement pour localhost (127.0.0.1) pour éviter qu'un serveur distant n'envoie un mail directement par ce biais.

master.cf, définition des services d'émission et de réception des content filters :

# AV scan filter (used by content_filter)
scan      unix  -       -       n       -       16      smtp
        -o smtp_send_xforward_command=yes
# For injecting mail back into postfix from the filter
127.0.0.1:10027 inet  n -       n       -       16      smtpd
        -o content_filter=
        -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
        -o smtpd_helo_restrictions=
        -o smtpd_client_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks_style=host
        -o smtpd_authorized_xforward_hosts=127.0.0.0/8

ClamSMTPd

L'interface entre postfix et ClamAV peut être faite de différentes manières. La plus simple à mettre en place est d'utiliser le daemona ClamSMTP.

C'est un simple content filter pour lequel on définit le port d'entrée selon le paramètre content_filter de postfix et le port de sortie comme le port du prochain content filter mis en place ou bien celui de postfix si on ne désire pas en mettre en place d'autres.

Installation de ClamSMTP :

# apt-get install clamsmtp clamav-daemon

/etc/clamsmtpd.conf, fichier de configuration du daemon :

# Port et adresse IP sur lesquels le daemon écoute
Listen: 127.0.0.1:10025

# Port et adresse IP sur lesquels le mail sera forwardé
OutAddress: 127.0.0.1:10026

# Chemin vers la socket unix ouverte par le daemon ClamAV
ClamAddress: /var/run/clamav/clamd.ctl

# Header ajouté au mail pour indiquer qu'il a bien été scanné
Header: X-AV-Checked: ClamAV using ClamSMTP

# Répertoire temporaire
TempDirectory: /var/spool/clamsmtp

# Chemin vers le fichier PID
PidFile: /var/run/clamsmtp/clamsmtpd.pid

# Action effectuée en cas de détection de virus :
# * bounce : retour à l'envoyeur (pas génial car l'adresse émettrice est souvent spoofée)
# * drop : le mail est supprimé silencieusement
# * pass : le mail est accepté mais le header X-Virus-Infected est ajouté
Action: drop

# Si 'on', les mails infectés sont stockés dans le répertoire temporaire
Quarantine: on

# Nom d'utilisateur sous lequel le programme tourne (ne pas utiliser root !)
User: clamsmtp

SpamPD

SpamPD est un proxy mail (un content filter) codé en perl et utilisant SpamAssassin pour tagger les mails en tant que spam ou ham (non spam).

_ Installation de SpamPD :_

# apt-get install spampd spamassassin

/etc/default/spampd, configuration du daemon :

# Démarrage du daemon au boot
STARTSPAMPD=1

# Chemin vers le fichier PID
PIDFILE=/var/run/spampd.pid

# Port et adresse IP sur lesquels le daemon écoute
LISTENHOST=127.0.0.1
LISTENPORT=10026

# Port et adresse IP sur lesquels le mail sera forwardé
DESTHOST=127.0.0.1
DESTPORT=10027

# Nombre de processus enfants (trop = beaucoup de ressources utilisées, pas assez = traitement des mails lent en cas de gros trafic)
CHILDREN=3

# Nom d'utilisateur et groupe sous lesquels le daemon tourne (pas root !)
USERID=spampd
GRPID=spampd

# Ajoute les headers de SpamAssassin indiquant que le mail a été scanné même s'il n'a pas été identifié comme spam.
TAGALL=1

# Option non utilisée depuis SpamAssassin >= 3.x
AUTOWHITELIST=0

# Désactivation de tous les tests sur l'adresse IP source (ici ce sera toujours 127.0.0.1)
LOCALONLY=1

# Utilisation de syslog via une socket unix (=0) ou une socket IP (=1)
LOGINET=0

# Options additionnelles à passer à SpamAssassin
ADDOPTS="" 

Postgrey

Postgrey est un policy server (voir plus haut) qui est appelé par postfix si besoin et via un port TCP. Ici le port 10023 a été choisi de façon arbitraire.

Installation de postgrey :

# apt-get install postgrey

/etc/default/postgrey, configuration du service :

# --inet    : Port utilisé pour dialoguer avec postfix
# --delay   : Durée en secondes pendant laquelle les mails sont refusés
# --max-age : Période en jour après laquelle le compteur d'émission est remis à zéro si pas de nouvelle réémission d'un mail
POSTGREY_OPTS="--inet=10023 --delay=300 --max-age=35" 

# Message renvoyé en plus de l'erreur 4xx au serveur émettant le mail
POSTGREY_TEXT="Good news, everyone ! I taught the mail server to detect spambots." 

main.cf, ajout du policy service postgrey aux restrictions sur le destinataire :

# Requirement for the recipient address 
smtpd_recipient_restrictions =
*snip*
        check_policy_service inet:127.0.0.1:10023,
        permit

RBL

Les RBL sont directement gérées par postfix en ajoutant une restriction reject_rbl_client pour le client (le serveur émetteur du mail). Il existe bon nombre de RBL (ou DNSBL), wikipedia en liste un bon nombre mais en voici quatre plutôt « réputées » :

main.cf, configuration des RBL :

smtpd_client_restrictions =
        permit_mynetworks,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client dnsbl.njabl.org,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client sbl-xbl.spamhaus.org,
        permit

Policyd-SPF

Configuration du serveur de mail

La vérification SPF peut se faire via deux daemon « policy », un en perl et un en python. Leur installation et leur configuration dans postfix se fait exactement de la même manière. Seul le nom du paquet change (postfix-policyd-spf-perl ou postfix-policyd-spf-python).

Installation de policy-spf :

# apt-get install postfix-policyd-spf-python

main.cf, ajout du policy service postgrey aux restrictions sur le destinataire :

# SPF
policyd-spf_time_limit = 3600

smtpd_recipient_restrictions =
*snip*
        check_policy_service unix:private/policyd-spf,
        permit

master.cf, définition de la socket permettant de dialoguer avec postfix-spf :

policyd-spf  unix  -       n       n       -       0       spawn
        user=nobody argv=/usr/bin/python /usr/bin/policyd-spf
        /etc/postfix-policyd-spf-python/policyd-spf.conf

Configuration du nom de domaine

La configuration du nom de domaine est facultative mais recommandée car elle permet aux serveurs distants de vérifier que les mails ayant notre nom de domaine dans l'adresse source proviennent bien de notre serveur. Cela permet de ne pas se faire « spoofer » nos adresses.

vspf=1 [qualifier]mechanism1 [qualifier]mechanism2 .. [qualifier]mechanisN

Les mechanisms sont des paramètres appliqués ou non selon les valeurs associées. En voici la liste (non-exhaustive ) :

  • all, s'applique tout le temps.
  • a, s'applique si le domaine de l'émetteur peut être résolu (A ou AAAA) en l'adresse IP de l'émetteur.
  • mx, s'applique si l'adresse IP de l'émetteur correspond au(x) MX du domaine.
  • ip:11.22.33.44, s'applique si l'adresse IP de l'émetteur est 11.22.33.44
  • ip6:1111:2222:3333::, idem pour IPv6.
  • ptr:server.domain.tld, s'applique si le reverse de l'IP de l'émetteur est server.domain.tld et que server.domain.tld peut être résolu en l’adresse IP de l’émetteur.
  • include:domain.tld, s'applique si les mechanism définis dans le champs SPF de doman.tld s'appliquent aussi.

Les qualifiers permette de définir l'action à effectuer lors qu'un mechanism est appliqué :

  • +, le mail est accepté si le mechanism est vérifié. C'est la valeur par défaut.
  • ?, le mechanism associé est ignoré.
  • ~, le mail n'est pas refusé mais il devrait être noté comme refusé par le serveur utilisant SPF.
  • -, le mail est refusé si le mechanism n'est pas vérifié.

Ainsi, le champs SPF du domaine kafe-in.net :

      IN SPF v=spf1 mx ptr:muscat.kafe-in.net ip6:2a01:6600:8081:8e00::fab ip4:91.224.149.142 -all

A pour signification :

  • Si un mail a pour adresse *@kafe-in.net :
    • S'il provient d'un des MX de la zone kafe-in.net, alors il peut être accepté,
    • Si le reverse du serveur émetteur est muscat.kafe-in.net, alors il peut être accepté,
    • Si l'adresse IPv6 du serveur émetteur est 2a01:6600:8081:8e00::fab, alors il peut être accepté,
    • Si l'adresse IPv4 du serveur émetteur est 91.224.149.142, alors il peut être accepté,
    • Si aucune des conditions précédentes n'a été vérifiées, alors le mail doit être refusé.

Le champs SPF est défini dans la RFC448 mais certains serveurs n'appliquent pas cette RFC et ne lisent que les champs TXT du domaine. Il est donc préférable de définir à la fois un champs SPF et un champs TXT.

OpenDKIM

OpenDKIM est un milter appelé par postfix sur un port TCP. Ici le port 10028 a été choisi arbitrairement.

Installation de opendkim :

# apt-get install opendkim

main.cf, ajout du milter opendkim :

# DKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:10028
non_smtpd_milters = inet:127.0.0.1:10028

/etc/opendkim.conf, configuration du milter :

# Auto-redémarrage du daemon en cas de plantage
AutoRestart             Yes
Background              Yes

# Domaines pour lesquels les mails doivent être signés
Domain                  localhost.localdomain,localhost,kafe-in.net

# Adresses IP des machines internes ne nécessitant pas de vérification
InternalHosts           127.0.0.0/8,[::1]/128,192.168.2.125/32,[2001:910:109c::]/48

# Chemin vers la clé privée
KeyFile                 /var/lib/dkim/default.private

# Adresse mail à laquelle un rapport sera envoyé en cas de détection de mail mal signé
ReportAddress           "DKIM Error Postmaster" <postmaster@kafe-in.net>

# Nom du sélecteur utilisé dans le cas où il y a plusieurs clés pour un même domaine
Selector                default

# Définition de la socket sur laquelle le daemon écoute. Peut être :
# - inet:port@host
# - inet6:port@host
# - unix:/chemin/vers/la/socket
Socket                  inet:10028@localhost

# Configuration de l'utilisation de syslog
Syslog                  Yes
SyslogFacility          mail

Une fois OpenDKIM installé, il faut générer la paire de clés privée/publique permettant de signer le mail. La clé privée est stockée dans le fichier /var/lib/dkim/default.private et la clé publique dans un champ TXT du domaine. OpenDKIM fourni divers outils dont opendkim-genkey qui permet de générer cette paire de clé.

Installation des outils d'opendkim :

# apt-get install opendkim-tools

_ Génération de la paire de clé :_

# opendkim-genkey -d kafe-in.net -s default
# mkdir -p /var/lib/dkim
# mv default.private /var/lib/dkim
# chmod 640 /var/lib/dkim/default.private

Le champs TXT est généré par opendkim-genkey dans le fichier default.txt. Il suffit d'ajouter son contenu à la zone kafe-in.net.

_ Champs TXT pour DKIM du domaine kafe-in.net :_

default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/B6ZgFIeKutA6W6jgaH4LCpDtHY5SNUmmFnt+Um68pYO6YZSNUF+mbxtN2+P4fI+CoFgoFEViI+HcRWMPd7IWMgoTTSwF4hOqzw8kscP/R+h2ZV/ogPQBbH8tWc6NyvIA6RnRwET5OUOEt4zOb7WwO26jmn+L1rIXgQb5I6ZqTwIDAQAB" ; ----- DKIM key default for kafe-in.net

Une fois tout installé, configuré et généré, il faut démarrer le daemon opendkim pour prise en compte.

Redémarrage du daemon opendkim :

# /etc/init.d/opendkim start

Vérifications

Postfix et open relay

Maintenant que tout est configuré au niveau du serveur de mail, on peut vérifier qu'il n'est pas en mode « open relay ». C'est à dire qu'il n'autorise pas l'émission de mails depuis d'autres domaines que celui qu'il gère. Si 'était le cas, il serait très vite utilisé par les vilains spammeurs pour polluer nos boites mail.

Il existe bon nombre de tests en ligne. Celui de DNS Goodies fonctionne plutôt bien.

Good News!
All tests for an open relay on your mail server failed.
Your mail server does not allow open relay.

Détection de virus

EICAR est une chaîne de caractères utilisée pour valider la détection de virus. Ce n'est pas un virus méchant, c'est juste un faux virus de test reconnus par tous les anti-virus.

Pour tester notre serveur de mail, il suffit donc d'envoyer cette chaîne de caractère par mail à une de nos boites :

Envoi du virus de test :

$ echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' | mail -s "Test d'antivirus" test@kafe-in.net

Vérification de sa détection dans les logs :

# tail -fn 100 /var/log/mail.log
*snip*
Aug 17 09:00:36 ve-mail postfix/smtpd[1957]: 898B62022F: client=localhost[127.0.0.1], orig_queue_id=E9D552012C, orig_client=unknown[2001:910:109c:1::cab]
Aug 17 09:00:36 ve-mail clamsmtpd: 10002E: quarantined virus file as: /var/spool/clamsmtp/virus.z3YbhR
Aug 17 09:00:36 ve-mail postfix/smtp[1954]: E9D552012C: to=<test@kafe-in.net>, relay=127.0.0.1[127.0.0.1]:10025, delay=3.7, delays=1.2/0/2.4/0.14, dsn=2.0.0, status=sent (250 Virus Detected; Discarded Email)
Aug 17 09:00:36 ve-mail postfix/qmgr[479]: E9D552012C: removed
Aug 17 09:00:36 ve-mail clamsmtpd: 10002E: from=test@kafe-in.net, to=test@kafe-in.net, status=VIRUS:EICAR-Test-Signature
Aug 17 09:00:36 ve-mail postfix/smtpd[1957]: disconnect from localhost[127.0.0.1]
*snip*

Détection de spams

De la même façon que EICAR, GTUBE (Generic Test for Unsolicited Bulk Email) est une chaîne de caractère détectée par SpamAssassin comme étant un spam.

La vérification se déroule à peu prêt de la même manière : envoi de la chaîne de caractère, puis vérification des headers dans le mail reçu. Attention, pas mal de clients mails vont déplacer ce mail dans une boite dédiées aux spams.

Envoi du faux spam de test :

$ echo 'XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X' | mail -s "Test d'antispam" test@kafe-in.net

Headers ajoutés au mail reçu :

X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ve-mail.kafe-in.net
X-Spam-Flag: YES
X-Spam-Level: **************************************************
X-Spam-Status: Yes, score=1003.0 required=5.0 tests=GTUBE,MISSING_MID,
        RDNS_NONE,TVD_SPACE_RATIO autolearn=no version=3.3.2

Validation du greylisting

Pour valider le greylisting, il suffit de s'envoyer une mail depuis une boite mail externe et de vérifier les logs du serveur de mail. Lors de la première réception du mail, celui-ci doit être refusé temporairement avec un code d'erreur 4xx (ici, 450).

Greylisting dans les logs du serveur de mail :

# tail -fn 100 /var/log/mail.log
*snip*
Aug 17 00:53:34 ve-mail postfix/smtpd[22763]: NOQUEUE: reject: RCPT from muscat.kafe-in.net[2a01:6600:8081:8e00::fab]: 450 4.2.0 <test@kafe-in.net>: Recipient address rejected: Good news, everyone ! I taught the mail server to detect spambots.; from=<whatever@domain.tld> to=<test@kafe-in.net> proto=ESMTP helo=<muscat.kafe-in.net>
*snip*

Validation des RBL

Ce n'est pas facile de vérifier les RBL dans postfix. Il faudrait s'auto-blacklister une adresse IP et ce n'est quand même pas conseillé. Ceci-dit, une fois qu'un serveur de mail est rendu visible d'Internet, il est très vite assailli de mails. Il ne devrait pas trop se passer de temps avant que des mails bloqués par les RBL arrivent. On peut vérifier ça dans les logs du serveur de mail.

RBL dans les logs du serveur de mail :

# tail -fn 100 /var/log/mail.log
*snip*
Aug 17 01:02:35 ve-mail postfix/smtpd[23453]: NOQUEUE: reject: RCPT from unknown[176.44.93.9]: 554 5.7.1 Service unavailable; Client host [176.44.93.9] blocked using cbl.abuseat.org; Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=176.44.93.9; from=<826AD18@julianenpark.de> to=<test@kafe-in.net> proto=SMTP helo=<[176.44.93.9]>
*snip*

Validation de SPF

Validation de la policy

Pour vérifier la policy, il suffit de s'envoyer un mail depuis une adresse mail dont le domaine dispose du champs SPF (ex: gmail.com).

Interrogation du champs SPF du domaine gmail.com :

$ dig -t txt gmail.com +short                                                                                                                                                                                                 
"v=spf1 redirect=_spf.google.com" 
$ dig -t txt _spf.google.com +short                                                                                                                                                                                           
"v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all" 

Logs de réception d'un mail depuis gmail.com :

# tail -fn 100 /var/log/mail.log
*snip*
Aug 17 09:47:27 ve-mail policyd-spf[2765]: None; identity=helo; client-ip=209.85.214.171; helo=mail-ob0-f171.google.com; envelope-from=whatever@gmail.com; receiver=test@kafe-in.net 
Aug 17 09:47:27 ve-mail policyd-spf[2765]: Pass; identity=mailfrom; client-ip=209.85.214.171; helo=mail-ob0-f171.google.com; envelope-from=whatever@gmail.com; receiver=test@kafe-in.net 
*snip*

Headers du mail reçu :

*snip*
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.85.214.171; helo=mail-ob0-f171.google.com; envelope-from=whatever@gmail.com; receiver=test@kafe-in.net 
*snip*

Par contre, on peut tester le refus d'un mail grâce à SPF en s'envoyant un mail, depuis une adresse IP externe, avec pour source une adresse @gmail.com. SPF va vérifier que l'adresse IP ne correspond pas à celles définies dans le champs SPF de la zone gmail.com et va refuser le mail.

Envoi d'un « faux » mail gmail.com :

$ telnet 80.67.176.156 25
Connected to 80.67.176.156
Escape character is '^]'.
220 ve-mail.kafe-in.net ESMTP kafe-in.net (I'm Scruffy... the Janitor.)
HELO gmail.com
250 ve-mail.kafe-in.net
MAIL from: <test@gmail.com>
250 2.1.0 Ok
RCPT to: <test@kafe-in.net>
550 5.7.1 <test@kafe-in.net>: Recipient address rejected: Message rejected due to: access neither permitted nor denied. Please see http://www.openspf.net/Why?s=helo;id=gmail.com;ip=103.6.65.2;r=test@kafe-in.net
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Logs du refus sur le serveur de mail :

# tail -fn 100 /var/log/mail.log
*snip*
Aug 17 09:56:26 ve-mail policyd-spf[6051]: Neutral; identity=helo; client-ip=103.6.65.2; helo=gmail.com; envelope-from=test@gmail.com; receiver=test@kafe-in.net 
Aug 17 09:56:26 ve-mail postfix/smtpd[6035]: NOQUEUE: reject: RCPT from unknown[103.6.65.2]: 550 5.7.1 <test@kafe-in.net>: Recipient address rejected: Message rejected due to: access neither permitted nor denied. Please see http://www.openspf.net/Why?s=helo;id=gmail.com;ip=103.6.65.2;r=test@kafe-in.net; from=<test@gmail.com> to=<test@kafe-in.net> proto=SMTP helo=<gmail.com>
*snip*

Validation du champs SPF pour le nom de domaine

Le champs SPF peut être validé grâce à l'outil spfquery. Cet outil permet d'interroger le champs SPF d'un nom de domaine et de valider ou pas ce champs en fonction de paramètres d'un mail (émetteur, récepteur, etc.).

Installation de spfquery :

# apt-get install spfquery

Validation du domaine kafe-in.net :

$ spfquery -ip 80.67.176.156 -sender test.kafe-in.net -helo mail.kafe-in.net -rcpt-to test@kafe-in.net
pass

spfquery: domain of kafe-in.net designates 80.67.176.156 as permitted sender
Received-SPF: pass (spfquery: domain of kafe-in.net designates 80.67.176.156 as permitted sender) client-ip=80.67.176.156; envelope-from=test@kafe-in.net; helo=mail.kafe-in.net;

Validation de DKIM

Validation du milter OpenDKIM

De même que pour SPF, pour tester DKIM il suffit de s'envoyer un mail depuis une boite dont le serveur signe les mails, par exemple gmail.com. Le résultat de la validation de la signature du mail est visible dans les headers du mail.

Headers correspondant à la signature d'un mail :

Authentication-Results: ve-mail.kafe-in.net; dkim=pass
        reason="2048-bit key; insecure key" header.i=@gmail.com
        header.b=YblIqntw; dkim-adsp=pass; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:date:message-id:subject:from:to:content-type;
        bh=hPPI4v8dQehE4w4uUfmkx8PSxwisYyowXufU8qvkDu8=;
        b=YblIqntwajS0Y5tTvLXmoMNuiIgfdIN/iVQEBYUEy8CYZvPtOo7R66sT+FqcMCq4kt
         W3DEKRPeYpty/aqTP42WvP3hGK2x/Ar1azrUiAH2JkKqkmaH13DRHXyOspmGMk/oIuXa
         O90qSPZtOrgGA5/6fJUi7ioJL8dDiEXbnkCEoknVcaP1T8Rm9XmT2ikQLcqI2J/h4F7o
         9iIa+UrU8OQ/f6MP67YV3kmMqeTkk9w1fcvPM+l29F/lb3mKdOGiMddoPLGvh2Khe1OR
         BBVDdPmhcMtR+3Oijf3BUJFgZK+Fo9DJrlauDXpl35yA7cDVZIairP66StWX+dswjXMu
         /giQ==

Validation du champs TXT pour le nom de domaine

La validation du champs TXT d'un nom de domaine peut se faire en ligne sur dkimcore.org par exemple ou bien, tout simplement, en envoyant un mail à un serveur vérifiant les signatures DKIM (toujours gmail.com).

Headers d'un mail signé reçu par gmail :

Authentication-Results: mx.google.com; spf=pass (google.com: domain of test@kafe-in.net designates 80.67.176.156 as permitted sender) smtp.mail=test@kafe-in.net; dkim=pass header.i=@kafe-in.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kafe-in.net;
        s=default; t=1345197103;
        bh=4z3/ZP7zCKksb7M9Tss8QbgzOTP4YCBLM4qIxozbd7o=;
        h=Date:From:To:Subject;
        b=V7bIXcxv+wICKCX8AvN8cwex1LP/tRZabciI9A68gmccoG9NWRg/DFS63yOZhDITy
         e4x4tVqt++4IhDTSgqNx5ILbLUrwHQNzgAGuTS96EjamjZRqFvLvvzSNg+DA0MThbd
         AVymYUIXS/2gf1HYxpsSArQL34YlUt4Spow2owwg=

Puppetisation du tout

Tous ces logiciels, ainsi que postfix, peuvent bien évidemment être installés et configurés via puppet.

J'ai d'ailleurs écrit un module puppet-mailserver pour ça, il peut être utilisé sans soucis (voir ma conf à titre d'exemple).

Liens