Implementing VPC Traffic Mirroring

One of the more hyped services to come to AWS during re:inforce is VPC Traffic Mirroring. We are going to cover this in-depth since it has the potential to have an immediate impact on our clients that have PCI-DSS and other compliance requirements.

Up until this point, AWS’s position (as stated within their PCI-DSS roles and responsibility matrix) has been:

“Intrusion-detection systems were a shared responsibility, and AWS customers are responsible for implementing IDS functionality, typically using Host-based IDS (HIDS), for network segments they implement and manage.”

Because of this our clients have built out their EC2’s with HIDS and left the NIDS up to AWS.

Today we are going to walk through the process of setting up VPC Traffic Mirroring, test it out to make sure it works, and in future blog posts, we are going to establish a Cloud SOC with some of the most popular open-source tools used in the industry.

AWS Language

The first we need to cover is the Seattle Terminology.

Mirror Source – An AWS network resource that exists within a particular VPC, and that can be used as the source of traffic. VPC Traffic Mirroring supports the use of Elastic Network Interfaces (ENIs) as mirror sources.

Mirror Target – An ENI or Network Load Balancer that serves as a destination for the mirrored traffic.

Mirror Filter – A specification of the inbound or outbound (with respect to the source) traffic that is to be captured (accepted) or skipped (rejected). The filter can specify a protocol, ranges for the source and destination ports, and CIDR blocks for the source and destination. Rules are numbered and processed in order within the scope of a particular Mirror Session.

Traffic Mirror Session – A connection between a mirror source and target that makes use of a filter. Sessions are numbered, evaluated in order, and the first match (accept or reject) is used to determine the fate of the packet. A given packet is sent to at most one target.

Since CloudFormation support is still lacking let’s check out the VPC Console and get our environment setup.

Setup the Tap

Step 1 Document ENIs:
Since this is our lab environment, we are not using a Network Load Balancer, which would be the ideal spot for the Mirror source. I have labeled them accordingly. The Mirror Source is the ENI for the EC2 found within our DMZ subnet.

Github Project

Step 2: Attaching the ENI’s:
Your environment may look different, but for this particular lab, we are going to attach the Virtual Tap to our Bastion Host within our EC2.

Step 3: VPC – Create Mirror target

Step 4: Create Traffic Mirror Filter
Now we are going to create the Traffic Mirror Filter. The paranoid side of me would want to monitor all traffic in, and out. However, since we are just testing this at the moment, I’m going to establish filters over the protocols that are inspected for testing.

 

Step 5: Create Traffic Mirror Session
Lastly, we need to create the Traffic Mirror Session; this is the destination of the tapped traffic. Everything is straight forward here, and AWS provides some helpful tips to make sure you are selecting the correct source, target, and filter.

Step 6: The Test
Odd that when doing the ifconfig command that the Interface setup as the tap does not show up as in promiscuous mode, but that’s to be expected.

Overall Impressions:

Well, that was pretty straight forward. We ran into a few bumps along the way, but that was mostly related to restricted network settings from my lab.

Overall, I feel this has the most significant impact on our clients from an architecture perspective, when concerning upcoming security assessments. At this point, AWS has not revised their roles and responsibility matrix.

If you need assistance with the architecture, we are here to help – at Tevora we have quite a bit of experience and love helping our current and future clients with these sorts of projects. Remember, it is not just about setting up the Tap, but ensuring you have the right security stack to support it for your organization. Generally, we see organizations immediately start to ignore or interpret the alerts they are getting as false positives, which personally I can’t understand! How can you classify something as a false positive without an investigation? Most of these alerts can be balanced with careful tuning of things like preprocessors.

For our next post, we will setup up a LAMP stack, and install SNORT to see if there is odd behavior when using a virtual tap. Then we will go down the route of getting Security Onion setup. If you are not familiar with Security Onion, it is a great tool that brings together excellent resources such as ELK, SNORT, BRO, Suricata and more into a single platform, all working beautifully together. I have been running it at home for years and I am excited to see its capabilities in the Cloud.

Current VPC Traffic Mirroring Limitations:

  1. Lack of Terraform/CloudFormation support
  2. Only supports the latest Nitro Hypervisor

Upcoming Research:

  1. Setting up a SOC
  2. Balancing, Ignorance is not always Bliss (Successful preprocessing in the clod)
  3. Breaking TLS for inspection