Office Servers and Services

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Sécurisation des flux Sortants : Mind the Gap (Partie1)

Posted by Teruin laurent sur avril 8, 2010


Si la disponibilité des services de messagerie Microsoft Exchange est actuellement complètement résolue par les techniques des groupes de disponibilité et de redondance des services et de données, la fiabilisation des flux en bordure de l’environnement reste encore un point parfois négligé dans la conception d’architecture de messagerie.

De plus en plus, la messagerie est considérée par les utilisateurs comme un moyen extrêmement fiable pour la communication extérieure. Or la signature électronique, et les techniques de sécurisation des messages ne sont pas encore totalement rentrées dans les mœurs. Si la conception d’environnement messagerie n’ayant pas de point de rupture unique est devenue une tendance forte, la réflexion sur la continuité du service de communication s’arrête bien souvent à la bordure Internet.

Paradoxalement, les utilisateurs ont depuis longtemps accordé leurs confiances à ce mode de transmission sans ce soucier des problèmes de sécurisation et d’identification que cela supposais. Peu conscient des risques, la plupart n’hésite pas à communiquer sans précaution particulière des données confidentielles par messageries interposées. D’un autre coté, les équipes techniques considèrent que l’envoi de message en sortie de leurs infrastructures ne relèvent plus de leurs compétences et négligent généralement certains dispositifs de sécurisation qui pourtant sont totalement gratuits et dont la mise en place n’engendrent aucun impact coté utilisateur. Il est bien évident que la sécurisation totale des échanges d’une entreprise vers le reste du monde reste pour l’instant illusoire, malgré tout un effort devrait être porté sur la fiabilisation des flux smtp surtout si il s’agit d’action totalement transparente pour l’utilisateur.

Une des premières questions à se poser, concerne la disponibilité des services de réception et d’envoi des flux de messagerie. Ce sont typiquement dans l’environnement Microsoft Exchange, les services EDGE que l’on trouvera généralement au sein d’une DMZ. Dans certains cas de figure, les services Edge sont utilisés en réception par une publication bien souvent unique d’un seul enregistrement MailXExchanger. Or un des points faibles provient de cette unicité de référencement. L’usage d’un seul MX peut en effet poser problème notamment si ce dernier est identifié comme potentiellement dangereux par les services de « blacklistage » de plus en plus usités sur l’Internet. Ce blacklistage est par ailleurs souvent engendré par des erreurs de configuration autorisant soit le relai ouvert ou partiellement ouvert ou bien la non adéquation du nom externe des passerelles SMTP avec leurs adresses IP natées par les équipements de sécurité. Il est en effet indispensable que l’adresse IP natée utilisée par la passerelle SMTP de sortie corresponde en tout point à l’enregistrement MX publié sur internet. Dans le cas contraire, certaines passerelles effectuant des opérations de recherches inversées refuseront le message via un simple déni de connexion. L’on notera sur ce point que l’effort de conformité doit être particulièrement porté sur la configuration des éléments sortants plutôt que sur les dispositifs de réception, qui en règle générale ne posent que peu de problème.

D’un point de vue pratique, je pense par expérience que l’utilisation de plusieurs MX à un réel intérêt. Le premier consiste à utiliser nativement une technologie de tolérance de panne totalement gratuite et partagée par la quasi-totalité des passerelles SMTP, j’ai nommé les MX. L’intérêt de cette dernière est donc, plutôt que de masquer plusieurs dispositifs d’envoi vers Internet à travers un « nattage unique », de bénéficier de la publication de deux environnements sortants et identifiés comme tel. Je conseillerais par ailleurs un usage sortant, basé sur une mode de fonctionnement de type « tolérance de panne », de façon à ce qu’une seule passerelle émette en même temps. L’intérêt de cette solution est de permettre à l’entreprise en cas de « blacklistage » de pouvoir utiliser la seconde passerelle déclarée sur une deuxième adresse Ip Externe et un deuxième enregistrement MX. De la sorte vous contribuerez à rendre toujours disponible votre environnement et disposerez de temps afin de régler votre problème de référencement incorrect auprès des services de type mailabuse etc..

La figure suivante illustre un environnement possible


 

Dans ce cas de figure les deux passerelles externes seront connues séparément avec leurs deux identités. Pensez à modifier également l’invite des passerelles Smtp pour qu’elle reflète les noms externes. Edgex.unifiedit.com. Vérifier également que le Nat en sortie est correct. Pour ce faire, envoyer un message en interne vers une boite aux lettres Externe et éditer les entêtes de message via Outlook depuis votre boite aux lettres de réception.


Vous devriez apercevoir l’adresse IP avec laquelle votre passerelle se présente. Voir l’exemple ci-dessous :

Received: from smtp1.unifiedit.com (94.2.0.20) by
smtp.itpro.fr (10.64.3.234) with Microsoft SMTP Server (TLS) id
8.1.375.2; Fri, 26 Feb 2010 14:46:52 +0100

Dans le cas contraire, le blacklistage risque d’apparaitre après quelques jours, et certains messages de votre organisation n’arriveront pas à certaine destination. Notamment celles qui possèdent des passerelles SMTP qui effectuent des opérations de vérification basées sur des recherches inverses.

Meilleur encore est l’utilisation des enregistrements Sender Policy Framework au sein de vos DNS qui vont décrire de façon explicite au reste du monde l’organisation de vos flux smtp externes. La mise en place de ces enregistrements déclaratifs va renforcer la confiance des passerelles SMTP de destination et faciliter votre indentification et diminuer votre « SPAM Score » réduisant de facto le risque de mauvaise classification de vos envois. Si vous n’êtes pas familier avec cette technologie, je vous conseille le site élaboré par Microsoft qui vous aidera dans la rédaction de vos enregistrements Dns de type SPF.

http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

L’extrait suivant montre l’effet d’une déclaration SPF réussie et approuvée par la passerelle de destination

Received: from dtactr-eexs-01.hotmail.com (92.168.100.10) by
btz-exs-02.hotmail.com (10.64.3.234) with Microsoft SMTP Server (TLS) id
8.1.375.2; Thu, 8 Apr 2010 13:57:35 +0200
Received: from smtp1.unifiedit.com (94.2.0.20) by mail.hotmail.com
(92.168.100.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 8 Apr
2010 13:57:44 +0200
From: Teruin Laurent laurent.teruin@unifiedit.com
To: TERUIN Laurent laurentt@hotmail.com
Date: Thu, 8 Apr 2010 13:57:27 +0200
Subject: RE: Prochaine date d’intervention unifiedit
Thread-Topic: Prochaine date d’intervention unifiedit
Thread-Index: AcrW+VWGOtIZN7AVQJakHmawNNYyEwAGUXWQ
Message-ID: 4499A138EB2B604C862C32F36971A7C001330C85F997@EXCCLUS.unifiedit.local
References: 6ddd1745-074a-4283-849a-e01ef75dbb86@casmac2K01.unifiedit.local
In-Reply-To: 6ddd1745-074a-4283-849a-e01ef75dbb86@casmac2K01.unifiedit.local
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR, en-US
Content-Type: multipart/alternative;
boundary= »_000_4499A138EB2B604C862C32F36971A7C001330C85F997EXCCLUSbour_ »
MIME-Version: 1.0
Return-Path: laurent.teruin@unifiedit.com
X-MS-Exchange-Organization-PRD: unifiedit.com
Received-SPF: Pass (dtactr-eexs-01.hotmail.com: domain of laurent.teruin@unifiedit.com designates 94.2.0.20 as permitted sender) receiver=dtactr-eexs-01.hotmail.com; client-ip=94.2.0.20; helo=smtp1.unifiedit.com;
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-Antispam-Report: DV:3.3.8805.535;SV:3.3.8702.1003;SID:SenderIDStatus Pass;OrigIP:94.2.0.20
X-MS-Exchange-Organization-SCL: 0
X-MS-Exchange-Organization-SenderIdResult: PASS

Dans le cas contraire voici ce que vous devriez constatez.

Received-SPF: None (mail1.itpro.fr: Laurent.TERUIN@unifiedit.com does not designate permitted sender hosts)
X-MS-Exchange-Organization-SenderIdResult: NONE

Dans le prochain article nous parlons des signatures de domaine à insérer dans vos flux sortants et les quelques outils qui pourront vous servir pour diagnostiquer la facon dont sont percus sur internet vos passerelles smtp.

Bonne soirée
Laurent Teruin

 

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

 
%d blogueurs aiment cette page :