On Sunday 25 March 2007 09:27, Jason Dixon wrote: > On Mar 25, 2007, at 12:21 PM, J.C. Roberts wrote: > > On Sunday 25 March 2007 08:41, Jason Dixon wrote: > >> On Mar 25, 2007, at 11:24 AM, bofh wrote: > >>> On 3/25/07, Jason Dixon <[EMAIL PROTECTED]> wrote: > >>>> Disabling DTP, which should be done anyways, will prevent VLAN > >>>> hopping. I'm not sure what "arp-based thing" you're referring > >>>> to that wasn't fixed 5-6 years ago. Perhaps you're referring to > >>>> arp spoofing, which has nothing to do with VLANs. Please > >>>> clarify. > >>> > >>> My point was that there may be future vulnerabilities, and it may > >>> be a good idea to keep that in mind for the original poster's > >>> designs. > >> > >> There may also be future vulnerabilities in physical ethernet. > >> Guess you'd better unplug now! ;-) > > > > Future? -Nope. It's been already done. > > > > http://www.wired.com/news/technology/0,70619-0.html > > http://www.wired.com/news/technology/1,70908-0.html > > > > Though the example is not formally "ethernet," physical access to > > the "tubes" still means you should consider yourself 0wnd. > > > > But bofh is kinda right, arp-cache poisoning (possibly the "thing" > > he was talking about?) is really very interesting. > > The topic was in regards to VLAN security. Arp-cache poisoning, or > spoofing (as I already mentioned) has nothing to do with VLANs. > Unless either of you have anything relevant to add with regards to > the OP's question about single-homed routing, I suggest we move on. > > Thanks, >
Strange... ? -As far as I know, arp-cache poisioning and spoofing are still relevant even in VLANs (see below), and single homed routing might compound the known problems, so the OP should do a bit of reading before accepting VLANs as an answer. Title: "VLAN Security Guidelines" http://www.corecom.com/external/livesecurity/vlansec.htm [QUOTE] VLAN switch configurations and deployments have been vulnerable to a number of spoofing and man-in-the-middle attacks. The most well known exploits include the following. (Links at the end of this article lead to detailed descriptions.) * MAC address spoofing * VLAN tag spoofing (where the attack computer falsely identifies itself as a member of a VLAN by spoofing the IEEE 802.1q tag ) * ARP cache poisoning * Connection hijacking following a successful ARP attack (see HUNT) [/QUOTE] The sad part is even if all such issues have been addressed in OpenBSD, the attacker would go just after the switch which is probably not running the latest and greatest firmware (assuming the vendor has bothered to fix the issues and is still offering "support" for the device and the admin has bothered to install it). There are probably other ways to attack it... Can we use OpenBSD to get around the vulnerable switch problem? How? (Hark! -I think I hear the infamous "wooshing" sound of a quickly approaching clue stick) Since you know real world usage of VLANs far better than most (and certainly better than me), your insights on using OpenBSD to properly secure VLANs seem totally MetaBUGable! kind regards, jcr
