This section reviews the Connector connection used by Fluid Attacks to access the private resources required to provide our service.
Architecture
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.
Pivot agent minimum 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 access to the Internet
- Firewall permissions for pulling the cloudflared Docker container or downloading the cloudflared agent
- Firewall permissions for reaching Fluid Attacks' Cloudflare network
- 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:
- 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.1.60
- 192.168.10.60
- 192.168.100.60
- 192.168.100.61
- 192.168.100.62
- 192.168.100.63
- 192.168.100.64
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.
Installation
In order to grant Fluid Attacks access to your application resources, you need to:
-
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.
-
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.
-
Install cloudflared on the pivot agent.
Docker
If you intend to share access to several servers within the same private network, you only need to install one pivot agent.
-
Make sure the pivot agent has firewall egress permissions for the required traffic.
If 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.
-
Run the following command using the secret token provided by Fluid Attacks.
Docker
cloudflared tunnel --no-autoupdate run --token <SECRET TOKEN>
Windows
cloudflared.exe service install <SECRET TOKEN>
Linux & Mac
cloudflared service install <SECRET TOKEN>
Caution: 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.
Example
Below we provide a detailed example of setting up a Connector connection for securely exposing your application's resources.
Scenario
Let's suppose the following scenario. You want to share access to three different servers within your 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:
- 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
For this you will:
- Fill out the connection form so we can set up a connection for you.
- 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.
- 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 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.
Conclusions
Once you have:
- A working pivot agent
- Minimum privilege firewall rules within your private network
All use cases for this example scenario should be covered.
Authentication
The authentication mechanisms available for this method are as follows:
Additional support
If you require additional support, do not hesitate to contact us.