Posted on June 27, 2016
The Carbon Black Developer Network is proud to announce a new major release of the Carbon Black Event Forwarder, 3.2.0. The Carbon Black Event Forwarder is a standalone service that will listen on the Carbon Black enterprise bus and export events (both watchlist/feed hits as well as raw endpoint events, if configured) in a normalized JSON or LEEF format. The events can be saved to a file, delivered to a network service or archived automatically to an Amazon AWS S3 bucket. These events can be consumed by any external system that accepts JSON or LEEF, including Splunk and IBM QRadar.
This release adds two major features:
See the changelog below for more detailed technical information each of these features.
For more information on the Event Forwarder:
This is a major new release with two new features:
In Cb Response 5.2, a new “raw sensor exchange” has been introduced for customers that are subscribing to all endpoint events. Previously, the server would receive the data from sensors, unpack all the events and resend them individually over the message bus. The large volume of very small messages introduces a large overhead.
The new “raw sensor exchange” solves this problem in two ways: first, it greatly reduces the volume of messages broadcast over the bus by sending batches of sensor messages instead of a single message at a time. Additionally, these messages are compressed, further saving network bandwidth.
It’s recommended that you consider using the raw sensor exchange if you are subscribing to the filemod, regmod, or moduleload event types. If you are subscribing to lower volume message types such as procstart, then the original message exchange is more efficient.
To enable the raw sensor exchange, first uncomment the
use_raw_sensor_exchange option in
cb-event-forwarder.conf. Then enable the exchange in the Carbon Black server by adding a
EnableRawSensorDataBroadcast=true line in
/etc/cb/cb.conf on the Cb Response server (including any minions in a cluster). Restart the Carbon Black services then the raw sensor exchange will be enabled.
Event Forwarder 3.2.0 introduces TLS encryption support for syslog destinations. The Forwarder can use SSL client certificates for mutual authentication and the SSL server validation is completely configurable as well. To use TLS syslog support, set the
syslog and set
syslogout to the protocol, hostname and port for the remote syslog server. See the below configuration file for details.
In addition, the new Event Forwarder has enhanced network output including reconnection logic if the connectivity to the remote log destination is lost. All network based output types: tcp, udp, and syslog now use the enhanced reconnection logic.
See the following configuration file snippet for more information on configuring TLS parameters for the new syslog protocol.
# options for syslog output # syslogout: # uses the format <protocol>:<hostname>:<port> # where <protocol> can be: # tcp+tls: TCP over TLS/SSL # tcp: plaintext TCP # udp: plaintext UDP # example: # tcp+tls:syslog.company.com:514 syslogout= [syslog] # Uncomment ca_cert to specify a file containing PEM-encoded CA certificates for verifying the peer # server when using TLS+TCP syslog # ca_cert=/etc/cb/integrations/event-forwarder/ca-certs.pem # Uncomment tls_verify and set to "false" in order to disable verification of the peer server certificate # when using TLS+TCP syslog # tls_verify=false # Uncomment client_key and client_cert and set to files containing PEM-encoded private key and public # certificate when using client TLS certificates when using TLS+TCP syslog # client_key=/etc/cb/integrations/event-forwarder/client-key.pem # client_cert=/etc/cb/integrations/event-forwarder/client-cert.pem