misschien een gekke vraag. maar in welke prijs klasse zat je te denken?

in welke omgeving kom de switch te hangen? welke eisen stel je aan de snelheid 100Mbit of ook GBit uplink? wat voor bekabeling wil je gebruiken? hoeveel porten moet je minimaal hebben? dit zijn een aantal dingen die je voor je zelf op een rijtje moet hebben.

Vervolgens moet je gaan kijken wat je wilt beheren met de switch, wil je puur alleen netwerk verkeer switchen of wil je ook met Vlans werken. De eisen die je er aanstelt maken ook de prijsklasse deels uit.

Als je je eisen op een rijtje hebt en ongeveer de prijs klasse bepaalt kun je gaan kijken welke switches in aanmerkingen komen aan de hand van de gestelde eisen. Een switch die in een kantoor van 10 man komt te hangen die dagelijks wat documenten op de werkvloer opvragen hoeven lang niet zo geavanceerd te zijn als wanneer er 50 man de gehele dag zware applicaties over het netwerk gaan draaien.

Privé: de prijs

Zakelijk:
1. By default is een switch geen security device ([url=http://www.youtube.com/watch?v=JNTsd7w-Ibk]video[/url], de oorspronkelijke video en deel 2 ervan staan onderaan [url=http://www.informit.com/podcasts/channel.aspx?c=efe8cc1f-a28a-4c9d-b6a7-961ed8948f75]deze page[/url]).

2. Als je er een security device van probeert te maken verwacht dan veel uitzoek- en helpdeskwerk (koop het in de video genoemde boek van de geïnterviewde Belg Eric Vyncke, tevens auteur van een van de eerste netwerksniffers genaamd [url=http://alpha.hec.be/~evyncke/utilities/ethload/index.htm]ETHLOAD[/url]).

Bedankt voor je reactie en het is zeker geen gekke vraag MAAR het gaat me puur of het mogelijk is om extra security in het netwerk aan te brengen even los van de kosten, aantal gebruikers en of snelheid.

Bedankt Bitwiper voor je reactie en de informatiebronnen :)
Ik zal hier zeker aandacht aan besteden.

Beste CPT(M)

Het is wel mogelijk om een switch onderdeel te maken van je totale beveiliging, je moet dan echter wat meer doen dan alleen een switch in je netwerk hangen. Met IDP is het mogelijk je netwerk zodanig af te schermen dat een indringer die zijn apparatuur op het netwerk aansluit wordt geblocked op de switch, de poort wordt vervolgens pas open gezet als daar vanuit het netwerk een akkoord voor wordt gegeven.

dit is absoluut waar. al kijk je alleen de mogelijkheden van een cisco switch die kun je met veel apparatuur samen laten werken biijvoorbeeld met een ASA firewall en of een IPS, en dan nog maar niet te spreken over de combinatie met een cs-mars maar dan heb je het wel over geld :P

Bedankt voor je reactie.
IDP is bij mij bekend, ik neem aan zoals Predjuh vermeld dat de switch moet kunnen samenwerken met andere hardware waarop IDP of een Firewall draait!! Dus als ik bijvoorbeeld zou kiezen voor Cisco switch dan zal de IDP en of Firewall hardware ook van Cisco vandaan moeten komen!

Standaard weet ik bijvoorbeeld dat de de 4200SI van 3COM ook een aantal security opties heeft, zoals Port security.
Is dit basis security, maken jullie hier ook gebruik van!

Mijn suggesties zijn gebaseerd op mogelijkheden die geboden worden middels Cisco switches.

Port Security: Het is mogelijk om toegang tot een poort te beperken tot één MAC adres. Als de poort een ander MAC adres merkt, wordt de poort automatisch uitgezet.
Let wel op de schaalbaarheid. Voor grote organisaties kan dit arbeidsintensief zijn. Een poort die zichzelf uitschakelt zal tenslotte weer open gezet moeten worden.

VLANs:
Cisco gebruikt het VLAN 1 concept voor beheer functionaliteiten. Een ACL kan dan gebruikt worden om VLAN 1 te beschermen. Het is daarom aan te bevelen om het overige verkeer een andere VLAN te laten gebruiken.

Onthou wel dat VLANs niet bedoeld zijn voor security maar om je netwerk performance te verbeteren.

@CPT(M)

In de switches is standaard de mogelijkheid voor IDP aanwezig, je zult echter wel een device moeten plaatsen b.v. een Juniper IDP appliance (sorry voor de reclame maar die verkopen wij :-) ) om de IDP op de switches aan te sturen en je policies in te definieren.

Binnen Enterprise organisaties begint IDP wel gemeengoed te worden maar voor het MKB is het nog ver van mijn bed.

Het gebruik van Port security zoals Anoniem 12:00 uur voor steld is een mogelijkheid maar je moet zelf wel over enige technische kennis beschikken en als je een IT-dienstverlener je IT laat onderhouden is het kostentechnisch niet aan te raden omdat inderdaad ieder nieuw apparaat en/of wijziging in de switch geconfigureerd moet worden.

Volgens [url=http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml]deze Cisco white paper[/url] (de [url=http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/vlnwp_wp.pdf]PDF versie daarvan[/url] en de [url=http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/tech/stake_wp.pdf]PDF[/url] met onderzoek van @Stake waarop het Cisco white paper is gebaseerd) is "Secure use of VLANs" wel mogelijk. Waarom zijn volgens jou VLANs by default niet secure, en wat zou je er eventueel aan kunnen doen om ze wel secure te krijgen? Als dat niet kan, wat zijn daarbij dan de problemen volgens jou?

Door middel van VLAN's wordt het mogelijk om je netwerk in afgescheiden 'segmenten' op te delen, zonder dat je allemaal extra apparatuur nodig hebt. Je kunt dan met ACL's op je VLAN's ervoor zorgen dat verkeer van het ene VLAN naar het andere wat beperkt wordt.
Hoe strak je die ACL's wilt hebben kun je dan zelf nog gaan bepalen. Je kunt heel strickt zijn en ze alleen implementeren als "van ip naar ip op die poort en meer niet" tot aan: "dat vlan naar dat vlan staat helemaal open".
Je kunt dus best wel met VLAN's een stuk van je security inbouwen.
Hierbij moet je security wel zien als een gelaagd iets. Je bent er niet met alleen maar vlan's en acl's. Je zult nog meer moeten gaan implementeren.

Wat veel mensen in het begin niet door hebben is dat de CS-MARS een rapportage tool/apparaat is en dus geen actief security apparaat zoals een IDP/IPS/Firewall e.d. Daarnaast is het ook geen HP OpenView (status management) of CiscoWorks (inventory management).

Security is inderdaad gelaagd. De switch is maar een relatief klein onderdeel van het hele concept. Security loopt door alle lagen van het OSI model, waarbij ook laag 8 (de persoon) niet vergeten moet worden.
De veiligste switches en firewalls hebben geen enkele zin als men er niet mee kan/wil werken.

De normale (enterprise) access switches van de gerenormeerde merken ondersteunen diverse features om de beveiliging op te schroeven, maar uiteindelijk valt of staat je hele netwerk bij je beleid...

Als ik me niet vergis is het de bedoeling dat VLAN's impliciet gescheiden zijn, en moet je routeren om VLAN's te koppelen (toegegeven er zijn switches die ingebouwde routingfunctionaliteit hebben, maar het is routeren, niet switchen). Als het zonder routeringsmogelijkheden toch lukt om pakketjes van het ene naar het andere VLAN te tunnelen is er sprake van het onbedoelde VLAN hopping.
Ik zie Eric Vyncke in zijn boek [url=http://www.comcol.nl/detail/62979.htm]LAN Switch Security[/url] in het hoofdstuk "Are VLANS Safe?" helemaal niks zeggen over ACL's. VLAN's hebben trouwens niet noodzakelijkerwijs iets met IP te maken (verschillende layers, je kunt er net zo goed NetBEUI i.p.v. IP over praten).

Wel schrijft Vyncke dat je moet zorgen dat je native VLAN aan geen enkele access poort moet worden toegekend, en bij Cisco switches dat je bij voorkeur moet afdwingen dat al het verkeer op ene trunk getagged moet zijn (om -unidirectionele- VLAN-hopping via double encapsulated 802.1Q packets frames te voorkomen, zoals je o.a. met [url=http://www.yersinia.net/attacks.htm]Yersinia[/url] kunt genereren). En dat je goed moet uitkijken dat Cisco's DTP (Dynamic Trunking Protocol) en VTP (VLAN Trunking Protocol) niet via de doojes in de muur aan te sturen zijn...

Iemand aanvullingen hierop? SirDice?

ik wil iedereen nogmaals bedanken voor de discussie die hier is ontstaan, mvgr.

Valt me mee dat er nog niemand is begonnen over 802.1x authenticatie. Lijkt me toch wel het primaire voorbeeld als het op switch security aankomt. Waar ik verder zelf op let is dat het sowieso een CLI manageable switch is in plaats van alleen maar web management. Blijf de console toch vele malen beter vinden om mee te werken. Security is overigens niet iets wat je op één plek in je netwerk afvangt. IDP is een mooi concept maar niet voldoende, hetzelfde geldt voor VLAN's. Het is het totaal concept wat ervoor moet zorgen dat je netwerk veilig is voor zowel je resources als de andere gebruikers.

Helemaal mee eens, voordat je ook maar aan de techniek van Security gaat denken is het noodzakelijk een goed beleid op te stellen en dat beleid ook als vast agenda punt van de management meeting op te voeren want ook dit beleid moet voortdurend getoetst worden en waar nodig aangepast.

Nope, weinig meer aan toe te voegen :)

802.1X is leuk, maar niet zaligmakend.

Als iemand een hubje (of slimmer, een bridging systeem) kan tussenvoegen waarna een, meestal dichtgetimmerd, systeem na authenticatie via 802.1X de ethernetpoort laat openzetten, is er weer vanalles mogelijk...

Hubs zijn eenvoudig te voorkomen... Zet je switch poorten hard op full duplex. Zodra iemand een hub aansluit krijg je een erg leuk effect ;)

Niks is zaligmakend, toch is 802.1x een goed onderdeel van de netwerk beveiliging. Zoals ik al eerder zei is ook niet alleen IDP de oplossing, of alleen VLAN's bouwen de oplossing. Complete netwerk security is op alle lagen de nodige beveiliging inbouwen die elkaar aanvullen. 802.1x & IDP & endpoint security & firewalls & DLP & gewaarwording gebruikers zijn de verschillende onderdelen waar ik op zou inzetten.

Ervaringen met 3com Baseline Switch 2916-SFP Plus!

Een vlan is een zeer beperke veiligheids maatregel. Als je ook maar iets verkeerd doet breek je zo door de beveiliging heen (er IS geen beveiliging als je de tags door stuurt). VLANs staan bekend als 'poor man's switch', en is feitelijk een goedkope manier van meerdere switches stapelen.

Neemt niet weg dat ze vaak worden ingezet, ook door mij. Ik gebruik Dell 2716 web beheerde switches. Goedkoop, snel en goed. 16 poorten gigabit snelheid.

IDS en erger IDP is mosterd na de maaltijd. Zorg eerst voor een goede opzet. IDP laat zichzelf veel te makkelijk voor de gek houden, waardoor je snel geneigd bent het maar uit te zetten.

Ik ken overigens geen enkele goede implementatie van IPS en maar heel weinig echt goed actieve IDS omgevingen. Wel is overal de wens aanwezig om het aan te zetten, maar de praktijk is (te) weerbarstig.

EJ

VLAN = IP Subnet = Broadcast Domain.
Vandaar dat je een router nodig hebt on tussen de VLANs traffic mogelijk te maken. Je kunt ook een L3 switch gebruiken maar dat is een switch met een ASIC router.
Cisco kent VACLs (VLAN ACLs), dus ja, je kunt ACLs voor VLANs gebruiken.
Een nieuwe CIsco switch , zo uit de doos, heeft de poorten op auto dynamic desirable staan. Mooi om gelijk aan de slag te gaan, maar slecht voor security. De poort wil namelijk dynamisch een trunk port aangaan.
Stel je toch eens voor dat de attacker op je trunked port zit en alle VLAN traffic can sniffen... bad!
(Mijn advies is om alles wat auto is met cisco niet te gebruiken en zelfs uit te schakelen.)
Laat het beheer van je switch over aan trusted admin.
Schakel alle niet gebruikte poorten uit.
Schakel alle niet gebruikte servics uit.
Als je al SNMP wilt gebruiken, gebruik dan versie 3.
Schakel DHCP snooping en DAI (Dynamic ARP) in om een MIM attack te verhinderen.
Beperk het aantal MAC adressen dat aan je poorten kunnen bevestigen.
Stuur geen user data over de native VLAN met een 802.1q trunk.
Gebruik Root Guard en BPDU guard om je STP te beschermen.
:-)

Er kunnen, als je wilt, natuurlijk meerdere IP subnetten op hetzelfde netwerk actief zijn.

Ik heb het nooit geprobeerd, maar ik vermoed dat 2 access poorten van verschillende VLAN's en een kabeltje (crossed voor het mooie) volstaan (mits het aantal MAC-adressen niet beperkt is middels port security)... Heeft iemand dat weleens getest?

Verder een uitstekend verhaal van HyperVisor!

Bedankt voor het compliment Bitwiper.
Verschillende VLAN's is gelijk aan verschillende subnetten.
Je kunt ze wel koppelen maar je zult computers op verschillende ip subnets nooit kunnen laten pingen.
Voor traffic van een VLAN naar een andere VLAN heb je echt een router nodig.
Een klassieker is de zg. Router-on-a-Stick.
Een poort van de switch is via een 802.1q trunk (tagged) gekoppeld aan de router (moet wel een fastethernetkoppeling zijn 100 Mbps).
Aan de router zijde maak je zg virtuele interfaces aan. Een voor elke VLAN.
Iedere virtruele I/F zit in hetzelfde IP subnet als de bijbehorende VLAN. Als nu een PC in VLAN met een andere PC in andere VLAN wil laten communiceren dat moet de Default Gateway ingesteld zijn met het IP adres van de virtuele I/F op de router. Route: PC VLAN x, switch, Trunk naar router, Router, terug door de trunk naar de switch en vervolgens naar de poorten met de bestemmings VLAN y.
Probeer dit eens:
twee PCs via een switch koppelen. Beide PCs in een verschillend subnet. (bijv 192.168.1.10/24 en 192.168.2.10/24)
Probeer maar te pingen...... lukt niet; kan alleen met een router.

Zelf ben ik op de hoogte van wat je hierboven vertelt, maar vroeg me af of er binnen switches nog mechanismes bestaat die een fysieke koppeling tussen 2 VLAN's detecteren (ik neem aan dat STP dit niet doet, er is met 1 interconnectie immers nog geen sprake van een loop).

Dat devices met verschillende subnetten elkaar niet kunnen zien klopt, maar bij aaneengesloten ranges zou je de subnetten natuurlijk kunnen oprekken, en niets belet je om meerdere IP-adressen (en dus subnets) aan een ethernetkaart te knopen (zie bijv. [url=http://www.windowsreference.com/windows-2000/how-to-addassign-multiple-ip-address-in-vistaxp20002003/]deze page[/url]). Ik heb wel eens een gecompromitteerde PC gezien (viel gelukkig niet onder mijn beheer) die zichzelf meer dan 100 IP-adressen had toegeigend. Het doel daarvan was me overigens niet helemaal duidelijk.

Ik ben altijd in dit soort zaken geïnteresseerd vanuit security oogpunt; wat als een kwaadwillende medewerker stiekem 2 VLAN's aan elkaar weet te knopen met een kabeltje? Ik ga ervan uit dat, als je geen port security toepast en passief snifft, je van beide VLAN's in elk geval broadcast en multicast voorbij ziet komen, en hier en daar een gelekt unicast pakketje. Actief (dsniff, ettercap etc.) is er dan natuurlijk veel meer mogelijk van het ene naar het andere VLAN...

Bzzt wrong. Je mag in verschillende vlans best dezelfde ip reeksen gebruiken, zelfs dezelfde ip adressen. Ze zien elkaar toch niet. Dat is een subtiel onderscheid met alleen ip subnetten. Een vlan is echt een poor man's switch.

EJ

Nou EJ, het klopt als je zegt dat PCs in verschillende VLAN elkaar niet zien. En ja, dan kun je in theorie dezelfde IP adressen gebruiken in verschillende VLANs.
Ben ik wel heel benieuwd hoe je dat denkt te gaan routeren.
Hoe routeer je van 172.16.1.10 in VLAN 1 naar 172.16.1.10 in VLAN 2? :-)

Maar om nou te zeggen dat VLAN = IP subnet = BC domain fout is gaat mij te ver.

Ik snap je opmerking niet dat een VLAN een poor man's switch is.

VLANs hebben te maken met het opsplitsen van broadcast domains en de logische groepering van gebruikers.
Kijk hier eens naar:
http://www.cisco.com/en/US/docs/internetworking/design/guide/nd2012.html#wp3702

Nee, de primaire functie van een vlan is het vervangen van een switch door een virtuele switch. Dat dat handig is bij het inperken van broadcast domains is meegenomen.

Waarom wil je routeren tussen 2 netwerken met dezelfde ip reeks? :-) (en o, er zijn inderdaad wel mogelijkheden om dat te bereiken, maar dan ga je hele vieze spelletjes spelen).

Jij geeft aan dat VLAN = IP subnet = BC domain een gegeven is, ik zeg dat DAT niet de PRIMAIRE functie is van een vlan. Het is meegenomen dat dat gebeurt, mits je geen layer 3 switches gebruikt die een en ander weer doorknopen.

Een vlan is ten principale NIET ONTWORPEN om broadcast domains te scheiden. DAT is wat ik bedoel. Het is handig dat het kan, maar niet meer dan dat.

Een vlan spaart je fysieke switches en bekabeling uit. Dat bedoel ik met een poor man's switch. O, en in security kritische omgevingen is het gebruik van vlan's in het algemeen NIET toegestaan. Om redelijk voor de hand liggende redenen. Omdat het een poor man's switch is. ;-)

EJ

EJ,

"Nee, de primaire functie van een vlan is het vervangen van een switch door een virtuele switch."

Dit is apert fout.
Een vlan is geen virtuele switch en ook geen poor man's switch.
Het is een virtuele LAN.

Een vlan bestaat alleen in een switch omdat in de switch een vlan database is aangemaakt. Geen switch, geen vlans.
PCs in een vlan weten niet eens dat ze in de vlan ingedeeld zijn. Ze kennen alleen hun IP adres, subnet mask, default gateway en het IP adres van de DNS.

Kuch. Volg zelf eens een cursus CISSP. Als je daarmee klaar bent praten we verder ok?

EJ

??

Precies. Dat bedoel ik. Als je nog niet verder bent gekomen dan een cursusje CCNA dan heb je nog niet echt recht van spreken.

Reactie van NielsT is al een stuk genuanceerder dan jouw ongenuanceerde en oppervlakkige verhaal. Je luistert teveel naar de cisco marketing verhaaltjes en doorziet blijkbaar nog niet de techniek daarachter.

EJ

Heren, volgens mij is niemand gebaat bij verwijten dat je eerst maar een cursus x of y moet volgen. Zullen we de discussie verder op basis van argumenten voeren?

Voor zover ik kan vinden wordt de term "virtuele switch" in twee verschillende "omgevingen" gebruikt: [url=http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf]VMWare ESX Server virtual networking [PDF][/url] en [url=http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/prod_qas0900aecd806ed74b.html]Cisco's Virtual Switching System (VSS)[/url]. Het switchen tussen VLAN's op basis van de tags in 802.1Q frames is net zo min virtueel als het switchen op basis van het destination MAC adres.

Dat VLAN's alles met security te maken hebben is ook niet waar. In de [url=]IEEE Std 802.1Q"-2005 standaard [PDF][/url] komt het woord "security" maar een keer of 6 voor, en geheel niet in § 1.2, VLAN aims and benefits. Daarin staat in grote lijnen:
a) Vereenvoudiging van administratie
b) Begrenzing/beperking van verkeer tussen VLANs
c) Zo groot mogelijke compatibiliteit met bestaande switches en eindstations
d) Een switch waarvan alle poorten zo zijn geconfigureerd dat ze uitsluitend untagged packets verzenden en ontvangen zal 100% uitwisselbaar zijn met een non-VLAN-switch.
(I.p.v. het woord "switch" wordt in het document op de meeste plaatsen "bridge" gebruikt).

Bijv. de oude Cisco Catalyst 1900 en 2820 Enterprise Edition ondersteunden formeel wel VLAN's maar, als ik het goed begrijp, werd uitsluitend broadcast verkeer gescheiden tussen VLAN's. Als je het MAC-adres van een host in een andere VLAN kende, kon je er gewoon mee communiceren (zie [url=http://www.cisco.com/en/US/docs/switches/lan/catalyst2900xl_3500xl/catalyst1900_2820/version8.00.03/scg/AleakyV.html]deze[/url] Cisco page).

Een aardig overzicht van VLAN attacks en tegenmaatregelen vind je in [url=http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-figueroa-williams.pdf]deze presentatie [PDF][/url] (Defcon 16, aug. 2008).

Helemaal met je verhaal eens Bitwiper,
Nexus 1000v is een virtuele switch die door Cisco in samenwerking met VMware is ontwikkeld.
En die 1900 switch: die is al al lang EOL.
Slide 40 van de Defcon presentatie is een aardige opsomming van wat ik al eerder in deze thread beweerd heb.(Met de toevoeging van OOB management)

Bitwiper: dit sluit 100% aan bij wat ik beweerde.

Overigens is het gebruik van virtual switches inmiddels zo oud als de weg naar Rome, en juist de kern tot de mogelijke kwetsbaarheden van vlan's. Als ik het me goed herinner zat de dot1q code al in OpenBSD 2.6, nu 10 jaar geleden. Daarmee was eenvoudig aan te tonen dat als je toegang had tot tagged verkeer, het hele tagged verkeer te compromitteren was. Linux heeft deze bridging mogelijkheden ook al heel lang, ver voordat vmware bestond.

Let wel dat dot1q verkeer geen enkele vorm van authenticatie kent, en iedereen dus enthousiast pakketjes mag injecteren. Dan ligt het aan de configuratie van de switch of dat dit tot problemen kan leiden.

Vlan's hebben, in tegenstelling tot wat hypervisor zo duidelijk beweerde, en waar hij blijkbaar in bovenstaande post ineens op terug komt, inderdaad niets met beveiliging te maken. Hetgeen mijn stelling onderschrijft.

Die oude cisco catalysts waar bitwiper aan refereert zijn al een tijdje EOL. ;-) Ik kom ze in de praktijk ook niet meer tegen.

EJ

Gents, ik weet dat de 1900 EOL is, maar ik noemde hem om aan te geven dat middels het ondersteunde type VLANs welliswaar broadcast domains konden worden gescheiden maar het qua security niets voorstelde. Het is maar net wat het doel is wat je wil bereiken...

Het is helder dat als je VLANs voor security wilt gebruiken je er dan voor moet zorgen dat access ports alle tagged pakketjes droppen.

Wat is jullie mening als ik stel dat het wel mogelijk is om VLANs voor security doeleinden in te zetten, maar dat het grootste risico zit in configuratiefouten o.a. doordat de gemiddelde netwerkbeheerder onvoldoende op de hoogte is van alle aanvalsscenario's?

Bitwiper,

Het grootste risico zit inderdaad in configuratiefouten. Denk ook aan vlan1 doorgeven op verkeerde poorten, of management plegen via vlan1 in plaats van een dedicated vlan niet zijnde vlan 1. Je ontkomt er IRL niet aan om vlan's in te zetten voor security doeleinden cq het wordt zeer vaak ingezet voor dit doel.

Sowieso heeft de gemiddelde netwerkbeheerder te weinig begrip voor aanvals-scenario's. Te vaak worden beheerders door domme management beslissingen gedwongen om verkeerde beslissingen te nemen. Inclusief te weinig training. En een mentaliteit van 'dat overkomt ons toch niet', 'we hoeven niet te checken, alles is goed geregeld bij ons' of de ergste: 'logfiles, waar heb je die voor nodig'.

Combineer dat met blind vertrouwen op niet security gerichte producten zoals cisco works, of op (verkeerd) geconfigureerde security tooling en de basis voor ellende is gelegd.

EJ

Dat is de meest rare oplossing die ik ooit heb gehoord. Je wilt geen gezeik op je netwerk, je wilt regels stellen en deze laten hanteren door je apparatuur.

Je hele verhaal klopt niet. Behalve het feit dat Router-on-a-stick een klassieker is ;-). VLAN's routeren, dus zijn in principe zijn het ook routers. En ook kun je computers op verschillende subnetten pingen, zolang de route er maar naar bekend is. En dan nog de opbouw van je verhaal. Er zit totaal geen logica in.

"Voor traffic van een VLAN naar een andere VLAN heb je echt een router nodig."

Bij legitiem verkeer klopt dat zonder meer. Echter kan je via aanvallen op een slecht beveiligde switch wel verkeer mogelijk maken met andere vlans. Voor een uitgebreid overzicht, zie het eerder genoemde boek 'LAN Switch Security: What Hackers Know About Your Switches' van Eric Vyncke, of bekijk onderstaande presentatie eens :

Hacking Layer 2: Fun with Ethernet Switches
http://www.blackhat.com/presentations/bh-usa-02/bh-us-02-convery-switches.pdf

"VLAN's routeren, dus zijn in principe zijn het ook routers. "

Nee, VLANs routeren helemaal niet. VLANs scheiden enkel broadcast domains van elkaar. Routeren gebeurd op layer 3 in het netwerk (ip adressen), en switchen gebeurt op layer 2 (mac adressen). De enige 'switch' die kan routeren is de multi-layer switch, wat in feite een combinatie is van een switch en een router.

"En ook kun je computers op verschillende subnetten pingen, zolang de route er maar naar bekend is. En dan nog de opbouw van je verhaal. Er zit totaal geen logica in."

Zolang er niet gerouteerd wordt, kan je een ander subnet niet bereiken. Je zal dus toch echt een router nodig hebben. Verder klopt de uitleg van HyperVisor, dus wat dat betreft zie ik de logica van zijn betoog geheel in.

"Dat is de meest rare oplossing die ik ooit heb gehoord. Je wilt geen gezeik op je netwerk, je wilt regels stellen en deze laten hanteren door je apparatuur."

Op zich is die gedachte niet zo raar. Dat doet een firewall immers ook. Of een switchport waarop je port security hebt aangezet. Al zou ik niet gaan beveiligen via speed/duplex settings ;)

@ cpt(m) :

Je kunt trouwens de configuratie van switches, routers of firewalls nakijken op beveiligingsproblemen met software zoals Nipper. Deze verwerkt je configuratiebestand, en geeft advies indien er zwakheden worden gevonden (gebruik is voor privedoeleinden gratis) :

Nipper: Network Infrastructure Parser
http://www.titania.co.uk/index.php?option=com_content&view=article&id=48&Itemid=59

Het gaat hierbij dan wel om apparaten van bijvoorbeeld Cisco, en niet om consumentenmodellen (i.e. D-Link, Linksys e.d.).