TP sysres IMA5 2022/2023 G5
Sommaire
- 1 Installation de l'OS
- 2 Ansible
- 3 Réalisation
- 4 Séance 7 (dernière séance)
- 5 Coffre Fort
Installation de l'OS
Devuan Chimaera (netinstall) sur les zabeth 17 et 11
Configuration réseau
- IP machine : 172.26.145.50+n°zabeth/24
- DNS : 193.48.57.48
- Domain name : plil.info
- Routeur : 172.26.145.254
- Proxy : http://proxy.polyetch-lille.fr:3128
- mdp dio5 : XXXXXX
Ansible
Prérequis:
- python
- pip
- ansible
Rédaction du script ansible pour le Screen Saver (.yml)
Tâches accomplies :
- Suppression des animations de veille d'écran
Tâches restantes :
- Fixer une animation lente pour la veille
- Eteindre complétement l'écran au bout d'un certain temps (1 heure)
Réalisation
Installation de la machine virtuelle XEN (séance 2)
Connexion au serveur hébergeant les VM :
ssh root@capbreton.plil.info
Création de l'image de conifguration de la VM :
xen-create-image --ip=193.48.57.105 --gateway=193.48.57.161 --netmask=255.255.255.0 --hostname=dio5 --dist=chimaera --dir=/usr/local/xen/
/!\ Adresse ip provisoire car réseau 193.48.57.160/27 non créé pour le moment. Actuellement ip : 172.26.145.105 /!\
Modification du fichier de config (image):
/etc/xen/dio5.cfg -->
Création de la VM à partir de l'image précédemment créée :
xen create dio5.cfg (en étant dans le dir /etc/xen/ évidemment)
Lancement de la VM :
xen console dio5
login: root
password: XXXXXX
Vérifier avant que la machine a bien été lancée avec xen create dio5.cfg par la commande xen list
Séance 3
Amélioration du coffre fort
Un dossier compressé est en bas de page
Création des volumes virtuels
Sur Capbreton, on créé les LVM /home /var avec leurs systèmes de fichiers :
lvcreate -L10G -ndio5_home storage
mkfs /dev/storage/dio5_home
lvcreate -L5G -ndio5_var storage
mkfs /dev/storage/dio5_var
Il faut changer le fichier de configuration (situé dans /etc/xen) et y ajouter ces deux lignes dans la partie disk =
'phy:/dev/storage/dio5_home,xvdb1,w', 'phy:/dev/storage/dio5_var,xvdb2,w',
Ainsi que modifier la ligne vif comme suit :
vif = [ 'mac=00:16:3E:7B:4D:A4,bridge=IMA5sc' ]
On relance ensuite la machine avec xen create.
Pour monter les deux partitions, il faut ensuite modifier le fichier /etc/fstab comme suit :
/dev/xvdb1 /home ext4 defaults 0 2 /dev/xvdb2 /var ext4 defaults 0 2
Pour que ces modificcations soient prises en compte :
mount -a reboot
Séance 4
Sécurisation par certificat TLS
Nous avons commencé par lancer la machine virtuelle qui était créée et configurée lors des séances précédentes.
Ensuite nous avons acheté le nom de domaine blanquette.site via le fournisseur de nom de domaine GANDI. Ce nom de domaine servira par la suite pour héberger notre site web Apache.
Pour sécuriser la connexion HTTPS sur Apache, il est nécessaire de créer une clé et un CSR. On utilise pour cela l'utilitaire OpenSSL et on exécute les commandes :
apt install openssl openssl req -nodes -newkey rsa:2048 -sha256 -keyout myserver.key -out server.csr -utf8
Pour valider cette demande de certificat et obtenir notre certificat TSL, nous avons également utilisé GANDI.
Configuration du routeur de secours (Cisco 9200????)
Pendant que d'autres binômes s'occupaient de la configuration physique des routeurs (câblage), nous nous sommes occupés de configurer le routeur en E304. Pour cela, on accède à l'interface de configuration Cisco du routeur par port série, via minicom :
minicom -os """device:/dev/ttyUSB0, baudrate:9600, pas de contrôle de flux"""
Depuis cette interface, création de 3 vlan et configuration des ports physiques associés pour répondre à l'architecture réseau demandée pour le TP :
- Connexion entre le routeur et Capbreton sur le VLAN 2 :
enable routeur#conf t routeur#vlan 2 routeur(vlan)#name Capb-E304 routeur#exit routeur#int Te5/4 routeur(if)#switchport routeur(if)#switchport access vlan 2
Il restera ensuite à configurer ce vlan sur le réseau 193.48.57.176/28
- Connexion de redondance entre les deux routeurs :
enable routeur#conf t routeur#vlan 64 routeur(vlan)#name INTERCO-E306/304
Après le choix du port à connecter sur le routeur, il restera à attribuer ce port au vlan 64 en mode trunk.
- Connexion entre le routeur et le SR2
enable routeur#conf t routeur#vlan 531 routeur(vlan)#name INTERCO-5A routeur#exit routeur#int Te5/5 routeur(if)#switchport routeur(if)#switchport access vlan 531
Il restera ensuite à configurer ce vlan sur le réseau 192.168.222.72/29
PHOTO A METTRE !!!
Pour checker la configuration des vlan du routeur :
routeur#show interfaces status
ou :
routeur#show interface vlan X
Séance 5
Tout d'abord nous avons commencé à vérifer le fonctionnement de notre service SSH sur la machine Xen. Pour cela nous avons modifié en premier temps après avoir être connecté sur la machine virtuelle le fichier sshd_config situé dans :
/etc/ssh
comme suit :
# Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10
d'où nous avons décommenté la ligne de qui nous permet de se connecter en tant que root, ensuite nous avons lui donné cette permission par l'expression yes.
Une fois que cette étape est faite, nous avons lancé dans le shell la commande suivante :
root@dio5:~# service ssh restart
Dans le but de prendre en compte les modifications faites.
Pour vérfier la connexion en ssh, nous lançons depuis notre machine zabeth17 la commande suivante :
root@zabeth17:~# ssh root@193.48.57.182
Attribution de l'adresse IP à VLAN2:
- voici les commandes faites sous minicom pour cette attribution:
enable routeur#conf routeur#int vlan 2 routeur#ip address 193.48.57.178 255.255.255.240 routeur#do show run | include interface vlan | ip address
Attribution de l'adresse IP à VLAN531:
- voici les commandes faites sous minicom pour cette attribution:
enable routeur#conf t routeur#int vlan 531 routeur#ip address 192.168.222.75 255.255.255.248 routeur#do show run | include interface vlan | ip address
Configuration et interconnection du port trunk
- voici les commandes faites sous minicom pour cette attribution:
conf t int Te6/5 switchport switchport trunk encapsulation dot1q switchport mode trunk end
- Afin de sauvegarder ces configurations; on oublie pas de les écrire par la commande :
write
Changement de l'addresse IP de la machine Xen
- Changement du Bridge de la machine :
Dans la machine Xen, nous allons modifié le fichier de configuration de notre machine dio5 (situé à /etc/xen/dio5.cfg). Il est devenu comme suivant :
vif = [ 'mac=00:16:3E:2B:B5:60,bridge=IMA5sc' ]
Pour prendre les modifications en compte, nous avons arreté la machine xen puis nous l'avons redemaré depuis capbreton étant bien sur dans le repretoire /etc/xen:
xen shutdown dio5 xen create dio5.cfg
Ensuite nous avons modifié l'addresse IP de la machine dans le fichier /etc/network/interfaces avec l'addresse IP suivante et la gateway qui correspond :
address 193.48.57.182 gateway 193.48.57.176
Pour que les modifications réseaux seront prises en compte, nous exectutons les commandes suivantes dans la machine Xen:
ifdown -a ifup -a
HTTP
Pour que notre VM soit accessible en HTTP, il lui faut un serveur HTPP installé. Dans la machine Xen :
apt install apache2
HTTPS L'achat du certificat SSL nous permet de sécuriser la connexion à notre serveur Apache en HTTPS. Pour cela :
a2enmod ssl a2ensite default-ssl.conf service apache2 restart
On modifie ensuite le fichier /etc/apache2/sites-enabled/default-ssl.conf de telle sorte à y renseigner le certificat SSL, le certificat intermédiaire et notre clé privée. Les certificats sont à télécharger sur Gandi et à transférer sur notre VM en scp.
Voici le contenu du fichier /etc/apache2/sites-enabled/default-ssl.conf pour la configuration du https :
<VirtualHost *:443>
ServerName bolognaise.site
ServerAlias www.bolognaise.site
ServerAdmin webmaster@bolognaise.site
DocumentRoot /var/www/html
SSLEngine on
SSLCertificateFile /root/bolognaise.site.crt
SSLCertificateKeyFile /root/myserver.key
SSLCertificateChainFile /root/GandiStandardSSLCA2.pem
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
On note que VirtualHost *:443 est pour dire que c'est du HTTPS.
Nous avons ensuite modifié le bloc associé au HTTP, d'une façon à avoir une redirection vers du HTTPS comme suivant :
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
Redirect / https://bolognaise.site
</VirtualHost>
Dans ce cas l'utilisateur va arriver toujours sur notre site héberger en HTTPS grâce à la commande :
Redirect / https://bolognaise.site
Séance 6
Serveur DNS
Tout d'abord, sur le site gandi, dans la section Glue record, nous avons renseigné un nom de domaine ns.bolognaise.site, et nous avons ajouté les adresses IPv4 et IPv6 associé à notre machine xen.
IPv4 : 193.48.57.182 IPv6 : 2001:660:4401:60b0:216:3eff:fe7b:4da4
Ensuite dans la section NameServer nous avons ajouté un DNS secondaire ns6.gandi.net dont son adresse IPv4 est la suivante : 217.70.177.40.
Nous avons installé bind9 par apt install bind9.
Configuration du fichier d'option pour bind
Modification du fichier /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
forwarders {
8.8.8.8;
4.4.2.2; //ou 8.8.4.4
};
dnssec-validation auto;
recursion yes;
listen-on-v6 { any; };
listen-on {any;};
allow-recursion{trusted;};
//allow-transfer{none;};
};
listen-on-v6 { any;}
acl trusted{
193.48.57.182; //ns.bolognaise.net
217.70.177.40; //ns6.gandi.net
};
Paramétrage routeur E304
Afin de finir la configuration du routeur en E304, il est nécessaire de mettre en place deux protocoles :
OSBF: partage de routes entre les deux routeurs
En effet, l'objectif d'avoir 2 routeurs pour accéder au SR52 est d'avoir une redondance du réseau robuste aux pannes. Néanmoins, il faut pour cela que les deux routeurs connaissent chacun les tables de routages de l'autre. Ci-dessous la configuration OSBF du routeur E304 :
router ospf 1 router-id 192.162.222.6 summary-address 192.168.0.0 255.255.0.0 not-advertise summary-address 193.48.57.176 255.255.255.240 redistribute connected subnets ! subnets allowed redistribute static subnets route-map ospf ! subnets allowed network 192.168.222.72 0.0.0.7 area 20 default-information originate
Pour vérifier si le partage de routes est fonctionnel, on tape dans l'interface Cisco du routeur :
do show ip route
Si les routes du routeur en E306 s'affiche, c'est que le protocole a bien été configuré
RIPv6:
La première est de permettre au routeur d'attribuer des adresses IPv6 aux différentes machines sur son réseau (Xen ...), un peu à la manière d'un DHCP. Ci-dessous la configuration :
interface vlan 2
ipv6 enable
ipv6 address 2001:660:4401:60b0::/64 eui-64
ipv6 nd prefix 2001:660:4401:60b0::/64 1000 900
ipv6 nd router-preference high
!
ipv6 unicast-routing
La deuxième étape est d'activer le routage IPv6 entre les deux routeurs et de définir les priorités de route :
ipv6 rip tpima5sc enable
ipv6 router rip tpima5sc
redistribute connected metric 1 XXXXXXXXX
redistribute rip 1 metric 1
redistribute static metric 1
!
Pour tester que le routage IPv6 est bien activé :
do show ipv6 route
VRRP : Pour rendre notre réseau plus robuste, on a finalement implémenté le protocole VRRP sur le routeur. On a simplement repris la configuration donnée dans le sujet de TP et adaptée à notre cas. Pour la priorité, nous avons indiqué :
vrrp 1 priority 90
De cette manière, on a définit le routeur en E304 de telle sorte à ce qu'il ne soit pas prioritaire par rapport au 6509E en E306, puisque ce dernier a été configuré avec une priorité de 100.
Schéma
Pour récapituler l'architecture réseau, on peut regrouper de nombreuses informations dans le schéma ci-dessous :
Séance 7 (dernière séance)
Suite DNS
Fin de la configuration des fichiers DNS /etc/bind/named.conf.options , /etc/bind/named.conf.options.local et
Génération des clés dnssec dans un répertoire /etc/bind/bolognaise.site.dnssec
Une fois que le fichier /etc/bind/named.conf.options est rempli d'une manière à configurer notre DNS, nous avons mis en place une configuration des forward et des zones comme suit :
Dans le fichier /etc/bind/named.conf.local :
zone "57.48.193.in-addr.arpa"{
type master;
file "/etc/bind/db.193.48.57";
allow-transfer{217.70.177.40;};
notify yes;
};
zone "bolognaise.site"{
type master;
file "/etc/bind/db.bolognaise.site";
allow-transfer{217.70.177.40;};
notify yes;
};
Une fois que les paramètres sont ajoutés dans le fichier de configurations, nous avons créé ensuite les fichiers de zones comme suit:
cp /etc/bind/db.local /etc/bind/db.bolognaise.site
Cette commande va nous permettre de copier le contenu du fichier db.local dans le fichier db.bolognaise.site et qui sera créé en même temps. voici le contenu des fichiers /etc/bind/db.local et /etc/bind/db.bolognaise.site avant la configuration :
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1
Maintenant nous allons modifié le fichier /etc/bind/db.bolognaise.site
$TTL 604800
@ IN SOA ns.bolognaise.site. root.bolognaise.site. (
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ IN NS ns.bolognaise.site.
@ IN NS ns6.gandi.net.
@ IN A 193.48.57.182
@ IN AAAA 2001:660:4401:60b0:216:3eff:fe7b:4da4 ;addresse IPV6 de dio5
ns IN A 193.48.57.182
ns IN AAAA 2001:660:4401:60b0:216:3eff:fe7b:4da4
www IN A 193.48.57.182
www IN AAAA 2001:660:4401:60b0:216:3eff:fe7b:4da4
Pour que les modifications seront prises en compte :
service named restart
Nous faisions un test pour vérifer la fonctionalité de la forward zone :
root@dio5:~# host bolognaise.site localhost Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: bolognaise.site has address 193.48.57.182 bolognaise.site has IPv6 address 2001:660:4401:60b0:216:3eff:fe7b:4da4
Ensuite nous allons faire la même démarche pour la reverse zone, où on commence par la copie du fichier comme suit :
cp /etc/bind/db.127 /etc/bind/db.193.48.57
Voici le contenu du fichier /etc/bind/db.127 :
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ IN NS localhost.
1.0.0 IN PTR localhost.
Nous allons configuré le fichier /etc/bind/db.193.48.57 de la façon suivante :
$TTL 604800
@ IN SOA ns.bolognaise.site. root.bolognaise.site. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ IN NS ns.bolognaise.site.
182 IN PTR ns.bolognaise.site.
Pour que les modifications seront prises en compte :
service named restart
Voici un test pour la reverse zone :
root@dio5:~# host 193.48.57.182 localhost Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: 182.57.48.193.in-addr.arpa domain name pointer ns.bolognaise.site.
Notre DNS étant maintenant fonctionnel, nous avons pu refaire la demande sur Gandi pour les serveurs externes IPv4 et IPv6, pour rappel : ns.bolognaise.site et ns6.gandi.net
Sécurisation du DNS par DNSSEC
Pour sécuriser notre DNS par DNSSEC, nous aurons besions des clés DNSSEC, que nous allons les ranger dans le répertoire suivant :
/etc/bind/bolognaise.site.dnssec
Ensuite nous allons créé les clés DNSSEC :
- KSK (Key Signing Key)
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE bolognaise.site
- ZSK (Zone Signing Key)
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE bolognaise.site
Puis nous injectons les clés KSK et ZSK (Privées et Publiques) dans les fichiers qui leurs corresponds :
mv ./Kbolognaise.site.+005+14017.key ./bolognaise.site-zsk.key mv ./Kbolognaise.site.+005+19378.private ./bolognaise.site-zsk.private mv ./Kbolognaise.site.+005+13782.private ./bolognaise.site-ksk.private mv ./Kbolognaise.site.+005+02617.key ./bolognaise.site-ksk.key
On n'oublie pas de mettre la clé publique KSK sur gandi, en prenant l'algorithme de RSA/SHA1.
Dans le fichier /etc/bind/named.conf.options on ajoute le ligne suivante pour activer le dnssec :
dnssec-enable yes;
Ensuite nous allons modifié du nouveau le fichier /etc/bind/named.conf.local en ajoutant le champs signed:
zone "bolognaise.site"{
type master;
file "/etc/bind/db.bolognaise.site.signed";
allow-transfer{217.70.177.40;};
notify yes;
};
zone "57.48.193.in-addr.arpa"{
type master;
file "/etc/bind/db.193.48.57";
allow-transfer{217.70.177.40;};
notify yes;
};
Cela va impliquer la prise en compte des fichiers des zones. Après nous allons inclure les clés que nous l'avons créé dans le fichier /etc/bind/db.bolognaise.site
- Pour la clé ZSK :
$INCLUDE "/etc/bind/bolognaise.site.dnssec/bolognaise.site-zsk.key";
- Pour la clé KSK :
$INCLUDE "/etc/bind/bolognaise.site.dnssec/bolognaise.site-ksk.key";
Et pour terminer, nous avons signé le fichier de zone comme suivant :
dnssec-signzone -k bolognaise.site-ksk.key -o bolognaise.site ../db.bolognaise.site bolognaise.site-zsk.key
Modification du html de notre serveur pour ajouter une photo de BOLOGNAISE
Dans le fichier /var/www/html/index.html, nous avons modifié le code source de la page de notre site
d'une façon à avoir l'image de bolognaise qui s'affiche. Voici le code HTML :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>NOS Bolognaises !!!</title> </head> <style> img{ height:70vh; margin:auto; display:block; } </style> <body> <img src="bolognaise.jpg"> <a href="portail.polytech-lille.fr">ICI polytech</a> </body> </html>
Si on écrit dans un navigateur : https://bolognaise.site on peut arriver directement dans notre site.
Gestion de fail2ban
Nous avons commencé par installer la commande fail2ban :
apt install fail2ban
Puis nous avons activé le fil2ban comme suivant :
root@dio5:~# service fail2ban active
Usage: /etc/init.d/fail2ban {start|force-start|stop|restart|force reload|status}
root@dio5:~# service fail2ban enable
Usage: /etc/init.d/fail2ban {start|force-start|stop|restart|force-reload|status}
Nous regardons le status du fail2ban :
root@dio5:~# service fail2ban status Status of Authentication failure monitor:fail2ban is running.
Dans le fichier /etc/fail2ban/jail.d/defaults-debian.conf nous activons le name refused en ajoutant les 2 lignes suivantes :
[named-refused] enabled = true
Dans le fichier /etc/bind/named.conf.options, on va allumer le service de loggin de named-refused, qui est par défault éteint, pour cela nous ajoutant ce bloc :
logging {
channel security_file{
file "/var/log/named/security.log" versions 3 size 30m;
severity dynamic;
print-time yes;
};
category security{
security_file;
};
Dans le fichier /etc/bind/named.conf.options nous allons définir le nombre max de reponses par seconde que le server peut l'accepter avant de faire le ban, pour cela on ajoute le bloc suivant :
rate-limit{
responses-per-second 5;
};
Le nombre max des reponses par seconde est fixé à 5.
Comme que nous allons écrire dans le fichier security.log et que ce fichier n'existe pas, donc nous allons le créer et créer les dossiers qui correspondent :
- Création du dossier named:
mkdir /var/log/named
- Création du fichier security.log qui vide au départ:
touch security.log étant dans le dossier /var/log/named
Et comme que ce dossier named/ appartient au service bind (named) donc il était nécessaire de lui associé un owner qui est le bind9 :
- Etant dans le dossier /var/log :
chown bind named/ chown bind named/security.log
Pour vérifier la prise en compte des changement :
root@dio5:~# ls -l /var/log/ | grep named drwxr-xr-x 2 bind root 4096 Nov 30 09:56 named root@dio5:~# ls -l /var/log/named/ total 12 -rw-r--r-- 1 bind root 10898 Dec 7 17:43 security.log
On restart les services pour prendre en compte les modifications:
service named restart
Mise en place d'un RAID 5
Dans le but de rendre les données de notre VM sécurisées (résilience aux problèmes hardware de disque), nous mettons en place une configuration RAID 5. Pour cela : Création de 3 partitions LVM de 1Go sur capbreton :
lvcreate -L1G -nbolo-raid1 storage lvcreate -L1G -nbolo-raid2 storage lvcreate -L1G -nbolo-raid3 storage
Il faut évidemment modifier le fichier de configuration (/etc/xen/dio5.cfg) de notre VM en conséquence pour rattacher ces 3 partitions dans la partie disk:
'phy:/dev/storage/bolo-raidX,xvdb3,w' en répétant cette ligne pour X variant de 1 à 3
On redémarre ensuite la VM :
halt
Puis sur capbreton on exécute :
xen-create-image dio5.cfg xen console dio5
On peut maintenant créer depuis la xen le système RAID5:
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb3 /dev/xvdb4 /dev/xvdb5 mkfs /dev/md0 création du système de fichiers mount /dev/md0 /mnt on monte le disque RAID5
Rappel des commandes utiles :
lsblk : affiche la liste et les caractéristiques tous les disques et leurs partitions df : affiche la valeur d'espace disque disponible des systèmes de fichier disponibles en écriture pour le user
Test de résistance de notre RAID 5
On commence par enregistrer un fichier sur notre partition dans /mnt :
cd /mnt ; echo "Test résistance RAID5" > test.txt
Pour simuler un cas de défaillance d'un des 3 disques, on commente dans le fichier de configuration de la xen une des lignes correspondant à un des 3 disques, puis on reboot la xen. Une fois démarrée, on peut vérifier que la reconstruction des données à bien fonctionné simplement en exécutant :
cd /mnt ; cat test.txt
Ce qui nous donne en sortie dans la console :
Test résistantce RAID5
Notre système RAID5 est donc fonctionnel.
Cassage de mot de passe WEP
On va pour cette activité utiliser le paquet aircrack-ng. Une fois l'interface réseau Wifi identifiée (wlan0mon), on démarre aircrack-ng dessus :
airmon-ng start wlan0mon
On écoute ensuite tout ce qui passe sur cette interface pour identifier le BSSID correspondant à notre groupe (SSID cracotte05), et le channel associé:
airodump-ng -c wlan0mon
Une fois le BSSID identifié (XXXXXX), on recommence l'écoute du réseau mais cette fois en filtrant pour ne récupérer que des trames correspondant au SSID que l'on souhaite cracker :
airodump-ng -c 13 --bssid 04:DA:D2:9C:50:54 -w cracotte08 wlan0mon
Une fois un nombre de paquets suffisants récupérés, on lance l'algorithme de crackage pour récupéré la clé WEP :
aircrack-ng cracotte05-01.cap
On trouve : FF:FF:FF:FF:FA:BC:06:CB:AE:EE:EE:EE:EE
Cassage de mot de passe WPA-PSK par brut force
Pour le point d'accès sécurisé en WPA-PSK, il va falloir faire du brute force pour récupérer la clé. Nous savons que le mot de passe est une suite de 8 chiffres, on commence donc par créer un dictionnaire contenant toutes les possibilités à tester :
crunch 8 8 0123456789 -o dico.txt
Ensuite, même méthode que précédemment, on utilise le package aircrack-ng pour analyser le réseau et trouver le BSSID associé au point d'accès de notre groupe (kracotte05), et on trouve :
BSSID : 44:AD:D9:5F:87:04
Une fois un nombre de paquets récupérés suffisants, on peut lancer le carckage par brute force :
aircrack-ng -w dico.txt -b 44:AD:D9:5F:87:04 kracotte05-01.cap
Après plus d'une heure, la clé est trouvée ;
49905998
