Botları engellemek için küçük araçların hepsini devreye almak

(lambdacreate.com)

4 puan yazan GN⁺ 2025-06-02 | Henüz yorum yok. | WhatsApp'ta paylaş

Kişisel sunucudaki Gitea ve blog, scraping trafiği altında ezilince disk, CPU ve bellek uyarıları peş peşe geldi; yönetici savunma için log analizi, Nginx ve Fail2Ban birleşimini kullandı
Zabbix’e göre trafik olağanın çok üstüne çıktı; Nginx’in bir aylık ortalaması saniyede 8 istek iken en kötü aralıkta saniyede 20+ istek seviyesine ulaştı
Neden, Reddit veya Hacker News gibi tek bir kaynaktan gelen ani trafik patlaması değil; birden çok IP bloğunun www.lambdacreate.com ve krei.lambdacreate.com URL’lerini kazıdığı dağıtık scrapinge daha yakındı
Nginx, bilinen kötü amaçlı user agent’lara 403 döndürdü ve IP başına istek sınırlaması uyguladı; aşırı sayıda 403 üreten istemciler Fail2Ban ile 24 saat engellendi
Yazı yazıldığı sırada engelleme listesi toplam 735 ban seviyesine çıkmıştı; özellikle Gitea’daki herkese açık depoların tüm commit’leri için tarball üretmeye çalışan istekler sunucu yükünü artırdı

Kişisel sunucuyu zorlayan scraping trafiği

Kişisel internet alanına istenmeyen bot trafiği aniden yığılınca, gerçek okuyucuların erişmesi gereken hizmetler bile etkilendi
Archive.org gibi site koruma amacıyla indeksleyen servisler izin verilenler arasında görülürken; Amazon, Facebook, OpenAI ve çeşitli rastgele botlar, içeriği kendi amaçları için tüketen aktörler olarak ayrıldı
Büyük şirketlerin geniş ölçekli internet verisi toplaması ve yapay zeka modeli eğitimi için veri talebi, scraping baskısını daha da artırmış olarak değerlendiriliyor
Bu trafik Lambdacreate’in gerçek tüketicileri değil, insan okuyucuların erişilebilirliğini azaltan bir engel olarak ele alındı

Sorunu ilk bildiren Zabbix oldu; konteynerler için ayrılan diskin dolduğuna dair uyarı geldi
LXD tabanlı ortamda ZFS sparse file genişletilip site kısa süreliğine kapatılıp yeniden açıldı, ancak temel neden devam ediyordu
Ardından Gitea instance’ı her gün tüm diski tüketerek günde 20~30GB veri üretmeye başladı
Başta bunun Gitea’nın depo arşivi temizliğini varsayılan olarak etkinleştirmemesinden kaynaklandığı düşünülerek agresif bir temizlik işi yapılandırıldı
Kısa süre sonra CPU ve bellek uyarıları da geldi; Gitea’da git pull ve git push yapmak zorlaştı, weechat istemcisi de bağlantıyı koruyamaz hale geldi

Geçmiş metriklerle mevcut durumu karşılaştırmak için out-of-band izleme bulundurulması sayesinde anormal örüntü doğrulanabildi
Zabbix panosundaki temel metrikler Nginx istek sayısı ve ağ iş hacmi grafikleriydi
Bir aylık ölçekte ortalama Nginx istek hacmi saniyede 8 istek düzeyindeydi
En kötü dönemde saniyede 20+ istek geliyordu; büyük servisler için küçük sayılsa da kişisel sunucu için olağanın 10 katı olduğundan etkisi büyüktü
Basit istek sayısından ziyade, Gitea ile ilgili disk ve CPU kullanımındaki artışın da birlikte görülmesi sunucu işletme yükünü büyüttü

Logları inceleyebilmek için sunucuyu yeterince uzun süre ayakta tutmak amacıyla konteynerler ve Nginx kısa süreliğine kapatıldı ve analiz başlatıldı
Kullanılan araçlar lnav ve goaccess idi
lnav, log dosyalarını renklendirilmiş bir TUI içinde gösterir ve yaygın log formatlarının üzerinde bir soyutlama katmanı sağlayarak logların SQL sorgularıyla sorgulanmasına imkân tanır
access.log üzerinde şu sorulara odaklanıldı
- Toplam kaç ziyaretçi IP’si var?
- IP adreslerinde bir örüntü var mı?
- Trafik belirli bir referrer’dan mı geliyor?
- Hangi user agent’lar kullanılıyor?
- Hangi IP hangi user agent ile ilişkili?
Analiz sonucunda bunun tek bir referrer’dan gelen “hug of death” değil, birden çok IP bloğunun sitenin tüm URL’lerini kazıması olduğu görüldü

İlk müdahale, Nginx’te sorun çıkaran user agent’ları listeleyip 403 döndürmek oldu
Örnek yapılandırma, AdsBot-Google, Amazonbot, Amazonbot/0.1 gibi agent’ları işaretlemek için map $http_user_agent $badagent kullanıyordu
Varsayılan Nginx yapılandırmasına user agent kuralları include edildi ve IP başına rate limit de birlikte ayarlandı
Sanal host yapılandırmasına şu davranışlar eklendi
- limit_req zone=krei burst=20 nodelay; ile istek sınırlaması uygulama
- $badagent doğruysa return 403; ile içeriğe erişimi engelleme
Bu yöntem backend işlem yükünü azaltmaya yardımcı olur; ancak sunucunun HTTP isteğini alıp 403 işlemesi gerektiğinden, yüksek hacimli eşzamanlı isteklerde yük hâlâ devam eder

403 logları biriktikten sonra lnav ile 403 alan benzersiz IP’ler görülebilir
goaccess, geçmiş ve güncel logları birlikte analiz ederek sunucuya gelen istek sayısını ve en çok hedeflenen endpoint’leri görmek için kullanıldı
Sunucuyu fiilen korumak için Fail2Ban eklendi
Fail2Ban kuralı, Nginx access log içinde aşırı sayıda 403 yanıtı üreten IP’leri yakalayan basit bir biçimdeydi
Engelleme süresi 86400 saniye, yani 24 saat olarak ayarlandı
Yazı yazıldığı sırada fail2ban-client status nginx-forbidden sonucu şöyleydi
- Mevcut hata: 13
- Toplam hata: 57135
- Mevcut engelleme: 38
- Toplam engelleme: 735

Sonuçta okuyucular bloga ve Lambdacreate’in diğer servislerine yeniden erişebilir hale geldi
Robot trafiğini engellemek gereken durumlarda blog yazısı yazmak bile zorlaşıyor
Sorunlu trafik blog scraping’i değil, Gitea instance’ındaki her herkese açık depoda tüm commit’ler için tarball üretimini hedefliyordu
Uzun vadede engelleme listesini genişletmek veya Archive.org gibi meşru servislere istisna tanımak gibi yöntemler düşünülecek
İçeriğin arama motorlarından kaybolması istenmiyor; ancak internetin yapay zeka kaynaklı kötüleşmesine yakıt olmasına da izin verilmek istenmiyor