DDoS (Distributed Denial of Service) là dạng tấn công làm suy giảm hoặc làm mất khả năng phục vụ của website, API hay hạ tầng mạng bằng cách tạo tải từ nhiều nguồn phối hợp. Mục tiêu cốt lõi là availability: khiến người dùng hợp lệ không thể truy cập dịch vụ, truy cập rất chậm hoặc gặp lỗi hàng loạt.
Điểm khó của DDoS là không có một “mẫu duy nhất”. Có cuộc tấn công bão hòa băng thông, có cuộc làm cạn connection state, và có cuộc dùng request HTTP trông gần giống người dùng thật để đốt CPU, PHP worker, database hoặc API quota. Vì vậy cách nhận biết và giảm thiểu phải bắt đầu bằng việc xác định lớp tài nguyên nào đang bị làm cạn, không chỉ nhìn tổng traffic.
DoS và DDoS khác nhau như thế nào?
DoS là denial-of-service nói chung: một nguồn hoặc một cơ chế làm dịch vụ không còn đáp ứng bình thường. DDoS là trường hợp tải tấn công đến từ nhiều máy hoặc nhiều nguồn phối hợp. CISA mô tả DDoS là DoS trong đó lưu lượng overload bắt nguồn từ nhiều máy tấn công cùng hoạt động, thường thông qua botnet.
| Đặc điểm | DoS | DDoS |
|---|---|---|
| Nguồn traffic | Một hoặc ít nguồn | Nhiều nguồn phân tán |
| Khả năng chặn theo IP | Đôi khi khả thi | Thường không đủ |
| Quy mô | Có thể nhỏ hoặc cục bộ | Có thể rất lớn hoặc phân tán rộng |
| Khả năng giả traffic hợp lệ | Có | Có, đặc biệt ở Layer 7 |
| Mitigation | Có thể xử lý gần origin trong một số trường hợp | Thường cần upstream/CDN/edge capacity và nhiều control phối hợp |
Ba nhóm DDoS nên phân biệt khi vận hành website
Thay vì ghi nhớ hàng chục tên attack vector, có thể bắt đầu với ba nhóm tài nguyên mà attacker muốn làm cạn. Cách phân loại này gần với hướng dẫn của CISA: network resource overload, protocol/session resource overload và application resource overload.
1. Network hoặc volumetric attack
Mục tiêu là bão hòa đường truyền hoặc capacity xử lý packet trước khi request hợp lệ tới được ứng dụng. Ví dụ thường gặp gồm UDP flood, ICMP flood và các dạng reflection/amplification. Khi link hoặc upstream bị bão hòa, tăng CPU ứng dụng hay thêm PHP worker gần như không giải quyết được nguyên nhân.
- Tín hiệu nên xem: bits per second (bps), packets per second (pps), interface utilization, packet loss và upstream saturation.
- Điểm mitigation: càng gần upstream/edge càng tốt; nếu traffic đã làm nghẽn đường truyền vào origin thì firewall cục bộ có thể chặn quá muộn.
2. Protocol và connection-state attack
Nhóm này cố làm cạn bảng connection, state của firewall/load balancer hoặc tài nguyên xử lý TCP. SYN flood là ví dụ quen thuộc. Attacker không nhất thiết phải đẩy lượng byte khổng lồ; chỉ cần tạo đủ state hoặc packet pattern để thiết bị trung gian và server không còn phục vụ connection hợp lệ.
- Tín hiệu nên xem: new connections per second, SYN/ACK pattern, conntrack/session utilization, backlog, retransmission và drop.
- Điểm mitigation: network edge, load balancer, SYN protection hoặc DDoS service có capacity phù hợp.
3. Application-layer hoặc Layer 7 DDoS
Layer 7 DDoS nhắm vào nơi web application thực sự xử lý HTTP/HTTPS. Một request có thể nhỏ nhưng buộc backend thực hiện công việc tốn kém: search động, render trang không cache, login, checkout, API aggregation hoặc query database. Vì request có thể trông hợp lệ, Layer 7 thường khó phân biệt hơn network flood.
Bài này chỉ đặt boundary. Cách phân tích HTTP flood, cache-busting, endpoint cost và các tín hiệu RPS/latency/error được tách riêng tại Layer 7 DDoS là gì? Cách nhận biết HTTP Flood.
Reflection và amplification DDoS là gì?
Reflection attack lợi dụng một hệ thống trung gian để phản hồi traffic về IP nạn nhân. Nếu protocol cho phép response lớn hơn request, attacker còn đạt amplification: bỏ ra lượng traffic nhỏ hơn nhưng khiến reflector gửi lượng traffic lớn hơn tới mục tiêu. DNS amplification là ví dụ phổ biến của mô hình này.
Với reflection/amplification, địa chỉ nguồn quan sát được có thể là các reflector chứ không phải máy điều khiển cuộc tấn công. Vì vậy “block vài IP lớn nhất” thường không phải chiến lược bền vững.
DDoS có thể là multi-vector
Một incident không bắt buộc chỉ có một vector. Attacker có thể tạo network flood để gây nhiễu đồng thời gửi HTTP request vào endpoint tốn tài nguyên. Vì vậy dashboard chỉ cho một lớp có thể khiến đội vận hành kết luận sai. Khi triage, nên đồng thời kiểm tra network, connection, HTTP và backend resource.
| Lớp quan sát | Metric hữu ích | Câu hỏi chính |
|---|---|---|
| Network | bps, pps, packet loss | Đường truyền hay edge có bị bão hòa? |
| Transport | connections/s, SYN state, conntrack | State table hoặc handshake có bị làm cạn? |
| HTTP | RPS, status code, path, cache status | Request nào đang tăng và có giống traffic thật? |
| Application | latency, worker saturation, queue | Endpoint nào tốn tài nguyên? |
| Database | query latency, connection pool, CPU | HTTP flood có đẩy bottleneck xuống DB? |
Dấu hiệu nào gợi ý website đang bị DDoS?
Không có một metric đơn lẻ đủ để kết luận. Traffic tăng có thể do chiến dịch marketing, crawler, sự kiện tin tức hoặc release mới. DDoS nên được đánh giá bằng nhiều tín hiệu cùng lúc.
- RPS/pps/bps tăng nhanh ngoài baseline và không tương ứng với conversion hoặc traffic source bình thường;
- latency và 5xx tăng trong khi request tập trung bất thường vào một số path;
- cache hit giảm mạnh do attacker tạo URL/query ngẫu nhiên để bypass cache;
- PHP/app worker, connection pool hoặc database đạt giới hạn dù băng thông chưa đầy;
- nhiều request có fingerprint lặp lại hoặc phân bố nguồn bất thường;
- login/search/API bị gọi với tần suất cao nhưng không tạo hành vi người dùng hợp lệ;
- origin nhận traffic trực tiếp ngoài CDN/reverse proxy dự kiến.
Traffic spike hợp lệ và DDoS khác nhau ở đâu?
Điều quan trọng không phải “traffic có cao không” mà là traffic đó có hoàn thành hành vi hợp lệ và có phân bố giống baseline không. Một đợt sale có thể tạo RPS cao nhưng vẫn có session progression, cache pattern, conversion và user-agent/browser behavior hợp lý. DDoS thường bộc lộ sự mất cân bằng: rất nhiều request nhưng rất ít hành vi tiếp nối, tập trung vào endpoint tốn tài nguyên hoặc có fingerprint bất thường.
Do đó không nên tạo rule “RPS vượt X là chặn” mà không hiểu baseline. Threshold cố định có thể tự gây outage khi website thật sự tăng trưởng hoặc có campaign.
WAF có chặn được DDoS không?
WAF có thể giúp ở Layer 7 vì nó nhìn thấy HTTP request và có thể áp rule, challenge hoặc rate limiting. Nhưng WAF không phải lời giải duy nhất cho mọi DDoS. Nếu attack làm nghẽn network path trước khi traffic tới WAF, hoặc WAF nằm ngay trên origin với capacity hạn chế, lớp này có thể bị quá tải cùng hệ thống.
Vì vậy cần hiểu WAF bảo vệ website như thế nào và đặt nó trong kiến trúc có upstream/CDN, rate limiting, cache, bot control và origin protection phù hợp.
Firewall server có đủ để chống DDoS không?
Firewall server rất quan trọng để giảm network exposure, nhưng không thể hấp thụ vô hạn traffic. Nếu uplink đã bão hòa thì packet có bị drop trên server cũng không trả lại bandwidth cho legitimate user. Với attack lớn, mitigation cần diễn ra trước khi traffic tới đường truyền nhỏ hơn của origin.
Ở phạm vi server, firewall vẫn nên được cấu hình theo policy rõ ràng. Xem Linux Firewall cho Web Server để phân biệt bài toán exposure với bài toán DDoS capacity.
Khi DDoS xảy ra, nên triage theo thứ tự nào?
- Xác nhận impact: user thật gặp timeout, latency hay 5xx ở đâu?
- Xác định layer bị nghẽn: network, connection, HTTP, application hay database.
- Tách traffic: path, host, method, country/ASN, IP, user-agent, cache status và response code.
- Bảo vệ origin: bảo đảm traffic không bypass CDN/WAF và hạn chế đường vào trực tiếp.
- Áp mitigation hẹp trước: rate limit/challenge/block theo fingerprint có evidence, tránh chặn rộng ngay lập tức.
- Read-back: theo dõi impact sau mỗi thay đổi và rollback nếu legitimate traffic bị ảnh hưởng.
- Preserve evidence: lưu timeline, metric, rule/action và mẫu request để post-incident review.
Quy trình mitigation theo kiến trúc CDN + WAF + rate limit + origin protection được tách tại Cách giảm thiểu DDoS cho website.
Những sai lầm thường gặp khi xử lý DDoS
- Chỉ block IP: không hiệu quả khi botnet lớn hoặc source thay đổi liên tục.
- Chặn cả quốc gia không có evidence: có thể gây outage cho user thật mà attack vẫn tiếp tục từ nơi khác.
- Bật challenge cho mọi request: API, webhook hoặc bot hợp lệ có thể hỏng.
- Tăng server rồi dừng ở đó: scale có thể mua thêm thời gian nhưng không sửa network bottleneck hoặc attack logic.
- Không khóa origin: attacker bỏ qua CDN/WAF và đánh thẳng IP backend.
- Không lưu baseline: khi incident xảy ra không biết “bình thường” là bao nhiêu RPS, latency hoặc cache hit.
Checklist chuẩn bị trước khi bị DDoS
- Biết ai chịu trách nhiệm liên hệ CDN/hosting/upstream khi có incident.
- Có dashboard cho bps/pps/RPS, status code, latency và origin resource.
- Origin không public ngoài đường vào đã phê duyệt, hoặc có policy giới hạn phù hợp.
- Có rate-limit strategy cho login, search, API và endpoint tốn tài nguyên.
- Biết critical flow nào không được challenge: payment callback, webhook, API machine-to-machine.
- Có rollback cho WAF/rate-limit rule.
- Có cách lấy log/event trong khoảng thời gian incident.
- Đã xác định fail-open/fail-closed behavior của các lớp bảo vệ quan trọng.
Kết luận
DDoS là bài toán availability và resource exhaustion, không chỉ là “traffic rất lớn”. Muốn xử lý đúng cần phân biệt network/volumetric, protocol/connection và application-layer attack; sau đó đặt mitigation ở nơi có đủ visibility và capacity để chặn trước bottleneck.
Đối với website, bước tiếp theo nên là học cách nhận biết HTTP Flood ở Layer 7 và xây kiến trúc giảm thiểu DDoS nhiều lớp thay vì phụ thuộc vào một rule hoặc một thiết bị đơn lẻ.