You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After executing Aqua Security’s kube-bench, the Sidekick service fails and crashes. This issue occurs when the same Falco rule is triggered more than 15 times within a very short time window. Instead of handling the load gracefully, the service crashes.
How to reproduce it
Run Aqua Security’s kube-bench to perform security checks.
Ensure that a specific Falco rule is triggered more than 15 times in a very short window.
Expected behaviour
The Sidekick service should handle multiple rule triggers without crashing. It should remain stable and not be terminated
Screenshots
No screenshots available.
Environment
Falco version:
Falco version: 0.38.2
OS:
Talos 1.6.5
Kernel:
6.6.32-talos
Installation method:
Helm Additional context
The rule triggered:
# Note that runsv is both in protected_shell_spawner and the
# exclusions by pname. This means that runsv can itself spawn shells
# (the ./run and ./finish scripts), but the processes runsv can not
# spawn shells.
#
# Also, trivy uses this for vulnerability scanning and kyverno uses it to clean ephemeral reports
# And we exclude the incom user
- rule: Incom Run shell untrusted
desc: >
An attempt to spawn a shell below a non-shell application. The non-shell applications that are monitored are
defined in the protected_shell_spawner macro, with protected_shell_spawning_binaries being the list you can
easily customize. For Java parent processes, please note that Java often has a custom process name. Therefore,
rely more on proc.exe to define Java applications. This rule can be noisier, as you can see in the exhaustive
existing tuning. However, given it is very behavior-driven and broad, it is universally relevant to catch
general Remote Code Execution (RCE). Allocate time to tune this rule for your use cases and reduce noise.
Tuning suggestions include looking at the duration of the parent process (proc.ppid.duration) to define your
long-running app processes. Checking for newer fields such as proc.vpgid.name and proc.vpgid.exe instead of the
direct parent process being a non-shell application could make the rule more robust.
condition: >
spawned_process
and shell_procs
and proc.pname exists
and not (k8s.ns.name = trivy)
and not (k8s.ns.name = kyverno)
and not serf_script
and not check_process_status
and not (container.image.repository in (incom_network_images))
and not (user.name = incom)
and not (proc.pexe = /bin/containerd-shim-runc-v2)
output: Shell spawned by untrusted binary (parent_exe=%proc.pexe parent_exepath=%proc.pexepath pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] aname[4]=%proc.aname[4] aname[5]=%proc.aname[5] aname[6]=%proc.aname[6] aname[7]=%proc.aname[7] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
priority: ERROR
tags: [maturity_stable, host, container, process, shell, mitre_execution, T1059.004]
cme-incom
changed the title
Sidekick Crashes After Running Aqua Security’s Kube-Bench with Falco 0.38.2
Sidekick Crashes After Running Kube-Bench with Falco 0.38.2
Oct 1, 2024
cme-incom
changed the title
Sidekick Crashes After Running Kube-Bench with Falco 0.38.2
Sidekick Crashes After Triggering the Same Rule Multiple Times in a Short Window with Falco 0.38.2
Oct 1, 2024
Describe the bug
After executing Aqua Security’s kube-bench, the Sidekick service fails and crashes. This issue occurs when the same Falco rule is triggered more than 15 times within a very short time window. Instead of handling the load gracefully, the service crashes.
How to reproduce it
Run Aqua Security’s kube-bench to perform security checks.
Ensure that a specific Falco rule is triggered more than 15 times in a very short window.
Expected behaviour
The Sidekick service should handle multiple rule triggers without crashing. It should remain stable and not be terminated
Screenshots
No screenshots available.
Environment
Falco version:
Falco version: 0.38.2
OS:
Talos 1.6.5
6.6.32-talos
Helm
Additional context
The rule triggered:
The error msg from the failed pod:
The text was updated successfully, but these errors were encountered: