« Atelier SysRes SE4 2025/2026 E8 » : différence entre les versions

De wiki-se.plil.fr
Aller à la navigation Aller à la recherche
Ligne 226 : Ligne 226 :
nameserver 193.48.57.48
nameserver 193.48.57.48


search wahran.online
search rs7.online
nameserver 192.168.0.2
nameserver 192.168.7.2
nameserver 192.168.0.3
nameserver 192.168.7.3
</syntaxhighlight>
</syntaxhighlight>


Version du 7 février 2026 à 17:28

Création du pont et des VM

Création du pont:

Dans capbreton, dans /etc/network/interfaces on renseigne notre pont pontclio 

auto pontclio
iface pontclio inet manual
  bridge_ports none
  up ip link set $IFACE up
  down ip link set $IFACE down

Partitions

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

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

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

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

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

xen create SE4.RS7.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.RS7

Ensuite créer les partitions var et home: 

lvcreate -L10G -nSE4.RS7.home virtual
lvcreate -L10G -nSE4.RS7.var virtual

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 /var ext4 defaults 0 2
/dev/xvdb1 /home ext4 defaults 0 2

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, 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.7.2 
    netmask 255.255.255.0
    gateway 192.168.7.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 : 

# The loopback network interface
auto lo
iface lo inet loopback

# Primary interface
auto eth0
iface eth0 inet static
    address 192.168.7.1/24

# Second interface
auto eth1
iface eth1 inet static
    address 193.48.57.170/27
    gateway 193.48.57.164

iface eth1 inet6 auto

Tests

Après avoir mis UP toute les interfaces de nos VM nous obtenons bien nos adresse IPv4 et IPv6.

Voici l'état des interfaces de la machine de service RS7 : 

root@rs7:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:d3:d6:92 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.2/24 brd 192.168.7.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fed3:d692/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:d3:d6:93 brd ff:ff:ff:ff:ff:ff
    inet6 2001:660:4401:60a0:216:3eff:fed3:d693/64 scope global dynamic mngtmpaddr 
       valid_lft 942sec preferred_lft 842sec
    inet6 fe80::216:3eff:fed3:d693/64 scope link 
       valid_lft forever preferred_lft forever

Et voici l'état des interface de la machines mandataire Garage : 

root@Garage:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:e4:9c:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.1/24 brd 192.168.7.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fee4:9c07/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:e4:9c:08 brd ff:ff:ff:ff:ff:ff
    inet 193.48.57.170/27 brd 193.48.57.191 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 2001:660:4401:60a0:216:3eff:fee4:9c08/64 scope global dynamic mngtmpaddr 
       valid_lft 893sec preferred_lft 793sec
    inet6 fe80::216:3eff:fee4:9c08/64 scope link 
       valid_lft forever preferred_lft forever

Test de la LAN

Nous pouvons maintenant ping entre nos VM, voici un ping de RS7 vers C2:

Ping C2.png

Et voici un ping de RS7 vers Garages

Ping Garage.png

Test vers l'extérieur

Nous vérifions maintenant si ma machines de service RS7 à bien accès à internet en IPv4 (via la VM mandataire) et en IPv6.

Voici un ping de RS7 vers l'extérieur en IPv4:

Ping ipv4.png

Et voici un ping de RS7 vers l'extérieur en IPv6:

Fichier:Ping ipv6

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 rs7.online
nameserver 192.168.7.2
nameserver 192.168.7.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.

Fail2Ban

Nous pouvons implémenter une fonctionnalité pour sécuriser notre VM : bannir une IP après plusieurs tentative de connexions ssh raté. dans /etc/fail2ban/jail.local nous ajoutons ces options: 

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

Après 5 tentative de ssh échouée, l'IP en question sera banni 10 minutes:

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 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 h, nous somme redirigé vers .

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
Récupérée de « http:///mediawiki/index.php?title=Atelier_SysRes_SE4_2025/2026_E8&oldid=12102 »