Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
vlan vraagje
21-03-2017, 00:20 door Anoniem, 34 reacties
Momenteel heb ik een netwerk door middel van een managed switch opgedeeld in 2 vlans om 2 groepen te scheiden. De huidige situatie is nu router aangesloten op port 1 van de switch, apparaat op port 2 en een apparaat op port 3. Nu vroeg ik mij af of het mogelijk is voor een apparaten op port 3 http verkeer te lezen afkomstig van apparaten op port 2 en anders om.
Reacties (34)
Deze beschrijving geeft wat weinig info. zijn ze tagged, is er een connection vlan etc.
Dus een meer fundamenteel antwoord.
Een switch is om apparaten te verbinden, niet om ze te beveiligen. Een firewall is om te beveiligen, daar open je langzaam toegang als je het goed doet.
Je bent met een switch dus eigenlijk langzaam aan het kijken wat je dicht kan zetten en dit gaat je nooit een veilige situatie opleveren.
Buiten dat er ook dingen zijn als vlan hopping (https://en.wikipedia.org/wiki/VLAN_hopping) zal een switch als hij in paniek raakt met geheugen e.d. doen waar die voor ontworpen is. namelijk verbinden.
Dus met b.v. mac spoofing zijn mac tabellen vol laten lopen en je switch veranderd zichzelf in een hub om te doen waar hij voor ontworpen is.
Tevens is je vraag over http (applicatie en laag 7 in verkeer, en een switch kijkt naar mac en laag 2 (beetje 3 een ip nummer) niet naar welke applicatie taal (laag 7) er wordt gesproken. Een switch ziet dus geen verschil tussen http, https, ftp, mail etc etc etc) kijkt alleen naar de bestemming van een pakketje.
Vlan is om het verkeer op bepaalde segmenten te reduceren zodat je bandbreedte op segmenten niet wordt beïnvloed door verkeer bedoeld op andere segmenten. Het is geen vorm van beveiliging.
Dus een meer fundamenteel antwoord.
Een switch is om apparaten te verbinden, niet om ze te beveiligen. Een firewall is om te beveiligen, daar open je langzaam toegang als je het goed doet.
Je bent met een switch dus eigenlijk langzaam aan het kijken wat je dicht kan zetten en dit gaat je nooit een veilige situatie opleveren.
Buiten dat er ook dingen zijn als vlan hopping (https://en.wikipedia.org/wiki/VLAN_hopping) zal een switch als hij in paniek raakt met geheugen e.d. doen waar die voor ontworpen is. namelijk verbinden.
Dus met b.v. mac spoofing zijn mac tabellen vol laten lopen en je switch veranderd zichzelf in een hub om te doen waar hij voor ontworpen is.
Tevens is je vraag over http (applicatie en laag 7 in verkeer, en een switch kijkt naar mac en laag 2 (beetje 3 een ip nummer) niet naar welke applicatie taal (laag 7) er wordt gesproken. Een switch ziet dus geen verschil tussen http, https, ftp, mail etc etc etc) kijkt alleen naar de bestemming van een pakketje.
Vlan is om het verkeer op bepaalde segmenten te reduceren zodat je bandbreedte op segmenten niet wordt beïnvloed door verkeer bedoeld op andere segmenten. Het is geen vorm van beveiliging.
Zonder meer informatie te hebben is het antwoord: NEE
De functie van een switch is heel erg simpel, stuur informatie door van poort X naar poort Y en niet naar poort Z. Dit geldt voor al het unicast verkeer zoals HTTP. Alleen Multicast protocollen of broadcast protocollen gaan naar meerdere poorten.
https://nl.wikipedia.org/wiki/Unicast
Een goede switch stopt ook met werken wanneer zijn ARP/MAC tabellen vol lopen ter voorkoming van VLAN/PORT hopping. De enige methode om unicast af te luisteren is door poorten te dupliceren.
De functie van een switch is heel erg simpel, stuur informatie door van poort X naar poort Y en niet naar poort Z. Dit geldt voor al het unicast verkeer zoals HTTP. Alleen Multicast protocollen of broadcast protocollen gaan naar meerdere poorten.
https://nl.wikipedia.org/wiki/Unicast
Een goede switch stopt ook met werken wanneer zijn ARP/MAC tabellen vol lopen ter voorkoming van VLAN/PORT hopping. De enige methode om unicast af te luisteren is door poorten te dupliceren.
21-03-2017, 10:30 door
PietdeVries
In principe kan je met VLANs verkeer op een switch vrij goed scheiden. Er zijn wat technieken om toch van het ene VLAN naar het andere te komen, maar dit is niet iets wat je al te gemakkelijk voor elkaar krijgt. Daarmee is voor huis-tuin-en-keuken verkeer een VLAN toepassing dus goed genoeg om veilig te zijn.
Als je nu met een apparaat in VLAN 3 het verkeer van een apparaat in VLAN 2 wil sniffen dan komt 't er eigenlijk op neer dat je je moet verdiepen in de VLAN-hopping tools en exploits: zonder hacks gaat dat niet lukken: alhoewel het verkeer fysiek over dezelfde kabels gaat wordt 't door de software goed gescheiden.
Het is mogelijk om een switch zo te configureren dat 'ie het verkeer voor -zeg- poort 2 ook kopieert naar poort 3, maar dat is meer een toepassing en geen beveiligingsgat of hack.
Als je nu met een apparaat in VLAN 3 het verkeer van een apparaat in VLAN 2 wil sniffen dan komt 't er eigenlijk op neer dat je je moet verdiepen in de VLAN-hopping tools en exploits: zonder hacks gaat dat niet lukken: alhoewel het verkeer fysiek over dezelfde kabels gaat wordt 't door de software goed gescheiden.
Het is mogelijk om een switch zo te configureren dat 'ie het verkeer voor -zeg- poort 2 ook kopieert naar poort 3, maar dat is meer een toepassing en geen beveiligingsgat of hack.
TS, heb je een router waar je de vlans hebt aangemaakt? Met alleen een managed switch gaat het niet lukken.
21-03-2017, 11:21 door
Erik van Straten
21-03-2017, 11:20 door PietdeVries: Er zijn wat technieken om toch van het ene VLAN naar het andere te komen, maar dit is niet iets wat je al te gemakkelijk voor elkaar krijgt.
https://www.security.nl/posting/507852/Cisco+ontdekt+ernstig+ongepatcht+IOS-lek+in+CIA-arsenaal
21-03-2017, 15:17 door
PietdeVries
Door Erik van Straten:
21-03-2017, 11:20 door PietdeVries: Er zijn wat technieken om toch van het ene VLAN naar het andere te komen, maar dit is niet iets wat je al te gemakkelijk voor elkaar krijgt.
https://www.security.nl/posting/507852/Cisco+ontdekt+ernstig+ongepatcht+IOS-lek+in+CIA-arsenaalUhm... Ja. Dat is een zero-day gevonden in Cisco switches die het Cluster Management protocol gebruiken. Ik wil er wel een goede fles wijn op zetten dat dit niet het scenario is waar de OP op doelt.
Maar tuurlijk - het is mogelijk om uit een VLAN te breken. Er zijn tooltjes voor, en daar is vaak ook wel weer wat tegen te doen, maar als ik de vraag zo lees denk ik niet dat dit allemaal relevant is hier.
21-03-2017, 15:54 door
Erik van Straten
21-03-2017, 15:17 door PietdeVries: Dat is een zero-day gevonden in Cisco switches die het Cluster Management protocol gebruiken.
Uit [1] (vet toegevoegd door mij):The bug is in the default configuration of affected devices, even if the user doesn't have switch clusters configured, and can be exploited over either IPv4 or IPv6.
21-03-2017, 15:17 door PietdeVries: Ik wil er wel een goede fles wijn op zetten dat dit niet het scenario is waar de OP op doelt.
Vermoedelijk niet, maar aangezien er beheerders van credit-card-transactie-websites bestaan die menen dat de beveiliging van hun website zo goed is dat ze geen https nodig hebben [2], kijk ik nergens meer van op...[1] http://www.theregister.co.uk/2017/03/19/cisco_goes_public_with_its_first_vault7_response/
[2] https://www.security.nl/posting/507976/Bedrijf+dat+inloggen+via+http+aanbiedt+hekelt+Firefox-melding
21-03-2017, 16:16 door
PietdeVries
Door Erik van Straten:Vermoedelijk niet, maar aangezien er beheerders van credit-card-transactie-websites bestaan die menen dat de beveiliging van hun website zo goed is dat ze geen https nodig hebben [2], kijk ik nergens meer van op...
[2] https://www.security.nl/posting/507976/Bedrijf+dat+inloggen+via+http+aanbiedt+hekelt+Firefox-melding
[2] https://www.security.nl/posting/507976/Bedrijf+dat+inloggen+via+http+aanbiedt+hekelt+Firefox-melding
Ja - da's een mooi verhaal! Leest bijna als een jongensboek! Je ziet het zo voor je: een arrogante redneck uit Texas die de vreemde nerds van FireFox wel even de oren zou wassen. Nog voordat de inkt van z'n klacht droog was kwam 'little Bobby Tables' langs. Zeker de link naar Reddit is de moeite waard :-)
https://www.reddit.com/r/programming/comments/60jc69/company_with_an_httpserved_login_form_filed_a/
(TS)
bedankt boor de antwoorden. Wat meer informatie.
De apparaten achter de switch hebben hun eigen software firewall, het is dan ook zeker niet mijn bedoeling dat de switch als "firewall" tussen 2 groepen apparaten in het netwerk gaat functioneren. Voornamelijk alleen verkeer scheiden en via QoS en bandbreedte beheer de ene groep wat voortrekken op de andere groep. Hierbij vroeg ik mij af nu er dus vlans zijn of dit ook betekent dat apparaten op port 3 dus niet meer zomaar het verkeer kunnen zien van apparaten op port 2. Dit echter zeker geen vereiste (gevoelige zaken als bankieren gaan over https), maar zou wel zeker een mooie extra zijn.
Op de router zelf staat niets ingesteld van vlan.
De switch bevat ook DoS prevention, ik weet niet of dat ook tegen gaat dat zomaar iemand het geheugen van het ding kan vullen?
Weet niet of dit de extra nodige info is om de vraag beter te kunnen beantwoorden, alhoewel als ik de artikelen van de heer van Straten goed begrijp er momenteel wss toch wel een kwetsbaarheid is die misbruikt kan worden.
bedankt boor de antwoorden. Wat meer informatie.
De apparaten achter de switch hebben hun eigen software firewall, het is dan ook zeker niet mijn bedoeling dat de switch als "firewall" tussen 2 groepen apparaten in het netwerk gaat functioneren. Voornamelijk alleen verkeer scheiden en via QoS en bandbreedte beheer de ene groep wat voortrekken op de andere groep. Hierbij vroeg ik mij af nu er dus vlans zijn of dit ook betekent dat apparaten op port 3 dus niet meer zomaar het verkeer kunnen zien van apparaten op port 2. Dit echter zeker geen vereiste (gevoelige zaken als bankieren gaan over https), maar zou wel zeker een mooie extra zijn.
Op de router zelf staat niets ingesteld van vlan.
De switch bevat ook DoS prevention, ik weet niet of dat ook tegen gaat dat zomaar iemand het geheugen van het ding kan vullen?
Weet niet of dit de extra nodige info is om de vraag beter te kunnen beantwoorden, alhoewel als ik de artikelen van de heer van Straten goed begrijp er momenteel wss toch wel een kwetsbaarheid is die misbruikt kan worden.
Ja hoor. Er vanuit gaande dat de router het verkeer tussen de twee vlan's kan routeren (directly connected vlan's via een trunk op port 1) kun jij met een ACl's op je router http verkeer filteren tussen vlan's op port 2 en port 3.
Volgens mij is het simpel wat TS wil:
Switch in L3 zetten en 3 SVI's aanmaken en een extended ACL configureren, Port security, ARP inspection, IP source guard en storm control instellen tegen spoofing en DoS. ARP flooding zal alleen een goedkope pruts switch in hubmode zetten. VLAN hopping kan voorkomen worden met correct gebruik van access ports en trunks.
Dit is natuurlijk geen echte beveiliging maar TS kan wel bereiken wat hij wil.
Een trunk naar VLAN aware router kan uiteraard ook, maar dan krijg je daar een bottleneck. Als je switch alleen L2 is heb je geen keuze. Wat je ook wel eens ziet als het budget krap is: dubbel NAT parallel voor elk netwerksigment met goedkope (liefst verschillende) pruts routertjes en dan NAT en firewall rules aanmaken.
De beste beveiliging echter, is de stekker uit het stopcontact trekken en het apparaat weggooien of niet gebruiken.
Switch in L3 zetten en 3 SVI's aanmaken en een extended ACL configureren, Port security, ARP inspection, IP source guard en storm control instellen tegen spoofing en DoS. ARP flooding zal alleen een goedkope pruts switch in hubmode zetten. VLAN hopping kan voorkomen worden met correct gebruik van access ports en trunks.
Dit is natuurlijk geen echte beveiliging maar TS kan wel bereiken wat hij wil.
Een trunk naar VLAN aware router kan uiteraard ook, maar dan krijg je daar een bottleneck. Als je switch alleen L2 is heb je geen keuze. Wat je ook wel eens ziet als het budget krap is: dubbel NAT parallel voor elk netwerksigment met goedkope (liefst verschillende) pruts routertjes en dan NAT en firewall rules aanmaken.
De beste beveiliging echter, is de stekker uit het stopcontact trekken en het apparaat weggooien of niet gebruiken.
Ik wil een ondersteunend voorbeeld aanreiken.
Belangrijk hierin vind ik om het volgende in de gaten te houden:
Als verkeer aanwezig is, kan dit in twee vormen voorkomen;
"Tagged"-verkeer, heeft een VLAN-tag aan het pakket bevestigd
"Untagged"-verkeer, heeft geen VLAN-tag aan het pakket bevestigd
De enige manier om te zorgen dat een pakket niet gesniffed/gescooped moet kunnen worden is door te zorgen dat het pakket niet aanwezig is. Daarin biedt de VLAN-tag zelve geen bescherming.
Wat je echter kan doen is het volgende:
Stel je hebt switch A en switch B, dit zijn allebei hele simpele managed switched, laten we aannemen 8-poorts.
Aan switch A zit de uiteindelijke gateway/firewall verbonden in dit voorbeeld, op poort 1.
De switches zijn onderling ook verbonden, bij beiden via poort 8.
In dit voorbeeld willen wij herkennen welk verkeer van welke switch komt bij de firewall.
Verkeer dat via de andere poorten op switch A binnenkomt willen we toewijzen aan VLAN2 (voorbeeld uit simpliciteit), verkeer dat op switch B binnenkomt willen we toewijzen aan VLAN3 (ook maar een voorbeeld).
Op switch A wijs je poort 1 voor VLAN2 en VLAN3 een Tag toe, poorten 2 tot en met 7 stel je Untagged in op VLAN2. op poort 8 stel je VLAN3 tagged in. voor poorten 2 tot en met 7 zet je de PVID op VLAN#2.
Op switch B stel je poort 8 VLAN3 op Tagged in, poorten 1 tot en met 7 kunnen Untagged op VLAN3 en krijgen PVID op VLAN#3.
In mijn voorbeeld zou aan poort 1 van Switch A een firewall kunnen staan. Die kan aan de VLAN-nummers herkennen via welke switch het verkeer komt.
Ik gebruik dit ook om bepaalde delen van het netwerk wat op te scheiden en uiteindelijk vooral om bij mijn firewall wat makkelijker een onderscheid tussen verkeer vanuit de hobbykamer (servers) en de rest van het netwerk te houden.
Je kan ook een normale router/modem uiteindelijk aan poort 1 verbinden en beiden VLANs untagged serveren, maar ik wou de insteek mee geven, mocht je uiteindelijk een firewall willen inzetten.
Belangrijk hierin vind ik om het volgende in de gaten te houden:
Als verkeer aanwezig is, kan dit in twee vormen voorkomen;
"Tagged"-verkeer, heeft een VLAN-tag aan het pakket bevestigd
"Untagged"-verkeer, heeft geen VLAN-tag aan het pakket bevestigd
De enige manier om te zorgen dat een pakket niet gesniffed/gescooped moet kunnen worden is door te zorgen dat het pakket niet aanwezig is. Daarin biedt de VLAN-tag zelve geen bescherming.
Wat je echter kan doen is het volgende:
Stel je hebt switch A en switch B, dit zijn allebei hele simpele managed switched, laten we aannemen 8-poorts.
Aan switch A zit de uiteindelijke gateway/firewall verbonden in dit voorbeeld, op poort 1.
De switches zijn onderling ook verbonden, bij beiden via poort 8.
In dit voorbeeld willen wij herkennen welk verkeer van welke switch komt bij de firewall.
Verkeer dat via de andere poorten op switch A binnenkomt willen we toewijzen aan VLAN2 (voorbeeld uit simpliciteit), verkeer dat op switch B binnenkomt willen we toewijzen aan VLAN3 (ook maar een voorbeeld).
Op switch A wijs je poort 1 voor VLAN2 en VLAN3 een Tag toe, poorten 2 tot en met 7 stel je Untagged in op VLAN2. op poort 8 stel je VLAN3 tagged in. voor poorten 2 tot en met 7 zet je de PVID op VLAN#2.
Op switch B stel je poort 8 VLAN3 op Tagged in, poorten 1 tot en met 7 kunnen Untagged op VLAN3 en krijgen PVID op VLAN#3.
In mijn voorbeeld zou aan poort 1 van Switch A een firewall kunnen staan. Die kan aan de VLAN-nummers herkennen via welke switch het verkeer komt.
Ik gebruik dit ook om bepaalde delen van het netwerk wat op te scheiden en uiteindelijk vooral om bij mijn firewall wat makkelijker een onderscheid tussen verkeer vanuit de hobbykamer (servers) en de rest van het netwerk te houden.
Je kan ook een normale router/modem uiteindelijk aan poort 1 verbinden en beiden VLANs untagged serveren, maar ik wou de insteek mee geven, mocht je uiteindelijk een firewall willen inzetten.
De huidige situatie is nu router aangesloten op port 1 van de switch, apparaat op port 2 en een apparaat op port 3. Nu vroeg ik mij af of het mogelijk is voor een apparaten op port 3 http verkeer te lezen afkomstig van apparaten op port 2 en anders om.
Dat zou best eens kunnen! Ik meen mij zoiets ook te herinneren met 2 apparaten op 2 verschillende VLANs op één managed switch. Voor de zekerheid kun je met Wireshark meten. (meten = weten)Door Anoniem: (TS)
bedankt boor de antwoorden. Wat meer informatie.
De apparaten achter de switch hebben hun eigen software firewall, het is dan ook zeker niet mijn bedoeling dat de switch als "firewall" tussen 2 groepen apparaten in het netwerk gaat functioneren. Voornamelijk alleen verkeer scheiden en via QoS en bandbreedte beheer de ene groep wat voortrekken op de andere groep. Hierbij vroeg ik mij af nu er dus vlans zijn of dit ook betekent dat apparaten op port 3 dus niet meer zomaar het verkeer kunnen zien van apparaten op port 2. Dit echter zeker geen vereiste (gevoelige zaken als bankieren gaan over https), maar zou wel zeker een mooie extra zijn.
Op de router zelf staat niets ingesteld van vlan.
De switch bevat ook DoS prevention, ik weet niet of dat ook tegen gaat dat zomaar iemand het geheugen van het ding kan vullen?
Weet niet of dit de extra nodige info is om de vraag beter te kunnen beantwoorden, alhoewel als ik de artikelen van de heer van Straten goed begrijp er momenteel wss toch wel een kwetsbaarheid is die misbruikt kan worden.
bedankt boor de antwoorden. Wat meer informatie.
De apparaten achter de switch hebben hun eigen software firewall, het is dan ook zeker niet mijn bedoeling dat de switch als "firewall" tussen 2 groepen apparaten in het netwerk gaat functioneren. Voornamelijk alleen verkeer scheiden en via QoS en bandbreedte beheer de ene groep wat voortrekken op de andere groep. Hierbij vroeg ik mij af nu er dus vlans zijn of dit ook betekent dat apparaten op port 3 dus niet meer zomaar het verkeer kunnen zien van apparaten op port 2. Dit echter zeker geen vereiste (gevoelige zaken als bankieren gaan over https), maar zou wel zeker een mooie extra zijn.
Op de router zelf staat niets ingesteld van vlan.
De switch bevat ook DoS prevention, ik weet niet of dat ook tegen gaat dat zomaar iemand het geheugen van het ding kan vullen?
Weet niet of dit de extra nodige info is om de vraag beter te kunnen beantwoorden, alhoewel als ik de artikelen van de heer van Straten goed begrijp er momenteel wss toch wel een kwetsbaarheid is die misbruikt kan worden.
Een aantal van de bedoelingen van VLAN's is:o.a. Broadcast control en Security.
Als je router InterVLAN Routing ondersteunt dan kunnen alle apparaten in de verschillende VLAN's met elkaar communiceren zodra deze functie aangezet wordt, aangezien het broadcast verkeer niet gerouteerd wordt heb je toch ' broadcast control' maar geen security. Even uitgaande dat je een fully managed switch hebt en je wilt dan bijv. dat alleen 1 pc in VLAN X met een server in VLAN Y kan communiceren, dan zul je het overige verkeer tussen de VLAN's d.m.v. ACL's op de poorten moeten blokken en heb je security.
Ik lees nu zo veel onzin hier. En hele conspiracy theorieën. Maar het is heel erg eenvoudig, zonder routeren en met de juiste Switch en randapparatuur instelling is het niet mogelijk om van VLAN te wisselen indien dit niet gewenst is. Neem een switch met 8 poorten. Poort 1 t/m 4 zit UNTAGGED in VLAN 1, Poort 5 t/m 8 zitten UNTAGGED in VLAN 2. Devices in VLAN 1 kunnen NIET bij VLAN 2 ook al gaan ze opeens een VLAN ID meesturen. Een goede switch staat dat niet toe. Wanneer dat wel zou zijn dan zou de wereld er nu totaal anders uit zien omdat alles is opgesplitst in VLAN's en VRF's over de wereld.
Wat wel van belang is, is dat alles in het gehele netwerk goed geconfigureerd is. Bijvoorbeeld "VLAN Discovery" moet uit staan, poorten moeten expliciet getagged/untagged VLAN's hebben, GVRP moet uit staan (Dynamic mode) en dat soort zaken. Het liefst ook nog dat alle "client" poorten expliciet als Edge poort zijn gedefinieerd en geen deel uitmaken van Spanning tree en BPDU control en dergelijke.
Wat wel van belang is, is dat alles in het gehele netwerk goed geconfigureerd is. Bijvoorbeeld "VLAN Discovery" moet uit staan, poorten moeten expliciet getagged/untagged VLAN's hebben, GVRP moet uit staan (Dynamic mode) en dat soort zaken. Het liefst ook nog dat alle "client" poorten expliciet als Edge poort zijn gedefinieerd en geen deel uitmaken van Spanning tree en BPDU control en dergelijke.
(TS)
Bedankt voor de informatieve en uitgebreide reacties. Ik ga met de vele gegeven tips aan de slag in combinatie met de documentatie van de switch en kijken wat te bereiken/ verbeteren valt. Verder de switch bevat stormcontrol, maar heeft geen arp inspection aan boord. De router waar de switch op is aangesloten heeft ook totaal geen vlan mogelijkheden. Ik zal ook kijken of het mij lukt met wireshark(na dat ik wat documentatie gelezen heb hoe dit mogelijk is) meer duidelijkheid te krijgen over hoe het in de huidige situatie er voor staat.
Het betreft overigens een netgear prosafe GS105Ev2 switch (nog niet vermeld)
Bedankt voor de informatieve en uitgebreide reacties. Ik ga met de vele gegeven tips aan de slag in combinatie met de documentatie van de switch en kijken wat te bereiken/ verbeteren valt. Verder de switch bevat stormcontrol, maar heeft geen arp inspection aan boord. De router waar de switch op is aangesloten heeft ook totaal geen vlan mogelijkheden. Ik zal ook kijken of het mij lukt met wireshark(na dat ik wat documentatie gelezen heb hoe dit mogelijk is) meer duidelijkheid te krijgen over hoe het in de huidige situatie er voor staat.
Het betreft overigens een netgear prosafe GS105Ev2 switch (nog niet vermeld)
22-03-2017, 06:59 door
Erik van Straten
LAN
Oorspronkelijk was een LAN letterlijk een lange draad, vergelijkbaar met een waslijn, waar je computers op aansloot (elk van hen als een sok met een knijper aan die waslijn). Elke computer kon alle ethernetpakketjes van elke andere computer voorbij zien komen. Als je in zo'n netwerk 2 PC's had en 2 servers, en PC 1 op hetzelfde moment met Server 1 wilde communiceren als PC 2 met Server 2, dan ging dat niet - er moest op elkaar gewacht worden.
Ethernet Hub
Omdat die ene lange draad niet handig was (en de lengte beperkt tot 150 meter), werden de ethernethub uitgevonden, waarmee een stervormige structuur mogelijk werd (als spaken in een fietswiel; hub is Engels voor naaf). Een hub stuurt echter alle pakketjes die op 1 poort binnenkomen, gewoon door naar alle andere poorten. Nog steeds zag elke PC dus alle ethernetpakketjes uitgezonden door alle andere computers, en bij 2 PC's en 2 servers moest er nog steeds op elkaar gewacht worden.
Ethernet Switch
Om dat laatste probleem (performance dus) op te lossen, werd de ethernetswitch uitgevonden. Als deze een ethernetpakketje ontvangt op een willekeurige poort N, kijkt de switch naar het afzenderethernetadres in dat pakketje, en slaat de volgende gegevens op in een regel in een tabel:
1) dat (afzender-) ethernetadres;
2) het poortnummer N waarop dat pakketje de switch binnenkwam;
3) het tijdstip.
Bij het doorsturen van elk ethernetpakketje kijkt de switch naar het bestemmingsethernetadres in het ethernetpakket. Daarbij gebeurt het volgende:
A) Als het om een broadcastadres (FF:FF:FF:FF:FF:FF) of ander multicastadres (X:*:*:*:*:* waarbij het laagste bit van X gezet is en de rest niet uitmaakt) gaat, stuurt de switch het via al zijn poorten naar buiten en werkt dus als hub;
B) Ook als het bestemmingsadres niet in de tabel voorkomt, stuurt de switch het op alle poorten naar buiten;
C) Als het bestemmingsadres wel voorkomt in de tabel, wordt het uitsluitend via de bijbehorende poort naar buiten gestuurd.
Stel je de volgende configuratie voor:
Zodra PC 1 een pakketje naar Server 1 stuurt "leert" de switch dat PC 1 "achter" poort 1 zit. Als de switch nog niet weet waar Server 1 zich bevindt, wordt het pakketje op alle poorten naar buiten gestuurd. Zodra Server 1 een antwoord naar PC 1 stuurt, leert de switch waar Server 1 zit. En omdat de switch al weet waar PC 1 zit, stuurt hij het pakketje alleen naar buiten op poort 1.
Je zult begrijpen dat (als de switch intern snel genoeg is) PC 1 op hetzelfde moment met Server 1 kan communiceren als PC 2 met Server 2 en het dus lijkt of er 2 fysiek gescheiden verbindingen bestaan, elk met de maximale bandbreedte van 1 verbinding.
Dynamische karakter van ethernet switches
Er zijn verschillende redenen waarom de switch zo'n regel weer uit de tabel verwijdert. In elk geval gebeurt dat na een bepaalde tijd (vaak 5 minuten), daarom wordt het ontvangsttijdstip opgeslagen. Echter, als de switch binnen de ingestelde "onthoudtijd" opnieuw een ethernetpakketje van dezelfde PC ontvangt, blijft de regel in de tabel staan maar wordt wel het ontvangsttijdstip overschreven met de actuele tijd. Nb. per ethernetadres kan er maar 1 regel in de tabel staan.
Er zijn vaak ook verschillende redenen waarom een switch de tabel in 1 keer leeggooit, o.a. als de switch denkt dat er sprake is van een "topology change". Daarna moet de switch eerst weer leren (de tabel vullen) en zolang de switch niet weet achter welke poort bestemmingsadressen zich bevinden, werkt deze als hub (ik heb zo POP3 en FTP wachtwoorden naar alle PC's in een LAN gezonden zien worden). Daarnaast, een van de denkbare aanvallen is dat PC 2 voortdurend netwerkpakketjes verzendt met als afzenderethernetadres het adres van Server 1 (vervalst dus) waardoor de switch pakketjes bestemd voor Server 1 slechts naar PC 2 zal sturen.
Kortom, het switchproces is een truc om bandbreedte te optimaliseren; het is beslist geen security feature. Want zelfs zonder aanvallen is het by design dat er ethetnetpakketjes "gehubd" worden: sowieso geldt dat voor multicast (inclusief broadcast) ethernetpakketjes, maar af en toe ook voor unicast ethernetverkeer bestemd voor een andere dan jouw PC. Door slechts passief te sniffen kun je ontzettend veel informatie vergaren in een ethernetnetwerk (vooral met niet gehardende Windows PC's). Je moet je dan ook serieus afvragen of er wel zoiets bestaat als een "trusted network". In elk geval is een LAN niet betrouwbaarder dan de zwakste (aangesloten) schakel.
VLAN
Met VLANs simuleer je 2 of meer fysiek gescheiden ethernet netwerken die onderling geen gewone ethernetpakketjes kunnen uitwisselen, vergelijkbaar met het netwerk bij jou thuis en dat van jouw buren. Om tussen die (OSI layer 2) ethernetnetwerken toch informatie te kunnen uitwisselen, zul je dat op een hoger niveau moeten doen, meestal IP (op OSI layer 3) en daar heb je een router voor nodig.
Bij een switch die VLANs ondersteunt lijkt het erop of er, per VLAN, een losse onafhankelijke switch bestaat, waarbij VLANs "gekoppeld" (op IP niveau) kunnen zijn middels een router:
In de bovenstaande configuratie zijn er 2 ethernet broadcast domains, die (afhankelijk van de configuratie van de router) via IP pakketjes informatie met elkaar kunnen uitwisselen.
Meerdere VLANs over 1 fysieke kabel
Net zoals elk IP paket in een "ethernetdoosje" wordt gestopt om via een ethernetnetwerk te kunnen worden getransporteerd, is er een vergelijkbare truc nodig om gewone ethernetpakketjes voor verschillende VLANs via dezelfde ethernetkabel te kunnen versturen: ook die stoppen we weer in een omhullend doosje, waarna we daar een VLAN adreslabel op plakken. Zo'n adreslabel wordt ook wel een "tag" genoemd, en zo'n pakket een tagged pakket. Een verbinding waar dit soort pakketjes overheen gaan wordt vaak een trunk genoemd. Een switchpoort die tagged verkeer uitwisselt wordt een trunk poort genoemd, en een poort waarop gewoon ethernetverkeer wordt uitgewisseld wordt een access poort genoemd (bij uitgaande pakketjes verwijdert de switch de VLAN verpakking, en bij inkomende pakketjes voegt de switch deze verpakking toe).
Als een router ook een trunk poort heeft, is het volgende mogelijk:
Een pakketje van PC 1 naar Server 1 gaat dan eerst via VLAN "A" naar de router. Die verwijdert eerst de VLAN tag en daarna de ethernet header, en bepaalt vervolgens hoe het IP pakket gerouteerd moet worden. Als dat naar Server 1 moet, maakt de router er een ethernet envelop omheen (met bestemmingsethernetadres dat van Server 1), verpakt het resultaat met VLAN tag "B" en stuurt het (via dezelfde kabel) terug naar de switch. Vanwege de enkelvoudige verbinding met de switch wordt zo'n configuratie "router on a stick" genoemd.
VLAN security
Hoewel VLANs t.o.v. fysiek gescheiden netwerken en apparaten een aantal flinke beveiligingsrisico's introduceren, worden ze in de praktijk vaak als security boundary gebruikt. Enkele van die risico's zijn:
- Configuratiefouten
- Gebruik maken van het "default VLAN"
- Beschikbaarheidsproblemen in alle VLANs door problemen in één VLAN
- VLAN hopping
- Fysieke toegang door onbevoegden tot apparatuur (access points, VMware) en kabels met VLANs
- Mogelijkheden voor ongeautoriseerde toegang tot VLAN netwerkapparatuur, o.a. door bugs
Op internet is zat info te vinden over de risico's van het gebruik van VLANs voor CIA (Confidentiality, Integrity en Availability), zie bijv. http://www.pages02.net/coastams-networkbox/newsletter/newsletter_oct2013_article1.html.
Oorspronkelijk was een LAN letterlijk een lange draad, vergelijkbaar met een waslijn, waar je computers op aansloot (elk van hen als een sok met een knijper aan die waslijn). Elke computer kon alle ethernetpakketjes van elke andere computer voorbij zien komen. Als je in zo'n netwerk 2 PC's had en 2 servers, en PC 1 op hetzelfde moment met Server 1 wilde communiceren als PC 2 met Server 2, dan ging dat niet - er moest op elkaar gewacht worden.
PC 1 ------|
PC 2 ------|
Server 1 --|
Server 2 --|
PC 2 ------|
Server 1 --|
Server 2 --|
Ethernet Hub
Omdat die ene lange draad niet handig was (en de lengte beperkt tot 150 meter), werden de ethernethub uitgevonden, waarmee een stervormige structuur mogelijk werd (als spaken in een fietswiel; hub is Engels voor naaf). Een hub stuurt echter alle pakketjes die op 1 poort binnenkomen, gewoon door naar alle andere poorten. Nog steeds zag elke PC dus alle ethernetpakketjes uitgezonden door alle andere computers, en bij 2 PC's en 2 servers moest er nog steeds op elkaar gewacht worden.
Ethernet Switch
Om dat laatste probleem (performance dus) op te lossen, werd de ethernetswitch uitgevonden. Als deze een ethernetpakketje ontvangt op een willekeurige poort N, kijkt de switch naar het afzenderethernetadres in dat pakketje, en slaat de volgende gegevens op in een regel in een tabel:
1) dat (afzender-) ethernetadres;
2) het poortnummer N waarop dat pakketje de switch binnenkwam;
3) het tijdstip.
Bij het doorsturen van elk ethernetpakketje kijkt de switch naar het bestemmingsethernetadres in het ethernetpakket. Daarbij gebeurt het volgende:
A) Als het om een broadcastadres (FF:FF:FF:FF:FF:FF) of ander multicastadres (X:*:*:*:*:* waarbij het laagste bit van X gezet is en de rest niet uitmaakt) gaat, stuurt de switch het via al zijn poorten naar buiten en werkt dus als hub;
B) Ook als het bestemmingsadres niet in de tabel voorkomt, stuurt de switch het op alle poorten naar buiten;
C) Als het bestemmingsadres wel voorkomt in de tabel, wordt het uitsluitend via de bijbehorende poort naar buiten gestuurd.
Stel je de volgende configuratie voor:
PC 1 --------------- Switchpoort 1 | Switch
PC 2 --------------- Switchpoort 2 |
Server 1 ----------- Switchpoort 3 | backplane
Server 2 ----------- Switchpoort 4 |
PC 2 --------------- Switchpoort 2 |
Server 1 ----------- Switchpoort 3 | backplane
Server 2 ----------- Switchpoort 4 |
Zodra PC 1 een pakketje naar Server 1 stuurt "leert" de switch dat PC 1 "achter" poort 1 zit. Als de switch nog niet weet waar Server 1 zich bevindt, wordt het pakketje op alle poorten naar buiten gestuurd. Zodra Server 1 een antwoord naar PC 1 stuurt, leert de switch waar Server 1 zit. En omdat de switch al weet waar PC 1 zit, stuurt hij het pakketje alleen naar buiten op poort 1.
Je zult begrijpen dat (als de switch intern snel genoeg is) PC 1 op hetzelfde moment met Server 1 kan communiceren als PC 2 met Server 2 en het dus lijkt of er 2 fysiek gescheiden verbindingen bestaan, elk met de maximale bandbreedte van 1 verbinding.
Dynamische karakter van ethernet switches
Er zijn verschillende redenen waarom de switch zo'n regel weer uit de tabel verwijdert. In elk geval gebeurt dat na een bepaalde tijd (vaak 5 minuten), daarom wordt het ontvangsttijdstip opgeslagen. Echter, als de switch binnen de ingestelde "onthoudtijd" opnieuw een ethernetpakketje van dezelfde PC ontvangt, blijft de regel in de tabel staan maar wordt wel het ontvangsttijdstip overschreven met de actuele tijd. Nb. per ethernetadres kan er maar 1 regel in de tabel staan.
Er zijn vaak ook verschillende redenen waarom een switch de tabel in 1 keer leeggooit, o.a. als de switch denkt dat er sprake is van een "topology change". Daarna moet de switch eerst weer leren (de tabel vullen) en zolang de switch niet weet achter welke poort bestemmingsadressen zich bevinden, werkt deze als hub (ik heb zo POP3 en FTP wachtwoorden naar alle PC's in een LAN gezonden zien worden). Daarnaast, een van de denkbare aanvallen is dat PC 2 voortdurend netwerkpakketjes verzendt met als afzenderethernetadres het adres van Server 1 (vervalst dus) waardoor de switch pakketjes bestemd voor Server 1 slechts naar PC 2 zal sturen.
Kortom, het switchproces is een truc om bandbreedte te optimaliseren; het is beslist geen security feature. Want zelfs zonder aanvallen is het by design dat er ethetnetpakketjes "gehubd" worden: sowieso geldt dat voor multicast (inclusief broadcast) ethernetpakketjes, maar af en toe ook voor unicast ethernetverkeer bestemd voor een andere dan jouw PC. Door slechts passief te sniffen kun je ontzettend veel informatie vergaren in een ethernetnetwerk (vooral met niet gehardende Windows PC's). Je moet je dan ook serieus afvragen of er wel zoiets bestaat als een "trusted network". In elk geval is een LAN niet betrouwbaarder dan de zwakste (aangesloten) schakel.
VLAN
Met VLANs simuleer je 2 of meer fysiek gescheiden ethernet netwerken die onderling geen gewone ethernetpakketjes kunnen uitwisselen, vergelijkbaar met het netwerk bij jou thuis en dat van jouw buren. Om tussen die (OSI layer 2) ethernetnetwerken toch informatie te kunnen uitwisselen, zul je dat op een hoger niveau moeten doen, meestal IP (op OSI layer 3) en daar heb je een router voor nodig.
Bij een switch die VLANs ondersteunt lijkt het erop of er, per VLAN, een losse onafhankelijke switch bestaat, waarbij VLANs "gekoppeld" (op IP niveau) kunnen zijn middels een router:
PC 1 ------------------ Switchpoort 1 | Fysieke switch 1, virtuele switch 1
PC 2 ------------------ Switchpoort 2 | VLAN "A" bijv. met nummer 123
/ Routerpoort 1 ------- Switchpoort 3 |
| ROUTER
\ Routerpoort 2 ------- Switchpoort 4 | Fysieke switch 1, virtuele switch 2
Server 1 -------------- Switchpoort 5 | VLAN "B" bijv. met nummer 456
Server 2 -------------- Switchpoort 6 |
PC 2 ------------------ Switchpoort 2 | VLAN "A" bijv. met nummer 123
/ Routerpoort 1 ------- Switchpoort 3 |
| ROUTER
\ Routerpoort 2 ------- Switchpoort 4 | Fysieke switch 1, virtuele switch 2
Server 1 -------------- Switchpoort 5 | VLAN "B" bijv. met nummer 456
Server 2 -------------- Switchpoort 6 |
In de bovenstaande configuratie zijn er 2 ethernet broadcast domains, die (afhankelijk van de configuratie van de router) via IP pakketjes informatie met elkaar kunnen uitwisselen.
Meerdere VLANs over 1 fysieke kabel
Net zoals elk IP paket in een "ethernetdoosje" wordt gestopt om via een ethernetnetwerk te kunnen worden getransporteerd, is er een vergelijkbare truc nodig om gewone ethernetpakketjes voor verschillende VLANs via dezelfde ethernetkabel te kunnen versturen: ook die stoppen we weer in een omhullend doosje, waarna we daar een VLAN adreslabel op plakken. Zo'n adreslabel wordt ook wel een "tag" genoemd, en zo'n pakket een tagged pakket. Een verbinding waar dit soort pakketjes overheen gaan wordt vaak een trunk genoemd. Een switchpoort die tagged verkeer uitwisselt wordt een trunk poort genoemd, en een poort waarop gewoon ethernetverkeer wordt uitgewisseld wordt een access poort genoemd (bij uitgaande pakketjes verwijdert de switch de VLAN verpakking, en bij inkomende pakketjes voegt de switch deze verpakking toe).
Als een router ook een trunk poort heeft, is het volgende mogelijk:
PC 1 ------------------- Switchpoort 1 (access) | Fysieke switch 1, virtuele switch 1
PC 2 ------------------- Switchpoort 2 (access) | VLAN "A" bijv. met nummer 123
Routerpoort (trunk) ----- Switchpoort 3 (trunk) | Fysieke switch 1, VLANs "A" en 'B"
Server 1 --------------- Switchpoort 4 (access) | Fysieke switch 1, virtuele switch 2
Server 2 --------------- Switchpoort 5 (access) | VLAN "B" bijv. met nummer 456
PC 2 ------------------- Switchpoort 2 (access) | VLAN "A" bijv. met nummer 123
Routerpoort (trunk) ----- Switchpoort 3 (trunk) | Fysieke switch 1, VLANs "A" en 'B"
Server 1 --------------- Switchpoort 4 (access) | Fysieke switch 1, virtuele switch 2
Server 2 --------------- Switchpoort 5 (access) | VLAN "B" bijv. met nummer 456
Een pakketje van PC 1 naar Server 1 gaat dan eerst via VLAN "A" naar de router. Die verwijdert eerst de VLAN tag en daarna de ethernet header, en bepaalt vervolgens hoe het IP pakket gerouteerd moet worden. Als dat naar Server 1 moet, maakt de router er een ethernet envelop omheen (met bestemmingsethernetadres dat van Server 1), verpakt het resultaat met VLAN tag "B" en stuurt het (via dezelfde kabel) terug naar de switch. Vanwege de enkelvoudige verbinding met de switch wordt zo'n configuratie "router on a stick" genoemd.
VLAN security
Hoewel VLANs t.o.v. fysiek gescheiden netwerken en apparaten een aantal flinke beveiligingsrisico's introduceren, worden ze in de praktijk vaak als security boundary gebruikt. Enkele van die risico's zijn:
- Configuratiefouten
- Gebruik maken van het "default VLAN"
- Beschikbaarheidsproblemen in alle VLANs door problemen in één VLAN
- VLAN hopping
- Fysieke toegang door onbevoegden tot apparatuur (access points, VMware) en kabels met VLANs
- Mogelijkheden voor ongeautoriseerde toegang tot VLAN netwerkapparatuur, o.a. door bugs
Op internet is zat info te vinden over de risico's van het gebruik van VLANs voor CIA (Confidentiality, Integrity en Availability), zie bijv. http://www.pages02.net/coastams-networkbox/newsletter/newsletter_oct2013_article1.html.
Door Erik van Straten: LAN
Oorspronkelijk was een LAN letterlijk een lange draad, vergelijkbaar met een waslijn, waar je computers op aansloot (elk van hen als een sok met een knijper aan die waslijn). Elke computer kon alle ethernetpakketjes van elke andere computer voorbij zien komen. Als je in zo'n netwerk 2 PC's had en 2 servers, en PC 1 op hetzelfde moment met Server 1 wilde communiceren als PC 2 met Server 2, dan ging dat niet - er moest op elkaar gewacht worden.
Ethernet Hub
Omdat die ene lange draad niet handig was (en de lengte beperkt tot 150 meter), werden de ethernethub uitgevonden, waarmee een stervormige structuur mogelijk werd (als spaken in een fietswiel; hub is Engels voor naaf). Een hub stuurt echter alle pakketjes die op 1 poort binnenkomen, gewoon door naar alle andere poorten. Nog steeds zag elke PC dus alle ethernetpakketjes uitgezonden door alle andere computers, en bij 2 PC's en 2 servers moest er nog steeds op elkaar gewacht worden.
Ethernet Switch
Om dat laatste probleem (performance dus) op te lossen, werd de ethernetswitch uitgevonden. Als deze een ethernetpakketje ontvangt op een willekeurige poort N, kijkt de switch naar het afzenderethernetadres in dat pakketje, en slaat de volgende gegevens op in een regel in een tabel:
1) dat (afzender-) ethernetadres;
2) het poortnummer N waarop dat pakketje de switch binnenkwam;
3) het tijdstip.
Bij het doorsturen van elk ethernetpakketje kijkt de switch naar het bestemmingsethernetadres in het ethernetpakket. Daarbij gebeurt het volgende:
A) Als het om een broadcastadres (FF:FF:FF:FF:FF:FF) of ander multicastadres (X:*:*:*:*:* waarbij het laagste bit van X gezet is en de rest niet uitmaakt) gaat, stuurt de switch het via al zijn poorten naar buiten en werkt dus als hub;
B) Ook als het bestemmingsadres niet in de tabel voorkomt, stuurt de switch het op alle poorten naar buiten;
C) Als het bestemmingsadres wel voorkomt in de tabel, wordt het uitsluitend via de bijbehorende poort naar buiten gestuurd.
Stel je de volgende configuratie voor:
Zodra PC 1 een pakketje naar Server 1 stuurt "leert" de switch dat PC 1 "achter" poort 1 zit. Als de switch nog niet weet waar Server 1 zich bevindt, wordt het pakketje op alle poorten naar buiten gestuurd. Zodra Server 1 een antwoord naar PC 1 stuurt, leert de switch waar Server 1 zit. En omdat de switch al weet waar PC 1 zit, stuurt hij het pakketje alleen naar buiten op poort 1.
Je zult begrijpen dat (als de switch intern snel genoeg is) PC 1 op hetzelfde moment met Server 1 kan communiceren als PC 2 met Server 2 en het dus lijkt of er 2 fysiek gescheiden verbindingen bestaan, elk met de maximale bandbreedte van 1 verbinding.
Dynamische karakter van ethernet switches
Er zijn verschillende redenen waarom de switch zo'n regel weer uit de tabel verwijdert. In elk geval gebeurt dat na een bepaalde tijd (vaak 5 minuten), daarom wordt het ontvangsttijdstip opgeslagen. Echter, als de switch binnen de ingestelde "onthoudtijd" opnieuw een ethernetpakketje van dezelfde PC ontvangt, blijft de regel in de tabel staan maar wordt wel het ontvangsttijdstip overschreven met de actuele tijd. Nb. per ethernetadres kan er maar 1 regel in de tabel staan.
Er zijn vaak ook verschillende redenen waarom een switch de tabel in 1 keer leeggooit, o.a. als de switch denkt dat er sprake is van een "topology change". Daarna moet de switch eerst weer leren (de tabel vullen) en zolang de switch niet weet achter welke poort bestemmingsadressen zich bevinden, werkt deze als hub (ik heb zo POP3 en FTP wachtwoorden naar alle PC's in een LAN gezonden zien worden). Daarnaast, een van de denkbare aanvallen is dat PC 2 voortdurend netwerkpakketjes verzendt met als afzenderethernetadres het adres van Server 1 (vervalst dus) waardoor de switch pakketjes bestemd voor Server 1 slechts naar PC 2 zal sturen.
Kortom, het switchproces is een truc om bandbreedte te optimaliseren; het is beslist geen security feature. Want zelfs zonder aanvallen is het by design dat er ethetnetpakketjes "gehubd" worden: sowieso geldt dat voor multicast (inclusief broadcast) ethernetpakketjes, maar af en toe ook voor unicast ethernetverkeer bestemd voor een andere dan jouw PC. Door slechts passief te sniffen kun je ontzettend veel informatie vergaren in een ethernetnetwerk (vooral met niet gehardende Windows PC's). Je moet je dan ook serieus afvragen of er wel zoiets bestaat als een "trusted network". In elk geval is een LAN niet betrouwbaarder dan de zwakste (aangesloten) schakel.
VLAN
Met VLANs simuleer je 2 of meer fysiek gescheiden ethernet netwerken die onderling geen gewone ethernetpakketjes kunnen uitwisselen, vergelijkbaar met het netwerk bij jou thuis en dat van jouw buren. Om tussen die (OSI layer 2) ethernetnetwerken toch informatie te kunnen uitwisselen, zul je dat op een hoger niveau moeten doen, meestal IP (op OSI layer 3) en daar heb je een router voor nodig.
Bij een switch die VLANs ondersteunt lijkt het erop of er, per VLAN, een losse onafhankelijke switch bestaat, waarbij VLANs "gekoppeld" (op IP niveau) kunnen zijn middels een router:
In de bovenstaande configuratie zijn er 2 ethernet broadcast domains, die (afhankelijk van de configuratie van de router) via IP pakketjes informatie met elkaar kunnen uitwisselen.
Meerdere VLANs over 1 fysieke kabel
Net zoals elk IP paket in een "ethernetdoosje" wordt gestopt om via een ethernetnetwerk te kunnen worden getransporteerd, is er een vergelijkbare truc nodig om gewone ethernetpakketjes voor verschillende VLANs via dezelfde ethernetkabel te kunnen versturen: ook die stoppen we weer in een omhullend doosje, waarna we daar een VLAN adreslabel op plakken. Zo'n adreslabel wordt ook wel een "tag" genoemd, en zo'n pakket een tagged pakket. Een verbinding waar dit soort pakketjes overheen gaan wordt vaak een trunk genoemd. Een switchpoort die tagged verkeer uitwisselt wordt een trunk poort genoemd, en een poort waarop gewoon ethernetverkeer wordt uitgewisseld wordt een access poort genoemd (bij uitgaande pakketjes verwijdert de switch de VLAN verpakking, en bij inkomende pakketjes voegt de switch deze verpakking toe).
Als een router ook een trunk poort heeft, is het volgende mogelijk:
Een pakketje van PC 1 naar Server 1 gaat dan eerst via VLAN "A" naar de router. Die verwijdert eerst de VLAN tag en daarna de ethernet header, en bepaalt vervolgens hoe het IP pakket gerouteerd moet worden. Als dat naar Server 1 moet, maakt de router er een ethernet envelop omheen (met bestemmingsethernetadres dat van Server 1), verpakt het resultaat met VLAN tag "B" en stuurt het (via dezelfde kabel) terug naar de switch. Vanwege de enkelvoudige verbinding met de switch wordt zo'n configuratie "router on a stick" genoemd.
VLAN security
Hoewel VLANs t.o.v. fysiek gescheiden netwerken en apparaten een aantal flinke beveiligingsrisico's introduceren, worden ze in de praktijk vaak als security boundary gebruikt. Enkele van die risico's zijn:
- Configuratiefouten
- Gebruik maken van het "default VLAN"
- Beschikbaarheidsproblemen in alle VLANs door problemen in één VLAN
- VLAN hopping
- Fysieke toegang door onbevoegden tot apparatuur (access points, VMware) en kabels met VLANs
- Mogelijkheden voor ongeautoriseerde toegang tot VLAN netwerkapparatuur, o.a. door bugs
Op internet is zat info te vinden over de risico's van het gebruik van VLANs voor CIA (Confidentiality, Integrity en Availability), zie bijv. http://www.pages02.net/coastams-networkbox/newsletter/newsletter_oct2013_article1.html.
Erik je moet natuurlijk wel het hele verhaal vertellen en niet alleen focussen op de mogelijke bugs die kunnen leiden tot.Oorspronkelijk was een LAN letterlijk een lange draad, vergelijkbaar met een waslijn, waar je computers op aansloot (elk van hen als een sok met een knijper aan die waslijn). Elke computer kon alle ethernetpakketjes van elke andere computer voorbij zien komen. Als je in zo'n netwerk 2 PC's had en 2 servers, en PC 1 op hetzelfde moment met Server 1 wilde communiceren als PC 2 met Server 2, dan ging dat niet - er moest op elkaar gewacht worden.
PC 1 ------|
PC 2 ------|
Server 1 --|
Server 2 --|
PC 2 ------|
Server 1 --|
Server 2 --|
Ethernet Hub
Omdat die ene lange draad niet handig was (en de lengte beperkt tot 150 meter), werden de ethernethub uitgevonden, waarmee een stervormige structuur mogelijk werd (als spaken in een fietswiel; hub is Engels voor naaf). Een hub stuurt echter alle pakketjes die op 1 poort binnenkomen, gewoon door naar alle andere poorten. Nog steeds zag elke PC dus alle ethernetpakketjes uitgezonden door alle andere computers, en bij 2 PC's en 2 servers moest er nog steeds op elkaar gewacht worden.
Ethernet Switch
Om dat laatste probleem (performance dus) op te lossen, werd de ethernetswitch uitgevonden. Als deze een ethernetpakketje ontvangt op een willekeurige poort N, kijkt de switch naar het afzenderethernetadres in dat pakketje, en slaat de volgende gegevens op in een regel in een tabel:
1) dat (afzender-) ethernetadres;
2) het poortnummer N waarop dat pakketje de switch binnenkwam;
3) het tijdstip.
Bij het doorsturen van elk ethernetpakketje kijkt de switch naar het bestemmingsethernetadres in het ethernetpakket. Daarbij gebeurt het volgende:
A) Als het om een broadcastadres (FF:FF:FF:FF:FF:FF) of ander multicastadres (X:*:*:*:*:* waarbij het laagste bit van X gezet is en de rest niet uitmaakt) gaat, stuurt de switch het via al zijn poorten naar buiten en werkt dus als hub;
B) Ook als het bestemmingsadres niet in de tabel voorkomt, stuurt de switch het op alle poorten naar buiten;
C) Als het bestemmingsadres wel voorkomt in de tabel, wordt het uitsluitend via de bijbehorende poort naar buiten gestuurd.
Stel je de volgende configuratie voor:
PC 1 --------------- Switchpoort 1 | Switch
PC 2 --------------- Switchpoort 2 |
Server 1 ----------- Switchpoort 3 | backplane
Server 2 ----------- Switchpoort 4 |
PC 2 --------------- Switchpoort 2 |
Server 1 ----------- Switchpoort 3 | backplane
Server 2 ----------- Switchpoort 4 |
Zodra PC 1 een pakketje naar Server 1 stuurt "leert" de switch dat PC 1 "achter" poort 1 zit. Als de switch nog niet weet waar Server 1 zich bevindt, wordt het pakketje op alle poorten naar buiten gestuurd. Zodra Server 1 een antwoord naar PC 1 stuurt, leert de switch waar Server 1 zit. En omdat de switch al weet waar PC 1 zit, stuurt hij het pakketje alleen naar buiten op poort 1.
Je zult begrijpen dat (als de switch intern snel genoeg is) PC 1 op hetzelfde moment met Server 1 kan communiceren als PC 2 met Server 2 en het dus lijkt of er 2 fysiek gescheiden verbindingen bestaan, elk met de maximale bandbreedte van 1 verbinding.
Dynamische karakter van ethernet switches
Er zijn verschillende redenen waarom de switch zo'n regel weer uit de tabel verwijdert. In elk geval gebeurt dat na een bepaalde tijd (vaak 5 minuten), daarom wordt het ontvangsttijdstip opgeslagen. Echter, als de switch binnen de ingestelde "onthoudtijd" opnieuw een ethernetpakketje van dezelfde PC ontvangt, blijft de regel in de tabel staan maar wordt wel het ontvangsttijdstip overschreven met de actuele tijd. Nb. per ethernetadres kan er maar 1 regel in de tabel staan.
Er zijn vaak ook verschillende redenen waarom een switch de tabel in 1 keer leeggooit, o.a. als de switch denkt dat er sprake is van een "topology change". Daarna moet de switch eerst weer leren (de tabel vullen) en zolang de switch niet weet achter welke poort bestemmingsadressen zich bevinden, werkt deze als hub (ik heb zo POP3 en FTP wachtwoorden naar alle PC's in een LAN gezonden zien worden). Daarnaast, een van de denkbare aanvallen is dat PC 2 voortdurend netwerkpakketjes verzendt met als afzenderethernetadres het adres van Server 1 (vervalst dus) waardoor de switch pakketjes bestemd voor Server 1 slechts naar PC 2 zal sturen.
Kortom, het switchproces is een truc om bandbreedte te optimaliseren; het is beslist geen security feature. Want zelfs zonder aanvallen is het by design dat er ethetnetpakketjes "gehubd" worden: sowieso geldt dat voor multicast (inclusief broadcast) ethernetpakketjes, maar af en toe ook voor unicast ethernetverkeer bestemd voor een andere dan jouw PC. Door slechts passief te sniffen kun je ontzettend veel informatie vergaren in een ethernetnetwerk (vooral met niet gehardende Windows PC's). Je moet je dan ook serieus afvragen of er wel zoiets bestaat als een "trusted network". In elk geval is een LAN niet betrouwbaarder dan de zwakste (aangesloten) schakel.
VLAN
Met VLANs simuleer je 2 of meer fysiek gescheiden ethernet netwerken die onderling geen gewone ethernetpakketjes kunnen uitwisselen, vergelijkbaar met het netwerk bij jou thuis en dat van jouw buren. Om tussen die (OSI layer 2) ethernetnetwerken toch informatie te kunnen uitwisselen, zul je dat op een hoger niveau moeten doen, meestal IP (op OSI layer 3) en daar heb je een router voor nodig.
Bij een switch die VLANs ondersteunt lijkt het erop of er, per VLAN, een losse onafhankelijke switch bestaat, waarbij VLANs "gekoppeld" (op IP niveau) kunnen zijn middels een router:
PC 1 ------------------ Switchpoort 1 | Fysieke switch 1, virtuele switch 1
PC 2 ------------------ Switchpoort 2 | VLAN "A" bijv. met nummer 123
/ Routerpoort 1 ------- Switchpoort 3 |
| ROUTER
\ Routerpoort 2 ------- Switchpoort 4 | Fysieke switch 1, virtuele switch 2
Server 1 -------------- Switchpoort 5 | VLAN "B" bijv. met nummer 456
Server 2 -------------- Switchpoort 6 |
PC 2 ------------------ Switchpoort 2 | VLAN "A" bijv. met nummer 123
/ Routerpoort 1 ------- Switchpoort 3 |
| ROUTER
\ Routerpoort 2 ------- Switchpoort 4 | Fysieke switch 1, virtuele switch 2
Server 1 -------------- Switchpoort 5 | VLAN "B" bijv. met nummer 456
Server 2 -------------- Switchpoort 6 |
In de bovenstaande configuratie zijn er 2 ethernet broadcast domains, die (afhankelijk van de configuratie van de router) via IP pakketjes informatie met elkaar kunnen uitwisselen.
Meerdere VLANs over 1 fysieke kabel
Net zoals elk IP paket in een "ethernetdoosje" wordt gestopt om via een ethernetnetwerk te kunnen worden getransporteerd, is er een vergelijkbare truc nodig om gewone ethernetpakketjes voor verschillende VLANs via dezelfde ethernetkabel te kunnen versturen: ook die stoppen we weer in een omhullend doosje, waarna we daar een VLAN adreslabel op plakken. Zo'n adreslabel wordt ook wel een "tag" genoemd, en zo'n pakket een tagged pakket. Een verbinding waar dit soort pakketjes overheen gaan wordt vaak een trunk genoemd. Een switchpoort die tagged verkeer uitwisselt wordt een trunk poort genoemd, en een poort waarop gewoon ethernetverkeer wordt uitgewisseld wordt een access poort genoemd (bij uitgaande pakketjes verwijdert de switch de VLAN verpakking, en bij inkomende pakketjes voegt de switch deze verpakking toe).
Als een router ook een trunk poort heeft, is het volgende mogelijk:
PC 1 ------------------- Switchpoort 1 (access) | Fysieke switch 1, virtuele switch 1
PC 2 ------------------- Switchpoort 2 (access) | VLAN "A" bijv. met nummer 123
Routerpoort (trunk) ----- Switchpoort 3 (trunk) | Fysieke switch 1, VLANs "A" en 'B"
Server 1 --------------- Switchpoort 4 (access) | Fysieke switch 1, virtuele switch 2
Server 2 --------------- Switchpoort 5 (access) | VLAN "B" bijv. met nummer 456
PC 2 ------------------- Switchpoort 2 (access) | VLAN "A" bijv. met nummer 123
Routerpoort (trunk) ----- Switchpoort 3 (trunk) | Fysieke switch 1, VLANs "A" en 'B"
Server 1 --------------- Switchpoort 4 (access) | Fysieke switch 1, virtuele switch 2
Server 2 --------------- Switchpoort 5 (access) | VLAN "B" bijv. met nummer 456
Een pakketje van PC 1 naar Server 1 gaat dan eerst via VLAN "A" naar de router. Die verwijdert eerst de VLAN tag en daarna de ethernet header, en bepaalt vervolgens hoe het IP pakket gerouteerd moet worden. Als dat naar Server 1 moet, maakt de router er een ethernet envelop omheen (met bestemmingsethernetadres dat van Server 1), verpakt het resultaat met VLAN tag "B" en stuurt het (via dezelfde kabel) terug naar de switch. Vanwege de enkelvoudige verbinding met de switch wordt zo'n configuratie "router on a stick" genoemd.
VLAN security
Hoewel VLANs t.o.v. fysiek gescheiden netwerken en apparaten een aantal flinke beveiligingsrisico's introduceren, worden ze in de praktijk vaak als security boundary gebruikt. Enkele van die risico's zijn:
- Configuratiefouten
- Gebruik maken van het "default VLAN"
- Beschikbaarheidsproblemen in alle VLANs door problemen in één VLAN
- VLAN hopping
- Fysieke toegang door onbevoegden tot apparatuur (access points, VMware) en kabels met VLANs
- Mogelijkheden voor ongeautoriseerde toegang tot VLAN netwerkapparatuur, o.a. door bugs
Op internet is zat info te vinden over de risico's van het gebruik van VLANs voor CIA (Confidentiality, Integrity en Availability), zie bijv. http://www.pages02.net/coastams-networkbox/newsletter/newsletter_oct2013_article1.html.
Zonder VLAN's hebben ongeautoriseerde ook toegang tot access points, VMWare etc.
Een heel betoog over de gevaren van VLAN's maar wat is het alternatief?
Dat je kennis van zaken moet hebben betreffende dit onderwerp ben ik met je eens en dat het werk is voor een netwerkspecialist ook, maar stop met het alleen maar focussen op de mogelijke gevaren van VLAN's. Je vergeet het hele onderwerp wat je moet doen om VLAN's wel veilig te maken.
Wat ik gister 21:04 heb geschreven mist nog iets: je kan vlan-checking toepassen (worden alleen op de poort toegestane VLANs beheerd), als iemand dan een apparaat aansluit en VLAN tags daaraan bevestigd zitten die niet op die poort "horen", worden ze gedropped.
Zelf pas ik ook toe dat op aansluitingen die normaal onverbonden zijn of alleen met bepaalde VLAN-tags een PVID van 666 hebben. De firewall logt alle verkeer op VLAN666, zo kan ik het ook zien als iemand bijv kabels is gaan verwisselen of een oneigenlijk apparaat tussengeplaatst zou worden.
Zelf pas ik ook toe dat op aansluitingen die normaal onverbonden zijn of alleen met bepaalde VLAN-tags een PVID van 666 hebben. De firewall logt alle verkeer op VLAN666, zo kan ik het ook zien als iemand bijv kabels is gaan verwisselen of een oneigenlijk apparaat tussengeplaatst zou worden.
(TS)
Bedankt voor de zeer uitgebreide post Erik an Straten en Anoniemen. Een aantal zaken waren mij bekend zoals de werking van een hub en hoe een switch de "locatie" van apparaten leert kennen. Zoals ik eerder schreef is het primaire doel van de switch 2 vlans aanmaken om het verkeer van een groep een hogere prioriteit te kunnen geven en meer bandbreedte voor die groep, hierbij zou het interessant zijn als er ook extra beveiliging kan worden toegevoegd aan het netwerk doormiddel van de switch. Inmiddels is mij echter duidelijk dat ik dit niet hard hoef te verwachten, er zijn hier wel een hoop verbeter mogelijkheden aangedragen maar een aantal van die ondersteund de switch bij mij wetende niet.
Echter wat betreft jouw laatste alinea, in de oude situatie zaten de apparaten gewoon allemaal direct of de router aangesloten. Kan het zo zijn dat de switch het netwerk zelfs nog onveiliger maakt als in de oude situatie?
Bedankt voor de zeer uitgebreide post Erik an Straten en Anoniemen. Een aantal zaken waren mij bekend zoals de werking van een hub en hoe een switch de "locatie" van apparaten leert kennen. Zoals ik eerder schreef is het primaire doel van de switch 2 vlans aanmaken om het verkeer van een groep een hogere prioriteit te kunnen geven en meer bandbreedte voor die groep, hierbij zou het interessant zijn als er ook extra beveiliging kan worden toegevoegd aan het netwerk doormiddel van de switch. Inmiddels is mij echter duidelijk dat ik dit niet hard hoef te verwachten, er zijn hier wel een hoop verbeter mogelijkheden aangedragen maar een aantal van die ondersteund de switch bij mij wetende niet.
Echter wat betreft jouw laatste alinea, in de oude situatie zaten de apparaten gewoon allemaal direct of de router aangesloten. Kan het zo zijn dat de switch het netwerk zelfs nog onveiliger maakt als in de oude situatie?
22-03-2017, 22:50 door
Erik van Straten
22-03-2017, 09:07 door Anoniem: Erik je moet natuurlijk wel het hele verhaal vertellen en niet alleen focussen op de mogelijke bugs die kunnen leiden tot.
Welk hele verhaal?22-03-2017, 09:07 door Anoniem: Een heel betoog over de gevaren van VLAN's
Ik heb geprobeerd om ook aan leken helder uit te leggen hoe switching en VLANs werken en eindig met lijstje risico's van VLANs; als ik de TS goed begrijp is hij of zij daarin geïnteresseerd. En sowieso, als ik me niet vergis, is dit een security site.22-03-2017, 09:07 door Anoniem: Zonder VLAN's hebben ongeautoriseerde ook toegang tot access points, VMWare etc. [...] maar wat is het alternatief?
Als de risico's in een specifieke situatie te groot zijn, geen VLANs (ter plaatse) gebruiken? Eventueel access points zo plaatsen dat deze niet eenvoudig fysiek toegankelijk zijn? Netwerkkabels die VLANs transporteren uitsluitend in afgesloten schachten, en netwerkapparatuur in afgesloten ruimtes?VLANs zijn een goedkoop alternatief voor fysiek gescheiden netwerken. Nogal wat beheerders hebben in mijn ervaring te veel vertrouwen in virtualisatie (VMs, virtuele switches en VLANs). Met de laatste tijd bekend geworden lekken in netwerkapparatuur en virtualisatiesoftware (guest to host escapes) vooral in Xen maar afgelopen week ook in VMware, ben je een wegkijker als je de bijbehorende risico's negeert.
22-03-2017, 09:07 door Anoniem: Dat je kennis van zaken moet hebben betreffende dit onderwerp ben ik met je eens en dat het werk is voor een netwerkspecialist ook, maar stop met het alleen maar focussen op de mogelijke gevaren van VLAN's. Je vergeet het hele onderwerp wat je moet doen om VLAN's wel veilig te maken.
Als jij weet hoe dat moet, waaron schrijf je daar dan zelf niet wat over?22-03-2017, 00:18 door Anoniem: (TS)
[...]
Het betreft overigens een netgear prosafe GS105Ev2 switch (nog niet vermeld)
en[...]
Het betreft overigens een netgear prosafe GS105Ev2 switch (nog niet vermeld)
22-03-2017, 14:58 door Anoniem: (TS)
[...]
Echter wat betreft jouw laatste alinea, in de oude situatie zaten de apparaten gewoon allemaal direct of de router aangesloten. Kan het zo zijn dat de switch het netwerk zelfs nog onveiliger maakt als in de oude situatie?
Ja. Als de huidige firmware van deze low-budget managed Netgear switches nog net zo lek is als toen ik ernaar keek in 2014 (zie mijn bijdrage onderaan in [1]) en iemand anders in 2016 (zie [2]), zou ik dit soort apparaten persoonlijk niet in netwerken opnemen - zelfs niet in m'n thuisnetwerk.[...]
Echter wat betreft jouw laatste alinea, in de oude situatie zaten de apparaten gewoon allemaal direct of de router aangesloten. Kan het zo zijn dat de switch het netwerk zelfs nog onveiliger maakt als in de oude situatie?
Immers, als je alle devices aan je netwerk vertrouwt heb je, neem ik aan, geen VLANs nodig. Als je wel devices aan je netwerk hebt die potentieel onbetrouwbaar zijn, heeft een switch waarvan het admin wachtwoord tijdens verzenden over het netwerk wordt "versleuteld" middels XOR met "NtgrSmartSwitchRock" (plus een stel andere kwetsbaarheden, zie [2]), tot gevolg dat het voor een aanvaller vanaf zo'n untrusted device niet moeilijk is om al jouw netwerkverkeer af te luisteren - ongeacht geconfigureerde VLANs.
[1] https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357
[2] http://seclists.org/fulldisclosure/2016/Jan/77
Waarom geen TL-SG105E (5 poorten) of TL-SG108E (8 poorten) Easy Smart switch, TP-Link genomen?
Door Erik van Straten:
Immers, als je alle devices aan je netwerk vertrouwt heb je, neem ik aan, geen VLANs nodig. Als je wel devices aan je netwerk hebt die potentieel onbetrouwbaar zijn, heeft een switch waarvan het admin wachtwoord tijdens verzenden over het netwerk wordt "versleuteld" middels XOR met "NtgrSmartSwitchRock" (plus een stel andere kwetsbaarheden, zie [2]), tot gevolg dat het voor een aanvaller vanaf zo'n untrusted device niet moeilijk is om al jouw netwerkverkeer af te luisteren - ongeacht geconfigureerde VLANs.
Immers, als je alle devices aan je netwerk vertrouwt heb je, neem ik aan, geen VLANs nodig. Als je wel devices aan je netwerk hebt die potentieel onbetrouwbaar zijn, heeft een switch waarvan het admin wachtwoord tijdens verzenden over het netwerk wordt "versleuteld" middels XOR met "NtgrSmartSwitchRock" (plus een stel andere kwetsbaarheden, zie [2]), tot gevolg dat het voor een aanvaller vanaf zo'n untrusted device niet moeilijk is om al jouw netwerkverkeer af te luisteren - ongeacht geconfigureerde VLANs.
Dit vind ik nogal hoogdravend. Niet alleen zijn er veel meer toepassingen voor VLAN dan het beveiligen tegen devices
die je niet vertrouwt, maar dan nog kan een device wat jij niet vertrouwt niet meeluisteren met een configuratie sessie
die je vanaf een andere poort met de switch voert.
Daarnaast is de configuratie mode van deze switches zo traag en onhandig dat je dit meestal maar eenmalig doet om
de boel goed in te delen en er dan verder niks meer aan te veranderen.
(nadat je je een avond gefrustreerd hebt over de onhandige manier waarmee je untagged poorten op dit soort switches
moet aanmaken, waarbij je niet alleen moet aangeven welk tag untagged naar buiten gaat op een poort maar ook, op
een ander scherm, welk tag moet worden toegevoegd aan inkomend untagged verkeer op die poort. hetzelfde uiteraard,
in alle behalve een heel theoretisch geval misschien, maar dat heeft de ontwerper van deze switches niet gesnapt)
Als je wel devices aan je netwerk hebt die potentieel onbetrouwbaar zijn, heeft een switch waarvan het admin wachtwoord tijdens verzenden over het netwerk wordt "versleuteld" middels XOR met "NtgrSmartSwitchRock" (plus een stel andere kwetsbaarheden, zie [2]), tot gevolg dat het voor een aanvaller vanaf zo'n untrusted device niet moeilijk is om al jouw netwerkverkeer af te luisteren - ongeacht geconfigureerde VLANs.
[1] https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357
[2] http://seclists.org/fulldisclosure/2016/Jan/77
[1] https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357
[2] http://seclists.org/fulldisclosure/2016/Jan/77
Beetje voorbarig wellicht om hier nog steeds vanuit te gaan.
Even op de Netgear website kijken levert op:
In firmware V1.4.0.9:
Bug Fixes:
* Fixed the security vulnerability issue related to XSS (Cross-Site Scripting) and CSRF (Cross-Site request forgery) attacks..
* Fixed the security vulnerability issue where the web login session ID is predictable.
In ProSAFE Plus Utility V2.4.3:
New Features and Enhancements:
1. Supports more secured encryption algorithm to work with new version of Plus Switch firmware.
23-03-2017, 17:45 door
Erik van Straten
23-03-2017, 10:32 door Anoniem: Dit vind ik nogal hoogdravend. Niet alleen zijn er veel meer toepassingen voor VLAN dan het beveiligen tegen devices die je niet vertrouwt,
Je hebt gelijk dat je VLANs voor andere zaken kunt gebruiken, zoals om grote broadcast domains op te splitsen. Los van het feit dat je dat niet doet met een 5-poorts Netgear switchje, zie ik toch vaak VLANs juist worden ingezet om netwerken te segmenteren om risico's bij malwareinfecties te mitigeren, maar ook om management VLANs te scheiden van productie.Vooral dat laatste doe je niet zomaar. Maar zorg dan ook dat zo'n management VLAN niet benaderbaar is via door ongeautoriseerden letterlijk "aan te raken" apparatuur of kabels. En hou rekening met de andere bekende risico's waar ik er enkele van noemde (waaronder firmware kwetsbaarheden).
23-03-2017, 10:32 door Anoniem: maar dan nog kan een device wat jij niet vertrouwt niet meeluisteren met een configuratie sessie die je vanaf een andere poort met de switch voert.
Als je zo'n switch kunt overnemen, kun je een SPAN port (port mirroring) openzetten en desgewenst alle netwerkverkeer via die switch afluisteren.23-03-2017, 14:48 door Anoniem: [...]
In firmware V1.4.0.9:
[...]
In ProSAFE Plus Utility V2.4.3:
New Features and Enhancements:
1. Supports more secured encryption algorithm to work with new version of Plus Switch firmware.
In GS105Ev2_V1.4.0.9.bin uit http://www.downloads.netgear.com/files/GDC/GS105EV2/GS105Ev2_V1.4.0.9.zip zie ik op offset 0x57BD: "NtgrSmartSwitchRock". Ik vermoed dat als je niet de laatste ProSAFE Plus gebruikt, de "versleuteling" van het wachtwoord nog steeds te wensen overlaat.In firmware V1.4.0.9:
[...]
In ProSAFE Plus Utility V2.4.3:
New Features and Enhancements:
1. Supports more secured encryption algorithm to work with new version of Plus Switch firmware.
En ik ben benieuwd wat een "more secured encryption algorithm" inhoudt (hopelijk niet weer een zelf bedacht "onkraakbaar" algoritme). Waarom niet gewoon proven technology zoals https of ssh gebruiken?
Maar sowieso: ook met de laatste firmware is o.a. deze switch op dit moment nog steeds lek. Uit https://kb.netgear.com/000037849/Security-Advisory-for-Authentication-Bypass-on-ProSAFE-Web-Managed-Switches-PSV-2015-0043 (uit "PSV-2015-0043" leid ik af dat de kwetsbaarheid al in 2015 bekend was bij Netgear):
NETGEAR is aware of a security issue that can allow an attacker to bypass authentication on some models of NETGEAR Web Managed Switches and gain access to a switch’s configuration file and password. This vulnerability only occurs when an attacker is on the same subnet as the switch.
This vulnerability affects the following products:
JGS516PE
JGS524Ev2
JGS524PE
GS105Ev2
GS105PE
GS108Ev3
GS108PEv3
GS116Ev2
GSS108E
GSS116E
XS708Ev2
XS716E
NETGEAR plans to release firmware updates that fix the authentication bypass vulnerability for all affected products by the end of March, 2017. NETGEAR strongly recommends that all users update their firmware as soon as a fix is available.
Gezien hun track history (https://www.cvedetails.com/vulnerability-list/vendor_id-834/Netgear.html) heb ik een voorgevoel dat dit niet het laatste lek ooit in Netgear spul is.This vulnerability affects the following products:
JGS516PE
JGS524Ev2
JGS524PE
GS105Ev2
GS105PE
GS108Ev3
GS108PEv3
GS116Ev2
GSS108E
GSS116E
XS708Ev2
XS716E
NETGEAR plans to release firmware updates that fix the authentication bypass vulnerability for all affected products by the end of March, 2017. NETGEAR strongly recommends that all users update their firmware as soon as a fix is available.
Gezien hun track history (https://www.cvedetails.com/vulnerability-list/vendor_id-834/Netgear.html) heb ik een voorgevoel dat dit niet het laatste lek ooit in Netgear spul is.
Dat is geen voorgevoel Erik. Dat is zo goed als wetenschap! Die V1.4.0.9 firmware dateert nog van vorig jaar, dus volgens Netgear's belofte moet er in ieder geval nog een nieuwere firmware uitkomen deze maand.
(ts)
Op een poort zitten allemaal apparaten die wifi gebruiken, op de andere zitten apparaten doe via kabel zijn aangesloten. In principe acht ik de met kabel aangesloten apparaten op het netwerk . De switch heb ik geconfugeerd toen deze niet aan het netwerk was gekoppeld, in principe hoef ik er nu meer op in te loggen, echter als er security problemen zijn waardoor de switch kan worden overgenomen van schiet het weinig op.
Verder als alles direct op de router is aangesloten kan een aanvaller dan niet eenvoudig met al het verkeer mee kijken?
Ben wel benieuwd wat hier een betrouwbare methode wordt gevonden om apparaten in een netwerk te scheiden.
Bedankt voor het melden dat er een update in pijpleiding zit, ik hou het in de gaten en installeer hem als hij beschikbaar is.
Op een poort zitten allemaal apparaten die wifi gebruiken, op de andere zitten apparaten doe via kabel zijn aangesloten. In principe acht ik de met kabel aangesloten apparaten op het netwerk . De switch heb ik geconfugeerd toen deze niet aan het netwerk was gekoppeld, in principe hoef ik er nu meer op in te loggen, echter als er security problemen zijn waardoor de switch kan worden overgenomen van schiet het weinig op.
Verder als alles direct op de router is aangesloten kan een aanvaller dan niet eenvoudig met al het verkeer mee kijken?
Ben wel benieuwd wat hier een betrouwbare methode wordt gevonden om apparaten in een netwerk te scheiden.
Bedankt voor het melden dat er een update in pijpleiding zit, ik hou het in de gaten en installeer hem als hij beschikbaar is.
Door Erik van Straten:
Vooral dat laatste doe je niet zomaar. Maar zorg dan ook dat zo'n management VLAN niet benaderbaar is via door ongeautoriseerden letterlijk "aan te raken" apparatuur of kabels. En hou rekening met de andere bekende risico's waar ik er enkele van noemde (waaronder firmware kwetsbaarheden).
En ik ben benieuwd wat een "more secured encryption algorithm" inhoudt (hopelijk niet weer een zelf bedacht "onkraakbaar" algoritme). Waarom niet gewoon proven technology zoals https of ssh gebruiken?
Maar sowieso: ook met de laatste firmware is o.a. deze switch op dit moment nog steeds lek. Uit https://kb.netgear.com/000037849/Security-Advisory-for-Authentication-Bypass-on-ProSAFE-Web-Managed-Switches-PSV-2015-0043 (uit "PSV-2015-0043" leid ik af dat de kwetsbaarheid al in 2015 bekend was bij Netgear):
23-03-2017, 10:32 door Anoniem: Dit vind ik nogal hoogdravend. Niet alleen zijn er veel meer toepassingen voor VLAN dan het beveiligen tegen devices die je niet vertrouwt,
Je hebt gelijk dat je VLANs voor andere zaken kunt gebruiken, zoals om grote broadcast domains op te splitsen. Los van het feit dat je dat niet doet met een 5-poorts Netgear switchje, zie ik toch vaak VLANs juist worden ingezet om netwerken te segmenteren om risico's bij malwareinfecties te mitigeren, maar ook om management VLANs te scheiden van productie.Vooral dat laatste doe je niet zomaar. Maar zorg dan ook dat zo'n management VLAN niet benaderbaar is via door ongeautoriseerden letterlijk "aan te raken" apparatuur of kabels. En hou rekening met de andere bekende risico's waar ik er enkele van noemde (waaronder firmware kwetsbaarheden).
23-03-2017, 10:32 door Anoniem: maar dan nog kan een device wat jij niet vertrouwt niet meeluisteren met een configuratie sessie die je vanaf een andere poort met de switch voert.
Als je zo'n switch kunt overnemen, kun je een SPAN port (port mirroring) openzetten en desgewenst alle netwerkverkeer via die switch afluisteren.23-03-2017, 14:48 door Anoniem: [...]
In firmware V1.4.0.9:
[...]
In ProSAFE Plus Utility V2.4.3:
New Features and Enhancements:
1. Supports more secured encryption algorithm to work with new version of Plus Switch firmware.
In GS105Ev2_V1.4.0.9.bin uit http://www.downloads.netgear.com/files/GDC/GS105EV2/GS105Ev2_V1.4.0.9.zip zie ik op offset 0x57BD: "NtgrSmartSwitchRock". Ik vermoed dat als je niet de laatste ProSAFE Plus gebruikt, de "versleuteling" van het wachtwoord nog steeds te wensen overlaat.In firmware V1.4.0.9:
[...]
In ProSAFE Plus Utility V2.4.3:
New Features and Enhancements:
1. Supports more secured encryption algorithm to work with new version of Plus Switch firmware.
En ik ben benieuwd wat een "more secured encryption algorithm" inhoudt (hopelijk niet weer een zelf bedacht "onkraakbaar" algoritme). Waarom niet gewoon proven technology zoals https of ssh gebruiken?
Maar sowieso: ook met de laatste firmware is o.a. deze switch op dit moment nog steeds lek. Uit https://kb.netgear.com/000037849/Security-Advisory-for-Authentication-Bypass-on-ProSAFE-Web-Managed-Switches-PSV-2015-0043 (uit "PSV-2015-0043" leid ik af dat de kwetsbaarheid al in 2015 bekend was bij Netgear):
NETGEAR is aware of a security issue that can allow an attacker to bypass authentication on some models of NETGEAR Web Managed Switches and gain access to a switch’s configuration file and password. This vulnerability only occurs when an attacker is on the same subnet as the switch.
This vulnerability affects the following products:
JGS516PE
JGS524Ev2
JGS524PE
GS105Ev2
GS105PE
GS108Ev3
GS108PEv3
GS116Ev2
GSS108E
GSS116E
XS708Ev2
XS716E
NETGEAR plans to release firmware updates that fix the authentication bypass vulnerability for all affected products by the end of March, 2017. NETGEAR strongly recommends that all users update their firmware as soon as a fix is available.
Gezien hun track history (https://www.cvedetails.com/vulnerability-list/vendor_id-834/Netgear.html) heb ik een voorgevoel dat dit niet het laatste lek ooit in Netgear spul is.This vulnerability affects the following products:
JGS516PE
JGS524Ev2
JGS524PE
GS105Ev2
GS105PE
GS108Ev3
GS108PEv3
GS116Ev2
GSS108E
GSS116E
XS708Ev2
XS716E
NETGEAR plans to release firmware updates that fix the authentication bypass vulnerability for all affected products by the end of March, 2017. NETGEAR strongly recommends that all users update their firmware as soon as a fix is available.
Niet om hun track historie te verdedigen, maar in deze context hebben we het over switches in een intern netwerk... als je je daar zorgen wilt gaan maken over softwarematige aanvallen moet je dit probleem wat stappen eerder oplossen (firewall / 802.1x)
Door Erik van Straten:
23-03-2017, 10:32 door Anoniem: maar dan nog kan een device wat jij niet vertrouwt niet meeluisteren met een configuratie sessie die je vanaf een andere poort met de switch voert.
Als je zo'n switch kunt overnemen, kun je een SPAN port (port mirroring) openzetten en desgewenst alle netwerkverkeer via die switch afluisteren.Jaja, dus jij probeert het configuratie wachtwoord van de switch te achterhalen door mee te luisteren met een
configuratie sessie op een andere poort en dat ga je bereiken door eerst de switch over te nemen en een port
mirroring te configureren. Okeee.
Kijk nog even los van deze wat vreemde aanpak: dit zijn switches voor een thuisnetwerk+ en worden ingezet om
wat simpele dingen te kunnen regelen zoals het trunken van TV en DATA over dezelfde kabel van meterkast naar
huiskamer bijvoorbeeld. Als je er fortune500 corporate security mee dacht te gaan regelen heb je een product
uit het verkeerde segment te pakken.
24-03-2017, 15:48 door
Erik van Straten
24-03-2017, 10:36 door Anoniem: Jaja, dus jij probeert het configuratie wachtwoord van de switch te achterhalen door mee te luisteren met een configuratie sessie op een andere poort en dat ga je bereiken door eerst de switch over te nemen en een port mirroring te configureren. Okeee.
Misschien dat je het wel leest als ik het nog eens herhaal?23-03-2017, 17:45 door Erik van Straten: [...]
Uit https://kb.netgear.com/000037849/Security-Advisory-for-Authentication-Bypass-on-ProSAFE-Web-Managed-Switches-PSV-2015-0043 (uit "PSV-2015-0043" leid ik af dat de kwetsbaarheid al in 2015 bekend was bij Netgear):
Uit https://kb.netgear.com/000037849/Security-Advisory-for-Authentication-Bypass-on-ProSAFE-Web-Managed-Switches-PSV-2015-0043 (uit "PSV-2015-0043" leid ik af dat de kwetsbaarheid al in 2015 bekend was bij Netgear):
NETGEAR is aware of a security issue that can allow an attacker to bypass authentication on some models of NETGEAR Web Managed Switches and gain access to a switch’s configuration file and password. This vulnerability only occurs when an attacker is on the same subnet as the switch.
[...]
[...]
24-03-2017, 10:36 door Anoniem: Kijk nog even los van deze wat vreemde aanpak: dit zijn switches voor een thuisnetwerk+ en worden ingezet om wat simpele dingen te kunnen regelen zoals het trunken van TV en DATA over dezelfde kabel van meterkast naar huiskamer bijvoorbeeld. Als je er fortune500 corporate security mee dacht te gaan regelen heb je een product uit het verkeerde segment te pakken.
Misschien dat je het wel leest als ik het nog eens herhaal? 22-03-2017, 23:31 door Erik van Straten - Bijgewerkt: 22-03-2017, 23:47: [...]
Als de huidige firmware van deze low-budget managed Netgear switches nog net zo lek is als toen ik ernaar keek in 2014 (zie mijn bijdrage onderaan in [1]) en iemand anders in 2016 (zie [2]), zou ik dit soort apparaten persoonlijk niet in netwerken opnemen - zelfs niet in m'n thuisnetwerk.
[...]
[1] https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357
[2] http://seclists.org/fulldisclosure/2016/Jan/77
Als de huidige firmware van deze low-budget managed Netgear switches nog net zo lek is als toen ik ernaar keek in 2014 (zie mijn bijdrage onderaan in [1]) en iemand anders in 2016 (zie [2]), zou ik dit soort apparaten persoonlijk niet in netwerken opnemen - zelfs niet in m'n thuisnetwerk.
[...]
[1] https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357
[2] http://seclists.org/fulldisclosure/2016/Jan/77
Door Erik van Straten:
24-03-2017, 10:36 door Anoniem: Jaja, dus jij probeert het configuratie wachtwoord van de switch te achterhalen door mee te luisteren met een configuratie sessie op een andere poort en dat ga je bereiken door eerst de switch over te nemen en een port mirroring te configureren. Okeee.
Misschien dat je het wel leest als ik het nog eens herhaal?23-03-2017, 17:45 door Erik van Straten: [...]
Uit https://kb.netgear.com/000037849/Security-Advisory-for-Authentication-Bypass-on-ProSAFE-Web-Managed-Switches-PSV-2015-0043 (uit "PSV-2015-0043" leid ik af dat de kwetsbaarheid al in 2015 bekend was bij Netgear):
Uit https://kb.netgear.com/000037849/Security-Advisory-for-Authentication-Bypass-on-ProSAFE-Web-Managed-Switches-PSV-2015-0043 (uit "PSV-2015-0043" leid ik af dat de kwetsbaarheid al in 2015 bekend was bij Netgear):
NETGEAR is aware of a security issue that can allow an attacker to bypass authentication on some models of NETGEAR Web Managed Switches and gain access to a switch’s configuration file and password. This vulnerability only occurs when an attacker is on the same subnet as the switch.
[...]
[...]
24-03-2017, 10:36 door Anoniem: Kijk nog even los van deze wat vreemde aanpak: dit zijn switches voor een thuisnetwerk+ en worden ingezet om wat simpele dingen te kunnen regelen zoals het trunken van TV en DATA over dezelfde kabel van meterkast naar huiskamer bijvoorbeeld. Als je er fortune500 corporate security mee dacht te gaan regelen heb je een product uit het verkeerde segment te pakken.
Misschien dat je het wel leest als ik het nog eens herhaal? 22-03-2017, 23:31 door Erik van Straten - Bijgewerkt: 22-03-2017, 23:47: [...]
Als de huidige firmware van deze low-budget managed Netgear switches nog net zo lek is als toen ik ernaar keek in 2014 (zie mijn bijdrage onderaan in [1]) en iemand anders in 2016 (zie [2]), zou ik dit soort apparaten persoonlijk niet in netwerken opnemen - zelfs niet in m'n thuisnetwerk.
[...]
[1] https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357
[2] http://seclists.org/fulldisclosure/2016/Jan/77
Als de huidige firmware van deze low-budget managed Netgear switches nog net zo lek is als toen ik ernaar keek in 2014 (zie mijn bijdrage onderaan in [1]) en iemand anders in 2016 (zie [2]), zou ik dit soort apparaten persoonlijk niet in netwerken opnemen - zelfs niet in m'n thuisnetwerk.
[...]
[1] https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357
[2] http://seclists.org/fulldisclosure/2016/Jan/77
Het maakt niet uit hoe vaak je het herhaalt als het niet strookt met de situatie. Hier worden de switches NIET ingezet als semi-fysieke beveiliging... zowel, dan zijn dit switches uit het verkeerde segment en moet je op zoek naar hardware die 802.1x kan toepassen. Toevallig-genoeg ondersteunen de switches die specifieke functie niet. Dit is niet echt anders dan een gebruiker een complete security-oplossing aan te raden terwijl dat alles-behalve het doel is.
Door Erik van Straten:
Immers, als je alle devices aan je netwerk vertrouwt heb je, neem ik aan, geen VLANs nodig. Als je wel devices aan je netwerk hebt die potentieel onbetrouwbaar zijn, heeft een switch waarvan het admin wachtwoord tijdens verzenden over het netwerk wordt "versleuteld" middels XOR met "NtgrSmartSwitchRock" (plus een stel andere kwetsbaarheden, zie [2]), tot gevolg dat het voor een aanvaller vanaf zo'n untrusted device niet moeilijk is om al jouw netwerkverkeer af te luisteren - ongeacht geconfigureerde VLANs.
[1] https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357
[2] http://seclists.org/fulldisclosure/2016/Jan/77
22-03-2017, 00:18 door Anoniem: (TS)
[...]
Het betreft overigens een netgear prosafe GS105Ev2 switch (nog niet vermeld)
en[...]
Het betreft overigens een netgear prosafe GS105Ev2 switch (nog niet vermeld)
22-03-2017, 14:58 door Anoniem: (TS)
[...]
Echter wat betreft jouw laatste alinea, in de oude situatie zaten de apparaten gewoon allemaal direct of de router aangesloten. Kan het zo zijn dat de switch het netwerk zelfs nog onveiliger maakt als in de oude situatie?
Ja. Als de huidige firmware van deze low-budget managed Netgear switches nog net zo lek is als toen ik ernaar keek in 2014 (zie mijn bijdrage onderaan in [1]) en iemand anders in 2016 (zie [2]), zou ik dit soort apparaten persoonlijk niet in netwerken opnemen - zelfs niet in m'n thuisnetwerk.[...]
Echter wat betreft jouw laatste alinea, in de oude situatie zaten de apparaten gewoon allemaal direct of de router aangesloten. Kan het zo zijn dat de switch het netwerk zelfs nog onveiliger maakt als in de oude situatie?
Immers, als je alle devices aan je netwerk vertrouwt heb je, neem ik aan, geen VLANs nodig. Als je wel devices aan je netwerk hebt die potentieel onbetrouwbaar zijn, heeft een switch waarvan het admin wachtwoord tijdens verzenden over het netwerk wordt "versleuteld" middels XOR met "NtgrSmartSwitchRock" (plus een stel andere kwetsbaarheden, zie [2]), tot gevolg dat het voor een aanvaller vanaf zo'n untrusted device niet moeilijk is om al jouw netwerkverkeer af te luisteren - ongeacht geconfigureerde VLANs.
[1] https://isc.sans.edu/forums/diary/Hardcoded+Netgear+Prosafe+Switch+Password/18357
[2] http://seclists.org/fulldisclosure/2016/Jan/77
Meeste (Enterprise) routers en switches zijn ook aardig lek daar is niks nieuws aan, het is simpel weg game over als iemand code kan excuteren or priviledge kan escaleren.
Dus zorg dat je alleen over ssh met die switches/routers kan verbinden en geen webgui.
Als poort 1 van de switch en de poort van de router zelf netjes geconfigureerd zijn als vlan-trunk-poort en als er sprake is van twee aparte subnetten met ieder een correct geconfigureerd ip-adres op de router (de beide vlans moeten daar zichtbaar zijn als aparte subinterfaces of ip-adres-configureerbare vlans), dan is alles d.m.v. IP met elkaar verbonden. Dus alles is te pingen. Blokkeren is mogelijk d.m.v firewall-regels op de router (ACL, VACL, of iets dergelijks).
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
