ConnectWise Automate firewall ports have changed over the years, and many partners still have ports open that aren’t required (or are dangerous to have open). Since the guidance has changed over the years, we wanted to create an updated guide that covers how the protocols work, along with what firewall ports are required (and what exposure each port creates).

ConnectWise Automate Network Architecture

Automate is a complex application, with at least 5 different components communicating over the network (2 of which should never be exposed externally). Automate uses a mix of TCP and UDP traffic, and the architecture is as follows:

Below, we’ll examine this architecture in detail. However, if you’re in a hurry, our recommendations are:

Ideal ConnectWise Automate firewall configuration

For any MSPs looking to verify their ConnectWise Automate firewall rules, we have a best practice security scanner that can be used to check for misconfiguration or missing best practices.

MSP Tool Security Scanner

This scanner checks for common MSP tool security misconfigurations and missing best practices. Check your security posture today!

Web traffic

Web traffic is the most commonly used protocol in the ConnectWise Automate network architecture. It is used by the agents to communicate with the server, as well as the desktop and web clients for the application UIs. It also has the largest security footprint of any component.

IIS listens on port 80 by default (and 89% of Automate servers still listen on plain-text HTTP). For security best practices, it’s recommended that only HTTPS be used for Automate web traffic. Any firewall rules for port 80 should be removed after verifying that HTTPS is working on the Automate server. In split-server environments, the Database Agent service might use plain HTTP to communicate with secondary web servers, so it might be required internally (but can be ACLed accordingly).

The security footprint for the web traffic is quite large, and it’s the most likely attack vector for the application. While the native IP restrictions are a step in the right direction, they do leave some important parts of the application exposed — and it’s advisable to implement additional security layers, such as a reverse proxy or a WAF.

Heartbeat

Heartbeat is a supplemental service (running via the agent watchdog service on remote devices) that is used for offline agent validation and to speed up certain agent communications. It’s not required, but it is very useful, and the additional features enhance user experience.

Heartbeat formerly used port 70/TCP, but the new Enhanced Heartbeat uses 75/UDP. The new UDP configuration is preferable to the TCP variant because TCP traffic can be enumerated via a port scanner, whereas UDP traffic can’t be. Since heartbeat is a proprietary protocol, there’s little that can be done to further harden the communications beyond enabling the new version and closing the old TCP port.

The security footprint is minimal for the Heartbeat traffic — but it’s worth noting that it does read/write data from the database (and in theory, an unsanitized input could be attacked if one exists). However, no known vulnerabilities have been found in the heartbeat traffic, and the non-enumerability of the UDP traffic makes it difficult to attack.

MySQL

Automate uses a MySQL database, and it connects over TCP/IP. Both IIS and the Database Agent services connect to the database, along with most of the other server-side services (such as the Solution Center and Redirector services). Older versions of Automate allowed the client to connect directly to the database (and some Automate servers still have the MySQL port open from this era!).

MySQL should never be open to the Internet (and it should be restricted as much as possible internally) since a total takeover of the Automate server is possible with MySQL access. On single-server environments, it’s advisable to bind MySQL to localhost to prevent access from outside the server. For split-server environments, using the Windows Firewall to restrict access is advisable to prevent attacks from the local network segment.

How to pwn an Automate server: Connectwise Automate LAN Security

ConnectWise Automate security is something at the forefront of discussion for every MSP. Previously we’ve discussed security from the WAN angle, and how reverse proxy technology can be implemented to reduce the attack surface. However, internal LAN communications can also be an attack vector, and here at Automation Theory, we wanted to give proper attention to this often neglected aspect of Automate security. Below we’ll review the risks and remediations for the different components of Automate, including the database, integrations, and the OS.

File Service

The File Service is a helper service for file uploads, downloads, and LTShare replication in split server environments. It is used by IIS, and it doesn’t have any direct interaction with remote agents or users directly.

The security footprint of this service can vary by environment. When it was originally released in 2018, it was discovered that this service had a directory traversal bug, where any file in the OS could be accessed. While this has been fixed, the files in the LTShare are often used in scripts — and an attacker could try to abuse the service and tamper with the contents of the LTShare.

Since this service is internal, it should never be open to the Internet. Like MySQL, it’s advisable to use the Windows Firewall to ensure that access to port 12413 is closed to anything besides other Automate web servers.

Solution Center

Automate uses the Solution Center to keep various components (default searches, scripts, etc.) and 3rd party integrations up to date. The Solution Center is a distinct service that runs over a different port, and is not part of the traditional web service.

This service uses .Net Remoting as its underlying technology, which makes the security footprint interesting for this service (since it’s a SOAP API under the hood). There are newer preferred protocols for achieving this functionality today, and the .Net Remoting protocol has traditionally had surface area concerns — giving this relatively little-known service a large security footprint (especially since it can modify scripts and plugins).

While this service has valid use cases to be used remotely (when updating Solutions in Automate), it’s advisable to close this port and perform updates on the Automate server itself — especially from the perspective of least access.

Tunnels and Redirectors

Tunnels and Redirectors in Automate are a feature for network tunneling for remote access. They date back to the early era of the software, before the integration with ScreenConnect. Automate can establish a tunnel to a remote agent, and then a redirector can be used to launch remote access to or through that remote device (e.g., accessing RDP on a server or connecting to an ILO web interface through a device on the same network).

The functionality of the tunneling appears to be implemented with wodVPN.dll, which has a digital signature timestamp of May 2013. It appears that this software vendor hasn’t released any additional versions since 2013, which raises interesting questions about the cryptographic strength of the communications given the age of the library. In reviewing the documentation, the same library is used for the client and the server, meaning that the exposed server side of the communications is also running on code that hasn’t been patched in 11+ years.

Given the circumstances with the implementation, it would be prudent to close the ports for Tunnels and Redirectors. If the functionality is required, restricting communications to client IP addresses to limit the surface area would be advisable.

We hope our guide for ConnectWise Automate firewall ports has been helpful. Be sure to verify your configuration with our security scanner to make sure your security controls are working correctly once the rules are in place!