Atelier SysRes SE4 2024/2025 E5

Projet Virtualisation KAOUTAR EL BACHIRI - Machine Apollo 🚀

Introduction

Dans ce projet de virtualisation, j'ai mis en place une infrastructure comprenant deux machines de services et une machine mandataire, le tout orchestré avec Xen. La machine Apollo joue un rôle clé dans l'hébergement des services, tandis que Solstice assure la gestion du réseau et l'interconnexion avec l'extérieur.

Si vous souhaitez plonger plus en détail dans la configuration de Moon, la seconde machine de services, il vous suffit de cliquant sur le lien suivant : 📎 Moon.

Les prochaines sections vous guideront à travers chaque étape de cette mission. 🛰️

Création et Connexion aux Machines Virtuelles

Dans ce projet, j'ai créé deux machines de services et une machine mandataire à l'aide de l'outil Xen. Les commandes utilisées sont les suivantes :

root@capbreton:~# xen-create-image --hostname=SE4.Apollo --dhcp --bridge=pontKS --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
root@capbreton:~# xen-create-image --hostname=SE4.Solstice --dhcp --bridge=pontKS --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force

Pour démarrer les machines, j'ai utilisé :

xen create /etc/xen/SE4.Apollo.cfg
xen create /etc/xen/SE4.Solstice.cfg

Et pour accéder aux consoles des VMs :

xen console SE4.Apollo
xen console SE4.Solstice

root@capbreton:~# xen list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  3970     4     r-----   83423.2
SE4.Zeus                                    15  2048     1     -b----    3778.8
SE4.Pattes                                  16  2048     1     -b----    2954.3
SE4.Vander                                  18  2048     1     -b----    2659.5
SE4.Solstice                                39  2048     1     -b----    2560.1
SE4.Jinx                                    48  2048     1     -b----    1043.3
SE4.jeanluc                                 62  2048     1     -b----     728.4
SE4.ElMordjene                              68  2048     1     -b----     868.4
SE4.Poseidon                                82  2048     1     -b----    1334.2
SE4.Gaby                                    89  2048     1     -b----     704.1
SE4.Bree                                    90  2048     1     -b----     547.6
SE4.Desperate                               99  2048     1     -b----    3969.9
SE4.Orion                                  100  2048     1     -b----     906.5
SE4.Vi                                     109  2048     1     -b----     903.6
SE4.Rod                                    110  2048     1     -b----    1339.9
SE4.Rodrigo                                112  2048     1     -b----    2388.2
SE4.Rigo                                   113  2048     1     -b----    1390.1
SE4.Apollo                                 118  2048     1     -b----     462.7
SE4.Moon                                   119  2048     1     -b----     452.3

Liste des commandes utiles :

Fonction	Commande
listes des VMs allumées	xen list
Allumer la VM	xen create /etc/xen/SE4.Apollo.cfg
Connexion à la VM	xen console SE4.Apollo
Eteindre la VM	xen shutdown SE4.Apollo

Montage des Partitions /var et /home sur Apollo

Pour améliorer la gestion des données, j'ai monté les répertoires /var et /home sur des partitions LVM dédiées.

Création des Fichiers de Partition

Depuis le serveur Capbreton, j'ai créé les fichiers de partitions dans /dev/virtual :

root@capbreton:/dev/virtual# ls
SE4.Apollo.var  SE4.Apollo.home  SE4.Moon.var  SE4.Moon.home

Modification des Fichiers de Configuration

J'ai modifié les fichiers .cfg pour attacher les partitions LVM aux machines :

disk = [
    'file:/usr/local/xen/domains/SE4.Apollo/disk.img,xvda2,w',
    'file:/usr/local/xen/domains/SE4.Apollo/swap.img,xvda1,w',
    'phy:/dev/virtual/SE4.Apollo.home,xvdb,w',
    'phy:/dev/virtual/SE4.Apollo.var,xvdc,w',
]

Une configuration similaire a été appliquée à Moon.

Formatage et Montage

Les partitions ont été formatées et montées avec les commandes suivantes :

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

Pour /home :

mkfs -t ext4 /dev/xvdb
mount -a

Enfin, j'ai modifié le fichier /etc/fstab pour un montage automatique au démarrage:

/dev/xvda1 none swap sw 0 0
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
/dev/xvdb /var ext4 defaults 0 2 
/dev/xvdc /home ext4 defaults 0 2 
root@Apollo:~# vim /etc/fstab

Après cela pour confirmer le tout, je redemarre la machine :

xen shutdown SE4.Apollo

Configuration Réseau

Chaque machine a été configurée avec des adresses IPv4 fixes sur un réseau privé et une configuration automatique pour IPv6.

Machines de Services (Apollo et Moon)

Exemple de configuration dans /etc/network/interfaces pour Apollo :

auto eth0
iface eth0 inet static
    address 172.16.0.2/24
    gateway 172.16.0.1

iface eth0 inet6 auto

Moon utilise une configuration similaire avec l’adresse 172.16.0.3.

Machine Mandataire (Solstice)

La machine mandataire agit comme passerelle IPv4 pour les machines de services. Voici sa configuration réseau :

auto eth0
iface eth0 inet static
    address 172.16.0.1/24

iface eth0 inet6 auto

auto eth1
iface eth1 inet static
    address 193.48.57.166/27
    gateway 193.48.57.161

Séance Improvisée du 4 Février

Avec les personnes présentes lors de cette séance, nous avons configuré le routeur pour y ajouter une option pour le mode OSPF. J'ai donc pu suivre les étapes.

Configuration des VLANs

Pendant cette séance, nous avons configuré plusieurs VLANs nécessaires à l'interconnexion des machines et au respect des contraintes du TP :

- VLAN 1 : Service.

- VLAN 50 : Machines Xen.

- VLAN X : Réseaux privés (1 par étudiant).

- VLAN 530 : Connexion au SR52 pour l'accès à Internet.

Les adresses de réseau utilisées, sont des adresses privées en 10.0.0.0 que nous avons adapté : 10.0.100+Numero.0/24 pour chaque machine de service, soit chaque étudiant.

Configuration SSH

Nous avons restreint l'accès SSH au routeur en autorisant uniquement les machines du réseau via une access-list. Voici les commandes utilisées :

ip access-list standard 10
10 permit 193.48.57.160 0.0.0.15
20 deny any

line vty 0 4
 access-class 10 in
 password <mot_de_passe_de_promo>
 transport input ssh

La connexion SSH se fait avec :

ssh admin@193.48.57.161 -o KexAlgorithms=diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 -o HostKeyAlgorithms=ssh-rsa

Pour tester le ssh nous avons utiliser la commande touch fichier pour créer un fichier sur la machine mandataire depuis la machine d'un autre binôme. Il reste tout de même les redirection de ports a faire pour les machines.

Configuration du Routeur avec OSPF

Le protocole OSPF a été configuré pour partager les tables de routage avec le SR52. Voici un extrait de la configuration :

router ospf 1
 router-id 10.0.101.1
 summary-address 193.48.57.160 255.255.255.240
 redistribute static route-map ospf
 redistribute connected
 network 193.48.57.160 0.0.0.15 area 10
 default-information originate

Les routes OSPF sont bien détectées, comme visible dans les résultats de show ip route.

Connexion Internet

Avec OSPF actif, la machine mandataire peut accéder à Internet. Voici le test de ping :

Ping sur Apollo et Moon

Redirection de Port et Persistance des Règles

Pour permettre l’accès SSH aux machines de services via Solstice, j’ai mis en place des redirections de port. J'ai d'abord modifié le fichier d'autorisation ssh de root en modifiant le fichier suivant /etc/ssh/sshd_config :

PermitRootLogin yes

Il faut ensuite redémarrer le serveur ssh :

root@Solstice:/etc/ssh# /etc/init.d/ssh restart

Cependant, j’ai rencontré un problème : les règles nftables sur les machines de services n’étaient pas persistantes, ce qui empêchait l’accès SSH après un redémarrage.

Redirection des Ports sur Solstice avec iptables

À l'origine, j'avais configuré iptables pour rediriger le trafic SSH vers Apollo et Moon, mais en voulant modifier les règles, je n’arrivais plus à appliquer correctement nftables sur Solstice.

La solution était de revenir à iptables pour Solstice. En effet Solstice avait garder par défaut ma configuration erronée mais avec iptables. Cela ne pouvais pas être modifié avec ntftables.

iptables -t nat -A PREROUTING -p tcp --dport 2201 -j DNAT --to-destination 172.16.0.2:22 # Apollo
iptables -t nat -A PREROUTING -p tcp --dport 2202 -j DNAT --to-destination 172.16.0.3:22 # Moon
iptables -t nat -A POSTROUTING -p tcp -d 172.16.0.2 --dport 22 -j MASQUERADE # Apollo
iptables -t nat -A POSTROUTING -p tcp -d 172.16.0.3 --dport 22 -j MASQUERADE # Moon

Rendre la configuration persistante sur Solstice :

1. J'ai installé iptables-persistent  :

apt install iptables-persistent -y

2. Puis j'ai sauvegardé les règles pour qu'elles soient appliquées au démarrage :

iptables-save > /etc/iptables/rules.v4

Maintenant, après chaque redémarrage (reboot de la machine), la redirection SSH via Solstice fonctionne bien !

Redirection des Ports sur les Machines de Services avec nftables

Sur Apollo et Moon, j’ai configuré nftables pour gérer la redirection SSH. Je redirige le port 2201 vers Apollo et 2202 vers Moon.

Ajout des règles nftables sur les machines de services** :

nft add table ip nat
nft add chain ip nat PREROUTING { type nat hook prerouting priority 0 \; }
nft add rule ip nat PREROUTING tcp dport 2201 dnat to 172.16.0.2:22
nft add rule ip nat PREROUTING tcp dport 2202 dnat to 172.16.0.3:22
nft add chain ip nat POSTROUTING { type nat hook postrouting priority 100 \; }
nft add rule ip nat POSTROUTING masquerade

Rendre les règles persistantes sur les machines de services :

1. Je sauvegarde la configuration actuelle :

nft list ruleset > /etc/nftables.conf

2. Puis, j'active nftables au démarrage pour appliquer les règles :

systemctl enable nftables
systemctl restart nftables

Avec ces configurations :

- Solstice utilise iptables pour la redirection des ports vers les machines de services

- Apollo et Moon utilisent nftables avec des règles persistantes

Maintenant, je peux me connecter en SSH à Apollo et Moon via Solstice sans problème, même après un reboot des machines.

Mise en Place d’un Serveur DNS

J'ai configuré un serveur DNS pour gérer les noms de domaine associés à nos machines virtuelles : apollo-exploration.online et moonrises.online.

La première chose à faire est de se reconnecter au registrar de domaine Gandi. Je y avions déjà au préalable commandé nos noms de domaine pour Apollo et Moon. Après connexion, je je rendons dans l'onglet Domaine et je suivons les instructions pour je procurer le certificat pour nos deux machines. Après avoir suivi le tutoriel, je obtenons deux fichiers :

- myserver.key : la clé privée du domaine

- server.csr : la demande de signature du certificat

Je utiliserons ces fichiers pour configurer DNSSEC et sécuriser notre zone DNS.

Configuration de bind9

J'ai installé bind9 et configuré l’interface réseau :

apt install bind9 -y

j'ai vérifier les version de bind9 afin d'éviter certains problèmes par la suite, et celle ci doit être supérieure a la version 9.11, et c'est bien le cas. Des problèmes liés à la mise en place du DNSSEC aurait pu survenir dans le cas contraire.

root@Apollo:~# named -v
BIND 9.18.33-1~deb12u2-Debian (Extended Support Version) <id:>

Ajout de l'interface eth1 pour gérer l'IPv6 dans `/etc/network/interfaces` :

auto eth1
iface eth1 inet6 auto

Redémarrage du service pour appliquer les modifications en utilisant une des deux commandes suivantes :

systemctl restart networking
service networking restart

Configuration du Serveur DNS Maître et Secondaire

Sur Apollo, j'ai configuré les zones DNS dans `/etc/bind/named.conf.local` :

zone "apollo-exploration.online" {
	type master;
	file "/etc/bind/db.apollo-exploration.online";
	key-directory "/etc/bind/keys";
        dnssec-policy "dnspol"; # Active DNSSEC avec la politique "dnspol"
        inline-signing yes;
	allow-transfer{secondaries;}; # filtrer les secondaires
	also-notify{hiddensecondaries;}; # secondaires caches
	notify yes;
};

acl "secondaries" {
	2001:660:4401:60a0:216:3eff:fe6f:f548; # Adresse IPv6 de Moon (serveur secondaire)
	2001:660:4401:60a0:216:3eff:fe29:880f; # Adresse IPv6 de Solstice 
};

masters "hiddensecondaries" {
	2001:660:4401:60a0:216:3eff:fe29:880f; 
};

zone "moonrises.online" {
	type slave;
	file "/etc/bind/backup/db.moonrises.online"; 
	masters{2001:660:4401:60a0:216:3eff:fe6f:f548;}; 
};

La machine Apollo est le serveur DNS principal, tandis que Moon sert de DNS secondaire et récupère la zone depuis Apollo.

Fichier de Zone pour Apollo

J'ai créé `/etc/bind/zones/db.apollo-exploration.online` :

Je suis partie d'un exemple puis j'ai adapté en ajoutant les enregistrements A et AAAA.

$TTL 200
@ IN SOA ns2.apollo-exploration.online. admin.apollo-exploration.online. (
        3298267245      ;Version
        7200            ;Refresh
        3600            ;Retry
        1209600         ;Expire
        259200 )        ;Minimum TTL

;
        IN      NS      ns1.moonrises.online.
        IN      NS      ns2.apollo-exploration.online.
ns2     IN      AAAA    2001:660:4401:60a0:216:3eff:fe3c:33a5 
ns2     IN      A       193.48.57.166
@       IN      A       193.48.57.166
@       IN      AAAA    2001:660:4401:60a0:216:3eff:fe3c:33a5

Remarque : il est utile d'incrémenter de 1 le numero de Version a chaque restart de named.

J'ai donc ensuite vérifié la syntaxe :

named-checkzone apollo-exploration.online /etc/bind/db.apollo-exploration.online

Activation et Tests du Serveur DNS

J'ai redémarré bind9 (on peut toujours faire cela soit en utilisant systemctl ou service)  :

systemctl restart named
systemctl enable named

J'ai autorisé les utilisateurs bind à accéder aux fichiers de zone et de config :

chown bind:bind /etc/bind/db.apollo-exploration.online
chmod 644 /etc/bind/zones/db.apollo-exploration.online
chown bind:bind /etc/bind/named.conf.local
chmod 644 /etc/bind/named.conf.local

J'ai effectué un premier test DNS avec dig :

dig @localhost apollo-exploration.online

Le serveur répond correctement aux requêtes sur les deux machines.

Publication du DNS

Afin de rendre notre serveur DNS opérationnel et accessible, je me rends sur le site du registrar Gandi pour effectuer les configurations nécessaires.

Dans l’onglet "Nameserver" de mon domaine, j'ajoute un "Glue Record", qui permet d’associer directement mon nom de domaine à mes propres serveurs DNS. Pour cela, j’enregistre les adresses IPv4 (celle de la machine mandataire) et IPv6 (celle de la machine de services).

Ensuite, je remplace les Nameservers actuels par ceux de mon propre serveur, afin qu'il devienne le référent pour la résolution des noms de domaine associés.

Nameserver et Glue records pour Apollo

Nameserver et Glue records pour Moon

Après quelques heures, le temps que la propagation DNS s'effectue, je vérifie la bonne prise en compte de ces changements sur le site DNS Checker. Celui-ci me permet de confirmer que mon serveur DNS est bien propagé (vérifier la disponibilité des enregistrements A et AAAA) à l’échelle mondiale, en affichant les adresses IP correspondantes lors d’une requête sur apollo-exploration.online et moonrises.online.

DNS Checker pour Apollo

DNS Checker pour Moon

Configuration et Activation de DNSSEC

Clés générées pour le DNSSEC pour Apollo et Moon

J'ai mis en place DNSSEC pour signer les zones DNS.

1️⃣ Génération des Clés DNSSEC :

mkdir -p /etc/bind/keys
cd /etc/bind/keys
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE apollo-exploration.online
dnssec-keygen -a RSASHA256 -b 1024 -n ZONE -f KSK apollo-exploration.online

Deux paires de clés sont générées :

- ZSK (Zone Signing Key)

- KSK (Key Signing Key)

2️⃣ Ajout des Clés DNSSEC à la Zone :

J'ai modifié `/etc/bind/zones/db.apollo-exploration.online` pour inclure les clé

$INCLUDE /etc/bind/keys/Kapollo-exploration.online.+013+12345.key
$INCLUDE /etc/bind/keys/Kapollo-exploration.online.+013+67890.key

J'ai vérifié le bon fonctionnement avec :

named-checkzone apollo-exploration.online /etc/bind/db.apollo-exploration.online.signed

Test et Publication de DNSSEC

J'ajoute alors la suite de ce qui est demandé dans le sujet dans le fichier '/etc/bind/named.conf.options' (dans le .option pour rendre les chose propres) :

root@Apollo:/etc/bind/keys# cat /etc/bind/named.conf.options 
options {
	directory "/var/cache/bind";
	dnssec-validation auto;

	listen-on-v6 { any; };
	allow-query {any;};
	recursion yes;
};


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

Après tout cela, j'ai redémarré bind9 :

systemctl restart bind9

J'ai testé la propagation DNS et celle de DNSSES avec le site DNSviz. Cela permet d’analyser les signatures DNSSEC et de vérifier si la chaîne de validation est correcte: Si tout est bleu, tout est bon.

DNSviz apollo-exploration.online

DNSviz moonrises.online

Les tests ont confirmé que la configuration était fonctionnelle.

Mise en Place de Fail2Ban sur Apollo

Pour protéger Apollo contre les attaques brute force sur SSH, j’ai installé et configuré Fail2Ban.

Installation et Configuration

Installation du paquet :

 apt install fail2ban -y

Création du fichier /etc/fail2ban/jail.local avec les règles de bannissement :

 [sshd] enable = true port = ssh filter = sshd maxretry = 5 findtime = 300 bantime = 600

Correction de l’erreur "allowipv6 not defined"

Au redémarrage, Fail2Ban affichait un avertissement sur allowipv6. Pour le corriger, j’ai ajouté dans /etc/fail2ban/jail.conf :

 allowipv6 = true

Activation de Fail2Ban

 service fail2ban restart

Donc maintenant :

✅ Fail2Ban est désormais actif et protège SSH en IPv4 et IPv6

✅ Le serveur DNS répond correctement aux requêtes

✅ Les enregistrements A et AAAA sont bien configurés

✅ DNSSEC est actif et validé sur DNSViz

✅ La réplication de la zone fonctionne avec Moon

Cette configuration assure une résolution de noms fiable et sécurisée, avec DNSSEC garantissant l’intégrité des enregistrements DNS.

Prochaine étape : finaliser l’interconnexion avec Internet et peaufiner la gestion IPv6.

Mise en Place du Serveur Apache (HTTP et HTTPS)

Pour rendre accessible mon site web sur Apollo, j’ai mis en place Apache2, en suivant un ordre logique :

1️⃣ Installation et activation du HTTP

2️⃣ Configuration de la redirection HTTPS sur la machine mandataire (Solstice)

3️⃣ Ajout du support HTTPS sur Apollo

Installation d’Apache et Activation du HTTP

J’ai commencé par installer Apache2 sur Apollo :

apt update && apt install apache2 -y

J'entre les commandes suivantes :

a2enmod ssl
a2enmod proxy
a2enmod proxy_http

Puis, apres avoir modifier le fichier /etc/apache2/sites-available/default-ssl.conf, j’ai vérifié que le serveur fonctionnait en HTTP en tapant mon nom de domaines sur mon moteur de recherche. Voicl les modification du fichier default-ssl.conf :

SSLEngine on
SSLCertificateFile	/etc/apache2/sites-available/apollo-exploration.online.crt
SSLCertificateKeyFile /root/myserver.key
SSLCertificateChainFile /etc/apache2/sites-available/GandiCert.pem
SSLProxyEngine on

Tout est fonctionnel en HTTP !

Mise en Place de la Redirection HTTPS via Solstice

Étant donné qu'Apollo ne dispose pas d’IPv4 routée, Solstice agit en tant que mandataire inverse pour rediriger le trafic HTTPS vers Apollo.

Configuration d’Apache sur Solstice dans `/etc/apache2/sites-available/default-ssl.conf` :

<VirtualHost *:80>
    ServerName apollo-exploration.online
    ServerAlias www.apollo-exploration.online
    Redirect permanent / https://apollo-exploration.online/
</VirtualHost>

<VirtualHost *:443>
    ServerName apollo-exploration.online

    SSLProxyEngine on
    ProxyPreserveHost on

    ProxyPass / https://apollo-exploration.online/
    ProxyPassReverse / https://apollo-exploration.online/

    ErrorLog /var/log/apache2/apollo_error.log

    SSLCertificateFile /etc/apache2/sites-available/certifapollo/apollo-exploration.online.crt
    SSLCertificateKeyFile /etc/apache2/sites-available/certifapollo/myserver_apollo.key
    SSLCertificateChainFile /etc/apache2/sites-available/certifapollo/GandiCert.pem
</VirtualHost>

Activation de la configuration et redémarrage d’Apache sur Solstice :

a2ensite apollo-exploration.online.conf
systemctl reload apache2

À ce stade, HTTPS redirige bien vers Apollo, mais il fallait encore activer HTTPS sur Apollo.

Activation du HTTPS sur Apollo

Installation des modules nécessaires :

a2enmod ssl
systemctl restart apache2

Ajout du site HTTPS sur Apollo dans `/etc/apache2/sites-available/default-ssl.conf` :

<VirtualHost *:443>
	ServerAdmin webmaster@localhost

	DocumentRoot /var/www/html

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	SSLEngine on

	SSLCertificateFile      /etc/apache2/sites-available/apollo-exploration.online.crt
	SSLCertificateKeyFile   /root/myserver.key

	SSLCertificateChainFile /etc/apache2/sites-available/GandiCert.pem

	<FilesMatch "\.(?:cgi|shtml|phtml|php)$">
		SSLOptions +StdEnvVars
	</FilesMatch>
	<Directory /usr/lib/cgi-bin>
		SSLOptions +StdEnvVars
	</Directory>

</VirtualHost>

<VirtualHost *:80>
	ServerName apollo-exploration.online
	ServerAlias www.apollo-exploration.online
	Redirect permanent / https://apollo-exploration.online/
</VirtualHost>

Activation du site HTTPS sur Apollo et redémarrage :

a2ensite default-ssl.conf
systemctl reload apache2

Résolution d’un Problème Apache (Merci M. Redon !)

Lors de la configuration, j’ai eu des difficultés à cause d’un problème de fichier activé. J’avais modifié plusieurs fichiers dans sites-available sans vérifier ceux activés dans sites-enabled. La solution était de reverifier les fichiers default-ssl.conf (ne pas mettre de ~/ dans les chemins pour les fichiers important mais écrire root/) et d’exécuter la commande :

  a2ensite default-ssl.conf
  systemctl reload apache2

Finalement, tout est bien redirigé vers HTTPS. Mon site est maintenant entièrement sécurisé et accessible en HTTPS 🚀.

Mon site La Mission Apollo