TP sysres IMA5sc 2020/2021 G9
| Groupe | Domaine | IP (publique) |
|---|---|---|
| Groupe 9 | calicedelamort.site | 193.48.57.180 |
Création de la VM
root@capbreton:~# xen-create-image --hostname=Calicedelamort --ip=100.64.0.20 --netmask=255.255.255.240 --password=pasglop --dir=/usr/local/xen --dist=buster --gateway=100.64.0.5
--- Logical volume --- LV Path /dev/storage/PaulTanguy1 LV Name PaulTanguy1 VG Name storage LV UUID Mk2sRM-HJvO-Ul2V-7z4A-WYDR-w2Rs-woO4FD LV Write Access read/write LV Creation host, time capbreton, 2020-10-12 17:02:07 +0100 LV Status available # open 0 LV Size 10.00 GiB Current LE 2560 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:24 --- Logical volume --- LV Path /dev/storage/PaulTanguy2 LV Name PaulTanguy2 VG Name storage LV UUID zWVz4u-2u2T-Fd1T-7W5X-G4Fg-M8dO-bEwuEt LV Write Access read/write LV Creation host, time capbreton, 2020-10-12 17:02:11 +0100 LV Status available # open 0 LV Size 10.00 GiB Current LE 2560 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:25
Services Internet
Serveur SSH
On installe simplement un serveur SSH sur la VM. On modifie le fichier /etc/ssh/sshd_config pour autoriser la connexion en tant que root. On peut s'y connecter à distance avec la commande suivante :
ssh root@ns1.calicedelamort.site
(avec le même mot de passe (pifou) que les machines de TPs)
Serveur DNS
Dans un premier temps, on loue un nom de domaine sur gandi.net. Notre nom de domaine est calicedelamort.site
Ensuite, on installe sur la VM, le paquetage bind9
Une fois ce paquetage installé, on modifie les fichiers de configuration.
Dans /etc/bind/db.calicedelamort.site
;BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.calicedelamort.site. postmaster.calicedelamort.site. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.calicedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1
ns1 IN A 193.48.57.180
Ensuite, dans /etc/bind/named.conf.local
zone "calicedelamort.site" IN {
type master;
file "/etc/bind/db.calicedelamort.site";
allow-transfer {217.70.177.40;};
};
Et enfin, dans /etc/bind/name.conf.options :
options {
directory "/var/cache/bind";
dnssec-enable yes;
dnssec-validation auto;
listen-on-v6 { any; };
allow-recursion { localhost; };
};
Pour finir, on se rend sur gandi.net et dans l'option Gluerecords on lie ns1.calicedelamort.site à l'adresse 193.48.57.180. Puis, on ajoute dans serveurs de noms externes :
ns1.calicedelamort.site ns6.gandi.net
Sécurisation de site web par certificat
La première étape est de générer un certificat à l'aide de la commande suivante :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout calicedelamort.site.key -out calicedelamort.site.csr
Ensuite, on se rend sur gandi.net, et nous ajoutons le certificat généré à notre domaine calicedelamort.site. Ensuite, nous attendons d'obtenir le certificat signé sur le serveur de mail que nous avons installé sur notre VM.
Sécurisation de serveur DNS par DNSSEC
En premier lieu, nous devons activer le protocole DNSSEC dans le fichier de configuration de bind : /etc/bind/named.conf.local
dnssec-enable yes
Ensuite, nous créons un dossier calicedelamort.site.dnssec/ puis nous y générons les clefs ZSK et KSK à l'aide des commandes suivantes :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE calicedelamort.site
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE calicedelamort.site
Puis, nous allons dans le fichier de configuration de notre site : /etc/bind/db.calicedelamort.site, et nous y ajoutons les deux lignes suivantes :
$include /etc/bind/calicedelamort.site.dnssec/calicedelamort.site-ksk.key $include /etc/bind/calicedelamort.site.dnssec/calicedelamort.site-zsk.key
Enfin, nous signons le tout à l'aide de la commande :
dnssec-signzone -o calicedelamort.site -k calicedelamort.site-ksk ../db.calicedelamort.site calicedelamort.site-zsk
Dans le fichier /etc/bind/named.conf.local, nous modifions la zone pour y mettre le fichier signé :
zone "calicedelamort.site" IN {
type master;
file "/etc/bind/db.calicedelamort.site.signed";
allow-transfer{217.70.177.40;};
};
Pour finir, nous relançons bind9 :
service bind9 restart
Tests d'intrusion
Cassage de clef WEP d'un point d'accés Wifi
En premier lieu, on installe le paquetage aircrack-ng sur un PC.
Ensuite, on utilise les commandes suivantes :
airmon-ng
Cette commande permet d'afficher les interfaces réseau
airmon-ng start <interface>
Pour passer l'interface en mode monitor
airodump-ng --encrypt wep 'nomInterface'
Pour afficher les réseaux wifi WEP
airodump-ng --write 'nomFichier' --channel 3 -bssid '@mac_AP' 'nomInterface'
Pour capturer les paquets émis par le point d'accés ciblé
aircrack-ng -x 'nomFichier'-01.cap
Pour cracker la clef WEP (à condition d'avoir capturé assez de paquets)
Cassage de mot de passe WPA-PSK par force brute
Pour cette partie, nous utilisons aussi le paquetage aircrack-ng.
On utilise les mêmes commandes que précédemment pour trouver les réseaux wifi utilisant WPA-PSK
airodump-ng --encrypt wpa-psk 'nomInterface'
airodump-ng --write 'nomFichier' --bssid '@mac_AP' -c 'numChannel' 'nomInterface'
Une fois que l'on obtient le handshake de point d'accés, on peut essayer de cracker la clef WPA-PSK à l'aide de la commande aircrack-ng
Cependant, il faut créer un dictionnaire de clef, dans le sujet, nous savons que la clef est composée de 8 chiffres, on crée donc un dictionnaire constitué de toutes les clef à 8 chiffres possible Pour cela, on utilisa la commande :
crunch 8 8 0123456789 > 'nomDuDico.txt'
Maintenant, on peut essayer de cracker la clef à l'aide du dictionnaire :
aircrack-ng -a 2 -w 'nomDuDico.txt' 'nomFichier'-01.cap
Au bout d'un certain temps, on obtient la clef WPA-PSK permettant de se connecter au point d'accés Wifi.
Il est aussi possible de cracker la clef avec hashcat. Cela permet de d'utiliser la puissance du GPU pour brute force la clef. Grace à ma super carte graphique la 2080 super, nous avons pu diviser par 100 le temps du brute force.
La commande est la suivante:
crunch 8 8 0123456789 | hashcat -m 2500 output.hccapx
Man In The Middle
(Homme du milieu en anglais)
D'abord, sur le eeePC, on modifie le fichier /proc/sys/net/ipv4/ip_forward :
echo 1 > /proc/sys/net/ipv4/ip_forward
Ensuite on utilise la commande du paquet dsniff :
arpspoof -i eth0 -t 172.26.145.254 172.26.145.58 arpspoof -i eth0 -t 172.26.145.58 172.26.145.254
Enfin, on utilise wireshark pour observer les paquets. Pour tester l'attaque MiTM, nous avons essayer de nous connecter à un site utilisant un protocole http.
Sur wireshark, nous avons pu voir, en clair, les identifiants de connexion ainsi que le mot de passe saisi par l'utilisateur.
Intrusion sur un serveur d'application Web
Pour cette partie, on se rend sur le lien http://honey.plil.info. Nous y trouvons une page de connexion demandant un login et un password.
N'ayant pas de compte sur ce site, on essaye une simple injection SQL : Dans les champs 'login' et 'password' on écrit l'injection SQL suivante : " ' OR 1 = 1 -- " Ca fonctionne ! Nous avons accès aux informations de connexion des utilisateurs
Grâce aux informations trouvées à l'aide de l'injection SQL nous pouvons nous connecter en tant qu'administrateur.
En explorant un peu le site, nous trouvons une fonctionnalité qui permet d'importer des fichiers sur la page web et de les télécharger.
En parallèle de cela, à l'aide de la commande
dirb http://honey.plil.info/
On trouve une page phpmyadmin : http://honey.plil.info/phpmyadmin
Encore une page de connexion, il faut donc trouver le login et le password permettant de se connecter à cette page. Cette fois, les injections SQL ne fonctionne pas.
Cependant, nous avons vu plus tôt que nous pouvions importer et télécharger des fichiers depuis la page web précédente, et en effectuant quelques tests, nous nous sommes rendu compte que ces fichiers provenaient du serveur qui hébergeait le site web.
En regardant sur internet, nous avons trouvé que le fichier contenant les logins et mot de passes de connexion à la page phpmyadmin se trouvaient dans /etc/phpmyadmin/config-db.php
Nous uploadons et téléchargeons ce fichier depuis la page web :
Nous avons maintenant accès à la page de gestion de la base de données du serveur.
Maintenant que l'on sait que l'on peut télécharger des fichiers depuis le serveur, on décide de télécharger le fichier /etc/passwd :
On trouve l'utilisateur 'rex' sur lequel on pourrait tenter de se connecter en ssh. Nous essayons, cependant, il nous faut le mot de passe de cet utilisateur. Explorons donc phpmyadmin en s'y connectant en tant que root.
En cherchant bien, on trouve un fichiers 'users' (dans la structure 'test') dans lequel apparait le mot de passe de l'utilisateur 'rex' en clair.
On se connecte donc en ssh sur cet utilisateur.
ssh rex@honey.plil.info
La dernière étape est donc de récupérer le mot de passe root du serveur. Or, on sait que celui-ci se trouve dans le fichier /etc/shadow , fichier qui est, bien entendu, accessible depuis l'utilisateur 'rex'.
Une fois ce fichier récupéré, il ne nous reste plus qu'à brute force le mot de passe root.
On utilise le programme 'John The Ripper', cependant, il nous faut un dictionnaire pour aider John The Riper. On sait que le mot de passe root à la même particularité que les mots de passes des machines de TPs. On crée donc un dictionnaire en fonction de cette information à l'aide de la commande 'crunch'.
On peut finalement lancer John The Riper avec le dictionnaire, on trouve le mot de passe, et on peut enfin se connecter en tant qu'utilisateur root sur le serveur.
Réalisation
Sécurisation de données
Nous avons dans un premier temps créé 3 partitions virtuelles:
lvcreate -L1G -n calicedelamort-raid1 storage lvcreate -L1G -n calicedelamort-raid2 storage lvcreate -L1G -n calicedelamort-raid3 storage
Ensuite, nous les avons ajoutées dans notre fichier: /etc/xen/Calicedelamort.cfg
disk = [
'file:/usr/local/xen/domains/Calicedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Calicedelamort/swap.img,xvda1,w',
'phy:/dev/storage/PaulTanguy1,xvda3,w',
'phy:/dev/storage/PaulTanguy2,xvda4,w',
'phy:/dev/storage/calicedelamort-raid1,xvda5,w',
'phy:/dev/storage/calicedelamort-raid2,xvda6,w',
'phy:/dev/storage/calicedelamort-raid3,xvda7,w',
]
il faut ensuite redémarrer notre VM:
xl destroy Calicedelamort xl create /etc/xen/Calicedelamort.cfg
Suite à cela nous installons mdadm qui est l'utilitaire standard sous Linux utilisé pour gérer les périphériques RAID logiciel:
apt instal mdadm
Ensuite, nous construisons notre volume RAID 5, et on s'assure qu'il fonctionne à chaque démarrage.
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7 mdadm --monitor --daemonise /dev/md0
On formate notre volume RAID.
mkfs.ext4 /dev/md0
On rajoute cette ligne dans le fstab :
/dev/md0 /raid5 ext4 defaults 0 2
Pour finir, on peuple notre volume RAID.
mkdir /raid5 mount -a touch /raid5/test
TP ASR
Ajout d'une seconde interface réseau sur la VM
On se connecte sur capbreton
ssh root@capbreton
Et on modifie le fichier de configuration de notre VM (Calicedelamort.cfg) en y ajoutant une deuxième interfaces dans la ligne 'vif'
nano /etc/xen/Calicedelamort.cfg vif = [ 'bridge=IMA5sc, ip=100.64.0.20, mac=00:16:3E:DC:81:A8', 'bridge=bridgeStudents, ip=192.168.42.9 ,mac=00:16:3E:DC:81:A9' ]
Ensuite, on relance la VM et on modifie le fichier dans /etc/network/interfaces pour y ajouter l'interface réseau eth1 avec la bonne adresse IP
auto eth1 iface eth1 inet static address 192.168.42.9 netmask 255.255.255.0
Pour finir on réalise une masquarade à l'aide de la commande iptables
iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to-source 193.48.57.180 -s 192.168.42.23
Ansible
Premièrement, on installe ansible sur notre VM sur capbreton
apt install ansible
Ensuite, on génère les clefs ssh avec la commande
ssh-keygen -t rsa
Puis, on installe la clef publique sur les Vms cibles
cat .ssh/id_rsa.pub | ssh root@192.168.42.9 "cat >> /root/.ssh/authorized_keys2" (installation sur notre VM chassiron)
On crée ensuite un inventaire : /etc/ansible/hosts
[Me_Chassiron] calicedelamort ansible_host=192.168.42.9 [All_Chassiron] calicedelamort ansible_host=192.168.42.9 truffe ansible_host=192.168.42.12 girolle ansible_host=192.168.42.7 amanite ansible_host=192.168.42.5 tricholome ansible_host=192.168.42.4 ophiocordyceps ansible_host=192.168.42.2
Une fois ces étapes réalisées, nous créons un premier rôle ansible qui va venir modifier le fichier /etc/motd de notre VM sur chassiron, ainsi qu'installer les paquetages NTP et copier les fichiers de configuration NTP de notre VM sur capbreton.
- name: Modification de /etc/motd
copy:
src: "../files/modif_motd"
dest: "/etc/motd"
owner: root
group: root
mode: '0644'
- name: Installation de ntp
apt:
name: ntp
state: latest
- name: Copie de ntp conf
copy:
src: "../files/ntp.conf"
dest: "/etc/ntp.conf"
owner: root
group: root
mode: '0644'
Docker
Avant d'installer docker sur notre VM, nous devons y installer python3, python3-pip, ainsi qu'un module docker de python. Pour cela, on crée un rôle ansible qui va réaliser cette installation.
- name: python install
apt:
update_cache: yes
name: "{ { packages } }"
vars:
packages:
- python3
- python3-pip
- name: docker pip install
pip:
name:
- docker
On peut maintenant installer Docker sur notre VM. Pour cela, on a récupéré un rôle ansible 'geerlingguy.docker'
Puis, on crée le playbook.yml suivant pour l'installation :
- hosts: Me_Chassiron
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 du conteneur
La première étape consiste en la création d'un Dockerfile :
FROM httpd:2.4 COPY index.html /usr/local/apache2/htdocs/ CMD [ "httpd", "-D", "FOREGROUND" ]
Ensuite, on construit l'image du Dockerfile, puis on le lance à l'aide des commandes suivantes :
docker build -t webserveur . docker run -d webserveur
On peut regarder si les commandes précédentes ont fonctionnées : Affichage des images docker :
docker images
Affichage des conteneurs en cours d'exécution :
docker ps -a
Puis, on utilise un rôle ansible pour créer un dépôt sur notre machine sur chassiron :
- name: Docker registry
docker_container:
name: registry
image: registry
ports:
- "5000:5000"
Une fois le dépôt créé, on peut push notre conteneur :
docker tag webserveur 192.168.42.9:5000/webserveur docker push 192.168.42.9:5000/webserveur
Pour finir, on se connecte sur notre VM chassiron et on pull :
docker pull 192.168.42.9:5000/webserveur
Configuration des serveurs internes
Pour déployer notre conteneur Web sur tous les serveurs Web internes, nous utilisons le rôle ansible suivant :
- name: container webserver
docker_container:
name: calicedelamort_container
image: 192.168.42.9:5000/webserveur_calicedelamort
ports:
- "8089:80"
Enfin, nous pouvons déployer ce conteneur en ajoutant à notre playbook.yml les commandes suivantes :
- hosts: All_Chassiron
roles:
- deploy_webserver
Equilibreur de charge
Nous ajoutons un deuxième site dans /etc/apache2/sites-available que nous appelons site2calicedelamort.conf :
<VirtualHost *:80>
ServerName reverse.calicedelamort.site
ServerAdmin paulLeCannard
ProxyPass / http://192.168.42.9:8089
ProxyPassReverse / http://192.168.42.9:8089
</VirtualHost>
Ensuite, nous modifions le fichier /etc/bind/db.calicedelamort.site pour y ajouter cette ligne :
reverse IN CNAME www
On installe les paquets manquants :
a2enmod proxy a2enmod proxy_http
On active notre 2ème site, puis on redémarre bind9 et apache2 :
a2ensite site2calicedelamort.conf service bind9 restart service apache2 restart
Notre deuxième site est maintenant accessible via reverse.calicedelamort.site, cependant il n'est disponible que sur notre VM chassiron (192.168.42.9)
Nous souhaitons maintenant le rendre accessible sur toutes les VM chassiron, nous utilisons donc un Load Balancer.
Dans un premier temps, on installe les paquetages nécessaires :
a2enmod proxy_balancer a2enmod lbmethod_byrequests
Puis, on modifie le fichier de configuration de notre site /etc/apache2/sites-available/site2calicedelamort.site, et on y ajoute un système d'équilibrage de charges :
<VirtualHost *:80>
ServerName reverse.calicedelamort.site
ServerAdmin paulLeCannard
<Proxy "balancer://macrondemission">
BalancerMember "http://192.168.42.2:8089" route=1
BalancerMember "http://192.168.42.4:8089" route=2
BalancerMember "http://192.168.42.5:8089" route=3
BalancerMember "http://192.168.42.7:8089" route=4
BalancerMember "http://192.168.42.9:8089" route=5
BalancerMember "http://192.168.42.12:8089" route=6
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://macrondemission/
ProxyPassReverse / balancer://macrondemission/
</VirtualHost>
On redémarre apache2.
Pour vérifier le bon fonctionnement du Load Balancer, nous avons chargé une page internet différente sur notre VM (192.168.42.9). Lorsque l'on se connecte sur notre site via un navigateur (http://reverse.calicedelamort.site), on voit bien que l'on obtient parfois la page du site 'classique' et d'autre fois la page du site propre à notre VM chassiron.
