Jump to content
allitsolutions

Locking down Automate and Control to CloudFlare

Recommended Posts

Posted (edited)

Hey All!

 

I can’t take any credit for this work (or at least the ideas behind it)! A good mate of mine recently wrote this article. It is a step-by-step on securing his N-Central environment with a free CloudFlare account.

As MSPs, we're always striving to lower the chances of getting hacked by implementing as many humps in the road as possible for any potential hacker. As we all know, we’re potentially only one hack away from going under.

 

My scenario:

  • The Control instance is sitting on the Automate server at https://domain.com/remotesupport.
  • We’re not using heartbeat.
  • Only ports we’re passing via CloudFlare is 443.
  • All Agent communication, Automate GUI and Control GUI will run via CloudFlare
  • Relay ports will stay as is and will continue to pass directly from client to server’s WAN IP/hostname.
  • We’re using Azure AD authentication for CloudFlare Access purposes.

Note that some of the URLs in the allow list may be different to yours based on authentication types or possibly a host of other reasons.

 

We have also implemented CloudFlare Access. This is a great function that adds another level of security via authentication, but possibly more importantly, a level of obscurity. If you are not familiar with CloudFlare’s Access feature, based on the rules you set, it will throw an authentication prompt (from an identity provider of your choice) before you reach your login page. This way, someone trying to exploit your login page, can’t get to it without passing your identity provider’s challenge first. After you have satisfied this, you can then proceed to login with your credentials for that webpage.

 

Here’s what we’ve done

  1. Register a weird domain that has nothing to do with ‘what we do’ – like ffxxsd.xxx. Make sure you hide all your registration information so a whois won’t return anything meaningful.
  2. Sign up for a free CloudFlare plan and add this domain to it.
  3. Change the name servers to CloudFlare’s.
  4. Create the following DNS entries:
    1. Root DNS A record to point to the WAN IP of your Automate/Control server.
  5. Go to SSL/TLS tab > Edge Certifications tab
    1. Always use HTTPS – ON
    2. Set Minimum TLS version to 1.2
    3. TLS 1.3 – ON
  6. Start creating some rules
    1. Go to Firewall tab > Firewall Rules tab. I’ve added the Expressions so you can copy/paste. Create the following rules in the following order:
      1. Block all traffic outside of US. Then BLOCK.
        1. (ip.geoip.country ne "US")

           

      2. Block Bots = On. Then BLOCK.

        1. (cf.client.bot)

           

      3.  Agent Traffic. Then ALLOW.

        1. (lower(http.user_agent) contains "labtech agent") and (lower(http.request.uri.path) eq "/labtech/agent.aspx") or (lower(http.request.uri.path) contains "/labtech") or (lower(http.request.uri.path) contains "/labtech/agent.aspx") or (lower(http.request.uri.path) contains "/labtech/deployment.aspx") and (lower(http.user_agent) contains "labech agent") or (lower(http.request.uri.path) contains "/wcc2") or (lower(http.request.uri.path) contains "/automate")

           

      4. Technician Logins. Then ALLOW.

        1. (lower(http.request.uri.path) contains "/") or (lower(http.request.full_uri) contains "/remotesupport") or (lower(http.request.uri.path) contains "/favicon.ico") or (lower(http.request.uri.path) contains "/wcc2/api/") or (lower(http.request.uri.path) contains "/cwa/api/v1/") or (lower(http.request.uri.path) contains "/labtech/controlcenter.asmx") or (lower(http.request.uri.path) contains "/cdn-cgi/access/authorized") or (lower(http.request.uri.path) eq "/.well-known/http-opportunistic")

           

      5.  Catchall. Then BLOCK.

        1. (http.cookie ne "ertjherherherh")

           

 

So, by doing the above, you are creating a rule to:

  1. Enable geo-blocking. Of course, you’ll want to open this up if you have clients in other countries.
  2. block bots from crawling your website.
  3. ONLY allow traffic to the specified paths required by the Automate agent.
  4. ONLY allow traffic to the required webpages (login pages, Automate console login, Control login page etc.)
  5. Block everything that’s not a cookie equaling “ertjherherherh”. This should capture most (if not all) other traffic so you can see what’s getting caught. Based on that, you can then modify the above rules to allow the relevant traffic through.

 

CloudFlare Access

Now, we need to lock down the login pages with CloudFlare’s Access.

  1. Go to the Access button along the top.
  2. Click Add + under the Login Methods section
  3. Choose your identity provider of choice (we’re using AzureAD)
  4. Follow the prompts to add it.
  5. Turn Instant Auth On if you’re only got one provider.

When you click Test at the end, it should show you a new tab that shows all your Azure Groups and their GUIDs. Make note of the ones you want to use as you will need to assign them to Access Policies (below) – CloudFlare doesn’t search group names believe it or not.

 

You now need to create the access polices. Some traffic needs to be bypassed as agents cannot respond to an AzureAD authentication prompt. We also need other policies to specify the pages we want protected by Access.

Agent Traffic

  1. Click Create Access Policy
    1. Application Name: Agent Traffic
    2. Application Domain: ffxxsd.xxx/LabTech/agent.aspx
  2. Policy Name: Agent Traffic Policy
    1. Decision: Bypass
    2. Include: Everyone : Everyone
  3. Save

Automate Login Page

  1. Click Create Access Policy
    1. Application Name: Automate Login Page
    2. Application Domain: ffxxsd.xxx/automate/login
  2. Policy Name: Agent Traffic Policy
    1. Decision: Allow
    2. Include: Azure Groups : groupGUID
  3. Save

 

Automate Main Page

  1. Click Create Access Policy
    1. Application Name: Automate Main Page
    2. Application Domain: ffxxsd.xxx/WCC2/Home/Login
  2. Policy Name: Automate main page policy
    1. Decision: Allow
    2. Include: Azure Groups : groupGUID
  3. Save

Control Main Page

  1. Click Create Access Policy
    1. Application Name: Control Main Page
    2. Application Domain: ffxxsd.xxx/RemoteSupport
  2. Policy Name: Control Main Page Login Policy
    1. Decision: Allow
    2. Include: Azure Groups : groupGUID
  3. Save

 

I'm just in the process now with CloudFlare trying to figure out how to make the Automate Login Page truly Access protected. If you navigate directly to that page, it's protected, but if you go to ffxxsd.xxx/automate and it redirects to ffxxsd.xxx/automate/login , it's not. I'll edit back once I have a solution.

 

Now that you’ve done all the background work, we need to start testing agents. Install an agent on a machine close by and apply a new Automate template to it where the server address is https://ffxxsd.xxx. You should start to see a small amount of traffic appearing in the CloudFlare firewall rule for Agent Traffic. If not, it will most likely appear in the Catchall. If that’s the case, you need to look at the traffic and add it to the Agent Traffic Firewall Rule.

Once you push the new server address to all the agents, then you may want to consider locking down your router’s firewall. Using CloudFlare’s IP addresses, you will want to nail your firewall down to only allow port 443 incoming from their IPs.

 

To be able to see who’s still got the old address in their template, I’ve created an Advanced Search that says:

[Computer.CurrentConfig.ServerAddress] Equals *OldServerAddress*

I’ve then created a new Group under the Automation tab and under Autojoin Searches/Computers, I’ve chosen the above saved search so that I can simply check on the group to work out who still hasn’t applied the new template.

 

I was going to talk about the Control part; however, you may simply like to leave your existing ports/hostnames/DNS entries the same for the relay as changing it is a real bastard of a thing and there probably isn’t any real gain by doing so.  

 

Let me know how you guys go and any improvements you make!

 

Edited by allitsolutions
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

Great post. Few questions:

- Does this affect integration with Manage?
- What if clients are using automate web portal (main page) to access their PCs?
- Where did you find all Agent traffic and Tech logins traffic URLs for Automate. ConnectWise document or?
 

Edited by Sasa
typo

Share this post


Link to post
Share on other sites
4 hours ago, Sasa said:

Great post. Few questions:

- Does this affect integration with Manage?
- What if clients are using automate web portal (main page) to access their PCs?
- Where did you find all Agent traffic and Tech logins traffic URLs for Automate. ConnectWise document or?
 

- Good question. We actually haven't locked our old external URL yet as we're still waiting for some units to come online and grab the new template. 

- I'm assuming you're asking if their traffic will be blocked or not? Well you wouldn't be able to put Access on that page as it will throw an Authentication prompt.

- Assume you don't use Access for the above, you then just need to go to Firewall > Firewall Rules then Click on the traffic graph next to the Catchall rule. This will then show you all the traffic that's been blocked. You'll see subpages that will get caught up in there. So you got to log in, and check to see all the things it's calling to know what to allow.

 

Hope that helps. 

  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...