🥇پروتکل های جریان به عنوان ابزاری برای نظارت بر امنیت شبکه داخلی

هنگامی که صحبت از نظارت بر امنیت یک شبکه داخلی شرکت یا بخش می شود، بسیاری آن را با کنترل نشت اطلاعات و پیاده سازی راه حل های DLP مرتبط می دانند. و اگر سعی کنید سوال را روشن کنید و بپرسید که چگونه حملات به شبکه داخلی را شناسایی می کنید ، معمولاً پاسخ به ذکر سیستم های تشخیص نفوذ (IDS) خواهد بود. و آنچه تنها گزینه 10-20 سال پیش بود، امروز به یک نابهنگام تبدیل شده است. یک گزینه موثرتر و در برخی مکان ها تنها گزینه ممکن برای نظارت بر شبکه داخلی وجود دارد - استفاده از پروتکل های جریان، که در ابتدا برای جستجوی مشکلات شبکه (عیب یابی) طراحی شده بودند، اما با گذشت زمان به یک ابزار امنیتی بسیار جالب تبدیل شدند. ما در مورد اینکه چه پروتکل‌هایی وجود دارد و کدام پروتکل‌ها در تشخیص حملات شبکه بهتر هستند، کجا بهتر است نظارت بر جریان را پیاده‌سازی کنیم، در هنگام استقرار چنین طرحی به دنبال چه چیزی باشیم و حتی نحوه "بالا بردن" همه اینها در تجهیزات داخلی صحبت خواهیم کرد. در محدوده این مقاله

من روی این سوال تمرکز نمی کنم "چرا نظارت بر امنیت زیرساخت داخلی لازم است؟" به نظر می رسد پاسخ روشن است. اما اگر، با این وجود، می خواهید یک بار دیگر مطمئن شوید که امروز نمی توانید بدون آن زندگی کنید، نگاهی بینداز یک ویدیوی کوتاه در مورد اینکه چگونه می توانید به 17 روش به یک شبکه شرکتی محافظت شده توسط فایروال نفوذ کنید. بنابراین، فرض می‌کنیم که می‌دانیم نظارت داخلی یک امر ضروری است و تنها چیزی که باقی می‌ماند این است که بفهمیم چگونه می‌توان آن را سازماندهی کرد.

من سه منبع داده کلیدی برای نظارت بر زیرساخت در سطح شبکه را برجسته می کنم:

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

گرفتن ترافیک خام محبوب ترین گزینه در بین متخصصان امنیتی است، زیرا از نظر تاریخی ظاهر شده و اولین گزینه بوده است. سیستم‌های تشخیص نفوذ متعارف شبکه (اولین سیستم تشخیص نفوذ تجاری NetRanger از Wheel Group بود که در سال 1998 توسط سیسکو خریداری شد) دقیقاً درگیر گرفتن بسته‌ها (و جلسات بعدی) بودند که در آنها امضاهای خاصی جستجو می‌شد ("قوانین تعیین کننده" در اصطلاحات FSTEC)، حملات سیگنالینگ. البته، شما می توانید ترافیک خام را نه تنها با استفاده از IDS، بلکه با استفاده از ابزارهای دیگر (مثلاً Wireshark، tcpdum یا عملکرد NBAR2 در Cisco IOS) تجزیه و تحلیل کنید، اما آنها معمولاً فاقد پایگاه دانشی هستند که یک ابزار امنیت اطلاعات را از یک ابزار معمولی متمایز می کند. ابزار فناوری اطلاعات

بنابراین، سیستم های تشخیص حمله. قدیمی‌ترین و محبوب‌ترین روش تشخیص حملات شبکه است که در محیط (مهم نیست - شرکت، مرکز داده، بخش و غیره) به خوبی کار می‌کند، اما در شبکه‌های سوئیچ‌شده و نرم‌افزاری تعریف‌شده مدرن با شکست مواجه می‌شود. در مورد شبکه ای که بر اساس سوئیچ های معمولی ساخته شده است، زیرساخت سنسورهای تشخیص حمله بیش از حد بزرگ می شود - شما باید یک حسگر را روی هر اتصال به گره ای که می خواهید حملات را نظارت کنید نصب کنید. مطمئناً هر سازنده ای خوشحال خواهد شد که صدها و هزاران حسگر را به شما بفروشد، اما فکر می کنم بودجه شما نمی تواند چنین هزینه هایی را تامین کند. می توانم بگویم که حتی در سیسکو (و ما توسعه دهندگان NGIPS هستیم) نتوانستیم این کار را انجام دهیم، اگرچه به نظر می رسد که موضوع قیمت پیش روی ما است. من نباید بایستم - این تصمیم خود ماست. علاوه بر این، این سوال پیش می آید که چگونه سنسور را در این نسخه وصل کنیم؟ به شکاف؟ اگر خود سنسور از کار بیفتد چه؟ نیاز به یک ماژول بای پس در سنسور دارید؟ استفاده از اسپلیتر (شیر)؟ همه اینها راه حل را گران تر می کند و آن را برای شرکتی با هر اندازه ای غیر قابل استفاده می کند.

می توانید سعی کنید حسگر را روی پورت SPAN/RSPAN/ERSPAN آویزان کنید و ترافیک را از پورت های سوئیچ مورد نیاز به آن هدایت کنید. این گزینه تا حدی مشکل توضیح داده شده در پاراگراف قبلی را برطرف می کند، اما مشکل دیگری را ایجاد می کند - پورت SPAN نمی تواند مطلقاً تمام ترافیکی را که به آن ارسال می شود بپذیرد - پهنای باند کافی نخواهد داشت. شما باید چیزی را قربانی کنید. یا برخی از گره ها را بدون نظارت رها کنید (سپس ابتدا باید آنها را اولویت بندی کنید)، یا نه همه ترافیک را از گره، بلکه فقط یک نوع خاص را ارسال کنید. در هر صورت ممکن است برخی حملات را از دست بدهیم. علاوه بر این می توان از پورت SPAN برای سایر نیازها استفاده کرد. در نتیجه، ما باید توپولوژی شبکه موجود را بررسی کنیم و احتمالاً تنظیماتی را در آن انجام دهیم تا با تعداد سنسورهایی که در اختیار دارید، شبکه شما را حداکثر پوشش دهیم (و این را با IT هماهنگ کنیم).

اگر شبکه شما از مسیرهای نامتقارن استفاده کند چه؟ اگر SDN را پیاده سازی کرده اید یا در حال برنامه ریزی برای پیاده سازی هستید چه؟ اگر نیاز به نظارت بر ماشین‌های مجازی یا کانتینرهایی که ترافیک آن‌ها اصلاً به سوئیچ فیزیکی نمی‌رسد چه باید کرد؟ اینها سوالاتی هستند که فروشندگان IDS سنتی آن را دوست ندارند زیرا نمی دانند چگونه به آنها پاسخ دهند. شاید آنها شما را متقاعد کنند که همه این فناوری های مد روز تبلیغاتی هستند و شما به آن نیاز ندارید. شاید آنها در مورد نیاز به شروع کوچک صحبت کنند. یا شاید آنها بگویند که باید یک thresher قدرتمند در مرکز شبکه قرار دهید و با استفاده از متعادل کننده ها تمام ترافیک را به سمت آن هدایت کنید. هر گزینه ای که به شما پیشنهاد می شود، باید به وضوح درک کنید که چگونه برای شما مناسب است. و تنها پس از آن تصمیم گیری در مورد انتخاب رویکرد نظارت بر امنیت اطلاعات زیرساخت شبکه. با بازگشت به ضبط بسته ها، می خواهم بگویم که این روش همچنان بسیار محبوب و مهم است، اما هدف اصلی آن کنترل مرز است. مرزهای بین سازمان شما و اینترنت، مرزهای بین مرکز داده و بقیه شبکه، مرزهای بین سیستم کنترل فرآیند و بخش شرکتی. در این مکان‌ها، IDS/IPS کلاسیک هنوز هم حق دارند وجود داشته باشند و به خوبی با وظایف خود کنار بیایند.

بریم سراغ گزینه دوم. تجزیه و تحلیل رویدادهایی که از دستگاه‌های شبکه می‌آیند نیز می‌تواند برای اهداف تشخیص حمله استفاده شود، اما نه به عنوان مکانیسم اصلی، زیرا امکان تشخیص تنها کلاس کوچکی از نفوذها را فراهم می‌کند. علاوه بر این، در برخی واکنش‌ها ذاتی است - حمله ابتدا باید رخ دهد، سپس باید توسط یک دستگاه شبکه ضبط شود، که به هر طریقی مشکل امنیت اطلاعات را نشان می‌دهد. چندین راه از این دست وجود دارد. این می تواند syslog، RMON یا SNMP باشد. دو پروتکل آخر برای نظارت بر شبکه در زمینه امنیت اطلاعات تنها در صورتی مورد استفاده قرار می‌گیرند که نیاز به شناسایی حمله DoS به خود تجهیزات شبکه داشته باشیم، زیرا با استفاده از RMON و SNMP می‌توان به عنوان مثال، بار روی دستگاه مرکزی را نظارت کرد. پردازنده یا رابط های آن این یکی از "ارزان ترین" است (همه دارای syslog یا SNMP هستند)، اما همچنین بی اثرترین روش نظارت بر امنیت اطلاعات زیرساخت داخلی است - بسیاری از حملات به سادگی از آن پنهان می شوند. البته نباید از آنها غافل شد و همان تجزیه و تحلیل syslog به شما کمک می کند تا تغییرات در پیکربندی خود دستگاه را به موقع شناسایی کنید، به خطر افتادن آن، اما برای تشخیص حملات به کل شبکه بسیار مناسب نیست.

گزینه سوم تجزیه و تحلیل اطلاعات مربوط به ترافیک عبوری از دستگاهی است که یکی از چندین پروتکل جریان را پشتیبانی می کند. در این مورد، صرف نظر از پروتکل، زیرساخت رشته سازی لزوما از سه جزء تشکیل شده است:

تولید یا صادرات جریان. این نقش معمولاً به یک روتر، سوئیچ یا سایر دستگاه های شبکه اختصاص می یابد که با عبور ترافیک شبکه از خود، به شما امکان می دهد پارامترهای کلیدی را از آن استخراج کنید و سپس به ماژول مجموعه منتقل می شود. به عنوان مثال، سیسکو از پروتکل Netflow نه تنها در روترها و سوئیچ ها، از جمله انواع مجازی و صنعتی، بلکه در کنترلرهای بی سیم، فایروال ها و حتی سرورها نیز پشتیبانی می کند.
جریان مجموعه با توجه به اینکه یک شبکه مدرن معمولا بیش از یک دستگاه شبکه دارد، مشکل جمع آوری و یکپارچه سازی جریان ها به وجود می آید که با استفاده از به اصطلاح کلکتورها حل می شود که جریان های دریافتی را پردازش و سپس برای تجزیه و تحلیل ارسال می کنند.
تجزیه و تحلیل جریان تحلیلگر وظیفه اصلی فکری را بر عهده می گیرد و با اعمال الگوریتم های مختلف در جریان ها، نتایج خاصی را به دست می آورد. به عنوان مثال، به عنوان بخشی از یک عملکرد فناوری اطلاعات، چنین تحلیلگری می تواند گلوگاه های شبکه را شناسایی کند یا پروفایل بار ترافیک را برای بهینه سازی بیشتر شبکه تجزیه و تحلیل کند. و برای امنیت اطلاعات، چنین تحلیلگری می تواند نشت داده ها، گسترش کدهای مخرب یا حملات DoS را تشخیص دهد.

فکر نکنید که این معماری سه لایه خیلی پیچیده است - همه گزینه های دیگر (به جز، شاید، سیستم های نظارت شبکه که با SNMP و RMON کار می کنند) نیز بر اساس آن کار می کنند. ما یک تولید کننده داده برای تجزیه و تحلیل داریم که می تواند یک دستگاه شبکه یا یک حسگر مستقل باشد. ما یک سیستم جمع آوری هشدار و یک سیستم مدیریت برای کل زیرساخت نظارت داریم. دو جزء آخر را می توان در یک گره ترکیب کرد، اما در شبکه های کم و بیش بزرگ معمولاً در حداقل دو دستگاه پخش می شوند تا از مقیاس پذیری و قابلیت اطمینان اطمینان حاصل شود.

برخلاف تجزیه و تحلیل بسته، که مبتنی بر مطالعه هدر و داده های بدنه هر بسته و جلساتی است که از آن تشکیل شده است، تجزیه و تحلیل جریان بر جمع آوری ابرداده در مورد ترافیک شبکه متکی است. چه زمانی، چقدر، از کجا و کجا، چگونه... اینها سوالاتی است که توسط تجزیه و تحلیل تله متری شبکه با استفاده از پروتکل های جریان مختلف پاسخ داده می شود. در ابتدا، از آنها برای تجزیه و تحلیل آمار و یافتن مشکلات فناوری اطلاعات در شبکه استفاده می شد، اما پس از آن، با توسعه مکانیسم های تحلیلی، امکان اعمال آنها در همان تله متری برای اهداف امنیتی فراهم شد. شایان ذکر است که تجزیه و تحلیل جریان جایگزین یا جایگزین ضبط بسته نمی شود. هر یک از این روش ها حوزه کاربرد خاص خود را دارد. اما در چارچوب این مقاله، آنالیز جریان است که برای نظارت بر زیرساخت‌های داخلی مناسب‌تر است. شما دستگاه های شبکه ای دارید (چه آنها در یک پارادایم تعریف شده توسط نرم افزار و چه بر اساس قوانین ایستا کار می کنند) که حمله نمی تواند از آنها عبور کند. می تواند حسگر IDS کلاسیک را دور بزند، اما دستگاه شبکه ای که از پروتکل جریان پشتیبانی می کند نمی تواند. این مزیت این روش است.

از سوی دیگر، اگر به شواهدی برای مجری قانون یا تیم تحقیق حادثه خودتان نیاز دارید، نمی‌توانید بدون ضبط بسته‌ها کار کنید - تله‌متری شبکه کپی‌ای از ترافیک نیست که بتوان از آن برای جمع‌آوری شواهد استفاده کرد. برای تشخیص سریع و تصمیم گیری در زمینه امنیت اطلاعات مورد نیاز است. از سوی دیگر، با استفاده از تجزیه و تحلیل تله متری، می توانید نه تمام ترافیک شبکه را بنویسید (در صورت وجود، سیسکو با مراکز داده سر و کار دارد :-)، بلکه فقط مواردی را که در حمله دخالت دارند، بنویسید. ابزارهای تجزیه و تحلیل تله متری در این رابطه مکانیسم های سنتی ضبط بسته را به خوبی تکمیل می کنند و دستوراتی را برای ضبط و ذخیره سازی انتخابی می دهند. در غیر این صورت، باید زیرساخت ذخیره سازی عظیمی داشته باشید.

بیایید شبکه ای را تصور کنیم که با سرعت 250 مگابیت بر ثانیه کار می کند. اگر می خواهید تمام این حجم را ذخیره کنید، برای یک ثانیه انتقال ترافیک به 31 مگابایت، برای یک دقیقه به 1,8 گیگابایت، یک ساعت به 108 گیگابایت و برای یک روز به 2,6 ترابایت فضای ذخیره سازی نیاز دارید. برای ذخیره داده های روزانه از شبکه ای با پهنای باند 10 گیگابیت بر ثانیه، به 108 ترابایت فضای ذخیره سازی نیاز دارید. اما برخی از تنظیم‌کننده‌ها به ذخیره‌سازی داده‌های امنیتی برای سال‌ها نیاز دارند... ضبط بر اساس تقاضا، که تجزیه و تحلیل جریان به شما در پیاده‌سازی آن کمک می‌کند، به کاهش این مقادیر با مرتبه‌ای بزرگ کمک می‌کند. به هر حال، اگر ما در مورد نسبت حجم داده های تله متری شبکه ضبط شده و جمع آوری کامل داده صحبت کنیم، تقریباً 1 به 500 است. برای همان مقادیر داده شده در بالا، ذخیره یک رونوشت کامل از کل ترافیک روزانه به ترتیب 5 و 216 گیگابایت خواهد بود (حتی می توانید آن را روی یک درایو فلش معمولی ضبط کنید).

اگر برای ابزارهای تجزیه و تحلیل داده های خام شبکه، روش گرفتن آن از فروشنده به فروشنده تقریباً یکسان است، در مورد تجزیه و تحلیل جریان وضعیت متفاوت است. چندین گزینه برای پروتکل های جریان وجود دارد، تفاوت هایی که باید در زمینه امنیت در مورد آنها بدانید. محبوب ترین پروتکل Netflow است که توسط سیسکو توسعه یافته است. نسخه های مختلفی از این پروتکل وجود دارد که از نظر قابلیت ها و میزان اطلاعات ترافیکی ثبت شده متفاوت است. نسخه فعلی نهمین نسخه (Netflow v9) است که بر اساس آن استاندارد صنعتی Netflow v10 که با نام IPFIX نیز شناخته می شود، توسعه یافته است. امروزه اکثر فروشندگان شبکه از Netflow یا IPFIX در تجهیزات خود پشتیبانی می کنند. اما گزینه های مختلفی برای پروتکل های جریان وجود دارد - sFlow، jFlow، cFlow، rFlow، NetStream و غیره که sFlow محبوب ترین آنهاست. این نوع است که اغلب توسط سازندگان داخلی تجهیزات شبکه به دلیل سهولت اجرا پشتیبانی می شود. تفاوت های کلیدی بین Netflow که به یک استاندارد واقعی تبدیل شده است و sFlow چیست؟ من چندین مورد کلیدی را برجسته می کنم. اول، Netflow دارای فیلدهای قابل تنظیم توسط کاربر در مقابل فیلدهای ثابت در sFlow است. و دوم، و این مهمترین چیز در مورد ما است، sFlow به اصطلاح تله متری نمونه برداری را جمع آوری می کند. در مقایسه با نمونه بدون نمونه برای Netflow و IPFIX. چه تفاوتی بین آنها وجود دارد؟

تصور کنید که تصمیم دارید کتاب را بخوانیدمرکز عملیات امنیتی: ساخت، بهره برداری و نگهداری SOC شما” از همکاران من - گری مک اینتایر، جوزف مونیتز و نادم آلفردان (بخشی از کتاب را می توانید از لینک دانلود کنید). شما سه گزینه برای رسیدن به هدف خود دارید - کل کتاب را بخوانید، آن را مرور کنید، در هر صفحه دهم یا بیستم توقف کنید، یا سعی کنید بازگویی مفاهیم کلیدی را در وبلاگ یا سرویسی مانند SmartReading پیدا کنید. بنابراین، تله متری نمونه برداری نشده، خواندن هر صفحه از ترافیک شبکه است، یعنی تجزیه و تحلیل ابرداده برای هر بسته. تله متری نمونه مطالعه انتخابی ترافیک است به این امید که نمونه های انتخاب شده حاوی آنچه شما نیاز دارید باشد. بسته به سرعت کانال، تله متری نمونه برای آنالیز هر بسته 10، 20، 64، 200، 500 یا حتی 1000 ارسال می شود.

در زمینه نظارت بر امنیت اطلاعات، این بدان معنی است که تله متری نمونه برای تشخیص حملات DDoS، اسکن، و انتشار کدهای مخرب مناسب است، اما ممکن است حملات اتمی یا چند بسته ای را که در نمونه ارسال شده برای تجزیه و تحلیل گنجانده نشده اند، از دست بدهد. تله متری بدون نمونه چنین معایبی ندارد. با این کار، دامنه حملات شناسایی شده بسیار گسترده تر است. در اینجا لیست کوتاهی از رویدادهایی است که با استفاده از ابزارهای تجزیه و تحلیل تله متری شبکه قابل شناسایی هستند.

البته، برخی از تحلیلگرهای منبع باز Netflow به شما اجازه انجام این کار را نمی دهند، زیرا وظیفه اصلی آن جمع آوری تله متری و انجام تجزیه و تحلیل اولیه روی آن از نقطه نظر فناوری اطلاعات است. برای شناسایی تهدیدات امنیت اطلاعات بر اساس جریان، تجهیز آنالیزور به موتورها و الگوریتم‌های مختلفی ضروری است که مشکلات امنیت سایبری را بر اساس فیلدهای استاندارد یا سفارشی Netflow شناسایی می‌کند، داده‌های استاندارد را با داده‌های خارجی از منابع مختلف Threat Intelligence و غیره غنی می‌کند.

بنابراین، اگر حق انتخاب دارید، Netflow یا IPFIX را انتخاب کنید. اما حتی اگر تجهیزات شما مانند سازندگان داخلی فقط با sFlow کار می کند، حتی در این مورد نیز می توانید در زمینه امنیتی از آن بهره مند شوید.

در تابستان 2019، من توانایی‌هایی را که سازندگان سخت‌افزار شبکه روسی دارند، تجزیه و تحلیل کردم و همه آنها، به استثنای NSG، Polygon و Craftway، پشتیبانی از sFlow (حداقل Zelax، Natex، Eltex، QTech، Rusteleteh) را اعلام کردند.

سوال بعدی که با آن روبرو خواهید شد این است که پشتیبانی جریان را برای اهداف امنیتی در کجا پیاده سازی کنیم؟ در واقع، سؤال کاملاً درست مطرح نشده است. تجهیزات مدرن تقریباً همیشه از پروتکل های جریان پشتیبانی می کنند. بنابراین، من این سوال را به گونه‌ای دیگر فرموله می‌کنم - جمع‌آوری تله متری از نقطه نظر امنیتی کجا مؤثرتر است؟ پاسخ کاملاً واضح خواهد بود - در سطح دسترسی، جایی که 100٪ از کل ترافیک را مشاهده خواهید کرد، جایی که اطلاعات دقیقی در مورد هاست (MAC، VLAN، شناسه رابط) خواهید داشت، جایی که می توانید حتی ترافیک P2P بین هاست ها را نظارت کنید. برای اسکن تشخیص و توزیع کدهای مخرب بسیار مهم است. در سطح هسته، ممکن است به سادگی مقداری از ترافیک را نبینید، اما در سطح محیطی، یک چهارم کل ترافیک شبکه خود را خواهید دید. اما اگر به دلایلی دستگاه های خارجی در شبکه خود دارید که به مهاجمان اجازه می دهد بدون دور زدن محیط "ورود و خارج شوند"، تجزیه و تحلیل تله متری از آن چیزی به شما نمی دهد. بنابراین، برای حداکثر پوشش، توصیه می شود مجموعه تله متری را در سطح دسترسی فعال کنید. در عین حال، شایان ذکر است که حتی اگر در مورد مجازی سازی یا کانتینرها صحبت می کنیم، پشتیبانی جریان نیز اغلب در سوئیچ های مجازی مدرن یافت می شود که به شما امکان می دهد ترافیک را در آنجا نیز کنترل کنید.

اما از آنجایی که موضوع را مطرح کردم، باید به این سوال پاسخ دهم: اگر تجهیزات، فیزیکی یا مجازی، از پروتکل های جریان پشتیبانی نکنند، چه؟ یا گنجاندن آن ممنوع است (مثلاً در بخش های صنعتی برای اطمینان از قابلیت اطمینان)؟ یا روشن کردن آن منجر به بار بالای CPU می شود (این اتفاق در سخت افزارهای قدیمی رخ می دهد)؟ برای حل این مشکل، سنسورهای مجازی تخصصی (سنسورهای جریان) وجود دارند که در اصل اسپلیترهای معمولی هستند که ترافیک را از خود عبور داده و به صورت جریان به ماژول مجموعه پخش می کنند. درست است، در این مورد، ما تمام مشکلاتی را که در بالا در مورد ابزارهای ضبط بسته صحبت کردیم، دریافت می کنیم. به این معنا که نه تنها باید مزایای فناوری تحلیل جریان، بلکه محدودیت‌های آن را نیز درک کنید.

نکته دیگری که هنگام صحبت در مورد ابزارهای تحلیل جریان باید به خاطر بسپارید. اگر در رابطه با وسایل متداول تولید رویدادهای امنیتی از متریک EPS (رویداد در ثانیه) استفاده کنیم، این شاخص برای تجزیه و تحلیل تله متری قابل استفاده نیست. FPS (جریان در ثانیه) جایگزین آن می شود. همانطور که در مورد EPS، نمی توان آن را از قبل محاسبه کرد، اما می توانید تعداد تقریبی رشته هایی را که یک دستگاه خاص تولید می کند بسته به وظیفه خود تخمین بزنید. می توانید جداول را در اینترنت با مقادیر تقریبی برای انواع مختلف دستگاه ها و شرایط سازمانی پیدا کنید که به شما امکان می دهد تخمین بزنید که برای ابزارهای تجزیه و تحلیل به چه مجوزهایی نیاز دارید و معماری آنها چگونه خواهد بود؟ واقعیت این است که سنسور IDS با پهنای باند خاصی که می تواند "کشش" را محدود کند، و جمع کننده جریان محدودیت های خاص خود را دارد که باید درک شود. بنابراین، در شبکه های بزرگ و پراکنده جغرافیایی معمولاً چندین جمع کننده وجود دارد. وقتی توصیف کردم چگونه شبکه در داخل سیسکو نظارت می شود، من قبلاً تعداد کلکسیونرهایمان را آورده ام - 21 نفر از آنها وجود دارد. و این برای شبکه ای است که در پنج قاره پراکنده است و حدود نیم میلیون دستگاه فعال دارد).

ما از راه حل خودمان به عنوان یک سیستم مانیتورینگ Netflow استفاده می کنیم سیسکو Stealthwatch، که به طور خاص بر حل مشکلات امنیتی متمرکز است. دارای موتورهای داخلی بسیاری برای تشخیص فعالیت های غیرعادی، مشکوک و آشکارا مخرب است که به شما امکان می دهد طیف گسترده ای از تهدیدات مختلف را شناسایی کنید - از رمزنگاری گرفته تا نشت اطلاعات، از انتشار کدهای مخرب تا کلاهبرداری. مانند اکثر آنالایزرهای جریان، Stealthwatch بر اساس یک طرح سه سطحی (ژنراتور - جمع کننده - تحلیلگر) ساخته شده است، اما با تعدادی ویژگی جالب تکمیل شده است که در زمینه مواد مورد بررسی مهم هستند. اول، با راه حل های ضبط بسته (مانند Cisco Security Packet Analyzer) یکپارچه می شود، که به شما امکان می دهد جلسات شبکه انتخاب شده را برای بررسی و تجزیه و تحلیل عمیق بعدی ضبط کنید. ثانیاً، به طور خاص برای گسترش وظایف امنیتی، ما یک پروتکل nvzFlow ویژه ایجاد کرده‌ایم که به شما امکان می‌دهد فعالیت برنامه‌های کاربردی در گره‌های انتهایی (سرورها، ایستگاه‌های کاری و غیره) را به تله متری «پخش» کرده و آن را برای تجزیه و تحلیل بیشتر به جمع‌کننده منتقل کنید. اگر در نسخه اصلی خود Stealthwatch با هر پروتکل جریانی (sFlow، rFlow، Netflow، IPFIX، cFlow، jFlow، NetStream) در سطح شبکه کار می کند، در این صورت پشتیبانی nvzFlow امکان همبستگی داده ها را در سطح گره نیز فراهم می کند. افزایش کارایی کل سیستم و مشاهده حملات بیشتر نسبت به تحلیلگرهای جریان شبکه معمولی.

واضح است که وقتی در مورد سیستم های تحلیل Netflow از نقطه نظر امنیتی صحبت می شود، بازار به یک راه حل منفرد از سیسکو محدود نمی شود. شما می توانید از راه حل های تجاری و رایگان یا اشتراک افزار استفاده کنید. اگر راه حل های رقبا را به عنوان مثال در وبلاگ سیسکو ذکر کنم، بسیار عجیب است، بنابراین چند کلمه در مورد چگونگی تجزیه و تحلیل تله متری شبکه با استفاده از دو ابزار محبوب، مشابه از نظر نام، اما همچنان متفاوت - SiLK و ELK می گویم.

SiLK مجموعه ای از ابزارها (سیستم دانش سطح اینترنت) برای تجزیه و تحلیل ترافیک است که توسط CERT/CC آمریکا توسعه یافته و در چارچوب مقاله امروز، Netflow (نسخه های پنجم و نهم، محبوب ترین)، IPFIX را پشتیبانی می کند. و sFlow و با استفاده از ابزارهای مختلف (rwfilter، rwcount، rwflowpack و ...) برای انجام عملیات های مختلف بر روی تله متری شبکه به منظور تشخیص علائم اعمال غیرمجاز در آن. اما باید به چند نکته مهم توجه کرد. SiLK یک ابزار خط فرمان است که با وارد کردن دستوراتی مانند این تجزیه و تحلیل آنلاین انجام می دهد (تشخیص بسته های ICMP بزرگتر از 5 بایت):

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

خیلی راحت نیست می‌توانید از رابط کاربری گرافیکی iSiLK استفاده کنید، اما این کار زندگی شما را آسان‌تر نمی‌کند، فقط عملکرد تجسم را حل می‌کند و جایگزین تحلیلگر نمی‌کند. و این نکته دوم است. بر خلاف راه حل های تجاری، که در حال حاضر دارای یک پایگاه تحلیلی جامد، الگوریتم های تشخیص ناهنجاری، گردش کار متناظر و غیره هستند، در مورد SiLK شما باید همه این کارها را خودتان انجام دهید، که نیاز به شایستگی های کمی متفاوت از شما نسبت به استفاده از روش های آماده دارد. برای استفاده از ابزار این نه خوب است و نه بد - این ویژگی تقریباً هر ابزار رایگانی است که فرض می‌کند شما می‌دانید چه کاری باید انجام دهید، و فقط در این مورد به شما کمک می‌کند (ابزارهای تجاری کمتر به شایستگی‌های کاربرانش وابسته هستند، اگرچه آنها نیز فرض می‌کنند که تحلیلگران حداقل اصول اولیه تحقیقات و نظارت شبکه را درک می کنند). اما اجازه دهید به SiLK برگردیم. چرخه کاری تحلیلگر با آن به این صورت است:

تدوین یک فرضیه. ما باید بفهمیم که در داخل تله متری شبکه به دنبال چه چیزی خواهیم بود، ویژگی های منحصر به فردی را بدانیم که توسط آن ناهنجاری ها یا تهدیدات خاصی را شناسایی می کنیم.
ساخت مدل. پس از فرموله کردن یک فرضیه، آن را با استفاده از همان پایتون، پوسته یا سایر ابزارهایی که در SiLK وجود ندارد، برنامه ریزی می کنیم.
آزمایش کردن. اکنون نوبت بررسی صحت فرضیه ما است، که با استفاده از ابزارهای SiLK که با 'rw'، 'set'، 'bag' شروع می شود، تأیید یا رد می شود.
تجزیه و تحلیل داده های واقعی در عملیات صنعتی، SiLK به ما کمک می کند چیزی را شناسایی کنیم و تحلیلگر باید به سؤالات «آیا آنچه را که انتظار داشتیم پیدا کردیم؟»، «آیا این با فرضیه ما مطابقت دارد؟»، «چگونه تعداد مثبت کاذب را کاهش دهیم؟»، «چگونه پاسخ دهد؟» برای بهبود سطح شناخت؟» و غیره
بهبود. در مرحله نهایی، آنچه را که قبلا انجام شده بود بهبود می‌دهیم - قالب‌ها را ایجاد می‌کنیم، کد را بهبود می‌بخشیم و بهینه می‌کنیم، فرضیه را دوباره فرمول‌بندی و شفاف می‌کنیم و غیره.

این چرخه برای Cisco Stealthwatch نیز قابل اجرا خواهد بود، تنها آخرین مرحله این پنج مرحله را به حداکثر خودکار می‌کند و تعداد خطاهای تحلیلگر را کاهش می‌دهد و کارایی تشخیص حادثه را افزایش می‌دهد. به عنوان مثال، در SiLK می‌توانید آمار شبکه را با داده‌های خارجی در IPهای مخرب با استفاده از اسکریپت‌های دست‌نویس غنی کنید، و در سیسکو Stealthwatch یک تابع داخلی است که اگر ترافیک شبکه دارای تعامل با آدرس‌های IP از لیست سیاه باشد، فوراً زنگ هشدار را نشان می‌دهد.

اگر در هرم "پرداخت" نرم افزار تجزیه و تحلیل جریان بالاتر بروید، پس از SiLK کاملا رایگان، یک اشتراک افزار ELK وجود خواهد داشت که از سه جزء کلیدی تشکیل شده است - Elasticsearch (نمایه گذاری، جستجو و تجزیه و تحلیل داده)، Logstash (ورودی/خروجی داده ها). ) و کیبانا (تجسم). برخلاف SiLK، که در آن شما باید همه چیز را خودتان بنویسید، ELK در حال حاضر دارای بسیاری از کتابخانه ها/ماژول های آماده (بعضی پولی، برخی نه) است که تجزیه و تحلیل تله متری شبکه را خودکار می کند. به عنوان مثال، فیلتر GeoIP در Logstash به شما امکان می دهد آدرس های IP نظارت شده را با موقعیت جغرافیایی آنها مرتبط کنید (Stealthwatch این ویژگی داخلی را دارد).

ELK همچنین دارای یک جامعه نسبتاً بزرگ است که در حال تکمیل اجزای گمشده برای این راه حل نظارت است. به عنوان مثال، برای کار با Netflow، IPFIX و sFlow می توانید از ماژول استفاده کنید elastiflow، اگر از ماژول Logstash Netflow که فقط از Netflow پشتیبانی می کند راضی نیستید.

در حالی که ELK کارایی بیشتری در جمع آوری جریان و جستجو در آن می دهد، در حال حاضر فاقد تجزیه و تحلیل داخلی غنی برای تشخیص ناهنجاری ها و تهدیدات در تله متری شبکه است. یعنی با پیروی از چرخه زندگی که در بالا توضیح داده شد، باید به طور مستقل مدل های نقض را توصیف کنید و سپس از آن در سیستم مبارزه استفاده کنید (هیچ مدل داخلی در آنجا وجود ندارد).

البته افزونه‌های پیچیده‌تری برای ELK وجود دارد که قبلاً دارای مدل‌هایی برای تشخیص ناهنجاری‌ها در تله‌متری شبکه است، اما چنین افزونه‌هایی هزینه دارند و در اینجا سؤال این است که آیا بازی ارزش شمع را دارد - خودتان یک مدل مشابه بنویسید، آن را بخرید. برای ابزار مانیتورینگ خود پیاده سازی کنید یا راه حل آماده کلاس تحلیل ترافیک شبکه را خریداری کنید.

در کل نمی خواهم وارد این بحث شوم که بهتر است پول خرج کنید و یک راه حل آماده برای نظارت بر ناهنجاری ها و تهدیدات در تله متری شبکه بخرید (مثلا سیسکو Stealthwatch) یا خودتان آن را بفهمید و همان را شخصی سازی کنید. SiLK، ELK یا nfdump یا OSU Flow Tools برای هر تهدید جدید (در مورد دو مورد آخر صحبت می کنم گفت آخرین بار)؟ هر کس برای خودش انتخاب می کند و هرکس انگیزه های خود را برای انتخاب هر یک از این دو گزینه دارد. من فقط می خواستم نشان دهم که تله متری شبکه ابزار بسیار مهمی در تضمین امنیت شبکه زیرساخت داخلی شما است و نباید از آن غافل شوید تا به لیست شرکت هایی که نام آنها در رسانه ها همراه با القاب ذکر شده است نپیوندید. هک شده، "غیر مطابق با الزامات امنیت اطلاعات" "، "به امنیت داده های خود و داده های مشتری فکر نمی کنند."

به طور خلاصه، من می خواهم نکات کلیدی را که باید هنگام ایجاد نظارت بر امنیت اطلاعات زیرساخت داخلی خود رعایت کنید، فهرست کنم:

فقط خود را به محیط محدود نکنید! از زیرساخت شبکه استفاده کنید (و انتخاب کنید) نه تنها برای انتقال ترافیک از نقطه A به نقطه B، بلکه برای رسیدگی به مسائل امنیت سایبری.
مکانیسم های نظارت بر امنیت اطلاعات موجود در تجهیزات شبکه خود را مطالعه کرده و از آنها استفاده کنید.
برای نظارت داخلی، تجزیه و تحلیل تله متری را ترجیح دهید - به شما امکان می دهد تا 80-90٪ از تمام حوادث امنیت اطلاعات شبکه را شناسایی کنید، در حالی که در هنگام ضبط بسته های شبکه و صرفه جویی در فضا برای ذخیره همه رویدادهای امنیت اطلاعات، آنچه غیرممکن است انجام دهید.
برای نظارت بر جریان ها، از Netflow v9 یا IPFIX استفاده کنید - آنها اطلاعات بیشتری را در زمینه امنیتی ارائه می دهند و به شما امکان می دهند نه تنها IPv4، بلکه IPv6، MPLS و غیره را نیز نظارت کنید.
از یک پروتکل جریان نمونه برداری نشده استفاده کنید - این پروتکل اطلاعات بیشتری را برای شناسایی تهدیدها فراهم می کند. به عنوان مثال، Netflow یا IPFIX.
بار روی تجهیزات شبکه خود را بررسی کنید - ممکن است نتواند پروتکل جریان را نیز مدیریت کند. سپس استفاده از حسگرهای مجازی یا Netflow Generation Appliance را در نظر بگیرید.
کنترل را اول از همه در سطح دسترسی اجرا کنید - این به شما این فرصت را می دهد که 100٪ از کل ترافیک را ببینید.
اگر انتخابی ندارید و از تجهیزات شبکه روسی استفاده می کنید، یکی را انتخاب کنید که از پروتکل های جریان پشتیبانی می کند یا دارای پورت های SPAN/RSPAN است.
سیستم‌های تشخیص نفوذ/حمله/پیشگیری در لبه‌ها و سیستم‌های تحلیل جریان را در شبکه داخلی (از جمله در ابرها) ترکیب کنید.

در مورد آخرین نکته، می خواهم تصویری را که قبلاً ارائه کرده ام، ارائه دهم. می‌بینید که اگر قبلاً سرویس امنیت اطلاعات سیسکو تقریباً به طور کامل سیستم نظارت بر امنیت اطلاعات خود را بر اساس سیستم‌های تشخیص نفوذ و روش‌های امضا ساخته بود، اکنون فقط 20٪ از حوادث را تشکیل می‌دهند. 20٪ دیگر به سیستم های تجزیه و تحلیل جریان می رسد، که نشان می دهد این راه حل ها یک هوی و هوس نیستند، بلکه یک ابزار واقعی در فعالیت های خدمات امنیت اطلاعات یک شرکت مدرن هستند. علاوه بر این، شما مهمترین چیز را برای اجرای آنها دارید - زیرساخت شبکه، سرمایه گذاری هایی که در آن می توان با اختصاص عملکردهای نظارت بر امنیت اطلاعات به شبکه بیشتر محافظت کرد.

من به طور خاص به موضوع پاسخ به ناهنجاری ها یا تهدیدهای شناسایی شده در جریان های شبکه اشاره نکردم، اما فکر می کنم از قبل واضح است که نظارت نباید تنها با شناسایی یک تهدید خاتمه یابد. باید به دنبال پاسخ و ترجیحاً در حالت خودکار یا خودکار باشد. اما این موضوع برای یک مقاله جداگانه است.

اطلاعات اضافی:

PS. اگر شنیدن همه چیزهایی که در بالا نوشته شده است برای شما آسان تر است، می توانید ارائه یک ساعته را که اساس این یادداشت را تشکیل می دهد تماشا کنید.

منبع: www.habr.com

پروتکل های جریان به عنوان ابزاری برای نظارت بر امنیت یک شبکه داخلی

اضافه کردن نظر انصراف از پاسخ