Outils de monitoring des infrastructures
Profitant d’une légère accalmie sur le plan des projets en cours, vacances des collaborateurs oblige, je fais avancer certains dossiers moins prioritaires en cours. Parmi ceux-ci, le monitoring des équipements réseaux actifs et autres travaux liés à la supervision et au designe de nos infrastructures techniques internes.
Dans ce billet, je vous livre donc quelques infos sur les outils qui me tiennent à coeur… mais avant, une petite devinette !
Devinette : Quelle est l’organisation qui possède plus de 500 serveurs physiques répartis sur plusieurs datacenters dans le monde, avec des millions de requêtes web par minute 24h/24, des centaines d’utilisateurs connectés en simultanés, et qui met à disposition du public la totalité de ses schémas d’architecture, ses documentations d’exploitation des serveurs et routeurs, ses plans d’adressages IP, ses schémas et photos des datacenters, ses schémas d’implantation des racks, listes de patches des armoires de brassages, et bien plus encore ?!!! Ils publient également les statistiques et le monitoring détaillé de l’ensemble, serveurs, applications et routeurs, et comble de transparence documentent en temps réel les interventions des administrateurs et les travaux et anomalies…
En tant que RSSI, oseriez-vous publier toute votre infrastructure, statistiques temps réel, schémas et documentation d’exploitation ? Il faut être sacrément sûr de soi 
Réfléchissez un peu, je vous laisse trouver la réponse un peu plus bas !
en attendant, revenons à nos outils, justement.
Netdisco, un outil de suivi réseau excellent et gratuit
Tout d’abord je ne peux que vous recommander l’excellent produit OpenSource Netdisco. Il y a quelques mois, lorsque j’ai lancé le projet de « suivi dynamique réseaus internes », j’étais à la recherche d’outils performants et si possibles peu onéreux. Mon cahier des charges était simple : être capable de fournir à nos équipes techniques une vision exacte et dynamique de notre infrastructure réseaux, équipements actifs, tout en permettant le suivi des déplacements et changements survenant sur le réseau (connexion/déconnexion de machines, etc…).
Netdisco ne paye pas de mine, mais lorsque j’ai commencé à m’en servir le résultat a été largement supérieur à mes attentes, ce qui est rare en général !! En vrac, voici quelques unes des fonctionnalités que j’ai pu découvrir avec joie :
- autodécouvrir l’ensemble de l’architecture réseau, interconnexions etc, sous forme graphique et dynamique,
- avoir des informations sur le nombre de machines de tel ou tel modèle connectées (nombre d’imprimantes HP, ordinateur Apple etc…), et à quels endroits,
- lister les équipements de tel ou tel site,
- avoir la liste des éventuels points d’accès wifi « pirates » branchés à la sauvage,
- savoir si une personne a interconnecté un hub ou un petit switch entre son PC et la prise murale (l’outil me dit si il y a plusieurs mac-adresses sur un même port de nos switches, cela facilite le diagnostic),
- savoir si des personnes utilisent des machines virtuelles sur leur poste de travail (même principe basé sur le nombre de Mac-Adresses par port),
- découvrir les erreurs de topologie réseau, les soucis de DNS mal configurés, les soucis de PC mal paramétrés au niveau du domaine Netbios,
- avoir l’inventaire des domaines Netbios présents sur le réseau… Cela m’a permis de lister les PC « rapportés » de la maison ou d’ailleurs présents sur nos réseaux.
- avoir la liste des switches et routeurs, classés par modèle, version de firmware, etc…
- retrouver le numéro de port du switch sur lequel un équipement quelconque est connecté,
- rechercher une adresse IP, Mac, un nom Netbios ou DNS n’importe où sur le réseau et le localiser précisément,
- et bien d’autres choses…
Et tout ça gratuitement !
Et oui, Netdisco est publié sous licence GPL, donc libre. Ca tourne sous Linux bien évidemment, avec une base Postgresql. Le principe est grosso-modo basé sur une interrogation SNMP des équipements actifs du réseau (routeurs et switches), plus quelques ajouts pour scanner les plages IP…
C’est selon moi un *must* des outils gratuits de supervision, à l’instar des Nagios, Ntop et autres outils de monitoring et de diagnostic.
Nagios, c’est une interface web permettant de diagnostiquer et d’assurer le suivi des serveurs et équipements actifs. Par exemple le statut de chaque équipement peut être visualisé sous forme de graphiques MRTG et RRDTool (deux standards en la matière), mais également sous forme synthétique (vert ou rouge) et déclencher des alertes et alarmes par email ou SMS…
Ntop s’intéresse quant à lui au trafic réseau. Il permet également via une interface web d’afficher des statistiques assez précises de ce qui passe sur le réseau en termes de débit, flux, sources et destinations, et sait traiter les flux locaux (par exemple sur un serveur Linux faisant office de routeur) ou bien distants via des collecteurs NetFlow ou Rmon/Smon (des protocoles permettant l’envoi de statistiques plus ou moins détaillées d’équipements réseau)).
Devinette : La réponse !
Alors, vous avez trouvé ? Auriez-vous pensé qu’il s’agit de la Fondation Wikimedia, qui s’occupe (entre autres) de l’excellente Wikipédia… et oui, tant qu’à faire du « libre de droits », ils sont allés jusqu’au bout !
Depuis hier soir, je m’intéresse à l’architecture de Wikipedia, ou plus précisément de Wikimédia. Ne vous êtes vous jamais demandés comment Wikipédia fonctionnait ? Comme j’aime « ouvrir le capot » pour voir comment le moteur ronronne, j’ai un peu creusé, et suis tombé sur des informations passionnantes !
Une petite introduction s’impose : L’encyclopédie mondiale Wikimedia, c’est énorme mais cela ne représente qu’un seul projet de la fondation Wikimedia ! Pour gérer le tout, on imagine bien qu’il doit y avoir quelques (centaines de) serveurs répartis dans le monde, le tout fonctionnant sans accroc 24 heures sur 24. Ce qui est remarquable est que les concepteurs ont souhaité que tout cela soit transparent, c’est à dire que les informations concernant la gestion du tout est accessible au commun des mortels. Cela est probablement dû à plusieurs facteurs.
D’une part, comme il s’agit d’une association vivant de dons, ils ont souhaité que les donateurs puissent savoir exactement où leurs dons étaient utilisés…
D’autre part, comme de nombreux bénévoles contribuent à la Wikipédia, dans le monde entier et 24h/24, ces derniers (du moins ceux qui ont la charge d’administrer les systèmes) doivent pouvoir gérer au mieux et le plus simplement possible le tout, et dépanner rapidement. Leur laisser un accès aux documents d’exploitation et aux statistiques temps réel est donc non seulement appréciable mais indispensable.
Enfin, cela permet de continuer dans l’esprit « open source », en offrant au monde entier le savoir nécessaire à la mise en place et au maintien opérationnel d’une belle infrastructure en Cloud Computing !
Ca vous dit de jeter un coup d’oeil à tout cela ? Hop, c’est parti !
(et en plus c’est l’occasion de découvrir quelques outils de monitoring des infrastructures mentionnés ci-dessus).
La page principale WikiTech permet d’accéder à l’ensemble des documentations système, réseau et architecture, entre autres. On y trouve par exemple (en vrac) :
- Le plan d’adressage IP,
- la liste des serveurs et leurs rôles,
- les documentations d’exploitation, procédures et scripts pour la gestion des serveurs de messagerie,
- les plans de sauvegarde, et le statut serveur par serveur.
- le paramétrage et le design réseau au niveau BGP.
- Les plans d’installation des serveurs dans les racks des datacenters,
- les incidents et travaux en cours.
- la liste des actions effectuées par les administrateurs.
- etc.
Pas mal, mais ce n’est pas tout, il y a également la partie de monitoring temps-réel :
- Sur l’interface Ganglia, on voit l’activité agrégée de l’ensemble des nuages, en termes de puissance de calcul (plus de 1400 processeurs, et plus de 2 To de mémoire vive utilisés en permanence, et oui…), et on peut descendre dans le détail.
- L’interface Nagios mentionnée précedemment affiche le statut du tout, déclenche les alertes et historise les statistiques détaillées système par système, application par application.
- etc…
J’espère que tout cela vous a donné l’eau à la bouche, et surtout que cela vous incitera à contribuer à la grande aventure qu’est la Wikipedia ! Si vous avez du temps et des compétences, je suis certain que vous serez utile pour faire avancer le schmilblick !!
Bruno Kerouanton on juillet 31st 2009 in IT, IT Security
Une photo de...
Sebes responded on 03 août 2009 at 9:02 #
Tout cela est très intéressant.
Pour la supervision, je ne connaissais pas Netdisco
.
Certaines features ont l’air plutôt intéressantes :
- pouvoir détecter les « rogues » AP – le mieux en terme de sécurité étant bien sûr de ne pas mettre en place de WiFi en Entreprise, malheureusement cela n’est plus possible car les utilisateurs veulent pouvoir se connecter partout,
- savoir si une personne a interconnecté un hub ou un petit switch entre son PC et la prise murale –> très utile quand on gère un grand parc informatique car ce genre d’équipements utilisateurs est fréquent !
Pour le reste, on va dire que c’est classique venant d’un outil de supervision.
Bien sûr tu as parlé de Nagios qui reste la référence en matière de supervision open-source. C’est un outil très complet avec de nombreux développements réalisés par la communauté.
On peut aussi l’interfacer avec Cacti ce qui rend la solution de supervision plus complète.
Concernant le Wikitech j’ai trouvé ça très intéressant mais sacrément osé de la part de la Wikimedia Foundation d’exposer autant les informations de son SI. Les plans d’adressage, les distributions utilisées, les modèles de serveurs, etc… il ne faut pas avoir peur et être sûr de sa SSI derrière
S. responded on 03 août 2009 at 14:27 #
Moins prioritaire la supervision…mouais….pour ma part c’est un chantier toujours tres important et a monter au plus vite car des défaillances simples peuvent montrer des ttaques
Bruno Kerouanton responded on 09 août 2009 at 14:29 #
@S. : Je ne partage pas ton point de vue, du moins en pratique (en théorie, tu as raison). En effet, la supervision est et sera toujours très importante, mais complexe et lourde à mettre en oeuvre pour être utile. Lorsque l’on est affecté à un nouveau poste de RSSI, les priorités sont plus liées à – dans l’ordre : l’étude de l’existant, l’analyse des risques et besoins, la correction des infrastructures, la stabilisation de l’ensemble. Ensuite, seulement, on peut se consacrer à la supervision. Pour un RSSI, il est dangereux (pour sa carrière) de mettre d’abord de la supervision, car si il ne connaît pas l’existant et les risques il ne saura pas quels sont les points à surveiller. De même, si il consacre un budget considérable (la supervision, ça coûte toujours cher, surtout en temps humain, notamment pour le paramétrage et le monitoring) avant que les infrastructures ne soient à peu près stabilisées, il risque de devoir réclamer une « rallonge » budgétaire quelques mois plus tard car l’infrastructure aura changé et quel les points névralgiques ne seront plus les mêmes. Dans mon cas, la remise en condition de l’infrastructure est un chantier de plus de 4 ans… la supervision n’arrive que maintenant car les budgets ont d’abord été consacrés aux travaux les plus urgents, entre autres considérations.
Sebes responded on 10 août 2009 at 15:32 #
Bonjour Bruno,
je suis d’accord avec ton raisonnement même si je n’ai pas le même recul ni la même expérience que toi dans le domaine de la SI
Tu as raison quand tu dis que la supervision est très lourde à mettre en place. Elle demande effectivement beaucoup de temps et des ressources humaines, si bien sûr l’on souhaite mettre en place une supervision efficace.
Actuellement je suis encore étudiant en BAC + 5 et je réalise cette dernière année d’étude en Apprentissage. Je me suis vu confier la mise en place d’une solution de supervision logicielle au sein de mon Entreprise d’accueil qui est une moyenne structure (environ 35 serveurs, 20 équipements d’interconnexion « backbone »), plusieurs sites distants.
La solution choisie est What’s Up Gold d’Ipswitch. C’est une solution efficace mais qui est payante, et je trouve qu’un nagio n’a rien à lui envier ! Aussi, voici ce que j’ai pu retenir d’un tel projet :
- il est primordial de se fixer des objectifs en matière de supervision dès le lancement du projet et s’y tenir ! On a vite fait de dériver et de rajouter des éléments qui n’étaient pas prévus, et de ce fait le temps de réalisation s’en retrouve augmenté,
- il faut bien prendre en considération les projets parallèles qui peuvent modifier la structure du SI. Dans mon cas, on a eut conjointement un projet de virtualisation de nos serveurs, et du coup il a fallut rajouter certains équipements non prévus (comme une baie SAN). Ca peut rajouter de la complexité,
- avoir conscience que plus un SI est complexe, plus sa supervision la sera. Dans mon cas, comme je l’ai dit, c’est une structure modeste donc pas trop de problème de ce côté là :-p
- la supervision est une tâche de tous les jours, qu’il faut constamment maintenir à jour et qui évolue avec le SI. Je passe encore beaucoup de temps dessus, ne serait-ce que pour mettre à jour certaines données, certaines ressources monitorées, etc…
Alors je suis assez d’accord avec toi, la supervision ne constitue pas une priorité en terme de sécurité mais elle constitue un réel plus quand on a les moyens (temps et argent) de la mettre en place. Je pense notamment aux possibilités de mener des actions pro-actives et prédictives. N’y a-t-il rien de mieux que de solutionner le problème d’un utilisateur dont il n’avait pas conscience ??
Cordialement,
Sébastien
Bruno Kerouanton responded on 10 août 2009 at 15:49 #
Et oui, bienvenue dans le monde « réel » de la supervision ! J’ai le souvenir de plusieurs projets de supervision sécurité, avec ou sans IDS et IPS, et avec ou sans corrélation de journaux, qui ont littéralement été des échecs notoires, au sein de grandes entreprises…
Bilan des comptes pour chacun de ces projets, dans le désordre :
- il a fallu augmenter le budget « prestations », car il fallait faire revenir les experts et/ou racheter des licences à chaque fois qu’un changement de configuration sur l’infrastructure informatique avait lieu, c’est à dire presque quotidiennement.
- une fois le système de corrélation de journaux en place, l’on s’est rendus compte que le système aspirait quotidiennement des centaines de Mo de journaux, et que les temps de traitement et la capacité de stockage excédaient les capacités des systèmes. Résultats, pour continuer il fallait doubler les systèmes de corrélation… pour le début !
- un autre projet qui m’a été narré par un confrère chez un grand compte, a mené à la constitution d’une équipe de 5 spécialistes, et donc l’embauche puis la formation de ces personnes dont le rôle « se bornait » à suivre la supervision et les détecteurs d’intrusion… Le budget IT n’a pas vraiment été impacté, mais le budget RH l’a été fortement… très peu d’entreprises sont prêtes à consacrer des ressources humaines pour ce type de surveillance.
- un dernier projet basé sur un produit propriétaire (H. OpenV…) pour ne pas le nommer, a fait exploser le coûts, toujours pour les mêmes raisons…
… et la cerise sur le gâteau : trois de ces projets ont dû être abandonnés au bout de périodes allant de 6 mois à 2 ans, car ils devenaient trop coûteux ou inexploitables. Pas rassurant, même si je ne dis pas qu’il ne faut pas de supervision : disons plutôt que tout comme l’IAM, la PKI ou d’autres serpents de mer, il s’agit là de projets complexes et lourds que l’on ne doit pas implémenter à la légère, que des mois (voire des années) sont nécessaires pour que les études de déploiement soient menées sérieusement (je parle d’architectures de grandes entreprises, bien entendu), et que si l’on veut quelque chose de viable, il vaut mieux stabiliser l’infrastructure existante et mener son analyse de risques avant tout…
Pour toutes ces raisons, et d’autres, je suis encore réticent à mettre la supervision dans mes priorités tant que les ressources permettant de traiter les résultats ne sont pas présentes. D’ailleurs j’en avais fait état lors d’un précédent billet consacré à ma relation méfiante vis à vis des IDS, IPS et autres bestioles…
S. responded on 21 août 2009 at 9:49 #
Bruno,
Je pense que tout dépend de ce qu’on l’appelle supervision.
Pour ma part je pense que lors d’un départ d’un programme de management de sécurité (un SMSI pour reprendre des termes consacrés…), il est important que le RSSI aille juste demander aux gens de l’IT de lui faire parvenir les rapports sur la disponibilité des systèmes et des incidents.
Grace a cela il peut commencer a mettre en place la « supervision » sécurité.
PS: on se voit le 7/09 alors ?
kerkad ryma responded on 25 août 2009 at 18:39 #
comment cacti fonctionne et son déploiemement sur RHEL4?merci d’avence
Bruno Kerouanton responded on 05 sept 2009 at 2:56 #
Sans vouloir introduire une polémique, il est possible d’introduire la démarche que tu décris dans la mesure où les gens de l’IT ont la capacité de produire de tels rapports. Cela n’est pas toujours le cas… Mais dans l’absolu tu as raison, le RSSI devrait plus avoir un rôle de coordinateur et de manager que de technicien sécurité.
On se voit le 7/09, oui !
Bruno Kerouanton responded on 05 sept 2009 at 3:08 #
Bonjour,
Le plus simple pour apprendre Cacti est selon moi d’aller voir directement sur le site officiel du produit, car on y trouve la documentation, les captures d’écran pour se rendre compte de quoi il s’agit etc.
Techniquement, Cacti est un ensemble de scripts PHP qui affichent via une interface web des graphiques statistiques. Ces graphiques générés périodiquement par des scripts tournant en crontab (le scheduler Unix), lesquels vont interroger les différents équipements à surveiller en SNMP. Toutes ces informations sot également stockées et utilisées dans une base de données de type MySQL.
Pour l’installation sur RHEL, j’avoue ne pas avoir de pistes, vu que j’utilise principalement Debian (« apt-get install cacti » faisant le téléchargement puis l’installation de la version courante), mais il y a des chances qu’un « rpm -i cacti***.rpm » fasse le nécessaire. Le mieux encore est d’aller lire la doc sur le site officiel de Cacti. En général, et de toute manière même sous Debian, le plus efficace est de télécharger soi-même la dernière version des différents composants au format .tgz, et de les installer manuellement, ce qui permet d’avoir une version à jour.
Contrairement à Nagios (qui ressemble fortement à Cacti), la configuration des équipements à surveiller peut se faire directement via l’interface web, Nagios nécessitant d’aller taper des commandes assez longues pour ajouter chacun des équipements à superviser.
kerkad ryma responded on 05 sept 2009 at 19:06 #
bonsoir, merci pour votre attention.En fait,j’ai fais toutes les recherches sur cacti sous RHEL4, mais je ne sais pas encore sur quelle machine on l’installe pour monitorer est ce que sur le serveur ou bien sur d’autre machine?et si vous povez illustrez par un schema concret.merci et bonne journée
Bruno Kerouanton responded on 05 sept 2009 at 20:39 #
A ma connaissance (du moins c’est comme ça que je m’en sers depuis toujours), Cacti se met sur un serveur de supervision unique, qui va collecter les informations en provenance d’autres éléments actifs et/ou serveurs via SNMP ou d’autres moyens.
Mais il est peut-être également possible de s’en servir en mode déporté, un peu comme Ntop ou Snort… cela, je n’en sais franchement rien, n’ayant jamais eu la nécessité de creuser le sujet.
Hosni Skander responded on 29 oct 2009 at 9:19 #
Très intéressant