مدت زمان مطالعه:
0
اولین قدم عملی برای انتشار یک سامانه پشت FortiWeb، ساخت درست Server Policy است. Server Policy جایی است که FortiWeb تصمیم میگیرد ترافیک ورودی از کجا دریافت شود، به کدام سرور پشتصحنه ارسال شود، چه Certificate و Serviceای استفاده شود و کدام Web Protection Profile روی درخواستها اعمال شود.
این مقاله بر اساس FortiWeb 7.6 نوشته شده و تمرکز آن روی سناریوی رایج Reverse Proxy است؛ یعنی کاربر از بیرون به یک IP یا FQDN عمومی وصل میشود، FortiWeb درخواست را دریافت میکند، آن را بررسی میکند و سپس به Web Server یا Server Pool داخلی تحویل میدهد.
هدف مقاله این است که ادمین قبل از نوشتن Policy بداند Virtual Server، Server Pool، Protected Host و Web Protection Profile هرکدام چه نقشی دارند و ترتیب درست کانفیگ اولیه در FortiWeb چیست.
مروری بر این مقاله
در FortiWeb، Server Policy نقطه اتصال بین بخش شبکه، بخش سرور و بخش امنیت است. به زبان ساده، Server Policy مشخص میکند FortiWeb ترافیک کدام Virtual Server را دریافت کند، آن را به کدام Server Pool ارسال کند و چه پروفایلهای امنیتی و تنظیمات SSL/TLS روی آن اعمال شود.
طبق CLI Reference نسخه 7.6.6، FortiWeb برای هر Connection فقط یک Server Policy اعمال میکند. به همین دلیل ترتیب، نامگذاری، Host Matching، Virtual Server و Server Pool باید دقیق طراحی شوند؛ چون اگر ترافیک به Policy اشتباه بخورد، ممکن است به سرور اشتباه Forward شود یا اصلاً توسط FortiWeb بررسی نشود.
برای اینکه Server Policy درست نوشته شود، باید قبل از آن چند آبجکت اصلی آماده شده باشد. این ترتیب در مستندات Fortinet هم دیده میشود؛ برای ساخت HTTP Server Policy، ابتدا باید Virtual Server و Server Pool مشخص شوند و در صورت نیاز Protected Host، HTTP Content Routing، Certificate و Web Protection Profile هم آماده باشند.
| آبجکت | نقش در FortiWeb | مثال |
|---|---|---|
| Virtual Server | آدرس و Interfaceای که FortiWeb ترافیک کاربران را روی آن دریافت میکند. | 203.0.113.10:443 on port1 |
| Server Pool | لیست یک یا چند Web Server پشت FortiWeb که درخواستها به آنها ارسال میشود. | 10.10.10.21:443, 10.10.10.22:443 |
| Protected Host | نام دامنه یا Host Header مجاز که FortiWeb باید از آن محافظت کند. | app.example.com |
| Certificate | گواهی SSL/TLS که FortiWeb برای سمت Client استفاده میکند. | wildcard-example-com |
| Web Protection Profile | مجموعه تنظیمات امنیتی مثل Signature، HTTP Constraint، URL Access، Parameter Validation و Bot Mitigation. | WPP-App-Initial-Monitor |
| Server Policy | آبجکت نهایی که همه موارد بالا را به هم وصل میکند. | SP-App-HTTPS |
در این مقاله یک سناریوی ساده اما واقعی را در نظر میگیریم. یک سامانه داخلی داریم که روی دو سرور وب اجرا شده و قرار است کاربران از اینترنت با آدرس HTTPS به آن دسترسی داشته باشند.
| مورد | مقدار نمونه |
|---|---|
| FQDN سرویس | app.example.com |
| IP عمومی یا VIP روی FortiWeb | 203.0.113.10 |
| Real Server اول | 10.10.10.21:443 |
| Real Server دوم | 10.10.10.22:443 |
| Mode عملیاتی | Reverse Proxy |
| سمت کاربر | HTTPS/443 |
| سمت Backend | HTTPS/443 |
قبل از اینکه داخل FortiWeb Server Policy بسازید، این موارد باید مشخص شده باشند. اگر این اطلاعات ناقص باشد، Policy ساخته میشود اما در زمان تست با خطاهای SSL، عدم دسترسی Backend، Host Header اشتباه یا لاگهای مبهم مواجه میشوید.
Virtual Server مشخص میکند FortiWeb ترافیک را روی کدام Interface و کدام IP دریافت کند. در Reverse Proxy، Destination IP کاربر معمولاً همان IPای است که در Virtual Server تعریف میشود.
| فیلد | مقدار پیشنهادی در سناریوی نمونه |
|---|---|
| Name | VS-App-HTTPS |
| Interface | port1 |
| IP Address | 203.0.113.10 |
| Status | Enable |
نمونه CLI بر اساس ساختار FortiWeb 7.6:
config server-policy vserver
edit "VS-App-HTTPS"
config vip-list
edit 1
set interface "port1"
set vip "203.0.113.10"
set status enable
next
end
next
end
Server Pool گروهی از یک یا چند Web Server است که FortiWeb درخواستها را به آنها ارسال میکند. در Reverse Proxy، FortiWeb میتواند بین سرورهای داخل Pool توزیع بار انجام دهد؛ مثلاً با Round Robin یا Least Connections.
| فیلد | مقدار پیشنهادی |
|---|---|
| Name | POOL-App-HTTPS |
| Type | Reverse Proxy |
| Load Balancing | Round Robin / Least Connections |
| Server 1 | 10.10.10.21:443 |
| Server 2 | 10.10.10.22:443 |
| SSL to Backend | Enable |
نمونه CLI:
config server-policy server-pool
edit "POOL-App-HTTPS"
set type reverse-proxy
set protocol HTTP
set lb-algo round-robin
set server-balance enable
config pserver-list
edit 1
set server-type physical
set ip 10.10.10.21
set port 443
set ssl enable
set status enable
next
edit 2
set server-type physical
set ip 10.10.10.22
set port 443
set ssl enable
set status enable
next
end
next
end
اگر چند Backend دارید، Health Check بسیار مهم است. بدون Health Check درست، FortiWeb ممکن است همچنان ترافیک را به سروری ارسال کند که سرویس روی آن Down است یا پاسخ HTTP اشتباه برمیگرداند.
برای شروع، Health Check ساده میتواند فقط TCP/443 را بررسی کند؛ اما برای سامانههای حساس بهتر است مسیر واقعی مثل صفحه Login یا Health Endpoint بررسی شود.
Protected Host مشخص میکند FortiWeb کدام مقدار Host Header را برای این سرویس معتبر بداند. اگر سرویس با FQDN مشخص منتشر میشود، تعریف Protected Host کمک میکند درخواستهایی که برای Hostهای ناشناس یا اشتباه ارسال شدهاند، در همان لایه WAF کنترل شوند.
| فیلد | مقدار پیشنهادی |
|---|---|
| Name | HOST-App |
| Host | app.example.com |
نمونه CLI:
config server-policy allow-hosts
edit "HOST-App"
config allow-hosts-list
edit 1
set host-type fqdn
set host "app.example.com"
next
end
next
end
اگر قرار است کاربران با HTTPS به سامانه وصل شوند، Certificate باید روی FortiWeb وجود داشته باشد. این Certificate میتواند یک گواهی برای همان FQDN، یک Wildcard Certificate یا یک SNI Configuration باشد.
برای سناریوی ساده، یک Certificate روی Server Policy انتخاب میشود. اگر چند FQDN روی یک IP دارید، بهتر است SNI را طراحی کنید.
| سناریو | پیشنهاد |
|---|---|
| یک دامنه روی یک IP | استفاده از یک Local Certificate روی Server Policy کافی است. |
| چند دامنه روی یک IP | از SNI Configuration یا Certificate Group استفاده شود. |
| HTTPS از FortiWeb تا Backend | در Server Pool برای Real Server گزینه SSL فعال شود. |
| HTTP به HTTPS | در Server Policy گزینه HTTP-to-HTTPS فعال شود. |
Web Protection Profile مجموعه تنظیمات امنیتی FortiWeb است. در شروع کار، اگر شناخت کاملی از رفتار برنامه ندارید، بهتر است Profile را با حالت محافظهکارانه و مانیتورینگ فعال کنید؛ سپس بعد از بررسی لاگها، Actionها را سختگیرانهتر کنید.
برای کانفیگ اولیه، این رویکرد پیشنهاد میشود:
حالا که Virtual Server، Server Pool، Protected Host، Certificate و Web Protection Profile آماده شدند، میتوان Server Policy را ساخت. این Policy تعیین میکند ترافیک HTTPS ورودی روی Virtual Server به Server Pool داخلی ارسال شود و در مسیر، Web Protection Profile روی آن اعمال شود.
| فیلد | مقدار پیشنهادی |
|---|---|
| Name | SP-App-HTTPS |
| Deployment Mode | Server Pool |
| Virtual Server | VS-App-HTTPS |
| Server Pool | POOL-App-HTTPS |
| Protected Host Names | HOST-App |
| Service | HTTPS |
| Certificate | wildcard-example-com |
| Web Protection Profile | WPP-App-Initial-Monitor |
| Status | Enable |
نمونه CLI پایه:
config server-policy policy
edit "SP-App-HTTPS"
set status enable
set protocol HTTP
set deployment-mode server-pool
set vserver "VS-App-HTTPS"
set server-pool "POOL-App-HTTPS"
set allow-hosts "HOST-App"
set service "HTTPS"
set HTTPS-service "HTTPS"
set ssl enable
set certificate "wildcard-example-com"
set HTTP-to-HTTPS enable
set hsts-header enable
set hsts-max-age 31536000
set web-protection-profile "WPP-App-Initial-Monitor"
set monitor-mode enable
set client-real-ip disable
set syncookie enable
next
end
در حالت Reverse Proxy، معمولاً Backend اتصال را از IP خود FortiWeb میبیند. اگر لازم است Backend IP واقعی کاربر را به عنوان Source IP شبکهای ببیند، میتوان Client Real IP را بررسی کرد؛ اما باید Route برگشت درست باشد و معمولاً Backend باید FortiWeb را به عنوان Gateway ببیند. در بسیاری از سناریوها، استفاده از Headerهایی مثل X-Forwarded-For برای ثبت IP واقعی کاربر در برنامه کافیتر و کمریسکتر است.
بعد از ساخت Server Policy، فقط باز شدن صفحه اصلی کافی نیست. باید SSL، Host Header، مسیر Login، Upload، API، Redirect و لاگها بررسی شوند.
curl -vk https://app.example.com/ curl -vk -H "Host: app.example.com" https://203.0.113.10/ curl -I http://app.example.com/ curl -I https://app.example.com/
| اشتباه رایج | نتیجه احتمالی | راهحل |
|---|---|---|
| اشتباه گرفتن Virtual Server با Backend Server | ترافیک به Policy نمیخورد یا به مقصد اشتباه میرود. | Virtual Server را برای IP ورودی کاربر و Server Pool را برای Backend تعریف کنید. |
| تعریف نکردن Protected Host | درخواستهای Host ناشناس هم ممکن است وارد Policy شوند. | برای هر FQDN اصلی Protected Host بسازید. |
| فعال کردن Block شدید از روز اول | False Positive و اختلال در سرویس. | ابتدا Monitor/Alert، سپس سختگیری مرحلهای. |
| نداشتن Health Check درست | ارسال ترافیک به Backend خراب یا Down. | Health Check واقعی بر اساس سرویس تعریف شود. |
| باز بودن دسترسی مستقیم به Backend | Bypass شدن FortiWeb. | روی Firewall یا Routing، دسترسی مستقیم به Backend محدود شود. |
| انتخاب Certificate اشتباه | خطای SSL، Warning مرورگر یا قطع اتصال. | Certificate و Chain را کامل و متناسب با FQDN وارد کنید. |
| مورد | وضعیت مطلوب |
|---|---|
| DNS | FQDN به IP یا VIP درست روی FortiWeb اشاره کند. |
| Virtual Server | Interface، IP و Status درست تنظیم شده باشد. |
| Server Pool | همه Backendها با IP، Port، SSL و Health Check درست تعریف شده باشند. |
| Protected Host | FQDNهای مجاز سرویس تعریف شده باشند. |
| Certificate | Certificate، Private Key و Chain کامل وارد شده باشد. |
| Server Policy | Virtual Server، Server Pool، Protected Host، Certificate و Web Protection Profile به Policy متصل شده باشند. |
| HTTP to HTTPS | در صورت نیاز Redirect فعال و تست شده باشد. |
| Logging | Traffic Log و Attack Log در FortiWeb و FortiAnalyzer قابل مشاهده باشد. |
| Security Profile | ابتدا در حالت قابل کنترل فعال شده و بعد از بررسی لاگها به سمت Block تنظیم شود. |
| Bypass Prevention | دسترسی مستقیم به Backend از بیرون یا شبکههای غیرمجاز بسته شده باشد. |