Local-in Policy در FortiGate: طراحی امن و مدیریت سرویس‌های داخلی

Local-in Policy در FortiGate: طراحی امن و مدیریت سرویس‌های داخلی

در FortiOS 7.6، Local-in Policy برای کنترل ترافیکی استفاده می‌شود که به Interface‌های FortiGate می‌رسد؛ مانند HTTPS، SSH، PING، SNMP، IKE، SSL VPN و سایر سرویس‌هایی که روی FortiGate پاسخ می‌دهند. بنابراین اگر FortiGate شما در مرز شبکه قرار دارد یا Administrative Access روی Interfaceها فعال است، طراحی صحیح Local-in Policy یکی از ستون‌های Hardening به حساب می‌آید.

1. Local-in Traffic چیست؟

Local-in Traffic به ترافیک گفته می‌شود که مقصد آن خود FortiGate است، نه شبکه پشت FortiGate. برای مثال وقتی از خارج به IP یکی از Interfaceهای FortiGate با HTTPS وصل می‌شود، این ترافیک به FortiGate می‌رسد. وقتی یک سیستم به Interface فایروال Ping می‌زند، یا وقتی FortiGate را مانیتور می‌کند، یا وقتی یک مذاکره IKE برای IPsec VPN انجام می‌شود، همه این‌ها نمونه‌هایی از Local-in Traffic هستند.

نکتهSecurity Profileها مانند IPS، Antivirus و Web Filter برای ترافیکی هستند که از FortiGate عبور می‌کند. اما Local-in Policy برای ترافیک‌هایی است که به Interface‌های FortiGate می‌رسد و قرار نیست از فایروال عبور کند.

2. تفاوت Local-in Policy با Firewall Policy معمولی

Firewall Policy معمولی برای کنترل ترافیک Transit استفاده می‌شود؛ یعنی ترافیکی که از یک Interface وارد می‌شود و از Interface دیگری خارج می‌شود. اما Local-in Policy برای کنترل ترافیکی است که Destination آن FortiGate Interface است. همین تفاوت باعث می‌شود که نوشتن یک Firewall Policy معمولی برای Block کردن دسترسی به GUI یا SSH خود FortiGate کافی نباشد.

3. چه سرویس‌هایی با Local-in Policy کنترل می‌شوند؟

هر سرویسی که روی FortiGate پاسخ می‌دهد می‌تواند در Local-in Policy گنجانده شود. بسته به سناریو، این خدمات می‌تواند مدیریتی، مانیتورینگ یا VPN باشد.

4. Local-in Policy، Interface Administrative Access و Trusted Host چه فرقی دارند؟

برای حفاظت از دسترسی به FortiGate، سه لایه اصلی وجود دارد: Administrative Access روی Interface، Trusted Host برای مدیران و Local-in Policy. این سه مکمل یکدیگرند و به‌طور کامل جایگزین نیستند.

هشدار: اگر روی Interface بیرونی FortiGate دسترسی HTTPS یا SSH فعال است، به Firewall Policy معمولی تکیه نکنید. ترافیک به خود IP فایروال باید با Interface Administrative Access، Trusted Host و Local-in Policy کنترل شود.

5. قابلیت‌های مهم FortiOS 7.6 برای Local-in Policy

در FortiOS 7.6، Fortinet چند قابلیت مهم را برای Local-in Policy برجسته کرده است تا طراحی امن‌تر و عیب‌یابی دقیق‌تری فراهم شود.

5.1 پشتیبانی GUI برای ساخت Local-in Policy

در FortiOS 7.6 امکان ساخت و ویرایش Local-in Policy از طریق GUI وجود دارد. در GUI می‌توان بین Local-In Policy برای IPv4 و Local-In Policy برای IPv6 تفکیک قائل شد و Ruleهای مربوط به هرکدام را جدا ساخت.

Policy & Objects > Local-In Policy

5.2 Default Local-in Policy برای منابع مخرب

در FortiOS 7.6.1، یک Default Local-in Policy برای افزایش امنیت اضافه شده است که از ISDB برای منابعی مانند Malicious-Malicious.Server، Tor-Exit.Node و Tor-Relay.Node استفاده می‌کند. هدف این Rule جلوگیری از دسترسی منابع شناخته‌شده مخرب به Interfaceهای FortiGate روی هر سرویس و پورت است.

نکتهاین Rule برای کارخانه یا VDOM جدید اضافه می‌شود. برای FortiOSهایی که ISDB را به‌عنوان Source در Local-in Policy پشتیبانی می‌کنند، می‌توان این Rule را به‌صورت دستی اضافه کرد.

5.3 Logging به‌صورت Per Policy

در FortiOS 7.6، می‌توان Logging مربوط به Local-in Traffic را دقیق‌تر و به‌صورت Per Policy فعال کرد. این قابلیت برای عیب‌یابی و مستندسازی تلاش‌های دسترسی غیرمجاز و حملات به Management Plane بسیار کاربردی است.

5.4 Virtual Patching روی Local-in Management Interface

در Local-in Policy می‌توان از Virtual Patching برای کاهش ریسک آسیب‌پذیری‌هایی که خود FortiGate را هدف می‌گیرند استفاده کرد. در این حالت Ruleهای Vulnerability روی Local-in Traffic برای یک Interface مشخص بررسی می‌شوند و ترافیک Match شده Dropped می‌شود.

5.5 استفاده از Internet Service به‌عنوان Source

یکی از قابلیت‌های مهم، امکان استفاده از Internet Service به‌عنوان Source در Local-in Policy است. این موضوع برای سناریوهایی مانند بلاک کردن منابع Tor، منابع Malicious یا سرویس‌های مشخص‌شده در ISDB کاربرد دارد.

6. روش طراحی امن Local-in Policy

طراحی Local-in Policy با دید Management Plane Protection انجام می‌شود. هدف صرفاً نوشتن یک Rule نیست، بلکه مشخص کردن دقیق اینکه چه کسی، از کدام Interface، به کدام سرویس FortiGate دسترسی پیدا کند است.

اصل اول: اول Allowهای محدود، بعد Denyهای عمومی

برای سرویس‌هایی مانند HTTPS، SSH، SNMP و PING بهتر است ابتدا Sourceهای مجاز را Allow کنید و سپس یک Rule عمومی برای Deny کردن Sourceهای دیگر اضافه کنید. داشتن فقط Allow به‌تنهایی ممکن است بسته به وضعیت Administrative Access و Ruleهای موجود، منجر به دسترسی ناخواسته شود.

اصل دوم: برای هر Interface جدا فکر کنید

ریسک‌های Interface داخلی و Interface اینترنتی یکسان نیستند. روی WAN دسترسی مدیریتی باز نکرده یا محدود به منابع معتبر باشد. روی Interfaceهای مدیریتی داخلی هم بهتر است تنها Subnet ادمین‌ها یا سامانه‌های مانیتورینگ مجاز باشند.

اصل سوم: سرویس‌ها را جدا کنید

برای HTTPS، SSH، PING، SNMP و VPN، Ruleهای جداگانه ایجاد کنید تا Logها واضح‌تر باشند و Troubleshooting ساده‌تر شود و از باز یا بسته شدن ناخواسته سرویس‌ها جلوگیری شود.

اصل چهارم: Local-in Policy جایگزین Hardening نیست

Local-in Policy باید هم‌زمان با اقداماتی مانند غیرفعال‌سازی سرویس‌های غیرضروری روی Interface، تغییر پورت‌های مدیریتی در صورت نیاز، استفاده از Trusted Host، فعال‌سازی MFA برای ادمین‌ها و به‌روزرسانی FortiOS استفاده شود.

7. سناریوهای کاربردی

سناریو 1: محدود کردن GUI و SSH فقط به شبکه ادمین‌ها

FortiGate روی Interface مدیریتی یا داخلی به HTTPS و SSH پاسخ می‌دهد، اما تنها Subnet ادمین‌ها مجاز است به آن وصل شود و سایر Sourceها Deny شوند.

• Source مجاز: Subnet ادمین یا Jump Server
• Service‌های مجاز: HTTPS و SSH
• Action برای Source مجاز: Accept
• Action برای سایر Sourceها: Deny
• Logging: برای Deny حتما فعال شود

سناریو 2: جلوگیری از Ping به Interface اینترنتی

اگر Ping روی Interface اینترنتی فعال باشد، FortiGate برای اسکنرها و مهاجمان قابل شناسایی‌تر خواهد بود. می‌توان Ping را برای همه Sourceها Deny کرد یا فقط برای Sourceهای مانیتورینگ مجاز نگه داشت.

سناریو 3: محدود کردن SNMP فقط به سرور مانیتورینگ

SNMP معمولاً برای مانیتورینگ وضعیت FortiGate استفاده می‌شود، اما باز بودن SNMP برای همه Sourceها می‌تواند منجر به افشای اطلاعات مدیریتی شود. بهتر است فقط IP سرور مانیتورینگ دسترسی داشته باشد.

سناریو 4: محدود کردن IKE/IPsec به Peerهای مشخص

اگر FortiGate نقش VPN Gateway دارد، ترافیک مذاکره VPN باید فقط از IP Peerهای معتبر مجاز باشد تا تلاش‌های ناخواسته کاهش یابد.

سناریو 5: استفاده از ISDB برای بلاک منابع مخرب

برای منابع شناخته‌شده مخرب مانند Tor Exit Node یا Malicious Serverها، می‌توان از ISDB در Local-in Policy استفاده کرد تا قبل از رسیدن به سرویس‌های FortiGate، ترافیک آن‌ها Drop شود.

8. مراحل GUI در FortiOS 7.6

برای ساخت Local-in Policy در FortiOS 7.6 از مسیر زیر استفاده کنید

Policy & Objects > Local-In Policy

مراحل کلی به شکل زیر است

1. ابتدا Address Object مربوط به Source مجاز را بسازید.
2. وارد بخش Local-In Policy شوید.
3. برای IPv4 از تب Local-In Policy و برای IPv6 از تب IPv6 Local-In Policy استفاده کنید.
4. Interface موردنظر را انتخاب کنید.
5. Source، Destination، Schedule و Service را مشخص کنید.
6. Action را روی Accept یا Deny بگذارید.
7. برای Ruleهای حساس، Logging را فعال کنید.

نکته مهمقبل از اعمال Ruleهای Deny روی دسترسی مدیریتی، حتماً یک Session مدیریتی جایگزین یا دسترسی کنسول داشته باشید. اشتباه در Local-in Policy می‌تواند باعث قطع دسترسی ادمین به FortiGate شود.

9. نمونه CLIهای کاربردی

9.1 ساخت Address Object برای شبکه ادمین‌ها

در این مثال، شبکه ادمین‌ها برابر با 10.10.10.0/24 در نظر گرفته شده است.

config firewall address edit "ADMINS_10.10.10.0_24" set subnet 10.10.10.0/24 next end

9.2 Allow کردن HTTPS و SSH فقط از شبکه ادمین‌ها

این Rule اجازه می‌دهد فقط شبکه ادمین‌ها روی Interface مشخص‌شده به HTTPS و SSH خود FortiGate وصل شوند.

config firewall local-in-policy edit 10 set intf "port1" set srcaddr "ADMINS_10.10.10.0_24" set dstaddr "all" set action accept set service "HTTPS" "SSH" set schedule "always" set logtraffic enable set comments "Allow admin access from trusted admin subnet" next end

9.3 Deny کردن HTTPS و SSH برای سایر Sourceها

بعد از Rule مجاز، یک Rule عمومی برای Deny کردن سایر Sourceها قرار می‌گیرد. این Rule باید بعد از Allow Rule قرار داشته باشد.

config firewall local-in-policy edit 20 set intf "port1" set srcaddr "all" set dstaddr "all" set action deny set service "HTTPS" "SSH" set schedule "always" set logtraffic enable set comments "Deny admin access from untrusted sources" next end

9.4 اجازه Ping فقط از سرور مانیتورینگ

در این مثال فقط یک IP مانیتورینگ اجازه Ping دارد و سایر Sourceها برای PING Deny می‌شوند.

config firewall address edit "MONITORING_10.20.20.10" set subnet 10.20.20.10/32 next end

config firewall local-in-policy edit 30 set intf "port1" set srcaddr "MONITORING_10.20.20.10" set dstaddr "all" set action accept set service "PING" set schedule "always" set logtraffic enable set comments "Allow ping from monitoring server" next edit 31 set intf "port1" set srcaddr "all" set dstaddr "all" set action deny set service "PING" set schedule "always" set logtraffic enable set comments "Deny ping from other sources" next end

9.5 اضافه کردن Default Local-in Policy برای منابع مخرب ISDB

اگر در سناریوی شما ISDB به‌عنوان Source پشتیبانی می‌شود، می‌توانید مشابه زیر اضافه کنید

config firewall local-in-policy edit 1 set intf "any" set dstaddr "all" set internet-service-src enable set internet-service-src-name "Malicious-Malicious.Server" "Tor-Exit.Node" "Tor-Relay.Node" set service "ALL" set schedule "always" set action deny set logtraffic enable set comments "Block known malicious sources to FortiGate local services" next end

9.6 فعال کردن Logging به‌صورت Per Policy

می‌توان Logging را به‌طور Per Policy فعال کرد و یا به شکل Global تنظیم نمود. برای فعال‌سازی Per Policy از این دستورات استفاده کنید

config log setting set local-in-policy-log enable end

config firewall local-in-policy edit 20 set logtraffic enable next end

9.7 بررسی Ruleها در CLI

config show firewall local-in-policy

config firewall local-in-policy6

10. Logging و عیب‌یابی Local-in Policy

یکی از اشتباهات رایج عدم وجود Logging کافی است. در FortiOS 7.6 می‌توان Local Traffic Logging را به صورت Global یا Per Policy فعال کرد. برای امنیت، Per Policy معمولاً روشن‌تر است.

Log & Report > Log Settings > Global Settings > Local traffic logging > Per policy

در CLI می‌توان از دستور زیر استفاده کرد

config log setting set local-in-policy-log enable end

عیب‌یابی با Debug Flow

اگر ترافیکی که باید Block شود عبور می‌کند یا ترافیک مجاز به درستی Allow نمی‌شود، از Debug Flow استفاده کنید. در خروجی، Dropped شدن معمولاً با عبارتی مشابه زیر نمایش داده می‌شود

diagnose debug reset diagnose debug flow filter addr 10.10.10.12 diagnose debug flow filter proto 1 diagnose debug enable diagnose debug flow trace start 10

نمونه خروجی ممکن است مشابه

fw_local_in_handler line=545 msg="iprope_in_check() check failed on policy 3, drop"

11. Best Practice برای Local-in Policy

• روی Interfaceهای اینترنتی تا حد امکان Administrative Access مانند HTTPS و SSH را بسته یا محدود کنید.
• در صورت نیاز، Source را با Local-in Policy و Trusted Host محدود کنید.
• برای HTTPS، SSH، SNMP، PING و VPN Ruleهای جدا بنویسید.
• Allowهای محدود را بالاتر و Denyهای عمومی را پایین‌تر قرار دهید.
• برای سرویس‌های حساس، لاگ Deny فعال باشد.
• SNMP را فقط از IPهای سرورهای مانیتورینگ مجاز کنید.
• IPsec VPN فقط با Peerهای معتبر مجاز باشد، در صورت امکان.
• ISDB را برای منابع مخرب بررسی کنید.
• بعد از تغییرات، از یک مسیر مدیریتی جایگزین یا کنسول مطمئن باشید.
• بعد از Upgrade FortiOS، Local-in Policyها، Logging و دسترسی‌های Interface را دوباره بررسی کنید.

12. چک‌لیست پیاده‌سازی Local-in Policy

برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمایپشتیبانی شبکهرا نیز مطالعه کنید.