TP sysres IMA2a5 2020/2021 G8 : Différence entre versions

Version actuelle datée du 1 décembre 2020 à 22:16

La description du projet et de son architecture matérielle générale (matérielle et hardware) se trouve sur la page de garde commune a tous les groupes de la promo IMA2A5 2020/21.

Sommaire

1 Architecture matérielle
- 1.1 Cartes de supervision
2 Configuration des Machines Virtuelles
- 2.1 Configuration de base
- 2.2 Ajout des partitions var et home
3 Services Internet
4 Tests d'intrusion
5 Réalisations

Architecture matérielle

Toute la classe a participé à la mise en place de l'architecture matérielle pour ce projet aux vues du nombre important de tâches à réaliser. Nous nous sommes donc séparé le travail en plusieurs sous-tâche sur lesquelles nous avons travaillé par binôme. J'ai personnellement travaillé en binôme avec Samuel sur la configuration des cartes de supervision, que je décris dans la partie qui suit.

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 des cartes 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 une connexion en SSH 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

J’installe le paquet apache2 sur ma machine virtuelle

Ainsi, depuis un navigateur, en tapant boeing.paletbreton.site, je peux accéder à ma page web.

Pour sécuriser mon site web par certificat, je vais utiliser une clef asymétrique et un certificat signé par Gandi. Gandi doit signé le CSR, qui est créé via la commande :

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

On renseigne les données permettant d’être vérifié par le CA comme le pays, la région, le nom d’organisation etc. et bien sûr le plus important le Common Name, qui correspond à mon nom de domaine (boeing.paletbreton.site).

Deux fichiers sont alors générés, un public .csr et une clé privée .key. Les deux fichiers sont les suivants :

    myserver.key

Fichier .key généré

    server.csr

Fichier .csr généré

Je déplace ces deux fichiers dans le /root de ma VM. Il est très important d’enregistrer le .key pour l’installation du certificat.

Puis, sur le site de gandi, j'achète un SSL extérieur, de type standard. Je lui précise ma clé CSR, si celle-ci est valide le nom du domaine (paletbreton.site) se remplit automatiquement. Le CA doit vérifier que j’ai l’autorisation du propriétaire du domaine pour pouvoir délivrer un certificat SSL pour ce domaine. Ainsi, il doit être sûr que je contrôle le domaine. Pour ça, je choisis comme méthode de confirmation l’envoi d’email. Ainsi, le CA envoie un mail à admin@paletbreton.com qui devra confirmer.

Pour configurer l’adresse mail de ma MV :

- J’installe le paquet post-fix sur ma machine (apt-get install postfix) - Dans l’outil de configuration de postfix, je choisis le type “site internet” et paletbreton.site comme nom de domaine. -Je me rends ensuite dans le dossier /etc/alliases et j’ajoute l’alias admin en root. -J’ajoute dans le fichier “/etc/bind/options" les lignes :

    allow-transfer { "allowed_to_transfer"; };’

Afin d’autoriser les transferts de la liste “allowed_to_transfer”. Cette liste est défini juste après :

    acl "allowed_to_transfer" {
       217.70.177.40/32;}

L’adresse 217.70.177.40/32 correspond au serveur secondaire de gandi ns6.gandi.net qui supporte les zones DNSSEC.

-J’ajoute également au fichier db.paletbreton.site la ligne “@ IN MX 100 boeing” afin de renseigner le serveur de messagerie;

-Dans /etc/aliases, j’ajoute la ligne “admin : root” afin de configurer l’adresse mail de la machine en tant que “admin@paletbreton.site”. Puis je sors du fichier et j’actualise avec la commande “newaliases”;

Ensuite, pour pouvoir consulter les mails de la VM, il faut un petit utilitaire appelé mailx (paquet à installer : bsd-mailx) :

Une fois l’adresse mail configurée, je tape la commande mailx pour afficher les mails reçus par la VM.

Mail reçu de gandi pour confirmation du SSL :

En suivant le lien de confirmation, j'entre le code de validation et après un cours instant, gandi valide mon SSL.

Je télécharge les deux certificats de mon SSL (paletbreton.site.crt et paletbreton.site.crt ) sur gandi et les transfert sur mon /root de ma VM afin de ne pas les perdre.

Je configure désormais apache2 pour gérer du HTTPS sur le port 443.

Tout d’abord, pour que le protocole TLS puisse fonctionner avec le Serveur HTTP Apache2, il faut activer le module ssl avec la commande :

    a2enmod ssl

Puis, j’active le site via :

    a2ensite default-ssl.conf

J’ai donc désormais :

Je modifie maintenant mon fichier default-ssl.conf, je précise les chemins d’accès à mon certificat, ma clé et mon .crt :

Modifications du fichier default-ssl.conf

Puis je reload le service apache2 :

Je modifie également mon fichier etcbind/db.paletbreton.site pour lui ajouter l’alias pour mon site en https :

Je peux désormais me connecter en HTTPS sur mon site.

Mon site en https

Sécurisation de serveur DNS par DNSSEC

Le DNS est vulnérable, notamment aux attaques par déni de service et par corruption des données. On parle "d'empoisonnement" du DNS. Depuis la faille Kaminsky de 2008, la solution de sécurité DNSSEC est mise en place la plupart du temps. DNSSEC consiste en la signature cryptographique des données distribuées par le DNS.

Je vais donc sécuriser mon serveur DNS par DNSSEC.

J'ajoute d'une part l'option dnssec-enable yes; dans le fichier named.conf.options.

Je créé ensuite un dossier paletbreton.site.dnssec dans mon /etc/bind pour y générer mes clés.

La clef asymétrique de signature de clefs de zone est créée via la commande :

    dnssec-keygen -r /dev/urandom -a RSASHA1 -b 2048 -f KSK -n ZONE paletbreton.site

La clé asymétrique de la zone pour signer les enregistrements est quant à elle générée via :

    dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE liosaw.site

Je renomme ensuite mes deux clés comme suit :

    paletbreton.site-ksk.key
    paletbreton.site-ksk.private
    paletbreton.site-zsk.key
    paletbreton.site-zsk.private

Attention à bien renommer les clés avec le bon suffixe, sinon Gandi (notre registrar) pensera que les clés ne correspondent pas.

J'inclue ensuite mes clés publiques dans mon fichier db.paletbreton.site

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

Je n'oublie pas d'incrémenter le numéro de version de la zone.

Je signe ensuite les enregistrements de la zone via la commande :

    dnssec-signzone -o paletbreton.site -k paletbreton.site ../paletbreton.site paletbreton.site-zsk

Je modifie enfin mon fichier named.conf.local pour utiliser la zone signée en y ajoutant :

    file "/etc/bind/db.paletbreton.site.signed";

Je peux finalement communiquer ma clé KSK publique a Gandi et tester la configuration de mon DNS sur le site dnsviz.net :

Résultats de l'analyse sur dnsviz.net

Note : L’erreur restante sur la photo précédente vient du fait que notre IPV6 ne marchait pas à ce moment alors que j'avais intégrer mon adresse sous ce format dans mon db.paletbreton.site, sinon tout semble correct.

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 :

Trames WIFI

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

Attaque de type "homme au milieu" par usurpation ARP

J’installe le paquet dnsiff sur ma zabeth et la transforme en router en mettant la variable noyau à 1 dans le fichier ip_forward:

Je choisi d’aller espionner la zabeth06 dont l’adresse ip est 172.26.145.254 en lançant la commande :

       arpspoof -i bridge -t zabeth06 172.26.145.254

Ainsi, j’envoie des réponses ARP en continue à la zabeth06 pour me faire passer pour le routeur.

Je peux ouvrir un sniffeur réseau à côté tel que wireshark pour espionner la zabeth06.

On peut voir que la zabeth06 se connectait à un site web HTTP.

Réalisations

Sécurisation de données

Je vais créer trois partitions raid1 raid2 et raid3 sur capbreton :

Je fais la commande mke2fs sur les trois partitions pour créer le système de fichiers ext2 sur chacune d'entre elles.

Je modifie ensuite le fichier boeing.cfg pour intégrer les nouvelles partitions.

Je redémarre ma machine pour que les modifications soient prise en compte :

    xl shutdown boeing
    xl creae /etc/xen/boeing

La commande fdisk -l nous montre que les partitions sont bien liées à ma VM.

J'installe ensuite le paquet mdadm sur ma machine permettant de mettre en place un système RAID5, afin d'améliorer les performances et de sécuriser mes données.

Je lance ainsi la commande :

    mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 dev /xvdc3 
    mkfs /dev/md0
    mount /dev/md0 /mnt
    cat /proc/mdstat

Le RAID5 est alors créé et monté avec le système de fichiers ext2.

Je créé le dossier RAID5 à la racione de ma machine afin que le raid soit toujours monté à cet emplacement.

Je modifie ensuite le fichier fstab pour que le RAID soit monté à chaque fois.

Je stocke ensuite des données dans mon RAID5. J'y copie par exemple mon dossier bind :

    cp -r /etc/bind raid5

On voit que le dossier bind se retrouve bien dans le RAID5.

Je passe ensuite sur Capbreton et j'éteins ma machine pour réaliser un test.

J'enlève une des partitions que j'ai créée, le raid2, dans le fichier boeing.cfg en commentant la ligne qui lui correspond.

Je redémarre ensuite ma machine.

Mon raid a été renommé /dev/mod127 et mes partitions ne sont apparemment pas actives.

Il faut donc les réactiver en lançant la commande suivante :

    mdadm --manage /dev/md127 --run

On peut ensuite remonter mon raid via la commande

    root@boeing:/# mount /dev/md127 /mnt

Et on remarque que, bien qu’ayant enlevé l’une des trois partitions de mon RAID5, les données qu’il y avait de stocker dessus sont toujours présentes :

Ainsi, la sécurisation des données est désormais effective. L'objectif de cette partie est atteint.

Sur capbreton, je recoupe ma machine, décommente la ligne que j’ai commenté précédemment et redémarre ma machine

On voit que mes partitions 3 partitions et mon raid5 sont présents.

En remontant le md127, on retrouve bien nos données :

Chiffrement de données

Je branche la clé USB que je vais chiffrer sur mon PC. J’installe les paquets lvm2 et cryptsetup sur mon PC. Je fais un lsblk pour repérer ma clé usb :

On voit que ma clé est le sdb (environ 8G. J’utilise fdisk pour accéder aux partitions de la clé :

Je nettoie la clé en supprimant les partitions déjà présentes dessus :

Je créé ensuite une nouvelle partition unique sur la clé :

Je sauvegarde ensuite mes modifications :

Je peux désormais lancer le cryptage de la clé grâce à cryptsetup. J’ai le choix entre deux types de cryptages : Plain ou Luks. Comme le conseille l’aide de cryptsetup, je vais plutôt m’orienter vers le type Luks.

Je lance donc la commande cryptsetup suivante pour initialiser le chiffrement de la partition au format LUKS :

Le passphrase, ou mot de passe, est glopglop. J’ouvre ensuite ma partition LUKS et la nomme cle_cryptee_nath :

Je créé ensuite un système de fichier sur la partition (ext2).

Je créé ensuite un dossier /cle_cryptee_nath dans mon /mnt et je monte ma partition via la commande :

    mount -t ext2 /dev/mapper/cle_cryptee_nath  /mnt/cle_cryptee_nath

Je peux désormais copier des fichiers sur ma clé via le dossier mnt/cle_cryptee/nath.

Je copie le dossier Documents de ma zabeth sur ma clé par exemple.

Avant de débrancher ma clé, il faut démonter le montage du système de fichier et fermer ma partition chiffrée :

    umount /mnt/cle_cryptee_nath
    cryptsetup luksClose cle_cryptee_nath

Je débranche ma clé et la rebranche sur un autre PC. Je vois que désormais pour accéder à ses fichiers il faut que j’entre mon mot de passe (glopglop):

Sécurisation WIFI par WPA2-EAP

L’objectif de cette partie est de contrôler l’accès à la borne WIFI par WPA2-EAP (WIFI Protected Access) en créant dans un premier temps des comptes sur le serveur FreeRadius.

Je commence par installer le paquet correspondant :

    apt-get update
    apt-get install freeradius

J’ajoute ensuite un utilisateur dans le fichier de users :

Je configure ensuite le serveur en peap comme demandé en changeant le type par défaut dans le fichier de configuraiton eap :

    default_eap_type = peap

Je précise également le port d’écoute du serveur dans le fichier etc/freeradius/3.0/sites-enabled/default

    port = 1812

Je restart ensuite freeradius (attention à tuer toutes ses instances auparavant car freeradius ne le fait pas de lui-même).

Je teste ensuite ma configuration en lançant la commande :

    freeradius -CX

Je fais ensuite un test d’authentification avec l’utilisateur créé un peu plus tôt :

    radtest nathan glopglop 127.0.0.1 1812 testing123

testing123 est le mot de passe par défaut indiqué dans le fichier clients.conf et l’adresse 127.0.0.1 correspond au localhost pour les tests.

Le résultat de la commande est le suivant :

On voit que mon test d’authentification est bien passé.