تیم امنیت یک موج Login را با Block کردن IP مهار میکند؛ همان روز، کاربران چند اپراتور موبایل ایران پشت NAT مشترک از حسابشان بیرون میمانند و Googlebot جعلی همچنان از IPهای دیگر Scrape میکند. داشبورد «۹۹٪ Bot blocked» سبز است، اما Account takeover ادامه دارد و False positive به فروش آسیب زده است. معیار موفقیت، تعداد Block نیست؛ کاهش سوءاستفاده با کمترین آسیب به کاربر و Bot مجاز است.
مدیریت ربات مخرب یعنی Business flowهای حساس را پیدا کنید، هزینه و سرعت سوءاستفاده را بالا ببرید، موفقیت حمله را در Truth source بسنجید و پاسخ را از Observe تا Limit، Challenge و Block متناسب کنید. تشخیص «انسان یا ربات» بهتنهایی هدف امنیتی خوبی نیست: انسان اجیرشده میتواند سوءاستفاده کند و Automation مجاز—Crawler جستوجو، Monitoring، شریک API یا ابزار دسترسپذیری—نباید کورکورانه حذف شود.
ربات مخرب چیست؟
Bot برنامه یا سامانهای است که کار را خودکار میکند. «بد» بودن از Technology یا Headless browser نمیآید؛ از نبود مجوز، نقض Policy، اثر نامطلوب و زمینه کسبوکار میآید. یک Crawler قیمت ممکن است برای شریک قراردادی مجاز و برای Scraper ناشناس نامجاز باشد. Automation تست شما نیز اگر Rate/Scope نادرست داشته باشد میتواند شبیه حمله عمل کند.
پروژه Automated Threats در OWASP بیستویک الگوی OAT از Credential stuffing و Scraping تا Scalping، Denial of inventory، Carding، Fake account، Spamming و Skewing را نامگذاری میکند. این Taxonomy از اصطلاح مبهم «Advanced Persistent Bot» عملیاتیتر است.
درصد ثابت Bot را به سایت خود تعمیم ندهید
گزارش Vendorها درباره سهم Bot به مشتری، Sensor، تعریف، Geography و دوره آنها وابسته است. عدد جهانی—۴۰٪ یا هر مقدار دیگر—Baseline شما نیست. ترافیک Static asset، Search crawler، API partner، Health check، Mobile app و Attack را جدا کنید و Coverage/Unknown را نشان دهید.
| برچسب | تعریف عملی | مثال | پاسخ پیشفرض |
|---|---|---|---|
| Verified automation | هویت و Purpose با روش مستقل تأیید شده | Googlebot تأییدشده، Monitoring شما | Allow با Quota/Scope |
| Authorized partner | Credential/Contract و Flow مشخص | API همکار | Auth، quota و audit |
| Benign unknown | اثر کم، هویت نامعلوم | Feed reader کوچک | Observe/limit نرم |
| Suspicious automation | Signalهای ناسازگار یا Velocity غیرعادی | Signup burst | Step-up/challenge |
| Confirmed abuse | Outcome نامطلوب/Policy violation ثابت | ATO، Carding، hoarding | Block/contain/respond |
تهدیدها را با Business flow دستهبندی کنید
| Flow | سوءاستفاده | دارایی/زیان | Truth signal |
|---|---|---|---|
| Login/Recovery | Stuffing، spraying، enumeration، ATO | حساب، اعتبار، موجودی/اعتبار | ورود موفق پرریسک، تغییر/برداشت |
| Signup/OTP | Fake account، SMS pumping، referral abuse | هزینه پیام، اعتبار کمپین | اکانت فعال/رفتار/هزینه Provider |
| Search/API | Scraping، aggregation، expensive query | داده، CPU، هزینه API | Coverage داده/Cost/latency |
| Cart/Inventory | Hoarding، scalping، denial of inventory | موجودی و فروش واقعی | Hold بدون خرید، release loop |
| Checkout/Payment | Carding، coupon/gift-card cracking | Chargeback، Gateway fee، reputation | Decline pattern/chargeback |
| Review/Ad/Content | Spam، fake review، click fraud، skewing | اعتماد و داده تصمیم | Moderation/fraud/invalid traffic |
| Availability | Layer ۷ DoS، resource exhaustion | SLO و هزینه | Queue/saturation/error/user failure |
OWASP API Top ۱۰ ۲۰۲۳، مصرف نامحدود منابع و دسترسی نامحدود به Flow حساس را جدا میکند؛ Bot abuse ممکن است بدون Vulnerability کلاسیک، صرفاً با استفاده بیشازحد از قابلیت قانونی رخ دهد.
Attack surface فقط صفحه وب نیست
Web، Mobile API، GraphQL، REST، gRPC-web، WebSocket، AJAX، legacy endpoint، subdomain، Origin IP و نسخه قدیمی را Inventory کنید. Bot میتواند UI و JavaScript را دور بزند و مستقیم API را صدا بزند. کنترل فقط روی CDN وقتی Origin قابلدسترسی است، bypass میشود.
| فیلد Inventory | نمونه | مالک |
|---|---|---|
| Route/Method/Version | POST /v2/login | API team |
| Business action | احراز، رزرو، ارسال OTP | Product |
| Cost unit | CPU-ms، DB query، SMS، Gateway call | Platform/Finance |
| Identity | Anonymous، account، partner، device | IAM |
| Allowed automation | Partner quota/monitoring | Business owner |
| Abuse outcome | ATO/stock hold/decline | Fraud/Security |
| Control/telemetry | Edge/WAF/app/risk/event | Shared |
Threat contract برای هر Flow
| فیلد | مثال Login |
|---|---|
| هدف مهاجم | تبدیل Credential نشتکرده به Session معتبر |
| واحد حمله | account × device/network × time |
| هزینه مهاجم | Proxy، Credential، CAPTCHA solving، زمان |
| Success evidence | ورود و اقدام پرخطر؛ نه فقط HTTP ۲۰۰ |
| کاربر خوب پرریسک | Travel/VPN/NAT/device reset/accessibility |
| Control ladder | rate→delay→step-up→MFA→block |
| Guardrail | auth success، recovery، support، latency |
| Runbook | contain session/account، evidence، notify، recover |
Signal بهتنهایی حقیقت نیست
| Signal family | نمونه | ضعف/سوگیری |
|---|---|---|
| Network | IP/ASN/Geo/proxy/reputation | NAT، VPN، IPv6 rotation، reputation stale |
| Protocol | TLS/HTTP/header order | قابل تقلید و تغییر Library |
| Client | JS capability، cookie، browser/device feature | Privacy، spoof، no-JS/assistive tools |
| Behavior | Velocity، sequence، timing، navigation | Power user/automation مجاز/Low traffic |
| Identity | Account age، auth strength، session history | Account compromise یا new user |
| Entity graph | account-device-IP-payment-address | خانواده/شرکت/NAT مشترک |
| Outcome | ATO، chargeback، hoarding، spam accepted | Lag و Label ناقص |
Fingerprint «شناسه منحصربهفرد و غیرقابلجعل» نیست. ممکن است تغییر کند، میان کاربران مشترک باشد یا برای حریم خصوصی حساس تلقی شود. Signalها را با Purpose limitation، Retention، Access، Confidence و امکان اعتراض/Recovery مدیریت کنید.
Risk score را به Action وصل کنید
هدف مدل، نمایش امتیاز نیست؛ انتخاب پاسخ متناسب است. Threshold را برای هر Flow جدا بسازید. همان Risk برای خواندن صفحه عمومی و برداشت اعتبار حساب پیامد یکسان ندارد.
| Risk/Confidence | Action | نمونه | Guardrail |
|---|---|---|---|
| کم | Allow + telemetry | Browse عادی | Cost baseline |
| متوسط | Rate/queue/cache/degrade | Search burst | Latency کاربر |
| بالا ولی نامطمئن | Managed challenge/step-up | Login از context جدید | solve/auth success |
| بالا و outcomeدار | Block/contain entity | Carding pattern | False decline |
| Incident | Revoke/recover/investigate | ATO موفق | کاربر مشروع/شواهد |
معماری دفاع چندلایه
Client → DNS/CDN/DDoS → Edge Bot/WAF → Gateway/API → Identity/Session → Business rule → Data/Payment → Telemetry/Response
هر لایه هزینهای را پیش از لایه گرانتر محدود کند، اما تصمیم Business-critical باید در برنامه نیز Enforcement شود. Edge ممکن است Request را بشناسد؛ فقط سرویس سفارش میداند Hold موجودی مجاز است یا نه.
Edge، CDN و Origin protection
- Traffic حجیم و Challenge را پیش از Origin جذب کنید.
- Origin را به Edge/Private path محدود و IPv4/IPv6/hostname bypass را تست کنید.
- محتوای عمومی را Cache و endpoint گران را budget کنید.
- Log/decision ID را از Edge به Application trace منتقل کنید.
- Fail-open/fail-closed را برای outage سرویس Bot تعریف کنید.
طراحی Cache/Origin/WAF/Edge failure و TCO در راهنمای CDN پیشرفته آمده است.
Rate limiting چندبعدی و Cost-aware
Limit فقط بر IP، پشت NAT کاربر خوب را جمعی تنبیه و در برابر Proxy rotation شکست میخورد. Bucketها را براساس Flow و Risk ترکیب کنید: account، credential identifier، device/session، API key، IP/ASN، endpoint، object، payment instrument و global capacity.
| Flow | Dimension | Cost weight | Response |
|---|---|---|---|
| Login | account + network + device | ۱ | backoff/step-up بدون enumeration |
| Search | session/API key + query cost | ساده ۱، wildcard/export ۱۰ | quota/cache/async |
| OTP | phone + account + device + global spend | هزینه پیام | cooldown/budget/verify |
| Cart hold | account/device/item/address | scarcity × duration | short lease/deposit/release |
| Checkout | account/payment/device | Gateway/chargeback | velocity/step-up/block |
Distributed rate limit باید Clock، retry، race، failover و consistency را بسنجد. Response ۴۲۹ با Retry-After برای Client مجاز مفید است؛ مهاجم را لزوماً راهنمایی نکنید و Error body را بدون enumeration طراحی کنید.
CAPTCHA آخرین و تنها دفاع نیست
راهنمای Bot Management در OWASP هدف را افزایش هزینه سوءاستفاده با حفظ کاربر/Automation مشروع میداند. CAPTCHA میتواند اصطکاک بسازد، با سرویس انسانی/خودکار حل شود و دسترسپذیری را آسیب بزند.
Challenge ladder
- Passive signal و Observe
- Rate/Backoff/queue و Cost budget
- Proof سبک یا JavaScript challenge با fallback
- Managed challenge دسترسپذیر
- Reauthentication/MFA/Passkey برای عمل پرخطر
- Block موقت Entity و Incident response
Challenge solve rate، abandonment، time، accessibility failure و bypass outcome را بسنجید. نمایش Challenge برای همه، «امنتر» بودن را ثابت نمیکند.
دفاع Login و Account takeover
راهنمای Credential stuffing در OWASP دفاع چندلایه شامل MFA، password breach check، signal شبکه/دستگاه، CAPTCHA هدفمند، metrics و اطلاعرسانی رویداد غیرعادی را توضیح میدهد.
- Password تکراری/نشتکرده را هنگام انتخاب/تغییر رد کنید؛ Login message enumeration نسازد.
- Rate را per-account و cross-account ببینید تا Spraying و Stuffing پنهان نشوند.
- MFA/Passkey و Step-up را برای Admin و اقدام مالی اولویت دهید.
- Session issuance، refresh، recovery، email change و disable MFA را همانقدر محافظت کنید.
- Lockout سخت میتواند DoS حساب بسازد؛ backoff و recovery امن طراحی کنید.
NIST SP ۸۰۰-63B-۴ نیز Rate limiting تلاش ناموفق احراز هویت و کنترلهای تکمیلی برای کاهش Lockout را الزام/توصیه میکند. راهنمای کامل Flow ورود در دفاع Brute force و Credential stuffing و روشهای قویتر در راهنمای MFA و Passkey آمدهاند.
دفاع API و Mobile app
مخفیکردن Endpoint در JavaScript یا Mobile binary کنترل امنیت نیست. Inventory/version، Authentication/Authorization، schema/size/pagination، query complexity، cost quota، idempotency، nonce/replay، token audience، webhook و egress را طراحی کنید. API key داخل اپ عمومی Secret قابلاعتماد نیست.
Device attestation و signed request میتوانند Signal اضافه کنند، اما Rooted device، relay و client modification را صفر نمیکنند. Business action را در Server enforce کنید. برای API1–API10، OAuth/JWT، SSRF و Business flow به راهنمای امنیت API رجوع کنید.
Inventory hoarding و Scalping را در منطق محصول حل کنید
| کنترل | اثر | ریسک جانبی | شاهد |
|---|---|---|---|
| Hold کوتاه و Release قطعی | کاهش قفل موجودی | کاربر کند/پرداخت | hold→purchase ratio |
| Purchase limit per verified entity | کاهش Scalping | خانواده/سازمان مشروع | resale/duplicate graph |
| Queue/Fairness token | کنترل Burst | bot queue farms | wait/fair completion |
| Deposit/commitment | افزایش هزینه Hoard | Refund/support/legal | abuse vs conversion |
| Reconciliation | رفع hold یتیم | race/oversell | inventory ledger |
«Bot score بالا» جای invariant موجودی، transaction و reconciliation را نمیگیرد.
Carding، Coupon و Gift card abuse
Attempt کممبلغ، BIN/expiry variation، velocity میان account/device/payment/address و decline code الگو میسازند. اما داده پرداخت حساس است؛ Tokenized identifier و کمینهسازی Log لازم است. Limit و Step-up را با Gateway/Fraud team هماهنگ کنید تا مهاجم از سایت شما برای آزمون کارت و تحمیل هزینه استفاده نکند.
Scraping: امنیت، دسترسی، قرارداد و SEO را جدا کنید
Scraping میتواند بار، هزینه، داده اختصاصی یا حریم خصوصی را تهدید کند؛ اما استخراج محتوای عمومی همیشه با Credential stuffing یکسان نیست و مرز حقوقی/قراردادی به Jurisdiction و داده وابسته است. برای داده حساس، Authorization و کمینهسازی پاسخ لازم است؛ robots.txt گاوصندوق نیست.
RFC ۹۳۰۹ برای Robots Exclusion Protocol صریحاً قواعد را درخواست Crawler میداند، نه Access authorization. همچنین Google میگوید Duplicate content عموماً نقض Spam policy نیست؛ Scrape شدن خودکار به معنی «جریمه SEO سایت اصلی» نیست. ریسک واقعی را در Origin load، Data misuse، brand/confusion و indexing شواهدی بسنجید.
Bot خوب را فقط از User-Agent نشناسید
User-Agent قابل جعل است. راهنمای رسمی Googlebot تطبیق IP با Range رسمی یا Reverse DNS را برای Verification توصیه میکند. برای Partnerها از Credential، mTLS/signature، IP range با Change process و Quota استفاده کنید؛ Allowlist بدون Expiry/Owner به bypass دائمی بدل میشود.
| Automation مجاز | روش Verification | Scope | Fallback |
|---|---|---|---|
| Search crawler | IP range/rDNS رسمی | Read public | crawl-safe limit |
| Partner API | OAuth/mTLS/key + contract | Endpoint/object quota | revoke/rotate |
| Monitoring | signed identity/source list | Health route | secondary probe |
| Internal job | workload identity | least privilege | queue/retry |
WAF و Bot Management مرزهای متفاوت دارند
WAF برای Pattern/Protocol/Vulnerability و Rate policy مفید است؛ Bot Management Signal/Classification/Challenge تخصصیتر میدهد؛ DDoS service حجم/Availability را جذب میکند؛ Application منطق Business را enforce میکند. هیچکدام جای دیگری را کامل نمیگیرد.
Policy، Count→Canary→Block، False positive و Origin lock را با راهنمای WAF و فایروال و حمله حجمی/لایه هفت را با راهنمای مقابله با DDoS تکمیل کنید.
حریم خصوصی و Fingerprinting
جمعآوری Font، Canvas، hardware، IP، behavior و graph میتواند داده شخصی/قابلپیوند بسازد. Purpose، Necessity، data map، retention، access، sharing، vendor processing، user notice و deletion را با متخصص حقوقی بازار هدف بررسی کنید. Risk score را برای Marketing reuse نکنید مگر مبنای جدا و شفاف داشته باشد.
کاربر باید مسیر Recovery داشته باشد. Black box که حساب را میبندد و دلیل/راه اعتراض نمیدهد، هم ریسک اخلاقی دارد و هم Labelهای آموزشی را آلوده میکند. اصول Manipulation/consent در راهنمای طراحی اخلاقی آمده است.
False positive یک Incident کسبوکار است
| Guardrail | تقسیمبندی | Alarm |
|---|---|---|
| Challenge exposure/solve/time | device/browser/ISP/accessibility | افزایش ناگهانی |
| Login success/recovery | new/returning/risk cohort | افت کاربر خوب |
| Checkout/booking completion | payment/region/source | افت با Policy version |
| Support/appeal | reason/policy | شکایت Block |
| Verified crawler coverage | bot type/route/status | 403/429 crawl |
| API partner success | credential/version | quota regression |
کاربر ایرانی ممکن است بهخاطر NAT اپراتور، VPN، تغییر IP یا Browser محدود شبیه ریسک بالا دیده شود. Country/IP block کور میتواند بازار هدف را حذف کند.
Telemetry و Label برای Bot defense
| لایه | فیلد کلیدی | محدودیت |
|---|---|---|
| Edge | request_id، rule/policy، score، action، network | sampling/privacy |
| Application | flow، account/entity pseudonym، outcome، cost | PII و cardinality |
| Identity | auth strength، session/recovery/change | sensitive |
| Payment/Fraud | token/decline/chargeback label | lag/PCI boundary |
| Business | hold/purchase/refund/spam accepted | ground truth delay |
| Support | false-block appeal/outcome | manual bias |
Decision ID را Edge→Gateway→App→Outcome حمل کنید. Log صرف «blocked=true» مدل را ارزیابی نمیکند. Metric/Log/Trace، Sampling و SLO را با راهنمای Observability طراحی کنید.
KPIهای درست
| بعد | KPI | ضدشاخص |
|---|---|---|
| Security | Attack success/ATO/accepted abuse | تعداد Bot block |
| User | False-positive، auth/checkout success | Challenge count |
| Economics | Cost per prevented abuse، SMS/Gateway/compute saved | Traffic درصدی |
| Availability | User SLO، origin saturation/offload | Edge request volume |
| Detection | Precision/recall روی Label معتبر، coverage/unknown | Vendor score average |
| Response | MTTD/MTTC/MTTR و recovery success | alert count |
Rollout Policy بدون Lockout
- Shadow/Log-only: Baseline، coverage و candidate policy.
- Count: تصمیم پیشنهادی بدون اثر کاربر.
- Challenge روی cohort کوچک/Flow کمخطر.
- Block confidence بالا با allow/recovery و kill switch.
- Compare outcome/guardrail و بررسی daily.
- گسترش مرحلهای بر Route/Region/percent.
- Drill vendor outage، fail mode و rollback.
Policy version را در Log و Dashboard ثبت کنید. Rollback فقط حذف Rule نیست؛ ممکن است Session، Cart، account lock و data skew نیازمند جبران باشند.
Runbook حمله Login/ATO
- Scope: route، account cohort، IP/device graph، شروع و policy.
- Contain: rate/step-up، credential/session revoke متناسب، نه reset کور همه.
- Preserve: log، decision، auth/session/change و outcome.
- Confirm compromise: اقدام پس از Login، نه صرف failure.
- Recover: user verification، factor/session rebinding و support امن.
- Notify: متن متناسب با شواهد و الزام حقوقی.
- Close gaps: recovery، MFA bypass، leaked password و monitoring.
- Postmortem: false positive، missed abuse، cost و test regression.
Runbook Inventory/Carding/Layer 7
| Incident | Contain | Reconcile | Recover |
|---|---|---|---|
| Inventory hoarding | hold TTL/queue/entity limit | orphan hold و oversell | release + customer comms |
| Carding | velocity/step-up/Gateway coordination | attempt/fee/order state | block token/entity و monitor |
| SMS pumping | global spend cap/cooldown | provider bill/message status | route/provider/user support |
| Layer 7 DoS | edge rate/cache/degrade/queue | origin/job/DB backlog | drain، SLO و capacity |
انتخاب ابزار Bot Management
| معیار | سؤال Pilot | شاهد |
|---|---|---|
| Coverage | Web/Mobile/API/GraphQL و Origin را میبیند؟ | route inventory match |
| Signals/Privacy | چه دادهای، کجا، چندروز و برای چه هدف؟ | DPA/data map/config |
| Actions | Observe/rate/challenge/block/exception/API؟ | canary/rollback test |
| Accuracy | Ground truth و appeal چگونه وصل میشود؟ | confusion matrix/FP cohort |
| Latency/Availability | p95 overhead و vendor outage mode؟ | load/failure test |
| Explain/Export | decision reason/raw log/version قابل خروج؟ | SIEM export/replay |
| Cost | Request، feature، overage، FX و attack spike؟ | low/base/peak TCO |
| Iran/Eligibility | دسترسی، پرداخت، support، route و data region؟ | contract + ISP pilot |
| Exit | Rule/list/label/log و fallback؟ | disable/rebuild drill |
نام AI یا «تشخیص ناشناخته» شاهد نیست. Black box را با replay ترافیک پاکسازیشده، Attack simulation مجاز و Cohort واقعی بسنجید. هیچ حملهای به سامانه ثالث اجرا نکنید.
ملاحظات ایران
- NAT اشتراکی اپراتور و IPv4 محدود، IP reputation/limit را پرخطا میکند.
- VPN و تغییر مسیر، Geo/ASN/fingerprint را ناپایدار میکند؛ آن را Signal بدانید نه حکم.
- Latency Challenge و Script خارجی را روی چند ISP/Android/Browser بسنجید.
- سرویس داخلی/خارجی Edge ممکن است Coverage و Origin path متفاوت داشته باشد؛ bypass را IPv4/IPv6/hostname تست کنید.
- هزینه SMS/OTP، Gateway call و FX میتواند هدف Cost-inflation شود؛ global budget و alert لازم است.
- Eligibility، پرداخت، Data location، Export و قطع سرویس Vendor را پیش از خرید بررسی کنید.
- Search crawler و Monitoring داخلی را با هویت و Quota نگه دارید؛ Country allow/block کافی نیست.
- قانون حریم خصوصی، داده دستگاه، Scraping، اطلاعرسانی رخداد و پرداخت را با مشاور حوزه مربوط بررسی کنید.
برنامه ۹۰روزه مدیریت ربات
روز ۱ تا ۳۰: Baseline و Flow
- Web/Mobile/API/Origin inventory و هشت Flow پرریسک را ثبت کنید.
- OAT mapping، دارایی، abuse outcome، cost unit و owner بسازید.
- Logهای Edge/App/Identity/Business را با request/decision ID همبسته کنید.
- Verified automation/partner allowlist را با Owner/Expiry بازبینی کنید.
- False-positive guardrail و Incident severity تعریف کنید.
روز ۳۱ تا ۶۰: Control و Pilot
- Origin lock، cache، endpoint cost budget و rate limit چندبعدی را اجرا کنید.
- Login: breached-password، backoff، MFA/step-up و recovery را تست کنید.
- Inventory/OTP/Checkout invariant و reconciliation را اضافه کنید.
- Bot policy را Shadow→Count→Challenge روی Cohort محدود ببرید.
- Latency، solve، auth/checkout، support و crawler را Guardrail کنید.
روز ۶۱ تا ۹۰: Block، Runbook و تصمیم خرید
- Block فقط برای confidence/outcome بالا با kill switch و appeal.
- ATO، hoarding، carding، SMS pumping و Layer ۷ drills اجرا کنید.
- Attack success، FP، cost saved، SLO و MTTx را گزارش کنید.
- Vendor/Build/Edge option را با Scorecard/TCO/Exit مقایسه کنید.
- Policy review، label QA، privacy retention و red-team مجاز را تقویم کنید.
اشتباههای پرتکرار
- تعمیم درصد Bot گزارش Vendor به سایت خود.
- تعریف Bot=بد و Human=خوب.
- اعتماد به User-Agent، IP یا Fingerprint بهعنوان هویت قطعی.
- Rate limit فقط IP و ساختن Lockout پشت NAT.
- CAPTCHA برای همه بدون fallback/Accessibility.
- خرید Bot tool پیش از Flow/Outcome/Telemetry.
- WAF/Edge بدون Origin protection و API inventory.
- Block کردن Scraper و فراموشکردن Authorization/response minimization.
- تصور robots.txt بهعنوان کنترل دسترسی.
- ادعای جریمه خودکار SEO بهخاطر Scrape شدن.
- گزارش Block volume بدون Attack success و False positive.
- مدلسازی با Label خود Vendor و ندیدن Miss/appeal.
- Rollout مستقیم Block بدون Shadow/Count/Canary/Rollback.
چکلیست اجرایی
- Route/Flow/Version/Origin/Mobile/API inventory کامل است.
- OAT، دارایی، outcome، cost، owner و risk contract هر Flow ثبت شدهاند.
- Automation مجاز با روش مستقل، scope، quota و expiry تأیید میشود.
- Signalها Confidence/Privacy/Retention دارند و حکم منفرد نیستند.
- Rate limit چندبعدی، Cost-aware و در failure تست شده است.
- Login/Recovery/MFA/Session و Business invariant دفاع مستقل دارند.
- Origin فقط از مسیر مجاز قابلدسترسی است.
- Challenge ladder، accessibility fallback و appeal موجود است.
- Decision ID از Edge تا outcome و cost قابلردیابی است.
- Attack success، FP، SLO، conversion، support و crawler guardrail میشوند.
- Policy با Shadow/Count/Canary/kill switch منتشر میشود.
- ATO/Inventory/Carding/SMS/DDoS runbook و reconciliation تمرین شدهاند.
- Vendor TCO/eligibility/data/export/outage/exit در ایران Pilot شده است.
پرسشهای متداول
ربات مخرب پیشرفته چیست؟
اصطلاح یک استاندارد دقیق واحد نیست. عملیتر است Automation را با Flow و الگوی OWASP مثل Credential stuffing، Scraping، Scalping، Denial of inventory، Carding یا Fake account نامگذاری کنید و Success outcome آن را بسنجید.
آیا CAPTCHA برای توقف ربات کافی است؟
خیر. CAPTCHA میتواند هزینه حمله را بالا ببرد، اما قابل حل/دورزدن است و برای کاربر واقعی و افراد دارای نیاز دسترسپذیری اصطکاک میسازد. آن را فقط در Risk مناسب داخل ladder چندلایه و با fallback استفاده کنید.
تفاوت WAF و Bot Management چیست؟
WAF بیشتر روی Ruleهای Protocol/Pattern/Vulnerability و Rate تمرکز دارد؛ Bot Management Signal، classification و challenge تخصصیتر میدهد. Application همچنان باید Identity و Business rule را enforce کند و DDoS/Edge لایه Availability را پوشش میدهد.
آیا Scraping به SEO سایت اصلی جریمه میزند؟
نه بهصورت خودکار. Google میگوید Duplicate content عموماً نقض Spam policy نیست و Scrape شدن تقصیر سایت اصلی محسوب نمیشود. Scraping میتواند بار، داده، برند یا کنترل نمایش را تهدید کند؛ این اثرها را جداگانه بسنجید.
کسبوکار کوچک از کجا شروع کند؟
از Login، Signup/OTP، Search، Cart و Checkout inventory بگیرد؛ Log outcome و cost را وصل کند؛ Origin و WAF/rate پایه را امن کند؛ MFA را برای مدیر/عمل پرخطر فعال کند؛ و فقط Flow دارای سوءاستفاده شواهدی را با Challenge/Block مرحلهای سختتر کند.
جمعبندی: Bot defense یعنی مهندسی سوءاستفاده
ربات مخرب را با حرکت ماوس یا IP تنها نمیتوان تعریف کرد. باید بفهمید کدام عمل، برای کدام Identity و Resource، با چه Velocity و Outcome نامجاز است. سپس هزینه را در Edge بالا ببرید، Capacity را محافظت کنید، Auth و Business invariant را در برنامه enforce کنید و پاسخ را با Confidence افزایش دهید.
اگر امروز فقط یک کار انجام میدهید، صفحه Login را انتخاب نکنید چون مشهور است؛ گرانترین Flow واقعی خود را انتخاب کنید. Success abuse، کاربر خوب، cost unit و truth event آن را بنویسید. دفاع مؤثر از همان قرارداد شروع میشود، نه از دکمه Block all bots.
