چک‌لیست جامع امن‌سازی پنل مدیریتی FortiGate

این مقاله بر اساس FortiOS 7.4.12، آخرین Patch فعلی شاخه FortiOS 7.4 نوشته شده است. مسیرهای اصلی در Patchهای دیگر 7.4 مشابه‌اند، اما بعضی گزینه‌ها به مدل، VDOM Mode، HA و Build وابسته‌اند. در FortiOS 7.6 امکان ایجاد Local-in Policy از GUI اضافه شده است؛ در FortiOS 7.4، Local-in Policy سفارشی از CLI ساخته و ویرایش می‌شود. از FortiOS 7.4.8 نیز PBKDF2 به الگوریتم پیش‌فرض ذخیره Password Administratorهای جدید تبدیل شده است و حساب‌های قدیمی ممکن است تا زمان Login یا Reset Password همچنان Hash قدیمی داشته باشند.

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

1. مدل تهدید Management Plane
2. جمع‌آوری اطلاعات قبل از Hardening
3. ترتیب امن اجرای تغییرات
4. طراحی شبکه مدیریت
5. Firmware، PSIRT و PBKDF2
6. Administrator Account و Least Privilege
7. Password Policy و حساب اضطراری
8. MFA برای Administratorها
9. Trusted Hosts و محدودسازی Source IP
10. Administrative Access روی Interface
11. Certificate، TLS، HSTS و Redirect
12. Hardening سرویس SSH
13. Local-in Policy در FortiOS 7.4
14. Remote Authentication و SSO Admin
15. REST API Administrator
16. نکات HA و Management Interface
17. پیکربندی مرحله‌به‌مرحله در GUI
18. Baseline کامل در CLI
19. Logging، Audit و Backup
20. روش تست و Rollback
21. Troubleshooting
22. Best Practice و چک‌لیست اجرایی

1. مدل تهدید Management Plane

ترافیک مدیریتی با ترافیک عبوری متفاوت است. ممکن است یک FortiGate هیچ Firewall Policy ورودی از اینترنت نداشته باشد، اما چون HTTPS روی WAN فعال است، خود Device همچنان از اینترنت قابل دسترسی باشد. برای حفاظت باید هم Interface، هم Administrator و هم Local-in Traffic کنترل شوند.

2. جمع‌آوری اطلاعات قبل از Hardening

قبل از تغییر، وضعیت فعلی را مستند کنید. بدون Baseline مشخص نیست تغییر جدید باعث اختلال شده یا مشکل از قبل وجود داشته است.

اطلاعاتی که باید ثبت شوند

• مدل، Serial Number، FortiOS Version و Build
• Standalone یا HA بودن Device
• NAT Mode یا Transparent Mode
• VDOM Mode و VDOM مدیریتی
• Interfaceهایی که HTTPS، SSH، SNMP، PING یا FMG-Access روی آن‌ها فعال است
• تمام Local، Remote، SAML، FortiCloud و REST API Administratorها
• Trusted Hostهای هر حساب
• Admin Port، Certificate، TLS Version و SSH Setting
• Local-in Policyهای IPv4 و IPv6
• مقصد Log و وضعیت FortiAnalyzer یا Syslog
• روش Recovery شامل Console، OOB و حساب Break-glass

دستورات Read-only اولیه

get system status
get system ha status
show system interface
show system admin
show system api-user
show system global
show system password-policy
show firewall local-in-policy
show firewall local-in-policy6
show log fortianalyzer setting
show log syslogd setting

3. ترتیب امن اجرای تغییرات

ترتیب تغییرات اهمیت زیادی دارد. برای مثال اگر ابتدا HTTPS را از Interface حذف کنید و سپس بخواهید حساب جدید را آزمایش کنید، ممکن است دسترسی خود را از دست بدهید.

1. Backup رمزگذاری‌شده بگیرید.
2. Console یا OOB را آزمایش کنید.
3. حساب Administrator دوم بسازید.
4. Access Profile و MFA حساب جدید را تنظیم کنید.
5. از Source مجاز با حساب جدید Login کنید.
6. Certificate و پورت جدید را اعمال و تست کنید.
7. Trusted Host را روی حساب جدید اعمال و دوباره تست کنید.
8. Administrative Access را روی Interface مدیریت نگه دارید.
9. Local-in Policy Allow را بسازید و تست کنید.
10. در آخر Local-in Policy Deny و حذف دسترسی از Interfaceهای غیرضروری را انجام دهید.
11. Log، Alert و Backup نهایی را بررسی کنید.

4. طراحی شبکه مدیریت

مدیریت In-band

Administrator از همان شبکه‌ای به FortiGate متصل می‌شود که ترافیک عملیاتی از آن عبور می‌کند. پیاده‌سازی ساده‌تر است، اما خرابی Routing، VLAN یا Policy می‌تواند مدیریت را نیز قطع کند.

مدیریت Out-of-Band

یک Interface، Switch و مسیر مستقل برای Management وجود دارد. این طراحی برای Datacenter و محیط‌های حساس ترجیح داده می‌شود، زیرا مشکل Data Plane الزاماً مسیر مدیریت را قطع نمی‌کند.

طراحی پیشنهادی

• Management VLAN یا Interface اختصاصی
• دسترسی فقط از Jump Host یا PAM
• ورود Remote ابتدا از IPsec VPN سپس به Management Network
• عدم Route عمومی از شبکه کاربران به Management Subnet
• ثبت Sessionهای مدیریتی و استفاده از MFA
• Console Server مستقل برای Recovery

5. Firmware، PSIRT و PBKDF2

Fortinet توصیه می‌کند Release Notes، Resolved Issues، Known Issues و PSIRT Advisoryها بررسی شوند. انتخاب Firmware باید با سیاست سازمان، Featureهای موردنیاز و Upgrade Path رسمی هماهنگ باشد.

بعد از ارتقا به FortiOS 7.4.8 یا بالاتر

PBKDF2 برای Hash کردن Password حساب‌های Administrator جدید یا Passwordهای به‌روزشده استفاده می‌شود. حساب‌هایی که از نسخه قدیمی ارتقا یافته‌اند ممکن است تا Login یا Reset Password با Hash قدیمی باقی بمانند.

# بررسی فرمت Hash:
show system admin

# نمونه جدید:
set password ENC PB2...

# نمونه قدیمی:
set password ENC SH2...

فرآیند مهاجرت Hash

1. از همه Administratorهای فعال بخواهید بعد از Upgrade یک بار Login کنند.
2. Password حساب‌های بلااستفاده یا Service Accountها را Reset یا حساب را حذف کنید.
3. خروجی Configuration را برای Prefixهای PB2 و SH2 Audit کنید.
4. Secretهای API را جداگانه Rotate کنید؛ API Token با Password Admin یکسان نیست.

6. Administrator Account و Least Privilege

هر شخص باید حساب اختصاصی داشته باشد. حساب مشترک مانند admin امکان تشخیص فرد انجام‌دهنده تغییر را از بین می‌برد.

گروه‌بندی پیشنهادی نقش‌ها

نکات Access Profile

• برای عملیات روزمره از super_admin استفاده نکنید.
• CLI Access را برای افرادی که فقط GUI نیاز دارند محدود کنید.
• VDOM Access را فقط به VDOMهای مسئولیت فرد محدود کنید.
• حساب‌های Read-only را برای Monitoring Toolها استفاده کنید.
• Profile سفارشی را بعد از Upgrade بازبینی کنید؛ Feature جدید ممکن است Permission جدید داشته باشد.

7. Password Policy و حساب اضطراری

Password Policy در FortiOS 7.4 برای Local Administrator Passwordها قابل فعال‌سازی است. مقدار مناسب باید با سیاست سازمان و PAM هماهنگ باشد.

Baseline پیشنهادی

• حداقل طول 14 یا 16 کاراکتر
• حداقل یک حرف کوچک، بزرگ، عدد و کاراکتر خاص
• عدم استفاده مجدد از Password
• حداقل تعداد کاراکتر تغییرکرده نسبت به Password قبلی
• Expiration فقط در صورت الزام Policy؛ Rotation زیاد بدون PAM می‌تواند Password ضعیف‌تر ایجاد کند.

config system password-policy
    set status enable
    set apply-to admin-password
    set minimum-length 14
    set min-lower-case-letter 1
    set min-upper-case-letter 1
    set min-number 1
    set min-non-alphanumeric 1
    set min-change-characters 4
    set reuse-password disable
    set expire-status enable
    set expire-day 90
end

حساب Break-glass

• Local باشد و به IdP خارجی وابسته نباشد.
• Password بسیار طولانی در Secret Vault یا پاکت اضطراری نگهداری شود.
• Trusted Host آن به Console Network یا OOB محدود باشد.
• استفاده از آن Alert ایجاد کند.
• هر سه تا شش ماه Login آن تست و Password Rotate شود.

8. MFA برای Administratorها

MFA احتمال موفقیت حمله با Password سرقت‌شده را کاهش می‌دهد. Fortinet توصیه می‌کند قبل از فعال‌کردن MFA یک حساب Administrator دوم برای Recovery ایجاد شود.

روش‌های رایج

• FortiToken Mobile یا Hardware Token
• FortiIdentity Cloud یا FortiToken Cloud
• RADIUS به FortiAuthenticator با MFA
• SAML با MFA روی Identity Provider
• PKI/Certificate برای سناریوهای پیشرفته

Side Effectهای مهم

• NTP اشتباه می‌تواند Token زمان‌محور را نامعتبر کند.
• اختلال FortiGuard یا Cloud Service ممکن است Activation یا Cloud Token را مختل کند.
• حساب Remote بدون Local Fallback ممکن است هنگام خرابی LDAP/RADIUS قابل استفاده نباشد.
• Automation نباید از حساب Interactive دارای MFA استفاده کند؛ برای آن API Admin محدود بسازید.

9. Trusted Hosts و محدودسازی Source IP

Trusted Hosts روی هر Administrator تعیین می‌کند Login فقط از کدام Source IP یا Subnet مجاز باشد. اگر برای تمام Administratorهای Local تعریف شده باشد، دسترسی مدیریتی Interfaceها به Sourceهای تعریف‌شده محدود می‌شود؛ PING از این رفتار مستثنا است.

سناریوی نمونه

خطاهای رایج

• استفاده از IP قبل از NAT به‌جای IP دیده‌شده توسط FortiGate
• فراموش‌کردن IPv6 Trusted Host
• تعریف Subnet بسیار بزرگ
• اعمال Trusted Host روی آخرین Administrator قبل از تست حساب دوم
• توقع محدودشدن PING با Trusted Host

10. Administrative Access روی Interface

این تنظیم اولین لایه است. اگر HTTPS روی یک Interface فعال نباشد، FortiGate روی آن Interface GUI ارائه نمی‌دهد؛ حتی اگر Local-in Policy Allow وجود داشته باشد.

11. Certificate، TLS، HSTS و Redirect

Certificate معتبر

Certificate باید برای FQDN مدیریت صادر شده باشد؛ برای مثال fgt01-mgmt.example.local. استفاده از IP در URL زمانی بدون Warning است که IP داخل SAN Certificate باشد.

TLS Version

در شاخه 7.4، TLS 1.2 و TLS 1.3 برای Web Administration قابل انتخاب‌اند. Clientهای بسیار قدیمی ممکن است بعد از حذف TLS قدیمی دیگر متصل نشوند؛ این رفتار مطلوب امنیتی است اما باید Jump Hostها تست شوند.

HTTP Redirect و Host Header

Fortinet توصیه می‌کند HTTP Redirect غیرفعال باشد. اگر Redirect لازم است، admin-host را روی FQDN ثابت تنظیم کنید تا Redirect از Host Header ارسال‌شده توسط Client استفاده نکند.

HSTS

HSTS باعث می‌شود Browser برای مدت مشخص فقط HTTPS استفاده کند. قبل از فعال‌سازی بلندمدت، Certificate و FQDN را درست کنید؛ اشتباه در HSTS می‌تواند دسترسی Browser را تا پایان Max-Age دشوار کند.

12. Hardening سرویس SSH

• SSH v1 غیرفعال باشد.
• SSH Password Authentication در صورت استفاده از Public Key قابل غیرفعال‌کردن است.
• Grace Time را کوتاه کنید تا Connectionهای بدون Authentication طولانی نمانند.
• SSH را فقط از Jump Host و Management Subnet مجاز کنید.
• Algorithmهای قدیمی را بعد از تست Clientهای مدیریت Ban کنید.
• Keyهای شخصی Administratorها Rotate و در صورت خروج فرد حذف شوند.

config system global
    set admin-ssh-v1 disable
    set admin-ssh-grace-time 30
    set admin-ssh-password enable
end

13. Local-in Policy در FortiOS 7.4

Local-in Policy ترافیکی را کنترل می‌کند که مقصد آن خود FortiGate است. این Policy با Firewall Policy عبوری متفاوت است و برای HTTPS، SSH، PING، SNMP، IPsec، BGP و سایر سرویس‌های Local کاربرد دارد.

منطق پردازش

• Ruleها از بالا به پایین بررسی می‌شوند.
• Interface، Source Address، Destination Address، Service و Schedule Match می‌شوند.
• Rule می‌تواند Accept یا Deny باشد.
• برای IPv6 باید local-in-policy6 جداگانه ساخته شود.
• برای Whitelist کردن Management، Allow محدود و Deny صریح لازم است.

چرا فقط Trusted Host کافی نیست؟

Trusted Host به حساب Administrator مربوط است. Local-in Policy می‌تواند قبل از مرحله Authentication کل Traffic یک Service را بر اساس Interface و Source محدود کند و همچنین برای سرویس‌های غیرAdmin مانند PING یا SNMP استفاده شود.

14. Remote Authentication و SSO Admin

RADIUS، LDAP، TACACS+ و SAML می‌توانند مدیریت حساب‌ها را مرکزی کنند. با این حال، خرابی Identity Provider نباید سازمان را بدون دسترسی بگذارد.

• حداقل یک Local Break-glass Admin نگه دارید.
• Group Mapping را به Access Profile محدود وصل کنید.
• Default Group یا Catch-all را به super_admin متصل نکنید.
• MFA را روی IdP یا FortiAuthenticator الزامی کنید.
• Timeout و Availability سرورهای Remote را مانیتور کنید.
• در SAML، Entity ID، Certificate و Clock را کنترل کنید.

15. REST API Administrator

REST API Admin برای Automation، Backup و Monitoring استفاده می‌شود. Token آن باید مانند Password سطح بالا محافظت شود.

• برای هر Integration یک API User جدا بسازید.
• Access Profile را فقط به Endpointهای موردنیاز محدود کنید.
• Trusted Host را به Automation Server محدود کنید.
• Token را فقط یک‌بار در Secret Vault ذخیره کنید.
• Token را در Command History، Git، Ticket یا Log چاپ نکنید.
• در زمان خروج Vendor یا تغییر Server، Token را Revoke کنید.

config system api-user
    edit "backup-automation"
        set accprofile "API-Backup-ReadOnly"
        set vdom "root"
        config trusthost
            edit 1
                set ipv4-trusthost 10.20.40.25 255.255.255.255
            next
        end
    next
end

16. نکات HA و Management Interface

• در HA، مدیریت Cluster IP با مدیریت مستقیم Memberها متفاوت است.
• برای دسترسی مستقل به هر Member از HA Reserved Management Interface استفاده کنید.
• Local-in Policy دارای گزینه ha-mgmt-intf-only است.
• Certificate و Admin Settings معمولاً Sync می‌شوند، اما IP مدیریت اختصاصی Memberها متفاوت است.
• قبل از Failover، Login به هر Member از Interface رزروشده را آزمایش کنید.

17. پیکربندی مرحله‌به‌مرحله در GUI

مرحله 1: Backup و دسترسی اضطراری

Backup را با Password قوی Encrypt کنید. Console Login را جداگانه آزمایش کنید.

مرحله 2: Import Certificate

1. Certificate و Private Key یا CSR-signed Certificate را Import کنید.
2. Certificate Chain را بررسی کنید.
3. FQDN داخل SAN را با URL مدیریت تطبیق دهید.

مرحله 3: ساخت Access Profile

1. Profile را بر اساس نقش نام‌گذاری کنید.
2. Permissionهای System، Network، Policy، VPN و Log را Read یا Read/Write تنظیم کنید.
3. CLI Access را فقط در صورت نیاز فعال کنید.

مرحله 4: ساخت Administrator دوم

1. Username اختصاصی و Profile مناسب وارد کنید.
2. VDOM را محدود کنید.
3. Trusted Host اولیه را وارد کنید.
4. Two-factor Authentication را فعال کنید.
5. از یک Browser جدید Login را آزمایش کنید.

مرحله 5: Administration Settings

1. HTTPS Certificate را انتخاب کنید.
2. Admin HTTPS Port و SSH Port را تنظیم کنید.
3. Idle Timeout را کوتاه کنید.
4. HTTP Redirect را غیرفعال کنید.

مرحله 6: Interface Access

HTTPS و SSH را فقط روی Management Interface نگه دارید. تغییر را ابتدا از Source مجاز آزمایش و سپس از WAN حذف کنید.

مرحله 7: Local-in Policy

Feature Visibility برای مشاهده مفید است، اما Rule سفارشی در 7.4 از CLI ساخته می‌شود. بعد از ساخت، اثر Rule را از Source مجاز و غیرمجاز تست کنید.

18. Baseline کامل در CLI

Management Interface

config system interface
    edit "mgmt"
        set ip 10.20.30.1 255.255.255.0
        set allowaccess ping https ssh
        set role lan
        set description "Dedicated management interface"
    next
end

Global Administration Hardening

config system global
    set hostname "FGT-HQ-EDGE-01"
    set admin-sport 10443
    set admin-ssh-port 10022
    set admin-server-cert "FGT-MGMT-CERT"
    set admin-https-ssl-versions tlsv1-2 tlsv1-3
    set admin-https-redirect disable
    set admin-lockout-threshold 3
    set admin-lockout-duration 900
    set admintimeout 10
    set admin-ssh-v1 disable
    set admin-ssh-grace-time 30
    set cli-audit-log enable
    set revision-backup-on-logout enable
end

Password Policy

config system password-policy
    set status enable
    set apply-to admin-password
    set minimum-length 14
    set min-lower-case-letter 1
    set min-upper-case-letter 1
    set min-number 1
    set min-non-alphanumeric 1
    set min-change-characters 4
    set reuse-password disable
    set expire-status enable
    set expire-day 90
end

Administrator با Trusted Hosts و MFA

config system admin
    edit "netadmin"
        set accprofile "Network_Admin_Limited"
        set vdom "root"
        set trusthost1 10.20.30.50 255.255.255.255
        set trusthost2 10.20.30.51 255.255.255.255
        set trusthost3 10.99.10.0 255.255.255.240
        set two-factor fortitoken
        set fortitoken "FTKMOBXXXXXXXXXX"
        set comments "Named administrator - daily operations"
    next
end

Objectهای Local-in

config firewall address
    edit "MGMT-JUMP-HOSTS"
        set type iprange
        set start-ip 10.20.30.50
        set end-ip 10.20.30.51
    next
    edit "NMS-SERVER"
        set subnet 10.20.40.10 255.255.255.255
    next
end

config firewall service custom
    edit "FGT-HTTPS-10443"
        set tcp-portrange 10443
    next
    edit "FGT-SSH-10022"
        set tcp-portrange 10022
    next
end

Local-in Policy برای Management

config firewall local-in-policy
    edit 10
        set intf "mgmt"
        set srcaddr "MGMT-JUMP-HOSTS"
        set dstaddr "all"
        set action accept
        set service "FGT-HTTPS-10443" "FGT-SSH-10022"
        set schedule "always"
        set comments "Allow management from jump hosts"
    next
    edit 20
        set intf "mgmt"
        set srcaddr "NMS-SERVER"
        set dstaddr "all"
        set action accept
        set service "PING" "SNMP"
        set schedule "always"
    next
    edit 90
        set intf "mgmt"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "FGT-HTTPS-10443" "FGT-SSH-10022" "PING" "SNMP"
        set schedule "always"
    next
end

IPv6 Local-in نمونه

config firewall address6
    edit "MGMT-IPV6-SUBNET"
        set ip6 2001:db8:100:20::/64
    next
end

config firewall local-in-policy6
    edit 10
        set intf "mgmt"
        set srcaddr "MGMT-IPV6-SUBNET"
        set dstaddr "all"
        set action accept
        set service "FGT-HTTPS-10443" "FGT-SSH-10022"
        set schedule "always"
    next
end

بررسی نهایی

get system status
show system global
show system interface mgmt
show system password-policy
show system admin
show system api-user
show firewall local-in-policy
show firewall local-in-policy6

19. Logging، Audit و Backup

• Event Log مربوط به Successful و Failed Admin Login را فعال نگه دارید.
• CLI Audit Log را فعال کنید.
• Configuration Revision بعد از Logout را فعال کنید.
• Log را به FortiAnalyzer با Reliable Logging ارسال کنید.
• روی ایجاد Administrator، تغییر Trusted Host، تغییر Local-in و Firmware Upgrade Alert بسازید.
• NTP را دقیق تنظیم کنید تا Timeline قابل اتکا باشد.
• Backup دوره‌ای را خارج از Device و رمزگذاری‌شده نگهداری کنید.

20. روش تست و Rollback

تست Positive

• Login HTTPS از Jump Host مجاز
• Login SSH از Jump Host مجاز
• MFA موفق
• Certificate بدون Warning
• ثبت Login و CLI Command در Log

تست Negative

• عدم دسترسی از Client شبکه کاربران
• عدم دسترسی HTTPS روی WAN
• عدم دسترسی با Password صحیح از Source غیرمجاز
• Lockout پس از Threshold تعریف‌شده
• عدم دسترسی API از IP خارج Trusted Host

Rollback Plan نمونه

1. از Console وارد شوید.
2. Local-in Deny جدید را Disable کنید.
3. Administrative Access قبلی را موقتاً برگردانید.
4. Trusted Host اشتباه را اصلاح کنید.
5. پورت یا Certificate قبلی را Restore کنید.
6. پس از بازیابی، Root Cause را ثبت کنید.

21. Troubleshooting

Debug Flow محدود

diagnose debug reset
diagnose debug flow filter addr 10.20.30.50
diagnose debug flow show function-name enable
diagnose debug flow trace start 50
diagnose debug enable

# پس از تست:
diagnose debug disable
diagnose debug reset

22. Best Practice و چک‌لیست اجرایی

• FortiOS روی Patch تأییدشده و مسیر Upgrade رسمی است.
• Release Notes و PSIRT Advisoryها بررسی شده‌اند.
• مدیریت مستقیم از اینترنت غیرفعال است.
• Management VLAN یا OOB وجود دارد.
• Console و Break-glass Account آزمایش شده‌اند.
• هر فرد حساب اختصاصی دارد.
• حساب روزمره super_admin نیست.
• MFA روی حساب‌های Interactive فعال است.
• Trusted Host برای همه حساب‌های لازم تعریف شده است.
• IPv6 Management نیز کنترل شده است.
• HTTPS و SSH فقط روی Interface لازم فعال‌اند.
• HTTP و Telnet غیرفعال‌اند.
• Certificate معتبر و FQDN مدیریتی استفاده می‌شود.
• فقط TLS 1.2 و TLS 1.3 مجازند.
• SSH v1 غیرفعال است.
• Lockout و Idle Timeout تنظیم شده‌اند.
• Password Policy فعال است.
• Hash حساب‌های قدیمی به PBKDF2 مهاجرت کرده است.
• Local-in Policy Allow محدود و Deny صریح دارد.
• Local-in Policy6 نیز در صورت IPv6 ساخته شده است.
• API Adminها جدا، محدود و دارای Token Rotation هستند.
• CLI Audit و Configuration Revision فعال‌اند.
• Log به FortiAnalyzer یا Syslog امن ارسال می‌شود.
• Backup رمزگذاری‌شده و Restore Process آزمایش شده است.