Tên miền đã chạy qua CDN nhưng băng thông máy chủ vẫn bị bão hòa. Đổi sang nhà cung cấp CDN khác mà máy chủ gốc vẫn bị tấn công. Trước tiên, hãy xác định liệu lưu lượng tấn công có đi vòng qua CDN để đến thẳng IP máy chủ hay không.

Khi IP máy chủ gốc đã lộ, website có thể cân nhắc CDN tích hợp chống DDoS kết hợp giới hạn truy cập vào máy chủ gốc. Nếu cuộc tấn công đã làm nghẽn đường truyền thượng nguồn, hoặc dịch vụ cần mở cổng TCP/UDP công khai, bạn cũng cần đánh giá khả năng lọc lưu lượng ở thượng nguồn, dịch vụ IP chống DDoS hoặc máy chủ chống DDoS. Đổi IP có thể là một bước khắc phục, nhưng trước hết phải chặn đường làm lộ IP.

Xác định nơi chịu tấn công trước khi chọn dịch vụ

Máy chủ gốc là nơi thực sự chạy website, API hoặc dịch vụ trò chơi. Việc người khác biết IP không có nghĩa là máy chủ đã bị xâm nhập. Điều cần xác định là địa chỉ đó chấp nhận những kết nối nào và lưu lượng tấn công có thể làm cạn kiệt tài nguyên ở đâu.

“Blackholing” thường là biện pháp nhà cung cấp loại bỏ lưu lượng đến một IP đích để bảo vệ mạng của họ. Truy cập hợp lệ cũng có thể bị gián đoạn. Điều kiện kích hoạt, thời gian áp dụng và cách gỡ bỏ phụ thuộc vào quy định của nhà cung cấp tương ứng.

Nếu dịch vụ đang gián đoạn, trước khi bàn đến việc di chuyển hệ thống, hãy yêu cầu nhà cung cấp hiện tại xác nhận thời gian bị tấn công, IP đích, lưu lượng đi vào và liệu đã áp dụng blackholing hay chưa. CPU tăng cao, website hết thời gian chờ hoặc cảnh báo CDN riêng lẻ không đủ để xác định lớp nào đang bị tấn công.

Vì sao máy chủ gốc vẫn có thể bị tấn công sau khi triển khai CDN chống DDoS?

CDN cho website thường nằm giữa người dùng và máy chủ gốc. Người dùng truy cập điểm biên; điểm này xử lý yêu cầu và lấy dữ liệu từ máy chủ gốc khi cần.

Khi biết IP máy chủ gốc, kẻ tấn công có thể kết nối trực tiếp đến địa chỉ đó. Không thể mặc định lưu lượng không đi qua CDN vẫn được dịch vụ proxy website của CDN bảo vệ.

Cần phân biệt hai loại áp lực:

• Tải yêu cầu ở lớp ứng dụng: Lượng lớn yêu cầu vào các API đăng nhập, tìm kiếm hoặc truy vấn tiêu tốn tài nguyên ứng dụng, cơ sở dữ liệu hay nhóm kết nối.
• Tải mạng và kết nối: Lượng lớn gói tin hoặc kết nối tiêu tốn dung lượng đường truyền, tài nguyên thiết bị mạng hay máy chủ, có thể gây sự cố trước cả khi ứng dụng nhận được yêu cầu.

Trong tài liệu về tấn công ở lớp hạ tầng, AWS cho biết các cuộc tấn công như phản xạ UDP và SYN flood có thể làm cạn kiệt dung lượng mạng hoặc tài nguyên hệ thống; việc giảm thiểu đòi hỏi năng lực lọc hoặc hấp thụ lưu lượng tấn công. Vì vậy, việc website trả về mã 403 và khả năng máy chủ gốc chịu được cuộc tấn công lưu lượng lớn là hai vấn đề khác nhau.

Mã 403 chỉ cho thấy một yêu cầu HTTP cụ thể đã bị từ chối. Nếu lưu lượng đã làm nghẽn đường truyền trước máy chủ gốc, quy tắc Nginx hoặc tường lửa trên máy chủ từ chối yêu cầu cũng không thể lấy lại dung lượng thượng nguồn đã bị chiếm dụng. Kết quả sẽ khác nếu lọc trước điểm nghẽn. Khi mua dịch vụ, hãy hỏi rõ lưu lượng thực sự bị loại bỏ hoặc lọc sạch ở đâu.

Kiểm tra những điểm truy cập máy chủ gốc còn lộ trước khi mua dịch vụ

Kiểm kê tên miền, địa chỉ và cổng dịch vụ

Đừng chỉ kiểm tra tên miền chính. Hãy lập danh sách địa chỉ IPv4 và IPv6 công khai, tên miền phụ và dịch vụ của mình, tập trung vào những điểm sau:

• Bản ghi DNS cũ, trang thử nghiệm, trang quản trị hoặc tên miền dự phòng còn trỏ đến máy chủ gốc hay không.
• Tên miền chính đi qua CDN, nhưng bản ghi A hoặc AAAA khác vẫn cho phép kết nối trực tiếp hay không.
• Dịch vụ email có dùng chung IP công khai với website hay không.
• Tài nguyên trang, cấu hình API hoặc URL callback được công bố có chứa địa chỉ máy chủ gốc hay không.
• SSH, máy tính từ xa, cơ sở dữ liệu và bảng quản trị có thực sự cần mở cho toàn bộ Internet hay không.

Tài liệu bảo vệ máy chủ gốc của Cloudflare khuyến nghị kiểm tra các bản ghi DNS không qua proxy, cách triển khai dịch vụ email và lịch sử bản ghi DNS, đồng thời cân nhắc thay IP máy chủ gốc sau khi bật proxy. Vấn đề thực tế là: DNS hiện tại không còn hiển thị máy chủ gốc không có nghĩa địa chỉ cũ chưa từng được ghi lại.

Nếu chưa rà soát các điểm truy cập này, bạn có thể dùng bài viết của chúng tôi về các đường lộ IP máy chủ gốc và cách bảo vệ để kiểm kê tài sản, sau đó xác minh từng cấu hình hiện tại.

Trên máy chủ gốc Linux đã cài ss, trước tiên có thể chạy lệnh chỉ đọc sau:

ss -lntup

Theo phần giải thích tùy chọn trong tài liệu lệnh ss, lệnh này liệt kê các cổng TCP đang lắng nghe và socket UDP liên quan, hiển thị địa chỉ và cổng dưới dạng số, đồng thời thử hiển thị tiến trình sở hữu. Một số thông tin tiến trình cần quyền phù hợp.

Hãy chú ý Local Address:Port. Dịch vụ gắn với 0.0.0.0 hoặc [::] cần được kiểm tra phạm vi truy cập, nhưng việc lắng nghe trên máy không đủ chứng minh dịch vụ có thể truy cập từ Internet. Còn phải xem nhóm bảo mật trên nền tảng đám mây, tường lửa và chuyển tiếp cổng. Ngược lại, chỉ kiểm tra IPv4 có thể bỏ sót điểm truy cập qua IPv6.

Dùng đúng tên miền khi kiểm tra kết nối trực tiếp

Không mở được “https://源站IP” trong trình duyệt không chứng minh rằng không thể đi vòng qua CDN. Máy chủ có thể chọn website và chứng chỉ theo tên miền; truy cập thẳng IP rất dễ chỉ thấy trang mặc định.

Lệnh dưới đây dùng trên terminal Linux hoặc macOS có cài curl. Chỉ kiểm tra máy chủ gốc mà bạn sở hữu hoặc được phép quản trị. Thay tên miền ví dụ và IP dành cho tài liệu 192.0.2.10 bằng cấu hình thực tế của mình, rồi gửi một yêu cầu từ mạng bên ngoài không nằm trong danh sách nguồn được phép kết nối đến máy chủ gốc:

curl --noproxy '*' -sS --connect-timeout 5 --max-time 10 \
  --resolve 'www.example.com:443:192.0.2.10' \
  -D - -o /dev/null \
  -w '\nstatus=%{http_code} remote=%{remote_ip}\n' \
  'https://www.example.com/'

Theo phần giải thích của curl về --resolve, tùy chọn này cung cấp địa chỉ đích cho một máy chủ và cổng được chỉ định. Cách kiểm tra giữ nguyên tên miền trong URL và tên máy chủ dùng khi bắt tay HTTPS, đồng thời hướng kết nối đến IP máy chủ gốc đã chỉ định. --noproxy '*' bỏ qua thiết lập proxy cục bộ; hai tham số timeout giới hạn thời gian chờ.

Trước tiên, kiểm tra remote có đúng là địa chỉ máy chủ gốc cần thử hay không, rồi đối chiếu header phản hồi với nhật ký trên máy chủ gốc:

Nếu máy chủ gốc dùng chứng chỉ Cloudflare Origin CA, tài liệu Origin CA của Cloudflare lưu ý rằng trình duyệt kết nối trực tiếp sau khi tắt proxy có thể báo chứng chỉ không đáng tin cậy. Khi chuyển sang CDN khác, cũng cần kiểm tra riêng yêu cầu xác thực chứng chỉ máy chủ gốc của dịch vụ đó; đừng mặc định chứng chỉ hiện tại được tin cậy.

Những phép kiểm tra với tần suất thấp này nhằm xác minh khả năng kết nối, không phải thử nghiệm năng lực chống DDoS. Một lần thành công hay thất bại cũng không phản ánh kết quả ở mọi khu vực và giao thức.

Khi nào nên ưu tiên CDN chống DDoS và cô lập máy chủ gốc?

Nếu dịch vụ chủ yếu là website hoặc API HTTPS, máy chủ hiện tại vẫn hoạt động bình thường, còn vấn đề chính là yêu cầu độc hại và điểm truy cập bị lộ, bạn có thể đánh giá phương án giữ nguyên máy chủ ứng dụng. CDN chống DDoS tiếp nhận lưu lượng vào website, trong khi phạm vi truy cập máy chủ gốc được thu hẹp.

Cách này thường giảm công việc di chuyển ứng dụng, nhưng cần thực hiện đồng thời ba việc.

Đưa đầy đủ các điểm truy cập cần bảo vệ qua dịch vụ.

Ngoài trang chủ, hãy kiểm tra API đăng nhập, tên miền phục vụ hình ảnh, chức năng tải tệp lên và xuống, WebSocket cùng các điểm truy cập khác. Khả năng hỗ trợ từng tính năng, giới hạn thời gian chờ hay kích thước phải được xác nhận theo cấu hình thực tế của nhà cung cấp. Cũng không nên lưu vào cache dữ liệu riêng của người dùng trong phản hồi động chỉ để tăng tỷ lệ cache hit.

Giới hạn nguồn được kết nối đến máy chủ gốc.

Yêu cầu nhà cung cấp cung cấp các địa chỉ IP đầu ra thực tế dùng để kết nối máy chủ gốc và cách cập nhật chúng. Phân biệt lưu lượng CDN đến máy chủ gốc, yêu cầu kiểm tra sức khỏe hệ thống và truy cập quản trị. Cho phép CDN kết nối không có nghĩa phải mở cả bảng quản trị và cơ sở dữ liệu cho những địa chỉ CDN đó.

Đánh giá việc xác thực yêu cầu đến máy chủ gốc.

Danh sách cho phép theo IP nguồn giúp thu hẹp phạm vi, nhưng IP đầu ra dùng chung có thể không phân biệt được yêu cầu của từng khách hàng. Hãy hỏi nhà cung cấp có hỗ trợ thông tin xác thực riêng hoặc xác thực TLS hai chiều phù hợp với dịch vụ của bạn hay không, đồng thời làm rõ cách bảo vệ, luân chuyển và thu hồi khóa. Chỉ kiểm tra tên miền trong header Host không chứng minh yêu cầu đến từ CDN của bạn.

Trước khi siết quy tắc truy cập, hãy bảo đảm kết nối hợp lệ từ CDN đến máy chủ gốc, kênh quản trị, hệ thống giám sát và việc gia hạn chứng chỉ vẫn hoạt động. Áp dụng ngay quy tắc “từ chối mọi nguồn khác” trên môi trường sản xuất có thể khiến chính dịch vụ của bạn bị ngắt.

Dịch vụ CDN chống DDoS của CDN07 kết hợp phân phối nội dung với bảo vệ chống DDoS và cho phép đánh giá cấu hình theo điểm biên, băng thông và chính sách bảo mật. Website đã có máy chủ gốc ở nước ngoài có thể xem xét các cấu hình này dựa trên kiến trúc hiện tại. Cách xác thực yêu cầu đến máy chủ gốc, quản lý IP đầu ra và các cổng được hỗ trợ cần được xác nhận riêng trước khi tích hợp.

Khi nào nên dành ngân sách cho bảo vệ thượng nguồn hoặc máy chủ chống DDoS?

Tấn công ảnh hưởng trực tiếp đến khả năng hoạt động của mạng máy chủ gốc

Nếu nhà cung cấp xác nhận IP máy chủ gốc liên tục hứng chịu tấn công lưu lượng lớn và tình trạng nghẽn mạng hoặc blackholing đã ảnh hưởng đến kết nối từ CDN, chỉ nâng cấp gói CDN cho website có thể không giải quyết được sự cố hiện tại.

Hãy so sánh các khả năng: nhà cung cấp hiện tại có thể bổ sung bảo vệ ở thượng nguồn không; có dịch vụ IP chống DDoS phù hợp không; việc đổi địa chỉ có thể đi kèm cô lập máy chủ gốc đầy đủ không; hay di chuyển sang máy chủ có mức bảo vệ phù hợp là lựa chọn tốt hơn.

Chuyển sang máy chủ chống DDoS không phải lựa chọn duy nhất. Nếu nền tảng hiện tại có thể lọc lưu lượng ở thượng nguồn đáp ứng nhu cầu, bạn có thể giảm công việc chuyển cơ sở dữ liệu, thay đổi lưu trữ và cấu hình lại mạng. Ngược lại, nếu nền tảng cũ không đáp ứng mức bảo vệ hoặc kết nối mạng mà dịch vụ cần, việc di chuyển sẽ có cơ sở hơn.

Khi mua máy chủ chống DDoS, hãy hỏi lưu lượng tấn công được xử lý ở đâu, những IP và cổng nào được bảo vệ, cũng như cách xử lý khi vượt phạm vi đã thỏa thuận. CPU và RAM lớn hơn giúp ứng dụng xử lý tải, nhưng không thay thế được bảo vệ đường truyền.

CDN07 cũng cung cấp máy chủ chống DDoS tại Hồng Kông. Nếu cần chuyển vị trí đặt máy chủ gốc, bạn có thể đánh giá tài nguyên máy chủ, kết nối mạng và điều kiện bảo vệ trong cùng một phương án. Phạm vi bảo vệ, băng thông phục vụ lưu lượng hợp lệ và quy định khi vượt ngưỡng cần được ghi rõ trong báo giá và thỏa thuận dịch vụ.

Dịch vụ dùng các cổng mà CDN cho website không thể tiếp nhận trực tiếp

Lưu lượng trận đấu trò chơi, thoại và giao thức TCP/UDP tùy chỉnh không trở thành lưu lượng website thông thường chỉ vì sử dụng tên miền. Cần kiểm tra giao thức, cổng, thời gian duy trì kết nối và cách máy khách kết nối.

Chẳng hạn, website của trò chơi có thể đi qua CDN cho website, nhưng các cổng kết nối trò chơi có thể cần hình thức bảo vệ khác. Với dự án có thể sửa ứng dụng phía máy khách, bạn có thể tham khảo bài so sánh SDK bảo vệ trò chơi và dịch vụ IP chống DDoS để đánh giá công sức tích hợp. Nếu không thể sửa máy khách, càng cần xác minh giải pháp phía máy chủ tương thích với giao thức hiện có.

Cũng không nên mặc định máy chủ chống DDoS bảo vệ mọi dịch vụ. Các cổng, giao thức, số kết nối, chính sách lọc lưu lượng và cam kết dịch vụ trong thời gian bị tấn công đều cần được xác nhận cụ thể.

Đổi IP có giải quyết được vấn đề không? Làm sao tránh lộ địa chỉ mới?

Đổi IP giúp dịch vụ cũ không còn chạy trên địa chỉ đã bị biết đến, giảm khả năng địa chỉ đó tiếp tục bị khai thác để tấn công. Nhưng việc này không tự khắc phục đường lộ IP trong tên miền, dịch vụ email hay cấu hình API, cũng không bảo đảm địa chỉ mới sẽ không bao giờ bị phát hiện.

Nên thực hiện theo thứ tự sau:

1. Lập danh sách phụ thuộc. Xác định chương trình, callback của bên thứ ba, danh sách IP được phép truy cập cơ sở dữ liệu và hệ thống giám sát còn phụ thuộc IP cũ; sao lưu cấu hình và chuẩn bị phương án quay lui.
2. Chuẩn bị địa chỉ và quy tắc truy cập mới. Thiết lập kết nối cần thiết từ CDN và kênh quản trị trước khi máy chủ gốc mới nhận lưu lượng chính thức; kiểm tra cả IPv4 lẫn IPv6.
3. Xác minh kết nối từ CDN đến máy chủ gốc mới. Kiểm tra chứng chỉ, tên miền dùng để kết nối máy chủ gốc, đăng nhập, tải tệp lên, API và các kết nối kéo dài; đừng chỉ xem trang chủ có mở được không.
4. Chuyển lưu lượng theo từng giai đoạn và theo dõi. Đối chiếu nhật ký CDN với máy chủ gốc, kiểm tra mã trạng thái bất thường, số yêu cầu và tỷ lệ giao dịch thành công.
5. Xử lý địa chỉ cũ và các điểm truy cập bỏ sót. Chỉ ngừng điểm truy cập cũ sau khi xác nhận di chuyển hoàn tất, tránh để tên miền dự phòng duy trì đường đi vòng lâu dài.

Đừng tạm đưa IP máy chủ gốc mới vào DNS công khai để gỡ lỗi rồi xóa đi. Nếu chuyển đổi thất bại, cũng đừng chuyển toàn bộ lưu lượng người dùng trực tiếp đến máy chủ gốc chưa được bảo vệ khi chưa đánh giá tác động.

Nếu có dấu hiệu xâm nhập, chẳng hạn xuất hiện quản trị viên không rõ nguồn gốc, tệp bị sửa hoặc thông tin đăng nhập bị lộ, cần xử lý sự cố bảo mật riêng. Đổi IP và triển khai dịch vụ chống DDoS không thay thế cho việc điều tra xâm nhập.

So sánh báo giá thế nào để chọn đúng phương án?

Đừng chỉ hỏi “chống được bao nhiêu Gbps, mỗi tháng bao nhiêu tiền”. Hãy cung cấp cho nhà cung cấp các điểm truy cập dịch vụ và bằng chứng sự cố để so sánh chi phí giải quyết cùng một vấn đề.

Với dịch vụ vừa chịu yêu cầu độc hại vào website vừa bị tấn công IP máy chủ gốc, có thể kết hợp CDN chống DDoS với máy chủ gốc được bảo vệ. Nhưng không nên mặc định phải mua cả hai lớp. Hãy tìm lớp bảo vệ còn thiếu rồi mới quyết định bổ sung.

Ứng dụng vẫn cần xác thực, giới hạn tốc độ hợp lý và khắc phục lỗ hổng. Bài viết của chúng tôi về cách phối hợp WAF, quản lý bot và chống DDoS trình bày vai trò của từng cơ chế. Khi chọn dịch vụ, hãy xác nhận chính sách nào xử lý tấn công mạng, yêu cầu độc hại và hành vi lạm dụng ứng dụng, thay vì gộp mọi trách nhiệm vào một nhãn “chống DDoS”.

Câu hỏi thường gặp

IP máy chủ gốc đã lộ thì CDN chống DDoS còn hữu ích không?

Có. Dịch vụ đi qua CDN vẫn có thể được tăng tốc và bảo vệ theo khả năng tương ứng. Tuy nhiên, đường kết nối trực tiếp đến IP máy chủ gốc đã biết cần được xử lý riêng, có thể bằng giới hạn truy cập, xác thực yêu cầu, đổi địa chỉ hoặc bảo vệ máy chủ gốc ở thượng nguồn.

Chỉ cho phép các điểm biên CDN kết nối đến máy chủ gốc có chặn được mọi cuộc tấn công DDoS không?

Không. Biện pháp này chủ yếu giới hạn nguồn mà máy chủ gốc chấp nhận kết nối ứng dụng. Nếu việc lọc diễn ra bên trong máy chủ trong khi cuộc tấn công đã làm nghẽn đường truyền thượng nguồn, kết nối hợp lệ từ CDN vẫn có thể thất bại. Cần xem vị trí lọc, dung lượng thượng nguồn và cơ chế lọc lưu lượng của nhà cung cấp.

Không đổi được IP máy chủ thì bắt buộc phải di chuyển sao?

Không hẳn. Trước tiên hãy hỏi nhà cung cấp hiện tại có hỗ trợ bảo vệ ở thượng nguồn cho địa chỉ đang dùng không và kiểm tra khả năng siết chặt điểm truy cập dịch vụ, quản trị. Nếu năng lực bảo vệ, tương thích giao thức hoặc điều kiện mạng không đáp ứng, lúc đó hãy so sánh chi phí di chuyển.

Chuyển sang máy chủ chống DDoS rồi có cần CDN chống DDoS nữa không?

Điều đó phụ thuộc website còn cần phân phối nội dung, cải thiện tốc độ truy cập hoặc chính sách chi tiết hơn tại điểm truy cập hay không. Vai trò của máy chủ và CDN vừa có phần giao nhau vừa có điểm khác biệt; không cần mua trùng cho nhu cầu đã được đáp ứng.

Không ping được máy chủ gốc có nghĩa IP đã được ẩn thành công không?

Không. Ping dùng ICMP, khác với kết nối HTTPS của website. Muốn xác minh có thể truy cập trực tiếp ứng dụng hay không, phải thử theo tên miền, cổng và giao thức thực tế. Ping cũng không cho biết IP đã từng bị lộ trong quá khứ hay chưa.

Làm sao nghiệm thu hiệu quả khắc phục?

Ít nhất cần kiểm tra riêng: người dùng hợp lệ có truy cập được dịch vụ không; CDN có kết nối ổn định đến máy chủ gốc không; nguồn không được phép có đi vòng qua quy tắc truy cập được không; tên miền cũ và điểm truy cập IPv6 đã được giới hạn chưa. Năng lực chống tấn công lưu lượng lớn cần được đánh giá theo thỏa thuận dịch vụ, cơ chế lọc và kế hoạch thử nghiệm được cả hai bên cho phép; vài yêu cầu curl không thể chứng minh điều đó.

Sau khi IP máy chủ gốc bị lộ, bước tiếp theo là gì?

• CDN chống DDoS chủ yếu bảo vệ lưu lượng đi qua nó; cần đánh giá riêng các cuộc tấn công trực tiếp vào máy chủ gốc.
• Kiểm soát truy cập có thể giảm đường đi vòng nhưng không thay thế bảo vệ đường truyền ở thượng nguồn.
• Việc đổi IP phải đi kèm rà soát đường lộ, xác minh kết nối từ CDN và ngừng các điểm truy cập cũ.
• Có nên chuyển sang máy chủ chống DDoS hay không phụ thuộc nhu cầu bảo vệ mạng, giao thức dịch vụ và khả năng của nền tảng hiện tại.

Hãy tổng hợp tên miền dịch vụ, giao thức và cổng, khu vực người dùng mục tiêu, vị trí máy chủ gốc cùng bản ghi tấn công do nhà cung cấp cung cấp. Khi chia sẻ địa chỉ máy chủ gốc và nhật ký, hãy dùng kênh trao đổi có kiểm soát, tránh công khai cấu hình nhạy cảm.

Nếu cần so sánh hai hướng triển khai CDN và di chuyển máy chủ gốc, hãy mang theo danh sách này và liên hệ CDN07 để trao đổi về phương án bảo vệ. Chúng tôi khuyên bạn làm rõ riêng điểm truy cập, kết nối từ CDN đến máy chủ gốc và bản thân máy chủ gốc trước khi chọn tổ hợp sản phẩm và báo giá, để ngân sách bổ sung giải quyết đúng khoảng trống bảo vệ.