Layer 7 DDoS là tấn công từ chối dịch vụ nhắm vào lớp ứng dụng — nơi website và API xử lý HTTP/HTTPS. Thay vì chỉ đẩy thật nhiều byte vào đường truyền, attacker gửi lượng lớn request trông tương đối hợp lệ nhưng khiến web server, PHP worker, application thread, cache, upstream API hoặc database phải làm việc quá mức.
HTTP Flood là một dạng phổ biến của Layer 7 DDoS. Điểm khó là request tấn công có thể dùng GET/POST bình thường, đến từ botnet phân tán và không có một signature đơn giản như “IP này gửi packet sai protocol”. Vì vậy nhận biết Layer 7 DDoS phải kết hợp request rate, endpoint cost, cache behavior, error rate và resource saturation. Một ví dụ về phát hiện sớm bằng baseline và traffic anomaly là case Traffic Anomaly cảnh báo Layer 7 Attack trước khi Website quá tải.
Layer 7 DDoS khác volumetric DDoS như thế nào?
| Đặc điểm | Layer 7 / HTTP Flood | Volumetric / Network Flood |
|---|---|---|
| Mục tiêu chính | Application resource | Bandwidth/packet capacity |
| Đơn vị dễ quan sát | RPS, path, method, latency, cache status | bps, pps, packet loss |
| Traffic | Có thể trông hợp lệ | Thường có pattern ở network/protocol |
| Bottleneck | PHP/app worker, DB, API, cache miss | Uplink, router, firewall, conntrack |
| Mitigation | HTTP DDoS protection, WAF, rate limit, cache, bot controls | Upstream/CDN/scrubbing/network DDoS protection |
Để hiểu toàn bộ các nhóm DDoS trước, xem DDoS là gì?. Bài này chỉ tập trung vào HTTP/Application Layer.
Vì sao một request nhỏ vẫn có thể gây tác động lớn?
Một request vài kilobyte có thể kích hoạt chuỗi xử lý lớn phía sau:
- PHP khởi tạo WordPress/plugin stack;
- application kiểm tra session/auth;
- database chạy query;
- search xử lý filter/sort;
- API gọi service khác;
- checkout tính giá, inventory hoặc shipping;
- cache miss buộc origin render toàn bộ response.
Attacker thường ưu tiên endpoint có “cost ratio” cao: request rẻ cho client nhưng đắt cho server. Vì vậy chỉ nhìn bandwidth có thể bỏ lỡ Layer 7 attack đang làm CPU/database đầy. Failure mode thực tế xem HTTP Flood làm quá tải WordPress/PHP-FPM.
Các dạng HTTP Flood thường gặp
1. Flood vào một endpoint tốn tài nguyên
Search, login, cart, checkout, report, API aggregation hoặc trang không cache có thể bị gọi liên tục. Traffic có thể không quá lớn về bandwidth nhưng đủ để làm cạn worker hoặc DB connection.
2. Cache-busting
Attacker thay đổi query string, path hoặc header để tạo nhiều cache key và ép CDN/origin xử lý như request mới. Dấu hiệu điển hình là cache hit ratio giảm nhanh trong khi lượng request tăng.
3. Distributed low-rate flood
Nhiều bot gửi request ở tốc độ vừa phải để mỗi IP không nổi bật. Tổng traffic vẫn đủ lớn để gây áp lực. Đây là lý do block top IP không luôn giải quyết được vấn đề.
4. Dynamic path/randomized request
Request được biến đổi path/query/header để né cache và rule tĩnh. Hệ thống phòng thủ cần nhìn pattern tổng thể thay vì exact string.
Nhận biết HTTP Flood bằng metric nào?
| Lớp | Metric | Dấu hiệu đáng chú ý |
|---|---|---|
| Edge/CDN | RPS, cache hit, action, bot/risk signal | RPS tăng, cache hit giảm |
| HTTP | host/path/method/status | một vài path chiếm traffic bất thường |
| Web server | active connections, request queue | queue/connection tăng |
| Application | worker saturation, latency | worker đầy, p95/p99 tăng |
| Database | connections, query latency, CPU | pool đầy hoặc query chậm |
| User impact | 5xx, timeout, conversion | user thật bắt đầu lỗi |
Cloudflare mô tả HTTP DDoS detection hiện có thể dùng metadata như header, user-agent, query, path, host, method, HTTP version, request rate và cả origin error rate. Điều này cho thấy không nên phụ thuộc vào một metric đơn lẻ.
Traffic spike hợp lệ khác HTTP Flood như thế nào?
Một campaign hoặc bài viết viral cũng làm RPS tăng. Khác biệt nằm ở hành vi và hiệu quả:
- traffic hợp lệ thường có session progression và phân bố page hợp lý;
- campaign có nguồn/referrer/business event giải thích được;
- cache hit có thể tăng chứ không nhất thiết giảm;
- conversion hoặc engagement tăng tương ứng;
- HTTP Flood thường tập trung vào endpoint đắt hoặc tạo request entropy bất thường;
- attack có thể làm 5xx/latency tăng nhanh hơn traffic hợp lệ cùng mức RPS.
Không nên tạo rule “RPS vượt X là attack” mà không có baseline. Cloudflare cũng lưu ý threshold DDoS không có một con số chung hữu ích vì fingerprint, colo và traffic pattern khác nhau.
Endpoint cost quan trọng hơn tổng RPS
1.000 request/giây tới static asset cache-hit có thể rẻ hơn 50 request/giây tới search endpoint chạy nhiều query. Khi triage, hãy xếp hạng endpoint theo:
- RPS;
- cache miss;
- response time;
- CPU time;
- database query count;
- upstream/API calls;
- error rate;
- bytes response;
- business criticality.
Dấu hiệu cache-busting
- nhiều URL gần giống nhau chỉ khác query/random token;
- cache hit ratio giảm mạnh;
- origin request tăng nhanh hơn edge request bình thường;
- response content thực chất giống nhau;
- CPU/application load tăng dù bandwidth edge không bất thường tương ứng.
Mitigation có thể cần chuẩn hóa cache key, bỏ query không cần thiết, cache nội dung phù hợp và kết hợp WAF/rate limit. Không nên cache mù login, cart hoặc personalized response.
Rate Limiting có chặn được mọi Layer 7 DDoS không?
Không. Rate limiting rất hữu ích cho endpoint có semantics rõ như login, search hoặc API quota, nhưng botnet phân tán có thể chia request qua nhiều source. Một global per-IP limit cũng có thể chặn user sau NAT.
Rate limiting nên là một lớp trong mô hình gồm HTTP DDoS managed protection, WAF, bot controls, caching và origin protection. Với login cụ thể, xem WAF + Rate Limiting cho wp-login.php.
WAF giúp gì trong HTTP Flood?
WAF có thể giảm traffic có pattern cụ thể, tạo challenge hoặc kết hợp với risk/bot signal. Nhưng generic WAF signature không thay DDoS system tự động. Nhiều HTTP flood không chứa SQLi/XSS mà chỉ là request hợp lệ với tần suất hoặc phân bố bất thường.
Cloudflare hiện tách HTTP DDoS Attack Protection managed ruleset khỏi WAF managed rules, dù các lớp có thể phối hợp. Khi incident xảy ra, cần biết action đến từ feature nào để tuning đúng chỗ.
Origin Protection là điều kiện quan trọng
Nếu attacker biết origin IP và có thể gửi request trực tiếp, mọi WAF/CDN/rate limit ở edge đều có thể bị bypass. Vì vậy Layer 7 protection chỉ hoàn chỉnh khi origin chấp nhận traffic từ đường vào được phê duyệt.
Xem Origin Protection: cách ngăn bypass CDN/WAF.
Quy trình triage Layer 7 DDoS
- Xác nhận user impact: timeout, latency hay 5xx.
- So sánh RPS hiện tại với baseline.
- Nhóm request theo host/path/method/status/cache status.
- Tìm endpoint có cost cao và mức tăng bất thường.
- Kiểm tra cache hit và origin request.
- Kiểm tra worker, CPU, DB pool và query latency.
- Xác định traffic có bypass edge không.
- Áp mitigation hẹp theo fingerprint/endpoint.
- Read-back impact sau mỗi thay đổi.
- Lưu evidence cho post-incident review.
Mitigation theo thứ tự ưu tiên
- giữ DDoS managed protection ở edge hoạt động đúng;
- khóa origin để tránh bypass;
- cache nội dung an toàn có thể cache;
- rate-limit endpoint có semantics rõ;
- challenge/bot control cho browser traffic nghi ngờ;
- custom WAF rule cho fingerprint có confidence cao;
- giảm endpoint cost ở application/database;
- scale chỉ là lớp bổ sung, không phải root fix duy nhất.
Không block rộng khi chưa biết fingerprint
Country block, ASN block hoặc blanket challenge có thể gây outage thứ hai cho user thật. Mitigation nên dựa trên evidence: path, method, request characteristics, bot/risk signal, rate pattern hoặc attack signature. Nếu confidence thấp, dùng log/challenge trước block.
Metric cần giữ sau incident
- peak RPS và duration;
- top host/path/method;
- cache hit ratio;
- unique IP/ASN/country distribution;
- WAF/DDoS rule ID và action;
- origin RPS và 5xx;
- CPU/worker/database saturation;
- time-to-detect và time-to-mitigate;
- false positive/legitimate impact;
- rule/architecture change đã áp dụng.
Để đặt các metric triage này vào kiến trúc phản ứng nhiều lớp, xem Cách giảm thiểu DDoS cho website: CDN, WAF, Rate Limit và Origin Protection.
Checklist nhận biết HTTP Flood
- RPS tăng ngoài baseline?
- Top path có thay đổi bất thường?
- Cache hit giảm?
- Origin RPS tăng nhanh?
- PHP/app worker đầy?
- DB latency/connection tăng?
- 5xx/timeout tăng?
- Traffic có phân tán qua nhiều IP?
- Request có entropy/query ngẫu nhiên?
- Origin có bị truy cập trực tiếp?
Kết luận
Layer 7 DDoS không nhất thiết phải có bandwidth cực lớn. Chỉ cần đủ request đắt để làm cạn worker, database hoặc upstream service, website đã có thể mất availability. Vì vậy nhận biết HTTP Flood phải nối được traffic ở edge với cost ở origin.
Sau khi xác định đúng Layer 7 attack, bước tiếp theo là phối hợp CDN/DDoS protection, WAF, rate limiting, cache và origin protection theo kiến trúc nhiều lớp thay vì phụ thuộc vào một threshold hoặc một rule duy nhất.