4 puan yazan GN⁺ 2025-06-02 | 1 yorum | WhatsApp'ta paylaş
  • Büyük AI/arama şirketlerinin ayrım gözetmeyen crawling ve scraping faaliyetleri nedeniyle kişisel sunucular ve servisler ciddi şekilde etkileniyor; kaynak tüketimi ve servis kararsızlığı sürekli yaşanıyor
  • Zabbix·Loki tabanlı izleme ile anormal trafiği tespit ettikten sonra, log analiz araçları (lnav, goaccess) ve SQL tabanlı sorgularla saldırgan desenleri, IP'ler ve User Agent'lar ayrıntılı biçimde belirlendi
  • Nginx ayarlarında User Agent tabanlı 403 engeli, rate limit ve Fail2Ban entegrasyonu gibi katmanlı savunma sistemi kurularak yüzlerce kötü amaçlı IP engellendi ve sunucu istikrarı sağlandı
  • Asıl sorun, botların Gitea deposunun tamamını tarball olarak toplu indirmeye çalışmasıydı; yalnızca içerik tüketen botlardan değil, "AI veri toplama/model eğitimi amacı" taşıyan trafikten hızlı bir artış görüldü
  • Uzun vadede archive.org gibi meşru servisler için istisna tanımları yapmayı, arama motoru görünürlüğünü korurken AI kaynaklı enshittification'a karşı koymayı planlıyor

Giriş: Küçük sunucuma yağan bot trafiği

  • Son dönemde kişisel olarak işlettiği lambdacreate blogu ve çeşitli servislerde kimliği belirsiz yoğun trafik hızla arttı
  • Archive.org gibi meşru servisler memnuniyetle karşılanıyor, ancak Amazon, Facebook, OpenAI gibi büyük şirketlerin kontrolsüz veri taraması siteye zarar veriyor
  • AI model eğitimi gibi nedenlerle veri toplama talebi arttıkça bu durum daha da ciddileşiyor
  • Bu yüzden gerçek okurların (insanların) yerine, esas olarak büyük hacimli bot trafiğiyle uğraşmak zorunda kalıyor

Sorunun tespiti: İzleme araçlarıyla trafik patlamasını teşhis etmek

  • Sunucu kaynak tüketimini analiz etmek için Zabbix, Loki gibi izleme araçları kullanıldı
  • Gitea instance'ında günde 20~30GB düzeyinde veri artışı görüldü ve çeşitli CPU/bellek uyarıları oluştu
  • nginx trafik analizi sonucunda aylık ortalama 8req/s olan değer anlık olarak 20req/s üzerini gördü
  • Trafik mutlak olarak çok büyük olmasa da, normalin neredeyse 10 katına çıkarak kaynak tükenmesine yol açtı

Saldırının nedenini analiz etmek: Log dosyalarını derinlemesine inceleme

  • nginx access log'ları lnav ve goaccess ile SQL üzerinden analiz edildi
    • Ziyaretçi IP'leri, User Agent, Referrer gibi desenler incelendi
  • Sonuç olarak, belirli bir servis ya da topluluktan gelen trafik değil, belirli IP aralıklarından yoğun crawling olduğu anlaşıldı
  • User Agent içinde Amazonbot, OpenAI, Applebot, Facebook gibi açıkça belirtilen ya da taklit edilmiş çok sayıda değer bulundu
  • Bunun gerçek servis kullanımını aksatması nedeniyle daha güçlü engelleme politikalarına ihtiyaç doğdu

Çözüm: Nginx, Fail2Ban ve diğer savunma katmanlarını birlikte uygulamak

  • Nginx map kullanılarak kötü amaçlı User Agent'lara anında 403 döndürüldü, ayrıca rate limit (ziyaret hızı sınırı) devreye alındı
  • Yeni ya da henüz tespit edilmemiş botların bile web istek sıklığı düşürülerek sunucu yükü en aza indirildi
  • 403 oluşan log'lara dayanarak goaccess ve lnav ile yeni kötü amaçlı IP'ler ve User Agent'lar tespit edildi
  • Otomatik güvenlik aracı Fail2Ban ile aşırı sayıda 403 yanıtı üreten IP'ler 24 saatliğine otomatik engellendi
    • 735'ten fazla otomatik ban kaydı oluştu
  • Gerçek kaynak kullanım oranları önemli ölçüde normale döndü
  • Bundan sonra archive.org gibi normal servisler için istisna kuralları uygulanacak; arama motoru indekslemesine izin verilirken AI eğitimi için yapılan kontrolsüz crawling ise engellenmeye devam edecek

Sonuç: Araç kombinasyonunun gücü ve kişisel servis güvenliğinin gerekliliği

  • Bu tür çok katmanlı savunma önlemleri uygulanarak kişisel blogun sorunsuz işletimi ve servis erişilebilirliği yeniden sağlandı
  • Çok sayıda küçük sistem yönetimi ve otomasyon aracının kişisel sunucu güvenliğinde etkili olduğu doğrulandı
  • Büyüyen AI eğitim talebi nedeniyle kişisel sunucuların bile gelişigüzel tarandığı bir ortamda, aktif engelleme ve yönetim otomasyonu artık zorunlu hale geliyor

1 yorum

 
GN⁺ 2025-06-02
Hacker News yorumu
  • Birçok kötü niyetli crawler’ın sadece büyük arama motorlarını taklit ettiğini sık sık görüyorum; user-agent bilgisine kanmamak gerektiğini söyleyenler de var ama benim en sevdiğim yöntemlerden biri robots.txt içine şüpheli bilgiler (ör. gzip bomb) koyup bunu algılayan crawler’ı bir sonraki istekten itibaren engelleyecek şekilde ayarlamak. Caddy ile bunu basitçe yapmak mümkün ve bu yöntem çoğunlukla en ağır ihlalcileri yakalıyor. Botların davranışını savunmak istemem ama birkaç bot sitenizi çökertiyorsa bu, kötü niyetli bir saldırgana karşı gerçekten savunmasız bir site olduğunun kanıtıdır.

    • Son yorumun meseleyi gerçekten tam yerinden vurduğunu düşünüyorum. Ben farklı bir kuşaktan olabilirim ama bugünlerde yazı yazan insanların neden bu kadar az kaynak kullanımına takıntılı olduğunu anlamıyorum. Sanki büyükanne büyükbabanın LED ışıkları kapatma konusunda aşırı telaş yapması ya da yakıttan 5 sent tasarruf etmek için 24 km araba kullanması gibi. Saniyede 20 istek gerçekten hiçbir şey değil; üstelik içerik dinamik üretilse bile (neden öyle olsun ki? O sürede cache ayarlamak çok daha kârlı). Son zamanlarda 'fuck the bots' tarzı yazılar moda ama bu yeni bir konu değil. Zaman kaybetmeden başa çıkmanın çok daha üretken yolları var.

    • robots.txt ile gzip bomb kurma yöntemini daha ayrıntılı duymak isterim. Çoğu yapay zekanın robots.txt’yi görmezden geldiğini sanıyordum; sonuçta yalnızca bazı saf crawler’lar mı yakalanıyor diye merak ediyorum. Kimseye karşı çıkmak için sormuyorum, sadece iyi tarafa zarar vermeden bunu nasıl uygulayabileceğimi daha iyi anlamak istiyorum.

    • Kendi alanımdaki en büyük wiki’lerden birini işletiyorum ve geliştirme ekibindeki diğer insanları gzip bomb kullanmaya ikna etmek neredeyse imkânsız. Bu yöntemin risklerinin çok büyük olduğunu (zihniyetleri daha çok AB düzenlemeleri yüzünden) ve peşine düşmeye değmeyeceğini savunuyorlar. Gerçek, herkese açık sitelerde bunu gerçekten kullanan var mı merak ediyorum.

  • Bugünlerde botların robots.txt dosyasına hiç saygı göstermemesi beni gerçekten sinirlendiriyor. Bunu yapanların gerçekten bencil insanlar olduğunu düşünüyorum; böyle botları yapanlarsa artık ne halleri varsa görsünler.

    • robots dosyasına tuzaklar (honeypot) yerleştirirseniz, tamamen yok sayanları yakalamasanız bile özellikle sorun çıkarmak için gelen botları ayıklamada yardımcı olabilir.

    • Chatbot, arama motoru veya fiyat karşılaştırma aracı kullanan insanlara da benzer şeyler söylenebilir. Aslında scraper’ları ekonomik olarak teşvik edenlerin başında bu kullanıcılar geliyor.

  • Yazarın “artık umursamıyorum” demesini anlıyorum ama yasaklı IP’ler arasında Google, ripe.net ve semrush gördüm. Diğer şirketleri bilmem ama Google’ı gerçekten engellemezdim. Sitenizin duyulmasını istiyorsanız Semrush ya da ripe.net’i de engellemenize gerek olmadığını düşünüyorum. İçeriğim AI ya da tuhaf tipler tarafından scrape edilse bile, site en baştan herkese açıksa bir ölçüde kullanılacağını peşinen kabul etmek gerekir. Bir bakıma motel tabelasının ışığını kapatıp yine de müşteri davet etmek gibi.

    • Semrush uzun süre boyunca çeşitli seviyelerde gerçekten çok ciddi şekilde rahatsızlık verdi; son 8 yıldır robots.txt içinde alışılmadık bir uyarı notu bile bırakıyordum. Sonunda ancak hukuk ekibi devreye girince durulabildi. Benim açımdan, gerçek ziyaretçileri dışarı iterek siteyi kaba şekilde kazıyan bir 'SEO' şirketine izin vermenin hiçbir değeri yok. Semrush’ın rakipleri de benzer şekilde berbattı. Bugünkü AI scraper’lar da o kadar düşük seviyede ki, büyük yatırımcılara ve PR departmanlarına defalarca resmî şikâyet göndermek zorunda kaldığım oldu. Teknik ve hukuki çeşitli yöntemlerle ancak normale döndürebildik.

    • Asıl sorun, botların büyük miktarda trafik (bant genişliği, bellek, CPU, disk kaynakları) tüketmesi. Tanıtım yazısında da bunun kabul edilemez bir görgüsüzlük olduğu söyleniyor. Böyle bir trafiği scraper’lara sunmak zorunda değilmişiz gibi geliyor. Google da AI scraper çalıştırdığı için muhtemelen engel listesine bu yüzden girmiş olabilir.

    • Google taklidi yapan gerçekten kötü niyetli botlar da var. Eskiden Google nispeten daha kibar scraping yapardı ama yazar engellesin ya da engellemesin, ihtiyaç duyduğu trafiği zaten alıyorsa pek umursaması için bir sebep kalmaz.

    • İnsanların son 10 yıldır Google kullanmamaları gerektiğini hâlâ fark etmemiş olmasına şaşırıyorum; özellikle de Google’ın AI ile bağımsız siteleri sansürlediği durumlar ortaya çıkarken, ilgili yoruma da doğrudan bağlantı verilmiş. Artık Google bir varlıktan çok bir yükümlülüğe daha yakın görünüyor.

  • Botlar yüzünden sunucu log dosyaları aşırı büyüdü; benim sunucularımda artık loglamayı tamamen kapatmış durumdayım. Botlar API’leri, formları, hatta web sitesinde yalnızca tıklamayla erişilebilen bölümleri bile inatla scrape ediyor. Anthropic, openAI, Facebook ve diğerleri hâlâ sitemi scrape etmeyi sürdürüyor.

    • Yalnızca tıklamayla erişilebilen API’ler söz konusuysa, botlar bunlara nasıl ulaşıyor merak ediyorum.

    • Bu API bilgisi hakkında daha fazla ayrıntı duymak isterim. Arayüzün bir parçasını veya sadece insanların kullanabildiği bölümleri mi kastediyorsunuz, yoksa başka hiçbir yolun olmadığı bir şeyi mi? Son dönemde AI agent’ları gerçek kullanıcı davranış örüntülerini taklit ettiği için insanla botu ayırmak neredeyse imkânsız hale geldi.

  • AI crawler botlarının User-Agent başlığını dürüstçe doldurmasını olumlu görüyordum ama bu kadar yoğun trafiğin sebebinin bu olması beni biraz şaşırttı. Çoğu web sitesinin bu kadar sık veriye ihtiyacı yok ama trafik yine de çok yüksek. Bir geliştirici bloguysa bunu anlamak daha da zor.

    • AI crawler’ların çoğu robots.txt’ye uyuyor ama engellendiklerinde veya bloklandıklarında hemen tarayıcı user-agent’ına geçip konut tipi IP’lerden yeniden crawl etmeye çalışan örnekler de oldu. Yine de sahte şekilde OpenAI/Amazon/Facebook kimliğine bürünen çok fazla örnek olduğu için vakaları doğru ayırırken dikkatli olmak gerekiyor.
  • Ben tirreno’nun geliştiricisiyim. Platformumuz canlı oturum açmış kullanıcılara odaklı optimize edilmiş olsa da bot tespiti ve engelleme için de etkili şekilde kullanılabiliyor. IP’nin son oktetini yıldızla (*) değiştirip aynı subnet’i tek bir hesapta toplayarak IP’yi anonimleştiren bir yöntem kullanıyoruz. Trafik anormallikleri (500/404 hataları, brute-force giriş denemeleri, datacenter IP’leri vb.) için otomatik kara liste oluşturulabiliyor. tirreno’nun blacklist API’si ile istenmeyen trafik hata sayfasına yönlendirilebiliyor. Yanlış pozitifleri önlemeye ve yönetime yardımcı olan bir izleme paneli de var.
    tirreno Github, yönetici demosu

    • Günümüzde birçok ISP CGNAT yapısına geçtiğinden, tek bir IP’nin yüzlerce gerçek kullanıcıyı temsil edebilmesi sorununu nasıl ele aldığınızı merak ediyorum.

    • Açık IP aralıkları temelli benzer bir bot engelleme sistemi ben de geliştiriyorum; iyileştirme fikriniz varsa her zaman memnuniyetle karşılarım.

    • IP’nin son oktetini değiştirme yöntemi yüzünden, gerçekte benimle hiçbir ilgisi olmayan adres komşularıyla tek kullanıcı gibi gruplanıyorum. Datacenter IP’lerinden kaynaklanan yanlış pozitifleri de küçümsememek gerekir. Gerçekte bir şey engellenmemişse bile bazen 87 trafik ışığını tıklayıp ancak geçebiliyorsunuz. Sonuçta bu, yanlış pozitiflerden kaçınma aşamasında bile kişisel verilerimi rızasız toplamıyoruz diyebilmek için yapılmış gibi duruyor. Müşterinin gerçekten ücretli kullanıcıları kaçırdığını hemen fark etmesini sağlayacak bir geri bildirim yapınız mutlaka olsun.

  • Uzun zamandır aklıma takılan bir şey var: “page knocking”, yani belirli bir sayfa sırasını açınca erişim izni kazanılan bir yapı mümkün olmaz mı? Mesela belirlenmiş gizli bir URL’ye önce erişilmeden diğer sayfaların 404 yerine normal sayfa olarak açılmaması gibi.

    • Böyle bir mimari, sıradan kullanıcıların projeyi arama motorundan bulup hesap oluşturmadan veya ayrı bir kimlik doğrulaması yapmadan doğrudan kullanmaya başlayabilmesi gereken durumlarla uyumlu değil.

    • Kullanılabilirlik açısından, ne kadar iyi tasarlanırsa tasarlansın rahatsızlık yaratması kaçınılmaz. Yer imi kullanırken ya da bir arkadaşınıza bağlantı gönderirken sürekli 404 görmek zorunda kalabilirsiniz.

  • Küçük sunucum gayet sorunsuz çalıştığı için son zamanlarda fail2ban durumuna bakmamıştım.
    Komut çıktısı karşılaştırması:

    sshd-ddos:      0
    postfix:       583
    dovecot:     9690
    postfix-sasl: 4227
    nginx-botsearch: 1421
    nginx-http-auth: 0
    postfix-botnet:  5425
    sshd:         202157
    

220.000’den fazla IP’nin engellendiğini görünce biraz şaşırdım.

  • İzlediğimiz 'DotBot/1.2' adlı bot son 2 haftada 220 binden fazla istek bıraktı. Web sunucusundaki dosya ve klasör adlarını rastgele isteyen bir örüntü sergiliyor. Meraktan, ne kadar ileri gideceğini görmek için özellikle engellemeden izliyorum.

  • AI ya da arama motorları için merkezi indeksleme yapısının artık push veya gönderim tabanlı bir sisteme dönüşmesi gerekip gerekmediğini düşünüyorum. Sadece ben istediğimde doğrudan paylaştığım (push ettiğim) bir yapı olsaydı scraping sorunu büyük ölçüde azalırdı diye düşünüyorum.

  • 90’larda çocukken ISP’den bir telefon gelmiş ve bilgisayarımın bir botnet’e bulaştığı için internet bağlantımın kesileceği söylenmişti. Belki de o günlere geri dönüp buna izin veren ISP’lerin tüm ASN’lerini engellemek bu sorunu da bitirebilir.

    • Konut tipi proxy’ler ISP’ler tarafından doğrudan sağlanmıyor; dünyanın dört bir yanında kullanıcılar bilerek ya da fark etmeden kötü amaçlı yazılım kurup kendi bilgisayarlarını proxy olarak kullandırdığı için ortaya çıkıyor. Kısa süre önce HN’de bununla ilgili iyi bir yazı vardı.

    • Ağımda belirli bir cihaz kötü amaçlı yazılımla ilişkilendirilen portlara outbound bağlantı kurmaya çalıştığında uyarı veren firewall kuralları ayarladım. Port listesi, malware hedefleri sürekli değiştiği için düzenli güncelleme gerektiriyor. Küçük bir yöntem ama bu da bir başka savunma katmanı.