Bài phân tích này xem xét tình huống bot traffic tạo request abuse ở một số endpoint có giá trị cao và cách dùng rate limiting để kiểm soát mà vẫn hạn chế false positive với verified bots và người dùng hợp lệ. Nội dung được xây dựng từ tài liệu kỹ thuật công khai của Cloudflare và AWS; đây không phải incident, số liệu vận hành hay case khách hàng thực tế của SecureWebOps.
Bot traffic không đồng nghĩa với malicious traffic. Search crawlers, monitoring agents và integration hợp lệ cũng là bot. Vấn đề xuất hiện khi automation tạo request với tần suất, hành vi hoặc mục tiêu vượt ngoài baseline của application: scraping catalog, account enumeration, credential abuse, bulk actions hoặc gọi API liên tục.
Cloudflare hiện khuyến nghị review bot analytics trước khi thay đổi mitigation và dùng custom rules/rate limiting để nhắm đúng traffic pattern thay vì chặn automation một cách rộng. AWS Bot Control cũng tách verified/desirable bots khỏi traffic tự động đáng ngờ và kết hợp rate limiting, CAPTCHA/challenge cùng behavioral signals cho bot tinh vi. Nguồn: Cloudflare — Stop malicious bots while allowing legitimate traffic và AWS WAF Bot Control.
Bối cảnh và dấu hiệu ban đầu
Giả sử một website thương mại điện tử có product catalog, search, login và một số API phục vụ frontend. Hệ thống vẫn online nhưng origin bắt đầu nhận nhiều request lặp lại vào search, product detail hoặc API; business conversion không tăng tương ứng.
Nếu chỉ nhìn tổng request, đội vận hành có thể nhầm đây là tăng trưởng traffic. Điểm cần kiểm tra là request intent và cost: automation có đang đọc hàng nghìn URL, thử nhiều account, hoặc gọi endpoint có backend cost cao mà không tạo business outcome tương ứng hay không?
Các tín hiệu đáng chú ý
- Một số URI hoặc API endpoint có request rate vượt xa baseline.
- Nhiều request lặp pattern nhưng session/user behavior không giống người dùng thật.
- 403/404 tăng do bot dò URL hoặc resource không tồn tại.
- Search, catalog hoặc account endpoint bị gọi liên tục nhưng conversion không tăng.
- Traffic phân tán qua nhiều IP nên threshold theo IP đơn thuần không đủ.
- Verified search bots vẫn xuất hiện và cần được phân biệt với scraper/automation abuse.
Investigation: từ traffic spike đến bot classification
Bước 1: xác định endpoint bị abuse
Điều tra nên bắt đầu từ endpoint và hành vi, không bắt đầu bằng một ngưỡng sitewide. Nhóm request theo URI, method, status code, session/cookie, source network, user-agent, bot score hoặc label nếu nền tảng có hỗ trợ.
Cloudflare rate limiting best practices liệt kê các use case như chống scraping, bảo vệ REST API khỏi resource exhaustion và hạn chế operation do automated sources thực hiện. AWS cũng khuyến nghị rate-based rule đặc biệt hữu ích khi bot traffic tăng cao trên sensitive URI hoặc bắt đầu ảnh hưởng operation. Nguồn: Cloudflare Rate Limiting Best Practices và AWS Prescriptive Guidance.
Bước 2: phân biệt good bot, suspicious bot và human traffic
Không nên dựa duy nhất vào User-Agent. Bot tốt có thể được provider xác minh; bot xấu có thể giả browser hoặc giả crawler nổi tiếng. Khi có thể, kết hợp verified-bot signal, behavior/fingerprint, request rate, session continuity và endpoint pattern.
AWS Bot Control cho biết verified bots được nhận diện riêng, trong khi targeted protection sử dụng browser interrogation, fingerprinting, behavior heuristics và rate limiting cho automation tinh vi hơn. Cloudflare cũng tách detection khỏi mitigation: bot score hoặc tín hiệu automation có thể được dùng làm điều kiện trước khi action. Điều này giúp giảm false positive so với “mọi request nhanh đều block”.
Bước 3: chọn counting key đúng với traffic
IP là counting key phổ biến nhưng có giới hạn. NAT, mobile carrier, VPN hoặc distributed botnet có thể làm IP-based threshold vừa chặn nhầm người thật vừa bỏ lọt bot phân tán.
Cloudflare cho phép dùng các characteristic như IP hoặc cookie/session trong một số cấu hình rate limiting; AWS WAF hỗ trợ aggregation key như IP, HTTP method và các tổ hợp key. Vì vậy thiết kế threshold phải bám vào identity/context thực tế của endpoint thay vì áp một con số cố định cho mọi request. Nguồn: Cloudflare và AWS WAF Rate Limiting.
Root cause
Không phải chỉ vì “có bot”
Root cause trong tình huống này là automation abuse không có control phù hợp với endpoint cost và traffic identity. Website có thể đã có WAF nhưng vẫn thiếu threshold theo hành vi, thiếu bot classification hoặc dùng một policy quá rộng cho mọi visitor.
Do đó remediation không phải “block bot”, mà là giới hạn hành động vượt baseline ở đúng endpoint và đúng loại traffic, đồng thời bảo toàn verified bots và user flow hợp lệ.
Khi nào có thể xác nhận root cause?
- Telemetry xác nhận request abuse tập trung ở endpoint/pattern cụ thể.
- Traffic classification cho thấy tỷ lệ automation đáng kể hoặc behavior phi-human.
- Business metrics không tăng tương ứng với request volume.
- Khi áp rate limit/challenge có scope, origin load hoặc abuse metric giảm.
- Verified bots và legitimate user flow vẫn hoạt động sau thay đổi.
Remediation
Containment: giới hạn đúng endpoint trước
AWS khuyến nghị layer rate-based rules: có thể có một blanket ceiling để chống flood lớn, nhưng sensitive URI nên có rule riêng với threshold chặt hơn. Cloudflare cũng cung cấp các ví dụ rate limit theo bot signal và endpoint thay vì sitewide block.
- Rate limit search, login, API hoặc bulk-action endpoint theo baseline riêng.
- Scope rule bằng path, method, bot score/label hoặc request characteristic phù hợp.
- Dùng Managed Challenge/CAPTCHA khi confidence chưa đủ để block cứng.
- Cho verified/desirable bots đi qua theo policy rõ ràng.
- Không dùng một threshold IP thấp cho toàn site nếu có NAT/VPN/shared users.
Kiến thức nền xem Rate Limiting là gì? và Bot Protection: phân biệt bot tốt, bot xấu và automation abuse.
Corrective action: từ IP limit sang context-aware control
Nếu bot phân tán hoặc nhiều user chia sẻ IP, rate limiting cần thêm context. Cookie/session, authenticated identity, method + path, bot label hoặc token/challenge outcome có thể giúp policy phản ánh hành vi tốt hơn.
Với API hoặc endpoint có backend cost cao, nên tách quota/rate riêng thay vì dùng policy của page browsing. Xem thêm Cách bảo vệ API và endpoint nhạy cảm bằng Rate Limiting.
Validation sau remediation
| Test | Kết quả mong đợi |
|---|---|
| Người dùng hợp lệ ở endpoint bị bảo vệ | PASS, không tăng false positive đáng kể |
| Verified search/monitoring bot | Đi theo policy allow/limit đã định |
| Automation abuse vượt threshold | Rate limit/challenge/block theo rule |
| Distributed bot qua nhiều IP | Không dễ bypass nếu có context/aggregation phù hợp |
| Origin request/load | Giảm về baseline chấp nhận được |
| Conversion/API success | Không giảm do policy mới |
| WAF events | Có telemetry đủ để review false positive |
Validation cần theo dõi cả security outcome và business outcome. Một rate limit “chặn được bot” nhưng làm người thật fail checkout/login vẫn là remediation chưa đạt.
Bài học vận hành và bước tiếp theo
- Bot không mặc định là xấu; classification phải đi trước mitigation.
- Threshold cần dựa trên baseline và endpoint cost, không dùng con số cố định cho mọi site.
- IP-only rate limiting có thể sai trong NAT/VPN hoặc botnet phân tán.
- Challenge thường an toàn hơn block khi confidence chưa cao.
- Verified bot policy phải được review định kỳ.
- Rate limit cần telemetry, owner, rollback và false-positive review.
Đưa rule vào quy trình review định kỳ tại WAF Maintenance Checklist. Bài này tập trung vào chuỗi phát hiện bot abuse → phân loại → rate limit có scope → xác minh bot xấu giảm nhưng legitimate traffic vẫn PASS.