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 >> > > >> > >> > >
