ALB Traffic Capture with AWS Traffic Mirroring

Discover how Pynt leverages AWS Traffic Mirroring to capture live traffic for API discovery and security testing, providing deep visibility without impacting performance.

Introduction & Purpose

This document provides a concise overview of how Pynt leverages AWS Traffic Mirroring and Suricata to capture real-time HTTP traffic from ALB target groups. The captured traffic is converted into HAR files, serving as an additional source for API testing - just like our eBPF approach. By analyzing real traffic, we uncover both known and shadow endpoints with minimal impact to production workloads, enabling continuous API discovery and robust security testing.

---

1. Why Live Traffic Capture?

1. Full Visibility: By mirroring raw traffic from your ALB target groups, you discover all real-time API calls, including hidden or undocumented endpoints.

2. Low Overhead: AWS Traffic Mirroring has a minimal performance impact on production instances, as only a copy of the packets is sent to a separate target instance.

3. Actionable Insights for Testing: Generating HAR files from actual network activity enables integration into security workflows—including fuzzing, pen-testing, or uploading to Pynt’s SaaS. This approach reveals vulnerabilities that static or manual discovery might miss.

---

2. Key Components

Mirror Manager

• Purpose: Automates discovery/configuration of AWS Traffic Mirroring for ALB target groups.

• Deployment: Typically runs on a dedicated Target Instance or with Pynt’s internal services.

• Value: Eliminates manual overhead by identifying relevant instances and setting up mirroring seamlessly.

Target Instance (Suricata)

• Purpose: Receives mirrored traffic, uses Suricata to parse HTTP flows, and hands off data to the Aggregator.

• Deployment: An EC2 instance in the customer’s AWS account.

• Benefit: Centralized environment for analyzing mirrored packets, leaving production nodes unaffected.

Aggregator

• Purpose: Collects, filters, deduplicates Suricata’s session data, and generates HAR files.

• Deployment: Can run on the same Target Instance or in a separate container environment.

• Responsibilities:

  • Filtering noise or irrelevant traffic

  • Deduplicating repeated sessions

  • Storing recent sessions (configurable limit)

  • Generating HAR files on demand

  • Enabling further testing (local or SaaS)

Attacker Container (Sidecar)

• Purpose: Accesses generated HAR files for automated security testing (e.g., DAST/fuzzing).

• Deployment: A sidecar within the Aggregator’s pod (if containerized).

• Value: Allows immediate, in-cluster usage of HAR files for rapid testing without manual file transfers.

---

3. Architecture Diagram

AWS Traffic Mirroring

---

4. Data Flow & High-Level Steps

1. Mirroring Setup (Mirror Manager): Discover ALB target group instances and configure AWS Traffic Mirroring.

2. Packet Capture (Suricata):

   1. Suricata inspects mirrored packets in real time, logging HTTP request/response details.

   2. Logs are stored locally for the Aggregator to process.

3. Aggregation & Storage

   1. The Aggregator collects Suricata’s session data, filtering and deduplicating.

   2. Recent sessions remain in memory; a request to the Aggregator API produces an HAR file.

4. HAR Generation & Testing

   1. The Aggregator saves an HAR file.

   2. (Optional) Upload or stream the HAR to Pynt’s SaaS for advanced scanning (fuzzing, vulnerability detection, API inventory creation).

5. API Discovery & Inventory

   1. The captured sessions reveal all encountered endpoints, including shadow APIs.

   2. This inventory can be maintained locally or synced to Pynt’s SaaS for continuous analysis.

---

5. Security & Trust Considerations

1. Minimal Footprint: Traffic mirroring offloads analysis to a separate Target Instance, preserving performance on production ALB instances.

2. Controlled Access: IAM roles govern who can configure mirroring.

3. Filtered Storage: Aggregator rules ensure that only relevant or necessary HTTP data is retained, protecting sensitive information from overexposure.

---

6. Next Steps & Additional Resources

1. Setup Guidelines: The EC2 and Pynt’s services are deployed by applying Pynt’s Terraform module on your AWS account.

2. Integration Support

   1. Our team is available to help tailor filtering rules, memory limits, or advanced Suricata settings.

   2. We’ll also advise on piping HAR files to Pynt’s SaaS or local scanners for robust vulnerability testing.

3. Documentation Request

   Because these details are not publicly available, we’ll share them directly or schedule a walkthrough based on your environment specifics.