Previously we wrote on using AppArmor in Linux that is native to Linux what about detection of system calls that can happen from Linux? These are a good area to monitor and can be used in conjunction with other tools like Tracee by Aqua Security as well for more data to identify alerts. In summary on the CKS curriculum this is covered, and digging into system calls are a critical part of the Linux kernel and are used by nearly every program that runs on the system. Tools such as Falco by Sysdig can help detect malicious or abnormal activity in Kubernetes environments by monitoring system calls in real-time. This can help organizations to protect their systems and data from threats such as malware and unauthorized access.
I won’t go through the installation in this but rather the operations of this in your terminal after installation run the following command
Follow the steps linked here https://falco.org/docs/getting-started/download/
Remeber to verify the hash (you can also run this in minikube see the details in the documentation) I’m running on 1.26 playground for this demo.
journalctl -fu falco
The terminal output will be from Falco and we can see the rules are loaded by /etc/falco_rules.local.yaml
Open another terminal you can ssh to another node or run from control plane
kubectl run nginx --image=nginx --dry-run=client -o yaml > nginx.yaml
kubectl apply -f nginx.yamlAfter the pod is created go back to the controlplane terminal that’s active and running the command earlier
Okay so now we have some system calls that are caught what now? How does this become meaningful as far of applicability of your custom rules. Well let’s take a look at the rules configuration which exists in the following folder
cd /etc/falco/
We should have a file called falco.yaml and we will use cat to open the file as shown above this list the files shipped with falco by default as far as rules and instructs us to use falco_rules.local.yaml for any additions.
After opening up the falco_rules_local.yaml file we are greeted with a example rule along with the break down of a description (helpful)
Let’s run a command such as spawning a pod and then run a whoami command
kubectl run nginx-runner --image=nginx:alpine --dry-run=client -o yaml > lost .yaml
kubectl apply -f lost.yaml
kubectl exec -it nginx-runner -- whoami
Great! We are running as root so our security team should be concerned as this pod is running privileged (imperatively defined) let’s take a look at our logs (*crosses fingers*)
When we think of detection especially in the aftermath its what is needed to quickly identify who, what, when, where, and why?
This is just scratching the surface of the capabilities but start to think how you’d configure a alert what is needed and by who system calls are fast way to identify a threat if malicious activity is going on or any anomalous activity.
Third-party integrations work for this tool in the configuration that you can send a notification of what is important more formatted to a “Slack Channel”
What if we are trying to find the status of our falco detection?
systemctl status falco
If you did CKA you’re likely familiar with troubleshooting various services and this is always a sight to see so this shows us not only the PID associated but also the status of falco.
Hopefully this gets you up and running on considering or moving to a proactive approach to syscalls while vital to running applications and can be valid this is a really root approach to system activity that can be utilized to respond.