Cloudflare Zero Trust Admin

Summary

This article describes an alternative method to access the CAS administration web interface for CAS users via the Cloudflare “Zero Trust” tunnel: “cloudflared”.

Technical explanation

Cloudflare offers (amongst it's rich services) a tunnel daemon that can expose your port to your company while hiding your CAS server IP and protecting your system. The cloudflared daemon is used for this purpose. The recommended procedure for accessing the Admin interface is still via VPN, however the Cloudflare Zero Trust tunnel provides a more user-friendly alternative with sufficient security.

This tunnel is useful for exposing the Administration service - without a VPN. It further restricts access to specific emails and geographies - reducing the threats from foreign actors.

The tunnel requires your DNS to be hosted by Cloudflare.

The essential idea is that the CAS Admin service can thus be mapped to a subdomain on your website while utilizing the Cloudflare DNS to hide your server IP.

• The DNS entry should be a little obscure to minimize your visibility to threat actors.

• The tunnel will enjoy the same HTTPS certification of your website.

• The tunnel can be used without without altering the integrated VPN settings.

You must have a Cloudflare account (free) and use their DNS services (not free) to employ this option.

Overview:

Create your Cloudflare tunnel

Navigate to: https://one.dash.cloudflare.com/

1. Create a tunnel.

Open

2. Enter a descriptive name:

Open

3. Save it.

4. Select your Operating System (debian) and architecture (64-bit):

5. Execute the installation command on your CAS HOST:

• Paste it into your SSH window on your CAS system, and

• press Enter.

6. Enter the tunnel endpoints.

• All tunnel configuration is performed at this web page (no configuration at the CAS server).

• the Subdomain will be used in your browser, i.e. the “admin” in: https://admin.yourcasdomain.com

• Choose your Domain (it should already be listed in the dropdown box).

• Type must be HTTPS.

• The URL for the CAS admin is the same as “Admin IP” as shown by batm-manage info: e.g. 10.3.2.2:7777

Open/expand “Additional application settings” towards the bottom:

• Click on “TLS”, and

• enable the option “No TLS Verify”.

7. Finally:

• Save it (click “Save tunnel” in the bottom right corner).

The tunnel will now be active and should be “live”, exposing the admin service from CAS to your subdomain. You’ll be able to access in your browser using https://admin.yourcasdomain.com (replace “yourcasdomain.com” with your actual CAS domain).

It is not protected from threat actors though, and you’re not quite done yet. You’ll need to restrict access to the page by changing one more tunnel setting, and configuring Google access.

Restrict access via Cloudflare

You need to setup some authorization rules in a new Cloudflare “application”. These rules will determine who is permitted access to the newly shared subdomain.

Navigate to: https://one.dash.cloudflare.com/

Open “Access”, then “Applications”:

Create a new “Application”:

• Choose “Self-hosted”

Fill in the details:

• The Application name will be displayed on the login page, and is not critical.

• Session Duration is the time before re-authorization is required. When the authorization expires, the user attempting to access your domain will have to either enter a new PIN, or login to Google (again).

• Subdomain should be the same as what you entered in Step 6 of tunnel creation.

• Domain is one of the Cloudflare-handled domains you have registered with them.

Scroll down, click NEXT.

Create an “Allow” Policy

• Name the policy something meaningful for authorizing CAS access, e.g. “CAS Access”.

• Action: “Allow” enables only people that pass the “included” rules to be permitted access.

Next, add “Include” rules to the new policy. All rules will “allow” access:

• This example “Include rule” will allow access to anyone with a generalbytes.com email.

• The rules are tricky. Keep it simple to get it working now, then play with the settings later. Add yourself (or your email domain if you have one) as the single rule and move on to the next step.

Scroll down, click NEXT. Skip the next page.

Scroll down, click Add application.

Finished:

Now you’ve restricted access to the subdomain to only the people that pass the “Include rules”.

• To test the rules, navigate back to your Application policy and “Test your policies”.

Currently, Cloudflare will now offer this screen to every user attempting to access your domain:

• Only people you’ve added to the “Include rules” will receive a PIN.

• Next, you can (optionally) configure Google to automate more of this process.

Automating access via Google

Google can authenticate users for you, and forward the authenticated info to Cloudflare for comparison against your rules. Currently (as configured above), Cloudflare will send a PIN to the email (if they’re on the Allow list) which is requesting access, and after entering the PIN - the user will be permitted to access the subdomain . If the user has a Google-managed email, then they can skip a step (if not - they’re stuck using a PIN).

You can enable a user’s Google login to authenticate them, and enable access automatically. Here’s how.

1. Navigate to the Google Cloud Platform credentials page at: https://console.developers.google.com/apis/credentials

2. Create a new Google Cloud project: click Create Project then New Project.

3. Name your Cloud Project, then click Create.

4. On the project home page, go to APIs & Services on the sidebar and select Dashboard.

5. On the sidebar, go to Credentials and select Configure Consent Screen at the top of the page.

6. Choose External as the User Type (any user with a Gmail address can login).

7. Name the application, add a support email, and input contact fields. Only enter required details!

   1. Google Cloud Platform requires an email in your account.

   2. In the Scopes section, we recommend adding the userinfo.email scope.

   3. You do not need to add test users.

   4. Do not upload a logo, or Google will require review & verification.

   5. Save your changes.

8. Return to the APIs & Services page, select Create Credentials > OAuth client ID, and name the application (e.g. “CAS Admin”).

   1. Select “Web Application”.

   2. Under Authorized JavaScript origins, in the URIs field, enter your team domain:

      1. https://<your-team-name>

      2. <your-team-name> is found in Zero Trust: Settings: Custom Pages: Team domain

      3. example: https://yourcasdomain.cloudflareaccess.com

   3. Under Authorized redirect URIs, in the URIs field, enter the following URL:

      1. https://<your-team-name>/cdn-cgi/access/callback

      2. <your-team-name> is found in Zero Trust: Settings: Custom Pages: Team domain

      3. example: https://yourcasdomain.cloudflareaccess.com/cdn-cgi/access/callback

   4. Save your changes.

9. Google will present the OAuth Client ID and Secret values.

   1. The secret field functions like a password and should not be shared.

   2. Copy both values. You’ll need them next on the Cloudflare API page.

   3. You’re done at Google.

10. In Cloudflare Zero Trust, go to Settings > Authentication.

11. Under Login methods, select Add new. Choose Google on the next page.

12. Input the Client ID and Client Secret fields generated in Step 9.

13. (Optional) Enable Proof of Key Exchange (PKCE). PKCE will be performed on all login attempts.

14. Select Save.

Done.

Now, when you access the subdomain, you should also be offered a Google login (instead of just a PIN):

Troubleshooting

You may start the Cloudflared daemon in the foreground to watch live activity.

1. Stop the daemon: sudo systemctl stop cloudflared

2. Start it manually:

Logs

• Cloudflare documentation regarding logs.

• Working directory for the daemon using this article: /usr/local/etc/cloudflared

The default daemon behavior is to log to the system journal. To view the cloudflared entries:

Change the YAML file to modify the defaults, located at: /usr/local/etc/cloudflared/config.yml

For performance reasons, logging is disabled by default, but to turn it on for diagnostic reasons:

1. Open the config file: nano /usr/local/etc/cloudflared/config.yml

2. Add these lines (and save + exit):

   1. logfile: /var/log/cloudflared/cftunnel.log

   2. loglevel: debug

3. Restart the tunnel:

   1. sudo systemctl restart cloudflared

4. Watch the logging in real time:

   1. tail -f /var/log/cloudflared/cftunnel.log