Bài phân tích này xem xét cách traffic anomaly có thể cảnh báo sớm một Layer 7 attack trước khi origin rơi vào resource saturation. Nội dung được xây dựng từ tài liệu công khai của Cloudflare và Google Cloud về adaptive DDoS detection; đâ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.
Layer 7 DDoS không phải lúc nào cũng bắt đầu bằng một spike khổng lồ. Nhiều cuộc tấn công tăng dần, dùng request HTTP hợp lệ về mặt cú pháp và chỉ trở nên rõ ràng khi traffic pattern lệch khỏi baseline bình thường của website.
Cloudflare cho biết hệ thống DDoS của họ phân tích HTTP metadata như path, method, query string, user agent, request rate và cả origin error rate để tìm attack pattern. Google Cloud Armor Adaptive Protection cũng xây baseline theo từng backend service, phát hiện anomaly, tạo attack signature và đề xuất WAF rule tương ứng. Nguồn: Cloudflare — How DDoS protection works và Google Cloud Armor Adaptive Protection.
Bối cảnh và dấu hiệu ban đầu
Giả sử một website có baseline tương đối ổn định theo giờ, ngày trong tuần và traffic source. Một thời điểm, tổng request bắt đầu tăng nhưng website chưa down; CPU origin chỉ nhích lên nhẹ, latency chưa vượt ngưỡng cảnh báo truyền thống và chưa có nhiều 5xx.
Nếu chỉ chờ “CPU 100%” hoặc “website mất kết nối” mới phản ứng thì đội vận hành đã bỏ lỡ giai đoạn sớm nhất của incident. Mục tiêu của anomaly detection là nhận ra sự lệch chuẩn trước khi impact trở thành outage.
Những tín hiệu nên được xem cùng nhau
- Request rate tăng bất thường so với baseline cùng khung giờ.
- Một path hoặc method chiếm tỷ trọng cao bất thường.
- User-Agent, quốc gia/region hoặc ASN distribution thay đổi đột ngột.
- Query-string diversity hoặc cache-miss pattern tăng mạnh.
- Origin 4xx/5xx hoặc latency bắt đầu tăng nhưng chưa thành outage.
- Business outcome như conversion/session chất lượng không tăng tương ứng với traffic.
Cloudflare Adaptive DDoS Protection hiện có các profile riêng cho origin errors, user agents và geo distribution; việc một hoặc nhiều profile lệch khỏi trạng thái thông thường có thể kích hoạt detection/mitigation. Nguồn: Cloudflare Adaptive DDoS Protection.
Investigation: từ anomaly đến attack hypothesis
Bước 1: so sánh với baseline, không chỉ nhìn absolute threshold
Một ngưỡng cố định như “1.000 request/giây” có thể quá cao với site nhỏ và quá thấp với site lớn. Baseline theo service, endpoint, giờ và weekday thường có giá trị hơn. Google Cloud Armor mô tả Adaptive Protection là hệ thống học traffic bình thường của từng backend service để phát hiện request pattern lệch chuẩn.
Vì vậy detection nên trả lời: traffic hiện tại khác trạng thái bình thường ở điểm nào, thay vì chỉ hỏi traffic có vượt một con số tuyệt đối hay chưa.
Bước 2: tìm signature của anomaly
Khi có anomaly, tiếp tục phân tích các dimension như path, method, query, header, source network, user-agent, geo và request rate. Cloudflare cho biết hệ thống DDoS dùng chính các trường này để phát hiện suspicious patterns và requests gây nhiều origin errors.
Google Cloud Armor cũng tạo một attack signature mô tả traffic đáng ngờ và có thể đề xuất custom WAF rule để giảm thiểu. Điều này cho thấy alert có giá trị hơn khi đi kèm “traffic nào khác thường” chứ không chỉ “traffic tăng”.
Bước 3: correlate anomaly với origin impact
Anomaly chỉ là một tín hiệu quan sát được. Để nâng độ tin cậy, cần correlate với origin latency, error rate, worker/process usage, cache hit/miss và business telemetry. Nếu request pattern bất thường tăng cùng lúc origin errors hoặc latency xấu đi, giả thuyết Layer 7 attack mạnh hơn.
Cloudflare HTTP Traffic Alerts cho phép theo dõi elevated origin 5xx và một số edge error như 521/522/523; đây là ví dụ về việc kết hợp traffic anomaly với availability signal. Nguồn: Cloudflare HTTP Traffic Alerts.
Xác minh nguyên nhân và mức độ tin cậy
Không phải mọi anomaly đều là attack
Marketing campaign, crawler, flash sale, cache purge hoặc deploy mới đều có thể làm traffic lệch baseline. Vì vậy anomaly detection không nên tự động biến thành kết luận “DDoS confirmed”.
Chỉ nên xác nhận nguyên nhân khi traffic signature, timing, origin impact và phản ứng sau mitigation cùng khớp với nhau.
Khi nào có thể xác nhận đây là Layer 7 attack?
- Traffic lệch baseline rõ ràng ở một hoặc nhiều dimension có ý nghĩa.
- Pattern tập trung vào endpoint/method/request signature cụ thể.
- Origin latency, error rate hoặc resource usage xấu đi cùng thời điểm.
- Khi áp mitigation đúng signature, anomalous traffic giảm và origin phục hồi.
- Legitimate traffic cùng business flow vẫn hoạt động sau mitigation.
Remediation: từ alert đến mitigation có scope
Ưu tiên rule có scope thay vì block rộng
Google Cloud từng mô tả một Layer 7 DDoS lớn được Adaptive Protection phát hiện sớm, sau đó hệ thống đề xuất rule và khách hàng chọn throttle thay vì deny để giảm khả năng ảnh hưởng legitimate traffic. Họ cũng triển khai rule ở preview mode trước để xác minh scope. Nguồn: Google Cloud Blog — 46M RPS L7 DDoS.
- Rate limit/challenge đúng path, method hoặc signature bất thường.
- Ưu tiên preview/log-only nếu confidence chưa đủ để block.
- Không dùng geo/IP block rộng nếu anomaly là distributed traffic.
- Giữ telemetry để so sánh trước và sau mitigation.
- Escalate sang stronger mitigation khi origin vẫn bị ảnh hưởng.
Đọc nền tảng tại Layer 7 DDoS là gì? Cách nhận biết HTTP Flood và Cách giảm thiểu DDoS cho website.
Nếu origin đã bắt đầu bão hòa
Khi alert xuất hiện muộn và origin đã có queue/worker saturation, investigation cần đi sâu sang resource exhaustion. Xem bài HTTP Flood làm quá tải WordPress/PHP-FPM để theo dõi chuỗi request flood → dynamic execution → worker saturation.
Validation sau mitigation
| Signal | Kết quả mong đợi |
|---|---|
| Anomalous request rate | Giảm về baseline hoặc bị throttle ở edge |
| Origin latency | Trở về vùng bình thường |
| Origin 5xx/error rate | Giảm, không tiếp tục tăng |
| Legitimate sessions | Tiếp tục PASS |
| Conversion/API success | Không giảm do false positive |
| Alert rule | Giữ đủ sensitivity để phát hiện recurrence |
Validation phải kiểm tra cả detection quality lẫn mitigation quality. Một alert phát hiện đúng nhưng rule chặn người dùng thật vẫn chưa phải outcome tốt.
Bài học vận hành và bước tiếp theo
- Baseline quan trọng hơn một threshold tuyệt đối cho mọi site.
- Anomaly nên có signature: path, method, source, geo, UA hoặc error profile.
- Alert phải correlate được với origin health và business metrics.
- Preview/throttle thường an toàn hơn block rộng khi confidence chưa cao.
- Detection rule cần owner, review cycle và false-positive feedback.
- Monitoring tốt phải phát hiện trước resource exhaustion, không chỉ báo sau outage.
Để xây baseline và giảm false positive, xem Security Monitoring Baseline và Security Monitoring WordPress. Bài này tập trung vào chuỗi traffic anomaly → attack hypothesis → evidence correlation → scoped mitigation → validation.