Skip to content
Snippets Groups Projects
Commit 554aa74e authored by iliya's avatar iliya
Browse files

feat: part2 lab2 done, TODO part3

parent 13552965
No related branches found
No related tags found
No related merge requests found
*.pdf *.pdf
*.tex *.tex
mermaid-filter.err
...@@ -92,6 +92,7 @@ dans les tables d'adresses MACs de S1, S2 et S3. La raison pour laquelle cela ...@@ -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 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. paquet à H1 depuis une un hôte possedant une adresse MAC aléatoire.
\newpage
## Attaque du MAC flooding ## Attaque du MAC flooding
...@@ -171,7 +172,7 @@ la table d'adresse MAC du switch, sera copié sur tous les ports. ...@@ -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 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. 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 8. Cela se produit sûrement parce que les paquets seront "droppé" après un certain
temps donné. temps donné.
...@@ -201,6 +202,7 @@ Security // Verifies the configuration ...@@ -201,6 +202,7 @@ Security // Verifies the configuration
`type slot/port` est ex.: `GigabitEthernet 0/0` `type slot/port` est ex.: `GigabitEthernet 0/0`
\newpage
### Port Security --- Access Port ### Port Security --- Access Port
...@@ -327,7 +329,6 @@ En ce qui concerne la commande `show port-security interface GigabitEthernet 0/0 ...@@ -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 elle reflète la "violation" qui s'est produite en mettant à jour la valeur du
compteur "SecurityViolation". compteur "SecurityViolation".
2. Le risque d'une réactivation automatique est que l'attaque lancée reprendra 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. 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 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 ...@@ -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 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 possible de discerner du trafic normal et repérer une attaque car les paquets
seront envoyés à une cadence constante. seront envoyés à une cadence constante.
...@@ -105,6 +105,8 @@ desactivée (en réalité, elle est marquée comme chemin alternatif vers la rac ...@@ -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ù 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. ce lien tombe, l'interface Gi0/2 de S2 permettra à S3 de se relier jusqu'à la racine.
\newpage
```CiscoIOS ```CiscoIOS
Interface Role Sts Cost Prio.Nbr Type Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- -------------------------------- ------------------- ---- --- --------- -------- --------------------------------
...@@ -132,3 +134,96 @@ conséquent il servira de chemin pour S1 afin de rejoindre la racine. ...@@ -132,3 +134,96 @@ conséquent il servira de chemin pour S1 afin de rejoindre la racine.
```CiscoIOS ```CiscoIOS
Gi0/0 Altn BLK 4 128.1 P2p 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)
figs/gns3_path_to_root_from_s2.png

25.2 KiB

figs/h1-h2_fail_topology-change.png

222 KiB

figs/h1-h2_fail_topology-change_annotated.png

271 KiB

figs/s2_route_to_root.png

80.1 KiB

figs/s2_route_to_root_annotated.png

80.5 KiB

figs/wireshark_topology_change.png

245 KiB

figs/yersinia_list_attacks.png

92.7 KiB

figs/yersinia_ui.png

70.2 KiB

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment