feat: part2 lab2 done, TODO part3

.gitignore

 *.pdf
 *.tex
+mermaid-filter.err

content/01_labo1_macflooding.md

@@ -92,6 +92,7 @@ dans les tables d'adresses MACs de S1, S2 et S3. La raison pour laquelle cela
 est le cas est qu'en ayant inversé les adresses `src` et `dst` on envoie le 
 paquet à H1 depuis une un hôte possedant une adresse MAC aléatoire.
 
+\newpage
 
 ## Attaque du MAC flooding
 
@@ -171,7 +172,7 @@ la table d'adresse MAC du switch, sera copié sur tous les ports.
 7. Sur la capture d'écran ci-dessous, on peut effectivement remarquer que le paquet
 ICMP envoyé depuis H2 à H3 est bien visible sur le lien H1 $\Rightarrow$ S1.
 
-![Capture wireshark entre H1 et S1 des paquets ICMP entre H2 et H3](../figs/traffic_h2_h3_on_h1_s1.png) 
+![Capture wireshark entre H1 et S1 des paquets ICMP entre H2 et H3](../figs/traffic_h2_h3_on_h1_s1.png){width=80%}
 
 8. Cela se produit sûrement parce que les paquets seront "droppé" après un certain
 temps donné.
@@ -201,6 +202,7 @@ Security // Verifies the configuration
 
 où `type slot/port` est ex.: `GigabitEthernet 0/0`
 
+\newpage
 
 ### Port Security --- Access Port
 
@@ -327,7 +329,6 @@ En ce qui concerne la commande `show port-security interface GigabitEthernet 0/0
 elle reflète la "violation" qui s'est produite en mettant à jour la valeur du
 compteur "SecurityViolation".
 
-
 2. Le risque d'une réactivation automatique est que l'attaque lancée reprendra
 son effet s'il n'a pas été arrête entre-temps par la personne malveillante.
 L'inconvénient est qu'il est possible de mettre "hors-service" tous les ports
@@ -337,5 +338,3 @@ instaurer un méchanisme qui surveillerai la fréquence à laquelle les paquets
 sur le switch. C'est un des rares facteurs grâce auquel à mon avis il est encore
 possible de discerner du trafic normal et repérer une attaque car les paquets
 seront envoyés à une cadence constante.
-
-

content/02_labo_stp.md

@@ -105,6 +105,8 @@ desactivée (en réalité, elle est marquée comme chemin alternatif vers la rac
 car S3 est relié à la racine par un chemin plus court. Cependant, dans le cas où
 ce lien tombe, l'interface Gi0/2 de S2 permettra à S3 de se relier jusqu'à la racine.
 
+\newpage
+
 ```CiscoIOS
 Interface           Role Sts Cost      Prio.Nbr Type
 ------------------- ---- --- --------- -------- --------------------------------
@@ -132,3 +134,96 @@ conséquent il servira de chemin pour S1 afin de rejoindre la racine.
 ```CiscoIOS
 Gi0/0               Altn BLK 4         128.1    P2p
 ```
+
+\newpage
+
+## Attaque de STP avec Yersinia
+
+
+### Claiming Root STP Role
+
+
+1.  Commande à exécuter sur H1 :
+```sh
+ip addr add 10.0.0.1/24 dev eth0 && ip link set up dev eth0
+```
+
+Commande à exécuter sur H2 :
+```sh
+ip addr add 10.0.0.2/24 dev eth0 && ip link set up dev eth0
+```
+
+2.  Avec la commande ci-dessous lancez `Yersinia` sur la machine `kali-linux-1`:
+```sh
+sudo yersinia -I
+```
+![Interface `Yersinia`](../figs/yersinia_ui.png) 
+
+
+3. Il est possible d'assez vite remarquer que le _timestamp_ du champ _last seen_
+est synchronisé avec le champ _STP Packets_ qui s'incrémente au même moment que
+le champ _last seen_ est mis à jour. D'après mon observation ce champ à un retard
+de $\approx$ 2 secondes par rapport au temps réel affiché dans le coin en haut
+à droite du _TUI_ (Terminal User Interface). Par conséquent, il est possible d'en
+déduire que la fréquence d'envoi des _BPDU_ (Bridge Protocol Data Units) de type
+"conf" est de $\approx$ 2 secondes.
+
+4. Sur la capture d'écran ci-dessous, on peut les divers types d'attaques proposées :
+
+![Liste des attaques proposées par `Yersinia`](../figs/yersinia_list_attacks.png)
+
+L'attaque du type "_Claiming Root Role_" consiste à initialement "écouter" ce qui
+se passe sur le réseau afin d'en déduire quel switch est la racine. Après avoir
+déterminé cela, la seconde partie de l'attaque consiste à envoyer des BPDU de type
+conf avec une valeur de priorité (_Bridge Priority_) modifiée et **inférieure**
+à la valeur actuelle. Pour rappel, la valeur du _Bridge Priority_ est codée sur
+2 des 8 octets du champ _Bridge ID_.
+
+\newpage
+
+Ci-dessous, le lecteur trouvera la liste détaillée des modifications faites au
+BPDU. [Source: GitHub Yersinia](https://github.com/tomac/yersinia/blob/master/README)
+```md
+Source MAC: same one as the sniffed BPDU.
+Destination MAC: same one as the sniffed BPDU.
+Bridge ID: the sniffed one slightly modified to have a lower priority
+Root ID: 8000: same as bridge id.
+Hello time: same one as the sniffed BPDU.
+Forward delay: same one as the sniffed BPDU.
+Max age: same one as the sniffed BPDU.
+Root pathcost: same one as the sniffed BPDU.
+```
+
+5. Démarrez une capture _Wireshark_ entre `kali-linux-1` et S2, puis exécutez
+une attaque de type de "Claiming Root Role".
+
+6. La communication entre H1-H2 échoue lors du changement de topologie causé par l'attaque
+"Claiming Root Role". Ceci est le cas car pendant le recalcul de la racine le
+switches ne savent pas à travers quels ports "forwarder" (en bon français) les
+paquets (ICMP en l'occurrence).
+
+![Communication entre H1-H2 tombe suite au changement de topologie](../figs/h1-h2_fail_topology-change_annotated.png)
+
+\newpage
+
+7. 
+
+Sur la capture Wireshark entre `kali-linux-1` et S2 ci-dessous, on peut remarquer
+la notification de changement de topologie.
+
+![Capture Wireshark --- Changement de topologie](../figs/wireshark_topology_change.png){width=80%}
+
+
+Sur la capture d'écran ci-dessous, on remarque qu'en exécutant la commande Cisco
+`show spanning-tree root` sur le switch S2, on obtient l'information qui concerne
+le port menant vers la racine, en l'occurrence l'interface Gi0/3.
+
+![`show spanning-tree root` sur S2](../figs/s2_route_to_root_annotated.png){width=70%}
+
+
+Afin de s'assurer que la nouvelle racine est bien la machine `kali-linux-1`, il
+nous suffit de regarder sur le schéma du labo est remarquer que l'interface Gi0/3
+de S2 est bel et bien reliée à `kali-linux-1` ce qui nous confirme que cette machine
+est la nouvelle racine
+
+![Vérification avec le schéma du réseau](../figs/gns3_path_to_root_from_s2.png)