«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 en-crypté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-dit message. 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 une 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.3.1 <<>> nic.fr MX ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1648 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 3 ;; QUESTION SECTION: ;nic.fr. IN MX ;; ANSWER SECTION: nic.fr. 172800 IN MX 50 mx1.nic.fr. nic.fr. 172800 IN MX 100 mx2.nic.fr.
Passons 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|| \------ / \------ / ======/ ======/
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. |
Le rôle du Mail Tranfer Agent est de transférer le courrier sur l'Internet vers le Mail Tranfer 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 chassis 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. On observe trop souvent des comportements irresponsables d'administrateurs, qui sous prétexte que leur installation n'a pas été infectée, n'appliquent aucun traitement sur les courriers qui transitent par leur service alors qu'ils ne leur sont pas destinés.
Les fonctions de sécurité sont identiques à celles mises en oeuvre 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.
Relativement au MTA(1), le Mail Tranfer 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 30% des courriers présentés au Mail Tranfer Agent. De plus, le début d'année 2004 a 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 de nouveaux vers.
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 oeuvre au niveau Mail Tranfer Agent.
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 sont totalement inutiles croît à une vitesse exponentielle. 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 Tranfer 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 Tranfer 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 (FIXME: Voir liste amavis). 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. Donner une représentation exhaustive de toutes les relations possibles serait illisible.
Les en-têtes de courrier servent de plus en plus à
(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 :
X-Spam-Status: Yes, hits=33.2 tag1=3.0 tag2=8.0 kill=8.0 tests=CLICK_BELOW_CAPS, FORGED_YAHOO_RCVD, HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNKNOWN, HTML_FONT_BIG, HTML_MESSAGE, HTML_SHOUTING4, MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI, OBFUSCATING_COMMENT, RAZOR2_CF_RANGE_51_100, RAZOR2_CHECK, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DSBL, RCVD_IN_DYNABLOCK, RCVD_IN_NJABL, RCVD_IN_NJABL_PROXY, RCVD_IN_OPM, RCVD_IN_OPM_HTTP, RCVD_IN_OPM_HTTP_POST, RCVD_IN_SBL, RCVD_IN_SORBS, RCVD_IN_SORBS_HTTP, REMOVE_PAGE, UPPERCASE_25_50 X-Spam-Level: *********************************
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 50% du courrier sur 2 adresses (FIXME: voir échantillon amavis-stats).
Dans ces conditions, la mise en place de cette configuration lourde à titre domestique se justifie pleinement.
En considérant les 2 propositions d'architecture ci-dessus, voici un tableau récapitulatif des règles de filtrage à appliquer sur le(s) pare-feu(x).
Tableau 1. Filtrage réseau
| Source | Destination | Type | Port | Description |
|---|---|---|---|---|
| Internet | Passerelle | TCP | 22 | Accès SSH vers la passerelle |
| Internet | Passerelle | TCP | 25 | Courriers entrant vers la passerelle |
| Passerelle | MTA interne et Internet | TCP | 25 | Courriers sortant de la passerelle |
| MTA interne | Passerelle | TCP | 25 | Courriers sortant du MTA interne |
| Passerelle | Internet | TCP | 80 | Téléchargement de fichiers Web |
| Passerelle | Internet | TCP | 2703 | Accès aux serveurs Razor |
| Passerelle | Internet | ICMP | 8 | Accès ICMP aux serveurs Razor |
![[Linux France logo]](./../../images/lf-petit.png)
Vous êtes ici :