مشاهده رفتار به‌جای تکیه بر نام ایمیج
Falco برای تشخیص رفتارهای زمان اجرا از رویدادها و قواعد استفاده می‌کند. در سناریوهای لینوکسی، رویدادهای سیستمی می‌توانند بخشی از ورودی تشخیص باشند؛ قابلیت‌ها و منابع رویداد به نصب و تنظیمات بستگی دارند. قاعده، رویداد را در زمینه مرتبط ارزیابی می‌کند و در صورت انطباق هشدار می‌سازد.
نمودار رسمی، مسیر دریافت رویداد، ارزیابی و خروجی را نشان می‌دهد. هشدار Falco را نباید خودکار معادل متوقف‌شدن عملیات دانست. مهار یا پاسخ خودکار، به ابزارهای متصل و سیاست اجرایی شما وابسته است. تشخیص یک رفتار غیرعادی نیز به‌تنهایی اثبات قصد مخرب کاربر نیست.
یک تمرین آموزشی محدود
فرض کنید برنامه آزمایشی شما معمولاً فقط یک سرویس وب اجرا می‌کند. پیش از نوشتن قاعده، رفتار عادی آن را ثبت کنید: فرایندها، مسیرهای فایل موردنیاز و کارهای نگه‌داری مجاز. سپس یک فعالیت بی‌خطر اما خارج از این الگوی معمول را در محیط آزمایش ایجاد کنید و ببینید هشدار با چه اطلاعاتی ظاهر می‌شود.
معیار پذیرش این نیست که «تعداد هشدار زیاد شد». باید بتوانید هشدار را به بار کاری درست، زمان درست و رخداد قابل توضیح وصل کنید. فعالیت مورد انتظار تیم عملیات را هم آزمایش کنید تا قاعده برای هر کار عادی اعلام خطر نکند.
هشدار مفید چه چیزی دارد؟
پیشنهاد تحریریه ثبت نام قاعده، هویت بار کاری، زمان و اطلاعات ضروری برای بررسی است. داده حساس نباید بدون نیاز به مقصد عمومی ارسال شود. یک هشدار باید مسئول رسیدگی و راهنمای کوتاه بررسی داشته باشد؛ وگرنه ممکن است در انبوه اعلان‌ها گم شود.
سپس مسیر تحویل هشدار را امتحان کنید. آیا قطع مقصد اعلان قابل تشخیص است؟ آیا نبود رویداد ناشی از آرام‌بودن برنامه است یا خرابی حسگر؟ سلامت خود سامانه پایش بخشی از همان طراحی است.
پاسخ خودکار را مرحله‌ای بسازید
قبل از اتصال تشخیص به توقف بار کاری، سناریوی اشتباه را بررسی کنید. برای یک آزمایش اولیه، پاسخ را به ثبت یا اعلان محدود کنید و فقط پس از شناخت خطاهای تشخیص، اقدام برگشت‌پذیر اضافه کنید. حذف فایل، توقف گسترده سرویس یا تغییر شبکه باید اختیار و معیار روشن داشته باشد.
Falco یک لایه مشاهده رفتار است؛ جای به‌روزرسانی نرم‌افزار، کمینه‌سازی مجوز و طراحی درست برنامه را نمی‌گیرد. ارزش آن در شواهدی است که بتوان بر اساسشان تصمیم گرفت، نه صرفاً روشن‌بودن یک داشبورد.
از رخداد خام تا هشدار قابل بررسی
یک رخداد سیستمی معمولاً فقط بخشی از داستان را نشان می‌دهد. برای مثال باز شدن یک فایل می‌تواند نتیجه رفتار عادی برنامه، ابزار پشتیبان‌گیری یا یک فعالیت نامجاز باشد. قاعده تشخیص باید زمینه لازم را اضافه کند: کدام فرایند، با کدام هویت، در کدام بار کاری و در چه مسیر اجرایی این کار را انجام داده است. هرچه قاعده فقط به نام فایل یا نام برنامه تکیه کند، احتمال برداشت ناقص بیشتر می‌شود. در طراحی نخست، رفتار مجاز و نامجاز را با نمونه‌های مشخص بنویسید.
یک هشدار مفید باید به پرسش بعدی پاسخ دهد. اگر هشدار از اجرای shell در کانتینر خبر می‌دهد، بررسی‌کننده باید بتواند کانتینر، میزبان، فرایند والد و زمان را پیدا کند. با این اطلاعات هنوز نمی‌توان قصد مخرب را قطعی دانست، اما می‌توان اجرای نگه‌داری مجاز را از مسیر غیرمنتظره جدا بررسی کرد. حفظ همین زمینه در مقصد اعلان اهمیت دارد؛ کوتاه کردن افراطی پیام ممکن است نام قاعده را نگه دارد و شواهد ضروری را حذف کند.
انتخاب منبع رخداد و شناخت پوشش
نصب Falco باید با منبع رخداد مورد نظر سازگار باشد. روش دریافت رخدادهای لینوکس و نیازهای کرنل یا محیط کانتینری را از مستندات همان انتشار بررسی کنید. وجود فرایند Falco در فهرست سرویس‌ها اثبات دریافت رخداد نیست. یک فعالیت آزمایشی شناخته‌شده ایجاد کنید و نشان دهید به مسیر ارزیابی می‌رسد. اگر از افزونه‌ای برای منبع دیگر استفاده می‌کنید، همان منبع نیز باید جدا آزمایش شود؛ موفقیت یک منبع، سلامت همه منابع را تضمین نمی‌کند.
پوشش را به فهرست گره‌ها مرتبط کنید. اگر بعضی گره‌ها حسگر ندارند یا حسگر آن‌ها به دلیل تفاوت محیط کار نمی‌کند، سکوت آن گره‌ها نباید به معنای نبود رفتار غیرعادی تعبیر شود. یک ماتریس ساده از گره، نسخه، منبع رخداد و آخرین آزمون موفق نگه دارید. این ثبت برای محیطی که گره‌ها خودکار ساخته و حذف می‌شوند اهمیت بیشتری دارد. پایش سلامت حسگر و پایش رفتار برنامه دو مسئولیت مکمل‌اند.
ساخت قاعده از یک نیاز واقعی
فرض کنید یک سرویس فقط باید فایل‌های تنظیمات خود را بخواند و در پوشه داده مشخصی بنویسد. هدف تشخیص می‌تواند نوشتن در مسیر غیرمنتظره باشد. ابتدا اجرای عادی سرویس را با عملیات روزمره، restart و نگه‌داری مشاهده کنید تا فهرست نیازها کامل شود. سپس فعالیت ساختگی خارج از این الگو را در محیط آزمایش انجام دهید. قاعده باید این تفاوت را ببیند، اما برای هر فایل موقت یا کار معمول هشدار بی‌ارزش تولید نکند.
در قاعده، شرط را از متن خروجی جدا بررسی کنید. ممکن است شرط درست باشد اما خروجی اطلاعات لازم را نداشته باشد، یا خروجی ظاهراً دقیق باشد اما شرط خیلی گسترده انتخاب شده باشد. فهرست‌ها و ماکروها می‌توانند نگه‌داری را ساده کنند، ولی نام آن‌ها جای فهم منطق را نمی‌گیرد. هنگام بازبینی، وابستگی قاعده به این اجزا را دنبال کنید تا تغییر یک فهرست مشترک به‌طور ناخواسته ده‌ها قاعده را عوض نکند.
استثنا باید کوچک و قابل توضیح باشد
وقتی یک عملیات مجاز هشدار می‌سازد، راه ساده خاموش کردن کل قاعده است؛ اما این کار پوشش رفتار نامجاز را هم حذف می‌کند. بهتر است تفاوت واقعی عملیات مجاز را پیدا کنید، مانند workload مشخص، مسیر مشخص یا زمینه اجرایی معین. استثنای مبتنی بر نام بسیار عمومی ممکن است به فعالیت‌های نامرتبط هم اجازه عبور از تشخیص بدهد. هر استثنا باید به یک نمونه آزمون مجاز و یک نمونه نامجاز مرتبط بماند تا محدود بودن آن قابل اثبات باشد.
استثناهای موقت را با دلیل و زمان بازبینی ثبت کنید. یک ابزار مهاجرت که فقط یک‌بار اجرا شده، نباید برای همیشه دامنه تشخیص را کوچک کند. پس از پایان تغییر، نمونه نامجاز را دوباره اجرا کنید و مطمئن شوید قاعده هنوز هشدار می‌دهد. این کار نگه‌داری محتواست، نه صرفاً نگه‌داری باینری Falco. مجموعه قواعد بدون بازبینی ممکن است به مرور آرام شود، در حالی که سکوت آن نتیجه استثناهای انباشته است.
کیفیت داده و رخدادهای ازدست‌رفته
در بار زیاد، ظرفیت دریافت و پردازش رخداد اهمیت پیدا می‌کند. نرخ خروجی کم ممکن است ناشی از رفتار آرام برنامه باشد یا از دست رفتن داده در مسیر. شمارنده‌ها و گزارش‌های مربوط به افت رخداد و سلامت driver را بررسی کنید. یک آزمون بار باید هم هزینه روی میزبان و هم کیفیت داده دریافتی را بسنجد. فقط مشاهده مصرف CPU پایین کافی نیست؛ ممکن است ابزار داده مورد نیاز را اصلاً دریافت نکرده باشد.
خروجی پرحجم نیز مسئله جداگانه‌ای است. اگر هر رخداد کم‌اهمیت به سامانه مرکزی فرستاده شود، هزینه ذخیره و زمان بررسی بالا می‌رود و هشدار مهم در انبوه پیام گم می‌شود. شدت و مسیر ارسال را با عمل مورد انتظار مرتبط کنید. بعضی رویدادها برای جست‌وجوی بعدی مناسب‌اند و برخی نیاز به اعلان فوری دارند. این تصمیم باید بر اساس اثر و اطمینان قاعده باشد، نه صرفاً جذاب بودن نام آن.
انتقال هشدار و حفاظت از اطلاعات
خروجی ممکن است شامل مسیر فایل، آرگومان فرایند یا داده‌ای باشد که اطلاعات حساس را آشکار می‌کند. پیش از اتصال به پیام‌رسان یا سرویس بیرونی، نمونه خروجی را بررسی کنید و فقط زمینه لازم را نگه دارید. ارسال رخداد به مقصد عمومی برای راحتی عیب‌یابی مناسب نیست. کنترل دسترسی، نگه‌داری و حذف داده باید متناسب با حساسیت همان log طراحی شود. هشدار امنیتی می‌تواند خودش به منبع داده حساس تبدیل شود.
قطع مقصد اعلان را به صورت کنترل‌شده آزمایش کنید. مشخص کنید آیا پیام‌ها در صف می‌مانند، کنار گذاشته می‌شوند یا به مسیر دیگری می‌روند. سپس بازگشت مقصد را بررسی کنید تا تیم بداند آیا هشدارهای دوره قطع قابل بازیابی‌اند. فرض اینکه هر هشدار تولیدشده حتماً به انسان رسیده، بدون آزمون مسیر تحویل معتبر نیست. برای رخدادهای مهم، سلامت این مسیر باید جدا از سلامت خود حسگر قابل مشاهده باشد.
پاسخ به رخداد با حدود روشن
پس از دریافت هشدار، ابتدا هویت workload و ارتباط آن با تغییرات مجاز همان زمان را بررسی کنید. اگر شواهد نیاز به مهار نشان می‌دهند، اقدام را با دامنه کوچک و اثر قابل فهم انتخاب کنید. توقف همه کانتینرهای دارای نام مشابه ممکن است خدمت سالم را هم قطع کند. اتصال خودکار به ابزار پاسخ باید شرط، اختیار و مسیر بازگشت مشخص داشته باشد. نخست می‌توان تصمیم پیشنهادی را ثبت کرد و پس از بررسی خطاهای تشخیص، اقدام محدود را فعال کرد.
در تمرین تیمی، یک نفر فعالیت آزمایشی را ایجاد کند و نفر دیگر فقط با هشدار و دستورالعمل بررسی آن را توضیح دهد. اگر فرد دوم بدون تماس با نویسنده قاعده نمی‌تواند مبدأ و اثر را پیدا کند، اطلاعات خروجی یا دستورالعمل هنوز کافی نیست. نتیجه تمرین را به اصلاح قاعده و مسیر پاسخ تبدیل کنید. هدف نهایی هشدار بیشتر نیست؛ هدف کاهش زمان رسیدن از یک رفتار مشکوک به تصمیم مستند و متناسب است.
نسخه قواعد هم یک وابستگی عملیاتی است
به‌روزرسانی مجموعه قواعد می‌تواند تعداد و نوع هشدارها را تغییر دهد حتی اگر باینری و برنامه‌های شما ثابت مانده باشند. بنابراین نسخه قواعد و تغییرات محلی را ثبت کنید و پیش از گسترش، آن‌ها را روی چند workload نماینده اجرا کنید. یک هشدار تازه ممکن است کشف پوشش بهتر باشد یا از تفاوت نام‌گذاری و رفتار محیط شما ناشی شود. مقایسه نمونه رخدادها به فهم این تفاوت کمک می‌کند.
برای هر قاعده مهم، چند ورودی آزمون نگه دارید: رفتار مجاز عادی، رفتار مجاز استثنایی و رفتار نامجاز مورد نظر. پس از تغییر قواعد، انتظار هر ورودی را دوباره کنترل کنید. این مجموعه کوچک مانع آن می‌شود که اصلاح یک هشدار مزاحم، تشخیص مهم دیگری را بی‌صدا از بین ببرد. نتیجه را با نام قاعده و نسخه مرتبط کنید تا در بررسی حادثه روشن باشد در زمان رخداد چه منطقی فعال بوده است. مشاهده امروز نمی‌تواند به تنهایی رفتار مجموعه قواعد ماه گذشته را ثابت کند.
