Cách giảm thiểu DDoS: CDN, WAF, Rate Limit, Origin

Giảm thiểu DDoS cho website không nên dựa vào một control duy nhất. Một kiến trúc bền vững cần xử lý nhiều lớp: upstream/CDN hấp thụ traffic, DDoS protection phát hiện flood, WAF lọc request web, rate limiting kiểm soát endpoint abuse, cache giảm tải origin và origin protection ngăn bypass.

Điểm quan trọng là đặt control trước bottleneck. Nếu uplink của origin đã đầy, firewall trên chính server chặn packet cũng quá muộn. Nếu HTTP request hợp lệ nhưng rất đắt, chỉ có network DDoS protection cũng chưa đủ. Vì vậy mitigation phải bắt đầu từ việc xác định lớp tài nguyên bị làm cạn. Nếu chưa phân biệt volumetric, protocol và application-layer attack, xem DDoS là gì? trước khi chọn control.

Kiến trúc nhiều lớp để giảm DDoS

Internet
  ↓
Anycast / CDN / DDoS Protection
  ↓
WAF / Bot / Rate Limiting
  ↓
Origin Protection / Firewall
  ↓
Reverse Proxy / Web Server
  ↓
Application / API
  ↓
Database / Internal Services

Mỗi lớp có nhiệm vụ riêng. CDN không thay authorization; WAF không hấp thụ vô hạn volumetric traffic; rate limiting không chặn được mọi distributed botnet; origin firewall không cứu được đường truyền đã bão hòa. Giá trị đến từ cách các lớp bổ sung cho nhau.

Các lớp phòng thủ và thứ tự triển khai

Bước 1: Đặt website sau lớp edge có đủ capacity

Với volumetric hoặc protocol DDoS, mitigation phải xảy ra trước đường truyền nhỏ hơn của origin. CDN/DDoS provider có mạng phân tán và capacity lớn hơn giúp hấp thụ hoặc drop traffic ở edge.

Cloudflare hiện mô tả DDoS managed protection cho cả L3/4 và L7 và khuyến nghị giữ protection mặc định hoạt động, sau đó bổ sung custom rules/rate limiting khi application cần policy riêng. Dù dùng nhà cung cấp nào, hãy xác minh rõ:

HTTP/HTTPS có thực sự được proxy qua edge;
DNS record public có bỏ qua proxy không;
DDoS protection áp ở layer nào;
có giới hạn attack size/duration hoặc billing impact nào;
telemetry/event có đủ để điều tra không;
cơ chế failover khi provider lỗi là gì.

Bước 2: Khóa origin để attacker không bypass edge

Nếu origin IP vẫn nhận request trực tiếp từ Internet, attacker có thể đánh thẳng backend và bỏ qua CDN/WAF. Đây là một trong những lỗi kiến trúc phổ biến nhất khi “đã bật Cloud/CDN nhưng server vẫn chết”. Case Attacker Bypass CDN/WAF bằng Origin IP cho thấy cách direct-origin access vô hiệu hóa protection ở edge.

chỉ cho phép source network/proxy hợp lệ tới web ports;
dùng mTLS/origin authentication nếu nền tảng hỗ trợ;
không public service quản trị qua cùng interface;
kiểm tra DNS history và record phụ có lộ origin;
đổi origin IP khi đã bị lộ và threat model yêu cầu;
test trực tiếp IP để xác nhận bypass không còn hoạt động.

Phần này có owner riêng tại Origin Protection là gì?

Bước 3: Tận dụng cache để giảm request về origin

Cache biến nhiều request giống nhau thành edge hit thay vì origin render. Đây là lớp rất hiệu quả với static asset và nội dung public có thể cache an toàn.

cache static assets lâu hơn khi phù hợp;
cache HTML public nếu application cho phép;
chuẩn hóa cache key để tránh query vô nghĩa;
không cache login, cart, checkout hoặc personalized response một cách mù quáng;
theo dõi cache hit ratio trước và trong incident.

HTTP flood kiểu cache-busting thường cố làm giảm cache hit để ép origin xử lý. Vì vậy cache strategy là một phần của DDoS defense, không chỉ performance optimization.

Bước 4: Dùng WAF cho attack pattern ở HTTP layer

WAF hữu ích khi traffic có đặc điểm có thể match bằng HTTP context: path, method, header, query, bot/risk signal hoặc signature. Nó phù hợp với exploit attempt, malformed request và một số HTTP flood có fingerprint rõ.

Tuy nhiên đừng kỳ vọng managed WAF rules tự chặn mọi DDoS. Một HTTP flood có thể chỉ là hàng triệu GET hợp lệ. Khi đó DDoS managed protection, rate limiting, bot controls và cache mới là phần quan trọng hơn. Case HTTP Flood làm quá tải WordPress/PHP-FPM minh họa cách request hợp lệ về hình thức vẫn có thể làm cạn worker và tài nguyên backend.

Nếu chưa rõ boundary, xem WAF là gì? và Layer 7 DDoS là gì?.

Bước 5: Rate-limit endpoint có semantics rõ

Rate limiting hiệu quả nhất khi endpoint có hành vi bình thường có thể dự đoán: login, password reset, search, API operation, form submission hoặc expensive report. Khi thiết kế threshold, nên nhớ cùng “100 request/phút” chưa chắc được đếm và enforce giống nhau giữa nền tảng; xem Cloudflare vs AWS WAF Rate Limiting để hiểu khác biệt về counting key, aggregation và window.

lấy threshold từ baseline, không copy con số từ tutorial;
tách GET/POST hoặc operation khác nhau;
nếu có thể, đếm failed attempts thay vì mọi request;
cân nhắc shared IP/NAT;
challenge trước block nếu browser flow phù hợp;
API/webhook cần action không phá machine traffic.

Rate limiting per-IP không đủ với botnet phân tán. Nếu attack phân tán, cần thêm bot score, fingerprint, session/API key hoặc DDoS detection tự động tùy nền tảng. Xem Bot Protection cho website và case Bot Traffic được kiểm soát bằng Rate Limiting để thấy cách kết hợp classification với scoped rate limit. Với WordPress login, dùng WAF + Rate Limiting cho wp-login.php để tách login abuse khỏi policy sitewide.

Bước 6: Giảm cost của endpoint ở application

Không phải mitigation nào cũng nằm ở edge. Nếu một request search nhỏ làm 30 query đắt, application đang có amplification nội bộ. Tối ưu endpoint giúp site chịu được cả traffic hợp lệ lẫn attack tốt hơn.

index database hợp lý;
cache query/result có thể cache;
giới hạn page size và expensive filter;
timeout upstream hợp lý;
queue job nặng thay vì xử lý đồng bộ;
protect search/report/API aggregation;
giảm plugin/middleware không cần thiết trên critical path.

Bước 7: Scale để mua thời gian, không coi là root fix duy nhất

Autoscaling hoặc tăng worker có thể giúp hấp thụ traffic, nhưng nếu attacker scale cùng bạn thì chi phí có thể tăng nhanh. Scale nên đi kèm mitigation để giảm traffic độc hại trước backend.

Với database hoặc stateful service, scale thường chậm hơn web tier. Vì vậy cần biết bottleneck thật thay vì chỉ tăng số web server.

Mitigation theo từng loại DDoS

Attack	Control ưu tiên	Control bổ sung
Volumetric flood	Upstream/CDN/DDoS network protection	Origin firewall, provider escalation
SYN/protocol flood	Network DDoS protection, load balancer	Connection tuning, SYN protection
HTTP flood	HTTP DDoS protection	WAF, rate limit, bot control
Cache-busting	HTTP DDoS protection + cache strategy	Query normalization, WAF/rate limit
Login abuse	Rate limit + MFA	WAF/bot challenge
Origin bypass	Origin protection	mTLS, firewall, new origin IP

Runbook khi DDoS đang diễn ra

Xác nhận impact và layer bị nghẽn.
Kiểm tra edge/CDN có đang proxy đúng traffic không.
Xác minh origin không bị đánh trực tiếp.
Nhóm attack theo host/path/method/source/fingerprint.
Giữ managed DDoS protection ở trạng thái phù hợp.
Thêm mitigation hẹp: rate limit/challenge/WAF rule nếu có evidence.
Tăng cache cho nội dung an toàn nếu giúp giảm origin load.
Liên hệ provider/upstream nếu bandwidth hoặc network edge bị bão hòa.
Read-back user impact, 5xx, latency, origin RPS.
Ghi timeline và change để rollback/postmortem.

Vận hành incident an toàn

Không thay đổi quá nhiều control cùng lúc

Trong incident dễ có xu hướng bật country block, tăng WAF sensitivity, hạ rate limit và sửa cache cùng lúc. Điều này làm khó xác định thay đổi nào thực sự hiệu quả hoặc gây false positive.

Ưu tiên change nhỏ, có snapshot, read-back và rollback. Nếu cần emergency action rộng, ghi rõ lý do và đặt review/expiry sau incident. Sau khi traffic ổn định, đưa rule, exception, rate-limit và origin policy vào WAF Maintenance Checklist để gỡ emergency rule và kiểm tra configuration drift.

Metric cần dashboard trước khi có incident

network bps/pps;
edge RPS;
origin RPS;
cache hit ratio;
top host/path/method;
WAF/DDoS action count;
latency p95/p99;
4xx/5xx;
PHP/app worker utilization;
database connections/query latency;
business metric như login/checkout/API success.

Chuẩn bị contact và quyền thay đổi trước incident

DDoS response thường thất bại vì thiếu access hoặc không biết ai gọi provider. Runbook nên có:

CDN/DDoS provider account owner;
hosting/upstream escalation contact;
quyền chỉnh WAF/rate-limit/firewall;
rollback owner;
status communication owner;
cách lấy log trong attack window;
mốc nào cần chuyển incident severity cao hơn.

Sai lầm thường gặp

chỉ tăng server mà không giảm traffic độc hại;
chỉ block IP trong botnet phân tán;
origin vẫn public dù đã dùng CDN;
rate limit sitewide không có baseline;
challenge API/webhook;
cache nhầm personalized content;
tắt DDoS managed protection vì false positive mà không tune scope;
không biết provider/upstream contact khi incident xảy ra;
không read-back sau mỗi mitigation.

Checklist kiến trúc chống DDoS

HTTP traffic có đi qua CDN/DDoS edge?
Origin có chặn direct Internet access?
DDoS protection L3/4 và L7 đang hoạt động?
Cache strategy đã được kiểm tra?
Endpoint đắt đã có rate limit?
WAF có rule/managed protection phù hợp?
API/webhook có exception đúng cách?
Dashboard có edge + origin metric?
Có rollback và escalation contact?
Đã diễn tập incident chưa?

Kết luận

Giảm thiểu DDoS hiệu quả là bài toán kiến trúc nhiều lớp. CDN/DDoS protection phải hấp thụ traffic trước bottleneck, WAF/rate limit giảm HTTP abuse, cache giảm origin work và origin protection bảo đảm attacker không bỏ qua toàn bộ edge.

Quan trọng nhất là biết mỗi control đang giải quyết loại resource exhaustion nào và xác minh hiệu quả bằng metric sau từng thay đổi. Không có một rule hay một threshold duy nhất phù hợp mọi website.

Nguồn tham khảo

Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem bảo vệ website trước DDoS.