- Herkese açık Gitea sunucusu
git.xeserv.us, AmazonBot istekleri nedeniyle kararsız hale geldi; işletmeci AmazonBot ekibinden bu alan adını engelleme listesine eklemesini istedi
robots.txt ile tüm botlar için Disallow: / ayarlanmış olsa da istekler gelmeye devam etti; bu durum herkese açık Git sunucusu işletmeyi tamamen bırakmayı gerektirebilecek bir noktaya geldi- Yapay zeka tarayıcıları, kullanıcı ajanını değiştirerek veya konut tipi IP proxy’leri kullanarak engellemeyi zorlaştırıyor
- nginx ingress üzerinde
Amazon kullanıcı ajanına 418 dönecek şekilde engelleme yapıldı; ancak istekler farklı IP’lerden devam etti ve yaklaşık %10’unda amazonbot kullanıcı ajanı da yoktu
- Sonunda Gitea sunucusu yeniden VPN arkasına taşındı ve isteklerden önce iş ispatı denetimi yapan ters proxy
Anubis geliştirildi
AmazonBot istekleri ve robots.txt’in sınırları
- İşletmeci, AmazonBot operatörlerinden
git.xeserv.us alan adını engellenen alan adları listesine eklemelerini istedi
- Git sunucusunu taramak istiyorlarsa, aşırı kaynak kullanımını karşılayacak donanım yükseltme maliyetini ödeyebilmeleri için kendisiyle iletişime geçmelerini istedi
- Tüm botları engelleyen
robots.txt zaten ayarlanmıştı, ancak gerçek istekleri engellemek için yeterli olmadı
User-agent: *
Disallow: /
- Yapay zeka tarayıcı botlarını engellemenin neden zor olduğunu da özetledi
- Botlar yalan söylüyor
- Kullanıcı ajanını değiştiriyor
- Konut tipi IP adreslerini proxy olarak kullanıyor
- Başka yöntemler de kullanıyor
nginx ingress engellemesi ve Anubis’in yayımlanması
- 2025-01-17 17:50 UTC’de nginx ingress yapılandırmasıyla kullanıcı ajanı engellemesi eklendi
nginx.ingress.kubernetes.io/configuration-snippet: |
if ($http_user_agent ~* "(Amazon)" ){
return 418;
}
- Bu ayardan sonra da bot her seferinde farklı IP’lerden istek göndermeye devam etti ve isteklerin yaklaşık %10’unda
amazonbot kullanıcı ajanı yoktu
- 2025-01-18 19:00 UTC’de Gitea sunucusu yeniden VPN arkasına taşındı
- Ardından Gitea sunucusunun önünde, isteklere izin vermeden önce iş ispatını denetleyen bir ters proxy geliştirilmeye başlandı
- 2025-01-18 23:50 UTC’de bu proxy
Anubis adıyla https://git.xeserv.us/ üzerinden görülebilir hale geldi
- 2025-03-26 14:27 UTC itibarıyla
Anubis, dokümantasyon sitesi olan bağımsız bir projeye dönüştü
1 yorum
Hacker News yorumları
Artık avukat imzalı bir mektup gönderme zamanı. Computer Fraud and Abuse Act kovuşturma yönergelerine bakınca, ABD Adalet Bakanlığı'nın genel olarak açıkça saldırı olmayan herkese açık sunucu erişimini “yetkisiz erişim” saymadığı, ancak sonrasında yetki sahibi kişinin açık bir yazılı durdurma talebi gönderip davalının bunu alıp anladığı durumda, o noktadan itibaren yetkisiz saydığı yazıyor.
Bu yüzden bir avukata “net bir cease and desist” mektubu yazdırıp, avukatın önerdiği şekilde taahhütlü posta ya da tebligat görevlisiyle Amazon'a ulaştırmak yeterli. Muhtemelen ikisini de yapıp bir de e-posta göndermek gerekir.
Sonra Amazon'un durup durmadığına bakılır; durmazsa suç duyurusunda bulunulabilir. O zaman Amazon da ciddiye almak zorunda kalır.
https://www.justice.gov/jm/jm-9-48000-computer-fraud
Amazon botunun bilinen Amazon IP aralıklarından gelmesi ve robots.txt'ye uyması gerekir. Bir Amazon mühendisi de başka bir yorumda bunu doğrulamış: https://news.ycombinator.com/item?id=42751729
Amazon'la eşleşen tek şey “AmazonBot” kullanıcı ajanı dizesiyse, IP aralıkları ya da davranış eşleşmiyorsa Amazon'a avukat mektubu göndermek parayı yakmaya benzer.
Bu yorumdaki çözümü beğendim: https://news.ycombinator.com/item?id=42727510
Sitenin bir yerine bir insanın ziyaret etmesi mümkün olmayan bir bağlantı koyup bunu robots.txt'de yasaklamak, ardından herhangi bir IP o bağlantıyı ziyaret ederse 24 saat engellemek. OpenAI crawler'ının özellikle joker karakterleri görmezden geldiği söyleniyor; bu yüzden onu joker karakterin altına koyarak ele alıyorlar.
Ama ilgili IP sayısı o kadar fazlaydı ki trafiğe neredeyse hiç etkisi olmadı.
Gelen başlıklara çok ayrıntılı bakmanızı öneririm. varnishlog bu iş için oldukça iyi; yeterince uzun bakınca tüm isteklerin paylaştığı özellikleri bulabiliyorsunuz. Örneğin bildirilen dil ile coğrafi konumun tuhaf bir kombinasyonu ya da aynı eski tarayıcı sürümü gibi.
Daha da kötüsü, hata işleyicide bir bug vardı; bu koşul oluştuğunda sunucu süreci yeniden başlatılıyor, bu sırada “.NET 2.0 standartlarına göre oldukça iyi olan” önbellek uygulaması da geçersiz hale geliyordu.
Bu yüzden güvenlik önlemi olarak kanarya tekniği eklemeye başladığımızı hatırlıyorum. Birkaç basit kanarya, başka web sunucuları eklemekten hâlâ daha ucuzdu. Elbette önbellek sorununu da düzelttik ve o servise çok fazla kötü istek gelirse “çığlık atan” bir mekanizma da ekledik.
Ama işin komiği, o şirketlerin kendi crawler'ları kendi oluşturdukları manifestleri parse edemiyordu.
Biz de tüm AI·SEO botlarında aynı davranışı görüyoruz, bu yüzden öneririm. robots.txt'ye zar zor uyuyorlar ve engellemeleri de zor. Crawl ederken spam gibi akın edip yükü ciddi artırıyor, müşteri sunucularının çoğunu çökertiyorlar.
AI crawler'ları erişmek istiyorsa uslu durmalı ya da ödeme yapmalı. Aksi halde sonuç neredeyse evrensel bir engelleme olacak.
/apiye saniyede ortalama X'ten fazla istek atan IP'lere iptables ile-j TARPITuygulamıştım.Bulutta bunu nasıl uygularım pek bilmiyorum. Orada henüz ihtiyacım olmadı.
https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
Ya da en azından nezaketen gece ya da yoğun olmayan saatlerde kazısalar.
Bunun gerçekten Amazon olduğunu varsaymayacağım. Yazar, konut IP’leri arasında dönen ve kullanıcı aracısı dizesi de değişen istekler görüyor.
Büyük bir şirketin crawler’ı gibi davranmak, dikkat çekmek istemeyen kişilerin sık kullandığı bir yöntem. İsteklerin konut IP’lerinden geliyor olması, başka bir şeyler döndüğüne dair büyük bir uyarı işareti.
İçeride kontrol edebildiğim bilgilere göre bunun gerçekten Amazon olma ihtimali çok düşük. Amazonbot’un robots.txt’ye uyması ve her zaman Amazon’a ait IP adreslerinden gelmesi gerekir. Doğrulama süreci burada: https://developer.amazon.com/en/amazonbot
Bilmediğim garip bir iç ekibin böyle bir şey yapıp yapmadığını anlamak için konuyu içeride ilettim; ama yazarın bu trafiği kötü niyetli sayıp kullanıcı aracısını sahte gösteriyor diye ele alması daha iyi olur.
[1] https://brightdata.com/proxy-types/residential-proxies
Yakın zamanda aynı sorunu yaşadım. Forgejo instance’ım ev sunucusunun CPU’sunu %100 kullanmaya başladı; Claude ve Meta ile Google’ın yapay zeka arkadaşları fiilen sonsuz sayıdaki bağlantıya yüksek hızda istek gönderiyordu.
robots.txt ve Caddy’nin kullanıcı aracısı tabanlı engelleme listesiyle bir ölçüde azalttım, ama bunun ne kadar süre işe yarayacağını bilmiyorum.
Scraping adabı nereye gitti?
Daha büyük risk, bu şirketlerden birinin —hatta kendine “Open” diyen bir şirketin— ekonomi ya da ulusal güvenlik açısından “batmasına izin verilemeyecek” bir ölçeğe ulaşması.
Facebook, MySpace’ten arkadaş listelerini kazımayı kolaylaştırmasıyla meşhurdu; kendileri büyüdükten sonra aynı davranışı kendi sitelerinde yasakladılar.
Lütfen artık kendimize gelelim.
Bunun Amazon gibi görünen bir DDoS olmadığından emin miyiz?
İsteklerin konut IP’lerinden gelmesi gerçekten şüpheli.
Böyle bir DDoS’un motivasyonu, küçük siteleri çökertip sorumluluk Amazon’daymış gibi göstererek Amazon’u hedef almak olabilir.
Gerçekten Amazon ise başlangıç noktası, yayımladıkları tüm IP aralıklarını engellemek olur. Ancak anlattığına göre istekler o aralıkların dışından da geliyor gibi.
Bu tür hizmetler kullanıcı bant genişliği için para ödüyor ve bunu üçüncü taraflara yeniden satıyor; bu yüzden birçok bot trafiği konut IP’lerinden geliyormuş gibi görünüyor.
Benim sitem Pinboard da yapay zeka crawler’ı olduğu tahmin edilen şeyler tarafından dövülüyor. Bu yaz Çin ve Singapur IP’leriyle başladı, ama artık IP aralığı engellemesi de yapamıyorum ve CAPTCHA’ya güvenmek zorundayım.
Trafik seviyesi siteyi anında öldürecek kadar yüksek; üstelik eğitilecek ilginç metinlerim de yok, sadece bağlantılar var.
Orijinal yazının sahibi bunun nedeninin Amazon crawler’ı olduğunu nasıl anladı merak ediyorum. Ben de suçu atacak birilerini bulmak istiyorum.
Böyle şeylerle savaşmanın en iyi yolu engellemek olmayabilir. Engellemek Amazon’a ya da başka şirketlere hiçbir zarar vermez.
Bunun yerine botlara açıkça zararlı ya da bozucu içerik yedirebilsek nasıl olur?
Daha büyük ölçekte yapılır ve Amazon zehirli veriyi fark ederse, bunu hızlıca temizlemek için para harcamak ve botların bu tür verileri yemesini engellemek zorunda kalırlar.
Elbette en büyük sorun, kimsenin böyle bir şeyi kendi sitesinde tutmak istememesi.
Bu scraper’lar zaten CSAM ve ona denk korkunç şeyleri de hiç çekinmeden yiyor. OpenAI’ın Kenya’daki veri etiketleme taşeronlarından bazıları bu yüzden işi bıraktı. 2023 tarihli Time haberi.
Şu anda yapay zeka şirketleri veri kalitesiyle ilgilenmiyor, sadece miktara bakıyor. Onlara zarar vermenin tek yolu 0 bayt vermek.
Sam Altman’ın onayladığı şeylerin onda birini bile yapsa sıradan bir insan doğrudan hapse girerdi.
https://zadzmo.org/code/nepenthes/
Amazon ve diğer botların yarattığı fazla çıkış trafiğini telafi etmek için iyi niyet göstergesi olarak biraz AWS kredisi verseler güzel olurdu. Yine de bu yazının reklam geliriyle muhtemelen kapanır. Reklam engelleyiciyi kapatırsanız hesap denk gelir.
Nginx ile engellemeden önce Bytespider %59, Amazonbot ise %21 paya sahipti; ikisi birlikte Git sunucumuzun toplam trafiğinin %80’ini oluşturuyordu
ClaudeBot, bir ay içinde Redmine’a, ClaudeBot’tan önceki 5 yılın toplamından daha fazla trafik gönderdi