<@UDQ7VN163> it is needed to do FIM, without that ...
# fim
a
@Stephan it is needed to do FIM, without that you disable the table 🤔
s
That's what i thought too 😃 And that's kind of proposed by the docs. However the reality is different. Actually after disabling this flag, my FIM started to work properly (counting Hashes and population the tables)
a
file_events or process_file_events?
s
file_events
a
You probably have misinterpreted the documentation, as file_events is based on inotify and doesn't require audit
Also, speaking about audit, your backlog is constantly full and will cause issues regardless of which audit feature you enable in audit
you can completely disable audit if you only need file_events
(also, allow_fim_events is already set to FALSE by default, so you can remove the flag from your command line)
The documentation for file integrity monitoring talks about how to tune inotify: https://osquery.readthedocs.io/en/stable/deployment/file-integrity-monitoring/
Audit is not mentioned there, can you link me the page you were reading?
s
Whatever, I just wanted to monitor running processes and track changes to the files. My thought was that if there is an explicit flag audit_allow_process_events that I have to enable to do process monitoring, I should then also enable allow_fim_events to do FIM
a
It is best to always start from the documentation and then tweak the settings
Audit is kind of complex
There's a really good talk from Chris Long on the matter

https://www.youtube.com/watch?v=AIO7mgVt4O8â–¾

s
I did watch the video and I do use Palantir's work patially
a
In general, flags that change the behavior of a publisher are all grouped with a prefix
in this case audit
When something is not clear, referring to the header file of the source code is usually useful (flags are declared at the top of the file). You can also open an issue about it so that we can extend the documentation
s
This is the output from the osqueryi --help --audit_allow_config Allow the audit publisher to change auditing configuration --audit_allow_fim_events Allow the audit publisher to install file event monitoring rules --audit_allow_process_events Allow the audit publisher to install process event monitoring rules --audit_allow_selinux_events Allow the audit publisher to process audit events --audit_allow_sockets Allow the audit publisher to install socket-related rules --audit_allow_user_events Allow the audit publisher to install user events-related rules
To monitor sockets or processes you need to explicitly enable the flags
it's "logical" at least to me, that to do FIM you need to enable audit_allow_fim_events
a
Yes! But you can still use the inotify-based FIM and keep the audit-based FIM off
audit-based FIM performs syscall tracing, so it's a little heavy (and if your machine already has the backlog full it's not going to work)
s
My backlog was full due to osquery failing to handle the events
a
It seemed like there was some spamming from SECCOMP
Does that still happen?
s
Nope
a
If you could open a ticket with your configuration and running processes, maybe we can have a look at it
s
sure, where do I post it?
a
It may just be caused by too many processes doing i/o, but it's still worth to open the issue since we could at least document this problem on the documentation for Audit
s
Tried to gather some I/O stats but couldn't find any weirdness either. Anyway will be very glad if you will have a look.
a
The trouble with syscall tracing is that even keeping a terminal that prints data to screen will call the write() syscall many times
A more precise way to debug this is using the perf tools
to count how many times certain syscalls (the ones monitored by osquery) are being called
s
Strangely just reproducing the audit rules manually with disabled osquery doesn't impact the system
a
How did you do that? To replicate it I would set --audit_allow_config=false and --audit_allow_fim=true, then restore the configuration manually using auditctl
s
restored the configuration with auditctl but without osquery