CloudFlare, the popular security services provider, probably isn’t a good choice for your MSP tools. Here at Automation Theory, we’ve seen the whole spectrum of security options for MSP tools. While their services are easy to use, several things lacking in the CloudFlare offering make it a poor fit for MSP tool security.
History
CloudFlare gained popularity for self-hosted MSP tools after a Reddit thread in /r/msp described how one MSP used the service to secure an N-Central RMM instance. Subsequent forum threads were started for other MSP tools, and adoption grew over time. Mentions of CloudFlare for use with MSP tools increased after security incidents (like the Kaseya VSA attacks or the ScreenConnect CVSS 10 vulnerability).
Both of the original posts were written by MSP techs who were trying to secure their MSPs from zero-day attacks. Their efforts are commendable, but certain issues with the CloudFlare service make it ill-suited for securing MSP tools.
Reason 1: CloudFlare doesn’t harden HTTP headers
HTTP headers are extra pieces of data included with an HTTP request, containing information about the content, source/destination, browser handling instructions, etc. There are a number of HTTP headers used for security configuration – and a number of MSP tools are missing them. As a result, any security solution should address these.
Using the free tier of CloudFlare with the default settings (like the popular guides did), we proxied a ConnectWise Automate instance and ran a series of benchmarks on it. The screenshot below is the output from the HTTP header test:
The test fails miserably – which is actually an Automate issue (which is why it should really be proxied). However, we can see that CloudFlare does nothing on this front, which is a significant concern for hardening MSP tools.
Reason 2: CloudFlare doesn’t harden TLS
It’s common knowledge in IT security that TLS 1.2 should be the minimum version used. TLS versions 1.0 and 1.1 have known cryptographic weaknesses and have been considered insecure since 2011. However, our SSL Labs test revealed that CloudFlare (by default) was listening on these protocols:
The community guides for CloudFlare call out hardening TLS, but we’ve found this step is often missed. The default support for this protocol is interesting, as RFC 9325 details recommendations for secure use of SSL/TLS protocols, and section 3.1.1 says the following:
Implementations MUST NOT negotiate TLS version 1.0 [RFC2246].
RFC 9325
Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per-record Initialization Vector (IV) for cipher suites based on cipher block chaining (CBC) and does not warn against common padding errors. This and other recommendations in this section are in line with [RFC8996].
The use of the old protocols is likely a compatibility choice made by CloudFlare, since it’s meant as a general website security platform (more on that below). However, many MSP tools are currently listening on TLS 1.2 only, making the default CloudFlare deployment a step backward cryptographically for them (not to mention a likely issue for MSP insurance policies).
Reason 3: The WAF does almost nothing
A WAF is supposed to watch for and block SQL injection, Cross-Site Scripting, and other common web application attacks. However, our testing left us shocked at the ineffectiveness of this so-called “WAF:”
Looking at the documentation, the WAF included with the free tier of CloudFlare is not a traditional WAF (using rules to inspect web requests for various code-syntax patterns) but rather a selective WAF only designed for “high severity” threats. This might be sufficient for a general-purpose website, but it is woefully inadequate to secure MSP tools.
According to our test suite, only 3 of the 846 malicious requests sent were blocked (although the CloudFlare logs only show 2 blocks). We ran the test a second time just to make sure it wasn’t a fluke.
MSPs need to defend themselves against nation-state actors. Often, these threat actors have more money and resources than the average MSP, so every technical advantage is critical. A WAF that can’t block a blatantly obvious Cross-Site Scripting attack isn’t going to do anyone any good in this defensive scenario:
There’s one other problem with the CloudFlare WAF, which is best discussed on its own…
Reason 4: CloudFlare isn’t designed for MSP tools
CloudFlare is designed to protect traditional websites – not complex application stacks commonly found in the MSP industry. This is both a problem of product fit and of support.
Most RMM tools are multi-protocol, mixing both HTTP and non-HTTP traffic. You’d need the enterprise package from CloudFlare to properly proxy a typical RMM – if you can get through the sales process (we have a client who explored such a package, only to have a CloudFlare sales engineer insist that since ScreenConnect was running on port 8040, it couldn’t be a web application needing WAF…).
Remember how the free WAF only protects against “high severity and widespread” threats?
Unfortunately for MSPs, neither the ScreenConnect CVSS 10 vulnerability in February of 2024 nor the Kaseya VSA attack from July of 2021 made it into the WAF rules for the free tier WAF. Inside the MSP industry these were indisputably high severity and widespread events – but it just shows that CloudFlare isn’t designed for the MSP use case.
Alternatives to CloudFlare for MSPs
So, what should an MSP do? Securing self-hosted tools is undoubtedly important, but MSPs obviously need something better than CloudFlare.
Here at Automation Theory, we offer a Reverse Proxy and WAF service that is designed for MSP tools, complete with HTTP hardening, strong TLS enforcement, and an effective WAF:
Our service deployment is designed to be turn-key for MSP tools, and our team guides you through the implementation process. You can find more details about our offering here.
