VPS: Cloudflare Zero Trust access to Web Applications (20240715)

Service setup: Docker and Dockge

1. Follow the “Docker setup (from docker.io)” section from the “Setting up NVIDIA docker & podman (Ubuntu 24.04)” post (this section provides only the steps to install Docker).

2. Follow the “Setup (with Docker)” section from the “Dockge” post. In the following, we will not install additional stacks, but the tools will enable us to add many should we decide to.

ssh vps -L 4001:127.0.0.1:5001 -N

Cloudflare

DNS Provider setup

• Sign up for a Cloudflare account (if you don't already have one), make sure to set Multi-Factor Authentication.

• Once logged in, add your domain to Cloudflare’s dashboard.
• Cloudflare will attempt to scan your existing DNS records and import them automatically.
• Review these records carefully to ensure all your current DNS settings are accurately captured. It is possible you will need to refer to your original registar to fill in any missing details.

• When all records are ccurrent, update your domain's name servers at your current registrar to point to Cloudflare's nameservers (provided to you by Cloudflare).
• This change can take up to 24 hours to propagate globally (generally it is done in minutes).

• Once the name server change is complete, you will receive a confirmation email and your domain will be active on Cloudflare's DNS.

Additional security recommendations

• select “SSL/TLS” and set the “encryption mode” to “Full (strict)” (or at least “Full”)
• In “Edge Certificates”, make sure “Always Use HTTPS” is enabled

• In “Security” (in order of options)
• for “WAF” select “Custom Rules” and “Create Rule”
• this rule will block anything that Cloudflare considers threatening; we will name it Zero Threat
• “When incoming requests match…” Threat Score ”Field”, greater than ”Operator”, 0 ”value”
• “Then take action …” Block
• select “Deploy”
• for “Bots”
• enable “Bot Fight Mode”
• decide on “Block AI Scrapers and Crawlers”
• Cloudflare enables “DDos” protection by default, so nothing should need to be changed there
• Review Cloudflare’s proposed defaults for “Security”

cloudflared: Cloudflare tunnels

From the moment an application is deployed, developers and IT spend time locking it down — configuring ACLs, rotating IP addresses […] Your origin IP addresses and open ports are exposed and vulnerable to advanced attackers, even when they’re behind your cloud-based security services. […] Cloudflare Tunnel is tunneling software that lets you quickly secure and encrypt application traffic to any type of infrastructure, so you can hide your web server IP addresses, block direct attacks […] The Tunnel daemon creates an encrypted tunnel between your origin web server and Cloudflare’s nearest data center, all without opening any public inbound ports.

“Zero Trust is a security approach built on the assumption that threats are already present within an organization. In a Zero Trust approach, no user, device, or application is automatically trusted — instead, strict identity verification is applied to every request anywhere in a corporate network, even for users and devices already connected to that network. […] Zero Trust only grants access to a specific application and denies access to all other resources by default”

“Zero Trust Web Access (ZTWA), also known as Zero Trust Application Access (ZTAA), provides users with secure access to internal applications using Zero Trust principles. ZTWA authenticates users to applications by integrating with identity providers, encrypting connections, considering each access request for an application individually, and blocking or allowing on a request-by-request basis.”

• Once on our dashboard, select the “Zero Trust” entry on the left side.

• If this is our first time setting it up:

On the onboarding screen, choose a team name. The team name is a unique, internal identifier for your Zero Trust organization […] it will be the subdomain for your App Launcher […] Complete your onboarding by selecting a subscription plan and entering your payment details. If you chose the Zero Trust Free plan, this step is still needed but you will not be charged.

• Configure an identity provider (if preferred); in our setup we will use the One-time PIN login method (free up to 50 users); when end users go the the application’s url (for our setup we will name it dockge.example.com):
• end users will be challenged with an “Access login” page, where they will enter an authorized email address, and select “Send me a code”
• if the email is allowed (and only then), they will receive a One-time PIN at that email, which expires 10 minutes after the request to enter on the challenge page.
• Valid users with valid pins will be allowed access to the web application.

• Connecting the web application is done by using cloudflared which connects an host and port to Cloudflare’s global network.



The steps to follow are:
• from the Zero Trust Dashboard, select “Network -> Tunnels -> Create a Tunnel”.
• select “cloudflared”.
• name the tunnel; here we will name it vps-cloudflared when in general we would name it the same as the host or its ssh alias.
• on the “Install and run a connector” page, we will be prompted with options to download cloudflared. Our VPS host is an x86 Ubuntu 24.04, so we follow the “Debian” “64-bit” instructions which includes that tunnel’s token. This token is a secret, similar to an API key, and should not be shared.
• if your VPS was configured with DNS-over-HTTPS with cloudflared (as in our VPS hardening post), you already have the tool installed and can use the sudo cloudflared service ... entry
• otherwise, the curl ... command line will install and configure the service on the VPS
• Once the connection is established, it will show up in the “Connectors” section.
• The “Route” tab allows us to connect our application; let’s add a “Public Hostname”
• for subdomain, we will use dockge
• for domain, we will use example.com
• we will not provide any path
• service type should match the protocol used by the application, here http
• service url is 127.0.0.1:5001, the service is accessible only on localhost and is running on port 5001
• under “Additional application settings”, we will not alter “HTTP Settings”, “Connection” or “Access”; we will configure the One-time PIN shortly.
• make sure to save
• from the Zero Trust Dashboard, select “Access -> Applications -> Add an Application”.
• select the “Self-hosted” type
• for “Configure application”
• we will use the dockge name
• the duration is the time before the access is challenged again for a given browser session, select an option that matches the expected policy.
• the subdomain, domain and path must match our configured “Route”, so we will use dockge, example.com, and no value
• we will not modify “Tags”, “Block pages” or enable “WARP”.
• Unless you have added alternate ones, the “Identity providers” section should have “One-time PIN”
• on the “Add policies” page, we will configure the users allowed to access the dockge.example.com URL with authorized emails. We note that you can prepare lists of “Access Groups” to add more than one person to that list, but for this setup, we will only add one authorize user.
• name the policy, we will use email
• we will set what the email policy allows for the a “Session duration” of Same as application session timeout
• In the “Create additional rules”, we can add multiple options (please see the zero trust learning path for additional details). We will only “Add include” the email ”Selector” and set an [email protected] ”Value”
• we will not alter the “Additional settings” section, or the values of the “Setup” page
• After adding the application, we will be returned to the “Applications” page where the newly configured tunnel, protected by an access policy, is now active.

Other options for limiting access to a web application

• From “Zero Trust Dashboard → Networks → Tunnels”, we select the “…” at the far right end of the matching tunnel and use “Configure”. We then create a new “Public Hostname” such as “web.example.com”
• Note that if this is not done first, the next step will show “Warning: No DNS record found for this domain. The policy may not execute as expected.”, but it is possible to set the access policy before creating the matching “Public Hostname”

• As before, from “Zero Trust Dashboard → Access → Applications”, select “Add an Application” of type “Self Hosted”. We name it usa access web and match the application to the web subdomain and the example.com domain.

• in the “Add policies” tab, name it “usa only”, and select the Bypass type, then deselect any email option, instead in “Configure rules” “Include” the Country ”Selector” and set its value to Canada

Bypass policies set a path that Access will not protect. You can configure IP or group-based rules, or set the policy to permit all requests with “Everyone”. Bypassed requests will still use HTTPS if it is turned on in the SSL/TLS dashboard. […]

• After completing the “Setup” tab, when trying to access our web.example.com we will be facing a “Forbidden” (403) page since our request is made from the USA.

• to make it work as expected, go back to “Zero Trust Dashboard → Access → Applications”, use the “…” on the right side of “usa access web” to “edit” it. This will show us a list of policies. Select the “…” on the right next to the policy to alter to “Configure” it, modifying it for United States

Revision History

• 20240721-0: Added note about “basic features”

• 20240716-0: Restructured Cloudflare section

• 20240715-0: Added a few recommended security settings when using a domain with Cloudflare.

• 20240713-0: Initial release