Jump to content

sinistersnowgod

Members
  • Posts

    20
  • Joined

  • Last visited

Posts posted by sinistersnowgod

  1. Ok... so I guess the best option for me at this time is going to be to adjust the XML file for the client which does work.  I can only think of two ways of doing that relatively elegantly but maybe you have another option?

    I can either change the server config to the publicly resolvable name for as long as it takes to generate the installation package so that the package contains the XML file with the correct URL... or on my software deployment platform (SCCM) I can create a software deployment package that installs Malwarebytes and then goes back in and overwrites the XML file with one that has the correct URL.

    I guess my question is, is there any easy way in the console to adjust the URL that will be in the XML file when generating the XML package without having to jump through those hoops every time we have a need to generate a new installation package?  Not the end of the world if we have to follow that process every time but just kind of messy.

     

    Thanks,

    Ian

  2. That's usefull information but I guess where I'm getting hung up is that I am using an FQDN... it's just not the FQDN of the local host as it is in the AD domain.  The AD domain has it's own DNS name that isn't publicly resolvable... so the internal FQDN of the server is complicatedservername.addomain.local.  The requisite ports for the clients are open to the server and a publicly resolvable DNS name is registered to the NAT address of the internal host IP.  The publicly resolvable "friendly" FQDN is mwbytes.publicdomain.com.  I'm using that FQDN in the configuration.  That FQDN is resolvable by the server and the clients... so that's where I'm confused because I believe that should work?

  3. Yeah actually it was already set to update from the internet and by changing it to update from the MBMC the client was able to successfully update so it probably is a proxy issue for the client which is easy for me to resolve and switch back to internet updates or at least have the internet update fallback work.

    So that's cool... making progress... but I'm still stuck with the issue of the "friendly" name not working.  When I change the server name to one that is publicly resolvable I get the "Registered server address cannot be found.  Please go to the Admin pane to modify the server address." error when running the management console... and I also need the friendly name to work so that clients on the internet can resolve it and check in.

  4. Yeah I'm basically trying to set it up to be accessible from outside the network for roaming clients and let internal clients reach out to it using split DNS.  The recommended model in the install guide is a violation of our n-tier security policy so I've decided to just put this thing on the internet and lose the AD integrated functionality and instead use SCCM to push and manage the client packages and have our internal clients reach out to the Malwarebytes server in the Internet Services zone rather than communicate with it internally, since if I put it internally I wouldn't be able to manage our external clients or have them connect back for updates.

    Usually products like this... whether it's Palo Alto Traps or AirWatch or whatever allow for kind of a split horizon... Traps for example has a listening service for roaming clients on a server facing the internet that writes to the same database as the internal management server but the installation guide for Malwarebytes doesn't seem to indicate that model is possible and suggests opening the firewall on 443 and 18457 to the internal server directly... which we would never do here and I would think that would not be an uncommon restriction.

  5. Ok... I found a way to get rid of the error however it is not a workable solution.  I changed the Server Address in Server Address Settings to match the local hostname of the server.... however this is a complex name and not resolvable outside of that AD domain.

    It needs to be able to work with the "friendly" name I've registered in DNS... which is split between public and private.  It is also the name for which I've issued the public certificate.

    So for example the server name is something like PMWBETPAV01.addomain.com.  The "friendly" name is mwbytes.fqdn.com

    So now that I've updated the server address I can run the console without error, however I still get the error on the client which is configured to connect to the friendly name.

  6. I've recently installed Malwarebytes for business and when I launch the Management console from the server I get the following error message:

    "Registered server address cannot be found.  Please go to the Admin pane to modify the server address."

    It will then successfully launch the console.  When running the console on a desktop for management purposes I get the same result.

    When trying to "Check for updates from a client" I get the error message "An error has occured. Please report this issue to our support team (include the content of all error message(s) and code(s) in your submission).

    PROGRAM_ERROR_UPDATING (11001, 0, Host not found)

    No such host is known."

    I've validated that DNS is correct and name resolution for the server host works fine... as evidenced by the ability to run the management console from a client even though it throws this error.

     

    Please advise.

     

    Thanks,

    Ian

     

     

     

    mgtconsole1.jpg

    mgtconsole2.jpg

  7. I read that document and it is kind of unrelated... I'm running Windows Server 2016 DataCenter and there isn't any problem with the SQL connection... the problem was on the contacting of the Malwarebytes servers during the installation process, for which I had to downgrade the security on the server to support TLS 1.0... the server once installed may support TLS 1.1 and 1.2 and the SQL connection looks fine... but you can't actually install the product without TLS 1.0 being supported because the licensing mechanism during installation in the installation package itself didn't seem support TLS 1.1 or 1.2 even though the licensing servers themselves do when I checked them with Qualys.  I think you're missing the TLS 1.1 and 1.2 support in the actual installation package but maybe not the product once installed...

     

    Thanks!

  8. Yeah in fact I just enabled TLS 1.0 on this server to test and was able to run through the installer... so you're licensing servers are trying to negotiate TLS 1.0 with the registering server and anyone who doesn't have TLS 1.0 negotiation enabled on their system will fail.  I'm surprised I'm the first one to find this since TLS 1.0 has been a security issue for some time now.

    https://www.nist.gov/oism/tls-10-being-turned-wwwnistgov

    I'm going to have to turn this back off due to our policy here... but I got the product installed.  I think you guys need to make sure TLS 1.1 or 1.2 is getting negotiated by those licensing servers in order to ensure licensing continues to work and so that other clients are able to register.

     

     

  9. Ok... found the log file... here's what looks like the pertinent part of it:

    "***MEEServer*** 2017-11-21 10:43:53.488: Testing Keystone connectivity
    MSI (s) (D0!8C) [10:43:53:488]: Closing MSIHANDLE (24) of type 790531 for thread 3212
    MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (25) of type 790531 for thread 3212
    ***MEEServer*** 2017-11-21 10:43:53.816: Exception thrown while testing Keystone connectivity: 
    System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
       at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)
       at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential)
       at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte& thumbPrint)
       at System.Net.Security.SecureChannel.GenerateToken(Byte input, Int32 offset, Int32 count, Byte& output)
       at System.Net.Security.SecureChannel.NextMessage(Byte incoming, Int32 offset, Int32 count)
       at System.Net.Security.SslState.StartSendBlob(Byte incoming, Int32 count, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte buffer, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
       at System.Net.TlsStream.CallProcessAuthentication(Object state)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
       at System.Net.TlsStream.Write(Byte buffer, Int32 offset, Int32 size)
       at System.Net.PooledStream.Write(Byte buffer, Int32 offset, Int32 size)
       at System.Net.ConnectStream.WriteHeaders(Boolean async)
       --- End of inner exception stack trace ---
       at System.Net.HttpWebRequest.GetResponse()
       at SC.Server.Setup.CustomAction.CustomActions.TestKeystone(Session session)
    MSI (s) (D0!8C) [10:43:53:816]: Closing MSIHANDLE (25) of type 790531 for thread 3212
    MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (26) of type 790531 for thread 3212
    ***MEEServer*** 2017-11-21 10:43:53.816: Done with Keystone test. Result: Failure"

     

    I would probably associate this with an SSL connection that is trying to negotiate an unsupported protocol or cipher.  So for example TLS 1.0 which has been deprecated and we disable via Group Policy.  Here are are the supported protocols and ciphers on the system this install is failing on... do you kno

  10. Ok... found the log file... here's what looks like the pertinent part of it:

    "***MEEServer*** 2017-11-21 10:43:53.488: Testing Keystone connectivity
    MSI (s) (D0!8C) [10:43:53:488]: Closing MSIHANDLE (24) of type 790531 for thread 3212
    MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (25) of type 790531 for thread 3212
    ***MEEServer*** 2017-11-21 10:43:53.816: Exception thrown while testing Keystone connectivity: 
    System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
       at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)
       at System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential& secureCredential)
       at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte& thumbPrint)
       at System.Net.Security.SecureChannel.GenerateToken(Byte input, Int32 offset, Int32 count, Byte& output)
       at System.Net.Security.SecureChannel.NextMessage(Byte incoming, Int32 offset, Int32 count)
       at System.Net.Security.SslState.StartSendBlob(Byte incoming, Int32 count, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte buffer, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
       at System.Net.TlsStream.CallProcessAuthentication(Object state)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
       at System.Net.TlsStream.Write(Byte buffer, Int32 offset, Int32 size)
       at System.Net.PooledStream.Write(Byte buffer, Int32 offset, Int32 size)
       at System.Net.ConnectStream.WriteHeaders(Boolean async)
       --- End of inner exception stack trace ---
       at System.Net.HttpWebRequest.GetResponse()
       at SC.Server.Setup.CustomAction.CustomActions.TestKeystone(Session session)
    MSI (s) (D0!8C) [10:43:53:816]: Closing MSIHANDLE (25) of type 790531 for thread 3212
    MSI (s) (D0!8C) [10:43:53:816]: Creating MSIHANDLE (26) of type 790531 for thread 3212
    ***MEEServer*** 2017-11-21 10:43:53.816: Done with Keystone test. Result: Failure"

     

    I would normally associate this with an SSL connection that is trying to negotiate an unsupported protocol or cipher.  So for example TLS 1.0 which has been deprecated and we disable via Group Policy.  Here are are the supported protocols and ciphers on the system this install is failing on... but I also see that the licensing systems allow for our supported protocols and ciphers so not sure why this is failing just yet...

     

     

    ciphers.jpg

  11. I imported all those into the local machine trusted root store... same error.  I still think this is somehow related to the fact that when I run this doing an netstat I see that redirection to the AWS hosts by the installer, not a proxy... and that those AWS hosts have the keystone.mwbsys.com certs applied which is mismatched with the AWS hostname.  This is true from the server host I'm attempting to install on, and from any other host or network I've tried including my house.  If you go to  https://ec2-54-175-208-50.compute-1.amazonaws.com/  I imagine you will see this as well?

    Thanks...

    cert3.jpg

  12. Negative... that was my first thought but I validated this server is part of our WCCP bypass ACL, the whole VLAN is and is rather just blocked on outbound 80/443 unless an exception is granted and the firewall opened which in this case it is.  It's also easy enough to see from the browser because when you are getting SSL inspection you get the intermediate certificate in the chain visiting any SSL site which is also not the case here.  I set up the Triton system doing the inspection so I always start with that if I'm having any issues with an SSL communication.

    I still don't get why Malwarebytes would have a mismatched certificate on the AWS hosts the licensing is calling?  Why not just fix that?

  13. I have recently purchased and am trying to install the Malwarebytes Management Server and am receiving the error "Unable to contact license validation servers (https://keystone.mwbsys.com).  Please check your connection.

    The server I'm on has access to the internet.  It appears that there is a certificate mismatch on the AWS systems licensing redirects to, specifically https://ec2-54-175-208-50.compute-1.amazonaws.com/ which has a mismatched certificate address for a wildcard cert issued to *.mwbsys.com.  

    Please advise.

    cert2.jpg

    cert1.jpg

  14. I'm experiencing the same issue trying to install the Malwarebytes Management server for the first time.  I have an SSL decryption bypass for the source of the server on my content proxy so I'm positive that's not the issue.  It appears that the Amazon Web Services hosts handling the licensing have hostname conflicts with the certificates being issued which is causing the problem and is resulting in local security policy blocking the connection (as it should!). 

    cert1.jpg

    cert2.jpg

Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.