- Winlogbeat Reference: other versions:
- Overview
- Getting Started With Winlogbeat
- Setting up and running Winlogbeat
- Upgrading Winlogbeat
- Configuring Winlogbeat
- Set up Winlogbeat
- Specify general settings
- Configure the internal queue
- Configure the output
- Configure index lifecycle management
- Specify SSL settings
- Filter and Enhance the exported data
- Define processors
- Add cloud metadata
- Add fields
- Add labels
- Add the local time zone
- Add tags
- Decode JSON fields
- Decode Base64 fields
- Decompress gzip fields
- Community ID Network Flow Hash
- Convert
- Drop events
- Drop fields from events
- Extract array
- Keep fields from events
- Registered Domain
- Rename fields from events
- Add Kubernetes metadata
- Add Docker metadata
- Add Host metadata
- Add Observer metadata
- Dissect strings
- DNS Reverse Lookup
- Add process metadata
- Script Processor
- Timestamp
- Parse data by using ingest node
- Enrich events with geoIP information
- Configure project paths
- Configure the Kibana endpoint
- Load the Kibana dashboards
- Load the Elasticsearch index template
- Configure logging
- Use environment variables in the configuration
- YAML tips and gotchas
- HTTP Endpoint
- winlogbeat.reference.yml
- Modules
- Exported fields
- Monitoring Winlogbeat
- Securing Winlogbeat
- Troubleshooting
- Get Help
- Debug
- Common problems
- Dashboard in Kibana is breaking up data fields incorrectly
- Bogus computer_name fields are reported in some events
- Error loading config file
- Found unexpected or unknown characters
- Logstash connection doesn’t work
- @metadata is missing in Logstash
- Not sure whether to use Logstash or Beats
- SSL client fails to connect to Logstash
- Monitoring UI shows fewer Beats than expected
- Not sure how to read from .evtx files
- Contributing to Beats
Community ID Network Flow Hash
editCommunity ID Network Flow Hash
editThe community_id
processor computes a network flow hash according to the
Community ID Flow Hash
specification.
The flow hash is useful for correlating all network events related to a single flow. For example you can filter on a community ID value and you might get back the Netflow records from multiple collectors and layer 7 protocol records from Packetbeat.
By default the processor is configured to read the flow parameters from the appropriate Elastic Common Schema (ECS) fields. If you are processing ECS data then no parameters are required.
processors: - community_id:
If the data does not conform to ECS then you can customize the field names
that the processor reads from. You can also change the target
field which
is where the computed hash is written to.
processors: - community_id: fields: source_ip: my_source_ip source_port: my_source_port destination_ip: my_dest_ip destination_port: my_dest_port iana_number: my_iana_number transport: my_transport icmp_type: my_icmp_type icmp_code: my_icmp_code target: network.community_id
If the necessary fields are not present in the event then the processor will silently continue without adding the target field.
The processor also accepts an optional seed
parameter that must be a 16-bit
unsigned integer. This value gets incorporated into all generated hashes.