Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of shadowsor@gmail.com
 designates 209.85.128.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAP997UcAKzcxjmBmh3OxVaswUKSsntqYo0hOOwo9qUhLM5hQrg@mail.gmail.com>
References: 
 <CALFpzo5Y-E+F7+3aYf-opo999Yv8C0O6SKM_iaYPF0y0WZHu2w@mail.gmail.com>
	<CALFpzo6baxo=upCp+h8wrzqAXLCukD+Xa0bCr4=ez4Fy4OOtFg@mail.gmail.com>
	<CAGQtxvab=JiybjEByxcJakoTZ0n4nOuMrfUTKBf6i=CExe_zog@mail.gmail.com>
	<CALFpzo7ijXU+f0UFrdMThjx8kKGfT9iJYNWRZ8tSO4BgYQ+yKg@mail.gmail.com>
	<CAP997UcAKzcxjmBmh3OxVaswUKSsntqYo0hOOwo9qUhLM5hQrg@mail.gmail.com>
Date: Thu, 22 May 2014 09:04:21 -0600
Message-ID: 
 <CALFpzo46BaTjYmPD7xeLWFwCz9kKn3p2toKPax-zEkP39RkAGw@mail.gmail.com>
Subject: Re: Network IDS in VPC
From: Marcus <shadowsor@gmail.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=001a11c3a28484901204f9fe6db4

--001a11c3a28484901204f9fe6db4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=B8lgende:
>
> > I've always viewed the permissions to be additive, if a domain admin ha=
s
> > 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 introduc=
e
> 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 abl=
e
> to
> > if they had access to the root passwords of the tenant's instances or t=
he
> > 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 stora=
ge
> > 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 suppose=
d
> 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 maintenanc=
e
> 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 route=
r.
> > These (along with the migration issues) are the reasons why I was leani=
ng
> > 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 reall=
y
> > > > 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 networ=
k
> > 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 VP=
C
> > > router
> > > >> that does traffic mirroring (netsniff-ng or daemonlogger are debia=
n
> > > >> packages) from the public interface to the 'sniffer net' interface=
.
> > > >>
> > > >> 2) disables mac learning on the bridges created for the sniffer ne=
t,
> > 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 b=
e
> up
> > > to
> > > >> the customer, it would simply create a network that enables traffi=
c
> > > >> 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 no=
t
> an
> > > >> immediate requirement. I dislike the idea of trying to run an actu=
al
> > > >> 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 interfac=
e
> > > >> directly to another VM's interface, host side (daemonlogger -i
> vpcintf
> > > -o
> > > >> idsintf), but it would need to be on the same host.
> > > >>
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
>

--001a11c3a28484901204f9fe6db4--