[ovirt-users] Associate IP addresses to MAC addresses (anti-spoofing rules)

[Edward Haas]

On Thu, Sep 15, 2016 at 8:49 PM, Marcin Mirecki <mmirecki at redhat.com> wrote:

> Andre,
>
> The clean-traffic is meant to prevent mac/IP/ARP spoofing.
> I am afraid this is the best we can offer out of the box at the moment.
>
> If you are willing to give some additional effort you can try and look at
> the OVS based
> networking (added recently). You could use the vdsm hooks to create some
> additional
> openflow rules on the ovs-switch that would put some constraints on where
> the traffic is going.
>
> One more item which is still in a very early development stage is an
> OVN-provider (http://openvswitch.org/support/dist-docs/ovn-
> architecture.7.html).
> OVN itself is also still not a ripe project, but is actively being
> developed.
> If you are interested I could update you once we have something working.
>
> Thanks,
> Marcin
>
>
> ----- Original Message -----
> > From: "André Gustavo" <andre at andregustavo.org>
> > To: "Marcin Mirecki" <mmirecki at redhat.com>
> > Cc: Users at ovirt.org
> > Sent: Tuesday, September 13, 2016 11:53:30 PM
> > Subject: Re: [ovirt-users] Associate IP addresses to MAC addresses
> (anti-spoofing rules)
> >
> > I forgot to comment
> >
> > It is a public network (Public IP)
> >
> > I have 2 servers and 1 router
> > I hired a "IP block" that can be accessed through the router
> >
> > For example:
> >
> > Network: 165.112.12.112/28
> > IPs: 165.112.12.113 - 167.114.12.125
> > Gateway: 165.112.12.126 (router)
> >
> > I provide to my client a public IP directly in VM
> >
> > I want to prevent a customer responds by another customer
> > or take another ip available for himself
> >
> > ----
> >
> > Since that my client has access to the "User Portal"
> > The "clean-traffic" filter will prevent it change the ip when it shut
> down
> > and restart the VM?
>
This is a security mechanism provided by libvirt to restrict the VM from
communicating
with more than one mac, one IP (and some more restrictions).
If I'm not mistaken, the heuristic (when not set manually in the domxml),
is to lock on the first
source address it detects.

>
> > Thanks,
> > André
> >
> > 2016-09-13 5:57 GMT-03:00 Marcin Mirecki <mmirecki at redhat.com>:
> >
> > > Hi André,
> > >
> > > The best separation would be providing a separate network for each
> > > customer.
> > > This way you could protect them from other malicious users on your
> > > internal networks.
> > > Please describe your env in some more detail.
> > >
> > > Thanks,
> > > Marcin
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "André Gustavo" <andre at andregustavo.org>
> > > > To: Users at ovirt.org
> > > > Sent: Monday, September 12, 2016 8:33:40 PM
> > > > Subject: [ovirt-users] Associate IP addresses to MAC addresses
> > > (anti-spoofing rules)
> > > >
> > > > Aloha,
> > > >
> > > > I'm using oVirt 4 in my hosting.
> > > >
> > > > However, easily a customer can change the IP to another client (IP
> > > spoofing)
> > > >
> > > > In vNIC profiles, altered Network Filter
> > > > from "VDSM-on-mac-spoofing" to "no-ip-spoofing"
> > > >
> > > > It worked partially, but if the client power off 'vm' and turn on the
> > > 'vm',
> > > > he can perform the change in IP
> > > >
> > > > I tried to use eptables, but also had problems
> > > > http://ebtables.netfilter.org/examples/basic.html#ex_anti-spoof
> > > >
> > > >
> > > > What is the best option?
> > > >
> > > >
> > > > --
> > > > ---
> > > > André Gustavo Timermann
> > > > Curitiba/PR - Brasil
> > > >
> > > > _______________________________________________
> > > > Users mailing list
> > > > Users at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/users
> > > >
> > >
> >
> >
> >
> > --
> > ---
> > André Gustavo Timermann
> >
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160916/04a96a80/attachment-0001.html>