manu
04/07/2021, 9:56 AMJuan Alvarez
04/08/2021, 3:49 PMevent_optimize
events start triggering again... in your test did you have 4.7.0 + event_optimize
enabled? Also, do you (or anybody else) know what is the drawback of disabling events_optimize
?theopolis
04/08/2021, 4:44 PM*_events
tables are "buffers" of events published by the operating system and the scheduled queries essentially list those buffers. When --event_optimize
is enabled the "list" behavior turned into a "drain" behavior. The expectation is that a scheduled query will not return the same buffered event twice.Juan Alvarez
04/08/2021, 4:48 PM--events_expiry=1
give me a similar behavior?manu
04/09/2021, 12:02 PMevents_expiry
? I checked the logs you shared in github issue that seems to indicate the same. This might lead to older events from not being picked up in the queries being run.
I0408 15:52:27.529646 20352 eventsubscriberplugin.cpp:438] Found 26 events for subscriber WindowsEventLogPublisher.windows_events
I0408 15:52:27.533550 20352 eventfactory.cpp:351] Subscriber expiration is too low: windows_events
The buffered events will eventually expire! The --events_expiry flag controls the lifetime of buffered events. This is set to 1 day by default, this expiration occurs when events are selected from their subscriber table. For example: the process_events subscriber will buffer process starts until a query selects from this table. At that point all results will be returned and immediately after, any event that happened time-86400 seconds ago will be deleted. If you select from this table every second you will constantly see a window of 1 day's worth of process events.
Juan Alvarez
04/09/2021, 1:38 PMtheopolis
04/09/2021, 2:33 PMwindows_events
table?Juan Alvarez
04/09/2021, 2:39 PMSELECT *, "events_windows." || lower(source) || "." || eventid as __devoSubTag FROM windows_events WHERE source IN ('Application', 'Setup', 'Security', 'System');
SELECT *, "events_windows.powershell" || "." || eventid as __devoSubTag FROM windows_events WHERE source IN ('Microsoft-Windows-PowerShell/Operational', 'Microsoft-Windows-PowerShell/Admin');
SELECT *, "events_windows.other_sources" || "." || eventid as __devoSubTag FROM windows_events WHERE source Not IN ('Application', 'Setup', 'Security', 'System', 'Microsoft-Windows-PowerShell/Operational', 'Microsoft-Windows-PowerShell/Admin');
Basically they just depend on the source
fieldtheopolis
04/09/2021, 6:21 PMJuan Alvarez
04/10/2021, 7:28 PMtheopolis
04/10/2021, 11:43 PM--events_optimize=false
. This is because the scheduler is treating the query like a normal differential query and it is only logging the "new" events.
This works for you now, but in the background osquery is doing a lot of comparison work to determine what events it should log. This is going to cause osquery to use a lot of system resources after a while.--events_optimize=true
(the default). I would like to remove this flag in the future and make this default behavior the only behavior.Juan Alvarez
04/12/2021, 11:08 AMevents_optimize=true
and events_expiry=1
. This has been working fine up until now. When i tried to test 4.7.0 i found out that i was missing almost all events with the same settings. When i was testing, i decided to set events_optimize=false
and everything starting working properly. I understand that disabling events_optimize
may not be the best idea, so i am testing now events_optimize=true
with a bigger events_expiry
as previously suggested. It seems to work, but i need to get some more testing done.theopolis
04/12/2021, 2:52 PMJuan Alvarez
04/12/2021, 3:06 PMevents_expiry=300
and events_optimize=true
. It seems that this combination works properly for me. However, the docs are a bit confusing when comparing what i read in https://osquery.readthedocs.io/en/stable/deployment/process-auditing/#osquery-events-optimization or in https://osquery.readthedocs.io/en/stable/installation/cli-flags/#events-control-flags ...
From what i understood about events_optimize=true
in this thread and in https://osquery.readthedocs.io/en/stable/development/pubsub-framework/ , an event will be only returned once, so the value set in events_expiry
should not actually have an impact on the query as the events are cleared inmediately as per the doc:
This allows each subscriber to return the exact window of the schedule and delete buffered events immediately. This saves the most memory and disk usage possible while still allowing flexible scheduling.
theopolis
04/12/2021, 3:08 PMJuan Alvarez
04/12/2021, 3:13 PMevents_optimize=true
as the only behavior. Would not that make the events_expiry
flag obsolete?events_expiry
should not be impacting the queries, just setting it to a different value than 1 is a valid workaround until that happenstheopolis
04/15/2021, 1:09 AM