در Cisco Firepower همه تصمیمها داخل Access Control Policy گرفته نمیشود. Prefilter Policy قبل از ACP قرار میگیرد و برای بعضی نوعهای ترافیک تصمیم زودتر میگیرد: trust، block، analyze یا عبور سریعتر. اگر این لایه مستند نباشد، تیم فنی بعداً نمیفهمد چرا ترافیکی که انتظار inspect داشته از مسیر دیگری عبور کرده یا چرا Ruleهای ACP نتیجه مورد انتظار ندادهاند.
Prefilter چه مشکلی را حل میکند؟
در شبکههای بزرگ، بعضی جریانها حجم بالا دارند، بعضی tunnel هستند، بعضی برای دسترسی مدیریتی یا سرویسهای حساس باید سریع و قابل پیشبینی عبور کنند، و بعضی باید قبل از درگیر شدن با ruleهای پیچیدهتر فیلتر شوند. Prefilter کمک میکند این تصمیمها جدا از Rule Base اصلی نوشته شوند. اما همین جدا بودن اگر بدون طراحی باشد، به ابهام تبدیل میشود.
- ترافیک tunnel یا encapsulated که باید قبل از ACP دیده شود.
- مسیرهایی که قرار است fastpath یا trust شوند و نباید بیدلیل وارد inspection سنگین شوند.
- ترافیکهای پرحجم که باید با منطق روشن از مسیر مناسب عبور کنند.
- سناریوهایی که block زودهنگام از شلوغ شدن ACP جلوگیری میکند.
ریسک طراحی بد
ریسک اصلی این است که Prefilter به محلی برای bypass کردن مسئله تبدیل شود. مثلاً برای حل یک مشکل فوری، ترافیک trust میشود و بعد فراموش میشود. چند ماه بعد، تیم امنیت فکر میکند IPS یا File Policy روی آن مسیر فعال است، در حالی که تصمیم قبل از ACP گرفته شده است. اینجا گزارشگیری و مستندسازی rule اهمیت زیادی دارد.
ترتیب پیشنهادی برای بازبینی
اول لیست ruleهای Prefilter را با هدف فنی هر rule بخوانید. بعد مسیر ترافیکهای حساس را مشخص کنید: آیا قرار است inspect شوند یا فقط عبور کنند؟ سپس ACP، IPS Policy، SSL Policy و Logging را کنار Prefilter بگذارید. اگر rule مالک، دلیل و تاریخ بازبینی ندارد، باید مشکوک تلقی شود.
این موضوع مکمل طراحی Access Control Policy در Cisco Firepower، بازبینی Ruleها در Firepower و عیبیابی Deploy در FMC/FTD است. اگر صفحه اصلی شاخه را میخواهید، Cisco Firepower نقشه کلی محتوا را دارد.
Prefilter را مثل یک استثنای دائمی رها نکنید
Prefilter وقتی درست استفاده شود، Rule Base را تمیزتر و پردازش را قابل پیشبینیتر میکند. اما اگر هر مشکل فوری با trust یا fastpath حل شود، بعد از مدتی بخشی از ترافیکهای مهم خارج از کنترلهای اصلی امنیتی حرکت میکنند. این موضوع در گزارشهای امنیتی خطرناک است، چون ممکن است تیم فکر کند IPS، file policy یا logging روی مسیری فعال است که عملاً قبل از ACP تصمیم گرفته شده است.
برای هر rule در Prefilter باید دلیل فنی مشخص باشد. مثلاً ترافیک tunnel، مسیر backup، سرویس مانیتورینگ، یا جریان پرحجمی که inspect کامل آن توجیه ندارد. اگر دلیل فقط «مشکل داشتیم و اینطوری درست شد» باشد، آن rule باید وارد بازبینی شود. Firepower برای محیط عملیاتی ابزار قدرتمندی است، ولی فقط وقتی قابل دفاع میماند که مسیر تصمیمگیری آن مستند باشد.
گزارش قابل استفاده از بازبینی Prefilter
- فهرست ruleهایی که قبل از ACP تصمیم میگیرند.
- دلیل فنی هر trust، block، analyze یا fastpath.
- مسیرهایی که logging کافی ندارند.
- ترافیکهایی که باید دوباره وارد inspection شوند.
- تغییرهای پیشنهادی با ریسک، تست و rollback مشخص.
اگر Prefilter تمیز شود، ACP هم قابل فهمتر میشود. در غیر این صورت، تیم مجبور است برای هر رفتار عجیب بین چند لایه policy حدس بزند و این دقیقاً همان چیزی است که در زمان حادثه یا قطعی سرویس نباید اتفاق بیفتد.
منبع فنی
برای جزئیات مفهومی Prefilter، مستندات رسمی Cisco درباره Prefiltering در Secure Firewall Management مرجع مناسب است. در اجرا، رفتار دقیق به نسخه FMC/FTD و policyهای فعال بستگی دارد.
Prefilter را مثل میانبر خطرناک نبینید
در Cisco Firepower، Prefilter Policy قبل از Access Control Policy تصمیم میگیرد بخشی از ترافیک چطور عبور کند یا اصلاً وارد inspection عمیق شود یا نه. همین جایگاه باعث میشود طراحی آن حساس باشد. اگر ruleهای prefilter بیدقت نوشته شوند، ممکن است ترافیکی که باید بررسی شود از مسیر fastpath عبور کند، یا برعکس، ترافیک سنگین و کمریسک بیدلیل وارد inspection کامل شود و روی performance اثر بگذارد.
طراحی کمریسک قبل از Deploy
برای طراحی عملی، اول ترافیک را دستهبندی کنید: tunnelها، جریانهای شناختهشده و کمریسک، ترافیکهایی که باید trust شوند، و ترافیکهایی که حتماً باید به Access Control و IPS برسند. هر rule باید دلیل روشن داشته باشد و با objectهای دقیق نوشته شود؛ استفاده از any/any در Prefilter معمولاً نشانه طراحی ضعیف است مگر در سناریوی بسیار کنترلشده و مستند. قبل از deploy، hit count و log policy را بررسی کنید تا مطمئن شوید rule جدید ترافیک بیش از حد نمیگیرد.
بعد از اعمال تغییر، فقط به موفق بودن deploy اکتفا نکنید. باید connection events، load دستگاه، خطاهای application detection و مسیر rule match بررسی شود. اگر هدف کاهش بار است، عدد قبل و بعد لازم دارید. اگر هدف عبور tunnel است، باید مطمئن شوید ترافیک حساس ناخواسته از inspection خارج نشده است. Prefilter خوب، طراحی Access Control را سادهتر میکند؛ Prefilter بد، دید امنیتی را کور میکند.
