Bachelor 2 – Rapport de Stage #3

Cet article récapitule les tâches réalisé lors de mon stage sur la période du 30/07/2018 au 10/08/2018.

I. Réalisation du 30/07/2018 au 10/08/2018

Ces deux semaines on été différentes puisqu’elles ont commencé par le départ d’un membre de l’équipe, Gaëtan, qui est parti pour évoluer sur un autre poste. Son départ étant prévu de longue date, un stagiaire devait le remplacer jusqu’à la rentrée, où un alternant le remplacerait définitivement.

Sven étant en congé lors de l’arrivée du stagiaire, j’ai eu la responsabilité de lui expliquer le fonctionnement de l’entreprise, l’aider à prendre en main les outils ainsi que l’aider dans ses premiers jours.

J’ai donc dispensé la même formation que j’ai reçu un mois auparavant.

Cette période étant plus calme dû aux vacances, j’en ai profité pour commencer des projets internes.

A. Activation des instantanés sur un NAS Synology

Le premier à été de réaliser l’activation des instantanés sur un NAS Synology, afin d’ajouter une protection en plus de la sauvegarde existante. Cette fonctionnalité est apparue avec la mise à jour 6.2 du DSM. Après m’être renseigné sur la documentation officielle de Synology, j’ai appris qu’il fallait que le volume soit en Btrfs pour pouvoir l’activer.

Pour information, le Btrfs est un système de fichier récent ; il est né en 2010. Il permet en autre la possibilité d’instantané (snapshot) et est voué à devenir le successeur de ext4.

Le volume du NAS étant en ext4, je devais le migrer vers Btrfs, ce qui impliquait de sauvegarder la configuration et les données existantes, supprimer le volume en ext4 pour recréer le même en Btrfs et enfin réimporter la configuration et les données. Malheureusement, après quelques recherche, j’ai appris que le NAS était trop ancien pour prendre en charge ce système de fichier. Je n’ai donc pas pu activer les instantanés.

B. Mise en place de GLPI

Ce projet étant abandonné, suite à l’incompatibilité du matériel, nous avons entrepris avec le nouveau stagiaire, Dominique, de mettre en place GLPI en interne.

GLPI est un outil de gestion des services informatiques libre et puissant pour la gestion de parcs et de centre de services.

Afin de ne pas impacter l’environnement de production, nous avons installé un Windows Server 2012 R2 sur un serveur inutilisé. Sur ce serveur, nous avons installé le service de virtualisation de Microsoft, Hyper-V, ce qui nous a permis d’héberger GLPI sur une machine virtuelle (VM). La virtualisation présente plusieurs avantage comparé à  la mise en place du service en dur sur le serveur :

  • En cas d’erreur, on peut recommencer de zéro sans aucun problème
  • On peut gérer les ressources allouées dynamiquement
  • On peut exporter le disque virtuel (VHD) pour recréer le service à l’identique sur un autre serveur, sans devoir réinstaller complétement GLPI

Nous avons donc commencé par créer la VM ainsi que son VHD via Hyper-V et, comme sur l’hyperviseur, un Windows Server 2012 R2 a été installé. Ensuite, le serveur virtuel, la VM que l’on a créée, a été mis dans le domaine local et a reçu une IP statique.

Par la suite, il nous a fallu installer les pré-requis de GLPI, c’est-à-dir : 

  • un service web, IIS dans notre cas
  • une base MySQL
  • PHP ainsi que plusieurs de ces extensions

Le serveur IIS à été installé via l’interface d’ajout de rôle et fonctionnalités du serveur. Ensuite un nouveau site à été créé pour servir GLPI sur le port 7777 et 7778 afin qu’il soit accessible par le web.

Les sites mis en place sur le serveur IIS

En ce qui concerne PHP, on a du l’installer via le Web Platorm Installer (WPI) de microsoft afin de procéder à une installation propre sur windows. On a ensuite ajouté manuellement les extensions manquantes et modifier la configuration de PHP (le fichier php.ini) pour répondre au besoin de GLPI.

Interface de WPI

Finalement, MySQL a été installé via l’installeur officiel récupérable sur leur site internet. Lors de l’installation, MySQL à été configuré pour fonctionner comme sur un serveur en production. Afin d’administrer rapidement la base MySQl, on a aussi ajouté phpMyAdmin sur le service web en localhost.

Tous ces pré-requis remplient, nous avons enfin pu commencer l’installation de GLPI. On a donc télécharger l’archive de la dernière version de GLPI puis décompressé dans le dossier racine du site. L’installation s’est ensuite poursuivit via l’interface web. On a aussi crée une base MySQL ‘glpi’ avec son utilisateur associé.

Une fois GLPI installé, il a fallu rendre l’application accessible depuis l’extérieur. Pour se faire, nous avons créé un sous-domaine ticket.aldisa.fr sur le domaine existant qui renvoie vers l’adresse IP publique de Aldisa. Nous avons ensuite créé un enregistrement pour ce sous-domaine sur le DNS local afin qu’il redirige vers le serveur de GLPI. Pour finir, nous avons autorisé le port 7777 en entrant et créé une règle de NAT sur le pare-feu pour rediriger le port 7777 vers le serveur de GLPI. Ainsi l’application est disponible via l’adresse ticket.aldisa.fr:7777 (le service n’est plus disponible puisque le serveur sur lequel il était a été réutilisé pour un autre service) 

L’application étant disponible de l’extérieur ainsi qu’en local, nous avons commencé par explorer l’application et les différentes configurations possibles , comme par exemple l’authentification via un LDAP existant, on a utilisé l’Active directory local pour faire nos test. On a aussi créé des tickets, utilisateurs, groupes, entités, profils etc…, afin d’expérimenter les fonctionnalités de GLPI. Par la suite, on a ajouté des plugins afin de comprendre leur gestions et les possibilités qu’ils peuvent offrir en terme de personnalisation.

C. Problème de sécurité

Le vendredi 10 août, j’ai participé à une intervention un peu particulière. En effet, un utilisateur nous a appelés se plaignant d’avertissement de Chrome lorsqu’il naviguait sur certains sites internet.

Tout d’abord, il faut savoir que les employés de ce client travail tous sur un serveur commun via une connexion TSE, plus communément appelé serveur TSE. Il travaille donc tous sur le même système, chacun sur sa session. Ainsi, s’il y a un problème lié au système, tous les utilisateurs sont impactés.

Effectivement, lors de prise en main sur le serveur, il s’est avéré que Chrome bloquait la connexion vers certains sites à cause de certificats SSL invalide. Nous avons donc commencer à investiguer pendant près d’une demi-heure pour découvrir que le fichier système hosts* était corrompue par plusieurs milliers de redirections pirate, ce qui était la cause des avertissement de Chrome. Par la suite, afin de vérifier l’état de santé du serveur, on a installé malwarebytes et lancée une analyse. Il s’est avéré que le serveur possédait 150 menaces potentielle dont plusieurs malware de type Hijack, ce qui correspondait parfaitement à notre découverte. On a donc supprimé l’intégralité des menaces ainsi que nettoyer complètement le fichier hosts, ce qui a résolu le problème initial.

* le fichier hosts est consulté par l’ordinateur avant d’accéder à un site Internet. Ainsi, par exemple si l’adresse IP 1.1.1.1 est spécifié pour www.lemonde.fr, lorsque vous voulerez accéder à cette URL vous serez redirigé vers l’adresse IP 1.1.1.1 et non la véritable adresse IP.

Cette période calme m’a donc permis d’en apprendre plus sur la gestion et la mise à jour d’un NAS Synology. J’ai aussi pu configurer un service de son installation à sa mise en service, qui plus est, j’ai appréhendé GLPI qui est un des leader sur le marché des ITSM. De plus, j’ai amélioré ma capacité à analyser un problème majeur, comme celui rencontré en fin de semaine.

Cela conclut cet article sur mon stage de deuxième année.