در FortiWeb هر block یا خطای کاربر الزاماً از Signature یا WAF Profile شروع نمیشود. اگر SSL termination، SNI، certificate chain یا Server Policy درست طراحی نشده باشد، درخواست قبل از رسیدن به تحلیل امنیتی مسیر اشتباه میرود. نتیجه برای کاربر ممکن است خطای TLS، صفحه ۴۰۳، redirect عجیب یا رفتار ناپایدار بین چند دامنه باشد.
اول Server Policy را ثابت کنید
Server Policy در FortiWeb نقطه اتصال دامنه، certificate، protected host، server pool و protection profile است. اگر چند سایت یا API پشت یک FortiWeb هستند، باید روشن باشد هر Host/SNI به کدام policy میخورد. قبل از تغییر دادن signatureها، یک درخواست نمونه را با Host header واقعی و همان مسیر production بررسی کنید.
- نام دامنه و SNI با certificate و protected host همخوان است؟
- درخواست به Server Pool درست میرسد یا به pool عمومی/قدیمی؟
- SSL offload یا SSL inspection با نیاز همان سرویس هماهنگ است؟
- redirect از HTTP به HTTPS در FortiWeb انجام میشود یا پشت سرور اصلی؟
- Exceptionها برای path خاص هستند یا ناخواسته کل دامنه را ضعیف کردهاند؟
نشانههای مشکل SNI یا Certificate
اگر فقط بعضی کلاینتها خطا میگیرند، اگر یک دامنه روی چند آدرس رفتار متفاوت دارد، یا اگر بعد از اضافه شدن دامنه جدید خطاها شروع شده، باید SNI و certificate chain را جداگانه بررسی کرد. در محیطهایی که چند دامنه روی یک IP هستند، نبودن SNI یا match اشتباه میتواند درخواست را به policy نادرست ببرد. اینجا خاموش کردن WAF Profile مشکل را ریشهای حل نمیکند.
روش کمریسک برای اصلاح
بهتر است تغییرها از مسیر کمریسک شروع شود: اول نام دامنه و certificate درست شود، بعد server pool و health check بررسی شود، بعد فقط برای endpoint مشکلدار exception محدود ساخته شود. اگر API دارید، موضوع token، JSON body و rate limit باید جدا از SSL بررسی شود؛ برای این بخش، مطلب حفاظت API با FortiWeb ادامه مناسبتری است.
برای خطاهای مربوط به block یا false positive، بهتر است این مقاله را کنار عیبیابی FortiWeb با لاگ و Request و کاهش False Positive در FortiWeb بخوانید. اگر هدف طراحی کاملتر WAF است، صفحه مشاوره و پیادهسازی WAF مسیر خدماتی را توضیح میدهد.
تفاوت خطای SSL با خطای WAF را جدا کنید
اگر کاربر قبل از لود شدن کامل صفحه خطای TLS میگیرد، مشکل احتمالاً هنوز به WAF rule نرسیده است. اما اگر صفحه باز میشود و فقط یک endpoint خاص block میشود، بررسی request log و signature منطقیتر است. این تفکیک ساده جلوی یک اشتباه رایج را میگیرد: خاموش کردن protection profile برای مشکلی که از certificate یا SNI آمده است.
در محیطهایی که چند دامنه پشت FortiWeb هستند، باید برای هر دامنه یک مسیر روشن وجود داشته باشد: کدام certificate ارائه میشود، کدام protected host match میشود، کدام server policy فعال است و درخواست بعد از offload به کدام backend میرود. اگر backend خودش redirect یا HSTS دارد، این رفتار باید با FortiWeb هماهنگ شود؛ وگرنه کاربر بین HTTPS، HTTP و چند hostname مختلف میچرخد.
چکلیست کمریسک قبل از تغییر Policy
- با همان hostname واقعی production تست بگیرید، نه فقط IP.
- certificate chain و تاریخ اعتبار گواهی را جدا بررسی کنید.
- Server Pool و Health Check را قبل از Profile امنیتی بخوانید.
- اگر فقط یک path مشکل دارد، exception را به همان path محدود کنید.
- برای APIها، تفاوت خطای احراز هویت، rate limit و signature را جدا کنید.
این ترتیب کمک میکند FortiWeb بهجای یک جعبه سیاه، به یک لایه قابل تحلیل تبدیل شود. هدف این نیست که هر block سریع حذف شود؛ هدف این است که block درست بماند و فقط خطای واقعی، با کمترین سطح استثنا اصلاح شود.
منبع فنی
برای معماری policy و مفاهیم FortiWeb، مستند رسمی Fortinet در FortiWeb Administration Guide مرجع پایه است. در تغییرات عملی، بهتر است قبل از اعمال تنظیمات SSL یا policy از پیکربندی backup گرفته شود.
جایی که SSL، SNI و Server Policy به هم گره میخورند
در FortiWeb، match نشدن Server Policy همیشه به معنی مشکل در خود WAF Profile نیست. در بسیاری از سناریوها، قبل از رسیدن درخواست به Ruleهای امنیتی، تصمیم اصلی در لایه SSL، certificate، hostname و SNI گرفته میشود. اگر certificate درست انتخاب نشود، اگر hostname با server policy همخوان نباشد، یا اگر client بدون SNI وصل شود، نتیجهای که در log میبینید ممکن است شبیه خطای policy باشد ولی ریشه در TLS termination داشته باشد.
چکهای عملی قبل از تغییر WAF Profile
قبل از اینکه profileهای امنیتی را تغییر دهید، اول chain گواهی، SAN/CN certificate، تنظیمات HTTPS service، server pool و ترتیب policyها را بررسی کنید. یک تست مستقیم با hostname واقعی و یک تست با IP خام میتواند تفاوت رفتار SNI را نشان دهد. اگر چند دامنه روی یک VIP قرار دارند، باید مطمئن شوید policy درست برای همان hostname فعال است و default policy ناخواسته ترافیک را نمیگیرد. در محیطی که reverse proxy یا load balancer جلوی FortiWeb وجود دارد، headerها و scheme واقعی هم باید بررسی شوند.
تغییر کمریسک معمولاً از اصلاح نام دامنه، certificate mapping، server pool یا ترتیب policy شروع میشود؛ نه خاموش کردن ruleهای امنیتی. اگر مجبور شدید برای تست یک گزینه امنیتی را موقتاً تغییر دهید، بازه زمانی، دلیل، نتیجه و مسیر بازگشت را همان لحظه ثبت کنید. هدف این است که عیبیابی SSL باعث کاهش سطح امنیت WAF نشود.
