Skip to content

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 table below.
  2. The Sec-Escape-User header: An Escape-specific HTTP header that identifies the simulated user sending the request.

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.

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:

Allow traffic when both conditions are true:

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

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:

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.

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:

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 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 SOCKS proxies. DAST, ASM, and AI Pentesting scan traffic to your applications appears to come from these IPs.

Private Locations

Alternatively, you can deploy Private Locations 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, connectivity checks, and other platform-originated callbacks to your URLs

How to confirm the source IP

Trigger a workflow with a Webhook 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.

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)
Private Location Tunnel 34.198.143.22 SSH 2222
Private Location Tunnel 52.6.14.96 SSH 2222
Private Location Tunnel private-location.escape.tech TCP 2222
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

IP-Based Firewall Rules

If your Firewall requires specific IP addresses instead of domain names, use nslookup private-location.escape.tech to retrieve the current IP addresses.

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 show that the SSH connection reaches the server, for example debug1: Connection established. Your local SSH client's version banner alone doesn't confirm 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.