IMPORTANT ANNOUNCEMENT: On May 6, 2024, Carbon Black User eXchange (UeX) and Case Management will move to a new platform!
The Community will be in read-only mode starting April 19th, 7:00 AM PDT. Check out the blog post!
You will still be able to use the case portal to create and interact with your support cases until the transition, view more information here!

Action Required for Upcoming Carbon Black Cloud 3.6 Windows Sensor Release

Action Required for Upcoming Carbon Black Cloud 3.6 Windows Sensor Release

The 3.6 Carbon Black Cloud Windows sensor uses a content management system to enable dynamic configuration of prevention features.

For the 3.6 sensor to be fully functional, customers who have restrictive firewall policies must add a new exclusion prior to installing or upgrading to 3.6. These customers must add a new network/proxy exclusion for “”.

The following features require the exclusion or they will not work with the 3.6 sensor: Enterprise EDR, Device Control, AMSI Prevention, and Unified Binary Store.


What port? 443?

@assafefrat Yes, it is Port 443.

Is 54443 used as a backup port?

Clarifying question:
Do we need to exclude inspection of all traffic to/from this host?
SSL Decryption Exception?
or do we just need to not block traffic?

Are those listed features going to be part of Endpoint Standard?

SSL Inspection bypass on the Proxy or Full traffic Bypass ?

I would also know if SSL inspection would break the connection or not. i.e. Does the agent use the root cert store on endpoints to validate AND would it also require turning off Authentication through the proxy as well?



The should have come with an example and CB should have explained why it is needed.

Yes, why is an exclusion needed.  example please.....

A screenshot would be great.

If it helps others, I spotted issues CB Defense updating with zscaler.
I had to bypass '' from SSL interception in order for the udpates to work.

Same issue here with zscaler, we must bypass  

Carbon Black

You dropped the ball big time on effective communication.  

From you poorly written release notes for 3.6.

Firewall exclusion

The 3.6 Windows sensor leverages a content management system to enable the dynamic configuration of prevention features. Prior to installing or upgrading to 3.6, if you have restrictive firewall policies active in your environment, you might need to add a new firewall/proxy exclusion for the sensor to be fully functional.

Add a new network/proxy exclusion for a direct connection over TCP/443 to 

Enterprise EDR, AMSI Prevention, and Unified Binary Store require the exclusion to work with the 3.6 sensor. 

Please answer these VERY IMPORTANT questions

Which Firewall?  The endpoint or the company egress firewall.  Big difference.

Is this an inbound or outbound connection?

How about you provide Step by Step screenshots.

Carbon Black

Another thing you must give information on: 

How will we know if the firewall exclusion is required in our environment? 

Where would we look in the CB console to is see if these new features are working or not working? 

@esullivan Can we please get an update on this? I know you're just the messenger, but it seems that everyone has the same concerns, and I would imagine that the product team has ready answers on this that just weren't communicated. Please relay this to them so they can provide better guidance.

I don't see any mention of Cb Defense (new name Endpoint Standard). Does it apply to this as well?

@assafefrat Port 54443 is used as a backup port for sensor communications ( for example).

@nolsen @jfaulhefer  You will want to exclude all of our URLs from any SSL inspection/encryption/decryption, and allow a direct connection. Both incoming and outgoing are required as TCP require bi-directional communication.

@ken9k @lourenco_tf AMSI Prevention will be a part of Endpoint Standard, and therefore is included in this new exception:

@Navar_Holmes @tdorsch If you are running any 3.6 sensors and either Enterprise EDR or Endpoint Standard, you will want to exclude the new URL, as it is required for the new features. The Release Notes I linked directly above will explain the new features in a bit more detail. These changes are required on your network firewall, and both incoming and outgoing are required as TCP require bi-directional communication.

I would recommend that anyone with outstanding questions in regards to this new firewall exception, go and open a case with Customer Support and they will be able to help assist with any further questions:

@cfanion, thank you for your prompt response- this is the confirmation I think we were looking for. Correct me if I'm wrong, but to sum up:

  • If you are running restricted end point firewalls, everything should remain the same (outbound ports TCP 443/ 54443) from the sensor.
  • If you are doing perimeter  man-in-the-middle SSL decryption, then will need to be treated the same way that "*" currently is treated- which should be outbound SSL inspection bypass over TCP 443/54443. Inbound technically isn't needed because a hole is opened in the firewall when the sensor reaches out, al la TCP.

I'm excited to see what the new AMSI features bring.

@firstguy Both are correct! Although 54443 will only be needed for the devices URL as outlined in:

443 is all that is required for the other URLs. 

If I may provide some feedback in regards to the Sensor configuration, please cover scenarios where proxy servers are utilized. Not every company is going to permit their endpoints to communicate directly to the internet, so security gateways/proxies are going to be utilized. 

For windows systems, the sensor should be referring to the system (IE/Edge) proxy settings.

In every case where I've raised a support ticket, I've explained that we use proxies, and the response is almost always 'please ensure your endpoints can communicate directly with the internet'. And we go back and forth about our use of proxies. It adds lots of lost time trying to resolve the case, as we go back and forth.

In scenarios where proxies change, I've seen many cases where despite going through the registry to ensure there's absolutely no reference to the old proxy, we still see the sensor talking to the old proxy.. 

it really needs to be improved.

If you are a Cisco Firewall user you will need to add all the carbonblack URLs not just, to multiple location within the Cisco firewall.  This is because carbonblack is not fully trusted by Cisco.  As a note carbonblack needs to partner with Cisco Threat Defense.

If you are using Cisco Firewall the process that a URL/domain is checked:  (if you are using these features)

1st DNS Policy

2nd Access Control Policy - Security Intelligence

3rd Access Control Policy - Rules.  Your traditional URL approved list.




I've received notification:

We have identified that some of your recently deployed or updated endpoints running the Carbon Black Cloud Windows 3.6 sensor are unable to communicate with This connectivity is required to deliver certain functionality of the 3.6 sensor. To enable connectivity, update your firewall configuration.


My environment is divided in a bunch of small parts, so it's pretty difficult to keep an eye on every possible firewall out there.

If you are mentioning "We have identified that some of your recently deployed or updated endpoints ... are unable to communicate with" - is there a way to determine, which endpoints exactly do have this problem?



I'm assuming that you need a rule on both pc and perimeter firewalls to allow this outgoing traffic.

I'm going to push an update to one station and test this change and will report back.


I would recommend if you have not done so yet is to add all the CB URLs to your corporate firewall approved list.

Depending on how your firewall and other edge protection devices work together, you might need to add the URLs to multiple locations.

The last thing you need is your end points having inbound and/or outbound communication issues with CB Mothership.  And even more so if one or more of the CB URLs end up on a denied list.

You might even think about adding to this list also as it has been on Cisco Talos Intelligence block list.


Good afternoon, 

Just wanted to shed some light on the URL's.  You will not need to have any of the Prod0x URLs that your orginization is not on.  For example, if your are North America based and on Prod05, there will not need to be a extra entry on your firewall for any of the other Prod0x URLs.

Just for reference, in case anyone did not see this...

Have a great day!

Good afternoon All,

Installed on one station version took some time and was successful with no need to change firewalls, now pushing to more stations.

It depends on  other security tools and their configs. So if you are limiting traffic by inspecting it using proxy, then you will need to skip Cb url's destinations and allow free traffic.

Good luck!

Article Information
Creation Date: