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

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

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

طراحی Health Monitor درست در F5 BIG-IP؛ فقط TCP کافی نیست

طراحی Health Monitor درست در F5 BIG-IP؛ فقط TCP کافی نیست

پاسخ کوتاه: Health Monitor در F5 BIG-IP نباید فقط باز بودن یک پورت را چک کند. مانیتور خوب باید همان رفتاری را بسنجد که برای کاربر مهم است: پاسخ درست HTTP، سلامت سرویس پشت Pool، وضعیت SSL، زمان پاسخ و تفاوت بین خطای واقعی و کندی موقت. در طراحی لودبالانسر، خیلی وقت‌ها همه توجه روی Virtual Server و Pool می‌رود، اما تصمیم نهایی برای خارج کردن یک سرور از مسیر ترافیک را Health Monitor می‌گیرد. اگر این بخش ساده یا اشتباه طراحی شود، F5 می‌تواند ترافیک را به سروری بفرستد که از بیرون «زنده» دیده می‌شود اما برنامه واقعی روی...

عیب‌یابی Deploy نشدن Policy در Cisco FMC/FTD

عیب‌یابی Deploy نشدن Policy در Cisco FMC/FTD

تصویر شاخص عیب‌یابی Deploy نشدن Policy در Cisco FMC و FTD پاسخ کوتاه: وقتی Policy در Cisco FMC روی FTD deploy نمی‌شود، اول باید خطای deploy، وضعیت health دستگاه، ارتباط FMC و FTD، تغییرات pending و objectهای وابسته بررسی شود. تغییر دادن چند policy هم‌زمان معمولاً عیب‌یابی را سخت‌تر می‌کند. در Firepower، deploy فقط یک دکمه ساده نیست. پشت آن Access Control Policy، NAT، intrusion policy، file policy، platform settings، identity و objectهای مشترک قرار دارد. اگر یکی از این بخش‌ها ناسازگار باشد، deploy ممکن است fail شود یا روی یک دستگاه از چند دستگاه انجام نشود. چرا Deploy در...

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

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

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

Persistence در F5 چیست و چه زمانی Source Address یا Cookie بهتر است؟

Persistence در F5 چیست و چه زمانی Source Address یا Cookie بهتر است؟

پاسخ کوتاه: Persistence در F5 BIG-IP برای نگه داشتن کاربر روی همان عضو Pool استفاده می‌شود. اگر برنامه به session سمت سرور وابسته باشد، نبودن Persistence می‌تواند باعث logout، خطای سبد خرید، خطای فرم یا رفتار ناپایدار کاربر شود. Load Balancing فقط تقسیم ترافیک نیست. در خیلی از سرویس‌های واقعی، باید بدانیم آیا هر درخواست می‌تواند به هر سروری برود یا کاربر بعد از اتصال اول باید به همان backend برگردد. اینجاست که Persistence در F5 مهم می‌شود. Persistence در F5 دقیقاً چه کاری انجام می‌دهد؟ وقتی یک کاربر به Virtual Server وصل می‌شود، F5 بر اساس روش load balancing...

امن‌سازی دسترسی مدیریتی FortiGate؛ اشتباهاتی که نباید انجام داد

امن‌سازی دسترسی مدیریتی FortiGate؛ اشتباهاتی که نباید انجام داد

پاسخ کوتاه: دسترسی مدیریتی FortiGate باید فقط از مسیرهای مشخص، کاربران مشخص و با لاگ قابل بررسی انجام شود. اگر پنل مدیریت روی اینترنت باز باشد، حتی با رمز قوی هم ریسک غیرضروری به شبکه اضافه می‌شود. در خیلی از شبکه‌ها خود فایروال از سرورها مهم‌تر است؛ چون مسیر ترافیک، VPN، NAT، Policy و لاگ‌های امنیتی از آن عبور می‌کند. به همین دلیل امن‌سازی دسترسی مدیریتی FortiGate یک کار تزئینی نیست؛ بخشی از hardening پایه فایروال است. چرا دسترسی مدیریتی FortiGate حساس است؟ حساب مدیریتی FortiGate می‌تواند Policy را تغییر دهد، مسیرها را دستکاری کند، VPN بسازد، لاگ‌ها را پاک...