How to check which vm generated the bad BPDU

[RanjnaAggarwal]

how to check which vm generated the bad bdpu? is that possible to find out? if yes the how?

[RanjnaAggarwal]

sorry for mistake it's not bdpu...it's bpdu

[UmeshAhuja]

Hi,

You need to implement BPDU guard on the virtual switch.

Go with the below link for more details

http://blog.ipexpert.com/2010/12/06/bpdu-filter-and-bpdu-guard/

[RanjnaAggarwal]

The purpose of globally configured BPDU Guard is to disable (err-disable) all portfast-enabled ports should they ever receive BPDU frames and global BPDU Filter is configured as part of global “portfast” configuration. The purpose of BPDU Filter is to prevent the switch from sending BPDU frames on ports that are enabled with portfast but i want to track which vm sent the bad bpdu.

[rickardnobel]

There is no Spanning Tree support on the ESXi virtual switches and by that no BPDUs being sent. There is also no possibility to enable any BPDU-guard or similar techniques.

When should an ordinary VM send a BPDU?

[RanjnaAggarwal]

Check this out:-

http://blog.ioshints.info/2011/11/virtual-switches-need-bpdu-guard.html

[Gkeerthy]

as mentioned by the rickardnobel

the vswitch wont generate these, and inside the vm delibarately with some application only you can generate this. As per the best practice you need to enable the portfast, STP and BPDU in the pswitch. Some times when your vm is compromise the hacker can send BPDU packets, thats why you need to enable the BPDU guard in the pswitch

[Gkeerthy]

more info on BPDU see below

https://supportforums.cisco.com/docs/DOC-11825

http://www.ciscozine.com/2009/03/17/how-to-protect-against-bpdu-attack/

http://etherealmind.com/basics-whats-the-difference-between-stp-bpdu-guard-and-root-guard/

[RanjnaAggarwal]

How to check from these particular VM's BPDU is generated?

[Josh26]

Ranjna Aggarwal wrote:

Check this out:-

http://blog.ioshints.info/2011/11/virtual-switches-need-bpdu-guard.html

I must admit I thought this thread was a bit misguided until I read this link.

If it can be put this way:

Imagine I'm a hosting company. A customer owns a VM. Or maybe, a single VM is hacked. Either way, someone has administrative access and can run an application that spoofs BPDUs.

At this point, BPDUGuard on the pswitch drops the HOST port. This is effectively a DoS attack on VMware - sounds like a security issue.

[Josh26]

Gopinath Keerthyrajan wrote:

Some times when your vm is compromise the hacker can send BPDU packets, thats why you need to enable the BPDU guard in the pswitch

This means the hacker has the ability to impact on other virtual machines on the host.

[rickardnobel]

Ranjna Aggarwal wrote:

Check this out:-

http://blog.ioshints.info/2011/11/virtual-switches-need-bpdu-guard.html

So your question is actually: if a hacker inside a VM sends a faked BPDU, can we later see which VM sent this frame?

[RanjnaAggarwal]

exactly that's my question

[rickardnobel]

For me the answer to this is no, there are no frame tracking functionality inside the vSwitches.

If that would happen, we would have no way to see which VM was the culprit unfortunately.

[ngarjuna]

on the upstream switches that the VEM is connected to it is highly recommneded to that Global BPDU Filtering and BPDU Guard be enabled.

For IOS
cat65k-1(config)# spanning-tree portfast bpdufilter
cat65k-1(config)# spanning-tree portfast bpduguard

For NXOS
n5k-1(config)# spanning-tree port type edge bpduguard default
n5k-1(config)# spanning-tree port type edge bpdufilter default

In environments where you can NOT use global modes set the following on the switchports the VEM are connected to

For IOS
cat65k-1(config-if)#spanning-tree bpdufilter
cat65k-1(config-if)#spannning-tree bpduguard

For NXOS
n5k-1(config-if)#spanning-tree bpdufilter
n5k-1(config-if)#spanning-tree bpduguard

[ngarjuna]

http://blog.ioshints.info/2010/11/vmware-virtual-switch-no-need-for-stp.html

[rickardnobel]

ngarjuna wrote:

http://blog.ioshints.info/2010/11/vmware-virtual-switch-no-need-for-stp.html

It is an interesting article, but I think it is good to point out what you want to refer to more specifically inside that post?

[Josh26]

ngarjuna wrote:

http://blog.ioshints.info/2010/11/vmware-virtual-switch-no-need-for-stp.html

That it's not needed to assure loop free topologies does not mean that the current, non existent implementation is secure.

[VirtuallyMikeB]

Good day!

Perhaps by using port mirroring with the vDS or Nexus 1000v, you can dig into a captured BPDU and look at the Port ID field.  I haven't done this, but the Port ID may give you the port number (virtual port number) on the vDS or Nexus 1000v which is in use by the offending VM.  Find the virtual port ID, then cross reference this with which port ID each VM is using.  Let us know what you find.  Here's a description of a BPDU packet:

http://www.iphelp.ru/faq/24/ch06lev1sec8.html

Of course, this also means you can't use a Virtual Standard Switch (vSS) because it doesn't have the port mirroring feature.  I imagine you also can't use a packet capture on the physical switching infrastructure because the port ID might very well come from the ESXi host, which you already know is only hosting the real culprit.

Depending on the number of VMs you have, it might be feasible to just go through each VM and investigate their networking and installed software, looking out for bridging software or configurations.

Cheers,

Mike

http://VirtuallyMikeBrown.com

https://twitter.com/#!/VirtuallyMikeB

http://LinkedIn.com/in/michaelbbrown

Note: Please let me also add to the record that IOShints.info is *awesome*

[rickardnobel]

In ESXi 5.1 there will finally be a solution for this, the new BPDU Block feature will prevent a denial-of-service attack from a VM running on ESXi 5.1.

Not totally obvious how to enable this however: http://rickardnobel.se/esxi-5-1-bdpu-guard

Even if it is not common for a VM to deliberate create faked BPDU frames it is still a dangerous situation where a single VM could shut down the whole host networking and bring all other VMs to a disconnected state.