add the ability to audit login failures/successes for logging in to the web interface
add the ability to audit login failures/successes for logging in to the web interface
Welcome to our community!
Duplicates 4
Notification on failed and successful logins
Log site logins with notification capabilities
From CW#7590390:
Would like to be able to audit when users login to ScreenConnect instance, including failures. Would also like to be able to receive email notifications when failed login attempts occur on site.
Audit logs of when someone logs on (successfully or failure) into the web interface?
Hello
When someone logs on to the web interface, Id like to log it and send it to a syslog ( more specifically Elastic Stack ) to not only keep logs but to meet certain compliance requirements.
We have ScreenConnect ( or ConnectWise ) installed on Windows on prem.
Where are these audit logs located?
Thank you
log user login history
Please add this feature that can log user login history for audit and investigation.
Replies 78
jp,
First, thanks for your comments. I am a lone, self-employed IT consultant, and my path to ScreenConnect was as a duly researched replacement to LogMeIn, whose doubling of prices year after year (after first going back on their long term promise to always offer a basic free version) quickly became untenable. Having been "bitten" this once, I was "twice shy" about committing myself 100% to a single other platform. Still, the more than adequate quality and performance of SC in 2015 won me over. I just ALSO signed up, around the same time, to a second remote access service as a backup (remember: "once bitten, twice shy" - or "not putting all your eggs in the same basket"). My cost for that first year was 325$ US for SC, plus 60$ for Splashtop, my "plan B" service. Then, for the next few years, remaining eligible to updates and support cost me 20% yearly of the original SC cost, while I had to fork over 100% of the modest Splashtop price to keep the service active (also with updates). Frankly, I would have probably bought into a cloud-based version of SC if it had been offered at the time, at a reasonable price of course (what does that EVEN mean nowadays^).
This whole situation stinks. I strongly suspect that ScreenConnect, if it had not been bought out by ConnectWise, might have been maintained and improved at a faster clip, I am seriously considering NOT renewing my license when it expires next summer...
Justin - can we really attribute that ransomware to Screen Connect? or just to "not using 2FA" in general? Seems a little disingenuous.
Regardless if 2FA is implemented - auditing login attempts to the web port, and traffic to the relay port, is something we should all want, and not because of satisfying some compliance requirement - but because you should be reviewing all traffic and making firewall rules to prevent unwanted traffic - on a daily basis. Are we IT professionals here, or are we just a manager looking to check another box on the joke that is a compliance survey?
It's disappointing that after jacking the price of ScreenConnect up 1000 X all that's been accomplished under ConnectWise is a massive effort to sell the product as a cloud service, instead of real thoughtfulness to security. Auditing (at least logs) of connection attempts to the web and relay ports should be made available - somehow - and regardless if you're using the cloud service or an on-prem install. Don't get me started on all the things your missing by running in the cloud - on prem is still a requirement for some business that aren't drinking the cool-aid.
I don't think so.. but then again I have mine set for max 30 minutes without forcing the user to re-authenticate... no matter what. Default is 360.. I suppose folks can forget to log out or have their 2fa stuff stolen.
jp,
First, thanks for your comments. I am a lone, self-employed IT consultant, and my path to ScreenConnect was as a duly researched replacement to LogMeIn, whose doubling of prices year after year (after first going back on their long term promise to always offer a basic free version) quickly became untenable. Having been "bitten" this once, I was "twice shy" about committing myself 100% to a single other platform. Still, the more than adequate quality and performance of SC in 2015 won me over. I just ALSO signed up, around the same time, to a second remote access service as a backup (remember: "once bitten, twice shy" - or "not putting all your eggs in the same basket"). My cost for that first year was 325$ US for SC, plus 60$ for Splashtop, my "plan B" service. Then, for the next few years, remaining eligible to updates and support cost me 20% yearly of the original SC cost, while I had to fork over 100% of the modest Splashtop price to keep the service active (also with updates). Frankly, I would have probably bought into a cloud-based version of SC if it had been offered at the time, at a reasonable price of course (what does that EVEN mean nowadays^).
This whole situation stinks. I strongly suspect that ScreenConnect, if it had not been bought out by ConnectWise, might have been maintained and improved at a faster clip, I am seriously considering NOT renewing my license when it expires next summer...
It really is probably one of the better products out there with TONS of potential. it sucks to see that CW is running it into the ground. Some of the OG support is still with them, the people that know the product well but I think there's been some turnover too and I haven't a clue what that looks like for the dev team.
This is a pretty huge pain point for a lot of people not having logging or any way to audit failed logons.
We utilize syslog data from SC to track all events & those are retained within our SIEM for 400 days but that doesn't account for failed logon attempts so we can look for abuse & try to mitigate it.
The only way I can think of is stick a WAF in front of SC web portal & protect against credential stuffing & connections from IP's with poor reputation. Fortinet has a pretty slick WAF product but there's just a lot of cost associated with it.
Sean White Team Member
All, I apologize that this was still appearing as 'Roadmapped', and have updated the status. We do realize the importance of this request, and it has been under development for several months.
It has just hit QA. I expect that it will be available in a release in early Q2, barring any setbacks.
All, I apologize that this was still appearing as 'Roadmapped', and have updated the status. We do realize the importance of this request, and it has been under development for several months.
It has just hit QA. I expect that it will be available in a release in early Q2, barring any setbacks.
SWEET!!! Thanks!!!
All, I apologize that this was still appearing as 'Roadmapped', and have updated the status. We do realize the importance of this request, and it has been under development for several months.
It has just hit QA. I expect that it will be available in a release in early Q2, barring any setbacks.
Excellent news!
All, I apologize that this was still appearing as 'Roadmapped', and have updated the status. We do realize the importance of this request, and it has been under development for several months.
It has just hit QA. I expect that it will be available in a release in early Q2, barring any setbacks.
swhite,
That's good news, and very welcome. Of course, it would have been just as welcome, as well as more timely, if it had been implemented more quickly (pick any time delay between 5 weeks and 5 years...). Still, I am grateful for the action on this item at this time - looking forward to checking it out when it comes out, possibly even in pre-release.
However, this will only respond to ONE of the 3 questions that were in my original query, which was brushed off as belonging in feature requests: WHEN, HOW MANY and WHICH IPs? I guess I will have to take the last two and make them part of a new post on the Feature Request Portal...
It would also be desirable to have a configurable setting as to how many (consecutive?) bad logins it would take before an account is locked out. Also, in the case of a self-hosted SC installation with only the ONE "Administrator" account, locking it out seems to me to be a far from optimal response to multiple bad logins. I would find it highly preferable if one of the following measures were implemented instead:
*) limited time lockout - least desirable, but certainly preferable to a PERMANENT lockout that makes the whole installation UNUSABLE (forcing recourse to a password reset that also deletes the user table, if there is one).
*) blacklisting of originating IP address of the bad logins, with settings to manage the list of blacklisted IPs (and possible auto-expiration from that list)
Again, I realize this probably belongs in a separate feature request, which is where I am headed next. But I also thought it would be appropriate to first previous these comments here, as part of this long thread with (FINALLY) some action at the end...
Renald: Reviewing this: https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Security_guide
Goes over IP blocking. It doesn't have IP based fail2ban style greylist/autoban interface but does offer some options.
This is for locking user accounts (not IP's): https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Administration_page/Security_page/Internal_user_authentication/Edit_user_password_requirements_and_configurations
Which has MaxInvalidPasswordAttempts
It would be nice for smarter greylisting and blacklisting based on IP...but I'm not holding my breath on that.
Renald: Reviewing this: https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Security_guide
Goes over IP blocking. It doesn't have IP based fail2ban style greylist/autoban interface but does offer some options.
This is for locking user accounts (not IP's): https://docs.connectwise.com/ConnectWise_Control_Documentation/Get_started/Administration_page/Security_page/Internal_user_authentication/Edit_user_password_requirements_and_configurations
Which has MaxInvalidPasswordAttempts
It would be nice for smarter greylisting and blacklisting based on IP...but I'm not holding my breath on that.
David,
Thanks for these links.
I see that IP blocking actually offers both "Block IP Addresses" and "Restrict to IP Addresses", the latter of which could be particularly useful under the right circumstances. Nevertheless, you got it exactly right when you alluded to "IP based fail2ban style greylist/autoban" as the desirable (but so far missing) feature.
Regarding locking user accounts, I have now raised the "MaxInvalidPasswordAttempts" setting to an absurdly high level, so I may be protected (somewhat) against getting 100% locked out of my own self-hosted SC installation. Furthermore, I have now created a second administrator account with a non-obvious name (and strong password), something I will admit I should have done from the beginning. I also activated 2FA on both accounts. And finally, I have implemented a daily task that stops SC services, saves a daily archive of the entire SC program directory (not that big, around 80 MB presently) and restarts SC services.
I still think that my original configuration, with ONLY the standard/default "Administrator" user, should have had some kind of safeguard or mitigation built-in, such that I could not end up locked out of my own PAID self-hosted server through actions of some unknown external bad actor (and on a Patch Tuesday morning, of all possible times...). But that's water under the bridge, as they say.
Moving on,
Renald
Partner stated that he would like a email notification when there is a successful or failed login