ترتیب Ruleها در Cisco Firepower؛ وقتی Policy درست است اما Match اشتباه می‌شود

در Access Control Policy فایرپاور، گاهی rule از نظر محتوا درست است اما به‌خاطر ترتیب قرارگیری یا match شدن rule بالاتر، هیچ‌وقت به ترافیک واقعی نمی‌رسد. نتیجه این می‌شود که تیم چند بار object، port یا action را بررسی می‌کند، در حالی که مشکل اصلی مسیر تصمیم‌گیری policy است.

بررسی hit count، log، سایه انداختن ruleها و ترتیب exceptionها باید قبل از هر تغییر انجام شود. این موضوع کنار صفحه Cisco Firepower و مانیتورینگ و پشتیبانی امنیت شبکه مهم است، چون policy بدون مشاهده‌پذیری و تحلیل رفتار واقعی فقط روی کاغذ قابل دفاع است.

سناریوی واقعی مسئله

سناریوی معمول این است که تیم شبکه یک تغییر ظاهراً ساده می‌دهد: یک policy اضافه می‌شود، یک interface جابه‌جا می‌شود، یک سرویس پشت load balancer قرار می‌گیرد، یا یک مسیر مانیتورینگ/احراز هویت فعال می‌شود. در همان لحظه شاید همه چیز سالم به نظر برسد، اما چند ساعت بعد کاربر می‌گوید بخشی از سرویس کند شده یا بعضی connectionها fail می‌شوند. اینجا اگر فقط به آخرین تغییر نگاه کنیم، احتمالاً علت اصلی را از دست می‌دهیم.

در تحلیل ترتیب ruleها و hit count در Access Control Policy فایرپاور باید مسیر داده را مرحله به مرحله دید. اول باید معلوم شود packet یا request از کجا وارد می‌شود، با چه identity یا contextی شناخته می‌شود، کدام rule روی آن match می‌شود، بعد از تصمیم امنیتی به کجا می‌رود، و در نهایت سمت مقصد چه پاسخی می‌دهد. این نگاه ساده است، اما جلوی بیشتر عیب‌یابی‌های پراکنده و حدسی را می‌گیرد.

نشانه مهم در این سناریو معمولاً اجازه یا block غیرمنتظره با وجود اینکه rule ظاهراً درست در policy وجود دارد است. این نشانه به‌تنهایی حکم قطعی نمی‌دهد، ولی جهت بررسی را مشخص می‌کند. اگر نشانه را درست بخوانیم، لازم نیست ده‌ها گزینه را همزمان تغییر بدهیم. تغییر همزمان چند چیز، بدترین دشمن عیب‌یابی در شبکه production است.

قبل از تغییر چه چیزهایی باید ثبت شود؟

قبل از هر اصلاح، snapshot عملیاتی لازم است. منظور فقط backup گرفتن از config نیست. باید بدانیم وضعیت sessionها، hit countها، logها، route table، objectها، certificateها و وضعیت health check در همان لحظه چه بوده است. اگر بعداً تغییر جواب نداد، بدون این snapshot نمی‌شود دقیق برگشت یا فهمید مشکل از کجا شروع شده.

• hit count ruleهای نزدیک به هم
• zone و network object واقعی ترافیک
• pre-filter و ruleهای trust/block قبل از ACP
• زمان آخرین deploy و تفاوت running با candidate config

این موارد شاید بدیهی به نظر برسند، اما در عمل خیلی از downtimeها از همین جا شروع می‌شود: تغییر انجام شده، اما وضعیت قبل از تغییر ثبت نشده است. وقتی وضعیت قبلی نداریم، rollback هم فقط یک حدس خوش‌بینانه است.

روش عیب‌یابی مرحله‌ای

برای Cisco Firepower بهتر است عیب‌یابی را از ساده‌ترین لایه شروع کنیم. اول دسترسی پایه و مسیر را ببینیم، بعد سراغ policy و inspection برویم، بعد وابستگی‌های پیشرفته‌تر مثل profile، identity، certificate یا automation را بررسی کنیم. اگر از همان ابتدا سراغ گزینه‌های پیچیده برویم، احتمالاً یک مشکل ساده routing یا object اشتباه را نمی‌بینیم.

من در این نوع کار معمولاً سه سؤال ثابت می‌پرسم: آیا ترافیک به نقطه تصمیم می‌رسد؟ آیا rule درست match می‌شود؟ آیا بعد از تصمیم، مسیر برگشت و state درست است؟ همین سه سؤال برای بیشتر تجهیزات امنیتی و شبکه‌ای جواب می‌دهد، حتی اگر اسم featureها فرق کند.

FMC: Analysis > Connections > filter initiator/responder
ACP: inspect rule order and hit count
Deployment: compare pending changes before deploy

دستورها و خروجی‌ها باید در همان change record نگهداری شوند. اگر بعداً یک نفر دیگر بخواهد ادامه کار را بگیرد، نباید مجبور شود از صفر بفهمد چه چیزهایی بررسی شده است.

خطاهای رایج

• ساخت rule جدید به جای اصلاح rule سایه‌انداز
• اعتماد به اسم object بدون دیدن اعضا
• deploy نکردن تغییر بعد از اصلاح
• نادیده گرفتن prefilter policy

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

طراحی درست برای محیط production

در محیط production، اینکه rule جدید باید بالاتر از rule عمومی باشد، rule قبلی محدود شود یا objectها بازطراحی شوند باید از قبل مشخص باشد. یعنی تیم بداند اگر تست اول fail شد چه کاری می‌کند، اگر فقط بخشی از کاربران مشکل داشتند چه چیزی را جدا می‌کند، و اگر rollback لازم شد دقیقاً کدام object یا policy برمی‌گردد. طراحی خوب فقط دیاگرام نیست؛ طراحی خوب یعنی تصمیم‌های روز حادثه از قبل آماده باشند.

برای تحلیل ترتیب ruleها و hit count در Access Control Policy فایرپاور بهتر است naming هم جدی گرفته شود. اسم object، rule، profile و monitor باید طوری باشد که شش ماه بعد هم قابل فهم باشد. اسم‌های کوتاه و مبهم شاید زمان ایجاد سریع‌تر باشند، اما هزینه عیب‌یابی را بالا می‌برند. وقتی policy زیاد می‌شود، naming ضعیف خودش به یک ریسک امنیتی تبدیل می‌شود.

موضوع دیگر logging است. لاگ زیاد بدون معنا کمک نمی‌کند؛ لاگ کم هم تیم را کور می‌کند. باید مشخص باشد برای چه decisionهایی log لازم داریم، کدام logها فقط noise تولید می‌کنند، و کدام رویدادها باید به مانیتورینگ یا SIEM بروند. در Cisco Firepower این تنظیم اگر درست انجام شود، هم troubleshooting را سریع‌تر می‌کند و هم ردپای تغییرات را نگه می‌دارد.

چک‌لیست اجرا

1. packet را به zone و object واقعی تبدیل کن
2. ruleهای بالاتر را از نظر overlap ببین
3. hit count و event را کنار هم بررسی کن
4. تغییر را با توضیح دقیق deploy کن
5. بعد از deploy، connection event همان flow را چک کن

این چک‌لیست جای تجربه را نمی‌گیرد، ولی جلوی بی‌نظمی را می‌گیرد. تجربه زمانی ارزش دارد که به روش تبدیل شود؛ وگرنه هر بار باید همان اشتباه‌ها را دوباره کشف کنیم.

تحویل کار به تیم بعدی

در Firepower، policy سالم یعنی کسی بتواند بفهمد چرا یک ترافیک match شده است. اگر فقط بگوییم rule ساختیم، ولی ترتیب و overlap را ننویسیم، کار نیمه‌تمام است.

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

اگر این موضوع در شبکه شما درگیر چند محصول یا چند تیم است، بهتر است قبل از تغییر نهایی یک جدول مسئولیت هم داشته باشید: مالک policy، مالک route، مالک application، مالک certificate، و کسی که decision نهایی rollback را می‌گیرد. نبودن همین مالکیت‌ها معمولاً زمان حل مشکل را چند برابر می‌کند.