DDoS protection cho website: Chọn đúng hạ tầng

DDoS protection cho website không chỉ là bật một tùy chọn trong hosting. Shared hosting thường dựa vào hệ thống lọc của nhà cung cấp, VPS có thể được bảo vệ ở tầng mạng nhưng vẫn cần tự xử lý ứng dụng, còn CDN chống DDoS hiệu quả nhất khi đóng vai trò reverse proxy và che giấu máy chủ gốc. Đặc biệt, các cuộc tấn công HTTP hiện đại nhắm vào DDoS layer 7 có thể dùng request hợp lệ để làm quá tải PHP, WordPress, cơ sở dữ liệu hoặc API.

Muốn chọn đúng giải pháp, bạn cần tách ba câu hỏi: lưu lượng bị chặn ở đâu, lớp nào được bảo vệ và traffic xấu có thể đi vòng qua hệ thống hay không.

DDoS protection cho website khác nhau thế nào trên shared hosting, VPS và CDN?

Hạ tầng	Lớp thường được bảo vệ	Ai cấu hình?	Điểm mạnh	Giới hạn chính	Phù hợp với
Shared hosting	Chủ yếu L3/L4 ở cấp nhà cung cấp; một số gói có WAF	Nhà cung cấp	Ít phải vận hành, chi phí thấp	Không kiểm soát firewall, rate limit và tài nguyên riêng	Blog, website giới thiệu nhỏ
VPS	Phụ thuộc nhà cung cấp; thường là L3/L4	Bạn và nhà cung cấp	Toàn quyền cấu hình hệ điều hành, web server và WAF	Vẫn có thể cạn CPU, RAM, băng thông; L7 phải tự thiết kế	Ứng dụng cần quyền quản trị
CDN reverse proxy	L3/L4 và L7 tùy dịch vụ, kèm cache, WAF	Nhà cung cấp CDN và bạn	Lọc traffic ở edge, giảm request đến origin	Origin lộ IP hoặc cổng phụ sẽ làm mất lợi thế	Website công khai, API, thương mại điện tử
CDN kết hợp WAF	L3/L4, L7, bot và rate limiting	Bạn xây chính sách; CDN thực thi	Bảo vệ URL, phương thức, header và hành vi	Cần học luật bảo mật, tránh chặn nhầm người dùng	Website có đăng nhập, API, giao dịch

Điểm cần nhớ là “có DDoS protection” không đồng nghĩa với “website luôn online”. Ví dụ, DigitalOcean mô tả lớp DDoS tích hợp cho Droplet là bảo vệ L3/L4 và không cung cấp bảo vệ L7; khi vượt năng lực giảm thiểu, nhà cung cấp có thể blackhole traffic, khiến cả request hợp lệ cũng không truy cập được (theo DigitalOcean Documentation).

Shared hosting: tiện nhưng phụ thuộc hoàn toàn vào nhà cung cấp

Trên shared hosting, nhiều website dùng chung máy chủ và đường truyền. Nhà cung cấp thường có bộ lọc biên, firewall, cân bằng tải hoặc chính sách tự động khi phát hiện lưu lượng bất thường. Tuy nhiên, bạn thường không biết chính xác ngưỡng lọc, thời gian phản ứng, cách xử lý HTTP flood hay giới hạn tài nguyên riêng của tài khoản.

Shared hosting có thể đủ cho website ít traffic, nhưng không nên xem nó là giải pháp chống DDoS chuyên dụng. Khi một cuộc tấn công làm tăng số kết nối hoặc request PHP, nhà cung cấp có thể giới hạn tài khoản, tạm khóa website hoặc yêu cầu chuyển sang gói cao hơn. Module như mod_evasive chỉ hữu ích trong phạm vi máy chủ còn đủ băng thông và năng lực xử lý; tài liệu cPanel cũng lưu ý rằng cơ chế này không thể thay thế lớp bảo vệ ở firewall và router (theo cPanel Documentation).

VPS: toàn quyền hơn nhưng không tự động an toàn hơn

VPS cho phép bạn cấu hình Nginx hoặc Apache, firewall, Fail2ban, cache, giới hạn kết nối và WAF. Đây là lợi thế lớn khi cần chống DDoS cho VPS. Nhưng quyền quản trị cũng đồng nghĩa với trách nhiệm: bạn phải cập nhật hệ điều hành, đóng cổng không cần thiết, theo dõi log và chuẩn bị phương án khi CPU, RAM hoặc băng thông bị tiêu thụ quá nhanh.

Firewall trên VPS có thể chặn IP, cổng hoặc giao thức, nhưng thường không cứu được một HTTP flood phân tán từ hàng nghìn địa chỉ. Nếu request đã đi tới Nginx rồi gọi PHP hoặc truy vấn cơ sở dữ liệu, việc chặn ở ứng dụng có thể đã quá muộn. Vì vậy, VPS nên đặt sau CDN/WAF khi website có nguy cơ bị tấn công L7.

Bạn có thể tham khảo hướng dẫn bảo mật Ubuntu Server để củng cố cấu hình ban đầu, sau đó kiểm tra web server, firewall và nhật ký truy cập theo từng dịch vụ.

DDoS layer 7: Vì sao CDN chống DDoS cần WAF và rate limiting?

DDoS L3/L4 thường nhắm vào băng thông, TCP, UDP hoặc giao thức. Ngược lại, DDoS layer 7 gửi request HTTP/S trông giống người dùng thật, chẳng hạn liên tục gọi trang tìm kiếm, đăng nhập, giỏ hàng hoặc API tốn tài nguyên. Một request hợp lệ nhưng lặp lại với tốc độ cao vẫn có thể làm nghẽn PHP worker, connection pool hoặc database.

CDN giúp giảm áp lực bằng cách lưu cache và phục vụ tài nguyên tĩnh tại edge. Khi nội dung đã được cache, request không nhất thiết phải đi tới origin (theo Cloudflare Learning Paths). Tuy vậy, CDN không thể cache mọi trang động và không tự hiểu endpoint nào đắt hơn endpoint nào. Đây là phần WAF và rate limiting phải đảm nhiệm.

WAF lọc nội dung và ngữ cảnh request

WAF có thể kiểm tra URI, phương thức HTTP, header, cookie, quốc gia, danh tiếng IP, mẫu truy vấn và dấu hiệu bot. Bạn có thể yêu cầu challenge với traffic đáng ngờ, chặn request tới đường dẫn quản trị hoặc giới hạn các phương thức không cần thiết.

WAF không nên được cấu hình theo kiểu chặn hàng loạt chỉ vì một User-Agent hoặc quốc gia. Botnet có thể phân tán địa chỉ IP, giả lập trình duyệt và thay đổi header. Chính sách tốt thường kết hợp nhiều tín hiệu: đường dẫn, tần suất, mã phản hồi, trạng thái đăng nhập và hành vi trong một khoảng thời gian.

Rate limiting bảo vệ endpoint đắt tiền

WAF và rate limiting bổ sung cho nhau. WAF quyết định request có đáng tin hay không; rate limiting giới hạn số lần một client hoặc một nhóm client được gọi tài nguyên trong khoảng thời gian nhất định. Cloudflare cho phép đặt điều kiện theo biểu thức, đặc tính đếm, khoảng thời gian, ngưỡng request và hành động như block, challenge hoặc throttle (theo Cloudflare WAF Documentation).

Ví dụ khởi đầu cho website WordPress:

/wp-login.php: challenge khi một IP vượt ngưỡng đăng nhập thất bại đã quan sát trong thực tế.
/wp-admin/: chỉ cho phép người dùng đã xác thực hoặc IP quản trị phù hợp.
/xmlrpc.php: tắt nếu website không sử dụng, hoặc giới hạn nghiêm ngặt.
/search và endpoint API: đặt ngưỡng thấp hơn trang bài viết vì mỗi request có thể truy vấn cơ sở dữ liệu.
Không áp dụng cùng một ngưỡng cho người dùng, crawler hợp lệ và API key khác nhau.

Không nên coi rate limiting là bộ đếm tuyệt đối. Cloudflare lưu ý bộ đếm có thể được tính theo từng trung tâm dữ liệu và có độ trễ vài giây, nên một lượng request vượt ngưỡng vẫn có thể tới origin trước khi hành động được áp dụng (theo Cloudflare WAF Documentation).

Cấu hình thực tế và cách kiểm tra hệ thống có thật sự chống DDoS

Quy trình triển khai theo thứ tự

Xác định origin: ghi lại IP máy chủ, cổng đang mở, DNS-only record, subdomain quản trị và dịch vụ email. Không để bản ghi phụ vô tình làm lộ IP origin.
Đưa website qua CDN proxy: chỉ bật proxy cho hostname web phù hợp. CDN cần đứng trước origin để lọc request trước khi chúng chạm máy chủ.
Khóa origin: trên firewall, chỉ cho phép IP của CDN truy cập cổng HTTP/HTTPS; SSH chỉ cho phép từ IP quản trị hoặc qua VPN. Cloudflare khuyến nghị allowlist IP của họ tại origin và kiểm tra các bản ghi DNS có thể chứa IP gốc (theo Cloudflare Documentation).
Bật WAF: bắt đầu ở chế độ quan sát hoặc challenge cho luật có rủi ro chặn nhầm, sau đó chuyển sang block khi đã kiểm tra log.
Đặt rate limit: ưu tiên login, search, checkout, upload và API; đếm theo IP, session, API key hoặc tài khoản tùy thiết kế.
Giảm tải origin: bật cache cho CSS, JavaScript, hình ảnh và trang có thể cache; tối ưu truy vấn, object cache và giới hạn worker PHP.
Chuẩn bị phương án sự cố: lưu backup, thông tin liên hệ nhà cung cấp, ngưỡng cảnh báo và quy trình chuyển sang trang tĩnh hoặc chế độ bảo trì.

Nếu bạn quản trị VPS Ubuntu, hãy kết hợp quy trình này với cấu hình SSL Let’s Encrypt tự động để bảo đảm kết nối CDN–origin được mã hóa và chứng chỉ không hết hạn.

Cách kiểm tra kết quả mà không tự tạo DDoS

Kiểm tra DNS công khai, lịch sử DNS và certificate transparency để phát hiện IP origin bị lộ.
Gửi một số request hợp lệ ở mức thấp tới login, search và API; xác nhận rule ghi nhận đúng nhưng không chặn người dùng bình thường.
Kiểm tra access log origin: request trực tiếp từ Internet phải bị từ chối, còn request từ CDN phải đi qua được.
So sánh cache hit, CPU, RAM, PHP workers, kết nối database và tỷ lệ lỗi 4xx/5xx trước và sau khi bật CDN.
Không dùng công cụ tạo flood trên website thật nếu chưa có văn bản cho phép. Hãy dùng môi trường staging hoặc bài kiểm tra tải có kiểm soát.

Lỗi thường gặp và cách khắc phục

Chỉ bật CDN nhưng vẫn để lộ IP origin: đổi IP origin, kiểm tra DNS cũ và khóa truy cập trực tiếp bằng firewall.
Chỉ chặn theo IP: chuyển sang đếm theo IP kết hợp path, session hoặc API key vì L7 thường phân tán nguồn.
Đặt ngưỡng quá thấp: phân tích traffic bình thường trước, dùng challenge cho bước đầu và whitelist có kiểm soát.
Tưởng cache giải quyết mọi thứ: xác định endpoint động, truy vấn nặng và request không thể cache.
Bỏ qua chi phí và giới hạn: đọc rõ chính sách nhà cung cấp về băng thông, request, blackhole, hỗ trợ sự cố và thời gian phản ứng.

Kết luận: shared hosting phù hợp website nhỏ nhưng bạn phụ thuộc vào chính sách của nhà cung cấp. VPS cho quyền kiểm soát và là nền tảng tốt để tự cấu hình, nhưng chống DDoS L7 không nên chỉ dựa vào firewall trên máy. Với website công khai, lựa chọn thực tế nhất thường là VPS hoặc hosting đặt sau CDN reverse proxy, kết hợp cache, WAF, rate limiting và khóa origin. Nếu ứng dụng có API, đăng nhập hoặc giao dịch, hãy ưu tiên thiết kế chính sách theo từng endpoint thay vì mua một gói được quảng cáo chung chung là “chống DDoS”.

DDoS protection cho website: Shared hosting, VPS và CDN xử lý đến đâu?