در بسیاری از سازمانها، تمرکز اصلی هنگام پیادهسازی تجهیزات امنیتی روی طراحی Access Control Policy، فعالسازی IPS و تنظیم NAT است. اما در عمل آنچه تعیین میکند شبکه واقعاً امن است یا صرفاً تصور امنیت وجود دارد، کیفیت مانیتورینگ و تحلیل دادههای تولیدشده توسط فایروال است. در معماری مبتنی بر Cisco Firepower Management Center، شما تنها با یک کنسول مدیریتی طرف نیستید؛ بلکه با یک پلتفرم تحلیلی سروکار دارید که میتواند میلیونها Event را پردازش، دستهبندی و تحلیل کند.
مانیتورینگ پیشرفته در FMC یعنی درک دقیق از اینکه چه Eventهایی تولید میشوند، کجا ذخیره میشوند، چگونه Correlate میشوند و در نهایت چگونه به اطلاعات قابل اقدام تبدیل میشوند. اگر این زنجیره بهدرستی طراحی نشود، یا دیتابیس اشباع میشود یا تیم SOC در میان انبوهی از لاگهای بیارزش غرق خواهد شد.
در این مقاله، تمام ابعاد فنی و تجربی مانیتورینگ و گزارشگیری در FMC را از منظر یک مهندس امنیت شبکه بررسی میکنیم و سناریوهای واقعی پروژهای را تحلیل خواهیم کرد.
برای اینکه بتوانید مانیتورینگ پیشرفته و قابل اتکا در Cisco Firepower Management Center پیادهسازی کنید، باید معماری تولید، انتقال و پردازش Event را در سطح Packet Flow درک کنید، نه صرفاً در حد یک دیاگرام منطقی.
زمانی که یک Packet وارد FTD میشود، ابتدا وارد ماژول Snort یا همان Detection Engine میگردد. قبل از هر چیز، مرحله Pre-Filtering انجام میشود. اگر Pre-Filter Policy فعال باشد، بخشی از ترافیک ممکن است FastPath شود و اصلاً وارد پردازش عمیق نشود. این موضوع مستقیماً روی تولید Event اثر دارد، زیرا ترافیکی که FastPath شود، Intrusion Event تولید نخواهد کرد. در یکی از پروژههای سازمانی، فعال بودن FastPath برای بخشی از VLANهای داخلی باعث شد چندین Exploit داخلی هیچگاه در Intrusion Event ثبت نشوند. تیم امنیتی تصور میکرد IPS بهدرستی کار میکند، در حالی که معماری پردازش بهدرستی تحلیل نشده بود.
پس از مرحله Pre-Filter، ترافیک وارد Access Control Policy میشود. در این مرحله، Rule Matching بر اساس Zone، Network Object، Application، URL Category و سایر پارامترها انجام میشود. اگر Rule شامل Logging باشد، متادیتای Session ذخیره میشود. نکته مهم این است که Logging میتواند در دو نقطه انجام شود. Log at Beginning زمانی ثبت میشود که Session ایجاد میشود، در حالی که Log at End پس از اتمام Session و با داشتن اطلاعات کامل مانند Byte Count و Duration ثبت میشود. انتخاب اشتباه این دو، هم روی کیفیت تحلیل اثر دارد و هم روی حجم دیتابیس.
پس از تصمیم Allow یا Block، اگر Intrusion Policy به Rule متصل باشد، ترافیک به موتور Snort ارسال میشود. در اینجا Signatureها، Preprocessorها و Ruleهای IPS اجرا میشوند. اگر Signature تطابق پیدا کند، Intrusion Event تولید میشود. شدت Event بر اساس Impact Level و Priority تعیین میشود. درک این موضوع مهم است که Intrusion Event مستقل از Connection Event است. یعنی ممکن است Connection Allow شود ولی Intrusion با Impact بالا ثبت گردد. در پروژهای که روی زیرساخت مالی کار میکردیم، چندین SQL Injection با Impact بالا ثبت شده بود ولی چون Connection Allow بود، تیم شبکه آن را بیاهمیت تلقی کرده بود.
پس از تولید Event در FTD، این Event از طریق کانال امن و رمزنگاریشده به FMC ارسال میشود. در این مرحله، Queue داخلی روی FTD اهمیت پیدا میکند. اگر FMC به هر دلیل در دسترس نباشد یا Latency بالا باشد، Queue پر میشود و در نهایت Event Drop رخ میدهد. این موضوع در محیطهای توزیعشده با لینکهای WAN ضعیف بسیار دیده شده است. در یکی از پروژههای چندسایته، به دلیل محدودیت پهنای باند MPLS، حدود ۷ درصد Eventها به FMC نرسیده بودند. بدون مانیتورینگ Health، این موضوع ماهها پنهان مانده بود.
وقتی Event وارد FMC میشود، ابتدا در Message Broker پردازش شده و سپس وارد Event Database میشود. دیتابیس FMC ساختاری بهینهشده برای ذخیره حجم بالای داده دارد، اما همچنان محدودیت IOPS و Disk Throughput وجود دارد. هر Query در بخش Analysis مستقیماً روی این دیتابیس اجرا میشود. اگر ایندکسها سنگین شوند یا حجم Event بیش از حد افزایش یابد، زمان پاسخگویی Queryها بهشدت بالا میرود. در یک دیتاسنتر با بیش از ۱۵ میلیون Event روزانه، زمان اجرای یک Query ساده به بیش از ۴۵ ثانیه رسیده بود. پس از بازطراحی Logging و کاهش Eventهای کمارزش، این زمان به کمتر از ۵ ثانیه کاهش یافت.
اگر بخواهیم حرفهای به مانیتورینگ در Cisco Firepower Management Center نگاه کنیم، باید از سطح نامگذاری Eventها عبور کنیم و بفهمیم هر Event دقیقاً در چه لایهای تولید میشود، چه Contextی دارد و در چه سناریویی ارزش عملیاتی پیدا میکند. بسیاری از مهندسان فقط Connection Event را میبینند چون بیشترین حجم را دارد، اما در واقع ارزش امنیتی بالاتر معمولاً در Intrusion، File و Security Intelligence Event نهفته است.
Connection Event پایهایترین نوع Event است. این Event زمانی تولید میشود که یک Session بر اساس Access Control Policy Allow یا Block شود و Logging فعال باشد. اطلاعاتی مانند Source IP، Destination IP، Port، Application، URL، Byte Count و Duration در آن ثبت میشود. از نظر عملیاتی، Connection Event برای تحلیل رفتار شبکه و Baseline گرفتن بسیار مهم است. شما با بررسی Connection Event میتوانید بفهمید کدام Applicationها بیشترین مصرف را دارند، کدام Host بیشترین Session را ایجاد میکند و الگوی ترافیکی در ساعات مختلف چگونه تغییر میکند.
اما اشتباه رایج این است که Connection Event را به عنوان شاخص تهدید در نظر بگیرند. در یکی از پروژههای صنعتی، تیم امنیتی صرفاً به دنبال Block Event میگشت. چون تعداد Block کم بود، تصور میکردند وضعیت پایدار است. در حالی که بررسی دقیقتر نشان داد حجم بالایی از Connectionهای Allow به سمت یک IP خارجی خاص برقرار شده است. این IP بعداً به عنوان C2 Server شناسایی شد. Connection Event به تنهایی تهدید را مشخص نمیکرد، اما الگوی غیرعادی آن نشانه اولیه بود.
Intrusion Event سطح بالاتری از تحلیل را نشان میدهد. این Event زمانی ثبت میشود که ترافیک با Signatureهای IPS تطابق پیدا کند. در اینجا مفاهیمی مانند Impact Level، Priority و Classification اهمیت پیدا میکند. Intrusion Event میتواند نشان دهد که حملهای در حال وقوع است حتی اگر Session در نهایت Allow شده باشد. این تفاوت بسیار مهم است. Allow شدن Connection به معنای سالم بودن آن نیست.
در یک پروژه بانکی، چندین Intrusion Event با Impact بالا برای SQL Injection ثبت شده بود، اما چون Rule اصلی Allow بود و سرویس وب در دسترس باقی مانده بود، تیم عملیاتی آن را جدی نگرفت. چند هفته بعد مشخص شد مهاجم از همان Endpoint برای استخراج داده استفاده کرده است. اگر Intrusion Event به عنوان شاخص اصلی ریسک تحلیل میشد، Incident بسیار زودتر مهار میشد.
File Event زمانی تولید میشود که قابلیت Advanced Malware Protection فعال باشد و فایلهای در حال انتقال بررسی شوند. این Event شامل Hash فایل، Verdict اولیه، و در صورت فعال بودن Retrospective Analysis، تغییر وضعیت فایل در آینده است. ارزش واقعی File Event در تحلیل تأخیری مشخص میشود. ممکن است فایلی در لحظه دانلود Clean تشخیص داده شود اما چند روز بعد به عنوان Malware طبقهبندی شود. در این حالت FMC میتواند Retrospective Alert تولید کند.
بزرگترین اشتباه در پروژههای Firepower، Logging بیهدف است. هر Rule باید بر اساس سطح ریسک و نیاز تحلیلی تصمیمگیری شود.
برای ترافیک Allow عمومی مانند HTTPS کاربران داخلی، Log at End کافی است. برای ترافیک Block شده، Log at Beginning منطقیتر است چون Session شکل نمیگیرد. برای Ruleهای حساس مانند دسترسی به سرورهای حیاتی، میتوان Logging را در سطح Detailed فعال کرد.
در محیط CLI نیز میتوان رفتار لاگ را بررسی کرد. مثال زیر در FTD نشان میدهد چگونه Rule با سطح informational لاگ تولید میکند:
اما توصیه عملی این است که مدیریت Logging از طریق FMC انجام شود تا دید متمرکز حفظ گردد.
در پروژهای که بیش از ۲۰۰ Rule داشت، با حذف Logging از ترافیک CDN و Backup، حجم Event روزانه ۳۵ درصد کاهش یافت بدون آنکه دید امنیتی آسیب ببیند. این همان طراحی مهندسی است، نه تنظیمات پیشفرض.
بخش Analysis در FMC جایی است که مهندس امنیت میتواند الگوهای حمله را کشف کند. استفاده از فیلترهای ترکیبی اهمیت بالایی دارد. برای مثال، اگر بخواهید حرکت جانبی در شبکه را بررسی کنید، میتوانید Destination Port برابر 445 را همراه با Intrusion Impact بالا فیلتر کنید و Application را روی SMB بگذارید.
در یک سازمان صنعتی، افزایش غیرعادی Sessionهای SMB مشاهده شد. بررسی دقیق نشان داد یک سیستم آلوده در حال اسکن شبکه داخلی است. اگر صرفاً بر اساس IP یا Port فیلتر میکردیم، کشف این رفتار بسیار زمانبر میشد.
تحلیل پیشرفته یعنی استفاده از چند شاخص همزمان و ساختن Context از دادهها.
یکی از قابلیتهای کمتر استفادهشده در FMC، Correlation Policy است. این قابلیت اجازه میدهد چند Event مرتبط بهصورت زنجیرهای تحلیل شوند.
فرض کنید در بازه پنج دقیقهای بیش از ده Authentication Failure ثبت شود و بلافاصله پس از آن یک File Event مشکوک رخ دهد. هرکدام از این رویدادها به تنهایی ممکن است هشدار بحرانی ایجاد نکنند، اما ترکیب آنها میتواند نشاندهنده حمله Credential Stuffing باشد.
در یک پروژه ISP، همین مدل Correlation منجر به شناسایی حملهای شد که در سطح Connection Event عادی به نظر میرسید. پیادهسازی Correlation حرفهای نیازمند شناخت رفتار نرمال شبکه است، در غیر این صورت Alertهای کاذب افزایش پیدا میکند.
FMC برای ذخیره Eventها از دیتابیس PostgreSQL استفاده میکند. در شبکههای پرترافیک، رشد سریع دیتابیس میتواند به افت عملکرد منجر شود.
بررسی وضعیت Disk و سرویسها از طریق دسترسی expert در FMC انجام میشود.
کاهش Retention Period، تنظیم Auto Purge و انتقال Logهای بلندمدت به SIEM خارجی از اقدامات حیاتی است.
در یکی از پروژههای Enterprise با ۱۲ میلیون Event روزانه، بدون اتصال به SIEM، FMC پس از دو ماه با کندی شدید مواجه شد. پس از انتقال لاگها به Splunk و نگهداری تنها ۳۰ روز داده در FMC، عملکرد به حالت پایدار بازگشت.
بخش Reporting در FMC معمولاً برای مدیران استفاده میشود، اما با طراحی مناسب میتواند ابزار فنی قدرتمندی باشد. هنگام ساخت Report، باید Data Source مناسب انتخاب شود و فیلدهایی مانند Intrusion Impact، Client Application، Policy Name و SHA256 فایلها لحاظ گردد.
در یکی از پروژههای دولتی، گزارش هفتگی شامل Top Risk Host طراحی شد. این گزارش بهجای نمایش صرف تعداد Connection، تمرکز را روی Hostهایی با بیشترین Intrusion Impact قرار داد. نتیجه این شد که تیم امنیتی توانست سه سیستم آلوده را پیش از گسترش حمله شناسایی کند.
گزارش حرفهای یعنی ارائه داده قابل اقدام، نه صرفاً نمودارهای زیبا.
در شبکههای بزرگ، FMC به تنهایی پاسخگوی نیاز تحلیلی بلندمدت نیست. ارسال Syslog به پلتفرمهایی مانند IBM QRadar یا Elastic Security امکان تحلیل عمیقتر و نگهداری طولانیمدت را فراهم میکند.
در یکی از پروژههای مالی، الگوی DNS Tunneling تنها زمانی کشف شد که SIEM با استفاده از تحلیل آماری، حجم غیرعادی Queryها را شناسایی کرد. FMC به تنهایی آن رفتار را به عنوان تهدید علامتگذاری نکرده بود.
یکپارچهسازی صحیح یعنی FMC بهعنوان منبع تولید Event و SIEM بهعنوان موتور تحلیل کلان عمل کند.
گاهی در شرایط Incident، GUI پاسخگو نیست و نیاز به بررسی لحظهای دارید. در FTD میتوان از diagnostic-cli استفاده کرد.
در یک پروژه بانکی، در زمان حمله DoS داخلی، بررسی Real-Time Connection Table از طریق CLI کمک کرد IP مهاجم در کمتر از ده دقیقه شناسایی و Block شود.
این تجربه نشان میدهد مانیتورینگ حرفهای فقط وابسته به داشبورد گرافیکی نیست.
یک چارچوب عملیاتی مناسب شامل تعریف سطح Logging بر اساس Criticality، تعیین Retention مناسب، تعریف Correlation Ruleهای کلیدی و طراحی گزارشهای دورهای است. بدون Baseline رفتاری، تشخیص تهدید دشوار خواهد بود. بنابراین در هفتههای ابتدایی راهاندازی، باید رفتار نرمال شبکه مستندسازی شود.
در پروژههای موفق، همیشه سه لایه دیده میشود. لایه اول مانیتورینگ روزانه Connection و Intrusion Event است. لایه دوم تحلیل هفتگی گزارشهای Risk محور است. لایه سوم تحلیل بلندمدت در SIEM برای کشف الگوهای پنهان است.
مانیتورینگ و گزارشگیری در Cisco Firepower Management Center یک فرآیند چندبعدی است که شامل طراحی Logging، تحلیل Event، پیادهسازی Correlation، مدیریت دیتابیس و یکپارچهسازی با SIEM میشود. تجربه پروژههای واقعی نشان میدهد تفاوت یک شبکه ایمن با شبکهای که فقط ظاهراً امن است، دقیقاً در کیفیت مانیتورینگ مشخص میشود.
اگر این فرآیند بهدرستی طراحی شود، FMC میتواند دیدی عمیق، عملیاتی و قابل اتکا از وضعیت امنیتی شبکه ارائه دهد. در غیر این صورت، یا با سیل Alertهای کاذب مواجه خواهید شد یا تهدیدات واقعی در میان انبوه لاگها پنهان میشوند.
پیادهسازی مانیتورینگ پیشرفته در FMC نیازمند تجربه عملی در پروژههای بزرگ است. بسیاری از چالشها مانند افت Performance، طراحی Correlation دقیق، بهینهسازی Retention و اتصال اصولی به SIEM در مستندات رسمی بهصورت تئوری مطرح شدهاند، اما اجرای صحیح آنها نیازمند تجربه میدانی است.
وینو سرور با تجربه عملی در طراحی و بهینهسازی زیرساختهای مبتنی بر Firepower در سازمانهای Enterprise و دیتاسنترهای پرترافیک، میتواند معماری مانیتورینگ شما را به سطحی پایدار و حرفهای برساند. اگر هدف شما تنها نصب FMC نیست بلکه ایجاد یک سیستم مانیتورینگ تحلیلی، دقیق و قابل اتکا است، وینو سرور میتواند به عنوان یک مرجع تخصصی در کنار تیم فنی شما قرار گیرد و راهکارهایی مبتنی بر تجربه واقعی پروژه ارائه دهد.
وینو سرور، اولین استارتاپ ارائه تجهیزات و سیستم های سخت افزاری، به صورت مستقیم از تولید کننده به مصرف کننده است. همواره تلاش مجموعه بر این اصل استوار بوده است تا مشتریان بتوانند بهترین سیستم را برای پروژه خود انتخاب کرده و با مناسبترین قیمت، آن را تهیه کنند. تیم وینو سرور، همواره سعی میکند تا جامعترین خدمات را به مشتریان ارائه دهد تا خرید را برای شما به کاری لذتبخش و آسان تبدیل کند.
مطلع شدن از پست های جدید
میخواهم اولین نفری باشم که از مقالههایی که در وینو سرور منتشر میشود، آگاه شوم.
