Zeek چیست و چه دیدی از شبکه می‌دهد؟
Zeek یک تحلیلگر ترافیک شبکه است که از بسته‌های قابل مشاهده، گزارش‌های ساخت‌یافته تولید می‌کند. به جای آنکه تحلیلگر برای هر پرسش مجبور باشد تمام بسته‌ها را دستی بخواند، می‌تواند از اطلاعات خلاصه‌تر درباره ارتباط‌ها و پروتکل‌ها شروع کند. برای مثال، پرسش «این میزبان با چه مقصدهایی ارتباط داشته؟» را می‌توان از گزارش اتصال بررسی کرد و سپس برای جزئیات بیشتر به گزارش پروتکل یا داده خام مراجعه کرد. این روش برای پایش امنیتی و تحقیق رخداد مفید است، اما کیفیت نتیجه به محل مشاهده و کامل بودن ترافیک وابسته است.
Zeek را نباید یک ابزار جادویی برای دیدن همه اتفاقات شبکه دانست. اگر ترافیک به حسگر نرسد، گزارش مربوط نیز تولید نمی‌شود. اگر بخشی رمزگذاری شده باشد، همه محتوای کاربردی آن قابل خواندن نیست. اگر بسته‌ها از دست بروند، بازسازی ارتباط ممکن است ناقص شود. بنابراین هر نتیجه باید همراه با محدوده دید حسگر تفسیر شود. نبود یک رویداد در گزارش، بدون دانستن سلامت دریافت داده، دلیل قطعی نبود آن رویداد نیست. این اصل برای استفاده حرفه‌ای مهم‌تر از یاد گرفتن نام تعداد زیادی فایل لاگ است.
تفاوت با ضبط بسته و سامانه هشدار
ضبط بسته، داده خام را برای بررسی دقیق نگه می‌دارد. Zeek از ترافیک، اطلاعاتی در سطح بالاتر استخراج می‌کند که جست‌وجو و پیوند دادن آن‌ها آسان‌تر است. یک سامانه تشخیص مبتنی بر قواعد نیز ممکن است روی نشانه‌های خاص هشدار بدهد. این نقش‌ها می‌توانند مکمل باشند. گزارش ارتباط به شما زمینه می‌دهد، هشدار توجه را به موردی جلب می‌کند و بسته خام در صورت موجود بودن امکان بررسی جزئی‌تر را فراهم می‌کند. انتخاب ترکیب مناسب به نیاز و منابع بستگی دارد؛ نگهداری همه بسته‌ها برای همیشه نه همیشه ممکن است و نه همیشه ضروری.
برای یک تیم کوچک، بهتر است از چند پرسش عملیاتی آغاز کنید. مثلاً آیا می‌خواهید مقصدهای تازه یک سرور حساس را پیدا کنید یا پس از هشدار میزبان، ارتباط‌های همان بازه زمانی را ببینید؟ این پرسش‌ها تعیین می‌کنند کدام محل شبکه و کدام گزارش‌ها اهمیت دارند. راه‌اندازی ابزار بدون تعریف پرسش معمولاً به تولید حجم زیادی داده منتهی می‌شود که کسی مسئول بررسی آن نیست. در مقابل، یک گزارش محدود که مرتب در تصمیم واقعی استفاده شود، ارزش بیشتری از داشبوردی پر از عددهای بدون اقدام دارد.
محل قرارگیری حسگر و مرز مشاهده
حسگر معمولاً باید نسخه‌ای از ترافیک مجاز را از مسیر مناسب دریافت کند. طراحی این مسیر به معماری شبکه بستگی دارد. مشاهده در مرز اینترنت با مشاهده میان بخش‌های داخلی یکسان نیست؛ هر کدام بخشی از ارتباط‌ها را نشان می‌دهند. اگر ترافیک رفت و برگشت از مسیرهای متفاوت عبور کند، حسگر ممکن است فقط یک جهت را ببیند. این وضعیت روی تفسیر ارتباط و پروتکل اثر می‌گذارد. پیش از اعتماد به خروجی، یک ارتباط آموزشی معلوم ایجاد کنید و بررسی کنید هر دو سمت مورد انتظار در محل مشاهده دیده می‌شوند.
همچنین باید ظرفیت مسیر آینه‌سازی یا تجهیزات دریافت را در نظر بگیرید. تنظیم ظاهری یک درگاه برای ارسال ترافیک، تضمین تحویل کامل در بار بالا نیست. ازدحام، محدودیت لینک یا تنظیم اشتباه می‌تواند بخشی از داده را حذف کند. این مشکل ممکن است در زمان آرام دیده نشود و درست هنگام رخداد یا اوج مصرف ظاهر شود. بنابراین آزمایش باید شرایط نماینده داشته باشد و سلامت دریافت مستقل از تعداد هشدارها پایش شود. نقشه‌ای کوچک از محدوده دید هر حسگر برای تحلیلگران بسیار مفید است، چون می‌دانند از هر گزارش چه انتظاری داشته باشند.
شروع با فایل ضبط‌شده آموزشی
برای یادگیری، تحلیل آفلاین یک فایل ضبط‌شده مجاز روش مناسبی است. ورودی ثابت می‌ماند و می‌توانید چند بار نتیجه را با تنظیمات مختلف مقایسه کنید. مستندات رسمی یک مسیر شروع با فایل نمونه ارائه می‌کند. خروجی معمولاً در فایل‌های گزارش نوشته می‌شود؛ نبود متن زیاد در ترمینال به معنی انجام نشدن تحلیل نیست. بهتر است برای هر آزمایش پوشه جدا بسازید تا خروجی اجرای قبلی با اجرای جدید مخلوط نشود. نام ورودی و نسخه ابزار را نیز کنار نتیجه ثبت کنید.
در نخستین تمرین، از فایلی استفاده کنید که ارتباط‌های آن را می‌شناسید. ابتدا تعداد و جهت ارتباط‌ها را بررسی کنید، سپس گزارش پروتکل مربوط را باز کنید. اگر نتیجه با انتظار فرق دارد، به فایل اصلی برگردید و ببینید آیا ترافیک مورد نظر واقعاً در آن وجود دارد. این روش به شما کمک می‌کند بین مشکل ورودی، تنظیم تحلیلگر و تفسیر اشتباه گزارش فرق بگذارید. تحلیل داده ناشناخته پیش از فهم یک نمونه کوچک، احتمال نتیجه‌گیری عجولانه را بیشتر می‌کند. یک نمونه مرجع سالم برای آزمون بعد از به‌روزرسانی نیز کاربرد دارد.
گزارش conn.log را چگونه بخوانیم؟
گزارش اتصال یکی از نقطه‌های شروع مهم است و می‌تواند اطلاعاتی مانند زمان، دو سمت ارتباط، پروتکل و حجم مشاهده‌شده داشته باشد. مفهوم ارتباط در Zeek فقط به TCP محدود نیست؛ ترافیک‌هایی مانند UDP نیز در این مدل گزارش می‌شوند. نام و معنای دقیق فیلدها را از مستندات همان نسخه بخوانید. به‌خصوص نقش آغازگر و پاسخ‌دهنده را با برچسب دلخواه «داخل» و «خارج» یکی نگیرید. یک میزبان داخلی ممکن است در ارتباطی پاسخ‌دهنده باشد و در ارتباط دیگر آغازگر. تفسیر باید بر اساس همان رکورد و زمینه شبکه باشد.
عدد حجم نیز باید با تعریف فیلد خوانده شود. حجم داده کاربردی، تعداد بسته و حجم در سطح IP لزوماً یک عدد نیستند. اگر دو ابزار عدد متفاوت نشان می‌دهند، ابتدا لایه اندازه‌گیری و محدوده زمانی را مقایسه کنید. اختلاف ممکن است کاملاً قابل توضیح باشد. برای تمرین، یک انتقال کوچک با اندازه معلوم انجام دهید و گزارش‌های مختلف را کنار هم ببینید. هدف این نیست که همه عددها دقیقاً برابر شوند؛ هدف این است که بتوانید توضیح دهید هر عدد چه چیزی را اندازه گرفته و چه چیزی را شامل نمی‌شود.
پیوند گزارش‌ها و دنبال کردن یک ارتباط
در بسیاری از گزارش‌های مرتبط، شناسه ارتباط کمک می‌کند از یک نمای کلی به جزئیات پروتکل بروید. راهنمای رسمی نمونه‌ای از پیوند گزارش اتصال و HTTP با uid ارائه می‌کند. این قابلیت برای تحقیق مفید است: ابتدا ارتباط مورد نظر را پیدا می‌کنید و سپس گزارش‌های مرتبط را بررسی می‌کنید. اما نباید فرض کرد هر رکورد اتصال حتماً تمام انواع گزارش را دارد. تولید گزارش به تشخیص پروتکل، وجود داده کافی و تنظیمات وابسته است. نبود گزارش HTTP روی ترافیکی که محتوای آن قابل تحلیل نیست، لزوماً خرابی ابزار نیست.
برای یک پرونده آموزشی، زمان، شناسه و نام حسگر را کنار هم ثبت کنید. اگر داده چند حسگر را در سامانه مرکزی جمع می‌کنید، زمینه تولید هر رکورد اهمیت دارد. همچنین ساعت‌های ناهماهنگ می‌توانند ترتیب رخدادها را گمراه‌کننده کنند. در تحلیل، زمان مشاهده را از زمان دریافت در سامانه مرکزی جدا نگه دارید. اگر ارسال گزارش با تأخیر انجام شده، تاریخ ورود فایل به مرکز نباید به جای زمان واقعی ارتباط استفاده شود. این دقت در پرونده‌هایی که چند منبع داده دارند، جلوی ارتباط دادن اتفاق‌های نامرتبط را می‌گیرد.
DNS، HTTP و ترافیک رمزگذاری‌شده
گزارش‌های پروتکل می‌توانند زمینه مفیدی درباره پرسش‌های DNS یا درخواست‌های قابل مشاهده فراهم کنند. با این حال، باید مرز دید را بشناسید. اگر DNS از مسیر رمزگذاری‌شده دیگری انجام شود، حسگر شبکه الزاماً متن پرسش را مثل DNS معمولی نمی‌بیند. در HTTPS نیز بدنه و مسیر درخواست بدون دسترسی مناسب به محتوای رمزگشایی‌شده قابل مشاهده کامل نیستند. ممکن است همچنان فراداده‌ای درباره ارتباط یا مذاکره در دسترس باشد، اما آن را با محتوای کامل برنامه اشتباه نگیرید. طراحی پایش باید این محدودیت را از ابتدا بپذیرد.
برای نمونه، دیدن ارتباط با یک سرویس اشتراکی به تنهایی نشان نمی‌دهد کاربر در آن سرویس چه کاری کرده است. نسبت دادن رفتار مشخص نیاز به شواهد دیگر دارد. در گزارش امنیتی، عبارت «ارتباط مشاهده شد» دقیق‌تر از نتیجه‌گیری درباره محتوایی است که حسگر ندیده است. اگر سازمان به دید بیشتری نیاز دارد، باید منابع مکمل مانند لاگ برنامه یا میزبان را با سیاست دسترسی مناسب بررسی کند. افزایش جزئیات جمع‌آوری نیز هزینه حریم خصوصی و نگهداری دارد و باید به نیاز مشخص وصل باشد، نه صرفاً امکان فنی ابزار.
رخداد غیرعادی با رخداد مخرب برابر نیست
گزارشی مانند weird.log می‌تواند رفتار غیرمنتظره یا ناسازگار در تحلیل پروتکل را نشان دهد. چنین رکوردی ارزش بررسی دارد، ولی به تنهایی حکم حمله نیست. پیاده‌سازی نامعمول، بسته ناقص یا مشکل مسیر مشاهده نیز ممکن است نتیجه غیرعادی ایجاد کند. تحلیلگر باید زمان، فراوانی و زمینه را ببیند. اگر یک نوع رویداد بلافاصله پس از تغییر معماری شبکه افزایش یافته، شاید ابتدا باید کیفیت دریافت و مسیر ترافیک بررسی شود. برچسب هیجان‌انگیز بدون فهم علت، باعث اتلاف زمان و کاهش اعتماد به پایش می‌شود.
برای اولویت‌بندی، داده را با نقش دارایی ترکیب کنید. رفتار غیرعادی روی سامانه آزمایشی توسعه با همان رفتار روی سرویس حساس تولید یکسان نیست. در عین حال، مجاز بودن مالک دارایی نباید باعث نادیده گرفتن خودکار همه تغییرها شود. یک روش مناسب این است که برای هر دسته رویداد، دلیل بررسی و معیار ارجاع تعریف شود. نمونه‌های شناخته‌شده را با توضیح نگه دارید تا تحلیلگر تازه بتواند از تجربه قبلی استفاده کند. حذف خاموش رویدادهای پرتعداد، بدون شناخت منشأ، ممکن است مشکل واقعی دریافت یا پیکربندی را پنهان کند.
ظرفیت، افت بسته و نگهداری داده
هزینه تحلیل به نرخ بسته، ترکیب پروتکل، اسکریپت‌ها و منابع سیستم وابسته است. یک عدد پهنای باند به تنهایی برای تعیین ظرفیت کافی نیست. تعداد زیاد بسته‌های کوچک می‌تواند رفتار متفاوتی از انتقال حجیم و یکنواخت داشته باشد. پیش از استقرار گسترده، بار نماینده را بسنجید و معیارهای سلامت دریافت و پردازش را ببینید. اگر بخشی از ترافیک از دست می‌رود، نتیجه‌های تحلیلی باید با همین محدودیت تفسیر شوند. افزایش منابع ممکن است کمک کند، اما نخست باید مشخص شود گلوگاه در دریافت، پردازش یا نوشتن گزارش است.
برای نگهداری، حجم روزانه گزارش و نیاز جست‌وجو را اندازه بگیرید. نگهداری همه انواع داده برای مدت یکسان همیشه منطقی نیست. بعضی گزارش‌ها برای بررسی کوتاه‌مدت لازم‌اند و بعضی خلاصه‌ها برای روند بلندمدت مفیدند. سیاست حذف باید مستند باشد تا هنگام رخداد، کسی انتظار داده‌ای را نداشته باشد که طبق روال حذف شده است. فشرده‌سازی و انتقال نیز باید با کنترل سلامت همراه باشد. وجود فایل در مقصد کافی نیست؛ باید بتوان نمونه‌ای از آن را باز کرد و فیلدهای لازم برای تحلیل را خواند.
اسکریپت‌ها و اتصال به گردش کار امنیت
Zeek امکان گسترش رفتار تحلیلی با اسکریپت و بسته‌های مرتبط را دارد. پیش از افزودن یک بسته، هدف، منبع و اثر آن روی خروجی را بررسی کنید. تغییر ممکن است نام یا ساختار گزارش را عوض کند و سامانه پایین‌دست را تحت تأثیر قرار دهد. برای همین، یک فایل نمونه ثابت و چند انتظار مشخص نگه دارید تا پس از تغییر، نتیجه قابل مقایسه باشد. تولید گزارش جدید فقط زمانی مفید است که مصرف‌کننده آن معلوم باشد. اگر هیچ تحلیل یا تصمیمی از آن استفاده نمی‌کند، احتمالاً باید ضرورت نگهداری آن دوباره بررسی شود.
در اتصال به SIEM یا سامانه تحقیق، نام حسگر، زمان و شناسه‌های ارتباط را حفظ کنید. تبدیل داده نباید زمینه را از بین ببرد یا چند مقدار متفاوت را در یک فیلد مبهم ادغام کند. یک آزمون انتها به انتها طراحی کنید: ارتباط آموزشی ایجاد شود، Zeek آن را گزارش کند، داده به مرکز برسد و تحلیلگر بتواند آن را پیدا کند. هر مرحله باید شاهد داشته باشد. سبز بودن سرویس انتقال، به تنهایی ثابت نمی‌کند محتوای گزارش درست تجزیه و قابل جست‌وجو شده است. این آزمون ساده برای تحویل عملیاتی بسیار ارزشمند است.
استفاده مسئولانه و جمع‌بندی عملی
ترافیک شبکه می‌تواند اطلاعات شخصی یا محرمانه داشته باشد. جمع‌آوری و دسترسی به آن باید در محدوده مجاز و با هدف روشن انجام شود. حتی فراداده نیز ممکن است الگوی کار یا سرویس‌های مورد استفاده افراد را نشان دهد. برای آموزش، از فایل نمونه یا ترافیک ساختگی استفاده کنید و در گزارش اشتراکی، نشانی‌ها و داده حساس را پالایش کنید. دسترسی به داده خام و خروجی‌های تحلیلی را نیز یکسان فرض نکنید؛ هر گروه باید فقط اطلاعات لازم برای کار خود را ببیند.
مسیر مناسب شروع با Zeek این است که یک نمونه معلوم را تحلیل کنید، گزارش اتصال را بفهمید و سپس یک ارتباط را میان چند گزارش دنبال کنید. بعد از آن، محل مشاهده زنده و سلامت دریافت را آزمایش کنید. در نهایت، داده را به یک پرسش عملیاتی و گردش کار پاسخ وصل کنید. با این ترتیب، ابزار به منبع دید قابل اعتماد تبدیل می‌شود. معیار موفقیت، تعداد فایل‌های لاگ نیست؛ توانایی توضیح یک رخداد با شواهد، شناخت محدودیت مشاهده و رسیدن به تصمیم درست است.
