Sécurisation des connexions à l’interface web

PRESENTATION DU PROJET 

Au cours de ces six mois de stage chez Thales Underwater Systems, sur le site de Sophia Antipolis, j’ai été chargé de mettre en place une solution permettant à l’équipe SAT de superviser, en temps réel, l’ensemble des serveurs atelier. Ces serveurs atelier sont des machines physiques et virtuelles, qui intègrent des outils comme MatLab, Eclipse ou encore Orchestra. Ces machines permettent de mettre à disposition des employés une suite logiciels et de la puissance de calcul.
Pour répondre aux besoins de l’équipe, j’ai tout d’abord commencé par étudier différentes solutions parmi les plus utilisées dans le domaine. Le cahier des charges imposé m’a permis d’en retenir trois. J’ai ensuite présenté à l’équipe les avantages et inconvénients de chacune de ces solutions. A l’issue de cette présentation, nous avons retenu la solution de supervision Check_MK, car elle répondait le mieux aux exigences imposées.
Par la suite, j’ai pu commencer à mettre en place un prototype de la solution en installant Check_MK sur un serveur Linux dédié et en testant le fonctionnement de l’outil. Cette étape m’a permis de me familiariser avec Check_MK. J’ai poursuivi la construction de mon prototype en développant des scripts et en configurant la solution selon le cahier des charges.
Pour finir, j’ai procédé à la validation de chaque exigence du cahier des charges et à la rédaction de la documentation technique de la solution. Enfin, j’ai déployé la solution sur tous les serveurs atelier du site et j’ai formé l’équipe à l’utilisation de Check_MK.

Cahier des charges

Pour définir les besoins de l’équipe en termes de supervision des serveurs, la première étape a été d’étudier le cahier des charges et d’éclaircir chacune des exigences. Le cahier des charges se présente sous la forme suivante :
La colonne « Titre Exigence » définit l’exigence. La colonne « Validation » me permettra d’indiquer les tests que j’effectuerai pour valider l’exigence. La colonne « Validateur » me permettra d’écrire le compte rendu du test effectué pour valider l’exigence.
Le cahier des charges complet comporte 31 exigences. Il a donc été nécessaire, au début du stage, de discuter de chacune des exigences avec les administrateurs. Cette étape a permis de correctement définir chaque exigence et de parfaitement comprendre les besoins des administrateurs.
Durant cette phase, nous avons retiré deux exigences car aucun outil de supervision ne permet d’y répondre.
Après avoir présenté, lors d’une réunion, la démarche que je suivrai pour valider chacune des exigences, j’ai pu commencer à étudier les différentes solutions parmi les plus utilisées dans le domaine de la supervision, afin de trouver celle qui répondra le mieux au cahier des charges.

Etude des solutions

Après de nombreuses recherches, j’ai pu sélectionner trois solutions de supervisions open source qui pourraient répondre aux besoins définis :
o Centreon
o Check_MK
o Zabbix
D’après mes recherches, c’est la solution Check_MK qui semble la plus appropriée. Néanmoins, j’ai préféré tester chacune des trois solutions.
Sur les sites dédiés à chacune des solutions, il est possible d’essayer l’outil grâce à une « live demo ». Ces « live demo » ne permettent pas de tester chacune des fonctionnalités, mais seulement d’avoir un aperçu de l’interface Web. L’interface Web est l’ensemble des pages, accessibles depuis un navigateur, qui vont permettre d’administrer l’outil et de présenter les informations récupérées sur chaque machine.
Comme je l’ai dit dans l’introduction, deux solutions de supervision avaient été mises en place par le passé. Leur complexité d’utilisation n’avait pas permis à l’équipe de maintenir à jour ces deux outils. Il me semblait donc indispensable de choisir l’outil le plus simple d’utilisation.
Après avoir testé chacune des « live demo », c’est Check_MK qui m’a paru la solution la plus appropriée. En effet, son interface Web présente un design beaucoup plus intuitif que Centreon ou Zabbix. Sa maintenance en est donc grandement facilitée.
Lors d’une réunion, j’ai ainsi présenté les avantages et inconvénients de chaque solution. J’ai également pu définir, grâce à mes recherches, de quelle manière chaque solution peut répondre à chaque exigence du cahier des charges. Pour simplifier la maintenance de la future solution, il fallait trouver l’outil permettant de répondre, nativement, au maximum d’exigences. La solution retenue a ainsi été Check_MK. J’ai alors commencé à me documenter sur la procédure d’installation de cet outil.
Durant toute la suite de mon stage, j’ai présenté l’avancement du projet, à l’équipe, lors de différentes réunions mais aussi en rédigeant un planning d’avancement hebdomadaire.
Check_MK collecte les informations sur les machines, mais utilise le coeur de Nagios pour les traiter. Cette solution intègre une interface Web beaucoup plus intuitive et des outils, comme PNP4Nagios et RRDTtool, qui permettent de réaliser des graphiques. Contrairement à Nagios, qui se configure à partir de fichiers texte, l’interface de Check_MK permet une configuration entièrement graphique.
Une dernière particularité de Check_MK est que cette solution intègre son propre agent, installé sur chaque machine à superviser, qui récupère toutes les informations d’une machine en une seule requête. La supervision est de ce fait plus performante et nécessite moins de ressources CPU et RAM pour le serveur qui héberge Check_MK. Il est ainsi possible d’utiliser un serveur virtuel plutôt qu’un serveur physique.

INSTALLATION DE CHECK_MK

Dans cette deuxième partie de mon stage, je pouvais commencer à mettre en place un prototype de la future solution de supervision.
Pour cela, je devais procéder à l’installation de Check_MK et de tous les éléments qui permettraient son fonctionnement. Il fallait ensuite que je me familiarise avec l’environnement Check_MK et que je paramètre le serveur.

Installation de Check_MK

Check_MK se trouve sous la forme d’un package, appelé OMD (Open Monitoring Distribution). La version que je vais installer est la « omd-1.20.rhel6.x86_64.rpm », sortie en fin d’année 2014.
Pour héberger Check_MK, j’ai à ma disposition un serveur virtuel, sous CentOS 6.6, qui dispose de 4 Go de RAM et d’un CPU deux coeurs.
Pour installer le package OMD, il me suffit de passer la commande « rpm –ivh omd-1.20.rhel6.x86_64.rpm ». Cependant, ce package a besoin d’autres paquets Linux « rmp » pour fonctionner. L’installation de ces dépendances se ferait de façon automatique en utilisant la commande « yum omd-1.20.rhel6.x86_64.rpm ». La commande « yum » se charge de récupérer les dépendances dans un dépôt, sur internet, et les installe. Cependant, la politique de sécurité du groupe Thales m’impose de télécharger et installer manuellement chaque dépendance.

Scripts locaux

Tout comme Nagios, pour récupérer des informations sur des machines, Check_MK utilise des plugins. Ces plugins sont des scripts, qui doivent se trouver sur chaque machine supervisée et qui sont exécutés en local, à intervalle de temps régulier. Check_MK se connecte ensuite sur la machine et récupère les résultats retournés par chaque plugin.
Par défaut, Check_MK propose près de 400 plugins génériques. Malheureusement, pour des applications particulières, si aucun plugin n’existe, il est nécessaire de développer ses propres plugins, appelés scripts locaux.
Ces scripts locaux, du fait qu’ils sont exécutés par la machine supervisée elle-même, peuvent être écrits dans n’importe quel langage exécutable par cette machine. Cependant, les données issues de ces scripts doivent respecter un certain format de sortie afin d’être compatibles avec Check_MK. Les arguments de sortie du script doivent ainsi se présenter sous la forme :
La variable « Status » indique, sur l’interface web, l’état de la ressource monitorée par le script. Si l’état est « Ok », « Status » vaut 0. Si l’état est « Warning », « Status » vaut 1. Enfin, si « Status » vaut 2, l’état de la ressource sera « Critical ». « Ok », « Warning » et « Critical » sont les trois niveaux d’alerte par ordre de criticité croissant.
Par exemple, si la charge CPU est inférieure à 90%, la ressource se trouve à l’état « Ok ». Il n’y a alors aucun problème.
Si la charge dépasse les 90%, l’état passe à « Warning ». Les administrateurs sont alors avertis d’un potentiel problème.
Enfin, si la charge dépasse les 95%, l’état devient « Critical ». Il faut intervenir tout de suite car le serveur est en surcharge anormale.
C’est donc la variable « Status » qui déclenche les alarmes sur l’interface Check_MK.
La variable « Script_Name » contient le nom du script qui sera affiché sur l’interface web.
La variable « Data » n’est pas obligatoire. Elle contient les données à afficher sur les graphiques. Ainsi, « Perfdata » contient la valeur mesurée à l’instant t par le script, « Warning_seuil » et « Critical_seuil » servent à tracer les seuils limites sur les graphiques.
Pour finir, la variable « Statustxt » contient le texte d’information qui sera affiché, sur l’interface web, en fonction de l’état de la ressource supervisée.

Développement de scripts locaux

Parmi toutes les exigences du cahier des charges, Check_MK ne peut pas, nativement, toutes les satisfaire. Ces exigences sont plus techniques et propres aux applications de Thales. Elles requièrent donc le développement de scripts locaux adaptés. J’ai développé au total une quinzaine de scripts permettant de récupérer des informations comme la vérification des mises à jour des antivirus Windows, l’état des sauvegardes des serveurs, la liste des applications installées sur chaque serveur, le nombre de licences utilisées pour certaines applications, etc…
Le développement des scripts a été une étape assez longue. J’ai en effet dû, pour chaque script, me documenter sur les différentes méthodes qui permettent de récupérer l’information souhaitée. J’ai ensuite testé plusieurs méthodes afin d’aboutir à un script performant, c’est-à-dire le plus léger possible en terme d’exécution et compatible avec toutes les versions de Linux (RedHat et CentOS), Solaris et Windows.
Les scripts que je vais devoir écrire nécessitent l’utilisation de commandes système. J’ai donc choisi de les développer en Shell sous Linux et en Bat sous Windows. De plus, ces langages restent assez simples de compréhension pour les administrateurs système. Il leur sera donc plus facile, dans l’avenir, de les maintenir à jour ou les modifier.
Pour exemple, voici un script qui permet de vérifier si l’antivirus d’une machine Windows est à jour :

Validation des exigences du cahier des charges

Tout au long de la phase de développement des scripts, je devais également, en parallèle, tester et valider chaque exigence du cahier des charges.
Il fallait ainsi que je valide la compatibilité de la solution de supervision pour chaque système d’exploitation présent dans le parc de serveurs. Dans ce parc, on compte quatre systèmes d’exploitation déclinés en dix-huit versions :
Il était donc indispensable, avant de déployer la solution, de vérifier que l’agent de supervision installé sur les machines était bien compatible. Pour cela, j’ai installé l’agent de supervision sur des machines de test, puis j’ai testé et vérifié une quinzaine de points pour chaque version. Il fallait vérifier, pour ces quinze points, que les informations collectées par l’agent de supervision étaient bien celles que l’on pouvait observer directement sur la machine.
Les informations à vérifier étaient par exemple la quantité de mémoire totale et utilisée, la charge processeur, les espaces disque, les montages réseau, les paramètres de l’interface réseau ou encore les informations remontées par chaque script local, etc…
Je devais ensuite renseigner, dans la colonne « Validateur » du cahier des charges, la procédure que j’avais suivie pour valider l’exigence. Voici, pour exemple, un aperçu de colonne « Validateur » pour les espaces disque :
Après avoir vérifié chaque exigence sur chaque système d’exploitation, j’ai pu constater quelques problèmes de compatibilité avec la version 3.3 de RedHat et Solaris 7. Sur ces machines, l’interface réseau n’est pas détectée et la quantité de mémoire vive collectée par le serveur de supervision est fausse. Néanmoins, ces OS étant assez anciens, les serveurs qui embarquent ces versions migreront bientôt vers une version plus récente de Linux. Il n’est donc pas indispensable de corriger ces problèmes de compatibilité.
Pour toutes les autres versions de Windows, Linux et Solaris, l’agent de supervision Check_MK est parfaitement compatible.
Mon prototype de la future solution de supervision était donc complet. J’ai ainsi pu le présenter à l’équipe lors d’une réunion et nous avons décidé de déployer l’outil.
Au terme de cette étape, j’ai travaillé sur le développement de scripts afin de répondre aux exigences que Check_MK ne peut pas satisfaire nativement. J’ai ainsi pu modeler Check_MK et son interface web aux besoins des administrateurs.
En parallèle, j’ai pu valider toutes les exigences du cahier des charges, pour tous les systèmes d’exploitation utilisés, hormis RedHat 3.3 et Solaris 7.
Après avoir présenté le prototype de la solution, l’équipe a décidé de mettre l’outil en production. Je pouvais ainsi passer à la dernière étape de mon stage : le déploiement de la solution.
Dans cette dernière partie de mon stage, la solution de supervision fonctionnait correctement sur les machines de test. Je devais maintenant automatiser l’installation et la configuration de l’agent afin de faciliter le déploiement sur les serveurs en production.
Pour finir, je devais procéder au déploiement de la solution.

Supervision d’une machine Linux

Sous Linux, l’agent Check_MK se compose de deux fichiers exécutables :
o Check_mk-agent-version.noarch.rpm
o Check_mk-agent-logwatch-version.noarch.rpm
Le premier fichier permet d’installer les plugins Check_MK. Ce sont ces plugins qui permettront de récupérer des informations génériques comme l’utilisation du CPU, de la mémoire vive, des disques durs, etc…
Le deuxième fichier permet de superviser les fichiers de logs afin de remonter des alertes au niveau du système ou des applications qui tournent sur le serveur.
Sous Linux, l’installation de l’agent se fait en ligne de commande. Etant donnée l’architecture de la solution de supervision, installer l’agent sur une machine Linux prend environ dix minutes et il est facile de faire des erreurs lors de la configuration.

Déploiement

La solution de supervision doit être déployée sur une cinquantaine de machines Linux, Solaris et Windows. Le parc de serveurs ne contient que quatre serveurs Solaris. Ceux-ci migreront bientôt sous Linux et Solaris sera abandonné. Je n’ai donc pas écrit de script d’installation pour cet OS. Cependant, pour les machines restantes, je vais pouvoir déployer la solution très rapidement.
Après avoir installé l’agent de supervision sur chaque serveur, via les scripts d’installation, il ne reste plus qu’à ajouter les nouvelles machines dans Check_MK. Pour cela, il faut aller sur l’interface web et créer ces nouvelles machines.
La solution de supervision est maintenant déployée sur toutes les machines. Près de 50 serveurs et 750 ressources sont vérifiés toutes les trois minutes. Dès qu’un problème survient sur un serveur, l’équipe est maintenant prévenue dans les trois minutes.
Afin de permettre à l’équipe de maintenir à jour l’outil, c’est-à-dire pouvoir ajouter/supprimer des serveurs, ajouter des ressources à superviser, modifier la configuration de l’interface web, etc…, j’ai, tout au long du stage, rédigé une documentation de soixante pages.
Dans cette documentation, j’ai décrit l’architecture du serveur de supervision, rédigé toutes les procédures d’installation de l’outil ainsi que des tutoriels détaillant la configuration de chaque fonctionnalité disponible dans l’interface web.

CONCLUSION

Durant ces six mois de stage, j’ai tout d’abord commencé par étudier le cahier des charges. J’ai ainsi pu sélectionner différentes solutions de supervision répondant le mieux aux exigences imposées. Cette étape m’a permis de retenir trois solutions parmi les plus connues dans le domaine de la supervision. Après avoir présenté chacune des solutions, Check_MK a été retenu.
J’ai ensuite pu débuter la construction d’un prototype de la solution de supervision. Pour cela, j’ai installé Check_MK sur un serveur virtuel dédié et je me suis servi de machines de test Linux, Solaris et Windows sous différentes versions.
Dans un premier temps, j’ai installé l’agent de supervision sur les machines de test afin de vérifier la validité des informations remontées par Check_MK (utilisation CPU, RAM, espace disque, etc…).
Une fois ceci fait pour chaque version de chaque OS, j’ai commencé à travailler sur les fonctionnalités, souhaitées par l’équipe, qui n’étaient pas disponibles en natif. Cette étape a été assez longue et a demandé de nombreuses recherches. J’ai, en effet, développé plusieurs scripts, en Bat et en Shell, permettant de récupérer en temps réel l’utilisation des licences de chaque logiciel, l’utilisation des espaces disques en réseau, le déroulement des sauvegardes, les mises à jour de l’antivirus, etc… La complexité de cette étape a été de développer des scripts Linux entièrement compatibles avec toutes les versions de Linux, de même pour Windows et Solaris. J’ai ainsi dû, pour chaque script, tester différentes méthodes afin d’aboutir à un script fonctionnant pour toutes les versions de chaque système d’exploitation. Ces scripts devaient, de plus, être les plus légers possible afin d’être exécutés rapidement par les machines supervisées, sans altérer les performances.
Enfin, mon prototype terminé, j’ai pu valider chacune des exigences du cahier des charges et déployer la solution de supervision. Pour faciliter l’installation de l’agent de supervision et la supervision de futurs serveurs, j’ai développé des scripts d’installation Linux et Windows. J’ai également rédigé une documentation technique d’une soixantaine de pages détaillant le fonctionnement et la configuration de la solution et des scripts locaux. Cette documentation permettra à l’équipe de maintenir à jour l’outil de supervision.
Au terme de ce stage, les objectifs fixés ont donc été atteints. J’ai en effet su proposer une solution de supervision complète qui répond au cahier des charges imposé.
Comme demandé, cette solution n’altère pas les performances des machines ni la bande passante du réseau.
L’outil de supervision devait être simple à maintenir à jour afin de ne pas être abandonné par l’équipe. Durant la phase de développement et configuration, j’ai toujours gardé cela à l’esprit et je pense avoir livré une solution facile d’utilisation.

Table des matières

PRESENTATION DE L’ENTREPRISE
PRESENTATION DU PROJET 
INTRODUCTION 
I. CHOIX DE LA SOLUTION 
1. Cahier des charges
2. Etude des solutions
3. Présentation de Check_MK
II. INSTALLATION DE CHECK_MK 
1. Installation de Check_MK
2. Supervision du serveur de supervision
3. Sécurisation des connexions à l’interface web
III. DEVELOPPEMENT ET VALIDATION 
1. Scripts locaux
2. Développement de scripts locaux
3. Validation des exigences du cahier des charges
IV. DEPLOIEMENT DE LA SOLUTION
1. Supervision d’une machine Linux
2. Supervision d’une machine Windows
3. Déploiement
CONCLUSION 
ANNEXE 1
ANNEXE 2 
1. Script qui récupère l’utilisation des montages NFS
2. Script qui récupère l’utilisation des licences pour une application donnée
TABLE DES ILLUSTRATIONS

Télécharger le rapport complet