Restricting access to parties that need it is a core tenant of IT security. As IT professionals, if a client wanted to leave well-known management ports (like 22 for SSH, or 3389 for RDP) accessible from anywhere, even with proper lockout measures, we’d likely explain that it’s unwise to do. Our preference would likely be to restrict access to certain IP addresses, change the port numbers to obfuscate the service, and maybe implement other security controls as the situation dictated.
Here at Automation Theory, we like to apply the same logic to Automate stacks. After all, the Automate server is probably the most savory target for potential attackers. Leaving access open to places that you don’t have clients or employees is asking for trouble. Perch tracked network traffic from the Enraged Duck vulnerability and found that traffic increased from several foreign IPs after the disclosure was published, with Russia leading in traffic volume (even from before the vulnerability was published).
So, what’s an MSP to do about this? First, let’s do some checking to test your Automate security controls and see if your server is open to the world. Some websites do scans for this, but we don’t recommend them for two reasons:
- It’s bad practice to put the FQDN of your Automate server into random scanners.
- Different sites use different technologies; we’ve seen false positives/negatives before.
Using Tor to test Automate security controls
A better way to test is to use a VPN to browse from a specific country. The Tor browser can be used to do this, and the country of the exit node can be configured (set it to a country that should be blocked). To do this, modify the config file in the following path <base folder>\Tor Browser\Browser\TorBrowser\Data\Tor\torrc. You can enter a country code with the following syntax, save the config, and start the browser.
ExitNodes {RU}
Once you launch Tor, go to https://www.maxmind.com/en/locate-my-ip-address to verify that you’re indeed browsing from the country you selected. Once you’ve verified that enter the FQDN of your Automate server in the browser and see if you can reach the web UI. If you can, then your Automate server is open to the world. If you see a connection timeout message then whatever security measures you have in place are working.
What can you do if your server is open to the world? Locking it down is definitely a best practice. While GeoIP will not stop determined attackers, it reduces attack surface (especially from basic bots scanning for Automate servers). Most enterprise security appliances implement GeoIP and enabling that functionality should be part of the security baseline for any managed IT provider.
Here at Automation Theory we’re launching a new reverse proxy service that implements GeoIP filtering, along with IPS, reputation-based filtering, and reverse proxying. This service solves the normal implementation challenges of reverse proxy technologies with RMM stacks, and it also adds extra obfuscation by changing the FQDN and public IP address to values that aren’t easily traceable to the provider. You can find more details about our service here.
