Chống DDoS cho máy chủ dedicated: lớp L3/L4/L7 thực tế

DDoS làm gián đoạn dịch vụ bằng lưu lượng hoặc request vượt khả năng xử lý của hệ thống. Đối với máy chủ thuê, cần đánh giá cả đường truyền trước máy chủ và tài nguyên của ứng dụng. Một firewall trên server không giải quyết được mọi tấn công nếu uplink đã đầy.

Phân biệt mục tiêu tấn công

Một sự cố có thể kết hợp nhiều nhóm. Khi chẩn đoán, đối chiếu bps, packets/s, connections, request/s, latency và error rate. Traffic cao cũng có thể là truy cập hợp lệ; không kết luận DDoS chỉ từ một biểu đồ.

Nhà cung cấp bảo vệ phần nào?

• Điểm lọc có nằm trước uplink giới hạn của khách không?
• Bảo vệ IPv4/IPv6, TCP/UDP hay HTTP theo phạm vi nào?
• Profile có phù hợp giao thức game, API hoặc VPN không?
• Khi vượt ngưỡng, dịch vụ lọc, giảm tốc hay blackhole?
• Thời gian kích hoạt, thông báo và liên hệ khẩn cấp?

Không dùng quy mô tổng của hệ thống scrubbing để suy ra mức bảo vệ dành cho từng khách. Cần phạm vi và điều kiện cụ thể trong báo giá. Blackhole có thể bảo vệ phần mạng còn lại nhưng cũng làm đích bị chặn không truy cập được.

Bảo vệ website và API qua proxy

Đối với HTTP được đưa qua CDN/WAF, cần bảo vệ origin để tránh kết nối bỏ qua lớp proxy. Cloudflare khuyến nghị các cơ chế giới hạn truy cập origin và xác thực phù hợp. Allowlist IP proxy có thể là một lớp kiểm soát, nhưng cần xử lý cả IPv4/IPv6 và các luồng quản trị cần thiết.

Khi ứng dụng lấy IP người dùng từ header, chỉ tin header do proxy tin cậy chuyển đến. Nếu origin cho phép truy cập trực tiếp và tin header bất kỳ, cơ chế rate limit theo IP có thể bị sai. Kiểm thử trước khi thay firewall và giữ kênh console để xử lý khóa nhầm.

Game UDP và dịch vụ ngoài HTTP

WAF HTTP không thay thế bảo vệ lưu lượng game UDP hoặc SSH. Hỏi phương án phù hợp từng cổng và giao thức. Không áp dụng chặn toàn UDP khi hệ thống cần DNS, VPN hoặc giao thức ứng dụng dùng UDP; xác định luồng cần thiết trước.

Checklist ứng dụng

• Chỉ mở cổng cần dùng; hạn chế quản trị vào IPMI và hypervisor.
• Giới hạn request/connection theo khả năng xử lý, có ngoại lệ phù hợp.
• Cache nội dung và giảm truy vấn đắt ở endpoint public.
• Giới hạn kích thước request và thời gian xử lý.
• Giám sát error rate, queue, CPU và database.
• Có log tập trung và cảnh báo trước khi tài nguyên cạn.

Quy trình khi nghi ngờ DDoS

1. Ghi thời gian, IP đích, cổng/giao thức và ảnh hưởng khách.
2. Kiểm tra tải mạng cùng log ứng dụng để xác định lớp bị nghẽn.
3. Liên hệ nhà cung cấp với số liệu; xác nhận biện pháp và tác động.
4. Áp dụng rule có phạm vi rõ, theo dõi truy cập hợp lệ và chuẩn bị rollback.
5. Sau sự cố, rà soát ngưỡng, điểm lỗi và quy trình thông báo.

Chống DDoS không thay thế backup hay bảo mật tài khoản. Một sự cố mạng và một sự cố mã hóa dữ liệu cần quy trình phục hồi khác nhau. Khi thuê máy chủ, gửi giao thức, tải bình thường và mức gián đoạn chấp nhận được để xác nhận gói bảo vệ phù hợp.