Network IDS in VPC

[Marcus <sh...@gmail.com>]

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.

Re: Network IDS in VPC

[Marcus <sh...@gmail.com>]

The traffic is sniffer traffic. It wouldn't be a network for guests, or
public, it would be both.


On Fri, May 23, 2014 at 2:45 PM, Daan Hoogland <da...@gmail.com>wrote:

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

Re: Network IDS in VPC

[Daan Hoogland <da...@gmail.com>]

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

Re: Network IDS in VPC

[Marcus <sh...@gmail.com>]

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 <sh...@gmail.com> wrote:

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

Re: Network IDS in VPC

[Marcus <sh...@gmail.com>]

Yet another vector


On Thu, May 22, 2014 at 8:07 AM, Erik Weber <te...@gmail.com> wrote:

> What prevents root from revealing and using the domain admin api / secret
> Key?
>
> Erik
> 22. mai 2014 15:54 skrev "Marcus" <sh...@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 <sh...@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 <sh...@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
> > >
> >
>

Re: Network IDS in VPC

[Erik Weber <te...@gmail.com>]

What prevents root from revealing and using the domain admin api / secret
Key?

Erik
22. mai 2014 15:54 skrev "Marcus" <sh...@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 <sh...@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 <sh...@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
> >
>

Re: Network IDS in VPC

[Marcus <sh...@gmail.com>]

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 <da...@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 <sh...@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 <sh...@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
>

Re: Network IDS in VPC

[Daan Hoogland <da...@gmail.com>]

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 <sh...@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 <sh...@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

Re: Network IDS in VPC

[Marcus <sh...@gmail.com>]

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 <sh...@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.
>
>
>
>