TP sysres IMA5sc 2020/2021 G4 : Différence entre versions
(→Sécuritsation de serveur DNS par DNSSEC) |
|||
(75 révisions intermédiaires par 2 utilisateurs non affichées) | |||
Ligne 3 : | Ligne 3 : | ||
=Présentation générale= | =Présentation générale= | ||
+ | '''https://www.tricholome.site/''' | ||
− | Ceci est le wiki du tp de PRA de 2020 réalisé par Samuel BENAYED et Théo EVRARD. | + | Ceci est le wiki du tp de PRA de 2020 réalisé par Samuel BENAYED et Théo EVRARD. Au cours de ce TP, de nombreux "exercices" ont pu être réalisés : |
+ | * Installation de machine virtuelles sur un serveur (Capbreton) | ||
+ | * Mise ne place d'une architecture réseau redondante reliée à Internet (en partenariat avec les groupes 1 et 14) | ||
+ | * Connexion de notre VM à ce réseau | ||
+ | * Cassage de clé WIFI (WEP et WPA) | ||
+ | * Intrusion au sein d'un service web | ||
+ | * Chiffrement d'une clé USB | ||
− | + | L'ensemble de ces exercices nous a permis de mettre en application mais surtout d'approfondir nos connaissances en systèmes et réseaux. Nous tenons à remercier tout particulièrement nos professeurs pour l'aide non négligeable qu'ils nous ont apportée durant les heures de TP ainsi que Guillaume Rouillé pour son implication lors de la mise en place de l'architecture réseau. | |
− | |||
− | |||
=Installation de la machine virtuelle= | =Installation de la machine virtuelle= | ||
Ligne 14 : | Ligne 19 : | ||
Nous avons installé la VM sur capbreton.plil.info avec la commande suivante : | Nous avons installé la VM sur capbreton.plil.info avec la commande suivante : | ||
− | root@capbreton:~# xen-create-image --hostname=tricholome --ip=100.64.0.18 --netmask=255.255.255.0 --password=pasglop --dir=/usr/local/xen --dist=buster --gateway=100.64.0.5 --force | + | root@capbreton:~# xen-create-image --hostname=tricholome --ip=100.64.0.18 --netmask=255.255.255.0 --password=pasglop --dir=/usr/local/xen --dist=buster --gateway=100.64.0.5 --force |
Ligne 26 : | Ligne 31 : | ||
IP Address(es) : 100.64.0.18 | IP Address(es) : 100.64.0.18 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Root Password : pasglop | Root Password : pasglop | ||
Ligne 74 : | Ligne 71 : | ||
- currently set to 256 | - currently set to 256 | ||
Block device 254:12 | Block device 254:12 | ||
+ | |||
+ | =Mise en réseau de la VM= | ||
+ | |||
+ | On cherche à donner un accès internet à Tricholome, une attention toute particulière est portée à la redondance au sein du réseau. On a donc l'architecture suivante : | ||
+ | |||
+ | [[Fichier:Global_scheme_PRA_2020.png|400px|center|Schéma de câblage]] | ||
− | + | On a donc 2 routeurs (9200 et 6509-E) qui relient le serveur Capbreton au routeur de l'école et ainsi sortir sur internet. | |
==Paramétrage de l'OSPF== | ==Paramétrage de l'OSPF== | ||
+ | Nos routeurs seuls ne nous mèneront pas bien loin, il est nécessaire, pour pouvoir communiquer avec l'extérieur, que ceux-ci disposent des tables de routage des routeurs voisins (notamment celui de l'école) afin de pouvoir orienter correctement nos paquets. Ce protocole de routage porte le nom de OSPF (Open Shortest Path Link) et doit donc être configuré correctement au sein de nos deux routeurs : | ||
+ | '''En minicom sur nos routeurs :''' | ||
+ | |||
+ | ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur | ||
+ | router ospf 1 # un numéro de processus | ||
+ | router-id 10.60.0.10X # un id pour le routeur (X = 1 pour 6509-E et X = 2 pour 9200) | ||
+ | log-adjacency-changes | ||
+ | summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333) | ||
+ | summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé) | ||
+ | summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?) | ||
+ | redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés | ||
+ | redistribute static subnets | ||
+ | network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé) | ||
+ | |||
+ | Les nouvelles routes ainsi obtenues sont visibles via la commande : ''show ip route''. La réussite de la manipulation est validée par un ping fonctionnel d'une VM vers 193.48.57.48 qui est l'adresse du routeur de l'école | ||
==Paramétrage du NAT== | ==Paramétrage du NAT== | ||
+ | =Service Internet= | ||
+ | |||
+ | ==Serveur SSH== | ||
+ | |||
+ | Autorisation de la connexion SSH en root dans le fichier '''/etc/ssh/sshd_config''' | ||
+ | PermitRootLogin yes | ||
+ | |||
+ | Connexion possible grâce à la commande : '''ssh root@193.48.57.185''' | ||
+ | |||
+ | ==Serveur DNS== | ||
+ | |||
+ | Installation de bind9 : | ||
+ | apt install bind9 dnsutils | ||
+ | |||
+ | Modification du fichier /etc/resolv.conf (indique le serveur DNS à utiliser) : | ||
+ | nameserver 127.0.0.1 | ||
+ | |||
+ | Modification de /etc/bind/named.conf.local | ||
+ | |||
+ | zone "tricholome.site" IN { | ||
+ | type master; | ||
+ | file "/etc/bind/db.tricholome.site.signed"; | ||
+ | allow-transfer { 217.70.177.40; }; | ||
+ | }; | ||
+ | |||
+ | Configuration du DNS sur gandi.net : | ||
+ | *Ajout de deux External nameservers | ||
+ | ns1.tricholome.site | ||
+ | ns6.gandi.net | ||
+ | |||
+ | *Ajout de ns1.tricholome.site : 193.48.57.185 dans Glue records | ||
+ | |||
+ | ==Sécurisation de site web par certificat== | ||
+ | |||
+ | Notre certificat sera validé et envoyé par mail, on installe donc un serveur de mail : | ||
+ | |||
+ | apt install postfix | ||
+ | |||
+ | On configure postfix et on crée un alias dans /etc/aliases : | ||
+ | |||
+ | admin: root | ||
+ | |||
+ | Pour la génération de la clés et du certificat utilise openssl : | ||
+ | |||
+ | openssl req -nodes -newkey rsa:2048 -sha256 -keyout tricholome.site.key -out tricholome.site.csr | ||
+ | |||
+ | On transmet ensuite le certificat à gandi pour qu'il soit signé. On reçoit plus tard le certificat signé par mail. | ||
+ | |||
+ | '''Site web''' | ||
+ | |||
+ | Notre site est hébergé sur un serveur apache2 (apt install apache2). Pour la sécurisation du site par certificat on active le module SSL d'apache2 : | ||
+ | a2enmod ssl | ||
+ | |||
+ | On configure notre site 000-tricholome.site-ssl.conf : | ||
+ | |||
+ | <VirtualHost *:80> | ||
+ | ServerName tricholome.site | ||
+ | ServerAlias www.tricholome.site | ||
+ | # Redirection 301 vers le site en HTTPS | ||
+ | Redirect permanent / https://www.tricholome.site/ | ||
+ | </VirtualHost> | ||
+ | |||
+ | <VirtualHost *:443> | ||
+ | ServerName tricholome.site | ||
+ | ServerAlias www.tricholome.site | ||
+ | ServerAdmin webmaster@localhost | ||
+ | DocumentRoot /var/www/tricholome.site/ | ||
+ | CustomLog /var/log/apache2/access.tricholome.site.log combined | ||
+ | ErrorLog /var/log/apache2/error.tricholome.site.log | ||
+ | SSLEngine on | ||
+ | SSLCertificateFile /etc/ssl/cert/tricholome.site.crt | ||
+ | SSLCertificateKeyFile /etc/ssl/private/tricholome.site.key | ||
+ | SSLCACertificateFile /etc/ssl/certs/GandiStandardSSLCA2.pem | ||
+ | SSLVerifyClient None | ||
+ | </VirtualHost> | ||
+ | |||
+ | On active ensuite notre site : | ||
+ | a2ensite 000-tricholome.site-ssl | ||
+ | |||
+ | ==Sécuritsation de serveur DNS par DNSSEC== | ||
+ | Ajout de l'option dans /etc/bind/named.conf.options : | ||
+ | dnssec-enable yes | ||
+ | |||
+ | Création d'un répertoire tricholome.dnssec puis génération des clefs (KSK et ZSK) au sein de ce répertoire via les commande : | ||
+ | |||
+ | dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE tricholome.site | ||
+ | |||
+ | dnssec-keygen -a RSASHA1 -b 1024 -n ZONE tricholome.site | ||
+ | |||
+ | On renome ces paires de clefs pour plus de lisibilité puis ajoute les lignes suivante dans /etc/bind/db.tricholome.site (en incrémentant le serial) | ||
+ | |||
+ | $include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key | ||
+ | $include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key | ||
+ | |||
+ | On signe ensuite la zone via la commande : | ||
+ | dnssec-signzone -o tricholome.site -k tricholome.site-ksk ../db.tricholome.site tricholome.site-zsk | ||
+ | |||
+ | On obtient alors le fichier de zone suivant : '''db.tricholome.site.signed''' | ||
+ | |||
+ | On instancie alors ce fichier dans notre /etc/bind/name.conf.local puis on transmet la clef KSK à gandi.net. | ||
=Pentesting= | =Pentesting= | ||
− | Intrusion sur un serveur d’application Web | + | ==Exploitation de failles du système== |
+ | |||
+ | En parallèle des TPs, nous avons réalisé des challenges sur la plateforme Root-me.org afin d'affiner nos compétences | ||
+ | *https://www.root-me.org/totor62 | ||
+ | *https://www.root-me.org/Gamjy | ||
+ | |||
+ | ==Cassage clé WEP== | ||
+ | |||
+ | Les clés WEP utilisent l'algorithme de chiffrement RC4 qui crypte les messages via des vecteurs d'initialisation sur 24 bits. De cette manière en récupérant suffisamment de paquets échangés entre une machine et l'AP on peut récupérer plusieurs paquets chiffrés avec le même vecteur d'initialisation. | ||
+ | |||
+ | Dès lors on peut craquer le code assez facilement en se basant sur des attaques statistiques par exemple. | ||
+ | |||
+ | On démarre l'interface réseau en mode moniteur | ||
+ | |||
+ | airmon-ng start [interface réseau] | ||
+ | |||
+ | On affiche les réseaux disponibles en WEP | ||
+ | |||
+ | airodump-ng --encrypt wep [NomInterface] | ||
+ | |||
+ | On capture les paquets émis par l'AP (il en faut environ 50.000 pour avoir une bonne chance de le craquer, cela devrait offrir suffisamment de collisions) | ||
+ | |||
+ | airodump-ng --write output --channel [channel] -bssid [Adresse MAC AP] [NomInterface] | ||
+ | |||
+ | On casse le code avec | ||
+ | |||
+ | aircrack-ng -x output.cap | ||
+ | |||
+ | ==Cassage clé WPA2== | ||
+ | |||
+ | Pour casser la clé WPA on utilise les commandes suivantes : | ||
+ | |||
+ | airmon-ng start [carte réseau] | ||
+ | |||
+ | On cherche ensuite à scanner l'environnement pour détecter les connexions possibles et leurs BSSID, ESSID ainsi que le canal utilisé : | ||
+ | |||
+ | airodump-ng [carte réseau] | ||
+ | |||
+ | Le crack d'une clé WPA nécessite un handshake entre l'AP et une machine. On récupère donc le handshake avec la commande : | ||
+ | |||
+ | airodump-ng -c[canal] -bssid [Adresse MAC de l'AP] -w output [carte réseau] | ||
+ | |||
+ | Après maximum une quinzaine de minutes on récupère le handshake. | ||
+ | |||
+ | A partir de là il suffit de réaliser une attaque par dictionnaire, nous savions que le code comporte 8 caractères numériques : | ||
+ | |||
+ | crunch 8 8 0123456789 -o dico.txt | ||
+ | |||
+ | Et pour lancer le bruteforce : | ||
+ | |||
+ | aircrack-ng -w dico.txt -b [Adresse MAC de l'AP] output*.cap | ||
+ | |||
+ | La clé est donc 20122222 pour la kracotte04, le bruteforce a duré 43min sur un intel core i5 8265U. | ||
+ | |||
+ | ==Attaque de l'homme du milieu== | ||
+ | |||
+ | L'attaque consiste à usurper l'identité d'une machine par rapport au routeur pour récupérer toutes les données qui transitent entre le routeur et la machine victime. | ||
+ | |||
+ | Pour réaliser cette attaque on utilise les commandes suivantes : | ||
+ | |||
+ | arp -a | ||
+ | |||
+ | Cela nous permet de récupérer les adresses ip du routeur et de la machine. | ||
+ | |||
+ | arpspoof -i eth0 -t <ip routeur> <ip machine> | ||
+ | arpspoof -i eth0 -t <ip machine> <ip routeur> | ||
+ | |||
+ | De cette manière on s'immisce entre les deux équipements en remplissant les tables ARP de mauvaises informations et on récupère le trafic. | ||
+ | |||
+ | Afin de rediriger le trafic on utilise : | ||
+ | |||
+ | echo 1 > /proc/sys/net/ipv4/ip_forward | ||
+ | |||
+ | Une fois que toutes ces commandes ont été lancées on attend que la machine victime se connecte à un site http afin de voir le trafic circuler en clair. | ||
+ | |||
+ | [[Fichier:wireshark_grp5.jpg|thumb|center||alt=texte alternatif|400px|Capture Wireshark]] | ||
+ | |||
+ | On récupère ainsi des informations sensibles de la victime. | ||
+ | |||
+ | Cette attaque ne fonctionne pas si la victime utilise des sites sécurisés avec HTTPS car le protocole HTTPS utilise de la cryptographie asymétrique et les clés privées ne transitent donc pas sur le réseau. | ||
+ | |||
+ | ==Intrusion sur un serveur d’application Web== | ||
+ | |||
+ | Le fichier explicatif est chiffré et disponible ci dessous. | ||
+ | |||
+ | Pour le déchiffrer il faut lancer les commandes suivantes : | ||
+ | |||
+ | wget https://wiki-ima.plil.fr/mediawiki//images/0/09/Intrusion.txt | ||
+ | gpg --decrypt Intrusion.txt | ||
+ | spécifier le mot de passe root@honey.plil.info | ||
+ | |||
+ | =Réalisation= | ||
+ | |||
+ | ==Sécurisation de données== | ||
+ | |||
+ | Création des trois partitions 3 sur capbreton : | ||
+ | |||
+ | lvcreate -L1G -n tricholome.raid1 storage | ||
+ | lvcreate -L1G -n tricholome.raid2 storage | ||
+ | lvcreate -L1G -n tricholome.raid3 storage | ||
+ | |||
+ | Ajout dans /etc/xen/tricholome.cfg : | ||
+ | 'phy:/dev/storage/tricholome.raid1,xvda5,w', | ||
+ | 'phy:/dev/storage/tricholome.raid2,xvda6,w', | ||
+ | 'phy:/dev/storage/tricholome.raid3,xvda7,w' | ||
+ | |||
+ | Reboot de la VM : | ||
+ | xl shut tricholome | ||
+ | xl create -c /etc/xen/tricholome.cfg | ||
+ | |||
+ | Sur tricholome, installation de mdadm. | ||
+ | apt instal mdadm | ||
+ | |||
+ | Construction et formatage du volume RAID 5. | ||
+ | mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7 | ||
+ | mdadm --monitor --daemonise /dev/md0 | ||
+ | mkfs.ext4 /dev/md0 | ||
+ | |||
+ | Ajout de ce volume dans le fstab : | ||
+ | /dev/md0 /raid5 ext4 defaults 0 2 | ||
+ | |||
+ | Raid 5 nous permet de reconstruire d'un disque supprimé à partir de 2 autres disques. Il nous faut au minimum 3 disques. On peut donc supprimer une partition et toujours avoir accès à nos fichiers. On peut noter que pour 3 volumes alloués à Raid5, 1 ne sera pas "réellement utilisable". | ||
+ | |||
+ | ==Chiffrement de données== | ||
+ | |||
+ | On cherche à chiffrer une clef USB. | ||
+ | |||
+ | fdisk -l # on repère la clé USB | ||
+ | fdisk /dev/sdb # on formate la clé en une seule partition | ||
+ | |||
+ | Installation de cryptsetup et lvm : apt install cryptsetup lvm2 | ||
+ | cryptsetup luksFormat /dev/sdb1 # chiffrement de la partition de la clé USB | ||
+ | cryptsetup luksOpen /dev/sdb1 myusbkey # déchiffrement de la partition | ||
+ | |||
+ | On monte la clé USB, on la peuple : | ||
+ | |||
+ | mkdir /mnt/USB | ||
+ | mount -t ext4 /dev/mapper/myusbkey /mnt/USB | ||
+ | touch /mnt/USB/sameo.txt | ||
+ | |||
+ | Puis on démonte le système de fichier proprement : | ||
+ | |||
+ | umount /mnt/USB | ||
+ | cryptsetup luksClose myusbkey | ||
+ | |||
+ | Pour que quelqu'un puisse accéder à notre clef, il doit maintenant renseigné le mot de passe. | ||
+ | |||
+ | ==Inspection ARP par un élément réseau== | ||
+ | |||
+ | Nous avons à notre disposition un Cisco ASA-5506-X qui permet de monitorer le réseau et éviter notamment les attaques de type man in the middle (l'homme du milieu). Nous avions donc pour objectif de brancher l'appareil sur le réseau et d'y connecter deux machines de façon à pouvoir recréer une attaque ARP spoofing. Nous avons rencontré un problème lors de la mise en place de ce dispositif : le Cisco ASA-5506-X n'a pas la fonctionnalité commutateur contrairement au Cisco ASA-5505. | ||
+ | |||
+ | Nous n'avons donc pas pu réaliser cette partie. | ||
+ | |||
+ | ==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. | ||
+ | |||
+ | Ajout d'une seconde interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50 | ||
+ | |||
+ | 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 VM capbreton on configure notre fichier /etc/network/interfaces : | ||
+ | |||
+ | # The secondary network interface | ||
+ | auto eth1 | ||
+ | iface eth1 inet static | ||
+ | address 192.168.42.18 | ||
+ | netmask 255.255.255.0 | ||
+ | |||
+ | Mise en place d'une mascarade avec les commandes suivantes : | ||
+ | iptables -P FORWARD DROP | ||
+ | iptables -A FORWARD -j ACCEPT -s 192.168.45.4/24 | ||
+ | iptables -A FORWARD -j ACCEPT -d 192.168.45.4/24 | ||
+ | iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.4/24 --to-source 193.48.57.185 | ||
+ | Permet à nos paquets en provenance de 192.168.45.4 (VM chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton. | ||
+ | |||
+ | |||
+ | Sur VM chassiron on configure 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.18 | ||
+ | |||
+ | |||
+ | '''Clés SSH''' | ||
+ | |||
+ | Génération d’une paire de clef asymétrique : | ||
+ | ssh-keygen -t rsa | ||
+ | |||
+ | Transmission de la clefs publique aux autres machines de chassiron : | ||
+ | cat .ssh/id_rsa.pub | ssh 192.168.42.x "cat >> /root/.ssh/authorized_keys2" | ||
+ | |||
+ | On peut maintenant se connecter en ssh sans authentification sur les autres machines de notre groupe. | ||
+ | |||
+ | |||
+ | '''Installation d'Ansible''' | ||
+ | |||
+ | Installation via la commande : | ||
+ | apt install ansible | ||
+ | |||
+ | Création d'un 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 | ||
+ | |||
+ | On a donc deux ensemble, un contenant notre machine seule, l'autre contenant toutes les vm de chassiron. On pourra appeler ces ensembles dans nos playbook ansible. | ||
+ | |||
+ | |||
+ | |||
+ | == Installation de docker == | ||
+ | |||
+ | Installation de docker, prérequis : python3 et python3-pip installé via le role basic | ||
+ | |||
+ | - name: Install packages | ||
+ | apt: | ||
+ | pkg: | ||
+ | - python3 | ||
+ | - python3-pip | ||
+ | - ntp | ||
+ | - curl | ||
+ | |||
+ | - name : NTP_configuration | ||
+ | copy: | ||
+ | src: /etc/ntp.conf | ||
+ | dest: /etc/ntp.conf | ||
+ | |||
+ | |||
+ | |||
+ | Utilisation du rôle geerlingguy.docker pour l'installation de docker : | ||
+ | |||
+ | On obtient donc le playbook suivant : | ||
+ | |||
+ | - 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 d'un conteneur == | ||
+ | |||
+ | On crée notre conteneur à l'aide d'un dockerfile situé dans /root/Dockerfile | ||
+ | |||
+ | FROM httpd:lattest | ||
+ | MAINTAINER Sameo | ||
+ | COPY .index.html /usr/local/apache2/htdocs/ | ||
+ | CMD ["httpd", "-D", "FOREGROUND"] | ||
+ | |||
+ | Création de l'image (dans le même dossier que notre dockerfile) : | ||
+ | docker build -t tricholome | ||
+ | |||
+ | Test de lancement de nore image : | ||
+ | docker run -d -p "8085:80" --name tricholome tricholome | ||
+ | |||
+ | Commande de vérification : | ||
+ | docker images (Affichage des différentes images docker installées) | ||
+ | docker ps -a (Affichage des différents containeurs en cours d'exécution) | ||
+ | |||
+ | |||
+ | Création d'un rôle ansible pour créer un registry sur notre VM chassiron : | ||
+ | - name: Setup registry | ||
+ | docker_container: | ||
+ | name: registry | ||
+ | image: registry | ||
+ | ports: | ||
+ | - "5000:5000" | ||
+ | |||
+ | On appel ce rôle dans ansible puis on peut push-pull de notre image dans notre registry sur Chassiron : | ||
+ | docker tag tricholome 192.168.42.5:5000/tricholome | ||
+ | docker push 192.168.42.4.:5000/tricholome | ||
+ | |||
+ | Puis coté chassiron : | ||
+ | docker pull 192.168.42.4:5000/tricholome | ||
+ | |||
+ | == Déploiement de notre image == | ||
+ | |||
+ | On crée un rôle qui permet de déployer notre image sur une machine : | ||
+ | |||
+ | - name: Create a container | ||
+ | docker_container: | ||
+ | name: amanite_container | ||
+ | image: 192.168.42.4:5000/tricholome | ||
+ | ports: | ||
+ | - "8084:80" | ||
+ | |||
+ | Via le playbook ansible on déploie notre image sur les machines de chassiron : | ||
+ | |||
+ | - hosts: webservers | ||
+ | roles: | ||
+ | - new_container | ||
+ | |||
+ | == Equilibreur de charge == | ||
+ | |||
+ | Configuration des modules nécessaires : | ||
+ | |||
+ | a2enmod proxy | ||
+ | a2enmod proxy_http | ||
+ | a2enmod proxy_balancer | ||
+ | a2enmod lbmethod_byrequests | ||
+ | |||
+ | Modification de notre zone dans /etc/bind/db.tricholome.site : | ||
+ | reverse IN CNAME www | ||
+ | (+ incrémentation du numéro de version, signature de la zone pour DNSSEC et redémarrage de bind9). | ||
+ | |||
+ | Ajout d'un nouveau site dans /etc/apache2/site-available que nous nommons reverse.conf : | ||
+ | <VirtualHost *:80> | ||
+ | ServerName bis.tricholome.site | ||
+ | ServerAdmin Sameo | ||
+ | ProxyPass / http://192.168.42.4:8084 | ||
+ | ProxyPassReverse / http://192.168.42.4:8084 | ||
+ | </VirtualHost> | ||
+ | |||
+ | On rend notre site enable : | ||
+ | a2ensite reverse.conf | ||
+ | service apache2 restart | ||
+ | |||
+ | Site désormais accessible via l'URL bis.tricholome.site | ||
+ | |||
+ | Ajout de l'équilibreur de charge : (dans /etc/apache2/site-availables/reverse.conf) | ||
+ | <VirtualHost *:80> | ||
+ | ServerName bis.tricholome.site | ||
+ | ServerAdmin Sameo | ||
+ | <Proxy "balancer://myset"> | ||
+ | BalancerMember "http://192.168.42.2:8084" route=1 | ||
+ | BalancerMember "http://192.168.42.4:8084" route=2 | ||
+ | BalancerMember "http://192.168.42.5:8084" route=3 | ||
+ | BalancerMember "http://192.168.42.7:8084" route=4 | ||
+ | BalancerMember "http://192.168.42.9:8084" route=5 | ||
+ | BalancerMember "http://192.168.42.12:8084" route=6 | ||
+ | ProxySet lbmethod=byrequests | ||
+ | </Proxy> | ||
+ | ProxyPass / balancer://myset/ | ||
+ | ProxyPassReverse / balancer://myset/ | ||
+ | </VirtualHost> | ||
+ | |||
+ | =Bonus= | ||
+ | |||
+ | ==Participation au challenge Brigitte Friang (DGSE)== | ||
+ | |||
+ | Participation en équipe à un challenge de cybersécurité organisé par la DGSE : https://www.defense.gouv.fr/dgse/tout-le-site/operation-brigitte-friang-prets-pour-relever-le-defi | ||
+ | |||
+ | ===Inscription au challenge :=== | ||
+ | *1- Connexion à https://www.challengecybersec.fr : | ||
+ | L'observation du code source de la page nous amène à une nouvelle adresse https://www.challengecybersec.fr/static/message-secret.html contenant un texte et 5 caractères en gras | ||
+ | |||
+ | |||
+ | [[Fichier:Secret.png|400px]] | ||
+ | |||
+ | |||
+ | *2- Dechiffrement de secret.html : | ||
+ | Il s'agit d'un texte chiffré avec un décalage ASCII de 7. Après déchiffrement on obtient un paragraphe nous expliquant qui était Brigitte Friang. L'observation des 5 caractères en gras nous donne '''/chat'''. On se connecte donc à https://www.challengecybersec.fr/chat. On arrive alors sur un portail avec différentes missions à accomplir | ||
+ | |||
+ | |||
+ | [[Fichier:Chat.png|400px]] | ||
+ | |||
+ | |||
+ | *3- Cryptographie par Antoine Rossignol : | ||
+ | On récupère plusieurs fichiers appartenant à Eve Descartes dont '''archive_chiffree''' (qui est donc chiffrée), '''layout.pdf''' (qui est protégé par un mot de passe) ainsi que le mail d'information ci-dessous : | ||
+ | |||
+ | |||
+ | [[Fichier:Eve.png|400px]] | ||
+ | |||
+ | |||
+ | En appelant sur le numéro de Eve on entends une succession de "BIP" faisant penser à du code morse. La traduction de ces "BIP" nous donne le mot '''resistance''' qui correspond au mot de passe de layout.pdf | ||
+ | |||
+ | L'ouverture de layout.pdf nous montre une photographie au microscope de la puce ayant servi au chiffrement de '''archive_chiffree'''. On a en réalité la photographie de la zone servant à stocker la clé de chiffrement. | ||
+ | |||
+ | |||
+ | [[Fichier:Fusibles.png|400px]] | ||
+ | |||
+ | |||
+ | Selon l'hypothèse de départ (fusible coupé = 0 ou 1) plusieurs clés sont possibles. En prenant l'hypothèse fusible coupé = 1 on obtient la clé suivante : | ||
+ | |||
+ | ''0100000101000101010100110010000000110010001101010011011000100000010001010100001101000010001000000010000000100000001 0000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000'' | ||
+ | |||
+ | La conversion de ce code binaire en code ascii nous donne la chaine de caractères suivante qui est clairement un indice pour aider au déchiffrement de l'archive. | ||
+ | |||
+ | |||
+ | [[Fichier:Aes256ecb.png|400px]] | ||
+ | |||
+ | |||
+ | A l'aide d'un script python et du module pycrypto ''(pip install pycrypto)'', on déchiffre notre archive et obtiens le mot de passe '''b a:e z''' que l'on transmet à Antoine Rossignol. Ce mot de passe valide le challenge et nous permet ENFIN d'accéder au portail d'inscription à l'adresse suivante : https://ctf.challengecybersec.fr/7a144cdc500b28e80cf760d60aca2ed3/ | ||
+ | |||
+ | |||
+ | ===Challenges réalisés :=== | ||
+ | |||
+ | Sur les 14 challenges proposés, 6 ont était réalisés ce qui nous a permis d'obtenir 600 point est de terminer 110e sur 785 | ||
+ | |||
+ | [[Fichier:Challenges.png|800px]] | ||
+ | |||
+ | |||
+ | '''Alone Musk :''' | ||
+ | |||
+ | Elevation de privilège au sein d'une machine et d'une application en python | ||
+ | |||
+ | |||
+ | '''Sous l'océan :''' | ||
+ | |||
+ | L'analyse du dump mémoire nous permet de récupérer l'historique de localisation. On remarque 19 "locations" sauvegardée avec entre 2 et n coordonnées pour chacune. En positionnant les coordonnées sur geogebra et en les reliant DANS L'ORDRE, on obtient le flag : DGSESIEE{OC34N} dessiné à l'écran | ||
+ | |||
+ | |||
+ | '''Definition :''' | ||
+ | |||
+ | Quelle heure est-il ? On transmet le nombre de seconde écoulée depuis 1970 via la commande suivante | ||
+ | date +%s | nc challengecybersec.fr 6660 | ||
+ | '''edit:''' Merci Monsieur Redon | ||
+ | |||
+ | |||
+ | '''Keypad sniffeur :''' | ||
+ | |||
+ | |||
+ | '''Polyglotte :''' | ||
+ | |||
+ | |||
+ | '''Ascii UART :''' | ||
+ | |||
+ | |||
+ | La plupart des ressources ou code créé afin de résoudre ces challenges sont disponibles dans l'archive ci contre : [[Fichier:DGSE_chall.zip]] | ||
+ | |||
+ | ==Participation au challenge DGHack (DGA)== | ||
+ | |||
+ | Inscription bien plus simple que pour le challenge de la DGSE. Après avoir créé un compte sur https://www.dghack.fr/ on obtient un accès aux différents challenges. | ||
+ | |||
+ | ===Challenges réalisés=== | ||
+ | |||
+ | '''Internal Support 1 :''' | ||
− | |||
− | + | ''' Time for something different :''' |
Version actuelle datée du 29 décembre 2020 à 14:09
Sommaire
Présentation générale
Ceci est le wiki du tp de PRA de 2020 réalisé par Samuel BENAYED et Théo EVRARD. Au cours de ce TP, de nombreux "exercices" ont pu être réalisés :
- Installation de machine virtuelles sur un serveur (Capbreton)
- Mise ne place d'une architecture réseau redondante reliée à Internet (en partenariat avec les groupes 1 et 14)
- Connexion de notre VM à ce réseau
- Cassage de clé WIFI (WEP et WPA)
- Intrusion au sein d'un service web
- Chiffrement d'une clé USB
L'ensemble de ces exercices nous a permis de mettre en application mais surtout d'approfondir nos connaissances en systèmes et réseaux. Nous tenons à remercier tout particulièrement nos professeurs pour l'aide non négligeable qu'ils nous ont apportée durant les heures de TP ainsi que Guillaume Rouillé pour son implication lors de la mise en place de l'architecture réseau.
Installation de la machine virtuelle
Nous avons installé la VM sur capbreton.plil.info avec la commande suivante :
root@capbreton:~# xen-create-image --hostname=tricholome --ip=100.64.0.18 --netmask=255.255.255.0 --password=pasglop --dir=/usr/local/xen --dist=buster --gateway=100.64.0.5 --force
Installation Summary
Hostname : tricholome
Distribution : buster
MAC Address : 00:16:3E:66:21:C5
IP Address(es) : 100.64.0.18
Root Password : pasglop
Information disques :
--- Logical volume ---
LV Path /dev/storage/BenEvrard1 LV Name BenEvrard1 VG Name storage LV UUID PMUddf-pfpz-CQW9-JDwp-5Bln-OwNV-cLQ2t8 LV Write Access read/write LV Creation host, time capbreton, 2020-10-12 16:37:17 +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:11 --- Logical volume --- LV Path /dev/storage/BenEvrard2 LV Name BenEvrard2 VG Name storage LV UUID peLdWt-86ZX-fai5-tkwS-VsTc-HApM-cnpqNr LV Write Access read/write LV Creation host, time capbreton, 2020-10-12 16:37:20 +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:12
Mise en réseau de la VM
On cherche à donner un accès internet à Tricholome, une attention toute particulière est portée à la redondance au sein du réseau. On a donc l'architecture suivante :
On a donc 2 routeurs (9200 et 6509-E) qui relient le serveur Capbreton au routeur de l'école et ainsi sortir sur internet.
Paramétrage de l'OSPF
Nos routeurs seuls ne nous mèneront pas bien loin, il est nécessaire, pour pouvoir communiquer avec l'extérieur, que ceux-ci disposent des tables de routage des routeurs voisins (notamment celui de l'école) afin de pouvoir orienter correctement nos paquets. Ce protocole de routage porte le nom de OSPF (Open Shortest Path Link) et doit donc être configuré correctement au sein de nos deux routeurs :
En minicom sur nos routeurs :
ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur router ospf 1 # un numéro de processus router-id 10.60.0.10X # un id pour le routeur (X = 1 pour 6509-E et X = 2 pour 9200) log-adjacency-changes summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333) summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé) summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?) redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés redistribute static subnets network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)
Les nouvelles routes ainsi obtenues sont visibles via la commande : show ip route. La réussite de la manipulation est validée par un ping fonctionnel d'une VM vers 193.48.57.48 qui est l'adresse du routeur de l'école
Paramétrage du NAT
Service Internet
Serveur SSH
Autorisation de la connexion SSH en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes
Connexion possible grâce à la commande : ssh root@193.48.57.185
Serveur DNS
Installation de bind9 :
apt install bind9 dnsutils
Modification du fichier /etc/resolv.conf (indique le serveur DNS à utiliser) :
nameserver 127.0.0.1
Modification de /etc/bind/named.conf.local
zone "tricholome.site" IN { type master; file "/etc/bind/db.tricholome.site.signed"; allow-transfer { 217.70.177.40; }; };
Configuration du DNS sur gandi.net :
- Ajout de deux External nameservers
ns1.tricholome.site ns6.gandi.net
- Ajout de ns1.tricholome.site : 193.48.57.185 dans Glue records
Sécurisation de site web par certificat
Notre certificat sera validé et envoyé par mail, on installe donc un serveur de mail :
apt install postfix
On configure postfix et on crée un alias dans /etc/aliases :
admin: root
Pour la génération de la clés et du certificat utilise openssl :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout tricholome.site.key -out tricholome.site.csr
On transmet ensuite le certificat à gandi pour qu'il soit signé. On reçoit plus tard le certificat signé par mail.
Site web
Notre site est hébergé sur un serveur apache2 (apt install apache2). Pour la sécurisation du site par certificat on active le module SSL d'apache2 :
a2enmod ssl
On configure notre site 000-tricholome.site-ssl.conf :
<VirtualHost *:80> ServerName tricholome.site ServerAlias www.tricholome.site # Redirection 301 vers le site en HTTPS Redirect permanent / https://www.tricholome.site/ </VirtualHost>
<VirtualHost *:443> ServerName tricholome.site ServerAlias www.tricholome.site ServerAdmin webmaster@localhost DocumentRoot /var/www/tricholome.site/ CustomLog /var/log/apache2/access.tricholome.site.log combined ErrorLog /var/log/apache2/error.tricholome.site.log SSLEngine on SSLCertificateFile /etc/ssl/cert/tricholome.site.crt SSLCertificateKeyFile /etc/ssl/private/tricholome.site.key SSLCACertificateFile /etc/ssl/certs/GandiStandardSSLCA2.pem SSLVerifyClient None </VirtualHost>
On active ensuite notre site :
a2ensite 000-tricholome.site-ssl
Sécuritsation de serveur DNS par DNSSEC
Ajout de l'option dans /etc/bind/named.conf.options :
dnssec-enable yes
Création d'un répertoire tricholome.dnssec puis génération des clefs (KSK et ZSK) au sein de ce répertoire via les commande :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE tricholome.site
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE tricholome.site
On renome ces paires de clefs pour plus de lisibilité puis ajoute les lignes suivante dans /etc/bind/db.tricholome.site (en incrémentant le serial)
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key $include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key
On signe ensuite la zone via la commande :
dnssec-signzone -o tricholome.site -k tricholome.site-ksk ../db.tricholome.site tricholome.site-zsk
On obtient alors le fichier de zone suivant : db.tricholome.site.signed
On instancie alors ce fichier dans notre /etc/bind/name.conf.local puis on transmet la clef KSK à gandi.net.
Pentesting
Exploitation de failles du système
En parallèle des TPs, nous avons réalisé des challenges sur la plateforme Root-me.org afin d'affiner nos compétences
Cassage clé WEP
Les clés WEP utilisent l'algorithme de chiffrement RC4 qui crypte les messages via des vecteurs d'initialisation sur 24 bits. De cette manière en récupérant suffisamment de paquets échangés entre une machine et l'AP on peut récupérer plusieurs paquets chiffrés avec le même vecteur d'initialisation.
Dès lors on peut craquer le code assez facilement en se basant sur des attaques statistiques par exemple.
On démarre l'interface réseau en mode moniteur
airmon-ng start [interface réseau]
On affiche les réseaux disponibles en WEP
airodump-ng --encrypt wep [NomInterface]
On capture les paquets émis par l'AP (il en faut environ 50.000 pour avoir une bonne chance de le craquer, cela devrait offrir suffisamment de collisions)
airodump-ng --write output --channel [channel] -bssid [Adresse MAC AP] [NomInterface]
On casse le code avec
aircrack-ng -x output.cap
Cassage clé WPA2
Pour casser la clé WPA on utilise les commandes suivantes :
airmon-ng start [carte réseau]
On cherche ensuite à scanner l'environnement pour détecter les connexions possibles et leurs BSSID, ESSID ainsi que le canal utilisé :
airodump-ng [carte réseau]
Le crack d'une clé WPA nécessite un handshake entre l'AP et une machine. On récupère donc le handshake avec la commande :
airodump-ng -c[canal] -bssid [Adresse MAC de l'AP] -w output [carte réseau]
Après maximum une quinzaine de minutes on récupère le handshake.
A partir de là il suffit de réaliser une attaque par dictionnaire, nous savions que le code comporte 8 caractères numériques :
crunch 8 8 0123456789 -o dico.txt
Et pour lancer le bruteforce :
aircrack-ng -w dico.txt -b [Adresse MAC de l'AP] output*.cap
La clé est donc 20122222 pour la kracotte04, le bruteforce a duré 43min sur un intel core i5 8265U.
Attaque de l'homme du milieu
L'attaque consiste à usurper l'identité d'une machine par rapport au routeur pour récupérer toutes les données qui transitent entre le routeur et la machine victime.
Pour réaliser cette attaque on utilise les commandes suivantes :
arp -a
Cela nous permet de récupérer les adresses ip du routeur et de la machine.
arpspoof -i eth0 -t <ip routeur> <ip machine> arpspoof -i eth0 -t <ip machine> <ip routeur>
De cette manière on s'immisce entre les deux équipements en remplissant les tables ARP de mauvaises informations et on récupère le trafic.
Afin de rediriger le trafic on utilise :
echo 1 > /proc/sys/net/ipv4/ip_forward
Une fois que toutes ces commandes ont été lancées on attend que la machine victime se connecte à un site http afin de voir le trafic circuler en clair.
On récupère ainsi des informations sensibles de la victime.
Cette attaque ne fonctionne pas si la victime utilise des sites sécurisés avec HTTPS car le protocole HTTPS utilise de la cryptographie asymétrique et les clés privées ne transitent donc pas sur le réseau.
Intrusion sur un serveur d’application Web
Le fichier explicatif est chiffré et disponible ci dessous.
Pour le déchiffrer il faut lancer les commandes suivantes :
wget https://wiki-ima.plil.fr/mediawiki//images/0/09/Intrusion.txt gpg --decrypt Intrusion.txt spécifier le mot de passe root@honey.plil.info
Réalisation
Sécurisation de données
Création des trois partitions 3 sur capbreton :
lvcreate -L1G -n tricholome.raid1 storage lvcreate -L1G -n tricholome.raid2 storage lvcreate -L1G -n tricholome.raid3 storage
Ajout dans /etc/xen/tricholome.cfg :
'phy:/dev/storage/tricholome.raid1,xvda5,w', 'phy:/dev/storage/tricholome.raid2,xvda6,w', 'phy:/dev/storage/tricholome.raid3,xvda7,w'
Reboot de la VM :
xl shut tricholome xl create -c /etc/xen/tricholome.cfg
Sur tricholome, installation de mdadm.
apt instal mdadm
Construction et formatage du volume RAID 5.
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7 mdadm --monitor --daemonise /dev/md0 mkfs.ext4 /dev/md0
Ajout de ce volume dans le fstab :
/dev/md0 /raid5 ext4 defaults 0 2
Raid 5 nous permet de reconstruire d'un disque supprimé à partir de 2 autres disques. Il nous faut au minimum 3 disques. On peut donc supprimer une partition et toujours avoir accès à nos fichiers. On peut noter que pour 3 volumes alloués à Raid5, 1 ne sera pas "réellement utilisable".
Chiffrement de données
On cherche à chiffrer une clef USB.
fdisk -l # on repère la clé USB fdisk /dev/sdb # on formate la clé en une seule partition
Installation de cryptsetup et lvm : apt install cryptsetup lvm2
cryptsetup luksFormat /dev/sdb1 # chiffrement de la partition de la clé USB cryptsetup luksOpen /dev/sdb1 myusbkey # déchiffrement de la partition
On monte la clé USB, on la peuple :
mkdir /mnt/USB mount -t ext4 /dev/mapper/myusbkey /mnt/USB touch /mnt/USB/sameo.txt
Puis on démonte le système de fichier proprement :
umount /mnt/USB cryptsetup luksClose myusbkey
Pour que quelqu'un puisse accéder à notre clef, il doit maintenant renseigné le mot de passe.
Inspection ARP par un élément réseau
Nous avons à notre disposition un Cisco ASA-5506-X qui permet de monitorer le réseau et éviter notamment les attaques de type man in the middle (l'homme du milieu). Nous avions donc pour objectif de brancher l'appareil sur le réseau et d'y connecter deux machines de façon à pouvoir recréer une attaque ARP spoofing. Nous avons rencontré un problème lors de la mise en place de ce dispositif : le Cisco ASA-5506-X n'a pas la fonctionnalité commutateur contrairement au Cisco ASA-5505.
Nous n'avons donc pas pu réaliser cette partie.
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.
Ajout d'une seconde interface réseau virtuelle à notre machine amanite sur capbreton (fichier /etc/xen/amanite.cfg) afin de la relier au VLAN50
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 VM capbreton on configure notre fichier /etc/network/interfaces :
# The secondary network interface auto eth1 iface eth1 inet static address 192.168.42.18 netmask 255.255.255.0
Mise en place d'une mascarade avec les commandes suivantes :
iptables -P FORWARD DROP iptables -A FORWARD -j ACCEPT -s 192.168.45.4/24 iptables -A FORWARD -j ACCEPT -d 192.168.45.4/24 iptables -t nat -A POSTROUTING -j SNAT -s 192.168.42.4/24 --to-source 193.48.57.185
Permet à nos paquets en provenance de 192.168.45.4 (VM chassiron) de sortir sur internet en passant par notre interface eth0 de notre machine virtuelle sur capbreton.
Sur VM chassiron on configure 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.18
Clés SSH
Génération d’une paire de clef asymétrique :
ssh-keygen -t rsa
Transmission de la clefs publique aux autres machines de chassiron :
cat .ssh/id_rsa.pub | ssh 192.168.42.x "cat >> /root/.ssh/authorized_keys2"
On peut maintenant se connecter en ssh sans authentification sur les autres machines de notre groupe.
Installation d'Ansible
Installation via la commande :
apt install ansible
Création d'un 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
On a donc deux ensemble, un contenant notre machine seule, l'autre contenant toutes les vm de chassiron. On pourra appeler ces ensembles dans nos playbook ansible.
Installation de docker
Installation de docker, prérequis : python3 et python3-pip installé via le role basic
- name: Install packages
apt: pkg: - python3 - python3-pip - ntp - curl
- name : NTP_configuration
copy: src: /etc/ntp.conf dest: /etc/ntp.conf
Utilisation du rôle geerlingguy.docker pour l'installation de docker :
On obtient donc le playbook suivant :
- 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 d'un conteneur
On crée notre conteneur à l'aide d'un dockerfile situé dans /root/Dockerfile
FROM httpd:lattest MAINTAINER Sameo COPY .index.html /usr/local/apache2/htdocs/ CMD ["httpd", "-D", "FOREGROUND"]
Création de l'image (dans le même dossier que notre dockerfile) :
docker build -t tricholome
Test de lancement de nore image :
docker run -d -p "8085:80" --name tricholome tricholome
Commande de vérification :
docker images (Affichage des différentes images docker installées) docker ps -a (Affichage des différents containeurs en cours d'exécution)
Création d'un rôle ansible pour créer un registry sur notre VM chassiron :
- name: Setup registry docker_container: name: registry image: registry ports: - "5000:5000"
On appel ce rôle dans ansible puis on peut push-pull de notre image dans notre registry sur Chassiron :
docker tag tricholome 192.168.42.5:5000/tricholome docker push 192.168.42.4.:5000/tricholome
Puis coté chassiron :
docker pull 192.168.42.4:5000/tricholome
Déploiement de notre image
On crée un rôle qui permet de déployer notre image sur une machine :
- name: Create a container docker_container: name: amanite_container image: 192.168.42.4:5000/tricholome ports: - "8084:80"
Via le playbook ansible on déploie notre image sur les machines de chassiron :
- hosts: webservers roles: - new_container
Equilibreur de charge
Configuration des modules nécessaires :
a2enmod proxy a2enmod proxy_http a2enmod proxy_balancer a2enmod lbmethod_byrequests
Modification de notre zone dans /etc/bind/db.tricholome.site :
reverse IN CNAME www
(+ incrémentation du numéro de version, signature de la zone pour DNSSEC et redémarrage de bind9).
Ajout d'un nouveau site dans /etc/apache2/site-available que nous nommons reverse.conf :
<VirtualHost *:80> ServerName bis.tricholome.site ServerAdmin Sameo ProxyPass / http://192.168.42.4:8084 ProxyPassReverse / http://192.168.42.4:8084 </VirtualHost>
On rend notre site enable :
a2ensite reverse.conf service apache2 restart
Site désormais accessible via l'URL bis.tricholome.site
Ajout de l'équilibreur de charge : (dans /etc/apache2/site-availables/reverse.conf)
<VirtualHost *:80> ServerName bis.tricholome.site ServerAdmin Sameo <Proxy "balancer://myset"> BalancerMember "http://192.168.42.2:8084" route=1 BalancerMember "http://192.168.42.4:8084" route=2 BalancerMember "http://192.168.42.5:8084" route=3 BalancerMember "http://192.168.42.7:8084" route=4 BalancerMember "http://192.168.42.9:8084" route=5 BalancerMember "http://192.168.42.12:8084" route=6 ProxySet lbmethod=byrequests </Proxy> ProxyPass / balancer://myset/ ProxyPassReverse / balancer://myset/ </VirtualHost>
Bonus
Participation au challenge Brigitte Friang (DGSE)
Participation en équipe à un challenge de cybersécurité organisé par la DGSE : https://www.defense.gouv.fr/dgse/tout-le-site/operation-brigitte-friang-prets-pour-relever-le-defi
Inscription au challenge :
- 1- Connexion à https://www.challengecybersec.fr :
L'observation du code source de la page nous amène à une nouvelle adresse https://www.challengecybersec.fr/static/message-secret.html contenant un texte et 5 caractères en gras
- 2- Dechiffrement de secret.html :
Il s'agit d'un texte chiffré avec un décalage ASCII de 7. Après déchiffrement on obtient un paragraphe nous expliquant qui était Brigitte Friang. L'observation des 5 caractères en gras nous donne /chat. On se connecte donc à https://www.challengecybersec.fr/chat. On arrive alors sur un portail avec différentes missions à accomplir
- 3- Cryptographie par Antoine Rossignol :
On récupère plusieurs fichiers appartenant à Eve Descartes dont archive_chiffree (qui est donc chiffrée), layout.pdf (qui est protégé par un mot de passe) ainsi que le mail d'information ci-dessous :
En appelant sur le numéro de Eve on entends une succession de "BIP" faisant penser à du code morse. La traduction de ces "BIP" nous donne le mot resistance qui correspond au mot de passe de layout.pdf
L'ouverture de layout.pdf nous montre une photographie au microscope de la puce ayant servi au chiffrement de archive_chiffree. On a en réalité la photographie de la zone servant à stocker la clé de chiffrement.
Selon l'hypothèse de départ (fusible coupé = 0 ou 1) plusieurs clés sont possibles. En prenant l'hypothèse fusible coupé = 1 on obtient la clé suivante :
0100000101000101010100110010000000110010001101010011011000100000010001010100001101000010001000000010000000100000001 0000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000
La conversion de ce code binaire en code ascii nous donne la chaine de caractères suivante qui est clairement un indice pour aider au déchiffrement de l'archive.
A l'aide d'un script python et du module pycrypto (pip install pycrypto), on déchiffre notre archive et obtiens le mot de passe b a:e z que l'on transmet à Antoine Rossignol. Ce mot de passe valide le challenge et nous permet ENFIN d'accéder au portail d'inscription à l'adresse suivante : https://ctf.challengecybersec.fr/7a144cdc500b28e80cf760d60aca2ed3/
Challenges réalisés :
Sur les 14 challenges proposés, 6 ont était réalisés ce qui nous a permis d'obtenir 600 point est de terminer 110e sur 785
Alone Musk :
Elevation de privilège au sein d'une machine et d'une application en python
Sous l'océan :
L'analyse du dump mémoire nous permet de récupérer l'historique de localisation. On remarque 19 "locations" sauvegardée avec entre 2 et n coordonnées pour chacune. En positionnant les coordonnées sur geogebra et en les reliant DANS L'ORDRE, on obtient le flag : DGSESIEE{OC34N} dessiné à l'écran
Definition :
Quelle heure est-il ? On transmet le nombre de seconde écoulée depuis 1970 via la commande suivante
date +%s | nc challengecybersec.fr 6660 edit: Merci Monsieur Redon
Keypad sniffeur :
Polyglotte :
Ascii UART :
La plupart des ressources ou code créé afin de résoudre ces challenges sont disponibles dans l'archive ci contre : Fichier:DGSE chall.zip
Participation au challenge DGHack (DGA)
Inscription bien plus simple que pour le challenge de la DGSE. Après avoir créé un compte sur https://www.dghack.fr/ on obtient un accès aux différents challenges.
Challenges réalisés
Internal Support 1 :
Time for something different :