Version du 23 octobre 2018 à 18:12

Présentation générale

L'objectif du projet est de réaliser un tableau de bord affichant l'état des serveurs physiques et virtuels de la plateforme informatique.

Description

L'idée pour la réalisation du projet est de remonter l'état des machines physiques et virtuelles sur un serveur virtuel de supervision, serveur sur lequel on va trouver les applications web permettant la génération du tableau de bord ainsi que la gestion des tâches de sauvegarde des machines virtuelles.

Objectifs

Le projet s'articule autour de ces deux principaux objectifs:

• Créer un serveur de supervision fonctionnel.
• Mettre en place une solution pour la gestion automatique des sauvegardes des machines virtuelles.

Préparation du projet

Architecture en salle serveur

Cahier des charges

Le système doit rapporter les points suivants :

• état de santé des machines physiques : température, état des disques, ...
• occupation des machines physiques : utilisation CPU, utilisation espace disque, utilisation mémoire
• état de santé des connexions réseau : réseau Renater, réseau ADSL, réseau SDSL
• état de santé des machines virtuelles : temps d\'exécution de chaque machine virtuelle
• occupation des machines virtuelles : utilisation disque et mémoire
• état de certaines applications critiques :
  • date de validité des clefs DNSSEC
  • dates des dernières sauvegardes des machines virtuelles
• vérification des certificats https de sites web.
• affichage de la température en salle serveur

En plus de cela, un système de sauvegarde automatique

Choix techniques : matériel et logiciel

Pour la réalisation du serveur de supervision, mon choix s'est tourné vers une solution déjà existante: Nagios Core. En plus d'être facile à mettre en place, Nagios possède l'avantage de posséder les plugins nécessaire au monitoring des machines virtuelles XenServeur.

A cela, on peut aussi ajouter une communauté active mettant à disposition des plugins et addons sur la plateforme communautaire nagios exchange.

Une comparaison avec la solution zabbix pourra éventuellement être effectué.

La surveillance des hôtes ainsi que des machines virtuelles sera assuré grâce à un applicatif déployé sur les hôtes nommé NRPE:

Cet agent permet de faire remonter à notre serveurs serveurs de monitoring (ici notre serveur nagios) le résultat de scripts lancé directement sur les hôtes.

Liste des tâches à effectuer

• Dans un premier temps, il sera nécessaire de réaliser une phase de test sur les machines projet en salle E306, L'idée sera de monitorer un PC depuis un autre PC.
• La deuxième étape consistera à installer la machine virtuelle et à mettre en place le serveur de supervision affichant l'état des machines physiques et virtuelles ainsi que des réseaux (réseau Renater, réseau ADSL, réseau SDSL) et effectuant la vérification des certificats https.
• La troisième partie du projet sera consacré l'automatisation des tâches de sauvegardes des VMs.
• Une fois cela fait, il faudra se concentrer sur la vérification des clefs DNSSEC.
• Il a prévu par la suite de mettre en place un système de surveillance de température en salle serveur.
• Toute autre tâche priorisé par Mr Redon et/ou Mr Vantroys.

Calendrier prévisionnel

Septembre:

• Un serveur de supervision fonctionnel avec AU MOINS une partie des valeurs à monitorer.

Octobre:

• Idéalement, avoir toutes valeurs à monitorer.
• commencer à mettre en place les tâches de sauvegarde.

Novembre:

• Avoir un serveur de supervision fonctionnel à 100 % avec toutes les valeurs à surveiller.
• Idéalement, avoir des tâches de sauvegarde fonctionnelles.
• Commencer à travailler sur la vérification des clefs DNSSEC.

Décembre:

• Serveur de supervision et tâches de sauvegarde fonctionnelles à 100%.
• Vérification des clefs DNSSEC en partie fonctionnelle.

Réalisation du Projet

Semaine 0

Durant cette semaine, 12h ont été consacré:

• A de la documentation pour le choix de la solution à utiliser.
• Réalisation de test sur les machines en salle E306.
• Début de l'installation et/ou de la modification de plugins à utiliser avec NRPE pour monitorer certaines valeurs (Température).

Tests réalisé sur zabeth13 en surveillant zabeth15:

Semaine 1

Les tests ayant été concluants voir (semaine 0), l'objectif pour cette semaine fut de mettre en place la supervision sur le serveur de sauvegarde baleine.

Résumé du travail effectué

Lundi matin (4h):

• Rédaction du wiki
• Installation de nagios sur la VM de supervision "supervise"
• Installation de NRPE sur baleine
• Premier tests des plugins:
  • check_load : test la surcharge du serveur.
  • check_mem : retourne la quantité de mémoire et SwAP disponible sur le serveur
  • check_disk : retourne la quantité d'espace de stockage disponible

Jeudi (8h):

• Mise en place d'un plugin vérification de température du processeur
• Création d'un plugin de vérification d'état de santé des disques

Vendredi (8h):

• Mise en place d'un plugin de vérification de l'état des VMs
• Résolution de problèmes pour NRPE (accès/droit des utilisateurs pour l’exécution de certain scripts)

Problèmes rencontrés et résolution

Des problèmes ont été rencontré lors de la mise en place des plugin de vérification d'état des disques et des VMs. Ces derniers furent lié à un souci de droit d'accès de certains plugins lancé par NRPE.

L'erreur s'est manifesté de la manière suivante: Le lancement d'une commande shell via un script(plugin) par NRPE s'est faite sans erreur mais avec aucun output.

Pour régler le problème, il a été nécessaire de donner à NRPE les même droits que le root pour l’exécution de certains plugins en suivant les étapes indiqué dans ce guide:

• Installation de sudo
• Ajout des lignes suivantes au fichier /etc/sudoers avec visudo:

Defaults: nagios !requiretty
nagios    ALL=(root)  NOPASSWD: /usr/local/nagios/libexec/check_xenvm
nagios    ALL=(root)  NOPASSWD: /usr/local/nagios/libexec/smart_check_disks.sh 

NB: Cette configuration peut être dangereuse est sera modifié par la suite.

• Dans le fichier de configuation /usr/local/nagios/etc/nrpe.cfg:

command[check_xenvm]=/usr/bin/sudo /usr/lib/nagios/plugins/check_xenvmm -w 1 -c 2
command[check_smartN]=/usr/bin/sudo /usr/lib/nagios/plugins/check_smartN N

Déploiement NRPE & Configuration de Nagios

Idée générale

La mise en place de la surveillance d'un serveur (physique comme virtuel) se fait en deux temps:

• Installation et configuration de NRPE sur le serveur distant à surveiller.
• Configuration de Nagios sur le serveur de supervision.

Configuration de Nagios

La configuration de Nagios se fait de manière assez simple par la modification des fichiers de configuration présent dans le répertoire /usr/local/nagios/etc/.

L'arborescence dans ce répertoire se présente comme suit:

|-- cgi.cfg                    Config de l'application web de nagios 
|-- htpasswd.users             Contient les identifiants pour la connexion à l'application web, ici: nagiosadmin:1234 
|-- nagios.cfg                 Fichier de configuration de Nagios    
|-- resource.cfg               Définition de chemin pour l'accès aux scripts lancé par Nagios    
|-- objects                    Dossier contenant les fichier de configuration relatifs aux services et hôtes   
|    |-- commands.cfg          Fichier de configuration des commandes pouvant être lancé par Nagios
|    |-- contacts.cfg          Configuration des contacts à avertir en cas de problème 
|    |-- localhost.cfg         Configuration de la supervision du serveur hôte Nagios 
|    |-- printer.cfg           Définition des imprimantes hôtes à superviser 
|    |-- switch.cfg            Définition des switchs hôtes à superviser 
|    |-- templates.cfg         Fichier contenant des templates de base pour la définition d'hôtes ou de services   
|    |-- timeperiods.cfg       Définition des configs de temps 
|    |-- windows.cfg           Exemple d'un fichier de configuration pour une machine Windows 
|-- servers                    Dossier contenant les fichier de configuration servant à la définition des hôtes à monitorer et des services à executer   
|    |-- baleine.cfg           Définitions pour l'hôte baleine    
|    |-- vmBaleine.cfg         Définitions pour les VMs se trouvant sur baleine    

Afin se surveiller une donnée, il est nécessaire de définir deux principaux élément:

• Un hôte à surveiller.
• Un servir à mettre en place.

La définition de ces objets se fait au moyen de macros dans des fichier de configuration (.cfg), situés dans un répertoire dédié: /usr/local/nagios/etc/servers.

Les définitions ci-dessous se situent dans le fichier /usr/local/nagios/etc/servers/baleine.cfg et permettent de monitorer le niveau de charge du serveur baleine:

On définie un hôte en lui attribuant une adresse:

define host 
      use linux-box 
      host_name baleine.insecserv.deule.net{ 
      alias Serveur de sauvegarde Baleine 
      address 172.26.64.15 
}

Et on met en place un service sur cet hôte:

define service{ 
     use generic-service 
     host_name baleine.insecserv.deule.net 
     service_description Current Load 
     check_command check_nrpe!check_load 
}

On peut voir dans la définition du service ci-dessus que Nagios exécute la commande check_nrpe, laquel prend en paramètre "check_load"

La définition de la commande check_nrpe est faite dans le fichier de configuration /usr/local/nagios/etc/objects/commands.cfg:

define command{ 
     command_name check_nrpe 
     command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ 
}

La commande check_nrpe va ensuite faire un appel au daemon nrpe executé sur la machine distante à monitorer.

Installation & Configuration de NRPE

L'installation de NRPE sur le serveur distant à monitorer s'est fait en suivant ce guide.

NRPE doit ensuite se paramétrer en modifiant le fichier /usr/local/nagios/etc/nrpe.cfg:

Serveurs autorisés à communiquer avec nrpe:

 allowed_hosts=127.0.0.1,172.26.64.13

Permet de demander à NRPE de lancer des commande avec des arguments

 dont_blame_nrme=1

Définition des commandes à lancer:

# Le script /usr/local/nagios/libexec/check_load est lancé lorsque NRPE reçoit check_load: 
command[check_load]=/usr/local/nagios/libexec/check_load -r -w .15,.10,.05 -c .30,.25,.20
...

Semaine 2

Résumé du travail effectué

Lundi(4h)

• Résolution de problèmes lié à l’exécution de quelques scripts (problème d'affichage de la température, de l'état des disques)
• Rédaction du wiki

Mercredi(4h)

• Installation d'une VM de test: vmtest
• Mise en place de nrpe sur la VM de test
• Tests des plugins sur la VM

Jeudi(4h)

• Premiers tests effectué pour la vérification des connexions ADSL, SDSL et Renater.

Semaine 3

Résumé du travail effectué

Lundi (4h)

• Premiers test réalisés sur une VM "stargate", possédant 3 interfaces reliés aux réseaux ADSL, SDSL et Renater

Mercredi(4h)

• Continuation tests sur la VM "stargate"

Jeudi(4h)

• Résolution de problème liés à la VM stargate (problème DNS).
• Début Documentation DNSSEC.

Semaine 4

Résumé du travail effectué

La semaine à entièrement été déduite à de la documentation à propos du protocole DNSSEC et à des recherches en vue de récupérer les dates de validité des certificats DNSSEC. A l'issue de la semaine, aucune solution n'a été trouvé pour trouver la date de validité des clefs KSK et ZSK.

Le protocole DNSSEC

Cette semaine fut pour moi l'occasion d'étudier en détail le fonctionnement du protocole DNSSEC ainsi que des différentes signatures qui y sont associées.

Fonctionnement général

Schéma d'une attaque type "man in the middle"

Fonctionnement du DNSSEC

DNSSEC est une amélioration du DNS permettant de sécuriser la communication entre un résolveur et un utilisateur. Ce protocole à été mis en place après la découverte de failles de sécurité lors de l’utilisation du DNS, lequel s'est avéré très vulnérable aux attaques DDOS ou de type "man in the middle". Il était en effet possible pour une personne malveillante d'intercepter les requêtes envoyés par des clients au serveur DNS et de répondre à la place de celui-ci, facilitant ainsi les technique de phishing.

Afin d’empêcher ce type de pratique, DNSSEC se base sur un modèle de cryptographie à clé publique. On va donc retrouver, entre le résolveur et le client, un serveur d'autorité dont le rôle va être de signer les réponses aux requêtes envoyés au serveur DNS avec une clé privé.

Les enregistrements signés par le serveur autorité sont ensuite groupé par type en RRSET.

Parmi les enregistrements propre au DNS, on retrouve notamment ces derniers:

* A       Renvoie une adresse IPv4 pour un nom de host donné.
* AAAA    Retourne une adresse IPv6 pour un nom de domaine donné.
* NS      Délègue la gestion d'une zone à un serveur de nom faisant autorité 
* SOA     Définit le serveur maitre du domaine. 
* MX      Définit le nom du serveur de courrier du domaine 
* CNAME   Permet de réaliser un alias (un raccourci) d'un host vers un autre.
...
liste complète des enregistrements DNS

A cela, on peut ajouter les enregistrements DNSSEC permettant de faciliter la validation des signatures par le client et par le serveur autorité:

* DNSSEC  Contient les clés publiques KSK et ZSK
* RRSIG   Contient les signatures des enregistrements
* NSEC    Contient la liste des enregistrements qui existent pour un domaine, utilisé notamment comme preuve de non existence (dans le cas d'une résolution impossible).
* DS      Contient des informations (Nom et clé publique) sur les zones fille du domaine concerné (ce qui permet d'établir une chaine de confiance et donc de réduire le nombre d'appel au serveur DNS).

Tests

Afin de récupérer les dates de validité des clefs ZSK et KSK, plusieurs tests ont été effectués grâce à l'utilisation de dig, un outil permettant d’interroger un serveur DNS. Les tests ont été effectué depuis une VM routé ne passant par le proxy, sur les domaines suivants:

• plil.fr
• ns.plil.fr
• dnssec-tools.org

Tester la connexion au serveur DNS

La commande dig plil.fr +dnssec permet de vérifier si les enregistrements obtenus en interrogeant le serveur DNS sont signés avec DNSSEC:

; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30025                 // Aucune erreur retourné 
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr. IN A
 
;; ANSWER SECTION:
plil.fr. 18696 IN A 193.48.57.52                                          // Adresse IP du domaine 
 
;; Query time: 6 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:17:09 DST 2018
;; MSG SIZE rcvd: 52

Récupérer la liste des signatures obtenues

Il est possible de récupérer la liste des enregistrements qui existent pour le domaine plil.fr grâce à cette commande: dig plil.fr NSEC +multi:

; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr NSEC +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr.               IN NSEC

;; ANSWER SECTION:
plil.fr.                259200 IN NSEC archives.plil.fr. A NS SOA AAAA RRSIG NSEC DNSKEY    // Enregistrements obtenus
 
;; Query time: 19 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:41:46 DST 2018
;; MSG SIZE  rcvd: 75

Récupération des clés publiques KSK et ZSK

Cette commande permet de récupérer les clefs publiques ZSK et KSK pour un domaine: dig plil.fr DNSKEY +multi:

; <<>> DiG 9.10.3-P4-Debian <<>> plil.fr DNSKEY +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57848
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;plil.fr.               IN DNSKEY
 
;; ANSWER SECTION:
plil.fr.                259200 IN DNSKEY 256 3 5 (
                                AwEAAcBspyK0pCevwfGt3wmU97YaOBlXhbcAxBE3tPy4
                                nGSBxFAs01WF0WUd3lgho3nXnwMXUI/KSp9nDdSLTgKe
                                H8u/IKMumUOQcggfh4UYZ2CzzycWzZ2gqBo531yI2GRZ
                                VSqdXH+jqeoVteJSH3cxEOAL0gT8yitN+RWIXumh/IId
                                ) ; ZSK; alg = RSASHA1; key id = 51828
plil.fr.                259200 IN DNSKEY 257 3 5 (
                                AwEAAaZre4ATp9W0nATXk5/nKW8unbLBOCSqpog/yYC0
                                2Y+3hUo8xrdM/OjvGNAJEpr46fp+4q10bN2SBBwNv8o6
                                cfZddEDei1HLsdJYukuLFK+EjYyboqD+fZtkgqyYFlHb
                                ltwZCpnEmfDcp+dcoTMvLwXpM1ZEyBIYJF0LBr4Na0lb
                                HNaAHrUJnMLZVLUDlA4U4rU/AZtbyJC/avdqEsjUC1w+
                                8+yY+o4j4sR3P9+iavb67XFi+Ta0fh6dQSH325drPX+T
                                CgXPUTGWjxbKJfJ0gTjrr5BYL6eEm80SC+OOdSdAEWHA
                                7QrrvO8kwYQdCzTKdbN1EZ4G5XdVo/dPtPLnlDc=
                                ) ; KSK; alg = RSASHA1; key id = 40768
 
;; Query time: 41 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Tue Oct 23 18:46:42 DST 2018
;; MSG SIZE  rcvd: 460

En plus des clés publiques, on récupère aussi les informations suivantes:

• ID de la clé
• Type d'algorithme

Récupération des enregistrements signés

Les tests suivants ont été réalisé sur le domaine suivants: dnssec-tools.org, en raison du plus grand nombre de signature obtenues.

On récupère les ID des clefs publiques KSK et ZSK dig dnssec-tools.org DNSKEY +multi:

;; ANSWER SECTION:
dnssec-tools.org.       300 IN DNSKEY 256 3 5 (
                                AwEAAfDcFXK9ef/BppquoTm7LSk2rIE5x9LPu+WplVEA
                                To9i7OhqxxPy6K6uIomxLNtZAlcDbUybQEeopWhglovk
                                odkvRY72q6ZUxW1vwzBAvmDLZ7dfTjPa0LYKVQ7qsf7Q
                                jFBiyPkWARSAHH2xqBATry25ft8j9O9ULX4/DYdYPq9D
                                ) ; ZSK; alg = RSASHA1; key id = 3147
dnssec-tools.org.       300 IN DNSKEY 256 3 5 (
                                AwEAAde0IFUPiuDwEQM8vGlR436nb+TzGLlMWxzMmWDP
                                mHfWMPv8OXgZafScErgijGRnwPfv+t9irTUsX4dkvJie
                                vkV549mtDwhXLb9Vyg9C5JsoqOBq//QJvZXEZHtcHPoQ
                                9tIGVt8W9uctLUKMsAdAVaozfMxl8CuLWjqkL2Gq57HP
                                ) ; ZSK; alg = RSASHA1; key id = 19221
dnssec-tools.org.       300 IN DNSKEY 257 3 5 (
                                AwEAAazJbvxfEciFb3LmGsddun82dGsrZj4YpCvn8qHI
                                KRQ2c0Hra0LnfhOK09YKG7B9eey3aWzOKWUa50fv/0sl
                                8npI7/5tgWCQFBpIdqcDxoJxtvtFlrUlOpRQz45aFE3x
                                FJoquCfPGYgaNSZu5VGED4qAsZqxGXLvDU8SDX76Eo3G
                                oLBqYJGXG0inRVAQViFNk9ovtA2kZSP4oHTsWBCcnKDx
                                8CRZhF9jrbplzUdW7ahbTRaYv6tPYaKd7nzvH8GksO9b
                                9t5EJ1o1BhL6cDOHXOrkL+Twhc1Mwg5jBhYWH6r1LaTX
                                w2NQN1hAQzGrAZPt13kP0KQp/ybGhoKtunLxVsFiiDb6
                                4HQs+cRiw2wSf/vYaNVAiYesrMHTpq5BLeWTVrMLk2Kt
                                NtQMV972pOKipT9UN7At7Sugdpbm1g7jQ8G3eKP6iRg5
                                YA0PjbuXFNYjmKG9fMTjQGgs5IHbDVe/W3mPHYS+1970
                                AmNX/momejvYG8NlQykZdrcqPUw5dSAOmUnbehl3wzJJ
                                HIR59FaxeG9bO8vrFBlaRapz1eMtrZbqkYV7P8PnUP/3
                                i7WVGZO5AJxPpxpHaSNbd63d575pQKMQxEU7dPPfQsq8
                                wnNxcCHDixb6EetVcfv9Id9up4v9t0O33O4562kN2S9/
                                cwPOOlnobJ/g597cU2sF5Pmxn+r7
                                ) ; KSK; alg = RSASHA1; key id = 34816

On remarque la présence de plusieurs clés ZSK. Ce type de clé est en effet destiné à être remplacé régulièrement (tous les 30 jours max), le rollover de la clé se fait alors progressivement et on se retrouve en général avec deux clés d'un même type. Dans ce cas, le serveur autorité valide les enregistrement signés avec les deux clés le temps du rollover.

Les enregistrements signés peuvent ensuite être obtenus avec la commande suivante: dig dnssec-tools.org RRSIG +multi:

 ; <<>> DiG 9.10.3-P4-Debian <<>> dnssec-tools.org RRSIG +multi
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5112
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ;; QUESTION SECTION:
 ;dnssec-tools.org.      IN RRSIG
  
 ;; ANSWER SECTION:
 dnssec-tools.org.       300 IN RRSIG DNSKEY 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.   // Signature de la clé ZSK utilisé 
                                 SRwNkxRrulP6wjFaCSKC/6ZWV9vidak3h3wqXKk9MjrH
                                 jCByL8dbqdpMWDBpnjGxgf2y7NLYhriYkvgQJJIAnwDT
                                 PJFUNGSV+2Houradlnjz4IMC7T5XQGFlvPiCQ00SF/zq
                                 k7sDKNl+umgDkKE1vYcg2VbmI1RSUsDD0tXlgb8= )
 dnssec-tools.org.       300 IN RRSIG DNSKEY 5 2 300 (
                                 20181117051029 20181018041029 34816 dnssec-tools.org.  // Signature de la clé KSK utilisé
                                 OUj7q7m78jdXacfB7rMGlFSIYkD1bb25TNpXc0UBbSMn
                                 El65gff8CZNWR26NWfYbD0ZwSpzO0ifDbQWB9PXyGoev
                                  F91+cmOm4WZfAEGrwxthEyIrcsdOlv8SbArnwJR64XmN
                                 CXNAzHSx+6YVuuP3QD+ZKNCVbyAbItbiagDhNAOmwidv
                                 g0MWz2oTiJOg3TfywcKef3nuBv2U95xvvLktOEY7hUUX
                                 Jlx9hM/s4F/CNlY0yZLMArrM75SlHGyvtG4q03HRlohZ
                                 cf5VhqaIeMkjjYul33Dtt5GKzq9uDi/8Ov6saFyPHTrU
                                 6SU1a75wZSKiWiA8W6xDhV+2gc9JmG4KfNbfsNWR5rZD
                                 64CQ4/6r1FKB/XGveIJ4xFamJ43qBBZRQfSEzE5uLHZw
                                 D1FZk3EcgeEhoBYeZzGTW4SWYCG/tXLdFilMYxvJA4Uh
                                 oEryW68AfIUpBnvCkwuVakvoKarxMIb1xusKtBMZNTrR
                                 oFyjn1oUgNpujUXAAEwy2zMRNMlWOffDw2HC5MXBxqzx
                                 Bu6lGY/D8hvFiZIg2QvjNKMAEsUDoBJsgxW9yonymIzb
                                 yJdn9bcD5X5JFzmBtBlqGZnkZkTgarhFg7Oc1Lhj+tqE
                                  MBxpYXHb4YAG4oghAg65u0XGnIoc4wQd9/E/U9nDPtaA
                                 M9S9rauoI0GKKdPf5kZB51c= )
 dnssec-tools.org.       300 IN RRSIG TXT 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 JT6HieOWWKoWniaePFwMWERiXWmHTLA/njxRUbJmYC25
                                 L0YWYpiS1SEuRxwHIrgILyWAgE5t02T8XMZCyM108VE4
                                 Ahu7WKxUMegWUe+UkUwWsSAi42XNT6q+j2biGi8zDUbF
                                 zJpK0qIzZCbMAdzLu4WZpdMx8LjTcXOnkBJWFbA= )
 dnssec-tools.org.       300 IN RRSIG MX 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 zvX7zsWg2wow08/cGjqysRChZnk9vOXCjaWylUAoJZsZ
                                 6lTKXL0Y1HCnqXJe9z/xjFwt8eIjnRDCucqoYeRegxBC
                                 QG8WX5aaDAZQuRSGNUc/qgf2+hE/GxHTn4hbaBJj5hCb
                                 DeX8/qo+ynUg3OVbU8h1ynjmr4u+20cypzo4Gxs= )
 dnssec-tools.org.       300 IN RRSIG A 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 2M4jkmtd9y2e+mRWeNqvunL5DjSV/Z3fUOx4uiWbCdNQ
                                 PpF2PfMq9iEngbEQvBD+m0BZl/RswbUnAoiTeGX7/Xt0
                                 e0KgG8v+4uyKVKfHfntK3YdBgaWL/ySWLHoCz3ISE37/
                                 B1Z4jhoGOBo4J2xUqGl3A99OlDv+ublcCC3aEBY= )
 dnssec-tools.org.       300 IN RRSIG NS 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 aZY3ax6C/C34VD204K1Y0wTmDKxQ/XK4prJE13VRO/+L
                                 nNgGGPwUMhnSjkKS3QHX8g447K7ERO49PLtEeJndgDJI
                                 28nac6Fcx9wmlaxKpy+VGkAS/t/MYlzkFBdZvZKvuE+p
                                 eWcIvHBpn8NGXI1KAU2tVKTGxvimMHxdznP69gM= )
 dnssec-tools.org.       300 IN RRSIG SOA 5 2 300 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 HZEcgLM4CWBHtwi5huuGrq7iF+Ek5HMu6Y8K1d+Rv0tD
                                 h1Qv9o/zzl7dLm7rKDHUv0uHo6gxgvRWYrE5a0ZHDZdI
                                 QHcMIXh64dhQ6tqqEAbeaXaHPCz7Nb0lRkqzQS5JTbrf
                                 1P43r84bTGxsBPvhxDDs0Ul9MAboCsYcoTstUDo= )
 dnssec-tools.org.       10800 IN RRSIG NSEC 5 2 10800 (
                                 20181117051029 20181018041029 3147 dnssec-tools.org.
                                 aDMGZpsKlyxTA3tHGnpCUfsKWtkFxzac6LzhxJNtn1Oy
                                 5uNyZDdv0s0uSrb1H+E9te7DW7Czadl74Y5iUNnwjw+s
                                 6EODP1LRJcnlFkatlwnKPjtTxB3VWldle8fwl/LPmnUg
                                 ioO0b/SVcjfRx/j7wqnZhvqWhRops2sKjMmIwbE= )
 dnssec-tools.org.       81812 IN RRSIG DS 7 2 86400 (
                                 20181107152349 20181017142349 1862 org.
                                 bod0E+AePe5i0M7eXJe994yyvohhh4BzpHiIkqgB6SGY
                                 IMY7w0imjfqqlBnwoIeFkBVmMRpZF7izWwUAr19tK5Bs
                                 0qcn/ZZdWJTBWCaeG5Hp8s85O85InMUMpI557A/MKOLu
                                 ipuxBVFei+vyuMhlb37TBMtc/IpU8SoBYDRyIpk= )
 
 ;; Query time: 1111 msec
 ;; SERVER: 192.168.1.254#53(192.168.1.254)
 ;; WHEN: Tue Oct 23 19:07:31 DST 2018
 ;; MSG SIZE  rcvd: 2000

On retrouve les signature des clés KSK et ZSK obtenus précédemment grâce à leurs ID. On récupère aussi les dates de validités de leurs signatures:

• 2018/11/17 - 05:10:29 pour la clé ZSK
• 2018/11/17 - 05:10:29 pour la clé KSK

Semaine 5

Résumé du travail effectué

Lundi (4h)

• Suite à une discussion avec le tuteur de projet, il a finalement été déterminé que la date de validité à récupérer est celle de la signature DNSKEY des clés ZSK et KSK.
• Documentation concernant les méthodes permettant de sauvegarder les machines virtuelles.

Mercredi(4h)

• Rédaction d'un script permettant de retourner la date de validité des signature DNSKEY des clés KSK et ZSK.
• Mise en place d'un script permettant de vérifier la validité des certificats https.

Jeudi(4h)

• Travail sur la VM stargate, afin de vérifier l'état des réseaux ADSL, SDSL et Renater.
• Mise en place de politiques de routages afin de router alternativement chacune des interfaces et de les tester.

Documents Rendus