Local-in Policy در FortiGate

مدت زمان مطالعه:

۲۱ خرداد ۱۴۰۵

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

وقتی درباره Policy در FortiGate صحبت می‌کنیم، معمولاً ذهن ادمین‌ها به سمت Firewall Policyهای معمولی می‌رود؛ همان Policyهایی که ترافیک کاربران، سرورها و اینترنت را از یک Interface به Interface دیگر عبور می‌دهند. اما بخشی از ترافیک اصلاً قرار نیست از FortiGate عبور کند؛ بلکه مقصد نهایی آن خود FortiGate است. اینجاست که Local-in Policy اهمیت پیدا می‌کند.

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

این مقاله بر اساس مستندات رسمی Fortinet برای FortiOS 7.6 نوشته شده و هدف آن این است که ادمین بداند Local-in Policy دقیقاً چه تفاوتی با Firewall Policy دارد، کجا باید استفاده شود، چطور باید Ruleها را مرتب کند، چه Logهایی بگیرد و چه اشتباهاتی می‌تواند باعث باز ماندن دسترسی به خود FortiGate شود.

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

Local-in Traffic چیست؟
Local-in Policy چه تفاوتی با Firewall Policy دارد؟
چه سرویس‌هایی با Local-in Policy کنترل می‌شوند؟
Local-in Policy، Interface Administrative Access و Trusted Host چه فرقی دارند؟
تغییرات و قابلیت‌های مهم FortiOS 7.6
روش طراحی امن Local-in Policy
سناریوهای کاربردی
مراحل GUI در FortiOS 7.6
نمونه CLIهای کاربردی
Logging و عیب‌یابی
Best Practice
چک‌لیست پیاده‌سازی

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 هستند.

نکته: 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 کافی نباشد.

مورد	Firewall Policy	Local-in Policy
نوع ترافیک	ترافیک عبوری از FortiGate	ترافیک ورودی به خود FortiGate
مثال	کاربر داخلی به اینترنت	اتصال SSH به IP Interface فایروال
کاربرد اصلی	کنترل ارتباط بین شبکه‌ها	محافظت از سرویس‌های خود FortiGate
Security Profile	قابل اعمال است	مثل Firewall Policyهای معمولی استفاده نمی‌شود
اهمیت امنیتی	محافظت از شبکه‌ها و سرویس‌ها	محافظت از Management Plane و سرویس‌های فایروال

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

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

سرویس	کاربرد	ریسک در صورت باز بودن روی Interface عمومی
HTTPS	دسترسی به GUI مدیریتی	افزایش سطح حمله روی صفحه Login و Management Plane
SSH	مدیریت CLI	Brute Force، اسکن، تلاش برای Exploit
PING	تست Reachability	شناسایی IP فعال و کمک به Reconnaissance
SNMP	مانیتورینگ	نشت اطلاعات مدیریتی یا سوءاستفاده از Community/String اشتباه
IKE/IPsec	راه‌اندازی VPN	اسکن، مذاکره ناخواسته و تلاش برای حمله به VPN Gateway
SSL VPN	دسترسی ریموت کاربران	Brute Force، Credential Stuffing و سوءاستفاده از آسیب‌پذیری‌ها

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

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

مکانیزم	محل تنظیم	نقش	محدودیت
Administrative Access	Interface Settings	مشخص می‌کند FortiGate روی آن Interface به چه سرویس‌هایی مثل HTTPS، SSH یا PING پاسخ دهد	برای کنترل دقیق Source، Service و Rule Order کافی نیست
Trusted Host	Administrator Account	مشخص می‌کند یک Admin از چه Sourceهایی اجازه Login داشته باشد	برای همه مدل‌های احراز هویت مثل SSO به‌صورت مستقیم قابل اعمال نیست و قبل از رسیدن به مرحله Login، همه Local-in Traffic را پوشش نمی‌دهد
Local-in Policy	Policy & Objects	کنترل دقیق Source، Destination، Interface، Service، Schedule و Action برای ترافیک ورودی به خود FortiGate	اگر Ruleها درست مرتب نشوند یا Deny نهایی نوشته نشود، ممکن است دسترسی ناخواسته باقی بماند

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

Policy & Objects > Local-In Policy

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 روی هر سرویس و پورت است.

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

5.3 Logging به‌صورت Per Policy

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

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

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 از مسیر زیر استفاده کنید:

Policy & Objects > Local-In Policy

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

ابتدا 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 را فعال کنید.

نکته مهم: قبل از اعمال 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 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 معمولاً دید دقیق‌تری می‌دهد.

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 شود 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

مورد	وضعیت مطلوب
Interfaceهای اینترنتی	HTTPS و SSH روی WAN غیرفعال باشد یا فقط از Sourceهای مشخص مجاز باشد
Admin Access	Sourceهای مجاز با Address Object مشخص شده باشند
Trusted Host	برای ادمین‌های Local و REST API تنظیم شده باشد
Local-in Policy	Allowهای محدود و Denyهای عمومی برای سرویس‌های مدیریتی وجود داشته باشد
SNMP	فقط از IP سرورهای مانیتورینگ مجاز باشد
PING	روی WAN غیرفعال یا محدود به مانیتورینگ باشد
VPN	در صورت امکان فقط Peerها یا Sourceهای معتبر مجاز باشند
ISDB	Block منابع Malicious و Tor برای Local-in بررسی شده باشد
Logging	Local-in Policy Logging به‌صورت Per Policy یا Global فعال باشد
تست بعد از تغییر	با Source مجاز و غیرمجاز تست شده و نتیجه در Log بررسی شده باشد

پرسش و پاسخ

آیا Local-in Policy برای IPv6 هم وجود دارد؟

بله. در FortiOS 7.6، GUI تب جداگانه‌ای برای IPv6 Local-In Policy دارد و در CLI نیز از config firewall local-in-policy6 استفاده می‌شود.

آیا Local-in Policy به‌صورت پیش‌فرض Implicit Deny دارد؟

طبق مستندات Fortinet، برخلاف IPv4 Firewall Policy معمولی، Local-in Policy به‌صورت پیش‌فرض همان مدل Implicit Deny را ندارد. اگر می‌خواهید یک سرویس فقط از Source مشخص مجاز باشد، بهتر است بعد از Rule مجاز، Rule Deny عمومی برای همان سرویس ایجاد کنید.

آیا Local-in Policy جای Trusted Host را می‌گیرد؟

خیر. Trusted Host و Local-in Policy مکمل هم هستند. Trusted Host روی حساب ادمین اعمال می‌شود، اما Local-in Policy قبل‌تر و در سطح ترافیک ورودی به Interface می‌تواند Source، Service و Interface را کنترل کند.

آیا Firewall Policy معمولی می‌تواند دسترسی به GUI خود FortiGate را ببندد؟

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

Local-in Policy در FortiGate دقیقاً چه کاری انجام می‌دهد؟

Local-in Policy ترافیکی را کنترل می‌کند که مقصد آن خود FortiGate است؛ مثل HTTPS، SSH، PING، SNMP، IKE یا SSL VPN روی Interfaceهای FortiGate. این Policy برای ترافیک عبوری بین شبکه‌ها نیست.

امتیاز و دیدگاه کاربران

دیدگاه خود را درباره این مقاله بیان کنید.ثبت دیدگاه

پایگاه دانش