Tracee چیست و چرا برای امنیت زمان اجرا مهم است؟

Tracee محصول متن‌باز Aqua Security برای امنیت زمان اجرا، مشاهده‌پذیری و جرم‌یابی در لینوکس است. ایده مرکزی آن این است که رفتار سیستم و برنامه را به رویداد تبدیل کند؛ از فراخوانی‌های سیستمی و اجرای فرایند تا عملیات فایل، فعالیت شبکه، رویدادهای کانتینری و تشخیص‌های امنیتی. Tracee برای تغییر ندادن کد برنامه‌ها طراحی شده و با eBPF در سطح کرنل داده می‌گیرد. بنابراین تیم امنیت می‌تواند به‌جای حدس‌زدن از روی لاگ برنامه، زنجیره‌ای از واقعیت‌های قابل مشاهده درباره فرایند، والد آن، فایل، کاربر، فضای نام، کانتینر و ارتباط شبکه بسازد.

این ابزار هم برای هشدار بلادرنگ و هم برای بررسی پس از رخداد مناسب است. مستندات رسمی، کاربردهایی مانند شناسایی بدافزار، افزایش سطح دسترسی، فرار از کانتینر، تغییر فایل‌های حساس، اشکال‌زدایی رفتار برنامه و جمع‌آوری شواهد را پوشش می‌دهند. با این حال Tracee جایگزین کنترل دسترسی، وصله‌کردن کرنل یا یک سامانه پاسخ‌گویی کامل نیست؛ ارزش آن در مشاهده عمیق رفتار لینوکس و رساندن داده ساخت‌یافته به فرایند تحلیل است.

معماری eBPF؛ از هوک کرنل تا رویداد قابل مصرف

در معماری Tracee، برنامه‌های eBPF به نقاطی از کرنل متصل می‌شوند و وقوع فعالیت را با سربار کمتر از یک عامل کاملاً کاربرفضا ثبت می‌کنند. داده از مسیر بافرهای داخلی به بخش کاربرفضا می‌رسد؛ سپس Tracee زمینه رویداد را کامل می‌کند، فیلترهای سیاست را اعمال می‌کند، تشخیص‌های امنیتی را اجرا می‌کند و نتیجه را به خروجی انتخاب‌شده می‌فرستد. Tracee هنگام شروع به کرنل سالم اعتماد می‌کند و اگر مهاجم پیش از آن کرنل را در اختیار گرفته باشد، امکان پنهان‌کردن رویداد یا مختل‌کردن eBPF وجود دارد.

نقطه قوت معماری، یکسان‌بودن مسیر داده است. در Tracee «همه‌چیز یک رویداد» است؛ هم system call خام و هم تشخیص سطح‌بالای امنیتی. شش گروه اصلی عبارت‌اند از syscalls برای پایش فراخوانی‌ها، network برای فعالیت و تحلیل پروتکل، security برای تشخیص‌ها و امضاها، lsm برای هوک‌های Linux Security Module، containers برای چرخه عمر و فراداده کانتینر و misc برای رویدادهای دیگر. راهنمای نمای کلی همچنین از بیش از ۴۰۰ system call، رخدادهای DNS و HTTP و تحلیل بسته نام می‌برد.

پس از ثبت، رویداد می‌تواند با اطلاعات فرایند و تبار آن، شناسه‌های PID و TID، شناسه‌های میزبان، کاربر، نام فرایند، فضای نام mount و PID، cgroup، اطلاعات کانتینر و در محیط Kubernetes با نام Pod و namespace غنی شود. این زمینه برای پاسخ‌گویی مهم است: هشدار اجرای shell در کنار والد، تصویر کانتینر، مسیر اجرایی و زنجیره فرایند قابل اولویت‌بندی می‌شود.

منابع رویداد و نقش LSM

برای مشاهده عمومی می‌توان eventهای منفرد یا مجموعه‌های آماده را انتخاب کرد. مجموعه syscalls همه system callها را پوشش می‌دهد و fs و net برای فایل‌سیستم و شبکه هستند؛ دستور tracee list --wide برای کشف مجموعه‌ها و eventهای موجود پیشنهاد شده است. eventهای LSM برای نقاط کنترل امنیتی کرنل اهمیت دارند. مستندات مدل امنیتی هشدار می‌دهند که خواندن آرگومان از کاربرفضا می‌تواند در معرض race یا TOCTOU باشد: برنامه ممکن است بعد از خوانده‌شدن آرگومان و پیش از مصرف آن در کرنل، مقدار را تغییر دهد. برای پایش حساس، مقایسه event عادی مانند execve با security_bprm_check داده قابل اتکاتری می‌دهد.

برای SOC، syscallها پوشش وسیع و خط زمانی می‌دهند و LSM شاهد مکمل در نقطه تصمیم کرنل است. نبود پشتیبانی LSM BPF مانع کار عادی Tracee نیست، اما بعضی قابلیت‌های پیشرفته محدود می‌شوند. پیش از سناریوی حیاتی، eventهای کرنل واقعی را آزمایش کنید.

سیاست‌ها؛ کنترل دامنه، رویداد و فیلتر

Policy واحد مشترک CLI و نصب Kubernetes است. هر policy نام، توضیح، scope و rules دارد و در هر rule event مشخص می‌شود. حداکثر ۶۴ policy قابل بارگذاری است. یک نمونه حداقلی چنین ساختاری دارد:

apiVersion: tracee.aquasec.com/v1beta1
kind: Policy
metadata:
  name: iro-sample
  annotations:
    description: monitor execution
spec:
  scope:
    - global
  rules:
    - event: execve

global کل میزبان را می‌گیرد، ولی دامنه می‌تواند به UID، PID، فضای نام mount یا PID، نام فرمان، executable، درخت فرایند، فقط کانتینر یا خارج از کانتینر محدود شود. چند شرط با AND ترکیب می‌شوند و چند مقدار یک فیلد با عملگر مساوی OR هستند. برای کم‌کردن نویز، به‌جای ثبت همه openatها، آن را به یک فرایند، image، Pod یا namespace و مسیر خاص محدود کنید.

فیلترها سه جنس دارند: scope برای زمینه فرایند و workload، data برای مقدار آرگومان رویداد و return value برای نتیجه فراخوانی. نمونه رسمی، security_file_open را به data.pathname=/tmp* محدود می‌کند؛ نمونه دیگر close را با retval!=0 فقط در خطاها نگه می‌دارد. هر event را در policy فقط یک‌بار تعریف کنید. ابتدا با tracee -e security_file_open --output json شکل واقعی آرگومان‌ها را ببینید و بعد فیلتر data بنویسید؛ این کار از حدس‌زدن نام فیلد جلوگیری می‌کند.

tracee-rules و تشخیص رفتاری

Tracee علاوه بر event خام، تشخیص‌های امنیتی آماده و امضاها دارد؛ در مستندات سیاست، نمونه‌هایی مانند fileless_execution، kernel_module_loading، syscall_hooking، proc_mem_code_injection، docker_abuse، k8s_cert_theft، ld_preload، تغییر sudoers، دست‌کاری cgroup و ایجاد فایل پنهان آمده است. tracee-rules لایه‌ای بالاتر از جمع‌آوری event است: rule چند مشاهده را به یک رفتار مشکوک تبدیل می‌کند و خروجی آن همچنان event است، بنابراین با همان policy و همان pipeline فیلتر و ارسال می‌شود.

برای شروع امن، تشخیص‌ها را کورکورانه در محیط پرترافیک فعال نکنید. ابتدا baseline بگیرید، سناریوها را در میزبان آزمایشی اجرا و سپس policy را به workload حساس ببرید. در Kubernetes راهنمای رسمی یک تصویر tracee-tester و شناسه TRC-105 را برای شبیه‌سازی اجرای fileless معرفی می‌کند؛ خروجی امنیتی باید همراه زمان، فرایند، container و سیاست به SIEM برسد.

نصب و شروع کنترل‌شده

برای آزمایش سریع Docker، مستندات فرمانی با --pid=host و --cgroupns=host، دسترسی privileged، اتصال فقط‌خواندنی /etc/os-release و اتصال /var/run نشان می‌دهند. این فرمان برای شناخت اولیه مناسب است، اما privileged انتخاب تولید نیست. تصویر رسمی چندسکویی aquasec/tracee برای x86 و arm64 است و می‌توان از tag نسخه‌دار به‌جای latest استفاده کرد تا بازتولیدپذیری بهتر شود.

پیش از اجرا، لینوکس و معماری را بررسی کنید: Tracee فقط Linux را پشتیبانی می‌کند و x86 و arm64 را هدف می‌گیرد. کرنل‌های مدرن LTS مانند 5.4، 5.10، 5.15، 6.2 و 6.5 در مستندات آمده‌اند؛ پشتیبانی واقعی به قابلیت‌های توزیع و آزمون‌های محیط بستگی دارد. وجود /sys/kernel/btf/vmlinux برای BTF و وجود /proc/kallsyms برای بعضی eventها را بررسی کنید. اگر kallsyms در دسترس نیست، تشخیص‌هایی مانند dirty pipe، syscall hooking، hidden kernel module و برخی رویدادهای مرتبط با symbol محدود یا غیرفعال می‌شوند. /etc/os-release و یکی از /boot/config-$(uname -r) یا /proc/config.gz نیز برای probe محیط لازم‌اند.

کمینه‌سازی capability و پیکربندی امن

راحت‌ترین راه privileged یا root است، اما راه کم‌اختیار رسمی نیز مشخص شده است: CAP_SYS_RESOURCE برای محدودیت mapهای eBPF، در کرنل‌های جدید CAP_BPF و CAP_PERFMON برای بارگذاری و اتصال برنامه‌ها در شرایط مناسب، CAP_SYS_PTRACE برای اطلاعات فرایند، CAP_NET_ADMIN برای cgroup_skb و capture شبکه، CAP_SETPCAP برای کاهش bounding set، CAP_SYSLOG برای kallsyms و گاهی CAP_IPC_LOCK. در cgroup v1 ممکن است CAP_SYS_ADMIN برای mount کنترلر cpuset لازم باشد.

این فهرست را با نیاز policy و قابلیت کرنل تطبیق دهید؛ همه را دائمی اعطا نکنید. capabilityهای اضافی را حذف کنید، socketهای runtime را فقط در صورت نیاز و read-only ارائه دهید، خروجی و artifact را در مسیر اختصاصی با مجوز محدود بنویسید، و سرورهای metrics، healthz، pprof و gRPC را بدون طرح دسترسی شبکه باز نکنید. گزینه install-path می‌تواند مسیر پیش‌فرض /tmp/tracee را به محل امن‌تری مانند /opt/tracee منتقل کند.

Kubernetes؛ یک DaemonSet برای هر node

Chart رسمی Tracee را به صورت DaemonSet نصب می‌کند؛ روی هر node یک Pod همان node را می‌پاید. روند پایه، افزودن repository Helm، به‌روزرسانی index و نصب chart در namespace tracee است. بعد با kubectl get pods -n tracee وضعیت را ببینید و برای آزمایش kubectl logs -f daemonset/tracee -n tracee را به‌کار ببرید. در cluster شلوغ، این روش ممکن است به‌دلیل حجم رویداد کند شود؛ مستندات توصیه می‌کنند در تولید، لاگ را به ذخیره‌سازی پایدار و قابل جست‌وجو منتقل کنید.

Policy در Kubernetes به شکل CRD عرضه می‌شود و نصب Tracee CRD و policy پیش‌فرض را اعمال می‌کند. با kubectl get policies.tracee.aquasec.com فهرست را ببینید، با kubectl apply -f بسازید، با kubectl edit تغییر دهید و با kubectl delete حذف کنید. Operator تغییر policy را می‌بیند و برای به‌روزشدن تنظیمات، rolling restart DaemonSet را تحریک می‌کند. دامنه را تا حد ممکن به Pod، namespace، image یا container محدود کنید تا پایش workload حساس هم مفید و هم قابل‌تحمل باشد.

خروجی، لاگ و مدیریت عملکرد

Tracee می‌تواند JSON را روی stdout یا فایل، جدول معمولی یا verbose، webhook و forward به گیرنده Fluent Bit بفرستد؛ در یک configuration فقط یک format انتخاب می‌شود. JSON برای SIEM و پردازش ماشینی مناسب است و pipe کردن آن به jq امکان گزینش و تغییر نام فیلدها را می‌دهد. webhook برای دریافت HTTP و forward برای زنجیره Fluent Bit است؛ پیش از ارسال، timeout، احراز هویت شبکه و ظرفیت مقصد را آزمایش کنید.

لاگ تشخیصی از event خروجی جداست. levelهای info، debug، warn، error و panic وجود دارند و می‌توان لاگ را به فایل، بازه‌ای aggregate، یا با فیلتر پیام، regex، package، file، level و libbpf محدود کرد. برای خطایابی کوتاه‌مدت debug مفید است؛ در تولید level و مقصد را طوری انتخاب کنید که خود لاگ تشخیصی به منبع نویز تبدیل نشود.

حجم تابع policy، نرخ system call، enrichment و artifact است. buffer داخلی perf، buffer blob و کانال pipeline قابل تنظیم‌اند؛ مقدار پیش‌فرض perf و blob در راهنمای config برابر ۱۰۲۴ صفحه، یعنی حدود ۴ مگابایت، و کانال pipeline برابر ۱۰۰۰ ذکر شده است. افزایش buffer درمان همه افت‌ها نیست: eventهای غیرضروری را حذف، scope و فیلتر را محدود، artifact شبکه را آگاهانه فعال و مقصد خروجی را پایش کنید. در capture شبکه، رفتار پیش‌فرض می‌تواند همه ترافیک باشد؛ گزینه filtered را برای پیروی از event filter و snaplen کوچک‌تر برای کنترل حجم به‌کار ببرید.

جرم‌یابی و سناریوی SOC/DFIR

پرچم --artifacts Tracee را از هشداردهنده به ابزار جمع‌آوری شاهد تبدیل می‌کند. مستندات artifactهای فایل‌های خوانده یا نوشته‌شده، فایل‌های اجرایی، ناحیه‌های حافظه مرتبط با memory unpacker، PCAP شبکه و ماژول‌های کرنل بارگذاری‌شده را معرفی می‌کنند. مسیر خروجی با dir.path تعیین می‌شود و dir.clear امکان پاک‌کردن مقصد در هر اجرا را دارد. برای پرونده DFIR، timestamp رویداد، hash یا نام artifact، container و زنجیره فرایند را کنار هم نگه دارید و دسترسی به خروجی را محدود کنید.

در SOC، policy کم‌حجم برای execution، network، فایل حساس و تشخیص‌ها بسازید؛ JSON را به جمع‌کننده بفرستید و artifact را فقط برای scope یا رخداد مشخص فعال کنید. اگر fileless execution دیده شد، فرایند والد و child، image، namespace، مسیر فایل‌های بازشده و در صورت مجاز بودن memory artifact را بررسی کنید. اگر ارتباط مشکوک رخ داد، event شبکه را با PCAP فیلترشده و در صورت نیاز split بر اساس process، container یا command به timeline تبدیل کنید.

مقایسه با Falco را باید منصفانه انجام داد: این مخزن سند رسمی رتبه‌بندی یا benchmark مشترک ارائه نمی‌کند، پس نباید عدد یا ادعای برتری ساخت. تفاوت قابل اتکای Tracee در همین مستندات، مدل «همه‌چیز event»، سیاست YAML مشترک میان CLI و Kubernetes، دسته‌های گسترده event، detectorهای امنیتی و artifactهای DFIR است. بنابراین هنگام انتخاب، تیم باید نوع منبع داده، سطح forensic، مدل policy، نیاز به LSM، محدودیت capability و مسیر خروجی را در محیط خودش آزمایش کند؛ نام ابزار به‌تنهایی معیار تصمیم نیست.

محدودیت‌ها و جمع‌بندی

Tracee برای userspace adversary، تا وقتی eBPF و خود Tracee فعال و محافظت‌شده‌اند، دید قوی فراهم می‌کند؛ اما rootkit یا ماژول مخربی که پیش از شروع آن کرنل را آلوده کرده، kernel zero-day، دست‌کاری مستقیم حافظه کرنل و حمله سخت‌افزاری خارج از تضمین آن هستند. مهاجم دارای capabilityهای مدیریتی نیز می‌تواند فرایند Tracee یا برنامه‌های eBPF را متوقف کند. پس Tracee را زود، روی سیستم تأییدشده و در کنار Secure Boot، امضای ماژول، SELinux/AppArmor، وصله منظم و کنترل دسترسی اجرا کنید.

شروع پیشنهادی IROSG این است: ابتدا prerequisites و BTF را بررسی کنید؛ با image نسخه‌دار یک اجرای آزمایشی محدود انجام دهید؛ eventها را در JSON مشاهده کنید؛ policy کم‌دامنه بسازید؛ سپس DaemonSet و CRD را در یک namespace آزمایشی پیاده کنید. بعد از baseline، ruleهای tracee-rules را مرحله‌ای فعال و artifact را برای DFIR آماده کنید. این زنجیره، از مشاهده خام تا هشدار و شاهد قابل بررسی، مهم‌ترین ارزش Tracee را بدون وعده‌ای فراتر از مرزهای eBPF و کرنل به کار می‌گیرد.