عیب‌یابی FortiWeb با لاگ و Request؛ از تشخیص Block تا اصلاح Policy

عیب‌یابی FortiWeb وقتی ارزش دارد که از روی حدس جلو نرویم. اگر یک کاربر خطای 403 می‌گیرد، یک API ناگهان جواب نمی‌دهد، یا لاگ حمله زیاد شده، اولین واکنش نباید خاموش کردن Rule یا بردن کل Policy به Monitor باشد. باید مشخص شود کدام Request، روی کدام Server Policy، با کدام Signature یا Constraint گیر کرده و آیا Block درست بوده یا false positive.

این مطلب برای سناریوهای عملیاتی نوشته شده؛ جایی که FortiWeb در مسیر سرویس واقعی است و هم امنیت مهم است، هم قطعی سرویس قابل قبول نیست. برای طراحی کلی‌تر معماری، صفحه طراحی استقرار FortiWeb در سازمان مسیر قبل از اجرا را توضیح می‌دهد.

اول مسئله را با یک نمونه Request واقعی محدود کنید

تا وقتی نمونه Request ندارید، عیب‌یابی بیشتر شبیه حدس زدن است. حداقل باید زمان خطا، دامنه، URL، IP مبدا، نام کاربر یا session، status code و رفتار مرورگر یا کلاینت API مشخص باشد. اگر تیم برنامه‌نویسی فقط بگوید «WAF دارد می‌بندد»، هنوز داده کافی برای تغییر Policy ندارید.

• آیا همه کاربران مشکل دارند یا فقط یک مسیر خاص؟
• آیا فقط متدهایی مثل POST، PUT یا upload درگیر هستند؟
• آیا خطا بعد از تغییر برنامه، تغییر certificate، تغییر load balancer یا آپدیت Signature شروع شده؟
• آیا Request از مسیر proxy یا CDN با headerهای متفاوت وارد می‌شود؟

لاگ را با Policy و Rule همان Request بخوانید

در FortiWeb فقط دیدن عبارت Block کافی نیست. باید بفهمید تصمیم روی کدام لایه گرفته شده: Signature، URL Access، Parameter Validation، Cookie Security، Bot، IP Reputation، File Upload یا Constraintهای مربوط به Size و Encoding. اگر لاگ را از Policy جدا بخوانید، احتمال دارد Rule اشتباه را تغییر بدهید.

time: 2026-06-18 14:35
host: app.example.com
url: /api/customer/update
method: POST
source_ip: 203.0.113.50
server_policy: app-prod-policy
action: Block
trigger: SQL Injection Signature / Parameter Constraint
request_id: keep-the-log-reference

این قالب ساده کمک می‌کند بعداً بدانید تغییری که داده‌اید دقیقاً برای چه رخدادی بوده، نه اینکه بعد از چند هفته یک Exception بی‌صاحب در Policy بماند.

False Positive را با Exception محدود حل کنید، نه با خاموش کردن دفاع

اشتباه رایج این است که برای حل سریع خطا، Signature یا Protection Profile را کلی غیرفعال کنیم. این کار شاید سرویس را برگرداند، اما WAF را کور می‌کند. راه بهتر این است که exception فقط برای همان host، همان URL، همان parameter و همان رفتار سالم اعمال شود. اگر برنامه واقعاً payload غیرمعمول دارد، مستندسازی کنید چرا exception لازم است و چه زمانی باید دوباره بررسی شود.

• Exception را تا حد ممکن روی URL و parameter مشخص محدود کنید.
• برای APIها، تفاوت JSON، form-data و file upload را جدا بررسی کنید.
• اگر چند Signature همزمان match می‌شوند، اول ریشه مشترک را پیدا کنید.
• بعد از تغییر، همان Request قبلی و چند Request سالم دیگر را تست کنید.

از Monitor به Block با معیار حرکت کنید

برای سرویس تازه، بهتر است مدتی رفتار واقعی در Monitor دیده شود، اما Monitor نباید به حالت دائمی تبدیل شود. باید معیار داشته باشید: تعداد رخدادهای false positive، مسیرهای پرتکرار، نوع حمله‌های واقعی، تغییرات برنامه و توان تیم برای بررسی لاگ. مطلب حرکت مرحله‌ای FortiWeb از Monitor تا Block همین مسیر را کامل‌تر توضیح می‌دهد.

وقتی FortiWeb پشت F5 یا Load Balancer است

در معماری‌هایی که F5 BIG-IP یا یک load balancer دیگر جلوی FortiWeb قرار دارد، باید source IP، headerهای اصلی، TLS termination و health checkها روشن باشد. اگر FortiWeb IP همه کاربران را IP لودبالانسر ببیند، تحلیل لاگ و IP-based control کیفیت خود را از دست می‌دهد. همچنین health check لودبالانسر نباید با Ruleهای WAF اشتباه Block شود.

برای سناریوهای ترکیبی، صفحه مشاوره و پیاده‌سازی WAF مسیر طراحی FortiWeb، F5 ASM و کنترل false positive را کنار هم توضیح می‌دهد.

منبع رسمی

برای جزئیات محصول، نسخه‌ها و قابلیت‌ها، مستندات رسمی Fortinet FortiWeb documentation مرجع اصلی است. در محیط واقعی، تصمیم نهایی باید با نسخه FortiWeb، نوع استقرار و Policy فعال همان سازمان تطبیق داده شود.