Traffic Capture Settings

The tap section in your Qtap configuration controls what traffic is processed. This section provides fine-grained control over which network connections to monitor, what traffic to include or exclude, and how to apply different processing stacks to specific domains.

Basic Configuration

Here's the structure of a basic tap configuration:

tap:
  direction: egress
  ignore_loopback: false
  audit_include_dns: true
  http:
    stack: default_stack

Traffic Direction Settings

The direction parameter controls which traffic flows Qtap captures:

Option	Description
egress	Captures all outgoing traffic (both internal and external)
egress-external	Only captures traffic to external networks
egress-internal	Only captures traffic to internal networks
ingress	Only captures inbound traffic
all	Captures all traffic (inbound and outbound)

tap:
  direction: egress-external  # Only capture traffic going to external networks

Network Interface Settings

Loopback Traffic

The ignore_loopback parameter controls whether traffic on the loopback interface (localhost) is captured:

tap:
  ignore_loopback: true  # Don't capture localhost traffic

• When set to true, traffic to addresses like 127.0.0.1 or localhost is ignored

• When set to false, local traffic is included in capture

DNS Traffic

The audit_include_dns parameter controls whether DNS queries are captured:

tap:
  audit_include_dns: true  # Include DNS traffic in audit logs

This is useful for:

• Troubleshooting DNS resolution issues

• Tracking which domains your applications are trying to reach

• Identifying potential DNS-based data exfiltration

Process Filtering

The filters section allows you to control which processes Qtap monitors:

tap:
  filters:
    groups:
      - kubernetes
      - qpoint
    custom:
      - exe: /usr/bin/curl
        strategy: exact
      - exe: /usr/bin/python3
        strategy: prefix
      - exe: .*ruby.*
        strategy: regex

Predefined Process Groups

The groups parameter allows you to ignore specific types of processes:

Group	Description
kubernetes	Standard Kubernetes processes
container	Container runtime processes
gke	Google Kubernetes Engine processes
eks	Amazon Elastic Kubernetes Service processes
qpoint	Qpoint's own processes (prevents self-monitoring)

When a group is included in the list, traffic from those processes is ignored.

Custom Process Filters

The custom parameter allows you to define specific processes to ignore:

custom:
  - exe: /usr/bin/curl
    strategy: exact

Each entry requires:

• exe: The executable path

• strategy: Matching strategy, which can be:

  • exact: Exact path match

  • prefix: Path prefix match

  • regex: Regular expression match

Strategy Examples

Exact Match - Blocks only the specific path:

filters:
  custom:
    - exe: /usr/bin/curl
      strategy: exact

• Blocks: /usr/bin/curl

• Does NOT block: /usr/local/bin/curl, /bin/curl, /opt/curl/bin/curl

Prefix Match - Blocks anything starting with the prefix:

filters:
  custom:
    - exe: /usr/bin/
      strategy: prefix

• Blocks: /usr/bin/curl, /usr/bin/wget, /usr/bin/python3

• Does NOT block: /usr/local/bin/curl, /bin/sh

Regex Match - Blocks paths matching the regex pattern:

filters:
  custom:
    - exe: .*curl.*
      strategy: regex

• Blocks: /usr/bin/curl, /usr/local/bin/curl, /opt/my-curl-app/bin/app

• Does NOT block: /usr/bin/wget, /usr/bin/python3

Common Use Cases

Development - Filter CLI tools to reduce noise:

filters:
  custom:
    # Block common HTTP clients
    - exe: /usr/bin/curl
      strategy: exact
    - exe: /usr/bin/wget
      strategy: exact

    # Block package managers
    - exe: /usr/bin/apt
      strategy: exact
    - exe: /usr/bin/yum
      strategy: exact

Production - Filter system processes:

filters:
  groups:
    - kubernetes
    - qpoint
  custom:
    # Block monitoring agents
    - exe: /opt/datadog-agent
      strategy: prefix
    - exe: /usr/bin/node_exporter
      strategy: exact

    # Block backup tools
    - exe: .*backup.*
      strategy: regex

Container environments - Filter by container tools:

filters:
  custom:
    # Docker containers often have curl at /usr/bin/curl
    - exe: /usr/bin/curl
      strategy: exact

    # Alpine-based containers
    - exe: /bin/wget
      strategy: exact

Multiple installations - Use regex to catch all variants:

filters:
  custom:
    # Catch curl wherever it's installed
    - exe: .*curl.*
      strategy: regex

    # Catch Python anywhere (python, python3, /opt/python, etc.)
    - exe: .*python.*
      strategy: regex

Finding the correct path:

To determine what path Qtap sees for a process, check the logs:

# Start Qtap and generate traffic
docker logs qtap-container 2>&1 | grep '"exe"' | head -20

# Look for exe field in output:
# "exe":"/usr/bin/curl"  <- This is what you filter on

Or find the path on your system:

which curl                    # Shows: /usr/bin/curl
readlink -f $(which curl)     # Shows real path if it's a symlink

Domain-Specific Rules

The endpoints section allows you to apply different processing stacks to specific domains or patterns:

tap:
  http:
    stack: default_stack  # Default stack for most traffic
  endpoints:
    - domain: 'api.payment-processor.com'
      http:
        stack: payment_stack  # Special stack for payment processor traffic
    - domain: 'internal-api.example.com'
      http:
        stack: debug_stack  # Debug stack for internal API traffic

Each endpoint entry consists of:

• domain: The domain pattern to match (supports wildcards)

• http.stack: The stack to apply for matching HTTP traffic

This allows you to:

• Apply detailed logging to specific APIs

• Handle sensitive traffic differently

• Focus debugging efforts on problematic domains

Complete Example

Here's a comprehensive example that demonstrates all the main features:

tap:
  direction: egress
  ignore_loopback: true
  audit_include_dns: true
  http:
    stack: default_stack
  filters:
    groups:
      - qpoint
      - kubernetes
    custom:
      - exe: /usr/bin/wget
        strategy: exact
      - exe: /usr/bin/curl
        strategy: exact
  endpoints:
    - domain: 'api.github.com'
      http:
        stack: debug_stack
    - domain: 'api.google.com'
      http:
        stack: debug_stack

This configuration:

1. Captures all outgoing traffic (direction: egress)

2. Ignores localhost traffic (ignore_loopback: true)

3. Includes DNS queries in audit logs (audit_include_dns: true)

4. Applies the default_stack to most HTTP traffic

5. Ignores traffic from Kubernetes and Qpoint processes

6. Ignores traffic from specific executables (wget, curl)

7. Applies the debug_stack to all traffic to api.github.com and api.google.com domains