Hacklendim ve Hetzner sunucum Monero madenciliği yapmaya başladı

 (blog.jakesaunders.dev)
1 puan yazan GN⁺ 2025-12-19 | 1 yorum | WhatsApp'ta paylaş
  • Bireysel olarak işletilen bir Hetzner sunucusunda anormal CPU kullanımı fark edildi ve yapılan incelemede kripto para Monero madencisi (xmrig) çalıştığı görüldü
  • Bunun nedeni, Umami analiz aracı konteynerinin, Next.js uzaktan kod çalıştırma açığı (CVE-2025-66478) üzerinden saldırıya uğramasıydı
  • Neyse ki ilgili konteyner root olmayan (non-root) bir kullanıcıyla çalışıyordu ve host mount ya da yetki yükseltme olmadığı için ihlal konteynerin içinde sınırlı kaldı
  • Saldırgan, Next.js server component'lerinde güvensiz deserileştirmeyi kötüye kullanarak zararlı payload'u çalıştırdı ve madenciyi kurdu
  • Bu olay, bağımlılık yönetimi ile konteyner güvenlik ayarlarının önemini gösteren bir örnek oldu; yazar da güvenlik duvarını etkinleştirme, SSH'ı sıkılaştırma ve düzenli güncelleme gibi önlemleri güçlendirdi

Saldırının fark edilmesi ve ilk müdahale

  • Hetzner'den, sunucunun dış ağı taradığına dair bir uyarı e-postası alındı
    • 4 saat içinde önlem alınmazsa sunucunun engellenebileceğine dair bildirim de yer alıyordu
  • SSH ile bağlanıp kontrol edildiğinde /tmp/.XIN-unix/javae yolunda %819 CPU kullanan bir süreç ve birden fazla xmrig süreci bulundu
  • Yaklaşık 10 gündür kripto para madenciliği yapıldığı tespit edildi

Sızma yolunun incelenmesi

  • Tüm zararlı süreçlerin UID 1001 kullanıcısı ile çalıştığı görüldü; bu da Umami konteyneri ile eşleşiyordu
  • /app/node_modules/next/dist/server/lib/xmrig-6.24.0/ dizininde madenci çalıştırılabilir dosyası bulundu
  • Çalıştırma komutunda auto.c3pool.org:443 madencilik havuzu adresi ve kullanıcı anahtarı yer alıyordu

Next.js açığı ve saldırı yöntemi

  • Sorunun kaynağı Next.js'in React Server Components deserileştirme açığı (CVE-2025-66478) idi
    • Saldırgan, değiştirilmiş bir HTTP isteği gönderdiğinde sunucuda keyfi kod çalıştırabiliyordu
    • Bunun sonucunda kripto para madencisinin kurulması ve çalıştırılması mümkün oldu
  • Yazar, “Ben doğrudan Next.js kullanmıyorum” diye düşünüyordu; ancak Umami'nin Next.js tabanlı olduğunu sonradan fark etti

Konteyner izolasyonunun doğrulanması

  • /tmp/.XIN-unix/javae dosyasının host dosya sisteminde bulunmadığı doğrulandı
    • Bu, Docker ps çıktısında konteyner süreçlerinin görünmesinden ibaretti; gerçekte izolasyon korunuyordu
  • docker inspect sonucu
    • Kullanıcı: nextjs
    • Privileged: false
    • Mounts: yok
  • Bu nedenle zararlı yazılım host erişimi, cron kaydı, sistem servisi oluşturma veya rootkit kurma gibi işlemleri gerçekleştiremedi

Kurtarma ve güvenliğin güçlendirilmesi

  • Enfekte Umami konteyneri durdurulup silindi ve ardından CPU kullanımı normale döndü
  • UFW güvenlik duvarı etkinleştirilerek yalnızca SSH, HTTP ve HTTPS'e izin verildi
  • İnceleme sonucu Hetzner'e bildirildi ve ticket 1 saat içinde kapatıldı

Çıkarılan dersler ve iyileştirme noktaları

  • “Ben X kullanmıyorum” demek, bağımlılıkları kapsamaz
    • Kullanılan araçların hangi teknoloji yığınıyla kurulduğunu kontrol etmek gerekir
  • Konteyner izolasyonunun etkisi doğrulandı
    • Root olmayan kullanıcı, ayrıcalıksız mod ve gereksiz volume kullanılmaması, hasarın büyümesini engelledi
  • Çok katmanlı güvenlik (Defense in Depth) gerekli
    • Güvenlik duvarı, fail2ban, izleme ve düzenli güncellemeler şart
  • Dockerfile'ı doğrudan yazmanın ve konteyner yetkilerini en aza indirmenin önemi vurgulandı

Olaydan sonra alınan önlemler

  • Umami en son sürümle yeniden dağıtıldı ve tüm üçüncü taraf konteynerler denetlendi
    • Çalıştırma kullanıcısı, mount'lar, güncelleme zamanı ve gereklilik gözden geçirildi
  • SSH anahtar tabanlı kimlik doğrulamaya geçildi, parola ile giriş devre dışı bırakıldı, fail2ban yapılandırıldı
  • Grafana ve Node Exporter ile izleme güçlendirildi, güvenlik güncellemeleri hemen uygulanmaya başlandı

Sonuç

  • Umami'deki Next.js açığı nedeniyle 10 gün boyunca Monero madenciliği için suistimal edilmiş olsa da,
    konteyner izolasyonu ve root olmayan kullanıcıyla çalışma ayarı sayesinde zarar sınırlı kaldı
  • Bu deneyim sayesinde yazar, bağımlılıkları anlama, güvenlik yapılandırması ve güncelleme yönetiminin önemini bizzat gördü
  • Olay yaklaşık 2 saat içinde kontrol altına alındı ve konteyner güvenliğinin pratikteki etkisini doğrulayan bir örnek olarak kaldı

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-19
Hacker News görüşleri

  • Eskiden UFW kullanıyordum ama artık firewalld öneriyorum
    UFW zamanla yönetmesi zorlaşıyor, ama firewalld XML tabanlı yapılandırması sayesinde çok daha sağlam
    firewall-cmd komutuyla SSH, HTTPS, 80 portu gibi ayarlar yapılabiliyor ve nftables arka ucunu kullanmak iyi oluyor
    Docker söz konusu olduğunda, güvenlik duvarı kurallarını by-pass edip port açtığı durumlar sık görüldüğünden /etc/firewalld/firewalld.conf içinde StrictForwardPorts=yes ayarlamak daha güvenli

    • Portları 8080:8080 gibi açmak yerine 192.168.0.1:8080:8080 gibi özel IP'ye bind etmek daha iyi
      Ben Docker'ı 10.0.10.11 VM üzerinde çalıştırıyorum, yalnızca WireGuard ile erişilebilecek şekilde ayarlayıp Caddy ile reverse proxy koymak kullanışlı oldu
    • Docker yerine Podman kurmanızı öneririm. Docker'da güvenlik duvarını by-pass etme sorunu sık görülüyor
    • Hangi netfilter frontend'ini kullanırsanız kullanın, giden bağlantı kısıtlaması yoksa pek anlamı kalmıyor
      Zararlı yazılım dış mining pool'larına ya da C2 sunucularına bağlanmaya çalışacağından, izin verilmeyen binary'lerin ağa erişimini engellemek gerekiyor
      /tmp, /var/tmp, /dev/shm için çalıştırma iznini kaldırmak da faydalı
    • Hetzner ücretsiz bir harici güvenlik duvarı hizmeti veriyor, bu yüzden ilk savunma hattı olarak kullanılabilir
    • Kişisel olarak sadece nftables.conf ile de yeterince basit ve net bir yapı kurulabildiğini düşünüyorum
      iptables zaten fiilen terk edildiği için firewalld gibi ek bir katman şart değil

  • Bu, “React2Shell CVE-2025-55182” ile ilgili bir sorun gibi görünüyor
    Bir yıldan uzun süredir etkili olan bir zafiyet olmasına rağmen neredeyse hiç dikkat çekmemesi garip
    Son 12 ay içinde Next.js ile deploy edilmiş bir web uygulamasıysa büyük ihtimalle zaten bir botnet'in parçası olmuştur
    Sektörün sadece “Docker kullan”, “güvenlik duvarını aç” seviyesinde tavsiye vermesi can sıkıcı
    Bugünlerde frontend ekosisteminden soğudum, kariyerimi C++ tarafına kaydırmayı düşünüyorum

    • Frontend'in teknoloji yenilenme döngüsü eskisine göre çok daha yavaşladı
      Şu anda Next.js, React, Tailwind, Postgres kombinasyonu 5 yıldır neredeyse standart hâline gelmiş durumda
      2000'lerin sonu ile 2010'ların başındaki framework karmaşasına kıyasla daha istikrarlı
      Trendlerden ve değişimden hoşlanmıyorsanız yapay zeka geliştirme tarafı çok daha hızlı değişiyor
    • En yeni JS framework'lerini kullanmadan da rahatlıkla web uygulaması yapılabilir
      Backend'de .NET, Java, Go gibi sağlam teknoloji yığınları kullanılabilir, frontend ise serbestçe seçilebilir
      Böylece hem CVE sayısı azalır hem de teknoloji yorgunluğu düşer
    • Benim Pangolin instance'ım da bu zafiyet yüzünden ele geçirildi
      İlgili GitHub tartışması
    • Ben de yaklaşık 100 Next.js frontend deploy ettim ama Server Components kullanmadığım için neyse ki etkilenmedim

  • Docker konteynerinin CPU kullanımını --cpus="0.5" ile sınırlandırırsanız, hatalı çalışan servisler veya miner'lar tüm sistemi etkileyemez

    • Konteynerleri read-only modda çalıştırmak saldırı yüzeyini daha da azaltabilir
    • Ancak CPU limiti fazla düşük olursa, ihlal fark edilmeden tespit gecikmesi yaşanabilir
    • Uygulamanın performans profilini iyi bilmek gerekir. Sonradan burst trafik oluşursa istenmeden throttle edilebilir
    • Bellek için soft/hard limitleri de birlikte ayarlamak iyi olur

  • Güvenlik duvarı olmadan sunucu işletmek epey cesur bir tercih
    Hetzner'in harici güvenlik duvarını da kullanırsanız hata yaptığınızda ekstra bir savunma katmanı olur
    Ben SSH'ı sadece ev IP'me açıyorum, dışarıdan gerektiğinde Hetzner web sitesinden geçici olarak açıyorum

    • Çoğu durumda güvenlik duvarının büyük bir etkisi yok
      Asıl önemli olan RCE zafiyeti olan yazılımları çalıştırmamak
      Docker'ın kurtarıcı gibi görünmesi aslında biraz da şans eseri
    • Public web hizmetiyse güvenlik duvarı çok yardımcı olmuyor
      Bunun yerine bir bastion host koyup HTTP proxy ile giriş çıkışı kontrol etme yöntemi var ama kurulumu karmaşık
    • 30 yıldır Linux çalıştırıyorum; hacklenmemin tek olduğu durum iyi bilinen portları açık bırakmaktı
      Standart dışı port kullanmak bile şaşırtıcı derecede etkili oldu
    • Parola ile kimlik doğrulamayı açık bırakmak riskli. Kişisel olarak fail2ban'ın şart olduğunu düşünmüyorum
    • SSH portunu rastgele değiştirerek port tarayıcılarından kaçınmaya çalışıyorum
      Ne kadar etkili olduğundan emin değilim ama biraz psikolojik şemsiye gibi

  • Docker konteynerlerini root olarak çalıştırınca host'a da saldırılabilir mi diye merak etmiştim

    • Docker bir güvenlik sınırı değildir. Sadece süreç seviyesinde izolasyon sağlar
      Güvenilmeyen kod çalıştıracaksanız VM (KVM/QEMU) ya da gVisor(https://gvisor.dev/), Firecracker(https://firecracker-microvm.github.io/) gibi teknolojiler kullanılmalı
      Docker'ı bir sandbox değil, izole yürütme ortamı olarak düşünmek gerekir
    • Saldırgan konteyner içinde de CPU kullanıp Monero madenciliği yapabilir
      Docker'ın varsayılan ayarlarında RAM, CPU, disk kullanım limiti yoktur; bu da DoS saldırılarına açık olduğu anlamına gelir
      Üstelik pek çok rehber --privileged ya da CAP_SYS_PTRACE gibi tehlikeli seçenekler öneriyor
    • privileged modda Docker soketi üzerinden host'un root dosya sistemine erişmek mümkün
      Yeni bir konteyner başlatıp root yetkisine geçmek de mümkün olabilir
    • Gerçek bir güvenlik sınırı için user namespace etkinleştirilmelidir
      Docker'da bu hâlâ varsayılan değil; ayarlanmazsa kaçış riski yüksektir
      Geçmişteki konteyner kaçışlarının çoğu user namespace ile engellenebilirdi
    • Konteyner kaçışı elbette var, ama çoğu saldırı sadece otomatik madencilik saldırısı
      Hassas veri işlemeyen bir sunucuda yalnızca konteyneri temizlemek yeterli olabilir

  • Saldırı yüzeyini azaltmak için dışarı açılması gerekmeyen servisleri internete açmamak gerekir
    Örneğin analiz araçlarına sadece WireGuard ya da SSH SOCKS proxy üzerinden erişim verilebilir

  • Ben de Hetzner sunucusunda Monero miner bulaşması yaşadım
    Neyse ki bu sadece Incus'un LXC konteyneri içinde olmuştu ve CPU önceliği düşük olduğu için fark etmemiştim
    root hesabına SSH anahtarı eklenmiş ve uzaktan yönetim ajanı kurulmuştu
    Sonunda konteyneri sildim ama birkaç ders çıkardım

    • Sistemin bir gün ele geçirileceğini varsayıp izolasyon ve kaynak limitleri ayarlamak gerekiyor
    • ZFS snapshot ve yedekleri düzenli tutmak kurtarmayı kolaylaştırıyor
    • İhlal edilmiş sistemi tamamen atmak ideal, ama duruma göre geri alıp güçlendirmek de mümkün
    • Miner düzgün yapılandırılmadığı için fark edildi; sessizce sızmış olsaydı muhtemelen hiç anlamazdım
    • Bu, Umami kurulu konteynerde olmuştu

  • Yazıda insan tarafından düzeltilmemiş yapay zeka halüsinasyonu içeren kısımlar vardı
    Bunun Puppeteer ile ilgili bir zafiyet olduğu tekrar tekrar söyleniyor ama doğru değil

    • Asıl metnin ilk paragrafında bunun bir Claude oturum dökümü olduğu açıkça belirtilmişti

  • Son dönemde React 19 zafiyetini kullanan Monero miner'lar sağa sola kuruluyor
    Ben de aynı sorunu yaşadım

    • Bu tür madencilik zararlıları aslında daha görünür ve daha az zararlı olduğu için bir bakıma faydalı
      Otomatik bug bounty gibi çalışıp zafiyeti haber veriyor
      Ağ veya süreç izleme iyi kurulmuşsa kolayca tespit edilebilir
    • Oracle Cloud üzerindeki Umami sunucum enfekte oldu ve sunucuyu sıfırladım
      Bu sayede yedekleme sistemimi yükseltmek için iyi bir fırsat doğdu

  • Bu tür örnekleri görünce VPS'i kendim yönetmeme kararımın doğru olduğunu düşünüyorum
    Daha önce denedim ama ben sıradan bir yönetici seviyesindeyim ve güvenliği sürdürmek bana zor geliyor
    Bu yüzden artık işi uzmana bırakıp ücret ödemek bana çok daha rahat geliyor