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.

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.

On se voit le 7/09, oui !

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 ?

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…

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