2026년 10월 8일부터 11일까지, 야ндекс는 세 개의 데이터 센터를 잃었습니다: 사소보와 블라디미르가 완전히 중단되었고, 칼루가는 성능 저하로 운영되었습니다. Yandex Cloud는 비상 모드로 전환되었고, 고객들에게 자체 재해 복구 계획을 활성화할 것을 권장했습니다. 가장 흥미로운 일은 그 이후에 발생했습니다. Cloudflare는 이 클라우드에 살고 있던 봇들이 어떻게 되었는지 분석했으며, 그들은 사라지지 않고 하루 만에 다른 호스팅 업체로 이동했음을 확인했습니다. 그리고 그들은 동일한 TLS 지문 JA4로 인식되었습니다. 파싱과 자동화에 종사하는 모든 이들에게 이는 인프라가 중단될 때 무엇을 해야 하는지, IP와 호스팅 변경이 봇의 '정체성'을 어떻게 변화시키지 않는지를 보여주는 드문 실험입니다.
야ндекс에 무슨 일이 있었나
BleepingComputer의 보도에 따르면, 야ндекс는 드론 공격으로 인해 세 개의 데이터 센터가 손상되었다고 밝혔습니다. 야ндекс는 가해자를 명시하지 않았고, BBC를 인용한 언론은 우크라이나와의 연관성을 제기했습니다. 연대기는 다음과 같습니다:
- 10월 8일 — 사소보 (리자주): 화재, 사이트 완전히 중단;
- 10월 9일 — 칼루가: 성능 저하로 운영, 완전 중단 아님;
- 10월 11일 — 블라디미르: 완전히 중단.
Yandex Cloud의 상태 페이지에서 일부 서비스(콘솔, API, IAM, 데이터베이스, S3, Kubernetes)는 성능 문제와 함께 여전히 접근 가능했습니다. Compute와 AI Studio는 부분적으로 작동했습니다. 회사는 신뢰할 수 있는 복구 일정은 제시할 수 없으며, 남은 자원 구성은 불안정하다고 판단하고 고객들에게 대체 재해 복구 계획을 사용할 것을 권장했습니다. BleepingComputer의 발표 시점인 10월 12일에는 복구 일정과 데이터 손실 가능성에 대한 명확한 정보가 없었습니다.
Cloudflare가 본 것: 트래픽은 감소했지만 봇은 아니다
10월 14일, Cloudflare는 자사 네트워크 측에서의 사고 분석을 발표했습니다. 주요 수치는 다음과 같습니다:
- 10월 11일, 야ндекс 검색 네트워크(AS13238)에서의 트래픽은 정상의 99% 감소했으며, Yandex.Cloud(AS200350)에서는 90% 감소했습니다;
- AS13238에서의 요청의 99.5%는 자동화된 것이었고, 그 중 93.6%는 야덱스의 인증된 크롤러였습니다. 이 네트워크는 러시아 IP에서 발생하는 모든 봇 요청의 약 7%를 차지했습니다;
- Yandex.Cloud에서는 평가된 요청의 약 95%가 봇이었으며, 그 중 인증된 것은 없었습니다. 이는 러시아 봇 트래픽의 약 2%에 해당합니다;
- Yandex.Cloud에서의 봇 트래픽은 약 40% 감소했으며, 이 네트워크에서의 WordPress 플러그인 스캔은 90% 감소했습니다.
그리고 가장 중요한 점은, Yandex.Cloud에서의 거의 모든 봇 요청이 Cloudflare의 한 고객 계정으로 향하고 있었다는 것입니다. 10월 8일 사고 직후 Yandex.Cloud에서의 요청은 0으로 감소했으며, 곧 다른 러시아 호스팅 네트워크인 Radist와 Selectel에서 동일한 요청이 발생했습니다. 동일한 JA4 TLS 지문, 동일한 드문 경로와 헤더, 동일한 비표준 User-Agent 문자열로 말입니다. 일주일 후의 결과: 러시아의 도박 계정에 대한 봇 트래픽은 감소하지 않고 증가했습니다 — 1억 6,770만에서 1억 7,010만 요청으로 (+1.4%) 증가했습니다.
Cloudflare의 결론은 엄격하게 제시되었습니다: 물리적 인프라는 정적이며, 악의적인 자동화는 이동할 수 있도록 설계되었습니다. HTTP 트래픽의 감소는 사고를 나타내지만, 봇이 멈췄다는 것을 의미하지는 않습니다.
소음 버전과 데이터: 왜 '봇들이 침묵했다'는 과장된 것인가
동시에 우크라이나의 정보 왜곡 방지 센터(CPD)는 사소보에 대한 공격 이후 Facebook과 Telegram에서 의심스러운 계정의 보고 수가 하루 만에 83.6% 감소했다고 발표했습니다 — 4,032에서 660으로. 그러나 TechRadar가 분석한 바에 따르면, 10월 10일에는 활동이 4,585로 돌아왔고, 10월 11일에는 공격 전 수준을 초과했습니다. Cloudflare는 눈에 띄는 변화가 없음을 발견했습니다: 러시아 IP에서의 '게시물, 응답, 좋아요'와 같은 소셜 미디어 엔드포인트에 대한 봇 트래픽은 단지 5.7% 감소했습니다. Graphika 역시 추적된 커뮤니티에서 활성 계정의 손실을 발견하지 못했습니다. 연구원 레네 디레스타는 Lawfare에서 이 이야기를 아름답지만 사실보다는 허구에 가깝다고 언급했습니다.
분석가들에게 주는 별도의 교훈: 10월 8일, 러시아 전역에서 은행, 소매업체, 통신사 및 언론이 중단되었기 때문에, 이날의 '활동 감소'를 봇 탓으로 돌리는 것은 신중해야 합니다. 집계된 트래픽은 쉽게 오해를 불러일으킬 수 있습니다.
첫 번째 교훈: IP와 호스팅은 봇의 정체성이 아니다
Cloudflare는 'Yandex.Cloud → Radist/Selectel'의 연관성을 주소로 인식하지 않았습니다 — 주소와 ASN이 완전히 변경되었습니다. 대신 행동과 클라이언트 지문으로 인식했습니다:
- JA4 — TLS ClientHello 해시: 암호화 집합, 확장, 프로토콜 버전. 이는 프로그램을 설명하며, 네트워크를 설명하지 않습니다. 동일한 Python 스크립트가 새로운 서버에서 동일한 JA4를 생성합니다;
- 드문 경로와 헤더 — 일반 브라우저에서는 발견되지 않는 HTTP 헤더의 순서와 집합;
- 고유한 User-Agent — 자체적으로 라벨 역할을 하는 고유한 문자열입니다.
합법적인 파싱을 위한 실용적인 결론: 데이터 센터나 IP 풀의 변경은 클라이언트 스택이 동일하다면 안티봇에게 '새로운' 존재가 되지 않습니다. 반대로, 크롤러가 정직하게 자신을 나타내고 조심스럽게 행동하며 민감한 엔드포인트를 공격하지 않는다면, 안정적인 지문은 문제가 되지 않습니다. 문제는 스택이 실제 사용자에게는 존재하지 않는 것처럼 보일 때 발생합니다: TLS 지문이 requests 라이브러리와 함께하는 Chrome로 주장되거나, 이국적인 UA, 비표준 헤더가 있을 때입니다. 이 탐지 계층이 어떻게 구성되어 있는지에 대한 자세한 내용은 JA4 및 TLS 지문 인식 스크래핑에서 다루었습니다.
또한 한 가지 세부 사항을 주목하십시오: 봇들은 한 데이터 센터에서 다른 데이터 센터로 이동했습니다. Cloudflare에게 이는 여전히 많은 사이트에서 사전에 높은 불신을 받는 호스팅 ASN의 범주입니다. 네트워크는 다르지만, 위험 프로필은 동일합니다.
두 번째 교훈: 인프라는 몇 시간 안에 이동할 수 있어야 한다
악의적인 사용자들은 하루 만에 이동할 수 있었던 이유는 그들의 자동화가 본래 이동 가능했기 때문입니다. 가격을 수집하거나 결과를 모니터링하거나 분석을 수행하는 정직한 팀에게도 이러한 이동 가능성이 필요합니다. Yandex Cloud의 '대체 재해 복구 계획을 사용하십시오'라는 권고는 그러한 계획이 이미 있을 때만 유효합니다. 최소 체크리스트는 다음과 같습니다:
- 코드와 구성 — 클라우드 밖에. 저장소, 컨테이너 이미지, 환경 변수는 다른 호스팅 업체에서 파서를 배포할 수 있도록 배치되어야 합니다.
- 두 번째 호스팅 업체 미리 확보. 다른 관할권과 지역의 대체 제공업체에서 계정, 결제 및 테스트 서버를 미리 확보해야 합니다. 사고 당일에 등록하고 검증을 받는 것은 늦습니다.
- 출력 계층은 계산과 분리. 목표 사이트에 대한 요청이 서버의 IP에서 직접가 아니라 프록시 제공업체를 통해 이루어지면, 계산의 이동은 지리적 위치, IP 유형, 세션 이력을 변경하지 않습니다. 서버는 이동할 수 있지만, 사이트에 대해서는 여전히 동일한 클라이언트로 남아 있습니다.
- 데이터와 큐는 복제와 함께. 파싱 결과와 작업 상태는 다른 저장소에 복사되어야 하며, 그렇지 않으면 사고 후 다시 시작해야 합니다.
- 대체 제공업체는 실제로 다르다. 백업 호스팅이나 프록시 제공업체는 다른 브랜드 아래 동일한 인프라가 되어서는 안 됩니다. 프록시에서 이를 확인하는 방법은 왜 백업 프록시 제공업체가 동일한 풀일 수 있는지에서 다루었습니다.
- 훈련 경고. 분기마다 백업 사이트에서 파서를 실행하고 실제 작업을 수행하십시오. 한 번도 실행하지 않은 계획은 실제로는 작동하지 않는 경우가 많습니다.
이런 상황에서 각기 다른 프록시 유형이 해결하는 문제
프록시는 나쁜 지문으로부터 보호하지 않으며 — 이는 Cloudflare의 분석 사례에서 볼 수 있습니다. 하지만 그들은 요청의 '얼굴'를 코드가 물리적으로 실행되는 위치와 분리합니다:
- 주거용 프록시 — 호스팅 ASN이 사전에 차단되거나 CAPTCHA를 받는 사이트에 적합합니다. 서버를 이동할 때 필요한 국가의 가정용 IP로 나갈 수 있습니다.
- 데이터 센터 프록시 — API 및 친화적인 사이트에 적합하며, 속도와 가격이 중요합니다. 이들도 귀하의 클라우드와 독립적인 제공업체에게 보관하는 것이 좋습니다, 호스팅 사고가 나가고 있는 IP를 함께 가져가지 않도록 하기 위해서입니다.
이와 함께 프록시는 단지 하나의 층일 뿐입니다. TLS 스택, 헤더 및 클라이언트의 행동이 두드러진다면, 그들은 어떤 IP에서도 인식됩니다, Radist와 Selectel로 이동한 봇들이 인식된 것처럼 말입니다.
사이트 소유자에게 의미하는 바
Cloudflare는 반대로도 결론을 내립니다: ASN과 트래픽 양은 봇의 신뢰할 수 없는 지표입니다. '나쁜' 네트워크를 차단하는 것은 첫 번째 이동까지 작동합니다. 행동을 보는 것이 더 신뢰할 수 있습니다: 서로 다른 네트워크의 일반적인 JA4 지문, 비정상적인 요청 빈도 및 민감한 엔드포인트에 대한 WAF 규칙은 요청이 어디에서 왔는지에 관계없이 확인해야 합니다. 반대의 경우도 있습니다: Cloudflare의 40.5% 고객이 Yandex 크롤러에게 403 코드를 응답했으며, 사고 기간 동안 Yandex에서 뉴스 사이트로의 트래픽은 44% 감소했습니다 — 즉, 정당한 인덱싱이 가장 큰 피해를 입었습니다.
결론
야ндекс의 사고는 두 가지 간단한 진리를 생생하게 검증했습니다. 첫 번째: 인프라는 하루 만에 사라질 수 있으며, 몇 시간 안에 이를 이동할 수 있는 사람이 이깁니다 — 클라우드 밖에 있는 코드, 두 번째 호스팅 업체, 서버에 종속되지 않은 출력 계층을 갖추고 있어야 합니다. 두 번째: 안티봇에게 당신은 당신의 클라이언트 스택이지, 당신의 IP가 아닙니다. 동일한 JA4와 동일한 User-Agent를 가진 새로운 데이터 센터는 새로운 주소의 동일한 봇입니다. 파싱을 구축할 때, 플랫폼 변경을 견딜 수 있도록 하고, 어떤 IP에서도 동일하게 깔끔하게 보이도록 하십시오.