Local-in Policy در FortiGate 7.6 چیست و چطور باید آن را طراحی کنیم؟

مروری بر این مقاله

1. Local-in Traffic چیست؟
2. Local-in Policy چه تفاوتی با Firewall Policy دارد؟
3. چه سرویس‌هایی با Local-in Policy کنترل می‌شوند؟
4. Local-in Policy، Interface Administrative Access و Trusted Host چه فرقی دارند؟
5. تغییرات و قابلیت‌های مهم FortiOS 7.6
6. روش طراحی امن Local-in Policy
7. سناریوهای کاربردی
8. مراحل GUI در FortiOS 7.6
9. نمونه CLIهای کاربردی
10. Logging و عیب‌یابی
11. Best Practice
12. چک‌لیست پیاده‌سازی

1. Local-in Traffic چیست؟

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

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 روی Administrator و 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 و IPv6 Local-In Policy تفکیک قائل شد و Ruleهای مربوط به هرکدام را جداگانه ساخت.

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

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

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 شده Drop می‌شود.

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

یکی از قابلیت‌های مهم، امکان استفاده از Internet Service به‌عنوان Source در Local-in Policy است. این موضوع برای سناریوهایی مثل Block کردن منابع 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ها بسازید. اگر فقط Rule Allow داشته باشید ولی Deny نهایی ننویسید، ممکن است بسته به وضعیت Administrative Access و Ruleهای موجود، دسترسی ناخواسته همچنان برقرار بماند.

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

ریسک Interface داخلی با Interface اینترنتی یکسان نیست. روی WAN بهتر است هیچ دسترسی مدیریتی باز نباشد. اگر مجبور به باز کردن هستید، Source باید کاملاً محدود باشد. روی Management Interface داخلی هم بهتر است فقط Subnet ادمین‌ها، Jump Server یا سامانه مانیتورینگ مجاز باشد.

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

برای HTTPS، SSH، PING، SNMP و VPN بهتر است Ruleهای جدا داشته باشید. این کار باعث می‌شود Logها واضح‌تر شوند، Troubleshooting ساده‌تر باشد و در زمان تغییرات، یک سرویس اشتباهی باز یا بسته نشود.

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

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

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

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

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

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

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

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

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

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

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

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

سناریوی پنجم: استفاده از ISDB برای Block کردن منابع مخرب

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

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

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

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

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

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 255.255.255.0
    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 255.255.255.255
    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

در FortiOS 7.6.1، Fortinet برای منابع شناخته‌شده مخرب یک Default Local-in Policy معرفی کرده است. اگر در سناریوی شما این Rule وجود ندارد و نسخه شما از 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

برای اینکه Logها به‌صورت دقیق بر اساس Local-in Policy ثبت شوند، می‌توان Logging را در Global Setting فعال کرد و سپس روی Ruleها Log را Enable کرد.

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

show firewall local-in-policy
show firewall local-in-policy6

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

یکی از اشتباهات رایج این است که Local-in Policy نوشته می‌شود، اما Log کافی برای بررسی اثر آن فعال نیست. در FortiOS 7.6 می‌توان Local Traffic Logging را Global یا Per Policy تنظیم کرد. برای سناریوهای امنیتی، Per Policy معمولاً دید دقیق‌تری می‌دهد.

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

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

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

اگر ترافیکی که باید Block شود همچنان عبور می‌کند، یا ترافیکی که باید Allow شود Drop می‌شود، می‌توان از Debug Flow استفاده کرد. در خروجی Fortinet، Drop شدن توسط Local-in Policy معمولاً با عبارتی مشابه زیر دیده می‌شود:

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

در خروجی Debug ممکن است عبارتی شبیه این دیده شود:

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های جدا بنویسید.
• Ruleهای Allow محدود را بالاتر و Ruleهای Deny عمومی را پایین‌تر قرار دهید.
• برای سرویس‌های حساس، Log Deny را فعال کنید.
• برای SNMP فقط IP سرورهای مانیتورینگ را مجاز کنید.
• برای IPsec VPN فقط IP Peerهای شناخته‌شده را مجاز کنید، اگر سناریو اجازه می‌دهد.
• برای منابع شناخته‌شده مخرب، استفاده از ISDB Source را بررسی کنید.
• بعد از تغییرات، از یک مسیر مدیریتی جایگزین یا Console مطمئن باشید.
• بعد از Upgrade FortiOS، Local-in Policyها، Logging و دسترسی‌های Interface را دوباره بررسی کنید.

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