Yandex에서 끊긴 요청이 다른 곳에서 다시 왔다

요약

• Yandex Search에서 줄어든 트래픽은 주로 검증된 검색 크롤러였다. Yandex.Cloud에는 일반 애플리케이션과 공격성 징후를 띤 자동화가 함께 있었다.
• 한 도박업 고객 계정에서는 여러 특성이 일치하는 요청이 다른 러시아 호스팅망을 통해 나타났다. 관측된 활동의 이동을 뒷받침하지만, 운영자의 신원이나 인터넷 전체의 상황을 밝혀 주지는 않는다.

요청이 어디에서 오는지는 바뀌었다. 그런데 받는 쪽에서는 낯익은 흔적이 보였다.

Cloudflare가 10월 14일 공개한 Yandex 장애 분석에서 가장 눈에 띄는 대목이다. 한 도박업 고객 계정으로 향하던 Yandex.Cloud의 봇 요청은 8일 장애 뒤에 끊겼다. 동시에 Radist와 Selectel 등 다른 러시아 호스팅 네트워크에서 같은 특성을 가진 요청이 나타났다.

이전 출발지만 보고 있었다면 활동이 끝났다고 생각하기 쉽다. 도착지에서 보면 이야기는 달라진다. 반대로 검색 네트워크에서 사라진 요청은 상당수가 웹페이지를 검색에 반영하는 유용한 작업이었다. 봇 트래픽 감소라는 말에는 이처럼 다른 결과가 섞여 있다.

먼저, 두 네트워크를 나눠 보자

Yandex Search는 AS13238, Yandex.Cloud는 AS200350이라는 자율 시스템을 사용한다. ASN은 네트워크를 식별하는 번호다. 클라우드에서 실행되는 프로그램마다 누가 주인인지를 알려 주는 번호는 아니다.

Cloudflare에 따르면 검색망에서 관측한 요청의 99.5%는 자동화였고, 그 봇 요청 중 93.6%는 검증된 것으로 분류됐다. 표본에는 YandexBot, YandexRenderResourcesBot, YandexImages가 있었다. 페이지와 이미지를 가져오고 렌더링하는 검색 작업에 부합하는 구성이다. 장애 전 이 망에서 뉴스 사이트로 향한 트래픽의 약 90%는 기사를 색인하는 YandexBot이었다.

이 방문이 줄면 Yandex 검색을 위한 수집과 콘텐츠 발견도 줄어든다. 공격 요청이 줄어드는 것과 같은 성과로 볼 수 없다. 뉴스 사이트 입장에서는 원치 않는 탐색을 막으면서도 검색엔진에는 기사가 잘 발견되기를 바랄 수 있다.

시설 피해는 Yandex가 직접 설명했다. 9일 발표에서는 7일에서 8일로 넘어가는 밤의 드론 공격으로 사소보 시설이 크게 손상돼 멈췄고, 9일 공격으로 칼루가 시설의 일부 인프라도 작동하지 않는다고 밝혔다. 11일 갱신한 투자자 공지에는 블라디미르 시설의 운영 중단이 추가됐다. 시설에 관한 회사의 설명이지, 그 망을 쓰던 모든 작업의 운영자를 밝혀 주는 자료는 아니다.

Cloudflare가 본 11일 트래픽은 검색망에서 기준치보다 99%, 클라우드망에서 90% 낮았다. 13일에도 두 망은 평소보다 86~90% 낮은 수준이었다. 보고서에 덧붙인 14일 18:00 UTC 관측치는 정상 수준의 85%였다. 당시의 측정값이며 현재 가동 상태를 보증하지 않는다.

검증되지 않았다는 말의 한계

클라우드 쪽에서는 점수를 매긴 요청의 약 95%가 봇으로 분류됐지만, 관측된 봇 요청 가운데 검증된 것은 없었다. 그렇다고 전부 악성이라는 뜻은 아니다. Cloudflare의 검증 제도에는 정체를 드러내는 방식과 비침해적 행동에 관한 기준이 있다. 그 표식이 없다는 사실만으로 개별 프로그램의 의도를 결정할 수는 없다.

요청의 거의 3분의 2는 사이트에 데이터를 보내고 있었다. 소프트웨어와 연동 기능의 비중이 컸으며, 소프트웨어 분야 요청의 과반은 장애 전과 중간 모두 HTTP 200 응답을 받았다. 프로토콜상 성공 응답이지 무해하다는 증명은 아니다. 다만 이곳이 일반 고객의 애플리케이션도 함께 사용하는 클라우드라는 점은 놓치지 말아야 한다.

공격성 징후가 있는 활동도 실제로 줄었다. Cloudflare가 기록한 감소폭은 AS200350의 봇 트래픽 약 40%, WordPress 플러그인 탐색 90%, 스캐너로 식별된 요청 93%였다. 고객이 Yandex.Cloud 트래픽에 적용한 차단도 70% 감소했다. 서로 다른 대상을 센 수치이므로 합칠 수 없고, 이것만으로 작업 자체가 종료됐다고 할 수도 없다.

같은 고객에게 남은 여러 단서

도박업 표본에서는 Yandex.Cloud의 봇 요청이 거의 모두 한 계정의 여러 호스트명으로 몰렸다. 그 출발지가 끊긴 뒤 다른 호스팅망으로 들어온 요청은 JA4 TLS 지문뿐 아니라 드문 요청 경로와 헤더, 자체 User-Agent 문자열까지 같았다.

JA4는 클라이언트의 암호화 연결 특성을 나타낸다. 사람의 신분증은 아니다. 여러 특징이 같은 목적지에서 이어졌다는 조합이 Cloudflare의 이동 해석을 뒷받침한다. 모든 봇이 옮겨 갔다는 뜻도, Yandex가 요청을 운영했다는 증거도 아니다.

더 넓은 도박업 계정 표본에서는 러시아발 봇 요청이 사건 전 1억 6,770만 건에서 사건 중 1억 7,010만 건으로 1.4% 늘었다. 이는 앞서 본 한 계정의 수치가 아니라 여러 도박업 계정에 대한 합계다.

보고서의 날짜별 표를 보면, Cloudflare가 관측한 전 세계 HTTP 요청 중 자동화 비중은 1~6일 39.4%, 11일과 13일 각각 39.5%였다. 러시아발 HTTP 요청 안에서의 비중은 50.4%, 42.2%, 42.1%였다. 분모가 다른 요청 비율이지 봇 운영자나 사람 수가 아니다. 세계 비중은 거의 그대로인데 지역 비중은 떨어지고, 특정 고객에게는 비슷한 요청이 계속 오는 일이 함께 가능하다.

Radar 트래픽 화면은 측정 배경을 제공한다. 그렇다고 Cloudflare가 인터넷의 모든 목적지를 본 것은 아니다. 회사는 이 장애가 소셜미디어 조작을 마비시켰다는 주장을 자사 데이터가 뒷받침하지 않는다고 하면서도, 더 넓은 관련성을 판단하려면 자사 망 밖의 데이터가 필요하다고 밝혔다.

Lu Heng의 Note 65는 실제 작동하는 시스템과 인터넷 번호 거버넌스를 논한 글이다. 이번 사건의 증거는 아니며, 이름보다 운영 현실을 보자는 편집상의 관점만 참고한다. 여기서 그 관점은 단순하다. 출발지 이름이 바뀌었다고 도착지의 일이 끝난 것은 아니다. 무엇이 사라졌고 무엇이 계속 오는지 나눠 봐야 장애의 의미가 보인다.