La gestion des configurations

L’évolution fulgurante des réseaux informatiques et Internet a fait accroitre la charge de travail des administrateurs réseaux, occasionnant ainsi un accroissement des ressources humaines consacrées à leur gestion. Les capacités de gestion de réseau ont été poussées à leurs limites et sont donc devenues plus complexes et source d’erreurs. Dans ce premier chapitre, nous allons présenter les incidents majeurs survenus récemment qui sont liés aux problèmes de configurations, ainsi que leurs enjeux au sein des entreprises.

ÉVÈNEMENTS DE L’ACTUALITÉ

Dans les dernières années, on a assisté à plusieurs incidents liés à des configurations incorrectes des équipements à cause d’une mauvaise vérification des configurations ou tout simplement à cause de la charge importante du travail des administrateurs (Deca et al., 2007).

L’INCIDENT AS 7007

Rappelons d’abord l’incident qui a paralysé le réseau Internet pendant une longue période, 20 minutes pour certains et 3 heures pour d’autres, en avril 1997 aux États-Unis.

D’après Vincent J. Bono, directeur du services réseau chez North American Network Operators Group, le problème a été attribué au routeur central estampillé AS 7007 de la société MAI Network Services en Virginie. Cette société hébergeait les routeurs et les backbones  devant interconnecter les différents réseaux pour la distribution d’Internet. Malheureusement une mauvaise configuration des routeurs a rendu incorrectes les tables de routage, entraînant rapidement une inondation des routeurs de la société MAI par le trafic réseau. De plus, l’annuaire InterNIC a inscrit par erreur le serveur Internet Exchange comme le propriétaire des tables de routage, c’est à dire qu’il devait diriger les paquets entrants vers leur destination. Ainsi, tous les paquets de l’ensemble du réseau Internet se sont dirigés vers ce seul serveur et, quelque 50 000 adresses sont venues congestionner le réseau, paralysant ainsi tout le réseau Internet des États-Unis et par ricochet ceux des autres réseaux dont il hébergeait aussi le backbone (Bono, 1997).

À la question de savoir pourquoi cette erreur n’a pas été détecté et corrigé, Vincent J. Bono explique qu’une autre erreur de configuration a empêché les routeurs de la société MAI Network Services qui pouvaient corriger le problème de détecter les données erronées. Les tables de routage étaient ainsi considérées comme non optimales, c’est-à-dire pouvant encore accepter une grande quantité de trafic – ce qui n’était malheureusement pas le cas-.

PIRATAGE DU COMPTE ADMINISTRATEUR

Un autre cas de problème de configuration s’est passé en 1992. Une alerte du CERT (Computer Emergency Response Team) avait été lancée suite aux informations indiquant un piratage systématique de mots de passe des clients d’une entreprise de services réseaux (Schaefer, 2003). Bien que les mots de passe soient la cause directe de la panne, l’incident avait débuté par le piratage du compte d’un administrateur réseau de cette entreprise suite à une mauvaise configuration de leur routeur au niveau du cryptage d’un protocole de sécurité. Ceci a permis au pirate d’installer un logiciel d’espionnage afin de s’approprier les comptes et les mots de passe de tous les clients de l’entreprise, qui iraient se connecter sur le réseau distant via leur réseau local. Cet incident malheureux a néanmoins permis d’améliorer le protocole d’identification par mots de passe avec des méthodes modernes de cryptographie (Schaefer, 2003).

PANNE DE GMAIL

Même les plus grands ne sont pas épargnés par les erreurs de configurations. Très récemment la très célèbre entreprise Google a vu sa messagerie Gmail tomber en panne pendant 40 minutes (Journal du Net, 2012). En effet, le service Sync de synchronisation chargé d’harmoniser le navigateur Chrome et certains autres services à partir d’un compte Google a mal fonctionné à cause d’un mauvais réglage d’un paramètre de la sandbox  affectant ainsi tout le système d’équilibrage des charges ou load balancing entrainant ainsi une indisponibilité de la messagerie Gmail, l’espace de stockage Drive, mais aussi le navigateur Chrome (Journal du Net, 2012).

PANNE CHEZ AMAZON

Contrairement aux autres pannes présentées ici, celle d’Amazon s’est étendue sur une période plus longue, soit quatre jours. Signalée le 21 avril 2011, cette panne avait été causée par une erreur de configuration entrainant une inaccessibilité partielle de leur plate-forme de service de cloud computing (Thibodeau, 2011; Pepitone, 2011).

Cette erreur de configuration a été faite lors de la mise à jour du réseau, laquelle produisit un routage incorrect des paquets. Amazon a expliqué qu’un trafic qui normalement aurait dû aller vers un réseau primaire a été acheminé vers une autre destination de capacité inférieure. Paralysant ainsi l’un de ses cinq sites mondiaux l’empêchant ainsi d’effectuer les opérations de lecture/écriture. Amazon a ainsi vu son pourcentage de disponibilité passer de 41% à 14,6% en seulement 48h (Thibodeau, 2011) (Pepitone, 2011). Suite à cet incident, plusieurs sites web de premier plan ont vu leur temps d’inaccessibilité croître ; c’est le cas de : Quora, Foursquare, Reddit et même du populaire client Twitter HootSuite (Pepitone, 2011).