Ability to Approve newly installed unattended access devices before they are added
If installers get in the wrong hands, unknown unattended access devices are added. This could allow an adversary to gather information about a ScreenConnect instance to potentially attack it. Additionally, it's common to get rogue devices show up. When unattended access is installed, we would like the device to go into a holding position and need approval before it's fully accessible in the system. Our RMM does this and it works well. Ideally, there should be minimal communication with the agent while it's waiting for approval to avoid an adversary mapping things out.
It's precisely my current problem - how to rotate keys without ruining existing clients. I want to get rid of rouge clients. I had to shut down my SC server as a precaution (i cannot be 100% sure that rouge client wont do anything malicious to host and other clients even if i wont join it). Adding networks to firewall works for one rouge and next day i have next one from different datacenter...
I have already a problem after changing address(domain) - removing old client removes both - new and old (one connecting to old address and other to new one).
Adding security features should be top priority at this moment.
FEATURE REQUEST: aside of accepting clients ALLOWLIST for clients on SC side.
Example and description of concept: Allowlist would allow us limiting client networks to known ip addresses or networks. Yes, it can be done on firewall side but on SC this could be more efective.
Unknown client connects to server - sends its ID, hostname, network address only. No other communication other than keep-alive.
If UnknownClient is on one of trusted networks (IP matches existing one already accepted) it can be aded automatically (suggestion: switchable option). Also existing accepted client IP could trigger whole network range of public addresses (switchable) to be treated as trusted.
If unknownclient is tagged by user as rouge and rejected: ban whole source network (to prevent next connect attempt as new client from similar ip)
Allowlist could allow normal connecting as usual for new instances of clients - such dynamic allowlist would prevent most of rouge client connections. Most of us have customers with known addresses or networks ranges.
Individual customers new clients or support connections can be on such waitlist.
This feature in SC will automate "firewalling" of relay. Rotating keys (for currently connected clients - two accepted keys for some peroid of time) would be good way to get rid of rouge clients if firewalling will fail, other SC 0day will occur or keys will leak.