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 target is fronted by a WAF, bot protection service, or rate-limiter (Cloudflare, Akamai, AWS WAF, Imperva, DataDome, reCAPTCHA, etc.), you'll usually need to allowlist Escape's traffic so scans aren't blocked, throttled, or challenged. Escape offers two identification mechanisms available across scan types (REST DAST, GraphQL DAST, Frontend DAST, and ASM). By default, both are included on requests unless explicitly disabled in configuration:

1. IP address — see the Public Locations table below. This is the only identifier that cannot be spoofed by a third party.
2. The Sec-Escape-User header — a single, Escape-specific HTTP header that identifies which scan and which simulated user sent each request.

Recommended WAF Allowlist Rule¶

HTTP headers can be trivially spoofed. Sec-Escape-User alone is fine for identification (e.g. to tag Escape traffic in logs), but for allowlisting — letting traffic bypass WAF rules — combine it with something that cannot be spoofed. Two equally good options:

network:
  sec_escape_user: true
  custom_headers:
    X-Escape-WAF-Bypass:
      - "<your-long-random-secret>"

Where to Configure¶

sec_escape_user and custom_headers live 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
• GraphQL DAST — network config
• Frontend DAST — network config
• ASM — network config

You can set these values either in your organization-wide defaults or in the Expert Configuration of an individual scan — scan-level values override defaults.

Public Locations¶

By default, all security testing requests from Escape are routed through Public Locations in your organization. To allow incoming traffic from Escape's Public Locations, allowlist the following IP addresses in your Firewall configuration:

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.

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:

Verifying Firewall Configuration¶

To verify that your Firewall is properly configured, run the following connectivity tests from your internal network:

Test Private Location Connection¶

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

Expected Result: The output should include debug1: OpenSSH_10.0p2, OpenSSL 3.4.1 11 Feb 2025 or similar version information, indicating successful SSH connectivity.

Test Out-of-Band Testing Endpoints¶

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.