Atelier SysRes SE4 2024/2025 E13

Création des machines virtuelles

Dans un premier temps, nous devons créer trois machines virtuelles sur Capbreton. 2 machines de services et 1 machine mandataire.

La commande utilisé pour la création de ces machines est xen-create-image --hostname=SE4.Rigo --dhcp --dir=/usr/local/xen --size=10G --memory=2G --dist=daedalus --bridge=Rodripont.

On se retrouve donc avec 3 machines virtuelles disposant d'un disque de 10go et de 2go de mémoire vive.

Configuration des machines de services

Création des partitions

Ensuite, nous devons allouer à chaque machines virtuelles deux partitions LVM de 10go pour y attribuer le /home et le /var.

Pour ce faire, nous devons créer ces deux partitions, puis modifier le fichier fstab pour les attribuer à nos machines. Ensuite, il faut déplacer les répertoires /var et /home sur leur partition respective.

on s'occupe d'abord du /var:

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

puis du /home:

mkfs -t ext4 /dev/xvda3
mount -a

On peut constater ensuite que les partions /home et /var sont implémentées grâce à la commande df -h .

root@SE4:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            973M     0  973M   0% /dev
tmpfs           199M   80K  199M   1% /run
/dev/xvda2      9.8G  481M  8.8G   6% /
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           500M     0  500M   0% /dev/shm
/dev/xvda3      9.8G   24K  9.3G   1% /home
/dev/xvdb1      9.8G  147M  9.1G   2% /var

Configuration du réseau

Machines de services

Pour configurer le réseau sur les machines, nous devons modifier le fichier de configuration /etc/network/interfaces pour faire en sorte que les machines de services obtiennent automatiquement une adresse IPv6 routée et pour fixer une adresse IPv4 sur le réseau privé de la machine mandataire.

On peut maintenant constater que ma machine Rigo possède bien ces adresses grâce à la commande ip a.

root@SE4:~# 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 pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3e:b9:b5:cf brd ff:ff:ff:ff:ff:ff
    inet 172.16.17.3/24 brd 172.16.17.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:feb9:b5cf/64 scope link 
       valid_lft forever preferred_lft forever

Machine mandataire

La machine mandataire va elle posséder 3 adresses. Une adresse IPv6 routée, une adresse IPv4 routée et une adresse IPv4 pour le réseau privé avec ces deux machines de services. Pour ce faire nous devons au préalable configurer une nouvelle interface eth1 pour y intégrer la seconde adresse IPv4.

vif         = [ 'mac=00:16:3E:B9:B5:CF,bridge=RodriPont',
		        'mac=00:16:3E:B9:B5:D0,bridge=SE4' ]

On peut maintenant constater que ma machine Rodrigo possède bien ces adresses grâce à la commande ip a.

root@SE4:~# 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 pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3e:08:13:e7 brd ff:ff:ff:ff:ff:ff
    inet 172.16.17.1/24 brd 172.16.17.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe08:13e7/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3e:08:13:e8 brd ff:ff:ff:ff:ff:ff
    inet 193.48.57.169/28 brd 193.48.57.175 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe08:13e8/64 scope link 
       valid_lft forever preferred_lft forever

On fait la même chose pour la machine de service, l'interface eth1 contient le pont SE4 avec l'adresse routé IPv6.

root@SE4:/etc/ssh# 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 pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3e:b9:b5:cf brd ff:ff:ff:ff:ff:ff
    inet 172.16.17.3/24 brd 172.16.17.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:feb9:b5cf/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3e:b9:b5:d0 brd ff:ff:ff:ff:ff:ff
    inet6 2001:660:4401:60a0:216:3eff:feb9:b5d0/64 scope global dynamic mngtmpaddr 
       valid_lft 881sec preferred_lft 781sec
    inet6 fe80::216:3eff:feb9:b5d0/64 scope link 
       valid_lft forever preferred_lft forever

Configuration du réseau

Branchement de Capbreton au réseau

Nos machines ayant théoriquement maintenant l'accès à internet, cela n'est pas le cas car Capbreton n'est pas branché au routeur. C'est donc l'objet de cette section.

Dans un premier temps, nous avons relié le serveur Capbreton en E306 au Cisco en E304.

Ensuite, nous avons configurer le routeur Cisco de la même manière que pour le TP Cisco effectué au S7.

On definit 4 VLANs: - VLAN1 pour la maintenance.

- VLAN530 pour relier le routeur E304 à internet en SR52.

- VLAN50 pour les machines XEN

- VLAN113 pour la machine de service

Configuration des VLANs (04/02/25)

On configure le VLAN 50 contenant toute les adresses routées des machines Xen. C'est à dire l'ipv6 de toute les machines et l'ipv4 des machines mandataires.

Ensuite on configure notre VLAN personelle, dans mon cas la 113, qui contient l'adresse ipv4 non routée de la machine de service et l'adresse du routeur (10.0.101.113).

Premier ping de Rodrigo

à l'issus de la configuration des VLANs, on constate que la machine madataire a maintenant accès au monde exterieur ...

root@SE4:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=4.05 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=3.85 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=114 time=4.04 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=114 time=3.90 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 3.854/3.959/4.052/0.086 ms

Serveur DNS

Configuration

Pour configurer le serveur DNS de la machine de service, on modifie le fichier resolv.conf pour y ajouter notre DNS.

root@SE4:/etc/bind# cat /etc/resolv.conf 
search plil.info
nameserver 172.26.188.12
nameserver 193.48.57.48

search robotech.monster
nameserver 172.16.17.3
nameserver 172.16.17.2

Ensuite on modifie le fichier named.conf.local du package bind9.

root@SE4:/etc/bind# cat named.conf.local 

zone "robotech.monster" {
  type master;
  file "/etc/bind/zones/robotech.monster/robotech-dir.zone";

  allow-transfer{secondaries;};  // filtrage des secondaires
  also-notify{hiddensecondaries;}; // pour les secondaires vicieux
  notify yes;    // notification des secondaires
};

acl "secondaries" {
  2001:660:4401:60a0:216:3eff:feb9:255b;
  2001:660:4401:60a0:216:3eff:fe08:13e8;
};

masters "hiddensecondaries" {
  2001:660:4401:60a0:216:3eff:fe08:13e8;
};

zone "sudiste.online" {
  type slave;
  file "/etc/bind/backup/sudiste.online";
  masters{ 2001:660:4401:60a0:216:3eff:feb9:255b;};
};

On a donc bien dans ce fichier, une zone robotech.monster principale et une zone sudiste.online secondaire. On va donc maintenant créer et configurer le fichier robotech-dir.zone.

root@SE4:/etc/bind/zones/robotech.monster# cat robotech-dir.zone 
$TTL 200
@       IN      SOA     ns.robotech.monster. admin.robotech.monster. (
        17       ; Version
        21600   ; Refresh secondary (6h)
        3600    ; Retry secondary (1h)
        2592000 ; Expire if no refresh (30j)
        86400   ; Negative cache (24h)
)

        IN      NS      ns.robotech.monster.
        IN      NS      ns.sudiste.online.
ns      IN      AAAA    2001:660:4401:60a0:216:3eff:feb9:b5d0
ns      IN      A       193.48.57.169
@       IN      AAAA    2001:660:4401:60a0:216:3eff:feb9:b5d0
@       IN      A       193.48.57.169
www     IN      CNAME   ns

sudiste.online est maintenant le backup de robotech.monster.

Maintenant, pour charger les fichiers, on utilise la commande named-checkzone <nom du fichier> dans le répertoire du fichier.

Test du serveur

Pour gérer le serveur DNS, on dispose de 3 commandes.

service named start
service named status
service named stop

Pour tester l'accès au serveur DNS, on peut utiliser la commande dig.

Services Internet

Sécurisation de site Web par certificat

Après avoir récupéré un nom de domaine sur Gandi (ici robotech.monster) , nous avons du récupérer le certificat SSL.

Pour faire cela nous avons généré le CSR contenant notamment le nom de domaine de notre site. le CSR est généré à partir de cette commande:

openssl req -nodes -newkey rsa:2048 -sha256 -keyout myserver.key -out server.csr -utf8

Ensuite, nous avons configuré apache2

root@Rigo:/etc/apache2/sites-enabled# cat default-ssl.conf
<VirtualHost *:443>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLEngine on

        SSLCertificateFile      /etc/ssl/certs/robotech.monster.crt
        SSLCertificateKeyFile   /home/serveur/myserver.key

        SSLCertificateChainFile /home/serveur/GandiCert.pem

        SSLProxyEngine on
        ProxyPass / http://robotech.monster/
        ProxyPassReverse / http://robotech.monster

        #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
        <FilesMatch "\.(?:cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

</VirtualHost>

SSLProxyEngine, ProxyPass et ProxyPassReverse permettent d'activer la fonction mandataire inverse afin d'avoir aussi accès à notre site en IPv4 et pas seulement en IPv6.

On peut donc maintenant accéder à robotech.monster .

Sécurisation de serveur DNS par DNSSEC

Pour sécuriser le serveur DNS par DNSSEC on procède par une gestion automatique des clefs.

On modifie la définition de zone de robotech.monster dans le fichier named.conf.local

zone "robotech.monster" {
  type master;
  file "/etc/bind/zones/robotech.monster/robotech-dir.zone.signed";

  key-directory "/etc/bind/keys";
  dnssec-policy "dnspol";
  inline-signing yes;

  allow-transfer{secondaries;};  // filtrage des secondaires
  also-notify{hiddensecondaries;}; // pour les secondaires vicieux
  notify yes;    // notification des secondaires
};

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

En redémarrant le service bind9, on observe la création d'un nouveau fichier de zone en .signed qui correspond à notre fichier signé. Aussi dans le répertoire keys on observe toutes les clés généré par ce service.

-rw-r--r-- 1 bind bind 357 Feb 20 08:49 Krobotech.monster.+013+16552.key
-rw------- 1 bind bind 187 Feb 20 08:49 Krobotech.monster.+013+16552.private
-rw-r--r-- 1 bind bind 446 Feb 20 08:49 Krobotech.monster.+013+16552.state
-rw-r--r-- 1 bind bind 413 Feb 20 08:49 Krobotech.monster.+013+19150.key
-rw------- 1 bind bind 215 Feb 20 08:49 Krobotech.monster.+013+19150.private
-rw-r--r-- 1 bind bind 568 Feb 20 08:49 Krobotech.monster.+013+19150.state

Filtrage des services

Pour filtrer les attaques par brute force sur le port ssh, nous utilisons l'utilitaire fail2ban. D'abord, on modifie le fichier jail.local pour y ajouter des paramètres.

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

maxretry correspond au nombre de tentative avant le ban, findtime correspond au temps avant lequel le nombre de tentative utilisé par l'utilisateur est réinitialisé et bantime correspond au temp durant lequel un utilisateur est banni. La commande fail2ban-client status sshd nous permet d'identifier le nombre d'utilisateur ayant tenté de se connecter, le nombre d'utilisateurs ayant été banni et la listes des utilisateurs actuellement banni.

root@Rigo:/etc/bind/keys# 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:

On fait de même pour les attaques DNS. Dans le fichier jail.local on ajoute

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

Ensuite on crée une règle dans le répertoire filter.d connect-refused afin d'y ajouter les règles définissant les requêtes TCP à bannir.

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

La commande fail2ban-client status connect-refused nous permet d'identifier le nombre d'utilisateur ayant tenté de se connecter, le nombre d'utilisateurs ayant été banni et la listes des utilisateurs actuellement banni.

root@Rigo:/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: