Divorce smtp entre Orange et Microsoft : clouderies et filtrages

Actualités - Administration - Posté on 01 Août 2014 at 9:38 par Solange Belkhayat-Fuchs

ŠiškoL’accident est survenu, pense-t-on, dans la nuit du vendredi 25 au samedi 26 juillet : les usagers des services professionnels Office 365 de Microsoft n’ont plus pu expédier le moindre courrier électronique aux abonnés des services grand-public Wanadoo.fr et Orange.fr. Panne d’autant plus étrange que les administrés du réseau interne d’Orange (regroupés dans le domaine Orange.com) recevaient bel et bien leurs emails.
S’engage alors une série de tests et de coups de téléphone du genre « je t’envoie un email, je te passe un coup de fil pour savoir si tu l’as reçu ? » digne d’un sketch de Michèle Laroque. Par mesure de prudence, quelques abonnés d’Office 365 réexpédient leurs messages avec un service tiers (Gmail ou autre)… messages que reçoivent alors leurs correspondants. Lesquels correspondants répondent illico (et avec succès) en direction du service Microsoft. Midi n’a pas sonné, ce samedi-là, qu’il faut se rendre à l’évidence : un docte administrateur est parvenu à inventer l’équivalent routage de la diode à semi-conducteur. Les messages passent dans un sens mais pas dans l’autre.
Et les usagers de 365 d’inonder de SOS tout ce que leurs carnets d’adresses peuvent compter de noms de domaine différents, histoire d’en avoir le cœur net et pouvoir conclure à leur tour que seuls les serveurs de l’Opérateur Historique sont devenus soudainement sourds à leurs requêtes. Samedi soir, un diagnostic à chaud se dessine, le firewall fou a encore frappé.

 

Douches froides et lignes chaudes

Tablant sur la réputation de compétence et de sérieux quasi séculaire de leur hébergeur, quelques wanadiens et quelques orangiennes expédient alors à leurs services d’assistance client l’expression de leur désarroi le plus profond. « Que nenni » répondent alors les calorolinéains (ou thermogrammes, opérateurs desdites lignes chaudes). « Si votre correspondant ne peut vous expédier un i-maihle, c’est que leur logiciel est mal paramétré ou que leur serveur est brusquement devenu berseck. D’ailleurs, la preuve, je vais vous expédier un courriel, qui vous prouvera que vous n’êtes point sourd aux échange épistolaires et néanmoins numériques ».
Et tous les wanadiens, toutes les orangiennes ont pu lire la missive suivante :
> Bonjour,
> Ceci est un mail dédié à tester le bon fonctionnement de votre boîte mail. Si vous parvenez à lire ce mail correctement, cela signifie que votre boîte fonctionne normalement, et que vous pouvez recevoir des mails.
> Si vous avez encore des questions, n’hésitez pas à consulter la rubrique assistance ou à contacter votre service client.
> Merci de votre confiance,
> Votre service clients Orange

– Certes, cher et docte linéocalorifère, rétorquèrent quelques wanadiens possédant quelque vernis technique, mais votre domaine n’est pas un domaine Office 365 !
– Cela vous prouve que la faute est bien de leur côté…puisque ça tombe en marche chez nous »
Sic, fermez le ban.

Un week-end passe, arrive le lundi, et avec lui un certain regain d’activité du côté des messageries. Quelques milliers de lettres partent des serveurs Microsoftiens pour ne jamais arriver, et quelques centaines de retours préviennent les abonnés du service 365 que leurs écrits datés du samedi n’ont pu être délivrés malgré deux jours d’incessantes tentatives. Avertissement accompagné du message d’insultes suivant :

7/28/2014 9:48:44 AM – Remote Server at emea01-internal.map.protection.outlook.com (10.47.216.25) returned ‘550 4.4.7 QUEUE.Expired; message expired’
7/28/2014 9:44:45 AM – Remote Server at emea01-internal.map.protection.outlook.com (10.47.216.25) returned ‘450 4.7.0 Proxy session setup failed on Frontend with ‘451 4.4.0 Primary target IP address responded with: « 421 mwinf5c08 ME Trop de connexions, veuillez verifier votre configuration.

Peste ! En jargon Héssemtépéhien, c’est bien là la signature d’un refus signé par l’engeance de France Telecom. Quelques échantillons de ces courriers sont transmis aux services techniques dudit opérateur, lequel répond « C’est là chose fort normale, nous respectons les rfc, nous. Manifestement, vos Microsoftiens serveurs commettent une des deux erreurs suivantes : soit ils envoient un nombre de requête smtp trop élevé dans un laps de temps trop court, soit ils excèdent le nombre maximum de connexions simultanées, ce qui peut être interprété dans les deux cas comme une attaque en déni de service. Demandez à vos administrateurs de retourner à leurs chères études, qu’ils apprennent à configurer proprement leurs machines ». Chez Microsoft, on assure que l’on « travaille activement sur le sujet ».
Lundi passe. Mardi s’écoule. Mercredi s’achève. Les deux géants se renvoient la balle avec autant de hargne qu’un McEnroe opposé à Lendl durant une finale de Rolland Garos. Dans les forums d’utilisateurs, l’exaspération devient palpable. Avec la fin du mois, des factures doivent être transmises, des collaborateurs extérieurs sont injoignables, les e-commerçants (qui ne peuvent choisir le nom de domaine de leurs clients) sont dans l’incapacité d’expédier la plus petite confirmation de commande.

Ce n’est que dans le courant de la journée de jeudi, soit après 5 jours et demi de défaut de fonctionnement, que les services techniques de Wanadoo parviennent à rétablir la situation. L’origine la plus probable de la panne serait une règle de sécurité qui considèrerait comme fortement suspecte toute adresse IP présentant des requêtes émanant de plus de 30 noms de domaines différents. Ah, le bon temps où chaque machine était un host, chaque IP un serveur unique… mais ça, c’était avant, dans les années 80 environ. Depuis, Internet a un peu changé et personne n’a pris la précaution de prévenir la Rue Olivier de Serres. La mode de la collocation, de l’hébergement multiple, du Cloud… sans mentionner l’art de gérer plusieurs domaines et sous-domaines derrière un unique proxy, une caractéristique technique précisément « inventée » pour plaire aux opérateurs et prestataires de services.

 

Des lendemains qui déchantent

Cette mésaventure relativement bénigne soulève tout de même quelques questions.
– Pour quelle raison une règle de sécurité a-t-elle été modifiée probablement un vendredi soir, sans que n’aient été achevés les tests de non-régression habituels ? (rappelons qu’Orange commercialise les services Office365 dans le cadre de ses offres « pro », et ne pouvait oublier un tel détail)
– Comment peut-on expliquer qu’il ait fallu plus de 5 jours pour que le problème soit pris en considération par la direction technique de l’opérateur ?
– Est-il normal que la cellule technique d’un opérateur de services rejette « par défaut » la responsabilité d’un dysfonctionnement sur les épaules d’un autre opérateur, sans avoir préalablement analysé avec sérieux puis éliminé toutes les causes probables de la panne.

D’une manière plus générale, cette mésaventure montre à quel point les usagers des services Cloud sont vulnérables et à la merci des opérateurs de service… et de leurs sautes d’humeur. Si les politiques de « Best Effort » tant chantées sur les brochures commerciales, sont à l’image de cette expérience, les DSI qui ont cloudifié leurs ERP et autres outils de production et de gestion ne doivent plus se demander ce qu’il faudrait faire « si » leur opérateur venait à défaillir, mais de prévoir « quand » ledit opérateur déclarera forfait.

Autre conséquence de cette massification des services, ce « bug de messagerie » nous prouve à quel point les clients d’un service professionnel sont vulnérables par la seule défaillance d’un service totalement étranger à leur organisation ou à celle de leur sous-traitant. C’était certes déjà le cas auparavant, mais désormais, lorsqu’un accident survient, il prend rapidement des proportions dantesques. Un avion qui s’écrase fait plus de victimes qu’un accident de la route, un service Cloud qui déraille impacte plus d’entreprises qu’un défaut de configuration de serveur mail lié à une seule société. Cette amplification du phénomène ne semble pas encore comprise, ou prise en compte, par les grands opérateurs de service.
Se pose enfin la question de la responsabilité financière d’un tel défaut et des recours possibles lorsque la défaillance entraîne une perte d’argent. Dans un tel cas, ils sont inexistants, puisqu’aucun contrat ne lie Orange aux clients Microsoft. Passé le périmètre d’un opérateur de Cloud, tout peut arriver, rien n’est garanti. La sécurité d’une telle configuration ne peut être auditée, il est impensable d’espérer ainsi bâtir un plan de continuité de service.
Car l’accroissement du risque, ou plus exactement de l’accroissement des conséquences d’un accident d’origine extérieure réduit à un périmètre quasi autistique le champ d’action « fiable » d’une architecture du S.I. . Pourtant, le passage au Cloud était censé démultiplier (à moindre coût) l’efficacité et les capacités de communication et d’échanges des systèmes d’information.

De façon plus générale, cette panne Wanadoo est génétiquement liée à l’idée même de sécurité dans le Cloud. Plus un service a du succès, plus il provoque de tentations auprès des gardiens de Bot et autres grands diffuseurs de bootkits. Lesquels ont de plus en plus souvent recours à des mécanismes dynamiques de recherche de C&C (centres de contrôle).Lesquels C&C se cachent souvent derrière des centaines de noms de domaines générés également de manière dynamique. Face à un tel comportement, il est logique qu’un opérateur cherche à réduire sa surface de vulnérabilité et filtrer tout ce qui ressemble à un Bot ou à un prélude d’attaque en déni de service. C’est un combat sans fin, avec, parfois, des dommages collatéraux.

1 commentaire

Laisser une réponse