TP sysres IMA5sc 2020/2021 G10 : Différence entre versions

De Wiki d'activités IMA
(Sécurisation de données)
(Sécurisation de données)
Ligne 478 : Ligne 478 :
 
   Persistence : Superblock is persistent
 
   Persistence : Superblock is persistent
 
   Update Time : Mon Nov 30 14:21:28 2020
 
   Update Time : Mon Nov 30 14:21:28 2020
        State : clean
+
        State : clean
Active Devices : 3
+
Active Devices : 3
  Working Devices : 3
+
        Working Devices : 3
Failed Devices : 0
+
Failed Devices : 0
Spare Devices : 0
+
Spare Devices : 0
 
+
        Layout : left-symmetric
        Layout : left-symmetric
 
 
     Chunk Size : 512K
 
     Chunk Size : 512K
  Consistency Policy : resync
+
        Consistency Policy : resync
 
+
Name : pleurote:0  (local to host pleurote)
          Name : pleurote:0  (local to host pleurote)
+
        UUID : 174ca3a2:9133344c:c58badf8:bccd6167
          UUID : 174ca3a2:9133344c:c58badf8:bccd6167
+
        Events : 18
        Events : 18
+
        Number  Major  Minor  RaidDevice State
 
 
Number  Major  Minor  RaidDevice State
 
 
   0 202 12037    0  active sync  /dev/xvdav5
 
   0 202 12037    0  active sync  /dev/xvdav5
 
   1 202 12038    1  active sync  /dev/xvdav6
 
   1 202 12038    1  active sync  /dev/xvdav6

Version du 13 décembre 2020 à 19:12

TP PRA : MALTI Hind & AHOUASSOU Loris

Séance 1

Installation des systèmes d'exploitation

Pour installer la machine virtuelle, il faut se connecter en SSH sur le serveur 'capbreton'et se mettre en root

 ssh capbreton.plil.info

Puis lancer la commande marquée ci dessous.

 xen-create-image --hostname=pleurote --dist=buster --ip=100.64.0.20 --netmask=255.255.255.240 --dir=/usr/local/xen/  --password=XXXXXXX --gateway=100.64.0.5 --force

Nous avions acheté un nom de domaine sur Gandi, le thème étant les champignons, nous avons choisi "Pleurote".


Toutefois, il convient de préciser que si nous lançons cette commande en étant simplement en 'su', cela ne fonctionnera pas et renverra une erreur de binaire "mkswap absent". Pour corriger cela, il convient au préalable de se mettre en 'su -' plutôt qu'un simple 'su' qui chargerait uniquement les variables d'environnement de l'utilisateur qui l'a invoqué, au lieu de celles du root véritable. En effet, le binaire 'mkswap' est présent dans le dossier /sbin qui n'est présent que dans les variables d'environnement de 'su -', d'où l'erreur.

Nous avons donc nos informations machine, que l'on retrouve dans le fichier /etc/xen/pleurote.cfg:

  • Nom de domaine: pleurote
  • @IP : 100.64.0.20
  • Netmask: 255.255.255.240
  • @MAC : 00:16:3E:64:5D:88

Nous avons modifier ce fichier afin d'apporter le bridge : IMA5sc

Par la suite, nous devions modifier le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l’hôte. Cependant, avant de réaliser cette action, il nous fallait disposer de nos partitions logiques alloués. L'un des binômes de la promo s'est chargé de créer d'abord un volume de groupe 'storage' avec la commande suivante

 vgcreate storage /dev/sde /dev/sdf 

Dans ce volume de groupe, il nous a assigné chacun (binôme) deux volumes logiques de 10Giga

 lvcreate -L10G LorisHind1 storage
 lvcreate -L10G LorisHind2 storage

À partir de là, nous pouvions modifier le fichier de configuration de notre machine virtuelle ( /etc/xen/pleurote.cfg ). Pour se faire, nous avons rajouté deux lignes au niveau de la section 'disks'.

  'phy:/.../LorisHind1,xvdav3,w'
  'phy:/.../LorisHind2,xvdav4,w'


La ligne avec '...xvdav3...' nous servira pour le répertoire 'var' et '...xvdav4...' pour le répertoire 'home'.

  • Pour mettre le répertoire /var sur notre première partition, il faut réaliser les étapes suivantes :

D'abord accéder à la console de notre VM.

 xl create -c etc/xen/pleurote.cfg
 xl console pleurote

Un fois dans notre VM, on va commencer par formater notre partition censée accueillir le répertoire /var

 mkfs -t ext4 /dev/xvdav3

Ensuite on monte cette partition sur le répertoire '/mnt' afin de récupérer ce qui se trouve sur le répertoire /var :

mount /dev/xvdav3 /mnt 
mv /var/* /mnt


On rajoute la ligne suivante dans le fichier /etc/fstab

 /dev/xvdav3 /var ext4 defaults 0 2


On démonte '/mnt'

 umount /mnt

Avant de remonter suivant le /etc/fstab

 mount -a


  • Nous faisons de même pour le répertoire /home sur notre seconde partition

Pour l'installation des paquetages SSH, apache2 et bind, cela nécessitait un accès internet dépendant de la configuration des VLANs (qui n'était pas encore complètement opérationnelle)

Séance 2

Cassage de clef WEP d’un point d’accès WiFi

Pour commencer, nous installons d'abord le packet "aircrack-ng" Ensuite afin de lister ce que contient le réseau Wifi,

airmon-ng start wlp2s0mon
airomon-ng --encrypt wep wlp2s0mon
infos sur les cracottes

Nous avons besoin de cette dernière commande pour avoir les informations nécessaire à notre wifi à craquer On note le bssId 04:DA:D2:9C:5050:59 et le channel 3

Nous choisissons de casser la clé WEP de la cracotte10 sur le channel 3, on enregistre les paquets dans webPack.

airodump-ng -c 3 –-bssid 04:DA:D2:9C:5050:59 -w paquets wlp2s0mon

La commande suivante permet de se faire passer pour un client afin de générer de l'activité sur le réseau.

aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:5050:59 wlp2s0mon

Un fichier paquets_01.cap est créé. On utilise les paquets enregistrés pour réaliser le cassage:

aircrack-ng -z paquets_01.cap


On parvient à avoir la clé au bout de 50.000 de paquets, la dernière commande teste chaque 5000 paquets pour essayer de trouver le mot de passe. Voici le résultat trouvé :

Key found
A la toute fin il est nécessaire de faire un :
airmon-ng stop wlp2s0mon

Ajout et configuration d'un serveur DNS sur la VM

Pour commencer nous avons installé les packages bind9 et apache2 puis nous avons fait l'acquisition du nom de domaine pleurote.site sur le site gandi.net qui nous servira tout au long du TP.

Dans le dossier de configuration de bind9 à l'emplacement /etc/bind, on créé le fichier de zone db.pleurote.site et on ajoute :

BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns1.pleurote.site. postmaster.pleurote.site. (
                             3         ; Serial
                        604800         ; Refresh
                         86400         ; Retry
                       2419200         ; Expire
                        604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.pleurote.site.
@       IN      NS      ns6.gandi.net.
ns1     IN      A       193.48.57.179

Dans le fichier named.conf.local :

zone "pleurote.site" IN {
       type master;
       file "/etc/bind/db.pleurote.site";
       allow-transfer {217.70.177.40;};
};

Dans le fichier named.conf.options :

options {
       directory "/var/cache/bind";
       dnssec-enable yes;
       dnssec-validation auto;
       listen-on-v6 { any; };
       allow-recursion { localhost; };
};

Ensuite on se rend sur le site gandi.net puis dans "Domains" :

Dans l'onglet "Glue Record", on ajoute :

namespace : ns1.pleurote.site
l'adresse IP de notre VM : 193.48.57.179

Dans l'onglet "Serveur de noms" on ajoute le DNS principal et secondaire :

DNS1 : ns1.pleurote.site
DNS2 : ns6.gandi.net

Séance 3

Attaque de type "homme au milieu" par usurpation ARP

Pour expérimenter cette attaque, on installe le paquet dsniff sur notre eeePC.

apt-get install dsniff

Ce paquet permet d'écouter le réseau afin de passer outre la sécurité intégrée dans des réseaux éthernet. dsniff contrefait l'adresse MAC de la passerelle Ethernet locale dans le but de rediriger tous les paquets vers la machine dsniff (donc vers notre eeePC, qui est en fait notre homme au milieu). Ces paquets pourront ensuite être analyser pour y prendre les informations sensibles que l'on souhaite.

Afin que notre eeePC soit effectif en tant qu'homme au milieu, on va passer la variable ip_forward du fichier /proc/sys/net/ipv4/ip_forward à 1. Cela le fait passer en mode routeur.

Nous insérons ensuite notre eeePC entre la machine d'un autre binôme ( son IP : 172.26.145.65 ) et le routeur utilisé par cette machine fixe ( IP : 172.26.145.254 ) à l'aide de la commande arpspoof.

arpspoof -i enp4s0 -t 172.26.145.65 172.26.145.254

En gros, cette commande dit "fait moi (l'eeePC) passer pour le routeur 172.26.145.254 auprès du client 172.26.145.65 afin que je reçoive ses paquets". Ensuite on va activer l'écoute sur Wireshark au moment où on se connecte sur un site HTTP tel que le Fabricarium de Polytech-Lille.

En lançant cela, on peut voir d'abord que l'eeePC envoie un message ARP pour se faire passer pour le routeur local 172.26.145.254. Ensuite, notre client envoie ses paquets à l'eeePC ( IP : 193.48.57.233 ) qui peut lire ses requêtes http.

Maninmiddle1.png

On voit ci-dessous des données lisibles envoyées depuis le formulaire de connexion du site du Fabricarium.

Lorismaninmiddle.png

Cependant, on constate qu'une fois la requête GET envoyée, le site du Fabricarium freeze, rien n'est chargé, même pas un page d'erreur, alors que le but de la manœuvre c'est que le client ne trouve rien d'anormal.

En fait, cela est dû au fait que notre routeur (eeePC) n'a pas renvoyée la page demandée au client, le retour n'est pas effectif. Pour permettre ça, il nous faut passer à 1 la variable rp_filter du fichier /proc/sys/net/ipv4/conf/default/rp_filter pour activer le chemin inverse.

On refait les étapes précédentes, et on peut constater que le retour est effectif chez le client.

Intrusion sur un serveur d’application Web

Le but de cette partie, est de réussir à s'introduire sur le serveur honey.plil.info en exploitant d'éventuelles failles de sécurité. L'idée première que nous avons eu a été de faire des injections SQL dans le formulaire présenté.

Nous avons donc tester l'injection suivante aussi bien dans le champ d'identifiant

'OR 1=1#

Le caractère # à la fin représente un commentaire et permet donc d'ignorer tout ce qui suivra après dans la requête. Ainsi, cela correspond à faire

SELECT * FROM admins WHERE login= OR 1=1

Même s'il n'y a pas de Login clairement entré, l'expression 1=1 étant toujours vraie, la requête nous a renvoyée une table contenant des identifiants et des mots de passe.

Tableadmin.png

Nous avons donc pris l'identifiant "admin" son mot de passe "jesuislechef" que nous avons ensuite entré naturellement dans le formulaire du site honey.plil.info. Cela a eu pour effet de nous donner l'accès à l'application Web. Nous avons un peu exploré l'application. Nous voulions pouvoir lire le fichier de configuration de base de données de phpmyadmin. Nous sommes entrés dans la Gestion des Manuels et nous avons ajouter un nouveau manuel : nom : nom ; path : /etc/phpmyadmin/config-db. Une fois ajouté, nous somme allé dans Recherche de manuels et nous avons téléchargé le fichier de config précédemment ajouté.


Config-db.png

Nous avons alors utilisé le mot de passe de la base de données sur phpmyadmin. Identifiant : root, Password : gencovid19. Suite à quoi on a eu l'accès. Après avoir un peu exploré, on est rentré dans la table users de la base test, ce qui nous a fournit le login rex et le mot de passe plainpassword.

Test users.png

Nous sommes retourné dans un terminal et nous avons lancée une connexion SSH.

ssh rex@honey.plil.info

À ce niveau là, on a aucun fichier directement utile. Néanmoins, en utilisant nos connaissances du système UNIX, on peut avoir se servir de deux fichiers très utiles:

/etc/passwd et /etc/shadow. En effet, le premier c'est celui qui contient généralement des informations sur les utilisateurs qui peuvent se connecter au système (le nom, l'identifiant, répertoire personnel...), mais il ne contient pas les mots de passe de ces utilisateurs. En revanche, le second fichier, lui, contient une version hashée des mots de passe et seuls des utilisateurs très privilégiés peuvent y avoir accès. Dans /etc/shadow on a pu voir à la dernière ligne le mot de passe crypté de root. Pour décrypter cela, nous utilisons John qui est un utilitaire de crackage de mots de passe. Pour fonctionner, John a besoin d'une liste de mots et un mot de passe à cracker. Mais avant, il faut combiner les deux fichiers précédents en utilisant la commande unshadow. Et comme c'est la dernière ligne qui nous intéresse, alors :

unshadow /etc/passwd /etc/shadow | head -> honey_mdp

À partir de là, nous avons un indice dans le sujet : La seule indication est que le mot de passe de root possède la même particularité que le mot de passe administrateur habituel des machines de projets. Cela nous donne plusieurs informations sur le mot de passe : il est probablement composé que de lettres; il est en minuscules; et il est certainement formé de deux mots identiques de 4 lettres (comme le mot de passe glopglop)

L'idée est de créer un dictionnaire de mots de 8 lettres (qui est en fait formé du même mot de 4 lettres comme glopglop). Au lieu de faire un code C qui nous génère cela, nous avons utilisé l'utilitaire crunch qui nous génère facilement ce dictionnaire. Mais attention, si nous générons directement des mots de 8 lettres, le temps de calcul sera très très long car il devrait créer 26^8 mots ~= 2x10^11 et donc une taille ÉNORME de fichier (~+1TB).

Une approche moins naïve serait de générer d'abord un dictionnaire de mots de 4 lettres, ce qui fait seulement 26^4 = 456976 mots pour une taille de ~2MB.

crunch 4 4 abcdefghijklmnopqrstuvwxyz > liste_mots

On peut dupliquer nos mots pour former des mots doublés de 8 lettres avec la commande 'sed'

sed -i 's/\(.*)/\1\1/' liste_mots

Maintenant, le boulot est fait, il ne reste plus qu'à laisser 'John' décrypter.

john -W:liste_mots honey_mdp

Quand c'est terminé, on affiche le mot de passe :

john --show honey_mdp

Comme indiqué sur la capture suivante, le mot de passe est fortfort

John crack.png

Séance 4

Cassage de mot de passe WPA-PSK par force brute

Nous avons précédemment craqué le clé WEP avec l'utilitaire aircrack-ng. Nous l'utilisons à nouveau pour faire de même avec la clé WPA-PSK. D'abord, on visualise notre interface :

airmon-ng

Ensuite, on active l'interface :

 airmon-ng start wlx40a5efd2140c

après cette commande, notre interface a été renommé en wlan0mon, nous travaillerons donc avec ce nom par la suite. On peut lancer l'écoute :

 airodump-ng wlan0mon

On va cracker la Kracotte10, on peut donc lire son BSSID 00:14:1B:60:8C:29 et son channel 3

Avec ces informations, on va récupérer l'handshake et le mettre dans un fichier result

 airodump-ng --bssid 00:14:1B:60:8C:29 wlan0mon --channel 3 --write result
5-3-3.png

Cela prend quelques minutes. Ensuite ce qu'il nous faut c'est générer un dictionnaire de mots de 8 chiffres, on peut utiliser l'utilitaire crunch pour cela.

crunch 8 8 0123456789 > dico.txt

Enfin on peut lancé le crackage :

aircrack-ng result-01.cap -w dico.txt

Cela peut durer un certain temps avant que ce soit décrypté.

5-3-4.png

Serveur SSH

Il était nécessaire que notre vm soit accessible en ssh, pour ce nous avons décommenter dans le fichier /etc/ssh/sshd-config:

PermitRootLogin yes

Puis on redémarre le service ssh afin qu'il prenne en considération nos changements:

systemctl restart sshd 

Et voilà ! Notre vm est accessible en root avec soit:

root@pleurote.site

soit:

root@193.48.57.179

Sécurisation de site web par certificat

Nous commençons par un générer deux fichiers grâce à la commande

openssl req -nodes -newkey rsa:2048 -sha1 -keyout pleurote.site.key -out pleurote.csr

pleurote.csr : Ce fichier nous sert à faire une demande de certificat auprès d'une autorité de certification. Il contient quelques informations personnelles ainsi que la clef publique.

pleurote.site.key : Celui-ci contient la clef privée (qu'on tâchera de ne jamais perdre ou distribuer) qui est complémentaire à celle présente dans le csr. On peut ensuite se rendre sur Gandi afin d'acheter le certificat. Le csr sera demandé pendant la procédure puis il faudra choisir une des trois méthodes proposées pour la vérification. Nous avons choisi celle par email pour le challenge de créer un serveur de mail sur notre machine.Pour ce, en parallèle :

on install postfix :

apt-get install postfix 

on modifie le fichier :

/etc/aliases 

On met dedans : admin: root

on install ensuite :

apt-get install -y bsd-mailx
postalias /etc/aliases
mailx 

et on reçoit alors le mail de Gandi avec un lien et un mot de passe de vérification à rentrer dans un champs. On clique sur le lien et on colle dessus le mot de passe de vérification.


Il nous faut maintenant récupérer notre certificat depuis Gandi ainsi que le certificat intermédiaire. On déplace ensuite l'ensemble de ces clefs dans les répertoires appropriés :

/etc/ssl/pleurote.site.crt                                                                      
/etc/ssl/pleurote.site.key                                                                 
/etc/ssl/GandiStandardSSLCA2.pem

Configuration d'apache2

Avant toute chose, on s'assure que le module ssl est actif pour apache2. Nous remplissons ensuite les informations territoriales utiles à la génération du CSR.

Ensuite sur gandi.net dans "SSL Certificates" on achète le certificat (bien qu'il soit indiqué comme coutant 12€, lors de l'encaissement il devient gratuit)

a2enmod ssl

On se rend ensuite dans le répertoire /etc/apache2/sites-enabled et on modifie par exemple le fichier 000-default.conf.

<VirtualHost *:80>                                                                                                         
  ServerName www.pleurote.site                                                                                             
  Redirect / https://www.pleurote.site       
  ....                                                                        
</VirtualHost>   
                                                                                                                                                                                                                              
<VirtualHost _default_:443>                                                                                                
  ServerName www.pleurote.site                                                                                             
  DocumentRoot /var/www/html                                                                                              
  SSLEngine On                                                                                                            
  SSLCertificateFile /etc/ssl/pleurote.site.crt                                                                     
  SSLCertificateKeyFile /etc/ssl/pleurote.site.key                                                                 
  SSLCertificateChainFile /etc/ssl/GandiStandardSSLCA2.pem                                                          
  SSLVerifyClient None                                                                                                 
</VirtualHost>    

Le premier VirtualHost s'assure que l'utilisateur se connecte toujours en https (grâce au Redirect) et le second est justement utilisé pour l'accès en https au site.

Enfin, on redémarre le service apache2 pour que les modifications soient prises en compte.

service apache2 restart

Sécurisation de serveur DNS par DNSSEC

Dans cette partie, nous allons certifier aux utilisateurs de notre site web que l'IP qu'il reçoit dans la réponse DNS est bien celle du domaine voulu. Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

On commence naturellement par activer DNSSEC en ajoutant l'option dnssec-enable yes; dans le fichier /etc/bind/named.conf.local

On génère deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous créons un dossier pleurote.site.dnssec et nous mettrons les clefs dedans. Nous commençons par créer la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE pleurote.site

Ensuite, nous créons la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -n ZONE pleurote.site

Afin que ce soit lisible et facile à manier, nous renommons nos deux paires de clefs en : pleurote-ksk.key pleurote-ksk.private pleurote-zsk.key pleurote-zsk.private

$include /etc/bind/pleurote.site.dnssec/pleurote.site-ksk.key
$include /etc/bind/pleurote.site.dnssec/pleurote.site-zsk.key

On signe les enregistrements de la zone, grâce à la commande:

dnssec-signzone -o pleurote.site -k pleurote.site-ksk ../db.pleurote.site pleurote.site-zsk  

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :

zone "pleurote.site" IN {
 type master;
 file "/etc/bind/db.pleurote.site.signed";
 allow-transfer {127.70.177.40;};
 dnssec-enable yes;
};   

Et puis finalement :

Faire communiquer la partie publique de la KSK (présente dans le fichier pleurote-ksk.key) sur gandi dans la partie DNSSEC. On oublie pas de changer le type en 5 (RSA/SHA-1) étant donné qu'on a utilisé du SHA1 dans notre commande. Dns-verif.PNG

Séance 5

Sécurisation de données

En un premier lieu, sur le serveur Capbreton, nous créons des volumes logiques et puis nous les relions au volume group "virtual" qui a été dédié à cette partie du TP.

root@capbreton:~# lvcreate -L1G -n pleurote-part1 virtual
 Logical volume "pleurote-part1" created.
root@capbreton:~# lvcreate -L1G -n pleurote-part2 virtual
 Logical volume "pleurote-part2" created.
root@capbreton:~# lvcreate -L1G -n pleurote-part3 virtual
 Logical volume "pleurote-part3" created.

Nous ajoutons ensuite au fichier pleurote.cfg

'phy:/dev/virtual/pleurote-part1,xvda5,w',
'phy:/dev/virtual/pleurote-part2,xvda6,w',
'phy:/dev/virtual/pleurote-part3,xvda7,w'
root@capbreton:~# lvdisplay | grep pleurote
 LV Path            	/dev/virtual/pleurote-part1
 LV Name            	pleurote-part1
 LV Path            	/dev/virtual/pleurote-part2
 LV Name            	pleurote-part2
 LV Path            	/dev/virtual/pleurote-part3
 LV Name            	pleurote-part3
xl destroy pleurote
xl create /etc/xen/pleurote.cfg

Ensuite : Sur notre VM pleurote:

root@pleurote:~# lsblk
NAME   MAJ:MIN   RM  SIZE RO TYPE MOUNTPOINT
xvda1  202:1  	0  512M  0 disk [SWAP]
xvda2  202:2  	0	4G  0 disk /
xvdav3 202:12035  0   10G  0 disk /var
xvdav4 202:12036  0   10G  0 disk /home
xvdav5 202:12037  0	1G  0 disk
xvdav6 202:12038  0	1G  0 disk
xvdav7 202:12039  0	1G  0 disk
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvdav5  
/dev/xvdav6 /dev/xvdav7--create /dev/md0 --level=5 --raid-devices=3 /dev/xvdav5  

Cette dernière commande permettra de créer un nouveau volume md0, de définir le niveau du raid (5) ainsi que les différents périphériques actifs xvdav 5->7

root@pleurote:~# mdadm --monitor --daemonise /dev/md0
root@pleurote:~# mkfs -t ext4 /dev/md0

Ensuite on modifie /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 1


root@pleurote:~# mdadm --detail /dev/md0
/dev/md0:
      	Version : 1.2
	Creation Time : Mon Nov 30 14:17:07 2020
   	Raid Level : raid5
   	Array Size : 2093056 (2044.00 MiB 2143.29 MB)
	Used Dev Size : 1046528 (1022.00 MiB 1071.64 MB)
 	Raid Devices : 3
	Total Devices : 3
  	Persistence : Superblock is persistent
  	Update Time : Mon Nov 30 14:21:28 2020
       State : clean

Active Devices : 3

       Working Devices : 3

Failed Devices : 0

	Spare Devices : 0
       Layout : left-symmetric
   	Chunk Size : 512K
       Consistency Policy : resync

Name : pleurote:0 (local to host pleurote)

       UUID : 174ca3a2:9133344c:c58badf8:bccd6167
       Events : 18
       Number   Major   Minor   RaidDevice State
  	0 	202	12037    	0  	active sync   /dev/xvdav5
  	1 	202	12038    	1  	active sync   /dev/xvdav6
  	3 	202	12039    	2  	active sync   /dev/xvdav7

Chiffrement de données

Sécurisation WiFi par WPA2-EAP

Exploitation de failles du système

Interconnexion Internet de secours (IPv6)

Interconnexion Internet de secours (IPv4)

Séance 6