تأمين أنظمة لينكس باستخدام eBPF: دليل شامل لمراقبة الأمان وحماية وقت التشغيل

مقدمة: لماذا تُعد تقنية eBPF ثورة حقيقية في أمان لينكس

في عالم أمان الأنظمة، نواة لينكس (Linux Kernel) هي خط الدفاع الأول والأهم — وهذا ليس مجرد كلام نظري. كل عملية تحدث على النظام، من فتح ملف بسيط إلى إنشاء اتصال شبكي، تمر حتماً عبر النواة. المشكلة؟ مراقبة هذه العمليات تقليدياً كانت مؤلمة: إما تعديل كود النواة مباشرة (وهو أمر محفوف بالمخاطر يُقلق كل من جرّبه)، أو الاعتماد على وحدات نواة (Kernel Modules) قد تُسبب عدم استقرار النظام بأكمله. هنا تأتي تقنية eBPF (extended Berkeley Packet Filter) لتُغير قواعد اللعبة بالكامل.

eBPF تسمح بتشغيل برامج مُصغّرة داخل النواة بشكل آمن ومُتحقق منه، دون الحاجة لتعديل كود النواة أو تحميل وحدات نواة تقليدية. هذه البرامج يمكنها مراقبة كل شيء: استدعاءات النظام (System Calls)، حركة الشبكة، عمليات الملفات، وحتى الأحداث على مستوى الأجهزة — كل ذلك بأثر أداء ضئيل للغاية.

والأرقام تتحدث عن نفسها: في عام 2025، وصل عدد ثغرات نواة لينكس المُعلنة (CVE) إلى 5,530 ثغرة، بزيادة قدرها 28% عن العام السابق. هذا الارتفاع يجعل الحاجة إلى مراقبة أمنية فعّالة على مستوى النواة أمراً لا يمكن تأجيله بأي حجة.

eBPF هو لنواة لينكس ما كان JavaScript للمتصفحات — تقنية تحويلية تسمح بالبرمجة داخل بيئة كانت جامدة سابقاً، مع ضمانات أمان مدمجة تمنع الأكواد الخبيثة من الإضرار بالنظام.

تاريخياً، بدأت تقنية BPF الأصلية عام 1992 كآلية بسيطة لتصفية حزم الشبكة في نظام BSD، ومن هنا جاء اسمها "Berkeley Packet Filter". لكن في عام 2014، قام Alexei Starovoitov بتقديم نسخة موسّعة بشكل جذري أُطلق عليها eBPF، والتي حوّلت هذه الآلية البسيطة إلى منصة برمجة كاملة داخل النواة. اليوم تُستخدم eBPF في كل شيء من مراقبة الأداء إلى أمان الشبكات وصولاً إلى فرض سياسات الأمان على مستوى النواة. وقد تبنّت شركات كبرى مثل Google وFacebook وNetflix وCloudflare هذه التقنية في بنيتها التحتية الإنتاجية — وهذا بحد ذاته شهادة على نضجها واستقرارها.

ما يجعل eBPF فريدة في مجال الأمان تحديداً هو أنها تعمل في نفس المستوى الذي تعمل فيه التهديدات. عندما يحاول مهاجم استغلال ثغرة في النواة أو تحميل وحدة نواة خبيثة، برنامج eBPF يرى هذا النشاط فور حدوثه — لا بعد ثوانٍ أو دقائق، بل في نفس اللحظة. هذه الفورية في الكشف هي ما يجعل أدوات الأمان المبنية على eBPF متفوقة بشكل واضح على الحلول التقليدية التي تعمل في مساحة المستخدم وتعتمد على قراءة سجلات الأحداث بعد وقوعها.

كيف تعمل تقنية eBPF على مستوى النواة: البنية والتحقق

البنية الأساسية لتقنية eBPF

لفهم قوة eBPF في مجال الأمان، يجب أولاً فهم كيف تعمل على المستوى المعماري. عندما يُكتب برنامج eBPF، يمر بعدة مراحل قبل أن يُنفّذ داخل النواة:

1. الكتابة والتجميع: يُكتب البرنامج عادة بلغة C المُقيّدة أو باستخدام أُطر عمل عالية المستوى، ثم يُجمّع إلى كود eBPF الثُنائي (bytecode).
2. التحقق (Verification): قبل التحميل في النواة، يمر البرنامج عبر مُحقق eBPF (eBPF Verifier) الذي يفحص كل مسار تنفيذ ممكن للتأكد من أمان البرنامج.
3. الترجمة JIT: بعد التحقق، يُترجم البرنامج إلى كود آلة أصلي (Native Machine Code) باستخدام مُترجم JIT لتحقيق أفضل أداء.
4. الربط بنقاط الالتقاط: يُربط البرنامج بنقطة التقاط (Hook Point) محددة في النواة — مثل استدعاء نظام معين أو حدث شبكي.
5. التنفيذ وجمع البيانات: عند وقوع الحدث المُراقب، يُنفّذ البرنامج ويمكنه إرسال البيانات إلى مساحة المستخدم عبر خرائط eBPF (eBPF Maps).

مُحقق eBPF: خط الدفاع الأول

مُحقق eBPF هو المكون الأكثر أهمية من الناحية الأمنية — وصراحةً، أعتقد أنه أذكى جزء في التصميم بأكمله. يقوم بعدة فحوصات حرجة:

• تحليل المسارات: يتحقق من أن كل مسار تنفيذ ينتهي بشكل صحيح ولا يوجد حلقات لا نهائية.
• التحقق من الذاكرة: يضمن أن البرنامج لا يصل إلى مناطق ذاكرة غير مسموح بها.
• التحقق من الأنواع: يفحص أن جميع عمليات القراءة والكتابة تتم على أنواع بيانات صحيحة.
• حدود التعقيد: يفرض حداً أقصى لعدد التعليمات (مليون تعليمة في النوى الحديثة) لمنع البرامج المُعقدة بشكل مُفرط.

يمكنك فحص البرامج المُحمّلة حالياً في النظام باستخدام الأمر التالي:

# List all loaded eBPF programs
sudo bpftool prog list

# Show detailed info about a specific program
sudo bpftool prog show id 42

# Dump the bytecode of an eBPF program
sudo bpftool prog dump xlated id 42

# List all eBPF maps
sudo bpftool map list

# Show system eBPF features and capabilities
sudo bpftool feature probe

نقاط الالتقاط (Hook Points) المتاحة

تتيح eBPF الربط بعدد كبير من نقاط الالتقاط داخل النواة، وكل نوع يخدم غرضاً أمنياً مختلفاً:

• Kprobes/Kretprobes: مراقبة أي دالة داخل النواة — مثالية لتتبع العمليات المشبوهة.
• Tracepoints: نقاط مراقبة مُعرّفة مسبقاً في النواة — أكثر استقراراً عبر إصدارات النواة.
• LSM Hooks: نقاط التقاط وحدات الأمان في لينكس — تسمح باتخاذ قرارات أمنية فعلية (السماح أو المنع).
• XDP (eXpress Data Path): أسرع نقطة لمعالجة حزم الشبكة — مثالية لتصفية حركة المرور الضارة.
• TC (Traffic Control): مراقبة وتعديل حركة الشبكة الصادرة والواردة.
• Uprobe/USDT: مراقبة تطبيقات مساحة المستخدم — مفيدة لتتبع سلوك التطبيقات.

eBPF سلاح ذو حدين: القدرات الدفاعية والهجومية

القدرات الدفاعية

على الجانب الدفاعي، تُتيح eBPF إمكانيات غير مسبوقة في مراقبة الأمان:

• اكتشاف التهديدات في الوقت الفعلي: مراقبة استدعاءات النظام المشبوهة فور حدوثها دون أي تأخير يُذكر.
• فرض السياسات الأمنية داخل النواة: حظر العمليات الخبيثة قبل أن تكتمل، وليس بعد اكتشافها.
• مراقبة الشبكة العميقة: فحص كل حزمة بيانات على مستوى النواة مع القدرة على حظر الاتصالات المشبوهة فوراً.
• تحليل جنائي رقمي: تسجيل سلاسل الأحداث الكاملة لفهم كيفية حدوث الاختراق.

القدرات الهجومية والمخاطر

لكن eBPF يمكن أن تُستخدم أيضاً كأداة هجومية — وهذا الجانب لا يحظى باهتمام كافٍ في كثير من النقاشات. إذا تمكن مهاجم من تحميل برنامج eBPF خبيث (وهو ما يتطلب صلاحيات CAP_BPF أو CAP_SYS_ADMIN)، يمكنه:

• إخفاء العمليات الضارة: تعديل البيانات المُرسلة إلى أدوات المراقبة لإخفاء الأنشطة الخبيثة.
• اعتراض البيانات الحساسة: التقاط كلمات المرور وبيانات التشفير قبل تشفيرها.
• التلاعب بحركة الشبكة: إعادة توجيه الاتصالات أو حقن بيانات ضارة.
• إنشاء أبواب خلفية مُستترة: برامج rootkit على مستوى النواة يصعب اكتشافها بالأدوات التقليدية.

لهذا السبب، من الضروري مراقبة تحميل برامج eBPF نفسها — وهو ما سنتناوله بالتفصيل لاحقاً.

من الأمثلة الواقعية على استخدام eBPF في الهجمات، ظهور أُطر عمل مثل TripleCross و ebpfkit التي تُثبت إمكانية بناء rootkits متقدمة باستخدام eBPF. هذه الأدوات قادرة على اعتراض استدعاءات النظام وتعديل مخرجاتها، مما يجعل العمليات الخبيثة غير مرئية لأدوات المراقبة التقليدية مثل ps و ls و netstat. الخبر الجيد هو أن تحميل برامج eBPF يتطلب صلاحيات مرتفعة، والخبر الأفضل هو أن أدوات مثل Tetragon و Falco يمكنها اكتشاف محاولات تحميل برامج eBPF غير مُصرّح بها.

أدوات أمان eBPF الرئيسية

Tetragon من Cilium: فرض السياسات الأمنية داخل النواة

يُعد Tetragon من أقوى أدوات الأمان المبنية على eBPF وأكثرها كفاءة من حيث الأداء. ما يميزه هو قدرته على فرض السياسات الأمنية داخل النواة مباشرة (In-Kernel Enforcement)، أي أنه يحظر العمليات الخبيثة قبل أن تكتمل، دون الحاجة لإرسال الأحداث إلى مساحة المستخدم أولاً.

المزايا الرئيسية لـ Tetragon:

• أقل استهلاك للموارد بين أدوات أمان eBPF — مثالي لبيئات الإنتاج الحساسة.
• تصفية داخل النواة: تقليل كمية البيانات المُرسلة إلى مساحة المستخدم بشكل كبير.
• تكامل أصلي مع Kubernetes: يوفر رؤية أمنية على مستوى الحاويات والـ Pods.
• سياسات TracingPolicy مرنة: تعريف قواعد مراقبة وفرض مُخصصة باستخدام YAML.

Falco: مراقبة وقت التشغيل باستخدام استدعاءات النظام

Falco — المشروع المُتخرج من CNCF — يُعد من أقدم أدوات مراقبة وقت التشغيل وأكثرها نضجاً. يعمل عبر مراقبة استدعاءات النظام (System Calls) ومقارنتها بمجموعة قواعد قابلة للتخصيص.

نقاط القوة في Falco:

• مكتبة قواعد غنية: يأتي مع مئات القواعد المُعدّة مسبقاً لاكتشاف أنماط الهجوم الشائعة.
• مجتمع نشط: كونه مشروع CNCF يضمن تحديثات مستمرة ودعم واسع.
• تكاملات متعددة: إرسال التنبيهات إلى Slack وPagerDuty وSIEM وغيرها.
• دعم محرك eBPF حديث: انتقل من وحدة نواة تقليدية إلى محرك eBPF أكثر أماناً واستقراراً.

ملاحظة مهمة: Falco يحتاج عادة إلى 2-4 أسابيع من التخصيص الأولي للقواعد في بيئة الإنتاج لتقليل الإنذارات الكاذبة. خلال هذه الفترة، شغّل Falco في وضع المراقبة فقط (بدون اتخاذ إجراءات تلقائية) لفهم أنماط السلوك الطبيعي وتحديد القواعد التي تحتاج إلى تعديل. هذه المرحلة حرجة لأن الإنذارات الكاذبة المُفرطة تؤدي إلى ما يُعرف بـ إرهاق التنبيهات (Alert Fatigue) — وهو سيناريو رأيته يحدث في بيئات حقيقية أكثر مما يجب — حيث يبدأ فريق الأمان في تجاهل التنبيهات مما قد يؤدي إلى تفويت تهديدات حقيقية.

Tracee من Aqua Security: التتبع العميق والتحليل الجنائي

Tracee يتميز بقدراته الاستثنائية في التتبع العميق على مستوى النواة والتحليل الجنائي الرقمي. يستخدم eBPF لمراقبة مئات من أحداث النواة ويوفر سياقاً غنياً لكل حدث.

ما يميز Tracee:

• كشف الأحداث على مستوى النواة: مراقبة أكثر من 400 نوع من أحداث النواة.
• محرك التوقيعات: كشف أنماط الهجوم المعروفة تلقائياً باستخدام توقيعات Rego أو Go.
• تحليل جنائي مُتقدم: تسجيل سلاسل الأحداث الكاملة مع الربط الزمني.
• دعم DNS وHTTP: التقاط وتحليل حركة الشبكة على مستوى التطبيق.

لكن خذ بالاعتبار أن Tracee يستهلك موارد أكثر مقارنة بـ Tetragon — تقريباً 2-4 أضعاف — بسبب عمق التتبع والمعلومات التفصيلية التي يجمعها. لذا يُنصح باستخدامه في بيئات التحليل الجنائي أو بيئات الاختبار، أو بتكوين انتقائي في بيئات الإنتاج.

Cilium: أمان الشبكات المبني على eBPF

Cilium هو الحل الأشمل لأمان الشبكات في بيئات Kubernetes، ويستخدم eBPF لتوفير:

• سياسات الشبكة (Network Policies): فرض قواعد دقيقة للتحكم في حركة المرور بين الخدمات.
• مراقبة الشبكة العميقة: رؤية كاملة لحركة المرور على مستوى L3/L4/L7.
• توزيع الحمل (Load Balancing): بديل عالي الأداء لـ kube-proxy.
• تشفير شفاف: تشفير الاتصالات بين العقد باستخدام WireGuard أو IPSec.
• Hubble: منصة مراقبة شبكية مبنية على eBPF توفر رؤية شاملة.

دليل التنفيذ العملي

تثبيت وتكوين Tetragon على Kubernetes

إذاً، لنبدأ بالجزء العملي. تثبيت Tetragon على مجموعة Kubernetes أسهل مما قد تتوقع. الطريقة الأكثر شيوعاً هي استخدام Helm. قبل البدء، تأكد من أن إصدار نواة لينكس على عُقد المجموعة هو 4.19 أو أحدث (ويُفضل 5.10+ للحصول على جميع الميزات)، وأن ملف BTF (BPF Type Format) متاح في المسار /sys/kernel/btf/vmlinux لتمكين البرامج المنقولة عبر إصدارات النواة المختلفة:

# Add the Cilium Helm repository
helm repo add cilium https://helm.cilium.io
helm repo update

# Install Tetragon with recommended production settings
helm install tetragon cilium/tetragon \
  --namespace kube-system \
  --set tetragon.enableProcessCred=true \
  --set tetragon.enableProcessNs=true \
  --set tetragon.hostProcPath=/proc \
  --set exportFilename=tetragon.log \
  --set tetragon.exportRateLimit=100 \
  --set tetragon.btf="/sys/kernel/btf/vmlinux"

# Verify Tetragon is running
kubectl get pods -n kube-system -l app.kubernetes.io/name=tetragon

# Install the tetra CLI for inspecting events
GOOS=$(go env GOOS)
GOARCH=$(go env GOARCH)
curl -L --remote-name-all \
  https://github.com/cilium/tetragon/releases/latest/download/tetra-${GOOS}-${GOARCH}.tar.gz
sudo tar -C /usr/local/bin -xzvf tetra-${GOOS}-${GOARCH}.tar.gz
sudo chmod +x /usr/local/bin/tetra

# Stream live Tetragon events
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon \
  -c export-stdout -f | tetra getevents -o compact

كتابة سياسات TracingPolicy مُخصصة لاكتشاف السلوكيات المشبوهة

قوة Tetragon الحقيقية تكمن في سياسات TracingPolicy المُخصصة. تُعرّف هذه السياسات باستخدام YAML وتحدد بدقة ما يجب مراقبته وكيفية الاستجابة. يمكن لكل سياسة تحديد نقاط الالتقاط (Kprobes أو Tracepoints)، وشروط التصفية (Selectors)، والإجراءات (Actions) التي تتراوح بين التسجيل البسيط وإيقاف العملية بإشارة SIGKILL. لنكتب عدة سياسات عملية تُغطي سيناريوهات أمنية شائعة:

السياسة الأولى: اكتشاف قراءة الملفات الحساسة

# sensitive-file-access.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: sensitive-file-access
spec:
  kprobes:
    - call: "fd_install"
      syscall: false
      args:
        - index: 0
          type: int
        - index: 1
          type: "file"
      selectors:
        - matchArgs:
            - index: 1
              operator: "Prefix"
              values:
                - "/etc/shadow"
                - "/etc/passwd"
                - "/etc/sudoers"
                - "/root/.ssh/"
                - "/etc/kubernetes/pki/"
          matchActions:
            - action: Post
              rateLimit: "1m"
            - action: NotifyEnforcer
              argError: -1

السياسة الثانية: اكتشاف تنفيذ الأوامر المشبوهة داخل الحاويات

# suspicious-container-exec.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: suspicious-container-exec
spec:
  tracepoints:
    - subsystem: "raw_syscalls"
      event: "sys_enter"
      args:
        - index: 4
          type: "syscall64"
      selectors:
        - matchArgs:
            - index: 4
              operator: "Equal"
              values:
                - "59"  # execve syscall number
          matchBinaries:
            - operator: "In"
              values:
                - "/bin/bash"
                - "/bin/sh"
                - "/usr/bin/curl"
                - "/usr/bin/wget"
                - "/usr/bin/nc"
                - "/usr/bin/ncat"
                - "/usr/bin/nmap"
                - "/usr/bin/python"
                - "/usr/bin/python3"
          matchNamespaces:
            - namespace: Pid
              operator: NotEqual
              values:
                - "4026531836"  # host PID namespace
          matchActions:
            - action: Sigkill

لتطبيق هذه السياسات:

# Apply the tracing policies
kubectl apply -f sensitive-file-access.yaml
kubectl apply -f suspicious-container-exec.yaml

# Verify policies are loaded
kubectl get tracingpolicies
kubectl describe tracingpolicy sensitive-file-access

# Monitor events from these policies in real-time
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon \
  -c export-stdout -f | tetra getevents -o compact \
  --policy-names sensitive-file-access,suspicious-container-exec

إعداد Falco مع قواعد مُخصصة

الآن لنقم بتثبيت Falco وإعداد قواعد مُخصصة للكشف عن التهديدات:

# Install Falco on Kubernetes using Helm
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Install with eBPF driver (recommended over kernel module)
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/XXX" \
  --set falcosidekick.config.slack.minimumpriority=warning \
  --set collectors.kubernetes.enabled=true \
  --set tty=true

# Verify Falco is running
kubectl get pods -n falco
kubectl logs -n falco -l app.kubernetes.io/name=falco -f

والآن الجزء الممتع — كتابة قواعد Falco مُخصصة:

# custom-falco-rules.yaml
# Rule 1: Detect cryptocurrency mining processes
- rule: Detect Crypto Mining Activity
  desc: >
    Detects processes commonly associated with cryptocurrency mining
    based on process names and command-line arguments.
  condition: >
    spawned_process and
    (proc.name in (xmrig, minerd, cpuminer, cgminer, bfgminer,
                   ethminer, stratum, cryptonight) or
     proc.cmdline contains "stratum+tcp://" or
     proc.cmdline contains "stratum+ssl://" or
     proc.cmdline contains "--donate-level" or
     proc.cmdline contains "-o pool." or
     proc.cmdline contains "nicehash")
  output: >
    Cryptocurrency mining activity detected
    (user=%user.name command=%proc.cmdline container=%container.name
     pod=%k8s.pod.name namespace=%k8s.ns.name image=%container.image.repository)
  priority: CRITICAL
  tags: [cryptomining, mitre_execution]

# Rule 2: Detect reverse shell attempts
- rule: Detect Reverse Shell
  desc: Detects attempts to create reverse shells
  condition: >
    spawned_process and
    ((proc.name = "bash" and proc.cmdline contains "/dev/tcp/") or
     (proc.name = "python" and proc.cmdline contains "socket" and
      proc.cmdline contains "connect") or
     (proc.name = "perl" and proc.cmdline contains "socket" and
      proc.cmdline contains "INET") or
     (proc.name = "nc" and proc.args contains "-e") or
     (proc.name = "ncat" and proc.args contains "--sh-exec") or
     (proc.name = "socat" and proc.cmdline contains "EXEC"))
  output: >
    Reverse shell attempt detected
    (user=%user.name command=%proc.cmdline pid=%proc.pid
     container=%container.name pod=%k8s.pod.name
     namespace=%k8s.ns.name parent=%proc.pname)
  priority: CRITICAL
  tags: [reverse_shell, mitre_execution, mitre_command_and_control]

# Rule 3: Detect sensitive mount in container
- rule: Sensitive Host Mount in Container
  desc: Detects containers with sensitive host path mounts
  condition: >
    container and evt.type = execve and
    (container.mount.source[/proc] != "" or
     container.mount.source[/sys] != "" or
     container.mount.source[/etc] != "" or
     container.mount.source[/var/run/docker.sock] != "")
  output: >
    Container with sensitive host mount detected
    (container=%container.name image=%container.image.repository
     pod=%k8s.pod.name namespace=%k8s.ns.name mounts=%container.mounts)
  priority: WARNING
  tags: [container_escape, mitre_privilege_escalation]

# Rule 4: Detect eBPF program loading (meta-security)
- rule: eBPF Program Loaded
  desc: Detects loading of eBPF programs which could indicate rootkit installation
  condition: >
    evt.type = bpf and evt.arg.cmd = 5 and
    not proc.name in (tetragon, falco, cilium-agent, tracee,
                      bpftool, systemd)
  output: >
    eBPF program loaded by unexpected process
    (user=%user.name command=%proc.cmdline pid=%proc.pid
     parent=%proc.pname container=%container.name)
  priority: WARNING
  tags: [ebpf_loading, mitre_defense_evasion]

لتحميل هذه القواعد المُخصصة، أنشئ ConfigMap:

# Create ConfigMap from custom rules
kubectl create configmap falco-custom-rules \
  --from-file=custom-falco-rules.yaml \
  -n falco

# Update Falco Helm deployment to use custom rules
helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set driver.kind=ebpf \
  --set "falco.rulesFile[0]=/etc/falco/falco_rules.yaml" \
  --set "falco.rulesFile[1]=/etc/falco/custom-rules/custom-falco-rules.yaml" \
  --set-file "customRules.custom-falco-rules\.yaml=custom-falco-rules.yaml"

# Test rules by triggering a known pattern
kubectl exec -it test-pod -- bash -c "cat /etc/shadow"

# Check Falco logs for the alert
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=20

استخدام Tracee للتحليل الجنائي

Tracee ممتاز للتحقيقات الجنائية العميقة والاستجابة للحوادث الأمنية. يمكن تشغيله بسرعة كحاوية Docker لإجراء تحليل فوري عند الاشتباه في اختراق، أو نشره كـ DaemonSet على Kubernetes للمراقبة المستمرة. ما يميزه حقاً هو قدرته على تتبع سلسلة الأحداث الكاملة — من لحظة تنفيذ أمر مشبوه وحتى جميع العمليات الفرعية والملفات التي يلمسها والاتصالات الشبكية التي يُنشئها. هذا المستوى من التفصيل لا يُقدّر بثمن عند محاولة فهم نطاق الاختراق وتأثيره.

لنقم بتشغيله مع التركيز على سيناريو التحقيق:

# Run Tracee as a Docker container for quick forensic analysis
docker run --name tracee -it --rm \
  --pid=host \
  --cgroupns=host \
  --privileged \
  -v /etc/os-release:/etc/os-release-host:ro \
  -v /boot/config-$(uname -r):/boot/config-$(uname -r):ro \
  -e LIBBPFGO_OSRELEASE_FILE=/etc/os-release-host \
  aquasec/tracee:latest \
  --events execve,execveat,security_file_open,mem_prot_alert,ptrace \
  --scope comm!=sshd --scope comm!=systemd \
  --output json

# Run Tracee with specific security signatures enabled
docker run --name tracee -it --rm \
  --pid=host \
  --cgroupns=host \
  --privileged \
  -v /etc/os-release:/etc/os-release-host:ro \
  -e LIBBPFGO_OSRELEASE_FILE=/etc/os-release-host \
  aquasec/tracee:latest \
  --events anti_debugging,aslr_inspection,cgroup_notify_on_release,\
default_loader_mod,disk_mount,dynamic_code_loading,fileless_execution,\
hidden_file_created,illegitimate_shell,kernel_module_loading,\
k8s_api_connection,proc_mem_access,process_vm_write_inject,\
rcd_modification,scheduled_task_mod,stdio_over_socket,\
sudoers_modification,syscall_table_check,system_request_key_mod

# Deploy Tracee on Kubernetes for ongoing monitoring
helm repo add aqua https://aquasecurity.github.io/helm-charts
helm install tracee aqua/tracee \
  --namespace tracee --create-namespace \
  --set hostPID=true \
  --set tracee.events="{execve,security_file_open,ptrace,mem_prot_alert}" \
  --set tracee.output.format=json

الحماية من هجمات eBPF نفسها

مراقبة تحميل برامج eBPF

كما ذكرنا، eBPF يمكن أن يُستخدم كأداة هجومية خطيرة. في السنوات الأخيرة ظهرت عدة حالات موثقة لاستخدام eBPF في هجمات متقدمة، بما في ذلك برامج rootkit تعمل بالكامل من خلال برامج eBPF دون الحاجة لتحميل وحدات نواة تقليدية. هذا النوع من الهجمات صعب الاكتشاف لأن برامج eBPF لا تظهر كوحدات نواة في مخرجات lsmod، ولا تترك آثاراً على نظام الملفات بالضرورة.

لذا من الضروري مراقبة عمليات تحميل برامج eBPF نفسها بشكل استباقي. يمكن استخدام عدة طرق متكاملة:

أولاً: استخدام أدوات التدقيق (Audit) المدمجة في النواة:

# Add audit rules to monitor bpf() system call
# The bpf() syscall number is 321 on x86_64
sudo auditctl -a always,exit -F arch=b64 -S bpf -k ebpf_monitoring

# Monitor the audit log for eBPF-related events
sudo ausearch -k ebpf_monitoring --interpret

# Make the audit rule persistent
echo "-a always,exit -F arch=b64 -S bpf -k ebpf_monitoring" | \
  sudo tee -a /etc/audit/rules.d/ebpf.rules

# Restart auditd to apply
sudo systemctl restart auditd

# List currently loaded eBPF programs and check for anomalies
sudo bpftool prog list --json | python3 -c "
import json, sys
progs = json.load(sys.stdin)
for p in progs:
    prog_type = p.get('type', 'unknown')
    name = p.get('name', 'unnamed')
    loaded_at = p.get('loaded_at', 'unknown')
    print(f'ID: {p[\"id\"]} | Type: {prog_type} | Name: {name} | Loaded: {loaded_at}')
"

استخدام eBPFmon من Red Canary

أداة eBPFmon التي طورتها Red Canary مُصممة خصيصاً لمراقبة وكشف برامج eBPF المشبوهة. تعمل كطبقة أمان إضافية تراقب البرامج المُحمّلة وتُقارنها بقاعدة بيانات للبرامج المعروفة والموثوقة.

المبدأ بسيط وفعّال: إنشاء قائمة بيضاء (Allowlist) لبرامج eBPF المسموح بها، والتنبيه عند اكتشاف أي برنامج غير معروف. عدد برامج eBPF الشرعية في نظام معين يكون عادة محدوداً ومعروفاً — وهذا ما يجعل أي انحراف عن الخط الأساسي مؤشراً واضحاً يستحق التحقيق.

يمكن تشغيل eBPFmon لأخذ لقطة أساسية (Baseline) من برامج eBPF المُحمّلة حالياً، ثم مراقبة أي تغييرات مُستقبلية. أي برنامج جديد يُحمّل ولم يكن في القائمة الأساسية يُثير تنبيهاً فورياً يجب التحقيق فيه.

تقييد وصول eBPF غير المُمتاز

من أهم إجراءات التقوية — وربما أبسطها — هو تقييد من يمكنه تحميل برامج eBPF:

# Disable unprivileged eBPF access (critical security hardening)
sudo sysctl -w kernel.unprivileged_bpf_disabled=2

# Make it persistent across reboots
echo "kernel.unprivileged_bpf_disabled=2" | \
  sudo tee /etc/sysctl.d/99-ebpf-hardening.conf

# Additional hardening: enable JIT hardening
sudo sysctl -w net.core.bpf_jit_harden=2
echo "net.core.bpf_jit_harden=2" | \
  sudo tee -a /etc/sysctl.d/99-ebpf-hardening.conf

# Lock down BPF-related capabilities using systemd
# In your service unit file, add:
# [Service]
# CapabilityBoundingSet=~CAP_BPF CAP_SYS_ADMIN CAP_PERFMON
# This prevents the service from gaining BPF capabilities

# Apply all sysctl changes
sudo sysctl --system

# Verify the settings
sysctl kernel.unprivileged_bpf_disabled
sysctl net.core.bpf_jit_harden

قيمة 2 لـ kernel.unprivileged_bpf_disabled تعني أنه لا يمكن إعادة تفعيله بدون إعادة تشغيل النظام — وهو أكثر أماناً من القيمة 1 التي يمكن التراجع عنها. فارق بسيط في الرقم، لكن فارق كبير في الأمان الفعلي.

التكامل مع خطوط أنابيب DevSecOps

دمج أمان eBPF في دورة التطوير

لتحقيق أقصى استفادة من أدوات أمان eBPF، يجب دمجها في خطوط أنابيب DevSecOps بشكل منهجي. الهدف هو جعل المراقبة الأمنية جزءاً لا يتجزأ من دورة حياة التطبيق — لا إضافة تأتي في آخر المطاف:

مرحلة البناء (Build):

• فحص صور الحاويات بحثاً عن ثغرات معروفة باستخدام أدوات مثل Trivy.
• التحقق من أن سياسات Tetragon TracingPolicy و Falco Rules مُضمّنة في مستودعات الكود.
• اختبار سياسات الأمان في بيئة CI/CD قبل النشر.

مرحلة النشر (Deploy):

• نشر سياسات Tetragon و Falco تلقائياً مع كل عملية نشر باستخدام GitOps (مثل ArgoCD أو Flux).
• تفعيل سياسات Cilium Network Policies الخاصة بكل تطبيق.
• التأكد من أن كل Namespace يحتوي على سياسات أمان eBPF مُناسبة.

مرحلة التشغيل (Run):

• مراقبة مستمرة باستخدام Tetragon مع إرسال الأحداث إلى SIEM.
• تنبيهات فورية من Falco عبر Falcosidekick إلى قنوات الاستجابة.
• تحليل جنائي دوري باستخدام Tracee عند الحاجة.
• مراجعة دورية لسياسات الأمان وتحديثها بناءً على التهديدات الجديدة.

مثال على تكوين خط أنابيب يتضمن نشر سياسات أمان eBPF:

# .github/workflows/deploy-security-policies.yaml
name: Deploy eBPF Security Policies
on:
  push:
    branches: [main]
    paths:
      - 'security-policies/**'

jobs:
  validate-policies:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Validate Tetragon TracingPolicies
        run: |
          # Install kubectl and validate YAML syntax
          for policy in security-policies/tetragon/*.yaml; do
            echo "Validating $policy..."
            kubectl apply --dry-run=client -f "$policy" 2>&1
            if [ $? -ne 0 ]; then
              echo "ERROR: Invalid policy $policy"
              exit 1
            fi
          done

      - name: Validate Falco Rules Syntax
        run: |
          docker run --rm \
            -v $(pwd)/security-policies/falco:/rules \
            falcosecurity/falco:latest \
            /usr/bin/falco --validate /rules/custom-rules.yaml

      - name: Run Policy Tests
        run: |
          # Use kind cluster for testing
          kind create cluster --name policy-test
          kubectl apply -f security-policies/tetragon/
          # Run test scenarios
          ./tests/test-security-policies.sh
          kind delete cluster --name policy-test

  deploy-policies:
    needs: validate-policies
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4

      - name: Configure kubectl
        uses: azure/k8s-set-context@v4
        with:
          kubeconfig: ${{ secrets.KUBE_CONFIG }}

      - name: Deploy Tetragon Policies
        run: kubectl apply -f security-policies/tetragon/

      - name: Deploy Falco Custom Rules
        run: |
          kubectl create configmap falco-custom-rules \
            --from-file=security-policies/falco/ \
            -n falco --dry-run=client -o yaml | \
            kubectl apply -f -
          # Restart Falco to pick up new rules
          kubectl rollout restart daemonset/falco -n falco

      - name: Verify Deployment
        run: |
          kubectl get tracingpolicies
          kubectl wait --for=condition=ready pod \
            -l app.kubernetes.io/name=falco -n falco \
            --timeout=120s

اعتبارات الأداء ومقارنة الحِمل الإضافي

تحليل مقارن لأداء أدوات eBPF الأمنية

أحد أهم العوامل في اختيار أداة أمان eBPF هو تأثيرها على أداء النظام — وهذا سؤال يطرحه كل مهندس بنية تحتية تقريباً. في بيئات الإنتاج، كل ميلي ثانية إضافية تأخير يمكن أن تؤثر على تجربة المستخدم وتكلفة البنية التحتية. الميزة الأساسية لأدوات eBPF مقارنة بحلول الأمان التقليدية هي أن البرامج تُنفّذ مباشرة في سياق النواة دون الحاجة لنسخ البيانات إلى مساحة المستخدم — وهو ما يُعرف بتكلفة تبديل السياق (Context Switching). ومع ذلك، تختلف الأدوات فيما بينها.

بناءً على اختبارات الأداء في بيئات إنتاج حقيقية (الأرقام تقريبية وتتفاوت حسب الحمل وعدد القواعد):

Tetragon:

• استهلاك وحدة المعالجة المركزية: 1-3% إضافي في الحالة النموذجية.
• استهلاك الذاكرة: 100-250 ميجابايت لكل عقدة.
• تأخير إضافي على استدعاءات النظام: أقل من 1 ميكروثانية.
• الأقل استهلاكاً للموارد بفضل التصفية داخل النواة.

Falco (محرك eBPF):

• استهلاك وحدة المعالجة المركزية: 3-7% إضافي حسب عدد القواعد المُفعّلة.
• استهلاك الذاكرة: 200-500 ميجابايت لكل عقدة.
• تأخير إضافي: 2-5 ميكروثانية لمطابقة القواعد في مساحة المستخدم.
• أداء أفضل بشكل ملحوظ مع محرك eBPF مقارنة بوحدة النواة القديمة.

Tracee:

• استهلاك وحدة المعالجة المركزية: 5-12% إضافي بسبب عمق التتبع.
• استهلاك الذاكرة: 300-800 ميجابايت لكل عقدة.
• تأخير إضافي: 3-8 ميكروثانية.
• الحمل الإضافي أعلى بـ 2-4 أضعاف مقارنة بـ Tetragon — وهو ثمن التحليل الجنائي العميق.

نصائح لتحسين الأداء

• استخدم التصفية الانتقائية: لا تراقب كل شيء — حدد الأحداث والمسارات الأكثر أهمية فقط.
• استفد من التصفية داخل النواة: Tetragon يتفوق هنا لأنه يُصفّي البيانات قبل إرسالها لمساحة المستخدم.
• حدد معدل الأحداث (Rate Limiting): تجنب إغراق النظام بالأحداث المتكررة.
• استخدم أدوات مختلفة لأغراض مختلفة: Tetragon لفرض السياسات في الإنتاج، و Tracee للتحقيقات المُحددة.
• راقب استهلاك موارد أدوات eBPF نفسها: ضع حدوداً لاستهلاك الموارد (Resource Limits) في Kubernetes.

أفضل الممارسات لعام 2026 وما بعده

استراتيجية أمان eBPF شاملة

مع تطور مشهد التهديدات بسرعة — وأحياناً بشكل يفاجئ حتى المتخصصين — إليك أفضل الممارسات لبناء استراتيجية أمان قوية مبنية على eBPF:

1. تبنّي نهج الدفاع في العمق (Defense in Depth):

• لا تعتمد على أداة واحدة فقط. استخدم Tetragon لفرض السياسات، و Falco للكشف الواسع، و Cilium لأمان الشبكات.
• اجعل أدوات eBPF طبقة واحدة ضمن استراتيجية أمان متعددة الطبقات تتضمن أيضاً SELinux/AppArmor، وجدران الحماية التقليدية، وأنظمة SIEM.

2. أتمتة كل شيء:

• ادمج سياسات الأمان في خطوط أنابيب CI/CD كما رأينا في القسم السابق.
• استخدم GitOps لإدارة سياسات TracingPolicy و Falco Rules كأكواد مصدرية.
• أتمتة الاستجابة للحوادث: عند كشف تهديد، يمكن لـ Tetragon قتل العملية تلقائياً، ويمكن لـ Falcosidekick تشغيل وظائف Kubernetes Job للعزل.

3. ابنِ رؤية شاملة (Observability):

• اجمع جميع أحداث eBPF الأمنية في منصة مركزية مثل Elasticsearch أو Splunk أو Grafana Loki.
• أنشئ لوحات معلومات (Dashboards) تُظهر الحالة الأمنية في الوقت الفعلي.
• استخدم Hubble (من Cilium) لمراقبة حركة الشبكة بين الخدمات.

4. التحديث المستمر:

• حدّث نواة لينكس بانتظام للحصول على أحدث ميزات eBPF وإصلاحات الأمان. النوى الأحدث (6.x+) توفر ميزات eBPF أكثر قوة وأماناً.
• تابع تحديثات أدوات الأمان — Tetragon و Falco و Tracee تتطور بسرعة.
• راجع سياساتك الأمنية دورياً وحدّثها بناءً على أحدث أساليب الهجوم.

5. قوّ أمان eBPF نفسه:

• عطّل eBPF غير المُمتاز على جميع الأنظمة الإنتاجية.
• فعّل تقوية JIT (bpf_jit_harden=2).
• راقب تحميل برامج eBPF باستخدام eBPFmon أو قواعد Falco المُخصصة.
• استخدم التوقيع الرقمي لبرامج eBPF حيث يُدعم ذلك.

6. استعد لمستقبل eBPF:

• eBPF على Windows: مايكروسوفت تعمل على دعم eBPF في Windows، مما سيوحّد أدوات المراقبة عبر الأنظمة.
• eBPF وتقنيات الذكاء الاصطناعي: دمج نماذج الذكاء الاصطناعي مع بيانات eBPF للكشف عن الشذوذات والتهديدات المتقدمة التي لا تكشفها القواعد التقليدية.
• معيار LSM BPF: تزايد استخدام خطافات LSM BPF كبديل أكثر مرونة لـ SELinux و AppArmor في بعض السيناريوهات.
• eBPF في بيئات الحوسبة الطرفية (Edge): مع انتشار Kubernetes على الحافة، ستكون أدوات eBPF الخفيفة مثل Tetragon حاسمة لتأمين هذه البيئات المحدودة الموارد.

جدول مقارنة سريع للأدوات

لتسهيل اتخاذ القرار — لأن الاختيار بينها ليس دائماً واضحاً من النظرة الأولى — إليك ملخص مقارن:

• Tetragon: الأفضل لـ — فرض السياسات في الإنتاج مع أقل حمل إضافي. مثالي عندما تحتاج إلى منع التهديدات وليس فقط اكتشافها.
• Falco: الأفضل لـ — الكشف الشامل عن التهديدات مع مكتبة قواعد غنية وتكاملات واسعة. الخيار الأنضج لمراقبة وقت التشغيل.
• Tracee: الأفضل لـ — التحليل الجنائي العميق والتحقيقات الأمنية. يوفر أكبر قدر من التفاصيل لكل حدث.
• Cilium: الأفضل لـ — أمان الشبكات ومراقبة حركة المرور بين الخدمات في Kubernetes. لا يُنافس في مجال سياسات الشبكة المبنية على eBPF.

الخلاصة

تقنية eBPF ليست مجرد أداة جديدة في ترسانة الأمان — إنها تحوّل جذري في كيفية مراقبة وحماية أنظمة لينكس. على مدار هذا الدليل، استعرضنا كيف تطورت من مُرشّح بسيط لحزم الشبكة إلى منصة برمجة كاملة داخل النواة تُعيد تعريف مفهوم الأمان على مستوى نظام التشغيل.

eBPF تسد فجوة كانت موجودة لعقود: الفجوة بين الحاجة إلى رؤية عميقة لما يحدث داخل النواة، وبين مخاطر تعديل النواة نفسها. من خلال توفير القدرة على تشغيل برامج مُتحقق منها داخل النواة، أصبح مستوى الرؤية والتحكم الذي كان مستحيلاً سابقاً (دون المخاطرة باستقرار النظام) متاحاً الآن.

مع وصول ثغرات نواة لينكس المُعلنة إلى 5,530 ثغرة في عام 2025 وتزايد تعقيد الهجمات، أصبحت المراقبة الأمنية على مستوى النواة ضرورة لا رفاهية. والأدوات المبنية على eBPF — Tetragon و Falco و Tracee و Cilium — توفر حلولاً ناضجة وجاهزة للإنتاج.

المفتاح هو اختيار الأداة المناسبة لكل حالة استخدام، ودمجها بشكل صحيح في خطوط أنابيب DevSecOps، ومراقبة أمان eBPF نفسه. تذكر: eBPF سلاح ذو حدين — نفس القوة التي تجعله أداة دفاعية استثنائية يمكن أن تُستخدم في الهجوم إذا لم تُؤمّن بشكل صحيح.

ابدأ بتثبيت Tetragon على مجموعة Kubernetes التجريبية الخاصة بك، واكتب سياسة TracingPolicy بسيطة لمراقبة الوصول إلى الملفات الحساسة. ثم وسّع النطاق تدريجياً بإضافة Falco للكشف الشامل و Cilium لأمان الشبكات. مع كل خطوة، ستبني طبقة دفاع إضافية تجعل اختراق أنظمتك أصعب بمراحل — وهذا في النهاية هو الهدف من كل هذا الجهد.

القاعدة الذهبية في أمان eBPF: راقب كل شيء، صفّ داخل النواة، فرض بذكاء، واستجب بسرعة. إذا لم تكن تراقب نواتك، فأنت لا تعرف ما يحدث حقاً في أنظمتك.