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

De wiki-se.plil.fr
Aller à la navigation Aller à la recherche
Ligne 284 : Ligne 284 :
</syntaxhighlight>
</syntaxhighlight>


Nous pouvons maintenant verifier sur le site "DNSViz" le DNS de ns.wahran.online
Nous pouvons maintenant verifier sur le site "DNSViz" le DNS de ns.wahran.online, pour l'instant le site indique une erreur : wahran.online zone: The server(s) were not responsive to queries over UDP.
 
J'essaye de regler cela.


=HTTPS=
=HTTPS=

Version du 8 mars 2025 à 17:27

Création de la VM

Partitions

Nous commençons par nous mettre en ssh sur capbreton et à rentre cet commande pour créer nos machines virtuelles (2 VM services + 1 VM mandataire) :

xen-create-image --hostname=SE4.Gtr --dhcp --dir=/usr/local/xen --size=10G --dist=daedalus --memory=2G --bridge=alloco_wahran

Ensuite nous assignons les partitions dans le fichier /etc/xen/SE4.Gtr.cfg:

phy:/dev/virtual/SE4.Jinx-home,xvdb1,w,
phy:/dev/virtual/SE4.Jinx-var,xvda3,w,

Pour démarrer notre VM nous exécutons la commande suivante:

xen create SE4.Gtr.cfg

Ensuite nous pouvons vérifier si la VM est démarrée avec:

xen list

Par la suite nous nous connectons à la VM de cette manière:

xen console SE4.Gtr

Nous devons maintenant implémenter /var et /home dans nos partitions LVM, on se place donc dans le fichier /etc/fstab pour y ajouter nos disk:

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

(J'ai fais une petite erreur sur cette partie car j'ai assigné /dev/xvdb1 à /var alors que ce n'était pas le bon, /var était sur xvda3, cette erreur n'est pas si grave je vais juste devoir faire attention à bien différencier /var et /home par la suite)

Et nous formatons ces disk avec ces deux commandes:

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

Il faut maintenant Mount les fichiers à implémenter le /var (xvda3 pour moi), or j'ai Mount le xvdb1 par mégarde comme énoncé ci-dessus:

mount /dev/xvdb1 /mnt

On copie les données et on démonte le fichier copié:

mv /var/* /mnt
unmount /mnt

Nous pouvons maintenant observer les changement:

mount -a

IP

Nous voulons maintenant assigner des adresse IPv4 et IPv6 à nos VM, chaque VM de service aura une IP privée, la VM mandataire aura une IP privée + une IP routée, pour cela nous modifions le fichier /etc/network/interfaces de nos VM, il ne faut pas oublier de modifier le fichier .cfg pour rajouter nos machines sur le commutateur SE4 (commutateur de la promo) en prenant la même adresse MAC et faire +1:

VM de service

Pour configurer le réseau, nous modifions le fichier /etc/network/interfaces afin d’attribuer une adresse IPv4 et une adresse IPv6.

Tout d'abord nous devons mettre nos machines sur le commutateur de la promo en modifiant le fichier .cfg:

L’adresse IPv6 ne pose aucun problème : il suffit d’ajouter la ligne suivante :

iface eth0 inet6 auto

Concernant l’adresse IPv4, nous avons choisi une adresse privée pour l’utilisation de notre binôme : 192.168.0.0/24.

De plus, la machine mandataire joue le rôle de passerelle (gateway) pour les deux machines de services. Nous lui avons attribué l’adresse IPv4 192.168.0.1.

Nous complétons donc le fichier avec une adresse statique :

iface eth0 inet static
    address 192.168.0.2 
    netmask 255.255.255.0
    gateway 192.168.0.1

VM mandataire

Ensuite, il est nécessaire d’attribuer une seconde adresse IPv4 sur eth1. Toutefois, cette interface n’existe pas par défaut sur les machines virtuelles (VM). Il faut donc la créer en modifiant le fichier .cfg de la machine sur Capbreton.

Dans la section Networking, on trouve une ligne vif à modifier. Nous l’ajustons pour ajouter une interface eth1 sur le bridge SE4, tout en conservant eth0.

Après avoir redémarré la machine, l’interface eth1 sera disponible. Nous pouvons alors mettre à jour le fichier /etc/network/interfaces :

auto eth0
iface eth0 inet static
    address 192.168.0.1
    netmask 255.255.255.0
#iface eth0 inet dhcp
# post-up ethtool -K eth0 tx off
iface eth0 inet6 auto

auto eth1
iface eth1 inet static
    address 193.48.57.162/28
    gateway 193.48.57.161

Après avoir fait un ifdown et un ifup nous pouvons envoyer des pings entre nos VM de service et avec la VM mandataire:

Ping de SE4.Gtr (192.168.0.2) vers SE4.Gyro (192.168.0.3):

Ping gyro.png

Ping de SE4.Gtr (192.168.0.2) vers SE4.Pegase (192.168.0.1):

Ping pegase.png

SSH

Nous avons configuré l’accès SSH à notre machine virtuelle Xen de services en autorisant la connexion de l’utilisateur root via le fichier /etc/ssh/sshd_config en activant l’option PermitRootLogin. Pour permettre l’accès via IPv4, nous avons mis en place une redirection de ports en utilisant iptables/nftables, en assignant le port 2203 à notre machine de services. De plus, nous avons installé les services essentiels, à savoir SSH, Apache2 pour l’hébergement web, ainsi que BIND pour la gestion des services DNS sur nos machines virtuelles.

DNS

Configuration du résolveur

Nous avons configuré le serveur DNS de notre machine de services en modifiant le fichier resolv.conf pour y ajouter notre propre serveur DNS. Cela permet à la machine d’utiliser le bon résolveur pour la résolution des noms de domaine:

search plil.info
nameserver 172.26.188.12
nameserver 193.48.57.48

search wahran.online
nameserver 192.168.0.2
nameserver 192.168.0.3

Configuration des zones

Ensuite, nous avons modifié le fichier named.conf.local du package BIND9 afin de déclarer une zone principale pour wahran.online et une zone secondaire pour alloco.online.

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "wahran.online" {
	type master;
	file "/etc/bind/wahran.online/wahran.zone";
	allow-transfer{secondaries;}; // filtrage des secondaires
//	also-notify{hiddensecondaries;}; // pour les secondaires vicieux
	notify yes; // notification des secondaires
};

acl "secondaries" {
	192.168.0.3; // serveur secondaire
	2001:660:4401:60a0:216:3eff:fe81:abfe; //serveur secondaire IPV6

Création et configuration du fichier .zone

Nous avons ensuite créé et configuré le fichier wahran.zone.

$TTL 100

@	IN	SOA	ns.wahran.online.	postmaster.wahran.online. (
	3600	; Version
	21600	; Refresh secondary	(6h)
	3600	; Retry secondary	(1h)
	2592000	; Expire if no refresh	(30 jours)
	86400	; Negative cache	(24h)
)

; Enregistrements des serveurs de noms
@	IN	NS	ns.wahran.online.
@	IN	NS	ns2.alloco.online.

; Enregistrements AAAA (IPv6)
ns	IN AAAA		2001:660:4401:60a0:216:3eff:fe32:8fa2

: Enregistrements A (IPv4)
ns	IN A		193.48.57.164

; Enregistrements CNAME
www	IN CNAME	wahran.online

On charge la version du fichier de zone avec la commande suivante :

root@Gtr:/etc/bind/wahran.online# named-checkzone wahran.zone wahran.zone 
zone wahran.zone/IN: loaded serial 3601
OK

Vérifications

Enfin, nous avons vérifié la syntaxe et chargé ces fichiers de zone en utilisant la commande suivante dans le répertoire concerné :

named-checkzone <nom du fichier>

Ces configurations nous permettent d’assurer une résolution correcte des noms de domaine et de gérer efficacement notre infrastructure DNS.

Après avoir effectué ces modifications, nous pouvons vérifier si notre DNS s’est correctement propagé sur le site DNSchecker. Comme le montre cet capture d'écran, la propagation est bien effective dans la zone de Lille avec une adresse IPv6 :

DNS Lille.png

DNSSEC

Configuration de la méthode automatique

Pour sécuriser notre DNS, nous modifions notre fichier named.conf.local pour utiliser la méthode automatique:

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "wahran.online" {
	type master;
	file "/etc/bind/wahran.online/wahran.zone";
	allow-transfer{secondaries;}; // filtrage des secondaires
//	also-notify{hiddensecondaries;}; // pour les secondaires vicieux
	notify yes; // notification des secondaires
	key-directory "/etc/bind/keys"; //repertoire des keys
  	dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
  	inline-signing yes; //activation de la signature automatique
};

acl "secondaries" {
	192.168.0.3; // serveur secondaire
	2001:660:4401:60a0:216:3eff:fe81:abfe; //serveur secondaire IPV6
};

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

Génération des clés

ensuite nous créeons le répertoire qui va acceuillir nos clés:

mkdir -p /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys

et nous redémarrons le service :

service named restart

voici nos clés disponible dans le répertoire /etc/bind/keys crée ci-dessus:

root@Gtr:~# ls /etc/bind/keys
Kwahran.online.+013+17231.key	   Kwahran.online.+013+62188.key
Kwahran.online.+013+17231.private  Kwahran.online.+013+62188.private
Kwahran.online.+013+17231.state    Kwahran.online.+013+62188.state

Nous pouvons maintenant verifier sur le site "DNSViz" le DNS de ns.wahran.online, pour l'instant le site indique une erreur : wahran.online zone: The server(s) were not responsive to queries over UDP.

J'essaye de regler cela.

HTTPS

Installation d'Apache2

Dans un premier temps, j'ai installé le serveur Apache en utilisant la commande suivante :

aptitude install apache2

Ensuite, j'ai activé le module SSL pour permettre les connexions HTTPS :

a2enmod ssl

Activation du port HTTPS

Dans le fichier `/etc/apache2/ports.conf`, j'ai ajouté la configuration nécessaire pour qu'Apache écoute sur le port 443, le port HTTPS :

root@Gtr:~# cat /etc/apache2/ports.conf
# Port HTTP classique
Listen 80

# Port HTTPS
<IfModule ssl_module>
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>

Configuration du certificat SSL

J'ai installé un certificat SSL, ainsi que la clé privée et le certificat intermédiaire fourni par Gandi pour créer une chaîne de confiance. Ces fichiers sont placés dans les répertoires appropriés sur le serveur :

/etc/ssl/certs/wahran.online.crt : Certificat SSL
/etc/ssl/private/myserver.key : Clé privée
/etc/ssl/certs/GandiCert.pem : Certificat intermédiaire

Configuration du domaine sécurisé

J'ai créé un fichier de configuration spécifique pour mon domaine (wahran.online) dans le répertoire `/etc/apache2/sites-available/000-wahran.online-ssl.conf`. Ce fichier définit un `VirtualHost` pour le port 443 et redirige toute les requetes http sur le port 80 vers https :

root@Gtr:~# cat /etc/apache2/sites-available/000-wahran.online-ssl.conf 

  <VirtualHost *:80>
        ServerName ns.wahran.online
        Redirect permanent / https://ns.wahran.online/  
 </VirtualHost>

 <VirtualHost *:443>

        ServerName wahran.online
        ServerAlias wahran.online
        DocumentRoot /var/www/wahran.online/
        CustomLog /var/log/apache2/secure_access.log combined

        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/wahran.online.crt
        SSLCertificateKeyFile /etc/ssl/private/myserver.key
        SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
        SSLVerifyClient None
        SSLProxyEngine on

lorsque l'on se rend sur http://ns.wahran.online, nous somme redirigé vers https://ns.wahran.online.

Configuration DNS avec DNSSEC

Pour la gestion des DNS de mon domaine, j'ai configuré le fichier `/etc/bind/named.conf.local` pour ajouter la zone DNS de `wahran.online` avec une politique DNSSEC, ce qui renforce la sécurité de la gestion de mes enregistrements DNS :

root@Gtr:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "wahran.online" {
	type master;
	file "/etc/bind/wahran.online/wahran.zone";
	allow-transfer{secondaries;}; // filtrage des secondaires
//	also-notify{hiddensecondaries;}; // pour les secondaires vicieux
	notify yes; // notification des secondaires
	key-directory "/etc/bind/keys"; //repertoire des keys
  	dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
  	inline-signing yes; //activation de la signature automatique
};

acl "secondaries" {
	192.168.0.3; // serveur secondaire
	2001:660:4401:60a0:216:3eff:fea0:ae02; //IPv6 Proxy
	2001:660:4401:60a0:216:3eff:fe81:abfe; //serveur secondaire IPV6
};

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

masters "hiddensecondaries"{
	2001:660:4401:60a0:216:3eff:fea0:ae02;
};

zone "alloco.online"{
	type slave;
	file "/etc/bind/backup/alloco.online";
	masters{2001:660:4401:60a0:216:3eff:fe81:abfe;};
};

Vérification du certificat SSL

Enfin, j'ai effectué le rehash de la structure SSL pour m'assurer que tous les certificats étaient bien reconnus et prêts à être utilisés :

c_rehash /etc/ssl/certs