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

De wiki-se.plil.fr
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Ligne 48 : Ligne 48 :
===Interface Réseau===
===Interface Réseau===
On modifie la configuration réseau de la machine mandataire dans <code>/etc/interfaces</code>
On modifie la configuration réseau de la machine mandataire dans <code>/etc/interfaces</code>
On modifie le .cfg de la machine de service pour qu'elle est deux interfaces, une pour communiquer avec le routeur, crée par nos camarades. Et une autre qui est le pont qu'on a créé pour parler entre nos trois machines.
On modifie le .cfg de la machine de service pour qu'elle est deux interfaces, une pour communiquer avec le routeur, crée par nos camarades. Et une autre qui est le pont que l'on a créé pour parler entre nos trois machines.
<syntaxhighlight>
<syntaxhighlight>
vif        = [ 'mac=00:16:3E:08:13:E7,bridge=bifrost',  
vif        = [ 'mac=00:16:3E:08:13:E7,bridge=bifrost',  
Ligne 55 : Ligne 55 :
</syntaxhighlight>
</syntaxhighlight>


Après avoir redémarré la machine, l'interface apparait dans le fichier <code>/etc/network/interfaces</code> que l'on peut modifier pour configurer l'adresse IP de GOW.
Après avoir redémarré la machine, l'interface apparait dans le fichier <code>/etc/network/interfaces</code> que l'on peut modifier pour rajouter l'adresse IP de GOW.
<syntaxhighlight lang="shell">
<syntaxhighlight lang="shell">
auto lo
auto lo

Version du 14 mars 2025 à 17:25

Projet AARV LECOMTE et CASIMIRI

Configuration de Kratos

Création de la machine

xen-create-image --hostname=SE4.Kratos --dhcp --bridge=bifrost --dir=/usr/local/xen --size=10GB --dist=daedalus --memory=1024M --force

La commande pour démarrer la machine depuis le fichier /etc/xen 

xen create SE4.Kratos.cfg

Puis on s'y connecte

xen console SE4.Kratos

Var et Home

On monte les disques /var /home

/dev/xvda3 /home ext4 defaults 02

/dev/xvdb1 /var ext4 defaults 02

dans /etc/fstab

On modifie ensuite le fichier .cfg de la machine pour y ajouter les répertoires créer au préalable dans le dossier /dev/virtual de capbreton 

disk        = [
                  'file:/usr/local/xen/domains/SE4.Kratos/disk.img,xvda2,w',
                  'file:/usr/local/xen/domains/SE4.Kratos/swap.img,xvda1,w',
		          'phy:/dev/virtual/SE4.Kratos.home,xvda3,w',
		          'phy:/dev/virtual/SE4.Kratos.var,xvdb1,w',
              ]

Il est ensuite nécessaire de monter les partitions des fichiers, pour se faire, on utilise l'enchainement de commande 

mkfs -t ext4 /dev/xvdb1
mount /dev/xvdb1 /mnt
mv /var/* /mnt
umount /mnt
mount -a

pour le fichier /var et 

mkfs -t ext4 /dev/xvda3
mount -a

pour le fichier /home car celui-ci est vide

Interface Réseau

On modifie la configuration réseau de la machine mandataire dans /etc/interfaces On modifie le .cfg de la machine de service pour qu'elle est deux interfaces, une pour communiquer avec le routeur, crée par nos camarades. Et une autre qui est le pont que l'on a créé pour parler entre nos trois machines. 

vif         = [ 'mac=00:16:3E:08:13:E7,bridge=bifrost', 
		        'mac=00:16:3E:08:13:E8, bridge=SE4' ]

Après avoir redémarré la machine, l'interface apparait dans le fichier /etc/network/interfaces que l'on peut modifier pour rajouter l'adresse IP de 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

Sur Kratos, on suit le même principe, on lui rajoute une interface dans son .cfg puis on modifie son fichier /etc/network/interfaces pour lui attribuer des addresses IP. 

auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet6 auto
iface eth0 inet static
	address 192.168.3.3/24
	gateway 192.168.3.1
# post-up ethtool -K eth0 tx off


auto eth1
iface eth1 inet6 auto

On donne la machine mandataire en gateway sur l'IPv4 et en IPv6 l'attribution d'une adresse est faite automatiquement grâce au bridge SE4

Après avoir vérifié que les machine pouvaient se ping entre elles et vers des sites extérieurs, on peut passer à la suite.

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


Serveur DNS

named.conf

Pour pouvoir accéder au serveur DNS il faut mettre à jour le fichier /etc/resolv.conf 

search plil.info
nameserver 172.26.188.12
nameserver 193.48.57.48

Puis on installe bind9 et apache2, on ajoute ensuite les addresses IPv4 et IPv6 de la machine de service dans le Glue Record de Gandi. Il faut également remplacer les "Nameserver".

On modifie également le fichier /etc/bind/named.conf.local 

zone "jotunheim2.tech" {
  type primary;
  file "/etc/bind/zones/jotunheim2.tech/jotunheim2.zone";

  allow-transfer{2001:660:4401:60a0:216:3eff:fee7:c51b;
                 2001:660:4401:60a0:216:3eff:fe91:f4e3;};  // filtrage des secondaire

  also-notify{2001:660:4401:60a0:216:3eff:fee7:c51b;}; // pour les secondaires vicieux

  notify yes;    // notification des secondaires
};

zone "muspellheim2.online"{
    type slave;
    file "/etc/bind/muspellheim2.online";
    primaries{2001:660:4401:60a0:216:3eff:fe91:f4e3;};
};

Dans ce fichier, nous définissons une zone principale pour notre serveur, associée au nom de domaine de la machine de service, ainsi qu'une zone secondaire pour la deuxième machine de service. Les adresses IPv6 sont utilisées pour ces machines.

Fichier de zone

Il faut alors réaliser un fichier de zone correspondant à notre serveur DNS, pour Kratos, le chemin est /etc/bind/zones/jotunheim2.tech/jotunheim2.zone 

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

@        IN      NS      ns.jotunheim2.tech.
@        IN      NS      ns.muspellheim2.online.

ns       IN     A     193.48.57.172
         IN     AAAA  2001:660:4401:60a0:216:3eff:fed0:9ab0

@        IN     A     193.48.57.172
@        IN     AAAA  2001:660:4401:60a0:216:3eff:fed0:9ab0
www      IN     CNAME jotunheim2.tech

On redémarre notre serveur avec les nouveaux paramètres avec la commande systemctl restart. Et on observe les logs avec la commande tail -f /var/log/syslog

Avec le site DNS-checker, on remarque que notre DNS est en train de se propager (en IPV4 et IPV6)

DNSSEC

On ajoute dans /etc/bind/named.conf.local 

zone "jotunheim2.tech" {
  type primary;
  file "/etc/bind/zones/jotunheim2.tech/jotunheim2.zone";

  allow-transfer{2001:660:4401:60a0:216:3eff:fee7:c51b;
               2001:660:4401:60a0:216:3eff:fe91:f4e3;};  // filtrage des secondaire

  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";   // DNSSEC automatique
  inline-signing yes;
};


zone "muspellheim2.online"{
    type slave;
    file "/etc/bind/muspellheim2.online";
    primaries{2001:660:4401:60a0:216:3eff:fe91:f4e3;};
};

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

Ensuite on crée le dossier keys et on donne les droits a bind d'écrire dedans avec : 

mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keys

On redémarre bind9 et les clefs sont crées automatiquement : 

root@Kratos:~# ls /etc/bind/keys/
Kjotunheim2.tech.+013+29981.key  Kjotunheim2.tech.+013+34154.key  Kjotunheim2.tech.+013+29981.private
Kjotunheim2.tech.+013+34154.private  Kjotunheim2.tech.+013+29981.state  Kjotunheim2.tech.+013+34154.state

Il ne reste qu'à ajouter la clé KSK sur Gandi et à consulter l'outil https://dnsviz.net/ pour voir si le site est bien protégé par dnssec.

Fail2ban

Dans un fichier /etc/fail2ban/jail.local 

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

Puis on relance le service avecservice fail2ban restart Désormais, si une connexion SSH sur les machines de service échoue 3 fois, l'adresse IP utilisée est bannie pendant 10 minutes.

Il est également possible de visualiser les adresses bannies avec la commande fail2ban-client status sshd ce qui donne le résultat suivant 

Status for the jail: sshd
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    0
|  `- File list:    /var/log/auth.log
`- Actions
   |- Currently banned:    0
   |- Total banned:    0
   `- Banned IP list:


Apache

HTTPS

A cette étape-ci nous nous nous sommes rendus compte que nous n'avions plus en notre possession les clés ssl de nos sites. Nous avons donc dû reprendre de nouveaux noms de domaine et recommencer à partir du DNS. D'où le 2 à la fin du site pour faciliter la modification des fichiers. Une fois le DNS de nos nouveaux sites repropagé et la vérification du DNSSEC, il a fallu crée le fichier /etc/apache2/sites-available/jotunheim2.tech.conf pour pouvoir accéder à notre site en https 

<VirtualHost *:80>
    ServerName jotunheim2.tech
    ServerAlias www.jotunheim2.tech
    RedirectPermanent / https://jotunheim2.tech/
</VirtualHost>

<VirtualHost *:443>
    ServerName jotunheim2.tech
    ServerAlias www.jotunheim2.tech
    SSLProxyEngine on
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    SSLCertificateFile      /etc/ssl/certs/jotunheim2.tech.crt
    SSLCertificateKeyFile   /home/certif/myserver.key
    SSLCertificateChainFile /home/certif/GandiCert.pem
    <FilesMatch "\.(?:cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
    </FilesMatch>
    <Directory /usr/lib/cgi-bin>
        SSLOptions +StdEnvVars
    </Directory>
</VirtualHost>

Il ne reste plus qu'à activer le module SSL, la configuration du site web définie dans jotunehim2.tech.conf redémarrer le service apache et aller sur le site pour vérifier qu'il n'y a pas d'ereur et qu'il affiche bien la page html demandé dans le fichier /var/www/html/index.html 

a2enmod ssl
a2ensite jotunehim2.tech.conf
service apache2 reload

IPv4

Selon le réseau auquel l'utilisateur est connecté, l'accès au site peut être limité à l'IPv6. Pour résoudre ce problème, on utilise la machine mandataire comme proxy inverse avec la configuration dans le fichier sur la machine GOW /etc/apache2/sites-available/jotunheim2.tech.conf 

# Partie HTTP (port 80)
<VirtualHost *:80>
     ServerName jotunheim2.tech
     ServerAlias www.jotunheim2.tech

     ProxyPass / http://[2001:660:4401:60a0:216:3eff:fed0:9ab0]/
     ProxyPassReverse / http://[2001:660:4401:60a0:216:3eff:fed0:9ab0]/
</VirtualHost>

#Partie HTTPS (port 443)
<IfModule mod_ssl.c>
<VirtualHost *:443>
     ServerName jotunheim2.tech
     ServerAlias www.jotunheim2.tech

     SSLEngine on
     SSLCertificateFile /etc/ssl/certs/jotunheim2.tech.crt
     SSLCertificateKeyFile /etc/ssl/private/jotunheim2.tech.key
     SSLCertificateChainFile /etc/ssl/certs/GandiCert.pem

     ProxyPass / http://[2001:660:4401:60a0:216:3eff:fed0:9ab0]/
     ProxyPassReverse / http://[2001:660:4401:60a0:216:3eff:fed0:9ab0]/

</VirtualHost>
</IfModule>

On active les modules proxy avec les commandes 

a2ensite jotunheim2.tech.conf
a2enmod proxy
a2enmod proxy_http
systemctl restart apache2
Récupérée de « http:///mediawiki/index.php?title=Atelier_SysRes_SE4_2024/2025_E11&oldid=9448 »