- Exabeam Site Collector
- Network Ports
- Install the Exabeam Site Collector
- Filtering Incoming Syslog Events in Exabeam Site Collector
- Filtering Outbound Logs in Exabeam Site Collector
- How to Direct Kafka Input to Exabeam Site Collector
- Supported Exabeam Site Collector Changes
- Troubleshoot the Exabeam Site Collector
- Capture Site Collector Diagnostics Using Exabeam Support Package
- Scenario 1: No logs are transmitted nor received
- Scenario 2: Kafka Google Cloud Storage (GCS) collectors have not appeared on Data Lake UI
- Scenario 3: If logs are not uploaded to GCS where logs are not on Data Lake
- Scenario 4: Unable to accept incoming syslog, active directory context, Splunk logs, or Incident Responder integrations
- Scenario 5: Unable to pull LDAP from SaaS
- Scenario 6: Cannot send after transport endpoint shutdown
- Scenario 8: Too many arguments in command /tools/config.parser.sh
- Other scenarios
- How to Migrate to New Exabeam SaaS Site Collector
- How to Uninstall Exabeam Site Collector
- Exabeam Site Collector Services
Filtering Outbound Logs in Exabeam Site Collector
Exabeam Site Collector (SC) supports log filtering before uploading the logs to configured destinations. SC can drop entire events if filtering conditions are matched. SC uses Kafkabeat for the outbound message processing. Configurations are made in /opt/exabeam/beats/<TARGET>/worker/kafkabeat.yml
, where <TARGET>
is the folder that contains the SC destination setup.
The values in <TARGET>
are the following options based on your deployment:
For SaaS:
gcs1
andgcs2
For DL on-premises:
lms1
andlms2
The configuration resembles the following configuration block:
kafkabeat: inputs: - type: kafka ... processors: - drop_event: when: - <condition>
Kafkabeat does not parse the event. Rather, it sends the event as-is to the destination. Filtering is based solely on the message
field of an event. Listed in the following table are the five conditions in the message field that are supported:
Condition | Description | Condition Example |
---|---|---|
| Checks if a value is part of a field. The field can be a string or an array of strings. The condition accepts only a string value. | Check if an error is part of the event message contains: message: "Specific error" |
| Checks the field against a regular expression. The condition accepts only strings. | Check if the event regexp: message: "src_ip=192\\.168\\.\\d{1,3}\\.\\d{1,3}" |
| An operator that receives a list of criteria to match at least one of. | Determines match to either or: - contains: message: "[DEBUG]" - contains: message: "[TRACE]" |
| An operator that receives a list of criteria to match all of. | Determines match where both and: - equals: http.response.code: 200 - equals: status: OK |
| An operator that receives the condition to negate. | Drops event if not contains: message: "[ERROR]" |
Here is an example:
We need to filter out logs from a particular Filebeat that sends logs from a given IP address. The filter will match logs that contain the text [OBSOLETE]
in content or that comes from the Filebeat with ID 573d5253-4e4e-4fff-92a5-8f2f227b3af1
and IP address src_ip=195.164.*.*
.
A sample log resembles:
[OBSOLETE] - Mar 24 15:00:34 2020 rt=1585062034 device=110.90.230.153 name=Stephanie Kim
The filter is written to apply all three possible match criteria:
processors: - drop_event: when: or: - and: - contains: message: "\"id\":\"573d5253-4e4e-4fff-92a5-8f2f227b3af1\"" - regexp: message: "src_ip=195\\.163\\.\\d{1,3}\\.\\d{1,3}" - contains: message: "[OBSOLETE]"