TP sysres IMA2a5 2020/2021 G8
Sommaire
Architecture matérielle
Cartes de supervision
Dans l'optique d'avoir une redondance matérielle totale, nous devons installer deux cartes de supervision dans la baie de la salle A304 (normalement une suffit pour gérer les cartes réseau).
Problèmatique: Configuration et installation des OS des cartes de supervision
Etape 1: Vérifier l'existance d'OS sur les deux cartes.
Pour cela, nous avons utilisé le port console de la première carte de SV grâce à une liaison série sur un PC. Nous avons ensuite utilisé l'interface minicom pour communiquer avec la carte de SV connectée en série au PC (minicom à installer au préalable).
Nous avons donc connecté à tour de rôle les deux cartes de SV : -> 1ere carte: OS présent. Réaction suite à la commande boot et différents OS trouvés (3) - La commande show version nous permet de voir les versions des OS. -> 2ème carte: OS absent.
Il faut donc copier l'OS de la première carte sur la deuxième. Nous avons choisi d'installer l'OS le plus "volumineux" par défaut.
Etape 2: Copie du fichier d'OS
Le fichier d'OS est stocké sur une carte flash présente sur les carte de SV.
Ainsi, grâce à l'emplacement en façade pour les cartes flash présents sur les cartes de SV, nous avons pu copier le fichier d'OS de la premiere carte de SV vers l'autre. Puis, il nous a suffit de replacer la carte flash dans la deuxième carte de supervision.
Commande pour copier le fichier d'OS de la première carte flash vers la deuxième : copy sup-bootdisk:/sys/s72033/base/s72033-ipservicesk9_wan-mz.&éé-33.SXI6.bin disk0:
Etape 3: Reboot de la deuxième carte
Pour s'assurer du bon fonctionnement de la deuxième carte, nous avons réinstallé sa carte flash contenant le fichier d'OS, puis nous avons redémarrée (boot) la deuxième carte de SV.
Commandes :
boot
sh ver
Etape 4: Vérificaton de la redondance
Pour vérifier que les deux cartes sont bien configurées et détectées, on utilise les commandes :
sh redundancy
On peut voir que la première carte de supervision est active alors que la deuxième est en standby. La première carte bootée est par défaut la carte active.
Nous pouvons désormais accéder aux deux cartes via la première. On peut remarquer, avec la commande 'dir ?' (faire un 'enable' avant), que les répertoires/fichiers de la deuxième carte de SV (standby) ont un nom en préfixe 'slave'.
Remarque: Nous avons ajouté des modules 10Gbit présents sur l'ancien chassis à la baie en E304. Nous pouvons voir l'ensemble des modules hardware via la commande 'sh module'. On voit qu'il y a 4 modules de 10Gbits et 2 cartes de SV.
Configuration des Machines Virtuelles
Configuration de base
Ayant travaillé, sur les deux premières séances, sur la configuration de la carte de supervision, mes camarades travaillant sur les VM se sont chargés de créer la mienne.
J'ai également manqué la troisième séance (COVID) et j'ai donc pris du retard sur le reste du groupe qui a pu continuer la configuration de leur VM, et de leur DNS.
Ainsi, j'ai repris le travail de mon côté sur ma VM.
Les VM Xen ont été installé sur CapBreton. Ma machine se nomme Boeing, a pour adresse IP 193.48.57.172 (2001:660:4401:60a2:216:3eff:fed9:7994 en IPV6) et les logins sont les suivants :
- id : root
- mdp : glopglopglop
Les paquetages nécessaires pour SSH et le serveur Web apache 2 ont été installé par mes camarades au préalable.
Ajout des partitions var et home
Dans un premier temps, j'ajoute les partitions /var et /home à ma machine virtuelle. En effet, cette dernière ayant peu de stockage (environ 4Go), l'ajout de ces deux partitions de 10Go chacune sera utile. /var est indiqué pour stocker les données systèmes/logs, et /home pour les répertoires utilisateurs.
La commande lvcreate permet de créer les deux nouvelles partitions.
Je créé le système de fichiers de deux nouvelles partitions avec la commande :
mke2fs
Je modifie ensuite le fichier boeing.cfg (fichier de configuration de ma VM) afin de "lier" les deux nouvelles partitions à ma VM en ajoutant les lignes suivantes :
phy:/dev/virtual/boeing-home,xvdb1,w
phy:/dev/virtual/boeing-var,xvdb2,w
La machine doit être redémarré désormais pour prendre en compte les modifications :
xl shutdown boeing
Il faut maintenant modifier le fichier fstab, la table des différents systèmes de fichiers sur Linux, qui contient la liste des disques utilisés au démarrage et des partitions de ces disques.
On y ajoute les lignes suivantes :
/dev/xvdb1 /home ext4 defaults 0 2
/dev/xvdb2 /var ext4 defaults 0 2
!Attention!
Avant d’intégrer le disque /var dans le fichier fstab, il faut monter /var dans un fichier temporaire /mnt sous peine de détruire la VM. Il faut ensuite supprimer les fichiers lock log et run de ce /mnt, déplacer les fichiers de /var dans /mnt, unmount le /mnt, et enfin monter toutes les partitions de fstab (mount -a).
Une fois les partitions /var et /home créées, liées à ma VM et montées, on a :
root@boeing:/etc# df -h
Filesystem Size Used Avail Use% Mounted on
udev 97M 0 97M 0% /dev
tmpfs 24M 80K 23M 1% /run
/dev/xvda2 3.9G 481M 3.2G 13% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 149M 0 149M 0% /dev/shm
/dev/xvdb1 9.9G 23M 9.4G 1% /home
/dev/xvdb2 9.9G 149M 9.2G 2% /var
Services Internet
Configuration du DNS
Une fois la VM configurée, il faut configurer le serveur DNS.
Premièrement, il faut acheter un nom de domaine sur le site gandi. Mon nom de domaine est : paletbreton.site.
J'installe le paquet bind9 sur ma VM.
Tout d'abord, je modifie le fichier /etc/resolve.conf de la manière suivante :
domain paletbreton.site
search paletbreton.site
name server 193.48.57.172
#search plil.info
#nameserver 193.48.57.48
Ainsi, je suis sur que ma machine passe bien par mon domaine et non celui de l'école.
Je créé ensuite les nouveaux "nom de domaines", appelés zones, en créant deux fichiers :
/etc/bind/db.paletbreton.site pour le sens direct;
/etc/bind/db.57.48.193.in-addr.arpa pour le sens inverse;
Ces fichiers donnent les informations envoyées lors d'une requête DNS, ils contiennent notamment les adresses IPs, les IPs des sous domaines, le TTL (Time To Live) qui est ici fixé à 2 jours (172800) etc.
J'inclue ensuite ces deux zones dans la liste des domaines de bind9 en modifiant le fichier /etc/bind/named.conf.local.
Jattribue désormais les noms d'hôtes à chacune des adresses IP en modifiant le fichier /etc/hosts comme suit :
127.0.0.1 localhost
127.0.0.1 boeing.paletbreton.site
193.48.57.172 boeing.paletbreton.site
2001:660:4401:60a2:216:3eff:fed9:7994 boeing.paletbreton.site
Enfin, dans le fichier hostname, j'identifie ma machine comme telle :
boeing.paletbreton.site
Je redémarre le serveur DNS (serivce bind9 restart).
Le DNS est désormais configuré. Pour le tester, je ping le site www.google.fr par exemple, si le ping passe le DNS est correctement configuré.
Il faut maintenant rediriger mon domaine paletbreton.site vers ma VM. Cela se fait via le site gandi, et la modification prend un certain temps à se faire.
Sécurisation de site web par certificat
Sécurisation de serveur DNS par DNSSEC
Tests d'intrusion
Je vais tester ici les méthodes de sécurisation du Wifi, en branchant notamment une clé wifi à ma machine permettant de créer un réseau wifi spécifique à ma clé. La clé branchée à ma machine est le cracotte08.
Cassage WEP
Premièrement, j'installe le paquet aircrack-ng, et je repère ma configuration wifi à l'aide de la commande :
iwconfig
Le résultat suivant s'affiche :
On voit que le nom de mon interface wifi est : wlx40a5ef0f6518. Je permets ensuite à la clé de recevoir des messages de tout le réseau pour pouvoir l’espionner en activant son mode monitor :
airmon-ng start wlx40a5ef0f6518
L’interface est renommée wlan0mon. Il faut également penser à installer les drivers de la carte wifi :
apt-get install firmware-linux-nonfree
Ensuite, je vais aller espionner les trames WIFI afin de repérer le BSSID (adresse MAC) de ma carte et son canal de communication avec la commande “airodump-ng wlan0mon”, je trouve :
On voit que ma clé (cracotte08 pour le WEP, kracotte08 pour le WPA) à pour BSSID 04:DA:D2:9C:50:57 et pour canal 9.
Je vais donc espionner plus précisément les trames de ma clé via la commande :
airodump-ng -c 9 –bssid 04:DA:D2:9C:50:57 wlan0mon
Je redirige ensuite les trames dans un fichier pour pouvoir les décrypter :
airodump-ng -c 9 –bssid 04:DA:D2:9C:50:57 wlan0mon -w data
Je lance ensuite dans un autre terminal la commande de aircrack :
aircrack-ng -b 04:DA:D2:9C:50:57 data*.cap
Et je trouve la clé :
Cassage WPA
Pour cette partie, je m'installe sur un autre PC que le mien (afin que je puisse avancer sur autre chose en attendant le décryptage), et je regarde les trames WPA envoyées par ma clé wifi :
airodump-ng -c 4 - - bssid 04:DA:D2:9C:50:57 wlan0mon -w log
Pour capturer les dialogues d'identification WPA avec airodump-ng, j'attends que l'utilitaire m'indique "HandShake" comme suit :
La clé WPA est un nombre sur 8 chiffres. Il faut donc fournir à aircrack un dictionnaire contenant tous les nombres de 8 chiffres possibles. Pour le créer, j'écris le programme suivant :
#include "stdio.h"
#include "stdlib.h"
int main (){
FILE* dico = NULL;
dico = fopen("dico.txt","w");
for (int i=0;i<100000000;i++) {
fprintf(dico,"08%d\n",i);
}
fclose(dico);
}
Ainsi, mon dictionnaire est créé sous le nom “dico.txt”. Je lance alors le décryptage via la commande (le fichier log-04 correspond à la génération du fichier log durant la quatrième itération de la commande précédente):
aircrack-ng dico.txt -w logW-04.cap
Ainsi, au bout d'un certain temps, on trouve la clé :
Transient Key : FC 1F 4E A6 BB 26 B5 3B 17 AD A3 EB 18 9A 0F 65
75 37 BA 34 EE D4 EC 1B B8 D8 7F 57 49 DA FF 15
12 E7 EB 20 6A 77 29 7D 1C 12 36 63 69 EE 43 F0
45 04 14 60 5F 2F A6 71 4E D3 49 69 98 7A 9A B9
EAPOL HMAC : F3 3A 44 13 3E 4D 5C E2 1C FA C2 91 98 91 29 38
