IP restrictions for Connectwise Automate were released in patch 2022.11. This long-awaited feature has some nuances worth noting in the implementation, which we’ll discuss below. But first, let’s review the good parts of this feature.
The good: IP restrictions are possible with Connectwise Automate
Right off the bat, it’s worth noting that this much-requested feature has been delivered (hats off to the dev team at Connectwise). The humble IP ACL has been a staple in the network security world for decades, and it’s nice to see the implementation of this feature in Automate.
The implementation is an in-app wrapper over the IIS IP Restriction feature, which works as advertised in our testing. Once configured, only the specified IPs and CIDR ranges are allowed to communicate with the administrative parts of the application (more on that shortly). The IP restrictions happen before rewrite rules are processed (as expected), so configuration is required for any device proxying traffic — and any existing IP restrictions manually configured previously need to be removed before implementing this feature.
Additionally, the IP changes update within a few minutes, and there are new log files that can be used for troubleshooting changes for on-premise Automate servers. Overall, this is a valuable feature (especially for cloud-hosted Automate servers, which are challenging to protect otherwise). When doing some DB table review, new tables with GeoIP data indicate that Geo-blocking might be on the road map (this is only speculation).
The bad: rigid implementation and partial coverage
However, the new Automate IP restriction feature leaves some things to be desired. The biggest item to note is that it only covers parts of Automate that are “administrative,” which includes:
- The WCC2 homepage
- The new /automate web UI
- The desktop Control Center
The restrictions are all-or-nothing, with all three areas receiving the same restrictions. This means that enabling the feature will be difficult if clients use legacy WCC2 features, since it’s impossible to apply different controls to the various parts of the application. Implementing creative solutions to work around the lack of granularity is possible, but it’s not a turnkey solution for all partners.
The other concern is incomplete coverage. The application pool for agent communications is a notable outlier in the protection scope. Historically, vulnerabilities were found in components of the agent communication — and leaving this exposed limits the usefulness of the feature as a security control.
The ugly: Gaps exist for integration callbacks
The most significant concern with the IP restriction feature in Automate is the integration callback (used for things like syncing tickets between Automate and Manage/CW PSA). These callbacks receive data via a web request, and the integration then processes it (this can vary by vendor, but typically it’s either added to the Automate database or triggers additional actions).
Authentication and input validation are performed by each individual integration — which leaves the possibility for a variety of potential attacks if individual vendors didn’t implement security best practices (keeping in mind that some “vendors” might include individual developers who wrote plugins years ago and no longer maintain them). These integrations are not a common point of security research either, so the scenario of a bad actor finding an exploitable flaw in a common integration and attempting mass attacks is entirely plausible.
Going beyond plain IP restrictions
There is a way to have IP restriction cake and eat it too — and that’s with a reverse proxy. A proxy can apply IP address ACLs based on the request’s destination, allowing for very granular controls and the ability to configure different access controls to various portions of the application. If an MSP wanted to allow legacy access to WCC2, only permit API access from specific IPs, and block access to the desktop client outside of the office, a reverse proxy can meet all of these requirements.
Additionally, a reverse proxy can provide full coverage for the application (not only in IP restrictions but also in HTTP header and TLS hardening). Specifically, for the application pool that serves the agent requests and integration callbacks, a proxy can apply an ACL to block any non-agent request (and IP lists can also be allowed). This granularity creates full protective coverage while letting agent traffic come in as expected.
Here at Automation Theory, we offer Reverse-Proxy-as-a-Service, and our solution (complete with a self-service API) is a Connectwise-certified integration designed for MSPs. You can find more information here.
