We *have*, actually, experimented with running snort -inline as an L2 IDS, but the VMs turned out to be a lousy place for it. (Weird/bad things happen in linux bridging occasionally).
On Mon, Sep 20, 2010 at 8:15 PM, Dan Wendlandt <[email protected]> wrote: > > > On Wed, Sep 15, 2010 at 4:33 AM, Soren Hansen <[email protected]> wrote: > >> I have a spec[1] and a corresponding branch[2] about making basic use of >> libvirt's nwfilter support. It basically just adds a snippet to the >> libvirt templates that enables a number of network filtering techniques. >> Specifically, it prevents MAC spoofing, ARP spoofing, and IP spoofing. I >> didn't bother making this configurable, since it seems like the sort of >> thing everyone will always want. As such, there's no API call to enable >> it, nor is there a setting in the datamodel that enables/disables it. >> >> > Hi Soren, > > Thanks for sending this out. My vote would be to expose this as optional, > at least with respect to ARP and IP packets. Such filters definitely make > sense in a "flat" network model like Amazon, but there are interesting use > cases (in addition to what Josh mentioned) for clouds that choose to expose > a private network (e.g., VLAN) model: > > 1) Using a VM as an L3 Firewall/NAT. In this scenario, a firewall VM might > have VIFs on both a "public" and "private" network, with VM hosts only on > the "private" network. The firewall VM must be able to transmit packets > packets with many different source IP addresses (enforcing a particular MAC > and ARP limits, however, would still be fine). > > 2) A common mechanism for primary-secondary failover in some clouds is to > run two VMs that both provide a particular service and have a "fail-over" IP > that can float between the two. If the secondary fails to get heartbeat > responses from the primary, it will "steal" the fail-over IP address, for > example, using a gratuitous ARP with its MAC address for the fail-over IP. > This technique is definitely common in clouds with per-tenant private > network, but I believe it is also supported in some clouds with a flatter > networking model (in fact, I believe that Rackspace provides such a > capability: > http://cloudservers.rackspacecloud.com/index.php/IP_Failover_-_High_Availability_Explained). > In this case, limiting a VM to using a single IP for ARP and IP would be > prohibitive, though MAC filters would be fine. > > 3) The final scenario is a case where customers may want to control their > own IP addressing, and thus the cloud provider and hypervisor layer does not > know what IP addresses to enforce for IP / ARP traffic. This applies only > in the context of private per-tenant network, for example, if a customer > wishes to connect a network in the cloud to a network on their on premises, > or simply wants to use the same RFC 1918 space they used in the data center > before transitioning an app to the cloud. > > In sum, I think there are some compelling reasons to provide the option of > not enforcing a particular IP address in ARP / IP packets sent by a VM. Off > the top of my head I can't think of such well-known use cases for needing to > disable MAC address spoofing protections (anyone using a VM as an L2 bridge > for transparent IDS?) but I wouldn't be surprised if someone else did. > > Thanks, > > Dan > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira Networks, Inc. > www.nicira.com | www.openvswitch.org > cell: 650-906-2650 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > _______________________________________________ > Mailing list: https://launchpad.net/~nova > Post to : [email protected] > Unsubscribe : https://launchpad.net/~nova > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
