Melpomene - Fotolia
How AWS VPC Traffic Mirroring works
Solve cloud network traffic issues with VPC Traffic Mirroring. Breakdown how traffic mirroring works and how it can boost monitoring and security practices in your AWS environment.
Cloud networks can be congested and chaotic places, with a complex maze of switches, routers and gateways over both physical and virtual routes. To balance traffic loads, block unwanted traffic and spot intrusions -- all of this on-the-fly -- IT organizations must review and analyze their cloud network traffic.
The VPC Traffic Mirroring feature for AWS' private cloud instances aims to simplify this complexity. The service is a virtualized equivalent of traditional network monitoring taps and tools. It copies network traffic for processing and analysis with monitoring or security virtual appliances.
The target location for mirrored traffic is dedicated on out-of-band infrastructure, meaning it is not part of the regular client/server VPC network. The target could be a network interface or a Network Load Balancer. This ensures low latency and high responsiveness for workloads.
VPC Traffic Mirroring gives IT organizations data for troubleshooting and intrusion detection, along with other types of threat monitoring and content inspection. The feature pulls this data from strategic spots on the network and sends it to these traffic mirror targets.
VPC users who want to analyze network traffic need to understand how VPC Traffic Mirroring works, the feature's use cases and its limitations. They might need to compare it to VPC Flow Logs so they can use the right technique for a given operations task. There are also additional tools to know to make the most of traffic analysis.
Inside VPC Traffic Mirroring
VPC Traffic Mirroring creates a copy of traffic on VPC network interfaces associated with EC2 instances. Mirroring can capture inbound and outbound network traffic. To configure VPC Traffic Mirroring, IT organizations must set up traffic sources and targets, filters, mirror sessions and connectivity.
The traffic source is where AWS copies the network traffic -- virtually always the network interface of an EC2 instance.
The traffic target is the destination of that mirrored traffic: the network interface of another EC2 instance or other services, such as load balancers. The target may be within the same VPC or in a different one. Users can select multiple traffic sources and direct the mirrored traffic to the same or different target as desired.
Once the source and destination are selected, configure appropriate filters. These are rules that govern the mirrored inbound and outbound traffic. There are no rules by default, and traffic mirroring can't occur without these rules. Add rules to filter network traffic using an array of criteria. Some common filters cover traffic direction, source ports, source classless inter-domain routing (CIDR), target ports, target CIDR, traffic following a desired protocol and action, such as capture or reject.
After setting filters, create a mirror session, which stipulates the relationship between the source, target and filter. Once you invoke a session, AWS encapsulates any traffic packets that match the filter criteria in a Virtual Extensible LAN wrapper and sends them to the target.
Multiple sessions can involve the same source or sources. That network traffic would be mirrored multiple times and delivered to different tools or virtual appliances. For example, one session is configured to copy specific incoming packets and send that traffic to a target for security monitoring, while another session copies all traffic at the source and sends it to a target for content monitoring. Users can also assign priorities to multiple sessions.
Finally, mirrored network traffic is subject to connectivity considerations. The source and target can share a VPC, or exist in different ones with an intra-Region VPC peering connection or a transit gateway. And the traffic target does not have to share an AWS account with the source. Thus, users must know the AWS rules that govern routing before they implement VPC Traffic Mirroring.
VPC Traffic Mirroring uses
Network traffic mirroring fits many purposes, including analysis to address problems and for regulations compliance. Mirrored traffic essentially provides a basis to evaluate, test and troubleshoot the network.
For compliance, mirrored traffic monitoring, logging and analytics can complement business governance requirements, because the business demonstrates that it has visibility into its network.
For security hardening, mirrored traffic data can provide a basis to test the effects of security changes, such as running an intrusion detection platform.
The support team can analyze outages caused by an arcane or easily overlooked configuration problem thanks to mirroring. Examples include poor firewall rules or an incorrect routing protocol.
For optimization, teams can watch traffic at multiple strategic points in the network to identify bottlenecks and problematic workloads, analyze the issues and zero in on corrective actions.
Traffic Mirroring vs. VPC Flow Logs
AWS users should compare VPC Traffic Mirroring to VPC Flow Logs in terms of use cases. Flow logs capture source and destination IP addresses, ports, protocols, packets and actions taken with that traffic. Logs are a useful tool for troubleshooting connectivity and security problems within the network, and to validate that network access rules are correct. Mirroring goes farther by capturing the actual data payload: what data is sent, not just how it's sent. Use mirroring for deeper analytics tasks than with logs. Examples include root cause analysis, reconstructing network attacks and to find inappropriate content or malicious activity. Users can put VPC Traffic Mirroring and VPC Flow Logs together to monitor VPC traffic.
Tools for VPC traffic analysis
There is a range of tools and services available for network data analysis.
Some are intended specifically for cloud services such as AWS VPC Traffic Mirroring. ExtraHop Reveal(x) Cloud is a SaaS tool that offers network threat detection, investigation and response using AWS VPC Traffic Mirroring. Nubeva TLS Decrypt does out-of-band packet decryption, so security professionals can decrypt and inspect every packet traversing critical workloads or storage. Services such as JASK monitor and analyze collected traffic from clouds, including AWS.
AWS users can also consider free or open source tools. Zeek Network Security Monitor is a comprehensive open source platform for intrusion detection and other security monitoring features, as well as network traffic analysis. Suricata, an open source network threat detection engine, enables real-time intrusion detection and prevention and network security monitoring, driven by the Open Information Security Foundation.
Limits set by AWS
AWS imposes several limits on VPC Traffic Mirroring, which could prevent users from adopting the service for a given task.
Instances. Traffic Mirroring is currently available only on AWS Nitro-based instances. These include various hypervisor-based instances such as A1, C5, C5d, C5n, G4, I3en, M5, M5a, M5ad, M5d, p3dn.24xlarge, R5, R5a, R5ad, R5d, T3, T3a and z1d, as well as varied bare metal instances including c5.metal, c5n.metal, i3.metal, i3en.metal, m5.metal, m5d.metal, r5.metal, r5d.metal, u-6tb1.metal, u-9tb1.metal, u-12tb1.metal and z1d.metal.
Packet handling. AWS may truncate packets to a maximum transmission unit (MTU) value if the mirrored packet size is larger than the target's MTU value. Cut off packets can result in unexpected data loss. Users may need to configure the target's MTU to a larger value to prevent this issue. Even with these steps, mirrored traffic may still get dropped in the event of network congestion, as AWS prioritizes the production network. Source packets dropped due to security group or network access control list rules are not mirrored. In all cases, the outgoing security group does not evaluate mirrored traffic.
Traffic and mirroring limits. VPC Traffic Mirroring cannot mirror all types of traffic. At time of publication, ARP, DHCP, Instance metadata service, NTP and Windows activation traffic cannot be mirrored. The service supports up to 10,000 sessions per account; up to three sessions per network interface; up to 10,000 traffic mirror targets per account; up to 100 mirror sources per dedicated instance type as target; up to 10 mirror sources per non-dedicated instance type as target; and up to 10 rules per filter. Users can request increases to these limits through AWS if needed.
Bandwidth impact. Mirrored traffic counts toward instance bandwidth. If a network interface handles 1 Gbps of inbound traffic and 1 Gbps of outbound traffic, the bandwidth must accommodate 4 Gbps to cover the existing and mirrored inbound and outbound traffic.
There are other limits not listed here, such as AWS load balancer considerations. Visit the AWS documentation to review the latest limitations when evaluating or adopting the service.
In addition to these limits imposed by the cloud provider, check for data rules within your organization. Copying network traffic can pose security headaches -- just consider what happens when sensitive business data goes to a weakly secured mirroring target. Put controls in place to delineate which users can mirror traffic, implement authentication and access control to protect mirrored traffic, enforce appropriate processes and procedures that will shut down sessions as needed, and protect the mirrored data in flight and at rest.
