TP sysres IMA5 2021/2022 G3 : Différence entre versions
(→Honey à descendre) |
|||
(80 révisions intermédiaires par 2 utilisateurs non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
+ | =PRA= | ||
Ceci est la contribution du groupe G3 ( numéroté groupe 2 ) aux travaux pratiques de réseau de cette 5ème Année. Le groupe est constitué de Axel Chemin et de Guillaume PERSON. | Ceci est la contribution du groupe G3 ( numéroté groupe 2 ) aux travaux pratiques de réseau de cette 5ème Année. Le groupe est constitué de Axel Chemin et de Guillaume PERSON. | ||
− | == | + | ==Table d'adressage== |
+ | Dans la première séance, toute la promotion s'est divisée en groupes qui se sont attachés à une tâche en particulier. Nous nous sommes pour notre part attelés à la partie adressage, avec les groupes 0, 5, 6, 8,9 et 10. | ||
+ | Nous avons déterminé les tables d'adressage des VLAN ainsi que des adresses IP du VLAN 42 ( qui est le VLAN que nous avons choisi pour être celui associé aux machines virtuelles). | ||
+ | |||
+ | Le résultat de cette réflexion peut être trouvé ici : [https://wiki-ima.plil.fr/mediawiki//index.php/TP_sysres_IMA5sc_2021/2022] | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==Configuration en SR-52== | ||
+ | Dans un second temps, il a fallu configurer les trous routeurs situés en E-304, E-306 et SR-52. L'équipe 0 et nous-mêmes sommes allés configurer le routeur situé en SR-52. | ||
+ | |||
+ | Voici ce qui a été fait et qui a causé le dérèglement de la plateforme. | ||
+ | |||
+ | Commandes rentrées : | ||
+ | |||
+ | |||
+ | enable | ||
+ | |||
+ | configure | ||
+ | |||
+ | interface Gigabitethernet 0/18 (ou Gi0/18) | ||
+ | |||
+ | switchport mode access | ||
+ | |||
+ | switchport access vlan 531 // permet de déplacer l’interface Gi0/18 sur le vlan 531 | ||
+ | |||
+ | |||
+ | // config adresse ipv4 : | ||
+ | |||
+ | interface vlan 531 | ||
+ | |||
+ | ip address 192.168.222.43 255.255.255.248 | ||
+ | |||
+ | |||
+ | //config adresse ipv6 | ||
+ | |||
+ | interface vlan 531 | ||
+ | |||
+ | ipv6 address 2001:660:4401:60b0::3/64 | ||
+ | |||
+ | ipv6 unicast-routing | ||
+ | //done | ||
+ | |||
+ | //interconnexion | ||
+ | |||
+ | router ospf 1 | ||
+ | |||
+ | ipv4 router-id 192.168.222.43 | ||
+ | |||
+ | summary-address 193.48.57.176 255.255.255.240 | ||
+ | |||
+ | summary-address ?? | ||
+ | |||
+ | summary-adress | ||
+ | |||
+ | redistribute connected subnets | ||
+ | |||
+ | redistribute static subnets route-map ospf | ||
+ | |||
+ | network 192.168.222.32 0.0.0.7 area 10 | ||
+ | |||
+ | network 192.168.222.40 0.0.0.7 area 20 | ||
+ | |||
+ | default-information originate | ||
+ | |||
+ | //done | ||
+ | |||
+ | //filtre pour ospf | ||
+ | |||
+ | route ospf 1 | ||
+ | |||
+ | summary-address 10.0.0.0 255.0.0.0 not-advertise | ||
+ | |||
+ | //done | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | Enfin, nous avons tenté de configurer le router avec la fibre. | ||
+ | Nous devons aussi configurer le cas d'interconnexion pour l'ipv6. | ||
+ | |||
+ | ==Gestion de la machine virtuelle== | ||
+ | |||
+ | Pour cette séance nous créons la machine virtuelle sur Capbreton | ||
+ | |||
+ | Il faut d'abord se connecter en root (mot de passe habituel) sur Capbreton. | ||
+ | |||
+ | Pour utiliser le miroir Debian de l'école : | ||
+ | export http_proxy=http://proxy.plil.fr:3128 | ||
+ | |||
+ | En utilisant Xen pour créer notre image : | ||
+ | xen-create-image --hostname=Kasteel --ip=193.48.57.178 --gateway=193.48.57.190 --netmask=255.255.255.224 --dir=/usr/local/xen --password=pasglop dist=debian | ||
+ | |||
+ | Les volumes logiques pour les répertoires home et var doivent être créés : | ||
+ | lvcreate -L10G -n KasteelHome storage | ||
+ | lvcreate -L10G -n KasteelVar storage | ||
+ | |||
+ | On peut vérifier le statut des volumes : | ||
+ | vgdisplay | ||
+ | lvdisplay [path] | ||
+ | |||
+ | Et vérifier qu'ils soient bien en ext4 : | ||
+ | file -Ls /dev/storage/ | ||
+ | mkfs.ext4 Kasteel | ||
+ | |||
+ | |||
+ | dans : nano /etc/xen/Kasteel.cfg | ||
+ | |||
+ | root = '/dev/xvda2 ro' | ||
+ | disk = [ | ||
+ | 'file:/usr/local/xen/domains/Kasteel/disk.img,xvda2,w', | ||
+ | 'file:/usr/local/xen/domains/Kasteel/swap.img,xvda1,w', | ||
+ | 'phy:/dev/storage/KasteelHome,xvda3,w' | ||
+ | 'phy:/dev/storage/KasteelVar,xvda4,w' | ||
+ | ] | ||
+ | |||
+ | |||
+ | vif = [ 'ip=193.48.57.178 ,mac=00:16:3E:88:65:42 ,bridge=IMA5sc' ] | ||
+ | |||
+ | |||
+ | Et on lance la machine pour s'y connecter. | ||
+ | xen create -c /etc/xen/Kasteel.cfg | ||
+ | |||
+ | |||
+ | on configure SSH, déjà lancé, mais il faut permettre root de s'y connecter : | ||
+ | /etc/ssh/sshd.config | ||
+ | => PermitRootLogin yes | ||
+ | |||
+ | et on redémarre le service : | ||
+ | service ssh restart | ||
+ | |||
+ | On installe installe Apache2 et on acitve le ssh en root dans /etc/ssh. | ||
+ | |||
+ | On monte ensuite /home et /var | ||
+ | |||
+ | On commence par créer les dossiers : | ||
+ | mkdir /mnt/xvda3 | ||
+ | mkdir /mnt/xvda4 | ||
+ | |||
+ | Puis : | ||
+ | mount /dev/xvda3 /mnt/xvda3 | ||
+ | mount /dev/xvda4 /mnt/xvda4 | ||
+ | |||
+ | Ensuite, on déplace le contenu de /var dans xvda4 : | ||
+ | |||
+ | mv /var/* /mnt/xvda4 | ||
+ | |||
+ | Alors, on ajoute les deux lignes dans le /etc/fstab : | ||
+ | |||
+ | /dev/xvda3 /home ext4 defaults 0 2 | ||
+ | /dev/xvda4 /var ext4 defaults 0 2 | ||
+ | |||
+ | On peut enfin taper : | ||
+ | |||
+ | mount -a | ||
+ | |||
+ | On peut alors voir avec lsblk que nos /home et /var existent ! | ||
+ | |||
+ | VRRP : redondance de routeur, choix du meilleur routeur | ||
+ | OSPF : les routeurs s'échangent leurs routes | ||
+ | |||
+ | ==Tests d'intrusion== | ||
+ | ===Recherche de failles du système=== | ||
+ | |||
+ | Nous recherchons des failles systèmes sur le ee. | ||
+ | lsb_release -a | ||
+ | on est en Devuan 2.1 | ||
+ | |||
+ | |||
+ | ===Honey à descendre=== | ||
+ | |||
+ | L'ensemble de la rédaction se trouve dans cette [https://drive.google.com/file/d/17CvPimVH66YAKXji1230K_-6TV7uMwyI/view?usp=sharing archive protégée avec mot de passe] . | ||
+ | |||
+ | MAJ 15/01/2022 : le mot de passe est "ilestlechef" | ||
+ | |||
+ | == Crackage de clefs wifi == | ||
+ | |||
+ | airmon-ng start wlan0mon | ||
+ | |||
+ | cela affiche toutes les cracottes ( les pts wifi) | ||
+ | ensuite on ecoute les trames wifi dela cracotte choisie ( la 03) | ||
+ | pour cela, on utilise : | ||
+ | airodump-ng --encrypt wep wlan0mon | ||
+ | on a son adresse MAC : 04:DA:D2:9C:50:52 | ||
+ | |||
+ | |||
+ | on va ensuite récupérer le BSSID associé à notre cracotte03 grace a son ESSID trouvé précéde> | ||
+ | |||
+ | |||
+ | aireplay-ng -9 -e cracotte03 -a 04:DA:D2:9C:50:50 | ||
+ | |||
+ | Puis, un recupere le bssid et enfin | ||
+ | |||
+ | airodump-ng -c 4 --bssid 04:DA:D2:9C:50:52 -w output wlan0mon | ||
+ | |||
+ | On utilise ensuite : | ||
+ | |||
+ | aircrack-ng output-01.cap pour recupérer le mot de passe ! | ||
+ | |||
+ | notre mot de passe, trouvé en 4:09m est 55:55:55:55:5A:BC:04:CB:A4:44:44:44:44 | ||
+ | |||
+ | |||
+ | Il reste à cracker la clef WPA. | ||
+ | Il faut créer un dictionnaire avec tous les mots de 8 caractères où chaque caractère est un chiffre. J'ai d'abord réalisé un fichier c le faisant, mais l'utilitaire crunch permet de réaliser cela plus simplement. | ||
+ | La suite n'a pas encore été réalisée, | ||
+ | |||
+ | |||
+ | ==Realisations== | ||
+ | ===Sécurisation des données=== | ||
+ | On commence par créer les trois volumes : | ||
+ | lvcreate -L1G -n Kasteel-secu1 storage | ||
+ | lvcreate -L1G -n Kasteel-secu2 storage | ||
+ | lvcreate -L1G -n Kasteel-secu3 storage | ||
+ | |||
+ | On les ajoute ensuite à la configuration de la machine virtuelle en ajoutant à Kasteel.cfg : | ||
+ | 'phy:/dev/storage/Kasteel-secu1,xvda5,w', | ||
+ | 'phy:/dev/storage/Kasteel-secu2,xvda6,w', | ||
+ | 'phy:/dev/storage/Kasteel-secu3,xvda7,w' | ||
+ | |||
+ | |||
+ | Ensuite, on redémarre la machine puis on utilise mdam pour créer le raid : | ||
+ | |||
+ | mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7 | ||
+ | |||
+ | Nous formatons /dev/md0 avec mkfs.ext4 | ||
+ | |||
+ | Nous utilisons ensuite : | ||
+ | mdadm --monitor --daemonise /dev/md0 | ||
+ | |||
+ | afin que le volume soit monté lorsque la machine virtuelle démarre. | ||
+ | |||
+ | Nous ajoutons enfin : | ||
+ | /dev/md0 /media/raid ext4 defaults 0 1 | ||
+ | à notre fstab. | ||
+ | |||
+ | Il est alors possible d'écrire : | ||
+ | mount -a | ||
+ | |||
+ | ===Chiffrement de données=== | ||
+ | |||
+ | On commence par installer lvm2 et cryptsetup sur le eeePc. Pour avoir internet, il faut brancher le eeePc sur une zabeth. | ||
+ | |||
+ | On branche la clef USB dans le eeePc et on utilise lsblk pour trouver son nom : sda. | ||
+ | |||
+ | On formate la clef : | ||
+ | |||
+ | mkfs.ext4 /dev/sda | ||
+ | |||
+ | Nous initialisons ensuite la clef au format LUKS grâce à : | ||
+ | |||
+ | cryptsetup luksFormat /dev/sda | ||
+ | Nous utilisons le mot de passe pasglop | ||
+ | |||
+ | Puis nous formatons la partition cryptée , avec un volume nommé encrypted : | ||
+ | cryptsetup luksOpen /dev/sdc encrypted | ||
+ | mkfs.ext4 /dev/mapper/encrypted | ||
+ | |||
+ | Nous montons alors la partition : | ||
+ | |||
+ | mkdir /mnt/encrypter | ||
+ | mount -t ext4 /dev/mapper/encrypted /mnt/encrypter | ||
+ | On ajoute un fichier texte dans /mnt/encrypter. | ||
+ | |||
+ | Nous démontons la clef avec umount et cryptsetup luksClose, puis nous la branchons sur un autre pc pour tenter d'accéder aux fichiers. | ||
+ | Sans connaitre le mot de passe, pas moyen d'accéder aux fichiers, c'est bien ce que nous voulons ! | ||
+ | |||
+ | ==Service Web== | ||
+ | |||
+ | ===DNS=== | ||
+ | |||
+ | Nous avons aussi réservé le nom de domaine kasteel.site sur gandi.net , et configuré la redirection vers notre serveur DNS local. | ||
+ | |||
+ | Puis bind a été configuré. | ||
+ | |||
+ | |||
+ | ===DNSSEC=== | ||
+ | |||
+ | Nous avons acheté un certificat sur gandi. | ||
+ | |||
+ | dnssec-enable yes; dans les configurations. | ||
+ | |||
+ | dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE kasteel.site | ||
+ | dnssec-keygen -a RSASHA1 -b 1024 -n ZONE kasteel.site | ||
+ | dnssec-signzone -o kasteel.site -k kasteel.site-ksk ../db.kasteel.site kasteel.site-zsk | ||
+ | |||
+ | dans named.conf.local, on remplace le file par "/etc/bind/db.kasteel.site.signed" | ||
+ | |||
+ | Manipulation faite dans gandi pour confirmer notre configuration. | ||
+ | |||
+ | ===HTTPS=== | ||
+ | |||
+ | Puis, nous avons généré les deux clefs grâce à openssl en suivant le tutoriel sur : https://docs.gandi.net/en/ssl/common_operations/csr.html | ||
+ | |||
+ | On installe Apache2, le mod ssl : "a2enmod ssl" , et on le configure pour utiliser HTTPS : | ||
+ | |||
+ | <VirtualHost *:443> | ||
+ | ServerAdmin webmaster@localhost | ||
+ | DocumentRoot /var/www/html | ||
+ | ErrorLog ${APACHE_LOG_DIR}/error.log | ||
+ | CustomLog ${APACHE_LOG_DIR}/access.log combined | ||
+ | SSLEngine on | ||
+ | SSLCertificateFile /etc/apache2/kasteel.site.crt | ||
+ | SSLCertificateKeyFile /keys/myserver.key | ||
+ | #SSLCertificateChainFile /etc/apache2/kasteel.site.crt | ||
+ | </VirtualHost> | ||
+ | |||
+ | =ASR= | ||
+ | ==Mise en place de ansible== | ||
+ | |||
+ | |||
+ | |||
+ | Nous débutons ce tp en lisant le sujet : [[https://github.com/thomas-maurice/polytech-asr-lab]] | ||
+ | Nous générons une clef ssh : | ||
+ | ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "axel.chemin@polytech-lille.net" -P '' | ||
+ | Cela nous permet de générer une clef ssh sans mot de passe qui sera utilse pour lier notre VM à ansible. | ||
+ | Notre Machine virtuelle est sur chassiron, avec le nom pra-03. | ||
+ | |||
+ | Nous modifions le fichier /etc/network/interfaces afin de pouvoir nous connecter en ssh à notre VM: | ||
+ | # The primary network interface | ||
+ | auto eth0 | ||
+ | iface eth0 inet static | ||
+ | address 172.26.145.103 | ||
+ | netmask 255.255.255.0 | ||
+ | gateway 172.26.188.254 | ||
+ | |||
+ | Nous continuons le tp, et nous nous y connectons ( à notre VM ) et copions la clef ssh dans : | ||
+ | /root/.ssh/authorized_keys | ||
+ | |||
+ | |||
+ | Revenons sur notre machine zabeth où nous avons cloné le repo depuis github. Nous modifions le fichier inventory pour y mettre l'adresse IP de notre VM : | ||
+ | pra-03 ansible_ssh_host="172.26.145.103" | ||
+ | Nous créons aussi le fichier host_vars/pra-03.yaml qui contiendra nos variables probablement nécessaires plus tard. Notons que pra-03 match le nom de notre machine dans inventory | ||
+ | |||
+ | Nous créons ensuite un environnement python et l'activons : | ||
+ | |||
+ | python3 -m venv ~/env-ansible | ||
+ | . ~/env-ansible/bin/activate | ||
+ | Puis, nous installons les packages grâce au gestionnaire de paquets python : | ||
+ | pip3 install -U setuptools wheel | ||
+ | pip3 install -U ansible | ||
+ | |||
+ | Il a été nécessaire de updrage pip au préalable. | ||
+ | Nous pouvons ensuite lancer le playbook avec la commande : | ||
+ | ansible-playbook -v -i inventory polytech.yaml | ||
+ | |||
+ | Nous trouvons une erreur, il faut au préalable installer python sur la machine pra-03 ! | ||
+ | apt-get install python3 | ||
+ | |||
+ | ( Rq : pour utiliser ansible, il faut : pouvoir se connecter en ssh dessus ET avoir python d'installé dessus) | ||
+ | |||
+ | Et nous recommençons la commande précédente. | ||
+ | |||
+ | Celle fois, le playbook semble faire ce qu'il faut ! | ||
+ | |||
+ | ==Ajout d'un rôle== | ||
+ | Nous ajoutons dans group_vars/all notre clef ssh publique créée précédemment afin de permettre à ansible d'accéder à notre VM en ssh. | ||
+ | -name: achemin@gperson | ||
+ | key: SSH_KEY_DONT_WANT_TO_COPY_IT | ||
+ | |||
+ | Nous ajoutons ensuite le fichier roles/ssh_key/tasks/main.yml pout y mettre notre tâche d'ajout des clefs ssh directement dans ~/.ssh/authorized_keys. Il y a deux étapes : | ||
+ | |||
+ | - Créer le fichier root/.ssh/authorized_keys s'il n'existe pas | ||
+ | - Utiliser un template pour mettre nos clefs ( la nôtre et celle de Thomas ) | ||
+ | |||
+ | Voici le fichier roles/ssh_key/tasks/main.yml : | ||
+ | - name: "check ssh present" | ||
+ | file: | ||
+ | path: "/root/.ssh/authorized_keys" | ||
+ | state: touch | ||
+ | mode: "0600" | ||
+ | become: yes | ||
+ | - name: "update ssh authorized" | ||
+ | template: | ||
+ | src: ssh.j2 | ||
+ | dest: "/root/.ssh/authorized_keys" | ||
+ | owner: root | ||
+ | group: root | ||
+ | mode: "0600" | ||
+ | become: yes | ||
+ | |||
+ | |||
+ | Et le fichier polytech.yml mis à jour afin d'appeler notre rôle ssh_key: | ||
+ | |||
+ | --- | ||
+ | - hosts: all | ||
+ | roles: | ||
+ | - role: base | ||
+ | tags: base | ||
+ | - role: ssh_key | ||
+ | tags: ssh_key | ||
+ | |||
+ | |||
+ | Et enfin le template qui sera utilisé pour remplacer le fichier root/.ssh/authorized/keys sur notre VM : | ||
+ | {% for key in ssh_keys %} | ||
+ | {{ key.key }} | ||
+ | {% endfor %} | ||
+ | En testant en utilisant : | ||
+ | ansible-playbook -v -i inventory polytech.yaml | ||
+ | Et cela met bien à jour les clefs sur notre VM ! | ||
+ | |||
+ | |||
+ | ==Docker== | ||
+ | Pour utiliser ansible-galaxy, il faut exporter le proxy : | ||
+ | export http_proxy="http://proxy.plil.fr:3128" | ||
+ | export https_proxy="https://proxy.plil.fr:3128" | ||
+ | Puis s'assurer d'être toujours dans l'environnement ansible créé précédemment ( réactiver si nécessaire) et lancer la commande : | ||
+ | ansible-galaxy install geerlingguy.docker | ||
+ | |||
+ | Cela est fait afin d'installer docker ! | ||
+ | ==Installation de consul== | ||
+ | On doit ensuite créer un utilisateur et un groupe consul, pour cela on ajoute un rôle appelé consul, où le fichier role/consul/tasks/main.yml est défini comme suit : | ||
+ | - name: "consul user" | ||
+ | user: | ||
+ | append: yes | ||
+ | name: "consul" | ||
+ | uid: "666" | ||
+ | become: yes | ||
+ | - name: "Change consul groupe id" | ||
+ | group: | ||
+ | name: "consul" | ||
+ | gid: "666" | ||
+ | |||
+ | On ajoute aussi le rôle consul dans polytech.yaml. | ||
+ | |||
+ | On ajoute ensuite le fichier de configuration /etc/consul/basic_config.json demandé dans le sujet : | ||
+ | { | ||
+ | "datacenter": "polytech", | ||
+ | "data_dir": "/var/lib/consul", | ||
+ | "log_level": "INFO", | ||
+ | "node_name": "<your node name>", | ||
+ | "server": true | ||
+ | } | ||
+ | |||
+ | Pour ce faire, on ajoute des tâches à notre rôle consul dans role/consul/tasks/main.yml : | ||
+ | |||
+ | - name: "presence of /etc/consul" | ||
+ | file: | ||
+ | path: "/etc/consul" | ||
+ | state: directory | ||
+ | mode: 700 | ||
+ | owner: consul | ||
+ | group: consul | ||
+ | become: yes | ||
+ | - name: "presence of /var/lib/consul" | ||
+ | file: | ||
+ | path: "/var/lib/consul" | ||
+ | state: directory | ||
+ | mode: 700 | ||
+ | owner: consul | ||
+ | group: consul | ||
+ | become: yes | ||
+ | - name: "presence of /etc/consul/basic_config.json" | ||
+ | file: | ||
+ | path: "/etc/consul/basic_config.json" | ||
+ | state: touch | ||
+ | mode: 700 | ||
+ | owner: consul | ||
+ | group: consul | ||
+ | become: yes | ||
+ | - name: "copy config" | ||
+ | copy: | ||
+ | src: "static_files/basic_config.json" | ||
+ | dest: "/etc/consul/basic_config.json" | ||
+ | mode: 644 | ||
+ | owner: consul | ||
+ | group: consul | ||
+ | become: yes | ||
+ | |||
+ | Nous ajoutons aussi un dossier static_files dans le rôle consul qui contient le fichier basic_config.json qui contient la configuration montrée précédemment, qui sera installée par ansible. | ||
+ | |||
+ | Nous relançons ansible de la même manière que les deux fois précédentes : Nous obtenons bien le résultat voulu, le dossier est créé sur la VM et le fichier de configuration est présent. | ||
+ | |||
+ | |||
+ | On veut ensuite lancer docker. On modifie donc le fichier role/consul/tasks/main.yml comme suit : | ||
+ | |||
+ | - name: "Run a 2048 in order to test" | ||
+ | community.docker.docker_container: | ||
+ | name: "acontainer" | ||
+ | image: "alexwhen/docker-2048" | ||
+ | |||
+ | |||
+ | On modifie aussi polytech.yml qui a maintenant l'allure comme suit : | ||
+ | |||
+ | --- | ||
+ | - hosts: all | ||
+ | roles: | ||
+ | - role: base | ||
+ | tags: base | ||
+ | - role: ssh_key | ||
+ | tags: ssh_key | ||
+ | - geerlingguy.pip | ||
+ | - geerlingguy.docker | ||
+ | - role: consul | ||
+ | tags: consul | ||
+ | |||
+ | |||
+ | On installe aussi sur notre vm docker et resuest : | ||
+ | pip install docker | ||
+ | pip install requests | ||
+ | |||
+ | |||
+ | Il est aussi nécessaire de gérer un problème de pull de l'image docker ( qui timeout) malgré le proxy de l'école configuré. |
Version actuelle datée du 15 janvier 2022 à 14:42
Sommaire
PRA
Ceci est la contribution du groupe G3 ( numéroté groupe 2 ) aux travaux pratiques de réseau de cette 5ème Année. Le groupe est constitué de Axel Chemin et de Guillaume PERSON.
Table d'adressage
Dans la première séance, toute la promotion s'est divisée en groupes qui se sont attachés à une tâche en particulier. Nous nous sommes pour notre part attelés à la partie adressage, avec les groupes 0, 5, 6, 8,9 et 10. Nous avons déterminé les tables d'adressage des VLAN ainsi que des adresses IP du VLAN 42 ( qui est le VLAN que nous avons choisi pour être celui associé aux machines virtuelles).
Le résultat de cette réflexion peut être trouvé ici : [1]
Configuration en SR-52
Dans un second temps, il a fallu configurer les trous routeurs situés en E-304, E-306 et SR-52. L'équipe 0 et nous-mêmes sommes allés configurer le routeur situé en SR-52.
Voici ce qui a été fait et qui a causé le dérèglement de la plateforme.
Commandes rentrées :
enable
configure
interface Gigabitethernet 0/18 (ou Gi0/18)
switchport mode access
switchport access vlan 531 // permet de déplacer l’interface Gi0/18 sur le vlan 531
// config adresse ipv4 :
interface vlan 531
ip address 192.168.222.43 255.255.255.248
//config adresse ipv6
interface vlan 531
ipv6 address 2001:660:4401:60b0::3/64
ipv6 unicast-routing
//done
//interconnexion
router ospf 1
ipv4 router-id 192.168.222.43
summary-address 193.48.57.176 255.255.255.240
summary-address ??
summary-adress
redistribute connected subnets
redistribute static subnets route-map ospf
network 192.168.222.32 0.0.0.7 area 10
network 192.168.222.40 0.0.0.7 area 20
default-information originate
//done
//filtre pour ospf
route ospf 1
summary-address 10.0.0.0 255.0.0.0 not-advertise
//done
Enfin, nous avons tenté de configurer le router avec la fibre. Nous devons aussi configurer le cas d'interconnexion pour l'ipv6.
Gestion de la machine virtuelle
Pour cette séance nous créons la machine virtuelle sur Capbreton
Il faut d'abord se connecter en root (mot de passe habituel) sur Capbreton.
Pour utiliser le miroir Debian de l'école :
export http_proxy=http://proxy.plil.fr:3128
En utilisant Xen pour créer notre image :
xen-create-image --hostname=Kasteel --ip=193.48.57.178 --gateway=193.48.57.190 --netmask=255.255.255.224 --dir=/usr/local/xen --password=pasglop dist=debian
Les volumes logiques pour les répertoires home et var doivent être créés :
lvcreate -L10G -n KasteelHome storage lvcreate -L10G -n KasteelVar storage
On peut vérifier le statut des volumes :
vgdisplay lvdisplay [path]
Et vérifier qu'ils soient bien en ext4 :
file -Ls /dev/storage/ mkfs.ext4 Kasteel
dans : nano /etc/xen/Kasteel.cfg
root = '/dev/xvda2 ro' disk = [
'file:/usr/local/xen/domains/Kasteel/disk.img,xvda2,w', 'file:/usr/local/xen/domains/Kasteel/swap.img,xvda1,w', 'phy:/dev/storage/KasteelHome,xvda3,w' 'phy:/dev/storage/KasteelVar,xvda4,w' ]
vif = [ 'ip=193.48.57.178 ,mac=00:16:3E:88:65:42 ,bridge=IMA5sc' ]
Et on lance la machine pour s'y connecter.
xen create -c /etc/xen/Kasteel.cfg
on configure SSH, déjà lancé, mais il faut permettre root de s'y connecter :
/etc/ssh/sshd.config
=> PermitRootLogin yes
et on redémarre le service :
service ssh restart
On installe installe Apache2 et on acitve le ssh en root dans /etc/ssh.
On monte ensuite /home et /var
On commence par créer les dossiers :
mkdir /mnt/xvda3 mkdir /mnt/xvda4
Puis :
mount /dev/xvda3 /mnt/xvda3 mount /dev/xvda4 /mnt/xvda4
Ensuite, on déplace le contenu de /var dans xvda4 :
mv /var/* /mnt/xvda4
Alors, on ajoute les deux lignes dans le /etc/fstab :
/dev/xvda3 /home ext4 defaults 0 2 /dev/xvda4 /var ext4 defaults 0 2
On peut enfin taper :
mount -a
On peut alors voir avec lsblk que nos /home et /var existent !
VRRP : redondance de routeur, choix du meilleur routeur OSPF : les routeurs s'échangent leurs routes
Tests d'intrusion
Recherche de failles du système
Nous recherchons des failles systèmes sur le ee. lsb_release -a
on est en Devuan 2.1
Honey à descendre
L'ensemble de la rédaction se trouve dans cette archive protégée avec mot de passe .
MAJ 15/01/2022 : le mot de passe est "ilestlechef"
Crackage de clefs wifi
airmon-ng start wlan0mon
cela affiche toutes les cracottes ( les pts wifi) ensuite on ecoute les trames wifi dela cracotte choisie ( la 03) pour cela, on utilise :
airodump-ng --encrypt wep wlan0mon
on a son adresse MAC : 04:DA:D2:9C:50:52
on va ensuite récupérer le BSSID associé à notre cracotte03 grace a son ESSID trouvé précéde>
aireplay-ng -9 -e cracotte03 -a 04:DA:D2:9C:50:50
Puis, un recupere le bssid et enfin
airodump-ng -c 4 --bssid 04:DA:D2:9C:50:52 -w output wlan0mon
On utilise ensuite :
aircrack-ng output-01.cap pour recupérer le mot de passe !
notre mot de passe, trouvé en 4:09m est 55:55:55:55:5A:BC:04:CB:A4:44:44:44:44
Il reste à cracker la clef WPA.
Il faut créer un dictionnaire avec tous les mots de 8 caractères où chaque caractère est un chiffre. J'ai d'abord réalisé un fichier c le faisant, mais l'utilitaire crunch permet de réaliser cela plus simplement.
La suite n'a pas encore été réalisée,
Realisations
Sécurisation des données
On commence par créer les trois volumes :
lvcreate -L1G -n Kasteel-secu1 storage lvcreate -L1G -n Kasteel-secu2 storage lvcreate -L1G -n Kasteel-secu3 storage
On les ajoute ensuite à la configuration de la machine virtuelle en ajoutant à Kasteel.cfg :
'phy:/dev/storage/Kasteel-secu1,xvda5,w', 'phy:/dev/storage/Kasteel-secu2,xvda6,w', 'phy:/dev/storage/Kasteel-secu3,xvda7,w'
Ensuite, on redémarre la machine puis on utilise mdam pour créer le raid :
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
Nous formatons /dev/md0 avec mkfs.ext4
Nous utilisons ensuite :
mdadm --monitor --daemonise /dev/md0
afin que le volume soit monté lorsque la machine virtuelle démarre.
Nous ajoutons enfin :
/dev/md0 /media/raid ext4 defaults 0 1
à notre fstab.
Il est alors possible d'écrire :
mount -a
Chiffrement de données
On commence par installer lvm2 et cryptsetup sur le eeePc. Pour avoir internet, il faut brancher le eeePc sur une zabeth.
On branche la clef USB dans le eeePc et on utilise lsblk pour trouver son nom : sda.
On formate la clef :
mkfs.ext4 /dev/sda
Nous initialisons ensuite la clef au format LUKS grâce à :
cryptsetup luksFormat /dev/sda
Nous utilisons le mot de passe pasglop
Puis nous formatons la partition cryptée , avec un volume nommé encrypted :
cryptsetup luksOpen /dev/sdc encrypted mkfs.ext4 /dev/mapper/encrypted
Nous montons alors la partition :
mkdir /mnt/encrypter mount -t ext4 /dev/mapper/encrypted /mnt/encrypter
On ajoute un fichier texte dans /mnt/encrypter.
Nous démontons la clef avec umount et cryptsetup luksClose, puis nous la branchons sur un autre pc pour tenter d'accéder aux fichiers. Sans connaitre le mot de passe, pas moyen d'accéder aux fichiers, c'est bien ce que nous voulons !
Service Web
DNS
Nous avons aussi réservé le nom de domaine kasteel.site sur gandi.net , et configuré la redirection vers notre serveur DNS local.
Puis bind a été configuré.
DNSSEC
Nous avons acheté un certificat sur gandi.
dnssec-enable yes; dans les configurations.
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE kasteel.site dnssec-keygen -a RSASHA1 -b 1024 -n ZONE kasteel.site dnssec-signzone -o kasteel.site -k kasteel.site-ksk ../db.kasteel.site kasteel.site-zsk
dans named.conf.local, on remplace le file par "/etc/bind/db.kasteel.site.signed"
Manipulation faite dans gandi pour confirmer notre configuration.
HTTPS
Puis, nous avons généré les deux clefs grâce à openssl en suivant le tutoriel sur : https://docs.gandi.net/en/ssl/common_operations/csr.html
On installe Apache2, le mod ssl : "a2enmod ssl" , et on le configure pour utiliser HTTPS :
<VirtualHost *:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/kasteel.site.crt SSLCertificateKeyFile /keys/myserver.key #SSLCertificateChainFile /etc/apache2/kasteel.site.crt </VirtualHost>
ASR
Mise en place de ansible
Nous débutons ce tp en lisant le sujet : [[2]] Nous générons une clef ssh :
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "axel.chemin@polytech-lille.net" -P
Cela nous permet de générer une clef ssh sans mot de passe qui sera utilse pour lier notre VM à ansible. Notre Machine virtuelle est sur chassiron, avec le nom pra-03.
Nous modifions le fichier /etc/network/interfaces afin de pouvoir nous connecter en ssh à notre VM:
# The primary network interface auto eth0 iface eth0 inet static address 172.26.145.103 netmask 255.255.255.0 gateway 172.26.188.254
Nous continuons le tp, et nous nous y connectons ( à notre VM ) et copions la clef ssh dans :
/root/.ssh/authorized_keys
Revenons sur notre machine zabeth où nous avons cloné le repo depuis github. Nous modifions le fichier inventory pour y mettre l'adresse IP de notre VM :
pra-03 ansible_ssh_host="172.26.145.103"
Nous créons aussi le fichier host_vars/pra-03.yaml qui contiendra nos variables probablement nécessaires plus tard. Notons que pra-03 match le nom de notre machine dans inventory
Nous créons ensuite un environnement python et l'activons :
python3 -m venv ~/env-ansible . ~/env-ansible/bin/activate
Puis, nous installons les packages grâce au gestionnaire de paquets python :
pip3 install -U setuptools wheel pip3 install -U ansible
Il a été nécessaire de updrage pip au préalable. Nous pouvons ensuite lancer le playbook avec la commande :
ansible-playbook -v -i inventory polytech.yaml
Nous trouvons une erreur, il faut au préalable installer python sur la machine pra-03 !
apt-get install python3
( Rq : pour utiliser ansible, il faut : pouvoir se connecter en ssh dessus ET avoir python d'installé dessus)
Et nous recommençons la commande précédente.
Celle fois, le playbook semble faire ce qu'il faut !
Ajout d'un rôle
Nous ajoutons dans group_vars/all notre clef ssh publique créée précédemment afin de permettre à ansible d'accéder à notre VM en ssh.
-name: achemin@gperson key: SSH_KEY_DONT_WANT_TO_COPY_IT
Nous ajoutons ensuite le fichier roles/ssh_key/tasks/main.yml pout y mettre notre tâche d'ajout des clefs ssh directement dans ~/.ssh/authorized_keys. Il y a deux étapes :
- Créer le fichier root/.ssh/authorized_keys s'il n'existe pas - Utiliser un template pour mettre nos clefs ( la nôtre et celle de Thomas )
Voici le fichier roles/ssh_key/tasks/main.yml :
- name: "check ssh present" file: path: "/root/.ssh/authorized_keys" state: touch mode: "0600" become: yes - name: "update ssh authorized" template: src: ssh.j2 dest: "/root/.ssh/authorized_keys" owner: root group: root mode: "0600" become: yes
Et le fichier polytech.yml mis à jour afin d'appeler notre rôle ssh_key:
--- - hosts: all roles: - role: base tags: base - role: ssh_key tags: ssh_key
Et enfin le template qui sera utilisé pour remplacer le fichier root/.ssh/authorized/keys sur notre VM :
{% for key in ssh_keys %} Modèle:Key.key {% endfor %}
En testant en utilisant :
ansible-playbook -v -i inventory polytech.yaml
Et cela met bien à jour les clefs sur notre VM !
Docker
Pour utiliser ansible-galaxy, il faut exporter le proxy :
export http_proxy="http://proxy.plil.fr:3128" export https_proxy="https://proxy.plil.fr:3128"
Puis s'assurer d'être toujours dans l'environnement ansible créé précédemment ( réactiver si nécessaire) et lancer la commande :
ansible-galaxy install geerlingguy.docker
Cela est fait afin d'installer docker !
Installation de consul
On doit ensuite créer un utilisateur et un groupe consul, pour cela on ajoute un rôle appelé consul, où le fichier role/consul/tasks/main.yml est défini comme suit :
- name: "consul user" user: append: yes name: "consul" uid: "666" become: yes - name: "Change consul groupe id" group: name: "consul" gid: "666"
On ajoute aussi le rôle consul dans polytech.yaml.
On ajoute ensuite le fichier de configuration /etc/consul/basic_config.json demandé dans le sujet :
{ "datacenter": "polytech", "data_dir": "/var/lib/consul", "log_level": "INFO", "node_name": "<your node name>", "server": true }
Pour ce faire, on ajoute des tâches à notre rôle consul dans role/consul/tasks/main.yml :
- name: "presence of /etc/consul" file: path: "/etc/consul" state: directory mode: 700 owner: consul group: consul become: yes - name: "presence of /var/lib/consul" file: path: "/var/lib/consul" state: directory mode: 700 owner: consul group: consul become: yes - name: "presence of /etc/consul/basic_config.json" file: path: "/etc/consul/basic_config.json" state: touch mode: 700 owner: consul group: consul become: yes - name: "copy config" copy: src: "static_files/basic_config.json" dest: "/etc/consul/basic_config.json" mode: 644 owner: consul group: consul become: yes
Nous ajoutons aussi un dossier static_files dans le rôle consul qui contient le fichier basic_config.json qui contient la configuration montrée précédemment, qui sera installée par ansible.
Nous relançons ansible de la même manière que les deux fois précédentes : Nous obtenons bien le résultat voulu, le dossier est créé sur la VM et le fichier de configuration est présent.
On veut ensuite lancer docker. On modifie donc le fichier role/consul/tasks/main.yml comme suit :
- name: "Run a 2048 in order to test" community.docker.docker_container: name: "acontainer" image: "alexwhen/docker-2048"
On modifie aussi polytech.yml qui a maintenant l'allure comme suit :
--- - hosts: all roles: - role: base tags: base - role: ssh_key tags: ssh_key - geerlingguy.pip - geerlingguy.docker - role: consul tags: consul
On installe aussi sur notre vm docker et resuest :
pip install docker pip install requests
Il est aussi nécessaire de gérer un problème de pull de l'image docker ( qui timeout) malgré le proxy de l'école configuré.