Traffic anomaly và request spike chỉ có ý nghĩa bảo mật khi được đặt trong baseline, endpoint context và impact. Request tăng không đồng nghĩa với attack: campaign, crawler, cache miss, release hoặc business event hợp lệ đều có thể tạo spike. Ngược lại, một spike nhỏ vào wp-login.php, XML-RPC, API nhạy cảm hoặc endpoint tốn tài nguyên có thể đáng chú ý hơn một spike lớn vào trang chủ.
Mục tiêu của monitoring là phân biệt expected traffic, operational anomaly, abuse và incident signal bằng evidence: request profile, route, source, status, WAF action, latency, resource và business context.
Traffic anomaly nên được đánh giá theo những lớp nào?
| Lớp | Signal | Câu hỏi chính |
|---|---|---|
| Volume | RPS/RPM, burst, duration | Deviation lớn đến đâu so với baseline phù hợp? |
| Endpoint | Path, method, query pattern | Traffic tập trung vào route nào và route đó có rủi ro gì? |
| Source | IP/ASN/country/user-agent | Nguồn có khớp audience/crawler/vendor đã biết không? |
| Response | 2xx/3xx/4xx/5xx, latency | Origin có đang bị tác động không? |
| Control | WAF block/challenge/rate-limit | Traffic đã bị hấp thụ hay đang tới origin? |
| Resource | CPU/RAM/I/O/connections/workers | Spike có gây saturation không? |
| Business | Campaign, launch, crawl, import | Có event hợp lệ giải thích traffic không? |
Baseline trước, threshold sau
Không nên chọn một con số request/giây cố định cho mọi website. Baseline nên phản ánh request profile theo giờ/ngày, route, status code, source, cache behavior và business cycle. Site có campaign theo tuần cần baseline khác site B2B ít traffic; endpoint login cần context khác landing page public.
Để xây baseline có version, owner và known exceptions, xem Security Monitoring Baseline.
Attack-vs-Campaign Decision Matrix
| Signal | Campaign/traffic hợp lệ thường có | Attack/abuse có thể có | Evidence bổ sung |
|---|---|---|---|
| Request rate | Tăng theo campaign window/referrer | Spike không gắn business event | Analytics + CDN/WAF |
| Endpoint mix | Landing/product/content dự kiến | Login, XML-RPC, search, API hoặc expensive route | Path/method distribution |
| Source | Phù hợp audience/vendor | ASN/IP/geography/pattern bất thường | Edge log + reputation nếu có |
| Status code | 2xx/3xx profile tương đối ổn | 4xx/5xx tăng hoặc retry pattern | Origin/app error |
| Latency/resource | Trong capacity | Latency/saturation tăng | CPU/RAM/I/O/worker |
| WAF | Rule hit không bất thường | Block/challenge/rate-limit tăng mạnh | Rule/action/false-positive review |
Không có một tín hiệu đơn lẻ đủ để kết luận attack. Confidence tăng khi nhiều lớp cùng lệch theo một hypothesis hợp lý.
Những anomaly đáng theo dõi
- Request rate tăng mạnh trong time window ngắn hoặc kéo dài ngoài expected window.
- POST/PUT/API request tăng ở route vốn ít traffic.
- 404/403/429/5xx tăng khác baseline.
- Source mới tạo volume lớn hoặc request pattern lặp cao.
- Traffic tới route authentication/admin tăng nhưng không có business reason.
- WAF block tăng và origin vẫn chịu load lớn.
- Spike đi cùng resource saturation, application error hoặc availability impact.
- Traffic tăng ngay sau một security finding/account event khác.
Phân biệt mitigated traffic và traffic tới origin
Một điểm dễ hiểu sai là nhìn số request ở WAF/CDN rồi suy ra origin đang chịu cùng lượng traffic. Cần tách ít nhất ba con số: request quan sát ở edge, request bị block/challenge/rate-limit, và request thực sự tới origin.
Nếu edge block tăng nhưng origin request/resource vẫn ổn, control có thể đang hấp thụ abuse đúng cách. Nếu edge event tăng đồng thời origin latency/CPU/5xx tăng, cần triage nhanh hơn.
Dùng WAF Monitoring và Resource Saturation Monitoring để correlate.
Endpoint context quan trọng hơn tổng volume
| Endpoint type | Điều cần xem | Escalation signal |
|---|---|---|
| Login/auth | Failed/success login, account target, source pattern | Login success bất thường + privilege/action |
| Search/filter | Query complexity, cache miss, bot pattern | Resource impact hoặc injection probing |
| API | Method, auth, rate, payload size | Unauthorized use, scraping, expensive calls |
| Static/content | Cacheability, referrer, crawler | Origin bypass, hotlink/bot abuse |
| Admin/maintenance | Expected owner/window | Access ngoài window hoặc nguồn mới |
Bot không đồng nghĩa với malicious
Search crawler, monitoring service, uptime checker, integration và vendor bot đều có thể tạo machine-like traffic. Không block chỉ theo user-agent string. Hãy dùng verified mechanism của nền tảng khi có, source/ASN, behavior, rate và route context để phân loại.
Nếu một crawler hợp lệ gây resource impact, đây vẫn có thể là vấn đề vận hành cần rate/caching/tuning dù không phải security incident.
Traffic Observation Record mẫu
Worksheet dưới đây để điền bằng telemetry thật; không phải ngưỡng mặc định cho SecureWebOps.
observation_id: TRAFFIC-YYYY-NNN
asset: example.com
window_start_utc: ...
window_end_utc: ...
baseline_ref: ...
business_event: none|campaign|launch|crawl|maintenance|unknown
request_profile:
total_requests: ...
requests_p50: ...
requests_p95: ...
top_paths: [...]
top_methods: [...]
top_status: [...]
source_profile:
top_asn_or_sources: [...]
new_source_ratio: ...
waf:
allowed: ...
blocked: ...
challenged: ...
origin:
requests: ...
latency: ...
error_rate: ...
cpu_ram_io: ...
classification: expected|operational-anomaly|abuse|incident-suspected|unknown
confidence: low|medium|high
next_action: observe|tune|rate-limit|triage|incident-response
owner: ...
evidence_refs: [...]
Alert design theo context
- Khóa host/route/method cần theo dõi.
- So với baseline cùng context và time window.
- Đặt minimum volume để tránh noise nhỏ.
- Kết hợp status/latency/WAF action/resource.
- Tách mitigated traffic khỏi origin traffic.
- Gắn known exceptions: campaign, crawl, backup, deploy.
- Gắn owner, severity và runbook.
- Review false positive sau mỗi tuning.
Thiết kế rule chi tiết xem Security Alerting.
PASS/FAIL/HOLD cho traffic triage
- PASS — Expected: spike có business/crawler owner rõ, route/source phù hợp, origin ổn và không có security correlation.
- PASS — Abuse mitigated: abuse được WAF/rate-limit hấp thụ, origin ổn, rule được xác minh không gây business impact.
- FAIL: chỉ nhìn tổng request rồi kết luận attack, không có baseline, không tách edge/origin hoặc bỏ qua resource/status impact.
- HOLD: traffic lệch baseline nhưng chưa xác định business event/source hoặc telemetry còn thiếu. HOLD cần thu thêm evidence.
Khi nào chuyển sang Incident Response?
Escalate khi anomaly đi cùng evidence compromise, account abuse, service degradation nghiêm trọng, persistence signal hoặc malicious activity đang tiếp diễn. Nếu chỉ là burst hợp lệ hoặc abuse đã mitigated và origin ổn, có thể xử lý ở monitoring/tuning.
Trước escalation, dùng Security Alert Triage để khóa evidence, impact và confidence.
Nguồn tham khảo
Kết luận
Traffic anomaly hiệu quả phải được đọc theo baseline → endpoint → source → WAF action → origin impact → business context. Đừng alert chỉ vì request tăng. Ưu tiên deviation có confidence, impact và correlation đủ để quyết định rõ: expected, tuning, abuse mitigation hay incident response.