Connector | Fluid Attacks Help


This section reviews the Connector connection used by Fluid Attacks to access the private resources required to provide our service.


Here you will find the high-level architecture for the Connector connection used by Fluid Attacks as well as its minimum requirements and limitations. This solution relies on Cloudflare Connector.

High-level architecture

We use a pivot agent in order to access your resources.

The pivot agent is installed in a container or server within your private network and will be the one accessing the private resources you expose to it.

Below is a high-level diagram that shows how the connection works.

Architecture - Connector

Pivot agent minimum requirements

  1. 1 CPU
  2. 2 GiB of memory
  3. At least 5GB of free disk space
  4. A user with administrative privileges
  5. Docker, Linux, Windows or macOS
  6. Stable access to the Internet
  7. Firewall permissions for pulling the cloudflared Docker container or downloading the cloudflared agent
  8. Firewall permissions for reaching Fluid Attacks' Cloudflare network
  9. Firewall permissions for reaching the internal resources Fluid Attacks' will be accessing

Limiting access for the pivot agent

Fluid Attacks uses the pivot agent for accessing your private network.

We recommend creating minimum privilege firewall rules for it in order to only expose those resources that are necessary.

Service limitations

Restricted IP addresses

There are several IP addresses that are reserved by our system and thus cannot be routed through a Connector connection.

Routing within Fluid Attacks' internal network:
DNS resolution within Fluid Attacks' internal network:
Reserved for internal testing:

Please make sure you do not expose such IP addresses to the pivot agent as this may cause service disruptions.

Maximum hosts

In order properly record network and HTTP logs, No more than 1024 hosts can be routed through a Connector connection.

Using self-signed certificates

When using self-signed SSL certificates within your private network, HTTPS traffic going through it will not be inspected, reducing the log detail that can be collected.

This is caused by the fact that the Cloudflare network does not trust certificates signed by non-trusted certificate authorities.

We recommend using SSL certificates signed by a valid certificate authority so navigation logs within the tunnel are fully detailed.


In order to grant Fluid Attacks access to your application resources, you need to:

  1. Fill out the following form in order to provide us with the required details for setting up the Connector connection. Once submitted, in less than 8 office hours you will receive a secret token that you will use in later steps.

  2. Provide a container or a server within your private network that satisfies the minimum requirements. This will be the pivot agent used by Fluid Attacks.

  3. Install cloudflared on the pivot agent.
    Deploy a service using the cloudflared Docker container on your container runtime system (AWS ECS, AWS EKS, Azure AKS, GCP GKE, etc.).
    Windows, Linux & Mac
    Download and install cloudflared on your server.
    Note on installation
    If you intend to share access to several servers within the same private network, you only need to install one pivot agent.

  4. Make sure the pivot agent has firewall egress permissions for the required traffic.
    Note on firewallIf you intend to share access to several servers within the same private network, make sure your firewall rules allow the pivot agent to reach them.

  5. Run the following command using the secret token provided by Fluid Attacks.

cloudflared tunnel --no-autoupdate run --token <SECRET TOKEN>
cloudflared.exe service install <SECRET TOKEN>
Linux & Mac
cloudflared service install <SECRET TOKEN>
Alert on running the commandCaution: Make sure you run this command as a System Administrator. If you're running a Docker container, being root within the container is enough.

Testing your connection

You can test your connection connectivity to make sure everything is working properly.


Below we provide a detailed example of setting up a Connector connection for securely exposing your application's resources.


Let's suppose the following scenario. You want to share access to three different servers within your network:

  1. Your Git repository server
  2. Your application environment server
  3. Your internal DNS server for proper name resolution

The use cases you want to allow are:

  1. Fluid Attacks can clone your Git repository using SSH.
  2. Fluid Attacks can test your application via HTTPS.
  3. Fluid Attacks can resolve your internal domains via DNS.


For this you will:

  1. Fill out the connection form so we can set up a connection for you.
  2. Install cloudflared in any of the servers you want to share. For this example, let's assume you install it on the Git repository server.
  3. Receive a secret token from Fluid Attacks that you will use for setting up the connection.

Firewall rules

Now you should focus on creating firewall rules that allow the use cases presented previously:

For the Git repository server, set the following egress firewall rules:

  • For secure connection
    •  Allow TCP/UDP via port 7844 to
    • Allow TCP/UDP via port 7844 to
    • Allow TCP via port 443 to
    • Allow TCP via port 443 to
  • For internal communication
    • Allow TCP connections via port 443 (HTTPS) to application environment server
    • Allow TCP/UDP connections via port 53 (DNS) to DNS server

For the application environment server, set the following ingress firewall rules:

  • Allow TCP connections via port 443 (HTTPS) from git repository server

For the DNS server, set the following ingress firewall rules:

  • ingress: Allow TCP/UDP connections via port 53 (DNS) from Git repository server

Turning on the connection

Now that cloudflared is installed and the required firewall rules are in place, you can proceed to enable the connection:

As a System Administrator, run the registration command for the connection using the secret token provided by Fluid Attacks.

Testing the connection

Once the connection is on, you can proceed and test it according to the documentation.


Once you have:

  1. A working pivot agent
  2. Minimum privilege firewall rules within your private network

All use cases for this example scenario should be covered.


The authentication mechanisms available for this method are as follows:


Additional support

If you require additional support, do not hesitate to contact us.