# 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