Activation Failed

[BRAM]

We have PC's on our network that are blocked from the Internet by design. They do still have email accounts on our Exchange server, so they can and do get infected emails. On the PC's without Internet access, the Anti-Ransomware client will not run. We get a message that license activation failed. What site is the client trying to talk to so I can add an exception to the firewall rules?

 

Thanks,

Brad

[1PW]

Hello @BRAM:

Reference: Malwarebytes Anti-Ransomware Administrator Guide

Please consult page 2, External Access Requirements, to find the six (6) URLs that need permission.

Thank you.

Edited January 5, 2017 by 1PW

[BRAM]

Just to let you know, those 6 URL's alone are not all I had to configure to allow through the firewall. I also had to allow ec2-52-3-62-78.compute-1.amazonaws.com before it would work. You may want to add that to your documentation.

[djacobson]

We cannot recommend that URL because that won't be the same for everyone. That extra one you had to do is going to be based on whichever CDN you are resolving to in your proximity. It is also dependant on your hardware appliance or software firewalls config and if you are using SSL inspection or not on that firewall. Our product expects the SSL packet to be a certain way, if your firewall is changing anything about it, the software will reject the received packet. You can see these SSL connection resets in Wireshark while following the TCP stream.

Basically if the external access URL's do not work right away, it is because your particular network appliance/app needs extra configuration of which we cannot advise as each product will have different options/features and will handle the SSL in different ways. For anyone else that comes across this thread while searching the same issue, I would recommend consulting your product vendor to see how they would suggest you perform the whitelist and any possible extra settings needed.

[Piper]

Dear Dyllon and Malwarebytes Staff,

We've started to deploy the new version of the endpoint security to our client computers and little bit disappointed that ARW is not included in the managed solution. However, it's better having than nothing, so we deployed it across and believe to be in the 50% till late. It's unfortunate that one of the Managers in the Top Management is having the activation issues.

He has Windows 7/64 and having the same as the rest of the IT personnel with unmanaged product installation. We all have successful install except for him and very unfortunate, as we've just started deploying to top management this afternoon.

Any idea why it's having the attached error?

Sincerely looking forward to your return.

Thanks,

Piper

[BRAM]

Piper,

On the PC's experiencing the activation issue, make sure they can access the URL's listed below. I had to create rules in our firewall to explicitly allow access to these URL's. Once I did that, the activation errors went away.

data.service.malwarebytes.com

data-cdn.mbamupdates.com

keystone.mwbsys.com

sirius.mwbsys.com

meps.mwbsys.com

blitz.mb-cosmos.com

 

Edited June 29, 2017 by BRAM
screen shot was lost on original post.

[Piper]

17 minutes ago, BRAM said:

Piper,

On the PC's experiencing the activation issue, make sure they can access the URL's listed below. I had to create rules in our firewall to explicitly allow access to these URL's. Once I did that, the activation errors went away.

data.service.malwarebytes.com

data-cdn.mbamupdates.com

keystone.mwbsys.com

sirius.mwbsys.com

meps.mwbsys.com

blitz.mb-cosmos.com

 

Dear BRAM,

We did the installation outside the secure network perimeter and as mentioned unmanaged, so firewall is not causing the issue and thing for sure is that we've checked that he can access the Internet without restrictions and freely, why there is no reason that he cannot access mentioned URLs. Also as mentioned, we did the same with the IT computers who loves to work without network boundaries, so diving deep into logs is the next thing to do. However, since we have a jet setter, it's very hard to get in touch or have his unit checked for long a time. Again, it's kinda weird and for whatever reason, is the thing we need to escalate.

[Piper]

5 minutes ago, Piper said:

Dear BRAM,

We did the installation outside the secure network perimeter and as mentioned unmanaged, so firewall is not causing the issue and thing for sure is that we've checked that he can access the Internet without restrictions and freely, why there is no reason that he cannot access mentioned URLs. Also as mentioned, we did the same with the IT computers who loves to work without network boundaries, so diving deep into logs is the next thing to do. However, since we have a jet setter, it's very hard to get in touch or have his unit checked for long a time. Again, it's kinda weird and for whatever reason, is the thing we need to escalate.

Dear BRAM,

Thanks for you reply, forgot to mention. Will double check on above too.

Just reading the manual and on page 2, where did you get the other 3 URLs?

I can only see these:

https://data.service.malwarebytes.org Port 443 outbound

https://data-cdn.mbamupdates.com Port 443 outbound

https://keystone.mwbsys.com Port 443 outbound

Thank,

Piper

 

[BRAM]

1 hour ago, Piper said:

Dear BRAM,

Thanks for you reply, forgot to mention. Will double check on above too.

Just reading the manual and on page 2, where did you get the other 3 URLs?

I can only see these:

https://data.service.malwarebytes.org Port 443 outbound

https://data-cdn.mbamupdates.com Port 443 outbound

https://keystone.mwbsys.com Port 443 outbound

Thank,

Piper

 

Piper,

I can't remember for sure where I got the other URL's. It was either in their documentation or from a network trace. I do know it doesn't work without them for us.

[djacobson]

The documentation suggests whitelisting *.mwbsys.com, which covers keystone, sirius and meps. The full list is provided by those of us in business support if requested and the standard ones in the documentation prove to not work via a Wireshark log. Very rarely would you need the whole thing. The biggest thing that trips up people's ability to verify against keystone is the program's MITM protection bumping up against some feature in their network appliance. The programs are extremely sensitive to any SSL packet inspection features on next gen firewalls. SSL packet inspection can alter the header and cause the program to drop the packets after the SSL handshake. It may be brazen to say this but it is the truth, difficulty in the ability to reach the activation servers has 100% been because of something in the customers environment, every time, for all support tickets opened regarding this issue since the introduction of the license enforcement.

https://data-cdn.mbamupdates.com Port 443 outbound
https://data-cdn-static.mbamupdates.com Port 443 outbound
https://keystone.mwbsys.com Port 443 outbound
https://sirius.mwbsys.com Port 443 outbound
https://meps.mwbsys.com Port 443 outbound
https://hubble.mb-cosmos.com Port 443 outbound
https://blitz.mb-cosmos.com Port 443 outbound
https://telemetry.malwarebytes.com Port 443 outbound

[Piper]

Guys,

Thanks for everything. It's weird however, a simple solution and hope can help other license holders as well. Maybe we've got strict carrier after all and best solution we've done was to point the DNS to Google and solved the issue.

Case closed. 

Piper