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 >
