Listen to this Post
Introduction:
Runtime security is the last line of defense against active intrusions, but creating effective Falco rules from scratch is time‑consuming and error‑prone. The newly released OSS2Falco project bridges this gap by converting proven detection logic from Sigma, LinPEAS, and Splunk into ready‑to‑use Falco rules, giving defenders instant access to community‑vetted threat patterns for cloud‑native environments.
Learning Objectives:
- Understand how OSS2Falco translates Sigma, LinPEAS, and Splunk detection rules into Falco’s real‑time anomaly detection language.
- Learn to install, configure, and customize OSS2Falco rules for detecting privilege escalation, suspicious process execution, and cloud misconfigurations.
- Acquire hands‑on skills to test and tune Falco rules using Linux commands, container workloads, and SIEM integration.
You Should Know:
1. Understanding OSS2Falco and Runtime Security
Falco, originally created by Sysdig, monitors system calls and Kubernetes audit logs to detect unexpected behavior. OSS2Falco (https://github.com/sammonsempes/OSS2Falco) aggregates rules from:
– Sigma – generic signature format for SIEMs (YAML rules)
– LinPEAS – Linux privilege escalation enumeration scripts
– Splunk Security Content – pre‑built detection searches
Step‑by‑step – What OSS2Falco does:
1. Parses Sigma/YARA-like rules and LinPEAS check logic.
- Converts them into Falco’s `rule` syntax (conditions like
spawned_process,open,mkdir). - Outputs a single `falco_rules.yaml` file ready for use.
How to inspect the conversion logic:
Clone the repository git clone https://github.com/sammonsempes/OSS2Falco.git cd OSS2Falco View the conversion script (Python) cat convert_rules.py | head -50 List all generated Falco rules ls -la rules/
2. Installing Falco and OSS2Falco Rules
You need Falco running on a Linux host or Kubernetes cluster. Below are deployment commands for Ubuntu 22.04.
Step‑by‑step installation:
Add Falco’s official repository curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | sudo gpg --dearmor -o /usr/share/keyrings/falco.gpg echo "deb [signed-by=/usr/share/keyrings/falco.gpg] https://download.falco.org/packages/deb stable main" | sudo tee /etc/apt/sources.list.d/falcosecurity.list sudo apt update && sudo apt install -y falco Start Falco service sudo systemctl enable falco sudo systemctl start falco Check status sudo systemctl status falco Copy OSS2Falco rules sudo cp OSS2Falco/falco_rules.yaml /etc/falco/ sudo systemctl restart falco
Windows (WSL2) alternative:
wsl --install -d Ubuntu wsl -d Ubuntu bash -c "curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | sudo apt-key add - && sudo apt update && sudo apt install -y falco"
3. Converting Sigma Rules to Falco
Sigma rules are YAML files describing malicious patterns (e.g., suspicious PowerShell). OSS2Falco’s `sigma2falco.py` translates conditions like `Image|endswith: ‘\powershell.exe’` into Falco’s proc.name = "powershell.exe".
Step‑by‑step rule conversion:
Install Python dependencies pip install pyyaml Convert a single Sigma rule python sigma2falco.py -i sigma_rules/windows/powershell_suspicious_download.yml -o falco_rules/custom_rule.yaml Bulk convert all Sigma rules from a directory for file in sigma_rules//.yml; do python sigma2falco.py -i "$file" -o "rules/$(basename "$file" .yml)_falco.yaml" done Validate output Falco syntax falco -r rules/custom_rule.yaml -t
Example converted rule – detect `sudo` brute force:
- rule: Sudo Brute Force Attempt desc: Multiple failed sudo attempts from LinPEAS detection condition: > spawned_process and proc.name = "sudo" and (fd.name contains "incorrect password" or fd.name contains "sudo_attempt") output: "Sudo brute force (user=%user.name command=%proc.cmdline)" priority: CRITICAL
4. Integrating LinPEAS Detection into Falco
LinPEAS checks for misconfigurations (e.g., writable /etc/passwd, cron wildcards). OSS2Falco converts these checks into Falco rules that trigger on file modifications.
Step‑by‑step – monitor critical file tampering:
Extract LinPEAS‑based rules grep -i "writable" OSS2Falco/rules/linpeas_based_rules.yaml Add a custom rule for /etc/shadow modification sudo tee -a /etc/falco/falco_rules.local.yaml <<EOF - rule: Shadow File Modified desc: Detects unauthorized writes to /etc/shadow (LinPEAS check) condition: > open_write and fd.name = /etc/shadow and not proc.name in (useradd, passwd, vipw) output: "Sensitive shadow file modified (user=%user.name process=%proc.name)" priority: WARNING EOF Reload Falco rules sudo falcoctl reload
Test the detection:
Simulate an attacker attempting to write to shadow (requires root) sudo echo "test" >> /etc/shadow Check Falco logs sudo journalctl -u falco -f | grep "Shadow File Modified"
5. Using Splunk Security Content with Falco
Splunk’s detection library includes searches for lateral movement, persistence, and ransomware patterns. OSS2Falco translates Splunk’s SPL syntax into Falco conditions, focusing on process ancestry and network connections.
Step‑by‑step import and customisation:
Download Splunk Security Content (if not included) git clone https://github.com/splunk/security_content.git Run the OSS2Falco Splunk converter python splunk2falco.py -i security_content/detections/endpoint/ -o falco_rules/splunk/ Enable a rule for suspicious parent‑child relationships cat falco_rules/splunk/susp_parent_child.yaml
Example Falco rule from Splunk – `cmd.exe` launching powershell.exe:
- rule: Suspicious Process Chain (cmd→powershell) condition: > spawned_process and proc.name = "powershell.exe" and proc.pname = "cmd.exe" output: "Suspicious parent‑child chain (parent=%proc.pname child=%proc.name)" priority: CRITICAL
Windows‑side testing (using Sysmon + Falco on WSL):
Simulate the attack cmd.exe /c powershell.exe -Command "Write-Host 'Test'" Falco event should appear in /var/log/syslog
6. Testing and Tuning OSS2Falco Rules
False positives are inevitable. Use Falco’s `-t` (test) flag and live monitoring to refine rules.
Step‑by‑step testing methodology:
1. List all active rules
sudo falco -l
<ol>
<li>Run Falco in test mode with a sample event (JSON format)
echo '{"output":"execve","proc.name":"nc","evt.type":"execve"}' | sudo falco -r /etc/falco/falco_rules.yaml -t</p></li>
<li><p>Use `falcoctl` to load rules with exceptions
sudo falcoctl add rule OSS2Falco/custom_exceptions.yaml</p></li>
<li><p>Create an exception for known good behaviour (e.g., backup scripts)
sudo tee -a /etc/falco/falco_rules.local.yaml <<EOF
<ul>
<li>macro: allowed_backup_processes
condition: proc.name = "rsync" or proc.name = "tar"</li>
<li>rule: File Write Outside Home
condition: open_write and not allowed_backup_processes
output: "Unexpected file write (file=%fd.name)"
priority: MEDIUM
EOF</li>
</ul></li>
<li>Simulate a benign backup to ensure no alert
rsync -av /home/user/ /backup/ && sleep 2
sudo journalctl -u falco --since "1 minute ago" | grep "Unexpected file write"
If no output → tuning successful
Performance tuning:
– Increase Falco’s buffer size: edit `/etc/falco/falco.yaml` → `syscall_buffer_size: 8388608`
– Disable noisy rules by setting `enabled: false` in the rule definition.
7. Deploying OSS2Falco in Production (Kubernetes)
For containerised environments, deploy Falco as a DaemonSet and mount OSS2Falco rules via ConfigMap.
Step‑by‑step Helm deployment:
Add Falco Helm repo
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
Create ConfigMap from OSS2Falco rules
kubectl create configmap oss2falco-rules --from-file=OSS2Falco/falco_rules.yaml
Install Falco with custom rules
helm install falco falcosecurity/falco \
--set falco.rulesFile="{/etc/falco/falco_rules.yaml,/etc/falco/oss2falco_rules.yaml}" \
--set-file falco.customRules.oss2falco=OSS2Falco/falco_rules.yaml
Verify deployment
kubectl get pods -l app=falco
kubectl logs -l app=falco | grep -i "rule"
Cloud hardening – detect AWS/GCP API abuse:
Add OSS2Falco’s cloud‑audit rules (converted from Splunk) to monitor `aws s3 rm` or gcloud compute instances delete.
What Undercode Say:
- Key Takeaway 1: OSS2Falco reduces rule‑writing effort by >90%, instantly providing hundreds of battle‑tested detections from Sigma, LinPEAS, and Splunk – a game changer for small security teams.
- Key Takeaway 2: Runtime security is only as good as its ruleset; by merging community signatures, OSS2Falco turns Falco into a universal detection engine that rivals commercial EDRs for Linux/cloud workloads.
Analysis: The project smartly leverages existing open‑source intelligence rather than reinventing the wheel. The LinPEAS conversions are particularly valuable for catching privilege escalation paths that static scanners miss. However, users must tune rules to avoid alert fatigue – a generic rule like “write to /etc” will fire frequently in DevOps environments. The maintainers should provide pre‑tuned exception lists for common orchestration tools (kubectl, docker, systemd). Overall, OSS2Falco is a must‑have for any blue team running Falco in production.
Prediction:
Within 12 months, OSS2Falco will become the default rule pack for new Falco deployments, pushing the project to integrate with MITRE ATT&CK mappings and automated CI/CD pipelines. The line between host‑based IDS (like OSSEC) and runtime security will blur as more Sigma rules get auto‑converted to Falco. Expect cloud providers (AWS, GCP) to offer one‑click “OSS2Falco Security Profiles” for EKS/GKE clusters – commoditising runtime detection while raising the bar for attackers.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Samuel Monsempes – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
