Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 5 subscribers
  • Views 4586 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Issue with Carbon Black Defense

Alan Lehman

We are running an SG-310 with 9.601 as our primary firewall. Endpoint systems behind the 310 also have Carbon Black Defense sensor installed.

When I enable web protection on the SG-310, with only one host in the "allowed networks", many of our endpoint systems with Carbon Black hang and go to 100% CPU utilization. These systems are not on the allowed network list. I have searched the web filter log files for traffic from/to the hanging systems and can't find anything.

Web application control shows traffic to Carbon Black's update site, but it is showing as "pass" which it should be.

Nothing in IPS logs related to these systems.

Any ideas why web filtering would be interfering with Carbon Black sensor software?

Thanks,

Alan Lehman



This thread was automatically locked due to age.
Parents
  • 0

    For web filtering questions, it is always helpful to know proxy mode (standard or transparent) and https inspection mode (on or off).

    If you are seeing CarbonBlack traffic in the web filter logs, something is wrong with your Allowed Networks list so traffic is being sent through the web filter.   The log file has the values for srcip="address" filteraction="value" and policy="value".   That is your first clue.

    Add a firewall rule to allow-but-log any traffic going to CarbonBlack servers.   This will help (a) prove that traffic is flowing correctly when the web filter is bypassed, (b) prove that CarbonBlack is only using port 443, and (c) prove whether client devices are bypassing the webfilter as intended.

    Are you seeing any entries for CarbonBlack destinations with statuscode="407" (authentication required)?   You want to exclude any auto-update application from authentication.  Also exclude file checking, mime-type checking, and https inspection. 

Reply
  • 0

    For web filtering questions, it is always helpful to know proxy mode (standard or transparent) and https inspection mode (on or off).

    If you are seeing CarbonBlack traffic in the web filter logs, something is wrong with your Allowed Networks list so traffic is being sent through the web filter.   The log file has the values for srcip="address" filteraction="value" and policy="value".   That is your first clue.

    Add a firewall rule to allow-but-log any traffic going to CarbonBlack servers.   This will help (a) prove that traffic is flowing correctly when the web filter is bypassed, (b) prove that CarbonBlack is only using port 443, and (c) prove whether client devices are bypassing the webfilter as intended.

    Are you seeing any entries for CarbonBlack destinations with statuscode="407" (authentication required)?   You want to exclude any auto-update application from authentication.  Also exclude file checking, mime-type checking, and https inspection. 

Children
No Data
Unfiltered HTML