The traffic is sniffer traffic. It wouldn't be a network for guests, or public, it would be both.
On Fri, May 23, 2014 at 2:45 PM, Daan Hoogland <daan.hoogl...@gmail.com>wrote: > H Marcus, > > You are raising more questions here > The traffic is just user data isn't it? Why a new traffic type? Or are > you forking the data and then considering the fork another type? > > thanks, > Daan > > > On Fri, May 23, 2014 at 5:53 PM, Marcus <shadow...@gmail.com> wrote: > > Perhaps it should be a separate traffic type, if we go the route of > piping > > it through to another network. I've also found a network_details table > that > > seems to be unused. > > > > > > On Thu, May 22, 2014 at 9:04 AM, Marcus <shadow...@gmail.com> wrote: > > > >> Yet another vector > >> > >> > >> On Thu, May 22, 2014 at 8:07 AM, Erik Weber <terbol...@gmail.com> > wrote: > >> > >>> What prevents root from revealing and using the domain admin api / > secret > >>> Key? > >>> > >>> Erik > >>> 22. mai 2014 15:54 skrev "Marcus" <shadow...@gmail.com> følgende: > >>> > >>> > I've always viewed the permissions to be additive, if a domain admin > has > >>> > the ability to set up network sniffing on the VPC I'd imagine the > root > >>> > admin should be able to as well. Although perhaps not. Even though > they > >>> > have unfettered access to destroy all vms, networks, zones, the root > >>> admin > >>> > may not have access to the VM hosts, and may not already have access > to > >>> the > >>> > VMs themselves if the root passwords are not known. This would > >>> introduce a > >>> > vector whereby a root admin without host access could spin up a > network > >>> and > >>> > vm for a tenant and see their traffic where they'd normally only be > >>> able to > >>> > if they had access to the root passwords of the tenant's instances or > >>> the > >>> > hosts. I imagine the overwhelming majority of root admins have host > or > >>> > network access, but not all. In the end I'm not sure such an > untrusted > >>> user > >>> > should be a root admin, as there are many other attack vectors (such > as > >>> > downloading a tenant's volume). Perhaps I'm missing the point. > >>> > > >>> > It would certainly be easier to implement from an orchestration > >>> perspective > >>> > on the router. The collection could happen on the router, but the > >>> storage > >>> > of the packet data probably not, and for the analysis it seems kind > of > >>> > dangerous to run more user-accessible tools on a system that is > >>> supposed to > >>> > be locked down. Especially since it would likely be a web service of > >>> some > >>> > sort running on the public interface. IDS software setup and > >>> maintenance is > >>> > pretty involved, I'm not sure the CS community would be interested in > >>> > maintaining that. We generally promote the virtual router as an > >>> appliance, > >>> > and so I think we'd need to maintain that software install on the > >>> router. > >>> > These (along with the migration issues) are the reasons why I was > >>> leaning > >>> > toward a 'sniffer net', where the users could have what they'd > normally > >>> > have in a datacenter with a 'port mirror', and they can decide how to > >>> > collect and analyze the data. > >>> > > >>> > > >>> > On Thu, May 22, 2014 at 2:34 AM, Daan Hoogland < > daan.hoogl...@gmail.com > >>> > >wrote: > >>> > > >>> > > Marcus, you mention a permission issue that triggers the though: > >>> > > should a root admin be allowed? I think not. This brings up extra > >>> > > requirements on the IAM, does it? > >>> > > > >>> > > I would implement the functionality on the router. > >>> > > > >>> > > On Thu, May 22, 2014 at 6:42 AM, Marcus <shadow...@gmail.com> > wrote: > >>> > > > I really like the lower overhead of just port mirroring from one > of > >>> the > >>> > > > router's interfaces to an instance interface host-side, but I > really > >>> > > > dislike the affinity it creates between the router and the > listener, > >>> > and > >>> > > > all of the complications it creates for host maintenance and > >>> > migrations. > >>> > > It > >>> > > > may also require that whomever creates a network or vms on a > network > >>> > with > >>> > > > this permission be a domain admin, since it has the ability to > see > >>> > > > everything on the wire for the whole VPC. > >>> > > > > >>> > > > > >>> > > > On Wed, May 21, 2014 at 4:25 PM, Marcus <shadow...@gmail.com> > >>> wrote: > >>> > > > > >>> > > >> Hi guys, > >>> > > >> Not sure if this has been discussed before, but we are > getting > >>> > > feature > >>> > > >> requests for an IDS or packet-sniffing/monitoring capability. I > >>> have a > >>> > > >> prototyped idea of how to do this (manual config), but would > like > >>> some > >>> > > >> input. > >>> > > >> > >>> > > >> We create a network offering or network capability/detail that > is > >>> > > >> specifically a 'sniffer net'. This would be relatively simple, > and > >>> > just > >>> > > do > >>> > > >> two things: > >>> > > >> > >>> > > >> 1) when network is added to VPC, spin up a simple daemon on the > VPC > >>> > > router > >>> > > >> that does traffic mirroring (netsniff-ng or daemonlogger are > debian > >>> > > >> packages) from the public interface to the 'sniffer net' > interface. > >>> > > >> > >>> > > >> 2) disables mac learning on the bridges created for the sniffer > >>> net, > >>> > so > >>> > > >> that an IDS system can come up in this net and see all of the > >>> mirrored > >>> > > >> traffic. It wouldn't handle making the IDS appliance, that would > >>> be up > >>> > > to > >>> > > >> the customer, it would simply create a network that enables > traffic > >>> > > >> monitoring for the VPC. > >>> > > >> > >>> > > >> I think we'd prefer any VMs brought up in this network to live > on > >>> the > >>> > > same > >>> > > >> host as the router for performance reasons, but that's probably > >>> not an > >>> > > >> immediate requirement. I dislike the idea of trying to run an > >>> actual > >>> > > >> capture saved to the VPC router, or an IDS software on the VPC > >>> router > >>> > > that > >>> > > >> would need to be updated. > >>> > > >> > >>> > > >> We could also run traffic mirroring from the VPC router's > interface > >>> > > >> directly to another VM's interface, host side (daemonlogger -i > >>> vpcintf > >>> > > -o > >>> > > >> idsintf), but it would need to be on the same host. > >>> > > >> > >>> > > >> > >>> > > >> > >>> > > >> > >>> > > > >>> > > > >>> > > > >>> > > -- > >>> > > Daan > >>> > > > >>> > > >>> > >> > >> > > > > -- > Daan >
