-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add simple message filters #24
Comments
Drop message for specific keys (threathunters-io#24)
Hi, could it be possible to also filter based on exe ? example of cron generate events:
with auditbeat, it's possible to do something like
Also, here an example of telegraf parent daemon , calling sudo to launch another executable.
|
@aderumier I'd like to use the process labels for that. Currently, a key can be turned into a process label (which may then be inherited by the children of the process.) A filtering mechanism that drops events based on those labels would satisfy your requirement. (I'm sure that the filtering mechanism of auditbeat is more powerful, but I'd rather solve those more complex use-cases with a proper embedded programming language.) |
yes, sure, if we can do it on a process label, it could be great too ! |
Filtering based on process labels has been implemented as of 3ef7c45 by @Hublerho. Closing this issue. |
Hi @hillu, Minimizing/Optimizing the data which is being sent into ones SIEM is of general concern (either due to storage, performance or money reasons). Auditd generates a lot of data and most of the time only a subset of this is required to be sent or stored inside a SIEM. In our custom rules we can flag events using keys and then we are able to filter based on those keys. Unfortunately there are some situations where it is required to log an event but no key can be set or auditd generates an entry without specifying a rule (for example if SELinux is enforced). This will end with auditd logging "key=(null)" which in turn ends up not being de-serialized in Laurel. This means we cannot filter based on null value keys and all that data will end up in our SIEM. If you also consider this an issue/improvement I suggest fixing it adding the following code: Lines 777 to 782 in 040b278
else
{
if self.settings.filter_keys.contains("null".as_bytes()) {
ev.filter = true;
return;
}
} What do you think? |
If the SYSCALL message contains a specific key (from the
-k
option in audit rules), there should at least the following options:The text was updated successfully, but these errors were encountered: