November 15, 2019
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.
Since CloudFormation support is still lacking let’s check out the VPC Console and get our environment set up.
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.
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.
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:
- Lack of Terraform/CloudFormation support
- Only supports the latest Nitro Hypervisor
- Setting up a SOC
- Balancing, Ignorance is not always Bliss (Successful preprocessing in the clod)
- Breaking TLS for inspection