Considering for Future Release

add dynamic ip block for the login page, against brute force logins

Yves 8 years ago updated by Phill 1 month ago 18

we authenticate through Active Directory, but our public login page is sometimes attacked by brute force attempts, so some AD accounts are locked.

It would be great if ip could be banned after some bad attempts.

Definitely important otherwise the SC login page basically open up a potential DoS attack surface when combined with AD.

Related question is http://product.screenconnect.com/topics/585-allow-e-mail-trigger-for-maxinvalidpasswordattempts-with-ip-info/ - possibly by setting 'MaxInvalidPasswordAttempts' you may be able to help mitigate this.

Still, I strongly believe that SC should support a fail2ban style automatic IP block on multiple failed login attempts. It should be configurable for number of accounts attempted, number of invalid passwords attempted and number of non-existant usernames attempted. This would allow much more effective blockage of brute force attacks while running a very low risk of locking out a legitimate user. A legit user will not likely misspell their own username 5 times - or try 3 different accounts, etc.

Pending Review

We do not allow users connecting from the internet to use the admin-page due to this... hope that we can see some improvements. :)


I don't understand what you mean by "We do not allow users connecting from the internet to use the admin-page". I use it through Internet almost each day

We have the SC server on our DMZ and authenticate towards the AD (private network). Today its possible to try to brute force the loginpage on the SC-admin and we do not want that to happen.

To restrict this we set "RestrictToIPs" in web.config and only allow internal IP's towards the Host.asp Administration.aspx and Login.aspx

ok, thanks. As we can't restrict by ip we lock accounts after some bad attempts...and still hope ScreenConnect implement more security features

Considering for Future Release

+1. This is very much something that would be useful.

Having something automated  help immensely. otherwise people would need to have people hunting logs to find offenders to add manually or script something out in a SIEM to where if a certain event with a specific IP was registered more than X times within a specific time frame to go do this at which point could be someone accessing a firewall via CLI or something to block an IP or whatever. pain in the ass is what that'd be.

Even having some form of alerting which would allow us to have a notification go out if we received like X amount of failed attempts from a single IP within 5 minutes or something would be useful too because I do have a "Shitlist" so to speak that is maintained on our firewalls to block abusive traffic.

Has there been any movement on this? After adding the ability to search for failed login attempts it would be great to be able to act on them, without having to restart the service. This has been a common feature for many of the other systems we use, for years.

shouldn't this be of a higher priority after what just happened?  if this were in place 7 years ago would we have had this issue??

yeah, the exploit that just happened still would have been an issue 

my server is still getting hit with unknown users from strange ip addresses:

User Name:badusername



User Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

and the badusername is using different ip addresses.

Banning or some type of limit on "number of tries" would be great. Even if it was simple, just blocked the IP for an hour after X number of attacks, that would help. This type of security doesn't seem like it would be too hard to implement into the code.

As a workaround, there are two ways I've found to mitigate unwanted access attempts:

1.) Restrict the login attempts to a list of allowed IP ranges. For IPs that are not static, I've looked up the network range that the IP is in, and allowed that. So although I may have allowed everyone in a certain city or connection, it's better than allowing the entire world. You can find the network range of an IP address on sites like ipinfo.io or arin.net. The allowed list can be changed under Advanced > Web Configuration > Settings > Restrict to IP Addresses.

2.) On another server, I implemented pfSense with pfBlockerNG and blocked IPs outside of the country. Doing that reduced the number of brute force attempts by 90%. Note that doing this can be effective but also adds some layer of complexity to the environment.

Although these fixes don't solve the issue of blocking brute force attacks, it does significantly reduce the attack surface.

getting picked on this morning over 150 times from 3 ip addresses.  it would be great to disable their attempts after a specified number of attempts instead of manually blocking them

Image 1236

~12hr period - number of attempts on the left.  manually blocking them as they come in ...

even adding CAPTCH (**like what's found on this board when posting replies**) would help ...

been getting an increasing number of attempts recently, the built in HTTP 504 IP blocking is not sufficient we need a real firewall to thwart these threats and zero-day exploits.