# Firewall Configuration

This document outlines the required Firewall configurations to ensure proper connectivity between your infrastructure and Escape's security testing platform.

## Ingress Rules (Incoming Connections)

### Identifying Escape Traffic (WAF / Bot Protection Allowlisting)

If your WAF, bot protection service, or rate limiter blocks, throttles, or challenges scanner requests, configure an allowlist for Escape's traffic. Examples include Cloudflare, Akamai, AWS WAF, Imperva, and DataDome. For HTTP traffic from REST DAST, GraphQL DAST, and Frontend DAST, use these identification signals:

1. **IP address**: See the [Public Locations](<#public-locations>) table below.
2. **The `Sec-Escape-User` header**: An Escape-specific HTTP header that identifies the simulated user sending the request.

> [!TIP]
>
> **Quick answer: is there a single header I can whitelist?**
>
> **Yes: `Sec-Escape-User`.** REST DAST, GraphQL DAST, and Frontend DAST use this header without customer configuration. AI Pentesting browser traffic also supports it. Raw ASM probes, such as DNS and port scans, don't carry HTTP headers. Pair the header with a source IP or shared secret for allowlisting.

#### Recommended WAF Allowlist Rule

HTTP headers can be spoofed. Use `Sec-Escape-User` to tag traffic in logs. To allow traffic to bypass WAF rules, validate the source IP or a shared secret with one of these rules:

**Option A: IP + Header (simplest)**

Allow traffic when **both** conditions are true:

- Source IP is in the [Public Locations](<#public-locations>) table (or your [Private Location](<https://docs.escape.tech/documentation/platform/private-location/index.md>) egress IP), **AND**
- Request contains a `Sec-Escape-User` header.

This is the right default for most customers: no extra configuration in Escape, and the IP match prevents spoofing.

**Option B: Shared Secret Header (most flexible)**

If your network path makes IP allowlisting painful (shared egress, proxies, CDN-to-origin flows), configure a custom header containing a shared secret and allowlist on that secret instead. In your global or per-scan configuration:

```yaml
network:
  custom_headers:
    X-Escape-WAF-Bypass:
      - "<your-long-random-secret>"
```

Then in your WAF, allow any request that presents `X-Escape-WAF-Bypass: <your-long-random-secret>`. Rotate the secret the same way you would rotate any other credential.

> [!WARNING]
>
> **Never allowlist on the header alone**
>
> An attacker who discovers that your WAF trusts `Sec-Escape-User` can simply send that header to bypass your WAF. Always pair the header with an IP allowlist (Option A) or a secret (Option B).

#### Where to Configure

`custom_headers` lives under the top-level `network:` key in the scan configuration YAML, which is the same across every scan type. See each product's reference for the full schema:

- [REST DAST: `network` config](<https://docs.escape.tech/documentation/reference/configuration-schemas/api-dast-rest/index.md>)
- [GraphQL DAST: `network` config](<https://docs.escape.tech/documentation/reference/configuration-schemas/api-dast-graphql/index.md>)
- [Frontend DAST: `network` config](<https://docs.escape.tech/documentation/reference/configuration-schemas/webapp-dast/index.md>)
- [ASM: `network` config](<https://docs.escape.tech/documentation/reference/configuration-schemas/asm/index.md>)

You can set these values either in your organization-wide defaults or in **Settings \> Scan configuration \> Expert** for a DAST profile: scan-level values override defaults.

### Public Locations

By default, all security testing requests from Escape are routed through [Public Locations](<https://app.escape.tech/organization/private-locations/>) in your organization. To allow incoming traffic from Escape's Public Locations, allowlist the following IP addresses in your Firewall configuration:

| IP Address | Region |
| --- | --- |
| `163.172.177.16` | Europe |
| `163.172.182.228` | Europe |
| `163.172.182.47` | Europe |
| `163.172.178.115` | Europe |
| `163.172.174.61` | Europe |
| `163.172.168.233` | Europe |
| `51.79.24.70` | Canada |
| `51.79.25.196` | Canada |
| `51.79.26.185` | Canada |
| `172.235.52.11` | United States |
| `172.235.52.232` | United States |
| `172.236.242.86` | United States |

These addresses are the egress IPs of Escape [Public Location](<https://app.escape.tech/organization/private-locations/>) SOCKS proxies. DAST, ASM, and AI Pentesting scan traffic to your applications appears to come from these IPs.

> [!NOTE]
>
> **Private Locations**
>
> Alternatively, you can deploy [Private Locations](<https://docs.escape.tech/documentation/platform/private-location/index.md>) to route requests through your own network infrastructure. Private Locations enable secure detection, fingerprinting, and scanning of internal applications behind your organization's Firewall or VPN without exposing them to the public internet.

### Workflow Webhooks and Platform Outbound HTTP

Workflow webhooks, connectivity checks, and other platform callbacks send HTTP requests **to** your infrastructure (inbound on your side). This traffic originates from Escape platform infrastructure at `23.22.140.167`. Configure its allowlist separately from the regional Public Location scan proxies above.

Use this table when you need to allowlist Escape on a **webhook receiver**, API gateway, or WAF in front of an endpoint that receives workflow exports or connectivity probes:

| IP Address | Purpose |
| --- | --- |
| `23.22.140.167` | [Workflow webhooks](<https://docs.escape.tech/documentation/automate/workflows/webhook/index.md>), connectivity checks, and other platform-originated callbacks to your URLs |

> [!TIP]
>
> **How to confirm the source IP**
>
> Trigger a workflow with a [Webhook](<https://docs.escape.tech/documentation/automate/workflows/webhook/index.md>) export action pointed at a URL you control, then inspect the access logs on that endpoint. The client IP should match `23.22.140.167`.

> [!NOTE]
>
> **Allowlisting Workflow Webhooks**
>
> Add `23.22.140.167` to your allowlist when your firewall sits in front of a customer-hosted webhook URL.

### External Exposure Assessment

In order to assess whether your assets are exposed to the public Internet, we use the following IP addresses. **Please DO NOT add them to the IP allowlist of your firewall**, as they are precisely used to simulate access from the open internet, mirroring the behavior of real-world attackers or external users outside your infrastructure.

| IP Address | Region |
| --- | --- |
| `172.232.32.148` | Europe |
| `172.236.228.250` | United States |

## Egress Rules (Outgoing Connections)

### Required for Private Locations and Out-of-Band Testing

To enable Private Locations and Out-of-Band Testing capabilities (to detect vulnerabilities like SSRF), ensure that outgoing connections are allowed to the following endpoints:

| Purpose | Address/Domain | Protocol | Port(s) |
| --- | --- | --- | --- |
| Escape Platform API | `public.escape.tech` | HTTPS | `443` |
| CLI Update Checks | `api.github.com` | HTTPS | `443` |
| Out-of-Band Testing | `51.159.205.221` | HTTP | `80` |
| Out-of-Band Testing | `51.159.205.221` | HTTPS | `443` |
| Out-of-Band Testing | `ssrf.tools.escape.tech` | HTTP | `80` |
| Out-of-Band Testing | `ssrf.tools.escape.tech` | HTTPS | `443` |

### Private Location Tunnel

A Private Location also needs one outbound tunnel, over SSH or HTTPS. Open only the one matching the [transport you deploy with](<https://docs.escape.tech/documentation/platform/private-location/deployment/#choose-a-transport>).

**SSH**

| Address/Domain | Protocol | Port |
| --- | --- | --- |
| `private-location.escape.tech` | SSH | `2222` |
| `34.198.143.22` | SSH | `2222` |
| `52.6.14.96` | SSH | `2222` |

If your firewall requires IP addresses instead of domain names, run `nslookup private-location.escape.tech` to retrieve the current ones.

Test from your internal network:

```bash
ssh -v private-location.escape.tech -p 2222
```

**Expected Result:** The output shows that the SSH connection reaches the server, for example `debug1: Connection established`. Your local SSH client's version banner alone doesn't confirm connectivity.

**HTTPS**

| Address/Domain | Protocol | Port |
| --- | --- | --- |
| `location.escape.tech` | HTTPS (WebSocket or HTTP) | `443` |

Allow `location.escape.tech` by hostname. It sits behind a load balancer whose IP addresses can change without notice, and differ from the SSH endpoint. If you must allowlist by IP, run `nslookup location.escape.tech` and re-check regularly.

Test from your internal network:

```bash
curl -v https://location.escape.tech/v2/connect
```

**Expected Result:** The TLS handshake completes and the server returns an HTTP response. Any status code, including `4xx`, confirms that `location.escape.tech:443` is reachable. A timeout means port `443` is blocked. A TLS or certificate error usually means a TLS-inspecting proxy re-signs the traffic: add its CA as described in [SSL Configuration](<https://docs.escape.tech/documentation/platform/private-location/ssl/index.md>).

### Verifying Firewall Configuration

To verify that your Firewall is properly configured, run the following connectivity tests from your internal network. For the Private Location tunnel, use the test in the [tab above](<#private-location-tunnel>).

#### Test Out-of-Band Testing Endpoints

```bash
curl -v http://ssrf.tools.escape.tech
curl -v https://ssrf.tools.escape.tech
```

**Expected Result:** Both commands should return an HTTP response (any status code indicates successful connectivity). If either command times out or fails to connect, the corresponding protocol (HTTP or HTTPS) requires additional Firewall configuration.