معرفی
این اپلیکیشن برای استفاده دفاعی، تحلیل، مدیریت یا تست مجاز معرفی شده و لینک اصلی آن به پروژه یا سازنده برمی‌گردد.
نکته 1
Suricata می‌تواند به‌شکل IDS، IPS یا network security monitor اجرا شود.
نکته 2
EVE JSON برای اتصال به SIEM و data pipeline بسیار رایج است.
نکته 3
Rule tuning برای کاهش false positive و هزینه پردازش ضروری است.
استفاده مسئولانه
قابلیت‌های RF، RFID، اسکن، credential audit، تحلیل ترافیک و تست امنیت فقط باید روی دارایی‌های خودتان، آزمایشگاه یا Scope دارای مجوز صریح استفاده شوند.
حسگر در کجای مسیر قرار می‌گیرد؟
پیش از فعال کردن قواعد، تعیین کنید Suricata چه ترافیکی را واقعاً می‌بیند. حسگری روی یک درگاه آینه‌شده، فقط بسته‌هایی را بررسی می‌کند که شبکه به آن می‌رساند. اگر جهت برگشت یا بخشی از VLANها دیده نشود، تحلیل جریان ناقص می‌شود. در معماری درون‌خط، حسگر می‌تواند در مسیر تصمیم عبور قرار گیرد و خرابی یا تنظیم آن اثر مستقیم‌تری بر ارتباط دارد. انتخاب حالت باید با هدف مشاهده یا جلوگیری و تحمل اختلال هماهنگ باشد. نصب نرم‌افزار بدون نقشه محل مشاهده، پوشش امنیتی مشخصی ایجاد نمی‌کند.
برای یک آزمایش کوچک، دو میزبان خودتان و یک سرویس ساده در نظر بگیرید. مسیر رفت و برگشت را از روی ضبط یا شمارنده‌ها تأیید کنید. سپس بررسی کنید آیا حسگر همان ارتباطی را که کلاینت و سرور می‌بینند دریافت می‌کند. اگر بسته‌ها ناقص‌اند، افزودن قواعد بیشتر مشکل را حل نمی‌کند. نخست آینه‌سازی، رابط، مسیر و ظرفیت انتقال را درست کنید. این ترتیب از نتیجه‌گیری اشتباه درباره ضعیف بودن تشخیص جلوگیری می‌کند، چون ممکن است داده لازم هرگز به موتور نرسیده باشد.
IDS، IPS و پایش شبکه نقش‌های متفاوت دارند
در حالت تشخیص، هشدار برای بررسی تولید می‌شود و عبور ترافیک لزوماً متوقف نمی‌شود. در حالت جلوگیری، تصمیم قاعده می‌تواند بر عبور اثر بگذارد، به شرط آنکه معماری و حالت اجرا برای این کار تنظیم شده باشند. پایش شبکه نیز می‌تواند فراداده جریان و پروتکل تولید کند، حتی بدون هشدار مشخص. این خروجی‌ها باید با هدف تیم هماهنگ شوند. اگر فقط به شمار هشدار نگاه کنید، ممکن است ارزش فراداده را نبینید؛ اگر تصور کنید هر هشدار به مسدودسازی منجر شده، درباره حفاظت واقعی ادعای نادرست می‌کنید.
برای شروع، حالت مشاهده در محدوده کنترل‌شده معمولاً به شناخت ترافیک کمک می‌کند. سپس قواعد مناسب برای جلوگیری باید با آزمون و پذیرش مالک سرویس انتخاب شوند. انتقال همه قواعد به حالت مسدودسازی بدون بررسی می‌تواند خطای مثبت را به اختلال تبدیل کند. در برنامه تغییر، مسیر بازگشت و رفتار هنگام توقف موتور مشخص باشد. این تصمیم به معماری وابسته است و نباید از یک نمونه تنظیمات عمومی کپی شود. سلامت شبکه پس از تغییر باید از دید کلاینت و سرویس نیز آزمایش شود.
تعریف شبکه داخلی و جهت ارتباط
متغیرهای مربوط به شبکه‌های تحت حفاظت باید با نشانی‌های واقعی محیط هماهنگ باشند. فهرست پیش‌فرض ممکن است همه محدوده‌های شما را پوشش ندهد یا محدوده‌های نامرتبط را شامل شود. در محیط ابری، شبکه عمومی متعلق به سازمان نیز ممکن است دارایی داخلی از دید سیاست باشد. بنابراین «داخلی» را فقط با خصوصی بودن نشانی برابر ندانید. هدف این تعریف، تفسیر درست جهت و دامنه قواعد است. پس از تغییر، یک نمونه ارتباط ورودی و خروجی را بررسی کنید تا برداشت موتور با طراحی شما هم‌خوان باشد.
NAT و پراکسی نیز هویت قابل مشاهده را تغییر می‌دهند. حسگر در یک سمت ممکن است نشانی اصلی کاربر را ببیند و در سمت دیگر فقط نشانی دروازه را مشاهده کند. در گزارش حادثه، محل حسگر را همراه با نشانی‌ها ثبت کنید. بدون این زمینه، تیم ممکن است یک دستگاه واسط را منبع واقعی همه رویدادها تصور کند. برای ارتباط با سامانه‌های دیگر، شناسه جریان و زمان هماهنگ کمک می‌کنند، اما نگاشت نشانی‌ها همچنان باید از معماری شبکه و گزارش تجهیزات مربوط به دست آید.
قاعده را به عنوان فرضیه تشخیص بخوانیم
یک قاعده می‌گوید چه الگوی قابل مشاهده‌ای ارزش هشدار یا اقدام دارد. دیدن نام تهدید در عنوان قاعده، به تنهایی اثبات وقوع موفق آن تهدید نیست. ممکن است الگو در ترافیک عادی نیز دیده شود یا تنها تلاش ناموفق باشد. برای بررسی، پروتکل، جهت، داده مرتبط و زمینه دارایی را بخوانید. اگر سرویس مقصد اصلاً فناوری مرتبط را ندارد، شدت و تفسیر یافته باید با دقت ارزیابی شود. هدف حذف بی‌دلیل هشدار نیست؛ هدف نسبت دادن معنی درست به شاهد است.
در تنظیم قواعد، دلیل هر استثنا را ثبت کنید. خاموش کردن یک قاعده پرسر‌وصدا بدون شناخت علت می‌تواند شکاف ایجاد کند. شاید محدود کردن دامنه دارایی یا تنظیم آستانه مناسب‌تر باشد. در مقابل، نگه داشتن هزاران هشدار بی‌اقدام نیز کار تیم را مختل می‌کند. یک نمونه از هشدار واقعی و یک نمونه از خطای مثبت نگه دارید و تغییر را با هر دو آزمایش کنید. معیار موفقیت، کاهش نویز همراه با حفظ تشخیص مورد نظر است، نه صرفاً پایین آمدن عدد هشدار روی داشبورد.
EVE JSON و زنجیره انتقال رویداد
خروجی EVE می‌تواند انواع رویداد مانند هشدار، اطلاعات جریان و فراداده پروتکل را در قالب JSON ارائه کند. مستندات رسمی EVE گزینه‌های خروجی را توضیح می‌دهد. برای اتصال به SIEM، ابتدا یک نمونه واقعی از هر نوع مورد نیاز را بررسی کنید و نگاشت فیلدها را روشن سازید. فرض اینکه تمام رویدادها ساختار یکسان دارند می‌تواند باعث حذف یا تفسیر نادرست داده شود. نوع رویداد و شناسه‌های ارتباط باید در مسیر پردازش حفظ شوند.
تولید فایل در حسگر پایان زنجیره نیست. جمع‌آورنده، صف، شبکه و ذخیره‌ساز مقصد نیز ممکن است داده را از دست بدهند یا تکرار کنند. یک رویداد آزمایشی با زمان مشخص ایجاد کنید و آن را از حسگر تا صفحه جست‌وجو دنبال کنید. سپس قطع موقت مقصد و چرخش فایل را آزمایش کنید. نتیجه باید نشان دهد صف چه مدت را پوشش می‌دهد و پس از بازگشت چه اتفاقی می‌افتد. نبود هشدار در SIEM ممکن است مشکل انتقال باشد، نه نبود تشخیص در Suricata.
رمزنگاری چه چیزی را پنهان می‌کند؟
بخش زیادی از ترافیک امروزی رمزگذاری‌شده است. حسگر شبکه بدون قرار گرفتن در نقطه مناسب دسترسی به متن آشکار، همه محتوای برنامه را نمی‌بیند. با این حال، بعضی فراداده‌ها و رفتارهای ارتباطی همچنان قابل مشاهده‌اند. طراحی پوشش باید این محدودیت را صریح بیان کند. ادعای بازرسی کامل محتوای همه ارتباط‌ها صرفاً به دلیل دیدن بسته‌ها نادرست است. کنترل نقطه پایانی، گزارش برنامه و داده هویت می‌توانند برای تکمیل تصویر لازم باشند.
در ارزیابی یک مورد تشخیص، بپرسید قاعده به چه داده‌ای نیاز دارد و آیا آن داده در محل حسگر موجود است. اگر پاسخ منفی است، افزایش تعداد قواعد یا منابع پردازشی مشکل پوشش را حل نمی‌کند. شاید محل مشاهده یا منبع داده دیگری لازم باشد. همچنین رمزگشایی ترافیک تصمیمی مستقل با اثر امنیتی و حریم داده است و نباید به صورت ضمنی وارد نصب حسگر شود. برای آموزش، فایل‌های آزمایشی و ترافیک خودتان کافی‌اند و می‌توان محدودیت مشاهده را بدون جمع‌آوری داده حساس نشان داد.
ظرفیت را با ترافیک نماینده بسنجیم
نرخ بیت تنها معیار بار نیست. تعداد بسته، تعداد جریان هم‌زمان، ترکیب پروتکل و مجموعه قواعد بر هزینه پردازش اثر دارند. یک فایل بزرگ یکنواخت ممکن است بار متفاوتی از تعداد زیادی اتصال کوتاه ایجاد کند. برای آزمایش، نمونه‌ای نماینده از محیط با داده مجاز استفاده کنید و افت بسته، استفاده پردازنده، حافظه و زمان خروجی را ثبت کنید. اگر حسگر بسته از دست می‌دهد، ممکن است ظاهراً کم‌هشدار و سالم باشد، در حالی که پوشش واقعی کاهش یافته است.
تنظیم هم‌زمان چند گزینه پردازشی تشخیص اثر را دشوار می‌کند. ابتدا محدودیت اصلی را از شمارنده‌ها پیدا کنید و سپس یک تغییر اعمال کنید. اگر مشکل در دریافت بسته است، افزایش منابع پردازش قواعد شاید کافی نباشد. اگر صف خروجی کند است، تغییر رابط شبکه مسئله را حل نمی‌کند. در گزارش ظرفیت، نسخه موتور، مجموعه قواعد، نوع دریافت و ویژگی ترافیک را ثبت کنید. عدد کارایی بدون این زمینه قابل تعمیم نیست و نباید به عنوان توان ثابت محصول در همه محیط‌ها منتشر شود.
آزمون بازگشت و نگه‌داری قواعد
پس از به‌روزرسانی قواعد یا موتور، مجموعه‌ای از ترافیک آزمایشی شناخته‌شده را دوباره پردازش کنید. انتظار دارید موارد مورد نظر همچنان دیده شوند و ترافیک سالم بی‌دلیل مسدود نشود. تغییر نام فیلد یا قالب رویداد نیز می‌تواند قواعد SIEM را متاثر کند، پس بررسی فقط محدود به اجرای موتور نباشد. یک آزمون انتها به انتها از تولید رویداد تا جست‌وجو و اعلان، پوشش بهتری می‌دهد. نسخه قبلی تنظیمات و قواعد باید برای مقایسه و بازگشت قابل دسترس باشد.
در عملیات روزانه، سلامت حسگر را از تعداد هشدار جدا پایش کنید. دریافت بسته، تازگی خروجی، افت داده و وضعیت فرایندها معیارهای پایه‌اند. حسگری که هیچ هشداری نمی‌دهد ممکن است محیط آرامی ببیند یا اصلاً داده نگیرد. یک نشانه آزمایشی کنترل‌شده و دوره‌ای می‌تواند مسیر را تأیید کند، به شرط آنکه دامنه و اثر آن روشن باشد. راهنمای آغاز کار رسمی Suricata برای اجزای پایه مناسب است؛ پیکربندی نهایی باید با نسخه نصب‌شده و معماری شبکه خودتان تطبیق یابد.
تحویل هشدار به تحلیلگر
هر هشدار باید اطلاعات کافی برای تصمیم بعدی داشته باشد: زمان، حسگر، مبدأ و مقصد مشاهده‌شده، شناسه قاعده و زمینه دارایی. در کنار آن روشن کنید آیا رویداد فقط تشخیص بوده یا اقدام جلوگیری نیز انجام شده است. تحلیلگر نباید از عنوان قاعده این موضوع را حدس بزند. اگر داده تکمیلی نگه‌داری می‌شود، دسترسی آن متناسب با حساسیت محدود شود. یک نمونه پرونده کامل از هشدار آزمایشی بسازید و از فرد دیگری بخواهید فقط با همان پرونده مسیر بررسی را دنبال کند. اگر برای هر مرحله به توضیح شفاهی سازنده نیاز دارد، تحویل عملیاتی هنوز کامل نیست. بهبود همین پرونده اغلب از افزودن هشدارهای بیشتر ارزشمندتر است، زیرا زمان رسیدن از مشاهده به تصمیم را کاهش می‌دهد.
