Reverse Proxy and WAF for MSP Tools

Zero-day attacks on MSP tools are the things nightmares are made of. A robust reverse proxy and WAF solution implements a variety of controls to add multiple layers of protection against zero-day attacks.

Our solution not only protects against enumeration to prevent attacks — our WAF engine offers protection against previously unknown threats. This buys MSPs critical time in zero-day scenarios when vendors are scrambling to release patches for emerging threats.

Best practice hardening will never be thrilling, but like diet and exercise, it’s foundational for baseline cyber hygiene. Most MSP tool vendors are years behind the security capability of modern web browsers, and managing cryptography involves OS-level tuning on multiple servers (and even multiple operating systems).

With our service, you can configure all your hardening for all your on-prem applications in one place. By configuring modern security headers, you can add exploit protection by instructing the browser to load content in specific manners or control what on a web page can access clipboard data.

Likewise, it’s possible to granularly allow for legacy cryptographic configurations. For example, for MSPs onboarding new clients, it’s common to see devices that are behind on patching or end-of-life that don’t support the latest TLS ciphers. If you’re using ConnectWise Automate behind our service, it’s possible to allow the remote agents to communicate on legacy versions of TLS to expedite onboarding while requiring all non-agent requests to use secure versions of TLS.

The IP address ACL has been around for over 40 years. While there are limitations to IP ACLs, they work well for certain use cases — and they are easy to implement and manage in our service’s API (and since the same instance can be used for multiple applications, it might streamline maintenance of IP lists).

Likewise, there are 195 countries in the world — and not all of them need to communicate with your MSP tools. Our service can implement traditional GeoIP filtering, which can still provide value in reducing attack surface.

Do you have a cloud vendor that integrates with your tools but doesn’t have static IP addresses? In this scenario, traditional network restrictions won’t work (or are brittle at best).

Our service can lock onto identifiers in the HTTP request and allow requests through to applications based on the originating vendor. This allows for low-maintenance access controls and ensures integrations won’t break if a vendor adds new infrastructure.

SSO providers offer a slew of security protections beyond strong authentication. However, there can be weaknesses in how an MSP tool handles SSO (or some applications might not support SSO or your provider).

With our service, it’s possible to redirect an inbound request to your SSO provider before it reaches the application. This allows MSPs to protect against authentication bypass vulnerabilities and add SSO to applications that don’t have it.

Most on-prem MSP tools show up in IoT scanners like Shodan. This is a critical issue since enumeration is the first phase of a cyberattack, and an attacker with a vulnerability can download a list of targets and feed it into a bot for exploitation in minutes. Likewise, most MSPs run their tools on their primary web domain, which allows attackers or competitors to quickly determine what MSP tools are in use.

Our service comes with anti-enumeration defaults. It will prevent the enumeration of the tools it protects by IoT scanners like Shodan. It also comes with obfuscated FQDNs by default (with the option to support a custom FQDN of yours) and implementation guidance to thwart enumeration techniques.

Does your MSP have an official browser that all staff are supposed to use? Or does your policy indicate that only company devices are allowed to access internal tools?

Depending on your overall security stack, some of these policies can be left to the honor system — which can be less than desirable. Our service can be used as a technical control to enforce policies, streamlining those controls for every application protected by the proxy.

MSPs have interesting access requirements. For example, every user should connect from the office/ZTNA network…except for the one script using a PowerShell module for the API. Or, only internal networks should access the remote access tools — except for users calling in who need to get to the home page to enter temporary access codes.

Our service can help MSPs meet these complex access needs. For example, it’s possible to allow PowerShell access to specific parts of an application while otherwise requiring access from known IPs. Likewise, an application’s home page can be accessible but require SSO, certificate authentication, or access from a trusted network to access any other part of the app.

Good logging is critical for security and troubleshooting. Unfortunately, the quality of the logging mechanisms for various MSP tools can be luck of the draw. In some scenarios, it can be difficult to tell if an attack actually happened without alternative logging configured beforehand.

Our service supports Syslog for HTTP requests. This allows all requests to be sent to your existing SIEM tool, allowing deep visibility for all applications behind the proxy. In the event of a threat, you’ll be prepared with the correct data to tell if your MSP has been impacted.

These days, MSPs have a lot of tools. If that wasn’t enough, each tool has different security options, which adds another layer of complexity.

Our service works with the most popular MSP tools — and is compatible with most other web applications. Protecting multiple applications with the same instance lets MSPs deploy the same controls to all apps for streamlined security and lower management overhead.