فرض کنید تیم امنیت برای یک پروژه سه‌ماهه، دسترسی محدودی از یک شبکه مشخص به یک Server داخلی باز کرده است. پروژه تمام می‌شود، پیمانکار می‌رود، Application جابه‌جا می‌شود؛ اما Rule روی Firewall باقی می‌ماند. چند ماه بعد کسی دقیقاً به خاطر نمی‌آورد این Rule چرا ساخته شده، حذف آن چه اثری دارد و آیا هنوز Traffic واقعی از آن عبور می‌کند یا نه.

این وضعیت در شبکه‌های سازمانی کاملاً رایج است. Firewall Policy به‌مرور بزرگ‌تر می‌شود؛ Ruleهای موقت دائمی می‌شوند، Objectهای قدیمی باقی می‌مانند، Ruleهای Shadow یا Redundant روی هم جمع می‌شوند و تیم امنیت برای هر تغییر جدید باید یک Rule Base پیچیده‌تر را بررسی کند.

Firewall Rule Cleanup در ManageEngine Firewall Analyzer برای همین مسئله طراحی شده است: استفاده واقعی Ruleها را با Log و Policy تطبیق می‌دهد، Rule و Objectهای بلااستفاده را پیدا می‌کند، Anomalyهای Policy را نشان می‌دهد و قبل از اعمال Rule جدید، Impact آن را روی Rule Base موجود تحلیل می‌کند.

برای سازمانی که چند Firewall، چند Vendor یا محیط‌های شعب، Data Center و DMZ دارد، این قابلیت فقط یک ابزار مرتب‌سازی نیست؛ بخشی از Firewall Governance و کاهش Attack Surface است.

چرا Ruleهای قدیمی فقط «شلوغی» نیستند؟

یک Firewall Rule قدیمی ممکن است سال‌ها هیچ مشکلی ایجاد نکند؛ تا روزی که یک تغییر شبکه، یک IP Reuse، یک سرویس جدید یا یک مسیر متفاوت باعث شود همان Rule دوباره قابل استفاده شود.

مثلاً Rule زیر را در نظر بگیرید:

Source: 10.10.20.0/24 → Destination: 172.16.5.25 → TCP/8443 → Allow

اگر Application قدیمی روی 172.16.5.25 حذف شده باشد، ممکن است تیم تصور کند Rule هم بی‌خطر شده است. اما اگر بعداً IP به Server دیگری اختصاص پیدا کند، یک Rule فراموش‌شده می‌تواند دسترسی ناخواسته ایجاد کند.

به همین دلیل CISA در راهنمای Hardening شبکه توصیه می‌کند Configurationها به‌صورت منظم Audit شوند و تاریخ ایجاد یا تغییر Firewall Ruleها با Change Approvalهای سازمان تطبیق داده شود. هدف این است که Rule Base فقط مجموعه‌ای از تصمیم‌های تاریخی نباشد؛ هر Rule باید Owner، دلیل و وضعیت فعلی مشخص داشته باشد.

Firewall Analyzer برای Rule Cleanup چه داده‌ای استفاده می‌کند؟

Firewall Analyzer Ruleها و Policyهای Firewall را از Device دریافت می‌کند و آن‌ها را با Syslog و اطلاعات واقعی Traffic تطبیق می‌دهد. این تفاوت مهمی با یک Export ساده از Configuration دارد.

اگر فقط Rule Base را ببینیم، می‌دانیم چه چیزی تعریف شده است. وقتی Log هم اضافه شود، می‌توانیم بفهمیم چه چیزی واقعاً استفاده شده است.

در گزارش‌های Cleanup، Firewall Analyzer می‌تواند مواردی مانند این‌ها را مشخص کند:

• Unused Rules: Ruleهایی که در بازه بررسی Trigger نشده‌اند.
• Unused Objects: Objectهایی که در Policy وجود دارند اما استفاده مؤثری ندارند.
• Unassigned Interfaces: Interfaceهای تعریف‌شده‌ای که به Policy فعال مرتبط نیستند.
• Unassigned Objects: Objectهایی که به هیچ Rule یا Policy متصل نیستند.

مستندات رسمی ManageEngine تأکید می‌کند که Unused Rule Report بر اساس Ruleهای دریافت‌شده از Device و Rule Hitهای موجود در Syslog ساخته می‌شود. بنابراین کیفیت Log Collection روی اعتبار نتیجه اثر مستقیم دارد.

Rule بلااستفاده را فوراً حذف نکنید

یکی از خطرناک‌ترین برداشت‌ها این است که «Unused» را مساوی «بی‌ارزش» بدانیم.

Rule ممکن است در سی روز گذشته Hit نداشته باشد، اما برای Disaster Recovery، فرآیند پایان ماه، Backup فصلی یا Maintenance سالانه ساخته شده باشد. ممکن است فقط هنگام Failover استفاده شود یا مربوط به یک سرویس اضطراری باشد.

بنابراین Cleanup خوب سه سؤال دارد:

1. آیا Rule در بازه زمانی مناسب واقعاً استفاده نشده است؟
2. آیا Owner یا Change Record معتبر برای آن وجود دارد؟
3. اگر Rule حذف شود، چه سرویس یا Rule دیگری تحت تأثیر قرار می‌گیرد؟

هدف، حذف بیشترین تعداد Rule نیست؛ هدف، حذف Ruleهای بدون توجیه و بدون مصرف واقعی است.

Shadow Rule چیست و چرا باید آن را پیدا کنیم؟

Shadow Rule زمانی رخ می‌دهد که یک Rule قبلی تمام Traffic مربوط به Rule بعدی را Match کند و Rule بعدی عملاً هیچ‌وقت فرصت اجرا پیدا نکند.

مثلاً:

چون R1 زودتر بررسی می‌شود و Traffic موردنظر R2 را هم Allow می‌کند، R2 هرگز اجرا نمی‌شود. اگر Administrator تصور کند R2 دسترسی Host خاصی را مسدود کرده، Policy واقعی با تصور او متفاوت است.

Firewall Analyzer در Policy Anomaly Report چنین Shadowingهایی را مشخص می‌کند تا Rule قابل اصلاح، Reorder یا حذف باشد.

تفاوت Shadow، Redundant، Correlation و Generalization

برای Cleanup بهتر است نوع Anomaly را دقیق بدانیم. همه Ruleهای مشابه یک مسئله واحد نیستند.

این تحلیل مخصوصاً در Firewallهایی با چندصد یا چندهزار Rule ارزش دارد؛ جایی که بررسی دستی تمام Interactionها تقریباً غیرواقعی است.

Rule Impact Analysis؛ قبل از Push کردن Rule جدید

Cleanup فقط برای گذشته نیست. یک بخش مهم‌تر، جلوگیری از ایجاد Rule نامناسب جدید است.

Firewall Analyzer قابلیت Rule Impact Analysis دارد که Rule پیشنهادی را قبل از اعمال روی Rule Base فعلی بررسی می‌کند. این تحلیل می‌تواند موارد زیر را نشان دهد:

• Anomaly با Ruleهای موجود
• Rule Order نامناسب
• Destination Interface بیش از حد باز
• Service یا Port پرریسک
• IPهای Blacklisted
• Objectهای تکراری
• Overly Permissive Rule

یعنی به‌جای اینکه Rule را روی Production اعمال کنیم و بعد بفهمیم مسیر مهمی Block شده یا دسترسی اضافه باز شده، ابتدا Draft را در Context کل Policy بررسی می‌کنیم.

سناریو: درخواست باز کردن Port برای Vendor

فرض کنید Vendor یک سیستم صنعتی درخواست می‌دهد:

Allow Vendor-VPN → PLC-Gateway → TCP/443, TCP/22

در نگاه اول Request ساده است. اما قبل از Push کردن Rule، چند سؤال باید جواب داده شود:

• آیا Source دقیقاً Network اختصاصی Vendor است یا Any؟
• آیا SSH واقعاً لازم است؟
• آیا Destination فقط یک Gateway است یا Subnet کامل؟
• آیا Rule مشابهی از قبل وجود دارد؟
• آیا Rule جدید با Rule Deny موجود Shadow یا Correlate می‌شود؟
• آیا این دسترسی باید Expiry Date داشته باشد؟

Rule Impact Analysis می‌تواند بخش فنی این ارزیابی را قبل از Change Approval روشن کند. تیم امنیت سپس Change Record، Business Justification و مدت اعتبار را هم به تصمیم اضافه می‌کند.

Rule Expiry؛ Rule موقت نباید دائمی شود

یکی از مشکلات متداول این است که Temporary Rule در Ticket با عبارت «تا پایان پروژه» ثبت می‌شود، اما خود Firewall هیچ Reminder عملیاتی ایجاد نمی‌کند.

Firewall Analyzer برای Ruleهای Scheduleدار، Rule Expiry Notification Report دارد و می‌تواند Ruleهای Active، Expiring Soon، Expired و Recurring را نمایش دهد. این قابلیت برای دسترسی‌های Vendor، پروژه‌های موقت و Maintenance Windowها اهمیت زیادی دارد.

مدل پیشنهادی این است که هر Temporary Rule حداقل این اطلاعات را داشته باشد:

• Owner
• Change یا Request ID
• Business Reason
• Start Date
• Expiry Date
• Rollback/Removal Owner

اگر Rule فقط یک «Allow» بدون Lifecycle باشد، دیر یا زود به Technical Debt امنیتی تبدیل می‌شود.

Cleanup را با Change Management ترکیب کنید

Firewall Governance از خود Firewall شروع و تمام نمی‌شود. هر Rule باید بخشی از یک Change قابل‌ردیابی باشد.

CISA در توصیه‌های Hardening خود به Audit منظم Configuration و تطبیق Rule Creation/Modification با Change Approval اشاره می‌کند. در عمل می‌توان جریان زیر را طراحی کرد:

1. درخواست Rule در Service Desk ثبت شود.
2. Source، Destination، Service، Owner و Expiry مشخص شوند.
3. Security Review انجام شود.
4. Rule Impact Analysis اجرا شود.
5. Change تأیید شود.
6. Rule روی Firewall اعمال شود.
7. Log و Usage مانیتور شود.
8. در موعد مقرر Recertification یا Removal انجام شود.

اگر سازمان از ServiceDesk Plus استفاده می‌کند، این مدل می‌تواند Rule Change را از یک اقدام مستقل تیم Network به یک فرآیند قابل Audit تبدیل کند.

آخرین تغییرات Firewall Analyzer در ۲۰۲۶ چه می‌گویند؟

در Release Notes رسمی ManageEngine، Build 12.9.119 در ۲۲ ژوئیه ۲۰۲۶ بهبودهایی برای Rule Management و Compliance Reportهای وابسته به Syslog در محیط‌های با حجم بالای Syslog اضافه کرده است. این بهبود شامل گزارش‌هایی مانند Unused Rules، Rule Suggestion، Policy Fine-Tuning، Objects Usage و Unused Objects می‌شود.

در Build 12.9.100 در ۴ ژوئن ۲۰۲۶ نیز Security Rating، Baseline Rating و Regulatory Rating به Executive Summary و Policy Overview اضافه شده تا وضعیت سلامت Policy و Compliance بهتر دیده شود.

این تغییرات نشان می‌دهد جهت توسعه محصول فقط «Log Viewer» نیست؛ Firewall Analyzer به سمت ارزیابی Policy Health و Rule Governance عمیق‌تر حرکت کرده است.

قبل از Cleanup چه بازه زمانی انتخاب کنیم؟

هیچ بازه واحدی برای همه Ruleها مناسب نیست.

این اعداد Policy داخلی سازمان هستند، نه محدودیت خود محصول. نکته مهم این است که بازه Usage با ماهیت Business Process هماهنگ باشد.

Syslog ناقص می‌تواند گزارش Unused Rules را گمراه کند

ManageEngine در FAQ رسمی خود توضیح می‌دهد که تشخیص Unused Rule به Rule Hitهای موجود در Syslog وابسته است. اگر Log دریافت نشود یا Rule ID در Logها درست Parse نشود، Rule ممکن است به‌اشتباه Unused دیده شود.

بنابراین قبل از حذف گروهی Ruleها این موارد را کنترل کنید:

• Firewall واقعاً Syslog می‌فرستد.
• Log Source در Firewall Analyzer Healthy است.
• Rule Usage Report داده واقعی نشان می‌دهد.
• Time Range مناسب است.
• Device Rule Fetch از روش پشتیبانی‌شده انجام شده است.

برای طراحی معماری Log Collection در محیط‌های LAN، WAN و DMZ، مقاله Agentless یا Agent-based در EventLog Analyzer نیز می‌تواند دید خوبی درباره محدودیت‌های شبکه و جمع‌آوری Log بدهد.

Rule Cleanup چه ارتباطی با SIEM دارد؟

SIEM به شما می‌گوید چه Event یا رفتار مشکوکی رخ داده است. Firewall Rule Governance کمک می‌کند مسیرهای شبکه‌ای که مهاجم می‌تواند از آن‌ها استفاده کند، از ابتدا محدودتر و قابل‌کنترل‌تر باشند.

به همین دلیل Log Analysis و Policy Management مکمل یکدیگرند. برای معماری گسترده‌تر SIEM و Correlation می‌توانید صفحه ManageEngine Log360 مدانت را هم بررسی کنید.

در یک مدل بالغ:

• Firewall Analyzer روی Rule، Configuration، Traffic و Compliance تمرکز می‌کند.
• SIEM رویدادهای چندمنبعی را Correlate می‌کند.
• ITSM Change و Incident را مدیریت می‌کند.
• PAM دسترسی Administrator به Firewall را کنترل می‌کند.

این چهار لایه کنار هم، کنترل فنی و Governance را کامل‌تر می‌کنند.

Checklist عملی برای اولین Firewall Rule Cleanup

1. Firewallهای Scope را مشخص کنید.
2. Rule Fetch و Syslog Collection را Validate کنید.
3. Policy Overview را Baseline بگیرید.
4. Unused Rule Report را با بازه مناسب اجرا کنید.
5. Unused Objects و Unassigned Objects را جدا بررسی کنید.
6. Shadow و Redundant Ruleها را تحلیل کنید.
7. Ruleهای Any-to-Any و Overly Permissive را در اولویت Review قرار دهید.
8. هر Rule را با Owner و Change Record تطبیق دهید.
9. Ruleهای DR و Emergency را بدون Context حذف نکنید.
10. برای حذف یا تغییر Rule، Change رسمی بسازید.
11. قبل از تغییر Ruleهای مهم، Impact Analysis اجرا کنید.
12. پس از Change، Traffic و Incidentها را مانیتور کنید.
13. Ruleهای موقت را Expiryدار کنید.
14. Review دوره‌ای را به Calendar عملیاتی SOC/NOC اضافه کنید.

چه KPIهایی برای Firewall Governance مفیدند؟

این KPIها باعث می‌شوند پروژه Cleanup یک فعالیت یک‌باره نباشد؛ بلکه به برنامه مستمر بهبود Policy تبدیل شود.

Firewall Analyzer برای چه سازمانی بیشترین ارزش را دارد؟

اگر فقط یک Firewall کوچک با چند Rule دارید، بخشی از این کارها هنوز با Review دستی قابل انجام است. ارزش Firewall Analyzer زمانی بیشتر می‌شود که یکی یا چند مورد زیر وجود داشته باشد:

• چند Firewall از Vendorهای مختلف
• صدها یا هزاران Rule
• محیط شعب و Data Center
• DMZ و Segmentهای متعدد
• الزام ISO 27001، PCI DSS، NIST یا سایر Complianceها
• Rule Changeهای مکرر
• Vendor Access زیاد
• نیاز به Audit Trail و Change Tracking

در چنین محیطی Rule Governance دستی به‌سرعت پرهزینه و خطاپذیر می‌شود.

خرید لایسنس به‌تنهایی مسئله را حل نمی‌کند

ابزار زمانی ارزش می‌دهد که Scope، Log Collection، Change Process و Review Cycle درست طراحی شده باشند. مدانت علاوه بر استعلام و تأمین لایسنس ManageEngine، خدمات مشاوره، استقرار، آموزش و پشتیبانی را هم ارائه می‌کند.

برای برآورد لایسنس Firewall Analyzer و سایر محصولات ManageEngine می‌توانید از صفحه استعلام قیمت لایسنس محصولات ManageEngine استفاده کنید. اگر ابتدا نیاز به بررسی معماری و انتخاب Scope دارید، صفحه درخواست جلسه، دمو و پروپوزال مدانت مسیر مناسب‌تری است. جزئیات خدمات نگهداری نیز در برنامه‌های پشتیبانی مدانت آمده است.

نکات کلیدی

• Unused Rule را قبل از حذف با Business Context و Change History بررسی کنید.
• Shadow و Redundant Rule یک مفهوم واحد نیستند و اثر متفاوت دارند.
• Rule Impact Analysis را قبل از Push کردن Ruleهای حساس اجرا کنید.
• Temporary Rule باید Expiry و Owner مشخص داشته باشد.
• Syslog ناقص می‌تواند نتیجه Unused Rule Report را مخدوش کند.
• Cleanup باید دوره‌ای باشد، نه یک پروژه یک‌باره.
• هدف Rule کمتر نیست؛ هدف Policy قابل‌فهم‌تر، قابل‌Auditتر و کم‌ریسک‌تر است.

سخن پایانی

Firewall Rule Base در طول زمان مثل یک سیستم زنده تغییر می‌کند. پروژه‌ها می‌آیند و می‌روند، Serverها جابه‌جا می‌شوند، Vendorها دسترسی می‌گیرند، سرویس‌ها بازطراحی می‌شوند و اگر Rule Lifecycle مدیریت نشود، Policy قدیمی روی شبکه جدید باقی می‌ماند.

Firewall Analyzer با ترکیب Rule Usage، Syslog، Policy Anomaly، Rule Cleanup، Expiry Tracking و Impact Analysis کمک می‌کند این Technical Debt به یک فرآیند قابل‌اندازه‌گیری تبدیل شود.

اما اصل مهم همان است: هیچ Ruleی فقط به این دلیل که قدیمی یا Unused دیده می‌شود نباید کورکورانه حذف شود. Cleanup خوب یعنی داده فنی، Business Context و Change Governance کنار هم قرار بگیرند.

منابع

• ManageEngine Firewall Analyzer – Firewall Rule Cleanup
• ManageEngine Firewall Analyzer – Rule Impact Analysis
• ManageEngine Firewall Analyzer – Policy Anomalies
• ManageEngine Firewall Analyzer – Rule Expiry
• ManageEngine Firewall Analyzer – Release Notes
• CISA – Network Device Configuration Auditing Guidance