Bitdefender GravityZone Input
The Bitdefender GravityZone input supports collecting logs published from Bitdefender GravityZone using their Event Push service. Once set up, Bitdefender will post batches of CEF messages to the Graylog input.
Prerequisites
Before proceeding, ensure that the following prerequisites are met:
-
You must have a Bitdefender GravityZone subscription.
-
The Bitdefender Push service must be able to forward to an endpoint in your environment that is secured with TLS 1.2 or greater.
-
We strongly recommend using the Authorization Header option when setting up the Bitdefender GravityZone input to ensure message requests are authenticated.
Required Third-Party Setup
To enable integration, complete the following required setup with your third-party service:
-
Set up the GravityZone Push service to send logs to Graylog.
-
Set up your endpoints. GravityZone Push requires using GravityZone API endpoints. Refer to the Bitdefender documentation for guidance on interacting with the API.
-
Authenticate API requests with a Base64-encoded API Key (followed by a trailing colon). Generate this API Key under My Account > API keys in the GravityZone User menu.
-
The setPushEventSettings request must be used to create the needed configuration for GravityZone to send logs to Graylog. Set the following options:
-
serviceType: cef -
serviceSettings:-
url: The URI where the Graylog Bitdefender GravityZone input is listening for requests. The URL should include the/bitdefenderroot path where the Graylog input listens. e.g.https://graylog-host:port/bitdefender. -
authorization: A password value matching the value set in the Graylog input Authorization Header Value configuration option. -
requireValidSslCertificate: true
-
-
An example request may look as follows:
curl -i -X POST https://cloud.gravityzone.bitdefender.com/api/v1.0/jsonrpc/push \
-H "Authorization: <base64-encoded GravityZone API Key followed by trailing colon>" \
-H "Content-Type: application/json" \
-d '{
"params": {
"status": 1,
"serviceType": "cef",
"serviceSettings": {
"url": "https://<graylog-host:port>/bitdefender",
"authorization": "<Graylog input Authorization Header Value value>",
"requireValidSslCertificate": true
},
"subscribeToEventTypes": {
<include desired event types>
}
},
"jsonrpc": "2.0",
"method": "setPushEventSettings",
"id": "d0bcb906-d0b7-4b5f-b29f-b2e8c459a2df"
}'
Once the configuration is complete, the sendTestPushEvent API request can be used to send a test message to Graylog.
Input Type
This Input is a
Input Configuration
Follow the input setup instructions. During setup of this input, you can configure the following options:
| Parameter | Description |
|---|---|
|
Global (Checkbox) |
Select this check box to enable the input on all Graylog nodes, or keep it unchecked to enable the input on a specific node. |
|
Node |
Select the node on which the input should start. |
|
Title |
Enter a unique name for the input. |
|
Bind Address |
Ensure that Bitdefender GravityZone can route through your network to the IP address and port specified. Note that this input listens for HTTP requests at the |
|
Port |
Enter the IP address and port on which the Zookeeper server is running. |
|
Timezone |
Select the timestamp configured on the system sending the log messages. If the sender does not include the timezone information, you can configure the timezone applied to the messages on arrival. That configuration does not overwrite the timezone included in the timestamp; however, it is the assumed timezone for messages that do not include timezone information. |
|
Receive Buffer Size (optional) |
Depending on the amount of traffic being ingested by the input, this value should be large enough to ensure proper flow of data but small enough to prevent the system from spending resources trying to process the buffered data. |
|
No. of worker threads (optional) |
This setting controls how many concurrent threads are used to process incoming data. Increasing the number of threads can enhance data processing speed, resulting in improved throughput. The ideal number of threads to configure depends on the available CPU cores on your Graylog server. A common starting point is to align the number of worker threads with the number of CPU cores. However, it is crucial to strike a balance with other server demands. |
|
TLS cert file (optional) |
The certificate file that is stored on a Graylog system. The value of this field is a path ( |
|
TLS private key file (optional) |
The certificate private key file that is stored on a Graylog system. The value of this field is a path ( |
|
Enable TLS (Checkbox) |
Select this option if this input should use TLS. |
|
TLS key password (optional) |
The private key password. |
|
TLS client authentication (optional) |
If you want to require authentication, set this value to optional or required. |
|
TLS Client Auth Trusted Certs (optional) |
The path where client (source) certificates are located on a Graylog system. The value of this field is a path ( |
|
TCP keepalive (Checkbox) |
Enable this option if you want the input to support TCP keep-alive packets to prevent idle connections. |
|
Enable Bulk Receiving (Checkbox) |
Enable this option to receive bulk messages separated by newlines (\n or \r\n). |
|
Enable CORS |
Allows Cross-Origin Resource Sharing (CORS), enabling requests from external domains. |
|
Max. HTTP chunk size (optional) |
Sets the maximum size for each HTTP data chunk to control memory usage and throughput. For large data, it is common practice to chunk smaller blocks (e.g. 8KB or 64KB chunks) to prevent overwhelming buffers. The maximum HTTP chunk size is 65536 bytes. |
|
Idle writer timeout (optional) |
The maximum amount of time the server will wait for a client to send data when writing to an output stream before closing the connection due to inactivity. |
|
Authorization Header Name (optional) |
Specify a custom authorization header name to optionally enforce authentication for all received messages. This is a way to add password-like security for this input. |
|
Authorization Header Value (optional) |
Specify the authorization header value to optionally enforce authentication for all received messages. |
|
Take original client IP from X-Forwarded-For or Forwarded headers (Checkbox) |
Enables Graylog to extract the client’s real IP address from proxy headers instead of the direct connection IP. |
|
Only allow trusted proxies (Checkbox) |
Ensures that only defined and trusted proxy servers are accepted when providing client IP information, preventing spoofed headers. |
|
Enable trusting the original client IP header(s) (Checkbox) |
Allows Graylog to trust and use client IP addresses specified in configured headers. |
|
Header(s) containing the original client IP (optional) |
Defines the specific HTTP header(s) that carry the original client IP address when requests are passed through proxies. |
|
Locale (optional) |
This setting is used to determine the language of the message. |
|
Use full field names (Checkbox) |
When enabled, Graylog preserves the complete original field names from the incoming message instead of shortening or normalizing them. |
Next Steps
After you complete input setup, visit Input Diagnosis for testing and validation of the new input. Use this functionality to help troubleshoot any connection issues.
Further Reading
Explore the following additional resources and recommended readings to expand your knowledge on related topics:
