کاهش False Positive در FortiWeb WAF؛ تنظیم امن بدون کور کردن دفاع

پاسخ کوتاه: برای کاهش False Positive در FortiWeb WAF نباید کل Signature یا Policy را بی‌هدف خاموش کرد. مسیر درست این است که لاگ را از روی URL، پارامتر، rule، client و response بررسی کنیم و فقط برای همان بخشِ مشکل‌دار exception محدود بسازیم.

در عمل، WAF وقتی ارزشمند است که هم حمله‌های واقعی را متوقف کند و هم مسیر کاربران واقعی را خراب نکند. اگر هر خطای برنامه با خاموش کردن یک ماژول بزرگ حل شود، بعد از مدتی FortiWeb فقط یک reverse proxy گران‌قیمت می‌شود. هدف این راهنما تنظیم دقیق است، نه کم کردن امنیت برای راحتی کوتاه‌مدت.

False Positive در FortiWeb یعنی چه؟

False Positive یعنی FortiWeb رفتاری را مشکوک یا مخرب تشخیص می‌دهد، اما آن درخواست در واقع بخشی از رفتار سالم برنامه است. نمونه رایج آن فرم‌هایی است که مقدار JSON، HTML، کاراکترهای خاص، query پیچیده یا فایل آپلود می‌فرستند و توسط ruleهای عمومی WAF block می‌شوند.

علت‌های رایج False Positive در WAF چیست؟

• فعال کردن signatureهای زیاد بدون شناخت دقیق برنامه
• نبودن profile جدا برای مسیرهای حساس مثل login، upload یا API
• ارسال کاراکترهای خاص در پارامترهایی که FortiWeb آن را SQLi یا XSS تفسیر می‌کند
• تغییر برنامه یا API بدون بازبینی policy
• اعتماد کامل به تنظیمات پیش‌فرض بدون مرحله learning و fine tuning
• نداشتن تفکیک بین alert، block و monitor در زمان تست

چک‌لیست سریع کاهش False Positive در FortiWeb

• اول لاگ block شده را با زمان، IP، host، URL، parameter و rule ID جدا کنید.
• مشخص کنید مشکل از signature است یا محدودیت‌هایی مثل file type، size، parameter length یا cookie.
• به‌جای خاموش کردن کل protection، exception را روی URL، parameter یا profile محدود کنید.
• اگر تغییر برنامه باعث خطا شده، policy را با نسخه جدید برنامه هماهنگ کنید.
• قبل از block سخت‌گیرانه، ruleهای پرریسک را مدتی در حالت alert یا monitor بررسی کنید.
• بعد از هر exception، یک تست منفی ساده انجام دهید تا همان مسیر واقعاً بی‌دفاع نشده باشد.

روش بررسی قدم‌به‌قدم در FortiWeb چگونه است؟

از لاگ شروع کنید. دنبال این نباشید که فقط «کدام کاربر خطا گرفته»؛ مهم‌تر این است که FortiWeb دقیقاً کدام rule را روی کدام بخش درخواست فعال کرده است. اگر چند لاگ مشابه برای یک URL دارید، نمونه‌ها را کنار هم بگذارید تا الگو مشخص شود: آیا همه روی یک parameter هستند؟ آیا فقط در upload رخ می‌دهد؟ آیا فقط درخواست‌های API مشکل دارند؟

بعد از پیدا کردن الگو، تغییر را کوچک نگه دارید. برای مثال اگر یک parameter خاص در مسیر مشخص باعث خطا می‌شود، exception را برای همان parameter بسازید. اگر rule را برای کل سایت خاموش کنید، شاید خطای کاربر حل شود، اما سطح دفاع برای بخش‌های دیگر هم بی‌دلیل پایین می‌آید.

چه زمانی exception امن است؟

exception وقتی قابل دفاع است که دامنه آن مشخص باشد: فقط یک host، یک URL، یک parameter، یک method یا یک profile مشخص. اگر exception به این شکل تعریف شود، هم مشکل کاربر حل می‌شود و هم WAF برای بقیه مسیرها فعال می‌ماند. exceptionهای کلی مثل «خاموش کردن XSS برای کل سایت» معمولاً نشانه عجله یا نبود لاگ کافی هستند.

اشتباهات رایج در تنظیم FortiWeb

• خاموش کردن کامل Signature: این کار سریع است، اما معمولاً بیش از حد لازم دفاع را کم می‌کند.
• اعتماد به یک لاگ منفرد: ممکن است یک خطا اتفاقی باشد. چند نمونه نزدیک به هم تصویر دقیق‌تری می‌دهد.
• نداشتن تست برگشتی: بعد از exception باید مسیر سالم و سناریوی حمله ساده را دوباره بررسی کرد.
• یکی دانستن همه برنامه‌ها: پنل ادمین، API و فرم عمومی رفتار متفاوتی دارند و profile جدا می‌خواهند.

جمع‌بندی عملی

در FortiWeb، کاهش False Positive یعنی دقیق‌تر کردن WAF، نه ضعیف‌تر کردن آن. مسیر درست این است: لاگ دقیق، تشخیص rule، exception محدود، تست دوباره و مستندسازی تغییر. برای طراحی پایه WAF می‌توانید راهنمای پیکربندی و عیب‌یابی FortiWeb WAF و صفحه اصلی آموزش FortiWeb را هم ببینید. اگر موضوع شما به hardening کلی برنامه مربوط است، مقاله امنیت نرم‌افزارهای کاربردی مکمل خوبی است.

واژه‌نامه کوتاه

• False Positive: تشخیص اشتباه یک رفتار سالم به عنوان حمله.
• Signature: الگوی تشخیص حمله یا رفتار مشکوک در WAF.
• Exception: استثنای محدود برای یک مسیر، پارامتر یا rule مشخص.
• Learning: دوره مشاهده رفتار عادی برنامه برای تنظیم دقیق‌تر policy.

درباره نویسنده

این یادداشت فنی توسط علیرضا عربیان برای مدیران شبکه و امنیت نوشته شده است؛ با تمرکز روی تنظیم قابل دفاع WAF، کاهش خطای عملیاتی و حفظ سطح امنیت برنامه.