VLAN-Frage

Computer: Hardware Netzwerk
21

Deshalb habe ich mich mal
durch die Handbooks zu den betr. Switches (Nortel Baystack,
Level One Websmart, D-Link DGS) durchgewühlt.

Dabei ist folgendes herausgekommen:

Es ist unmöglich, einen Switchport ohne 802.1q und ohne
protocol-based VLAN in
mehr als ein VLAN zu packen. Das geht nicht, und es kann gar
nicht gehen, weil
ja die VLAN-Unterscheidung anhand irgendwelcher Kriterien
getroffen werden muss.

Ich habe das Baystack Handbuch auch gelesen :smile: Auf welcher Seite willst Du gelesen haben, dass man *nur* tagged VLANS erstellen kann? Ich beziehe mich auf das Kapitel über „Shared Servers“. Auf Seite 1-44 siehst Du, dass ausnahmslos alle Ports als „untagged“ angelegt werden, und in der Skizze 1-27 ist zu sehen, dass ein Port mehreren VLANs angehören kann.

Ich finde es allerdings irreführend von Nortel, das ins Kapitel IEEE 802.1Q VLAN Workgroups zu packen, wo größtenteils über „tagged“ VLANS gesprochen wird.

> Es ist unmöglich, einen Switchport ohne 802.1q und ohne
> protocol-based VLAN in
> mehr als ein VLAN zu packen. Das geht nicht, und es kann gar
> nicht gehen, weil
> ja die VLAN-Unterscheidung anhand irgendwelcher Kriterien
> getroffen werden muss.

Sehe ich nicht so, solange man einen einzigen reinen Layer-2 Switch betrachtet.

Ich spekuliere mal ein wenig drauflos, findest Du einen Denkfehler, diskutieren wir darüber.

Ausgangslage: Der Switch kennt als reines LAyer-2 gerät nur die MAC Adressen aller angeschlossenen Geräte und die Ports. Die VLAN Definition im Switch weist Ports, und damit MACs, an ein oder mehrere VLANs zu. Die Filterlogik im Switch hat nun nicht die geringsten Probleme, „normale“ (Unicast) MAC Pakete durchzulassen oder nicht: wenn Quell- und Zielport ein gemeinsames VLAN haben: durchlassen, sonst sperren. Ob Quell- und Zielport dabei auch noch in einem anderen, nicht gemeinsamen VLAN ein Beinchen haben interessiert nicht.

Unicast wäre damit 100% erschlagen.

Bleiben noch die Broadcasts.

FF:FF:FF:FF:FF:FF FF:FF:FF:FF:FF:FF: unzulässig, sperren
FF:FF:FF:FF:FF:FF --> MAC: unzulässig, sperren

MAC --> FF:FF:FF:FF:FF:FF: notgedrungen an alle Ports in allen VLANS durchlassen

Scheint dass dieser Fall der 1. Knackpunkt ist. Nehmen wir an, der broadcastende Rechner PC1 sitzt in VLAN1. Dann erfährt ein Rechner PC2 in VLAN2, dass es die MAC Adresse PC1 gibt. PC1 seinerseits bekommt keine Kenntnisse zu PC2, da die ARP Antwort, die ja kein Broadcast ist, weggefiltert wird. Irrtümlich Daten an PC2 senden wird er also mangels MAC Adresse nicht. Aber auch PC2, der PC1 kennt, kann mit PC1 nicht wirklich reden, da alle Pakete von PC2 mit Zieladresse PC1 ausgefiltert werden. Also kann PC2 an PC1 nur Daten durchbekommen indem er sie ebenfalls broadcastet. Es gibt kein mir bekanntes Netzwerkprotokoll, das so kommuniziert. Ausnahme: IP Multicasting, aber das ist normalerweise nicht im Einsatz.

Man könnte nun, rein theoretisch, ein Programm schreiben, das auf PC1 und PC2 installiert werden muss, das ausschließlich über Broadcasts Daten in beide Richtungen austauscht, und das Kind wäre im Brunnen.

Abgesehen von der Frage, wer das tun soll, wie der „wer“ das Programm auf PC1 und PC2 installiert bekommt, und wie er einem dummen PC1 (Router!) sowas beibringt und es dann in seine Firmware flasht sind wir uns wahrscheinlich einig, dass man sich nur in ganz wenigen Szenarien, die hier sicher nicht zutreffen, vor einer solchen Attacke fürchten muss. Schließlich ist spätestens am Router Sendeschluss für Broadcasts, woraus folgt dass diese Art der Attacke nur in einem LAN, aber keinesfalls unter Beteiligung einer Internetanbindung Aussicht auf Erfolg hat.

  1. Knackpunkt:
    FF:FF:FF:FF:FF:FF --> unbekannte (erfundene oder nicht gelernte) MAC

Dem L2 Switch bleibt nichts anderes übrig als das Paket durchzulassen wie ein Broadcast, nur dass diesmal auch niemand antwortet und niemand was lernt. Kann man also als Sonderfall von Knackpunkt 1 betrachten.

> Wirklich funktionieren tut das desweiteren nur, wenn ENTWEDER
> zwei Subnetze
> verwendet werden ODER der IP-Stack kaputt ist. Letzteres führt
> zu
> Sicherheitsproblemen (Details auf Wunsch).

Es gibt auch eine Welt außerhalb von IP (Layer-3) Switchen. Layer 2 ist zwar nicht State of the Art, aber manche fahren auch mit einem 15 Jahre alten Golf rum und kommen vorwärts :smile:

> Unter’m Strich scheint mir, dass wir uns eh einig sind und nur
> ggf.
> unterschiedliche Begriffe benutzt haben :smile:

Goldene Brücke, aber in diesem Fall unzutreffend.

Ich finds übrigens angenehm, mit Dir zu diskutieren. Und wenn ich jetzt einen Hochsicherheitstrakt auslegen müsste, wo ich bestens ausgerüstete Angreifer auf jeder (!) Seite meiner Installation befürchten mküsste, die nicht auf Einbruch sodnern auf Ausbruch aus sind (fast alle ernstzunehmenden Angriffe kommen von innen!) würde ich Dir sofort recht geben, L2 VLANs wären zu unsicher. Es kann nicht sein dass ein bestochener Admin oder Dienstleister einen präparierten PC in mein Rechenzentrum einschleppt und meine wertvollen Daten nach außen an einen ebenfalls präparierten Empfänger-PC broadcastet.

Hier gibg es aber nur um die Absicherung eines popeligen Internetzugangs.

…Armin

22

Ich habe das Baystack Handbuch auch gelesen :smile: Auf welcher
Seite willst Du gelesen haben, dass man *nur* tagged VLANS
erstellen kann?

Das habe ich so nicht behauptet.

Ich beziehe mich auf das Kapitel über „Shared
Servers“. Auf Seite 1-44 siehst Du, dass ausnahmslos alle
Ports als „untagged“ angelegt werden, und in der Skizze 1-27
ist zu sehen, dass ein Port mehreren VLANs angehören kann.

http://www25.nortelnetworks.com/library/tpubs/pdf/sw… hab ich mir angeschaut.

Dort ist es Fig. 1-30 auf Seite 1-52, und die versteh ich jetzt gar nicht mehr. Dort sind zwar die VLANs 1 und 2 so aufgeteilt, wie Du sagst, aber über alle Ports liegt derweil noch VLAN 3, was das Ganze irgendwie witzlos macht. Außerdem finde ich keinerlei Info darüber, wie der Switch damit umgeht, leider.

> Es ist unmöglich, einen Switchport ohne 802.1q und ohne
> protocol-based VLAN in
> mehr als ein VLAN zu packen. Das geht nicht, und es kann gar
> nicht gehen, weil
> ja die VLAN-Unterscheidung anhand irgendwelcher Kriterien
> getroffen werden muss.

Sehe ich nicht so, solange man einen einzigen reinen Layer-2
Switch betrachtet.

Klar, wir sind nur auf Layer 2/Ethernet im Moment.

Ausgangslage: Der Switch kennt als reines LAyer-2 gerät nur
die MAC Adressen aller angeschlossenen Geräte und die Ports.

Erstmal d’accord.

Unicast wäre damit 100% erschlagen.

Bleiben noch die Broadcasts.

und Multicasts, bei IPv6 z.B. gibt’s keine (Ethernet-)Broadcasts mehr.

MAC --> FF:FF:FF:FF:FF:FF: notgedrungen an alle Ports in
allen VLANS durchlassen

Scheint dass dieser Fall der 1. Knackpunkt ist.

Aye.

Nehmen wir an,
der broadcastende Rechner PC1 sitzt in VLAN1. Dann erfährt ein
Rechner PC2 in VLAN2, dass es die MAC

und IP-

Adresse PC1 gibt.

Information Leakeage!

PC1 seinerseits bekommt keine Kenntnisse zu PC2, da die ARP
Antwort, die ja kein Broadcast ist, weggefiltert wird.

Auch erstmal d’accord.

Also kann PC2 an PC1 nur Daten
durchbekommen indem er sie ebenfalls broadcastet. Es gibt kein
mir bekanntes Netzwerkprotokoll, das so kommuniziert.
Ausnahme: IP Multicasting, aber das ist normalerweise nicht im
Einsatz.

Bei IPv6 ist das weitgehend üblich. Alles, was bei IPv4 „ARP“ erledigt sowie - das ist hier wichtig! - das, was für IPv4 die default route erledigt und noch einiges mehr (router discovery, neighbour advertisements, next hop detection) wird bei IPv6 mit Multicasts gelöst. Damit sind einige ziemlich eklige Sachen möglich, und hier eben sogar VLAN-übergreifend. Man könnte ohne weitere Vorkehrungen bspw. problemlos jeglichen Internettraffic, der eigentlich zum Router gehen sollte, abfangen.

  1. Knackpunkt:
    FF:FF:FF:FF:FF:FF --> unbekannte (erfundene oder nicht
    gelernte) MAC

Dem L2 Switch bleibt nichts anderes übrig als das Paket
durchzulassen wie ein Broadcast, nur dass diesmal auch niemand
antwortet und niemand was lernt. Kann man also als Sonderfall
von Knackpunkt 1 betrachten.

Stichwort: CAM Table Overflow. Damit bringst Du den Switch extrem einfach dazu, alle Frames zu flooden, es gibt keine MAC Port VLAN Zuordnung mehr, alle haben Internet Access.

Wirklich funktionieren tut das desweiteren nur, wenn
ENTWEDER zwei Subnetze verwendet werden ODER der IP-Stack kaputt ist.
Letzteres führt zu Sicherheitsproblemen (Details auf Wunsch).

Es gibt auch eine Welt außerhalb von IP (Layer-3) Switchen.

Das ist nicht mehr für den Switch relevant, sondern eben auf Layer 3, führt aber ggf. auch zu Problemen mit der Zugriffssicherheit und kann auch IP Traffic abfangen.

Layer 2 ist zwar nicht State of the Art, aber manche fahren
auch mit einem 15 Jahre alten Golf rum und kommen vorwärts :smile:

Layer 2 ist unverzichtbar, und Ethernet ist schon fast Monopolist auf Layer 2. Es liegt aber immer ein Layer 3 darüber, und der besteht nahezu immer aus IP, weshalb man das nicht vergessen darf.

Ich finds übrigens angenehm, mit Dir zu diskutieren. Und wenn
ich jetzt einen Hochsicherheitstrakt auslegen müsste, wo ich
bestens ausgerüstete Angreifer auf jeder (!) Seite meiner
Installation befürchten mküsste, die nicht auf Einbruch
sodnern auf Ausbruch aus sind (fast alle ernstzunehmenden
Angriffe kommen von innen!) würde ich Dir sofort recht geben

50% aller(!) Angriffe kommen von innen, von den eigenen Mitarbeitern o.ä.,
und hier wäre das wirklich sehr einfach.

Hier gibg es aber nur um die Absicherung eines popeligen
Internetzugangs.

Das ist wohl richtig. Ich sehe allerdings keinen Vorteil der port-based Lösung gegenüber der mit 802.1q, sondern umgekehrt nur Vorteile von letzterem.

Naja, und dann wäre da noch die Frage, ob der Switch das wirklich über die MAC Port Zuordnung löst.

Gruß,

Malte

23

http://www25.nortelnetworks.com/library/tpubs/pdf/sw…
hab ich mir angeschaut.

Genau dieses. Ich hatte allerdings noch eine ältere Version ohne Hyperlinks, die ist etwas kleiner, deshalb die unterschiedlichen Seitenzahlen. Aber da die neuere Version hyperlinked ist habe ich sie natürlich sofort übernommen, und ab jetzt schauen wir die selben Seitenzahlen an :smile:

Dort ist es Fig. 1-30 auf Seite 1-52, und die versteh ich
jetzt gar nicht mehr. Dort sind zwar die VLANs 1 und 2 so
aufgeteilt, wie Du sagst, aber über alle Ports liegt derweil
noch VLAN 3, was das Ganze irgendwie witzlos macht.

VLAN3 beinhaltet den Drucker, und da der laut Gefechtsannahme von allen Geräten erreicht werden soll ist er (einziges) Mitglied von VLAN3, und VLAN3 hat Zugriff auf alle Ports, damit alle Ports auf den Drucker zugreifen können.

Du verstehst den Nortel Ansatz leichter, wenn Du beginnst, stur in VLANs zu denken statt in Ports, die Skizze und die Oberfläche verleitet irgendwie dazu in Ports zu denken, und dann bekommt man einen Knopf ins Hirn.

Deshalb ist es übrigens in Fig 1-33 notwendig, einen bestimmten Port nochmal an ein VLAN zuzuweisen, obwohl man das - rein instinktiv - eigentlich schon in 1-32 durch das Eintragen eines „U“ gemacht hat - denkt man.

Ich habe seinerzeit gut Geld verdient mit den Baystacks als Consultant und Trainer, und der Standardfehler bei VLANs war 1-33 nicht zu beachten. Steht nämlich ein Port auf dem Default (VLAN1), und klaut man ihm in 1-32 das „U“ bei VLAN1 und verpasst ihm dagegen eins in VLAN2 um ihn VLAN2 zuzuordnen ist er nirgendwo. Erst wenn man ihn zusätzlich in 1-33 auf VLAN2 umschaltet funktioniert er wieder.

Selektive Benutzerführung :smile: Nur die Harten kommen durch :smile:

und Multicasts, bei IPv6 z.B. gibt’s keine
(Ethernet-)Broadcasts mehr.

V6 wollen wir mal schön draußen lassen, das ist Layer 3 und wir haben ausgemacht, nur Layer 2 zu benützen :smile:

MAC --> FF:FF:FF:FF:FF:FF: notgedrungen an alle Ports in
allen VLANS durchlassen

Scheint dass dieser Fall der 1. Knackpunkt ist.

Aye.

Information Leakeage!

Harmlos.

PC1 seinerseits bekommt keine Kenntnisse zu PC2, da die ARP
Antwort, die ja kein Broadcast ist, weggefiltert wird.

Auch erstmal d’accord.

Also kann PC2 an PC1 nur Daten
durchbekommen indem er sie ebenfalls broadcastet. Es gibt kein
mir bekanntes Netzwerkprotokoll, das so kommuniziert.
Ausnahme: IP Multicasting, aber das ist normalerweise nicht im
Einsatz.

Bei IPv6 ist das weitgehend üblich.

… und wer IPV6 machen will soll meinetwegen taggen bis er umfällt :smile: Trifft hier *nicht* zu. Schon deshalb nicht, weil der Router aller Wahrscheinlichkeit nach von IPV6 keine Ahnung hat, Drucker idR auch nicht, und die PCs auch nur nur deswegen, weil Vista langsam in Mode kommt und die meisten nicht wissen, wie man IPV6 abschaltet. Die fragen mich dann immer, ob ihre Netzwerkkarte kaputt ist, weil da plötzlich so komische MAC (!) Adressen wie 2001:0db8:1234::1234 auftauchen :smile:

Man könnte ohne weitere Vorkehrungen bspw. problemlos
jeglichen Internettraffic, der eigentlich zum Router gehen
sollte, abfangen.

Kann man natürlich auch bei IPV4. Router per ARP Spoofing einkassieren, fertig. Bedeutet allerdings aus Sicht des Switches, dass es eine dopppelte MAC im Ethernet gibt. Keine Ahnung was der arme Hund in dieser Situation tut, vermutlich ist es Hersteller- und Firmware-abhängig. Begeistert wird er sicher nicht sein, und ich fürchte unser Angreifer hat auf Dauer auch keine rechte Freude damit :smile: Aber nochmal: das ist ein lokales Angriffsszenario, mit dem sich Sicherheitsfreaks in Hochsicherheitsumgebungen herumplagen müssen.

Stichwort: CAM Table Overflow. Damit bringst Du den Switch
extrem einfach dazu, alle Frames zu flooden, es gibt keine MAC
Port VLAN Zuordnung mehr, alle haben
Internet Access.

Da wage ich zu zweifeln, aber ich gebe zu, ich habe meinen armen Bay noch nie „gefloodet“. Ich behaupte, dass er nicht *alle* Ports floodet, sonden nur den Port an dem der Angreifer sitzt. Und ich sehe auch keinerlei Grund, warum der Switch in dieser Situation gleich die VLANs über Bord werfen sollte. Ich denke, er floodet dann nur in das VLAN in dem der Angreifer-Port sitzt.

Die Nagelprobe kann ich aber mit meinen Möglichkeiten nicht machen.

Ich finds übrigens angenehm, mit Dir zu diskutieren. Und wenn
ich jetzt einen Hochsicherheitstrakt auslegen müsste, wo ich
bestens ausgerüstete Angreifer auf jeder (!) Seite meiner
Installation befürchten mküsste, die nicht auf Einbruch
sodnern auf Ausbruch aus sind (fast alle ernstzunehmenden
Angriffe kommen von innen!) würde ich Dir sofort recht geben

50% aller(!) Angriffe kommen von innen, von den eigenen
Mitarbeitern o.ä.,
und hier wäre das wirklich sehr einfach.

Ich habe sogar was von 80% gelesen. Wie auch immer man diese Zahlen erhoben hat :smile: Umfage an die Admins der Fortune-500: klauen Sie Ihrem Arbeitgeber Daten? Wir versichern, ihre Angaben streng vertraulich zu behandeln (grins).

Das ist wohl richtig. Ich sehe allerdings keinen Vorteil der
port-based Lösung gegenüber der mit 802.1q, sondern umgekehrt
nur Vorteile von letzterem.

Eins hast Du genannt: man muss sich mit IP Subnetzen herumplagen, die man eigentlich nicht braucht. Mit allen blöden Nebeneffekten eines Multi-Homing Hosts. Und einfach mal so einen shared Port definieren ist nicht. Man braucht sie für Drucker und Router.

aja, und dann wäre da noch die Frage, ob der Switch das
wirklich über die MAC Port Zuordnung löst.

Tut er. Es bleibt ihm ja gar nichts anderes übrig.

Warum ich behaupte, dass es so ist obwohl ich keine technische Doku von Bay habe? Weil ich meine ersten VLAns vor 15 Jahren in einer völlig anderen Welt gebaut habe. Damals gab es noch IP, NETBEUI, IPX und DECNET in meinem Netz, IP war nich mal die größte Welt, und ich habe die komplette Evolution durchleiden müssen: erst Hubs, dann Layer-2 Switche, dann Layer-2 Switche mit Layer-2 VLANs. Von Layer3 hatten die keine Ahnung. Layer-3 Switches kamen dann etwas später in Mode, aber man hat die Layer-2 Switchmöglichkeit zumindest bei Bay nie ganz ausgebaut, sie hat wie man sieht durchaus ihre Lebensberechtigung.

Schön ist doch, wenn man die Wahl hat!

…Armin

24

Dort ist es Fig. 1-30 auf Seite 1-52, und die versteh ich
jetzt gar nicht mehr. Dort sind zwar die VLANs 1 und 2 so
aufgeteilt, wie Du sagst, aber über alle Ports liegt derweil
noch VLAN 3, was das Ganze irgendwie witzlos macht.

VLAN3 beinhaltet den Drucker, und da der laut Gefechtsannahme
von allen Geräten erreicht werden soll ist er (einziges)
Mitglied von VLAN3, und VLAN3 hat Zugriff auf alle Ports,
damit alle Ports auf den Drucker zugreifen können.

Wieso hat VLAN3 Zugriff auf alle Ports? Wo ist das denn konfiguriert?

und Multicasts, bei IPv6 z.B. gibt’s keine
(Ethernet-)Broadcasts mehr.

V6 wollen wir mal schön draußen lassen, das ist Layer 3 und
wir haben ausgemacht, nur Layer 2 zu benützen :smile:

IPv6 ist nur ein Beispiel dafür, dass man Ethernet-Multicasts auch nicht
vergessen darf. Auf Layer 2 :wink:

Man könnte ohne weitere Vorkehrungen bspw. problemlos
jeglichen Internettraffic, der eigentlich zum Router gehen
sollte, abfangen.

Kann man natürlich auch bei IPV4. Router per ARP Spoofing
einkassieren, fertig. Bedeutet allerdings aus Sicht des
Switches, dass es eine dopppelte MAC im Ethernet gibt. Keine
Ahnung was der arme Hund in dieser Situation tut, vermutlich
ist es Hersteller- und Firmware-abhängig.

Es kann keine doppelten MACs geben, es kommt dann zu „Ethernet FlipFlops“.
Ein Angreifer würde allerdings so sehr flooden, dass die echte MAC keine Rolle mehr spielt.

ein lokales Angriffsszenario, mit dem sich Sicherheitsfreaks
in Hochsicherheitsumgebungen herumplagen müssen.

Das liegt im Auge des Betrachters :wink: Für mich gehört das schon zu den Basics.
Ich komme allerdings aus einem ganz anderen Umfeld und bin geprägt.

Stichwort: CAM Table Overflow. Damit bringst Du den Switch
extrem einfach dazu, alle Frames zu flooden, es gibt keine MAC
Port VLAN Zuordnung mehr, alle haben
Internet Access.

Da wage ich zu zweifeln, aber ich gebe zu, ich habe meinen
armen Bay noch nie „gefloodet“. Ich behaupte, dass er nicht
*alle* Ports floodet, sonden nur den Port an dem der Angreifer
sitzt. Und ich sehe auch keinerlei Grund, warum der Switch in
dieser Situation gleich die VLANs über Bord werfen sollte. Ich
denke, er floodet dann nur in das VLAN in dem der
Angreifer-Port sitzt.

Nun, es gibt nur eine CAM-Table, und die ist der Ort, an dem die Zuordnung MAC Port stattfindet. Wenn die voll ist mit Datenmüll, dann flooded der Switch gezwungenermaßen auf alle(!) Ports, denn von VLANs weiß er auch nichts mehr, die hängen ja von der MAC Port Zuordnung ab. Bei 802.1q hingegen ist die CAM-Table dafür egal, weil die VLAN-Zuordnung per Tag stattfindet.

Er flooded jeglichen(!) Traffic, weil er schlicht nicht weiß, auf welchem Port die Ziel-MAC sitzt.

Gruß,

Malte

25

Dort ist es Fig. 1-30 auf Seite 1-52, und die versteh ich
jetzt gar nicht mehr. Dort sind zwar die VLANs 1 und 2 so
aufgeteilt, wie Du sagst, aber über alle Ports liegt derweil
noch VLAN 3, was das Ganze irgendwie witzlos macht.

VLAN3 beinhaltet den Drucker, und da der laut Gefechtsannahme
von allen Geräten erreicht werden soll ist er (einziges)
Mitglied von VLAN3, und VLAN3 hat Zugriff auf alle Ports,
damit alle Ports auf den Drucker zugreifen können.

Wieso hat VLAN3 Zugriff auf alle Ports? Wo ist das denn
konfiguriert?

Ich war ungenau, Sorry. „Zugriff auf alle *belegten“ Ports" hätte ich sagen sollen. Das Bildchen dazu ist 1-32. Du siehst da ein „U“ bei Ports 2,4,6,8,10,11, und das sind nun mal alle wo was dran hängt. Sobald man wie in 1-34 gezeigt Port 8 von VLAN1 auf VLAN3 umschaltet kommt er sozusagen in den Genuss der Definition von 1-32, und kann dann mit allen Geräten reden, und sie mit ihm.

Ein neues Gerät dagegen, das sagen wir mal an Port 1 angestöpselt würde, landet bei den Defaults, also in VLAN1, und kann daher erst mal nur mit den anderen Geräten in VLAN1, könnte also z.B. erst mal nicht drucken.

Irgendwie verquer, die Benutzerführung, aber es macht durchaus Sinn. Du musst Dich nur von der Vorstellung lösen, dass man in 1-32 eine Portzuweisung macht. Man macht eigentlich so eine Art Zugriffsmaske für VLAN3. Die wird aber für Port 8 erst dann wichtig, wenn man zusätzlich 1-34 konfiguriert hat. Solange man das nicht tut gilt für Port 8 das Bild 1-31, und da man dort bei Port 8 das „U“ nicht entfernt hat bleibt der Drucker erst mal auf VLAN1 kleben, egal was man in 1-32 an Port 8 einträgt.

IPv6 ist nur ein Beispiel dafür, dass man Ethernet-Multicasts
auch nicht
vergessen darf. Auf Layer 2 :wink:

Es gibt im Ethernet keine Multicast-Adressen. Es gibt nur Broadcast und Unicast.

IPV4: Multicasting wird „emuliert“, wenn ich das mal so sagen darf. Bei dummen (Layer-2) Systemen wird aus einem IP Multicast ein Ethernet Broadcast, bei intelligenteren (mit Layer-3 Switch) hört der Switch auf die IP Multicast-Adressen 224.x.x.x und forwardet Pakete nur an Member dieser Mutlicast-Gruppe. Dazu muss der Client der Gruppe erst mal schön brav beitreten. Dazu gibt es ein eigenes Protokoll. Wir wollten aber auf Layer 2 bleiben. Würde ein Layer-2 Switch IP Mutlicasting irgendwie berücksichtigen können, wäre es kein Layer-2 Switch :smile:

IPV6: keine Ahnung :smile: Your call. Ich lerne gerne.

Kann man natürlich auch bei IPV4. Router per ARP Spoofing
einkassieren, fertig. Bedeutet allerdings aus Sicht des
Switches, dass es eine dopppelte MAC im Ethernet gibt. Keine
Ahnung was der arme Hund in dieser Situation tut, vermutlich
ist es Hersteller- und Firmware-abhängig.

Es kann keine doppelten MACs geben, es kommt dann zu „Ethernet
FlipFlops“.

Es kann so viele geben wie ich will, ich kann das ja bei vielen Ethernet-Karten durchaus provozieren. „Soll keine doppelten geben“ wäre richtig. Aber wir unterhalten uns ja darüber, was passiert, wenn ein Bösewicht absichtlich eine doppelte, real existierende MAC Adresse einfügt. Antwort: er kann einen Host ein paar Pakete lang „übernehmen“. Sobald der echte Besitzer der MAC auch mal was sagt verliert der Angreifer den Port wieder.

Aber darum gings nicht, auch nicht darum, ob man mit einem solchen Stootermechanismus ernsthaft daten transportieren kann.

Aus einem VLAN ausbrechen kann man damit nicht, und man kann auch kein VLAN übernehmen: wie Du am Baystack Beispiel sehen kannst werden VLANs dort ausschließlich den physikalischen Ports zugewiesen, und nicht den MAC Adressen. Allenfalls könnte es natürlich sein, dass irgendeine ungeschickt programmierte Firmware sich leimen lässt, wenn sie intern die Layer-2 auch die VLANs über einen (völlig unnötigen!) Zwischenschritt über eine MACPort Tabelle verwaltet. Müsste ich mal ausprobieren, halte ich aber für extrem unwahrscheinlich.

Stichwort: CAM Table Overflow. Damit bringst Du den Switch
extrem einfach dazu, alle Frames zu flooden, es gibt keine MAC
Port VLAN Zuordnung mehr, alle haben
Internet Access.

Da wage ich zu zweifeln, aber ich gebe zu, ich habe meinen
armen Bay noch nie „gefloodet“. Ich behaupte, dass er nicht
*alle* Ports floodet, sonden nur den Port an dem der Angreifer
sitzt. Und ich sehe auch keinerlei Grund, warum der Switch in
dieser Situation gleich die VLANs über Bord werfen sollte. Ich
denke, er floodet dann nur in das VLAN in dem der
Angreifer-Port sitzt.

Nun, es gibt nur eine CAM-Table, und die ist der Ort, an dem
die Zuordnung MAC Port stattfindet.

Ich sehe nicht den geringsten Grund, warum ein Switch nicht eine CAM Table *pro VLAN* führen sollte. Das schiene mir nicht nur eine mögliche, sondern sogar die einfachste Möglichkeit, VLANs zu verwalten :smile: Und selbst wenn er nur eine hat und ich sie floode setzt das noch lange nicht die Zuweisung PortVLAN außer Kraft, da diese - wie schon gesagt - beim Layer-2 Switch mit den physikalischen Portnummern arbeiten kann und nicht unbedingt den Umweg über die MAC Adressen nehmen muss.

Er flooded jeglichen(!) Traffic, weil er schlicht nicht weiß,
auf welchem Port die Ziel-MAC sitzt.

Aber er weiß, welcher physikalische Port zu welchem VLAN gehört, und das genügt, um die Flut auf die VLANs einzuschränken, bei denen der floodende Port Mitglied ist.

Meine ich.

…Armin

26

IPv6 ist nur ein Beispiel dafür, dass man Ethernet-Multicasts
auch nicht
vergessen darf. Auf Layer 2 :wink:

Es gibt im Ethernet keine Multicast-Adressen. Es gibt nur
Broadcast und Unicast.

http://www.cavebear.com/archive/cavebear/Ethernet/mu…

Es kann keine doppelten MACs geben, es kommt dann zu „Ethernet
FlipFlops“.

Es kann so viele geben wie ich will, ich kann das ja bei
vielen Ethernet-Karten durchaus provozieren. „Soll keine
doppelten geben“ wäre richtig.

In der CAM-Table gibt es keine Duplikate!

Aber wir unterhalten uns ja

darüber, was passiert, wenn ein Bösewicht absichtlich eine
doppelte, real existierende MAC Adresse einfügt. Antwort: er
kann einen Host ein paar Pakete lang „übernehmen“. Sobald der
echte Besitzer der MAC auch mal was sagt verliert der
Angreifer den Port wieder.

Wenn der Angreifer Frames flooded, kann er „fast alle“ Frames abgreifen, weil die echten MACs immer wieder sofort verschwinden (durch das Flooding).

Aus einem VLAN ausbrechen kann man damit nicht, und man kann
auch kein VLAN übernehmen: wie Du am Baystack Beispiel sehen
kannst werden VLANs dort ausschließlich den physikalischen
Ports zugewiesen, und nicht den MAC Adressen.

Du sagtest, der Switch entscheidet anhand der MAC-Tupel, wenn ein Port mehr als einem VLAN zugewiesen ist. Diese Zuweisung hast Du bei einem Overflow nicht mehr.

Gruß,

Malte

27

IPv6 ist nur ein Beispiel dafür, dass man Ethernet-Multicasts
auch nicht
vergessen darf. Auf Layer 2 :wink:

Es gibt im Ethernet keine Multicast-Adressen. Es gibt nur
Broadcast und Unicast.

http://www.cavebear.com/archive/cavebear/Ethernet/mu…

Der Punkt geht an Dich :smile:

Ich würde trotzdem annehmen, dass ein reiner L2 Switch den Multicst Verkehr auf alle Ports *des selben VLAN* geben muss, da er am IGMP ja nicht teilnehmen kann.

Rausfinden werde ich das nicht mein Bay kann IGMP. zu dem thema heißt es im Handbuch:

Note: Because IGMP snooping is set up per VLAN, all IGMP changes are
implemented according to the VLAN configuration for the specified ports.

Will heißen, dass Multicasting, Ethernet FF:FF:FF:FF:FF:FF oder x1:FF:FF:FF:FF:FF hin oder her, das VLAN auch nicht kompromittieren sollte.

Wenn der Angreifer Frames flooded, kann er „fast alle“ Frames
abgreifen, weil die echten MACs immer wieder sofort
verschwinden (durch das Flooding).

Müsste man mal real machen. je nach Protokoll kann „fast alle“ alles bedeuten, von geht fast alles bis geht gar nix.

Aus einem VLAN ausbrechen kann man damit nicht, und man kann
auch kein VLAN übernehmen: wie Du am Baystack Beispiel sehen
kannst werden VLANs dort ausschließlich den physikalischen
Ports zugewiesen, und nicht den MAC Adressen.

Du sagtest, der Switch entscheidet anhand der MAC-Tupel, wenn
ein Port mehr als einem VLAN zugewiesen ist. Diese Zuweisung
hast Du bei einem Overflow nicht mehr.

Muss nicht sein. Der Switch hat, nehme ich an, eine Tabelle

Physikalischer Port --> VLANS, für die er freigeschaltet ist.

Bleiben wir bei 1-31. An Port 6 (VLAN1) läuft irgendein Paket ein. Es ei meinetwegen für die MAC an Port 8 bestimmt.

Switch ratlos muss nun entscheiden, wohin er das Paket schickt. Schneller Blick in die VLAN Einstellung von Port 6 (analog 1-34). Aha, gehört zu VLAN1. Zweiter Blick in die VLAN Tabelle von VLAN1 Die ist nicht abgebildet - muss aber wenn man den Text unter der Skizze liest, lauten

---- -U-U- -U–

Dritter Blick in die CAM. Ist die Ziel-MAC Adresse dort verzeichnet?

Annahme 1: ja, und sie hängt an Port 8 (normalfall). Also Zustellung auf Port 8 ins Auge fassen. 3. Blick in die Porteinstellungen von Port 8. Ist er VLAN1 zugewiesen? Ja ist er --> Paket an Port 8 zustellen, alles OK.

Annahme 2: ja, aber sie hängt an Port 4 (böser ARP Spoofer). 3. Blick in die Porteinstellungen von Port 4. Ist er VLAN1 zugewiesen? Nein --> Paket nicht zustellen, alles OK. Spoofer wartet vergebens.

Annahme 3: nein, sie ist nirgendwo verzeichnet. Ob sie das nie war oder per CAM Overflow rausgekegelt wurde interessiert uns nicht, das Endresultat ist dasselbe. Paket zustellen an alle Ports, die für VLAN1 aktiviert wurden. Paket geht raus an 6,8,11 --> VLAN ist weiterhin dicht.

Wo ist das Leck?

…Armin

28

CAM Table Overflow und port-based VLANs vs. 802.1q

Wenn der Angreifer Frames flooded, kann er „fast alle“ Frames
abgreifen, weil die echten MACs immer wieder sofort
verschwinden (durch das Flooding).

Müsste man mal real machen. je nach Protokoll kann „fast alle“
alles bedeuten, von geht fast alles bis geht gar nix.

es bedeutet immer „quasi alles“, weil folgendes passiert:

  • Oskar schickt Frames mit zufälligen Mac-Adressen so schnell er kann.
  • Jede bislang unbekannte MAC landet in der CAM-Table
  • Die CAM-Table füllt sich, und läuft über, jede neue zufällige MAC verdrängt
    eine alte.
  • Die MAC von Bob verschwindet aus der CAM-Table, Frames von Alice an Bob werden geflooded.
  • Jede Antwort von Bob führt zu einem CAM-Table Eintrag, und dann können Frames von Alice an Bob wieder regulär zugestellt werden.
  • Jeder neue CAM-Table Eintrag von Bob lebt nicht lang, weil Oskar weiter flooded, Bob ist also stets nur kürzeste Zeit bekannt, „blitzt kurz auf“
  • reguläre Kommunikation zwischen Alice und Bob ist quasi unmöglich, durch die Layer 3- und 4-Mechanismen werden Pakete und Segmente mehrfach gesendet
  • Oskar kann alles mitlesen.

Du sagtest, der Switch entscheidet anhand der MAC-Tupel, wenn
ein Port mehr als einem VLAN zugewiesen ist. Diese Zuweisung
hast Du bei einem Overflow nicht mehr.

Muss nicht sein. Der Switch hat, nehme ich an, eine Tabelle

Zitat von Dir:

Die Filterlogik im Switch hat nun nicht die geringsten Probleme, „normale“
(Unicast) MAC Pakete durchzulassen oder nicht: wenn Quell- und Zielport ein
gemeinsames VLAN haben: durchlassen, sonst sperren. Ob Quell- und Zielport
dabei auch noch in einem anderen, nicht gemeinsamen VLAN ein Beinchen haben
interessiert nicht.

Wenn die CAM-Table nur Müll enthält, dann weiß der Switch nicht, an welchem Port Bobs MAC hängt. Er weiß somit auch nicht, ob Bob im selben VLAN wie Alice hängt. Was tut der Switch? Nun, er hat die Wahl zwischen „flooden“ und „verwerfen“. Ich behaupte, er flooded.

Annahme 3: nein, sie ist nirgendwo verzeichnet. Ob sie das nie
war oder per CAM Overflow rausgekegelt wurde interessiert uns
nicht, das Endresultat ist dasselbe. Paket zustellen an alle
Ports, die für VLAN1 aktiviert wurden. Paket geht raus an
6,8,11 --> VLAN ist weiterhin dicht.

Ah, verstehe. Du meinst, der Switch merkt sich bei unbekannten Frames zumindest den Quellport, damit das Quell-VLAN und flooded dann nur auf Ziel-Ports, die im selben VLAN hängen? Hm.

Klingt nach einem komplizierten Design in den Bausteinen des Switches, weil Logik zentral vorgehalten werden muss, die bspw. bei 802.1q komplett in die ASICS der Switchports ausgelagert werden kann, ohne Tabellen - weil die Information im Tag des Frames transportiert wird.

Außerdem finde ich das Konfigurationskonzept von port-based VLANs - insbesondere bei Nortel - echt kompliziert und fehleranfällig.

Wie dem auch sei, das mag alles daran liegen, dass ich bislang nur mit Switches von Cisco oder Klonen (Dell, Force10, Foundry) gearbeitet habe und deshalb einem Tunnelblick unterliege. Vielleicht weichen die Juniper-Switches den wieder etwas auf, die funktionieren erfrischend anders :wink:

Wir können uns also gerne darauf einigen, dass Broadcasts offensichtlich ein Problem sind, der Rest aber nicht unbedingt.

Gruß,

Malte

29
  • reguläre Kommunikation zwischen Alice und Bob ist quasi
    unmöglich, durch die Layer 3- und 4-Mechanismen werden Pakete
    und Segmente mehrfach gesendet
  • Oskar kann alles mitlesen.

Damit es kein Missverständnis gibt: ich habe nie eine solche Attacke live erlebt, und kenne auch niemanden der das hätte, oder der in der Lage wäre, es zu tun.

Ah, verstehe. Du meinst, der Switch merkt sich bei unbekannten
Frames zumindest den Quellport, damit das Quell-VLAN und
flooded dann nur auf Ziel-Ports, die im selben VLAN hängen?
Hm.

Jo. Könnte ich mir sogar gut vorstellen, dass er das bei *jedem* Frame macht. Weils einfach ist, weils logisch ist, und weil ich es auch so machen würde :smile: Was aber nicht heißt, dass es so sein muss :smile:

Klingt nach einem komplizierten Design in den Bausteinen des
Switches, weil Logik zentral vorgehalten werden muss, die
bspw. bei 802.1q komplett in die ASICS der Switchports
ausgelagert werden kann, ohne Tabellen - weil die Information
im Tag des Frames transportiert wird.

Wie es genau gemacht würde, da kann ich nicht mal spekulieren. Da aber die ganze Logik eines modernen Switches, incl. Traffic-Shaping, QOS, L3 Sperenzchen, Port-Statistik und diversen DOS Schutzmechanismen auch nicht gerade simpel ist traue ich es den Designern durchaus zu.

Außerdem finde ich das Konfigurationskonzept von port-based
VLANs - insbesondere bei Nortel - echt kompliziert und
fehleranfällig.

Da sind wir uns durchaus einig :smile: Aber es ist ein 10 jahre alter Dinosaurier, da hat man sich noch nicht so sehr darauf konzentriert, dass man sie konfigurieren kann ohne je einen Blick ins Handbuch geworfen zu haben. Das übrigens auch nicht gerade klar ist, und außerdem sind einige Fehler drin (ich nehme an, die falschen Beschriftungen in Skizze 1-30 sind Dir aufgefallen).

Ich würde deshalb sogar vermuten, dass er seine interne Filterlogik ziemlich ungefiltert auf den Bildschirm klatscht, aber das ist Spekulation.

Wir können uns also gerne darauf einigen, dass Broadcasts
offensichtlich ein Problem sind, der Rest aber nicht
unbedingt.

Für Broadcasts ist die selbe L2 Logik anwendbar. Einfach auf allen Ports raussenden die dem VLAN angehören, in dem der Port sitzt, der das Broadcast empfangen hat.

Ein Informationsleck ist auch da nicht vorhanden, und ein 802.11q tagged VLAN verhält sich bei Broadcasts meiner Meinung nach keinen Deut anders als ein portbasiertes.

…Armin