«La sécurité est un processus et non un produit. Et comme dans tout processus, certaines de ces composantes sont plus solides, plus fiables, mieux huilées et plus sûres que d'autres. De plus, ces composantes doivent s'emboîter les unes dans les autres. Mieux elles s'emboîtent, mieux le processus fonctionne. Souvent, ce sont les interfaces entre les composantes qui sont les éléments les moins sûrs.»
L'humain est-il la composante la plus faible du processus de sécurisation du courrier électronique ?. Répondre oui à cette question c'est choisir un alibi facile. L'ingénierie sociale (ou «esbroufe» dans un français plus académique), montre simplement les limites de la technologie. Il n'existe pas (encore ?) de système technique capable de détecter toutes les formes d'usurpation d'identité.
-
Ouvrir la pièce jointe chiffrée (contenant le virus !) dont la clé de déchiffrement est fournie dans le corps du message est un piège facile à éviter tant que l'on est pas «sensible» au contenu du message en question. Seule l'interprétation humaine provoquera le déclenchement du code viral.
-
Compléter un formulaire demandant toutes les coordonnées bancaires (n° de carte de crédit, etc.) transmis par courrier est un piège facile à éviter tant que l'on «détecte une différence» entre le message et le formulaire Web que l'on a l'habitude de saisir pour consulter l'état de son compte en banque. Là encore, tout n'est qu'une question d'interprétation qui échappe totalement aux technologies de sécurité.
Face aux évolutions constantes des méthodes d'usurpation d'identité, seule une information constante et complète des utilisateurs sur le «bon usage» du service de courrier électronique est efficace. Cette sensibilisation sur les usages, aussi nécessaire soit-elle, est parfois difficile. Essayez de convaincre la totalité des utilisateurs d'un service de ne plus composer leurs courriers en HTML !. Gros challenge en perspective ;).
Même si la technologie n'est pas une arme absolue, ses capacités de traitements automatisés sur des volumes de messages importants rendent de grands services.
L'objet de ce document est justement de présenter un service interface entre les fonctions classiques de filtrage de contenus de courrier électronique.
L'acheminement du courrier passe par des (étapes|points) bien particuliers. Tout commence par le service de noms de domaines (DNS) qui désigne les adresses IP responsables du traitement du courrier électronique d'une zone donnée. Les hôtes responsables de ces traitements (Mail Transfer Agent) sont repérés par le champ Mail eXchanger (MX) dans le fichier de zone DNS.
Voici un exemple simple permettant d'obtenir la liste des hôtes
responsables du courrier électronique pour la zone nic.fr. :
$ dig nic.fr MX
; <<>> DiG 9.7.3 <<>> nic.fr MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39798
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;nic.fr. IN MX
;; ANSWER SECTION:
nic.fr. 156070 IN MX 30 mx3.nic.fr.
nic.fr. 156070 IN MX 10 mx1.nic.fr.
nic.fr. 156070 IN MX 20 mx2.nic.fr.
;; Query time: 56 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 29 16:39:07 2011
;; MSG SIZE rcvd: 84Passons maintenant au courrier électronique proprement dit et son acheminement entre zones de l'Internet.
__ MTA(2) MDA(3) MTA(1) ___/ \_ .__. .__. .__. _/ \__ | | stockage | | _____ | | / \ | =| courrier | =| |=_=_=// _| =|__| Internet |__| -| _ _ _ | -|__/ | / | -| \_ __/ | |__(_)(_)(_)__| | | | | | \__ __/ ------ (_)(_)(_) ------ | |------ \___/ _______/ | / |.....MUA(0) |.....MUA(4) .------,~ .------,~ | PC |' | PC |' |Client|| |Client|| \------ / \------ / ======/ ======/
- MUA(0), Mail User Agent, Émission du courrier
-
L'utilisateur émet un courrier à l'aide d'une application appelée Mail User Agent vers le MTA(1) de son fournisseur d'accès Internet. La seule précaution possible à ce niveau consiste à utiliser un antivirus «à jour». Concrètement, cette condition est rarement respectée sur les postes domestiques. Pire encore, la vitesse de propagation des vers est maintenant supérieure à la fréquence des mises à jour de signatures de virus. Le niveau de sécurité d'un poste émettant du courrier est donc nécessairement faible.
![[Avertissement]](/images/warning.png)
Avertissement Il est possible, via une configuration particulière, d'émettre directement du courrier vers n'importe quel MTA sur l'Internet à partir du poste client.
Ce type de fonctionnement correspond presque systématiquement à une infection virale. C'est pour cette raison que dès que ces émissions sont détectées, l'adresse IP du poste est classée en liste noire. Il est donc vivement déconseillé d'émettre directement du courrier vers d'autres MTA que celui de son fournisseur d'accès.
- MTA(1), Mail Transfer Agent (-TX), Transfert du courrier en émission
-
Le rôle du Mail Transfer Agent est de transférer le courrier sur l'Internet vers le Mail Transfer Agent correspondant à l'adresse du destinataire.
La sécurisation des communications entre les MTAs est à la charge des opérateurs qui acheminent les données. Le rôle des fournisseurs d'accès dans la propagation des vers n'est pas neutre. Les clients sont facturés deux fois pour un service qui leur est dû. La surconsommation de bande passante due aux «pourriels» et aux vers est facturée à travers les forfaits et les fonctions antivirus et antispam sont facturées à travers des prestations supplémentaires. Si le problème était traité à la source, la surconsommation de bande passante serait sensiblement diminuée et la propagation des vers limitée.
Outre la logique commerciale de la démarche, l'argumentaire sur l'approche globale de la sécurisation s'applique parfaitement ici. Tant qu'un opérateur «respecte» la segmentation du marché qui lui impose d'affecter un groupe d'unités centrales à une fonction unique (antivirus, antispam, listes noires, etc.) sans (organiser|contrôler) les relations entre ces fonctions, il n'a d'autre choix que d'investir sans fin dans de nouveaux châssis dédiés. Cette course est asphyxiante aussi bien sur le plan financier que sur le plan des ressources humaines disponibles pour administrer le service.
Dans ce contexte, il faut réagir à son niveau et prendre un maximum de précautions lors de l'émission de courrier électronique depuis sa propre infrastructure.
Les fonctions de sécurité sont identiques à celles mises en œuvre au niveau d'un MTA(2) de réception du courrier électronique. Seules les relations entre ces fonctions diffèrent. C'est au service de réception d'assumer la protection des périmètres placés sous son contrôle.
- MTA(2), Mail Transfer Agent (-RX), Transfert du courrier en réception
-
Relativement au MTA(1), le Mail Transfer Agent de réception joue le rôle le plus important au niveau sécurité. C'est à ce point de passage que la charge de sécurisation est la plus critique. Il n'est pas rare de devoir «jeter» plus de 70% des courriers présentés au Mail Transfer Agent. Les évènements des années 2003 et 2004 ont montré combien il est important que les relations entre les fonctions de sécurité soient bien contrôlées. Cette maîtrise de la chaîne de sécurisation permet «d'encaisser» les chocs lors des propagations massives de nouveaux vers.
- MDA(3), Mail Delivery Agent, Délivrance du courrier
-
Le rôle du Mail Delivery Agent est de prélever le courrier dans les files d'attentes et de le déposer dans le répertoire de boîte aux lettres de l'utilisateur. Procmail est l'outil MDA le plus utilisé dans l'univers GNU/Linux. Il est possible de placer des fonctions de sécurité à ce niveau : appels antivirus (et|ou) antispam. Ce type d'appel est très pénalisant en charge CPU et surtout en accès au système de fichiers sur la machine qui exécute le programme. Il est donc déconseillé de traiter de gros volumes de courrier de cette façon.
Malgré ce défaut très pénalisant, le Mail Delivery Agent est l'outil de personnalisation des fonctions de sécurité. Si l'utilisateur souhaite régler lui-même les paramètres de fonctionnement des outils de sécurité, c'est là que l'opération doit se faire. Ces réglages individuels ne sont pas incompatibles avec les fonctions mises en œuvre au niveau Mail Transfer Agent.
- MUA(4), Mail User Agent, Réception du courrier
-
Pour faire simple, si un courrier infecté arrive à ce niveau : c'est foutu !. La population des administrateurs de parc informatique ayant constaté que les antivirus et antispam clients ont une efficacité plus que limitée ne cesse de croître. Si tous les ténors des solutions propriétaires cherchent encore à faire illusion, on (entend|lit) de plus en plus que la vitesse de propagation des vers et des pourriels est beaucoup trop rapide pour que ces solutions propriétaires soutiennent le rythme.
Dans la suite de ce document, nous allons nous concentrer sur les fonctions de sécurité appliquées aux Mail Transfer Agents assurant l'émission (-TX) et la réception (-RX) du courrier à la frontière du périmètre administré. Comme indiqué ci-avant (MDA(3)), il est toujours possible d'affiner les paramètres d'utilisation des outils de sécurité. C'est le moyen de personnaliser au niveau utilisateur la chaîne de sécurité. Il faut rappeler que cette individualisation a un coût d'exécution important. Par exemple, les appels à spamassassin à travers procmail sont si longs à exécuter qu'ils gênent la consultation des courriers électroniques.
En considérant les points de passage obligatoires de l'acheminement du courrier électronique on retient que les Mail Transfer Agents situés à la frontière du réseau sont les outils critiques sur lesquels l'approche globale de sécurité du service de courrier électronique doit s'appliquer.
Pour appliquer cette approche globale on utilise un service dédié aux relations entre les fonctions de sécurité : amavisd-new.
courrier issu du
MTA précédent
|
V +------+
+--------+ .--| .zip |
| | /| +------+-+
| MTA-RX | / | .--| .rar |
| | +-------------+ / | +------+-+
+--------+ | |-' , .--| .arj |
| | antivirus 1 | / +------+
| .--| |-+ / +---------------+
V / +-------------+ |' | |
+--------+ / | antivirus 2 | | liste noire 1 |
| |--' .-----| | .--| |--+
| amavis |---' +-------------+ / +---------------+ |
| |--. +------------+ / | liste noire 2 |
+--------+ \ | |----' .----| |
| \ | antispam 1 |-------' +---------------+
| `--| |---. +----------------+
V +------------+ \ | |
+--------+ `--| règles propres |
| | | |
| MTA-TX | +----------------+
| |
+--------+
|
V
courrier pour le
MTA suivant
Dans l'exemple ci-dessus, on a représenté 3 fonctions de sécurité à titre indicatif : 2 antivirus et 1 antispam. Il existe de très nombreuses combinaisons possibles. Chaque fonction de sécurité peut elle même faire appel à plusieurs autres services : bases de données de signatures de virus, bases de données de listes noires, algorithmes de calcul de notes, algorithmes de (dé)compression, etc. Une représentation exhaustive de toutes les relations possibles serait illisible.
Les en-têtes de courrier servent à (véhiculer|échanger) des
paramètres entre les services exécutés par les différents
Mail Transfer Agents. Ce sont ces
échanges de paramètres (X-Virus-*,
X-Spam-*, etc.) qui régissent les
relations entre MTA. Le service
amavisd-new
doit donc nécessairement prendre en compte ces champs d'en-têtes
pour prétendre à l'approche globale de sécurité.
Voici un «bel exemple» d'utilisation des champs d'en-tête indiquant le résultat d'un calcul de pondération antispam. Ici, le message a obtenu un score final de 46.551 alors que le seuil de classement en quarantaine est de 6.31. Aucun doute n'est permis sur la nature de ce courrier électronique. Il s'agit d'un pourriel.
X-Spam-Level: ********************************************** X-Spam-Status: Yes, score=46.551 tag=-999 tag2=6.31 kill=6.31 tests=[ADVANCE_FEE_2_NEW_FORM=0.001, ADVANCE_FEE_2_NEW_FRM_MNY=0.001, ADVANCE_FEE_2_NEW_MONEY=0.661, ADVANCE_FEE_3_NEW=0.835, ADVANCE_FEE_3_NEW_FORM=0.902, ADVANCE_FEE_3_NEW_FRM_MNY=2.969, ADVANCE_FEE_3_NEW_MONEY=0.001, BAYES_99=5.8, DATE_IN_PAST_96_XX=3.405, DEAR_BENEFICIARY=2.999, DKIM_SIGNED=0.1, FILL_THIS_FORM=0.001, FILL_THIS_FORM_LOAN=2.88, FILL_THIS_FORM_LONG=3.404, FORGED_MUA_OUTLOOK=1.927, FORM_FRAUD_3=0.001, FREEMAIL_FORGED_REPLYTO=2.095, FROM_MISSPACED=1.064, FROM_MISSP_DKIM=0.001, FROM_MISSP_MSFT=2.312, FROM_MISSP_REPLYTO=0.001, FROM_MISSP_TO_UNDISC=1.262, FROM_MISSP_URI=0.001, FROM_MISSP_USER=2.401, FSL_CTYPE_WIN1251=0.001, FSL_UA=0.782, FSL_XM_419=0.02, LOTS_OF_MONEY=0.001, MONEY_FRAUD_3=0.179, MONEY_FROM_MISSP=0.786, MSOE_MID_WRONG_CASE=2.584, NSL_RCVD_FROM_USER=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_PSBL=2.7, RCVD_IN_RP_RNBL=1.31, RCVD_IN_SBL=0.141, RCVD_IN_SORBS_WEB=0.77, RDNS_NONE=0.793, T_DKIM_INVALID=0.01] autolearn=spam
Voici une architecture réseau «simple» avec laquelle l'acheminement du courrier suit les processus suivants :
-
Le Mail Transfer Agent de réception de la passerelle est désigné comme service prioritaire dans la configuration du service de noms de domaines (champ MX du fichier de configuration de zone.
-
Les règles du Pare-feu sont rédigées de façon à ce que les courriers électroniques issus de l'Internet arrivent à la passerelle et nulle part ailleurs.
-
Le service amavisd-new appelle tous les traitements voulus et prend une décision sur chaque courrier : passage au MTA suivant, mise en quarantaine ou destruction.
-
Dans le cas ou le courrier doit passer au MTA suivant, les règles du Pare-feu sont rédigées de façon à ce que les courriers électroniques arrivent au MTA interne depuis la passerelle pour être délivrés dans les boîtes aux lettres des utilisateurs.
__ Pare-feu MTA + MDA internes
___/ \_ .__. .__.
_/ \__ |X |________________,| | _____
/ \ |X=| | =| |=_=_=//
| Internet |_,|X-|.__ | -|.____/ |
\_ __/ |X | \ | _ _ |
\__ __/ ------ |Passerelle --(_)(_) |
\___/ | .__. |_||_| |
| | | |
\_,| =| |.....
| -| .------,~
| | | PC |'
------ |Client||
MTA-RX MTA-TX \------ /
\amavisd-new/ ======/
Voici une architecture réseau «plus réaliste» qui intègre une redondance de la sécurisation du service ; on parle aujourd'hui de haute disponibilité. L'acheminement du courrier doit toujours disposer de 2 voies de communication distinctes de façon à tolérer une panne quelconque sur une ou plusieurs fonctions de sécurité. On utilise alors 2 passerelles placées sur des sites géographiques différents.
__ Pare-feu MTA + MDA internes
___/ \_ .__. .__.
_/ \__ |X |________________,| | _____
/ \ |X=| | =| |=_=_=//
| Internet |_,|X-|.__ | -|.____/ |
\_ __/ |X | \ | _ _ |
\__ __/ ------ |Passerelle --(_)(_) |
\___/ . | .__. |_||_| |
| VPN. | | | |
| . \_,| =| |.....
| . | -| .------,~
| . | | | PC |'
| . ------ |Client||
| Pare-feu MTA-RX MTA-TX \------ /
| .__. \amavisd-new/ ======/
| |X |
\___,|X=|
|X-|.__
|X | \
------ |Passerelle
| .__.
| | |
\_,| =|
| -|
| |
------
MTA-RX MTA-TX
\amavisd-new/
Le fonctionnement des passerelles est identique à celui décrit ci-dessus. Ce sont les champs MX du service de noms de domaines qui régissent les priorités entre les deux passerelles. Un réseau privé virtuel (VPN assure les communications entre les deux pare-feux.
Comment appliquer la stratégie de sécurité présentée lorsque l'on ne gère pas un domaine réseau en propre ? Il est tout à fait possible de «réintroduire» le courrier électronique déposé chez un fournisseur d'accès vers un Mail Transfer Agent. Voici un exemple d'architecture :
Fournisseur __
d'accès ___/ \_ modem .___.
.__. _/ \__ __ |== | _____
MTA | | / \ /\ |==| |. =| | |
+ | =|`---| Internet | \ / | | --| | |
MDA | -| \_ __/ \/ \_,| --| -------
| _ _ \__ __/ -------======/
--(_)(_) \___/ fetchmail
|_||_| MTA-RX MTA-TX
Boîte aux lettres \amavisd-new/
utilisateur
On utilise un outil particulier : fetchmail, dont la fonction de base est la collecte à distance et la retransmission du courrier électronique. L'outil fetchmail peut être utilisé comme passerelle POP ou IMAP pour un domaine DNS entier.
Cette architecture «domestique» peut paraître d'une complexité trop importante relativement à la charge utile de traitement du courrier électronique. Il faut cependant prendre en compte les arguments suivants :
-
La première approche de sécurisation consiste à faire appels aux fonctions antispam et antivirus à partir du Mail delivery Agent. Comme indiqué au point MDA(3), le coût d'exécution des fonctions de sécurité gêne considérablement l'utilisateur dans la consultation du courrier électronique. Cette gêne est d'autant plus importante qu'il n'existe pas de relations entre les fonctions de sécurité. Un même courrier doit passer par toutes les fonctions avant qu'une décision soit prise.
-
Il ne faut pas oublier que si les «pourriels» (et|ou) les virus arrivent jusqu'à l'interface réseau de votre poste, c'est que les opérateurs n'ont pas joué leur rôle. Il n'est pas rare aujourd'hui, de devoir rejeter plus de 80% du courrier arrivant sur l'interface externe d'une passerelle.
D'après les données ci-dessus, le total des messages bloqués est : 435675 + 31880 + 487 = 468042
Le total des messages reçus est : 541164
Le pourcentage de messages rejeté est : 468042 / 541164 * 100 = 86,5%
Dans ces conditions, la mise en place de cette configuration de traitement du courrier électronique, même à titre domestique, se justifie pleinement.