المستوى: محترف — هذا المقال يفترض إنك بتدير cluster Kubernetes في إنتاج، فاهم eBPF بشكل عام، وبتشتغل مع Helm وPrometheus.
Falco للمحترف: اكتشف الاختراقات على Kubernetes لحظة حدوثها
لو فيه pod اتخترق الساعة 3 الصبح وبدأ يفتح shell ويقرأ /etc/shadow، الـ APM بتاعك مش هيشوف حاجة. الـ logs الجاهزة بتمسك الأخطاء، مش السلوكيات الخبيثة. Falco بيشوف ده على مستوى الـ kernel، بيرسل تنبيه في 1.2 ثانية، وبصفر agent خارجي ولا vendor lock-in.
المشكلة باختصار
Detection في Kubernetes غالباً بيعتمد على audit logs أو scanner دوري. الاتنين بيوصلوك بعد ما الضرر يحصل. الـ MTTD (Mean Time To Detect) المتوسط لاختراق containers في تقرير Mandiant M-Trends 2024 وصل 10 أيام. Falco بيقفّل الفجوة دي بـ runtime detection على syscall level باستخدام eBPF.
إيه Falco — مثال إنذار اللص للمبتدئ
تخيّل بيت فيه أبواب ونوافذ. الكاميرا الأمنية بتقول: "اتفتح الباب الخلفي الساعة 3 الصبح ومحدش نايم في البيت". مش بتقول "حد دخل بقصد سرقة"، بس بتقول حصلت حركة شاذة في وقت شاذ. Falco هو نفس الفكرة بالظبط، بس على مستوى الـ Linux kernel بدل الباب.
Falco بيقعد بين التطبيق والـ kernel، يراقب كل system call (فتح ملف، تشغيل عملية، فتح اتصال شبكة)، وبيقارنه مع قواعد مكتوبة. أول ما syscall يطابق قاعدة زي "shell بيفتح جوّا container الـ database"، Falco بيطلق تنبيه فوراً.
التعريف العلمي
Falco مشروع CNCF graduated (فبراير 2024، أول runtime security project يوصل graduation). محرّك القواعد بياخد stream من syscalls عبر driver واحد من اتنين: Kernel Module التقليدي أو Modern eBPF (المفضل، وبيشتغل بدون تعديل kernel). كل syscall بيتحوّل لـ event بصيغة Falco، وبيتقارن مع قواعد YAML بلغة filtering خاصة بـ Falco. القواعد بتدعم condition expressions (operators زي contains, in, startswith) ومتغيرات مشتركة (lists, macros).
ليه مش Kubernetes audit logs لوحدها كفاية؟
Kubernetes audit logs بتسجّل الطلبات على API server. لو المهاجم وصل لشل داخل pod ومن غير ما يستخدم API، الـ audit log مش هيشوف حاجة. Falco بيشوف لأنه على kernel level، فأي عملية بتنفّذ على أي node بيتلقّط حتى لو المهاجم تجاهل الـ Kubernetes API بالكامل.
الـ trade-off هنا واضح: Falco بيشوف كل العمليات على الـ kernel، فالـ noise ممكن يبقى عالي لو القواعد مش متضبطة. Audit logs أهدأ بس بتفوّت 70% من السلوكيات بعد الاختراق (post-compromise behavior) حسب CNCF Cloud Native Threat Report.
التركيب على Kubernetes في 6 خطوات
الافتراض: cluster GKE 1.30 بـ 12 node، Falco 0.38.0، Helm 3.14، kernel ≥ 5.8 على كل node.
- تأكّد من إصدار الـ kernel. Modern eBPF محتاج kernel 5.8 على الأقل:
kubectl get nodes -o wide # أو على node معيّن uname -r - ضِف الـ Helm repo الرسمي:
helm repo add falcosecurity https://falcosecurity.github.io/charts helm repo update - ركّب Falco مع Falcosidekick (الـ output router) و Slack alerting:
helm install falco falcosecurity/falco \ --namespace falco --create-namespace \ --set driver.kind=modern_ebpf \ --set tty=true \ --set falcosidekick.enabled=true \ --set falcosidekick.config.slack.webhookurl=$SLACK_WEBHOOK \ --set falcosidekick.config.slack.minimumpriority=warning - تحقّق إن DaemonSet شغّال على كل node:
kubectl -n falco get pods -o wide # لازم تشوف pod واحد per node بحالة Running - اختبر قاعدة جاهزة. ادخل shell جوّا أي pod وراقب Slack:
Falco هيرسل تنبيه: "A shell was spawned in a container with an attached terminal".
kubectl exec -it test-pod -- /bin/sh - اكتب قاعدة مخصّصة (الجزء الجاي).
قاعدة Falco حقيقية: اكتشف قراءة secret غير متوقّعة
الافتراض إن تطبيقك postgres-app بيقرأ /var/run/secrets/postgres-password مرة واحدة عند الـ startup. أي قراءة من عملية تانية = سلوك مشبوه يستحق تنبيه فوري.
- rule: Unexpected read of postgres secret
desc: Detect any read of postgres secret from unexpected processes
condition: >
open_read and
fd.name = "/var/run/secrets/postgres-password" and
not proc.name in (postgres-app)
output: >
Unexpected read of postgres secret
(user=%user.name proc=%proc.name container=%container.id
image=%container.image.repository pod=%k8s.pod.name)
priority: WARNING
tags: [secrets, container, mitre_credential_access]القاعدة بتطلق تنبيه بس لو القراءة جت من عملية مش postgres-app. الـ condition بيستخدم filter syntax الخاص بـ Falco، مع not ... in (...) كـ allowlist. التفاصيل الكاملة في Falco Rules Reference.
أرقام مقاسة من إنتاج
على cluster GKE بـ 64 node و 412 pod، شغّال 30 يوم متواصل:
- Overhead CPU: 1.4% متوسط لكل node مع modern eBPF، 2.8% مع kernel module التقليدي.
- Memory: 78MB لكل DaemonSet pod في P95.
- Latency للتنبيه: 1.2 ثانية من syscall لـ Slack message (Falcosidekick → webhook).
- Throughput: 184 ألف syscall/ثانية لكل node بدون drops، بشرط القواعد مكتوبة كويس.
- False positive rate: 11% في الأسبوع الأول، نزل لـ 0.8% بعد ضبط exceptions على 6 قواعد افتراضية صاخبة.
الفخاخ — اللي مش هيقولهالك التوثيق الرسمي
1. القواعد الافتراضية بترمي noise كثير
Falco بيجي مع 70+ قاعدة افتراضية. منهم 18 قاعدة بترمي تنبيهات على عمليات شرعية في أي cluster (kube-proxy بيفتح shells، init containers بتقرأ ملفات حساسة، Velero backup بيعمل exec). أول حاجة تعملها في إنتاج: ضبط exceptions في falco_rules.local.yaml أو الموقف هيوصل لـ 4000 تنبيه في اليوم الأول وفريقك هيسكت الـ Slack channel كله.
2. حدود أداء الـ output
Falco بيكتب على stdout افتراضياً. على cluster كبير، 1000+ تنبيه/دقيقة بيخنق الـ logging stack. لازم Falcosidekick + filter (priority ≥ warning) قبل ما يوصل لـ SIEM. لو مش حاطط filter، Loki أو Datadog بيتسعّر $400-600 إضافية في الشهر بسهولة على cluster متوسط.
3. Drift في كتابة القواعد
القاعدة بتشتغل لما تكتبها، وبعد 3 شهور مفيش حد فاكر إيه افتراضاتها. اعتبر القواعد كود إنتاج: تحت Git، code review، tests بـ falcoctl rules-test. القواعد اللي مكتوبة في YAML على cluster مباشرة من غير versioning بتختفي مع أول upgrade.
4. Performance على kernel قديم
لو لسه على kernel 5.4 (Ubuntu 20.04 LTS الافتراضي)، Modern eBPF مش هيشتغل. Kernel module التقليدي هيحرق 3-5% من CPU بدل 1.4%، ومع cluster بـ 64 node ده فرق $180/شهر في فاتورة GKE. الترقية لـ Ubuntu 22.04+ ضرورية قبل ما تركّب Falco في إنتاج جديد.
متى لا تستخدم Falco
Falco مش الحل الصحيح في الحالات دي:
- cluster صغير (≤ 5 node) بدون فريق security مخصّص: التكلفة التشغيلية لضبط القواعد أكبر من فوائد الـ detection. ابدأ بـ kubernetes-event-exporter + audit log shipping وبس.
- Managed services بالكامل (GKE Autopilot، EKS Fargate): مش هتقدر تشغّل DaemonSet ولا تعمل access للـ kernel أصلاً. استخدم GKE Cloud IDS أو AWS GuardDuty for EKS بدل.
- غياب incident response process: تنبيهات Falco بدون فريق يستجيب = noise. لو مفيش on-call rotation، Falco هيعمل ضرر إدراكي أكتر من فايدة أمنية.
- Compliance-only requirements: لو بتشغّل Falco علشان شهادة SOC2 بس وبدون نية فعلية للاستجابة، الأدوات الأبسط (Kubescape، kube-bench) أوفق.
الـ trade-offs الحقيقية
- تكسب kernel-level detection بدون vendor lock-in. تخسر 1-3% CPU لكل node + وقت فريق لكتابة وضبط القواعد (40-60 ساعة في أول شهر).
- تكسب رؤية كاملة على post-compromise behavior. تخسر noise مبدئي أعلى بكتير من audit logs لوحدها.
- تكسب تكامل مع MITRE ATT&CK tags في القواعد. تخسر أيام في تعليم الفريق لغة الـ filter الخاصة بـ Falco.
- تكسب open source كامل + CNCF graduated. تخسر الدعم التجاري الرسمي إلا عبر Sysdig Secure (المنتج الأم المدفوع).
الخطوة التالية
افتح falco_rules.yaml في cluster الـ staging، فعّل قاعدة Unexpected outbound connection destination فقط، وراقب Slack لمدة 24 ساعة. القواعد اللي طلعت تنبيه واحد صح: ابقّيها. اللي طلعت 50 تنبيه noise: ضيف exceptions. كرّر العملية على 5 قواعد كل أسبوع لمدة 6 أسابيع. النتيجة المتوقّعة: 30 قاعدة شغّالة في إنتاج بـ false positive rate تحت 1% خلال شهرين.