-
Notifications
You must be signed in to change notification settings - Fork 912
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
Added rule to detect LKM module injects using insmod used by rootkits for kernel hooking #1401
Conversation
Signed-off-by: divious1 <[email protected]>
/assign @Kaizhe |
Thanks @d1vious ! PS: I have just edited the PR description to fix the release note block syntax. |
Thank you 😊 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @d1vious!
Waiting for @Kaizhe review but just a comment: shouldn't this new macro exclude the Falco kernel module ?
@leodido we can add exclusion for a bunch of commonly used modules, if you like we can collage a list and tack it to the end of the query. Otherwise I suspect a customer would have to do some tuning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this PR 👍
The rule seems good to me, but I believe it worth adding an exclusion list for known modules.
IMHO, the list should at least include the Falco kernel module, then users can extend it.
rules/falco_rules.yaml
Outdated
@@ -3010,6 +3010,12 @@ | |||
output: Drift detected (open+create), new executable created in a container (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode event=%evt.type) | |||
priority: ERROR | |||
|
|||
# find when a new kernel module is injected | |||
- rule: Linux Kernel Module injection detected |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please capitalized the beginning letter of every word?
rules/falco_rules.yaml
Outdated
@@ -3010,6 +3010,12 @@ | |||
output: Drift detected (open+create), new executable created in a container (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode event=%evt.type) | |||
priority: ERROR | |||
|
|||
# find when a new kernel module is injected | |||
- rule: Linux Kernel Module injection detected | |||
desc: It is very uncommon for kernel modules to be injected in running production instances, used rookits to obfuscate their behavior via kernel hooking |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you rephrase a little bit of the description to something as simple as
Detect kernel module was injected (from container).
rules/falco_rules.yaml
Outdated
# find when a new kernel module is injected | ||
- rule: Linux Kernel Module injection detected | ||
desc: It is very uncommon for kernel modules to be injected in running production instances, used rookits to obfuscate their behavior via kernel hooking | ||
condition: evt.type=execve and proc.name=insmod |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest to limit to activities happen from inside a container. So the condition would be something like:
spawned_process and container and proc.name=insmod
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed with @leogr , need to have a whitelisted images/containers that perform kernel module injection like falco.
desc: It is very uncommon for kernel modules to be injected in running production instances, used rookits to obfuscate their behavior via kernel hooking | ||
condition: evt.type=execve and proc.name=insmod | ||
output: Linux Kernel Module injection using insmod detected (user=%user.name user_loginuid=%user.loginuid parent_process=%proc.pname module=%proc.args) | ||
priority: WARNING |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add tags fields with process
Hey @d1vious Could you also rebase this PR, please? |
Signed-off-by: Leonardo Grasso <[email protected]>
Signed-off-by: Leonardo Grasso <[email protected]>
On previously modified files. Signed-off-by: Leonardo Grasso <[email protected]>
Signed-off-by: Leonardo Grasso <[email protected]>
…lco_common Signed-off-by: Leonardo Grasso <[email protected]>
…_started` macro Signed-off-by: Leonardo Di Donato <[email protected]>
Signed-off-by: Leonardo Grasso <[email protected]>
Reviewed-by: Spencer Krum <[email protected]> Reviewed-by: Leonardo Grasso <[email protected]> Reviewed-by: Leonardo Di Donato <[email protected]> Signed-off-by: Lorenzo Fontana <[email protected]>
Previously, formatters were freed by LUA code when re-opening outputs. Since now, outputs are not controlling anymore the falco_formats class (see #1412), we just free formatters only if were already initialized. That is needed when the engine restarts (see #1446). By doing so, we also ensure that correct inspector instance is set to the formatter cache. Signed-off-by: Leonardo Grasso <[email protected]>
Co-Authored-By: Leonardo Di Donato <[email protected]> Signed-off-by: Leonardo Grasso <[email protected]>
Use the right list name in the rule Full K8s Administrative Access--it was using the nonexistent list admin_k8s_users, so it was just using the string "admin_k8s_users". Signed-off-by: Mark Stemm <[email protected]>
…cts storage proposals Co-authored-by: Lorenzo Fontana <[email protected]> Signed-off-by: Leonardo Di Donato <[email protected]>
Co-authored-by: Lorenzo Fontana <[email protected]> Signed-off-by: Leonardo Di Donato <[email protected]>
…prefix Signed-off-by: Christian Zunker <[email protected]>
@d1vious: Adding label Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Signed-off-by: divious1 <[email protected]>
…dd_lkm_inject_rule
Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits. 📝 Please follow instructions in the contributing guide to update your commits with the DCO Full details of the Developer Certificate of Origin can be found at developercertificate.org. The list of commits missing DCO signoff:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hey @d1vious Thank you, but unfortunately, I see some issues now. There're merge commits in this PR and commits missing the sign-off that are both not allowed in this repo (please check out the comments from our bot). Moreover, integration tests are failing. :( Thus, I'd suggest reverting the merge then use |
@leogr This literally has been more work than is worth IMHO, if you want to rebase and include the changes feel free. I was hoping to contribute back to the project this detection which I found useful in my production environment at Splunk, but contributing here has been extremely cumbersome due to all the steps/hoops required and will likely not contribute again unfortunately. My advice is make this process easier for contributors if you really want the community to be part of the project. Feel free to close the PR if you did not find it useful, otherwise enjoy the free detection 😄 |
|
||
- rule: Linux Kernel Module Injection Detected | ||
desc: Detect kernel module was injected (from container). | ||
condition: spawned_process and container and evt.type=execve and proc.name=insmod |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
evt.type=execve
is redundant. Can you please remove it?
Hey @d1vious I'm sorry you felt unhappy with the process we have in place. Your contribution is valuable, and we appreciate it. We never thought it was unuseful. However, I'm here to help with this PR. So let's try to solve the issue. Unfortunately, GitHub does not allow us to force push on your branch, so I cannot rebase this PR by myself atm. I can propose two solutions (almost effortless for you):
In both cases, I will cherry-pick and keep your two commits (that have been signed-off by you, so it's perfectly fine) then we will also be able to include our suggestions on top of that. WDYT? |
cleaned up, added the fixes and DCO signature on #1478, closing this one |
What type of PR is this?
/kind rule-create
Any specific area of the project related to this PR?
/area rules
What this PR does / why we need it:
This PR adds a new falco rule that looks for when insmod is called as part of a execve event. Injecting LKM modules on (post build) running production instances should be rare and is a common way for rootkits that employ kernel hooking to obfuscate themselves.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
This is a rehashed of PR#1389 just cleaned up DCO
Does this PR introduce a user-facing change?:
Yes new rule in falco_rules.yml