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

De Wiki d'activités IMA
(→‎Exploitation de failles du système)
 
(181 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
 
TP PRA : MALTI Hind & AHOUASSOU Loris
 
TP PRA : MALTI Hind & AHOUASSOU Loris
  
−
=== Séance 1 ===
+
= Séance 1 =
 +
 
 +
Le but de ce TP est d'apprendre d'abord à faire une architecture système et réseau suffisamment représentative de ce que l'on peut trouver en entreprise (redondance réseau, redondance de stockage raid 5), une architecture réseau (DNS, DNSSEC etc), et puis en parallèle apprendre quelques notions de sécurité informatique.
  
 
== Installation des systèmes d'exploitation ==
 
== Installation des systèmes d'exploitation ==
 +
Pour installer la machine virtuelle, il  faut se connecter en SSH sur le serveur 'capbreton' et se mettre en root
  
−
Pour installer la machine virtuelle, il nous faut lancer la commande marquée ci dessus.
+
  ssh capbreton.plil.info
 +
 
 +
Puis lancer la commande marquée ci dessous.
 +
 
 +
  xen-create-image --hostname=pleurote --dist=buster --ip=100.64.0.20 --netmask=255.255.255.240 --dir=/usr/local/xen/  --password=XXXXXXX --gateway=100.64.0.5 --force
 +
 
 +
Nous avions acheté un nom de domaine sur Gandi, le thème étant les champignons, nous avons choisi "Pleurote".
  
−
  xen-create-image --hostname=pleurote --dist=buster --ip=100.64.0.20 --netmask=255.255.255.240 --dir=/usr/local/xen/ --gateway=100.64.0.5 --force
 
  
 
Toutefois, il convient de préciser que si nous lançons cette commande en étant simplement en 'su',  
 
Toutefois, il convient de préciser que si nous lançons cette commande en étant simplement en 'su',  
 
cela ne fonctionnera pas et renverra une erreur de binaire "mkswap absent".
 
cela ne fonctionnera pas et renverra une erreur de binaire "mkswap absent".
 
Pour corriger cela, il convient au préalable de se mettre en 'su -' plutôt qu'un simple 'su' qui chargerait uniquement les variables d'environnement de l'utilisateur qui l'a invoqué,  
 
Pour corriger cela, il convient au préalable de se mettre en 'su -' plutôt qu'un simple 'su' qui chargerait uniquement les variables d'environnement de l'utilisateur qui l'a invoqué,  
−
plutôt que celles du root véritable.
+
au lieu de celles du root véritable. En effet, le binaire 'mkswap' est présent dans le dossier /sbin qui n'est présent que dans les variables d'environnement de 'su -', d'où l'erreur.
  
−
Nous avons donc nos informations machine :
+
Nous avons donc nos informations machine, que l'on retrouve dans le fichier /etc/xen/pleurote.cfg:
  
−
* Nom de domaine: pleurote.site
+
* Nom de domaine: pleurote
 
* @IP : 100.64.0.20
 
* @IP : 100.64.0.20
 
* Netmask: 255.255.255.240
 
* Netmask: 255.255.255.240
−
* @MAC : [Hind Si tu peux rajouter ^^]
+
* @MAC : 00:16:3E:64:5D:88
  
−
Par la suite, nous devions modifierez le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l’hôte.
+
Nous avons modifier ce fichier afin d'apporter le bridge : IMA5sc
 +
 
 +
Par la suite, nous devions modifier le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l’hôte.
 
Cependant, avant de réaliser cette action, il nous fallait disposer de nos partitions logiques alloués.  
 
Cependant, avant de réaliser cette action, il nous fallait disposer de nos partitions logiques alloués.  
 
L'un des binômes de la promo s'est chargé de créer d'abord un volume de groupe 'storage' avec la commande suivante
 
L'un des binômes de la promo s'est chargé de créer d'abord un volume de groupe 'storage' avec la commande suivante
Ligne 28 : Ligne 38 :
  
 
Dans ce volume de groupe, il nous a assigné chacun (binôme) deux volumes logiques de 10Giga
 
Dans ce volume de groupe, il nous a assigné chacun (binôme) deux volumes logiques de 10Giga
 +
 
   lvcreate -L10G LorisHind1 storage
 
   lvcreate -L10G LorisHind1 storage
 
   lvcreate -L10G LorisHind2 storage
 
   lvcreate -L10G LorisHind2 storage
Ligne 39 : Ligne 50 :
  
 
La ligne avec '...xvdav3...' nous servira pour le répertoire 'var' et '...xvdav4...' pour le répertoire 'home'.
 
La ligne avec '...xvdav3...' nous servira pour le répertoire 'var' et '...xvdav4...' pour le répertoire 'home'.
 +
 +
* Pour mettre le répertoire /var sur notre première partition, il faut réaliser les étapes suivantes :
 +
D'abord accéder à la console de notre VM.
 +
 +
  xl create -c etc/xen/pleurote.cfg
 +
  xl console pleurote
 +
 +
Un fois dans notre VM, on va commencer par formater notre partition censée accueillir le répertoire /var
 +
 +
  mkfs -t ext4 /dev/xvdav3
 +
 +
Ensuite on monte cette partition sur le répertoire '/mnt' afin de récupérer ce qui se trouve sur le répertoire /var :
 +
 +
mount /dev/xvdav3 /mnt
 +
mv /var/* /mnt
 +
 +
 +
On rajoute la ligne suivante dans le fichier /etc/fstab
 +
 +
  /dev/xvdav3 /var ext4 defaults 0 2
 +
 +
 +
On démonte '/mnt'
 +
 +
  umount /mnt
 +
 +
Avant de remonter suivant le /etc/fstab
 +
  mount -a
 +
 +
 +
* Nous faisons de même pour le répertoire /home sur notre seconde partition
 +
 +
Pour l'installation des paquetages SSH, apache2 et bind, cela nécessitait un accès internet dépendant de la configuration des VLANs (qui n'était pas encore complètement opérationnelle)
 +
 +
= Séance 2 =
 +
 +
==  Cassage de clef WEP d’un point d’accès WiFi ==
 +
Pour commencer, nous installons d'abord le packet "aircrack-ng"
 +
Ensuite afin de lister ce que contient le réseau Wifi,
 +
 +
airmon-ng start wlp2s0mon
 +
airmon-ng --encrypt wep wlp2s0mon
 +
 +
[[Fichier:liste_bssid.png|800px|thumb|center|infos sur les cracottes]]
 +
 +
Nous avons besoin de cette dernière commande pour avoir les informations indispensables pour "cracker" le réseau wifi
 +
On note le bssId 04:DA:D2:9C:5050:59
 +
et le channel 3
 +
 +
Nous choisissons de casser la clé WEP de la cracotte10 sur le channel 3, on enregistre les paquets dans webPack.
 +
 +
airodump-ng -c 3 –-bssid 04:DA:D2:9C:5050:59 -w paquets wlp2s0mon
 +
 +
La commande suivante permet de se faire passer pour un client afin de générer de l'activité sur le réseau.
 +
 +
aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:5050:59 wlp2s0mon
 +
Un fichier paquets_01.cap est créé. On utilise les paquets enregistrés pour réaliser le cassage:
 +
 +
aircrack-ng -z paquets_01.cap
 +
 +
 +
On parvient à avoir la clé au bout de 50.000 de paquets, la dernière commande teste chaque 5000 paquets pour essayer de trouver le mot de passe. Voici le résultat trouvé :
 +
 +
[[Fichier:KEY_FOUND.png|600px|thumb|center|Key found]]
 +
 +
A la toute fin il est nécessaire de faire un :
 +
airmon-ng stop wlp2s0mon
 +
 +
== Ajout et configuration d'un serveur DNS sur la VM ==
 +
 +
Pour commencer nous avons installé les packages bind9 et apache2 puis nous avons fait l'acquisition du nom de domaine pleurote.site sur le site gandi.net qui nous servira tout au long du TP.
 +
 +
Dans le dossier de configuration de bind9 à l'emplacement /etc/bind, on créé le fichier de zone db.pleurote.site et on ajoute :
 +
 +
BIND data file for local loopback interface
 +
;
 +
$TTL    604800
 +
@      IN      SOA    ns1.pleurote.site. postmaster.pleurote.site. (
 +
                              3        ; Serial
 +
                        604800        ; Refresh
 +
                          86400        ; Retry
 +
                        2419200        ; Expire
 +
                        604800 )      ; Negative Cache TTL
 +
;
 +
@      IN      NS      ns1.pleurote.site.
 +
@      IN      NS      ns6.gandi.net.
 +
ns1    IN      A      193.48.57.179
 +
 +
Dans le fichier named.conf.local :
 +
 +
zone "pleurote.site" IN {
 +
        type master;
 +
        file "/etc/bind/db.pleurote.site";
 +
        allow-transfer {217.70.177.40;};
 +
};
 +
 +
Dans le fichier named.conf.options :
 +
 +
options {
 +
        directory "/var/cache/bind";
 +
        dnssec-enable yes;
 +
        dnssec-validation auto;
 +
        listen-on-v6 { any; };
 +
        allow-recursion { localhost; };
 +
};
 +
 +
Ensuite on se rend sur le site gandi.net puis dans "Domains" :
 +
 +
Dans l'onglet "Glue Record", on ajoute :
 +
 +
namespace : ns1.pleurote.site
 +
l'adresse IP de notre VM : 193.48.57.179
 +
 +
Dans l'onglet "Serveur de noms" on ajoute le DNS principal et secondaire :
 +
 +
DNS1 : ns1.pleurote.site
 +
DNS2 : ns6.gandi.net
 +
 +
= Séance 3 =
 +
 +
== Attaque de type "homme au milieu" par usurpation ARP ==
 +
 +
Pour expérimenter cette attaque, on installe le paquet dsniff sur notre eeePC.
 +
 +
apt-get install dsniff
 +
 +
Ce paquet nous permet d'écouter le réseau tout en contrefaisant l'adresse MAC de la passerelle Ethernet locale, ce faisant, nous pouvons rediriger tous les paquets vers notre machine qui agira en guise d'homme du milieu, interceptant l'ensemble des données échangées.
 +
 +
Afin que notre eeePC soit effectif en tant qu'homme au milieu, on va passer la variable ip_forward du fichier /proc/sys/net/ipv4/ip_forward à 1. Cela le fait passer en mode routeur.
 +
 +
Nous insérons ensuite  notre eeePC entre la machine d'un autre binôme ( son IP : 172.26.145.65 ) et le routeur utilisé par cette machine fixe ( IP : 172.26.145.254 ) à l'aide de la commande arpspoof.
 +
 +
arpspoof -i enp4s0 -t 172.26.145.65 172.26.145.254
 +
 +
En somme, cette commande fait passer l'eeePC pour le routeaur 172.26.145.254 auprès des clients afin d'intercepter leurs paquets.
 +
Ensuite on va activer l'écoute sur Wireshark au moment où on se connecte sur un site HTTP tel que le Fabricarium de Polytech-Lille.
 +
 +
En lançant cela, on peut voir d'abord que l'eeePC envoie un message ARP pour se faire passer pour le routeur local 172.26.145.254. Ensuite, notre client envoie ses paquets à l'eeePC ( IP : 193.48.57.233 ) qui peut lire ses requêtes http.
 +
 +
[[Fichier:Maninmiddle1.png|900px|thumb|center|]]
 +
 +
On voit ci-dessous des données lisibles envoyées depuis le formulaire de connexion du site du Fabricarium.
 +
 +
[[Fichier:Lorismaninmiddle.png|800px|thumb|center|]]
 +
 +
Cependant, on constate qu'une fois la requête GET envoyée, le site du Fabricarium freeze, rien n'est chargé, même pas un page d'erreur, alors que le but de la manœuvre c'est que le client ne trouve rien d'anormal.
 +
 +
En fait, cela est dû au fait que notre routeur (eeePC) n'a pas renvoyée la page demandée au client, le retour n'est pas effectif.
 +
Pour permettre ça, il nous faut passer à 1 la variable rp_filter du fichier /proc/sys/net/ipv4/conf/default/rp_filter pour activer le chemin inverse.
 +
 +
On refait les étapes précédentes, et on peut constater que le retour est effectif chez le client.
 +
 +
== Intrusion sur un serveur d’applications Web ==
 +
 +
Le but de cette partie, est de réussir à s'introduire sur le serveur honey.plil.info en exploitant d'éventuelles failles de sécurité.
 +
L'idée première que nous avons eu a été de faire des injections SQL dans le formulaire présenté.
 +
 +
Nous avons donc tester l'injection suivante aussi bien dans le champ d'identifiant
 +
 +
'OR 1=1#
 +
 +
Le caractère # à la fin représente un commentaire et permet donc d'ignorer tout ce qui suivra après dans la requête. Ainsi, cela correspond à faire
 +
 +
SELECT * FROM admins WHERE login='' OR 1=1
 +
 +
Même s'il n'y a pas de Login clairement entré, l'expression 1=1 étant toujours vraie, la requête nous a renvoyé une table contenant des identifiants et des mots de passe.
 +
 +
[[Fichier:Tableadmin.png|900px|thumb|center|]]
 +
 +
Nous avons donc pris l'identifiant "admin" son mot de passe "jesuislechef"
 +
que nous avons ensuite entré naturellement dans le formulaire du site honey.plil.info.
 +
Cela a eu pour effet de nous donner l'accès à l'application Web. Nous avons un peu exploré l'application.
 +
Nous voulions pouvoir lire le fichier de configuration de base de données de phpmyadmin.
 +
Nous sommes entrés dans la ''Gestion des Manuels'' et nous avons ajouter un nouveau manuel : nom : nom ; path : /etc/phpmyadmin/config-db.
 +
Une fois ajouté, nous somme allé dans ''Recherche de manuels'' et nous avons téléchargé le fichier de config précédemment ajouté.
 +
 +
 +
[[Fichier:Config-db.png|600px|thumb|center|]]
 +
 +
Nous avons alors utilisé le mot de passe de la base de données sur phpmyadmin. Identifiant : ''root'', Password : ''gencovid19''. Suite à quoi on a eu l'accès.
 +
Après avoir un peu exploré, on est rentré dans la table ''users'' de la base ''test'', ce qui nous a fournit le login ''rex'' et le mot de passe ''plainpassword''.
 +
 +
[[Fichier:Test_users.png|800px|thumb|center|]]
 +
 +
Nous sommes retourné dans un terminal et nous avons lancée une connexion SSH.
 +
 +
ssh rex@honey.plil.info
 +
 +
À ce niveau là, on a aucun fichier directement utile.
 +
Néanmoins, en utilisant nos connaissances du système UNIX, on peut avoir se servir de deux fichiers très utiles:
 +
 +
'''/etc/passwd''' et '''/etc/shadow'''. En effet,
 +
le premier c'est celui qui contient généralement des informations sur les utilisateurs qui peuvent se connecter au système (le nom, l'identifiant, répertoire personnel...),
 +
mais il ne contient pas les mots de passe de ces utilisateurs.
 +
En revanche, le second fichier, lui, contient une version hashée des mots de passe et seuls des utilisateurs très privilégiés peuvent y avoir accès.
 +
Dans /etc/shadow on a pu voir à la dernière ligne le mot de passe crypté de root.
 +
Pour décrypter cela, nous utilisons '''John''' qui est un utilitaire de crackage de mots de passe.
 +
Pour fonctionner, John a besoin d'une liste de mots et un mot de passe à cracker. Mais avant, il faut combiner les deux fichiers précédents en utilisant la commande '''unshadow'''.
 +
Et comme c'est la dernière ligne qui nous intéresse, alors :
 +
 +
unshadow /etc/passwd /etc/shadow | head -> honey_mdp
 +
 +
À partir de là, nous avons un indice dans le sujet : '''La seule indication est que le mot de passe de root possède la même particularité que le mot de passe administrateur habituel des machines de projets'''. Cela nous donne plusieurs informations sur le mot de passe : ''il est probablement composé que de lettres''; ''il est en minuscules''; ''et il est certainement formé de deux mots identiques de 4 lettres (comme le mot de passe glopglop)''
 +
 +
L'idée est de créer un dictionnaire de mots de 8 lettres (qui est en fait formé du même mot de 4 lettres comme glopglop). Au lieu de faire un code C qui nous génère cela, nous avons utilisé l'utilitaire '''crunch''' qui nous génère facilement ce dictionnaire. Mais ''attention'', si nous générons directement des mots de 8 lettres, le temps de calcul sera très très long car il devrait créer 26^8 mots ~= 2x10^11 et donc une taille ÉNORME de fichier (~+1TB).
 +
 +
Une approche moins naïve serait de générer d'abord un dictionnaire de mots de 4 lettres, ce qui fait seulement 26^4 = 456976 mots pour une taille de ~2MB.
 +
 +
crunch 4 4 abcdefghijklmnopqrstuvwxyz > liste_mots
 +
 +
On peut dupliquer nos mots pour former des mots doublés de 8 lettres avec la commande 'sed'
 +
 +
sed -i 's/\(.*)/\1\1/' liste_mots
 +
 +
Maintenant, le boulot est fait, il ne reste plus qu'à laisser 'John' décrypter.
 +
 +
john -W:liste_mots honey_mdp
 +
 +
Quand c'est terminé, on affiche le mot de passe :
 +
 +
john --show honey_mdp
 +
 +
Comme indiqué sur la capture suivante, le mot de passe est '''fortfort'''
 +
 +
[[Fichier:John_crack.png|800px|thumb|center|]]
 +
 +
= Séance 4 =
 +
== Cassage de mot de passe WPA-PSK par force brute ==
 +
 +
Nous avons précédemment craqué le clé WEP avec l'utilitaire ''aircrack-ng''.
 +
Nous l'utilisons à nouveau pour faire de même avec la clé WPA-PSK.
 +
D'abord, on visualise notre interface :
 +
 +
airmon-ng
 +
 +
Ensuite, on active l'interface :
 +
 +
  airmon-ng start wlx40a5efd2140c
 +
 +
après cette commande, notre interface a été renommé en wlan0mon, nous travaillerons donc avec ce nom par la suite.
 +
On peut lancer l'écoute :
 +
 +
  airodump-ng wlan0mon
 +
 +
On va cracker la Kracotte10, on peut donc lire son BSSID 00:14:1B:60:8C:29 et son channel 3
 +
 +
Avec ces informations, on va récupérer l'handshake et le mettre dans un fichier ''result''
 +
 +
  airodump-ng --bssid 00:14:1B:60:8C:29 wlan0mon --channel 3 --write result
 +
 +
[[Fichier:5-3-3.png|600px|thumb|center|]]
 +
 +
Cela prend quelques minutes. Ensuite ce qu'il nous faut c'est générer un dictionnaire de mots de 8 chiffres, on peut utiliser l'utilitaire crunch pour cela.
 +
 +
crunch 8 8 0123456789 > dico.txt
 +
 +
Enfin on peut lancé le crackage :
 +
 +
aircrack-ng result-01.cap -w dico.txt
 +
 +
Cela peut durer un certain temps avant que ce soit décrypté.
 +
 +
[[Fichier:5-3-4.png|500px|thumb|center|]]
 +
 +
== Serveur SSH ==
 +
 +
Il était nécessaire que notre vm soit accessible en ssh, pour ce nous avons décommenter dans le fichier /etc/ssh/sshd-config:
 +
PermitRootLogin yes
 +
Puis on redémarre le service ssh afin qu'il prenne en considération nos changements:
 +
systemctl restart sshd
 +
 +
Et voilà ! Notre vm est accessible en root avec soit:
 +
root@pleurote.site
 +
soit:
 +
root@193.48.57.179
 +
 +
==  Sécurisation de site web par certificat ==
 +
Nous commençons par un générer deux fichiers grâce à la commande
 +
 +
openssl req -nodes -newkey rsa:2048 -sha1 -keyout pleurote.site.key -out pleurote.csr
 +
<code>pleurote.csr</code> : Ce fichier nous sert à faire une demande de certificat auprès d'une autorité de certification. Il contient quelques informations personnelles ainsi que la clef publique.
 +
 +
<code>pleurote.site.key</code> : Celui-ci contient la clef privée (qu'on tâchera de ne jamais perdre ou distribuer) qui est complémentaire à celle présente dans le csr.
 +
On peut ensuite se rendre sur Gandi afin d'acheter le certificat. Le csr sera demandé pendant la procédure puis il faudra choisir une des trois méthodes proposées pour la vérification. Nous avons choisi celle par email pour le challenge de créer un serveur de mail sur notre machine.Pour ce, en parallèle :
 +
 +
on installe postfix :
 +
apt-get install postfix
 +
on modifie le fichier :
 +
/etc/aliases
 +
On met dedans : <code>admin: root </code>
 +
 +
on installe ensuite :
 +
apt-get install -y bsd-mailx
 +
postalias /etc/aliases
 +
mailx
 +
et on reçoit alors le mail de Gandi avec un lien et un mot de passe de vérification à rentrer dans un champs. On clique sur le lien et on colle dessus le mot de passe de vérification. 
 +
 +
 +
Il nous faut maintenant récupérer notre certificat depuis Gandi ainsi que le certificat intermédiaire. On déplace ensuite l'ensemble de ces clefs dans les répertoires appropriés :
 +
 +
/etc/ssl/pleurote.site.crt                                                                     
 +
/etc/ssl/pleurote.site.key                                                               
 +
/etc/ssl/GandiStandardSSLCA2.pem
 +
 +
== Configuration d'apache2 ==
 +
 +
Avant toute chose, on s'assure que le module ssl est actif pour apache2.
 +
Nous remplissons ensuite les informations territoriales utiles à la génération du CSR.
 +
 +
Ensuite sur gandi.net dans "SSL Certificates" on achète le certificat (bien qu'il soit indiqué comme coutant 12€, lors de l'encaissement il devient gratuit)
 +
a2enmod ssl
 +
On se rend ensuite dans le répertoire /etc/apache2/sites-enabled et on modifie par exemple le fichier 000-default.conf.
 +
 +
<VirtualHost *:80>                                                                                                       
 +
  ServerName www.pleurote.site                                                                                           
 +
  Redirect / https://www.pleurote.site     
 +
  ....                                                                       
 +
</VirtualHost> 
 +
                                                                                                                                                                                                                             
 +
<VirtualHost _default_:443>                                                                                               
 +
  ServerName www.pleurote.site                                                                                           
 +
  DocumentRoot /var/www/html                                                                                             
 +
  SSLEngine On                                                                                                           
 +
  SSLCertificateFile /etc/ssl/pleurote.site.crt                                                                   
 +
  SSLCertificateKeyFile /etc/ssl/pleurote.site.key                                                               
 +
  SSLCertificateChainFile /etc/ssl/GandiStandardSSLCA2.pem                                                         
 +
  SSLVerifyClient None                                                                                               
 +
</VirtualHost>   
 +
 +
Le premier VirtualHost s'assure que l'utilisateur se connecte toujours en https (grâce au Redirect) et le second est justement utilisé pour l'accès en https au site.
 +
 +
Enfin, on redémarre le service apache2 pour que les modifications soient prises en compte.
 +
 +
service apache2 restart
 +
 +
== Sécurisation de serveur DNS par DNSSEC ==
 +
 +
Dans cette partie, nous allons certifier aux utilisateurs de notre site web que l'IP qu'il reçoit dans la réponse DNS est bien celle du domaine voulu. Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.
 +
 +
On commence naturellement par activer DNSSEC en ajoutant l'option <code> dnssec-enable yes; </code> dans le fichier <code>/etc/bind/named.conf.local </code>
 +
 +
On génère deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous créons un dossier <code>pleurote.site.dnssec</code> et nous mettrons les clefs dedans.
 +
Nous commençons par créer la clef asymétrique de signature de clefs de zone :
 +
 +
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE pleurote.site
 +
 +
Ensuite, nous créons la clef asymétrique de la zone pour signer les enregistrements :
 +
 +
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE pleurote.site
 +
 +
Afin que ce soit lisible et facile à manier, nous renommons nos deux paires de clefs en :  <code>pleurote-ksk.key  pleurote-ksk.private  pleurote-zsk.key  pleurote-zsk.private</code>
 +
<code></code>
 +
 +
$include /etc/bind/pleurote.site.dnssec/pleurote.site-ksk.key
 +
$include /etc/bind/pleurote.site.dnssec/pleurote.site-zsk.key
 +
 +
On signe les enregistrements de la zone, grâce à la commande:
 +
dnssec-signzone -o pleurote.site -k pleurote.site-ksk ../db.pleurote.site pleurote.site-zsk 
 +
Ensuite dans le fichier /etc/bind/named.conf.local nous  modifions la zone :
 +
 +
zone "pleurote.site" IN {
 +
  type master;
 +
  file "/etc/bind/db.pleurote.site.signed";
 +
  allow-transfer {127.70.177.40;};
 +
  dnssec-enable yes;
 +
}; 
 +
 +
Et puis finalement :
 +
 +
Faire communiquer la partie publique de la KSK (présente dans le fichier pleurote-ksk.key) sur gandi dans la partie DNSSEC. On oublie pas de changer le type en 5 (RSA/SHA-1) étant donné qu'on a utilisé du SHA1 dans notre commande.
 +
[[Fichier:Dns-verif.PNG]]
 +
 +
= Séance 5 =
 +
== Sécurisation de données ==
 +
 +
En un premier lieu, sur le serveur Capbreton, nous créons des volumes logiques et puis nous les relions au volume group "virtual" qui a été dédié à cette partie du TP.
 +
root@capbreton:~# lvcreate -L1G -n pleurote-part1 virtual
 +
  Logical volume "pleurote-part1" created.
 +
root@capbreton:~# lvcreate -L1G -n pleurote-part2 virtual
 +
  Logical volume "pleurote-part2" created.
 +
root@capbreton:~# lvcreate -L1G -n pleurote-part3 virtual
 +
  Logical volume "pleurote-part3" created.
 +
Nous ajoutons ensuite au fichier pleurote.cfg
 +
'phy:/dev/virtual/pleurote-part1,xvda5,w',
 +
'phy:/dev/virtual/pleurote-part2,xvda6,w',
 +
'phy:/dev/virtual/pleurote-part3,xvda7,w'
 +
 +
root@capbreton:~# lvdisplay | grep pleurote
 +
  LV Path            /dev/virtual/pleurote-part1
 +
  LV Name            pleurote-part1
 +
  LV Path            /dev/virtual/pleurote-part2
 +
  LV Name            pleurote-part2
 +
  LV Path            /dev/virtual/pleurote-part3
 +
  LV Name            pleurote-part3
 +
 +
xl destroy pleurote
 +
xl create /etc/xen/pleurote.cfg
 +
 +
Ensuite : Sur notre VM pleurote:
 +
On peut vérifier :
 +
root@pleurote:~# lsblk
 +
NAME  MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT
 +
xvda1  202:1  0  512M  0 disk [SWAP]
 +
xvda2  202:2  0 4G  0 disk /
 +
xvdav3 202:12035  0  10G  0 disk /var
 +
xvdav4 202:12036  0  10G  0 disk /home
 +
xvdav5 202:12037  0 1G  0 disk
 +
xvdav6 202:12038  0 1G  0 disk
 +
xvdav7 202:12039  0 1G  0 disk
 +
 +
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvdav5 
 +
/dev/xvdav6 /dev/xvdav7--create /dev/md0 --level=5 --raid-devices=3 /dev/xvdav5 
 +
Cette dernière commande permettra de créer un nouveau volume md0, de définir le niveau du raid (5) ainsi que les différents périphériques actifs xvdav 5->7
 +
root@pleurote:~# mdadm --monitor --daemonise /dev/md0
 +
 +
root@pleurote:~# mkfs -t ext4 /dev/md0
 +
Ensuite on modifie /etc/fstab :
 +
/dev/md0 /raid5 ext4 defaults 0 1
 +
 +
 +
root@pleurote:~# mdadm --detail /dev/md0
 +
/dev/md0:
 +
      Version : 1.2
 +
Creation Time : Mon Nov 30 14:17:07 2020
 +
    Raid Level : raid5
 +
    Array Size : 2093056 (2044.00 MiB 2143.29 MB)
 +
Used Dev Size : 1046528 (1022.00 MiB 1071.64 MB)
 +
  Raid Devices : 3
 +
Total Devices : 3
 +
  Persistence : Superblock is persistent
 +
  Update Time : Mon Nov 30 14:21:28 2020
 +
        State : clean
 +
Active Devices : 3
 +
        Working Devices : 3
 +
Failed Devices : 0
 +
Spare Devices : 0
 +
        Layout : left-symmetric
 +
    Chunk Size : 512K
 +
        Consistency Policy : resync
 +
Name : pleurote:0  (local to host pleurote)
 +
        UUID : 174ca3a2:9133344c:c58badf8:bccd6167
 +
        Events : 18
 +
        Number  Major  Minor  RaidDevice State
 +
  0 202 12037    0  active sync  /dev/xvdav5
 +
  1 202 12038    1  active sync  /dev/xvdav6
 +
  3 202 12039    2  active sync  /dev/xvdav7
 +
Après avoir formaté la partition formée par le raid, on va la monter. Puis on crée un fichier sur cette partition:
 +
mount /dev/md0 /mnt
 +
touch test.txt
 +
 +
A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre redondance, simulons une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel.
 +
 +
mdadm --set-faulty /dev/md0 /dev/xvdf1
 +
mdadm --remove /dev/xvdf1
 +
Nous constatons que notre fichier test.txt est toujours présent, malgré la "perte" de l'un des disques.
 +
 +
== Chiffrement de données ==
 +
 +
Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire "cryptsetup" avec le format LUKS afin de chiffrer notre disque avec un mot de passe.
 +
 +
root@truite:~# fdisk -l
 +
On repère alors, notre clé USB:
 +
Disk /dev/sda: 7.2 GiB, 7736072192 bytes, 15109516 sectors
 +
 +
On formate la clé en une seule partition
 +
root@truite:~# fdisk /dev/sda 
 +
Command (m for help): d     
 +
Partition number (1,2, default 2): 1 
 +
Partition 1 has been deleted.
 +
 +
Idem pour la seconde existante.Puis, on chiffre l'unique partition de la clé USB et ensuite on la déchiffre :
 +
 +
root@truite:~# cryptsetup luksOpen /dev/sda1 MonUSB
 +
root@truite:~# cryptsetup luksOpen /dev/sda1 MonUSB
 +
 +
On choisis alors un bon mot de passe, puis on formate l'USB:
 +
root@truite:~# mkfs.ext4 /dev/mapper/MonUSB
 +
Et puis ensuite, on monte notre USB et on crée un fichier dedans par exemple:
 +
root@truite:~# mkdir /mnt/USB
 +
root@truite:~# mount -t ext4 /dev/mapper/MonUSB /mnt/USB
 +
root@truite:~# touch /mnt/USB/test.txt
 +
Une fois que l'on a terminé, on retire notre USB en toute sécurité:
 +
root@truite:~# umount /mnt/USB
 +
root@truite:~# cryptsetup luksClose MonUSB
 +
 +
== Interconnexion Internet de secours (IPv6)==
 +
 +
On ajoute dans /etc/network/interfaces :
 +
 +
iface eth0 inet6 auto
 +
 +
== Interconnexion Internet de secours (IPv4) ==
 +
 +
= Séance 6 =
 +
== Sécurisation WiFi par WPA2-EAP (FreeRadius) ==
 +
=== Configuration de Freeradius ===
 +
On commence par installer freeRadius :
 +
apt-get install freeradius
 +
 +
 +
Dans le fichier /etc/freeradius/3.0/mods-enabled/mschap :
 +
use_mppe = yes
 +
require_encryption = yes
 +
require_strong = yes
 +
 +
Ensuite dans le fichier /etc/freeradius/3.0/mods-enabledpeap :
 +
eap{
 +
default_eap_type = peap
 +
}
 +
 +
On modifie également le fichier users (on décommente la partie bob): 
 +
pleurote  Cleartext-Password := "pasglop"
 +
Puis le fichier clients.conf
 +
client pleurote {
 +
ipaddr = 10.60.100.10
 +
secret = secret_groupe10
 +
}
 +
On se connecte à la borne wifi avec :
 +
ssh root@10.60.100.10 -c aes128-cbc
 +
 +
wifi-ima5sc(config)#aaa authentication login eap_group10 group radius_group10
 +
wifi-ima5sc(config)#radius-server host 193.48.57.179 auth-port 1812 acct-port 1813 key secret_group10 
 +
wifi-ima5sc(config)#aaa group server radius radius_group10
 +
wifi-ima5sc(config-sg-radius)#server 193.48.57.179 auth-port 1812 acct-port 1813
 +
wifi-ima5sc(config-sg-radius)#dot11 ssid SSID_GROUP10
 +
wifi-ima5sc(config-ssid)#mbssid guest-mode
 +
wifi-ima5sc(config-ssid)#vlan 314
 +
wifi-ima5sc(config-ssid)#authentication open eap eap_group10
 +
wifi-ima5sc(config-ssid)#authentication network-eap eap_group10
 +
wifi-ima5sc(config-ssid)#authentication key-management wpa
 +
 +
 +
wifi-ima5sc(config-ssid)#interface Dot11Radio0
 +
wifi-ima5sc(config-if)#encryption vlan 310 mode ciphers aes-ccm tkip
 +
wifi-ima5sc(config-if)#mbssid                                     
 +
wifi-ima5sc(config-if)#ssid SSID_GROUP10
 +
 +
wifi-ima5sc(config)#int Dot11radio0.10
 +
wifi-ima5sc(config-subif)#encapsulation dot1q 310
 +
wifi-ima5sc(config-subif)#bridge-group 10
 +
wifi-ima5sc(config-subif)#exit
 +
wifi-ima5sc(config)#int Dot11radio0
 +
wifi-ima5sc(config-if)#no shutdown
 +
wifi-ima5sc(config-if)#exit
 +
wifi-ima5sc(config)#exit
 +
 +
Si nous faisons un ping :
 +
 +
[[Fichier:cap0.png]]
 +
 +
Sur un téléphone portable, nous essayons de nous connecter au wifi SSID_GROUP10 avec le bon mot de passe et user.
 +
Puis nous lançons le mode debug avec la commande:
 +
freeradius -X
 +
 +
et sur la borne wifi nous lançons afin de voir :
 +
sh dot11 associations
 +
 +
[[Fichier:Cap1.png]]
 +
 +
== DHCP ==
 +
On se connecte en ssh sur les deux routeurs 6509-E et C9200 :
 +
 +
IMA5sc-R1>enable
 +
  Password:
 +
IMA5sc-R1#config t
 +
Enter configuration commands, one per line.  End with CNTL/Z.
 +
IMA5sc-R1(config)#
 +
IMA5sc-R1(config)#ip dhcp pool groupe10
 +
IMA5sc-R1(dhcp-config)#dns 193.48.57.179
 +
IMA5sc-R1(dhcp-config)#network 10.6.110.0 255.255.255.0
 +
IMA5sc-R1(dhcp-config)#default-router 10.60.110.1
 +
IMA5sc-R1(dhcp-config)#exit
 +
IMA5sc-R1(config)#ip dhcp excluded-address 10.60.110.0 10.60.110.100
 +
IMA5sc-R1(config)#ip dhcp excluded-address 10.60.110.110 10.60.110.255
 +
IMA5sc-R1(config)#exit
 +
IMA5sc-R1#sh ip dhcp binding
 +
 +
Second rooter:
 +
root@zabeth15:/home/pifou# ssh admin@192.168.222.13
 +
IMA5sc-R2>enable
 +
IMA5sc-R2#config t
 +
IMA5sc-R2(config)#ip dhcp pool groupe10
 +
IMA5sc-R2(dhcp-config)#dns 193.48.57.179
 +
IMA5sc-R2(dhcp-config)#network 10.60.110.0 255.255.255.0
 +
IMA5sc-R2(dhcp-config)#default-router 10.60.110.2
 +
IMA5sc-R2(dhcp-config)#exit
 +
IMA5sc-R2(config)#ip dhcp excluded-address 10.60.110.0 10.60.110.50
 +
IMA5sc-R2(config)#ip dhcp excluded-address 10.60.110.100 10.60.110.255
 +
IMA5sc-R2(config)#exit
 +
IMA5sc-R2#sh ip dhcp binding
 +
 +
== Mascarade ==
 +
 +
IMA5sc-R1(config)#int vlan 310                                       
 +
IMA5sc-R1(config-if)#ip nat inside
 +
 +
 +
== Config des Vlan ==
 +
Rooter 1
 +
 +
IMA5sc-R1#config t
 +
IMA5sc-R1(config)#vlan 310
 +
IMA5sc-R1(config-vlan)#int vlan 310
 +
IMA5sc-R1(config-if)#vrrp 50 ip 10.60.110.254
 +
IMA5sc-R1(config-if)#vrrp 50 preempt
 +
IMA5sc-R1(config-if)#vrrp 50 priority 110
 +
IMA5sc-R1(config-if)#exit   
 +
IMA5sc-R1(config)#exit
 +
 +
 +
 +
Rooter 2
 +
 +
IMA5sc-R2#config t
 +
Enter configuration commands, one per line.  End with CNTL/Z.
 +
IMA5sc-R2(config)#vlan 310
 +
IMA5sc-R2(config-vlan)#int vlan 310
 +
IMA5sc-R2(config-if)#vrrp 50 address-family ipv4
 +
IMA5sc-R2(config-if-vrrp)#address 10.60.110.254
 +
IMA5sc-R2(config-if-vrrp)#preempt
 +
IMA5sc-R2(config-if-vrrp)#vrrpv2
 +
IMA5sc-R2(config-if-vrrp)#exit
 +
IMA5sc-R2(config-if)#exit
 +
 +
 +
borne wifi
 +
wifi-ima5sc(config)#interface GigabitEthernet0.10
 +
wifi-ima5sc(config-subif)#enc
 +
wifi-ima5sc(config-subif)#encapsulation do
 +
wifi-ima5sc(config-subif)#encapsulation dot1Q 310
 +
wifi-ima5sc(config-subif)#brid
 +
wifi-ima5sc(config-subif)#bridge-group 10
 +
wifi-ima5sc(config-subif)#exit
 +
 +
IMA5sc-R2(config)#exit
 +
IMA5sc-R2#
 +
 +
IMA5sc-R1(config)#ipv6 unicast-routing
 +
IMA5sc-R1(config)#vlan 310         
 +
IMA5sc-R1(config-vlan)#name pleurote.site
 +
IMA5sc-R1(config-vlan)#exit
 +
IMA5sc-R1(config)#int vlan 310
 +
IMA5sc-R1(config-if)#no shut
 +
IMA5sc-R1(config-if)#ip address 10.60.110.1 255.255.255.0
 +
IMA5sc-R1(config-if)#ipv6 enable
 +
IMA5sc-R1(config-if)#ipv6 address 2001:660:4401:60bc::0/64 eui-64ipv6
 +
IMA5sc-R1(config-if)#ipv6 nd prefix 2001:660:4401:60bc::0/64 1000 900
 +
IMA5sc-R1(config-if)#ipv6 nd router-preference Low
 +
IMA5sc-R1(config-if)#exit
 +
IMA5sc-R1(config)#exit
 +
 +
 +
IMA5sc-R2#config t
 +
Enter configuration commands, one per line.  End with CNTL/Z.
 +
IMA5sc-R2(config)#ipv6 unicast-routing
 +
IMA5sc-R2(config)#vlan 310
 +
IMA5sc-R2(config-vlan)#name pleurote.site
 +
IMA5sc-R2(config-vlan)#exit
 +
IMA5sc-R2(config)#int vlan 310
 +
IMA5sc-R2(config-if)#no shut
 +
IMA5sc-R2(config-if)#ip address 10.60.110.2 255.255.255.0
 +
IMA5sc-R2(config-if)#ipv6 enable       
 +
IMA5sc-R2(config-if)#ipv6 address 2001:660:4401:60bc::0/64 eui-64
 +
IMA5sc-R2(config-if)#ipv6 nd prefix 2001:660:4401:60bc::0/64 1000 900
 +
IMA5sc-R2(config-if)#ipv6 nd router-preference High
 +
IMA5sc-R2(config-if)#exit
 +
IMA5sc-R2(con
 +
 +
== Exploitation de failles du système ==
 +
 +
Nous avons d'abord cherché des programmes permettant l'analyse des failles et vulnérabilités sur le système Linux.
 +
Nous avons trouvé plusieurs avec leurs spécificités, en particulier Lynis.
 +
Lynis est un logiciel libre d'audit de sécurité extensible pour les ordinateurs ou machines virtuelles utilisant les systèmes d'exploitation, Linux, macOS, et autres dérivés d'Unix ou de type POSIX. Il permet un examen rapide (scan) d'un système et de ses défenses de sécurité.
 +
 +
Il va déterminer diverses informations sur le système à auditer, tels que le système d'exploitation, les paramètres du noyau, les mécanismes d'authentification et de fonctionnement des comptes, les paquets et services installés, la configuration réseau, la journalisation et la supervision (par exemple syslog-ng), la cryptographie (par exemple les certificats TLS/SSL) ou encore les antivirus installés (par exemple ClamAV ou rkhunter). En complément, il vérifiera le système à la recherche d'erreurs de configuration et de problèmes de sécurité.
 +
 +
Le test a été réalisé sur un noyau linux ubuntu.
 +
 +
Pour installer Lynis.
 +
 +
sudo apt install lynis
 +
 +
On peut ensuite lancer un audit du système.
 +
 +
lynis audit system
 +
 +
Lynis nous renverra tout un tas d'informations sur une multitude de tests qu'il aura réalisé. Tout ceci étant trop long, nous nous sommes contentés d'afficher une partie des résultats, notamment des avertissements sur des possibles faiblesses, tels que des vulnérabilités au niveau de différents paquets, du réseau, ou encore de l'authentification.
 +
 +
[[Fichier:Lynis1.png|700px|thumb|center|]]
 +
 +
Le programme termine en nous suggérant des solutions pour améliorer le système et sa sécurité.
 +
 +
Pour des tests plus ou moins variés, il existe d'autres programmes tels que chkrootkit, rkhunter etc.
 +
 +
= Séance 7 =
 +
Le but de ce TP est de nous initier a Ansible, Docker et nous apprendre à créer un loadbalancer et manier les différents outils nécessaire à la réalisation de TP.
 +
== Architecture générale de la ferme ==
 +
Une VM secondaire a été mise à notre disposition, elle n'est pas connectée à internet. Elle accèdera à internet en passant par une route (passant par la VM Pleurote primaire qui se trouve sur le serveur Capbreton). Ce qui fait de la VM primaire jouera le rôle d'un  bastion et d'un loadBalancer.
 +
 +
[[Fichier:ansible.png|500px|]]
 +
 +
 +
=== Configuration des Vlans ===
 +
Pour commencer, il a fallu faire quelques configurations réseau afin de faire le lien entre les deux VM et puis parvenir à accèder à internet sans jamais y être exposé directement.
 +
Pour ce, Nous ajoutons une interface réseau à notre machine principale afin de la relier au vlan50 et ce, sur le fichier /etc/xen/pleurote.cfg :
 +
 +
#
 +
#  Networking
 +
#
 +
vif = [ 'ip=100.64.0.20 ,mac=00:16:3E:64:5D:88,bridge=IMA5sc','ip=192.168.42.10, mac=00:16:3E:64:5D:88,bridge=bridgeStudents' ]
 +
 +
 +
Ensuite, nous allons sur le fichier /etc/network/interfaces de la vm primaire:
 +
#The primary network interface
 +
auto eth0
 +
iface eth0 inet static
 +
  address 193.48.57.179
 +
  netmask 255.255.255.255
 +
  up ip address add dev eth0 100.64.0.19/24
 +
  up ip route add default via 100.64.0.2 src 193.48.57.179
 +
  down ip address del dev eth0 100.64.0.19/24
 +
  down ip route del default via 100.64.0.2 src 193.48.57.179
 +
 +
Sur la vm secondaire et nous apportons les modifications suivantes:
 +
#The primary network interface
 +
auto eth0
 +
iface eth0 inet static
 +
  address 192.168.42.24
 +
  netmask 255.255.255.0
 +
  gateway 192.168.42.10
 +
 +
Ensuite nous indiquons le server par lequel notre secondaire devra passer /etc/resolv.conf :
 +
 +
domain plil.info
 +
nameserver 192.168.42.10
 +
 +
Nous constatons que désormais les deux machines peuvent se pinger l'une l'autre.
 +
=== Mascarade ===
 +
Afin de donner accès à internet à notre secondaire, nous procédons par la mise en place d'une mascarade:
 +
root@pleurote:~# iptables -P FORWARD DROP
 +
root@pleurote:~# iptables -A FORWARD -j ACCEPT -s 192.168.42.24/32
 +
root@pleurote:~# iptables -A FORWARD -j ACCEPT -d 192.168.42.24/32
 +
root@pleurote:~# iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.24/32 --to-source 193.48.57.179
 +
root@pleurote:~# iptables-save
 +
root@pleurote:~# echo 1 > /proc/sys/net/ipv4/ip_forward
 +
 +
=== Ansible ===
 +
Nous nous assurons avant tout que sur notre machine secondaire possède bien une bonne version python et pip qui soit compatible avec Ansible.
 +
Ansible sera notre allié si nous souhaitons déployer une succession de mêmes tâches sur les 7 VM sans devoir nous y connecter une à une et faire un travail assez redondant au risque de faire des erreurs etc.
 +
 +
Nous installons donc ansible sur la machine principale:
 +
$ apt update
 +
$ apt install ansible
 +
 +
Nous devons configurer le /etc/ansible/hosts afin de designer notre machine à nous et celles de nos camarades:
 +
 +
[VM_pleurote]
 +
192.168.42.24
 +
 +
[VM_Chassiron]
 +
192.168.42.28
 +
192.168.42.25
 +
192.168.42.22
 +
192.168.42.20
 +
192.168.42.17
 +
193.168.42.15
 +
 +
=== Clés SSH ===
 +
Naturellement, la première chose à faire est de créer une clé SSH et faire un échange de clés entre notre VM primaire et toutes les autres VM secondaires. Cela nous permettra de deployer ansible depuis notre vm principale vers les vm secondaires sans devoir s'authentifier à chaque fois.
 +
Nous générons d'abord une clé ssh asymétrique :
 +
ssh-keygen -t rsa
 +
 +
Ensuite, nous mettons notre clé publique sur le fichier authorized_key de chaque vm secondaire:
 +
cat .ssh/id_rsa.pub | ssh <IP_CIBLE> cat >> /root/.ssh/authorized_keys"
 +
 +
=== Motd===
 +
Notre premier essai sera sur un service assez simple "motd" : Il permet d'afficher lors d'une connexion SSH un message. Nous nous sommes questionnés sur l'utilité d'un tel programme et nous avons réalisé que dans un contexte entreprise, on pourrait très bien imaginé que le message nous préviendrait qu'on est sur une machine de Prod, qu'il nous décrirait des manipulations particulières à prendre en considération lors de l'utilisation de cette VM.
 +
Pour cela nous nous inspirons fortement du travail du repository :[https://github.com/adriagalin/ansible.motd]
 +
 +
D'abord nous créons un dossier ansible avec un dossier files et un autre tasks qui contiennent respectivement les fichiers utilisés et les tâches à faire:
 +
dans files, nous créons un fichier avec le contenu que l'on souhaite afficher:
 +
 +
root@pleurote:~/ansible/roles/motd/files# cat motd.txt
 +
--------------------------------------------------------------------------
 +
                      This system is managed by Ansible
 +
--------------------------------------------------------------------------
 +
Coucou depuis la lune
 +
 +
Ensuite dans ~/ansible/roles/motd/tasks:
 +
 +
---
 +
- name: Delete /etc/motd file
 +
  file:
 +
    path: /etc/motd
 +
    state: absent
 +
- name: Add motd
 +
  copy:
 +
    src: motd.txt
 +
    dest: /etc/motd
 +
    follow: yes
 +
 +
Ensuite dans un fichier qu'on nomme playbook.yml au niveau du ~/ansible :
 +
 +
---
 +
- name: Add motd to hosts
 +
  hosts: VM_pleurote
 +
  roles:
 +
    - motd
 +
 +
Nous exécutons ensuite la commande:
 +
ansible-playbook playbook.yml
 +
Nous allons faire la vérification en nous connectons en ssh sur la machine secondaire, et tadan : magie ? Nous retrouvons notre message d'accueil "Coucou depuis la lune"
 +
 +
=== NTP ===
 +
NTP va permettre de synchroniser les VM sur le même créneau horaire.
 +
Nous allons procéder de la même manière que pour le précèdent exercice, on nous inspirons également du repository [https://github.com/geerlingguy/ansible-role-ntp]:
 +
 +
Ainsi nous retrouvons dans ~/ansible/roles/ntp/files/ntp.conf :
 +
 +
driftfile /var/lib/ntp/drift
 +
statistics loopstats peerstats clockstats
 +
filegen loopstats file loopstats type day enable
 +
filegen peerstats file peerstats type day enable
 +
filegen clockstats file clockstats type day enable
 +
server ntp.plil.info
 +
 +
Ensuite dans ~/ansible/roles/ntp/tasks/main.yml :
 +
 +
---
 +
- name: Ensure NTP package is installed.
 +
  package:
 +
    name: ntp
 +
    state: present
 +
- name: Ensure tzdata package is installed (Linux).
 +
  package:
 +
    name: tzdata
 +
    state: present
 +
- name: Set timezone.
 +
  timezone:
 +
    name: "Europe/Paris"
 +
- name: Ensure NTP is running and enabled as configured.
 +
  service:
 +
    name: "ntp"
 +
    state: started
 +
    enabled: true
 +
- name: Generate ntp configuration file.
 +
  copy:
 +
    src: "ntp.conf"
 +
    dest: "/etc/ntp.conf"
 +
    mode: 0644
 +
- name: restart ntp
 +
  service:
 +
    name: "ntp"
 +
    state: restarted
 +
Et pour finir, au fichier ~/ansible/playbook.yml on ajoute une ligne dans les roles :
 +
- name: Add motd to hosts
 +
  hosts: VM_pleurote
 +
  roles:
 +
    #- motd
 +
    - ntp
 +
De la même manière qu'avant nous exécutons la command:
 +
ansible-playbook playbook.yml
 +
 +
== Installation de docker ==
 +
Nous installons Docker sur notre VM secondaire via ansible.
 +
 +
Cette fois-ci nous récupérons directement un role tout prêt [https://github.com/geerlingguy/ansible-role-docker] pour installer docker et nous apportons juste quelques modifications au niveau du playbook:
 +
 +
    - role: geerlingguy.docker
 +
      vars:
 +
        docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
 +
        docker_apt_repository: "deb [arch={{ docker_apt_arch }}] https://download.docker.com/linux/debian buster {{ docker_apt_release_channel }}"
 +
      environment:
 +
        http_proxy: "proxy.polytech-lille.fr:3128"
 +
    - registry
 +
    - web
 +
 +
De la même manière qu'avant nous exécutons la commande:
 +
ansible-playbook playbook.yml
 +
 +
Et encore une fois la magie opère et nous retrouvons sur notre machine secondaire docker installé, nous vérifions avec une simple: docker--version
 +
 +
Quant à l'installation de docker sur la machine principale, il nous a été demandé de l'installer manuellement, pour ce il nous faut installer trois choses [https://download.docker.com/linux/debian/dists/buster/pool/stable/amd64/]: containerd + docker-ce-cli + docker-ce
 +
 +
Une fois cela fait nous vérifions que l'on a bien notre docker d'installé avec un simple :
 +
service docker restart
 +
docker --version
 +
 +
== Création de votre conteneur ==
 +
Grâce à un dockerfile basé sur une couche httpd, nous créons d'abord une image avec les bons fichiers apache2.
 +
 +
Notre Dockerfile contient simplement:
 +
FROM httpd
 +
COPY ./html/ /usr/local/apache2/htdocs/
 +
 +
Nous mettons dans notre /html/index.html le message qui s'affichera sur la page web :
 +
Coucou depuis pleurote
 +
Nous créons sur notre machine principale le conteneur basé sur notre image après y avoir installé docker.
 +
docker build -t web-pleurote .
 +
docker tag web-pleurote 192.168.42.24/web-pleurote:latest #Le tag nous servira plus tard quand on la poussera sur le registry
 +
 +
Une fois toutes ces étapes faites: il est important de pouvoir stocker les images dans un registry. Nous créons un rôle ansible sur notre machine principale "docker_container" qui nous permettra de faire cette opération.
 +
 +
Nous exposons le port TCP 5000 afin de permettre la connexion et la récupération sur le registry de l'image:
 +
Dans ~/ansible/roles/registry/files/daemon.json nous indiquons les adresses avec le port 5000 (TCP) à laisser :
 +
 +
{
 +
  "insecure-registries" : ["192.168.42.15:5000","192.168.42.17:5000",
 +
"192.168.42.20:5000","192.168.42.22:5000","192.168.42.24:5000","192.168.42.25:5000","192.168.42.28:5000"]
 +
}
 +
 +
Ensuite dans ~/ansible/roles/registry/handlers/main.yml :
 +
- name: Restart docker
 +
  service:
 +
    name: docker
 +
    state: restarted
 +
 +
Et enfin dans ~/ansible/roles/registry/tasks/main.yml :
 +
 +
- name: Configuration regristre insecure
 +
  copy:
 +
    src: daemon.json
 +
    dest: /etc/docker/daemon.json
 +
  notify:
 +
    - Restart docker
 +
- name: Lancement registry docker
 +
  docker_container:
 +
    name: "docker_registry"
 +
    state: started
 +
    restart_policy: always
 +
    published_ports: "5000:5000"
 +
 +
Et pour finir dans notre playbook on ajoute une ligne dans les roles pour designer le nouveau role :
 +
-registry
 +
De la même manière qu'avant nous exécutons ansible et nous nous apercevons que notre conteneur de registry tourne bien sur la machine secondaire.
 +
 +
A partir de la, il est plus simple de créer des conteneurs sur les vm secondaires à partir de notre image qui se trouve sur le dépôt (sur la vm principale):
 +
 +
Il nous faut donc la pousser sur le regitry :
 +
docker push 192.168.42.24:5000/web-pleurote
 +
 +
==  Configuration de vos serveurs internes ==
 +
 +
Il nous a été demandé dans le TP de déployer sur les vm de nos camarades ...., mais comme nous n'avons pas tous fini en même temps le TP et afin de ne pas perturber le travail de chacun, nous avons pris la liberté et le choix de déployer tous nos fichiers ansible sur notre VM uniquement. Nous savons bien évidement que pour déployer sur les autres VM il suffit de passerle host dans le playbook.yml de VM_pleurote à VM_chanssiron (présents dans le  /etc/ansible/hosts )
 +
 +
Maintenant, nous allons enfin créer notre conteneur web:
 +
Dans ~/ansible/roles/web/tasks/main.yml :
 +
 +
- name: Lancement container web
 +
  docker_container:
 +
    name: "web_server"
 +
    image: "192.168.42.24:5000/web-pleurote:latest"
 +
    state: started
 +
    restart_policy: always
 +
    published_ports: "8090:80"
 +
 +
De la même manière qu'avant, nous modifions le fichier playbook.yml et exécutons ansible.
 +
 +
Enfin nous pouvons faire un docker ps sur la machine secondaire et voir:
 +
root@pleurote:~# docker ps
 +
CONTAINER ID  IMAGE                                    COMMAND                  CREATED      STATUS      PORTS                    NAMES
 +
36b9cd9dd4b9  192.168.42.24:5000/web-pleurote:latest  "httpd-foreground"      2 days ago  Up 2 hours  0.0.0.0:8090->80/tcp    web_server
 +
0712e73cae4f  registry                                "/entrypoint.sh /etc…"  2 days ago  Up 2 hours  0.0.0.0:5000->5000/tcp  docker_registry
 +
 +
==  Equilibreur de charge ==
 +
Enfin, nous rajoutons un CNAME à notre configuration de notre machine principale : Le but étant de mettre d'accéder à la vm secondaire depuis le même DNS que celui de la première sans pour autant se retrouver sur la page de la principale. Sachant que cette dernière est accessible avec le dns : pleurote.site , nous apportons lz CNAME lb => quand on voudra accéder à la page web de la secondaire il suffira de taper : lb.pleurote.site
 +
On n'oublie pas d'augmenter le SERIAL dans db.pleurote.site
 +
 +
Nous devons activer quelques configurations dans notre machine primaire dans /etc/apache2/mods-enabled :
 +
a2enmod mod_proxy_balancer
 +
a2enmod proxy
 +
a2enmod proxy_http
 +
a2enmod proxy_balancer
 +
a2enmod lbmethod_byrequests
 +
 +
Notre équilibreur de charge devra rediriger vers les différentes VM de notre groupe de TP, nous ajoutons alors sur la configuration du  /etc/apache2/enabled-sites/000-default.conf on ajoute:
 +
 +
</VirtualHost>
 +
<VirtualHost *:80>
 +
        ServerName lb.pleurote.site
 +
        <Proxy "balancer://mycluster>
 +
                BalancerMember "http://192.168.42.24:8090"
 +
                BalancerMember "http://192.168.42.28:8095"
 +
                BalancerMember "http://192.168.42.25:8091"
 +
                BalancerMember "http://192.168.42.22:8088"
 +
                BalancerMember "http://192.168.42.20:8086"
 +
                BalancerMember "http://192.168.42.17:8083"
 +
                BalancerMember "http://192.168.42.15:8081"
 +
        </Proxy>
 +
        ProxyPass        "/" "balancer://mycluster"
 +
        ProxyPassReverse "/" "balancer://mycluster"
 +
</VirtualHost>
 +
 +
Ainsi, à chaque fois que l'on rafraichira la page du loadBalancer, nous afficherons la page web de nos camarades.
 +
 +
Un petit  systemctl restart apache2 ne fait pas de mal, histoire d'enregistrer tout ça.
 +
Ensuite:
 +
 +
/etc/bind/
 +
rm db.pleurote.site.signed
 +
On retire l'ancienne signature, puis on signe à nouveau:
 +
/etc/bind/pleurote.site.dnssec/dnssec-signzone -o pleurote.site -k pleurote.site-ksk ../db.pleurote.site pleurote.site-zsk
 +
 +
On restart nos services:
 +
 +
service bind9 restart
 +
service apache2 restart
 +
 +
Et voilà ! Notre LB est fonctionnel et à chaque rafraichissement de page il nous affiche une des pages de nos camarades.

Version actuelle datée du 24 décembre 2020 à 08:56

TP PRA : MALTI Hind & AHOUASSOU Loris

Séance 1

Le but de ce TP est d'apprendre d'abord à faire une architecture système et réseau suffisamment représentative de ce que l'on peut trouver en entreprise (redondance réseau, redondance de stockage raid 5), une architecture réseau (DNS, DNSSEC etc), et puis en parallèle apprendre quelques notions de sécurité informatique.

Installation des systèmes d'exploitation

Pour installer la machine virtuelle, il faut se connecter en SSH sur le serveur 'capbreton' et se mettre en root 

 ssh capbreton.plil.info

Puis lancer la commande marquée ci dessous. 

 xen-create-image --hostname=pleurote --dist=buster --ip=100.64.0.20 --netmask=255.255.255.240 --dir=/usr/local/xen/  --password=XXXXXXX --gateway=100.64.0.5 --force

Nous avions acheté un nom de domaine sur Gandi, le thème étant les champignons, nous avons choisi "Pleurote".


Toutefois, il convient de préciser que si nous lançons cette commande en étant simplement en 'su', cela ne fonctionnera pas et renverra une erreur de binaire "mkswap absent". Pour corriger cela, il convient au préalable de se mettre en 'su -' plutôt qu'un simple 'su' qui chargerait uniquement les variables d'environnement de l'utilisateur qui l'a invoqué, au lieu de celles du root véritable. En effet, le binaire 'mkswap' est présent dans le dossier /sbin qui n'est présent que dans les variables d'environnement de 'su -', d'où l'erreur.

Nous avons donc nos informations machine, que l'on retrouve dans le fichier /etc/xen/pleurote.cfg:

  • Nom de domaine: pleurote
  • @IP : 100.64.0.20
  • Netmask: 255.255.255.240
  • @MAC : 00:16:3E:64:5D:88

Nous avons modifier ce fichier afin d'apporter le bridge : IMA5sc

Par la suite, nous devions modifier le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l’hôte. Cependant, avant de réaliser cette action, il nous fallait disposer de nos partitions logiques alloués. L'un des binômes de la promo s'est chargé de créer d'abord un volume de groupe 'storage' avec la commande suivante 

 vgcreate storage /dev/sde /dev/sdf

Dans ce volume de groupe, il nous a assigné chacun (binôme) deux volumes logiques de 10Giga 

 lvcreate -L10G LorisHind1 storage
 lvcreate -L10G LorisHind2 storage

À partir de là, nous pouvions modifier le fichier de configuration de notre machine virtuelle ( /etc/xen/pleurote.cfg ). Pour se faire, nous avons rajouté deux lignes au niveau de la section 'disks'. 

  'phy:/.../LorisHind1,xvdav3,w'
  'phy:/.../LorisHind2,xvdav4,w'


La ligne avec '...xvdav3...' nous servira pour le répertoire 'var' et '...xvdav4...' pour le répertoire 'home'.

  • Pour mettre le répertoire /var sur notre première partition, il faut réaliser les étapes suivantes :

D'abord accéder à la console de notre VM. 

 xl create -c etc/xen/pleurote.cfg
 xl console pleurote

Un fois dans notre VM, on va commencer par formater notre partition censée accueillir le répertoire /var 

 mkfs -t ext4 /dev/xvdav3

Ensuite on monte cette partition sur le répertoire '/mnt' afin de récupérer ce qui se trouve sur le répertoire /var : 

mount /dev/xvdav3 /mnt 
mv /var/* /mnt


On rajoute la ligne suivante dans le fichier /etc/fstab 

 /dev/xvdav3 /var ext4 defaults 0 2


On démonte '/mnt' 

 umount /mnt

Avant de remonter suivant le /etc/fstab 

 mount -a


  • Nous faisons de même pour le répertoire /home sur notre seconde partition

Pour l'installation des paquetages SSH, apache2 et bind, cela nécessitait un accès internet dépendant de la configuration des VLANs (qui n'était pas encore complètement opérationnelle)

Séance 2

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

Pour commencer, nous installons d'abord le packet "aircrack-ng" Ensuite afin de lister ce que contient le réseau Wifi, 

airmon-ng start wlp2s0mon
airmon-ng --encrypt wep wlp2s0mon
infos sur les cracottes

Nous avons besoin de cette dernière commande pour avoir les informations indispensables pour "cracker" le réseau wifi On note le bssId 04:DA:D2:9C:5050:59 et le channel 3

Nous choisissons de casser la clé WEP de la cracotte10 sur le channel 3, on enregistre les paquets dans webPack. 

airodump-ng -c 3 –-bssid 04:DA:D2:9C:5050:59 -w paquets wlp2s0mon

La commande suivante permet de se faire passer pour un client afin de générer de l'activité sur le réseau. 

aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:5050:59 wlp2s0mon

Un fichier paquets_01.cap est créé. On utilise les paquets enregistrés pour réaliser le cassage: 

aircrack-ng -z paquets_01.cap


On parvient à avoir la clé au bout de 50.000 de paquets, la dernière commande teste chaque 5000 paquets pour essayer de trouver le mot de passe. Voici le résultat trouvé :

Key found
A la toute fin il est nécessaire de faire un :
airmon-ng stop wlp2s0mon

Ajout et configuration d'un serveur DNS sur la VM

Pour commencer nous avons installé les packages bind9 et apache2 puis nous avons fait l'acquisition du nom de domaine pleurote.site sur le site gandi.net qui nous servira tout au long du TP.

Dans le dossier de configuration de bind9 à l'emplacement /etc/bind, on créé le fichier de zone db.pleurote.site et on ajoute : 

BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns1.pleurote.site. postmaster.pleurote.site. (
                             3         ; Serial
                        604800         ; Refresh
                         86400         ; Retry
                       2419200         ; Expire
                        604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.pleurote.site.
@       IN      NS      ns6.gandi.net.
ns1     IN      A       193.48.57.179

Dans le fichier named.conf.local : 

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

Dans le fichier named.conf.options : 

options {
       directory "/var/cache/bind";
       dnssec-enable yes;
       dnssec-validation auto;
       listen-on-v6 { any; };
       allow-recursion { localhost; };
};

Ensuite on se rend sur le site gandi.net puis dans "Domains" :

Dans l'onglet "Glue Record", on ajoute : 

namespace : ns1.pleurote.site
l'adresse IP de notre VM : 193.48.57.179

Dans l'onglet "Serveur de noms" on ajoute le DNS principal et secondaire : 

DNS1 : ns1.pleurote.site
DNS2 : ns6.gandi.net

Séance 3

Attaque de type "homme au milieu" par usurpation ARP

Pour expérimenter cette attaque, on installe le paquet dsniff sur notre eeePC. 

apt-get install dsniff

Ce paquet nous permet d'écouter le réseau tout en contrefaisant l'adresse MAC de la passerelle Ethernet locale, ce faisant, nous pouvons rediriger tous les paquets vers notre machine qui agira en guise d'homme du milieu, interceptant l'ensemble des données échangées.

Afin que notre eeePC soit effectif en tant qu'homme au milieu, on va passer la variable ip_forward du fichier /proc/sys/net/ipv4/ip_forward à 1. Cela le fait passer en mode routeur.

Nous insérons ensuite notre eeePC entre la machine d'un autre binôme ( son IP : 172.26.145.65 ) et le routeur utilisé par cette machine fixe ( IP : 172.26.145.254 ) à l'aide de la commande arpspoof. 

arpspoof -i enp4s0 -t 172.26.145.65 172.26.145.254

En somme, cette commande fait passer l'eeePC pour le routeaur 172.26.145.254 auprès des clients afin d'intercepter leurs paquets. Ensuite on va activer l'écoute sur Wireshark au moment où on se connecte sur un site HTTP tel que le Fabricarium de Polytech-Lille.

En lançant cela, on peut voir d'abord que l'eeePC envoie un message ARP pour se faire passer pour le routeur local 172.26.145.254. Ensuite, notre client envoie ses paquets à l'eeePC ( IP : 193.48.57.233 ) qui peut lire ses requêtes http.

Maninmiddle1.png

On voit ci-dessous des données lisibles envoyées depuis le formulaire de connexion du site du Fabricarium.

Lorismaninmiddle.png

Cependant, on constate qu'une fois la requête GET envoyée, le site du Fabricarium freeze, rien n'est chargé, même pas un page d'erreur, alors que le but de la manœuvre c'est que le client ne trouve rien d'anormal.

En fait, cela est dû au fait que notre routeur (eeePC) n'a pas renvoyée la page demandée au client, le retour n'est pas effectif. Pour permettre ça, il nous faut passer à 1 la variable rp_filter du fichier /proc/sys/net/ipv4/conf/default/rp_filter pour activer le chemin inverse.

On refait les étapes précédentes, et on peut constater que le retour est effectif chez le client.

Intrusion sur un serveur d’applications Web

Le but de cette partie, est de réussir à s'introduire sur le serveur honey.plil.info en exploitant d'éventuelles failles de sécurité. L'idée première que nous avons eu a été de faire des injections SQL dans le formulaire présenté.

Nous avons donc tester l'injection suivante aussi bien dans le champ d'identifiant 

'OR 1=1#

Le caractère # à la fin représente un commentaire et permet donc d'ignorer tout ce qui suivra après dans la requête. Ainsi, cela correspond à faire 

SELECT * FROM admins WHERE login= OR 1=1

Même s'il n'y a pas de Login clairement entré, l'expression 1=1 étant toujours vraie, la requête nous a renvoyé une table contenant des identifiants et des mots de passe.

Tableadmin.png

Nous avons donc pris l'identifiant "admin" son mot de passe "jesuislechef" que nous avons ensuite entré naturellement dans le formulaire du site honey.plil.info. Cela a eu pour effet de nous donner l'accès à l'application Web. Nous avons un peu exploré l'application. Nous voulions pouvoir lire le fichier de configuration de base de données de phpmyadmin. Nous sommes entrés dans la Gestion des Manuels et nous avons ajouter un nouveau manuel : nom : nom ; path : /etc/phpmyadmin/config-db. Une fois ajouté, nous somme allé dans Recherche de manuels et nous avons téléchargé le fichier de config précédemment ajouté.


Config-db.png

Nous avons alors utilisé le mot de passe de la base de données sur phpmyadmin. Identifiant : root, Password : gencovid19. Suite à quoi on a eu l'accès. Après avoir un peu exploré, on est rentré dans la table users de la base test, ce qui nous a fournit le login rex et le mot de passe plainpassword.

Test users.png

Nous sommes retourné dans un terminal et nous avons lancée une connexion SSH. 

ssh rex@honey.plil.info

À ce niveau là, on a aucun fichier directement utile. Néanmoins, en utilisant nos connaissances du système UNIX, on peut avoir se servir de deux fichiers très utiles:

/etc/passwd et /etc/shadow. En effet, le premier c'est celui qui contient généralement des informations sur les utilisateurs qui peuvent se connecter au système (le nom, l'identifiant, répertoire personnel...), mais il ne contient pas les mots de passe de ces utilisateurs. En revanche, le second fichier, lui, contient une version hashée des mots de passe et seuls des utilisateurs très privilégiés peuvent y avoir accès. Dans /etc/shadow on a pu voir à la dernière ligne le mot de passe crypté de root. Pour décrypter cela, nous utilisons John qui est un utilitaire de crackage de mots de passe. Pour fonctionner, John a besoin d'une liste de mots et un mot de passe à cracker. Mais avant, il faut combiner les deux fichiers précédents en utilisant la commande unshadow. Et comme c'est la dernière ligne qui nous intéresse, alors : 

unshadow /etc/passwd /etc/shadow | head -> honey_mdp

À partir de là, nous avons un indice dans le sujet : La seule indication est que le mot de passe de root possède la même particularité que le mot de passe administrateur habituel des machines de projets. Cela nous donne plusieurs informations sur le mot de passe : il est probablement composé que de lettres; il est en minuscules; et il est certainement formé de deux mots identiques de 4 lettres (comme le mot de passe glopglop)

L'idée est de créer un dictionnaire de mots de 8 lettres (qui est en fait formé du même mot de 4 lettres comme glopglop). Au lieu de faire un code C qui nous génère cela, nous avons utilisé l'utilitaire crunch qui nous génère facilement ce dictionnaire. Mais attention, si nous générons directement des mots de 8 lettres, le temps de calcul sera très très long car il devrait créer 26^8 mots ~= 2x10^11 et donc une taille ÉNORME de fichier (~+1TB).

Une approche moins naïve serait de générer d'abord un dictionnaire de mots de 4 lettres, ce qui fait seulement 26^4 = 456976 mots pour une taille de ~2MB. 

crunch 4 4 abcdefghijklmnopqrstuvwxyz > liste_mots

On peut dupliquer nos mots pour former des mots doublés de 8 lettres avec la commande 'sed' 

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

Maintenant, le boulot est fait, il ne reste plus qu'à laisser 'John' décrypter. 

john -W:liste_mots honey_mdp

Quand c'est terminé, on affiche le mot de passe : 

john --show honey_mdp

Comme indiqué sur la capture suivante, le mot de passe est fortfort

John crack.png

Séance 4

Cassage de mot de passe WPA-PSK par force brute

Nous avons précédemment craqué le clé WEP avec l'utilitaire aircrack-ng. Nous l'utilisons à nouveau pour faire de même avec la clé WPA-PSK. D'abord, on visualise notre interface : 

airmon-ng

Ensuite, on active l'interface : 

 airmon-ng start wlx40a5efd2140c

après cette commande, notre interface a été renommé en wlan0mon, nous travaillerons donc avec ce nom par la suite. On peut lancer l'écoute : 

 airodump-ng wlan0mon

On va cracker la Kracotte10, on peut donc lire son BSSID 00:14:1B:60:8C:29 et son channel 3

Avec ces informations, on va récupérer l'handshake et le mettre dans un fichier result 

 airodump-ng --bssid 00:14:1B:60:8C:29 wlan0mon --channel 3 --write result
5-3-3.png

Cela prend quelques minutes. Ensuite ce qu'il nous faut c'est générer un dictionnaire de mots de 8 chiffres, on peut utiliser l'utilitaire crunch pour cela. 

crunch 8 8 0123456789 > dico.txt

Enfin on peut lancé le crackage : 

aircrack-ng result-01.cap -w dico.txt

Cela peut durer un certain temps avant que ce soit décrypté.

5-3-4.png

Serveur SSH

Il était nécessaire que notre vm soit accessible en ssh, pour ce nous avons décommenter dans le fichier /etc/ssh/sshd-config: 

PermitRootLogin yes

Puis on redémarre le service ssh afin qu'il prenne en considération nos changements: 

systemctl restart sshd

Et voilà ! Notre vm est accessible en root avec soit: 

root@pleurote.site

soit: 

root@193.48.57.179

Sécurisation de site web par certificat

Nous commençons par un générer deux fichiers grâce à la commande 

openssl req -nodes -newkey rsa:2048 -sha1 -keyout pleurote.site.key -out pleurote.csr

pleurote.csr : Ce fichier nous sert à faire une demande de certificat auprès d'une autorité de certification. Il contient quelques informations personnelles ainsi que la clef publique.

pleurote.site.key : Celui-ci contient la clef privée (qu'on tâchera de ne jamais perdre ou distribuer) qui est complémentaire à celle présente dans le csr. On peut ensuite se rendre sur Gandi afin d'acheter le certificat. Le csr sera demandé pendant la procédure puis il faudra choisir une des trois méthodes proposées pour la vérification. Nous avons choisi celle par email pour le challenge de créer un serveur de mail sur notre machine.Pour ce, en parallèle :

on installe postfix : 

apt-get install postfix

on modifie le fichier : 

/etc/aliases

On met dedans : admin: root

on installe ensuite : 

apt-get install -y bsd-mailx
postalias /etc/aliases
mailx

et on reçoit alors le mail de Gandi avec un lien et un mot de passe de vérification à rentrer dans un champs. On clique sur le lien et on colle dessus le mot de passe de vérification.


Il nous faut maintenant récupérer notre certificat depuis Gandi ainsi que le certificat intermédiaire. On déplace ensuite l'ensemble de ces clefs dans les répertoires appropriés : 

/etc/ssl/pleurote.site.crt                                                                      
/etc/ssl/pleurote.site.key                                                                 
/etc/ssl/GandiStandardSSLCA2.pem

Configuration d'apache2

Avant toute chose, on s'assure que le module ssl est actif pour apache2. Nous remplissons ensuite les informations territoriales utiles à la génération du CSR.

Ensuite sur gandi.net dans "SSL Certificates" on achète le certificat (bien qu'il soit indiqué comme coutant 12€, lors de l'encaissement il devient gratuit) 

a2enmod ssl

On se rend ensuite dans le répertoire /etc/apache2/sites-enabled et on modifie par exemple le fichier 000-default.conf. 

<VirtualHost *:80>                                                                                                         
  ServerName www.pleurote.site                                                                                             
  Redirect / https://www.pleurote.site       
  ....                                                                        
</VirtualHost>   
                                                                                                                                                                                                                              
<VirtualHost _default_:443>                                                                                                
  ServerName www.pleurote.site                                                                                             
  DocumentRoot /var/www/html                                                                                              
  SSLEngine On                                                                                                            
  SSLCertificateFile /etc/ssl/pleurote.site.crt                                                                     
  SSLCertificateKeyFile /etc/ssl/pleurote.site.key                                                                 
  SSLCertificateChainFile /etc/ssl/GandiStandardSSLCA2.pem                                                          
  SSLVerifyClient None                                                                                                 
</VirtualHost>

Le premier VirtualHost s'assure que l'utilisateur se connecte toujours en https (grâce au Redirect) et le second est justement utilisé pour l'accès en https au site.

Enfin, on redémarre le service apache2 pour que les modifications soient prises en compte. 

service apache2 restart

Sécurisation de serveur DNS par DNSSEC

Dans cette partie, nous allons certifier aux utilisateurs de notre site web que l'IP qu'il reçoit dans la réponse DNS est bien celle du domaine voulu. Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

On commence naturellement par activer DNSSEC en ajoutant l'option dnssec-enable yes; dans le fichier /etc/bind/named.conf.local

On génère deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous créons un dossier pleurote.site.dnssec et nous mettrons les clefs dedans. Nous commençons par créer la clef asymétrique de signature de clefs de zone : 

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

Ensuite, nous créons la clef asymétrique de la zone pour signer les enregistrements : 

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

Afin que ce soit lisible et facile à manier, nous renommons nos deux paires de clefs en : pleurote-ksk.key pleurote-ksk.private pleurote-zsk.key pleurote-zsk.private 

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

On signe les enregistrements de la zone, grâce à la commande: 

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

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone : 

zone "pleurote.site" IN {
 type master;
 file "/etc/bind/db.pleurote.site.signed";
 allow-transfer {127.70.177.40;};
 dnssec-enable yes;
};

Et puis finalement :

Faire communiquer la partie publique de la KSK (présente dans le fichier pleurote-ksk.key) sur gandi dans la partie DNSSEC. On oublie pas de changer le type en 5 (RSA/SHA-1) étant donné qu'on a utilisé du SHA1 dans notre commande. Dns-verif.PNG

Séance 5

Sécurisation de données

En un premier lieu, sur le serveur Capbreton, nous créons des volumes logiques et puis nous les relions au volume group "virtual" qui a été dédié à cette partie du TP. 

root@capbreton:~# lvcreate -L1G -n pleurote-part1 virtual
 Logical volume "pleurote-part1" created.
root@capbreton:~# lvcreate -L1G -n pleurote-part2 virtual
 Logical volume "pleurote-part2" created.
root@capbreton:~# lvcreate -L1G -n pleurote-part3 virtual
 Logical volume "pleurote-part3" created.

Nous ajoutons ensuite au fichier pleurote.cfg 

'phy:/dev/virtual/pleurote-part1,xvda5,w',
'phy:/dev/virtual/pleurote-part2,xvda6,w',
'phy:/dev/virtual/pleurote-part3,xvda7,w'

root@capbreton:~# lvdisplay | grep pleurote
 LV Path            	/dev/virtual/pleurote-part1
 LV Name            	pleurote-part1
 LV Path            	/dev/virtual/pleurote-part2
 LV Name            	pleurote-part2
 LV Path            	/dev/virtual/pleurote-part3
 LV Name            	pleurote-part3

xl destroy pleurote
xl create /etc/xen/pleurote.cfg

Ensuite : Sur notre VM pleurote: On peut vérifier : 

root@pleurote:~# lsblk
NAME   MAJ:MIN   RM  SIZE RO TYPE MOUNTPOINT
xvda1  202:1  	0  512M  0 disk [SWAP]
xvda2  202:2  	0	4G  0 disk /
xvdav3 202:12035  0   10G  0 disk /var
xvdav4 202:12036  0   10G  0 disk /home
xvdav5 202:12037  0	1G  0 disk
xvdav6 202:12038  0	1G  0 disk
xvdav7 202:12039  0	1G  0 disk

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvdav5  
/dev/xvdav6 /dev/xvdav7--create /dev/md0 --level=5 --raid-devices=3 /dev/xvdav5

Cette dernière commande permettra de créer un nouveau volume md0, de définir le niveau du raid (5) ainsi que les différents périphériques actifs xvdav 5->7 

root@pleurote:~# mdadm --monitor --daemonise /dev/md0

root@pleurote:~# mkfs -t ext4 /dev/md0

Ensuite on modifie /etc/fstab : 

/dev/md0 /raid5 ext4 defaults 0 1



root@pleurote:~# mdadm --detail /dev/md0
/dev/md0:
      	Version : 1.2
	Creation Time : Mon Nov 30 14:17:07 2020
   	Raid Level : raid5
   	Array Size : 2093056 (2044.00 MiB 2143.29 MB)
	Used Dev Size : 1046528 (1022.00 MiB 1071.64 MB)
 	Raid Devices : 3
	Total Devices : 3
  	Persistence : Superblock is persistent
  	Update Time : Mon Nov 30 14:21:28 2020
       State : clean

Active Devices : 3 

       Working Devices : 3

Failed Devices : 0 

	Spare Devices : 0
       Layout : left-symmetric
   	Chunk Size : 512K
       Consistency Policy : resync

Name : pleurote:0 (local to host pleurote) 

       UUID : 174ca3a2:9133344c:c58badf8:bccd6167
       Events : 18
       Number   Major   Minor   RaidDevice State
  	0 	202	12037    	0  	active sync   /dev/xvdav5
  	1 	202	12038    	1  	active sync   /dev/xvdav6
  	3 	202	12039    	2  	active sync   /dev/xvdav7

Après avoir formaté la partition formée par le raid, on va la monter. Puis on crée un fichier sur cette partition: 

mount /dev/md0 /mnt
touch test.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre redondance, simulons une panne sur un des disques de notre RAID, ce qui pourrait arriver dans un cas réel. 

mdadm --set-faulty /dev/md0 /dev/xvdf1
mdadm --remove /dev/xvdf1

Nous constatons que notre fichier test.txt est toujours présent, malgré la "perte" de l'un des disques.

Chiffrement de données

Il peut être utile pour diverses raison de chiffrer les disques afin qu'un accès non autorisé par le propriétaire soit proscrit. Pour cela nous allons utiliser l'utilitaire "cryptsetup" avec le format LUKS afin de chiffrer notre disque avec un mot de passe. 

root@truite:~# fdisk -l

On repère alors, notre clé USB: 

Disk /dev/sda: 7.2 GiB, 7736072192 bytes, 15109516 sectors

On formate la clé en une seule partition 

root@truite:~# fdisk /dev/sda  
Command (m for help): d      	 
Partition number (1,2, default 2): 1   
Partition 1 has been deleted.

Idem pour la seconde existante.Puis, on chiffre l'unique partition de la clé USB et ensuite on la déchiffre : 

root@truite:~# cryptsetup luksOpen /dev/sda1 MonUSB
root@truite:~# cryptsetup luksOpen /dev/sda1 MonUSB

On choisis alors un bon mot de passe, puis on formate l'USB: 

root@truite:~# mkfs.ext4 /dev/mapper/MonUSB

Et puis ensuite, on monte notre USB et on crée un fichier dedans par exemple: 

root@truite:~# mkdir /mnt/USB
root@truite:~# mount -t ext4 /dev/mapper/MonUSB /mnt/USB
root@truite:~# touch /mnt/USB/test.txt

Une fois que l'on a terminé, on retire notre USB en toute sécurité: 

root@truite:~# umount /mnt/USB
root@truite:~# cryptsetup luksClose MonUSB

Interconnexion Internet de secours (IPv6)

On ajoute dans /etc/network/interfaces : 

iface eth0 inet6 auto

Interconnexion Internet de secours (IPv4)

Séance 6

Sécurisation WiFi par WPA2-EAP (FreeRadius)

Configuration de Freeradius

On commence par installer freeRadius : 

apt-get install freeradius


Dans le fichier /etc/freeradius/3.0/mods-enabled/mschap : 

use_mppe = yes
require_encryption = yes
require_strong = yes

Ensuite dans le fichier /etc/freeradius/3.0/mods-enabledpeap : 

eap{
default_eap_type = peap
}

On modifie également le fichier users (on décommente la partie bob): 

pleurote  Cleartext-Password := "pasglop"

Puis le fichier clients.conf 

client pleurote {
ipaddr = 10.60.100.10
secret = secret_groupe10
}

On se connecte à la borne wifi avec : 

ssh root@10.60.100.10 -c aes128-cbc

wifi-ima5sc(config)#aaa authentication login eap_group10 group radius_group10 
wifi-ima5sc(config)#radius-server host 193.48.57.179 auth-port 1812 acct-port 1813 key secret_group10  
wifi-ima5sc(config)#aaa group server radius radius_group10
wifi-ima5sc(config-sg-radius)#server 193.48.57.179 auth-port 1812 acct-port 1813
wifi-ima5sc(config-sg-radius)#dot11 ssid SSID_GROUP10
wifi-ima5sc(config-ssid)#mbssid guest-mode
wifi-ima5sc(config-ssid)#vlan 314 
wifi-ima5sc(config-ssid)#authentication open eap eap_group10
wifi-ima5sc(config-ssid)#authentication network-eap eap_group10
wifi-ima5sc(config-ssid)#authentication key-management wpa



wifi-ima5sc(config-ssid)#interface Dot11Radio0
wifi-ima5sc(config-if)#encryption vlan 310 mode ciphers aes-ccm tkip
wifi-ima5sc(config-if)#mbssid                                       
wifi-ima5sc(config-if)#ssid SSID_GROUP10

wifi-ima5sc(config)#int Dot11radio0.10
wifi-ima5sc(config-subif)#encapsulation dot1q 310
wifi-ima5sc(config-subif)#bridge-group 10
wifi-ima5sc(config-subif)#exit
wifi-ima5sc(config)#int Dot11radio0
wifi-ima5sc(config-if)#no shutdown 
wifi-ima5sc(config-if)#exit
wifi-ima5sc(config)#exit

Si nous faisons un ping :

Cap0.png

Sur un téléphone portable, nous essayons de nous connecter au wifi SSID_GROUP10 avec le bon mot de passe et user. Puis nous lançons le mode debug avec la commande: 

freeradius -X

et sur la borne wifi nous lançons afin de voir : 

sh dot11 associations

Cap1.png

DHCP

On se connecte en ssh sur les deux routeurs 6509-E et C9200 : 

IMA5sc-R1>enable
 Password: 
IMA5sc-R1#config t
Enter configuration commands, one per line.  End with CNTL/Z.
IMA5sc-R1(config)#
IMA5sc-R1(config)#ip dhcp pool groupe10
IMA5sc-R1(dhcp-config)#dns 193.48.57.179
IMA5sc-R1(dhcp-config)#network 10.6.110.0 255.255.255.0
IMA5sc-R1(dhcp-config)#default-router 10.60.110.1
IMA5sc-R1(dhcp-config)#exit
IMA5sc-R1(config)#ip dhcp excluded-address 10.60.110.0 10.60.110.100
IMA5sc-R1(config)#ip dhcp excluded-address 10.60.110.110 10.60.110.255
IMA5sc-R1(config)#exit
IMA5sc-R1#sh ip dhcp binding

Second rooter: 

root@zabeth15:/home/pifou# ssh admin@192.168.222.13
IMA5sc-R2>enable
IMA5sc-R2#config t
IMA5sc-R2(config)#ip dhcp pool groupe10
IMA5sc-R2(dhcp-config)#dns 193.48.57.179
IMA5sc-R2(dhcp-config)#network 10.60.110.0 255.255.255.0
IMA5sc-R2(dhcp-config)#default-router 10.60.110.2
IMA5sc-R2(dhcp-config)#exit
IMA5sc-R2(config)#ip dhcp excluded-address 10.60.110.0 10.60.110.50
IMA5sc-R2(config)#ip dhcp excluded-address 10.60.110.100 10.60.110.255
IMA5sc-R2(config)#exit
IMA5sc-R2#sh ip dhcp binding

Mascarade

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


Config des Vlan

Rooter 1 

IMA5sc-R1#config t
IMA5sc-R1(config)#vlan 310
IMA5sc-R1(config-vlan)#int vlan 310
IMA5sc-R1(config-if)#vrrp 50 ip 10.60.110.254
IMA5sc-R1(config-if)#vrrp 50 preempt
IMA5sc-R1(config-if)#vrrp 50 priority 110
IMA5sc-R1(config-if)#exit    
IMA5sc-R1(config)#exit


Rooter 2 

IMA5sc-R2#config t
Enter configuration commands, one per line.  End with CNTL/Z.
IMA5sc-R2(config)#vlan 310
IMA5sc-R2(config-vlan)#int vlan 310
IMA5sc-R2(config-if)#vrrp 50 address-family ipv4
IMA5sc-R2(config-if-vrrp)#address 10.60.110.254
IMA5sc-R2(config-if-vrrp)#preempt
IMA5sc-R2(config-if-vrrp)#vrrpv2
IMA5sc-R2(config-if-vrrp)#exit
IMA5sc-R2(config-if)#exit


borne wifi 

wifi-ima5sc(config)#interface GigabitEthernet0.10
wifi-ima5sc(config-subif)#enc
wifi-ima5sc(config-subif)#encapsulation do
wifi-ima5sc(config-subif)#encapsulation dot1Q 310
wifi-ima5sc(config-subif)#brid
wifi-ima5sc(config-subif)#bridge-group 10
wifi-ima5sc(config-subif)#exit

IMA5sc-R2(config)#exit
IMA5sc-R2#

IMA5sc-R1(config)#ipv6 unicast-routing
IMA5sc-R1(config)#vlan 310          
IMA5sc-R1(config-vlan)#name pleurote.site
IMA5sc-R1(config-vlan)#exit
IMA5sc-R1(config)#int vlan 310
IMA5sc-R1(config-if)#no shut
IMA5sc-R1(config-if)#ip address 10.60.110.1 255.255.255.0
IMA5sc-R1(config-if)#ipv6 enable
IMA5sc-R1(config-if)#ipv6 address 2001:660:4401:60bc::0/64 eui-64ipv6
IMA5sc-R1(config-if)#ipv6 nd prefix 2001:660:4401:60bc::0/64 1000 900
IMA5sc-R1(config-if)#ipv6 nd router-preference Low
IMA5sc-R1(config-if)#exit
IMA5sc-R1(config)#exit



IMA5sc-R2#config t
Enter configuration commands, one per line.  End with CNTL/Z.
IMA5sc-R2(config)#ipv6 unicast-routing
IMA5sc-R2(config)#vlan 310
IMA5sc-R2(config-vlan)#name pleurote.site
IMA5sc-R2(config-vlan)#exit
IMA5sc-R2(config)#int vlan 310
IMA5sc-R2(config-if)#no shut
IMA5sc-R2(config-if)#ip address 10.60.110.2 255.255.255.0
IMA5sc-R2(config-if)#ipv6 enable         
IMA5sc-R2(config-if)#ipv6 address 2001:660:4401:60bc::0/64 eui-64
IMA5sc-R2(config-if)#ipv6 nd prefix 2001:660:4401:60bc::0/64 1000 900
IMA5sc-R2(config-if)#ipv6 nd router-preference High
IMA5sc-R2(config-if)#exit 
IMA5sc-R2(con

Exploitation de failles du système

Nous avons d'abord cherché des programmes permettant l'analyse des failles et vulnérabilités sur le système Linux. Nous avons trouvé plusieurs avec leurs spécificités, en particulier Lynis. Lynis est un logiciel libre d'audit de sécurité extensible pour les ordinateurs ou machines virtuelles utilisant les systèmes d'exploitation, Linux, macOS, et autres dérivés d'Unix ou de type POSIX. Il permet un examen rapide (scan) d'un système et de ses défenses de sécurité.

Il va déterminer diverses informations sur le système à auditer, tels que le système d'exploitation, les paramètres du noyau, les mécanismes d'authentification et de fonctionnement des comptes, les paquets et services installés, la configuration réseau, la journalisation et la supervision (par exemple syslog-ng), la cryptographie (par exemple les certificats TLS/SSL) ou encore les antivirus installés (par exemple ClamAV ou rkhunter). En complément, il vérifiera le système à la recherche d'erreurs de configuration et de problèmes de sécurité.

Le test a été réalisé sur un noyau linux ubuntu.

Pour installer Lynis. 

sudo apt install lynis

On peut ensuite lancer un audit du système. 

lynis audit system

Lynis nous renverra tout un tas d'informations sur une multitude de tests qu'il aura réalisé. Tout ceci étant trop long, nous nous sommes contentés d'afficher une partie des résultats, notamment des avertissements sur des possibles faiblesses, tels que des vulnérabilités au niveau de différents paquets, du réseau, ou encore de l'authentification.

Lynis1.png

Le programme termine en nous suggérant des solutions pour améliorer le système et sa sécurité.

Pour des tests plus ou moins variés, il existe d'autres programmes tels que chkrootkit, rkhunter etc.

Séance 7

Le but de ce TP est de nous initier a Ansible, Docker et nous apprendre à créer un loadbalancer et manier les différents outils nécessaire à la réalisation de TP.

Architecture générale de la ferme

Une VM secondaire a été mise à notre disposition, elle n'est pas connectée à internet. Elle accèdera à internet en passant par une route (passant par la VM Pleurote primaire qui se trouve sur le serveur Capbreton). Ce qui fait de la VM primaire jouera le rôle d'un bastion et d'un loadBalancer.

Ansible.png


Configuration des Vlans

Pour commencer, il a fallu faire quelques configurations réseau afin de faire le lien entre les deux VM et puis parvenir à accèder à internet sans jamais y être exposé directement. Pour ce, Nous ajoutons une interface réseau à notre machine principale afin de la relier au vlan50 et ce, sur le fichier /etc/xen/pleurote.cfg : 

#
#  Networking
#
vif = [ 'ip=100.64.0.20 ,mac=00:16:3E:64:5D:88,bridge=IMA5sc','ip=192.168.42.10, mac=00:16:3E:64:5D:88,bridge=bridgeStudents' ]


Ensuite, nous allons sur le fichier /etc/network/interfaces de la vm primaire: 

#The primary network interface
auto eth0
iface eth0 inet static
  address 193.48.57.179
  netmask 255.255.255.255
  up ip address add dev eth0 100.64.0.19/24
  up ip route add default via 100.64.0.2 src 193.48.57.179
  down ip address del dev eth0 100.64.0.19/24
  down ip route del default via 100.64.0.2 src 193.48.57.179

Sur la vm secondaire et nous apportons les modifications suivantes: 

#The primary network interface
auto eth0
iface eth0 inet static
 address 192.168.42.24
 netmask 255.255.255.0
 gateway 192.168.42.10

Ensuite nous indiquons le server par lequel notre secondaire devra passer /etc/resolv.conf : 

domain plil.info
nameserver 192.168.42.10

Nous constatons que désormais les deux machines peuvent se pinger l'une l'autre.

Mascarade

Afin de donner accès à internet à notre secondaire, nous procédons par la mise en place d'une mascarade: 

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

Ansible

Nous nous assurons avant tout que sur notre machine secondaire possède bien une bonne version python et pip qui soit compatible avec Ansible. Ansible sera notre allié si nous souhaitons déployer une succession de mêmes tâches sur les 7 VM sans devoir nous y connecter une à une et faire un travail assez redondant au risque de faire des erreurs etc.

Nous installons donc ansible sur la machine principale: 

$ apt update
$ apt install ansible

Nous devons configurer le /etc/ansible/hosts afin de designer notre machine à nous et celles de nos camarades: 

[VM_pleurote]
192.168.42.24

[VM_Chassiron]
192.168.42.28
192.168.42.25
192.168.42.22
192.168.42.20
192.168.42.17
193.168.42.15

Clés SSH

Naturellement, la première chose à faire est de créer une clé SSH et faire un échange de clés entre notre VM primaire et toutes les autres VM secondaires. Cela nous permettra de deployer ansible depuis notre vm principale vers les vm secondaires sans devoir s'authentifier à chaque fois. Nous générons d'abord une clé ssh asymétrique : 

ssh-keygen -t rsa

Ensuite, nous mettons notre clé publique sur le fichier authorized_key de chaque vm secondaire: 

cat .ssh/id_rsa.pub | ssh <IP_CIBLE> cat >> /root/.ssh/authorized_keys"

Motd

Notre premier essai sera sur un service assez simple "motd" : Il permet d'afficher lors d'une connexion SSH un message. Nous nous sommes questionnés sur l'utilité d'un tel programme et nous avons réalisé que dans un contexte entreprise, on pourrait très bien imaginé que le message nous préviendrait qu'on est sur une machine de Prod, qu'il nous décrirait des manipulations particulières à prendre en considération lors de l'utilisation de cette VM. Pour cela nous nous inspirons fortement du travail du repository :[1]

D'abord nous créons un dossier ansible avec un dossier files et un autre tasks qui contiennent respectivement les fichiers utilisés et les tâches à faire: dans files, nous créons un fichier avec le contenu que l'on souhaite afficher: 

root@pleurote:~/ansible/roles/motd/files# cat motd.txt
--------------------------------------------------------------------------
                     This system is managed by Ansible
--------------------------------------------------------------------------
Coucou depuis la lune

Ensuite dans ~/ansible/roles/motd/tasks: 

---
- name: Delete /etc/motd file
  file:
    path: /etc/motd
    state: absent
- name: Add motd
  copy:
    src: motd.txt
    dest: /etc/motd
    follow: yes

Ensuite dans un fichier qu'on nomme playbook.yml au niveau du ~/ansible : 

---
- name: Add motd to hosts
  hosts: VM_pleurote
  roles:
    - motd

Nous exécutons ensuite la commande: 

ansible-playbook playbook.yml

Nous allons faire la vérification en nous connectons en ssh sur la machine secondaire, et tadan : magie ? Nous retrouvons notre message d'accueil "Coucou depuis la lune"

NTP

NTP va permettre de synchroniser les VM sur le même créneau horaire. Nous allons procéder de la même manière que pour le précèdent exercice, on nous inspirons également du repository [2]:

Ainsi nous retrouvons dans ~/ansible/roles/ntp/files/ntp.conf : 

driftfile /var/lib/ntp/drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server ntp.plil.info

Ensuite dans ~/ansible/roles/ntp/tasks/main.yml : 

---
- name: Ensure NTP package is installed.
 package:
   name: ntp
   state: present
- name: Ensure tzdata package is installed (Linux).
 package:
   name: tzdata
   state: present
- name: Set timezone.
 timezone:
   name: "Europe/Paris"
- name: Ensure NTP is running and enabled as configured.
 service:
   name: "ntp"
   state: started
   enabled: true
- name: Generate ntp configuration file.
 copy:
   src: "ntp.conf"
   dest: "/etc/ntp.conf"
   mode: 0644
- name: restart ntp
 service:
   name: "ntp"
   state: restarted

Et pour finir, au fichier ~/ansible/playbook.yml on ajoute une ligne dans les roles : 

- name: Add motd to hosts
  hosts: VM_pleurote
  roles:
    #- motd
    - ntp

De la même manière qu'avant nous exécutons la command: 

ansible-playbook playbook.yml

Installation de docker

Nous installons Docker sur notre VM secondaire via ansible.

Cette fois-ci nous récupérons directement un role tout prêt [3] pour installer docker et nous apportons juste quelques modifications au niveau du playbook: 

    - role: geerlingguy.docker
      vars:
        docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
        docker_apt_repository: "deb [arch=Modèle:Docker apt arch] https://download.docker.com/linux/debian buster Modèle:Docker apt release channel"
      environment:
        http_proxy: "proxy.polytech-lille.fr:3128"
    - registry
    - web

De la même manière qu'avant nous exécutons la commande: 

ansible-playbook playbook.yml

Et encore une fois la magie opère et nous retrouvons sur notre machine secondaire docker installé, nous vérifions avec une simple: docker--version

Quant à l'installation de docker sur la machine principale, il nous a été demandé de l'installer manuellement, pour ce il nous faut installer trois choses [4]: containerd + docker-ce-cli + docker-ce

Une fois cela fait nous vérifions que l'on a bien notre docker d'installé avec un simple : 

service docker restart 
docker --version

Création de votre conteneur

Grâce à un dockerfile basé sur une couche httpd, nous créons d'abord une image avec les bons fichiers apache2.

Notre Dockerfile contient simplement: 

FROM httpd
COPY ./html/ /usr/local/apache2/htdocs/

Nous mettons dans notre /html/index.html le message qui s'affichera sur la page web : 

Coucou depuis pleurote

Nous créons sur notre machine principale le conteneur basé sur notre image après y avoir installé docker. 

docker build -t web-pleurote .
docker tag web-pleurote 192.168.42.24/web-pleurote:latest #Le tag nous servira plus tard quand on la poussera sur le registry

Une fois toutes ces étapes faites: il est important de pouvoir stocker les images dans un registry. Nous créons un rôle ansible sur notre machine principale "docker_container" qui nous permettra de faire cette opération.

Nous exposons le port TCP 5000 afin de permettre la connexion et la récupération sur le registry de l'image: Dans ~/ansible/roles/registry/files/daemon.json nous indiquons les adresses avec le port 5000 (TCP) à laisser : 

{
 "insecure-registries" : ["192.168.42.15:5000","192.168.42.17:5000",
"192.168.42.20:5000","192.168.42.22:5000","192.168.42.24:5000","192.168.42.25:5000","192.168.42.28:5000"]
}

Ensuite dans ~/ansible/roles/registry/handlers/main.yml : 

- name: Restart docker
  service:
    name: docker
    state: restarted

Et enfin dans ~/ansible/roles/registry/tasks/main.yml : 

- name: Configuration regristre insecure
  copy:
    src: daemon.json
    dest: /etc/docker/daemon.json
  notify:
    - Restart docker
- name: Lancement registry docker
  docker_container:
    name: "docker_registry"
    state: started
    restart_policy: always
    published_ports: "5000:5000"

Et pour finir dans notre playbook on ajoute une ligne dans les roles pour designer le nouveau role : 

-registry

De la même manière qu'avant nous exécutons ansible et nous nous apercevons que notre conteneur de registry tourne bien sur la machine secondaire.

A partir de la, il est plus simple de créer des conteneurs sur les vm secondaires à partir de notre image qui se trouve sur le dépôt (sur la vm principale):

Il nous faut donc la pousser sur le regitry : 

docker push 192.168.42.24:5000/web-pleurote

Configuration de vos serveurs internes

Il nous a été demandé dans le TP de déployer sur les vm de nos camarades ...., mais comme nous n'avons pas tous fini en même temps le TP et afin de ne pas perturber le travail de chacun, nous avons pris la liberté et le choix de déployer tous nos fichiers ansible sur notre VM uniquement. Nous savons bien évidement que pour déployer sur les autres VM il suffit de passerle host dans le playbook.yml de VM_pleurote à VM_chanssiron (présents dans le /etc/ansible/hosts )

Maintenant, nous allons enfin créer notre conteneur web: Dans ~/ansible/roles/web/tasks/main.yml : 

- name: Lancement container web
  docker_container:
    name: "web_server"
    image: "192.168.42.24:5000/web-pleurote:latest"
    state: started
    restart_policy: always
    published_ports: "8090:80"

De la même manière qu'avant, nous modifions le fichier playbook.yml et exécutons ansible.

Enfin nous pouvons faire un docker ps sur la machine secondaire et voir: 

root@pleurote:~# docker ps
CONTAINER ID   IMAGE                                    COMMAND                  CREATED      STATUS       PORTS                    NAMES
36b9cd9dd4b9   192.168.42.24:5000/web-pleurote:latest   "httpd-foreground"       2 days ago   Up 2 hours   0.0.0.0:8090->80/tcp     web_server
0712e73cae4f   registry                                 "/entrypoint.sh /etc…"   2 days ago   Up 2 hours   0.0.0.0:5000->5000/tcp   docker_registry

Equilibreur de charge

Enfin, nous rajoutons un CNAME à notre configuration de notre machine principale : Le but étant de mettre d'accéder à la vm secondaire depuis le même DNS que celui de la première sans pour autant se retrouver sur la page de la principale. Sachant que cette dernière est accessible avec le dns : pleurote.site , nous apportons lz CNAME lb => quand on voudra accéder à la page web de la secondaire il suffira de taper : lb.pleurote.site On n'oublie pas d'augmenter le SERIAL dans db.pleurote.site

Nous devons activer quelques configurations dans notre machine primaire dans /etc/apache2/mods-enabled : 

a2enmod mod_proxy_balancer
a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Notre équilibreur de charge devra rediriger vers les différentes VM de notre groupe de TP, nous ajoutons alors sur la configuration du /etc/apache2/enabled-sites/000-default.conf on ajoute: 

</VirtualHost>
<VirtualHost *:80>
        ServerName lb.pleurote.site
        <Proxy "balancer://mycluster>
                BalancerMember "http://192.168.42.24:8090"
                BalancerMember "http://192.168.42.28:8095"
                BalancerMember "http://192.168.42.25:8091"
                BalancerMember "http://192.168.42.22:8088"
                BalancerMember "http://192.168.42.20:8086"
                BalancerMember "http://192.168.42.17:8083"
                BalancerMember "http://192.168.42.15:8081"
        </Proxy>
        ProxyPass        "/" "balancer://mycluster"
        ProxyPassReverse "/" "balancer://mycluster"
</VirtualHost>

Ainsi, à chaque fois que l'on rafraichira la page du loadBalancer, nous afficherons la page web de nos camarades.

Un petit systemctl restart apache2 ne fait pas de mal, histoire d'enregistrer tout ça. Ensuite: 

/etc/bind/
rm db.pleurote.site.signed

On retire l'ancienne signature, puis on signe à nouveau: 

/etc/bind/pleurote.site.dnssec/dnssec-signzone -o pleurote.site -k pleurote.site-ksk ../db.pleurote.site pleurote.site-zsk

On restart nos services: 

service bind9 restart
service apache2 restart

Et voilà ! Notre LB est fonctionnel et à chaque rafraichissement de page il nous affiche une des pages de nos camarades.

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