Tor, onion servisleri için proof-of-work savunmasını devreye aldı

 (blog.torproject.org)
2 puan yazan GN⁺ 2023-08-26 | 1 yorum | WhatsApp'ta paylaş
  • Tor 0.4.8, onion servisleri DoS saldırısı aldığında doğrulanmış ağ trafiğine öncelik veren bir savunma getiriyor
  • IP adreslerini gizleyen onion servis yapısında IP tabanlı hız sınırlama eksik kaldığı için, gizliliği bozmayan istemci bulmacası yaklaşımına ihtiyaç vardı
  • Servis baskı altına girdiğinde istemci, giderek zorlaşan bulmaca hesaplamalarıyla yaptığı işi kanıtlıyor ve bağlantı önceliği buna göre değişiyor
  • Normal kullanıcılar için ilk çözüm süresi hızlı bilgisayarlarda yaklaşık 5 ms, yavaş donanımlarda en fazla 30 ms düzeyinde olduğundan çoğu cihaz bunu kaldırabiliyor
  • Saldırı trafiği arttıkça istenen iş miktarı yaklaşık 1 dakikaya kadar çıkabiliyor; bu da toplu bağlantı denemelerini pahalı hale getirirken normal kullanıcılara yoğunluk sırasında da erişim şansı veriyor

Tor 0.4.8'in onion servisleri için PoW savunması

  • Tor, Tor 0.4.8 sürümüyle birlikte onion servisleri için proof-of-work (PoW) savunmasını resmen kullanıma sundu
  • Amaç, DoS saldırılarını caydırırken doğrulanmış trafiğe öncelik vermek
  • Onion servisi işletenlerin 0.4.8 sürümüne güncellemesi öneriliyor
  • Onion servisleri kullanıcı gizliliği için IP adreslerini sakladığından, DoS saldırılarına karşı savunmasız kalabiliyor ve geleneksel IP tabanlı hız sınırlama tek başına yeterli koruma sağlayamıyor

İstemci bulmacaları ve öncelikli işleme

  • PoW, temelde varsayılan olarak kapalı olan bir bilet sistemi gibi çalışıyor; ağ baskısı oluştuğunda ise öncelikli bir kuyruk oluşturuyor
  • İstemcinin onion servisine erişmeden önce küçük bir bulmacayı çözerek belirli bir iş yükünü yerine getirdiğini kanıtlaması gerekiyor
    • Bulmaca ne kadar zorsa, o kadar fazla iş yapıldığı anlamına geliyor
    • Onion servisi, istemcinin gösterdiği çaba düzeyine göre bağlantı önceliğini belirliyor
  • Saldırgan bir onion servisini çok sayıda istekle doldurduğunda, .onion siteye erişmek için gereken hesaplama çabası artıyor
    • Toplu bağlantı denemeleri daha fazla hesaplama kaynağı gerektiriyor
    • İş yükü arttıkça saldırganın kârlılığı düşüyor

Normal kullanıcıya görünen etki

  • Normal kullanıcılar genelde aynı anda az sayıda istek gönderdiği için bulmaca çözme yükü çoğu cihazda yönetilebilir düzeyde kalıyor
    • İlk çözüm süresi hızlı bilgisayarlarda yaklaşık 5 ms
    • Yavaş donanımlarda en fazla 30 ms
    • Saldırı trafiği arttığında iş yükü yaklaşık 1 dakikaya kadar çıkabiliyor
  • Bu süreç kullanıcıya görünmüyor ve PoW çözümünü bekleme deneyimi, yavaş bir ağ bağlantısını beklemeye benziyor
  • Büyük siteler bu yaklaşımı benimsediğinde, hedefli saldırıların ağ hızına olumsuz etkisini azaltmak, ani trafik artışlarında yük dengelemeye yardımcı olmak ve onion servislerine erişimi daha tutarlı ve güvenilir hale getirmek mümkün olabilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-26
Hacker News yorumları

  • İlginç. Teklife bakınca beklentiler net: büyük botnetleri durdurmayı değil, script kiddie'lere ve küçük ölçekli botnetlere karşı savunmayı hedefliyor
    DoS saldırısı sırasında gerçekten bağlanmak isteyen kullanıcılar geçebilir, ancak bunun için biraz çaba gerekebilir
    İş ispatı algoritması olarak https://github.com/tevador/equix seçilmiş olması da ilginç
    Bitcoin'deki gibi statik bir hedef değerin altına inince başarılı olunan bir yöntem değil; istemci iş ispatı çabasıyla “teklif veriyor” ve daha fazla çaba harcadıkça önceliği yükseliyor. Coin stake etmek yerine iş stake etmeye benzemesi açısından hisse ispatına benzediği açıklanıyor
    [1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...

    • CPP, yani istemci bulmaca protokolünü ilk kez duyuyorum. Büyük botnetlerin başka portlarda taşkınlık çıkararak bunu aşıp aşamayacağını merak ediyorum
    • İş ispatı savunmasının yalnızca kullanıcı tarafındaki kaynakları yakmak yerine, kullanıcıdan sağlayıcıya bir tür değer aktarımı içermesini isterdim
      Bu sürüm de iyi, ama değer aktarımı eklenirse daha iyi olacağını düşünüyorum
    • Artık iki tarafın dezavantajları da birlikte geliyor. En fazla hesaplama kaynağını tost makinesi gibi kullanabilen kişi diğer herkese DoS uygulayabilir
      Üstelik iş ispatı, boşa giden gereksiz hesaplamadan ibaret. Hesaplama bedava değil ve iş ispatı için harcanan her watt mevcut iklim krizini daha da kötüleştiriyor
      Birkaç gün içinde hissedilen sıcaklığın 120 dereceye, gerçek sıcaklığın 109 dereceye çıkacağı bir bölgede yaşayan biri olarak, kibarca söylemek gerekirse iş ispatının herhangi bir şey için iyi fikir olduğunu öne sürenlere defolup gitmelerini söylemek istiyorum
      İlginç değil; yeryüzündeki en bariz gösterişçi tüketim örneği

  • Daha iyi yazı, yani gerçek teknik ayrıntılar şurada: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
    Seçilen iş ispatı işlevi equi-X gibi görünüyor

  • Böyle bir şeyin daha önce eklenmemiş olmasına şaşırdım; teklif [0]'ı yeterince ayrıntılı okumadığım için kullanıcı anonimliliğini etkileyen verilerin artıp artmayacağını henüz bilmiyorum. Yine de kullanıcı-hizmet birimiyle sınırlı kalır ve hiçbir yerde saklanmazsa iyi görünüyor
    Proxy'lenen hizmetin yükünü ve düğümün kendi yükünü ayrı ayrı ne kadar azaltacağını da merak ediyorum. Erişim birden çok düğüme dağıldığı için hizmet tarafına daha büyük fayda sağlayacak gibi
    [0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...

    • Çoktan yapılmalıydı ama denizlerin kaynadığını haykıran insanlar yüzünden gecikti

  • Güzel. Yakında DDoS savunması için CDN gerekmeyebilir. API'yi Onion hizmeti olarak sunmak yeterli

  • Bu yöntem daha önce e-posta spam'ini önlemek için de önerilmişti
    Cloudflare de yapabilir. Yoğun bir siteye her bağlandığınızda birkaç saniyeden birkaç dakikaya kadar işe yaramaz hesaplama çalıştırılması gibi. Toplam etkisi, dünyanın dört bir yanındaki bataryaları emmek olur herhalde

    • E-posta depozitosu için iş ispatı önerisi Adam Back'in Hashcash'iydi ve kısmi hash çakışmaları kullanıyordu
      http://www.hashcash.org/
      İlginç biçimde Bitcoin iş ispatı madenciliğine ilham verdi
    • Cloudflare bunu zaten yapıyor. “Bağlantı kontrol ediliyor” ekranı çıkıyor ve tarayıcıda hash çalıştırıyor
    • Reklamlarla aynı şey. İzin almadan bataryayı tüketiyor
    • Bu değerlendirme adil değil
      Çünkü atmosfere sera gazı da salacak
    • Bu kavram etrafında yapılmış Bitmessage adlı bir uygulama vardı; şu anda terk edilmiş bir proje gibi görünüyor

  • İş ispatı çalışmaya başladığında, kötüye kullanan kişinin yeni bir kimlik alıp DDoS'a devam etmesini neyin engellediğini merak ediyorum
    Düzenleme: İş ispatı istemciye göre değil, saldırıya uğrayan “hizmet” birimine göre ayarlanıyor gibi görünüyor

    • Hizmet bazında uygulanıyor ve Onion hizmetini ezebildiğiniz bir durumdan, sunucunun istekleri işlemesinden daha fazla hesaplama kaynağı harcamanız gereken bir duruma dönüşüyor. Yardımı olur
    • Doğru. İş ispatı istek başına da olduğu için kimliğin yeni mi eski mi olduğu önemli değil
    • Doğru, istemci bazında değil. İstemci bazında olsaydı iş ispatı istemek yerine kötü niyetli istemciyi engellemek yeterli olurdu
      Anonimlik veya serbestçe yeni kimlik oluşturabilme özelliği nedeniyle saldırgan, Sybil saldırısıyla kapasiteyi tüketip hizmet reddine yol açabilir

  • Burada Sybil saldırısını daha zarif biçimde çözmenin bir yolu var mı merak ediyorum. Örneğin birçok CPU’da işlemci başına benzersiz bir anahtar çifti bulunuyor ve bunlar, düzenleyen Intel, AMD vb. tarafların CA kök sertifikalarıyla doğrulanabiliyor. İş ispatını ardışık imzalarla bağlayıp paralel doğrulamaya izin verirseniz, tüm iş ispatları CPU’ya özgü hâle gelir ve botnet ile paralelleştirilemez
    Bunlar botnet maliyetini artırmak için belleği hedefliyor gibi görünüyor. Bu saldırı senaryosunu azaltmanın başka birçok yolu da var gibi. Aynı mantık eSIM kullanan telefonlara da uygulanabilir. Sonrasında mobil ağ kimlik doğrulaması açık anahtarlı kriptografi kullandığı için benzersiz ispat da mümkün olabilir
    Sadece aklıma gelen bir düşünce; bu yöntemin bariz bir sorununu kaçırıyor olma ihtimalim yüksek

    • Değişmez donanım anahtarı ve üretici sertifikasyon tedarik zincirine dayalı bir çözüm öneriyorsanız, Tor’un ne olduğunu anlayıp anlamadığınızı sormak isterim
    • Onion hizmetine, başka Onion hizmeti kullanımlarıyla ilişkilendirilebilecek bir şekilde kimlik kanıtlamak kötü sonuçlar doğurabilir gibi görünüyor
    • DDoS’un Sybil saldırısıyla ilgisi yok. DoS, sınırlı bir kaynak — burada bağlantı başlatma — ücretsiz sunulduğu için ortaya çıkar
      Belleği yoğun kullanan bir algoritma seçilmesinin nedeni belirli donanımların, yani ASIC kullanımının önüne geçmek
    • Elbette Intel, AMD vb. sertifikalarına güvenmiyorsanız bu yöntem çalışmaz. Bu kullanım için neden güvenilmesi gerektiğini de bilmiyorum
    • “Eşleştirilmiş istemci bağlantısı bekleniyor” denmesi epey etkileyici olurdu. İlginç bir fikir ama aklıma birçok sorun geliyor
      Benzer yönde, sunucunun birden fazla IP havuzu tutup istemcinin port knocking ispatı döndürmesini sağlamak nasıl olur diye düşünüyorum. Örneğin bir token verip “şu IP:port’a gönder” demek ve doğrulayabileceğim benzersiz bir yanıt beklemek gibi. Buna gecikme ispatı denebilir. CPU kullanımı düşük olur ve yük birden fazla makineye ve porta dağıtılabilir. Dezavantajı elbette birden fazla IP’ye ve potansiyel olarak birden fazla sunucuya ihtiyaç duyması. Aynı makinede de uygulanabilir ama o zaman CPU yükü sadece port bağlantılarına kaymış olur

  • Tor ağının trafiğini azaltacak veya onu daha hızlı hâle getirecek bir fikrim var. Ağ CDN gibi kullanılabilmeli. Bir dosyayı yayımlamak istiyorsanız, izin verdiğiniz düğümlere dosya parçalarını gönderebilmeli ve dosya talebi geldiğinde bu düğümleri gösterebilmelisiniz
    Elbette Tor ağının “anonim torrent alternatifi” hâline gelip amacını zedelememesi için dikkatli olmak gerekir
    Mevcut öneri “doğrulanmış ağ trafiği önceliklendirmesi”nden söz ediyor. Gerçekten ağa yardımcı olduğu için, “dosya parçası” paylaşımı trafik önceliğini artırabiliyorsa ilginç olabilir. “İş ispatı” yerine bant genişliği katkısı ispatı olmuş olur

    • Bu, Tor’dan çok içerik tabanlı Freenet modeline daha yakın. Tor geleneksel olarak anonim TCP gerçek zamanlı ağ iletişimi sağlar
      Yine de bunun ağ trafiğini nasıl azaltacağını pek anlamıyorum. Sonuçta CDN düğümüyle iletişim kurmak gerekecek

  • Bu önerinin koyduğu hedefler ve sınırlar makul görünüyor; muhtemelen o hedeflere de ulaşacaktır. Söylendiği gibi küçük ölçekli botnet’lerde işe yarar, ancak büyük botnet’ler hâlâ tek tek istemcilerin kullanılabilir kaynaklarını ezebilir
    Kişisel olarak iş ispatını sevmiyorum. Burada bir savunma mekanizması olarak konuşmasızlıka daha yakın; eski donanımları hızla demode edebilir ve etkilenen tüm cihazlar açısından bakıldığında oldukça fazla elektrik tüketebilir. Büyük ölçekte uygulanırsa ciddi bir çevresel yük olur
    Saldırgan açısından zorluğu bu kadar yükseltmek bile başarı sayılabilir. Kullanıcı cihazını %100’de çalıştırarak 1 dakika beklemek zorunda kalırsa çoğu durumda basitçe vazgeçecektir
    Yine de kullanıcı anonimliğine zarar vermeden DoS saldırılarını hafifleten oldukça iyi bir yöntem; bu açıdan bakınca eksilerine rağmen iyi bir çözüm. Tor’da var olduğu sürece büyük bir sorun yok, ama genel web’e uygulanırsa tam bir felaket olur diye düşünüyorum

  • Yazıda üst seviye bir sunucu ile düşük donanımlı bir telefon arasındaki çözüm süresi farkının yalnızca 6 kat olduğu söyleniyor. Bunun nasıl mümkün olduğunu bilmiyorum. Sunucularda telefonlardan 6 kattan çok daha fazla RAM ve CPU sayısı var; CPU’ların da daha hızlı olma ihtimali yüksek
    Ayrıca söz konusu DDoS ise sunucunun işi rahatsız edecek kadar iyi paralelleştirilebilirken, istemcinin işi mutlaka paralelleştirilemeyebilir
    Fark 6 kat, hatta 1 kat bile olsa, DDoS algılandığında çözüm süresinin 1 dakika olduğu söyleniyor. O noktada hizmet fiilen çökmüş sayılmaz mı?

    • equihash söz konusuysa sınırlayıcı etkenin bellek bant genişliği olduğu biliniyor; sunucu ile telefon arasındaki fark sanıldığından küçük olabilir
    • Algoritmanın açıklaması burada iyi: https://github.com/tevador/equix/blob/master/devlog.md
      DDoS algılandığında çözüm süresinin 1 dakika olması kısmındaki ana fikir, mevcut kolay DoS saldırısı olan introduction flooding’i kısmi arızaya veya yavaşlamaya dönüştürmek. Zor bir problemde kademeli bir iyileştirme
    • O tahminin en azından bir basamak, belki iki basamak ya da daha fazla hatalı olduğunu düşünüyorum. GPU hızlandırması mümkünse fark daha da büyük olabilir