cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: Network IDS in VPC
Date Fri, 23 May 2014 15:53:19 GMT
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 <shadowsor@gmail.com> wrote:

> Yet another vector
>
>
> On Thu, May 22, 2014 at 8:07 AM, Erik Weber <terbolous@gmail.com> wrote:
>
>> What prevents root from revealing and using the domain admin api / secret
>> Key?
>>
>> Erik
>> 22. mai 2014 15:54 skrev "Marcus" <shadowsor@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.hoogland@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 <shadowsor@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 <shadowsor@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
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message