Ý chính: Không có một nút bấm duy nhất chặn được mọi kiểu DDoS. Mỗi lớp nên xử lý loại tấn công mà nó nhận biết tốt nhất.
Thuật ngữ trong bài: Rate limit: giới hạn tần suất truy cập; origin: máy chủ ứng dụng phía sau CDN; false positive: chặn nhầm người dùng hợp lệ.
Bài toán thực tế
Giới hạn tần suất ở ứng dụng là quá muộn với tấn công chiếm băng thông hoặc giữ kết nối. Nhưng gom mọi quy tắc vào một lớp cũng dễ chặn nhầm người dùng và tạo thêm một điểm nghẽn.
DDoS là bài toán bất cân xứng chi phí: kẻ tấn công bỏ ra rất ít nhưng buộc hệ thống tiêu tốn băng thông, kết nối hoặc tài nguyên tính toán. Vì vậy, lưu lượng xấu cần bị loại ở lớp rẻ nhất có đủ thông tin để quyết định.
CDN và WAF xử lý lưu lượng lớn; proxy bảo vệ kết nối; ứng dụng dùng danh tính và ngữ cảnh nghiệp vụ để giới hạn chính xác hơn. Không lớp nào thay thế hoàn toàn lớp còn lại.
Thiết kế và triển khai
- Để CDN hoặc WAF hấp thụ lưu lượng lớn và chặn các mẫu tấn công đã biết.
- Đặt giới hạn kết nối, kích thước nội dung và thời gian chờ ngay tại reverse proxy.
- Giới hạn theo chi phí của từng nhóm endpoint trước khi chạy xác thực hoặc truy vấn tốn tài nguyên.
Mã minh họa: Giới hạn tần suất bằng token bucket có trọng số
policy['read'] = { rate: 60/min, burst: 30, cost: 1 }
policy['login'] = { rate: 10/min, burst: 5, cost: 3 }
policy['export'] = { rate: 2/min, burst: 1, cost: 20 }
identity = accountId ?? apiKeyId ?? trustedClientIp
bucket = `${routeGroup}:${identity}`
allowed = tokenBucket.consume(bucket, policy[group].cost)
if (!allowed) return 429 with Retry-AfterChỉ tin các header chuyển tiếp do proxy đã được xác thực gửi tới; nếu không, ứng dụng khách có thể tự giả địa chỉ nguồn.
Rủi ro cần tính trước
- DNS hoặc IP máy chủ gốc vẫn công khai nên kẻ tấn công có thể đi vòng qua CDN.
- Kho giới hạn tần suất dùng chung gặp sự cố và làm mọi yêu cầu bị chặn hoặc được thả qua.
- Một chiến dịch hợp lệ tạo lưu lượng giống tấn công và bị chặn nhầm.
Nên theo dõi gì?
| Tín hiệu | Điều tín hiệu cho biết |
|---|---|
| Yêu cầu được CDN chấp nhận so với yêu cầu tới máy chủ gốc | Cho biết bao nhiêu lưu lượng đã bị loại trước khi tiêu tốn tài nguyên ứng dụng. |
| Số kết nối, lỗi bắt tay và timeout | Phát hiện kiểu giữ kết nối lâu mà bộ đếm yêu cầu không nhìn thấy. |
| Tỷ lệ phản hồi 429 theo endpoint và danh tính | Phân biệt hạn mức quá thấp với hành vi lạm dụng tập trung. |
| Mức bão hòa máy chủ gốc và tỷ lệ lỗi người dùng | Xác nhận biện pháp đang bảo vệ khả dụng thay vì chỉ chuyển lỗi sang người dùng hợp lệ. |
Đưa vào production từng bước
Chạy quy tắc mới ở chế độ chỉ đếm để biết ai sẽ bị ảnh hưởng và vì sao. Đối chiếu với người dùng đã xác thực cùng các đợt tăng tải hợp lệ, sau đó mới chặn từng nhóm nhỏ và luôn giữ một đường gỡ chặn khẩn cấp.
Điều cần nhớ
Phòng thủ nhiều lớp giúp loại lưu lượng xấu với chi phí tăng dần, đồng thời giữ tài nguyên ứng dụng cho người dùng hợp lệ.