Alleen 'nieuw' verkeer dat de switch nog niet kent (in principe komt dit dus al niet binnen wanneer je een firewall gebruikt) word aan alle poorten aangeboden. Het is dus niet mogelijk om via het éne systeem het netwerkverkeer van het andere systeem te onderscheppen.

Ook niet als de 'afgaande' poort wordt afgekoppeld? Een tijdje terug knalde de buitenlijn eruit op mijn werk, waarna ik via WireShark alle requests van het hele bedrijf voorbij zag komen. Enig idee hoe dit zou kunnen, mocht dit niet aan de switch (kunnen) liggen?

Arp poisoning ...

Zolang de switch weet welk mac adres achter welke poort zit wordt verkeer van het ene mac adres naar het andere 'direct' naar de juiste poort gestuurd.
Maar als de switch nog niet weet achter welke poort de destination zit, wordt het ethernet frame op alle switchpoorten [in het zelfde vlan] geflood. Normaal gesproken zal dat ophouden bij het eerste antwoord van de destination, want daarmee ziet de switch de poort waar in het vervolg dat verkeer naar toe moet.
Als de destination opeens ophoudt te werken, zal na kortere of langere tijd de switch de geleerde poort/mac combinatie vergeten, waarna alle verkeer voor die destination mac geflood zal worden op alle poorten.
Dat is wat gebeurd moet zijn op je werk.

Als een poort up/down gaat wordt de mapping van mac adressen naar die poort ook gewist; Verder zit er een timer op.
De mapping IP-mac is bij de clients nog wel bekend (dat is de arp table), en de timeout daarvan is meestal veel langer dan de mac/poort mapping timeout in een switch.
Als het bij je werk nog langer zou duren ga je alleen maar arp requests zien.

Verder zijn er nog wel actieve manier om dit soort dingen te forceren (arp poisoning, cam table flooding).

Een voldoende luxe/dure switch heeft weer opties om dit soort dingen te blokkeren, maar dat geeft meer overhead voor het beheer van het netwerk.

je zegt dat de switch een mogelijk security risico is.. dat is niet het geval.. de omgeving is het risico... een switch geeft en is geen substantiële security risico ( hij kan wat dingen voorkomen maar dat is heel beperkt en wat hij kan voorkomen is makkelijk te omzeilen)

Security begint bij de workstations. ( werken met profielen, zorgen dat er virusscanners zijn enz enz)
Je netwerk moet je netjes op orde houden door een goede firewall config en zorgen dat de spullen altijd op het laatste code level draaien.Indien mogelijk werken met gescheiden logische netwerken enz enz Als je je netwerk configureert heeft de leverancier altijd wel wat advies configs ( Cisco bijvoorbeeld)

Kortom een switch is maar een schakel in je IT infrastructuur en zal nooit de core oorzaak zijn van een security breach.

@Callie: workstation beveiliging is heel belangrijk, maar je moet in je achterhoofd houden dat er gegarandeerd vandaag of morgen eentje omvalt, of iemand een gecompromitteerde notebook aansluit. Als van daaruit je netwerk onderuit gehaald kan worden heb je ineens een veel groter probleem. Dan is die netwerkapparatuur misschien niet de oorzaak van de breach, maar een aanvaller die een switch (vooral die met geconfigureerde VLAN's) weet over te nemen is niet iets waar netwerkbeheerders blij van worden.

Ook als er geen gecompromitteerde hosts aan je netwerk hangen ben je niet per definitie safe. Hoewel ik geen aanvallen ken, kunnen switches wel degelijk de oorzaak zijn van security breaches. Steeds meer SOHO switches zijn voorzien van webinterfaces en die zijn lang niet altijd even goed beveiligd, en kunnen in principe worden benaderd door met een webbrowser naar een foute website te gaan. Ook komen vulnerabilities voor in de besturingssystemen van zwaardere switches (waaronder Cisco IOS). Samy Kamkar liet begin dit jaar met "NAT pinning" zien dat hij sommige NAT routers (en firewalls, beide met IRC DCC connection tracking) zo gek kan krijgen dat deze TCP poorten van Internet naar LAN open zetten (zie http://samy.pl/natpin/). Eerder wist Petko D. Petkov met html en Flash middels UPnP veel thuisrouter configuraties aan te passen (zie http://www.gnucitizen.org/blog/hacking-the-interwebs/). Wie weet kun je met vergelijkbare technieken ook switches kunstjes laten uitvoeren...

@TS: als je een besmette PC in een switched netwerk hebt zijn er allerlei (layer-2) aanvallen mogelijk waarbij het laten "flooden" van switches er slechts 1 is (en da's voor script-kiddies, want dit valt vaak op doordat het netwerk traag wordt). Als je geen bijzondere beveiligingsmaatregelen in je switches genomen hebt zijn layer-2 MITM attacks vaak mogelijk, die zijn veel enger en maken minder "lawaai". Tegenmaatregelen vind je o.a. hier http://isc.sans.edu/diary.html?storyid=7567 (of google naar: mitm gratuitous arp).

Als je mijn response goed had gelezen dan zie je dat ik de netwerkbeheerder zeker niet ontsla van zijn plichten voor security. Echter al jouw voorbeelden gaan ervanuit dat er bij je bedrijf INTERN al wat mis is. Tegen dit soort terreur is niets opgewassen ook geen goede security op een switch.

jouw voorbeeld:
"er gegarandeerd vandaag of morgen eentje omvalt, of iemand een gecompromitteerde notebook aansluit"
---> aanval komt vanuit intern en daar helpt geen enkele switch config tegen. Enige wat hij kan doen is de aanval moeilijker maken danwel vertragen.

tweede voorbeeld:
"Steeds meer SOHO switches zijn voorzien van webinterfaces en die zijn lang niet altijd even goed beveiligd, en kunnen in principe worden benaderd door met een webbrowser naar een foute website te gaan."

A: de foute website..---> goed proxy beheer kan dit voorkomen.
B: een advies voor het configen van met name Cisco switches is om de web interface dan wel uit te schakelen of er minimaal een access-list op te zetten. ( jammer genoeg worden steeds minder mensen gehinderd door enige vorm van kennis waardoor men de switch met de web interface configed..

Kortom ik begrijp wat je zegt maar ik ken geen enkel voorbeeld waarbij de switch de core breach is. Het heeft altijd te maken met de omgevingsfactoren. En ja en er zullen altijd nieuwe dingen komen waardoor je IT Infrastructure onder vuur kan komen te liggen. En zowel de systeembeheerder als de netwerkbeheerder moeten zeer zorgvuldig met hun security-beleid omgaan.