My Awesome Project

Appearance

Adaptive Protection & Always-On DDoS Defense ​

Why this matters in production ​

DDoS phòng thủ trên Cloud Armor gồm hai lớp bản chất khác nhau, và nhầm lẫn chúng dẫn tới kỳ vọng sai:

  1. Always-on L3/L4 DDoS defense — luôn bật, tự động, miễn phí ở Standard, chống volumetric/protocol attack ở tầng mạng. Bạn không cấu hình nó; nó là một phần của hạ tầng Google.
  2. Adaptive Protection — phát hiện L7 DDoS (HTTP flood, application-layer abuse) bằng machine learning. Đây là thứ bạn bật, vận hành, và phải hiểu để dùng đúng.

Điểm cốt lõi cần hiểu: Adaptive Protection không phải rule tĩnh. Nó không có signature "đây là attack". Thay vào đó nó học baseline hành vi bình thường của từng backend service rồi phát hiện độ lệch. Hệ quả trực tiếp: nó chỉ hữu ích khi backend có đủ traffic để xây baseline, và nó phát hiện bất thường, không phải biết trước attack. Không nắm bản chất "anomaly detection so với baseline", bạn sẽ hoặc kỳ vọng nó bắt được thứ nó không thể, hoặc bỏ qua giá trị thật của nó.

Internal model — cơ chế vận hành ​

Always-on L3/L4 defense: lớp nền ​

Trước khi nói Adaptive Protection, cần hiểu lớp dưới. Mọi traffic vào Google Cloud external load balancer đều đi qua hạ tầng edge của Google, nơi có always-on protection chống L3/L4 volumetric và protocol-based DDoS (SYN flood, UDP amplification, reflection…). Theo tài liệu, đây là bảo vệ mặc định ngay cả với Cloud Armor Standard.

Cơ chế: các attack tầng mạng bị hấp thụ và lọc tại edge của Google, tận dụng dung lượng mạng toàn cầu khổng lồ — cùng hạ tầng phục vụ Google Search/YouTube. Một SYN flood không bao giờ tới được backend của bạn vì nó bị hấp thụ ở lớp mạng, xa phía trước cả Cloud Armor policy evaluation. Đây là lý do bạn hiếm khi cần nghĩ về L3/L4 DDoS trên GCP — nó được xử lý dưới lớp bạn cấu hình.

Advanced Network DDoS Protection (thuộc Cloud Armor Enterprise) mở rộng điều này cho passthrough Network Load Balancer và VM có public IP thông qua network edge security policy — vì với passthrough LB, GFE không terminate connection, nên cần cơ chế lọc packet-level ở edge riêng.

Adaptive Protection: ML baseline per-backend-service ​

Đây là phần L7. Cơ chế vận hành:

Xây baseline. Adaptive Protection mô hình hóa traffic riêng cho từng backend service. Theo tài liệu Google, trong giai đoạn huấn luyện ban đầu "at least one hour", nó "models incoming traffic and usage patterns that are specific to each backend service, so that it develops the baseline for each backend service". Baseline nắm bắt hành vi bình thường: phân bố request theo path, header, geo, user-agent, tốc độ, v.v.

Điểm cơ chế quan trọng: baseline là per-backend-service, không phải toàn cục. Một backend phục vụ API mobile có baseline khác backend phục vụ web. Điều này cho phép phát hiện ngữ cảnh hóa — cái "bình thường" với service này là "bất thường" với service kia.

Phát hiện anomaly. Sau khi có baseline, Adaptive Protection liên tục so sánh traffic hiện tại với baseline. Khi phát hiện độ lệch khớp mẫu L7 DDoS (HTTP flood, high-frequency malicious activity), nó sinh alert. Nó phát hiện độ lệch so với bình thường, không phải signature tấn công đã biết — đây là điểm khác biệt bản chất với WAF.

Cấu trúc alert ​

Khi Adaptive Protection phát hiện attack, alert (dạng JSON payload trong Cloud Logging) chứa:

  • alertId — ID để theo dõi và gửi feedback.
  • confidence — điểm 0–1, "how strongly Adaptive Protection rates the detected event as a malicious attack". Điểm cao = tự tin hơn đây là attack thật.
  • attackSize — quy mô attack đo bằng QPS (queries per second).
  • headerSignatures — mảng các chữ ký: mỗi phần tử có name (tên header) và significantValues với attackLikelihood, matchType, proportionInAttack (tỷ lệ giá trị này trong traffic attack), proportionInBaseline (tỷ lệ trong baseline bình thường), và value. Đây là bằng chứng: nếu 95% traffic attack có User-Agent: BadBot/1.0 nhưng baseline chỉ 0.1%, đó là chữ ký phân biệt attack.
  • suggestedRule — Cloud Armor gợi ý sẵn một rule để mitigate: gồm action, expression (biểu thức CEL match attack traffic), và evaluation với impactedAttackProportion (bao nhiêu % attack rule này chặn) và impactedBaselineProportion (bao nhiêu % traffic hợp lệ bị ảnh hưởng — tức false positive dự kiến).

Đây là giá trị lớn nhất của Adaptive Protection: nó không chỉ báo "có attack", mà đưa cho bạn một CEL expression ước lượng sẵn sẽ chặn X% attack và ảnh hưởng Y% traffic hợp lệ. Bạn quyết định dựa trên trade-off định lượng đó, thay vì mò mẫm viết rule giữa lúc đang bị tấn công.

Manual vs auto-deploy ​

Có hai cách áp dụng suggested rule:

Manual. Bạn đọc alert, copy expression từ suggested rule, dán vào match condition của một rule mới (hoặc bấm Apply trên dashboard). Bạn kiểm soát hoàn toàn — xem xét impactedBaselineProportion trước khi enforce, thường deploy qua preview trước. Đánh đổi: có độ trễ con người; giữa đêm, attack có thể gây thiệt hại trước khi ai đó phản ứng.

Auto-deploy. Bạn tạo sẵn một placeholder rule với match expression evaluateAdaptiveProtectionAutoDeploy(). Rule này tự động đánh giá true cho request mà Adaptive Protection nhận diện là attack traffic. Khi attack xảy ra, mitigation áp dụng tự động, không cần con người. Bạn có thể tinh chỉnh ngưỡng auto-deploy (theo confidence, mức độ ảnh hưởng baseline dự kiến, attack size) để tránh auto-deploy khi false-positive risk cao.

# Rule auto-deploy: Cloud Armor tự điền quyết định vào evaluateAdaptiveProtectionAutoDeploy()
- priority: 5000
  match: evaluateAdaptiveProtectionAutoDeploy()
  action: deny(403)

Trade-off manual vs auto: auto-deploy loại bỏ độ trễ phản ứng (quan trọng với attack lúc 3h sáng) nhưng rủi ro tự chặn nhầm nếu ngưỡng đặt lỏng. Nhiều team chạy auto-deploy với ngưỡng bảo thủ (confidence cao, baseline impact thấp) để chỉ tự động hành động với attack rõ ràng, còn lại vẫn xử lý tay.

Feedback loop và attack visibility telemetry ​

Adaptive Protection không phải hộp đen một chiều. Mỗi alert có alertId, và bạn có thể gửi feedback (đây là true positive hay false positive) — feedback này giúp tinh chỉnh mô hình theo thời gian cho backend của bạn. Cơ chế này quan trọng vì baseline "bình thường" của một service tiến hóa (feature mới, tăng trưởng traffic, thay đổi hành vi user); feedback giúp mô hình không mắc kẹt ở baseline cũ.

Tier Enterprise còn cung cấp attack visibility telemetry — dashboard hiển thị attack đang diễn ra, quy mô (QPS), và mitigation đang áp dụng. Giá trị vận hành: trong một sự cố, bạn thấy được bức tranh thời gian thực thay vì ghép mảnh từ log thô. Kết hợp với suggestedRule, đây là bộ công cụ để ra quyết định nhanh dưới áp lực — điều tối quan trọng khi mỗi phút downtime là mất doanh thu.

Quan hệ với rate limiting và WAF: các lớp bổ sung, không thay thế ​

Cần định vị chính xác Adaptive Protection trong ngăn xếp phòng thủ:

  • Rate limiting (file 04) là ngưỡng tĩnh do bạn đặt — hiệu quả khi bạn biết trước giới hạn hợp lý (ví dụ /login không nên quá 5 lần/phút). Nó hoạt động ngay, không cần học baseline.
  • Adaptive Protection là ngưỡng động do ML học — hiệu quả khi bạn không biết trước thế nào là bất thường, hoặc khi attack tinh vi hơn một ngưỡng đơn giản (phân tán, thay đổi pattern).

Chúng bổ sung nhau: rate limit bắt abuse có ngưỡng rõ ràng; Adaptive Protection bắt độ lệch volumetric mà ngưỡng tĩnh bỏ sót. Và suggestedRule của Adaptive Protection thường chính là một custom rule (file 03) hoặc cấu hình rate-limit mà bạn có thể giữ lại lâu dài sau attack.

Yêu cầu subscription ​

Điểm cần biết trước khi kỳ vọng: full Adaptive Protection alert chỉ có với Cloud Armor Enterprise. Không có Enterprise, bạn chỉ nhận basic alert — báo có bất thường nhưng không có attack signature, không có suggested rule. Giá trị thật (headerSignatures, suggestedRule với evaluation định lượng) nằm sau Enterprise. Xem file 06 về tier.

Constraints, trade-offs & failure modes ​

Cần đủ traffic để có baseline. Adaptive Protection là anomaly detection — nó vô dụng với backend traffic thấp hoặc thất thường, vì không xây được baseline đáng tin. Một service nội bộ ít traffic sẽ không được bảo vệ hiệu quả bởi Adaptive Protection (dùng rate limit tĩnh/WAF thay thế). Đây là giới hạn bản chất của phương pháp ML baseline, không phải cấu hình.

Baseline cần thời gian và có thể "học nhầm". Giai đoạn huấn luyện tối thiểu ~1 giờ, nhưng baseline ổn định cần lâu hơn. Nếu bạn bật Adaptive Protection trong lúc đang bị attack, nó có thể coi attack traffic là một phần baseline bình thường — làm giảm khả năng phát hiện. Bật trước khi cần, để baseline hình thành từ traffic sạch.

Chỉ phát hiện L7 DDoS/flood, không phải mọi thứ. Adaptive Protection nhắm high-frequency L7 abuse. Nó không thay thế WAF (không bắt SQLi trong một request đơn lẻ) và không thay thế rate limiting có chủ đích. Nó là một lớp bổ sung.

Failure mode — kỳ vọng nó "tự lo mọi thứ": bật Adaptive Protection và nghĩ đã xong phòng thủ. Thực tế nó chỉ phát hiện độ lệch volumetric L7. Application logic abuse tinh vi (mỗi request đều hợp lệ nhưng tổng thể là gian lận) nằm dưới radar của nó. Phòng thủ đầy đủ = always-on L3/L4 + WAF + rate limit + Adaptive Protection + validation ở application.

Failure mode — auto-deploy ngưỡng lỏng: đặt auto-deploy phản ứng với confidence thấp → tự chặn nhầm traffic hợp lệ khi có biến động traffic bình thường (ví dụ flash sale, viral content trông giống flood). Đặt ngưỡng bảo thủ và theo dõi impactedBaselineProportion của các rule được đề xuất.

Real-world scenario: HTTP flood lúc nửa đêm ​

Một e-commerce backend bị HTTP flood 50k QPS từ botnet, tất cả nhắm /search với query ngẫu nhiên. Diễn biến theo cơ chế:

  1. Always-on L3/L4 không can thiệp — đây là request HTTP hợp lệ về mặt giao thức, chỉ nhiều bất thường. Đây đúng là địa hạt của Adaptive Protection.
  2. Adaptive Protection so traffic với baseline /search bình thường (~2k QPS, phân bố geo/UA quen thuộc), phát hiện độ lệch, sinh alert: confidence: 0.98, attackSize: 50000 QPS, headerSignatures chỉ ra 92% attack dùng một cụm User-Agent hiếm trong baseline, suggestedRule với impactedAttackProportion: 0.92, impactedBaselineProportion: 0.003.
  3. Vì đã bật auto-deploy ngưỡng bảo thủ (confidence ≥ 0.95, baseline impact < 0.01), rule tự áp dụng, chặn 92% attack với ~0.3% ảnh hưởng traffic hợp lệ — trước khi kỹ sư kịp thức dậy.
  4. Sáng hôm sau, kỹ sư xem alert, tinh chỉnh rule thành một custom rule bền hơn (kết hợp JA4 fingerprint — xem file 03) và gỡ auto-deployed rule.

Bài học cơ chế: baseline per-service cho phép phân biệt "50k QPS attack" với "2k QPS bình thường" của chính service đó; suggestedRule biến phán đoán thành con số ra quyết định được; auto-deploy loại bỏ độ trễ con người trong cửa sổ nguy hiểm.

Official references ​