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
