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