Từ ngày 8 đến 11 tháng 10 năm 2026, Yandex đã mất ba trung tâm dữ liệu: Sasovo và Vladimir đã ngừng hoạt động hoàn toàn, trong khi Kaluga hoạt động với sự suy giảm. Yandex Cloud đã chuyển sang chế độ khẩn cấp và đã khuyên khách hàng của mình kích hoạt các kế hoạch phục hồi khẩn cấp riêng. Điều thú vị nhất xảy ra sau đó. Cloudflare đã phân tích những gì đã xảy ra với các bot sống trong đám mây này và nhận thấy: chúng không biến mất, mà trong vòng một ngày đã chuyển đến các nhà cung cấp khác. Và chúng vẫn được nhận diện bởi cùng một dấu vân tay TLS JA4. Đối với tất cả những ai làm việc với việc phân tích và tự động hóa, đây là một thí nghiệm hiếm hoi về hai câu hỏi: phải làm gì khi cơ sở hạ tầng sụp đổ, và tại sao việc thay đổi IP và hosting không thay đổi "danh tính" của bot.
Điều gì đã xảy ra với Yandex
Theo thông tin từ BleepingComputer, Yandex đã thông báo về việc ba trung tâm dữ liệu bị thiệt hại do các cuộc tấn công bằng máy bay không người lái. Yandex không chỉ ra thủ phạm; các phương tiện truyền thông dẫn nguồn từ BBC liên kết các cuộc tấn công với Ukraine. Thời gian diễn ra như sau:
- 8 tháng 10 — Sasovo (tỉnh Ryazan): hỏa hoạn, khu vực ngừng hoạt động hoàn toàn;
- 9 tháng 10 — Kaluga: hoạt động với sự suy giảm, không ngừng hoàn toàn;
- 11 tháng 10 — Vladimir: ngừng hoạt động hoàn toàn.
Trên trang trạng thái của Yandex Cloud, một số dịch vụ (bảng điều khiển, API, IAM, cơ sở dữ liệu, S3, Kubernetes) vẫn có sẵn nhưng gặp vấn đề về hiệu suất, Compute và AI Studio hoạt động một phần. Công ty cho biết họ không thể đưa ra thời gian phục hồi đáng tin cậy, coi cấu hình tài nguyên còn lại là không ổn định và khuyên khách hàng sử dụng các kế hoạch phục hồi khẩn cấp thay thế. Không có thời gian phục hồi và sự rõ ràng về khả năng mất dữ liệu tại thời điểm công bố của BleepingComputer (12 tháng 10).
Cloudflare thấy gì: lưu lượng giảm, bot thì không
Vào ngày 14 tháng 10, Cloudflare đã công bố phân tích sự cố từ mạng của mình. Các con số chính:
- Vào ngày 11 tháng 10, lưu lượng từ mạng Yandex Search (AS13238) giảm 99% so với mức bình thường, từ Yandex.Cloud (AS200350) giảm 90%;
- 99,5% yêu cầu từ AS13238 trước sự cố là tự động, trong đó 93,6% yêu cầu bot là các crawler đã được xác minh của Yandex. Mạng này cung cấp khoảng 7% tất cả yêu cầu bot từ các IP của Nga;
- Tại Yandex.Cloud, khoảng 95% yêu cầu được đánh giá là bot, và không yêu cầu nào trong số đó là đã được xác minh. Đây là khoảng 2% lưu lượng bot của Nga;
- Lưu lượng bot từ Yandex.Cloud giảm khoảng 40%, quét các plugin WordPress từ mạng này giảm 90%.
Và điều quan trọng tiếp theo. Hầu hết các yêu cầu bot từ Yandex.Cloud đều được gửi đến một tài khoản khách hàng của Cloudflare trong lĩnh vực cờ bạc. Ngay sau sự cố vào ngày 8 tháng 10, các yêu cầu từ Yandex.Cloud đến tài khoản đó giảm xuống bằng không — và ngay lập tức xuất hiện các yêu cầu giống hệt từ các mạng của các nhà cung cấp hosting khác của Nga, Radist và Selectel. Với cùng một dấu vân tay JA4 của TLS, cùng những đường dẫn và tiêu đề hiếm gặp và cùng những chuỗi User-Agent không chuẩn. Kết quả trong một tuần: lưu lượng bot của Nga đến các tài khoản cờ bạc không giảm mà tăng — từ 167,7 triệu lên 170,1 triệu yêu cầu (+1,4%).
Kết luận của Cloudflare được đưa ra một cách cứng rắn: cơ sở hạ tầng vật lý là tĩnh, trong khi tự động hóa độc hại được xây dựng để có thể di chuyển. Sự sụt giảm lưu lượng HTTP cho thấy sự cố, nhưng không có nghĩa là các bot đã dừng lại.
Phiên bản ồn ào và dữ liệu: tại sao "các bot đã im lặng" lại là sự ph exaggeration
Song song, Trung tâm chống thông tin sai lệch của Ukraine (ЦПД) đã tuyên bố rằng sau cuộc tấn công vào Sasovo, số lượng thông báo từ các tài khoản nghi ngờ trên Facebook và Telegram trong một ngày đã giảm 83,6% — từ 4.032 xuống 660. Nhưng, như TechRadar đã phân tích, vào ngày 10 tháng 10, hoạt động đã trở lại với 4.585 thông báo, và vào ngày 11 tháng 10 đã vượt qua mức trước cuộc tấn công. Cloudflare không tìm thấy sự thay đổi đáng kể: lưu lượng bot từ các IP của Nga đến các điểm cuối "bài viết, phản hồi, thích" của một mạng xã hội chỉ giảm 5,7%. Graphika cũng không thấy mất mát tài khoản hoạt động trong các cộng đồng được theo dõi. Nhà nghiên cứu Renée DiResta trong Lawfare đã gọi câu chuyện này là đẹp, nhưng giống như một hư cấu hơn là một sự thật.
Một bài học riêng cho các nhà phân tích: vào ngày 8 tháng 10, các ngân hàng, bán lẻ, nhà cung cấp dịch vụ và phương tiện truyền thông trên toàn nước Nga đã gặp sự cố, vì vậy bất kỳ sự sụt giảm nào về "hoạt động" trong ngày đó không thể đơn giản quy cho các bot. Lưu lượng tổng hợp dễ dàng gây nhầm lẫn.
Bài học đầu tiên: IP và hosting không phải là danh tính của bot
Cloudflare đã nhận diện mối liên kết "Yandex.Cloud → Radist/Selectel" không phải qua địa chỉ — địa chỉ và ASN đã hoàn toàn thay đổi. Mà nhận diện qua hành vi và dấu vân tay của khách hàng:
- JA4 — băm TLS ClientHello: tập hợp các thuật toán mã hóa, mở rộng, phiên bản giao thức. Nó mô tả chương trình, không phải mạng. Cùng một script Python trên máy chủ mới sẽ cho cùng một JA4;
- các đường dẫn và tiêu đề hiếm gặp — thứ tự và tập hợp các tiêu đề HTTP mà không xuất hiện trên các trình duyệt thông thường;
- User-Agent riêng — chuỗi duy nhất, tự nó phục vụ như một nhãn.
Kết luận thực tiễn cho việc phân tích hợp pháp: việc thay đổi trung tâm dữ liệu hoặc nhóm IP không làm bạn trở thành "mới" đối với hệ thống chống bot, nếu toàn bộ ngăn xếp khách hàng vẫn giữ nguyên. Và ngược lại: nếu crawler của bạn tự giới thiệu một cách trung thực, hành xử cẩn thận và không tấn công vào các điểm nhạy cảm, dấu vân tay ổn định — không phải là vấn đề. Vấn đề phát sinh khi ngăn xếp trông giống như một thứ không tồn tại ở người dùng thực: Chrome được công bố với dấu vân tay TLS của thư viện requests, UA kỳ lạ, tiêu đề không chuẩn. Chúng tôi đã viết chi tiết về cách hoạt động của lớp phát hiện này trong phân tích JA4 và TLS-fingerprinting trong việc thu thập dữ liệu.
Hãy chú ý một chi tiết khác: các bot đã chuyển từ một trung tâm dữ liệu này sang các trung tâm dữ liệu khác. Đối với Cloudflare, đây vẫn là cùng một loại ASN hosting, mà nhiều trang web có sự không tin tưởng cao từ trước. Mạng khác — nhưng hồ sơ rủi ro vẫn như cũ.
Bài học thứ hai: cần biết cách di chuyển cơ sở hạ tầng trong vài giờ
Các kẻ xấu đã chuyển đi trong vòng một ngày, vì tự động hóa của họ vốn đã có thể di chuyển. Các đội ngũ trung thực, những người thu thập giá cả, theo dõi kết quả hoặc thực hiện phân tích, cũng cần sự di động như vậy. Khuyến nghị của Yandex Cloud "sử dụng các kế hoạch phục hồi khẩn cấp thay thế" chỉ tốt khi đã có kế hoạch như vậy. Danh sách kiểm tra tối thiểu:
- Mã và cấu hình — bên ngoài đám mây. Kho lưu trữ, hình ảnh container, biến môi trường phải được lưu trữ sao cho có thể triển khai parser tại một nhà cung cấp khác chỉ bằng một lệnh.
- Nhà cung cấp thứ hai trước. Tài khoản, thanh toán và máy chủ thử nghiệm tại một nhà cung cấp thay thế ở một khu vực và quyền tài phán khác. Đăng ký và kiểm tra vào ngày xảy ra sự cố — quá muộn.
- Lớp đầu ra tách biệt với tính toán. Nếu các yêu cầu đến các trang web mục tiêu đi qua nhà cung cấp proxy, chứ không phải trực tiếp từ IP của máy chủ, việc chuyển đổi tính toán không thay đổi địa lý, loại IP hay lịch sử phiên. Máy chủ có thể được chuyển, nhưng đối với trang web, bạn vẫn là cùng một khách hàng.
- Dữ liệu và hàng đợi — với việc sao chép. Kết quả thu thập dữ liệu và trạng thái nhiệm vụ được sao chép sang một kho lưu trữ khác, nếu không sau sự cố bạn sẽ phải bắt đầu lại từ đầu.
- Nhà cung cấp dự phòng — thực sự khác biệt. Hosting dự phòng hoặc nhà cung cấp proxy không nên là cùng một cơ sở hạ tầng dưới một thương hiệu khác. Chúng tôi đã phân tích cách kiểm tra điều này trên proxy trong tài liệu về tại sao nhà cung cấp proxy dự phòng có thể là cùng một nhóm.
- Cảnh báo huấn luyện. Mỗi quý, hãy khởi động parser trên một nền tảng dự phòng và chạy một nhiệm vụ thực tế. Kế hoạch mà chưa bao giờ được khởi động thường không hoạt động trong thực tế.
Loại proxy nào giải quyết vấn đề trong tình huống này
Proxy không cứu bạn khỏi dấu vân tay xấu — điều này rõ ràng từ ví dụ trong phân tích của Cloudflare. Nhưng chúng tách biệt "danh tính" của các yêu cầu của bạn khỏi nơi mà mã đang chạy vật lý:
- Proxy dân cư — cho các trang web mà ASN hosting bị cắt giảm trước hoặc nhận CAPTCHA. Khi chuyển máy chủ, đầu ra vẫn trên các IP gia đình của quốc gia cần thiết.
- Proxy trung tâm dữ liệu — cho API và các trang web thân thiện, nơi tốc độ và giá cả quan trọng. Chúng cũng nên được giữ tại một nhà cung cấp độc lập với đám mây của bạn, để sự cố hosting không kéo theo cả các IP đầu ra.
Trong khi đó, proxy chỉ là một lớp. Nếu ngăn xếp TLS, tiêu đề và hành vi của khách hàng của bạn nổi bật, chúng sẽ được nhận diện trên bất kỳ IP nào, như đã nhận diện các bot đã chuyển đến Radist và Selectel.
Điều này có nghĩa là gì đối với các chủ sở hữu trang web
Cloudflare cũng đưa ra kết luận ngược lại: ASN và lưu lượng tрафика — không phải là dấu hiệu đáng tin cậy của bot. Việc chặn "mạng xấu" hoạt động cho đến lần chuyển đầu tiên. Đáng tin cậy hơn là nhìn vào hành vi: các dấu vân tay JA4 chung giữa các mạng, tần suất yêu cầu bất thường và quy tắc WAF trên các điểm nhạy cảm bất kể yêu cầu đến từ đâu. Mặt trái của vấn đề cũng tồn tại: 40,5% khách hàng của Cloudflare đã phản hồi lại crawler của Yandex bằng mã 403, trong khi lưu lượng từ các mạng của Yandex đến các trang tin tức trong thời gian xảy ra sự cố đã giảm 44% — tức là trước tiên, việc lập chỉ mục hợp pháp đã bị ảnh hưởng.
Kết luận
Sự cố của Yandex đã trở thành một bài kiểm tra sống cho hai sự thật đơn giản. Đầu tiên: cơ sở hạ tầng có thể biến mất trong một ngày, và người chiến thắng là người biết cách di chuyển nó trong vài giờ — với mã bên ngoài đám mây, nhà cung cấp thứ hai và lớp đầu ra không gắn liền với máy chủ. Thứ hai: đối với hệ thống chống bot, bạn là ngăn xếp khách hàng của mình, chứ không phải IP của bạn. Một trung tâm dữ liệu mới với cùng một JA4 và cùng một User-Agent — đó là cùng một bot với địa chỉ mới. Hãy xây dựng việc thu thập dữ liệu sao cho nó có thể sống sót qua việc thay đổi nền tảng và vẫn trông giống như nhau trên bất kỳ IP nào.