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