I recently set up Winlogbeat with Sidecar on my Windows Server and I am trying to send specific Event ID logs to my Graylog server. However, according to Elasticsearch’s website, I cannot include more than 22 event ids in winlogbeat configuration, as the maximum number of Event IDs that can be filtered in a query on Windows is 22 and anything beyond that will result in the query being dropped.
Is there a way for me to send more than 40 Event IDs (all located in the security section) with Winlogbeat? I am currently using Graylog version 5 and Winlogbeat version 1.4.
Here is my Winlogbeat configuration for reference:
Thanks for the post, and welcome to the Graylog Community!
We have several practitioners here who can help you with your question. I’ll start the responses you’ll likely get by offering my suggestions. I hope these help.
One way to work around the 22 event ID limit is to break them into multiple Winlogbeat configurations, each including no more than 22 event IDs. You can then send the logs to different Graylog inputs and use the Graylog pipeline processor to combine them into a single stream.
Another alternative is to use Logstash as a processing intermediary, allowing you to process and aggregate the logs before sending them to Graylog. Logstash has a higher event ID limit, and you can use it to filter and aggregate the logs based on specific conditions, such as Event ID, before forwarding them to Graylog.
I have not tested this but based on an extensive github winlogbeat config file by JHotchwad I was looking at recently - located here - you can list Security multiple times with only <=22 event-ID’s in them. There are a lot of cool little details in this config file for manipulating what you are sending into Graylog there. NOTE: you can do event-ID ranges such as: 4780-4782
Alternatively you can take the approach of using winlogbeats to drop the event-ID’s that are not needed/chatty, then in Graylog, create a pipeline that handles the Event-ID’s that you are interested in and at the end of the pipeline drop the message that doesn’t match any of the Event-IDs that you are interested in. This way, when you are interested in a new Event-ID, you only have to create a pipeline rule to handle it.