Vụ Cloudflare “sập nguồn”: Vì sao lỗi cấu hình nghe có vẻ… chưa thuyết phục

[Heoanchayyy]

Khi sự cố Cloudflare tối hôm qua 18/11 xảy ra, tôi nhận ra đây không chỉ là chuyện một dịch vụ lớn gặp trục trặc. Từ một thay đổi tưởng chừng rất bình thường, sự cố lan ra khắp mạng lưới mà hàng ngày tôi vẫn cứ ngỡ là “ổn định”. Lúc đó tôi mới thấy rõ thực sự Internet phụ thuộc quá nhiều vào vài mắt xích trung tâm và chỉ một lỗi nhỏ cũng có thể làm cả thế giới lao đao.

Cú sốc toàn cầu và vị thế độc tôn​

Chiều tối ngày 18/11/2025 (theo giờ Việt Nam), tôi tin rằng hàng triệu người dùng tại Việt Nam và hơn 150 quốc gia khác đã đứng ngồi không yên khi truy cập mạng. Các trang web sập toàn cầu. Cụ thể chỉ trong vài phút, hơn 5.000 dịch vụ quen thuộc từ web phim, game online cho đến các nền tảng phổ biến của dân văn phòng như ChatGPT, X, Discord,... đều tê liệt.

Với chi phí hợp lý và tốc độ vượt trội, Cloudflare đã trở thành lựa chọn hàng đầu của hàng triệu website, ước tính xử lý hơn 20% lưu lượng Internet toàn cầu. Điều này đồng nghĩa chỉ cần một mắt xích trong mạng lưới gặp vấn đề, hiệu ứng domino sẽ xảy ra tức thì.

Nguyên nhân chính thức​

Sự cố ngày 18/11/2025 là một ví dụ rõ ràng cho thấy mức độ phụ thuộc này. Theo báo cáo chính thức, nguyên nhân phát sinh từ một thay đổi trong quyền truy cập cơ sở dữ liệu đã làm sai lệch truy vấn dữ liệu, khiến quy trình tự động tạo Feature File của Bot Management xuất ra nhiều bản ghi trùng lặp. Điều này làm kích thước tệp tăng đột biến, vượt ngưỡng xử lý của các Edge Server.

Tệp cấu hình quá khổ này đã được đồng bộ hóa tới các Edge Servers, vượt quá giới hạn bộ đệm được ấn định và khiến tiến trình xử lý bị sập hàng loạt. Lỗi nhỏ lập tức biến thành hiệu ứng dây chuyền, vốn rất dễ xảy ra trong các hệ thống phân tán quy mô lớn.

Tuy nhiên, việc một “file cấu hình phình to” lại đủ sức làm chao đảo cả Internet khiến tôi tự hỏi tại sao một sai sót cơ bản như vậy không bị chặn lại từ sớm? Rõ ràng, cơ chế triển khai cấu hình tự động đã thiếu các bộ lọc cơ bản để kiểm tra tính hợp lệ và giới hạn kích thước của tệp trước khi đẩy ra toàn cầu.

Nói cách khác, tôi tin rằng đây không phải là lỗi ngẫu nhiên, mà là biểu hiện rõ ràng của lỗ hổng trong quy trình Change Management - nền tảng cho các lỗ hổng sâu hơn.

Bốn giả thuyết có thể đứng sau sự cố​

Để hiểu vì sao một lỗi cấu hình có thể kéo sập hàng loạt dịch vụ toàn cầu, cần xem xét các kịch bản sâu hơn. Trong những sự cố hạ tầng lớn, “lỗi kỹ thuật” đôi khi chỉ là bề mặt – phía sau có thể là vấn đề quy trình, kiến trúc hoặc thậm chí là tác nhân cố ý. Dưới đây là ba giả thuyết đáng lưu ý dựa trên suy luận kỹ thuật.

1. Tấn công đúng thời điểm bảo trì (timing attack)​

Đây là một kịch bản tấn công tinh vi, kết hợp giữa sự cố bên trong và tác động bên ngoài. Các nhà phân tích thường cân nhắc rằng kẻ tấn công có thể lợi dụng thời điểm hệ thống đang bị tổn thương bởi các thay đổi cấu hình nội bộ (hoặc đang giảm khả năng phòng thủ) để tung ra một chiến dịch DDoS quy mô lớn.

Sự kết hợp giữa tải nặng nội bộ và tải nặng bên ngoài đã đẩy hệ thống vượt ngưỡng chịu đựng, làm bùng nổ lỗi dây chuyền và cản trở nỗ lực phục hồi.

Các giả thuyết này không có bằng chứng rõ ràng từ hãng, nhưng chúng đủ hợp lý để đặt câu hỏi về khả năng phòng thủ trong các kịch bản tấn công kép.

2. Khai thác zero-day trong thành phần cốt lõi​

Tốc độ lan truyền lỗi khiến nhiều người nghi ngờ khả năng về một lỗ hổng zero-day nhắm vào logic xử lý của hệ thống định tuyến nội bộ hoặc WAF.

Giả thuyết này cho rằng kẻ tấn công đã phát hiện và khai thác một lỗ hổng zero-day chưa từng được biết đến trong các giao thức Định tuyến Nội bộ hoặc trong phần mềm cốt lõi của Tường lửa Ứng dụng Web.

Việc khai thác có thể cho phép kẻ tấn công chèn dữ liệu vào vùng bộ nhớ lưu trữ cấu hình. Dữ liệu này cố tình làm cho vùng bộ nhớ đó vượt quá giới hạn, dẫn đến tình trạng tràn bộ nhớ đệm và khiến tiến trình chính bị sập.

3. Tấn công chuỗi cung ứng hoặc nội gián​

Giả thuyết này bác bỏ tính ngẫu nhiên của tệp cấu hình bị lỗi và nghi ngờ đó là kết quả của một hành vi chèn ép độc hại. Kẻ tấn công có thể đã chiếm đoạt tài khoản quản trị để đẩy cấu hình độc hại.

Kịch bản phức tạp hơn là tấn công vào chuỗi cung ứng phần mềm. Kẻ tấn công tiêm mã độc vào một thư viện bên thứ ba hoặc module được Cloudflare sử dụng để tự động tạo ra tệp cấu hình. Mã độc được lập trình để tạo ra một tệp lỗi có cấu trúc và kích thước nhằm gây ra lỗi tối đa ngay trong môi trường tin cậy, vượt qua các kiểm soát bảo mật thông thường.

4. Sai sót con người trong khâu triển khai cấu hình​

Nếu bỏ qua các kịch bản tấn công tinh vi, thì tôi nghĩ tới một khả năng thú vị là sự cố xuất phát từ nội bộ. Có thể một kỹ sư vô tình chỉnh sai cấu hình database hoặc logic code tạo Feature File chưa đủ “thông minh” để kiểm tra dữ liệu đầu ra. Dù là lỗi thao tác hay lỗi code, cú “vấp ngã” nhỏ này lập tức kéo theo việc quy trình tự động tạo ra tệp cấu hình chứa hàng loạt bản ghi trùng lặp.

Khi tệp cấu hình lỗi này được đồng bộ và đẩy tới hàng loạt Edge Servers, nó lập tức gây tràn bộ đệm và khiến các máy chủ này crash đồng loạt. Hiệu ứng dây chuyền diễn ra nhanh chóng, biến một thay đổi tưởng bình thường thành cơn khủng hoảng toàn cầu.

Nếu chuyện này là thật thì anh kỹ sư này chắc chắn phải chịu không ít trách nhiệm đâu.

Tạm kết​

Dù Cloudflare đã ra thông cáo chính thức, tôi thề là tôi vẫn không thể nào tin nổi một lỗi cấu hình nhỏ lại gây sập mạng diện rộng đến vậy. Tôi nghĩ, chắc chắn nhiều anh em làm hệ thống cũng có chung cảm giác bất hợp lý này. Tóm lại, vấn đề không phải là liệu họ có sập nữa hay không, mà là khi nào họ sập. Qua sự việc này, anh em mình nhớ: đừng bao giờ để một nhà cung cấp duy nhất quyết định số phận của mình. Thế nhé!