Atelier SysRes SE4 2024/2025 E14

Projet AARV LECOMTE et CASIMIRI

INTRODUCTION

Dans le cadre de ce projet de virtualisation, j’ai déployé une infrastructure composée de deux machines dédiées aux services et d’une machine mandataire, le tout orchestré à l’aide de Xen.

La machine Atreus joue un rôle central en assurant l’hébergement des services web et autres composants applicatifs. La machine GOW fait office de mandataire réseau : elle gère la connectivité vers l’extérieur, que ce soit en IPv4 ou en IPv6, et sert aussi de reverse proxy pour rediriger les requêtes vers les machines de service internes.

La deuxième machine de service appartient à Monsieur Antoine LECOMPTE et porte le nom de Kratos. Elle complète l’architecture et participe à l’ensemble des services distribués au sein de l’infrastructure.

✉️ Petit mot pour les prochaines promotions

Salut à vous les prochaines promos 👋

Dans ce document, j’ai essayé de vous expliquer au mieux les différentes étapes que j’ai traversées pour monter ce projet. Je me suis appuyé sur ce que j’ai compris moi-même au fil des TP, les cours des profs (qu’il faut vraiment relire, ils sont précieux), des ressources trouvées sur Internet, et je ne vais pas vous mentir… parfois un petit coup de main de certains LLM comme ChatGPT 👀 m’a bien aidé quand je bloquais.

Ce n’est pas un tutoriel parfait, mais plutôt un guide pour vous accompagner avec des explications techniques assez simples à comprendre (que je pense avoir compris surtout), même si vous n’avez encore jamais touché au réseau, à l’infra ou à un serveur web. L’objectif, c’est que vous puissiez prendre confiance, comprendre les bases, et réussir à faire tourner votre projet sans paniquer.

Je vous souhaite vraiment bon courage pour ce projet. C’est l’un des meilleurs moyens d’apprendre concrètement et de progresser à fond. N’hésitez pas à poser des questions à vos profs, ils sont là pour vous aider. Prenez le temps de relire vos cours tranquillement, et surtout, n’ayez pas peur de tester, de faire des erreurs, de casser et de recommencer (certains profs demande à ce qu'on casse les machines pour montrer qu'on cherche) : c’est comme ça qu’on apprend.

Si vous avez l'occasion de les consulter, je vous conseille vivement d'aller regarder les wikis de Madame EL BACHIRI, Monsieur TOURON et Monsieur DETREZ. Ils ont certaines informations en plus que moi sur tout ce qui va être configurations CISCO, OSPF et tout ce qui touche au physique (câbles, commutateurs).

En espérant que vous allez plus loin que nous sur ce projet !

CRÉATION MACHINES VIRTUELLES

Tout d'abord, nous devons configurer nos MV de services. Il leur faut plusieurs paramètres pour fonctionner selon nos critères.

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

• xen-create-image : Commande permettant de créer une nouvelle machine virtuelle Xen
• --hostname=SE4.Atreus : Spécifie le nom d'hôte de la nouvelle MV créée. Ici, le nom d'hôte sera SE4.Atreus.
• --dhcp : Indique que la MV obtiendra automatiquement une adresse IP via DHCP. Aucune configuration statique d'adresse IP ne sera nécessaire.
• --bridge=bifrost : Précise l'utilisation du pont réseau nommé bifrost pour connecter la machine virtuelle au réseau physique ou virtuel existant. Ceci permet une connexion directe de la VM au réseau.
• --dir=/usr/local/xen : Définit le répertoire dans lequel seront stockées les images disque et les fichiers associés de la MV. Ici, l'image sera placée dans le dossier /usr/local/xen.
• --size=10GB : Détermine la taille du disque virtuel pour cette MV. Dans cet exemple, le disque fera 10 Go.
• --dist=daedalus : Indique la distribution du système d'exploitation à utiliser pour la MV. Ici, la distribution choisie s'appelle daedalus pour Debian.

• --memory=2048M : Détermine la quantité de mémoire vive (RAM) allouée à la MV. Dans cet exemple, la MV aura 2048 Mo (soit 2 Go) de RAM.

Pour initialiser les machines, nous devons exécuter ces commandes:

xen create /etc/xen/SE4.Atreus.cfg
xen create /etc/xen/SE4.Kratos.cfg

Une fois les MV créées et en ligne, nous devons exécuter ces commandes pour les contrôler:

xen console SE4.Atreus
xen console SE4.Kratos

Une fois le login "root" et le mdp (top secret) rentrés dans la console, nous sommes sur la VM et pouvons la contrôler comme un ordinateur avec un OS classique.

root@Atreus:~#

PARTIONING DES MV

Nous avons modifié les fichiers /etc/xen/[Kratos][Atreus].cfg pour attacher les partitions LVM aux machines :

root        = '/dev/xvda2 ro'
disk        = [
                  'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w',
                  'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w',
		  'phy:/dev/virtual/SE4.Atreus.home,xvda3,w',
		  'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w',
              ]

Le paramètre disk définit les disques virtuels attachés à la machine virtuelle (domaine Xen). Chaque élément du tableau suit la syntaxe :

<type>:<source>,<cible>,<mode>

• type : indique si le disque provient :
  • d'un fichier (file:)
  • d'un périphérique physique réel (phy:).
• source : chemin complet vers l'image disque ou vers le périphérique physique sur la machine hôte.
• cible : nom du périphérique vu par la machine virtuelle (exemple : xvda, xvdb, etc.).

• mode : type d'accès au disque (r en lecture seule, w en lecture-écriture).

DISQUE VIRTUEL PRINCIPAL :

'file:/usr/local/xen/domains/SE4.Atreus/disk.img,xvda2,w'

• Type : file (stockage basé sur un fichier-image disque).
• Source : /usr/local/xen/domains/SE4.Atreus/disk.img (fichier contenant le disque virtuel).
• Cible : xvda2 (deuxième partition du disque virtuel xvda visible depuis la MV).
• Mode : w (lecture-écriture).

Ce disque correspond à la racine (/) du système de fichiers Linux de la MV.

DISQUE VIRTUEL SWAP

'file:/usr/local/xen/domains/SE4.Atreus/swap.img,xvda1,w'

• Type : file → Image disque stockée dans un fichier.
• Source : /usr/local/xen/domains/SE4.Atreus/swap.img → Chemin de l'image disque swap.
• Cible : xvda1 → Première partition du disque virtuel xvda.

DISQUE PHYSIQUE POUR /home

'phy:/dev/virtual/SE4.Atreus.home,xvda3,w'

• Type : phy → Un périphérique physique (généralement une partition réelle ou un volume logique LVM).
• Source : /dev/virtual/SE4.Atreus.home → Partition ou volume logique physique sur l'hôte. L'hôte étant le disque dur de capbreton.
• Cible : xvda3 → Troisième partition du disque virtuel xvda.

Cette partition dédiée permet d’isoler le répertoire /home, facilitant ainsi la gestion des données utilisateur séparément du système.

DISQUE PHYSIQUE POUR /var

'phy:/dev/virtual/SE4.Atreus.var,xvdb1,w'

• Type : phy → Périphérique physique.
• Source : /dev/virtual/SE4.Atreus.var → Partition physique ou volume logique dédié sur l'hôte.
• Cible : xvdb1 → Première partition du second disque virtuel (xvdb).

Cette partition est dédiée au répertoire /var, où sont stockés les journaux (logs), les bases de données, les fichiers temporaires, etc. Cette séparation permet une meilleure gestion des données systèmes dynamiques.

Pour le fichier /var

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

Pour le fichier /home

mkfs -t ext4 /dev/xvda3
mount -a

DÉMARRAGE AUTOMATIQUE DU MONTAGE

CONFIGURATION RÉSEAU

Chaque machine dispose d'une adresse IPv4 fixe sur un réseau privé, ainsi que d'une adresse IPv6 configurée automatiquement.

Nous modifions la configuration réseau dans /etc/network/interfaces de la machine mandataire. Ensuite, nous ajustons le fichier de configuration de la machine virtuelle afin qu'elle possède deux interfaces : la première permet de communiquer avec le routeur mis en place par nos collègues, tandis que la seconde est connectée au pont réseau que nous avons créé pour l’intercommunication entre nos trois machines.

MACHINE MANDATAIRE

name        = 'SE4.GOW'

#
#  Networking
#
dhcp        = 'dhcp'
vif         = [ 'mac=00:16:3E:E7:C5:1A,bridge=bifrost',
		'mac=00:16:3E:E7:C5:1B,bridge=SE4' ]

Le pont nommé "bifrost", défini dans le fichier de configuration de notre machine virtuelle mandataire, sert à relier virtuellement les trois machines entre elles.

Pour que des machines puissent communiquer, elles doivent être sur le même réseau. Ici, c’est un VIF (Virtual Interface) qui joue ce rôle : c’est une sorte de commutateur virtuel (ou switch virtuel).

Un commutateur, c’est ce que vous imaginez peut-être comme une grosse boîte avec plein de câbles et de lumières clignotantes, qu’on trouve dans les salles serveurs.

Dans notre cas, tout ça est simulé dans la machine virtuelle, donc pas de câbles physiques : la communication se fait via la carte réseau virtuelle attribuée à chaque machine.

Après avoir redémarré la machine, l’interface réseau est visible dans le fichier /etc/network/interfaces. On peut modifier ce fichier pour attribuer une adresse IP fixe à la machine GOW.

auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
	address 192.168.3.1/24
# post-up ethtool -K eth0 tx off

iface eth0 inet6 auto

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

MACHINE DE SERVICES

/etc/network/interfaces de la machine SE4.Atreus qui permet de lié les Interfaces de la MV avec ses VIF pour communiquer en IPv6 avec Internet et IPv4 avec la machine mandataire

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0

iface eth0 inet6 auto

iface eth0 inet static
	address 192.168.3.2/24
	gateway 192.168.3.1


auto eth1
iface eth1 inet6 auto

On configure la machine mandataire comme une passerelle (gateway) en IPv4. En IPv6, l’adresse est attribuée automatiquement grâce au bridge SE4.

Une fois que chaque machine peut être pingée par les autres et qu’elles arrivent à envoyer des requêtes vers Internet, on peut passer à l’étape suivante.

Interfacekratos	ip a de la machine SE4.Atreus
PingEntre2VM

SSH

On active le SSH avec la ligne PermitRootLogin yes dans le fichier /etc/ssh/sshd_configsur les 3 machines, on peut accéder à la mandataire avec son adresse IPv4 routée, pour les machines de service on utilise l'adresse en IPv6

🛡️ Sécurisation SSH avec Fail2Ban

📄 Fichier : /etc/fail2ban/jail.local

Ce fichier contient les règles locales de Fail2Ban, un outil qui surveille les logs système et bannit temporairement les adresses IP en cas de comportement suspect (comme des tentatives de connexion SSH répétées avec un mauvais mot de passe).

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

Paramètre	Explication
enable = true	Active la surveillance de SSH.
port = ssh	Surveille le port SSH.
filter = sshd	Utilise le filtre prédéfini sshd.conf, qui détecte les échecs de connexion dans les logs.
maxretry = 3	3 tentatives ratées autorisées avant bannissement.
findtime = 300	La fenêtre de détection : 5 minutes pour accumuler ces 3 tentatives.
bantime = 600	Durée de bannissement : 10 minutes (600 secondes).

CONFIGURATION DNS

Rappel : Qu’est-ce qu’un serveur DNS ?

Vu en cours avec Monsieur redon et Monsieur Vantroys, DNS veut dire Domain Name System. C’est un service qui fait la conversion entre un nom de domaine (comme muspellheim2.online) et une adresse IP (comme 193.48.57.172), que les machines utilisent pour communiquer. Ce sont les pages jaunes des serveurs et IP d'Internet. On ne connait pas l'adresse IP de tous les sites. On ne connait que les noms. Quand on écrit netflix.com sur Internet, on interroge les serveurs DNS pour qu"il puisse nous rediriger vers l'adresse IP associé au nom "netflix.com".

🌍 Fichier de zone DNS : muspellheim2.online

📄 Fichier : /etc/bind/zones/muspellheim2.online/muspellheim2.zone

Ce fichier définit tous les enregistrements DNS pour le domaine muspellheim2.online.

Il est utilisé par le serveur BIND maître (primary) pour répondre aux requêtes DNS.

🧾 En-tête : SOA (Start Of Authority)

@ IN SOA ns.muspellheim2.online. admin.muspellheim2.online. (
           3609     ; Numéro de version
          21600     ; Rafraîchissement (6h)
           3600     ; Re-tentative (1h)
        2592000     ; Expiration (30j)
          86400 )   ; Cache négatif (24h)

🔹 @ : représente le domaine racine (muspellheim2.online. ici)

🔹 SOA : Spécifie l’autorité principale de la zone. Ici :

• Serveur DNS maître : ns.muspellheim2.online.
• Contact admin : admin@muspellheim2.online (le point remplace le @)

A chaque modification de ce fichier, il faut incrémenter le numéro de version de +1.

📡 Serveurs DNS (NS)

@ IN NS ns.muspellheim2.online.
@ IN NS ns.jotunheim2.tech.

🔹 Ces lignes déclarent les serveurs DNS autoritaires pour cette zone :

- ns.muspellheim2.online. (le maître)

- ns.jotunheim2.tech. (un secondaire)

🧭 Enregistrements de type A / AAAA

ns         IN A    193.48.57.172
ns         IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3
@          IN A    193.48.57.172
@          IN AAAA 2001:660:4401:60a0:216:3eff:fe91:f4e3

🔹 A : Adresse IPv4

🔹 AAAA : Adresse IPv6

Ces enregistrements associent :

• ns.muspellheim2.online à ses adresses IP (serveur DNS)
• muspellheim2.online lui-même à la même machine (le site est hébergé dessus)

🔗 Alias (CNAME)

www IN CNAME muspellheim2.online.

🔹 Les requêtes pour www.muspellheim2.online seront redirigées vers muspellheim2.online.

Cela évite de dupliquer les enregistrements A/AAAA pour www.

🔐 DNS Validation via Digicert

_gay4mlana6awxk71vd9gjuzdkzfism2.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.
_gay4mlana6awxk71vd9gjuzdkzfism2.www.muspellheim2.online. 10800 IN CNAME dcv.digicert.com.

🔹 Ces lignes servent à valider le domaine auprès de l’autorité de certification (Digicert) pour obtenir un certificat SSL.

🔹 dcv.digicert.com. est le serveur que Digicert utilise pour vérifier la possession du domaine (via un CNAME dynamique généré).

On peut ensuite vérifier la syntaxe de notre fichier de zone DNS avec l’outil named-checkzone.

Cet outil nous aide à repérer les erreurs dans l’écriture du fichier, un peu comme Microsoft Word souligne les fautes de grammaire ou de syntaxe dans un texte.

Par exemple :

root@Atreus:~# named-checkzone muspellheim2.online /etc/bind/zones/muspellheim2.online/muspellheim2.zone
zone muspellheim2.online/IN: loaded serial 3609
OK

Ici, le message "OK" signifie que le fichier est bien écrit et ne contient pas d’erreurs de syntaxe.

Juste à noter : named-checkzone vérifie uniquement la syntaxe et la structure logique du fichier (comme la présence d’un SOA, la validité des enregistrements, etc.), mais pas si les adresses IP ou noms existent réellement.

Une fois que tout est correctement configuré, n’oubliez pas de redémarrer les services named et bind.

Cela permet à ces services de prendre en compte les nouvelles modifications que vous avez apportées dans les fichiers de configuration.

Il faut aussi attribuer les bons droits d'accès aux fichiers, pour que bind puisse les lire correctement. Sinon, il risque de ne pas fonctionner comme prévu.

chown bind:bind /etc/bind/zones/muspellheim2.online/muspellheim2.zone
chmod 644 /etc/bind/zones/muspellheim2.online/muspellheim2.zone

chown bind:bind /etc/bind/named.conf.local
chmod 644 /etc/bind/named.conf.local

• chown permet de donner la propriété des fichiers à l’utilisateur et au groupe bind.

• chmod 644 donne les droits de lecture au service bind, tout en empêchant d'autres utilisateurs non privilégiés de les modifier.

Vérification avec l'outil "dig"

On peut vérifier que notre serveur DNS fonctionne correctement en utilisant la commande dig.

C’est un outil qui envoie une requête DNS pour demander l’adresse IP d’un nom de domaine, et affiche la réponse complète reçue du serveur.

Par exemple, ici on interroge notre propre serveur DNS local (@localhost) pour vérifier s’il connaît le domaine muspellheim2.online :

root@Atreus:~# dig @localhost muspellheim2.online

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

Cela signifie que la requête s’est bien déroulée, et qu’il n’y a pas d’erreur dans le fichier de zone.

;; ANSWER SECTION:
muspellheim2.online.    200     IN      A       193.48.57.172

Le serveur DNS a bien répondu avec l’adresse IP 193.48.57.172, donc la zone est bien configurée et active.Ce test permet de s'assurer que le nom de domaine est bien reconnu et renvoie vers la bonne adresse IP.

On peut aussi tester depuis une autre machine virtuelle, pour voir si le domaine est connu à l'extérieur, par exemple par le DNS public de Google (8.8.8.8).

Pour cela, on utilise dig en spécifiant l’IP du serveur DNS qu’on veut interroger :

root@GOW:~# dig @8.8.8.8 muspellheim2.online

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

;; ANSWER SECTION:
muspellheim2.online.    189     IN      A       193.48.57.172

Google a répondu avec l’adresse IP 193.48.57.172, ce qui prouve que notre domaine est maintenant reconnu depuis l’extérieur.

🧠 Petit point d’attention : Si tu n’as pas volontairement enregistré le domaine muspellheim2.online sur Internet (via un registrar, ici c'est Gandi), alors :

• soit ton environnement de test est spécial (ex : en école avec une infra réseau propre et un DNS intermédiaire qui communique avec Google),
• soit le domaine a réellement été enregistré publiquement, auquel cas tu partages un vrai domaine avec d'autres (et ça peut poser des conflits si tu voulais juste faire des tests en local).

REGISTRAR ET PROPAGATION DNS

Pour rendre notre serveur DNS opérationnel et accessible depuis Internet, on se rend sur le site du registrar (dans notre cas : Gandi), qui est l’organisme auprès duquel on a acheté notre nom de domaine.

Dans l’onglet "Nameserver", on ajoute un Glue Record.

Un Glue Record sert à lier notre nom de domaine à nos propres serveurs DNS, en indiquant leurs adresses IP :

• l’adresse IPv4 de la machine mandataire (notre DNS principal),
• les adresses IPv6 des machines de service, si on veut un fonctionnement complet en IPv6.

Ensuite, on remplace les serveurs de noms (Nameservers) par les nôtres, c’est-à-dire notre propre serveur DNS.

Cela fait de notre serveur le référent officiel pour la gestion des noms de domaine associés à muspellheim2.online.

🧠 Pourquoi on fait tout ça ?

Eh bien, comme on l’a vu avec la commande :

dig @8.8.8.8 muspellheim2.online

Google a pu répondre car notre domaine est désormais public !

Si on n’avait pas fait cette configuration chez Gandi, personne sur Internet (hors de notre réseau) n’aurait pu le voir.

🌐 Pour faire simple :

En ajoutant un Glue Record et en configurant nos Nameservers, on annonce notre domaine au monde entier.

Cela permet à n’importe quel ordinateur sur Internet de retrouver l’adresse IP de notre serveur — et donc d’afficher notre site ou d’accéder à nos services.

DIFFUSION DE NOTRE SUPERBE SERVEUR AU MONDE

🌍 Une fois le Glue Record ajouté… on attend un peu que le monde entier soit au courant !

Une fois qu’on a :

• ajouté les Glue Records,
• remplacé les Nameservers dans le registrar (comme Gandi),

eh bien il faut patienter un peu. Pourquoi ? Parce que les informations DNS doivent se propager à travers le monde. Cette phase peut prendre quelques heures à quelques jours, selon les serveurs.

🛰️ Comment savoir si c’est bien propagé ?

Il existe des sites comme DNSChecker.org qui permettent de voir si votre nom de domaine est bien visible depuis plusieurs endroits de la planète.

📌 Exemple : muspellheim2.online

Sur DNSChecker, vous entrez votre domaine et choisissez le type d'enregistrement que vous voulez vérifier, par exemple :

Type	Ce que ça affiche
A	Adresse IPv4 liée au domaine
AAAA	Adresse IPv6
NS	Liste des Nameservers en charge du domaine
CNAME	Alias d’un domaine vers un autre
DNSKEY	Clés publiques DNSSEC (on y reviendra plus tard)

• ✅ Check vert : ça veut dire que ce serveur DNS a bien reçu et reconnu ton info.
• 🟡 Check en attente : propagation en cours ou serveur lent.
• ❌ Check rouge : info non encore propagée à ce serveur ou pas propagée car les certificats ne sont pas acceptés par ses serveurs DNS.

DNSSEC sur Atreus

🧭 Configuration DNS sur le serveur BIND – named.conf.local

📄 Fichier : /etc/bind/named.conf.local

Ce fichier contient la déclaration des zones DNS locales pour le serveur BIND.

On y définit ici :

-Une zone primaires (gérées en local)

-Une zone secondaire (copiée depuis un autre serveur)

Et une politique DNSSEC.

cat /etc/bind/named.conf.local

zone "muspellheim2.online" {

 type primary;
 file "/etc/bind/zones/muspellheim2.online/muspellheim2.zone";

allow-transfer{2001:660:4401:60a0:216:3eff:fee7:c51b;

              2001:660:4401:60a0:216:3eff:fed0:9ab0;};  // filtrage des secondaires

also-notify{2001:660:4401:60a0:216:3eff:fee7:c51b;}; // pour les secondaires vicieux notify yes; // notification des secondaires 
key-directory "/etc/bind/keys"; 
dnssec-policy "dnspol"; 
inline-signing yes; };

zone "jotunheim2.tech"{

       type slave;
       file "/etc/bind/jotunheim2.tech";
       primaries{2001:660:4401:60a0:216:3eff:fed0:9ab0;};

};


dnssec-policy "dnspol" {

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

};

🔹 type primary : Ce serveur est l'autorité principale pour la zone.

🔹 file : Chemin du fichier de zone contenant tous les enregistrements DNS (A, AAAA, NS, etc.).

🔹 allow-transfer : Liste des serveurs secondaires autorisés à faire un transfert de zone (AXFR). Cela sécurise l’accès aux données DNS.

🔹 also-notify : Force l’envoi de notifications DNS vers certains secondaires, même s’ils ne sont pas configurés comme secondaires officiels.

🔹 notify yes : Active les notifications automatiques des serveurs secondaires lorsqu’une mise à jour de la zone est faite.

🔹 dnssec-policy "dnspol" : Active DNSSEC avec une politique personnalisée.

🔹 inline-signing yes : Active la signature automatique de la zone par BIND.

Zone secondaire : jotunheim2.tech

zone "jotunheim2.tech" {
  type slave;
  file "/etc/bind/jotunheim2.tech";
  primaries { 2001:660:4401:60a0:216:3eff:fed0:9ab0; };
};

🔹 type slave : Ce serveur récupère les données de zone depuis un serveur primaire distant.

🔹 primaries { ... } : Adresse du serveur maître à interroger pour obtenir la zone.

🔹 file : Emplacement local où la zone est stockée après transfert.

🔐 Politique DNSSEC : "dnspol"

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

🔹 ksk : Key Signing Key (clé qui signe les autres clés DNS).

🔹 zsk : Zone Signing Key (clé qui signe les enregistrements DNS).

🔹 algorithm 13 : Il s’agit d’ECDSA P-256 with SHA-256 (RFC 6605), algorithme sécurisé et moderne.

🔹 nsec3param : Indique que NSEC3 est utilisé (permet de sécuriser les réponses "ce nom n'existe pas" sans divulguer d'autres noms).

✅ Les deux clés sont générées dans le répertoire key-directory, ont une durée de vie illimitée, et utilisent l’algorithme 13 (ED25519, rapide et sécurisé).

✅ nsec3param : active la protection contre l’énumération de noms (empêche de “scanner” une zone DNS facilement).

Pour que DNSSEC fonctionne correctement, il faut déclarer la clé KSK (Key Signing Key) chez votre registrar, ici Gandi.

Sur votre machine, les clés sont générées automatiquement dans le répertoire (key-directory dans le fichier /etc/bind/named.conf.local)

/etc/bind/keys/

Par exemple, vous pouvez voir des fichiers comme ceux-ci :

Kmuspellheim2.online.+013+03837.key
Kmuspellheim2.online.+013+03837.private
Kmuspellheim2.online.+013+03837.state

Kmuspellheim2.online.+013+14053.key
Kmuspellheim2.online.+013+14053.private
Kmuspellheim2.online.+013+14053.state

🗝️ Les fichiers importants :

• Les fichiers .key contiennent la clé publique (celle que vous devez copier/coller sur Gandi).
• Les fichiers .private contiennent la clé privée (à ne jamais partager !).
• Les fichiers .state servent à BIND pour gérer l’état et la durée de validité des clés.

Pour éviter tout problème avec la validation DNSSEC, pensez à mettre les deux fichiers .key dans l’interface de Gandi, dans la partie DNSSEC de votre domaine.

💡 En faisant cela, vous reliez votre zone DNS signée à la chaîne de confiance globale d’Internet : tout le monde pourra alors vérifier que vos données DNS sont authentiques et non modifiées.

Une fois la configuration DNSSEC en place, on peut tester si tout fonctionne correctement avec le site DNSViz.

Ce site permet d’analyser les signatures DNSSEC et de vérifier si la chaîne de confiance est bien construite du début à la fin (depuis la racine DNS jusqu’à votre zone).

Le graphe montre la chaîne de confiance DNSSEC :

• On part de la racine DNS (.), qui délègue au TLD .online.
• .online contient une clé DS qui fait le lien avec ton domaine muspellheim2.online.
• Ensuite, ton domaine possède ses propres clés (DNSKEY), qui signent toutes les infos de ta zone (A, NS, AAAA, etc.)

✅ Tout est "Secure" sur le graphe → la configuration DNSSEC est correcte et vérifiée !

APACHE

Configuration d’Apache sur GOW :

Apache va écouter les requêtes envoyées à muspellheim2.online, puis les rediriger vers un autre serveur (ici Atreus), via son adresse IPv6.

Cela permet d’accéder à un site web qui tourne sur Atreus même si celui-ci n’a pas d’IPv4 publique.

root@GOW:~# cat /etc/apache2/sites-available/muspellheim2.online.conf

#Partie HTTP (port 80)
<VirtualHost *:80>
    ServerName muspellheim2.online

    ProxyPass / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
    ProxyPassReverse / http://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
</VirtualHost>

# Partie HTTPS (port 443)
<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName muspellheim2.online

    SSLProxyEngine on
    ProxyPreserveHost on

    SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
    SSLCertificateKeyFile /etc/ssl/private/muspellheim2.online.key
    SSLCertificateChainFile /etc/ssl/certs/KGandiPierre/GandiCert.pem

    ProxyPass / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/
   ProxyPassReverse / https://[2001:660:4401:60a0:216:3eff:fe91:f4e3]/

</VirtualHost>
</IfModule>

📄 Fichier concerné : /etc/apache2/sites-available/muspellheim2.online.conf

Ce fichier configure un virtual host Apache2 pour le domaine muspellheim2.online, en mode proxy inverse (reverse proxy). Cela signifie que le serveur Apache2 reçoit les requêtes des utilisateurs et les redirige vers un autre serveur (Atreus), ici identifié par son adresse IPv6.

Le fichier gère deux protocoles :

- HTTP (port 80) — non sécurisé

- HTTPS (port 443) — sécurisé avec SSL/TLS

🔹 *VirtualHost :80 : Cela signifie que ce bloc s'applique à toutes les interfaces réseau, sur le port 80 (HTTP).

🔹 ServerName : Nom de domaine géré par ce virtual host. Apache redirigera les requêtes envoyées à muspellheim2.online.

🔹 ProxyPass / ... : Toutes les requêtes reçues sur / sont transmises à l'adresse IPv6 mentionnée. C’est là que tourne le vrai service web.

🔹 ProxyPassReverse : Permet de réécrire les en-têtes de redirection (comme les Location: envoyés par le serveur cible), pour que le client voit toujours muspellheim2.online au lieu de l’IP.

Atreus n’a pas d’IPv4 publique, donc il n’est pas directement joignable depuis Internet.

➜ GOW, qui a une IP publique, agit comme une porte d’entrée vers Atreus.

➜ C’est lui qui reçoit les requêtes extérieures et les redirige en interne vers le bon serveur.

On appelle ça un proxy inverse : le client ne sait pas que le site tourne ailleurs, tout passe par GOW.

Configuration d’Apache2 sur Atreus : le vrai serveur web – Site muspellheim2.online :

📄 Fichier : /etc/apache2/sites-available/000-muspellheim.conf

Ce fichier configure le serveur Apache2 sur la machine Atreus, qui héberge le véritable contenu du site muspellheim2.online. Il gère aussi bien les connexions HTTP que HTTPS.

<VirtualHost *:80>
    ServerName muspellheim2.online
    ServerAlias www.muspellheim2.online
    RedirectPermanent / https://muspellheim2.online/
</VirtualHost>

🔹 *VirtualHost :80 : Écoute sur le port HTTP.

🔹 ServerName / ServerAlias :

ServerName : Nom principal du site.

ServerAlias : Permet aussi de répondre à www.muspellheim2.online.

🔹 RedirectPermanent / : Redirige tout le trafic HTTP vers HTTPS.

💡 Pourquoi ?

C’est une bonne pratique de sécurité : on force tous les visiteurs à utiliser une connexion chiffrée.

Partie HTTPS – Serveur principal

<VirtualHost *:443>
    ServerName muspellheim2.online
    ServerAlias www.muspellheim.online
    ...
</VirtualHost>

 Port 443 : Pour les connexions HTTPS (chiffrées).

🔹 ServerName / ServerAlias : Idem que pour le port 80

SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem

🔹 Ces trois fichiers permettent au serveur d’offrir une connexion HTTPS sécurisée :

- .crt : certificat public du site.

- .key : clé privée (confidentielle).

- ChainFile : certificat intermédiaire (chaîne de certification, fourni par Gandi ici).

📝 Logs Apache

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

🔹 Gère la journalisation :

- error.log : erreurs serveur.

- access.log : toutes les requêtes reçues, avec IP, timestamp, etc.

# Partie HTTP (port 80)
<VirtualHost *:80>
    ServerName muspellheim2.online
    ServerAlias www.muspellheim2.online
    RedirectPermanent / https://muspellheim2.online/
</VirtualHost>

# Partie HTTPS (port 443)

<VirtualHost *:443>
    ServerName muspellheim2.online
    ServerAlias www.muspellheim.online
    # SSLProxyEngine on
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    SSLCertificateFile /etc/ssl/certs/muspellheim2.online.crt
    SSLCertificateKeyFile /etc/ssl/certs/private/muspellheim2.online.key
    SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
    <FilesMatch "\.(?:cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
        SSLOptions +StdEnvVars
    </Directory>
</VirtualHost>

Et comme Atreus est le vrai serveur, et que GOW redirige tout vers lui, ça permet à l’utilisateur de n’avoir aucune idée que deux serveurs travaillent ensemble derrière muspellheim2.online.

✅ Vérification finale : est-ce que le site est en ligne et accessible ?

Une fois que tout est configuré (serveur web, DNS, DNSSEC, reverse proxy, certificats...), il ne reste plus qu'à tester si le site fonctionne bien.

🧪 Méthode 1 : test en ligne de commande avec curl

curl -4 https://muspellheim2.online

curl -6 https://muspellheim2.online

🌍 Méthode 2 : test dans un navigateur

Vous pouvez aussi tout simplement ouvrir votre navigateur préféré et taper l’adresse :

https://muspellheim2.online

• curl -4 et curl -6 permettent de vérifier si votre site répond en IPv4 et IPv6.

• Si vous n’avez pas de retour ou que la connexion échoue, vérifiez :
  • votre config Apache
  • vos règles de pare-feu
  • vos enregistrements DNS
  • et que vos certificats sont bien en place