Bài phân tích này xem xét tình huống HTTP flood đánh vào các endpoint động của WordPress, làm PHP-FPM worker pool bão hòa và khiến request hợp lệ phải xếp hàng hoặc lỗi. Nội dung được xây dựng từ tài liệu công khai của Cloudflare, AWS, PHP và các pattern vận hành WordPress; đây không phải incident, số liệu vận hành hay case khách hàng thực tế của SecureWebOps.
HTTP flood ở Layer 7 nguy hiểm không chỉ vì số lượng request lớn. Với WordPress, mỗi request động có thể kích hoạt PHP, plugin logic, database query và các downstream calls. Nếu attacker liên tục đánh vào endpoint không cache được hoặc cố tình làm cache-busting, tải có thể dồn thẳng vào PHP-FPM cho đến khi worker pool bão hòa.
AWS mô tả HTTP flood/cache-busting là kiểu tấn công gửi nhiều GET/POST trông giống traffic người dùng thật, đồng thời thay đổi query string để tránh edge cache và buộc origin phải xử lý thêm tải. Cloudflare cũng mô tả Layer 7 DDoS có thể làm origin chậm hoặc crash khi request tăng đột biến. Nguồn: AWS WAF — Examples of DDoS attacks và Cloudflare — Under a DDoS attack?.
Bối cảnh và dấu hiệu ban đầu
Giả sử một website WordPress/WooCommerce chạy Nginx hoặc Apache phía trước PHP-FPM. Static assets phần lớn được cache, nhưng checkout, search, wp-login, REST API hoặc một số AJAX endpoint vẫn phải chạy PHP.
Trong một khoảng thời gian ngắn, origin bắt đầu tăng CPU, request latency kéo dài và người dùng hợp lệ gặp 502/503/504 hoặc timeout. Điểm quan trọng là edge bandwidth có thể chưa quá cao: bottleneck nằm ở application execution chứ không nhất thiết ở đường truyền.
Các tín hiệu đáng chú ý
- RPS tăng mạnh ở một số dynamic endpoint thay vì toàn site.
- PHP-FPM active processes tiến sát giới hạn pool.
- Request queue hoặc listen queue tăng trong khi worker rảnh gần như bằng 0.
- Latency tăng trước, sau đó mới xuất hiện 5xx hoặc timeout.
- Origin CPU cao nhưng cache hit ratio hoặc edge cache không giải thích được tải.
- Nhiều request có query string khác nhau khiến cache khó reuse.
Investigation: từ HTTP flood đến PHP-FPM saturation
Bước 1: tìm endpoint thật sự tiêu tốn tài nguyên
Không nên bắt đầu bằng việc block toàn bộ traffic. Trước hết cần nhóm request theo URI, method, query pattern, status code, source fingerprint và cache status để biết endpoint nào đang buộc origin chạy PHP nhiều nhất.
Cloudflare HTTP DDoS managed rules theo dõi các pattern như excessive traffic hitting origin/cache, protocol violations và request gây nhiều origin errors. Điều này củng cố việc dùng telemetry ở edge kết hợp origin log thay vì chỉ nhìn CPU. Nguồn: Cloudflare HTTP DDoS Attack Protection.
Bước 2: kiểm tra PHP-FPM thay vì chỉ nhìn load average
PHP manual xác nhận pm.max_children là số child process tối đa mà PHP-FPM có thể tạo và cũng là giới hạn số request có thể được phục vụ đồng thời. Khi mọi worker đều bận, request mới phải chờ hoặc thất bại tùy web server, timeout và queue configuration. Nguồn: PHP Manual — FPM configuration.
Vì vậy, bằng chứng nên bao gồm active/idle process, listen queue, max children reached, request duration, slowlog và endpoint tương ứng. Chỉ thấy “CPU 100%” chưa đủ để kết luận PHP-FPM saturation.
Bước 3: phân biệt attack với legitimate traffic spike
Một campaign, flash sale hoặc crawler hợp lệ cũng có thể tăng request. Phân biệt dựa trên distribution của endpoint, session behavior, cache-busting pattern, request repetition, geography/ASN, user-agent consistency, conversion/business event và correlation với edge security events.
WordPress support cũng có nhiều trường hợp public ghi nhận admin-ajax.php hoặc REST/AJAX request lặp lại gây CPU cao; các thread này không phải bằng chứng của incident SecureWebOps nhưng cho thấy dynamic WordPress endpoints có thể trở thành resource hotspot khi bị gọi với tần suất lớn. Nguồn tham khảo bổ sung: WordPress.org Support.
Root cause
Không phải chỉ vì “traffic nhiều”
Root cause trong tình huống này là sự kết hợp của request amplification ở application layer + dynamic endpoint cost + giới hạn worker concurrency. HTTP flood chỉ tạo áp lực; outage xảy ra khi mỗi request tiếp tục buộc origin làm đủ công việc đắt tiền và worker pool không còn headroom cho người dùng hợp lệ.
Cache-busting làm tình hình xấu hơn vì request không được phục vụ tại edge mà xuyên xuống origin. AWS mô tả chính pattern này: query-string variation làm mất hiệu quả cache và tạo strain bổ sung cho origin web server.
Khi nào có thể xác nhận root cause?
- HTTP telemetry xác nhận spike tập trung ở endpoint hoặc request pattern cụ thể.
- PHP-FPM metrics cho thấy active workers chạm ngưỡng hoặc queue tăng cùng thời điểm.
- Request profile cho thấy cache miss/dynamic execution cao.
- Khi giảm hoặc chặn đúng pattern, queue và latency phục hồi mà không cần restart toàn bộ stack.
- Legitimate traffic cùng endpoint vẫn hoạt động sau remediation.
Remediation
Containment: giảm request tới origin trước
Cloudflare khuyến nghị giảm số request đi tới origin bằng caching, WAF và các control ở edge. Với HTTP flood đang diễn ra, containment ưu tiên giảm workload chứ không phải lập tức tăng pm.max_children.
- Rate limit hoặc challenge đúng endpoint/pattern có chi phí cao.
- Cache các response có thể cache và normalize query string khi phù hợp.
- Block hoặc challenge cache-busting/automation pattern có confidence cao.
- Bảo vệ
wp-login.php, search, REST/AJAX endpoint theo baseline riêng. - Giữ origin chỉ nhận traffic từ CDN/WAF nếu kiến trúc cho phép.
Tham khảo nền tảng tại Rate Limiting là gì? và Cách giảm thiểu DDoS cho website.
Corrective action: giảm cost của dynamic path
- Profile endpoint chậm bằng PHP-FPM slowlog/APM.
- Giảm query hoặc plugin work không cần thiết trong request path.
- Đưa task dài ra background queue khi application architecture cho phép.
- Kiểm tra timeout giữa CDN, web server và PHP-FPM để tránh worker bị giữ quá lâu.
- Chỉ tune
pm.max_childrensau khi đo memory per worker và capacity thực tế; tăng worker mù quáng có thể chuyển bottleneck sang RAM, database hoặc upstream service.
Validation sau remediation
| Test | Kết quả mong đợi |
|---|---|
| Legitimate request tới endpoint bị target | PASS |
| Attack-like burst trong phạm vi test được phép | Bị rate limit/challenge trước origin |
| PHP-FPM active workers | Còn headroom, không chạm trần kéo dài |
| Listen/request queue | Không tăng liên tục |
| p95/p99 latency | Trở về baseline chấp nhận được |
| 5xx/timeout | Giảm về mức bình thường |
| Business flow | Checkout/login/API hợp lệ vẫn hoạt động |
Đọc thêm Cách giám sát resource saturation để phát hiện abuse để thiết lập baseline CPU, process, connection và request pattern.
Bài học vận hành và bước tiếp theo
- HTTP RPS không phản ánh đầy đủ mức độ nguy hiểm; cost/request quan trọng không kém.
- Dynamic endpoint cần baseline và protection riêng.
pm.max_childrenlà capacity limit, không phải biện pháp chống DDoS.- Cache-busting có thể biến request tưởng nhẹ thành origin-heavy traffic.
- Edge telemetry phải correlate được với web server và PHP-FPM metrics.
- Capacity tuning chỉ nên làm sau khi containment và profiling.
Phần kiến thức nền về loại tấn công xem Layer 7 DDoS là gì? Cách nhận biết HTTP Flood. Bài này tập trung vào chuỗi HTTP flood → dynamic execution → PHP-FPM saturation → remediation → validation.