+84
Roadmapped

add the ability to audit login failures/successes for logging in to the web interface

Ryan 5 years ago updated by Aaron J. Apap 1 week ago 40 3 duplicates

add the ability to audit login failures/successes for logging in to the web interface

Available in Version:

Duplicates 3

+3

He would also like a trigger that sends him an email in case of login success/failure

+3

I like this idea,

Would be nice to have something like this to know if someone is attempting to abuse the service we would be able to take action.

Email notification if there are X amount of failed login attempts over X period of time.

+1

This information should be able to be obtained on the client machine directly as well, in case the machine isn't connecting to the server to provide it's information to be seen in the web interface.

Under Review
+2

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.





+1
Under Review
+1
Roadmapped
+1
Planning
+1
Under Review
+2
Considering for Future Release
+1

Seems like a no-brainer.

We have no way, from Screen Connect server, to determine if we are getting brute forced or not. 

+4

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. 

+3

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.

+8

...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.
+3

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.

+1

Yea, this has got to be an option ASAP! Otherwise we will have to move to a different solution!

+6

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

Could not agree more!

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 NEED this too.  I'm shocked 4 years later this STILL Is not an option.

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. =)

+1

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());
}

+1

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());
}

+3

...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....

+1

David,


I like how the page you linked still mentions the more secure self-hosted product, and server-level auditing!

https://imgur.com/a/eSAb0aA

+1

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.