کانفیگ Server Policy در FortiWeb: گام به گام برای انتشار یک سامانه به صورت Reverse Proxy
این مقاله کانفیگ اولیه FortiWeb 7.6 برای انتشار یک سامانه پشت FortiWeb در حالت Reverse Proxy را تشریح میکند. تمرکز روی Virtual Server، Server Pool، Protected Host و Server Policy است و مراحل GUI، نمونه CLI، نکات SSL، لاگگیری، Health Check و چکلیست عملیاتی ارائه میشود.
خلاصه تخصصی مقاله
این مقاله کانفیگ اولیه FortiWeb 7.6 برای انتشار یک سامانه پشت FortiWeb در حالت Reverse Proxy را تشریح میکند. تمرکز روی Virtual Server، Server Pool، Protected Host و Server Policy است و مراحل GUI، نمونه CLI، نکات SSL، لاگگیری، Health Check و چکلیست عملیاتی ارائه میشود.
موضوعات اصلی: پشتیبانی شبکه، Server، FortiWeb، Policy، Host، Certificate
1. Server Policy در 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 بررسی نشود.
نکتهدر سناریوی Reverse Proxy، Server Policy معمولاً مهمترین آبجکت عملیاتی FortiWeb است؛ چون تقریباً همه تنظیمات مهم مثل Virtual Server، Server Pool، Certificate، HTTP to HTTPS، HSTS، Web Protection Profile، HTTP/2 و لاگگیری در نهایت در همین Policy به هم متصل میشوند.
2. اجزای اصلی یک Policy در FortiWeb 7.6
برای اینکه 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 |
| Server Pool | لیست یک یا چند Web Server پشت FortiWeb که درخواستها به آنها ارسال میشود. | |
| 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 |
3. سناریوی نمونه برای انتشار یک سامانه
در این مقاله یک سناریوی ساده اما واقعی را در نظر میگیریم. یک سامانه داخلی داریم که روی دو سرور وب اجرا شده و قرار است کاربران از اینترنت با آدرس 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 |
هشدار طراحیاگر Real Serverها از مسیرهای دیگر قابل دسترس مستقیم باشند، کاربر یا مهاجم میتواند FortiWeb را دور بزند. در طراحی درست، Backend باید فقط از FortiWeb یا مسیرهای مجاز داخلی قابل دسترسی باشد.
4. پیشنیازهای قبل از ساخت Policy
قبل از اینکه داخل FortiWeb Server Policy بسازید، این موارد باید مشخص شده باشند. اگر این اطلاعات ناقص باشد، Policy ساخته میشود اما در زمان تست با خطاهای SSL، عدم دسترسی Backend، Host Header اشتباه یا لاگهای مبهم مواجه میشوید.
- FQDN دقیق سرویس و رکورد DNS مشخص باشد.
- IP یا VIP ای که کاربر باید به آن وصل شود مشخص باشد.
- Interface دریافت ترافیک روی FortiWeb مشخص باشد.
- IP و Port سرورهای Backend مشخص باشد.
- Backend با HTTP کار میکند یا HTTPS؟
- Certificate سمت Client روی FortiWeb آماده باشد.
- نیاز به SNI وجود دارد یا یک Certificate ساده کافی است؟
- نیاز به HTTP to HTTPS Redirect وجود دارد یا نه؟
- Web Protection Profile اولیه در حالت Monitor باشد یا Block؟
- مسیر لاگگیری در FortiWeb و FortiAnalyzer مشخص باشد.
5. مرحله اول: ساخت Virtual Server
Virtual Server مشخص میکند FortiWeb ترافیک را روی کدام Interface و کدام IP دریافت کند. در Reverse Proxy، Destination IP کاربر معمولاً همان IP ای است که در Virtual Server تعریف میشود.
Server Objects → Server → Virtual Server → Create New
| فیلد | مقدار پیشنهادی در سناریوی نمونه |
|---|---|
| Name | VS-App-HTTPS |
| Interface | port1 |
| IP Address | 203.0.113.10 |
| Status | Enable |
نمونه CLI
- 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
نکتهVirtual Server خود Backend نیست. Virtual Server آدرسی است که FortiWeb ترافیک کاربر را روی آن دریافت میکند. Backend داخل Server Pool تعریف میشود.
6. مرحله دوم: تعریف Server Pool و Real Server
Server Pool گروهی از یک یا چند Web Server است که FortiWeb درخواستها را به آنها ارسال میکند. در Reverse Proxy، FortiWeb میتواند بین سرورهای داخل Pool توزیع بار انجام دهد؛ مثلاً با Round Robin یا Least Connections.
Server Objects → Server → Server Pool → Create New
| فیلد | مقدار پیشنهادی |
|---|---|
| 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
Health Check را فراموش نکنید
اگر چند Backend دارید، Health Check بسیار مهم است. بدون Health Check درست، FortiWeb ممکن است همچنان ترافیک را به سروری ارسال کند که سرویس روی آن Down است یا پاسخ HTTP اشتباه برمیگرداند.
Server Objects → Health Check
برای شروع، Health Check ساده میتواند فقط TCP/443 را بررسی کند؛ اما برای سامانههای حساس بهتر است مسیر واقعی مانند صفحه لاگین یا Health Endpoint بررسی شود.
GET /health
7. مرحله سوم: تعریف Protected Host Names
Protected Host مشخص میکند FortiWeb کدام مقدار Host Header را برای این سرویس معتبر بداند. اگر سرویس با FQDN مشخص منتشر میشود، تعریف Protected Host کمک میکند درخواستهایی که برای Hostهای ناشناس یا اشتباه ارسال شدهاند، در همان لایه WAF کنترل شوند.
Server Objects → Protected Hosts → Create New
| فیلد | مقدار پیشنهادی |
|---|---|
| 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
نکته عملیاتیProtected Host با Real Server فرق دارد. Protected Host مربوط به Host Header و نامی است که کاربر در لایه HTTP استفاده میکند؛ اما Real Server معمولاً IP خصوصی سرور داخلی است که FortiWeb به آن Forward میکند.
8. مرحله چهارم: آمادهسازی Certificate و HTTPS
اگر قرار است کاربران با HTTPS به سامانه وصل شوند، Certificate باید روی FortiWeb وجود داشته باشد. این Certificate میتواند یک گواهی برای همان FQDN، یک Wildcard Certificate یا یک SNI Configuration باشد.
System → Certificates → Local → Import
برای سناریوی ساده، یک 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 فعال شود. |
9. مرحله پنجم: انتخاب Web Protection Profile اولیه
Web Protection Profile مجموعه تنظیمات امنیتی FortiWeb است. در شروع کار، اگر شناخت کاملی از رفتار برنامه ندارید، بهتر است Profile را با حالت محافظهکارانه و مانیتورینگ فعال کنید؛ سپس بعد از بررسی لاگها، Actionها را سختگیرانهتر کنید.
برای کانفیگ اولیه، این رویکرد توصیه میشود
- Signatureها ابتدا در حالت Alert یا Monitor بررسی شوند.
- HTTP Protocol Constraint با مقادیر خیلی سختگیرانه شروع نشود.
- Parameter Validation فقط وقتی فعال شود که پارامترهای برنامه شناخته شده باشند.
- Bot Mitigation ابتدا با دقت و روی مسیرهای مشخص مثل Login فعال شود.
- Upload/Download Pathها جداگانه بررسی شوند.
هشداراشتباه رایج این است که همزمان با انتشار اولیه، همه ماژولهای امنیتی روی Block قرار میگیرند. این کار ممکن است باعث False Positive و اختلال در سرویس شود. بهتر است ابتدا Visibility و لاگ کامل ایجاد شود، بعد Policy سختگیرانهتر شود.
10. مرحله ششم: ساخت Server Policy
حالا که Virtual Server، Server Pool، Protected Host، Certificate و Web Protection Profile آماده شدند، میتوان Server Policy را ساخت. این Policy تعیین میکند ترافیک HTTPS ورودی روی Virtual Server به Server Pool داخلی ارسال شود و در مسیر، Web Protection Profile روی آن اعمال شود.
Policy → Server Policy → Server Policy → Create New
| فیلد | مقدار پیشنهادی |
|---|---|
| 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
- set web-protection-profile "WPP-App-Initial-Monitor"
- set monitor-mode enable
- set client-real-ip disable
- set syncookie enable
- next
- end
نکتهنام برخی سرویسها، گواهیها و پروفایلها ممکن است در محیط شما متفاوت باشد. پیش از اجرای CLI، نام دقیق آبجکتها را با فرمانهای show یا edit ? بررسی کنید.
چه زمانی Client Real IP را فعال کنیم؟
در حالت Reverse Proxy، معمولاً Backend ترافیک را از IP FortiWeb میبیند. اگر لازم باشد Backend IP واقعی کاربر را به عنوان Source IP شبکهای ببیند، میتوان Client Real IP را فعال کرد؛ اما باید مسیر بازگشتی درست باشد و معمولاً Backend باید FortiWeb را به عنوان Gateway ببیند. در بسیاری از سناریوها، استفاده از Headerهایی مانند X-Forwarded-For برای ثبت IP واقعی کاربر کافی و کمریسکتر است.
11. تست، لاگ و عیبیابی اولیه
بعد از ساخت 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/
مواردی که باید در لاگ بررسی شود
- آیا Traffic Log برای درخواستها ثبت میشود؟
- آیا Attack Log برای Signature Match یا Policy Violation ایجاد میشود؟
- آیا Actionها در آغاز کار بیشتر Alert هستند یا Deny؟
- آیا Host Header درست دیده میشود؟
- آیا Backend Latency یا Server Response Time غیرعادی است؟
- آیا خطاهای SSL Handshake وجود دارد؟
Log & Report → Log Access → Traffic
Log & Report → Log Access → Attack
12. اشتباهات رایج در کانفیگ اولیه FortiWeb
| اشتباه رایج | نتیجه احتمالی | راهحل |
|---|---|---|
| اشتباه گرفتن 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 وارد کنید. |
13. Best Practice پیشنهادی XNET
- برای هر سامانه مهم، Server Policy جدا بسازید و از Policyهای عمومی برای همه سرویسها استفاده نکنید.
- نامگذاری را استاندارد کنید؛ مثلاً VS، POOL، HOST، WPP و SP در ابتدای نام آبجکت مشخص باشد.
- در مرحله اول انتشار، Web Protection Profile را با Actionهای کمریسکتر شروع کنید و بعد از تحلیل لاگها سختگیرانهتر کنید.
- برای هر FQDN، Protected Host تعریف کنید تا Host Headerهای نامعتبر کنترل شوند.
- اگر Backend با HTTPS کار میکند، SSL سمت Backend و در صورت نیاز Certificate Verification را جداگانه بررسی کنید.
- برای سرویسهای حساس، Health Check فقط TCP نباشد و مسیر واقعی سرویس را بررسی کند.
- دسترسی مستقیم کاربران به Backend باید در Firewall یا Routing محدود شود.
- قبل از تحویل سرویس، Traffic Log، Attack Log و ارسال لاگ به FortiAnalyzer تست شود.
14. چکلیست نهایی قبل از تحویل سرویس
| مورد | وضعیت مطلوب |
|---|---|
| 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 از بیرون یا شبکههای غیرمجاز بسته شده باشد. |
برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمایپشتیبانی شبکهرا نیز مطالعه کنید.