Tuto Messagerie, partie V : Policyd SPF et Postscreen

Tutoriel révisé en décembre 2022 / Debian 11

Cinquième partie de ma série d’articles sur la mise en place d’un serveur mail complet.

Nous allons ajouter Polycyd SPF et Postscreen, deux outils bien pratiques dans la lutte contre le spam.

 

I – Policyd SPF

SPF (Sender Policy Framework) est un mécanisme simple qui permet de savoir si un SMTP à l’origine d’un mail est bien légitime .

Cela s’appuie sur un enregistrement TXT dans le DNS qui ressemble à ça :

"v=spf1 ip4:ip.legitime mx -all"

Cet enregistrement stipule quel MX est autorisé à envoyer depuis le domaine.

Ici, on va mettre en place la vérification pour les mails entrants, la création dans notre DNS de notre propre SPF se fera dans la partie VII.

On commence en installant le module SPF python (il existe aussi une version perl, mais celle en python est mieux maintenue et nécessite moins de dépendances, puis le python, c’est la vie !)

# apt install postfix-policyd-spf-python

Il se configure dans le fichier /etc/postfix-policyd-spf-python/policyd-spf.conf ou vous indiquez ceci :

debugLevel = 1

HELO_reject = Fail
Mail_From_reject = Fail

PermError_reject = False
TempError_Defer = False

skip_addresses = 127.0.0.0/8,10.0.0.0/8

Les mails qui ne respectent pas les SPF seront rejetés. Par contre, s’il n’y a pas de SPF définis, on accepte (les refuser ici est une mauvaise idée, nombre de domaines légitimes n’ont pas de SPF en place…)

Ensuite, dans le fichier /etc/postfix/master.cf on va ajouter en bas :

policyd-spf unix - n n - - spawn
  user=nobody argv=/usr/bin/policyd-spf

Et dans le /etc/postfix/main.cf, on ajoute tout d’abord une ligne :

policyd-spf_time_limit = 3600s

puis en dessous, dans le bloc smtpd_sender_restrictions, on ajoute :

smtpd_sender_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    check_sender_access ldap://etc/postfix/ldap/check_sender_domains_reject.cf,
    check_policy_service unix:private/policyd-spf,
    [...]

On recharge :

# postfix reload

Dorénavant, chaque mail entrant subira une vérification SPF. On pourra l’observer en regardant les headers d’un mail qu’on reçoit :

Received: from mail.domaine1.fr
	by mail (Dovecot) with LMTP id N59BECWohFzNVwAAZU03Dg
	for <toto@domaine1.fr>; Mon, 21 Jul 1969 02:56:20 +0000
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=blablabla...

Voila pour le contrôle SPF qui va permettre d’écrémer un peu plus.

 

II – Postcreen

On arrive à la chose la plus efficace pour lutter contre le spam bête et méchant. S’il ne devait en rester qu’un, ce serait lui je pense. Pourtant il ne réinvente rien et utilise des principes déjà connus, mais il le fait bien et simplement.

Il est le bouclier contre les zombies/bots, etc… que je résume en « les lourds »…

Il est… Postscreen !

A – Activation

Postscreen étant intégré dans Postfix, rien à installer, il suffit de l’activer.

Dans le fichier /etc/postfix/master.cf, commentez la ligne :

smtp  inet   n   -   y   -   -   smtpd

et décommentez juste en dessous :

smtp  inet   n   -   y   -   1   postscreen
smtpd pass   -   -   y   -   -   smtpd
 -o cleanup_service_name=subcleanin
dnsblog  unix   -   -   y   -   0   dnsblog
tlsproxy unix   -   -   y   -   0   tlsproxy

On active postscreen, dnsblog pour les checks Dns Blacklist et tlsproxy qui active le support STARTTLS pour postscreen (qui prend la main sur le port 25, en amont du démon SMTP.

Au final, on a donc ça au début :

smtp inet n - y - 1 postscreen
smtpd pass - - y - - smtpd
  -o cleanup_service_name=subcleanin
dnsblog unix - - y - 0 dnsblog
tlsproxy unix - - y - 0 tlsproxy
submission inet n - y - - smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o cleanup_service_name=subcleanout
smtps inet n - y - - smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_wrappermode=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o cleanup_service_name=subcleanout
#628 inet n - y - - qmqpd
[...]

Le reste de la configuration se passera dans le fichier /etc/postfix/main.cf.

B – Configuration

Postscreen peut faire deux types de contrôles :

• des contrôles simples
• des contrôles profonds

Les contrôles simples se fond avant de passer la main à Postfix. Si tout est Ok, le mail suit son chemin.

Au contraire, les contrôles profonds prennent la main sur l’ensemble du dialogue et introduisent de par ce fait, un greylisting. J’y reviens plus bas.

Pour chaque contrôle, on peut définir une action :

• ignore : on ne fait rien. Peut servir en cas de debug.
• enforced : le blocage est actif, mais la coupure se fera au moment du RCPT TO: avec une réponse 550 5.3.2 Service currently unavailable
• drop : efficace, on coupe court avec une réponse 521 5.3.2 Service currently unavailable

Un serveur qui sera accepté sera mis en liste blanche pour les prochaines fois afin de ne pas mobiliser de la ressource pour rien.

1 – Contrôles simples

Simples ne veut pas dire inefficaces. Personnellement, je n’utilise qu’eux, n’aimant pas le principe du greylisting.

a – Access list

Simplissime, ce contrôle va permettre de bloquer des IPs et contrairement au blocage dans Postfix, ici avec l’action sur drop, c’est immédiat. Ciao !

Pour l’activer, ajoutez ces lignes dans le fichier /etc/postfix/main.cf :

postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = drop

Le fichier /etc/postfix/postscreen_access.cidr doit ressembler à cela :

xxx.xxx.xxx.xxx reject
[...]

b – Greet banner

Ce contrôle joue sur une subtilité du protocole SMTP.

Une réponse 250 classique est de la forme :

250 mail.domaine1.fr ESMTP mail (Debian/GNU)

Si le serveur répond avec

250-On attend un pneu...

le tiret après le 250 indique qu’il y a plusieurs lignes.

Et il attend le temps indiqué avant d’envoyer :

250 mail.domaine1.fr ESMTP mail (Debian/GNU)

Du coup, un zombie trop rapide se fera avoir, et hop, dehors !

Pour l’activer, ajoutez ces lignes dans le fichier /etc/postfix/main.cf :

postscreen_greet_wait = 3s
postscreen_greet_banner = On attend un pneu...
postscreen_greet_action = drop

Le temps d’attente sert également à Postscreen pour consulter les Dnsbl qu’on voit juste en dessous.

c – Dnsbl

Ici, on va interroger des RBL.

Le principe est simple. On passe par une interrogation DNS pour savoir si un MX distant est légitime ou non.

Une réponse du genre 127.0.0.X indique qu’il ne faut pas accepter le mail (le type de réponse dépend de la liste dans la quelle se trouve l’IP). On peut éventuellement ne prendre que certaines réponses.

Pour l’activer, ajoutez ces lignes dans le fichier /etc/postfix/main.cf :

postscreen_dnsbl_sites =
 zen.spamhaus.org*2,
 bl.spamcop.net,
 b.barracudacentral.org*2
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_action = drop

J’utilise trois listes. En mettre de trop n’est pas forcement une bonne idée, temps d’interrogation plus long, trouver comment bien pondérer chacune…

Sachez cependant qu’il en existe plein. Vous en trouverez ici par exemple : https://www.dnsbl.info/dnsbl-list.php

Pour faire une interrogation à la main, si votre IP est AAA.BBB.CCC.DDD :

# dig +short DDD.CCC.BBB.AAA.b.barracudacentral.org

On passe par un PTR record, ce qui fait qu’on peut connaitre « l’état » d’une IP en interrogeant n’importe quel DNS, ce dernier ira faire la requête au bon endroit.

Si pas de retour, l’IP n’est pas blacklisté, si retour, IP blacklisté donc.

2 – Contrôle profond

Très efficace contre les « lourds » qui ne respecte pas le protocole SMTP, ces vérifications ont cependant un inconvénient comme je l’expliquais :

Ils  introduisent un Greylisting. Pour effectuer ces vérifications, Postscreen prend en charge tout la communication SMTP, mais le bougre à la fin n’est pas capable de repasser la main à Postfix.

Postscreen règle le problème très « simplement » en répondant à la fin : 450 4.3.2 Service currently unavailable et en mettant au passage le serveur en liste blanche.

Le voila le Greylisting … Un serveur SMTP bien configuré se doit de retenter l’envoi et comme il sera reconnu par Postscreen,  ce dernier passera la main à Postfix.

Ça, c’est la théorie… Les trucs configurés avec les pieds, on en voit partout et il est tout a fait possible que le SMTP distant, bien que légitime, ne retente jamais. C’est pourquoi je n’aime pas le principe du Greylisting.

A vous de voir comme vous le sentez …

a – Pipelining

Postscreen ne gérant pas le pipelining (du full duplex en quelque sorte), il l’indique durant la communication. Un client « correct » le prendra alors en compte. Un « lourd », certainement que non, et bam !

postscreen_pipelining_enable = yes
postscreen_pipelining_action = enforce

b – Non SMTP Command

Contrôle sur d’éventuelles commandes CONNECT, GET et POST utilisées par les « lourds » passant par des proxys.

postscreen_non_smtp_command_enable = yes
postscreen_non_smtp_command_action = enforce

c – Bare Newline

La norme SMTP impose que chaque ligne se terminer par <CR><LF>. Les « lourds », souvent, n’utilisent que <LF>.

postscreen_bare_newline_enable = yes
postscreen_bare_newline_action = enforce

 

III – Conclusion

Voila pour ces petits ajouts à Postfix. Ils sont simples, mais efficaces comme vous pouvez le voir.

Avec tout le travail abattu jusque la, Rspamd que l’on va maintenant installer dans la partie VI va se sentir léger.