vShield network rules

[beovax]

Hi,

We have just started to have a play with vShield in our demo environment. We are planning on setting up a shared hosted solution fro some of our customers. We would like to make this as secure as possible. I have a couple of questions.

1. We will be seperating most customers on their own private VLAN. We would like to secure this a bit more and provide logging by restricting traffic from oneVLAN to the other. My thinking is to create a default rule on the VM WALL for each VLAN which only allows all traffic on the VLAN to talk to VM's on the same VLAN. The last rule would block all communications from that VLAN for all traffic to all other ogranisational zones.

Hopefully this will prevent traffic from one VLAN reaching any others and provide auditing. All VM's on that VLAN should be able to communicate with their default gateway and talk to the rest of the world?

2. Is it possible to use vShield to enforce configured IP addresses to a switch port or VM? in some situations it will not be possible to place customerson a dedicated VLAN (users with external facing IP's will have to be placed on the same VLAN). Or would we need to use the cisco virtual switch to do this, if it supports this?.

We are concerend that customers may have the ability to perfrom arp spoofing attacks, or accidently set the wrong external IP which will conflict with another customer.

Cheers

Michael

[howie]

1. VMs on different vlan can only talk via a gateway anyways, do you want to place some restriction there?

2. i will ask a vShield expert to answer your questin whether it is part of vShield.

-howie

[carlosVSZ]

#1 is completely possible to achieve using vShield zones. You can create rules to allow VMs within a VLAN to communicate with each other, while preventing them to talk to VMs in other VLANs yet still allow them access to the outside.

For #2, vShield zones does not provide this functionality (enforce an IP to a port or VM).

[mwronski · Accepted solution]

2. Is it possible to use
vShield to enforce configured IP addresses to a switch port or VM? in
some situations it will not be possible to place customerson a
dedicated VLAN (users with external facing IP's will have to be placed
on the same VLAN). Or would we need to use the cisco virtual switch to
do this, if it supports this?.

Michael,

For basic Zone level protection, vShield will probably do the job. For more granular policy and segmentation, Reflex Systems has a vmSafe based solution that can provide the level of protection you are looking for. In fact it can provide all the segmentation without using VLANS at all.. Because it is vmsafe (kernel level) you can define the zones/segments entirely as policy without having to mess with using VLANS. For more information and details feel free to PM me or read about it at .

-Mike

[beovax]

Thnak you for all the responses. I iwll be checking out relflex to see what they offer -Cheers

[vSerge]

Hi Michael,

I sent you a private note on the community site here; we're working on some features that deal with L2 attack containment like ARP/IP spoofiing, IP->VM enforcement, etc - would love to get some further requirements from you.

-Serge

[beovax]

Hi, The only reature we are really looking for at them moment is to assign IP addresses to ports - preventing users from changing their IP addresses, or if they do the port becomes disabled. Sorry not a networking guy, im sure there must be a name for this requirment.

We are setting up a hosted solution for a number of customers and we are concerned they will be able to change their external facing IP address (by mistake ) which will conflict with other users

[mwronski]

Michael,

The Reflex VMC product can definitely help here. Our pending release has a policy engine with multiple enforcement points. One of those points utilizes vmSafe (thus requiring vSphere) another allows enforcement by modification of the infrastructure configuration via APIs (supporting VI3 and vSphere 4.0 environments). With the product you can write a policy that reads like "If VM-X from Customer Y does not have IP A.B.C.D then perform <ACTION>". The action is a set of tasks that can include, network blocking, notification (email, SNMP Trap,etc), chaning the port group to quarantine network, power down VM, etc. The action options are limited only by your creativity and the VMW management API.

If you are interested, let me know and we can schedule a demo or eval in your environment. We are in active beta of this functionality now and well be releasing soon.

-Mike

mike at reflexsystems.com