> For the complete documentation index, see [llms.txt](https://docs.qpoint.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.qpoint.io/getting-started/qtap/configuration/traffic-capture-settings.md). # 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: ```yaml 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) | ```yaml 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: ```yaml 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: ```yaml 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: ```yaml 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: ```yaml 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: ```yaml 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: ```yaml 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: ```yaml 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:** ```yaml 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:** ```yaml 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:** ```yaml 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:** ```yaml 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: ```bash # 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: ```bash 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: ```yaml 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: ```yaml 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 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.qpoint.io/getting-started/qtap/configuration/traffic-capture-settings.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.