TablePlus’ın haftalar süren DDoS saldırı girişimleri karşısında neden hiçbir şey yapmadığı

 (tableplus.com)
1 puan yazan GN⁺ 2024-03-31 | 1 yorum | WhatsApp'ta paylaş
  • TablePlus, haftalardır süren DDoS girişimlerine rağmen IP engelleme ya da Cloudflare “Under Attack” modu kullanmadan sunucu durumunu izliyor
  • Son 30 günde kurulum dosyası indirme girişimi yaklaşık 6 milyon, yalnızca son 5 günde 800.126 oldu; dosya boyutu indirme başına yaklaşık 200 MB
  • Saldırı sırasında bile sunucu CPU kullanımı çoğunlukla %0–1 seviyesinde kaldı; yaklaşık 8 API servisi ve veritabanı, önbellek olmadan ayda milyarlarca isteği işleyebilecek şekilde yapılandırılmış durumda
  • Backend, uygulama başına monolitik servisler olarak paketleniyor; Docker, Kubernetes veya runtime ortamı olmadan tek bir binary yeni VPS’e dağıtılıyor
  • Go/Rust framework’leri, veritabanı indeksleme, log DB ayrımı, Nginx reverse proxy, Cloudflare CDN/R2 ve e-posta gönderimi için throttling gibi basit yapılandırmalar saldırı maliyetini ve operasyonel karmaşıklığı düşürüyor

Haftalar süren DDoS girişimleri

  • Birileri TablePlus sunucularına haftalar boyunca yüz milyonlarca istek gönderdi ve kurulum dosyalarını milyonlarca kez indirmeye çalıştı
  • Kurulum dosyası indirme girişimleri son 5 günde 800.126, son 30 gün bazında yaklaşık 6 milyon seviyesine ulaştı
    • Kurulum dosyasının boyutu indirme başına yaklaşık 200 MB
  • Son 30 gündeki API çağrılarına göre trafiğin çoğu AB’den, özellikle Germany ve United Kingdom’dan geliyor
    • Bu sayı indirme isteklerini ve CDN trafiğini kapsamıyor
  • Yazının yazıldığı sırada saldırı hâlâ devam ediyor

Gerçek yanıt: engellemekten çok dayanacak yapı

  • Saldırgan IP adresleri engellenmiyor
  • Cloudflare kullanılıyor ancak “Under Attack” modu açılmıyor
  • Saldırı sırasında bile sunucu CPU’su çoğunlukla %0–1 seviyesinde, neredeyse boşta
  • Servis ayda milyarlarca isteği sorunsuz işleyebildiği ve maliyet yükü de büyük olmadığı için neredeyse hiç ek önlem alınmıyor

Basit backend tasarımı

  • TablePlus uygulama tasarımında sadeliği hedefliyor; backend servisleri de mümkün olduğunca minimum yapılandırmada tutuluyor
  • Vercel veya Netlify gibi üçüncü taraf rendering servisleri saldırı sırasında darboğaz ya da beklenmedik faturalar oluşturabileceği için kullanılmıyor
  • Kendi web sunucusunu kullanmanın bu sınırlamaları aşabileceği düşünülüyor
  • Geçmişte zayıf VPS’ler ve işlemciler nedeniyle monolit darboğaz haline gelebilirdi; ancak günümüzde VPS’ler çok çekirdekli CPU, büyük RAM ve hızlı SSD sunuyor
    • Hızlı SSD ve RAM, veritabanı performansını ciddi biçimde artırıyor
    • Doğru uygulanırsa tek bir instance üzerinde çalışan monolit servis de ayda milyarlarca isteği işleyebilir

Uygulama başına monolit işletim modeli

  • Her uygulama için gereken API, web sitesi, e-posta, ödeme gibi bileşenler tek bir serviste birleştiriliyor
  • Dağıtım; tek bir yapılandırma dosyası, build ve deploy adımlarıyla tamamlanıyor
  • Servisi başka bir bulut sağlayıcısına taşırken veya yeniden dağıtırken hızlı hareket edilebiliyor
  • Bağımlılık az olduğu için hata ayıklama ve darboğaz tespiti kolaylaşıyor
    • Hata oluştuğunda bile kontrol edilmesi gereken servis sayısı bir ya da birkaç tane ile sınırlı kalıyor
  • Seçilebilecek monolit framework örnekleri şunlar
    • Golang: Echo, Gin
    • PHP: Laravel
    • Ruby: Rails
    • Rust: Actix, Rocket, Warp

Ayda milyarlarca istek için yapılandırma ilkeleri

  • Yüksek performanslı web framework’leri seçiliyor; TablePlus Golang ve Rust tercih ediyor
  • Veri kümesi büyüdükçe sorgu süresini azaltmak için veritabanında indeksler ayarlanıyor
  • Temel iş performansını korumak için ana veritabanı ile log ve kullanım veritabanı ayrılıyor
    • Ana veritabanı, değişmeyen veya zaman geçse de boyutu artmayan veriler için
    • Log ve kullanım veritabanı, zamanla sürekli büyüyen veriler için
  • Temel API’lerin önüne istekleri işleyip dağıtan bir reverse proxy konuyor
    • Birden fazla sunucu gerektiğinde yardımcı oluyor
    • TablePlus Nginx kullanıyor
  • Her şey Cloudflare arkasına alınıyor; cache, Argo ve Cloudflare ile sunucu arasındaki full SSL uygun şekilde yapılandırılıyor
  • DDoS koruması olan bir CDN kullanılıyor
    • TablePlus maliyetleri düşürmek ve korunmak için Amazon CloudFront + S3 yerine Cloudflare R2 ve CDN tercih ediyor
  • Büyük indirme dosyaları CDN veya caching olmadan VPS üzerinde tutulursa bant genişliği hızla tükenir
    • TablePlus sınırsız bant genişlikli Cloudflare CDN kullanıyor
    • Aynı domain’de Argo etkinleştirilirse Cloudflare CDN trafiği Argo üzerinden geçebilir; Argo bant genişliği ücretsiz olmadığından maliyet artabilir
  • Şifre sıfırlama gibi sunucunun e-posta göndermesini gerektiren isteklerde mailer’ı korumak için throttling uygulanıyor

Dağıtım modeli: konteyner olmadan binary çalıştırma

  • TablePlus, Docker, Kubernetes, container veya ayrı runtime ortamı ayarı olmadan dağıtım sürecini olabildiğince basit tutuyor
  • Dağıtım birimi binary
    • Linux sunucuya kopyalanıp process olarak çalıştırılıyor
    • macOS’te TablePlus uygulamasını çalıştırmaya benzer şekilde ele alınıyor
  • Linux Systemctl’in process’i izlemesi ve kritik hata oluşursa yeniden başlatması sağlanabiliyor
  • VM, sanallaştırma veya üçüncü taraf altyapı yöneticileri gibi ara katmanlarda CPU/RAM israf etmemek için native şekilde çalıştırılıyor
  • Go ve Rust yüksek performanslı diller olduğu ve dağıtım için binary dosyası üretebildiği için seçiliyor

Vercel kullanırken açık tutulması gereken koruma özellikleri

  • Vercel, bu tür durumlarda siteyi korumak için Spend Management ve Attack Challenge Mode özelliklerini sunuyor
    • Spend Management: soft veya hard harcama limiti belirlenebilir
    • Attack Challenge Mode: Cloudflare’in “Under Attack” moduna benzer
  • Vercel kullanılıyorsa bu özellikleri açık tutmak gerekiyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-31
Hacker News yorumları

  • Bu yazı fazlasıyla kendini övme gibi geliyor. “Ayda 1 milyar istek” saniyede yalnızca birkaç yüz istek demek; önemsiz bir seviye ve buna DDoS demek bile zor.
    Üstelik site CDN olan Cloudflare’in arkasında; performans açısından kayda değer bir şey yaptıklarını düşünmenin nedenini daha da az anlıyorum.
    Örneğin 200 MB’lık bir dosyanın CDN’de önbelleğe alınmadan sunulması için makul bir durum yok. Uygulama sunucusunun her indirmede diskten 200 MB okuyup istemciye kopyalamamasıyla övünülecek bir şey değil; öyle yapmak zaten bariz şekilde kötü bir tasarım olurdu.

    • Bahsedilen 200 MB dosya, https://tableplus.com/download adresindeki TablePlus istemci uygulaması indirmesiyse, Windows sürümü 183 MB ve gerçekten Cloudflare’de önbelleğe alınmış.

      # curl -v https://files.tableplus.com/windows/5.9.2/TablePlusSetup.exec > /dev/null

      < cache-control: max-age=691200

      < cf-cache-status: HIT

      < age: 2980

    • Normalde FAANG şirketlerinde bunun 1.000’den fazla geliştirici gerektirecek bir iş olduğu düşünülmez miydi? Büyük şirketlerin bile düzenli olarak yapamadığı bir şey için nasıl yalnızca kendini övme denebilir, bilmiyorum.

    • Bunu sadece saniyede birkaç yüz istek diye görmek zor. İstek yoğunluğu zamana eşit dağılmaz ve ortalamanın 20 katına kadar sık sık çıkabilir.

  • Ayda 4 TB aslında DDoS saldırısı sayılması zor değil mi? Saatte 4 TB olsa DDoS denebilirdi, ama ayda 4 TB saniyede sadece 1,5 MB demek.
    Ayda 6 milyon istek de saniyede yalnızca 2 istek. Bu ölçekte monolitik bir servis olarak çalışması pek önemli görünmüyor; özellikle de Cloudflare’in isteklerin çoğunu CDN önbelleğiyle karşıladığını düşünürsek.

    • Web’in ezici çoğunluğu ayda 5–20 dolarlık çok kiracılı hostinglerde çalışan WordPress sitelerinden oluşuyor; daha büyük kuruluşlarda da çoğu zaman Drupal oluyor. Önbellek bile kurmadan doğrudan veritabanına bağlı oldukları için internetteki sitelerin çoğu saniyede 4 istekle bile çökebilir.

      Kulağa çılgınca gelebilir ama gerçek bu. Eskiden Cloudflare’de DDoS koruması, WAF, güvenlik duvarı ve müşterilere yönelik güvenlik projelerini yönetiyordum; web scraping veya çok düşük seviyeli, basit HTTP istek oranlarıyla müşteri sitelerinin sık sık düştüğünü gördüm.

      Büyük sayılar manşetlere çıkar ama çoğu insanın gerçekte hissettiği şey küçük sayılardır.

    • Hizmet engelleme saldırısı saatte birkaç KB ile bile mümkün olabilir. Hedef servisin ağır bir API endpoint’ine dokunursanız bu tek başına servisi düşürebilir; Distributed sadece birden çok makinenin aynı anda saldırdığı anlamına gelir.

      DDoS için mutlaka devasa throughput gerekmez. Sadece haberlerde genelde büyük saldırılar yer alır.

      Böyle bir saldırının amacı, origin sunucunun bant genişliği kotasını tüketmek veya bant genişliği maliyetini karşılanamaz hâle getirmek olabilir. Tek bir ya da az sayıda saldırı makinesiyle bile çok ucuza yapılabilir. Çoğu veri merkezi ve hosting sağlayıcısında bant genişliği sınırı vardır ya da belirli bir miktardan sonra ücretlendirme yapılır; saldırıya uğrayan şirketler çoğu zaman bunu ancak karşılayamayacakları faturayı alınca fark eder.

    • Toplam oyuncu sayısı yaklaşık 50 olan bir oyun indirme web sitesi var. Kimse kullanmıyor; gerçek insanların oyunu ayda birkaç kez indirdiğini tahmin ediyorum.
      Ama tek bir 2 GB zip dosyası geçen ay 5 TB trafik üretti ve bu yıllardır devam ediyor. Bu DDoS değil; bağlantıların hepsini takip edip indirmeyi iptal edemeyen yanlış yapılandırılmış bir bot/crawler sadece.

    • Günde yaklaşık 1 TB gibi görünüyor, ama yine de hâlâ çok küçük sayılır.

    • Trafiğin ne kadar düzensiz olduğuna bağlı gibi.

  • Bu, masaüstü uygulaması için yalnızca statik bir pazarlama sitesi. Tartışma forumu yok, geri bildirim GitHub issue’larıyla ele alınıyor.
    Statik bir pazarlama sitesi dağıtmanın ne kadar basit olduğunu ve statik dosyaların günde milyonlarca kez indirilse de ayakta kaldığını övmek oldukça tuhaf. Ayrıca burada azaltım işini yapan Cloudflare; onlar değil. Tabii bu küçücük trafik için azaltım gerekiyorsa.

    Ben böyle bir “saldırıya” uğrasaydım, Cloudflare’in her ay gönderdiği “X TB aktarıldı, neredeyse %100 bant genişliği tasarrufu” e-postasını alana kadar muhtemelen farkına bile varmazdım.

    Uygulamanın kendisini seviyorum ve tavsiye edilebilir buluyorum.

    • Uygulamayı ben de seviyorum, ama bu yazı ChatGPT’den tuhaf bir pazarlama yazısı üretmesini istemişler gibi duyuluyor. Genel olarak pek tutarlı değil; gerçek DDoS saldırısı yaşamış biri için daha da öyle.
    • “Dağıtımın ne kadar basit olduğunu övme” kısmının aslında daha fazla görülmesini isterim. İnsanlar kendi aşırı karmaşık altyapılarının optimal olmadığını ne kadar çok anlarsa o kadar iyi.

  • Bu, DDoS saldırısından çok; anlatıma göre ayda yaklaşık 8 TB ek trafiğe yol açan “sinir bozucu derecede anlamsız servis kötüye kullanımı”na benziyor.
    Böyle bir kötüye kullanım maliyet ya da kaynak tükenmesi sorunu yaratmadığı sürece yok sayılabilir; ama “meğer otomatik ölçeklenen filonun kapasitesinin %80’i hiçbir işe yaramayan şeylerle meşgulmüş” türü hikâyeler moral bozacak kadar yaygın, bu yüzden en azından izlemek gerekir.

    Bu tür kötüye kullanımda en sinir bozucu kısım genellikle loglardır. Logların çoğu aynı hostların aynı anlamsız davranışları tekrar etmesiyle dolar. Log depolama ucuz ve bol ise büyük sorun değil, ama belirli trafiği otomatik olarak kötüye kullanım diye sınıflandırıp rutin işlemeyi bastırmanın kesinlikle iyi bir fikir olduğu açık.

    Yine de söylemesi kadar kolay değil. Gelen SMTP sunucusuna bariz ve aptalca kötüye kullanımları yakalayan sınıflandırma mantığını kaç kez eklediğimi sayamam; her seferinde sınırda ama geçerli senaryolar da takılıyordu.

    Arka arkaya gelen rabbit hole’lara çok fazla zaman harcarsanız gerçek işi yapamaz hâle gelmek kolaydır. Bu yüzden dışarıya yaptırmak ya da o da çok zahmetli veya pahalıysa, sinir bozucu olsa bile kötüye kullanımı görmezden gelmek bazen daha iyi olabilir.

    • AWS’de 8 TB çıkış trafiği, aylık 1 TB ücretsiz kullanım hesaba katılsa bile 595 dolar; Hetzner’de ise 10 doların altından başlıyor.
      DigitalOcean’da örneğin s-4vcpu-8gb-intel paketine dahil 5 TB’ın üstündeki 3 TB fazlalık için 30 dolar ödersiniz; Linode’da 3 TB fazlalık 15 dolar. Bu yüzden yazının bir noktası olduğunu düşünüyorum.
    • Görmezden gelmeye devam ederseniz daha şüpheli şeyler yapmalarını teşvik etmiş olursunuz. Bu tavır bugünün internetini neredeyse bir bataklığa çevirdi.

  • Bu, dikkate değer bir “saldırı” değil. Birinin makinesinde kontrolden çıkmış tek bir bash betiğiyle bile mümkün
    “Birleşik Krallık’tan ayda 50 milyon istek” ortalamada saniyede 20 isteğin bile altında. Tek bir Go sunucusunun, büyük bir optimizasyon olmadan bile bunun 250 katı istek hacmini karşılamasını beklerim

    Tavsiyenin kendisi illa kötü değil, ama bu sayılar tavsiyeye kanıt oluşturmaz. Bir Go HTTP API servisi söz konusuysa, küçük-orta ölçekli bir VPS’te, biraz veritabanı işi ve JSON biçimlendirme olsa bile optimizasyonsuz saniyede 5 bin isteği kaldırmasını beklerim. Bu sayı, günde milyarlarca istek alan ve pikte saniyede 500 bin isteği aşan bir yerde benzer servislerden onlarcasını dağıtmış olmama dayanıyor

    • Böyle bir trafik API’ye tekrar tekrar istek olarak yığılıyorsa ve hepsi şüpheli olmayan konumlardan geliyorsa, DDoS’tan önce istemci koduna yanlışlıkla sonsuz yeniden deneme döngüsü koyup koymadığınızı düşünmelisiniz

  • Bunun zarar vermemesi güzel, ama bunu tavsiye olarak almak için eksik kalan çok şey var; bu yüzden biraz tedirgin edici
    Docker yerine ikili dosya dağıtımını tercih etme fikri tamam, ama o ikilinin çalıştığı host ne olacak? Konteyner kullanma nedenlerinden biri, güvenlik sertleştirme ayarlarını dağıtımla birlikte paketlemek ve ileride ölçeklemek gerektiğinde düğümler arasında güvenlik ayarlarının aynı olduğundan emin olmaktır

    Burada sözü edilen monolit tek bir VPS’e konabilir; bu iyi ve ucuz da. Ama çökerse ya da donanım herhangi bir nedenle arızalanırsa oldukça ciddi bir kesinti yaşanabilir

    Bir başka endişe de her şeyi monolite bağladığınızda uygulama yığınındaki derinlemesine savunmayı kaybetmeniz. Birisi ön uç üzerinden uygulamayı aşarsa, arka uç veri deposuna doğrudan gidebilir. Bu yüzden birçok kişi veri deposunu dahili web servislerinin arkasına koyar ve ön uçtan ayrı bir özel ağdaki güvenlik gruplarıyla kapatarak saldırı yüzeyini tarayıcıyla yapılabilecek işlemler seviyesinde sınırlar

    • Saldırı yüzeyini artırarak güvenliğin iyileştiği bir dünya yok

    • Docker kurunca host’un güvenli hale geldiğini düşünüyorsanız yanılıyorsunuz. Ölçeklerken ek host’ları nasıl yapılandıracaksınız?

      Docker kullanınca yalnızca konteynerin değil, host’un, yani konteyneri çalıştıran servisin de güvenli olması gerekir. Ölçekleyip ek host dağıttığınızda da aynı şekilde güvenli olması gerekir

      Kod olarak altyapı ve kod olarak yapılandırma kullanıyorsanız, sistem ayarlarının ardından ister ikili dosya dağıtın ister Docker dağıtın, özünde fark yoktur

    • “Bare metal” kurulumunu bir ölçüde yeniden üretilebilir kılan araçlar var. Örneğin NixOS, Ansible, Amazon AMI imajı oluşturma

    • “Ön uç üzerinden uygulamayı aşmak” ifadesini hiç anlayamıyorum. SQL enjeksiyonu, uzaktan kod çalıştırma olmadan veri deposuna doğrudan dokunur; XSS ise diğer kullanıcıları yatay olarak etkiler
      Peki ön uçtan tüm arka uca nasıl serbestçe ulaşılıyor? İnsanlar Go API servisinin içinde kabuk erişimi olan bir JavaScript yorumlayıcısı çalıştırıp kullanıcı girdisine eval mi çağırıyor? Teknik olarak fazla zorlama geliyor

    • Sonuçta bu muğlaklık yoluyla güvenlik değil mi? Biz de anlayamayacak kadar karmaşık yaparsak başkaları da anlayamaz mantığı mı?

      Önemli olan daha fazla duvar örmek değil, duvarları yıkılamaz hale getirmektir. Arayüzler performansı düşürür ve karmaşıklığı artırır

  • Şahsen rahatsız edici bir ifade. “Ayda 1 milyar istek” kabaca saniyede 370 istek eder. İyi yapılandırılmış tek bir sunucuyla bile kaldırılabilecek düzeyde; kesinlikle 10’dan az sunucu yeter
    Tek bir kötü niyetli bash betiğiyle bile bu kadar trafik üretilebilir

    • Mikroservisler sayesinde saniyede 1000 isteği karşılamak için 45 Kubernetes düğümüne ihtiyacımız var
    • Bu, istekler zamana eşit dağılmışsa doğru. Ama saldırı durumunda istekler birden zirve yapıp sonra düzleşebilir ve yine de 30 günlük ölçekte ayda 1 milyar istek edebilir
    • İyi yapılandırılmış tek bir sunucu değil; JVM JIT devreye girdikten sonra tek bir çekirdekle bile mümkün

  • Gerçeklik algım kaymış olabilir ama ayda birkaç milyar istek kulağa önemli bir şey değilmiş gibi geliyor. Bu büyük bir DDoS saldırısı sayılıyor mu?

    • Masrafı kimin ödediğine bağlı. Kendi barındırmanızsa sorun değil, ama serverless tarafında bu seviye bile genellikle pahalıya patlar; hele değersiz trafikse daha da öyle
    • Makul tasarlanmış bir API için saniyede 300-400 API isteği ağır bir yük değildir. Saniyede 300-400 statik dosya isteği ise fıstık bile sayılmaz
    • Evet. Ayda 1 milyar istek ortalamada saniyede 380 istek eder, yani o kadar yüksek değil
    • Birçok etkene bağlı. Altyapı genelde beklenen kullanıma göre provision edilir; aşırı fazla pay bırakmak israftır

  • “Her uygulama için dağıtımı ve bakımı kolay bir monolit servis oluşturuyoruz. Docker yok, Kubernetes yok, bağımlılık yok, çalışma zamanı ortamı yok; yeni oluşturulmuş herhangi bir VPS’e dağıtılabilen tek bir ikili dosya var” kısmını beğendim

    • TablePlus’ı doğrudan kullanmıyorum. Bu bir pazarlama web sitesinden bahsediyorsa Kubernetes gerekmediği zaten açık
      Uygulamadan bahsediyorsa bağımlılık olmaması tuhaf. Veri saklayıp log da tutmuyor mu?

    • Bu, Golang’in gerçekten harika bir avantajı. Bir VPS açıp makul varsayılanları uyguladıktan sonra çapraz derleme yapıp ikiliyi çalıştırmanız yeterli

      Python, Node, PHP dağıtımlarıyla karşılaştırınca gereksiz karmaşıklık çok daha az

      Veritabanı sunucusunu çalıştırıp ayakta tutmak da keşke bu kadar basit olabilse

  • Başlığı görünce biraz daha swole doge’a yakışır bir içerik beklemiştim. Tavsiyelerin önemli bir kısmına katılıyorum, ama Cloudflare arkasında olmak kesinlikle “hiçbir şey” değil
    Trafik dağılımına bağlı olarak Cloudflare olmadan sadece VPS’le de iyi dayanmış olabilirlerdi; ölçek de o kadar büyük görünmüyor. Saniye başına istek sayısı ve Cloudflare’ın origin’e ulaşmadan önce ne kadarını engellediği gibi daha ayrıntılı istatistikleri görmek ilginç olurdu

    Bildiğim, İsveçli şirketleri hedef alan Rusya kaynaklı 7. katman DDoS o kadar büyüktü ki büyük sağlayıcılar kapasite sorunlarına çarpıp düştü. Buna Verizon, Azure Frontdoor, Cloudflare ve GCP yük dengeleyici de dahildi. O ölçekte bu strateji kesinlikle işe yaramaz