Atelier SysRes SE4 2024/2025 E7
Création de la machine
Création des VMs avec XEN
Dans ce projet, nous avons 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.Vi --dhcp --bridge=ekko_caitlyn --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=2048M --force
Par la suite pour les démarrer on utilise:
xen create /etc/xen/SE4.Vi.cfg
Et pour y rentrer:
xen console SE4.Vi
Configuration des partitions LVM
Assigner les partitions dans le fichier `/etc/xen/SE4.Vi` (disk) :
'phy:/dev/virtual/SE4.Vi-home,xvda3,w',
'phy:/dev/virtual/SE4.Vi-var,xvdb1,w',
Affichage des partitions avec lsblk
Voici un aperçu des partitions avec la commande `lsblk` :
Modification du fichier fstab
Il faut aussi modifier le fichier `/etc/fstab` pour monter correctement les partitions :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvdb1 /var ext4 defaults 0 2
Aperçu du fichier fstab
Configuration des partitions /var et /home
Formatage et montage de /var (partition critique)
Création du système de fichiers et migration des données de `/var` :
mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a
Vérification du contenu de /var
Formatage et montage de /home
mkfs -t ext4 /dev/xvda3
mount -a
Vérification du montage des partitions
Réseau
Pour la partie réseau de la machine de service j'ai simplement modifié l'interface réseau de celle-ci. J'ai mis en place deux interfaces pour les deux bridges
ETH0: J'ai mis le routage de l'ipv6 en auto et pour l'ipv4 j'ai mit l'adresse privée correspondant à ma machine dans le réseau privé. On utilise l'adresse ipv4 privée de la machine mandataire comme gateway.
ETH1:
Configuration de la machine mandataire et routeur Cisco
Création des clés et des certificat pour les noms de domaines
Pour activer un certificat SSL, il est nécessaire de générer une CSR ainsi qu’une clé privée.
Les fichiers générés sont enregistrés dans les répertoires suivants sur la machine mandataire Vander :
- /home/cait
- /home/ekko
Lancer la commande OpenSSL
Depuis un terminal on exécutez la commande suivante :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout myserver.key -out server.csr -utf8
Remplir les informations requises
On doit donc remplir des informations comme
- Common Name : Nom de domaine principal 'caitlyn.eu'
- Pays, Région, Ville : Coordonnées de l’organisation.
Vérifier et copier la CSR
Une fois générée, la CSR peut être affichée avec :
cat server.csr
On copie ainsi le contenu du csr dans Gandi pour obtenir un certificat signé.
-----BEGIN CERTIFICATE REQUEST-----
… texte ….
-----END CERTIFICATE REQUEST-----Problème de renouvellement du certificat et validation DNS
Lors du renouvellement du certificat SSL pour le domaine caitlyn.eu, un problème a été rencontré : la clé privée initialement conservée ne correspondait pas au certificat signé reçu via Gandi. Cela a empêché la mise en place du nouveau certificat sur le serveur Apache.
Résolution du problème
Afin de corriger cette erreur, j'ai procédé aux étapes suivantes :
Génération d’une nouvelle paire de clés et CSR
Une nouvelle clé privée et une nouvelle demande de certificat ont été générées via la commande suivante :
openssl req -new -newkey rsa:2048 -nodes -keyout caitlyn.key -out caitlyn.csr
Cette commande génère une clé privée (caitlyn.key) et un fichier de requête de signature (caitlyn.csr) nécessaire à la création d’un nouveau certificat.
Validation du domaine via DNS
L’autorité de certification exigeait une nouvelle validation de la propriété du domaine. La méthode choisie fut la validation par enregistrement DNS.
Les enregistrements suivants ont été ajoutés dans la zone DNS du domaine caitlyn.eu :
_mznyn1dwqlil5cvfou9kcwr48c8cfku.caitlyn.eu. 10800 IN CNAME dcv.digicert.com. _mznyn1dwqlil5cvfou9kcwr48c8cfku.www.caitlyn.eu. 10800 IN CNAME dcv.digicert.com.
Ces entrées permettent à DigiCert de vérifier automatiquement que nous sommes bien propriétaires du domaine.
Vérification de la propagation DNS
Avant de poursuivre, un check DNS a été effectué (via un outil tel que dig, nslookup ou un site en ligne) pour s'assurer que les enregistrements étaient bien visibles publiquement et correctement propagés.
Une fois la validation réussie, le nouveau certificat signé a pu être récupéré et déployé sur le serveur Apache.
Serveur SSH
Afin d'éviter de passer tout le temps par capbreton pour se connecter à nos machines, on met en place un serveur ssh pour pouvoir y accéder directement. Pour vander possédant directement une adresse ipv4 routée il suffit de mettre le PermitRootLogin en yes. Mais nos machines de services n'en possèdant pas, il est nécessaire d'effectuer une redirection de port sur la mandataire, en redirigeant le port 2202 sur Vi.
iptables -t nat -A PREROUTING -p tcp --dport 2202 -j DNAT --to-destination 192.168.1.2:22
iptables -A FORWARD -p tcp -d 192.168.1.2 --dport 22 -j ACCEPT
Serveur DNS
Configuration du fichier named.conf.options
J'ai édité le fichier de configuration named.conf.options:
J'ai aussi rajouter l'emplacement de mes clés dans la définition de ma zone
key-directory "/etc/bind/keys"; dnssec-policy "dnspol"; inline-signing yes;
J'ai ajouté les lignes suivantes pour activer DNSSEC via les clés:
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
J'indique que cette zone représente ma zone principale, puis j'autorise tout le monde à interroger mon serveur DNS. Puis pour terminer j'ajoute le transfer de ma zone à la machine mandataire Vander ainsi qu'a la deuxième machine de service Jinx en les tenant au courant d'une modification de la zone grâce au notify.
Afin de permettre à l'autre machine de service de faire fonctionner mon DNS je dois spécifier une zone dans son named.conf.local
Création du fichier de zone
Puis ensuite j'ai créé le fichier de zone. Pour cela on y spécifie: -Le SOA spécifie le serveur DNS principal ns1.caitlyn.eu et l’adresse e-mail de l’administrateur admin.caitlyn.eu -A et AAAA associent le domaine à ses adresses IPv4 et IPv6 respectives -CNAME redirige www.caitlyn.eu vers caitlyn.eu, évitant ainsi d’avoir à dupliquer les enregistrements IP.
5. Configuration du serveur mandataire comme DNS secondaire
Nous avons ajouté sur le serveur mandataire :
zone "caitlyn.eu"{
type secondary; // version politiquement correcte de slave
file "/etc/bind/caitlyn.eu";
primariest{ 2001:660:4401:60a0:216:3eff: fe5b:8277; };
｝
(
)
6. Activation de DNSSEC
J'ai ajouté la politique DNSSEC dans `/etc/bind/named.conf` :
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};
Puis j'ai activé DNSSEC :
sudo systemctl restart bind9
7. Ajout des enregistrements DNS chez Gandi
Nous avons ajouté les glue records dans l’interface de Gandi en spécifiant : - `ns1.caitlyn.eu` avec l’adresse IPv6 du serveur de services - `ns2.caitlyn.eu` avec l’adresse IPv4 du serveur mandataire
Conclusion
Le serveur DNS est maintenant configuré avec Bind9 et sécurisé avec DNSSEC. Le serveur mandataire joue le rôle de serveur DNS secondaire et permet l'accès via IPv4. La configuration est testée et fonctionnelle.
Apache
Pour configurer un serveur web HTTPS, la première étape consiste à récupérer le certificat signé (.crt) ainsi que le certificat de chaîne (.pem) depuis Gandi. La clé privée, obtenue précédemment via OpenSSL, doit être conservée.
Le fichier de configuration Apache pour *caitlyn.eu* est présenté ci-dessous :
Toutes les requêtes arrivant sur le port 80 sont redirigées vers le port 443 afin d'imposer l'utilisation du protocole HTTPS.
La directive *DocumentRoot* définit le répertoire dans lequel seront stockés les fichiers HTML et autres ressources du site.
Les paramètres liés à SSL spécifient les emplacements des certificats et de la clé privée. Il est essentiel de vérifier les permissions des fichiers et répertoires pour s'assurer que l'utilisateur/groupe *www-data* puisse y accéder correctement.
De plus, il convient de vérifier les ports écoutés par Apache dans */etc/apache2/ports.conf*.
Configuration de l'accès IPv4
Il est nécessaire d'autoriser l'accès en IPv4 à HTTPS. Initialement, l'accès au site était impossible depuis mon réseau (FAI : Crous, Planet Campus) car celui-ci ne fournissait qu'une connexion IPv6.
Pour contourner cette limitation, on utilise une machine mandataire et on configure Apache2 en proxy inverse sur celle-ci.
Voici un exemple de fichier de configuration correspondant :
L'ajout de la directive suivante est requis pour assurer des redirections correctes vers les sites ciblés :
ProxyPreserveHost on
Il est également indispensable d'activer les modules *proxy* et *proxy_http*, ainsi que le site concerné :
a2enmod proxy
a2enmod proxy_http
a2ensite ekko.my.conf
service apache2 reload
service apache2 restart
Une fois ces étapes complétées, le serveur Apache est prêt à gérer les connexions HTTPS correctement.