Image scan و admission policy فقط میگویند «چه چیزی اجازه ورود دارد». حمله واقعی اغلب بعد از start رخ میدهد:
shell داخل container
خواندن /etc/shadow
mount حساس
اتصال غیرعادی outbound
تغییر binary در runtimeFalco برای همین لایه ساخته شد:
Detect security threats in real time — runtime security across hosts, containers, Kubernetes, and cloud environments.
با قوانین سفارشی روی رویدادهای کرنل Linux (و منابع دیگر از طریق plugins)، به همراه metadata کانتینر و Kubernetes، هشدار نزدیک به real-time میدهد.
CNCF Graduated — ۲۹ فوریه ۲۰۲۴ (Sandbox اکتبر ۲۰۱۸، Incubating ژانویه ۲۰۲۰). سازنده اولیه: Sysdig. نسخههای docs تا v0.44؛ adopters: Shopify، GitLab، Skyscanner، Vinted و دیگران.
مشکل: نقطه کور runtime
Supply chain / CI:
[Harbor](/blog/harbor-cloud-native-registry-guide/) scan + Cosign → قبل از pull
Admission:
OPA / Kyverno → قبل از schedule
Blind spot:
رفتار داخل Pod در حال اجرا
Falco:
kernel events → rules → alert → SIEM / response| لایه | ابزار نمونه | زمان |
|---|---|---|
| Build / registry | Trivy، Harbor | قبل از deploy |
| Admission | OPA، Kyverno | هنگام create |
| Network policy | Cilium | L3/L4(+L7) |
| Runtime behavior | Falco | هنگام اجرا |
Falco جایگزین firewall یا scanner نیست — detection روی رفتار سیستم است؛ مکمل defense-in-depth.
Falco چیست؟
طبق مستندات رسمی:
- agent مانیتورینگ و detection
- رویدادها را از kernel (و plugins) میگیرد
- در برابر rules engine قوی assert میکند
- با metadata از container runtime و Kubernetes غنی میکند
- alert را به stdout، فایل، syslog، HTTP، یا ۵۰+ سیستم (از طریق Falcosidekick) میفرستد
Site: falco.org
Docs: falco.org/docs
Repo: github.com/falcosecurity/falco
License: Apache 2.0
Arch: x86_64 و ARM64
Platforms: bare metal، VM، GKE، EKS، AKS، …
تاریخچه و CNCF
| تاریخ | رویداد |
|---|---|
| ۲۰۱۶ | متنباز توسط Sysdig |
| ۱۰ اکتبر ۲۰۱۸ | CNCF Sandbox — اولین پروژه runtime security |
| ۸ ژانویه ۲۰۲۰ | CNCF Incubating |
| ۲۹ فوریه ۲۰۲۴ | CNCF Graduated |
| ۲۰۲۶ | Falco 0.44؛ معرفی Prempti (Falco × AI coding agents) |
Maintainers از Amazon، Apple، IBM، Red Hat و community گستردهتر پیوستهاند.
معماری
Linux Kernel
syscalls / related events
│
▼
Driver (modern eBPF یا kernel module)
│
▼
Falco engine
├── parse events
├── enrich (container ID, k8s pod/ns, labels, …)
└── rules engine (YAML conditions)
│
▼
Alert (JSON / text)
│
├── stdout / file / syslog
└── Falcosidekick → Slack, SIEM, Kafka, Lambda, …Drivers
| Driver | توضیح |
|---|---|
| Modern eBPF (پیشفرض توصیهشده) | CO-RE؛ کرنلهای جدیدتر (اغلب ۵.۸+ با BTF/ring buffer)؛ capabilities محدودتر از module کامل |
| Kernel module | وقتی eBPF مناسب نیست؛ نیاز به privilege بیشتر |
Docs اخیر به سمت modern eBPF متمرکز شدهاند (مسیرهای legacy در حال سادهسازیاند — نسخه docs روز را چک کنید).
Capabilities نمونه برای eBPF path: CAP_BPF / CAP_PERFMON / CAP_SYS_RESOURCE / CAP_SYS_PTRACE (طبق راهنمای نسخه شما).
Rules engine
- شرایط در YAML
- macros و lists برای reuse
- priority (emergency → debug)
- output string توصیفی با فیلدهای event
ترتیب بارگذاری معمول:
/etc/falco/falco_rules.yaml(پیشفرض)falco_rules.local.yaml(local override)/etc/falco/rules.d/(اضافی)
توزیع rules بهصورت OCI artifacts با falcoctl در chartهای جدید رایج است.
Plugins
گسترش فراتر از syscall:
- AWS CloudTrail
- GitHub audit
- Okta
- Kubernetes audit logs
- منابع سفارشی (C / Go plugin API)
یک pipeline واحد برای host + cloud identity + SCM.
نمونه rule
- rule: Terminal shell in container
desc: A shell was spawned inside a container
condition: >
spawned_process and container
and shell_procs and proc.tty != 0
and container_entrypoint
output: >
Shell spawned in container
(user=%user.name container_id=%container.id
container_name=%container.name shell=%proc.name
parent=%proc.pname cmdline=%proc.cmdline
k8s.ns=%k8s.ns.name k8s.pod=%k8s.pod.name)
priority: WARNING
tags: [container, shell, mitre_execution]قوانین پیشفرض پوشش میدهند: shell در container، نوشتن به مسیرهای حساس، privilege escalation مشکوک، و الگوهای رایج حمله — سپس برای محیط خود customize کنید تا noise کم شود.
استقرار روی Kubernetes
Falco معمولاً بهصورت DaemonSet روی هر node اجرا میشود تا همه workloadها دیده شوند.
Helm
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco \
--namespace falco \
--create-namespace \
--set tty=true \
--set driver.kind=modern_ebpfبا Falcosidekick + UI
helm upgrade --install falco falcosecurity/falco \
--namespace falco \
--set falcosidekick.enabled=true \
--set falcosidekick.webui.enabled=truekubectl -n falco port-forward svc/falco-falcosidekick-ui 2802:2802
# UI روی localhost:2802Forward به Slack (مثال)
helm upgrade falco falcosecurity/falco -n falco \
--set falcosidekick.enabled=true \
--set falcosidekick.config.slack.webhookurl=https://hooks.slack.com/services/... \
--set falcosidekick.config.slack.minimumpriority=noticeFalcosidekick ۶۰+ integration دارد (SIEM، data lake، webhook، queue، serverless).
مشاهده alert خام
kubectl -n falco logs -l app.kubernetes.io/name=falco -fUse cases
| Use case | مثال |
|---|---|
| Threat detection | shell تعاملی، crypto miner، lateral movement نشانهها |
| Compliance / audit | نقض سیاست «no shell in prod»، دسترسی به secret path |
| Multi-tenant isolation | تشخیص فرار از مرز tenant (مکمل NetworkPolicy) |
| Cloud + K8s | CloudTrail + syscall در یک مدل قواعد |
| Ops anti-patterns | رفتارهای خطرناک که حمله نیستند اما policy را میشکنند (مثل Trendyol case) |
سایت Falco روی medical imaging multi-tenant، platform engineering، و ترکیب با mitigation tools هم case study دارد.
Falco در برابر گزینههای مشابه
| نیاز | ابزار |
|---|---|
| Runtime syscall detection OSS | Falco |
| CNI + NetworkPolicy / L7 | Cilium |
| Image CVE قبل از deploy | Harbor + Trivy |
| Policy admission | OPA / Kyverno |
| EDR تجاری کامل | محصولات vendor (گاهی روی همان ایده Sysdig/Falco) |
| App-layer fraud | منطق business — نه Falco |
Falco prevention کامل نیست (مگر با tooling واکنش جدا)؛ تمرکزش detect + alert است. برای block شبکه به Cilium/NetworkPolicy تکیه کنید.
عملکرد و مقیاس
- هر node یک agent → CPU/overhead تابع نرخ syscall و پیچیدگی rules است
- محیطهای پرتراکم ممکن است به tuning driver و rule set نیاز داشته باشند
- کار روی multi-threaded Falco در community برای مقیاس بالاتر در جریان است (experimental در افق ۰.۴۴+) — قبل از production روی PoC نسخه خودتان تست کنید
Best practice: rules را از noisy شروع کنید، با priority و exceptions محیط را آرام کنید، سپس به SIEM بفرستید.
امنیت خودِ Falco
- agent با دسترسی کرنل/eBPF → سطح حمله حساس؛ فقط از chart/image رسمی
- RBAC برای خواندن metadata Kubernetes را حداقل نگه دارید
- خروجی alert ممکن است شامل cmdline و path حساس باشد — مقصد SIEM را امن کنید
- قوانین را GitOps کنید (Argo CD) تا drift نداشته باشید
- بهروزرسانی منظم ruleset (CVE detection patterns و false-positive fixes)
Prempti و آینده AI
در ۲۰۲۶ پروژه Prempti را معرفی کرد: پیوند Falco با AI coding agents — گسترش مدل «runtime insight» به tooling توسعه agentic. جزئیات را در بلاگ Falco دنبال کنید؛ هسته همچنان detection مبتنی بر event است.
ارتباط با stack شما
Nodes
Falco DaemonSet (eBPF)
→ enrich via K8s API + [containerd](/blog/containerd-container-runtime-guide/) / CRI
→ Falcosidekick → Slack / SIEM
Prevention / policy neighbors:
[Cilium](/blog/cilium-ebpf-kubernetes-networking/) NetworkPolicy
[Harbor](/blog/harbor-cloud-native-registry-guide/) scan + sign
[cert-manager](/blog/cert-manager-kubernetes-tls-certificates/) TLS
[Envoy](/blog/envoy-proxy-cloud-native-data-plane-guide/) / [Contour](/blog/contour-kubernetes-ingress-envoy-guide/) edge
GitOps: [Argo](/blog/argo-project-kubernetes-gitops-cicd/) برای Helm values + rulesFalco لایه runtime visibility است — کنار storage (Longhorn) یا registry، نه جایگزین آنها.
Best practices
- modern_ebpf را در staging روی همان کرنل production امتحان کنید
- Default rules را یکجا خاموش نکنید — با exceptionهای هدفمند noise را کم کنید
- همیشه Kubernetes enrichment را روشن نگه دارید (ns/pod در alert)
- Falcosidekick به SIEM واقعی — نه فقط UI demo
- Rules را versioned در Git نگه دارید؛ با
falcoctl/ ConfigMap مدیریت کنید - جدا کردن priority برای on-call (CRITICAL/ERROR) vs audit (NOTICE)
- Resource requests/limits برای DaemonSet تا noisy neighbor نشود
- تست با سناریوی کنترلشده (مثلاً
kubectl exec+ shell) قبل از go-live - ترکیب با NetworkPolicy برای containment بعد از alert
- Runbook: alert → کدام namespace/image → quarantine یا revoke
Troubleshooting
| علامت | بررسی |
|---|---|
| Pod CrashLoop | driver load، کرنل بدون BTF، privileges |
| صفر event | rules load نشده؛ driver kind اشتباه؛ فیلتر بیش از حد |
| Noise زیاد | macros/exceptions؛ minimumpriority در sidekick |
| بدون k8s fields | دسترسی API / serviceaccount |
| CPU بالا | تعداد rules؛ syscall storm؛ sampling/tuning docs |
kubectl -n falco get pods -o wide
kubectl -n falco describe pod -l app.kubernetes.io/name=falco
kubectl -n falco logs -l app.kubernetes.io/name=falco --tail=100چه زمانی Falco؟
✅ استفاده کنید
- Kubernetes/container در production با نیاز threat detection
- complementary به scan و NetworkPolicy
- multi-cloud با plugins (CloudTrail، IdP، GitHub)
- تیم SecOps که SIEM و playbook دارند
⚠️ شاید نه
- فقط چند VM بدون container و بدون بودجه ops برای alert triage
- انتظار «جلوگیری خودکار کامل» بدون tooling واکنش
- کرنل خیلی قدیمی بدون مسیر driver پشتیبانیشده
جمعبندی
| مفهوم | توضیح |
|---|---|
| Falco | cloud native runtime security — detect & alert |
| Driver | modern eBPF (پیشفرض) یا kernel module |
| Rules | YAML conditions + output + priority |
| Enrichment | container + Kubernetes metadata |
| Plugins | CloudTrail، GitHub، Okta، k8s audit، … |
| Falcosidekick | fan-out به ۵۰–۶۰+ سیستم |
| CNCF | Graduated فوریه ۲۰۲۴ — اصل از Sysdig |
Falco چشم runtime شماست: وقتی image تمیز و policy admission سبز است، هنوز میتواند ببیند کسی داخل container چه syscall خطرناکی زده است — و همان لحظه به تیم امنیت خبر بدهد.
قدم بعدی
- Try Falco on Kubernetes با Helm
- یک
kubectl execکنترلشده و مشاهده alert - Falcosidekick → Slack یا webhook داخلی
- ۲–۳ rule سفارشی برای سیاست سازمان (مثلاً منع package manager در prod)
- اتصال به SIEM و تعریف on-call routing
منابع
- Falco — falco.org
- Documentation
- Kubernetes quickstart
- CNCF Falco
- Graduation announcement
- GitHub — falcosecurity/falco
منتشر شده در P30Light — بخش امنیت شبکه.