Carbon Black EDR (Endpoint Detection and Response) is the new name for the product formerly called CB Response.
Edit /etc/cb/cb.conf: add/uncomment the following line:
DatastoreBroadcastEventTypes=*
Take note of the RabbitMQ configuration in /etc/cb.conf: look for the lines that start with RabbitMQ. You are looking for the following- we will use those shortly to connect to the event bus.
RabbitMQPort
RabbitMQUser
RabbitMQPassword
Add the following to /etc/sysconfig/iptables right below the line with —dport 443 in order to enable communication with the RabbitMQ broker:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5004 -j ACCEPT
Restart the cb-enterprise and iptables services
service iptables restart
service cb-enterprise restart
At this point, the RabbitMQ broker is available for connections from external clients.
The Event Forwarder is the most straightforward way to get JSON-formatted events from the event bus.
If you want to develop against the event bus API directly, then you can use the eventBusToJson.py Python script to
act as a consumer of the event bus and print out the events in real time as they’re received by the server.
To start, you’ll need a system with Python 2.7 installed. The most straightforward way to run through this is to have a VM or physical machine with CentOS 7 installed. Ensure pip is installed
easy_install pip
Clone the cbapi repository on your local machine and cd into it:
git clone https://github.com/carbonblack/cbapi-python.git
cd cbapi
Install the dependencies
pip install -r server_apis/python/requirements.txt
Run the script
cd server_apis/python/example/bulk
./eventBusToJson.py –u cb –p <RabbitMQPassword> -c https://<CB Server DNS/IP address>
The script will now output JSON structures for every event that’s processed through the CB server on stdout.
Here is an example event:
{
"sensor_id": 1,
"event_type": "childproc",
"created": true,
"timestamp": 1435343070,
"child_process_guid": "00000001-0000-0e0c-01d0-b03d57c1746b",
"process_guid": 6217766278483900149,
"type": "ingress.event.childproc",
"md5": "98FA788238E71D9563D4BF177A4FC22C"
}Most syslog servers cannot handle the intense load that we will place on them. For example, just on my test CB server with 2-3 clients, I received multiple errors while testing the script pushing to the local rsyslog daemon on the CB server, such as:
Jun 26 14:21:53 cbtest rsyslogd-2177: imuxsock begins to drop messages from pid 37864 due to rate-limiting
You will also encounter some issues with the size of syslog messages; most syslog servers will silently truncate messages larger than a set size (usually around 500 bytes-1kb). As a result of these issues I would strongly suggest not using syslog as your event queue between CB and your analytics/data storage platform.
Requesting large numbers of process documents in a single query will cause timeouts, so you will want to request data in smaller batches.
The most straightforward way to do this - if you intend to iterate over all results of a query - is to use the
process_search_iter helper function. It takes the same arguments as process_search, but returns an iterator of
process dictionaries instead. So you could do something like:
for process in process_search_iter(‘mysearch’):
print process[‘start’], process[‘path’]
Another way to increase the speed of API calls is to disable faceting, if you’re not using that feature. Append the facet_enable=False option to process_search or process_search_iter.