Falco Logging Course lab CKS

Kubernetes
#1

When updating the rule in falco lab, the validation is still saying wrong. Below is the lab from Falco section
Change the output so that it now prints the events in the following sample format as shown below:

Error Package Management Tools Executed (user_loginuid=-1 command=apt update container_name=simple-webapp-1)

In the output i am getting the required output
06:28:01.879915486: Error Package management Tools Executed (user_loginuid=-1 command=apt update container_name=simple-webapp-1)
06:29:02.039056551: Error Package management Tools Executed (user_loginuid=-1 command=apt update container_name=simple-webapp-1)

can you please let me know what i am missing here? Below is the update falco rule

  • rule: Launch Package Management Process in Container
    desc: Package management process ran inside container
    condition: >
    spawned_process
    and container
    and user.name != “_apt”
    and package_mgmt_procs
    and not package_mgmt_ancestor_procs
    and not user_known_package_manager_in_container
    output: >
    Package management Tools Executed (user_loginuid=%user.loginuid command=%proc.cmdline container_name=%container.name)
    priority: ERROR
    tags: [process, mitre_persistence]

the rule is updated at location /etc/falco/falco_rules.local.yaml

#2

Hi @vinaydeep410

Your rule and the output match the requirements as asked in the question. I am not sure what’s going on here.
It would have been helpful if you had shared a screenshot of this behavior.

I just tried the lab it worked as expected.

falco
falco1266×562 101 KB

#3

thank you so much. I missed the kill part. question in some docs i see you can restart the falco using following
systemctl restart falco

now i did kill -1 . it seems to be working. Also in some documents i see kill -9 .

Can you please tell me diffrerences between systemctl restart falco and kill operations? Appreciate your help.

#4

The restarting is all to do with signals in Linux which are messages that interrupt a process to tell it to perform some action. The action performed is defined by the application code, but a convention is observed. The kill command is a way to send these signals from the command line. The ones related to controlling processes are

  • 1 - (SIGHUP). This signal is often used to instruct daemons to reload configuration files or restart after an update. Falco respects this and that is why kill -1 will make it reload the configuration without completely stopping and starting it.
  • 2 - (SIGINT). This gets sent to a foreground terminal application if you press CTRL-C. Normally the program will exit.
  • 9 - (SIGKILL). Forces a program to terminate immediately. The program cannot block this signal. kubelet sends tis to a pod that has not stopped after the grace period
  • 15 - (SIGTERM). Requests a program to do a normal shutdown. kubelet sends this initially to a pod when you do k delete pod.

As for systemctl restart, that will send a SIGTERM to the service, then a SIGKILL if it doesn’t respond in a timely manner (just like kublet with pods). Then it will re-launch the service.

Bottom line is if falco is running as a daemon (service), sending a kill -1 will result in it reloading faster because it doesn’t stop then start again.