Veiligheid VLAN's

[josvane]

Binnen mijn productie netwerk maak ik gebruik van Procurve 2524 switches. Hier zijn vlan's op aangemaakt en in gebruik.

Nu heb ik er drie in gebruik en één daarvan hangt een pand verder. Nu heb ik juist in dat pand een publiek IP nodig. Dit kan ik realiseren door "DMZ" vlan aan te maken en dan middels untagged poort het publieke gedeelte beschikbaar te maken.

Concreet is dus mijn vraag hoe veilig zijn vlan's. In de switch kun ip-authorized managers aanmaken, en op de desbetreffende vlan het ip op none zetten.

Maar kan ik nog meer veiligheid creeren, of zijn vlan's afdoende.

[CyBeR]

Tegen welke bedreiging wil je je beschermen?

[Noxious]

Als je op een poort maar een enkele vlan beschikbaar maakt is dat veilig genoeg.
Wel zou ik zorgen dat de ProCurve's de laatste software versie hebben, er zijn bij diverse modellen wat bugs bekend van 'data leaks' tussen vlans en problemen bij het switchen van vlan op poortjes (lange timeouts, enz).
Deze worden bij recentere firmwares opgelost.

[josvane]

CyBeR schreef op dinsdag 14 februari 2012 @ 17:08:
Tegen welke bedreiging wil je je beschermen?

Het is niet zozeer dat ik mij erg tegen wil beveiligen, mijn cisco router laat alleen de benodigde poorten door middels access-lists.

Maar ik wil niet de deuren open zetten, zeg maar.

[Jazzy]

Netwerken scheiden door middel van VLANs is breed geaccepteerd als een veilige oplossing. Als je een stap verder wilt gaan dan praat je over fysiek gescheiden netwerken. Tja...

[WhizzCat]

^^ Met Japy.

Laatste of een na laatste firmware d'r op en zorgen dat je je idee op papier netjes hebt, daarna doen zoals je hierboven zegt. Vlans zijn afdoende, zeker i.c.m. met een goeie Cisco router/firewall/access-lists (Firewall is 't mooiste natuurlijk, voor statefull zaken etc. )

[CyBeR]

josvane schreef op dinsdag 14 februari 2012 @ 17:28:
[...]

Het is niet zozeer dat ik mij erg tegen wil beveiligen, mijn cisco router laat alleen de benodigde poorten door middels access-lists.

Maar ik wil niet de deuren open zetten, zeg maar.

Als je in het VLAN met je publieke IP's geen IP aan de switch toewijst, zet je geen enkele deur zelfs maar op een kier. Zo wel, moet je vooral zorgen dat de authenticatie naar je switch goed zit en dat je erop let dat je recente firmware gebruikt.

[bazkar]

Ik neem aan dat je tussen de panden hierdoor een trunk nodig hebt. Houdt in dat geval wel rekening met VLAN hopping risico's (in dit geval double tagging). Ik ken je netwerk setup niet goed genoeg om het risico helemaal in te schatten en groot is het niet, maar lees onderstaand artikel na en check of dit op jouw setup van toepassing is:

Wikipedia: VLAN hopping

(voornamelijk het example bij double tagging)

[CyBeR]

Vrijwel alle switches fixen double-tagging door alle tags weg te slopen bij het untaggen van frames.

En sowieso om dat te doen moet je je in een positie bevinden om vlan tags toe te voegen aan je frames, en een internetter is dat niet.

[ Voor 40% gewijzigd door CyBeR op 15-02-2012 10:43 ]

[Keiichi]

De vlans op switches zijn veilig. Wat het minder veilig kan maken zijn de routers die zich tussen de vlans begeven.

Ter illustratie, ik heb een vlan die bedoeld is voor allerhande management interfaces, zoals een out-of-band management kaart. Als ik met mijn PC in hetzelfde vlan zit, kan ik hier aan. Als ik in een ander vlan zit niet.
Maar stel dat ik per abuis mijn router in 2 het management vlan en een ander vlan zet en routing tussen de vlans aanzet, dan kan iedereen er opeens aan die in het andere vlan zit.

[Paul]

De enige zaken die roet in het eten kunnen gooien zijn:

• Je switches een publiek IP (+gateway) geven en het management VLAN instellen op het VLAN met de publieke IP-adressen (huge sysop-error, kans: erg klein)
• Een router instellen dat je vrijelijk tussen alle VLANs mag communiceren. Zonder NAT kom je waarschijnlijk niet veel verder dan de router van je internetprovider, met NAT kom je van buiten enkel binnen over de port forwards (en eventuele lekken in de router). Ook dit heb je zelf compleet in de hand en staat los van VLANs an sich.
• Een apparaat aansluiten op een trunkpoort. Dit apparaat kan bij alle VLANs waar de poort lid van is, vergelijkbaar met meerdere netwerkkaarten in die PC stoppen en een kabeltje naar de fysieke netten leggen.

Al met al niks dat inherent onveilig is aan VLANs, je moet je alleen wel bewust zijn van de implicaties

[bazkar]

CyBeR schreef op woensdag 15 februari 2012 @ 10:42:
Vrijwel alle switches fixen double-tagging door alle tags weg te slopen bij het untaggen van frames.

En sowieso om dat te doen moet je je in een positie bevinden om vlan tags toe te voegen aan je frames, en een internetter is dat niet.

Een internetter ergens op het wilde internet niet, maar iemand die in hetzelfde laag 2 segment zit als het publieke IP wel. Iemand die dus een willekeurige DMZ host over weet te nemen (gegeven dat het DMZ geen private VLAN is), is binnen.

Voor de andere opmerking zie ik graag een bron aangezien wij voorlopig nog altijd redelijk wat geld investeren om zowel public als private DMZ als een fysiek gescheiden netwerk aanbieden met firewalling ertussen om dit risico te voorkomen.

[CyBeR]

Paul schreef op woensdag 15 februari 2012 @ 10:57:
De enige zaken die roet in het eten kunnen gooien zijn:
[ul]• Je switches een publiek IP (+gateway) geven en het management VLAN instellen op het VLAN met de publieke IP-adressen (huge sysop-error, kans: erg klein)

Niet noodzakelijkerwijs een groot probleem, tenzij je authenticatie ook kut is. D'r kan altijd een bug in zitten natuurlijk, maar normaal gesproken zijn die dingen redelijk veilig. D'r hangen er duizenden van aan het publieke internet bij colo's e.d.

bazkar schreef op woensdag 15 februari 2012 @ 11:01:
[...]


Een internetter ergens op het wilde internet niet, maar iemand die in hetzelfde laag 2 segment zit als het publieke IP wel. Iemand die dus een willekeurige DMZ host over weet te nemen (gegeven dat het DMZ geen private VLAN is), is binnen.

Fair point. Maar dit is nadat 't al mis is gegaan he.

Voor de andere opmerking zie ik graag een bron aangezien wij voorlopig nog altijd redelijk wat geld investeren om zowel public als private DMZ als een fysiek gescheiden netwerk aanbieden met firewalling ertussen om dit risico te voorkomen.

Ik heb daar zelf toen ik nog op de universiteit zat een onderzoekje naar gedaan. De switches die ik probeerde (van verschillende vendors, in verschillende segmenten, dwz goedkoper en duurder) vertoonden geen van allen dit probleem. Dat mocht ook wel want dat double-tagging probleem is al bekend sinds het begin van 802.1q en die spec is ook al weer een flink aantal jaartjes oud.

Wat ik wel niet getest heb en waar 't dus de moeite loont om op te letten, is switches die zelf double-tagging ondersteunen (Q-in-Q). Dat zou met andere ethernet id's moeten gaan en dus alsnog geen probleem moeten zijn, maar ik kan er weinig over zeggen.

[ Voor 7% gewijzigd door CyBeR op 15-02-2012 12:09 ]

[bazkar]

CyBeR schreef op woensdag 15 februari 2012 @ 11:59:


Ik heb daar zelf toen ik nog op de universiteit zat een onderzoekje naar gedaan. De switches die ik probeerde (van verschillende vendors, in verschillende segmenten, dwz goedkoper en duurder) vertoonden geen van allen dit probleem. Dat mocht ook wel want dat double-tagging probleem is al bekend sinds het begin van 802.1q en die spec is ook al weer een flink aantal jaartjes oud.

Wat ik wel niet getest heb en waar 't dus de moeite loont om op te letten, is switches die zelf double-tagging ondersteunen (Q-in-Q). Dat zou met andere ethernet id's moeten gaan en dus alsnog geen probleem moeten zijn, maar ik kan er weinig over zeggen.

Ik heb dit getest met een aantal van onze meest gangbare Cisco Catalysts (2960, 3560, 3750) en daar werkt het allemaal vlekkeloos (of juist niet afhankelijk van hoe je dat ziet). M.a.w. daar is double tagging 'gewoon' mogelijk (wellicht inderdaad met opzet?)

[Paul]

CyBeR schreef op woensdag 15 februari 2012 @ 11:59:
Niet noodzakelijkerwijs een groot probleem, tenzij je authenticatie ook kut is. D'r kan altijd een bug in zitten natuurlijk, maar normaal gesproken zijn die dingen redelijk veilig. D'r hangen er duizenden van aan het publieke internet bij colo's e.d.

Veel switches hebben 'gewoon' een webinterface of telnet server, dichtzetten op IP-adres of inlogpogingen na X keer blokkeren zit er lang niet altijd in

Veel bedrijven hebben switches waarbij je dat soort dingen wel in kunt stellen, maar er zijn er nog veel meer waarbij dat niet kan. Dan is het dus slimmer om je managementinterface niet direct aan internet te hangen

[CyBeR]

bazkar schreef op woensdag 15 februari 2012 @ 12:22:
[...]


Ik heb dit getest met een aantal van onze meest gangbare Cisco Catalysts (2960, 3560, 3750) en daar werkt het allemaal vlekkeloos (of juist niet afhankelijk van hoe je dat ziet). M.a.w. daar is double tagging 'gewoon' mogelijk (wellicht inderdaad met opzet?)

Hmm, grappig. Het is even geleden maar ik heb 't toen in ieder geval getest met een HP switch en die stripte de extra tags er netjes af. Als Cisco dat niet doet lijkt me dat iets wat ze expres doen, maar dan is 't inderdaad iets waar je op moet letten bij je netwerkontwerp. Mischien is er ergens een instelling voor die default niet aan staat? Heb je 't trouwens wel over twee dezelfde tags of zoals in Q-in-Q twee tags met verschillende ethernet id's? (0x8100 en 0x9100 zeg ik uit m'n hoofd)

Paul schreef op woensdag 15 februari 2012 @ 12:27:
[...]
Veel switches hebben 'gewoon' een webinterface of telnet server, dichtzetten op IP-adres of inlogpogingen na X keer blokkeren zit er lang niet altijd in

Veel bedrijven hebben switches waarbij je dat soort dingen wel in kunt stellen, maar er zijn er nog veel meer waarbij dat niet kan. Dan is het dus slimmer om je managementinterface niet direct aan internet te hangen

Nogmaals, als je authenticatie niet bestaat uit 'admin' invoeren in een webformuliertje is het niet een enorm probleem om een switch een publiek IP te geven. Ik heb er meerdere die precies dat doen, niet in de minste plek omdat dat niet doen voor mij juist enorme nadelen heeft. De authenticatie op mijn switches is natuurlijk wel gewoon even sterk als die op m'n servers.

Dat sommige mensen altijd zo panisch doen over management interfaces van switches doet mij denken dat dat mensen zijn die hun authenticatie als je eenmaal bij die interface kunt compleet niet op orde hebben.

[ Voor 5% gewijzigd door CyBeR op 15-02-2012 12:41 ]

[Paul]

Fijn dat jouw switches zulke goede management-meukjes hebben (al moet ik zelf de eerste nog tegenkomen die een account al dan niet tijdelijk kan blokkeren na een aantal gefaalde pogingen; het in kunnen geven van de management-stations kom ik wel regelmatig tegen), vooral de goedkopere switches hebben dat niet.

Dat je geen 'admin' als wachtwoord moet gebruiken lijkt me vrij evident, daar ga ik dan ook maar niet op ik

[bazkar]

CyBeR schreef op woensdag 15 februari 2012 @ 12:40:
[...]


Hmm, grappig. Het is even geleden maar ik heb 't toen in ieder geval getest met een HP switch en die stripte de extra tags er netjes af. Als Cisco dat niet doet lijkt me dat iets wat ze expres doen, maar dan is 't inderdaad iets waar je op moet letten bij je netwerkontwerp. Mischien is er ergens een instelling voor die default niet aan staat? Heb je 't trouwens wel over twee dezelfde tags of zoals in Q-in-Q twee tags met verschillende ethernet id's? (0x8100 en 0x9100 zeg ik uit m'n hoofd)

Twee 802.1q tags achter elkaar met een verschillende VLAN id.

[PenguinPower]

Ik zit dit topic met stuiterende verbazing te lezen.
Is iedereen vervroegt met carnaval gegaan? Ik had wel een klein beetje tegenstand verwacht.

Van network devices die niet primair voor beveiliging ontworpen zijn, hoef je niet te verwachten dat ze weerstand tegen welke aanval dan ook geven. Mogelijk krijg je er alleen maar beveiligings problemen erbij.

De procurve 2500 serie (2510 serie niet meegeteld) staan niet bekend om hun erg snelle processor. Wanneer er netwerk congestion plaatsvind op je netwerk, en je CPU overladen raakt, is het onbekend hoe je switch gaat dit handelen en misschien flood hij wel alles vol. Dit moet/mag/zal niet gebeuren bij een security device, omdat deze ontworpen is bij twijfel te blokkeren. Een switch heeft het omgekeerde ontwerp, aangezien de primaire taak is om te distibueren.

Om maar niet te spreken van de firmware fouten die niet met de dezelfde prioriteit worden opgelost als security devices.

Hiermee zeg ik niet dat je het niet moet doen. Dat is vanzelfsprekend je eigen afweging, ik zou er wel 3x over na denken, voordat ik dit zou implementeren
Om dezelfde reden ben ik ook een tegenstander om software firewall zoals TMG/ISA te virtualiseren! (gezien de virtuele netwerkkaarten/vswitches enzovoort)

[Keiichi]

Mogen we niet van een apparaat verwachten dat ie doet wat ie moet doen? Ik kan me voorstellen als het apparaat overloaded is, dat je problemen met verbinding/snelheid/etc gaat krijgen, maar dat er dan opeens packets terecht komen waar het niet hoort?

Wellicht dat het vroeger het geval kon zijn.

Over virtualiseren? Ik heb van extremenetwork een praatje bekeken waarin ze melden dat gevirtualiseerd verkeer gewoon door de switch afgehandeld kan worden alvorens deze naar wellicht dezelfde host terug te sturen. Gewoon omdat een gevirtualiseerde switch niet vlot genoeg werkt. Hieraan trek ik conclusie dat het voor fw's en andere security apparaten niet anders geld.

Ik zou vlan's blijven inzetten waar ik in andere situaties graag een los fysiek netwerk gezien had met een oogje op security, waarbij veiligheid niet hyperkritisch is (netwerk van een bankwezen bv)

[PenguinPower]

Keiichi schreef op vrijdag 17 februari 2012 @ 19:49:
Mogen we niet van een apparaat verwachten dat ie doet wat ie moet doen?

Dat zou de wereld wel een stuk gemakkelijker maken, en defense in depth overbodig.

Een vlan is simpel weg een segmentatie tool ter verbetering van de netwerk performance, geen security feature (op de management vlan na dan in Provurve termen, die apparte beveiligingsstatus heeft binnen een switch).

Daarom moet je er goed overnadenken, en afwegen op het moment dat je het wel als security feature gaat gebruiken.

[Keiichi]

Ik heb in mijn netwerk bv een apart VLAN voor out-of-band management kaarten op servers en configuratie interfaces van switches. Alle aparaten zijn voorzien van nodige security patches van firmware en van een gebruikersnaam/wachtwoord combinatie.

De rede die ik opvoer is dat gebruikers of onbekende niet qua L2 en L3 niveau aan mijn management kan, waardoor mochten ze echt graag er in willen, dat ze eerst in m'n vlan moeten breken (dit kan al door een vpn verbinding te kraken bv) voordat ze uberhaupt een gooi kunnen doen om in te breken in een management console.

Is dit samen met de rede die ik op voer good-practice van het inzetten van een VLAN als 'security'?

[DukeBox]

VLAN is een management oplossing, niet een security.. maar in het geval van een DMZ verlengen zie ik geen problemen. Wil je nog een extra laag toevoegen, dan zou je kunnen tunnelen.
Hoe dan ook, natuurlijk niet je switches een IP interface geven in het betreffende VLAN.