COMPTE RENDU DES TRAVAUX

PRATIQUES :
JANWOUO PATRICK, ENSPT MASTER2 SERES

I. OpenSSL usage des outils cryptographiques

L’objectif de ce TP est d’implémenter une infrastructure de gestion des clefs (PKI : Public
Key Infrastructure) en utilisant les outils fournis par OpenSSL.

Partie A : Mise en place de l’autorité de certification (CA)

1. Création du dossier /root/enspt_pki qui sera notre dossier dans lequel sera déployée
notre PKI.

2. Edition du fichier /etc/pki/tls/openssl.cnf

3. Modification de ce fichier pour configurer les chemins d’accès aux répertoires et
fichiers nécessaires au déploiement de la PKI. On précise aussi certaines valeurs qui
seront utilisées. Une partie du fichier est présentée ci-dessous :
 4. Création de tous les répertoires configurés dans le fichier openssl.cnf (certs,
newcerts, private, crl).

5. Création du fichier serial qui contient le prochain numéro de série qui sera utilisé pour
un certificat et le fichier index.txt qui contiendra la liste des certificats crées. Ces deux
fichiers sont dans le répertoire /root/enspt_pki. On initialise le fichier serial avec le
numéro 01 qui sera utilisé pour le premier certificat.

Partie B : Génération du certificat auto-signé de l’autorité de certification

1. Génération de la paire de clefs (publique et privée) RSA de l’autorité de certification

avec la commande :

openssl genrsa –des3 –out ensptcakey.pem 2048

openssl genrsa : Création de la paire de clefs RSA

-des3 : Précise l’algorithme utilisé pour chiffrer la paire de clef générée.

-out : Précise le fichier qui contiendra la paire de clef.

2048 : Précise la taille des clefs générée.

Le fichier ensptcakey.pem doit se trouver dans le répertoire /root/private. On

remarque un mot de passe nous est demandé pour la génération de la clef DES3 pour
 le chiffrement de la paire de clef générée. Ce mot de passe sera utilisé à chaque fois
que l’autorité de certification voudra utiliser sa clef privée pour une opération.

2. Affichage de la clef privée RSA de l’autorité de certification depuis le répertoire

/root/enspt_pki/private avec la commande :

openssl rsa –in ensptcakey.pem

Une partie du résultat est présentée ci-dessous :

3. Génération du certificat X509. Pour générer le certificat, il faut d’abord générer une
requête en direction de l’autorité d’enregistrement qui vérifie la requête. Dans notre cas
cette autorité est aussi l’autorité de certification. Nous allons donc générer et signer le
 certificat pour l’autorité racine. La commande utilisée depuis le répertoire
/root/enspt_pki/private est :
openssl req –new –X509 –days 1825 –key ensptcakey.pem –out ../ensptcacert.pem

Le certificat ensptcacert.pem doit être dans le répertoire /root/enspt_pki.

-new combiné avec -X509 : Permet de spécifier qu’il n’y aura pas de requête, un
certificat auto-signé sera généré.

-days : Précise le nombre de jour de validité du certificat.

-key : Pointe sur la paire de clef RSA à associer au certificat.

Partie C : Génération des certificats client

1. Génération du certificat d’un client A.

a. D’abord, génération de la paire de clef RSA du client A de taille 1024 toujours
dans le répertoire /root/enspt_pki/private et dans le fichier clientAkey.pem
avec la commande :
openssl genrsa –des3 –out clientAkey.pem 1024

Un mot de passe est aussi demandé pour générer la clef de chiffrement DES3
pour protéger la paire de clef RSA générée.

b. Ensuite, génération de la requête d’obtention du certificat dans le fichier

clientAreq.pem en destination de l’autorité d’enregistrement avec la
commande :
openssl req –new –key clientAkey.pem –out clientAreq.pem
 Ci-dessous le contenu du fichier clientAreq.pem

c. Génération du certificat du client A par l’autorité de certification (= autorité

d’enregistrement dans notre cas) en utilisant sa requête (clientAreq.pem),
toujours depuis le répertoire /root/enspt_pki/private et avec pour résultat le
fichier clientAcert.pem qu’on stockera dans le répertoire
/root/enspt_pki/certs avec la commande :
openssl ca –in clientAreq.pem –out ../certs/clientAcert.pem
Un aperçu du certificat généré est présenté ci-dessous :

d. Utilisation de la commande openssl pkcs12 pour exporter le certificat au format

PKCS12. Le résultat sera dans le fichier clientA.p12 dans le répertoire certs
openssl pkcs12 –export –in ../certs/clientAcert.pem –inkey
../private/clientAkey.pem –out ../certs/clientA.p12
 2. On effectue les mêmes étapes pour le client B

Partie D : Chiffrement et déchiffrement

Notre répertoire de travail ici est le répertoire /root/enspt_pki/works

1. Vérifier la validité du certificat du client B. Avec la commande :

openssl verify -CAfile ../ensptcacert.pem ../certs/clientB.cert.pem
Le résultat montre bien que le certificat est valide comme ci dessous

2. Chiffrement d’un fichier file1.txt.

Le chiffrement se fera par le client A pour être destiné au client B. La commande

utilisée est :
openssl rsautl –encrypt –in file1.txt –inkey ../certs/clientBcert.pem –out
file1crypted.txt
On précise ici le fichier correspondant au certificat contenant la clef publique du client
A. Ci-dessous la commande et le contenu du fichier contenant le résultat du
chiffrement. file1crypted.txt

3. Le déchiffrement du fichier file1crypted.txt dans le fichier file1decrypted.txt avec la

commande suivante :
 openssl rsautl –decrypt –in file1cryped.txt –inkey ../private/clientBkey.pem –out
file1decrypted.txt

Partie E : Signature
Nous allons ici générer la signature du fichier file1.txt par le client B. Pour cela nous
avons 2 étapes
1. Génération du hash du fichier grâce à la commande openssl dgst comme suit :
openssl dgst –MD5 –out file1hash.txt file1.txt
Ci-dessous le résultat de la commande

2. La deuxième étape consiste à générer la signature finale en utilisant la commande

openssl rautl –sign –in file1hash.txt –inkey ../private/clientBkey.pem –out
file1seigned.txt
Le résultat est le suivant :

3. Vérification de la signature. Cette vérification se fait en utilisant le certificat du client

B car c’est lui qui a signé le fichier file1.txt en file1signed.txt. La commande est la
suivante :
openssl rsautl –verify –in file1signed –certin –inkey ../certs/clientBcert.pem –out
file1verified.txt
Ci-dessous, le résultat de la vérification ainsi que sa comparaison avec le fichier
correspondant au hashage du fichier à signer.
 On remaque que la commande openssl rsautl –sign applique juste un chiffrement sur le
l’empreinte passée en paramètre et que la commande openssl rsautl –verify déchiffre
l’empreinte chifffrée

II. INVESTIGATION SUR DES DONNEES

CACHEES
L’objectif du TP est de récupérer des informations dissimulées dans la copie image d’une
disquette. L’image de la disquette est dans un fichier image.zip

1. Vérification de l’intégrité du fichier image.zip. L’empreinte du fichier original se

trouve dans le fichier MD5.txt qui a été générée avec l’algorithme MD5. Pour vérifier
on calcule l’empreinte du fichier image.zip et on compare avec le contenu du fichier
MD5.txt

2. Décompression de du fichier image.zip

 Après décompression remarque que le fichier est de type disquette de 1440Ko
3. Montage de l’image en lecture seule pour éviter qu’on la modifie et protéger son
intégrité afin que l’investigation ne soit pas biaisée.

4. Le contenue de la disquette montée

L’image de la disquette contient deux fichiers. Un fichier dont le nom contient des
espaces (cover\ page.jpgc\ \ \ \ \ \ \ \ \ \ \) et dont l’affichage est impossible avec la
commande cat à cause d’un problème d’entrée/sortie. On suppose ici qu’il y a un
problème au niveau des blocs du fichier en question. On affiche également du contenu
du deuxième fichier schedu~1.exe toujours avec la commande cat
 En utilisant la commande strings sur schedu~1.exe on obtient :

On peut supposer ici que ce fichier est un tableau Excel à cause de la première ligne du
résultat de la commande
5. Installation de sleuthkit et autopsy.
a. Sleuthkit est un une librairie et une collection de commandes et d’outils
permettant de faire l’investigation des systèmes de fichier des disques. Pour son
installation on le décompresse et on suit les indications du fichier INSTALL.txt
b. Autopsy est une interface graphique qui permet d’interfacer sleuthkit. Pour
l’installer on le décompresse et on lit le contenu du fichier README.txt pour
l’installer.
6. Lancement d’autopsy, avec la commande ./autopsy dans son répertoire d’installation
 Ensuite on copie l’URL généré dans le navigateur pour lancer l’interface graphique
d’autopsy. On obtient la page suivante

On clique sur « New Case » et on configure notre environnement d’investigation étape

par étape de la création d’une machine à l’importation de notre fichier image. Avant
d’importer le fichier image on doit démonter l’image.
7. En analysant l’image à travers autopsy on obtient trois fichiers comme présenté sur
l’image ci-dessous. Les fichiers dont le nom commence par le caractère ‘$’ représente
les données du système de fichier de la disquette.
8. Le premier fichier a pour nom cover page.jpgc. D’après le système de fichier un seul
secteur est occupé le secteur 451. Cela est anormal car la taille du fichier nous montre
que le nombre de secteur est de 15585/512 soit 31 secteur. Pour rendre ce fichier
inaccessible le fichier 451 a été marqué comme dernier secteur du fichier et rend
impossible l’accès aux secteurs suivants.

9. Le second fichier est Jimmy Jungle.doc. Le type de fichier correspond bien avec son
extension. Le nombre de fichier occupé par le fichier est de 40 ce qui coïncide car la
taille du fichier est de 20480 et 20480/512 = 40. Pour le rendre illisible il a été
supprimé de la disquette avant la récupération cette dernière.

10. Le troisième fichier Scheduled Visitets.exe. Son extension ne correspond pas au type
de fichier car il est de type archive (.zip). Le nombre de secteur occupé par le fichier
est de 2, le secteur 104 et 105. La taille du fichier est de 1000 ce qui correspond bien à
2 secteurs.

11. Récupération des fichiers :

Premier fichier : En cliquant sur « image details » on constate qu’il y a 31 secteurs
successifs qui constituent un fichier et dont la fin est bien marquée par EOF(End Of
File). Cette taille correspond au nombre de secteur du fichier cover page.jpgc. On
suppose que ces blocs correspondent à ce fichier. On affiche son contenu caractère par
caractère en ASCII.
On constate bien que le fichier est une image grâce à la signature JFIF. On exporte alors
le fichier et on le visualise avec l’outil GIMP

Deuxième fichier : Le fichier Jimmy Jungle.doc bien que effacé avec tous ces secteurs
marqués comme non alloués, a encore son contenu intact. Par chance tous les secteurs
sont consécutifs, ce qui facilite sa récupération. On clique dans l’option « Data Unit »,
le premier secteur est le secteur 33 et le nombre de secteur est 40. On affiche le contenu
caractères par caractères on constate qu’il s’agit d’une lettre qu’on exporte. Dans ce TP
on a eu à exporter et à modifier son extension en .doc pour pouvoir voir son contenu.
Cette lettre nous informe que le dernier fichier contient un tableau et est protégé par un
mot de passe qui se trouve dans le fichier envoyé précédemment. En effet à envoyer le
fichier image donc, c’est dans ce dernier que se trouve le mot de passe. Après examen
de manière graphique avec GIMP on ne voit pas de mot de passe. On décide d’afficher
le contenu du fichier image caractères par caractères avec la commande « strings ».

On voit ici à la dernière ligne une information qui ressemble à un mot de passe :
pw=goodtimes

Troisième fichier : Le fichier Scheduled Visitets.exe a deux secteur et correspond à

un fichier archive. Malheureusement après exportation il y a erreur et de plus, le fichier
semble incomplet. En revenant au niveau de « image details », on constate qu’il y a un
fichier avec des secteurs consécutifs qui vont du secteur 104 à 108. Les secteurs du
fichier quant à eux sont le secteur 104 et 105. On peut supposer que les secteurs
manquant sont ceux allant de 106 à 108. En considérant ainsi on exporte donc ce
contenu. Il s’agit d’un fichier archive et après décompression avec le mot de passe
touvé plus haut, on obtient le fichier Scheduled Vitits.xls.
12. Le fournisseur de Joe Jacob est Jimmy Jungle et son adresse est 626 Jungle Ave Apt
2. L’information cruciale véhiculée dans le fichier image est le mot de passe nécessaire
à l’ouverture du fichier contenant la liste des lycées dans lesquels Joe Jacob a vendu la
drogue. Les autres lycées fréquentés par Joe Jacob sont Key High School, Leetch
High, Birard High School, Richter High School et Hull High School.

13. Savoir avec quel logiciel a été créee l’image. L’image a été créée dans windows, nous
allons créer une image vide et afficher son contenu caractères par caractères en ASCII
pour essayer d’identifier une signature. Puis chercher cette signature dans le fichier
image envoyé par Jacob. On commence avec le logiciel Paint de windows, pour une
image vide on obtient :

On remarque la signature ci-dessus du fichier crée avec Paint. Cette signature se

retrouve aussi dans le fichier image envoyé par Jacob :

Donc l’image a été créée avec le logiciel Paint de windows.

 III. FILTRAGE DU TRAFIC RESEAU EN
UTILISANT IPTABLES
L’objectif de ce TP est :
 d’implémenter une politique de sécurité pour l’accès à un serveur ou
l’émission des requêtes depuis ce dernier en configurant des règles de filtrages
sur un firewall
 Créer des scénarios pour tester la configuration du firewall
 Capturer et analyser les paquets dans le réseau
 Comprendre et conduire des de scans pour tester le firewall.

1. Vérifions que iptables est configuré sur notre système avec la commande :
service iptables status

On voit bien ici en vert que le service iptables est actif.

2. Vérification des règles appliquées dans notre firewall avec la commande :

iptables –L

On voit qu’aucune règle n’est appliquée dans notre firewall et que la politique par
défaut est de tout accepter (policy ACCEPT)

3. Démarrage du service ssh avec la commande :

service sshd start
4. Démarrer le service telnet. Pour cela on édite le fichier /etc/xinetd.d/telnet en
modifiant la valeur de l’option Disable à no. En effet telnet est un service managé par
un autre service xinetd. Les fichiers de configuration des services qu’il manage se
trouvent dans le répertoire /etc/xinetd.d/, on modifie alors le fichier telnet dans ce
répertoire pour préciser que si le service xinetd est lancé alors le service telnet ne
reste pas inactif et se lance aussi (Disable = no).

Ensuite on relance le service xinetd et on vérifie qu’il est actif

5. On supprime toutes les règles avec la commande : iptables –F

6. Pour la première connexion avec Putty on nous demande d’enregistrer une clef de
connexion avec le serveur distant si on a confiance en ce dernier. Avec ssh la
connexion réussit :

De même avec telnet la connexion réussit :

7. Avec la commande netstat –lt on affiche la liste des ports TCP ouvert.

On remarque ainsi que les ports 110, 20 et 21 ne sont pas ouvert. Donc les services
pop3 et ftp sont inactifs.

8. On utilise la commande nslookup www.wikipedia.com pour obtenir l’adresse IP

correspondant à wikipédia.
 Après configuration des règles dans le firewall on obtient le résultat suivant :

Ici nous n’avons pas pu accéder à Wikipédia. Nous avons plutôt déployé le serveur
web apache sur le main host(Windows) en écoute sur le port 80. C’est sur ce serveur
que nous avons permit l’accès.

9. Test de configuration :
En utilisant la commande lynx pour accéder à la page web du serveur apache de la
main host (Windows).
10. Sauvegarde du fichier de configuration avec la commande :
iptables-save > /etc/lab-rules

11. Arrêter le service iptables et affichage des règles de filtrages.

12. Principe du TCP SYN SCAN : On envoie un SYN

 Si le port est ouvert, on reçoit un SYN/ACK et on ferme la connexion avec un
RST
 Si le port est fermé, on reçoit un RST/ACK
Principe du TCP XMAS SCAN : on envoie SYN, PUSH, URG
 Si le port est ouvert, on ne reçoit rien
 Si le port est fermé, on reçoit un RST

13. Résultat du scan des scans:

Scanned Port State deduced using SYN SCAN State deduced using XMAS SCAN
21 RST/ACK(fermé) RST(fermé)
22 SYN(ouvert) ouvert|filtré
23 SYN/ACK(ouvert) ouvert|filtré
110 RST/ACK(fermé) RST(fermé)

14. Utilisation de l’outil nmap pour effectuer une attaque de scans de port :
nmap –sS –p 21, 22, 23 192.168.84.128 (attaque SYN SCAN)
 nmap –sX –p 21, 22, 23 192.168.84.128 (attaque XMAS SCAN)

On constate que les résultats coïncident avec ceux de la question précédente.

15. Redémarrage du service iptables et chargement des règles.

16. Après réactivation du firewall on obtient les résultats suivant :
nmap –sS –p 21, 22, 23 192.168.84.128 (attaque SYN SCAN)

nmap –sX –p 21, 22, 23 192.168.84.128 (attaque XMAS SCAN)

 Soit en récapitulatif :
Scanned Port State deduced using SYN SCAN State deduced using XMAS SCAN
21 filtré filtré|ouvert
22 filtré filtré|ouvert
23 ouvert filtré|ouvert
110 fermé filtré|ouvert

17. Modification du fichier de configuration en remplaçant DROP par REJECT

18. Rechargement du fichier de configuration

19. En modifiant dans les règles par DROP par REJECT on obtient les résultats suivants :

nmap –sX –p 21, 22, 23 192.168.84.128 (attaque XMAS SCAN)

nmap –sX –p 21, 22, 23 192.168.84.128 (attaque XMAS SCAN)

Soit en récapitulatif le tableau suivant :
Scanned Port State deduced using SYN SCAN State deduced using XMAS SCAN
21 filtré filtré
22 filtré filtré
23 ouvert filtré|ouvert
110 fermé filtré|ouvert