Contrôle d'accès et de relais SMTP avec PostfixContrôle d'accès et de relais SMTP avec PostfixLe serveur SMTP de Postfix reçoit le courrier depuis le réseau et est exposé à tous les virus et pourriels du l'Internet. Ce document présente les méthodes internes et externes qui contrôle quels messages SMTP accepter, quelles erreurs éviter, et comment tester votre configuration.
Sujets abordés dans ce document :
A sa création, l'Internet était un réseau amical. Les serveurs de messagerie transferaient le courrier de n'importe qui vers n'importe quelle destination. Aujourd'hui, les spammers abusent des serveurs qui continuent de transferer le courrier sans contrôle et les systèmes ainsi abusés finissent dans les listes noires anti-spammer. Consultez par exemple le sites spécialisés comme http://www.mail-abuse.org/.
Par défaut, Postfix a une approche restrictive du relais. Il ne transfère que le courrier des clients du réseau sûr (réseau interne) ou des domaines de la liste des relais autorisés. Pour plus de détails sur la configuration par défaut, reportez-vous au paragraphe concernant le paramètre smtpd_recipient_restrictions dans la page de manuel postconf(5) et aux informations ci-dessous.
La plupart des contrôles d'accès du serveur SMTP de Postfix sont destinés à stopper le pourriel.
Orientés protocole : certains contrôles du serveur SMTP bloquent le courrier en étant très strict sur le respect du protocole SMTP ; ceci élimine les logiciels de spam mal configurés ou mal implémentés comme les vers qui arrivent avec une implémentation de client SMTP non standard. Ces contrôles sont inefficaces face à des spammers et vers écrits en respectant les RFC.
Orientés listes noires : certains contrôles du serveur SMTP interrogent des listes noires de sites connus pour être nocifs comme les relais SMTP ouverts, les proxies ouverts et certaines machines compromises et sous le contrôle de pirates. L'efficacité de ces listes noires dépend de la fréquence de leurs mises à jour.
Orienté seuil : certains contrôles du serveur SMTP n'autorisent l'accès qu'après avoir fait effectuer un travail (listes grises) au client ou lui avoir demandé un élément non prévu (vérification de l'adresse de l'expéditeur/du destinataire et SPF). Les listes grises et politiques SPF sont externalisées et font l'objet de la page SMTPD_POLICY_README. La vérification des adresses d'expédition/de destination font l'objet de la page ADDRESS_VERIFICATION_README.
Malheureusement, tous les contrôles peuvent parfois rejeter du courrier légitime. Ceci peut être un problème sur des sites avec des profils d'utilisateurs différents : certains trouveront inacceptable de recevoir un pourriel alors que pour d'autres la perte d'un message prend un caractère de fin du monde. Comme il n'y a pas de politique parfaite pour tous, Postfix supporte des restriction d'accès différentes par utilisateurs. Cette caractéristique est décrite à la page RESTRICTION_CLASS_README.
Outre les restrictions pouvant être configurées par utilisateur, Postfix en implemente quelques unes qui s'appliquent à tous les messages SMTP.
Les restrictions internes sur le contenu header_checks et body_checks décrites à la page BUILTIN_FILTER_README. Ceci s'applique lorsque Postfix reçoit le courrier avant stockage dans la file d'attente entrante.
Les restrictions sur le contenu à la volée et externalisées décrites à la page SMTPD_PROXY_README. Ceci s'applique lorsque Postfix reçoit le courrier avant stockage dans la file d'attente entrante.
L'obligation pour le client d'utiliser la commande HELO ou EHLO avant MAIL FROM ou ETRN. Ceci peut poser problème avec les applications maison qui envoient du courrier. Pour cette raison, cette fonctionnalité est désactivée par défaut ("smtpd_helo_required = no").
Interdire les syntaxes non conformes dans les commandes MAIL FROM ou RCPT TO. Ceci peut poser problème avec les applications maison qui envoient du courrier et avec les vieux clients de messagerie. Pour cette raison, cette fonctionnalité est désactivée par défaut ("strict_rfc821_envelopes = no").
Interdire la syntaxe d'adresses RFC 822 (exemple: "MAIL FROM: the dude <dude@example.com>").
Interdire les adresses non encapsulées dans <> (example: "MAIL FROM: dude@example.com").
Rejeter le courrier provenant d'une adresse inexistante. Cette forme de filtrage aide à ralentir les vers et autres logiciels malfaisant mais peut poser problème avec les applications maison qui envoient du courrier avec une adresse inexistante. Pour cette raison, cette fonctionnalité est désactivée par défaut ("smtpd_reject_unlisted_sender = no").
Rejeter le courrier à destination d'une adresse inexsistante. Cette forme de filtrage aide à garder la file d'attente vide des messages non livrables MAILER-DAEMON messages. Cette fonctionnalité est activée par défaut ("smtpd_reject_unlisted_recipient = yes").
Postfix vous permet de définir des listes de restrictions d'accès pour chaque type de session SMTP. Ces restrictions individuelles sont décrites à la page de manuel postconf(5).
Des exemples de listes de restrictions simples:
/etc/postfix/main.cf:
# Autorise les connexions depuis le réseau sûr seulement.
smtpd_client_restrictions = permit_mynetworks, reject
# Ne pas communiquer avec les systèmes qui ne connaissent pas leur propre nom de machine.
# Avec Postfix < 2.3, utilisez reject_unknown_hostname
smtpd_helo_restrictions = reject_unknown_helo_hostname
# Ne pas accepter de courrier des domaines qui n'existent pas.
smtpd_sender_restrictions = reject_unknown_sender_domain
# Liste blanche: les clients locaux peuvent indiquer n'importe quelle destination, pas les autres.
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
# Bloquer les clients qui parlent trop tôt
smtpd_data_restrictions = reject_unauth_pipelining
# Contrôle les quotas de volume de message via un appel au service de politique
smtpd_data_end_of_restrictions = check_policy_service unix:private/policy
Chaque liste de restrictions est évaluée de la gauche vers la droite jusqu'à ce qu'une restriction produise un résultat parmi PERMIT, REJECT ou DEFER (essayer plus tard). La fin de liste est équivalente à PERMIT. En plaçant une restriction PERMIT avant une restriction REJECT vous pouvez faire des exceptions pour des clients ou utilisateurs particuliers. C'est ce qu'on appelle liste blanche ; le dernier exemple ci-dessus autorise le courrier depuis le réseau local mais rejete autrement les destinations arbitraires.
Le tableau ci-dessous résume les bouts poursuivis par chaque liste de restriction d'accès. Elles utilisent toutes la même syntaxe et ne diffèrent que par l'instant où elles sont appelées et l'effet d'un résultat REJECT ou DEFER.
Nom de liste de restriction Status Effet d'un REJECT ou DEFER smtpd_client_restrictions Optionel Rejete toutes le commandes du client smtpd_helo_restrictions Optionel Rejette les informations HELO/EHLO smtpd_sender_restrictions Optionel Rejette l'information MAIL FROM smtpd_recipient_restrictions Obligatiore Rejette l'information RCPT TO smtpd_data_restrictions Optionel Rejette la commande DATA smtpd_data_end_of_restrictions Optionel Rejette la commande END-OF-DATA smtpd_etrn_restrictions Optionel Rejette la commande ETRN
Les versions précédente de Postfix evaluaient les listes de restriction d'accès SMTP aussi vite que possible. La restriction basée sur le client était ainsi évaluée avant l'envoi de la bannière d'accueil "220 $myhostname...", la restriction basée sur la commande HELO (EHLO) avant la réponse HELO (EHLO) et la restriction basée sur la commande MAIL FROM avant la réponse, etc. Cette approche devient difficile à utiliser.
La version actuelle de Postfix retarde l'évaluation du client, du HELO et des restrictions sur l'expéditeur jusqu'à la commande RCPT TO ou ETRN. Ce comportement est contrôlé par le paramètre smtpd_delay_reject. Les listes sont tout de même évaluées dans le bon ordre (client, helo, etrn) ou (client, helo, expéditeur, destinataire, data). Lorsqu'une de ces listes retourne REJECT ou DEFER, les suivantes sont pas évaluées.
A l'époque ou le paramètre smtpd_delay_reject fut introduit, Postfix fut également modifié pour supporter des listes de restriction combinant les informations sur le client, la commande HELO, l'expéditeur, le destinataire et la commande ETRN.
Bénéfices de l'évaluation retardée des restriction et la combinaison des restrictions :
Certains clients SMTP ne s'attendent pas à avoir une réponse négative en cours de session SMTP. Lorsque la réponse négative n'est envoyée qu'à la réponse RCPT TO, le client se déconnecte au lieu d'attendre jusqu'à la limite (timeout), ou pire d'entrer dans une boucle sans fin connexion-rejet-connexion.
Postfix peut logger des informations plus utiles. Par exemple, lorsque Postfix rejete un nom de client ou une adresse mais attent la commande RCPT TO, il peut enregistrer les adresses d'expéditeur et de destination au lieu de ne logger que le nom de machine du client et l'adresse IP et ne pas savoir quel courrier a été bloqué.
Mixing is needed for complex whitelisting policies. For example, in order to reject local sender addresses in mail from non-local clients, you need to be able to mix restrictions on client information with restrictions on sender information in the same restriction list. Without this ability, many per-user access restrictions would be impossible to express.
A ce niveau le lecteur peut se demander pourquoi nous avons besoin des restrictions sur le client, HELO ou l'adresse de l'expéditeur quand leur évaluation est remise à la commande RCPT TO or ETRN. Certaines personnes recommandent de placer TOUTES les restrictions d'accès dans la liste smtpd_recipient_restrictions. Malheureusement, celà peut entraîner un accès trop permissif. Comment est-ce possible ?
Le but de la fonctionnalité smtpd_recipient_restrictions est de contrôler comment Postfix répond ) la commande RCPT TO. Si la restriction repond REJECT ou DEFER, l'adresse du destinataire est rejetée; pas de surprise ici. Si le résultat est PERMIT, alors l'adresse de destination est acceptée, et c'est là qu'apparaissent les surprises.
Ci-dessous un exemple montrant qu'un résultat PERMIT peut entraîner un accès trop permissif :
1 /etc/postfix/main.cf: 2 smtpd_recipient_restrictions = 3 permit_mynetworks 4 check_helo_access hash:/etc/postfix/helo_access 5 reject_unknown_helo_hostname 6 reject_unauth_destination 7 8 /etc/postfix/helo_access: 9 localhost.localdomain PERMIT
La ligne 5 rejete le message des machines qui n'indiquent pas un nom correct dans la commande HELO (avec Postfix < 2.3, utilisez reject_unknown_hostname). Les lignes 4 et 9 font exception des machines s'annonçant "HELO localhost.localdomain".
Le problème de cette configuration est que le résultat de smtpd_recipient_restrictions est PERMIT pour toutes les machines s'annonçant comme "localhost.localdomain", faisant de Postfix un superbe relais pour de telles machines.
Pour éviter de telles surprises avec smtpd_recipient_restrictions, vous devez placer les restrictions ne concernant pas le destinataire APRÈS la restriction reject_unauth_destination, pas avant. Dans l'exemple ci-dessus, la restriction basée sur HELO devrait être placée APRÈS reject_unauth_destination, ou mieux, les restrictions sur HELO devraient être placées dans le paramètre smtpd_helo_restrictions où elles ne peuvent faire aucun mal.
Postfix possède différents dispositifs de test des règles d'accès :
C'est un filet de sécurité qui change les actions REJECT du serveur SMTP en actions DEFER (essayez plus tard). Ceci garde le message en file d'attente au lieu de le retourner à l'expéditeur. Indiquez "soft_bounce = yes" dans le fichier main.cf pour prévenir les rejets permanents en changeant tous les codes SMTP 5xx en 4xx.
Il s'agit d'une mécanisme de protection différent qui change les actions REJECT du serveur SMTP en avertissements. Indiquez "warn_if_reject" dans une liste de restrictions d'accès avant la restriction que vous voulez tester sans rejeter les messages.
Avec cette foctionnalité Postfix 2.1, des clients SMTP autorisés peuvent passer pour d'autres systèmes, ainsi vous pouvez effectuer de réels tests. Des exemples de simulation d'autres systèmes pour des règles d'accès sont présentées à la fin de la page XCLIENT_README.
traduction par Xavier Guimard - Retour au menu