TP sysres IMA5sc 2018/2019 G11
Sommaire
Présentation générale
Lors de ce TP nous allons apprendre à utiliser docker. Dans un premier temps nous réaliserons à la main 3 dockers interconnectés à l'aide d'un commutateur virtuel puis nous utiliserons directement la solution Docker. Ensuite nous travaillerons avec l'ensemble de la promotion au montage d'une infrastructure réseau complète, notre binôme aura pour tâche spécifique la configuration d'un routeur en plus des tâches individuelles de chaque binômes.
Déroulé du TP
Conteneur à la main
Séance 1 : 12/11/2018
Etapes réalisées : création de 3 systèmes de fichiers c1,c2,c3
On peut vérifier l'isolation de nos conteneurs en faisant df -h ou une fois le unshare réalisé en tapant le ps aux
création du commutateur virtuel : monpont.
On peut vérifier sa bonne activation avec la commande : brctl show
création des interfaces virtuel
Pour chacun des conteneurs on va créer une interface virtuel vifX qui relieront chacune "monpont" à un conteneur. Un des conteneurs sera relié au bridge de la zabeth afin de nous relier au monde extérieur, ce sera lui le mandataire inverse. Pour nous il s'agit de C1. On peut vérifier la bonne liaison entre le conteneur et le commutateur logiciel en tapant ip l dans chacun des conteneurs et en regardant les interfaces reliées à brctl show.
Attention, parfois Docker est source de problèmes pour nos manipulations, pour s'en débarrasser on tape les commandes suivantes :
iptables -F iptables -F -t nat iptables -P FORWARD ACCEPT
On va maintenant ajouter une IP à chaque interface virtuel pour être capable réaliser un ping depuis le réseau.
Pour cela on se sert de ip address add et de ip route add.
sur chaque conteneur : ip address add dev eth0 192.168.0.x ip l set eth0 up
on vérifie en faisant ip r et on peut pinger nos machines entres elles !
Attention : tout les ip add seront supprimées au prochain reboot. Probablement de même pour les interfaces virtuels.
Séance 2 : 19/11/2018
Objectif de la séance : installer reverse proxy sur un conteneur et 2 serveurs web sur les autres.
Lors du démarrage de la séance pour ressusciter ce que l'on avait fait la dernière fois:
mkdir c1,c2,c3
copie base fichiers
export https_proxy="https://proxy.polytech-lille.fr:3128" export http_proxy="http://proxy.polytech-lille.fr:3128" debootstrap --include=apache2,vim stable /tmp/c1 // de même pour c2 et c3
Montage media
mount -o loop /home/pifou/firstconteneur /tmp/c1 // de même pour c2 et c3 mount -o loop /home/pifou/firstconteneur2 /tmp/c2 mount -o loop /home/pifou/firstconteneur3 /tmp/c3
Création machine
unshare -p -f -m -n -u chroot /tmp/c1 /bin/sh -c "mount /proc ; /bin/bash" unshare -p -f -m -n -u chroot /tmp/c2 /bin/sh -c "mount /proc ; /bin/bash" unshare -p -f -m -n -u chroot /tmp/c3 /bin/sh -c "mount /proc ; /bin/bash"
Création du commutateurs virtuels et des interfaces virtuels
ip link add vif1 type veth peer name eth0@vif1 ip link add vif2 type veth peer name eth0@vif2 ip link add vif3 type veth peer name eth0@vif3 ip link add vif4 type veth peer name eth0@vif4
ip link set vif1 master monpont ip link set vif2 master monpont ip link set vif3 master monpont ip link set vif4 master monpont
Activation de monpont et des vifs
ip link set dev monpont up ip link set dev vif1 up ip link set dev vif2 up ip link set dev vif3 up ip link set dev vif4 up
Connection: (numero de PID arbitraire)
ip link set eth0@vif2 netns /proc/27880/ns/net name eth0 // pour vif 1 ip link set eth0@vif2 netns /proc/27879/ns/net name eth0 // pour vif 2 ip link set eth0@vif2 netns /Bcanuproc/27881/ns/net name eth0 // pour vif 3 ip link set eth0@vif2 netns /proc/27882/ns/net name eth0 // pour vif 4
(numéro de PID arbitraire) nsenter -t 27879 -n ip address add dev eth0 192.168.0.2/24 //pour C1 nsenter -t 27880 -n ip address add dev eth0 192.168.0.3/24 //pour C2 nsenter -t 27881 -n ip address add dev eth0 192.168.0.4/24 //pour C3
pour eth1, on cherche une IP valable dans le réseau du bridge, soit une IP qui ne donne rien quand on la ping puis :
nsenter -t 27879 -n ip address add dev eth1 172.26.145.45/24 // pour que c1 soit le mandataire inverse ip link set eth1 up // dans le conteneur c1
Dans chaque conteneur :
ip link set eth0 up ip link set dev lo up
Nous pouvons à présent pinger les 3 machines entre elles et depuis la machine physique.
Paramétrage du mandataire inverse :
On inscrit sur gandi.net 2 sitBcanues : websiteun et websitedeux.
Dans etc/apache2/sites-available/000-default.conf de notre conteneur C1 qui fait office de mandataire inverse:
< VirtualHost *:80> ServerName websinteun.plil.space ProxyPass "/web1" "http://192.1680.3/" ProxyPassReverse "/web1" "http://192.168.0.3/"
ProxyPass "/web2" "http://192.1680.4/" ProxyPassReverse "/web2" "http://192.168.0.4/"
ProxyRequests Off </VirtualHost >
ip route add default via 172.26.145.254
Il faut démarrer le serveur apBcanupache sur les deux conteneurs de base.
Au final nous pouvons accéder à nos deux conteneurs selon l'URL rentrée :
websiteun.plil.space/ --> accès sur le conteneur C2 websitedeux.plil.space/ --> accès sur le conteneur C3
11h25 => Serveurs Web OK (unshare)
Docker
Séance 2 : 19/11/2018
résumé des tâches à réaliser
1- docker run -t -i debian 2- installer apache et vi (export http htpps si besoin) 3- en dehors du conteneur : docker commit monNom pour sauvegarder l'image de ce conteneur 4- on peut sortir 5- docker image 6-réseau privé: docker network create à faire avant 7- lancer 3 docker --net nomdemonreseau avec un conteneur que je lance en --p:80.
Réalisation:
Dans etc/default/docker : on doit commenter Docker opts ="--iptables=false"
service docker restart iptables-save
Ensuite on peut lancer notre docker avec
docker run -t -i debian
Puis on exporte les variables d'environnements pour le proxy et on peut faire
apt update apt install apache2 apt install vi
Ensuite on sort du conteneur en faisant exit
docker image //nous permet de voir les différents docker disponible docker commit ID debian_apache// nous permet de sauvegarder ce docker avec cette configuration
On crée le réseau privé : docker network create OurReseau
On peut lancer 3 dockers en parrallèle : docker run -i -t --network=OurReseau debian_apache docker run -i -t --network=OurReseau debian_apache docker run -i -t --network=OurReseau -p:80 debian_apache // Docker écoute sur le port 80
On récupère les adresses ip des deux conteneurs serveur web en faisant:
ip a
Dans notre docker mandataire inverse on vient copier le même fichier de configuration que pour le conteneur à la main en pensant juste à modifier les ip Il ne faut pas oublier d'activer proxy et proxyhttps avec a2enmod
Ensuite sur gandi on crée deux nouveaux sites et un nouveau mandataire. On configure avec l'ip de la zabeth.
On teste les adresses suivantes : c2.plil.space c1.plil.space
On constate que tout fonctionne parfaitement!
12h50 : Serveurs WEB (docker) OK
Réseau avancé
Séance 1 : 26/11/2018
Analyse et choix d'organisation
Nous avons choisi la partie numéro 2 à savoir la configuration du routeur 4221
Avant de commencer à configurer le routeur nous nous sommes mis d'accord avec le groupe s'occupant de l'autre routeur ainsi que celui s'occupant du point d'accès pour l'organisation et la répartition des différentes adresses IP. Il a également fallu vérifier ce que le groupe des IMA2A avait fait pour ne pas entrer en collision avec ce qu'ils ont fait.
Voici ce que les IMA2A ont fait :
| Nom | Vlan | Réseau IPV4 | Réseau IPV6 | IP Routeur 1 | IP Routeur 2 | IP Routeur Virtuel |
|---|---|---|---|---|---|---|
| Xen | 42 | 193.48.57.160/28 | 2001.660.4401.60B1::/64 | 193.48.57.174/28 | 193.48.57.173/28 | 193.48.57.172/28 |
| Groupe 1 | 2 | 10.60.1.0/24 | 2001.660.4401.60B2::/64 | 10.60.1.254/24 | 10.60.1.253/24 | 10.60.1.252/24 |
| Groupe 2 | 3 | 10.60.2.0/24 | 2001.660.4401.60B3::/64 | 10.60.2.254/24 | 10.60.2.253/24 | 10.60.2.252/24 |
| Groupe 3 | 4 | 10.60.3.0/24 | 2001.660.4401.60B4::/64 | 10.60.3.254/24 | 10.60.3.253/24 | 10.60.3.252/24 |
| Groupe 4 | 5 | 10.60.4.0/24 | 2001.660.4401.60B5::/64 | 10.60.4.254/24 | 10.60.4.253/24 | 10.60.4.252/24 |
| Groupe 5 | 6 | 10.60.5.0/24 | 2001.660.4401.60B6::/64 | 10.60.5.254/24 | 10.60.5.253/24 | 10.60.5.252/24 |
| Interconnexion | 130 | 192.168.222.0/29 | Router1 : fe80::42:2 // Router2 : fe80::42:3 // Ecole : fe80::42:1 | 192.168.222.1/29 | 192.168.222.2/29 |
On remarque que les adresses prises par eux se trouvent après 193.48.57.174/28 ce qui nous laissent toutes les adresses inférieures.
Pour le réseau 10.60.X.0/24 nous pouvons prendre les adresses avec X >5
On peut donc attribuer d'ores et déjà les adresses suivantes :
193.48.57.188 Routeur 1
193.48.57.189 Routeur 2
193.48.57.190 Machine virtuel
On attribue donc les adresses suivantes sur le Réseau IPV4
on a choisi la convention suivantes : les groupes obtiennent l'ip 10.60.10+numeroDeGroupe.0/24
Configuration du commutateur
Connexion avec Minicom
Nous nous sommes connectés directement via USB au routeur pour ensuite taper les commande suivantes
demesg | grep tty // nous permet de vérifier que nous sommes bien connectés au commutateur minicom -os
Dans minicom on indique les informations de configuration :
baudrate : 9600 /ttyACM0 Hardware flow control : No
Configuration du commutateur
Nous avons 3 port GIGABIT disponible, GIGABIT 0 : relié au commutateur de l'école GIGABIT 1 : relié au commutateur 4006 par fibre GIGABIT 2 : relié au commutateur 6000 par cuivre
pour connaitre les interfaces disponibles:
show run
D'autres commandes de bases très utiles :
write // permet de sauvegarder la configuration
Configuration de l'interface pour le commutateur de l'école :
enable // passage en root configure terminal interface GigabitEthernet0/0/1 no ip address negotiation auto service instance 11 ethernet encapsulation dot1q 11 rewrite ingress tag pop 1 bridge-domain 11
service instance 12 ethernet encapsulation dot1q 12 rewrite ingress tag pop 1 bridge-domain 12
service instance 13 ethernet encapsulation dot1q 13 rewrite ingress tag pop 1 bridge-domain 13
...Et ainsi de suite jusque:
service instance 21 ethernet encapsulation dot1q 21 rewrite ingress tag pop 1 bridge-domain 21 service instance 43 ethernet encapsulation dot1q 43 rewrite ingress tag pop 1 bridge-domain 43 service instance 131 ethernet encapsulation dot1q 131 rewrite ingress tag pop 1 bridge-domain 131
Configuration des BDI :
On vient ici indiquer une adresse IP à chaque Vlan
interface BDI11 ip address 10.60.11.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.11.254
interface BDI12 ip address 10.60.12.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.12.254
interface BDI13 ip address 10.60.13.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.13.254
interface BDI14 ip address 10.60.14.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.14.254
interface BDI15 ip address 10.60.15.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.15.254
interface BDI16 ip address 10.60.16.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.16.254
interface BDI17 ip address 10.60.17.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.17.254
interface BDI18 ip address 10.60.18.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.18.254
interface BDI19 ip address 10.60.19.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.19.254
interface BDI20 ip address 10.60.20.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.20.254
interface BDI21 ip address 10.60.21.253/24 255.255.255.000 standby version 11 standby 11 ip 10.60.21.254
Séance 2 : 26/11/2018
Configuration du commutateur suite
Séance 3 : 10/12/2018
spanning tree
Spanning-tree pvst
Nous permet d'éviter le rebouclage ARP entre les routeurs.
fin de configuration du routeur
root@cordouan:/home# lvcreate -L10G -n IMA5-Ate-home virtual
Logical volume "IMA5-Ate-home" created.
root@cordouan:/home# lvcreate -L10G -n IMA5-Ate-var virtual
Logical volume "IMA5-Ate-var" created.
2.1 Installation dans la machine virtuelle Xen
Nous allons ici partitionner var et home pour notre VM:
4 Services Internet
4.1 Serveur ssh
Activation de ssh (déjà installé) :
sudo systemctl enable ssh sudo systemctl start ssh
4.2 Serveur DNS
En attendant que le certificat SSL de notre serveur soit validé, on commence à configurer notre serveur DNS pour en faire un DNSSEC (un DNS sécurisé).
Dans un premier temps, nous installons apache2 et bind9 dans notre VM. apache2 va nous permettre de gérer notre siteweb et bind9 de gérer le serveur DNS.
apt update apt-get install bind9 dnsutils apt-get install apache2
Configuration sur Gandi
Sur Gandi, une plateforme d'enregistrement notamment des sites webs et DNS, nous achetons un nom de domaine :
ate2.space
Nous voulons ensuite que notre site web puisse être accessible depuis l'extérieur, notamment grâce à un DNS personnel. Pour cela, nous enregistrons un nouveau serveur DNS dans Gandi qui ne sera visible que dans notre domaine. Nous affectons l'adresse ip de notre VM à ce DNS:
A présent que le DNS est créé, il faut préciser qu'on souhaite qu'il soit utilisé pour la recherche de notre site web.
Configuration sur la VM
A présent, on doit configurer notre VM afin de jouer le rôle de serveur DNS.
Pour cela, tout se fera dans le répertoire /etc/bind.
Dans un premier temps, on crée un fichier de config db.ate2.space :
@ IN SOA ns.ate2.space. root.ate2.space (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.ate2.space
@ IN A 193.48.57.187
ns IN A 193.48.57.187
www IN A 193.48.57.187
Ensuite on va configurer l'espace de noms, dans named.conf.local pour lui préciser quel fichier de configuration utiliser pour le DNS :
zone "ate2.space" {
type master;
file "/etc/bind/db.ate2.space";
allow-transfer{none;}; //Précise si il doit questionner d'autres serveurs DNS jusqu'à trouver l'adresse correspondante
};
On active le serveur DNS, avec named.conf.options :
options {
directory "/var/cache/bind";
//............//
dnssec-enable yes;
dnssec-validation auto;
listen-on-v6 { any; };
allow-recursion { localhost; };
};
Et finalement on redémarre le service Bind9 :
service bind9 restart
On vérifie si le domaine est accessible avec la commande suivante :
host ate2.space
Séance 4 : 17/12/2018
Configuration routeur
Lors de la semaine le routeur, probablement lors d'un shutdown, s'est rallumé en pointant vers le mauvais os ce qui a eu pour effet de modifier la configuration pour cause d'incompatibilité. A notre arrivée le VLAN1 était down sans que l'on comprenne pourquoi. Tout d'abord la configuration du Vlan1 doit se faire sans encapsulation et untag. Cependant le problème a subsisté.
Après quelques recherches nous n'avons pas trouvé l'origine du problème cependant un simple reload du router à réglé le problème. Toutefois Le fait de changer le vlan en untag empêche le spanning tree de fonctionner et ne nous protège donc pas d'un effondrement du réseau par appel récursif de paquets. Nous avons donc du nous résoudre à ne laisser qu'un seul vlan1 sur un des deux routeurs pour éviter ce problème.
4.3 Sécurisation de site web par certificat
Création du certificat avec OpenSSL
On génère avec OpenSSL deux fichiers, ate.csr et ate.space.key qui contiennent respectivement le Certificate Signing Request (CSR) et la clé.
openssl req -nodes -newkey rsa:2048 -sha1 -keyout ate.space.key -out ate.csr -rsa:2048 -sha1 : représente la méthode de chiffrement -newkey : demande une nouvelle clé
Sur Gandi on va pouvoir acheter le certificat. On lui transmet le .csr généré, qui regroupe toutes les informations sur notre entité. Gandi créera alors un certificat SSL pour notre serveur. Cependant, Gandi doit être certaine que ce certificat est bien pour l'entité qui la demande et non pour une personne tierce qui essaierait de se faire passer pour un autre serveur. Pour se faire, il y a plusieurs méthode d'authentification: - par mail - par fichier - par DNS Nous avons choisi l'authentification par fichier. Gandi génère alors un fichier contenant un nom et un contenu généré aléatoirement. On doit placer ce fichier dans notre serveur dns. Il est alors accessible par l'extérieur. Gandi peut alors le visualiser et déterminer ainsi qu'on est bien le propriétaire du serveur. Si ce n'était pas le cas, nous n'aurions pas pu mettre ce fichier sur le serveur officiel. Gandi n'aurait alors pas pu visualiser le fichier et ne nous aurait pas validé le certificat.
La validation a pris 4 heures. Gandi nous a ensuite délivré le certificat.
On place alors la clé, le certificat intermédiaire et le certificat final aux emplacements suivants :
/etc/ssl/certs/GandiStandardSSLCA2.pem
/etc/ssl/certs/ate2.space.crt
/etc/ssl/private/ate2.space.key
Ensuite on ajoute ces fichiers dans une nouvelle configuration dans /etc/apache2/sites-available : 000-neptune-poseidon.space-ssl.conf
<VirtualHost 193.48.57.187:443>
ServerName www.ate2.space
ServerAlias ate2.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/ate2.space.crt
SSLCertificateKeyFile /etc/ssl/ate2.space.key
SSLCertificateChainFile /etc/ssl/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>
Dans ce même fichier on ajoute une redirection pour être toujours connecté en https :
---------------------------
<VirtualHost 193.48.57.187:80>
ServerName www.ate2.space
ServerAlias ate2.space
Redirect / https://ate2.space
</VirtualHost>
On active le module ssl :
a2enmod ssl
On se place dans le répertoire : /etc/apache2/site-enabled/, puis on active notre configuration ssl :
a2ensite 000-ate2.space-ssl.conf
On relance le service apache2 :
service apache2 restart
Configuration d'apache2
4.4 Sécurisation de serveur DNS par DNSSEC
Maintenant que notre domaine est accessible par notre DNS, nous voulons rendre la liaison sécurisé. On va donc configurer notre serveur DNS en mode "secure"
On va générer des clés KFK et ZSK avec l'algorithme RSA/SHA-1.
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE ate2.space dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE ate2.space
On récupère alors 4 fichiers. Chaque couple de fichier correspond une des 2 clés. Dans ce couple, le fichier contient soit la clé publique, soit la clé privée.
On va alors les renommer en gardant leurs suffixes, mais en précisant quelle clé correspond à quoi:
ate2.space-kfk.key //clé publique ate2.space-kfk.private //clé privée ate2.space-zsk.key ate2.space-zsk.private
On retourne ensuite dans le fichier de configuration créé pour notre DNS : db.ate2.space.
On va rajouter le chemin des 2 clés générées:
$include /etc/bind/ate2.space-ksk $include /etc/bind/ate2.space-zsk
Ces deux lignes sont à rajouter après TTL 604800
On va à présent signer une zone, cela va crypter le fichier de configuration du DNS, qui sera utilisé pour les futures requêtes au DNS.
dnssec-signzone -o ate2.space -k ate2.space-ksk ../db.ate2.space ate2.space-zsk
On restart le service bind
Et on entre les 2 clés publiques générées dans Gandi.
5 Tests d’intrusion
5.2 Cassage de clef WEP d’un point d’accès Wifi
En suivant la même logique que pour le crackage de clé WAP:
airmon-ng airmon-ng start wlan0 airodump-ng --encrypt wep wlan0mon
On récupère les informations de cracotte10 et on lance la commande:
airodump-ng -c 12 –-bssid 04:DA:D2:9C:50:53 -w /root/Desktop/WEP wlan0mon
Et on force la connection avec :
aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:59 wlan0mon
une fois récupéré un nombre significatif de date, environ 100 000, nous allons arrêter le processus et lancer la commande suivante :
aircrack-ng WEP.cap
On obtient ainsi la clé WEP de notre point d'accès!
5.3 Cassage de mot de passe WPA-PSK par force brute
Pour le cassage de la clé WPA nous allons :
- récupérer les fichiers de handshake - générer un dictionnaire contenant toutes les possibilités de mot de passe - lancer le brute force du handshake
Nous avons utilisé un ordinateur portable (possédant donc une carte wifi) puis utilisé l'utilitaire suivant :
airmon-ng
On connait à présent le nom de l'interface et on s'y connecte en mode moniteur pour analyser le réseau :
passage en mode moniteur :
airmon-ng start wlan0
affichage du trafic:
airodump-ng wlanS0mon
On récupère ensuite le nom du wifi que l'on veut craquer, dans notre cas ce sera cracotte10
BSSIID de cracotte: 04:DA:D2:9C:50:59 channel : 9
On fait le handshake :
airodump-ng -c 9 –-bssid 04:DA:D2:9C:50:59 -w /root/Desktop/Amaury wlanS0mon
Après avoir attendu un certain temps nous avons récupéré les fichiers suivants :
Amaury-01.cap Amaury-01.csv Amaury-01.kismet.csv Amaury-01.kismet.netxml
Nous avons ensuite générer le dictionnaire contenant toutes les possibilités de mot de passe, il s'agit simplement d'un fichier texte contenant tout les nombres de 0 à 100000000.
On peut réaliser le crackage de la clé :
aircrack-ng -a2 -b 04:DA:D2:9C:50:59 -w /root/Desktop/Dictionnary.txt /root/Desktop/*.cap
-a indique la méthode de crack
Nous avons après plusieurs heures obtenus la clé WAP du point d'accès!
6 réalisation
6.1 Sécurisation de données avec RAID5
Nous allons ensuite créer 4 partitions LVM de 1Go sur Cordouan avec des noms liés à notre VM :
lvcreate -L1G -n /dev/virtual/AteRaid1 -v lvcreate -L1G -n /dev/virtual/AteRaid2 -v lvcreate -L1G -n /dev/virtual/AteRaid3 -v lvcreate -L1G -n /dev/virtual/AteRaid4 -v // utile pour 6.2
On modifie alors le fichier de configuration de notre machine afin d'ajouter les partitions précédentes à notre machine virtuelle. Dans /etc/xen/Ate.cfg :
'phy:/dev/virtual/AteRaid1,xvda5,w', 'phy:/dev/virtual/AteRaid2,xvda6,w', 'phy:/dev/virtual/AteRaid3,xvda7,w'
On relance enfin notre VM :
xl shutdown Ate xen create Ate.cfg
On peut donc générer un système RAID5 logiciel à l'aide des 3 partitions obtenues :
Sur la Xen
apt-get install mdadm
mdadm --create /dev/md127 --level=5 --assume-clean --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
On formate le RAID5 créé:
mkfs -t ext4 /dev/md127
On le monte sur notre VM:
mount /dev/md127 /mnt
6.2 Cryptage de données
Le but ici est de formater un volume en mode crypté.
Nous utiliserons ici le volume créé juste au dessus AteRaid4 sur la Zabeth11 correspondant au xvda8 de notre VM
on l'ajoute au fichier de configuration de notre VM sur Corduan en tant que volume physique.
disk = [
'file:/usr/local/xen/domains/Ate/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Ate/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-Ate-home,xvda3,w',
'phy:/dev/virtual/IMA5-Ate-var,xvda4,w',
'phy:/dev/virtual/ateRaid1,xvda5,w',
'phy:/dev/virtual/ateRaid2,xvda6,w',
'phy:/dev/virtual/ateRaid3,xvda7,w',
'phy:/dev/virtual/ateRaid4,xvda8,w'
]
Ensuite sur notre VM, on installe cryptsetup et LVM2
On va à présent configurer notre volume pour le rendre crypté, inaccessible sans le mot de passe.
Formatage de la partition avec encryptage :
cryptsetup luksFormat -c aes -h sha256 /dev/xvda8
On crée ensuite un volume virtuel (home_encrypted) sur le volume physique (xvda8)
cryptsetup luksOpen /dev/xvda8 home_crypted
On nous demande alors un mot de passe pour les prochaines connexions
On formate notre volume en ext4
mkfs -t ext4 /dev/mapper/home_encrypted
On le monte ensuite sur /mnt
mount -t ext4 /dev/mapper/home_crypted /mnt/
On y crée un fichier /mnt/testFile
On démonte /mnt
umount /mnt
Puis on ferme la communication sur le volume crypté
cryptsetup luksClose home_crypted
A présent, on ne peut plus avoir accès au volume /dev/mapper/home_crypted tant qu'on en s'est pas reconnecté avec cryptsetup
Pour pouvoir y raccéder, il suffit:
cryptsetup luksOpen /dev/xvda8 home_crypted mount -t ext4 /dev/mapper/home_crypted /mnt/
Et normalement, on devrait retrouver notre fichier testFile
6.5 Freeradius
FreeRadius est un serveur modulaire, aujourd'hui nous l'utiliserons pour l'authentification sur notre réseau pour les utilisateurs d'un point d'accès Wifi.
configuration du Point d'accès :
enable
conf t aaa new-model aaa group server radius radius_group21 server 193.48.57.180 auth-port 1812 acct-port 1813 radius-server host 193.48.57.180 auth-port 1812 acct-port 1813 key secretIMA5SC exit aaa authentication login eap_group21 group radius_group21 end
conf t dot11 ssid Hades vlan 21 authentication open eap eap_group21 authentication network-eap eap_group21 authentication key-management wpa Mbssid Guest-mode end
conf t int dot11radio0 Mbssid ssid Hades encryption vlan 21 mode ciphers aes-ccm tkip
conf t int dot11radio0.11 encapsulation dot1Q 21 end conf t int dot11radio0.11 encapsulation dot1q 21 bridge-group 21 end
Attention si on souhaite relancer FreeRadius ne pas oublier de kill le processus précèdent sinon la connexion ne pourra pas se faire le port étant déjà pris!
Nous avons pu confirmer la connexion entre notre serveur freeRadius et le point d'accès.
