Connector

This section provides a comprehensive guide to setting up and using the Connector connection, which enables Fluid Attacks  to securely access your private resources for security testing.

Architecture

This section outlines the architecture of the Connector connection, which relies on Cloudflare . It details how Fluid Attacks utilizes a pivot agent to access your private network and highlights the minimum requirements and limitations of this approach.

High-level architecture

To access your private resources securely, Fluid Attacks employs a “pivot agent.” This agent, installed within your private network on a container or server, acts as an intermediary (running as a service which listens and execute only network queries) and then allowing Fluid Attacks to interact with only the specific (local or internal) private network resources you grant access to.

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

Connector connection infrastructure diagram

Pivot agent minimum requirements

• 1 CPU
• 2 GiB of memory
• At least 5GB of free disk space
• A user with administrative privileges (only to access the server and agent installation from your side)
• Docker, Linux, Windows, or macOS
• Stable access to the Internet
• Firewall rules configuration (as is explained below)

Limiting access for the pivot agent

Fluid Attacks uses the pivot agent for accessing your private network. To enhance security, configure your firewall to grant the pivot agent only the minimum necessary permissions. This ensures that Fluid Attacks can only access the specific resources required for the assessment, limiting potential exposure.

Authentication

The authentication mechanisms  available for this connection are as follows:

Service limitations

Restricted IP addresses

Certain IP addresses are reserved for internal use within the Fluid Attacks system and cannot be routed through the Connector connection:

• Routing within Fluid Attacks’ internal network:
  • 192.168.0.1
• DNS resolution within Fluid Attacks’ internal network:
  • 192.168.0.2
• Reserved for internal testing:
  • 192.168.0.60 - 192.168.0.62
  • 192.168.1.60 - 192.168.1.62
  • 192.168.10.60 - 192.168.10.62
  • 192.168.100.60 - 192.168.100.64
  • 192.168.127.60 - 192.168.127.62

Ensure these IP addresses are not exposed to the pivot agent to prevent service disruptions.

Maximum hosts

In order to properly record network and HTTP logs, a maximum of 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 is not inspected, reducing the log detail that can be collected. This is because the Cloudflare network, on which the connection relies, requires certificates issued by trusted Certificate Authorities (CAs) for full validation and logging. Therefore, it is recommended to use SSL certificates signed by a valid CA so navigation logs within the tunnel are fully detailed.

Installation

Follow these steps to grant Fluid Attacks access to your application resources.

cloudflared-linux-<YOUR ARCH> service install <SECRET TOKEN>

sudo dpkg -i cloudflared-linux-<YOUR ARCH>.deb​
cloudflared service install <SECRET TOKEN>

sudo rpm -i cloudflared-linux-<YOUR ARCH>.rpm
cloudflared service install <SECRET TOKEN>

winget install --id Cloudflare.cloudflared

cloudflared.exe service install <SECRET TOKEN>

.\cloudflared.exe service install <SECRET TOKEN>

docker run -d --name cloudflared cloudflare/cloudflared:latest \
  tunnel --no-autoupdate run --token <SECRET TOKEN>

Test your connection

After establishing the connection, you should verify its functionality accordingly:

• Docker: Review the logs of your container. The specific method for accessing logs will depend on your container runtime environment (e.g., AWS ECS, AWS EKS, Azure AKS, GCP GKE, etc.).
• Windows: Follow the official steps to test connectivity with Powershell .
• Linux and macOS: Follow the official steps to test connectivity with dig .

Example

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

Scenario

Imagine you need to provide Fluid Attacks access to three servers within your private network:

• Your Git repository server
• Your application environment server
• Your internal DNS server for proper name resolution

The use cases you want to allow are the following:

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

Configuration

Follow these steps:

1. Fill out the connection form  so Fluid Attacks can set up a connection for you.
2. Install cloudflared in any of the servers you want to share. For this example, it is assumed you install it on the Git repository server.
3. Receive a secret token from Fluid Attacks 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 region1.v2.argotunnel.com (required)
  • Allow TCP/UDP via port 7844 to region2.v2.argotunnel.com (required)
  • Allow TCP via port 443 to api.cloudflare.com (optional, to query if software updates are available)
  • Allow TCP via port 443 to update.argotunnel.com (optional, to query if software updates are available)
• 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 rule:

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

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

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

Turning on the connection

With cloudflared installed and the required firewall rules 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 as described above.

Frequently asked questions

What is Connector used for?

Connector enables Fluid Attacks to securely access your private resources for security testing while maintaining network isolation and security.

What are the pivot agent minimum system requirements?

• 1 CPU
• 2 GiB of memory
• At least 5GB of free disk space
• A user with administrative privileges
• Docker, Linux, Windows, or macOS
• Stable internet connection

Why are 5GB of free disk space needed for the pivot server?

Although it is not an official requirement, it is highly recommended to have at least 5GB of disk space on the pivot server where the cloudflared agent runs. This capacity allows storing the agent binaries, configuration files, logs, and temporary caches generated during operation. Additionally, the extra space ensures that future software updates can be installed without issues and prevents errors due to insufficient storage. It is important to note that actual disk usage is usually lower and may vary depending on the specific configuration and usage.

Why are “administrative privileges” needed?

Administrative privileges are required exclusively for you to access the server, install the cloudflared agent, and execute related commands. Fluid Attacks does not need these privileges, nor does the cloudflared agent require any special system access or permission to run over the server.

How do you access my resources?

The connection is established through a secure, encrypted tunnel. When the cloudflared agent is run on your server with a unique token, it creates an outbound tunnel to the Cloudflare network. Fluid Attacks connects to your tunnel using the Cloudflare WARP client, which allows it to send network-only requests to the specific resources you have made accessible from the pivot server. This process does not require you to open any inbound ports on your end.

Will you be able to access any resource on my network?

No. Access is strictly limited to the resources you specify. The cloudflared tunnel only allows Fluid Attacks to reach resources that are accessible from the pivot server and that you have explicitly configured to be exposed. Additionally, you must provide a list of these resources (routes, domains, and/or internal DNS) through the corresponding web form. This ensures Fluid Attacks does not access any other resources on your internal network, even if the pivot server has access to them.

Can I allow or restrict access to my network at any time?

Yes. You can modify the permissions, firewall rules, or network architecture that controls access from Fluid Attacks to your resources at any time. However, you must also notify Fluid Attacks of these changes so we can update the corresponding tunnel configuration. You can do this through your assigned Fluid’s Engagement Manager or by sending a ticket to help@fluidattacks.com.

How is the installation token generated and is it secure?

When a tunnel is created by Fluid Attacks, an installation token is generated, which authorizes the cloudflared agent to install on the host (pivot server) and associate that host with the created tunnel. The token has 181 characters and is a secret value, randomly generated by Cloudflare, ensuring that each token is unique for each tunnel and difficult to guess. Its structure is similar to a base-64 JWT, although it does not strictly follow the standard JWT format.

Does the token expire, and can it be reused?

The installation token does not expire and is not automatically regenerated. It can be used indefinitely to install the service on any host where the agent will be installed while the tunnel exists. Once the installation is complete and the agent is running as a service, the token is no longer required. It will only be needed again if the agent needs to be reinstalled on the same or another host/server.

How is the installation token provided to me?

It is usually the Engagement Manager at Fluid Attacks who gives you the token privately, if you are going to perform the installation yourself. If you require live guidance during the installation, Fluid Attacks gives you the token at the time of executing the process.

Is there a risk of interception of the installation token?

The token is never transmitted through the tunnel. It is only used locally on the pivot server during the installation of the service. Once installed, the agent establishes a direct and secure connection with Cloudflare’s servers, without needing to re-verify the token at either end. Therefore, there is no risk of the token being intercepted during tunnel operation.

How do I know if my firewall rules are correctly configured?

Before proceeding with the installation, ensure the following:

• Your firewall allows pulling the cloudflared Docker container or downloading the cloudflared agent.
• Your firewall allows connections to Fluid Attacks’ Cloudflare network (for more information, refer to the official documentation on testing connectivity ).
• Your firewall permits access to the internal resources Fluid Attacks will be assessing.

Is it necessary to configure all specified firewall rules?

No. Only the firewall outbound rules to IPs or domain destinations specified here , over port 7844 (TCP and UDP) are required to ensure connection via Cloudflare tunnel. Rules related to port 443 (TCP and UDP) are optional  (used for some additional features, like download and update cloudflared binaries). And rules related to Region US  are not usually required; then, you can ignore them.

When should I configure firewall rules using domains or IPs?

You should use Cloudflare domains if your firewall supports filtering based on FQDN (Fully Qualified Domain Name) and/or enforce SNI (Server Name Indication). If your firewall does not support or enforce these functions, you will have to configure each of the IP addresses specified by Cloudflare instead.

What happens if firewall rules are not configured correctly?

If the required firewall rules  are not properly configured, the connection will fail, preventing Fluid Attacks from accessing your resources (tunnel connectivity could be in either Inactive or Down state). Additionally, if UDP (quic ) traffic is blocked or discarded, domain name resolution may fail, causing further disruptions in connectivity or difficulties to fetch and analyze your resources (mainly, in case of automatic cloning or testing).

What if my network uses a proxy behind the firewall?

If your network infrastructure uses a proxy to control outbound traffic, firewall rules must be configured on both the firewall and the proxy. It is crucial that both allow outbound traffic to the domains, IP addresses, ports, and protocols specified by Cloudflare.

What to do with the Connector after the service ends?

To terminate the connection, simply follow the instructions for uninstalling the cloudflared agent, specified below. You can also delete any binaries, executables, or container images related to cloudflared that you downloaded and, if you wish, take the server completely offline.

How do I check if cloudflared is correctly installed?

You can check the status of the service by running the following:

systemctl status cloudflared

sc query cloudflared
Get-Service cloudflared

docker ps | grep cloudflared
docker ps | findstr cloudflared

How can I obtain logs from the cloudflared service?

You can obtain real-time logs by executing the following:

journalctl -u cloudflared -f

Get-WinEvent -LogName Application -ProviderName cloudflared -MaxEvents 30 -Wait

docker logs -f cloudflared

How do I start the cloudflared service if needed?

You can start the service (if it was previously stopped) by executing the following:

systemctl start cloudflared

sc start cloudflared
Start-Service cloudflared

docker start cloudflared

How do I stop the cloudflared service if needed?

You can stop the service by running the following:

systemctl stop cloudflared

sc stop cloudflared
Stop-Service cloudflared

docker stop cloudflared

How do I restart the cloudflared service if needed?

You can restart the service by executing the following:

systemctl restart cloudflared

sc restart cloudflared
Restart-Service cloudflared

docker restart cloudflared

How do I uninstall the cloudflared service?

To uninstall the service, run the following:

cloudflared service uninstall

cloudflared service uninstall

.\cloudflared service uninstall

sc delete cloudflared
Remove-Service cloudflared

docker stop cloudflared
docker rm cloudflared

docker rmi cloudflare/cloudflared:latest

Troubleshooting

Follow these steps to diagnose and resolve common issues with the cloudflared agent. The suggested order moves from basic checks to more advanced diagnostics.

Check server requirements

Make sure the server meets the minimum system requirements to run the agent.

Verify internal network connectivity

Confirm that the pivot server can reach the internal resources it needs to connect to. This helps rule out accessibility issues, such as resources that are unavailable or misconfigured internal firewall rules.

• Ensure the resource is active, available, and hasn’t changed its network location.
• From the pivot server, try to access the resource using network commands (like telnet, netcat, nslookup, dig, curl, ping, etc.) to diagnose connectivity and DNS resolution.
• If possible, check your firewall logs to verify if traffic to the resource is being allowed.
• Confirm with us that the resource has been added to the tunnel configuration on our end. If not, request for us to add it.

Confirm external network connectivity

Validate that outbound traffic from your server to the Cloudflare tunnel is not blocked. This is crucial for the tunnel to establish and for traffic to flow smoothly.

• Make sure your firewall (and proxy) rules allow outbound traffic to Cloudflare’s domains and IPs on port 7844 (both TCP and UDP).
• Perform the connectivity tests to the Cloudflare tunnel mentioned in the connectivity test  documentation to confirm outbound TCP traffic.
• If possible, check your firewall logs to validate outbound connectivity to Cloudflare’s IPs and domains.

Check agent execution status

• Ensure the agent is active and running, executing the appropriate command.
• Try to obtain and check execution logs from the cloudflared service.

Rule out cloudflared agent version issues

An outdated or corrupted version usually can cause failures, such as tunnel malfunctioning or failed execution of cloudflared agent.

• Uninstall the cloudflared agent and delete the obsolete binary, executable, or container from your server’s storage.
• Download and reinstall the latest version (if needed, request the installation secret token).
• Verify the agent’s execution status.

Run and test a tunnel connection manually

If either the cloudflared service or the tunnel are not working, run the agent manually to get a clearer diagnosis.

• Stop the cloudflared service.

• Run a temporary connection with the following command (if needed, request the installation secret token):

  cloudflared tunnel --no-autoupdate run --token <SECRET TOKEN>

• Review the execution terminal logs for any error messages.

• You can stop the temporary execution by aborting the command or closing the terminal in any moment, and then, restart the cloudflared service if necessary.

Rule out secret token issues

In some cases, the agent may fail because the secret token is no longer valid.

• If needed, request Fluid Attacks to generate and provide you with a new token.
• Stop the cloudflared service.
• Rerun the cloudflared installation command with the new token.
• Validate the service status after execution.

Check intermediate network devices

If the problem persists, your network devices (firewall, proxy, etc.) might be blocking or not supporting the quic protocol.

• Ensure again that required outbound firewall rules towards the Cloudflare tunnel (over port 7844, UDP protocol) are configured and enabled on your network devices.
• Try configuring both the domains and the IPs in your outbound firewall rules at the same time.
• If that doesn’t resolve the issue, try configuring only the IP-based rules (even if your devices can handle domain-based rules).
• Confirm that your network devices support quic protocol.
• Finally, consider updating their firmware or configuring them to allow this protocol, if possible.

Support

If you require assistance with the Connector setup, send Fluid Attacks an email at help@fluidattacks.com.