Atelier SysRes SE4 2025/2026 E10

De wiki-se.plil.fr
Aller à la navigation Aller à la recherche

Informations utiles

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.

ssh root@capbreton

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.

xen-create-image --hostname=SE4-TomPere2 --dhcp --bridge=pont_pere --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

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 :

xen create /etc/xen/SE4-TomPere2.cfg
xen console SE4-TomPere2

Vérification

Remarque : On peut vérifier que les machines virtuelles en cours d’exécution grâce à xen list .

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

Comme on le voit, nos 3 machines sont démarrées !

Partionnage

Configuration

On ajoute dans le fichier /etc/xen/SE4-Tompere2.cfg nos partitions home et var.

    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',
                ]

Montage des partitions

mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
mkfs -t ext4 /dev/xvda3
mount -a

Le montage des partitions est fait ! On peut par ailleurs le voir via lsblk. Cependant, au redémarrage de la VM, les partitions ne seront pas automatiquement montées. Ainsi, il faut modifier le fichier /etc/fstab:

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

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 /etc/network/interfaces.

Sur ma machine de services TomPere2 :

auto eth0
	iface eth0 inet static
		address 192.168.0.3
		netmask 255.255.255.0
		gateway 192.168.0.1

et sur la machine mandataire TomPere0 :

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

Après un ifdown eth0 puis ifup eth0 pour charger les modifications apportées, cette configuration nous a permis de voir l'adresse IPV4 correspondante à eth0 avec la commande ip address.

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

Résultat

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.

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

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 /etc/ssh/sshd_config des VMs et activer la directive PermitRootLogin.

PermitRootLogin yes

Désormais, l'accès de root à distance est autorisé. On peut donc se ssh de TomPere2 vers TomPere1 et inversement !

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

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 :

Nom de la VM Port de redirection associé
TomPere1 2201
TomPere2 2202

Dans le fichier /etc/sysctl.conf:

net.ipv4.ip_forward=1

Ensuite nous activons la translation d'adresse NAT.

iptables -t nat -A POSTROUTING -j MASQUERADE

Remarque : Pour que ces changements soient persistants, il faut installer le paquet iptable-persistent.

nft add chain PREROUTING
nft add rule NAT PREROUTING tcp dport 2201 dnat to 192.168.

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 bind9 avec apt.

Ensuite, il faut configurer un fichier de zone : /etc/bind/zones/tompere2_xyz/tompere2.xyz.

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

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, 193.48.57.168 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 named-checkzone.

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 /etc/bind/named.conf.local

    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; };
    };

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 : 193.48.57.168
    • IPv6 : 2001:660:4401:60a0:216:3eff:fe3f:9410

DNSSEC

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


En effet, nous allons rajouter ces lignes dans zone "tompere2.xyz"

De plus, il faut ajouter

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

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 /bind/keys

mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys

Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.

systemctl restart named
systemctl enable named

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 :

Remarque : Nous avons également utilisé dig 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.

Le DNS a bien été déployé partout dans le monde !
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.

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

Objectif

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

Réalisation

Installation du paquet

apt update

apt install apache2

Paramètrage sur machine mandataire

Avant de commencer, il nous faut activer quelques modules permettant le bon fonctionnement d'Apache.

  • a2enmod ssl : active le module SSL pour permettre les connexions sécurisées en HTTPS (TLS) avec certificats.
  • a2enmod proxy : active les fonctionnalités de reverse proxy, permettant à Apache de rediriger les requêtes vers un autre serveur.
  • a2enmod proxy_http : active le support du proxy pour le protocole HTTP.

Sur la machine mandataire, nous avons créé et rempli le fichier /etc/apache2/sites-available/000-tompere2.xyz-ssl.conf

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

Ce fichier permet à la machine mandataire de gérer l’accès au site tompere2.xyz. Dans le fichier /var/www/html/index.html, nous avons modifié le titre pour pouvoir visualiser que les changements étaient bien pris en considération.

<title>Tom et Aurele Page: It works</title>

Résultat

Finalement, nous obtenons bien un accès au site tompere2.xyz avec le nouveau titre !

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étecter ces tentatives répétées et bloquer automatiquement les adresses IP malveillantes.

Réalisation

Installation du paquet

apt update

apt install fail2ban

Définition du Fail2Ban

Dans le fichier /etc/fail2ban/jail.local de la machine mandataire, nous pouvons définir la façon dont le fail2ban va agir.

[sshd]
enabled = true
port = ssh
filter = sshd
ignoreip = 127.0.0.1
findtime = 10m
bantime = 5m
maxretry = 3

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 airodump-ng. Pour ce faire, nous devons tout d'abord trouver le nom de la carte réseau. On peut trouver cela via ip link.

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

Ensuite, on scanne grâce à:

sudo airodump-ng wlx40a5efd2140c --essid cracotte10

Nous obtenons :

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

L'adresse MAC de cracotte10 est donc

04:DA:D2:9C:50:59

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

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

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.

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

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

KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]

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

sudo airodump-ng wlx40a5efd2140c --essid kracotte10

Nous obtenons :

 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

L'adresse MAC de kracotte10 est donc

44:AD:D9:5F:87:09

Dictionnaire

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

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

crunch 8 8 0123456789 -o 8numbers_dico.txt

Handshake

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

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

Cassage de la clef WPA-PSK

Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:

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

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.

	                               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

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

Récupérée de « http:///mediawiki/index.php?title=Atelier_SysRes_SE4_2025/2026_E10&oldid=12360 »