Closed pogao closed 6 years ago
@pogao I just went through attempting to recreate this and the rule works fine for me. Could you give me a bit more detail on your setup?
1) Host OS and Kernel Version (uname -a)
2) Are you running Falco as a container or in the host system as a daemon (or via a terminal)
Thanks.
@mfdii sorry for this, I found out what was wrong and solved the problem. Sorry for forgetting to update this.
No worries, glad you have it working. Would you mind sharing what the problem was?
The problem was me and my own dumbness obviously.
The alerts without the evt.type
filter would show up because the number of events generated matching the rest of the condition were enough to fill the buffer and make falco spit something on the screen. When I was using evt.type
in the condition, it would only match about 3 lines of output which wasn't enough to fill falco's buffer. I just needed to "break the rule" enough times for the alert to be displayed - but the rule was working fine :)
Oh yes, you can use the -U flag to disable buffering or change it in the config file.
I'm trying to use the pre-defined rule in falco_rules.local.yaml to detect when a user runs sudo inside a container. The rule is:
If I run it using the evt.type filter, nothing is detected. If I remove evt.type and try again, it detects the evt.type=execve event and millions of other events triggered by sudo (basically because now there isn't the filter looking exclusively for the execution of the command), like this:
I'm not really sure what's going on here... could someone let me know what is it that I'm doing wrong or if this is actually a bug?