Atelier SysRes SE4 2025/2026 E9

De wiki-se.plil.fr
Révision datée du 1 mars 2026 à 20:30 par Avanghel (discussion | contributions)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à la navigation Aller à la recherche

note : si vous voyez des noms entre chevrons, changez-les !

Creation des VMs

se connecter au serveur de promo

Toutes les machines virtuelles sont hébergées sur le serveur capbreton, nous nous y connectons donc: 

ssh root@capbreton

Le mot de passe est fourni par l'enseignant.

Attention ! Le serveur est commun à toute la promo et vous êtes en root, donc attention aux rm et mv !

Initialement, on ne pourra se connecter à nos VMs que par capbreton, on corrigera cela lorsque nous exposerons à internet nos VMs.

Creation du commutateur virtuel

Pour que les VMs puissent communiquer entre elles et pour bien séparer les réseaux des binômes, on crée un commutateur virtuel sur le serveur. On crée donc un fichier dans interfaces.d: 

vim /etc/nbetwork/interfaces.d/SE4_<login1>_<login2>

dans lequel on écrit: 

auto <nom_bridge>
iface <nom_bridge> inet manual
    bridge_ports none
    up ip link set $IFACE up
    down ip link set $IFACE down

On active l'interface virtuelle avec : 

ifup <nom_bridge>

initialisation des VMs

pour chacune des 2 VMs de service et la VM mandataire, on crée une image : 

xen-create-image --hostname=<nom_VM>  --dhcp --bridge=<nom_bridge> --dir=/usr/local/xen --size=10G --dist=excalibur --memory=2048M --force

on démarre les VMs avec : 

xen create /etc/xen/<nom_VM>.cfg

et on ouvre le terminal des VMs avec: 

xen console <nom_VM>

sur capbreton, vérifiez que vos VMs sont bien toutes présentes : 

xen list

mots de passe

vous pouvez simplement afficher le mot de passe de vos VMs avec la commande : 

cat /var/log/xen-tools/<nom_VM>.log | grep Password

chaque VM a initialement un mot de passe long et difficile à retenir, mais sûr. Il est recommandé de le laisser tel quel. vous pouvez toutefois le changer avec : 

vim /etc/xen/<nom_VM>.cfg

A partir d'ici, vous devriez avoir accès à vos 3 VMs.

montage des partitions

Nous allons ajouter des partions à nos VMs de service, donc pour seulement deux des trois VMs. On crée des volumes virtuels avec : 

lvcreate -n <nom_VM>.var -L 10G virtual
lvcreate -n <nom_VM>.home -L 10G virtual

Lorsque on exécute ces commandes, on nous demande où placer ces volumes. Placez-les sur un disque où de l'espace est disponible, "storage" par exemple. Eteignez ensuite les VMs: 

xen shutdown <nom_VM>

Editez le fichier de configuration de chaque VM: 

vim /etc/xen/<nom_VM>.cfg

ajoutez dans disk : 

'phy:/dev/virtual/<nom_VM>.home,xvda3,w',
'phy:/dev/virtual/<nom_VM>.var,xvdb1,w'

ajoutez dans /etc/fstab : 

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

formatez avec : 

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

puis montez avec : 

mount /dev/xvda3 /mnt
mount /dev/xvdb1 /mnt
mv /var/* /mnt
mv /home/* /mnt
umount /mnt
mount -a

puis relancez les VMs de service avec 

xen create

et 

xen console

.

Configuration réseau des VMs

 

Configuration des interfaces

Nous allons maintenant configurer les interfaces des VMs: 

vim /etc/network/interfaces

 On souhaite une adresse statique en IPv4 et une adresse fournie par DHCP en ipv6. nous allons donner l'adresse IPv4 avec le format suivant: 192.168.<numéro_binôme>.X avec X prenant une valeur différente pour chaque VM.

ce qui nous donne la configuration des machines de service : 

auto lo
iface lo inet loopback

#statique ipv4
auto eth0
iface eth0 inet static
    address 192.168.<numéro_binôme>.<numéro_VM_service>/24
    gateway 192.168.<numéro_binôme>.<numéro_VM_mandataire>

#dhcp ipv6
auto eth0
iface eth0 inet6 auto

de plus, sur la mandataire, il faut ajouter une seconde interface dans le fichier de configuration pour pouvoir l'exposer au bridge de promotion.

on éteint la machine mandataire et on édite la partie 

vif

du fichier 

/etc/xen/<nom_VM>.cfg

et on y ajoute: 

'mac=00:11:22:33:44:<numéro_binôme>,bridge=SE4'

On redémarre la mandataire et on édite les interface comme il suit: la variable <valeur_unique_au_binôme> est supérieure à 164 et unique pour chaque binôme, n'oubliez pas de la renseigner. (162 VRRP, 163 Routeur1, 164 Routeur2) 

auto lo
iface lo inet loopback

#statique ipv4
auto eth0
iface eth0 inet static
    address 192.168<numéro_binôme>.<numéro_VM_mandataire>/24

auto eth1
iface eth1 inet static
    address 193.48.57.<valeur_unique_au_binôme>/24
    gateway 193.48.57.162
#dhcp ipv6
auto eth1
iface eth1 inet6 auto

pour chaque interface configurée, on la redémarre: 

ifdown <interface>
ifup <interface>

Configuration du dns

dans 

 /etc/resolv.conf

sur les 3 machines, ajoutez: 

nameserver 8.8.8.8

cela nous donnera un serveur dns par défaut (on pourra vérifier le fonctionnement en faisant 

ping google.com

dans le terminal)


Installation des packages

Sur les machines de service on met à jour et on installe: 

apt update
apt upgrade
apt install ssh bind9 apache2 iptables dnsutils openssl fail2ban

pour pouvoir nous connecter en ssh de l'extérieur, il est nécessaire d'éditer 

/etc/ssh/sshd_config

: Il faut retrouver le paramètre 

PermitRootLogin

et le mettre à 

yes

, ou bien on peut l'ajouter en exécutant: 

echo "PermitRootLogin = yes" > /etc/ssh/sshd_config

on valide les changements en exécutant: 

/etc/init.d/ssh restart

Méthodes de routage IPv4

Mascarade

pour pouvoir router nos VMs de service en IPv4, on va d'abord utiliser la mascarade (si vous perdez accès à internet sur les machine de service avec la méthodes suivante, référez-vous à celle-ci). 

iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.168.<numéro_binôme>.<numéro_VM_mandataire>/24

on peut se connecter depuis l'extérieur vers nos machines de service en faisant une chaîne de ssh :pc_personnel -> machine mandataire -> machine de service.

Redirection de port

Cette méthode nous permettra de nous connecter en ssh sur les machines de service depuis la mandataire en nous connectant sur d'autres ports. sur la mandataire on exécute: 

iptables -t nat -A PREROUTING -p tcp --dport 2202 -j DNAT --to-destination 192.168.<numéro_binôme>.<numéro_VM1>:22
iptables -t nat -A PREROUTING -p tcp --dport 2203 -j DNAT --to-destination 192.168.<numéro_binôme>.<numéro_VM2>:22

et on active la redirection de port avec: 

echo "net.ipv4.ip_forward=1" > /etc/sysctl.conf

sur la mandataire

On peut alors se connecter en ssh sur nos machines de service depuis l'extérieur en changeant le port: 

ssh root@193.48.57.<valeur_unique_au_binôme> -p2202

ou 

ssh root@193.48.57.<valeur_unique_au_binôme> -p2203

on sauvegarde pour avoir une configuration persistante avec: 

iptables-save


Serveurs DNS

Création des noms de domaine

On choisit et achète deux noms de domaine auprès de gandi.net avec les logins fournis par l'enseignant avec un carte prépayée (ne pas prendre de noms de domaine trop cher, 2 euros environ). on prendra domain1.name et domain2.name pour l'exemple.

Création des serveurs dns redondants

Afin que bind(le service de serveur dns) puisse accéder aux fichiers de configuration: 

chown bind:bind /etc/bind/
chmod 666 /etc/bind/

nous éditons le fichier de configuration locale de bind 

/etc/bind/named.conf.local

sur la première machine de service: 

zone "domain1.name" {
 	type master;
 	file "/etc/bind/domain1.name";
 	allow-transfer{secondaries;};
 	notify yes;
};

acl "secondaries"{
 	<adresse_ipv4_machine_service_2>;
 	<adresse_ipv6_machine_service_2>;
};

zone "domain2.name" {
 	type secondary;
 	file "/etc/bind/backup/domain2.name";
 	primaries{<adresse_ipv6_machine_service_2>;};
};

sur la seconde machine de service: 

zone "domain2.name" {
 	type master;
 	file "/etc/bind/domain2.name";
 	allow-transfer{secondaries;};
 	notify yes;
};

acl "secondaries"{
 	<adresse_ipv4_machine_service_1>;
 	<adresse_ipv6_machine_service_1>;
};

zone "domain1.name" {
 	type secondary;
 	file "/etc/bind/backup/domain1.name";
 	primaries{<adresse_ipv6_machine_service_1>;};
};


et sur la machine mandataire: 

zone "domain1.name" {
 	type secondary;
 	file "/etc/bind/backup/domain1.name";
 	primaries{<adresse_ipv6_machine_service_1>;};
};
zone "domain2.name" {
 	type secondary;
 	file "/etc/bind/backup/domain2.name";
 	primaries{<adresse_ipv6_machine_service_2>;};
};

nous créons maintenant les fichiers de zone dns:

sur la première machine de service dans un fichier 

/etc/bind/domain1.name

: 

$TTL 400

@ IN SOA ns.domain1.name domain1.name (
        4000      ; Numero de version(faire +1 a chaque edition du fichier)
        21600     ; Rafraichissement (6h)
        3600      ; Re-tentative (1h)
        2592000   ; Expiration (30j)
        86400     ; Cache negatif (24h)
);

 	IN	NS	ns.domain1.name.
 	IN	NS	ns.domain2.name.

@	IN	A	<adresse_ipv4_bridge_SE4_mandataire>
@	IN	AAAA	<adresse_ipv6_bridge_SE4_mandataire>

ns	IN	A	<adresse_ipv4_bridge_SE4_mandataire>
ns	IN	AAAA	<adresse_ipv6_bridge_SE4_mandataire>

www IN CNAME domain1.name

sur la seconde machine de service, on inversera chaque itération de domain1.name par domain2.name du fichier de zone ci-dessus et on le placera dans 

/etc/bind/domain2.name

.

Lorsque la configuration du serveur dns est faite, on redémarre bind avec: 

service named restart

sur les trois machines.

glue record

Pour que nos serveurs DNS soient reconnus par les autres serveurs DNS d'internet, il faut créer un glue record. On se rend sur gandi.net et on suit la procédure décrite pour ajouter un glue record. On ajoute alors ns.domain1.name et ns.domain2.name.

On peut alors verifier que notre nom de domaine est bien reconnu par les autres serveurs DNS sur le site dnschecker.org, et aussi en exécutant: 

dig domain1.name @8.8.8.8

DNSSEC

Pour sécuriser nos serveurs dns, on vient insérer ces 3 lignes dans les fichiers 

/etc/bind/named.conf.local

des deux machines de service dans la zone hébergée par la machine (zone domain1.name pour la machine 1, domain2.name pour la machine 2) 

key-directory "/etc/bind/keys";
dnssec-policy "dnspol";
inline-signing yes;

on insère également la politique "dnspol" dans le fichier de zone sur les deux machines: 

dnssec-policy "dnspol" {

 keys {
   ksk key-directory lifetime unlimited algorithm 13;
   zsk key-directory lifetime unlimited algorithm 13;
 };
 nsec3param;

on crée aussi le répertoire /etc/bind/keys pour stocker les clés, et on donne les droits à bind pour y accéder (comme vu précédemment avec chown et chmod)


On crée maintenant les clés avec l'utilitaire dnssec-keygen: 

dnssec-keygen -a RSASHA256 -f KSK -n ZONE domain1.name -K /etc/bind/keys
dnssec-keygen -a RSASHA256 -n ZONE domain1.name -K /etc/bind/keys

Retournons maintenant sur gandi.net pour authentifier notre serveur avec les clé publiques générées (.keys).

On peut désormais recharger nos serveurs dns avec 

 service named restart<syntaxhighlight lang="shell">

On vérifie alors que toute la chaîne d'authentification est correcte sur dnsviz.net. (vous pouvez vérifier la chaîne de tompere.online à https://dnsviz.net/d/tompere.online/dnssec)

== Serveur web ==
Pour pouvoir déployer notre site web, on crée des certificats ssl avec la clé générée avec:

<syntaxhighlight lang="shell">
openssl req -nodes -newkey rsa:2048 -sha256 -keyout domain1.name.key -out domain1.name.csr

que l'on vient ensuite ajouter sur gandi.net pour récupérer des certificats. On a alors 3 fichiers qu'il faut placer au bon endroit: 

mv domain1.name.crt /etc/ssl/certs/
mv domain1.name.pem /etc/ssl/certs/
mv domain1.name.key /etc/ssl/private/


on configure notre site en éditant /etc/apache2/sites-available/000-domain1.name-ssl.conf 

<VirtualHost *:80>
    ServerName ns.domain1.name
    Redirect permanent / https://domain1.name/
</VirtualHost>

<VirtualHost *:443>
    ServerName domain1.name
    ServerAlias domain1.name
    DocumentRoot /var/www/domain1.name/
    CustomLog /var/log/apache2/secure_access.log combined

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

On pourra en faire de même pour la seconde machine de service en remplaçant avec domain2.name.

On peut maintenant lancer le site web en exécutant: 

a2ensite 000-domain1.name-ssl.conf
/etc/init.d/apache2 restart


On peut maintenant accéder au site web en allant sur https://domain1.name(nom pas déposé, n'y allez pas dans le doute) (dans mon cas, https://tompere.online)

Fail2Ban

Lorsque j'avais précisé qu'il valait mieux conserver le mot de passe par défaut des VMs, c'est pour la raison suivante: lorsque votre machine est exposée à internet, n'importe qui peut tenter d'y accéder en ssh, et donc si vous avez un mot de passe peu puissant, il y a le risque qu'une personne malveillante ait accès à votre machine. Pour s'en prémunir, nous allons configurer l'outil fail2ban pour bloquer les ip faisant des tentatives répétées de connexion: dans le fichier /etc/fail2ban/jail.local, on insère: 

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

on redémarre l'utilitaire avec : 

service fail2ban restart

Seront donc bloqués d'accès en ssh tous ceux qui tentent d'y accéder en échouant 3 fois.

BruteForce d'un point d'accès Wifi

récupération adresse mac

Afin de casser la clé, nous devons utiliser une carte wifi permettant d'accéder au point d'accès. Il est possible de vérifier quel est le nom de la carte wifi avec: 

ip link

Afin d'accélérer le bruteforce, nous avons pris une clé USB Wi-Pi qui dispose de son propre identifiant.

On peut maintenant scanner le réseau pour trouver l'adresse mac du point d'accès <cracotteX>. 

airodump-ng <nom_carte_wifi> --essid <cracotteX>

attaque sur clé WEP

Lorque l'on obtient l'adresse mac, on va logger dans un fichier de log avec: 

sudo airodump-ng -c 4 --bssid <adresse_mac> <nom_carte_wifi>  --write dump

maintenant, on bruteforce avec: 

aircrack-ng -b <adresse_mac> *.cap

attaque sur clé WPA-PSK

Pour l'attaque sur clé WPA-PSK nous avons l'information que le mot de passe ne contient que 8 chiffres et est donc facilement crackable. Nous créons donc un dictionnaire avec crunch (que l'on installe avec apt install) 

crunch 8 8 0123456789 -o 8numbers_dico.txt

A nouveau, nous sauvegardons les données reçues dans un fichier de logs: 

sudo airodump-ng -c 13 --bssid <adresse_mac> <nom_carte_wifi> --write dump

Dans mon cas je n'ai pas pu accéder aux clés, car le flux de données s'est retrouvé ralenti, et les tentatives d'authentification prenaient plusieurs secondes à chaque fois. Cela dit, dans un environnement moins chargé en perturbations électromagnétiques et/ou avec plus de temps, il aurait été possible de les obtenir.

Serveur FreeRadius et sécurisation WPA2-EAP

nous souhaitons accéder à nos machines de service via un point d'accès wifi, et que notre réseau soit séparé en y accédant à travers un Vlan. pour faire cela, nous accédons d'abord au point d'accès avec : 

ssh -oKexAlgorithms=+diffie-hellman-group11-sha1 -oHostKeyAlgorithms=+ssh-rsa -oCiphers=+aes128-cbc admin@172.27.0.3

une fois sur le point d'accès, on paramètre l'authentification en indiquant le serveur d'authentification (une machine de service) 

conf t

aaa new-model
aaa authentication login eap_student<numéro_étudiant> group radius_student<numéro_étudiant>
radius-server host <ip_machine_service> auth-port 1812 acct-port 1813 key secret_student<numéro_étudiant>        
aaa group server radius radius_student<numéro_étudiant>               
server <ip_machine_service> auth-port 1812 acct-port 1813        
exit

On crée maintenant le point d'accès WIFI avec les commandes : 

dot11 ssid VM_SERVICES_<numéro_étudiant>       
vlan <10 + numéro_étudiant>        
authentication open eap eap_student<numéro_étudiant> 
authentication network-eap eap_student<numéro_étudiant>
authentication key-management wpa
mbssid guest-mode

On active le vlan souhaité sur l'interface Dot11Radio0 (l'interface wifi du point d'accès) 

interface Dot11Radio0
ssid VM_SERVICES_<numéro_étudiant>
encryption vlan <10 + numéro_étudiant> mode ciphers aes-ccm

On active l'encapsulation dot1Q pour le vlan souhaité sur l'interface wifi : 

interface Dot11Radio0.<10 + numéro_étudiant>
encapsulation dot1Q <10 + numéro_étudiant>
bridge-group <10 + numéro_étudiant>

puis on active l'encapsulation dot1Q pour le vlan souhaité sur l'interface ethernet (qui est connectée au routeur) 

interface GigabitEthernet0.<10 + numéro_étudiant>
encapsulation dot1Q <10 + numéro_étudiant>
bridge-group <10 + numéro_étudiant>

Il faut réitiérer ce processus pour le second point accès pour avoir une redondance, qui est à l'adresse ip 172.27.0.4


Sur le premier routeur, On configure le vlan étudiant avec: 

interface Vlan <10 + numéro_étudiant>
description "VLAN etudiant_<numéro_étudiant>"
ip address 10.60.<numéro_étudiant>.2 255.255.255.0
ipv6 address 2001:660:4401:60a<numéro_étudiant>::2/64
vrrp <10 + numéro_étudiant> address-family ipv4
priority 110
address 10.60.<numéro_étudiant>.1 primary

et on vient configurer le DHCP de la façon suivante: 

ip dhcp pool <nom_pool_dhcp>
network 10.60.<numéro_étudiant>.0 255.255.255.0
dns-server 193.48.57.<valeur_unique_au_binôme>
default-router 10.60.<numéro_étudiant>.254

Encore une fois, il faudra doubler ces commandes sur le second routeur.

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