Atelier SysRes SE4 2025/2026 E8

De wiki-se.plil.fr
Révision datée du 10 février 2026 à 15:40 par Yyahiani (discussion | contributions) (→‎Test de la LAN)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à la navigation Aller à la recherche

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:

Ipv6.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 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 rs7.online et une zone secondaire pour c2vts.fr. 

zone "rs7.zone" {
    type primary;
    file "/etc/bind/zones/rs7.zone.signed";
    allow-transfer { secondaries; };
    also-notify { 2001:660:4401:60a0:216:3eff:fee4:9c08; };
    key-directory "/etc/bind/rs7.dnssec";
    dnssec-policy "dnspol";
    inline-signing yes;
};

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

acl "secondaries" {
    2001:660:4401:60a0:216:3eff:fed3:58ae;
    2001:660:4401:60a0:216:3eff:fee4:9c08;
};

zone "c2vts.fr" {
    type secondary;
    file "/etc/bind/backup/c2vts.fr.zone";
    primaries { 2001:660:4401:60a0:216:3eff:fed3:58ae; };
};

Création et configuration du fichier .zone

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

$TTL 200
@       IN      SOA     ns.rs7.online. admin.rs7.online. (
        4004    ; Version
        21600   ; Refresh secondary    (6h)
        3600    ; Retry secondary      (1h)
        2592000 ; Expire if no refresh (30j)
        86400 ) ; Negative cache       (24h)

; Serveurs de noms
@        IN      NS      ns.rs7.online.
@        IN      NS      ns.c2vts.fr.

;Enregistrements A 
@        IN     A     193.48.57.170
ns       IN     A     193.48.57.170 

;Enregistrements AAAA
@        IN     AAAA  2001:660:4401:60a0:216:3eff:fed3:d693
ns       IN     AAAA  2001:660:4401:60a0:216:3eff:fed3:d693

;Enregistrements CNAME
www      IN     CNAME rs7.online.

$include "/etc/bind/rs7.dnssec/rs7.online-ksk.key"
$include "/etc/bind/rs7.dnssec/rs7.online-zsk.key"

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

root@Gtr:/etc/bind/zones/rs7.online# named-checkzone rs7.zone
zone rs7.zone/IN: loaded serial 4004
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.

DNS.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: 

zone "rs7" {
    type primary;
    file "/etc/bind/zones/rs7.zone.signed";
    allow-transfer { secondaries; };
    also-notify { 2001:660:4401:60a0:216:3eff:fee4:9c08; };
    key-directory "/etc/bind/rs7.dnssec";
    dnssec-policy "dnspol";
    inline-signing yes;
};

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

acl "secondaries" {
    2001:660:4401:60a0:216:3eff:fed3:58ae;
    2001:660:4401:60a0:216:3eff:fee4:9c08;
};

zone "c2vts.fr" {
    type secondary;
    file "/etc/bind/backup/c2vts.fr.zone";
    primaries { 2001:660:4401:60a0:216:3eff:fed3:58ae; };
};

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@rs7:/etc/bind/rs7.dnssec# ls
Krs7.+013+14689.key	 Krs7.+013+57317.private  rs7.online-ksk.private
Krs7.+013+14689.private  Krs7.+013+57317.state	  rs7.online-zsk.key
Krs7.+013+14689.state	 dsset-rs7.		  rs7.online-zsk.private
Krs7.+013+57317.key	 rs7.online-ksk.key

Nous pouvons maintenant verifier sur le site "DNSViz" le DNS de rs7.online.

Fail2ban

Pour se protéger contre les attaques par brute force sur le service SSH, nous utilisons l’outil Fail2ban. La première étape consiste à modifier le fichier jail.local afin d’y définir les paramètres de protection suivants : 

[sshd]
enabled = true
port    = ssh
filter  = sshd
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
findtime = 600
bantime  = 600

Dans cette configuration :

  • maxretry indique le nombre maximal de tentatives autorisées avant le bannissement ;
  • findtime correspond à la période durant laquelle les tentatives sont comptabilisées avant réinitialisation ;
  • bantime définit la durée du bannissement de l’adresse IP fautive.

La commande fail2ban-client status sshd permet ensuite de consulter l’état du jail SSH, notamment le nombre de tentatives échouées, le nombre total de bannissements et la liste des adresses IP actuellement bloquées. 

root@rs7:/etc/bind# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     1
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     1
   `- Banned IP list:

Le même principe est appliqué pour limiter les attaques visant le service DNS. On ajoute alors une nouvelle configuration dans le fichier jail.local : 

[connect-refused]
enabled  = true
port     = domain
protocol = tcp
filter   = connect-refused
logpath  = /var/log/syslog
maxretry = 3
bantime  = 600
findtime = 600

Il est ensuite nécessaire de créer un filtre personnalisé dans le répertoire filter.d, nommé connect-refused.conf, afin de définir les motifs de requêtes TCP à bloquer : 

root@rs7:/etc/fail2ban/filter.d# cat connect-refused.conf
[Definition]
failregex = .* client_ip=<HOST>.*(NXDOMAIN|SERVFAIL|REFUSED).*
ignoreregex =

Enfin, la commande fail2ban-client status connect-refused permet de vérifier l’activité de ce jail, notamment les tentatives détectées et les adresses IP bannies. 

root@rs7:/etc/fail2ban/filter.d# fail2ban-client status connect-refused
Status for the jail: connect-refused
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/syslog
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

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@rs7:~# 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/rs7.online.crt : Certificat SSL
/etc/ssl/private/rs7.online.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 (rs7.online) dans le répertoire `/etc/apache2/sites-available/rs7.online.conf`. Ce fichier définit un `VirtualHost` pour le port 443 et redirige toute les requetes http sur le port 80 vers https : 

root@rs7:~# cat /etc/apache2/sites-available/rs7.online.conf 
 <VirtualHost *:80>
        ServerName rs7.online.
	ServerAlias www.rs7.online.
        Redirect permanent / https://rs7.online/  
 </VirtualHost>

 <VirtualHost *:443>

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

        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/rs7.online.crt
        SSLCertificateKeyFile /etc/ssl/private/rs7.online.key
        SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem
        SSLVerifyClient None
	ProxyPass / http://[2001:660:4401:60a0:216:3eff:fed3:d693]/
	ProxyPassReverse / http://[2001:660:4401:60a0:216:3eff:fed3:d693]/
        SSLProxyEngine on
	<Directory /var/www/rs7.online>
		AllowOverride All
		Require all granted
	</Directory>
	ErrorLog ${APACHE_LOG_DIR}/rs7.online_error.log
	CustomLog ${APACHE_LOG_DIR}/rs7.online_access.log combined


 </VirtualHost>

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=12174 »