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
Additionally, to add on to what I listed above.
Will there be any options or plans in the future to also have an automatic block feature where if someone failed 5 logon attempts consecutively in a 30 minute time period it would deny connections from their IP address? From there you could determine if it will automatically lift the block after X amount of time or be a permanent block.
Side note we'd have to be careful with this because if lets say some internal person fat fingered their pass 5 times and they were at a client location trying to log on, would it deny connections from all clients at that location coming from that IP address?...
Just food for thought.
Seems like a no-brainer.
We have no way, from Screen Connect server, to determine if we are getting brute forced or not.
Still pending on this one? Maybe this should be moved up in the list now that you're enforcing 2FA and strongly encouraging use because of all the MSP targeted hacking going on of late.
I second this.
We'd love to see a way that we can look through logs so we can block offenders that are attempting to abuse the system.
For some organizations this would be a dealbreaker not having audit logs for failed logon attempts.
...an argument could be made that the lack of an audit log makes use of Connectwise Control in Healthcare (HIPAA regulated) and Financial Services (Sarbanes-Oxley regulated) illegal and in violation of their respective requirements of: Maintain and auditing access logs.
https://www.securitymetrics.com/blog/what-are-hipaa-compliant-system-logs
Event, audit, and access logging are required for HIPAA compliance. HIPAA requires you to keep logs for at least six years. These three HIPAA requirements apply to logging and log monitoring:
- § 164.308(a)(5)(ii)(C): Log-in monitoring (Addressable). [Implement procedures] for monitoring log-in attempts and reporting discrepancies.
- § 164.312(b): Audit controls (Required). Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.
- § 164.308(a)(1)(ii)(D): Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
How is this not a thing yet? This is a feature I would have expected to be standard by now, especially with all of the MSP hijacking going on lately. Being able to track login attempts by IP I would consider essential, seems like it shouldn't be too difficult to implement given that we already get notified of successful sign-ins from new locations.
Yea, this has got to be an option ASAP! Otherwise we will have to move to a different solution!
Are you guys going to take security seriously and implement this? I should know that clients are locked out of their accounts or an attack is underway before they do.
We are still waiting
We are using the Syslog extension to our SIEM tool which is working well, However this only seems to log information about authorised sessions and connections to remote machines. It should also log connections to the control web interface. Can you please look at this ASAP as like everyone else, we take security very seriously and currently it seems connectwise do not.
We also NEED this. Doesn't matter if 2FA is enabled, someone can still bring the server to it's knees with invalid attempts.
I need at least a log file of attempts to the web interface, but also a log of attempts on the relay server port.
I have not seen any moderators or Connectwise support specialist reply to this tread at all. Is anyone updating this tread and can we get answers as to why these features are not already in place. My firm recently switched to Connectwise and Control and these audit features were sold to us as being "Already in place.". That is obviously not the case. Can someone from Connectwise please respond to all of our inquiries? JP is right, 2FA does not resolve these issues. Please respond.
Hi Rich,
We are still actively reviewing this feature and how best to architect it. Security is our top priority, and something we take very seriously. As to what you were told about login auditing when you purchased the product -- we'll have to follow up with Sales and make sure all information is correctly relayed.
Your statement ("Security is our top priority") CAN'T be true AND this security bug be outstanding for over 4 years. ConnectWise has prioritized hundreds of enhancements and fixes for years and neglected to resolve this.
You are not responding to an ignorant audience that is going to simply believe it is something "[you] take very seriously" because you said. We can all see how this has been handled.
https://controlforum.connectwise.com/yaf_postsm28485findunread_fail2ban-working-example.aspx
Works great on self hosted.
I now have a log of successful and failed logins by ip and ban appropriately.If you set your timezone, be sure to reboot or fail2ban won't work...
port setting should be whatever ports you want banned.
justin, the solution needs to be something that is native to the platform and supportable by the vendor themselves. Use of 3rd party apps and a configuration that is not supported by The vendor puts you in a position where you can be out of compliance if the modification breaks and doesn’t work.
Agreed, but this is better then nothing, and it does exactly what I want. Only thing is, editing Login.aspx after upgrading. I can live with that. I had issues with LetsEncrypt and my screenconnect installation..and ended up doing something different to make that work.
Only thing left to do, tell fail2ban to email me for successful logins... which is easy. But would be cooler if you guys could share some code to do that in Login.aspx. =)
I’ve been curious to know how much a web application firewall could benefit. Something like a fortinet WAF. Using fortiguards reputation database to proactively block stuff based on IP reputation or the AI behavior based learning. problem is a WAF gets expensive.
It’s also probably not super easy to build anything into the Product either
some people might be able to use a SIEM to look for logon failures or something and create an automation to add offending IP’s of consecutive logon failures into their firewall rule block list or something but still nothing is gonna be as good as an actual block list within the software itself and visibility into logon attempts whether they’re successful or not
Yeah... I just want the list of IP addresses that try to bang on the login... just to know. Never know what you could find. It would be cool to have a dangerous list of ip addresses to add to the list... I think pfSense does this..... Not sure.
Bam! Login.aspx email without fail2ban. Looked at the reset password function in Login.aspx. Seems to work okay.
if (result == LoginResult.Success)
{
File.AppendAllText(@"/var/log/screenconnect", DateTime.Now.ToString("MMM d H:mm:ss") + " screenconnect(" + Dns.GetHostName() +"): Authentication successful from " + GetIPAddress() + Environment.NewLine);
this.errorLabel.Text = null;
if (userName.IsNullOrEmpty())
throw new InvalidOperationException(WebResources.GetString("LoginPanel.InvalidUserNameText"));
var threadState = new
{
User = MembershipWebAuthenticationProvider.GetEnabledMembershipProviders()
.Where(_ => _ is IMembershipWithoutOldPasswordProvider)
.Select(_ => _.GetUser(userName))
.FirstOrDefault(),
Url = this.Context.Request.GetRealUrl(),
this.Context.Request.UserHostAddress,
this.Context.Request.UserAgent
};
if (threadState.User != null && !threadState.User.Email.IsNullOrEmpty())
System.Threading.ThreadPool.QueueUserWorkItem(delegate
{
Extensions.Try(() => MailSender.Instance.SendMail(
threadState.User.Email,
"Successful Login",
"Successful Login",
Extensions.TryParseBool(WebResources.GetString("ResetPasswordEmailIsBodyHtml"))
));
});
this.Response.Redirect(this.Context.GetValidReturnUrlOrDefault());
}
This works better.. kinda dirty but works.
if (result == LoginResult.Success)
{
File.AppendAllText(@"/var/log/screenconnect", DateTime.Now.ToString("MMM d H:mm:ss") + " screenconnect(" + Dns.GetHostName() +"): Authentication successful from " + GetIPAddress() + Environment.NewLine);
File.WriteAllText(@"/tmp/temp", GetIPAddress());
this.errorLabel.Text = null;
if (userName.IsNullOrEmpty())
throw new InvalidOperationException(WebResources.GetString("LoginPanel.InvalidUserNameText"));
var threadState = new
{
User = MembershipWebAuthenticationProvider.GetEnabledMembershipProviders()
.Where(_ => _ is IMembershipWithoutOldPasswordProvider)
.Select(_ => _.GetUser(userName))
.FirstOrDefault(),
Url = this.Context.Request.GetRealUrl(),
this.Context.Request.UserHostAddress,
this.Context.Request.UserAgent
};
if (threadState.User != null && !threadState.User.Email.IsNullOrEmpty())
System.Threading.ThreadPool.QueueUserWorkItem(delegate
{
string ipAddress = File.ReadAllText(@"/tmp/temp");
Extensions.Try(() => MailSender.Instance.SendMail(
threadState.User.Email,
"Successful Login from: " + ipAddress,
"Successful Login from: " + ipAddress,
Extensions.TryParseBool(WebResources.GetString("ResetPasswordEmailIsBodyHtml"))
));
});
this.Response.Redirect(this.Context.GetValidReturnUrlOrDefault());
}
...4 year old thread about a glaring compliance hole in the product, and posts to workarounds that could have been integrated years ago...good thing we have https://www.connectwise.com/software/control/remote-support/security "World Class Security" on our side.
You catch more flies with honey than vinegar or, sometimes you catch more flies with honey. Usually....
David,
I like how the page you linked still mentions the more secure self-hosted product, and server-level auditing!
Just going to bump this. As we work on NIST compliance this is going to be a very important feature.
Also bumping this - as it will be required for Australian SOC and ISO compliance.
We are all waiting for this basic security feature. Where we are with this ConnectWise?
So after upgrading to 21.1... the code has changed a lot in Login.aspx. Any update to this??? I spent a lot of time trying to get an email when I login. Nice to see you guys doing a lot of work on stuff though. Good work.
Priorities....and noone has reported them to Medicare or the SEC as non-compliant software due to no audit log. Were they also hacked like Solarwinds? Who knows...and you'll never know because there's no audit logs!
Have y'all considered sending syslog data into a SIEM or utilizing a WAF like a FortiWeb which can protect against credential stuffing or block connections to it by poor IP rep?
I'm not excusing the fact that there is a lack of visibility by failing to add audit logs to it, right now we track sign-ins via Duo because we're using Duo for MFA & all authentication must be via MFA.
Unfortunately this isn't a find-a-workaround situation.
Legally speaking if you want to comply with HIPAA/FINRA/SOC/ISO compliance certification then:
If you want to use product x, it needs to do abc. If it doesn't, you can't use it. Audit trail with logs, held and maintained for 2+ years is part of that compliance.
If you use something not in compliance, your regulatory compliance is going fine you x dollars, hold you libel, and remove your compliance certification. No more business for you.
5 years old?
FIVE?
Is this serious? I'm setting up my cloud instance now, and this functionality still isn't available either by a trigger or integration?
What sort of nonsense is this?
FIVE!? come on ConnectWise - Trusted, world-class security that’s scalable? Really? its on your god dam home page!
Today (of all possibilities, on a PATCH TUESDAY morning), I woke up to the following response from my self-hosted SC installation: "Too many incorrect password attempts; you have been locked out". 6 YEARS with them, and it's the first time this happens...
Chat with a support rep, some rigmarole about needing to go through a back and forth Email exchange in which I confirm a COUPLE of times that I do, INDEED, want their assistance in resetting my Administrator password, which I am then instructed to perform myself by following these instructions: Forgot on-premises username or password
Then I ask, pretty reasonably IMHO, the following questions:
How can I determine WHEN those "incorrect password attempts" occurred, HOW MANY there were, and (if possible) which IP ADDRESSES they came from?
The response: "this is not possible as this would be a Feature Request", and I get the link to their Feature Request Portal, which quickly brought me HERE...
FIVE YEARS???!!! "Just Roadmapped" (but no timetable or delivery ETA)???!!! Grrrrr... As I expressed in my conclusion to the email support thread, I now feel EXTREMELY VULNERABLE...
I will set up a backup administrator account, probably implement a nightly SC folder backup to expedite recovery if this happens again, but I am extremely dismayed at the lack of attention this "feature request" has received over the last 5 years... :-(
You should be using two form authentication.. Lot's of horror stories of folks that don't use that...
They were using Connectwise Control without two form:
https://www.pcmag.com/news/ransomware-attack-hits-400-dental-offices-across-the-us
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.
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.
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
Renaming/not using "administrator" (admin, root, user, owner etc) as the username has been best practices recommendations in the computer industry for decades. Microsoft windows domain setup guides are the first I was exposed to the practice in the late 90's. They even have a GPO for auto-renaming computer "administrator" accounts on first joining the domain.
Using/having default usernames is bad.
Developers carving exception out of security features to allow uninformed admins to do bad security is worse and not much better than hidden backdoor passwords/access. Hackers will find, and exploit them.
Could Screenconnect have better onboarding/setup wizard to guide new installs on the path to better security? Yes. As we all know this is a product that has been around for long time now. I've already written up a different feature request about enhancing the "status" section so that best practice testing can be done at any time because in terms of hacker targets: Remote access/RMM system are priority one targets. Recent Solarwinds hacks show the best in the world hackers are on constant attack at those juicy targets.
David,
you are absolutely, 100% correct: I SHOULD have renamed "Administrator" from the beginning, and/or created another admin account to use as my normal ID - "live and learn", indeed. Still, we can hope for better logging, monitoring and self-defense features to appear in SC in the (near?) future...
Thanks again for all the enlightening posts in this thread. You *really* know your stuff...
See this thread and upvote: https://control.product.connectwise.com/en/communities/1/topics/65-add-the-ability-to-audit-login-failuressuccesses-for-logging-in-to-the-web-interface
"It has just hit QA. I expect that it will be available in a release in early Q2, barring any setbacks."
feature has been implemented in the newer stable release versions of control.
logging is available via the audit tab.
Thanks Cody - I see it in the web GUI - is there a API method created and documented to be able to call the audit query programmatically yet?
Hey Steve,
Not sure if I follow what it is you're trying to accomplish.
If you're looking to have this information easily accessible/searchable my suggestion will be utilize the syslog from Control & pipe the logs into your SIEM. potentially even set alarms for patterns of behavior.
Trying to figure a method to be able to query login events directly for quick and dirty reporting, rather than through a 3rd party (a la Syslog as you laid out).
You might be able to do it via API but that's nothing I've any experience with personally.
Next steps with this from Control's end developmentally would likely be add into the reporting the ability to show authentication failures/successes, as well as via the dashboard visualize on successful/failed logon attempts (with the ability for it to just from the dashboard click and tell ya what you need/want)
Good luck!
Hey there! Cody is correct, the next plan for the security events are to make them reportable (will be available soon). We will then work on adding security events to our Triggers, which is slated for later in Q3.
Will login attempts be sent to SYSLOG? I'm sure that is what everyone is waiting for
Hi Luke,
Once security events are triggerable, we'll be able to update the Syslog Ext.
Can this audit FAILED logins only? I see LOGIN attempt but I need to sift through them all to find if any failed. If this is possible, is there a way to create a trigger to email us on failed login attempts?
Event.EventType = 'LoginAttempt' AND Event.OperationResult = 'PasswordInvalid'
Thanks I did find a video on this later in the evening. Is there some way to allow this to report back even if the username is not valid? Anyone trying to get in brute force is more than likely NOT going to know our username.
I tried to use this event but it does not work Event.EventType = 'PasswordInvalid'
What about logging the real, source IP? CC only logs the reverse proxy's IP address even though my reverse proxies (I tested a couple of different ones) are sending the source IP in the headers (i.e. x-forward-for, real-ip, etc). Not very effective if you can't audit the source IP. Many customers put CC behind a WAF or rproxy.
Customer support service by UserEcho
