Blocking The Use of CloudFlare Tunnels

I have sparked a lot of interest with the home lab and tech community about the use of CloudFlare Tunnels and CloudFlare Access. These offerings have a great potential for people like me and others as well as legitimate use for enterprises. That being said, I put on my “what if” hat and decided to think about this from the other side. Can these be used for nefarious acts by an insider? The answer is a resounding YES! In fact there are a few things that can allow this to happen which I will cover here in this very short post.

The Nefarious Use of CloudFlare Tunnels

The articles I posted show not only how beneficial these can be, but also how EASY this is to setup. Let’s take a look at this from another angle. Let’s suppose an internal user has the following two very basic things setup to create a connection.

• A Free CloudFlare Account
• Admin Rights to a local machine on the Corporate network

This is all that is needed to setup a tunnel, and install the tunnel daemon. Once that is setup they can setup external hostnames, tunnel SSH and RDP back to any number of machines, or use them as a jump off point to possibly exfiltrate data, and all the while you may have no idea. They can also setup Warp Zero Trust to access multiple private networks. Now it does seem that CloudFlare has taken this into account and I will explain how you can prevent this from happening.

CloudFlare Tunnel Endpoints

CloudFlare has done a good job of documenting the endpoints that these connectors seem to use to call home in their Zero Trust Documentation. What you can see is these are the key FQDN’s in use and their ports

You can also see here in my own NextDNS Firewall after I restarted a connector container it immediately calls home to three of these.

If you examine the hostnames with NSLOOKUP or DIG, you will get all the associated IP addresses as well and you should see some of them in your firewall logs too. For this I was starting only by focussing on DNS, but that is not the end all be all as you can start to see.

;region1.v2.argotunnel.com.     IN      A
;; ANSWER SECTION:
region1.v2.argotunnel.com. 5    IN      A       198.41.192.167
region1.v2.argotunnel.com. 5    IN      A       198.41.192.27
region1.v2.argotunnel.com. 5    IN      A       198.41.192.67
region1.v2.argotunnel.com. 5    IN      A       198.41.192.227
region1.v2.argotunnel.com. 5    IN      A       198.41.192.77
region1.v2.argotunnel.com. 5    IN      A       198.41.192.37
region1.v2.argotunnel.com. 5    IN      A       198.41.192.47
region1.v2.argotunnel.com. 5    IN      A       198.41.192.107
region1.v2.argotunnel.com. 5    IN      A       198.41.192.7
region1.v2.argotunnel.com. 5    IN      A       198.41.192.57

;region2.v2.argotunnel.com.     IN      A
;; ANSWER SECTION:
region2.v2.argotunnel.com. 5    IN      A       198.41.200.63
region2.v2.argotunnel.com. 5    IN      A       198.41.200.53
region2.v2.argotunnel.com. 5    IN      A       198.41.200.233
region2.v2.argotunnel.com. 5    IN      A       198.41.200.73
region2.v2.argotunnel.com. 5    IN      A       198.41.200.113
region2.v2.argotunnel.com. 5    IN      A       198.41.200.23
region2.v2.argotunnel.com. 5    IN      A       198.41.200.33
region2.v2.argotunnel.com. 5    IN      A       198.41.200.193
region2.v2.argotunnel.com. 5    IN      A       198.41.200.13
region2.v2.argotunnel.com. 5    IN      A       198.41.200.43

;update.argotunnel.com.         IN      A
;; ANSWER SECTION:
update.argotunnel.com.  5       IN      A       104.18.25.129
update.argotunnel.com.  5       IN      A       104.18.24.129

;api.cloudflare.com.            IN      A
;; ANSWER SECTION:
api.cloudflare.com.     5       IN      A       104.19.192.29
api.cloudflare.com.     5       IN      A       104.19.193.29

Blocking CloudFlare Tunnel Creation

From the information above the obvious starting point is to block these based on the hostname. I did this as a test with NextDNS and it works as expected when the connector container is restarted. it is blocked and cannot connect.

This is the fastest way to do this. or poison your DNS for these entries entirely. Now that will only work for so long because if the suspected user has admin rights to install the connector they can just work around this with a host file. In addition to this, you can add destination IP blocks in your edge firewall on top of this to ensure the real endpoints are not reachable. That will work as long as these are not changed or updated. Also you can see that port 7844 is in use so you can add a rule for that independent of the destinations for outbound traffic. Lastly you could add cloudflared services to your machine scans to see if the service it running or available and REMOVE it completely. There may be ways to even prevent it from being installed again, but if someone has admin rights that may be a constant battle.

To summarize your possible options to prevent these tunnels are:

• Block via DNS (weak and worked around with host files)
• Block via Destination IPs (better but could change)
• Block via outgoing port 7844
• Scan systems for cloudflared services, and remove
• Limit Admin Rights on systems (Obviously)

Also I had not found a way to break an already established connection. I could not tell if these retry on a regular basis. In fact I saw that until I rebooted one it came up a couple days ago and never called home again until the reboot. I am sure some firewalls can sever existing connections but frankly I am not sure if my UDM Pro can do that.

Consider Blocking Access to CloudFlare Tunnels

Depending on your use case, especially in a corporate data center network, blocking these connectors from calling home might be appropriate. Also with the given information and proper logging you should also be able to tell if anyone has already set these up without you knowing it and how long they have been up. The other unanswered question is even if you block these are find ones running I would venture to guess that the CloudFlare Privacy policy won’t be something easily bypassed to find out the account owner of the connector’s tunnel. While the information on the connector ID is on the account, I have no idea if they would give this up without proper legal processes.

Sadly while I do love this technology, like everything used for good it can also be exploited by someone who already has the appropriate access on a system to install the connector. Consider looking for this traffic now and if you do not have a legitimate use for these lock down the ports and destination IP’s. If you do have legitimate uses, that isolated the rules to only allow the known connector sources to call home. This should not be too hard to manage, but I felt after discovering this, it was worth pointing out.