چک‌لیست جامع امن‌سازی پنل مدیریتی 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 را برایMonitoringToolها استفاده کنید.
• 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. 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 .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. set trusthost2 10.20. set trusthost3 10.99.10..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. 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 آزمایش شده است.

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