Ba ngày tháng Tám: Sự cố DDoS phơi bày lỗ hổng trong hạ tầng mạng

Vào tối ngày 11 tháng 8 năm 2026, một khách hàng của Nine.ch trở thành mục tiêu của cuộc tấn công lớn nhất từng nhắm vào hạ tầng của công ty. Vì Nine.ch cung cấp đường kết nối internet cho khách hàng này, tác động lan trực tiếp sang chính họ — và vài giờ sau, kẻ tấn công quay sang nhắm vào các dịch vụ của Nine.ch. Bài phân tích hậu sự cố dưới đây kể lại chi tiết ba ngày căng thẳng đó, lý do việc xử lý mất nhiều thời gian, và những gì đã thay đổi kể từ đó.

Minh họa cuộc tấn công DDoS vào tháng 8 năm 2026

Quy mô vượt xa năng lực của chính chúng tôi

Để hình dung độ lớn của sự việc: Nine.ch ước tính lưu lượng đỉnh đạt 500 đến 600 Gbit/s đổ vào toàn bộ các đường truyền kết hợp. Hai nhà cung cấp upstream đã xác nhận trực tiếp 260 Gbit/s trong số đó. Con số này lớn hơn nhiều lần so với tổng dung lượng đường uplink của chính họ — bất kể hệ thống phòng thủ nội bộ được thiết lập tốt đến đâu.

Điều đáng chú ý là các dịch vụ bị ảnh hưởng vào những thời điểm khác nhau: mọi ứng dụng trên nền tảng Deploio, website của chính Nine.ch, hệ thống Cockpit và hệ thống ticketing. Đây không phải một sự cố kéo dài liên tục 42 giờ, mà là một chuỗi các đợt tấn công theo từng làn sóng, xen kẽ những khoảng thời gian hoạt động bình thường. Từ khoảng 19h15 tối thứ Ba đến khoảng 12h51 thứ Năm, các làn sóng liên tục tái diễn với mục tiêu và cường độ thay đổi.

Một điều chưa bao giờ bị đe dọa trong suốt sự cố: an toàn dữ liệu của khách hàng. Không có truy cập trái phép, không có hệ thống nào bị xâm phạm. Đây là một cuộc tấn công làm quá tải, không phải xâm nhập.

Xác nhận từ dữ liệu đo lường bên ngoài

Dữ liệu đo lường độc lập từ nhóm nghiên cứu mối đe dọa Deepfield của Nokia củng cố nhận định của Nine.ch. Các cảm biến của Nokia được đăng ký như bot trên chính những máy chủ command-and-control (C2) mà kẻ tấn công sử dụng, nên họ ghi lại được lệnh tấn công thực tế ngay khi phát đi, chứ không chỉ lưu lượng sau đó đổ vào mục tiêu.

Dữ liệu này cho thấy có hai họ botnet tham gia: CECbot và Katana, đồng thời xác nhận trình tự sự việc mà Nine.ch quan sát được: cuộc tấn công ban đầu nhắm trực tiếp vào khách hàng, và chỉ mở rộng sang hạ tầng của Nine.ch khoảng ba giờ sau đó. Điều này khớp hoàn toàn với giả thuyết rằng Nine.ch bị đánh vì cung cấp kết nối internet cho khách hàng, chứ không phải là mục tiêu thực sự.

Một chi tiết đáng lưu ý riêng: khách hàng này công bố dải địa chỉ của họ qua hai nhà cung cấp khác nhau — Nine.ch và một đơn vị khác. Bất kỳ ai cố gắng lọc hoặc quy kết cuộc tấn công chỉ dựa trên mạng của Nine.ch sẽ chỉ thấy được một nửa bức tranh. Dữ liệu của Nokia không quy kết cuộc tấn công cho một chủ thể cụ thể nào, và Nine.ch cũng vậy.

Cơ chế thực sự của một cuộc tấn công như thế này

Kẻ tấn công sử dụng kỹ thuật UDP amplification — khuếch đại UDP. Nói đơn giản: chúng gửi những yêu cầu nhỏ đến các dịch vụ mở trên internet, nhưng thay vì dùng địa chỉ của chính mình làm nguồn gửi, chúng giả mạo địa chỉ của nạn nhân. Phản hồi trả về — lớn hơn yêu cầu gốc nhiều lần — không đến tay kẻ tấn công mà đổ thẳng vào mục tiêu. Một lượng băng thông nhỏ của kẻ tấn công biến thành khối lưu lượng khổng lồ, phân tán từ hàng chục nghìn nguồn trên toàn cầu.

Điểm mấu chốt cho mọi diễn biến tiếp theo: một khi đường uplink internet của bạn đã bị lấp đầy, việc lọc bên trong mạng nội bộ không còn giúp ích gì. Những gói tin bạn muốn lọc đã làm tắc nghẽn đường truyền trước khi chúng chạm tới bộ lọc, kéo theo cả lưu lượng hợp lệ dùng chung đường đó. Từ thời điểm này, việc giảm thiểu phải diễn ra ở vòng ngoài, tại các nhà cung cấp mang lưu lượng tới bạn.

Công cụ cho việc đó là blackholing. Nine.ch yêu cầu các upstream ngừng chuyển toàn bộ lưu lượng hướng đến một địa chỉ cụ thể và loại bỏ chúng thay vì gửi tới. Cách này bảo vệ đáng tin cậy toàn bộ mạng lưới và mọi khách hàng không liên quan. Cái giá phải trả: địa chỉ bị ảnh hưởng trở nên cố ý không thể truy cập trong thời gian đó, với tất cả mọi người, kể cả khách truy cập chính danh. Trong nhiều trường hợp, đây chính là lý do thực sự khiến một ứng dụng ngừng hoạt động — không phải vì hỏng hóc, mà vì địa chỉ đó bị hy sinh để giữ ổn định phần còn lại.

Điều khiến mọi thứ khó khăn hơn: kẻ tấn công không lùi bước. Khi Nine.ch chuyển website sang địa chỉ IP mới, địa chỉ đó lại bị tấn công trong vòng vài phút. Và không chỉ là vấn đề dung lượng thô — số lượng yêu cầu tự nó đủ sức làm quá tải từng dịch vụ riêng lẻ, bất kể băng thông. Điều này đòi hỏi một công cụ khác ngoài blackholing — công cụ có khả năng phân biệt lưu lượng hợp lệ với lưu lượng độc hại thay vì chặn cả hai một cách thô bạo.

Con đường trở lại hoạt động

Đây là lúc biện pháp cuối cùng chấm dứt sự cố xuất hiện. Khi đã rõ blackholing đơn thuần không trụ nổi trước một kẻ tấn công nhắm vào chính Nine.ch bằng số lượng yêu cầu khổng lồ, họ bắt đầu đưa các ứng dụng phơi bày ra sau bunny.net — một CDN châu Âu có tích hợp sẵn khả năng chống DDoS — vào một ngày sau khi sự cố bắt đầu, và hoàn tất di chuyển trong ngày kế tiếp. Khách hàng cũng đánh giá và triển khai các biện pháp bảo vệ bổ sung ở phía họ cùng lúc.

Quản lý hạ tầng mạng bằng mã nguồn

Kể từ đó, lưu lượng tấn công dừng lại tại nhà cung cấp bảo vệ, trong khi các yêu cầu hợp lệ vẫn đến được Nine.ch.

Một yếu tố thực sự giúp ích trong ba ngày đó: vì Nine.ch tự vận hành mạng của mình, họ có thể thay đổi định tuyến trực tiếp ngay khi cuộc tấn công còn đang diễn ra, và phối hợp các biện pháp bảo vệ bổ sung mà không phải chờ đợi thay đổi trên hạ tầng mạng của bên thứ ba. Đó là một phần lý do vì sao một cuộc tấn công quy mô này không biến thành sự cố ngừng hoạt động toàn phần kéo dài nhiều ngày.

Ba lỗ hổng được phát hiện

Nine.ch thừa nhận thẳng thắn ba lỗ hổng cụ thể thay vì tô hồng sự việc.

Thứ nhất, hệ thống phát hiện tấn công tự động chỉ được giới hạn cho các địa chỉ của chính Nine.ch. Những dải mạng mà họ công bố trên internet thay mặt khách hàng — nhưng thuộc sở hữu của khách hàng — không nằm trong hệ thống tự động đó. Làn sóng đầu tiên tấn công đúng vào một dải mạng như vậy, khiến phải mất khoảng 90 phút xử lý thủ công mới khống chế được. Lỗ hổng này được đóng lại ngay trong đêm đó.

Thứ hai, họ chưa bao giờ xác minh một cách hệ thống liệu tín hiệu blackhole có thực sự hiệu lực trên mọi đường truyền mà lưu lượng đi qua hay không. Tín hiệu đó chỉ áp dụng cho các peer đã được cấu hình blackholing trước, hoặc cho lưu lượng đến qua route server của các điểm trao đổi internet (IX). Tại các IX mà họ kết nối, không có thỏa thuận nào với các peer trực tiếp, nên blackholing ở đó chỉ bao phủ lưu lượng gửi qua route server, chứ không bao phủ lưu lượng trao đổi trực tiếp. Hơn nữa, họ chưa có cách giữ lại một dải mạng cụ thể khỏi đúng một nhà cung cấp cụ thể, nên phải xây dựng khả năng này ngay giữa cuộc tấn công, dưới toàn tải. Nó đã hoạt động, nhưng xây công cụ giữa cơn khủng hoảng luôn chậm và rủi ro hơn là chuẩn bị sẵn từ trước.

Thứ ba, và đây là hậu quả khó chịu nhất với nhiều khách hàng: website của chính Nine.ch chạy trên cùng nền tảng Deploio với các ứng dụng của khách hàng. Khi cuộc tấn công nhắm vào website của họ, các ứng dụng không liên quan trên cùng nền tảng cũng tự động bị ảnh hưởng. Và vì Cockpit cùng hệ thống ticketing sau đó cũng bị tấn công trực tiếp, một số khách hàng tạm thời mất ứng dụng, mất khả năng quản lý ứng dụng, và mất một phần kênh liên lạc với Nine.ch — tất cả cùng một lúc, đúng vào lúc họ cần hỗ trợ nhất.

Những gì đã thay đổi

Cả ba lỗ hổng đều đã được đóng hoặc đang được xử lý tích cực.

• Mọi dải mạng khách hàng mà Nine.ch công bố nay tự động nằm trong hệ thống phát hiện tấn công — đây là phần cố định trong quy trình chuẩn.
• Các ứng dụng phơi bày vẫn thường trực phía sau CDN của bunny.net với bảo vệ DDoS, và việc di chuyển thêm dịch vụ giờ là quy trình đã chuẩn bị sẵn thay vì phải ứng biến dưới áp lực.
• Họ theo dõi hiệu quả của các biện pháp giảm thiểu trên mọi đường truyền, và phối hợp chặt chẽ hơn với các upstream.
• Vì vẫn cố ý vận hành dịch vụ của mình trên Deploio — đúng nền tảng họ cung cấp cho khách hàng — họ đang cải tiến kiến trúc để các ứng dụng riêng lẻ phụ thuộc ít hơn vào địa chỉ dùng chung. Cockpit và hệ thống ticketing được gia cố thêm để khách hàng vẫn liên lạc được ngay cả khi đang bị tấn công. Kịch bản từ sự cố này nay là phần cố định trong các buổi diễn tập định kỳ, không còn chỉ là lý thuyết trên giấy.

Khuyến nghị dành cho người vận hành

Sự cố này dẫn đến một khuyến nghị cụ thể cho bất kỳ ai chạy domain riêng trên Deploio:

Hãy dùng bản ghi CNAME hoặc ALIAS thay vì bản ghi A.

Bản ghi A gắn domain của bạn vào một địa chỉ IP cụ thể trên nền tảng. Ràng buộc cố định đó chính là vấn đề trong suốt cuộc tấn công: ở đâu có thể thay đổi địa chỉ trong thời gian ngắn, khả năng truy cập được khôi phục; ở đâu không thể, chỉ còn biện pháp thô bạo là blackholing. Thêm nữa, các ứng dụng khác thường truy cập được qua cùng địa chỉ dùng chung — đúng rủi ro đã nêu ở trên. Đây là vấn đề kiến trúc từ phía Nine.ch, và họ đang xử lý. Trong lúc chờ đợi, CNAME hoặc ALIAS là bước hiệu quả nhất mà bạn có thể tự làm.

Và bất cứ khi nào có thể, hãy đặt một CDN có bảo vệ DDoS riêng phía trước ứng dụng của bạn. Đó chính xác là điều đã khôi phục khả năng truy cập cho Nine.ch. Với hầu hết cấu hình, công sức triển khai ở mức chấp nhận được và chi phí vận hành thấp.

Trước và sau sự cố

Nhìn từ góc độ vận hành, sự cố này để lại vài bài học phổ quát cho mọi tổ chức vận hành hạ tầng:

• Không thể phòng ngừa hoàn toàn một cuộc tấn công quy mô này — điều đó nằm ngoài tầm kiểm soát. Điều có thể kiểm soát là tốc độ phản ứng và số lượng khách hàng không liên quan bị vạ lây.
• Giám sát phải bao phủ toàn bộ phạm vi thực tế mà bạn công bố ra internet, chứ không chỉ các địa chỉ thuộc sở hữu trực tiếp.
• Xác minh tính hiệu lực của các biện pháp giảm thiểu trên từng đường truyền thay vì giả định chúng hoạt động ở mọi nơi.
• Không chạy dịch vụ quan trọng chung địa chỉ với hạ tầng công khai, nếu muốn tránh hiệu ứng domino.

So sánh các biện pháp bảo vệ hạ tầng

Nine.ch kết thúc bài phân tích bằng lời xin lỗi vì sự bất tiện trong ba ngày đó, và lời cảm ơn sự kiên nhẫn của khách hàng. Bản hậu sự cố kỹ thuật đầy đủ, bao gồm dòng thời gian chính xác của từng sự kiện, được họ công bố dưới dạng PDF riêng.