WAF Tuning؛ کاهش False Positive و استقرار امن Ruleها

قانون WAF جدید را ساعت ۱۰ فعال می‌کنید و نمودار حمله پایین می‌آید؛ اما هم‌زمان پرداخت کاربران یک اپراتور، آپلود فایل رزومه و Webhook شریک تجاری هم ۴۰۳ می‌شوند. داشبورد فقط «Block بیشتر» را موفقیت نشان می‌دهد، در حالی که کسب‌وکار از دسترس خارج شده است. WAF Tuning یعنی همین فاصله میان Match و دفاع واقعی را اندازه بگیرید.

این راهنما برای تیمی است که WAF دارد و می‌خواهد Ruleها را بدون ایجاد قطعی تنظیم کند. از قرارداد ترافیک و Threat model شروع می‌کنیم، Anomaly scoring و Paranoia level را از Threshold جدا می‌کنیم، Exclusion کم‌دامنه می‌سازیم، Rate limit و Bot challenge را با هویت درست اعمال می‌کنیم و هر تغییر را از Count/Preview تا Canary، Block و Rollback پیش می‌بریم.

WAF Tuning چیست و چه مسئله‌ای را حل می‌کند؟

WAF درخواست HTTP/HTTPS را در یک نقطه از مسیر بررسی و بر اساس Rule یا Model عملی مانند Log، Count، Challenge، Rate limit یا Block انجام می‌دهد. Tuning چرخه تبدیل Rule عمومی به Policy متناسب با Application است:

Inventory → Traffic contract → Threat hypothesis → Detect/Count
→ Ground truth → Narrow tuning → Canary mitigation
→ Outcome verification → Monitor → Update/Retire

این مقاله فرض می‌کند جای WAF در معماری، Network firewall، TLS termination و Origin protection را می‌شناسید. برای انتخاب نوع و استقرار پایه، ابتدا راهنمای فایروال و WAF سایت را ببینید.

WAF چه کاری نمی‌تواند انجام دهد؟

فهرست جاری OWASP Top ۱۰:۲۰۲۵ شامل Broken Access Control، Security Misconfiguration، Software Supply Chain Failures، Injection و Insecure Design است. WAF فقط بخشی از سطح حمله را پوشش می‌دهد و جای برنامه AppSec نیست. OWASP Top 10:2025

اول Request path و نقطه مشاهده را ثبت کنید

Client → DNS → CDN/DDoS/Bot → Edge WAF → Load balancer
→ Origin WAF/Reverse proxy → App/API → Dependencies

دو WAF در مسیر ممکن است View متفاوت، Normalization متفاوت و Rule order متفاوت داشته باشند. مشخص کنید:

• TLS کجا باز می‌شود و هر لایه چه Header/Bodyای را می‌بیند؛
• Client IP از کدام Trusted proxy chain استخراج می‌شود؛
• Rewrite، URL decode و Body decompression کجا رخ می‌دهد؛
• حداکثر Body، Header و فایل قابل‌بررسی چقدر است؛
• Cache hit آیا از Origin WAF عبور می‌کند یا نه؛
• WebSocket، GraphQL، gRPC، multipart و streaming چگونه پوشش داده می‌شوند؛
• Fail-open/fail-closed هر جزء در قطعی چیست.

Rule را بر View واقعی WAF بنویسید، نه آنچه Application log بعد از Rewrite نشان می‌دهد. اختلاف Canonicalization می‌تواند هم False Positive و هم Bypass بسازد.

دارایی و Journey حیاتی را پیش از Rule فهرست کنید

Policy سراسری یکسان برای این Routeها معمولاً اشتباه است. Profile ورودی، Actor، احراز هویت، Cost هر درخواست و Tolerance هر Journey را جدا کنید.

Threat contract برای هر Rule

پیش از Expression یا Rule ID، این قرارداد را بنویسید:

«دفاع در برابر SQLi» بدون Route، Data، Action و Guardrail قابل‌تست نیست. Rule باید فرضیه‌ای درباره ریسک مشخص باشد.

Managed Rule، OWASP CRS یا Custom Rule؟

OWASP Core Rule Set مجموعه Ruleهای عمومی تشخیص حمله برای Engineهای سازگار است و هدفش پوشش گسترده با هشدار کاذب کم است؛ «عمومی» یعنی باید روی Application خودتان تنظیم شود. مخزن رسمی OWASP CRS

Anomaly scoring چگونه کار می‌کند؟

در حالت Anomaly، چند Rule ممکن است Match و Score اضافه کنند؛ تصمیم Block وقتی گرفته می‌شود که مجموع Score از Threshold عبور کند. بنابراین یک Request می‌تواند چند Detection داشته باشد، و Rule پرصدا لزوماً به‌تنهایی Block نکرده باشد.

نمونه تنظیم رسمی CRS هشدار می‌دهد افزایش Threshold باید موقت و برای Tuning باشد؛ راه بهتر، شناخت Match و Exclusion دقیق است. همچنین Paranoia level و Anomaly threshold دو محور جدا هستند. نمونه پیکربندی رسمی CRS

Paranoia level را چگونه بالا ببریم؟

PL بالاتر Ruleهای سخت‌گیرتر و Signal بیشتر می‌آورد، اما False Positive نیز معمولاً بیشتر می‌شود. مسیر امن:

1. PL پایه را با Threshold توصیه‌شده و Log کامل تثبیت کنید.
2. PL بعدی را فقط در Detection/Count فعال کنید.
3. Match را بر Route، Argument، Content-Type و Actor دسته‌بندی کنید.
4. False Positiveهای تکرارشونده را با Exclusion حداقلی اصلاح کنید.
5. Canary Route/Traffic را به Blocking PL جدید ببرید.
6. Guardrail کسب‌وکار و Detection coverage را مقایسه کنید.
7. در صورت موفقیت مرحله‌ای گسترش دهید؛ وگرنه Rollback کنید.

PL بالا برای همه سایت‌ها «امن‌تر» نیست. اگر تیم Log و Exclusion را نگهداری نمی‌کند، PL پرنویز می‌تواند به خاموش‌کردن کامل WAF منجر شود.

Count، Log و Preview؛ Deploy بدون اثر

Rule جدید ابتدا باید Match را ثبت کند، نه اینکه ترافیک را تغییر دهد. AWS WAF رسماً توصیه می‌کند تغییرها ابتدا در Test/Staging و سپس با ترافیک Production در Count mode تنظیم شوند. راهنمای رسمی Testing و Tuning در AWS WAF

اما Count mode به تنهایی Evidence کامل نیست:

• Sample ممکن است همه Requestها را نشان ندهد؛
• Action غیرTerminating باعث می‌شود Ruleهای بعدی هم Match کنند؛
• ترافیک Production همه Edge caseهای آینده را ندارد؛
• Match بدون Ground truth معلوم نمی‌کند Attack است یا Legitimate؛
• Log می‌تواند PII، Cookie، Token و Payload حساس داشته باشد.

Ground truth را چگونه بسازیم؟

برای نمونه‌های Matchشده Label انسانی یا قابل‌اعتماد بسازید:

Sample را فقط از Blockها برندارید؛ ترافیک Allow و مسیرهای کم‌ترافیک را نیز بررسی کنید. تیم Support، Fraud، Product و Developer در تشخیص Legitimate business flow نقش دارند.

False Positive rate را با مخرج درست بسنجید

«۱۰۰ درخواست اشتباه» بدون مخرج و اثر مفید نیست. چند Metric مکمل:

False Positive Rate = benign matches / all benign requests reviewed
False Block Rate = legitimate blocked requests / all legitimate requests
Rule Precision = confirmed malicious matches / all reviewed matches
Business harm = failed critical journeys attributable to WAF

Ground truth کامل در Production نادر است، پس Confidence و Sample method را همراه عدد گزارش کنید. نرخ را بر Route، Country/ASN، Client type، Release و Rule version تقسیم کنید.

Exclusion؛ باریک‌تر از Rule غیرفعال

وقتی Rule عمومی روی ورودی قانونی Match می‌کند، گزینه‌ها را از محدودترین به گسترده‌ترین بسنجید:

1. اصلاح Data/Content-Type یا Bug برنامه؛
2. حذف Target مشخص برای Rule مشخص؛
3. Exclusion Rule ID روی Argument و Route مشخص؛
4. Exclusion گروه Rule روی Route محدود؛
5. Skip یک Phase/Ruleset برای Client بسیار محدود؛
6. غیرفعال‌کردن Rule یا WAF سراسری، فقط آخرین راه.

هر Exclusion باید Rule ID، علت، Scope، Owner، Ticket، تاریخ انقضا و Test منفی داشته باشد. عبارت «این IP قابل‌اعتماد است» برای Skip همه کنترل‌ها کافی نیست؛ Credential یا IP شریک می‌تواند Compromise شود.

Rule order و Action termination

ترتیب Rule بخشی از Policy است. Actionهایی مانند Block می‌توانند ارزیابی بعدی را متوقف کنند؛ Log معمولاً Non-terminating است. Allow یا Skip در جای اشتباه ممکن است Managed rule، Rate limit یا Bot control را دور بزند.

در Cloudflare، Custom ruleها به‌ترتیب اجرا می‌شوند و Action پایان‌دهنده Ruleهای بعدی را متوقف می‌کند؛ Skip با Allow سراسری یکسان نیست و می‌تواند Phase یا Rule مشخصی را کنار بگذارد. مفاهیم و ترتیب اجرای رسمی Cloudflare WAF

Allowlist IP چرا خطرناک است؟

• IP ممکن است Shared، NAT، Proxy یا قابل‌تغییر باشد؛
• Credential روی همان Source می‌تواند سرقت شود؛
• Allow گسترده Telemetry و کنترل‌های بعدی را دور می‌زند؛
• IPv4/IPv6 و Proxy chain ممکن است Match متفاوت دهند؛
• Partner integration معمولاً Signature، mTLS یا OAuth هم لازم دارد.

به جای Allow کامل، Route، Method، Credential، Client certificate، Signature و Rule خاص را محدود کنید. Skip باید دقیقاً بگوید کدام کنترل کنار گذاشته می‌شود و بقیه همچنان اجرا شوند.

Rate limiting را بر Business flow طراحی کنید

آستانه «۱۰۰ درخواست در دقیقه برای هر IP» ممکن است هم مهاجم توزیع‌شده را عبور دهد و هم کاربران یک اپراتور پشت NAT را مسدود کند. Key و Cost را متناسب با Flow انتخاب کنید:

Rate limit باید پاسخ ۴۲۹ و Retry-After مناسب، Burst، Window و Recovery روشن داشته باشد. برای معماری Abuse و Bot پیشرفته، راهنمای مدیریت ربات مخرب را ببینید.

Bot score و AI تصمیم نهایی نیستند

مدل تشخیص می‌تواند Signal مفید بسازد، اما Score بدون نسخه، Feature، Context و Guardrail حقیقت قطعی نیست. Automation قانونی مانند Screen reader، Monitoring، Mobile WebView، API client و خزنده جست‌وجو ممکن است شبیه Bot دیده شود. Action ladder را متناسب با Confidence بسازید:

1. Log/label برای Confidence پایین؛
2. Throttle یا کاهش Cost برای متوسط؛
3. Managed challenge برای Browser سازگار؛
4. Step-up auth برای حساب حساس؛
5. Block موقت برای Evidence قوی و قابل‌بازبینی.

Challenge JavaScript/CAPTCHA برای API، Webhook، ابزار کمکی یا Browser محدود مناسب نیست. Accessibility، Privacy و امکان اعتراض کاربر را بسنجید.

API و WAF: مرز Gateway را روشن کنید

WAF می‌تواند Method، Path، Header، Body pattern، Rate و گاهی Schema را ببیند؛ اما Authorization سطح Object، مالکیت Field، State transition و Idempotency باید در API باشد. OWASP API Security، دسترسی نامحدود به Flowهای حساس مانند خرید موجودی محدود یا رزرو انبوه را مسئله طراحی کسب‌وکار می‌داند، نه صرفاً Signature مخرب. OWASP API6: Unrestricted Business Flows

برای کنترل‌های داخل Endpoint به چک‌لیست امن‌سازی Endpoint API و برای برنامه جامع به راهنمای امنیت API مراجعه کنید.

GraphQL را فقط با تعداد Request محدود نکنید

دو Query می‌توانند Cost بسیار متفاوت داشته باشند. Operation allowlist، persisted query، depth/node/alias limit، field cost، pagination cap، resolver budget و per-token quota را کنار WAF قرار دهید. Introspection policy را بر محیط و Client تعیین کنید؛ خاموش‌کردن آن جای Authorization نیست.

Upload و Body inspection

برای Upload این موارد را آزمایش کنید:

• حداکثر Body و رفتار Oversize: Continue، truncate، skip یا block؛
• multipart parser، boundary و filename encoding؛
• MIME ادعایی در برابر File signature؛
• فایل فشرده، nested archive و decompression bomb؛
• Malware scanning جدا و quarantine؛
• ذخیره خارج از Web root و نام تصادفی؛
• فارسی/Unicode در filename بدون شکستن Workflow؛
• Latency و Timeout برای فایل بزرگ.

اگر WAF فقط نخستین N بایت را می‌بیند، Dashboard نباید «فایل بررسی شد» گزارش کند. Coverage gap را صریح نگه دارید.

WebSocket، streaming و protocol gap

برخی WAFها فقط Handshake WebSocket یا Request اولیه را بررسی می‌کنند و Frameهای بعدی را نه؛ Streaming body نیز ممکن است کامل Buffer نشود. gRPC و HTTP/۲/۳ می‌توانند ترجمه یا محدودیت محصول متفاوت داشته باشند. از Vendor سند دقیق و PoC بخواهید؛ نام «WAF لایه ۷» پوشش همه Protocolها را تضمین نمی‌کند.

Origin bypass همه Ruleهای Edge را بی‌اثر می‌کند

اگر مهاجم IP یا Host اصلی را مستقیم بزند، Edge WAF دور زده می‌شود. Origin فقط ترافیک Edge معتبر و مسیرهای مدیریتی کنترل‌شده را بپذیرد؛ mTLS/Authenticated origin، Firewall allowlist به‌روز، Secret header به‌تنهایی ناکافی، Host validation و IPv6 را بررسی کنید. DNS قدیمی، Certificate transparency، Email header و Subdomain فراموش‌شده می‌توانند Origin را افشا کنند.

پیکربندی Edge، Cache و مسیر کاربران داخل ایران را با راهنمای CDN برای سایت ایرانی هماهنگ کنید.

WAF و DDoS را یکی ندانید

WAF لایه Application برای Payload و Flow مفید است، اما حمله حجمی ممکن است پیش از WAF لینک یا Origin را اشباع کند. Rate rule بد نیز زیر Flood هزینه Evaluation ایجاد می‌کند. لایه حمله، ظرفیت Edge، Origin protection، autoscaling و Cost attack را جدا تحلیل کنید. راهنمای مقابله با حملات DDoS معماری و Runbook آن را پوشش می‌دهد.

Log contract؛ چه چیزی ثبت شود؟

Token، Cookie، Authorization header، Password، کارت، کد OTP و Body کامل را Redact کنید. Sampling، Retention، دسترسی، محل ذخیره و حذف را تعریف کنید. Log خام برای همیشه «منبع طلایی» نیست؛ دارایی حساس و هزینه‌زا است.

Dashboard تنظیم WAF

Metric و Log را با Release و Incident در معماری Observability سایت پیوند دهید. نمودار WAF جدا از Outcome برنامه، False Positive را پنهان می‌کند.

SLO و Guardrailهای WAF

• نرخ موفقیت Login/Checkout/Upload از Baseline تعیین‌شده پایین‌تر نرود؛
• p95 Edge latency افزوده زیر بودجه بماند؛
• False block تأییدشده Route حیاتی زیر آستانه کسب‌وکار باشد؛
• Rule جدید فقط پس از Window و Sample کافی به Block برسد؛
• صددرصد Ruleها Owner، نسخه، دلیل و Rollback داشته باشند؛
• Virtual patch تا موعد مشخص با Fix ریشه‌ای جایگزین شود؛
• Alert WAF به Runbook و On-call قابل‌اقدام وصل باشد.

آستانه جهانی وجود ندارد. False block یک Webhook مالی و یک صفحه وبلاگ اثر یکسان ندارند. Risk tier و Error budget را به Route ببندید.

Pipeline تغییر Rule

1. Rule را به‌صورت Code/Config نسخه‌دار با ID یکتا ثبت کنید.
2. Lint، syntax، duplicate/shadow و Regex safety را اجرا کنید.
3. Corpus ترافیک Benign و Malicious را Replay کنید.
4. Test route، content type، encoding و bypass variants را اجرا کنید.
5. در Staging با Integration/E2E test بسنجید.
6. در Production Count/Preview و Ground truth بگیرید.
7. Canary محدود با Guardrail و Auto rollback فعال کنید.
8. Block را مرحله‌ای گسترش و نتیجه را Verify کنید.
9. پس از Window، Exclusion و Rule منقضی را Retire کنید.

Change باید Review امنیت، مالک Application و Operations را داشته باشد. Gate، Artifact، Evidence و Exception آن را در مدل عملیاتی DevSecOps سازمان ثبت کنید.

Corpus تست Rule چه چیزهایی دارد؟

تست حمله فقط در محیط و Scope مجاز انجام شود. تست نفوذ Production بدون Rules of Engagement می‌تواند Incident واقعی بسازد. برای طراحی Scope و Retest از راهنمای تست نفوذ وب‌اپلیکیشن استفاده کنید.

Regex و هزینه پردازش

Regex پیچیده می‌تواند Backtracking و Latency بسازد یا زیر ورودی خاص منبع را مصرف کند. Anchor، Length cap، operator ساده‌تر، prefilter و Engine-safe syntax را ترجیح دهید. Rule پرهزینه را بر Route لازم محدود کنید و با Payload حداکثر Benchmark بگیرید. «Match دقیق‌تر» اگر WAF را اشباع کند دفاع خوبی نیست.

نسخه Managed Rule را Pin یا Auto-update کنیم؟

Provider changelog، Rule ID change، default action و sunset را مانیتور کنید. نسخه تازه را مانند Release نرم‌افزار تست کنید؛ «Managed» به معنی بدون ریسک تغییر نیست.

Virtual patch باید تاریخ انقضا داشته باشد

وقتی آسیب‌پذیری فعال است و Patch هنوز Deploy نشده، Rule موقت می‌تواند Exposure را کم کند. اما Bypass، مسیر دیگر یا Payload جدید ممکن است عبور کند. Virtual patch باید به CVE/Finding، نسخه آسیب‌پذیر، Scope، Test، Owner، Patch plan و Expiry وصل باشد. پس از Fix و Retest، Rule را دوباره ارزیابی یا حذف کنید.

Performance WAF را End-to-end بسنجید

WAF ابری لزوماً کمترین Latency و WAF داخلی لزوماً کندتر نیست. فاصله Edge، TLS، Rule count/cost، Body buffering، Log export، Cache، Route و اپراتور کاربر نتیجه را عوض می‌کنند. قبل/بعد را با این Metricها مقایسه کنید:

• Edge processing و TTFB p50/p95/p99؛
• Cache hit/miss و Origin request rate؛
• WAF capacity/CPU یا Vendor unit؛
• Body size، upload duration و timeout؛
• Challenge solve/fail/abandon rate؛
• Cost به ازای میلیون Request و Log volume؛
• تجربه چند اپراتور و منطقه ایران.

پیکربندی برای کاربران ایران

• NAT اپراتور: Rate limit صرفاً IPمحور می‌تواند گروه بزرگی از کاربران را تنبیه کند؛ Account/session/device و Cost را بیفزایید.
• تغییر IP و شبکه: Challenge token، Session و failover شبکه موبایل را تست کنید.
• فارسی: نام، آدرس، Search، JSON و Multipart با Unicode/نیم‌فاصله را در Corpus Benign بگذارید.
• اختلال بین‌الملل: مسیر Edge، DNS، Control plane، API تنظیم Rule و دسترسی اضطراری را تمرین کنید.
• Webhook داخلی: PSP، پیامک و لجستیک نباید Browser challenge بگیرند؛ Signature/mTLS و Route محدود لازم است.
• محدودیت سرویس: Eligibility رسمی، قرارداد، پرداخت، Export Log/Rule و راه جایگزین را بررسی کنید؛ راه دورزدن هویت/محدودیت نسازید.
• حریم خصوصی: انتقال Log، IP، Cookie و Payload به Vendor خارجی را در Data map ثبت کنید.

پرسش‌نامه خرید/ارزیابی WAF برای Tuning

Runbook ۱: WAF پرداخت قانونی را Block می‌کند

1. Incident را با Rule ID، version، route، operator و request ID محدود کنید.
2. Rule را روی همان Scope به Count یا Exclusion حداقلی ببرید؛ WAF کل سایت را خاموش نکنید.
3. نمونه Redactشده و Journey موفق/ناموفق را مقایسه کنید.
4. Target/Argument یا Content-Type ایجادکننده Match را پیدا کنید.
5. Fix را با Test malicious/benign و Canary اعمال کنید.
6. Window حادثه، سفارش‌های ازدست‌رفته و Support impact را Reconcile کنید.

Runbook ۲: Rule update ناگهان Block را زیاد کرده است

1. نسخه و Changelog واقعی Provider را ثبت کنید.
2. Business success، false-block و attack trend را هم‌زمان ببینید.
3. به نسخه Pin قبلی Rollback یا Ruleهای مسئله‌دار را Count کنید.
4. Diff Rule/ID/action و Corpus regression را اجرا کنید.
5. نسخه جدید را در Shadow/Count با Exclusion دقیق دوباره بسنجید.
6. Auto-update policy و Canary coverage را اصلاح کنید.

Runbook ۳: Origin مستقیم دور زده شده است

1. IP/Host مسیر Bypass و Exposure را تأیید کنید.
2. Firewall را فقط به Range معتبر Edge و مسیر اضطراری محدود کنید.
3. Authenticated origin/mTLS و Host validation را فعال کنید.
4. DNS/Certificate/Subdomain/Repository/Log افشاکننده را جست‌وجو کنید.
5. IPv6 و سرویس‌های جانبی را هم ببندید.
6. پس از تغییر، Direct-origin negative test و Availability test اجرا کنید.

Runbook ۴: حمله Bot با IPهای توزیع‌شده عبور می‌کند

1. Flow و Business harm را تعریف؛ فقط Volume را نبینید.
2. Key را از IP به account/session/device/network و sequence گسترش دهید.
3. Cost-based limit، challenge ladder و step-up auth را Canary کنید.
4. False Positive کاربران NAT/Accessibility/Mobile را پایش کنید.
5. Backend rule برای inventory/payment/referral را سخت کنید.
6. پس از مهار، Fraud/reconciliation و Indicator retention را اجرا کنید.

Runbook ۵: WAF یا Control plane در دسترس نیست

1. مشخص کنید Data plane سالم است یا ترافیک Fail-open/closed شده.
2. SLO و Error را از Probe خارج Vendor بررسی کنید.
3. Change freeze و Credential اضطراری را فعال کنید.
4. در صورت معماری مجاز، مسیر Failover آزموده‌شده را اجرا کنید.
5. Origin را برای بازگرداندن سرویس عمومی نکنید.
6. پس از بازیابی، Config drift، Log gap و Rule version را Reconcile کنید.

RACI عملیات WAF

برنامه ۳۰ روزه Tuning اولیه

1. هفته اول: Request path، Route inventory، trusted proxy، body/protocol coverage و Rule/version را ثبت کنید.
2. هفته دوم: Managed/CRS Ruleها را Count، Log را Redact و Dashboard Business/WAF را هم‌زمان کنید.
3. هفته سوم: Ground truth، FP cluster، Exclusion محدود و Corpus فارسی/ماشین را بسازید.
4. هفته چهارم: دو Rule پرارزش را Canary Block، Guardrail و Rollback را تمرین و نتیجه را مستند کنید.

برنامه ۹۰ روزه Rule Operations

چک‌لیست پیش از Block کردن Rule

• Threat، Route، Actor، Outcome و Owner مشخص‌اند؛
• View واقعی WAF، Normalization و body/protocol limit معلوم است؛
• Rule/ruleset/version/action/order ثبت شده‌اند؛
• Count/Preview با Sample و Ground truth کافی اجرا شده است؛
• False Positive بر Journey و اپراتورهای ایران بررسی شده است؛
• Exclusion در کوچک‌ترین Scope و با Expiry است؛
• Corpus benign/malicious/evasion/machine/pass Persian پاس است؛
• Canary، Guardrail، Auto/manual rollback و emergency access آماده‌اند؛
• Log Redaction، Retention، Alert و Runbook وجود دارند؛
• Fix ریشه‌ای، Virtual patch expiry و Retest برنامه‌ریزی شده‌اند.

پرسش‌های متداول تنظیم پیشرفته WAF

WAF را مستقیم روی Block بگذاریم یا Count؟

Rule جدید یا نسخه جدید Managed rule ابتدا در Test/Staging و سپس روی ترافیک Production در Count/Preview ارزیابی شود. پس از Ground truth، اصلاح False Positive و تست Guardrail، آن را Canary و مرحله‌ای Block کنید. برای تهدید فعال می‌توان مسیر اضطراری کوتاه‌تر داشت، اما Rollback و Scope محدود لازم است.

Paranoia level بالاتر همیشه امن‌تر است؟

خیر. PL بالاتر Detection بیشتری فعال می‌کند اما معمولاً False Positive و هزینه Tuning را نیز بالا می‌برد. امنیت واقعی به Coverage، Threshold، Exclusion دقیق، توان عملیات و سالم‌ماندن Journey بستگی دارد. PL بعدی را ابتدا در Detection/Count بسنجید.

برای رفع False Positive یک Rule را خاموش کنیم؟

ترجیحاً نه. ابتدا Rule ID و Target/Argument مشکل‌ساز را روی Route و Actor مشخص محدود کنید. غیرفعال‌کردن سراسری Coverage را برای همه مسیرها از بین می‌برد. Exclusion باید Owner، دلیل، Test و تاریخ انقضا داشته باشد.

آیا WAF جلوی DDoS و ربات مخرب را می‌گیرد؟

WAF می‌تواند بخشی از حملات لایه ۷ و Automation را با Rate، Challenge و Rule کم کند، اما DDoS حجمی به دفاع شبکه/Edge و Bot abuse به Signal چندبعدی و کنترل Business flow نیاز دارد. IP rate limit یا CAPTCHA به‌تنهایی کافی نیست.

از کجا بفهمیم WAF درست تنظیم شده است؟

فقط از تعداد Block نه. باید Rule precision و False block را با Ground truth، موفقیت Login/Checkout/Upload، Latency، Attack test، Bypass test، Origin protection، Config drift و Rollback بسنجید. Rule بدون نسخه، Owner، Corpus و Guardrail قابل‌اعتماد نیست.

جمع‌بندی

WAF خوب سپری «هوشمند و کامل» نیست؛ یک Control قابل‌اندازه‌گیری در معماری دفاع چندلایه است. Rule عمومی باید با View واقعی ترافیک، Route، Actor و Business flow شما سازگار شود. Anomaly score، Paranoia level، Threshold و Action چهار تصمیم متفاوت‌اند و Exclusion دقیق از خاموش‌کردن Rule بهتر است.

چرخه پایدار این است: Threat contract، Count/Preview، Ground truth، Tuning کم‌دامنه، Corpus تست، Canary، Guardrail، Block مرحله‌ای، Monitoring و Retirement. اگر Rule را نمی‌توانید توضیح دهید، نسخه‌اش را نمی‌دانید یا Rollback آن تمرین نشده است، هنوز آماده Block کردن ترافیک کاربران واقعی نیست.