راه‌اندازی اولیه FortiGate پایان کار نیست. بعد از اینکه Interfaceها، Route، DNS، Policy اینترنت و NAT تنظیم شدند، مرحله مهم‌تری شروع می‌شود: Hardening یا امن‌سازی. هدف از FortiGate Hardening این است که سطح حمله دستگاه کاهش پیدا کند، دسترسی مدیریتی کنترل شود، لاگ‌ها قابل پیگیری باشند، Firmware در وضعیت امن نگه داشته شود و در صورت بروز خطا یا حمله، امکان بازیابی سریع وجود داشته باشد. این مقاله برای ادمین‌هایی نوشته شده که FortiGate را نصب کرده‌اند و حالا می‌خواهند مطمئن شوند دستگاه با تنظیمات پیش‌فرض و پرریسک در شبکه باقی نمانده است. تمرکز مقاله روی موارد عملیاتی است: تغییر پورت‌های مدیریتی، محدودسازی Admin Access، فعال‌سازی Two-Factor Authentication، Password Policy، بستن سرویس‌های غیرضروری، ارسال لاگ به FortiAnalyzer، Backup دوره‌ای، Local-in Policy و بررسی Firmware Version.

 

در CLI:

config system global
    set admin-sport 10443
    set admin-ssh-port 10022
    set admin-port 8080
    set admin-telnet-port 0
end

بعد از تغییر HTTPS Port، آدرس ورود به GUI تغییر می‌کند:

در انتخاب پورت‌ها نباید از پورت‌های معروف سرویس‌های دیگر استفاده شود. Fortinet در مستندات Port Selection نیز توصیه می‌کند پورت‌های HTTPS و SSH از مقادیر پیش‌فرض تغییر داده شوند و از پورت‌هایی که برای سرویس‌های شناخته‌شده استفاده می‌شوند، مثل SNMP، استفاده نشود.

یکی از مهم‌ترین اقدامات در امن‌سازی FortiGate، محدود کردن Login ادمین‌ها به IP یا Subnetهای مشخص است. این کار با Trusted Host انجام می‌شود. اگر Trusted Host برای یک اکانت تنظیم شود، آن اکانت فقط از IPهای تعریف‌شده اجازه ورود دارد.

این محدودسازی باید برای تمام اکانت‌های مدیریتی انجام شود. اگر فقط برای یک اکانت Trusted Host تنظیم شود ولی اکانت دیگری بدون محدودیت باقی بماند، همچنان صفحه Login از بیرون قابل مشاهده یا قابل تلاش خواهد بود. Fortinet در Best Practices توضیح می‌دهد که Trusted Host روی بیشتر روش‌های دسترسی مدیریتی مثل HTTPS، SSH و SNMP اثر دارد و Login از مبدأیی خارج از Trusted Host رد می‌شود.

از طریق GUI:

System > Administrators > Edit Administrator > Trusted Hosts

نمونه تنظیم:

Username: netadmin01

Trusted Host 1: 10.10.10.0/24

Trusted Host 2: 172.16.100.10/32

در CLI:

config system admin
    edit "netadmin01"
        set trusthost1 10.10.10.0 255.255.255.0
        set trusthost2 172.16.100.10 255.255.255.255
    next
end

برای اکانت پیش‌فرض admin هم باید Trusted Host تعریف شود:

config system admin
    edit "admin"
        set trusthost1 10.10.10.0 255.255.255.0
    next
end

در محیط‌های حرفه‌ای‌تر، دسترسی Admin بهتر است فقط از طریق یکی از این مسیرها مجاز باشد:

دسترسی مستقیم Admin از اینترنت، حتی با تغییر پورت، توصیه نمی‌شود مگر در شرایط خاص و با کنترل‌های تکمیلی مثل Trusted Host، MFA، Local-in Policy و مانیتورینگ دقیق لاگ‌ها.

رمز عبور به‌تنهایی برای اکانت‌های مدیریتی کافی نیست. اگر Password لو برود، با MFA هنوز یک لایه دفاعی دیگر وجود دارد. FortiGate برای اکانت‌های Administrator امکان فعال‌سازی Two-Factor Authentication دارد و روش‌هایی مثل FortiToken، FortiToken Cloud، Email و SMS در نسخه‌های مختلف FortiOS پشتیبانی می‌شوند. Fortinet در مستندات Administrator Account Options توضیح می‌دهد که برای فعال‌سازی MFA روی اکانت Admin باید وارد System > Administrators شد، اکانت را ویرایش کرد و Two-factor Authentication را فعال نمود.

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

از طریق GUI:

System > Administrators;> Edit Administrator

در CLI، نمونه فعال‌سازی FortiToken برای یک ادمین به شکل زیر است:

config system admin
    edit "netadmin01"
        set two-factor fortitoken
        set fortitoken <token-serial>
        set email-to "netadmin01@example.com"
    next
end

اگر از FortiAuthenticator یا RADIUS استفاده می‌شود، بهتر است احراز هویت ادمین‌ها به‌صورت متمرکز طراحی شود. در این حالت FortiGate فقط نقطه اعمال کنترل است و مدیریت هویت، MFA و سیاست‌های کاربری در FortiAuthenticator یا سامانه احراز هویت مرکزی انجام می‌شود.

Password Policy باعث می‌شود رمزهای ضعیف یا تکراری وارد سیستم نشوند. در FortiGate می‌توان برای Local Administrator Passwordها و IPsec Pre-shared Keyها سیاست رمز عبور تعریف کرد. Fortinet در مستندات Password Policy توضیح می‌دهد که FortiGate امکان تعریف سیاست برای ادمین‌ها و IPsec PSKها را دارد و می‌تواند معیارهایی مثل تغییر دوره‌ای و الزامات پیچیدگی رمز را enforce کند.

از طریق GUI، بسته به نسخه FortiOS، مسیر معمول به شکل زیر است:

System > Settings > Password Policy

یا:

System > Administrators > Password Policy

تنظیمات پیشنهادی:

در CLI:

config system password-policy
    set status enable
    set apply-to admin-password ipsec-preshared-key
    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 expire-status enable
    set expire-day 90
end

نام دقیق بعضی پارامترها ممکن است بین نسخه‌های FortiOS متفاوت باشد، اما ساختار کلی از مسیر config system password-policy انجام می‌شود. Fortinet در CLI Reference همین بخش را برای پیکربندی Password Policy ادمین‌های Local و IPsec VPN Pre-shared Keyها معرفی کرده است.

برای ادمین‌های حرفه‌ای، نکته اصلی این است که Password Policy جایگزین MFA نیست. Password Policy، MFA، Trusted Host و Local-in Policy باید هم‌زمان استفاده شوند.

هر Interface در FortiGate می‌تواند سرویس‌های مدیریتی یا سیستمی مشخصی را قبول کند؛ مثل HTTPS، SSH، PING، SNMP، FMG-Access، Security Fabric، Radius Accounting و موارد دیگر. هر سرویسی که روی Interface فعال باشد، سطح حمله همان Interface را افزایش می‌دهد.

اصل ساده است: روی هر Interface فقط همان سرویس‌هایی فعال باشد که واقعاً لازم است.

برای بررسی از GUI:

Network > Interfaces > Edit Interface > Administrative Access

روی Interface مدیریتی، معمولاً این موارد کافی است:

روی WAN، در حالت عادی بهتر است هیچ دسترسی مدیریتی فعال نباشد. اگر نیاز به مانیتورینگ Link وجود دارد، فقط PING با محدودسازی مناسب قابل قبول است. فعال بودن HTTPS یا SSH روی WAN باید استثنا باشد، نه حالت پیش‌فرض.

در CLI، برای بستن سرویس‌های غیرضروری روی WAN:

config system interface
    edit "wan1"
        set allowaccess ping
    next
end

برای Interface مدیریتی:

config system interface
    edit "mgmt"
        set allowaccess ping https ssh
    next
end

برای حذف کامل Administrative Access از یک Interface:

config system interface
    edit "wan1"
        set allowaccess ''
    next
end

در عمل، بهتر است بعد از هر تغییر Interface، از بیرون شبکه تست شود که سرویس‌های مدیریتی واقعاً بسته شده‌اند. این تست می‌تواند با اسکن کنترل‌شده از شبکه مجاز سازمان انجام شود، نه از اینترنت عمومی و بدون مجوز.

Hardening بدون لاگ قابل اتکا ناقص است. اگر ترافیک‌های مدیریتی، تغییرات ادمین‌ها، Loginهای ناموفق، Dropها، رویدادهای UTM و رخدادهای System ثبت نشوند، بعد از حادثه امنیتی امکان تحلیل دقیق وجود نخواهد داشت.

در محیط سازمانی، نگهداری لاگ فقط روی خود FortiGate کافی نیست. FortiAnalyzer برای جمع‌آوری، ذخیره‌سازی، تحلیل و گزارش‌گیری لاگ‌ها طراحی شده و در شبکه‌های چند FortiGate یا محیط‌های حساس، تقریباً یک نیاز عملیاتی است.

برای تنظیم FortiAnalyzer از طریق GUI:

Security Fabric > Fabric Connectors > Logging & Analytics (Right Click) > FortiAnalyzer 

در CLI:

config log fortianalyzer setting
    set status enable
    set server "10.10.20.50"
    set upload-option realtime
end

برای محیط‌هایی که قطعی ارتباط با FortiAnalyzer محتمل است، می‌توان گزینه Store-and-upload را بررسی کرد تا لاگ‌ها موقتاً ذخیره و بعداً ارسال شوند:

config log fortianalyzer setting
    set status enable
    set server "10.10.20.50"
    set upload-option store-and-upload
end

CLI Reference مربوط به FortiAnalyzer نشان می‌دهد که تنظیماتی مثل server، status، upload-option، upload-interval و upload-time در config log fortianalyzer setting قابل پیکربندی هستند.

بعد از اتصال FortiAnalyzer، این موارد باید بررسی شوند:

روی Policyهای مهم نیز باید Log فعال باشد:

config firewall policy
    edit <policy-id>
        set logtraffic all
    next
end

Backup فقط یک فایل پشتیبان نیست؛ بخشی از فرایند Hardening است. اگر FortiGate دچار خطای Firmware، خرابی سخت‌افزاری، اشتباه انسانی یا حمله شود، بدون Backup سالم و قابل بازیابی، زمان بازگشت سرویس طولانی خواهد شد.

Fortinet تأکید می‌کند بعد از پیکربندی موفق FortiGate، گرفتن Backup بسیار مهم است؛ چون در برخی سناریوها مثل Factory Reset یا Firmware Upload ممکن است Configuration فعلی پاک شود و بدون Backup نیاز به بازسازی دستی تنظیمات باشد.

Backup دستی از GUI:

Admin Menu > Configuration > Backup

یا در بعضی نسخه‌ها:

Dashboard > System Information > Backup

پیشنهاد عملیاتی:

برای Backup دستی از CLI به TFTP:

execute backup config tftp FGT-HQ-backup.conf 10.10.20.10

برای Backup دوره‌ای، می‌توان از FortiManager، اسکریپت‌های کنترل‌شده، Automation Stitch یا راهکارهای مدیریت متمرکز استفاده کرد. Fortinet Community نیز برای Backup خودکار با استفاده از Automation و نام‌گذاری مبتنی بر تاریخ، نکات و محدودیت‌هایی را توضیح داده است.

در همین بخش، راهکارهایی مثل سیبتا می‌توانند به‌صورت خودکار وارد فرایند عملیاتی Hardening شوند. وقتی سازمان چند FortiGate دارد، Backup دستی و به‌روزرسانی دستی Signatureها هم زمان‌بر است و هم احتمال خطای انسانی دارد. استفاده از یک سامانه متمرکز برای Backup خودکار، زمان‌بندی عملیات و بروزرسانی امن می‌تواند بخشی از برنامه نگهداری امن FortiGate باشد. طبق معرفی رسمی سیبتا، این سامانه برای بروزرسانی تجهیزات امنیتی FortiGate و FortiWeb، دانلود و نصب خودکار فایل‌های Update، زمان‌بندی عملیات، ذخیره Log فرایند Update و بروزرسانی چند دستگاه به‌صورت هم‌زمان طراحی شده است.

نکته مهم این است که Backup و Update نباید فقط «کارهای نگهداری» دیده شوند؛ این دو مستقیماً به امنیت عملیاتی FortiGate مربوط هستند. Backup امکان بازیابی را فراهم می‌کند و Update امن باعث می‌شود Signatureها و Patchها در وضعیت قابل قبول باقی بمانند.

Firewall Policy معمولی ترافیکی را کنترل می‌کند که از FortiGate عبور می‌کند؛ اما Local-in Policy ترافیکی را کنترل می‌کند که مقصد آن خود FortiGate است. این تفاوت برای Hardening بسیار مهم است.

مثال‌هایی از ترافیک Local-in:

اگر فقط Firewall Policyها را تنظیم کنید ولی Local-in Policy را بررسی نکنید، ممکن است ترافیک مدیریتی یا سیستمی همچنان به خود FortiGate برسد. Fortinet Community در توضیح اثر Local-in Policy و Trusted Hosts اشاره می‌کند که این تنظیمات روی اتصال سرویس‌ها به خود FortiGate و دسترسی مدیریتی دستگاه اثر دارند؛ همچنین از FortiOS 7.6.0 امکان ایجاد Local-in Policy از GUI فراهم شده است.

در FortiOS 7.6 به بعد، بسته به نسخه و Feature Visibility، مسیر GUI می‌تواند به شکل زیر باشد: (توجه داشتید باشید که تنظیمات این بخش فقط در CLI امکان پذیر است و در فضای GUI تنها امکان مشاهده کانفیگ‌ها وجود دارد)

Policy & Objects > Local-In Policy

سناریوی رایج این است که ابتدا دسترسی‌های لازم از شبکه مدیریتی Allow شوند و سپس دسترسی‌های ناخواسته از WAN Deny شوند.

نمونه CLI برای اجازه SSH و HTTPS فقط از شبکه مدیریتی:

config firewall local-in-policy
    edit 1
        set intf "wan1"
        set srcaddr "MGMT-Public-IP"
        set dstaddr "all"
        set action accept
        set service "HTTPS" "SSH"
        set schedule "always"
    next
end

نمونه Deny برای دسترسی مدیریتی از سایر مبدأها روی WAN:

config firewall local-in-policy
    edit 2
        set intf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "HTTPS" "SSH" "HTTP" "TELNET"
        set schedule "always"
    next
end

قبل از اعمال Local-in Policy باید دقت شود که دسترسی مدیریتی فعلی قطع نشود. بهترین روش این است که ابتدا Rule مجاز برای شبکه مدیریتی ساخته شود، سپس Ruleهای Deny اضافه شوند. هنگام اعمال این تغییرات، دسترسی Console یا مسیر مدیریتی جایگزین باید آماده باشد.

یکی از بخش‌های مهم افزایش امنیت فورتی گیت، بررسی نسخه Firmware است. بسیاری از آسیب‌پذیری‌ها با Patchهای FortiOS برطرف می‌شوند؛ اما Upgrade بدون برنامه هم می‌تواند ریسک عملیاتی ایجاد کند. بنابراین هدف این نیست که همیشه بدون بررسی به جدیدترین Major Version بروید، بلکه باید Patchهای امن و مسیر Upgrade رسمی بررسی شوند.

برای بررسی نسخه از GUI:

Dashboard > Status > System Information > Firmware Version

یا در نسخه‌های جدید:

System > Firmware & Registration

در CLI:

get system status

قبل از Upgrade باید این موارد بررسی شود:

Fortinet در مستندات Automatic Firmware Upgrades توضیح می‌دهد که در FortiOS 7.6.4، Automatic Firmware Upgrade به‌صورت پیش‌فرض برای افزایش امنیت فعال است و دستگاه هنگام در دسترس بودن Patch Release جدید به‌روزرسانی می‌شود. همچنین در مستندات FortiOS 7.4.2 آمده است که این قابلیت Patchهای همان Major Release را بررسی و در بازه زمانی تنظیم‌شده Upgrade را زمان‌بندی می‌کند تا Security Fixهای جدید اعمال شوند.

با وجود این، در محیط‌های سازمانی بهتر است Automatic Upgrade بدون سیاست Change Management رها نشود. Upgrade باید تحت کنترل تیم شبکه، با Backup، بررسی Release Notes و زمان‌بندی مشخص انجام شود. برای Firmware، همیشه باید بین امنیت و پایداری عملیاتی تعادل برقرار شود.

در این بخش هم بروزرسانی امن می‌تواند بخشی از فرایند Hardening باشد. برای مثال اگر سازمان به‌دلیل محدودیت‌های دسترسی اینترنتی، سیاست‌های داخلی یا تعدد تجهیزات نمی‌تواند Updateها را به‌صورت منظم انجام دهد، استفاده از سامانه‌ای مثل سیبتا برای زمان‌بندی و مدیریت متمرکز بروزرسانی Signatureها می‌تواند ریسک عقب‌ماندن از Updateهای امنیتی را کاهش دهد. طبق توضیحات ارائه‌شده برای سیبتا، این سامانه امکان بروزرسانی خودکار و حتی آفلاین Signatureهای امنیتی FortiGate و FortiWeb را فراهم می‌کند.

یک چک لیست کوتاه در قالب اکسل (خلاصه‌ای از موارد بررسی شده در مقاله هست) برای بررسی نهایی پس از نصب و امن‌سازی FortiGate استفاده می‌شود. بهتر است بعد از هر نصب، Upgrade یا تغییر اساسی، همین موارد دوباره بررسی شوند.