« Atelier SysRes SE4 2024/2025 E14 » : différence entre les versions

De wiki-se.plil.fr
Aller à la navigation Aller à la recherche
Ligne 182 : Ligne 182 :
'mac=00:16:3E:E7:C5:1B,bridge=SE4' ]
'mac=00:16:3E:E7:C5:1B,bridge=SE4' ]


</syntaxhighlight>Après avoir redémarré la machine, l’interface réseau est visible dans le fichier <code>/etc/network/interfaces</code>. On peut modifier ce fichier pour attribuer une adresse IP fixe à la machine GOW.<syntaxhighlight lang="bash">
</syntaxhighlight>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 <code>/etc/network/interfaces</code>. On peut modifier ce fichier pour attribuer une adresse IP fixe à la machine GOW.<syntaxhighlight lang="bash">
auto lo
auto lo
iface lo inet loopback
iface lo inet loopback
Ligne 283 : Ligne 291 :
* Serveur DNS maître : <code>ns.muspellheim2.online.</code>
* Serveur DNS maître : <code>ns.muspellheim2.online.</code>
* Contact admin : <code>admin@muspellheim2.online</code> (le point remplace le <code>@</code>)
* Contact admin : <code>admin@muspellheim2.online</code> (le point remplace le <code>@</code>)
A chaque modification de ce fichier, il faut incrémenter le numéro de version de +1.
On peut ensuite vérifier la syntaxe de notre '''fichier de zone DNS''' avec l’outil <code>named-checkzone</code>.
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 :<syntaxhighlight lang="ruby">
root@Atreus:~# named-checkzone muspellheim2.online /etc/bind/zones/muspellheim2.online/muspellheim2.zone
zone muspellheim2.online/IN: loaded serial 3609
OK
</syntaxhighlight>Ici, le message '''"OK"''' signifie que le fichier est bien écrit et ne contient pas d’erreurs de syntaxe.
Juste à noter : <code>named-checkzone</code> 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'''.


===== 📡 Serveurs DNS (NS) =====
===== 📡 Serveurs DNS (NS) =====

Version du 13 avril 2025 à 09:53

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 ainsi que d'une machine mandataire, orchestrées à l'aide de Xen. La machine Atreus occupe une place centrale dans l'hébergement des services, tandis que la machine GOW gère le réseau et assure la connectivité externe en IPv4 et IPv6. La deuxième machine de service est celle de Monsieur Antoine LECOMPTE, Kratos.

Df -h.png

vi /etc/hostname

  18  hostname -h

  19  hostname -h$

  20  host `cat /etc/hostname`

  21  hostname `cat /etc/hostname`

  22  cat  /etc/hostname

  23  reboot

  24  lsblk

  25  cat /etc/fstab

  26  mkfs -t ext4 /dev/xvda3

  27  mkfs -t ext4 /dev/xvdb1

  28  mount /dev/xvdb1 /mnt

  29  mv /var/* /mnt

  30  umount /mnt

  31  mount -a

  32  mkfs -t ext4 /dev/xvda3

  33  mkfs -t ext4 /dev/xvda3

  34  mount -a

  35  vi /etc/fstab

  36  mount -a

  37  df -h

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

Fichier_fstab
Fichier_fstab

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.

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

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

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.

📡 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é).


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



Interfacekratos
Interfacekratos
ip a de la machine SE4.Atreus
PingEntre2VM
PingEntre2VM

Configuration machine Mandataire

Fichier SE4.GOW.cfg montrant les deux bridges de notre machine mandataire. "bifrost" connecte nos 3 machines ensembles, "SE4" donne accès à Internet à nos 3 machines
Fichier SE4.GOW.cfg montrant les deux bridges de notre machine mandataire. "bifrost" connecte nos 3 machines ensembles, "SE4" donne accès à Internet à nos 3 machines
Ip forward.png

Commande : iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.168.3.0/24


Ssh machine.png

SSH : faire les commandes sur les 3 machines, et modifier le fichier ssh config dans /etc/ssh/ en mettant l'option PermitRootLogin yes


Faire la demande des certificats en ligne avec la commande openssl req -nodes -newkey rsa:2048 -sha256 -keyout myserver.key -out server.csr -utf8.



APACHE

IPV4

Configuration et redémarrage d’Apache sur GOW :

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.

Configuration Apache sur la machine Atreus – 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. C’est une bonne pratique de sécurité, car elle force la navigation sécurisé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>
PIng en IPv6