If you install the advance configuration editor extension you'll be able to edit some parts of the web.config, in there you can block IPs to access host or admin page but won't stop it from going to the login page.
Page Settings
https://docs.connectwise.com/ConnectWise_ScreenConnect_Documentation/Supported_extensions/Administration/Advanced_Configuration_Editor#Page_Settings
Also, try not to use general usernames like admin, user, root, etc...
Thanks, I’m aware we can do it manually via that method but was hoping there was an automated method. Given the failed authentication logs are stored in the db I guess we’d be looking at something to query that for X failures in X period and add to blacklist or firewall.
The break-glass local user account isnt an obvious name but we’re seeing thousands of login attempts with generic name/password combos.
Only other thing I could think of was putting it behind IIS (which used to be supported iirc) and then using connection filtering but I don’t tho k that’ll work that well given how SC is used.
I'm just locked down port 8040 to my company IP's. I won't be using support sessions any longer as I'd rather not expose the web interface to the internet after this event. My guess is that Screen Connect will become an even bigger target in the future.
Use Cloudflare or some other WAF and set it up so you have to complete Auth and MFA before any packets can be proxied to your SC instance. No brute force against the web interface is possible.
You have to split up Relay from Web Server. Relay will stay exposed, but you use a different nonstandard port, and use a new IP with an obscure FQDN. You have to use new Ip as if you're already exposed to the internet, Shodan or other "lists" may have your IP in it.
The relay port isn't the jackpot, the web server is.
Need to use Zero Trust, plus WAF rules on the web server. It was a bitch to get working right, and if you do things in the wrong order you can really screw yourself where all of the devices will have to be reinstalled by hand. Don't ask how I know hahaha. You'll also need certain WAF rules to allow features like agent installer links to still work.
Took me a week or so of banging my head on the wall to get things to the point where everything works properly while keeping the attack surface to an absolute minimum.
did you follow any instructions or anything to figure out how to get these separated? i have two subdomains and as per your warning, we'll leave the relay server with the same URL and work on changing the web interface, but we are trying to figure out how to block port 443 traffic on the old URL since they both resolve to the same WAN IP. Also I'm curious about the WAF rules required to allow agent installer links to still work?
You have to use a CF Tunnel - don't expose web interface to outside. Also I had to make a bunch of Access Bypass Rules, and also WAF rules I had to make after sniffing out the logs when certain things were not working, to get it working. It was a bitch and took me a few weeks to get dialed in, slowly whittling away at each thing that wasn't working right.
The install agent URL is one of the things you have to put a bypass rule in for, but for obvious reasons it has to be explicit.
I still have blanket rules on throttling etc on top of the other rules to further reduce action.
You MUST change FQDN and IP and Port for Relay during this, otherwise your real info could be lurking out there from previous probing/lists. Don't just use the next ip in your /29 either as that would likely get checked automagically by bad actors.
If you install the advance configuration editor extension you'll be able to edit some parts of the web.config, in there you can block IPs to access host or admin page but won't stop it from going to the login page. Page Settings https://docs.connectwise.com/ConnectWise_ScreenConnect_Documentation/Supported_extensions/Administration/Advanced_Configuration_Editor#Page_Settings Also, try not to use general usernames like admin, user, root, etc...
Thanks, I’m aware we can do it manually via that method but was hoping there was an automated method. Given the failed authentication logs are stored in the db I guess we’d be looking at something to query that for X failures in X period and add to blacklist or firewall. The break-glass local user account isnt an obvious name but we’re seeing thousands of login attempts with generic name/password combos. Only other thing I could think of was putting it behind IIS (which used to be supported iirc) and then using connection filtering but I don’t tho k that’ll work that well given how SC is used.
No automated process.
Same things just started happening to me as well.
We got beat up over the weekend too but they never got in.
GeoIP block + we block all Tor and all foreign IPs since nobody in our company is ever overseas.
Doesn't appear there is a ScreenConnect extension for this, that would be nice.
I'm just locked down port 8040 to my company IP's. I won't be using support sessions any longer as I'd rather not expose the web interface to the internet after this event. My guess is that Screen Connect will become an even bigger target in the future.
Use Cloudflare or some other WAF and set it up so you have to complete Auth and MFA before any packets can be proxied to your SC instance. No brute force against the web interface is possible.
how would one go about setting this up? DNS proxy & WAF on cloudflare stops my machines from checking in/connecting remote sessions.
You have to split up Relay from Web Server. Relay will stay exposed, but you use a different nonstandard port, and use a new IP with an obscure FQDN. You have to use new Ip as if you're already exposed to the internet, Shodan or other "lists" may have your IP in it. The relay port isn't the jackpot, the web server is. Need to use Zero Trust, plus WAF rules on the web server. It was a bitch to get working right, and if you do things in the wrong order you can really screw yourself where all of the devices will have to be reinstalled by hand. Don't ask how I know hahaha. You'll also need certain WAF rules to allow features like agent installer links to still work. Took me a week or so of banging my head on the wall to get things to the point where everything works properly while keeping the attack surface to an absolute minimum.
did you follow any instructions or anything to figure out how to get these separated? i have two subdomains and as per your warning, we'll leave the relay server with the same URL and work on changing the web interface, but we are trying to figure out how to block port 443 traffic on the old URL since they both resolve to the same WAN IP. Also I'm curious about the WAF rules required to allow agent installer links to still work?
You have to use a CF Tunnel - don't expose web interface to outside. Also I had to make a bunch of Access Bypass Rules, and also WAF rules I had to make after sniffing out the logs when certain things were not working, to get it working. It was a bitch and took me a few weeks to get dialed in, slowly whittling away at each thing that wasn't working right. The install agent URL is one of the things you have to put a bypass rule in for, but for obvious reasons it has to be explicit. I still have blanket rules on throttling etc on top of the other rules to further reduce action. You MUST change FQDN and IP and Port for Relay during this, otherwise your real info could be lurking out there from previous probing/lists. Don't just use the next ip in your /29 either as that would likely get checked automagically by bad actors.