8 ile 11 Ekim 2026 tarihleri arasında Yandex, üç veri merkezini kaybetti: Sasovo ve Vladimir tamamen durdu, Kaluga ise kısmi bir bozulma ile çalıştı. Yandex Cloud acil duruma geçti ve doğrudan müşterilerine kendi acil kurtarma planlarını devreye almalarını önerdi. En ilginç olanı ise sonrasında gerçekleşti. Cloudflare, bu bulutta yaşayan botların başına ne geldiğini inceledi ve gördü ki, botlar kaybolmadı, aksine bir günde başka barındırıcılara taşındılar. Ve aynı TLS parmak izi JA4 ile tanınmaya devam ettiler. Parsing ve otomasyon ile ilgilenen herkes için bu, iki konuda nadir bir deney: altyapı çöktüğünde ne yapılmalı ve neden IP ve barındırıcı değişikliği botun "kimliğini" değiştirmiyor.
Yandex ile ne oldu
BleepingComputer'a göre, Yandex, üç veri merkezinin insansız hava araçlarıyla yapılan saldırılar sonucu zarar gördüğünü bildirdi. Yandex, suçluyu belirtmedi; BBC'ye atıfta bulunan medya, saldırıları Ukrayna ile ilişkilendiriyor. Kronoloji şöyle:
- 8 Ekim — Sasovo (Ryazan bölgesi): yangın, alan tamamen durduruldu;
- 9 Ekim — Kaluga: kısmi bozulma ile çalışma, tam durdurma değil;
- 11 Ekim — Vladimir: tamamen durduruldu.
Yandex Cloud durum sayfasında bazı hizmetler (konsol, API, IAM, veritabanları, S3, Kubernetes) performans sorunlarıyla birlikte erişilebilir durumda kalmaya devam etti, Compute ve AI Studio kısmen çalıştı. Şirket, güvenilir kurtarma sürelerini belirtmenin mümkün olmadığını, kalan kaynak yapılandırmasının istikrarsız olduğunu ve müşterilere alternatif acil kurtarma planları kullanmalarını önerdi. BleepingComputer'ın yayınlandığı tarihte (12 Ekim) kurtarma süreleri ve olası veri kaybı hakkında netlik yoktu.
Cloudflare'ın gördüğü: trafik düştü, botlar düşmedi
14 Ekim'de Cloudflare, kendi ağı açısından kazanın analizini yayınladı. Anahtar rakamlar:
- 11 Ekim'de Yandex Arama ağından (AS13238) gelen trafik, normalin %99'unu, Yandex.Cloud'dan (AS200350) gelen trafik ise %90'ını kaybetti;
- AS13238'den gelen taleplerin %99,5'i otomatikti ve bunların %93,6'sı Yandex'in doğrulanmış tarayıcılarıydı. Bu ağ, Rus IP'lerinden gelen tüm bot taleplerinin yaklaşık %7'sini sağlıyordu;
- Yandex.Cloud'da değerlendirilen taleplerin yaklaşık %95'i botlardı ve bunların hiçbiri doğrulanmamıştı. Bu, Rus bot trafiğinin yaklaşık %2'sidir;
- Yandex.Cloud'dan gelen bot trafiği yaklaşık %40 oranında düştü, bu ağdan gelen WordPress eklentilerini tarama ise %90 oranında azaldı.
Ve ardından en önemlisi. Yandex.Cloud'dan gelen neredeyse tüm bot talepleri, Cloudflare'ın bir kumar hesabına yönlendirilmişti. 8 Ekim'deki arızadan hemen sonra Yandex.Cloud'dan gelen talepler sıfıra düştü — ve hemen ardından diğer Rus barındırıcıların ağlarından benzer talepler ortaya çıktı, Radist ve Selectel. Aynı JA4 TLS parmak izi, aynı nadir yollar ve başlıklar ile aynı standart dışı User-Agent dizeleriyle. Bir haftalık sonuç: Rus bot trafiği kumar hesaplarına düşmedi, aksine arttı — 167,7 milyon talepten 170,1 milyona (+%1,4) yükseldi.
Cloudflare'ın sonucu sert bir şekilde ifade edildi: fiziksel altyapı statiktir, ancak kötü niyetli otomasyon taşınacak şekilde inşa edilmiştir. HTTP trafiğindeki düşüş bir kazayı gösterir, ancak botların durduğu anlamına gelmez.
Gürültülü versiyon ve veriler: "botların sustuğu" ifadesi abartıydı
Aynı zamanda, Ukrayna'nın Bilgi Sahtekarlığıyla Mücadele Merkezi (ЦПД), Sasovo'ya yapılan saldırıdan sonra Facebook ve Telegram'daki şüpheli hesapların bildirim sayısının bir günde %83,6 oranında düştüğünü — 4.032'den 660'a — bildirdi. Ancak, TechRadar'ın incelediği gibi, 10 Ekim'de aktivite 4.585 bildirime geri döndü ve 11 Ekim'de saldırı öncesi seviyeyi aştı. Cloudflare, belirgin bir kayma bulamadı: Rus IP'lerinden gelen bot trafiği, bir sosyal medya platformundaki "gönderi, yanıt, beğeni" uç noktalarına yalnızca %5,7 oranında düştü. Graphika da takip edilen topluluklarda aktif hesap kaybı görmedi. Araştırmacı Rene DiResta, Lawfare'da hikayenin güzel olduğunu, ancak gerçeğe daha çok benzemediğini belirtti.
Analistler için ayrı bir ders: 8 Ekim'de Rusya genelinde bankalar, perakendeciler, operatörler ve medya sistemleri çöktü, bu nedenle o gün "aktivitedeki" herhangi bir düşüşü botlara atfetmek için dikkatli olunmalıdır. Toplam trafik yanıltıcı olabilir.
Birinci ders: IP ve barındırıcı — botun kimliği değil
Cloudflare, "Yandex.Cloud → Radist/Selectel" bağlantısını adreslerden tanımadı — adresler ve ASN tamamen değişti. Davranış ve istemci parmak izi ile tanıdı:
- JA4 — TLS ClientHello hash'i: şifreleme, uzantılar, protokol sürümleri seti. Bu, programı tanımlar, ağı değil. Aynı Python betiği yeni bir sunucuda aynı JA4'ü verir;
- nadir yollar ve başlıklar — sıradan tarayıcılarda bulunmayan HTTP başlıklarının sırası ve seti;
- özel User-Agent — kendisi bir etiket olarak hizmet eden benzersiz bir dize.
Yasal parsing için pratik bir sonuç: veri merkezi veya IP havuzunun değiştirilmesi, tüm istemci yığını aynı kalıyorsa sizi "yeni" yapmaz. Ve tersine: eğer tarayıcınız dürüst bir şekilde kendini tanıtıyorsa, dikkatli davranıyorsa ve hassas uç noktalara saldırmıyorsa, istikrarlı bir parmak izi sorun değildir. Sorun, yığın gerçek kullanıcılar tarafından bulunmayan bir şey gibi görünüyorsa ortaya çıkar: TLS parmak izi kütüphanesi ile belirtilen Chrome, egzotik UA, standart dışı başlıklar. Bu algılama katmanının nasıl çalıştığı hakkında daha fazla bilgi için JA4 ve TLS parmak izinin scraping üzerindeki etkisi başlıklı incelememize göz atabilirsiniz.
Bir başka detayı daha unutmayın: botlar bir veri merkezinden diğerlerine taşındı. Cloudflare için bu, birçok web sitesi için önceden artan güvensizlik ile aynı barındırıcı ASN kategorisidir. Ağ farklı — risk profili aynı.
İkinci ders: altyapıyı saatler içinde taşımayı bilmek gerekir
Kötü niyetli kişiler bir günde taşındılar çünkü otomasyonları başlangıçta taşınabilir. Fiyat toplayan, sonuçları izleyen veya analiz yapan dürüst ekiplerin de bu taşınabilirliğe ihtiyacı var. Yandex Cloud'un "alternatif acil kurtarma planları kullanın" önerisi, böyle bir plan zaten mevcut olduğunda iyidir. Minimum kontrol listesi:
- Kod ve yapılandırmalar — bulut dışında. Depo, konteyner görüntüleri, ortam değişkenleri, parser'ı başka bir barındırıcıda tek bir komutla dağıtacak şekilde yer almalıdır.
- İkinci barındırıcı önceden. Alternatif sağlayıcıda başka bir yargı ve bölgede hesap, ödeme ve test sunucusu. Kazanın olduğu günde kaydolmak ve doğrulama yapmak geç kalmaktır.
- Çıkış katmanı hesaplamalardan ayrı. Hedef web sitelerine yapılan talepler, sunucunun IP'sinden değil, bir proxy sağlayıcısı aracılığıyla gidiyorsa, hesaplamaların taşınması coğrafyayı, IP türünü veya oturum geçmişini değiştirmez. Sunucu taşınabilir, ancak web sitesi için aynı müşteri olursunuz.
- Veriler ve kuyruklar — replikasyon ile. Parsing sonuçları ve görev durumları başka bir depolama alanına kopyalanmalıdır, aksi takdirde kaza sonrası yeniden başlamak zorunda kalırsınız.
- Yedek sağlayıcı — gerçekten farklı. Yedek barındırıcı veya proxy sağlayıcısı, başka bir markanın altında aynı altyapı olmamalıdır. Proxy'lerde bunu nasıl kontrol edeceğimizi, yedek proxy sağlayıcısının aynı havuz olabileceği konulu materyalimizde inceledik.
- Deneme alarmı. Her çeyrekte yedek alanda parser'ı başlatın ve gerçek bir görevi çalıştırın. Hiç başlatılmamış bir plan, pratikte genellikle işe yaramaz.
Bu durumda hangi tür proxy neyi çözüyor
Proxy'ler kötü bir parmak izinden korumaz — bu, Cloudflare'ın analizinden görülebilir. Ancak, kodun fiziksel olarak nerede çalıştığınızdaki "yüzü" taleplerinizden ayırırlar:
- Konut proxy'leri — barındırıcı ASN'lerin önceden kesildiği veya CAPTCHA aldığı siteler için. Sunucu taşındığında çıkış, gerekli ülkenin ev IP'lerinde kalır.
- Veri merkezi proxy'leri — API ve hızlı ve uygun fiyatlı siteler için. Bunları da bulutunuzdan bağımsız bir sağlayıcıda tutmak önemlidir, böylece barındırma kazası çıkış IP'lerini de almaz.
Bu arada, proxy'ler yalnızca bir katmandır. Eğer TLS yığını, başlıklar ve istemci davranışınız öne çıkıyorsa, bunlar herhangi bir IP'de tanınır, Radist ve Selectel'e taşınan botlar gibi.
Bu, web sitesi sahipleri için ne anlama geliyor
Cloudflare, ters bir sonuç çıkarıyor: ASN ve trafik hacmi — botun güvenilir bir göstergesi değildir. "Kötü" ağın engellenmesi, ilk taşınmadan sonra işe yaramaz. Davranışa bakmak daha güvenilir: farklı ağlarda ortak JA4 parmak izleri, anormal talep sıklığı ve hassas uç noktalardaki WAF kuralları, talebin nereden geldiğine bakılmaksızın. Madalyonun diğer yüzü de var: Cloudflare'ın %40,5'i Yandex tarayıcısına 403 kodu ile yanıt verdi ve Yandex ağlarından haber sitelerine gelen trafik, kaza sırasında %44 oranında düştü — yani öncelikle meşru indeksleme etkilendi.
Sonuç
Yandex'in kazası, iki basit gerçeği canlı bir şekilde test etti. Birincisi: altyapı bir günde kaybolabilir ve saatler içinde taşımayı bilen kazanır — kod bulut dışında, ikinci barındırıcı ve sunucuya bağlı olmayan bir çıkış katmanıyla. İkincisi: anti-bot için siz, istemci yığınınızın kendisisiniz, IP'niz değil. Aynı JA4 ve aynı User-Agent ile yeni bir veri merkezi, yeni bir adresteki aynı bottur. Parsing'inizi, platform değişikliğini aşacak şekilde inşa edin ve her IP'de aynı dikkatle görünün.