Skip to content
Snippets Groups Projects
Commit 5fd5eded authored by iliya's avatar iliya
Browse files

feat: labo 2 (STP) finished

parent 554aa74e
No related branches found
No related tags found
No related merge requests found
......@@ -195,10 +195,10 @@ 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".
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
"_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).
......@@ -227,3 +227,51 @@ de S2 est bel et bien reliée à `kali-linux-1` ce qui nous confirme que cette m
est la nouvelle racine
![Vérification avec le schéma du réseau](../figs/gns3_path_to_root_from_s2.png)
## Protection du réseau par BPDU Guard
![Détails de l'interface Gi0/3 avant l'activation du BPDU Guard](./figs/etat_interface_avant_bpduGuard.png)
\newpage
### Activation du BPDU Guard sur l'interface Gi0/3 de S2
```CiscoIOS
S2#conf t
S2(config)#interface GigabitEthernet 0/3
S2(config-if)#spanning-tree bpduguard enable
S2(config-if)#no shut
```
### Configuration de la réactivation du port après 60 secondes suite à la violation BPDU
```CiscoIOS
S2(config)#errdisable recovery cause bpduguard
S2(config)#errdisable recovery interval 60
```
### Confirmation de l'activation du BPDU Guard
Sur la capture d'écran ci-dessous, on peut effectivement remarquer qu'un message
BPDU a été reçu sur l'interface GigabitEthernet 0/3 du switch S2.
À la suite de cet événement, l'état de l'interface passe à _**down**_. Puis, après
60 secondes, l'interface est à nouveau réactivée (_**up**_).
![Fonctionnement du BPDU Guard sur S2](./figs/disable_and_reactivation_bpduguard.png)
### Etat de l'interface avec BPDU Guard
Sur la capture d'écran ci-dessous, on remarque qu'effectivement même durant l'attaque
"_Claiming Root Role_" on arrive à conserver S1 (liaison à travers l'interface Gi0/0) en tant que la racine grâce à
BPDU Guard.
![État de l'interface GigabitEthernet 0/1 avec BPDU Guard](./figs/etat_interface_bpdu_guard.png){width=60%}
figs/disable_and_reactivation_bpduguard.png

82.8 KiB

figs/etat_interface_avant_bpduGuard.png

89.9 KiB

figs/etat_interface_bpdu_guard.png

47 KiB

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment