diff --git a/.gitignore b/.gitignore
index b51a70d1d91dca49a4e12ffd02103c538c413abd..2167e1fdc3fbe8bedd72c73e4075aa07a2bdce39 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
*.pdf
*.tex
+mermaid-filter.err
diff --git a/content/01_labo1_macflooding.md b/content/01_labo1_macflooding.md
index 51d43ce382bd48835fb93f85abbd9bcad1dfe71f..62a0da61d0bd147e414fabe6fca15667b3dd107f 100644
--- a/content/01_labo1_macflooding.md
+++ b/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.
-
+{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.
-
-
diff --git a/content/02_labo_stp.md b/content/02_labo_stp.md
index 34619360379f9458f4ff1143913a52e196c57006..25a5f5f66f65119ef49f26e12eb38431e63db2f6 100644
--- a/content/02_labo_stp.md
+++ b/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
+```
+
+
+
+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 :
+
+
+
+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).
+
+
+
+\newpage
+
+7.
+
+Sur la capture Wireshark entre `kali-linux-1` et S2 ci-dessous, on peut remarquer
+la notification de changement de topologie.
+
+{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.
+
+{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
+
+
diff --git a/figs/gns3_path_to_root_from_s2.png b/figs/gns3_path_to_root_from_s2.png
new file mode 100644
index 0000000000000000000000000000000000000000..1084688a31007dd95c07df06df2f243bea8876f3
Binary files /dev/null and b/figs/gns3_path_to_root_from_s2.png differ
diff --git a/figs/h1-h2_fail_topology-change.png b/figs/h1-h2_fail_topology-change.png
new file mode 100644
index 0000000000000000000000000000000000000000..a8016be3ad166e8782f2b1be5858f0a490466667
Binary files /dev/null and b/figs/h1-h2_fail_topology-change.png differ
diff --git a/figs/h1-h2_fail_topology-change_annotated.png b/figs/h1-h2_fail_topology-change_annotated.png
new file mode 100644
index 0000000000000000000000000000000000000000..9ec47d74474144bebce999a31df07d729aed57af
Binary files /dev/null and b/figs/h1-h2_fail_topology-change_annotated.png differ
diff --git a/figs/s2_route_to_root.png b/figs/s2_route_to_root.png
new file mode 100644
index 0000000000000000000000000000000000000000..0c743ee1d2ae73a43af60e1e0a0a93f885f0fd84
Binary files /dev/null and b/figs/s2_route_to_root.png differ
diff --git a/figs/s2_route_to_root_annotated.png b/figs/s2_route_to_root_annotated.png
new file mode 100644
index 0000000000000000000000000000000000000000..fa2516c24f7eb62964ecbe5a80f5a0791ef9de5f
Binary files /dev/null and b/figs/s2_route_to_root_annotated.png differ
diff --git a/figs/wireshark_topology_change.png b/figs/wireshark_topology_change.png
new file mode 100644
index 0000000000000000000000000000000000000000..bcddf43da55f085cc098a0445121d1b97a079541
Binary files /dev/null and b/figs/wireshark_topology_change.png differ
diff --git a/figs/yersinia_list_attacks.png b/figs/yersinia_list_attacks.png
new file mode 100644
index 0000000000000000000000000000000000000000..29d2b5db75082cbfc83c4f00ecfa9b75be50916d
Binary files /dev/null and b/figs/yersinia_list_attacks.png differ
diff --git a/figs/yersinia_ui.png b/figs/yersinia_ui.png
new file mode 100644
index 0000000000000000000000000000000000000000..f07512107ac227c3afda7c7e9e49d7f4c72e2ae4
Binary files /dev/null and b/figs/yersinia_ui.png differ