19/08/2022 Inventaire du parc

client – Suite ELK

Titre professionnel – Administrateur
d’Infrastructures Sécurisées

Marius COUVRAT-DESVERGNES
MISTRAL INFORMATIQUE – SIMPLON.CO
Sommaire
1. Remerciements ................................................................................................................................... 3
2. Introduction......................................................................................................................................... 4
3. Abstract ............................................................................................................................................... 5
4. Tableau récapitulatif ........................................................................................................................... 6
5. Présentation de l’entreprise................................................................................................................ 7
5.1. Présentation générale .................................................................................................................. 7
5.2. Les grandes dates ......................................................................................................................... 7
5.3. Les services ................................................................................................................................... 8
5.3.1. Zoom sur le service Opérations et Services IT ....................................................................... 9
5.3.2. Mon rôle au sein de Mistral .................................................................................................. 9
5.4. Présentation des logiciels ........................................................................................................... 11
5.4.1. Présentation générale ......................................................................................................... 11
5.4.2. Présentation technique ....................................................................................................... 12
6. Projet en entreprise – Inventaire du parc clients .............................................................................. 13
6.1. Contexte ..................................................................................................................................... 13
6.2. Expression des besoins ............................................................................................................... 14
6.3. Schéma directeur ....................................................................................................................... 15
6.3.1. Cibler les informations essentielles des serveurs – Étude des infrastructures ................... 16
6.3.2. Mettre en place une solution d’extraction des informations – Script d’inventaire ............ 17
6.3.3. Configuration du socle ........................................................................................................ 18
6.3.4. Traitement automatique des données – Logstash .............................................................. 19
6.3.5. Stockage des données de manière centralisée – ElasticSearch .......................................... 21
6.3.6. Affichage des données – Kibana.......................................................................................... 23
6.3.7. Sécurisation des outils ......................................................................................................... 25
Logstash ..................................................................................................................................... 25
ElasticSearch .............................................................................................................................. 28
Kibana ........................................................................................................................................ 29
6.4. Suite du projet ............................................................................................................................ 31
6.4.1. Restructuration du DNS de l’entreprise .............................................................................. 32
6.4.2. Mise en place d’une plateforme de collecte de l’inventaire ............................................... 32
6.4.3. Réflexion sur la méthode de collecte des données par Logstash ....................................... 32
7. Projet en entreprise – Analyse des rapports DMARC ....................................................................... 33
7.1. Contexte ..................................................................................................................................... 33
7.2. Expression des besoins ............................................................................................................... 33

Page 1 sur 43
 7.3. Schéma directeur ....................................................................................................................... 34
7.3.1. Rassembler les rapports – Création d’une boîte aux lettres dédiées ................................. 34
7.3.2. Collecter les données – ParseDMARC ................................................................................. 35
7.3.3. Visualiser les rapports DMARC – Kibana ............................................................................. 38
7.3.4. Sécurisation de l’outil .......................................................................................................... 38
8. Conclusion ......................................................................................................................................... 42
9. Annexe – Script d’inventaire ............................................................................................................. 43

Page 2 sur 43
1. Remerciements
Cette alternance fut une opportunité assez exceptionnelle, puisqu’embauché récemment en CDI à
Mistral Informatique. Mes remerciements vont en premier lieu à M. Fabrice LE CAMUS, Président
Directeur Général de la société, ainsi qu’à M. Vincent PORCEL, Directeur Opérations et Services IT et
également mon tuteur, pour avoir cru en mon travail et ma motivation et m’avoir permis poursuivre
ma formation au sein de l’entreprise.

Je remercie également l’organisme Simplon.co, pour m’avoir suivi une troisième année dans mon
parcours de formation dans le domaine des Systèmes et Réseaux, et surtout pour m’avoir accordé
leur confiance en me contactant lors de l’ouverture de cette promotion d’Administrateur
d’Infrastructures Sécurisées (AIS). Parmi eux, j’accorde une pensée particulière à Mme Christine
CAVARRETTA, ma chargée de formation sur cette promotion ; ainsi qu’à Mme Pauline MATHELIN-
ROUILLET, qui n’est plus en poste à Simplon à l’heure où j’écris ces lignes, mais qui est pour
beaucoup dans mon parcours d’études à Simplon et dans mon intégration à cette promotion AIS.

Je souhaite adresser des remerciements particuliers à M. Duncan ORRO, mon formateur pour cette
année qui, par sa disponibilité, ses compétences et sa pédagogie, a su faire naître cette motivation
pour le métier. Son soutien et son accompagnement ont participé à l’éveil de ma curiosité et à
l’accroissement de mes compétences techniques.

Enfin, j’adresse mes pensées aux personnes m’ayant apporté, collègues de formation comme
collaborateurs de société, ce sentiment de progression en collectif et l’acquisition de ces
compétences dans une atmosphère de travail sereine et efficace.

Leur présence sur l’ensemble de l’année a contribué positivement au travail fourni et fut pour moi
une expérience professionnelle épanouissante.

Page 3 sur 43
2. Introduction
J’ai effectué cette année de formation d’Administrateur d’Infrastructures Sécurisées auprès de
l’organisme Simplon.co, basé à Grenoble. Ces études ont été menées en complément de mon contrat
d’apprentissage au sein de Mistral Informatique.

Cette formation s’est naturellement présentée comme la suite logique de mon parcours, étant déjà
diplômé à deux reprises dans le domaine des Systèmes et Réseaux : Technicien d’Assistance
Informatique (2019) et Technicien Supérieur Systèmes et Réseaux (2021 – en alternance également).
Désireux de consolider mes compétences et de m’initier à l’automatisation et la supervision des
infrastructures, je n’ai pas hésité à postuler lorsque j’ai eu l’occasion d’intégrer la promotion.

En pleine crise COVID, Mistral Informatique s’est trouvé en sous-effectif. Je fus alors embauché en
CDI dans le service Opérations et Services IT afin de le renforcer. Satisfait et confiant dans mon
travail, M. Le Camus et M. Porcel m’ont permis de reprendre mon parcours de formation lorsque j’en
ai eu l’opportunité.

Si mes missions restaient inchangées, je découvris rapidement les problématiques des

infrastructures informatiques délivrées aux clients dans le cadre de nos prestations. Force de
proposition, plusieurs projets s’inscrivant dans un besoin d’uniformisation et de sécurisation du parc
client me furent confiés.

Ces projets, très formateurs car impliquant des systèmes sur lesquels je n’avais pas encore eu
l’occasion de travailler ni en formation, ni en environnement professionnel, m’ont fait acquérir une
méthode de réflexion différente puisque je devais réfléchir de manière globale. Malgré les
spécificités de chaque client, j’ai su mettre en place des méthodes uniformes pour répondre aux
besoins de chaque projet.

Page 4 sur 43
3. Abstract
I have the opportunity to graduate as a System and Network Administrator within Simplon.co while
working part time in Mistral Informatique. This formation lasts twelve months and follows my
training path in the profession since I already have two degrees :

• Technicien Assistant Informatique (Information Technology Assistant) in 2019 after a

continuing education
• Technicien Supérieur Systèmes et Réseaux (Systems and Network Technician) in 2021 after a
year of formation while working part time in an other company.

Mistral is actively implemented in France as a software company since 1980. Their softwares
depends on the operating AIX and Linux servers working essentially through command lines. By
selling equipments that might be necessary depending on the client infrastructure, the society also
prepares and maintains devices such as PCs, printers, routers and other network appliances.

This document describes my experience through fifteen months within the company where I learned
about its operating conditions and history. It brought me a better comprehension of the context and
its technical problematics. As a support technician, I’ve worked on basic incidents with customers
through phone and tickets, and happened to study on implementing larger scale solutions like
automation of maintenance via scripts.

The project I’ve worked on within Mistral is my answer to large scale maintenance of client
infrastructures. One of its part is a script collecting specific data of the operating system and its
services. Another part is the configuration of the ELK stack (ElasticSearch, Logstash and Kibana) on a
dedicated server.

Page 5 sur 43
4. Tableau récapitulatif
Voici le tableau récapitulant les compétences professionnelles sollicitées durant mon implication au
projet d’entreprise présenté.
Activités types
Administrer et sécuriser les
composants constituant
l’infrastructure
Intégrer, administrer et sécuriser une
infrastructure distribuée
Faire évoluer et optimiser
l’infrastructure et son niveau de
sécurité
Compétences professionnelles
Administrer et sécuriser le réseau
d’entreprise
Administrer et sécuriser un
environnement système hétérogène
Administrer et sécuriser une
infrastructure de serveurs virtualisée
Appliquer les bonnes pratiques et
participer à la qualité de service
Créer des scripts d’automatisation
Intégrer et gérer les différents
environnements de travail des
utilisateurs
Administrer les services dans une
infrastructure distribuée
Superviser, mesurer les performances
et la disponibilité de l’infrastructure et
en présenter les résultats
Proposer une solution informatique
répondant à des besoins nouveaux
Mesurer et analyser le niveau de
sécurité de l’infrastructure
Participer à l’élaboration et à la mise
en œuvre de la politique de sécurité
Tâches accomplies
Identification des ports non sécurisés
(FTP et Telnet) en écoute sur les
serveurs des clients.
Collecte de données relatives aux
services actifs sur les serveurs de
production des clients (AIX version 5 à
7, Linux Redhat version 4 à 7)
Sécurisation de la machine virtuelle
hébergeant la suite ElasticSearch.
Configuration et sécurisation du
système hébergeant ElasticSearch
selon les bonnes pratiques de sécurité.
Configuration de Kibana pour faciliter
l’accès à l’information avec les stricts
accès nécessaires.
Création d’un script de collecte de
données en vue d’effectuer
l’inventaire du parc client.
Collecte de données relatives au
logiciel Mistral en vue de mises à jour
de l’environnement utilisateur.
Collecte de données relatives aux
services pour déploiement de mises à
jour.
Collecte de données pour inventaire
du parc et création de dashboards
pour mesurer la performance globale
des infrastructures.
Initiative de mise en place de la suite
ELK suite à l’expression du besoin de
l’inventaire du parc client.
Collecte de données relatives aux
services afin d’identifier les versions
utilisées dans le parc client, en vue
d’appliquer d’éventuelles mises à jour.
Collecte de données afin de prévoir le
déploiement de mises à jour ou de
correctifs de sécurité.
Page 6 sur 43
5. Présentation de l’entreprise
5.1. Présentation générale
Groupe Mistral est un éditeur de logiciel ERP basé à Clermont-Ferrand. Ciblant principalement les
professionnels du métier agricole, de la location ou de la manutention, Mistral Informatique a été
créé en 1980 dans le but de révolutionner la distribution et la location de matériels. Groupe Mistral
est créé en 2018 afin de regrouper les multi sociétés ouvertes suivant les besoins administratifs des
différentes solutions. En constante évolution depuis plus de 40 ans, le logiciel Mistral est devenu une
référence, plaçant la société dans le top 250 des éditeurs de logiciels français (étude menée par
Numeum sur l’édition 2021). L’entreprise dépasse les dix millions de chiffre d’affaires avec 75
collaborateurs sur la fin de l’année 2021 en accompagnant plus de 550 clients pour plus de 17 000
postes de travail en France et à l’étranger. Parmi eux, nous pouvons citer les concessionnaires, les
distributeurs, les loueurs et les réparateurs de matériels divers.

5.2. Les grandes dates

Groupe Mistral a été marqué de plusieurs grandes dates marquantes de son évolution en tant
qu’éditeur de logiciels :

1988 – Création 1992 – Création

1980 - Création de Magrix ERP : de DLRIX ERP :
de la société spécialisé dans le Spécialisé dans
Mistral Machinisme les TP/BTP et la
Informatique Agricole location

1985 – Décision 1989 – Obtention

fondamentale de d’un double
s’engager en agrément de la
pionner dans le part d’IBM
monde UNIX permettant
d’implanter ses
logiciels sur
machines UNIX

1997 –
Première
version 2012 –
graphique des Premières 2018 – Reprise
ERP Magrix et applications de et création du
DLRIX mobilités Groupe Mistral

1997 – Mistral 2013 – Création 2021 –

Informatique du Datacenter Accélération
devient Centre des ventes
d’Expertise AIX dématérialisées
de la solution
Mistral

Cet historique permet la compréhension du contexte dans lequel se trouve aujourd’hui cette société
chargée d’histoire.

Page 7 sur 43
5.3. Les services
Dans un but commun de délivrer le meilleur service possible à ses clients, Groupe Mistral est
partitionné en différents services répondant aux besoins techniques, administratifs et commerciaux,
dont voici la liste et leurs chef·fes.

Opérations et
Support Logiciel services IT
• Aurélie Bijon • Vincent Porcel

Développement Commercial
• Cédric Gouttebroze • Vincent Chardot

Formations Marketing et
• Philippe Ranval communication
• Bruno Viallefont

Administratif et
financier
• Stéphanie Laurent

Administratif et S’occupe de la facturation et des contrats des différents services proposés par Mistral et par leurs
partenaires.
Financier
Commercial Couvre l’ensemble du territoire Français pour assurer les relations commerciales.

Développement Équipe de développeurs travaillant sur l’évolution, les projets et l’ajout de fonctionnalités des
solutions Mistral.

Formations Dispense les formations sur l’ensemble des modules du logiciel ; réalise des audits d'utilisation afin de
cibler les pratiques de l’entreprise cliente et ses process, dans un but d'amélioration du logiciel.

Marketing et Service prospectant de nouveaux clients, et médiatisant par le biais de vidéos ou d'infographies les
produits et solutions Mistral, dans le but d'être mieux connus de nos clients. Inversement, ils agissent
Communication pour que Mistral connaissent mieux leur clients afin d'être pertinent dans l'ajout de fonctionnalités.

Opérations et Assure le bon fonctionnement technique des solutions Mistral côté infrastructure, réseau et
périphériques.
Services IT
Support Logiciel Assiste les clients finaux dans l’utilisation et les incidents des solutions Mistral.

Page 8 sur 43
 5.3.1. Zoom sur le service Opérations et Services IT
En tant que Technicien Support, ma prise de poste eut lieu dans le service Opérations et Services IT,
au sein d’une équipe constituée de sept techniciens. L’existence d’un tel service dans une société
éditrice de logiciel s’explique par le fort besoin d’infrastructure pour permettre le bon
fonctionnement des logiciels. La société étant positionnée comme revendeur de matériel, il fallait un
service pour le maintenir. Aussi, le service Opérations et Services IT s’occupe de l’installation, du
paramétrage et du maintien en condition opérationnelle des matériels vendus par la société, dont
voici une liste exhaustive :

• Serveurs (AIX, Linux Redhat, ou Windows)

• Routeurs (Cisco, et prochainement PfSense)
• Ordinateurs fixes et portables
• Clients légers (Wyse)
• Imprimantes
• Équipements réseaux (switchs, bornes wifi)

Le service a également permis l’ouverture et le maintien du datacenter, par lequel les clients
accèdent au logiciel en mode SaaS.

Ainsi, la charge de travail est répartie en trois niveaux :

Niveau 1 Niveau 2 Niveau 3

•Prends en charge les •Traite les tickets •Traite les tickets

incidents "simples" des
équipements maintenus
•Paramètre le matériel
vendu
escaladés par le niveau 1
et les problématiques
"complexes"
•Met en place et dépanne
les liaisons IPSec entre
Mistral et ses clients
escaladés par le niveau 2
•Administre et maintien le
datacenter en condition
opérationnelle

5.3.2. Mon rôle au sein de Mistral

En intégrant Mistral en tant que Technicien Support, je fus affecté au niveau 1. Cette affectation
s’est décidée d’une part par le besoin de renforts dans ce niveau de résolution d’incidents, et d’autre
part comme support de formation à l’environnement technique spécifique englobant le logiciel. Ces
mois de travail au support m’ont permis de me saisir du contexte technique de notre société et de
gagner en compétences sur les systèmes Linux Redhat et UNIX. Je me rendis compte par la suite que
ces connaissances acquises furent essentielles pour traiter les projets confiés avec pertinence et
efficacité.

Ainsi, dans les premiers mois de mon intégration dans l’entreprise, je traitai par mail et par
téléphone les demandes bloquantes des clients telles que :

• Le dépannage de files d’attentes d’impressions UNIX et Linux

• L’installation et le paramétrage à distance d’équipements vendus par Mistral (comme par
exemple des routeurs Cisco, des imprimantes, ou encore des PC sous Windows)
• L’installation du client de connexion Mistral
• Le paramétrage et l’installation de connexion VPN IPSEC client to site

Page 9 sur 43
 • Le dépannage utilisateur sous Windows

Travaillant principalement sous des environnements en ligne de commande, je pris rapidement

l’initiative de travailler sur des scripts d’automatisation effectuant des tâches simples. Parmi ceux-ci,
je peux citer la création d’environnement Mistral (nécessitant la création de fichiers de
configurations et la définition de leurs ports de connexion associés), le démarrage et l’arrêt du
logiciel Mistral et les services dont il dépend, ou encore la création d’un logiciel d’installation du
client Mistral sous Windows. Peu à peu, mes missions au sein de l’équipe technique se divisèrent
entre la résolution d’incident de niveau 1 et la réalisation de projets d’administration de nos serveurs
de manière automatisée. Et au fur et à mesure que je gagnai en compétences, je finis par prêter
renfort ponctuellement au niveau 2, en traitant des problématiques plus complexes. Parmi celles-ci,
j’ai pu travailler sur des incidents tels que :

• L’analyse de charge inhabituelle de serveurs

• L’intégration de nouveaux pilotes dans les serveurs d’impression UNIX et Linux
• La modification en masse de fichiers de configuration, afin de mettre à niveau les versions de
Java appelées par le logiciel

Enfin, j’ai finalement pris part à des projets à plus long terme, comme le fonctionnement de Mistral
sous Windows 11, ou suite à la désinstallation d’Internet Explorer (sur lequel le logiciel s’appuie pour
certaines fonctionnalités).

Page 10 sur 43
5.4. Présentation des logiciels
5.4.1. Présentation générale
Mistral est une solution ERP divisée en deux logiciels, Magrix3G et DLRX3G qui peuvent sembler
similaires de par leur interface, mais qui auront des fonctionnalités différentes selon les besoins du
domaine d’activité. Magrix est destiné aux professionnels du monde agricole, tandis que DLRX
s’adresse au monde du BTP et de la location. Cette différence n’étant pas essentielle d’un point de
vue technique, nous désignerons les solutions par leur nom générique qu’est Mistral.

Regroupant plus de 300 modules avec chacun leur utilité, l’ERP couvre un ensemble de besoins dont
les plus notables sont la gestion des achat et des stocks, la comptabilité ou encore la gestion de parc
et de la location.

Il se présente à l’utilisateur comme une interface par laquelle l’appel de module se fait via une liste
déroulante, ou par l’appel de mnémonique.

Mistral s’accompagne de logiciels dits de « mobilités » pour les professionnels itinérants, permettant
l’accès à certaines fonctionnalités depuis des appareils mobiles comme des tablettes sous Apple ou
Android.

Page 11 sur 43
 5.4.2. Présentation technique
Mistral est un logiciel historiquement développé en Cobol qui s’exécute sur un serveur dédié sous
Linux Redhat ou AIX. Si son utilisation à ses débuts se faisait au travers d’une console directement sur
le serveur, l’évolution massive des outils informatiques et de notre manière de les utiliser pousse le
logiciel à se moderniser et permettre, dès 1997, son utilisation au travers de clients.

Évolution graphique de l'interface du logiciel

Pour cela, Mistral s’est appuyé sur les technologies AcuConnect et

ThinClient, toutes deux développées par MicroFocus.

En les intégrant au logiciel, ils rendaient possible les fonctionnalités suivantes :

• L’ajout d’une interface graphique aux logiciels Cobol

• La migration d’une application Cobol vers un modèle client/serveur
• Le déploiement en réseau de l’application
• Et d’autres possibilités non utilisées par Mistral.

AcuConnect, une fois mis en place sur les serveurs, permet l’ouverture de ports d’écoute pour la
connexion des clients, et le renvoie des informations du logiciel.

ThinClient, côté client, initie la connexion à AcuConnect selon l’adresse IP et le port renseignés dans
ses fichiers de configuration. Une fois la page d’authentification affichée, l’utilisateur peut naviguer
au travers du logiciel et de ses différents modules. Il est intéressant de noter que chaque ouverture
de module voit son processus associé côté serveur. Ainsi, chaque fonctionnalité du logiciel de chaque
utilisateur est gérée par le serveur de manière indépendante.

Selon les besoins exprimés par le client, Mistral peut être vendu sous différents supports, allant du
SaaS à l’infrastructure physique, ou encore la livraison du logiciel qui sera installé sur un équipement
non géré par la société.

L’accès au logiciel par les équipes techniques ou pour le déploiement de mises à jour, lorsqu’il est
délivré autrement qu’en mode SaaS, se fait via une télémaintenance, mise en place et maintenue par
Groupe Mistral et éventuellement par le client. Il s’agit d’un tunnel IPSec entre deux équipements
permettant la connexion à distance au serveur hébergeant le logiciel. L’équipement côté client est
configuré en mode responder, ce qui permet de monter le tunnel uniquement à l’initiative du réseau
Mistral, avec par exemple la tentative de connexion au serveur pour les opérations de maintenance.

Page 12 sur 43
6. Projet en entreprise – Inventaire du parc clients
6.1. Contexte
Mistral est une société éditrice de logiciels ayant la particularité de fournir du matériel informatique
et d’en assurer son maintien en condition opérationnelle. S’adaptant aux problématiques techniques
des infrastructures clients dans lesquelles nous intervenons, les équipements pourront varier. Dans
le cas de serveurs, il s’agira d’AIX ou de Redhat Linux qui seront vendus et donc sous la propriété du
client. Réputés très durables, ces serveurs ont une grande durée de vie et seront remplacés selon le
bon vouloir du client, généralement lors d’une défaillance technique hors garantie. Ce point est
important car il explique que le parc client que nous maintenons est hétérogène, non seulement du
fait qu’il s’y trouve deux systèmes d’exploitation aux différences notables, mais également de par les
différences de versions des serveurs toujours en production, pour certains depuis plus de 15 ans. Ces
versions plus anciennes, bien que toujours fonctionnelles, posent la question de l’obsolescence des
services installés, et les problématiques de sécurité que cela engendre.

Le mode SaaS se présente comme une solution à ces questions d’hétérogénéité. En effet, les
serveurs sont hébergés sur un hyperviseur VmWare dans notre datacenter ; ils sont faciles d’accès et
à maintenir à jour ; et ils sont sous la propriété de Mistral, en location pour le client.

C’est également un avantage pour le client, qui ne dispose pas de serveur à installer et à surveiller au
sein de sa société. Il n’a pas non plus à disposer d’équipements supplémentaires pour nous
permettre de maintenir son infrastructure Mistral en fonctionnement, comme c’est le cas avec les
tunnels IPSec mis en place pour assurer la télémaintenance.

Cependant, le mode SaaS n’est promu auprès des clients que depuis très récemment, et s’il séduit
les nouveaux clients, la migration des anciens se fait plus difficilement malgré nos démarchages
commerciaux. Cela s’explique du fait qu’ils sont propriétaires de leur infrastructure, et que celle-ci
est toujours fonctionnelle. De ce fait, nous avons toujours une très grande majorité de serveurs à
maintenir se trouvant chez les clients, et si nous avons conscience de ce parc hétérogène, nous
n'avons aucun moyen de déployer des solutions adaptées à chaque infrastructure.

Page 13 sur 43
6.2. Expression des besoins
En prenant le contexte en compte, l’objectif final est donc de sécuriser l’ensemble du parc
informatique client. Cependant, cet objectif en amenait d’autres, sans lesquels il ne peut être atteint,
que j’ai identifiés en trois étapes :

Inventaire technique de
l'ensemble des serveurs

Étude des solutions suivant

la problématique d'un ou
d'un groupe de serveur

Déploiement de solutions de
sécurisation des serveurs

Dans le cas de Mistral, tout restait à faire. Il m’a alors été confié la première étape de ce projet de
sécurisation des infrastructures : étudier et mettre en place une solution d’inventaire du parc
hétérogène client.

Cette mise en place doit se faire sous plusieurs contraintes, définies avec mon chef de service :

• L’ensemble du processus nécessite d’être automatique et sans, ou avec un minimum

d’intervention humaine
• Les données d’inventaire doivent être centralisées et toutes accessibles sur une même
interface
• La solution doit être gratuite, hébergée localement et sécurisée

Ce projet d’inventaire constitue mon projet d’entreprise pour mon alternance d’Administrateur
d’Infrastructures Sécurisées.

Page 14 sur 43
6.3. Schéma directeur
Partant de zéro, j’ai identifié les étapes du projet pour formaliser le schéma directeur suivant :

•Il s'agit d'identifier les informations du serveur pertinentes à recueillir concernant

ses services installés, et leur version, afin de connaître si ceux-ci sont sujets à une
Cibler faille de sécurité.

•Une fois ces informations ciblées, la mise en place d'une solution d'extraction des
données de manière automatique doit être mise en place et compatible avec tous
Extraire les serveurs installés chez les clients.

•Suite à leur extraction, ces informations ne peuvent pas rester contenues dans de
simples fichiers textes. Elles doivent être traitées dans le but d'être interprétables
Traiter par d'autres outils.

•Les données, une fois formatées, nécessitent ensuite d'être stockées dans une base
Stocker de données centralisée.

•Enfin, ces données, doivent être rendues accessibles au sein d'une même interface
Afficher dans le but d'être exploitées.

La finalité du projet est d’avoir une interface dans laquelle nous pourrons, par exemple, filtrer les
résultats en affichant seulement les serveurs présentant un service obsolète. Un tel résultat nous
permet d’avoir une liste de clients sur lesquels déployer une solution.

Page 15 sur 43
 6.3.1. Cibler les informations essentielles des serveurs – Étude des infrastructures
Inventorier les serveurs impliquait de connaître les informations essentielles à extraire. Un serveur
hébergeant le logiciel Mistral a besoin, pour fonctionner, de plusieurs services réseaux différents. A
titre d’exemple, la prévisualisation de documents PDF et leur impression nécessite que le serveur soit
serveur web et serveur d’impression.

Voici la liste des différents services que l’on peut trouver sur un serveur Mistral, et que l’on souhaite
donc connaître pour notre inventaire :

Il était pertinent de rajouter à cette liste un inventaire des protocoles non sécurisés susceptibles
d’être toujours activés, comme la connexion via Telnet ou le transfert de fichiers en FTP.

Bien sûr, cette liste de données à récupérer n’est qu’une base qui évoluera par la suite. Mais celle-ci
constitue pour le moment un bon point de départ pour la mise en place de ces solutions.

Page 16 sur 43
 6.3.2. Mettre en place une solution d’extraction des informations – Script d’inventaire
En possession des informations à obtenir des serveurs, il faut réfléchir à une solution pour les
extraire. Les cibles étant des serveurs Linux/UNIX, j’ai fait le choix de rédiger un script allant chercher
ces données pour les stocker ensuite dans un fichier. Ce script devait répondre à plusieurs
contraintes :

• Être compatible avec Bash et KSH, étant respectivement les shells par défaut des
environnements Linux Redhat et AIX.
• Dans certains cas, prévoir le cas où le système serait type Linux ou type Unix. En effet, les
commandes ne sont pas toujours les mêmes car le fonctionnement des services peut différer
d’une distribution à l’autre.

J’ai donc décidé que ce script serait orienté objet, où chaque fonction serait la succession de
commandes pour obtenir les informations d’un service. Ces informations sont stockées sur une seule
ligne dans un fichier texte pour l’apparenter à une donnée de journalisation, afin de faciliter son
traitement ensuite.

Le script est disponible en annexe. Il a bien sûr été modifié à plusieurs reprises afin de se conformer
aux prérequis des étapes suivantes.

Son fonctionnement est simple : après avoir été importé sur le serveur cible, il doit être rendu
exécutable, puis exécuté :

$ chmod 700 ./inventaire.sh

$ ./inventaire.sh

Le script s’exécute de manière silencieuse. Dès que la console rend la main, un fichier inventaire-
hostname-AAA_MM_JJ.inv est créé dans le répertoire /tmp.

$ ls /tmp/*.inv
> /tmp/inventaire-CLIENT7-2022_08_01.inv

Ce fichier contient les informations voulues sous la forme suivante :

hostname OS_distribution OS_version IP ?IP_2? ?IP_3? AcuShare SMB

GhostScript PsSelect SSH SSL FTP_activé SSH_activé Telnet_activé
COMMENTAIRE

Les champs ?IP_2? et ?IP_3? sont des informations optionnelles. Certains des serveurs de nos clients
disposent en effet de plusieurs cartes réseaux, une utilisée pour l’accès local pour les clients, et une
utilisée pour notre accès en télémaintenance. Cette particularité vient du fait que chaque client, chez
lequel nous sommes susceptibles de nous connecter au travers un tunnel IPSec, nécessite son propre
adressage réseau. Il ne doit pas être en double avec l’adressage d’un autre client, sans quoi cela
poserait des problèmes de routage.

Dans la majeure partie des cas, nous avons pu refaire l’adressage réseau de nos clients afin de ne
pas avoir recours à une deuxième carte réseau, mais une minorité de serveurs dispose tout de même

Page 17 sur 43
de deux, voir trois adresses IP (car les contraintes de prestataires extérieurs peuvent aussi nécessiter
la mise en place d’une autre adresse IP).

Le dernier champ COMMENTAIRE a été prévu dans le cas où des informations additionnelles
devraient être signalées. Non utilisé pour le moment, il contient à chaque fois la mention end.

Ainsi, nous obtenons un fichier tel que :

$ cat /tmp/inventaire-CLIENT7-2022_08_01.inv
> client7 AIX 7.2.0.0 192.168.1.1 9.2.1 3.6.25 8.50 1.17 8.1p1 1.0.2u
false true false end

C’est ce fichier qui sera utilisé pour le traitement des données dans les étapes suivantes.

6.3.3. Configuration du socle

Le but étant d’avoir un ensemble d’outils traitant les données de manière centralisée, automatique
et locale, je décide de configurer un serveur pouvant répondre aux exigences définies dans le schéma
directeur. A la recherche de solution gratuite, je m’oriente sur des solutions open source dont la
compatibilité est souvent plus établie lorsque s’exécutant sur des serveurs de distribution Linux.

J’ai donc choisi de mettre en place une machine virtuelle sur notre hyperviseur vCenter, avec la
configuration suivante :

• 2 CPU
• 8Go de Mémoire Vive
• 100Go de données sur un disque dur
• Système d’exploitation Debian 11

Mon choix d’OS s’est porté sur Debian, pour ma connaissance du système ainsi que pour sa
popularité auprès des outils open source.

Sachant que je manipulerai un certain nombre de données variables, le disque a été partitionné en
conséquence, en allouant la majeure partie de l’espace dans la partition /var.

Le serveur est installé sans interface graphique, avec simplement un serveur SSH pour permettre la
connexion distante.

Page 18 sur 43
 6.3.4. Traitement automatique des données – Logstash
En exécutant le script sur une soixantaine de serveurs, j’avais une base pertinente pour effectuer de
l’analyse de données. Plusieurs solutions ont été explorées pour le traitement :

• Un script Powershell pour compiler les différents inventaires des serveurs dans un fichier
Excel
• Formatter l’inventaire en XML pour le traitement ultérieur par des outils tierces

Je me suis finalement rappelé de cet outil vu en formation, Logstash, utilisé spécialement pour le
traitement et le renvoi des données analysées. Disposant d’un serveur Debian, j’ai pu l’installer et
commencer la configuration avec le filtre.

Logstash intègre nativement l’outil Grok, avec lequel nous pouvons analyser et séparer des données
de manière précise et automatique. Pour rappel, la ligne d’inventaire des fichiers qui seront analysés
a la forme suivante :

hostname OS_distribution OS_version IP ?IP_2? ?IP_3? AcuShare SMB

GhostScript PsSelect SSH SSL FTP_activé SSH_activé Telnet_activé
COMMENTAIRE

Ainsi, après plusieurs essais sur l’outil en ligne grokdebug, j’en suis venu au filtre Grok ci-dessous :

%{HOSTNAME:hostname} %{WORD:os_distribution} %{DATA:os_version} %{IPV4:IP}

(?:%{IPV4:IP})? (?:%{IPV4:IP})? %{DATA:acushare} %{DATA:smb} %{DATA:gs}
%{DATA:ps} %{DATA:sshv} %{DATA:sslv} %{WORD:ftp} %{WORD:ssh}
%{WORD:telnet} %{GREEDYDATA:comment}

Ici, le filtre prend bien compte le caractère « optionnel » des 2 adresses IP supplémentaires (pour un
maximum de 3).

Page 19 sur 43
Dans les différents cas de figure :

Ce qui m’a permis de faire un premier fichier de configuration inventaire.conf pour en valider le
fonctionnement en condition réelle :

Une fois Logstash démarré avec la commande :

$ bin/logstash -f ./inventaire.conf

L’entrée d’une ligne d’inventaire nous confirme que les données sont correctement formatées et
prêtes à être envoyées.

Une fois le filtre établi, il nous fallait savoir comment les données serait reçues, et où les envoyer :
soit les paramètres input et output.

Page 20 sur 43
Concernant le paramètre input, j’ai pensé pour le moment à créer un répertoire dédié pour le dépôt
de ces fichiers d’inventaires. Logstash garde ce dossier sous surveillance et traite l’arrivée des
nouveaux fichiers. Le paramètre input est alors configuré comme suit :

Fichier de configuration à l’issue de cette partie :

L’output, dépendant de la suite du traitement et de l’affichage des données, sera traité dans le
prochain point.

6.3.5. Stockage des données de manière centralisée – ElasticSearch

Comme il est rare d’évoquer Logstash sans parler d’ElasticSearch, j’ai décidé de le mettre en place
au sein du même serveur, afin de stocker les données renvoyées par Logstash.

ElasticSearch et son installation depuis les dépôts officiels se configure automatiquement de

manière sécurisée :

• Création d’un super utilisateur au mot de passe fort

• Ouverture de la base de données en connexion SSL/TLS sur le port 9200
• Création et utilisation d’un certificat de sécurité pour la connexion SSL/TLS

Aussi, le fichier de configuration elasticsearch.yml n’a, pour le moment, pas été modifié. La base de
données est prête à l’emploi et permet de finaliser le paramétrage de l’option output de Logstash,
donnant le fichier de configuration suivant :

Page 21 sur 43
 Le dernier paramètre « index » constitue le nom des rapports contenant les informations des
serveurs. Ici, pour chaque fichier analysé, un index, dont le nom dépendra du nom d’hôte du serveur
en question et du jour de l’année, sera généré dans ElasticSearch.

Une fois les fichiers d’inventaire placés à l’emplacement défini, relancer notre commande Logstash
ne renvoie maintenant aucun output. Une erreur de connexion à ElasticSearch aurait été signalée
directement dans la console. Mais nous pouvons tout de même nous assurer que les index ont bien
été créés avec la commande curl.

$ curl https://localhost:9200/_aliases?pretty=true -k -u [user:password]

La console nous renvoie les index créés, et nous constatons bien que nos rapports sont présents
dans la base de données ElasticSearch. Il nous reste à configurer l’interface sur laquelle consulter nos
données.

Page 22 sur 43
 6.3.6. Affichage des données – Kibana
Kibana semble le choix le plus approprié pour l’affichage des données d’ElasticSearch, et ce sur
plusieurs points :

• Sa compatibilité native avec ElasticSearch

• Son interface web, facilitant grandement l’accessibilité des données (nécessitant donc qu’un
navigateur)
• Son puissant système de filtrage des données

Toujours avec les dépôts officiels, l’installation de Kibana s’auto configure pour un accès à l’interface
web en http sur le port 5601, en localhost uniquement. Permettre la connexion à l’interface depuis le
réseau local nécessite d’éditer le fichier de configuration kibana.yml pour modifier le paramètre
server.host, le passant de localhost à 0.0.0.0 pour le faire écouter sur toutes ses interfaces réseaux.

Son interconnexion avec la base de données se fait grâce à un token de sécurité que l’on peut
générer avec une commande ElasticSearch :

$ bin/elasticsearch-create-enrollment-token -s kibana

Cette commande permet la configuration automatique de Kibana pour joindre la base de données
ElasticSearch. Une fois fait, nous pouvons nous connecter à l’interface web avec le super utilisateur
automatiquement créé par ElasticSearch lors de son installation.

Les index sont déjà visibles dans le menu Analytics -> Discover après création de la Data View
rapport_*, permettant de visualiser tous les index dont le nom commence par rapport_.

Page 23 sur 43
 A gauche, nous trouvons le nom des champs définis dans notre filtre grok ; et, au centre, les
différents rapports d’inventaire des serveurs collectés. En cliquant sur l’un d’eux, nous avons une
vision détaillée de l’index et de toutes les données récupérées.

Ces données, peu exploitables, peuvent l’être via la création de Dashboards pour une visualisation
simplifiée des informations, dans le menu Analytics -> Dashboard.

Voici la première version du dashboard permettant la visualisation de l’inventaire des serveurs :

Page 24 sur 43
En cliquant sur les différents éléments, nous pouvons affiner notre recherche. Dans l’exemple ci-
dessous, je choisis d’afficher uniquement les serveurs Linux 5.8 avec le port Telnet en écoute :

Cette fonction nous permet de cibler les services présentant des problématiques de sécurité et de
connaître l’étendue des serveurs clients sur lesquels déployer des solutions.

Ainsi, nous avons mis en place l’interface permettant de visualiser l’ensemble des inventaires
effectués sur les serveurs, de manière claire et centralisée.

6.3.7. Sécurisation des outils

Maintenant que nous avons une suite d’outils fonctionnels, nous devons nous assurer de la
sécurisation et du respect des bonnes pratiques pour chacun des outils.

Logstash
Parce que l’environnement est en phase de test, j’utilisais la commande Logstash démarrant
l’analyse des fichiers en tant que root. Plus tard, la commande sera invoquée automatiquement et
exécutée en tant que l’utilisateur Logstash. Pour cela, j’ajuste dans un premier temps les droits de
sécurité sur le répertoire de configuration Logstash.
$ chown -R root:logstash /etc/logstash
$ chmod -R 640 /etc/logstash

Les dossiers de l’arborescence /etc/logstash doivent également avoir les droits d’exécution, sans
quoi l’utilisateur Logstash ne pourra pas accéder aux fichiers enfants.
$ find /etc/logstash -type d | xargs chmod 750

Ainsi, seul root et logstash ont les droits de lecture sur ces fichiers de configuration contenant des
informations de configurations sensibles. Et ces fichiers ne sont modifiables que par root.

ElasticSearch recommande la copie du certificat de sécurité dans un répertoire accessible

uniquement par Logstash. Je crée donc un dossier certs dans le répertoire /etc/logstash afin d’y
stocker mon certificat.

$ mkdir /etc/logstash/certs
$ cp /etc/elasticsearch/certs/http_ca.crt /etc/logstash/certs/http_ca.crt

Page 25 sur 43
 Nous éditons ensuite le fichier de configuration inventaire.conf, dans la section Output, pour
redéfinir l’emplacement du certificat.

Le fichier inventaire.conf contient également l’utilisateur et le mot de passe super-utilisateur elastic,

utilisés pour créer les index de nos inventaires. ElasticSearch recommande la création d’utilisateurs
et de rôles avec les droits associés.

Dans un premier temps, nous créons un rôle logstash_writer avec les droits suivants :

Puis nous créons un utilisateur logstash_internal et l’attribuons au groupe logstash_writer.

Page 26 sur 43
Nous éditons enfin le fichier inventaire.conf pour utiliser les identifiants logstash_internal.

Nous ajustons également les droits des fichiers logs contenus dans /var/log/logstash/. En effectuant
les tests de configuration en tant que root, des fichiers non modifiables par logstash ont été créés,
l’empêchant ainsi de journaliser son activité.

$ chown -R logstash:root /var/log/logstash

Nous pouvons finalement constater le bon fonctionnement de Logstash en appelant la commande

avec l’utilisateur correspondant :

$ sudo -u logstash bin/logstash -f /etc/logstash/conf.d/inventaire.conf --

path.settings /etc/logstash/

Maintenant que notre commande fonctionne, il faut qu’elle soit en constante écoute des fichiers
entrants. Nous l’inscrivons alors en tant que service. De cette manière, la commande pourra être
exécutée au démarrage du système et contrôlée via systemctl.

$ vi /etc/systemd/system/inventaireMistral.service

L’inventaire Mistral peut maintenant être démarré et arrêté via systemctl.

$ systemctl daemon-reload
$ systemctl start inventaireMistral.service
$ systemctl status inventaireMistral.service

Page 27 sur 43
$ systemctl stop inventaireMistral.service

Nous l’ajoutons alors au démarrage du système.

$ systemctl enable inventaireMistral.service

Logstash est maintenant conforme aux bonnes pratiques systèmes et celles conseillées par
ElasticSearch.

ElasticSearch
Comme dit plus haut, ElasticSearch est installé et autoconfiguré de manière sécurisée.
Conformément à leurs recommandations : l’authentification est activée de sorte à ce que seuls les
utilisateurs autorisés et authentifiés puissent accéder à la base de données et la connexion se fait en
SSL vérifiée par un certificat de sécurité.

L’outil est également livré avec un module de sécurité, activé et fonctionnel par défaut, que nous
avons déjà utilisé pour gérer les rôles et les utilisateurs.

Nous pouvons nous assurer de son bon fonctionnement avec Curl, via la commande suivante :

$ curl -XGET https://localhost:9200/_xpack/usage?fileter_path=security -k

-u user:password

Aucune modification n’étant nécessaire car répondant déjà aux bonnes pratiques de sécurité, nous
pouvons alors sécuriser Kibana.

Page 28 sur 43
 Kibana
Une problématique majeure de sécurité dans la configuration de Kibana est son accès autoconfiguré
en http, contrairement à ElasticSearch. La première étape est donc de configurer l’utilisation du
protocole HTTPS pour chiffrer les données entre le navigateur et l’interface web.

Pour cela, nous générons un certificat grâce à l’outil intégré dans l’installation d’ElasticSearch.

$ bin/elasticsearch-certutil cert -name kibana

Cette commande génère une archive kibana contenant deux fichiers dont un certificat en .crt et une
clé privée en .key

Ces fichiers, une fois extraits, sont déplacés dans un sous répertoire de /etc/kibana afin d’en garantir
l’accès à l’utilisateur kibana uniquement.

$ tar -xvf kibana

$ mv kibana/* /etc/kibana/ca/
$ chmod 640 /etc/kibana/ca/*

Une fois fait, nous configurons le fichier kibana.yml pour activer la connexion https.

Ainsi, nous avons accès à l’interface web de manière sécurisée après redémarrage du service kibana.
L’outil est configuré de telle sorte à ce que les requêtes http soient redirigées automatiquement sur
du https.

$ systemctl restart kibana

Ceci étant fait, une bonne pratique serait la création de groupes permettant uniquement la lecture
des index d’inventaire rapport_*. Comme La plupart des utilisateurs auront accès de manière
consultative à la plateforme, leur administration en sera beaucoup plus simple.

Pour cela, nous créons un espace Consultation dont nous restreignons la visibilité simplement aux
index et aux dashboards.

Page 29 sur 43
Nous créons ensuite le rôle inventaire_viewer avec des droits de lectures sur les index commençant
par rapport_.

Comme il s’agit, avec ce groupe, d’accéder à Kibana, nous éditons également les accès associés en
autorisant l’accès aux index et aux dashboards.

Enfin, nous créons un utilisateur muni du rôle inventaire_viewer pour nous connecter à l’interface.

Page 30 sur 43
On constate dans le menu sur la gauche que seuls les menus autorisés en lecture sont accessibles, et
que les données sont consultables sans pouvoir être modifiées.

De cette manière, nous pourrons créer les rôles de lecture et d’écriture pour chaque partie de
l’interface, et en attribuer les droits aux utilisateurs définis.

Enfin, il reste à définir le paramètre de l’URL sur laquelle les utilisateurs finaux se connectent. Ce
paramètre server.publicBaseUrl se définit dans le fichier kibana.yml.

La sécurisation et l’introduction aux bonnes pratiques de Kibana clôture donc la partie de

sécurisation des outils installés, et permet une mise en production des outils de manière sécurisée.

6.4. Suite du projet

En mettant en place cette solution d’inventaire et de traitement des données, j’ouvre la possibilité
d’inventorier en masse les infrastructures clientes. Cependant, mon année d’alternance se termine
avant de pouvoir poursuivre le projet. Voici ce qui est envisagé pour la suite de mon parcours à
Mistral :

La réflexion doit toujours être ouverte sur l’ajout d’informations à inventorier. Nous avons pensé au
nombre de disques installés et leur taux d’occupation, ainsi qu’à des données applicatives spécifiques
à Mistral.

Un outil de déploiement doit être mis en place pour déployer massivement le script d’inventaire.
L’outil Ansible étant connu de l’entreprise, nous nous orientons déjà sur cette solution. Mais cette
mise en place dépend de plusieurs critères :

Déploiement de
l'inventaire (Ansible)

Mise en place d'une Réflexion sur la

Restructuration du plateforme de méthode de collecte
DNS de l'entreprise collecte de des données par
l'inventaire Logstash

Page 31 sur 43
 6.4.1. Restructuration du DNS de l’entreprise
Pour qu’Ansible fonctionne correctement et de manière organisée, nous devons restructurer le DNS
de l’entreprise pour avoir une liste de clients à jour. La connexion chez les clients se fait trop souvent
par adresse IP, par habitude et du fait que le DNS n’est pas toujours maintenu. Remettre le DNS à
jour nous permettrait de limiter les erreurs de connexion lors d’un déploiement.

Plusieurs pistes sont envisagées pour la restructuration du DNS, la plus convaincante étant de lier les
adresses IP au numéro de client interne à Mistral, et de créer des alias pour les différents noms que
peuvent prendre les clients. De cette façon, nous aurions une manière pratique pour les équipes de
joindre les serveurs des clients (via leur nom), et une manière infaillible pour Ansible d’effectuer son
déploiement (via le numéro de client).

6.4.2. Mise en place d’une plateforme de collecte de l’inventaire

Pour le moment, l’inventaire s’exécute sur le serveur et en ressort un fichier contenu dans le
répertoire /tmp/, ce qui n’en facilite pas la collecte. Il a été envisagé de mettre en place une
plateforme accessible via internet pour que le script envoie directement son inventaire sur un
équipement où l’accès nous serait facilité et les fichiers centralisés. Cette étape du projet est
toujours en réflexion.

6.4.3. Réflexion sur la méthode de collecte des données par Logstash

L’analyse de données dans un répertoire interne du serveur Logstash était la manière la plus simple
de traiter un flux important d’informations dans un cadre de test, et non de production. Comme
nous ne savons toujours pas précisément comment et où les données seront disponibles au
traitement, nous devons toujours définir la solution la plus appropriée pour que Logstash collecte les
inventaires.

Page 32 sur 43
7. Projet en entreprise – Analyse des rapports DMARC
La mise en place d’un serveur ElasticSearch et Kibana ouvrait des possibilités d’analyse de données
pour lesquelles nous n’avions pour le moment pas de solution de traitement. Parmi elles, nous
recevons régulièrement des rapports DMARC au format XML, difficilement lisibles tels quels.

7.1. Contexte
DMARC est une technologie venant se compléter à deux autres, SPF et DKIM, pour prouver
l’authenticité d’un mail délivré par le domaine qu’il protège.

• SPF (Sender Policy Framework) agit comme processus d’identification, par la déclaration
d’adresse IP publique autorisées à envoyer des mails.
• DKIM (DomainKeys Identified Mail) permet d’assurer, par chiffrement asymétrique,
l’intégrité du mail, de son contenu comme de son en-tête, et vérifie la légitimité de
l’expéditeur.
• DMARC s’appuie sur les vérifications SPF et DKIM afin d’appliquer des règles de traitement
des emails. Suivant la politique établie et les résultats, les emails pourront être envoyés,
placés en quarantaine ou rejetés.

Son fonctionnement peut être schématisé comme suit :

Il s’agit donc d’une mesure de sécurité pouvant prévenir l’envoi de mails indésirables en nom et
place d’un domaine de messagerie.

La mise en place de ce service s’accompagne de rapports DMARC envoyés par les hébergeurs de
messagerie, tels que Google ou Outlook, rapportant toutes les informations des tentatives de mails
expédiés avec le domaine de la société. Ces rapports sont envoyés sur la boîte mail de mon chef de
service pour une consultation manuelle.

7.2. Expression des besoins

Maintenant que nous disposions d’une plateforme d’analyse et de traitements des données, la
présence de rapports DMARC fut l’occasion de tester sa flexibilité. Il m’a alors été confié de faciliter
la visualisation de ces rapports de manière centralisée et automatique, en tirant profit de
l’installation d’ElasticSearch et de Kibana.

Page 33 sur 43
7.3. Schéma directeur
La partie traitement et visualisation des données étant déjà en place, j’ai défini le schéma directeur
suivant :

• Plutôt que de recevoir les mails dans une boîte aux lettres
utilisateurs, la création d'une adresse dédiées sur laquelle stocker
Rassembler la réception des rapports DMARC semblait plus approprié.

• L'objectif étant de trouver une solution de collecte de ces

rapports reçus par mail dans le but de les envoyés à
Collecter ElasticSearch.

• Une fois les données traitées, il s'agit de les visualiser sur notre
interface Kibana.
Visualiser

7.3.1. Rassembler les rapports – Création d’une boîte aux lettres dédiées
Cette étape, peut-être anodine au premier abord, est importante car il s’agit du point de départ
pour la collecte des rapports.

Nous créons alors une boîte mail dédiée, et reparamétrons les enregistrements DNS de notre
domaine pour y ajouter la boîte mail en tant que destinataire des rapports. Ces rapports arriveront
alors dans la boîte de réception. Nous créons un dossier processed dans lequel les rapports traités
devront être déplacés, de manière à garder une trace des rapports tels que nous les recevons.

Page 34 sur 43
 7.3.2. Collecter les données – ParseDMARC
ParseDMARC est un outil OpenSource développé en Python, dont les fonctionnalités permettent la
connexion en IMAP sur une boîte mail et la récupération des pièces jointes XML. Cet outil est
particulièrement efficace car il est également en capacité de traiter les rapports compressés, comme
cela peut être le cas selon l’hébergeur de mail expédiant le rapport.

Une fois les données traitées, il est en capacité de les envoyer à d’autres outils, comme par exemple
à une instance ElasticSearch.

S’exécutant sur une machine Linux, je décide de le rajouter sur le serveur ElasticSearch déjà en
place. Une fois installé via python3, ParseDMARC fonctionne via une ligne de commande appelant un
fichier de configuration.

$ parsedmarc -c [fichier de configuration]

Ce fichier comporte l’ensemble de la configuration permettant :

• La connexion IMAP au serveur de messagerie

• Les paramètres de traitement des mails
• La connexion à ElasticSearch pour l’envoi des données

Nous créons ce fichier et le formatons comme ci-dessous :

$ vi ./parsedmarc.ini

Le champ [general] définit les serveurs DNS ainsi que le traitement des rapports aggregate et
forensic. Le premier est un rapport journalier contenant les tentatives d’envois de mails et leurs
informations, comme par exemple leurs adresses IP sources. Le second est un rapport plus détaillé
dans le cas de refus d’envoi car les challenges SPF et DKIM ont échoué.

Le champ [imap] contient les informations de connexion au serveur de messagerie pour accéder à la
boîte aux lettres dédiée.

Page 35 sur 43
 Le champ [mailbox] paramètre le dossier de la boîte mail à scanner, et le dossier de réception des
mails traités. Il s’agit donc respectivement de la boîte de réception et du dossier processed créé plus
tôt.

Enfin, le champ [elasticsearch] indique la base de données ElasticSearch à contacter pour l’envoi des
données.

Nous pouvons constater le bon fonctionnement de notre fichier de configuration en exécutant la

commande parsedmarc :

$ parsedmarc -c ./parsedmarc.ini

Une fois en cours d’exécution, son bon fonctionnement se constate en vérifiant le point d’entrée et
de sortie, avec, d’une part, la boîte mail dont la boîte de réception s’est vidée pour les répartir dans
les différents dossiers créés par ParseDMARC -

- et de l’autre, je constate la création d’index dans la base de données ElasticSearch via la commande
Curl.

Ces index se trouvent également sur l’interface web de Kibana, après la création d’une data view
visualisant les index dont le nom commence par dmarc_.

Page 36 sur 43
 Une des fonctionnalités de ParseDMARC permet la géolocalisation des adresses IP source des
tentatives d’envoi de mails. Cette fonctionnalité s’appuie sur la base de données GeoIP, que j’installe
également sur le serveur. Disponible gratuitement à des fins d’utilisation non commerciale, son bon
fonctionnement peut se constater en appelant la version de l’outil.
$ geoipupdate -V

La mise à jour de la base de données s’effectue via une tâche dans le cron de l’utilisateur root,
conformément à la documentation.

Constatant le bon fonctionnement de ParseDMARC et de ses prérequis, il s’agit maintenant

d’exploiter les données à travers Kibana.

Page 37 sur 43
 7.3.3. Visualiser les rapports DMARC – Kibana
Pouvant visualiser les données dans le menu Analytics, nous pouvons directement passer à l’étape
de la création de Dashboard, dont voici un aperçu pertinent.

7.3.4. Sécurisation de l’outil

Maintenant que l’outil est fonctionnel, nous pouvons sécuriser ParseDMARC contenant, lui aussi,
des informations sensibles.

Dans un premier temps, nous créons un utilisateur système dédié à l’exécution des commandes
parsedmarc.
$ useradd parsedmarc -r -s /bin/false

En ajoutant les commandes -r et -s, nous spécifions qu’il s’agit d’un utilisateur système et qu’il ne
dispose pas de shell. Ainsi, nous ne pouvons pas nous connecter avec le compte de cet utilisateur. Il
ne servira qu’à exécuter les commandes parsedmarc.

Les fichiers de configuration ParseDMARC se trouvent dans le répertoire /etc/, dans lequel nous
créons le dossier dédié avec les bonnes autorisations.

$ mkdir /etc/parsedmarc
$ chown root:parsedmarc /etc/parsedmarc
$ chmod 750 /etc/parsedmarc

Page 38 sur 43
Ce dossier accueillera notre fichier parsedmarc.ini auquel nous attribuons les bonnes autorisations.

$ mv ./parsedmarc.ini /etc/parsedmarc/
$ chown root:parsedmarc /etc/parsedmarc/parsedmarc.ini
$ chmod 640 /etc/parsedmarc/parsedmarc.ini

De cette manière, seuls les utilisateurs root et parsedmarc ont accès au fichier, et il n’est modifiable
que par root.

Se connectant à ElasticSearch, ParseDMARC a aussi besoin du certificat de chiffrement pour

permettre la connexion SSL. Nous créons donc un emplacement dans son répertoire.
$ mkdir /etc/parsedmarc/certs
$ chown root:parsedmarc /etc/parsedmarc/certs
$ chmod 640 /etc/parsedmarc/certs

Nous copions le certificat d’ElasticSearch et lui attribuons les bons droits.

$ cp /etc/elasticsearch/certs/http_ca.crt /etc/parsedmarc/certs/http_ca.crt

$ chown root:parsedmarc /etc/parsedmarc/certs/http_ca.crt

$ chmod 640 /etc/parsedmarc/certs/http_ca.crt

Nous pouvons alors modifier l’emplacement du certificat dans le fichier parsedmarc.ini

Enfin, nous administrons les rôles et utilisateurs ElasticSearch via l’interface Kibana, dans le but de
dédier la création des index à un utilisateur créé spécifiquement. Nous créons un rôle
parsedmarc_writer permettant la création d’index dmarc_* avec les paramètres ci-dessous :

Et nous créons un utilisateur membre du rôle nouvellement créé.

Page 39 sur 43
 Ces configurations nécessitent la mise à jour du fichier parsedmarc.ini, en modifiant l’emplacement
du certificat ainsi que l’utilisateur et le mot de passe utilisés pour la connexion. Ensuite, nous testons
le fonctionnement de l’outil en l’appelant en tant que l’utilisateur parsedmarc.

$ sudo -u parsedmarc /usr/local/bin/parsedmarc -c /etc/parsedmarc/parsedmarc.ini

Une fois le bon fonctionnement de l’outil constaté, on peut inscrire la commande en tant que
service pour qu’elle soit appelée au démarrage du système, et contrôlée via systemctl.

$ vi /etc/systemd/system/parsedmarc.service

Dont le bon fonctionnement se constate de nouveau via systemctl.

La création d’un utilisateur via l’interface Kibana dédié à la consultation de l’inventaire ponctue la
partie de la sécurisation de l’outil ParseDMARC. Nous ajoutons un rôle dmarc_viewer associé à
l’espace Consultation déjà existant, copié sur le rôle inventaire_viewer (en adaptant cependant les
index consultables).

Page 40 sur 43
De cette manière, nous avons un rôle permettant d’autoriser l’accès à la consultation des rapports
DMARC.

Page 41 sur 43
8. Conclusion
Au travers la mise en place de ces différents outils travaillant les uns avec les autres, j’ai mis en place
une plateforme de consultation des données centralisées et sécurisées, traitant et rendant
disponible de manière automatique les fichiers d’inventaires déposés au sein du serveur.

Ce projet a été un travail de recherche et d’expérimentation. Partant de rien, j’ai dû appréhender et

expérimenter le fonctionnement de chaque outil afin d’en adapter chaque configuration.

Le script d’inventaire a été un challenge, me heurtant aux commandes non compatibles d’un
système à l’autre, ou la différence de fonctionnement des systèmes d’exploitation me contraignant
de prévoir de multiples scénarios. Ce script a dû être réécrit et adapté plusieurs fois pour formater
correctement la sortie en fonction de l’outil prévu pour le traitement des données. Avant de parler
de Logstash, le script formatait sa sortie en CSV, puis en XML. Finalement, une ligne par serveur avec
les informations voulues a été la meilleure manière de permettre l’intégration des données via
Logstash.

Une fois Logstash choisi, l’utilisation d’ElasticSearch et de Kibana a été plus évidente. La difficulté
résidait dans la configuration du filtre Grok et les paramètres optionnels, nécessitant une mise en
forme stricte sur les espacements entre chaque paramètres présents ou non présents.

Concernant ParseDMARC, le travail de recherches a été d’autant plus important, ne connaissant le

concept d’authentification DMARC que de nom. J’ai dû me renseigner sur le fonctionnement du
processus afin d’en cibler les enjeux. Ce n’est qu’après avoir compris le fonctionnement de ces
technologies que j’ai pu cibler mes recherches afin de trouver un outil adapté pour le traitement de
ces rapports.

Ayant déjà expérimenté l’installation de la suite ELK en formation, j’ai pu étendre mes connaissances
sur les outils, après leur installation et leur interconnexion, en les sécurisant et m’initiant aux bonnes
pratiques de sécurité et d’utilisation. Il ne s’agissait plus de rendre l’interface fonctionnelle en vue
d’une utilisation hypothétique, mais de la rendre exploitable dans un environnement professionnel
de production et de répondre à un cahier des charges. La présentation de cet outil à l’équipe devait
démontrer d’un fonctionnement concret et convaincre de sa pertinence.

Cela m’a permis d’approcher une méthode de travail complétement différente de celle vue jusqu’à
présent en formation. Après trois ans d’expérience professionnelle, ce fut mon premier pilotage de
projets aussi conséquent en autonomie. L’objectif principal étant d’inventorier le parc client, j’avais
carte blanche sur les solutions utilisées (pour peu que je réponde aux contraintes techniques et
budgétaires). Ayant non seulement apporté une réponse aux objectifs, j’ai mis à disposition pour
l’entreprise un nouvel outil de traitement des données qui est aujourd’hui déjà envisagé pour être
utilisé au travers d’autres projets, comme ça a été le cas avec l’analyse des rapports DMARC.

D’un point de vue plus personnel, ces projets m’ont permis de gagner en assurance et en
autonomie, de par les responsabilités qui m’ont été confiées. J’ai pu mettre à profit l’essentiel de
mes connaissances en systèmes et en sécurité pour mettre en place des plateformes sécurisées
répondant à des besoins spécifiques. Le bon déroulé de ces projets m’a fait prendre conscience de
mes capacités professionnelles.

Cette expérience a été, pour moi, une motivation supplémentaire à poursuivre dans le métier
d’Administrateur Systèmes et Réseaux.

Page 42 sur 43
9. Annexe – Script d’inventaire

Page 43 sur 43
Script d’inventaire du parc client
# Exécution du script en mode silencieux
exec 2>/dev/null

# Définition des variables

# La variable ficInventaire dépend du nom d'hôte de la machine ainsi que la date d'exécution du script
tempDir=/tmp/inventaireMistral
tempData=$tempDir/data
ficInventaire=/tmp/inventaire-`hostname`-`date "+%Y_%m_%d"`.inv

# Suppression des fichiers créés par une éventuelle exécution antérieure du script
rm -rf $tempDir $ficInventaire

# Création des répertoires temporaires

mkdir $tempDir $tempData

## FONCTIONS

# endFunc est utile afin de formatter le fichier différemment sans le modifier entièrement
_endFunc() {
printf ' ' >> $ficInventaire
}

# Fonction localisant le service entré ($1), selon si l'OS est de type Linux ou UNIX
_whereis() {
if [ "$OSTYPE" = "linux-gnu" ] ; then
_location=$(whereis $1 | awk -F' ' '{print $2}')
else
type $1 | awk -F' ' '{print $3}' > $tempData/tmpwhereis
_location=$(cat $tempData/tmpwhereis)
fi
if [ "$_location" = "" ] ; then
_location="introuvable"
else
break
fi
echo "$_location" | tr -d "\n"
}

# Nom d'hôte de la machine formatté en minuscule

_getHostname() {
hostname | tr -d "\n" | tr '[:upper:]' '[:lower:]' >> $ficInventaire
_endFunc
}

# Système d'exploitation, Linux ou UNIX

_getOs() {
if [ "$OSTYPE" = "linux-gnu" ] ; then
printf "Linux" >> $ficInventaire
else
printf "AIX" >> $ficInventaire
fi
_endFunc
}

# Version de l'OS
_getOsVersion() {
if [ "$OSTYPE" = "linux-gnu" ] ; then
cat /etc/redhat-release | awk -F'release ' '{print $2}' | tr '(' '#' | awk -F' #' '{print $1}' | tr -d "\n"
>> $ficInventaire
else
oslevel | tr -d "\n" >> $ficInventaire
fi
_endFunc
}

# Récupération des adresses IP de la machine, suivant le type d'OS

_getIpAddress() {
if [ "$OSTYPE" = "linux-gnu" ] ; then
ip a | awk -F'inet ' '{print $2}' | awk -F' ' '{print $1}' | sed '/^$/d' | awk -F'/' '{print $1}' | grep -wv
"127.0.0.1" > $tempData/tempIp
else
 ifconfig -a | awk -F'inet ' '{print $2}' | awk -F' netmask' '{print $1}' | grep -wv "127.0.0.1" | sed '/^$/d'
> $tempData/tempIp
fi
for i in 1 2 3 ; do
cat $tempData/tempIp | awk "NR==$i" | tr -d "\n" >> $ficInventaire
printf ' ' >> $ficInventaire
done
}

# Version en cours d'exécution d'AcuShare

_getAcushareVersion() {
_acushareLocation=$(ps -ef |grep acushare | grep -wv grep | awk -F'/usr/' '{print $2}' | awk -F'/' '{print $1}')
/usr/$_acushareLocation/bin/acushare -v | awk -F'version ' '{print $2}' | awk -F' ' '{print $1}' | sed '/^$/d' |
tr -d "\n" >> $ficInventaire
_endFunc
}

# Récupération des versions de SMB, GhostScript et PsUtil, en prévoyant le cas de figure où ceux-ci ne seraient pas
installés sur la machine
_getSmbdVersion() {
_smbdLocation=$(_whereis smbd)
if [ "$_smbdLocation" = "introuvable" ] ; then
printf 'introuvable' >> $ficInventaire
else
$_smbdLocation --version | awk '{print $2}' | tr -d "\n" >> $ficInventaire
fi
_endFunc
}

_getGsVersion() {
_gsLocation=$(_whereis gs)
if [ "$_gsLocation" = "introuvable" ] ; then
printf 'introuvable' >> $ficInventaire
else
$_gsLocation -v | awk 'NR==1{print $3}' | tr -d "\n" >> $ficInventaire
fi
_endFunc
}

_getPsselectVersion() {
_psSelectLocation=$(_whereis psselect)
if [ "$_psSelectLocation" = "introuvable" ] ; then
printf 'introuvable' >> $ficInventaire
else
$_psSelectLocation -v 2>$tempData/psselect
head -1 $tempData/psselect | awk '{print $3,$5}' | tr " " "." | tr -d "\n" >> $ficInventaire
fi
_endFunc
}

_getSshVersion() {
ssh -V 2>$tempData/sshV
head -1 $tempData/sshV | awk -F, '{print $1}' | awk -F_ '{print $2}' | tr -d "\n" >> $ficInventaire
_endFunc
}

_getSslVersion() {
ssh -V 2>$tempData/sshV
head -1 $tempData/sshV | awk '{print $3}' | tr -d "\n" >> $ficInventaire
_endFunc
}

# Vérification des ports d'écoute FTP, SSH et Telnet

_getFtpStatus() {
if [ "$OSTYPE" = "linux-gnu" ] ; then
_isFTP=$(netstat -an | grep :21 | grep LISTEN | awk 'NR==1{print $6}')";"
else
_isFTP=$(netstat -an | grep *.21 | awk 'NR==1{print$6}')";"
fi
if [ $_isFTP == 'LISTEN;' ] ; then
printf "true" >> $ficInventaire
else
printf "false" >> $ficInventaire
fi
_endFunc
}
_getSshStatus() {
if [ "$OSTYPE" = "linux-gnu" ] ; then
_isSSH=$(netstat -an | grep :22 | grep LISTEN | awk 'NR==1{print $6}')";"
else
_isSSH=$(netstat -an | grep *.22 | awk 'NR==1{print$6}')";"
fi
if [ $_isSSH == 'LISTEN;' ] ; then
printf "true" >> $ficInventaire
else
printf "false" >> $ficInventaire
fi
_endFunc
}

_getTelnetStatus () {
if [ "$OSTYPE" = "linux-gnu" ] ; then
_isTelnet=$(netstat -an | grep :23 | grep LISTEN | awk 'NR==1{print $6}')";"
else
_isTelnet=$(netstat -an | grep *.23 | awk 'NR==1{print$6}')";"
fi
if [ $_isTelnet == 'LISTEN;' ] ; then
printf "true" >> $ficInventaire
else
printf "false" >> $ficInventaire
fi
_endFunc
}

# APPEL DES FONCTIONS

_getHostname
_getOs
_getOsVersion
_getIpAddress
_getAcushareVersion
_getSmbdVersion
_getGsVersion
_getPsselectVersion
_getSshVersion
_getSslVersion
_getFtpStatus
_getSshStatus
_getTelnetStatus

echo "end" >> $ficInventaire

# Suppression des répertoires temporaires

rm -rf $tempDir