L’histoire de Pandora FMS
Une histoire de Sancho Lerena
PDG et fondateur de Pandora FMS
C’était en 2001. J’avais 25 ans et j’étais un fanatique de Linux.
Je travaillais chez AOL Espagne en tant que technicien de production dans le département des communications et de la sécurité, même si mon expérience était principalement avec les pare-feux Checkpoint, j’ai également beaucoup appris de la mise en réseau pure avec les équipements Cabletron et Cisco.
Mon travail à l’époque consistait à mettre en place et à gérer l’ensemble de l’environnement du réseau de production. C’était un DPC entier, avec des centaines d’équipements réseau Unix, Windows et haut de gamme. Malgré l’équipe d’exploitation utilisant HPOpenview, il était impossible d’avoir une photo ou une « carte » de tout.
Grâce à mon expérience dans la sécurité et les environnements Linux, j’ai fait un trou dans l’équipe pour ma capacité à explorer les réseaux, à entrer dans les systèmes et à cartographier ce qui s’y trouvait de manière logique.
À cette époque, j’ai découvert qu’il n’existait aucun outil décent pour superviser des environnements hétérogènes avec une topologie de réseau complexe.
A cette époque, j’ai géré plusieurs pilotes pour la mise en place d’outils de collecte et de centralisation d’événements (SEM, SIEM). J’ai beaucoup appris de cette expérience.
J’ai beaucoup utilisé MRTG et écrit des scripts avec RRDTool, avec lesquels j’ai peint des graphiques des principaux systèmes de communication (routeurs, équipements RAS haut de gamme, connectivité entre VPN, pare-feu, etc.), des choses qu’OVO n’avait pas fait ou ne voulait pas faire car il semblait très difficile d’apporter des modifications.
Puis j’ai commencé à travailler chez BBVA. Là, mon travail était plus lié au monde de la sécurité des systèmes et j’ai pris des contacts sérieux avec AIX et Solaris. Les outils de supervision en entreprise étaient tous ceux du Big4 : ils avaient tout, mais c’était un environnement très fragmenté.
La division des départements était orientée vers un binôme de systèmes ou de communications et chaque équipe de travail était orientée de manière différente, elles utilisaient donc des outils et des méthodologies différents.
Côté sécurité, je n’avais accès à aucun de ces outils non plus, donc pour surveiller mes systèmes (Firewalls, IDS, environnements Unix, environnements Windows, etc.) je n’avais pas d’autre choix que d’explorer de nouvelles voies.
Je suis devenu un spécialiste des techniques de perçage des pare-feu qui m’ont ensuite aidé à comprendre comment surmonter les problèmes des topologies de réseau complexes, en les appliquant à ce qui fait aujourd’hui partie de la conception de l’architecture Pandora FMS.
J’ai essayé d’implémenter Nagios, mais la faiblesse de leurs agents et la rigidité de leur conception de supervision ne me convenait pas. À cette époque, il était plus important pour nous d’obtenir des données de performance que de simples statuts.
J’avais besoin de graphiques puissants et de pouvoir agréger des données de différentes sources dans des rapports. Il était vital de relier les choses et de pouvoir les comparer, fixer des seuils et générer des alertes. Je devais également être capable de faire des tests complexes – car aucun environnement n’était standard – et de pouvoir collecter des informations à partir des systèmes. La grande majorité du temps, il n’y avait pas d’accès direct à la machine de supervision, j’ai donc dû installer des agents qui me contactaient «à l’aveugle» ou un autre système intermédiaire.
D’après mon expérience avec les outils de collecte d’événements et de journaux, j’avais vu tous les systèmes basés sur des agents tomber en panne en raison de leurs exigences rigides ; basé sur des machines Java récentes ou une distribution de packages binaires. Dans de nombreux environnements de production, il était impossible de mettre à jour les versions, d’installer des packages sur le système ou d’installer des éléments en tant que superutilisateur. Nagios n’était même pas proche de ce dont j’avait besoin.
Depuis lors, j’ai trouvé de nombreux systèmes avec des temps de fonctionnement de plusieurs années que personne ne voulait ou ne pouvait modifier.
Le père de Pandora FMS :
ARENA
Le premier concept logiciel qui intégrait nos besoins nous l’appelions « Arena » et c’était un environnement qui collectait des données envoyées par des agents précaires écrits en KSH.
Ces données n’étaient même pas standardisées, elles étaient envoyées en texte clair séparé par des pointillés «—-«. Le serveur était un développement en Perl réalisé par un collègue du département de sécurité logique (Juan H.) et le frontale en PHP que j’ai développé était mon premier code PHP.
Je connaissais un peu la programmation web grâce à mes précédents emplois, même si mon expérience était très limitée et avec des paradigmes très anciens (programmation CGI en C et HTML rudimentaire sur les serveurs Netscape). C’était aussi mon premier contact avec MySQL, puisque ma seule expérience dans les bases de données était Sybase.
La naissance de Pandora FMS
Les besoins augmentaient et l’architecture et le design ne correspondaient pas. En revanche, mon collègue Juan H. s’est désolidarisé du projet Arena et j’ai envisagé de le refaire de toutes pièces avec un autre design. C’est là que Pandora FMS est né, fin 2002.
C’était encore un hobby qui comblait mes heures mortes, qui à cette époque étaient nombreuses car je n’avais toujours pas d’enfants.
Avec l’aide d’un collègue (Sergio I.), nous avons créé le premier agent Windows, basé sur Windows Scripting Host et programmé en VBScript. Inutile de dire que ce n’était même pas l’ombre de ce qu’il serait des années plus tard, en fait cela posait beaucoup de problèmes. J’ai moi-même développé le serveur à partir de zéro, en utilisant Perl.
Je n’avais jamais fait de projet sérieux avec Perl, mon expérience se limitait à C et Turbo Pascal, où j’avais fait des choses plus importantes.
Cependant, j’ai réussi à développer de petits scripts en Pearl, très liés à l’audit des systèmes et aux outils de force brute, au balayage et à l’audit des réseaux. Une partie de ce code a ensuite été intégrée à Pandora sous le nom de Goliath, le moteur de transactions WEB synthétiques. Pourtant, mon expérience de Perl à cette époque était très limitée.
Petit à petit, et avec l’aide de quelques amis, nous avons créé quelque chose, avec une certaine documentation pour commencer, et j’ai montré le projet à des collègues et à des connaissances qui, grâce à leurs réactions et à leurs idées, lui donnaient forme. En interne, dans la banque, il a commencé à être un outil utile pour avoir une image précise de certains systèmes de sécurité, notamment les pare-feu Checkpoint et les environnements AIX.
Le projet initial s’appelait “Pandoramon”.
Il est important de préciser que le code des agents, de la console et du serveur est parti de zéro, je n’ai jamais rien emprunté à des projets comme Nagios. Certaines personnes ont douté de ce dernier point, et grâce au fait que tout le code est publié depuis la nuit des temps, vous pouvez parfaitement voir que l’architecture actuelle est l’héritière de ces premières versions du FMS Pandora..
Pandora FMS en tant qu’entreprise
En 2002, j’avais essayé de créer une société basée sur un logiciel que nous avions développé pour la télésurveillance Internet pour les gardes (BabyCam), et en 2004 une société de conseil en sécurité (Ip4All) mais aucun n’a abouti.
À la mi-2005, j’ai décidé de vivre professionnellement à partir de Pandora FMS, offrant des services d’audit de réseau, de développement personnalisé, d’installation de logiciels de sécurité, etc. À ce stade, le concept de « Version Entreprise » n’existe pas encore. Le modèle économique repose sur l’offre de services autour de deux produits de base : Pandora et Babel. Babel était un autre logiciel avec une philosophie similaire, orienté vers le renforcement des systèmes et la création de tableaux de bord de sécurité.
Avec David Villanueva –un ancien collègue de travail- , et moi avons décidé de créer Artica. J’ai quitté mon excellent travail de consultant spécialisé senior à la banque. À partir de ce moment, tout va de plus en plus vite, Ártica Soluciones Tecnológicas a été officiellement fondée en novembre 2005.
Les premiers démarrages sont durs, et Pandora reste une anecdote pour mes premiers clients. Je me consacre à observer leurs besoins et à apprendre des problèmes du monde réel dans différents environnements, toujours liés au monde de la sécurité.
L’une des premières choses que nous avons faites a été de renommer le projet en Pandora. Fin 2006, nous avons ajouté le slogan FMS car « Pandora » était trop générique.
Quelqu’un nous a donné de sages conseils : Free Monitoring System était un très mauvais moyen d’essayer de vendre (Free = Gratuit), donc pour le F, nous avons choisi la qualité principale de Pandora et étroitement liée au logo original (une pieuvre) : F pour Flexible.
Les premières années, Pandora FMS a eu un développement très lent, puisqu’il ne s’agissait pas d’un logiciel en tant que tel, mais d’un projet purement « Libre » qui servait à nous initier à des projets de conseil en sécurité. Nous avons développé ensemble Babel Enterprise et ce n’est qu’au début de l’année 2006 que le premier programmeur professionnel a rejoint l’équipe : Esteban Sánchez.
Il a commencé à travailler à plein temps dans Pandora FMS. Au cours des premières années, Esteban et moi étions les premiers programmeurs, jusqu’à ce que Ramon Novoa nous rejoigne en novembre 2007, avec Esteban, qui a commencé à faire de Pandora FMS un véritable produit logiciel. A cette époque, nous avons eu des collaborations de diverses personnes, l’une des plus importantes, Guruevi de New York et d’autres personnes d’Amérique du Sud, de Nouvelle-Zélande et du Japon.
Fait curieux, tous les projets de logiciels libres choisissent un animal, le nôtre était une pieuvre. Vous pouvez voir plus d’informations sur l’histoire du logo dans notre blog.
Pandora FMS aujourd’hui
Selon les données d’openhub.net en novembre 2015, Pandora FMS compte avec 11 000 commits effectués par plus de 50 personnes, avec un total de 413 000 lignes de code développées en PHP, Javascript, Perl, C ++, C, Shellscript et Java. Il y a environ un million de téléchargements enregistrés sur Sourceforge.
Il y a eu de nombreuses versions, correctifs et mises à jour qui, au cours des 12 dernières années, ont transformé ce qui était à l’origine un projet d’un simple technicien pour résoudre des problèmes techniques. Grâce à la collaboration de dizaines de programmeurs, de techniciens système, d’utilisateurs et de clients, Pandora FMS est aujourd’hui un outil professionnel de supervision et de gestion de grands environnements.
En tant que « Père » de la créature, je ne peux que dire : Merci à tous de nous avoir amenés ici !
Résumé des versions de Pandora FMS tout au long de son histoire
Null
Première version publique : Pandora v0.8.1 (août 2004)
Jusqu’en août 2004, nous n’avons pas publié notre première version publiquement, c’était la version 0.8. À cette époque, l’équipe de développement était composée de trois personnes : Moi, Sergio I. qui avait une partie de l’agent initial VBScript pour Windows et Raúl M. qui aidait avec différentes tâches, non liées au code.
À cette époque, le projet s’appelait « Pandoramon » sur Sourceforge (car Pandora était déjà pris).
La première version n’incorporait que des fonctionnalités liées aux agents (elle n’avait aucune supervision à distance d’aucune sorte) et son interface était pour le moins basique. Il n’a pas eu non plus d’événements. Les graphismes, cependant, étaient assez décents. Le modèle de données est peut-être le moins modifié de tout cela, puisqu’il n’y a aucune trace du code d’origine.
Ce n’est qu’à partir de la version 1.0 que nous avons commencé à utiliser CVS : un système de contrôle de version. Cela peut choquer, mais le fait est qu’aucun d’entre nous qui était lié au projet ne venait du monde du développement, mais des réseaux et des systèmes. Le fait est qu’à ce stade, le projet était totalement « Amateur ».
Pandora v1.0 (octobre 2004)
Dans cette version, « les choses devenaient sérieuses ». Cette version intègre un système ACL utilisateur.
Pandora v1.2 (décembre 2006)
Nous avons commencé à utiliser Subversion pour gérer le code. Première version de l’agent en C++, développé par Esteban S., l’agent que nous avions en VBScript est supprimé. La supervision et la réception à distance des traps SNMP sont intégrées.
Pandora v1.3 (novembre 2007)
Les rapports, les graphiques combinés, le serveur de reconnaissance et les rapports personnalisés sont intégrés. Modèles de modules et de machines, pour le serveur de reconnaissance. Il y a un changement visuel important, qui fait qu’on commence à le prendre « au sérieux ».
Pandora v2.x (2008-2009)
Nous créons le protocole Tentacle. Nous introduisons le serveur d’exportation. Tentacle (un protocole de transfert de fichiers propriétaire avec un port attribué par l’IANA, 41121/tcp) était un point crucial lorsqu’il s’agissait de faciliter la vie lors de l’installation d’agents.
Dans la version 2.x nous avons essayé de faire une version du serveur en C mais cela n’a pas fonctionné et nous continuons à travailler sur la version Perl. Vu en perspective, on peut dire que c’était une excellente décision. Le principal goulot d’étranglement du serveur est l’interaction SQL, pas les opérations internes.
Pandora v3.x (2010-2011)
Première version « Entreprise ». Il permet l’édition à distance des configurations des agents, des rapports PDF et d’autres fonctionnalités. Nous avons des clients surveillant des environnements d’environ 2 000 agents.
Pandora v5.x (2014-2015)
Nous passons le projet à GIT, de SVN. Nous présentons le serveur Satellite. Grâce au Satellite, on atteint dans certains environnements spécifiques un taux de 500 contrôles par seconde, un scandale et aussi de manière distribuée et sans connexion bidirectionnelle, ce que l’on appelle une supervision « headless ».
Pandora v6.x (2016)
Nous introduisons le Méta-répertoire des agents, le contrôle à distance intégré de bureau (avec Pandora RC), la gestion à distance des serveurs et des satellites, les améliorations des tableaux de bord, la supervision dynamique et les améliorations de la supervision prédictive.