Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
---
lang: fr
---
\newpage
# Protection d'un LAN d'attaques sur STP
## Révision STP
### Configuration des machines
S1 :
```CiscoIOS
conf t
hostname S1
exit
```
S2 :
```CiscoIOS
conf t
hostname S2
exit
```
S3 :
```CiscoIOS
conf t
hostname S3
exit
```
### Questions
1.
Ci-dessous nous pouvons voir la sortie de la commande `show spanning-tree` sur
le Switch S1.
En dessous de l'adresse MAC, il est dit que ce switch (S1) a été élu en tant que
racine.
```CiscoIOS
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0c0c.39d3.0000
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0c0c.39d3.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
```
L'élection de la racine se fait par l'identifiant du switch le plus faible
(Bridge ID). C'est un identifiant de 8 octets où 2 octets correspondent à
la valeur du `Bridge Priority` et les 6 autres octets sont l'adresse MAC de l'appareil.
Initialement les switches s'envoient des messages `BPDUs` (Bridge Priority Data Unit)
qui contiennent le `Bridge ID` du switch actuel, celui de la racine actuel ainsi
que la distance (_number of hops_) jusqu'à la racine. Au fur et à mesure les divers
arbres des plus courts chemins vers la racine seront calculés. Dans le cas où la
distance pour deux switches jusqu'à la racine est la même, on assignera la priorité
au switch qui porte la valeur de `Bridge Priority` la plus faible. Les ports qui
ne sont pas sur l'arbre couvrant seront désactivé et conserve uniquement les ports
actifs.
2. La commande `show spanning-tree root` sur le switch S2 nous fourni l'adresse
MAC de la racine ainsi que le coût (distance) vers la racine. Cette commande
nous donne aussi la valeur du _Hello Time_ qui correspond à 2 secondes. Si le
switch ne reçoit pas de BPDU pendant cette durée de temps (timeout de 2 secondes),
l'arbre couvrant sera recalculé.
```CiscoIOS
S2#show spanning-tree root
Root Hello Max Fwd
Vlan Root ID Cost Time Age Dly Root Port
---------------- -------------------- --------- ----- --- --- ------------
VLAN0001 32769 0c0c.39d3.0000 4 2 20 15 Gi0/0
```
3. La raison pour laquelle le champ `Root Port` n'est pas renseigné sur la racine
est que ce champ correspond à l'interface par laquelle passe l'arbre couvrant
jusqu'à la racine. Vu que le "chemin" depuis la racine jusqu'à la racine ne passe
par aucune interface, car il est la racine.
4.
```mermaid
graph TD;
S1-->S2;
S1-->S3;
```
L'interface Gi0/2 sur S2 est indiquée en tant que `Altn`. Cette interface est
desactivée (en réalité, elle est marquée comme chemin alternatif vers la racine)
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.
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
```CiscoIOS
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/2 Altn BLK 4 128.3 P2p
```
5. Afin que le switch S3 devienne la racine, il faut lui assigner une valeur
faible pour le `Bridge Priority`. La commande exécutée est :
```CiscoIOS
S3(config)#spanning-tree vlan 1 priority 0
```
6.
```mermaid
graph TD;
S3-->S1;
S3-->S2;
```
À présent, c'est l'interface Gi0/0 sur S2 qui est bloquée. Ceci est le cas, car
cette interface sera utilisée dans le cas où le lien entre S1 et S3 tombe et par
conséquent il servira de chemin pour S1 afin de rejoindre la racine.
```CiscoIOS
Gi0/0 Altn BLK 4 128.1 P2p
```
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
\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
