Version actuelle datée du 8 janvier 2023 à 21:56

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

Coffre Fort

Fichier:Coffre secret2.zip

TP sysres IMA5 2022/2023 G5 : Différence entre versions