راه‌اندازی FortiWeb بدون دردسر False Positive؛ از Monitor تا Block

پاسخ کوتاه: راه‌اندازی FortiWeb را بهتر است با حالت monitor و لاگ دقیق شروع کنید، بعد ruleها و exceptionها را محدود و قابل دفاع تنظیم کنید، و فقط وقتی الگوی خطاها روشن شد به block بروید. رفتن مستقیم به block معمولاً باعث false positive و فشار عملیاتی می‌شود.

FortiWeb وقتی درست تنظیم شود، جلوی بخش مهمی از حملات وب را می‌گیرد؛ اما اگر بدون شناخت برنامه فعال شود، ممکن است فرم‌های سالم، APIها، آپلود فایل یا حتی login کاربران را مختل کند. هدف این نوشته این است که مسیر عملی و کم‌ریسک از مانیتورینگ تا بلاک کردن را روشن کند.

چرا شروع با Monitor منطقی‌تر است؟

در حالت monitor، FortiWeb رفتار برنامه را می‌بیند و لاگ می‌سازد، بدون اینکه فوراً مسیر کاربر را قطع کند. این مرحله برای شناخت URLهای حساس، پارامترها، الگوی درخواست‌ها، ربات‌ها و رفتار خطاهای واقعی لازم است. اگر از روز اول block فعال شود، تیم فنی مجبور می‌شود بین امنیت و در دسترس بودن سرویس یکی را انتخاب کند؛ در حالی که تنظیم درست WAF باید هر دو را حفظ کند.

چه چیزهایی را در لاگ FortiWeb باید ببینیم؟

• کدام URLها بیشترین alert یا violation را دارند.
• خطاها مربوط به کدام پارامتر، cookie، header یا file upload هستند.
• آیا request از کاربر واقعی، ربات، اسکنر یا ابزار تست امنیتی آمده است.
• کدام ruleها تکراری فعال می‌شوند و آیا واقعاً به همان برنامه مربوط‌اند.
• آیا خطا فقط روی یک مسیر حساس مثل login یا payment رخ می‌دهد یا در کل سایت پخش است.

مسیر پیشنهادی از Monitor تا Block

1. Baseline بگیرید: چند روز لاگ normal traffic را ببینید تا رفتار عادی برنامه مشخص شود.
2. Ruleهای پرخطا را جدا کنید: همه چیز را با هم تغییر ندهید؛ اول ruleهایی را بررسی کنید که بیشترین اثر روی کاربران دارند.
3. Exception محدود بسازید: اگر یک parameter سالم خطا می‌گیرد، فقط همان parameter یا URL را استثنا کنید، نه کل signature را برای کل سایت.
4. Block را مرحله‌ای فعال کنید: مسیرهای کم‌ریسک‌تر را زودتر block کنید و مسیرهای حساس را بعد از تست بیشتر ببرید.
5. بعد از هر تغییر لاگ را دوباره ببینید: نبودن شکایت کاربر کافی نیست؛ باید مطمئن شوید دفاع اصلی هم ضعیف نشده است.

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

• خاموش کردن signature به جای تنظیم exception: این کار سریع است اما سطح دفاع را بیش از حد پایین می‌آورد.
• یک policy برای همه مسیرها: API، پنل مدیریت، فرم عمومی و upload رفتار یکسانی ندارند.
• نادیده گرفتن تغییرات برنامه: هر release جدید می‌تواند الگوی request را عوض کند و WAF باید همراه آن بازبینی شود.
• اعتماد کامل به تنظیمات پیش‌فرض: تنظیمات پیش‌فرض شروع کار است، نه پایان طراحی امنیتی.
• نداشتن مالک تغییر: اگر معلوم نباشد چه کسی exception را چرا ساخته، بعداً پاک‌سازی policy سخت می‌شود.

چه زمانی آماده Block هستیم؟

وقتی لاگ‌های چند روزه نشان می‌دهد یک rule با درخواست‌های مخرب یا غیرعادی مرتبط است، false positive آن بررسی شده، exceptionهای محدود ساخته شده و مسیر rollback روشن است، می‌توان block را فعال کرد. بهتر است این تغییر در زمان کم‌ریسک انجام شود و همان روز لاگ‌ها چند بار بررسی شوند.

چک‌لیست ذهنی برای راه‌اندازی FortiWeb بدون دردسر False Positive

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

نویسنده: علیرضا عربیان، فعال در حوزه شبکه، امنیت شبکه و پیاده‌سازی FortiWeb، FortiGate، Cisco، Juniper و F5.

مسیر عملیاتی بعد از راه‌اندازی FortiWeb بدون دردسر False Positive

اگر موضوع شما از مطالعه آموزشی فراتر رفته و به اجرای پروژه نزدیک شده است، برای امنیت وب‌اپلیکیشن صفحه مشاوره و پیاده‌سازی WAF و برای بازبینی کلی زیرساخت صفحه طراحی امنیت شبکه و هاردنینگ زیرساخت سازمانی مسیر عملی‌تری می‌دهند.