NAS’nde Bir Fan Sorunu Aradım, 40 Saattir Süren Kimlik Bilgisi Saldırısı Buldum.

Sadece sabit disk sıcaklıklarını kontrol etmem gerekiyordu. Her 10°C’lik artışın bir sabit diskin arızaya uğrama olasılığını yaklaşık %23 artırığını öğrendikten sonra, Synology DS1621xs+ cihazımın fanlarını kontrol etmek için DSM’yi açtım. Ardından Log Center’ı açtım ve fanlarla ilgili endişelerim en arkaya düştü.

Add

XDA

on Google

Add as Preferred Source

Follow on Google Discover

Birisi neredeyse iki gün boyunca NAS’ıma her 10 ila 40 saniyede bir giriş yapmaya çalışıyordu. Hiçbiri içeri giremedi, ama aslında hiçbirisi bu cihaza hiç ulaşmamalıydı. Ev laboruarım CGNAT’ın ardında duruyor (ya da öyle sandırdım), Tailscale’ın uzaktan erişimin korkutucu kısmını üstlenmesine izin verdim ve NAS’ımdaki yaygın güvenlik ayarlarını kontrol ettim. Suçlu, kendim oluşturup unuttuğum bir şeydi.

Log Center’da 40 saatlik DSM giriş saldırıları nasıl görünüyor

Dönen IP adresleri, her 10 ila 40 saniyede bir kullanıcı adlarını sıraya diziyor ve her deneme başarısız oluyor

Log Center’ın Bağlantı kategorisi, uyarılarla dolu bir duvardı; her biri farklı boşluklarla doldurulmuş aynı cümleydi. “[admin] kullanıcısı [IP]’den [DSM]’ye [password] yoluyla giriş yapamadı, yetkilendirme hatası nedeniyle.” Sonra yönetici, sonra pazarlama, sonra muhasebe, ardından melvin, charlene ve marcelo gibi bir sürü ilk ad. Günlükte gerçek kullanıcı adım denen tek bir giriş bile yoktu; işte gülebilmemi sağlayan tek sebep bu.

İlk deneme, NAS saatine göre 26 Eylül’de 20:38:04’te gerçekleşti. Bu saat, yaz saati uygulaması olmayan bir Bogotá saat dilimine ayarlıydı, dolayısıyla aslında 21:38 Doğu saatiydi ve bu düzeltme listenin üzerindeki küçük işlerden birini daha oluşturdu. Son deneme ise 28 Eylül’de 15:17’de geldi; bu da ilk deneme ile son deneme arasında yaklaşık 42 saat yaptığını gösteriyor.

Kimlik bilgisi doldurma bir sayı oyunudur ve bir NAS giriş sayfası kolay hedeftir

Kimlik bilgisi doldurma, bir giriş sayfasına kullanıcı adı ve parola çiftlerini o birine isele kadar fırlatmak anlamına gelir; genellikle diğer ihlallerden sızan çiftler kullanılır. Kesin konuşmak gerekirse, admin ve marketing gibi genel adları döndürmek parola püskürtmeye daha yakındır, ancak oyun kuralı ve araçlar aynıdır. Botlar yorulmaz ve bir bankaya mı yoksa birinin dolabındaki bir kutuya mı saldırdıklarının hiçbir önemi yoktur.

NAS, genellikle sahibinin önem verdiği her şeyi barındırdığı için iştah açıcı bir hedeftir. DSM’e girerseniz, dosyaları, yedekleri ve çoğu zaman ağın geri kalanına ayak uydurmayı elde edersiniz.

NAS’ımı açığa çıkaran unutulmuş port yönlendirmesi

Atıl bir nginx testi için açılmış bir port 80 yönlendirmesi, testten uzun yaşadı ve doğrudan DSM’e işaret ediyordu

İlk şüphe kaynağım QuickConnect’ti; doğrudan NAS bağlantısı mümkün olmadığında Synology sunucuları üzerinden bağlantıları iletebiliyor ve bu da CGNAT’ın engellemesini önüyor. Bunu kapattım ve Log Center’a baktım, yine de denemeler durmuyordu. eero üzerinde UPnP zaten kapalıydı ve DSM’in Router Configuration sayfasında herhangi bir kural yoktu, dolayısıyla sorun orada da değildi.

Sonra gerçekten arka planda CGNAT olup olmadığını kontrol ettim. Masaüstü bilgisayarımdan tek bir komut işi halletti.

curl -4 ifconfig.me

Aynı halka açık adresi döndürdü; eero’nun WAN IP olarak bildirdiği adres buydu ve CGNAT’ın kullandığı 100.64.0.0/10 aralığının dışında, yani araya giren hiçbir şey dönüştürmüyordu. Sonra telefonumun Wi-Fi’sini kapattım ve bu adresi LTE üzerinden yükledim. Bana bir nginx hata sayfası cevap verdi: “400 Bad Request. Plain HTTP isteği bir HTTPS portuna gönderildi.” Bu DSM’in kendi web sunucusuydu, yani NAS’ım internetle konuşuyordu.

Hata eero uygulamasının içinde, NAS’ın adres rezervasyonunun içinde gizliydi. 80 numaralı portu iletiyordu ve ben onu tamamen alakasız bir şeyi kanıtlamak için hızlı bir nginx test kurulumu için kurmuştum. Test uzun zaman önce gitmişti. İletim gitmemişti.

Bilinçsizce NAS’ımın güvenlik duvarını açmıştım ve onun hakkında her şeyi unuttum. LAN’ım üzerinden NAS’ımı 80 numaralı porttan açarsan, DSM seni doğrudan giriş sayfasına yönlendirir. Yani nginx testi ortadan kalktıktan sonra, bu iletimin ardında duran DSM’di ve Log Center’daki giriş denemeleri botların bunu bulduğunu gösteriyordu. Yaklaşık öğleden sonra 3:16’da sildim ve son başarısız deneme 3:17’de geldi.

DSM’in aynı zamanda hatalı bir kendiliğinden imzalı sertifika’sı da vardı. Bu, bir tarayıcıdaki kişiyi korkuturdu, ancak botlar sertifika uyarılarına bakmaz, dolayısıyla bana hiçbir şey kazandırmadı.

Arka planda CGNAT olduğumu varsaydım ve yanılıyordum

eero’um doğrudan bir Verizon Fios ONT’ye bağlandığı için önünde başka bir yönlendirici yok. eero halka açık adresi kendisi taşır, yani eero üzerinden iletilen her şey doğrudan internete gider. CGNAT, ev sunucusuna gelen bağlantıları sessizce engellediği için, arkasındaki eski 80 numaralı port yönlendirmesi hiçbir yere ulaşamayan bir şeyi işaret ediyordu. Gerçek bir halka açık IPv4 adresiyle bu, canlı bir kapıydı.

Hatımın CGNAT olma özelliğini tam olarak ne zaman kaybettiğini bilmiyorum. Ancak tarayıcılar interneti hızlıca tarıyor: Bir Unit 42 tuzak sunucu (honeypot) çalışmasında, 320 açık tuzak sunucunun %80’i 24 saat içinde ele geçirildi ve hepsi bir hafta içinde. Bu çalışma SSH ve RDP gibi hizmetleri kapsıyordu, bir DSM giriş sayfasını değil, dolayısıyla geçişimin ne zaman yapıldığını tarihlendiremez. Yine de en iyi tahminim, değişikliğin 26 Eylül’den kısa bir süre önce, haftalar önce değil gerçekleştiği yönünde. Log Center, saldırılar başlamadan önceki geçmişe sahip değil, bu yüzden her iki yönde de bir şey ispatlayamıyorum.

DSM’nin Otomatik Engellemesi bunun hiçbirini neden durduramadı

IP adreslerini döndüren saldırganlar, IP başına kilitlenmeyi tetiklemez

DSM’nin Otomatik Engellemesi sürekli açıktı ve temelde hiçbir şey yapmadı. Synology’nin belgelerine göre, belirli bir süre içinde belirli sayıda başarısız giriş denemesini aşan bir IP adresini engeller. Bu, sürekli vuran tek bir gürültülü adrese karşı iyi çalışır.

Bu saldırı böyle çalışmadı. Altı dakikalık tek bir örnekte, dört farklı aralıktan 14 adres sırayla girdi, dolayısıyla her biri muhtemelen eşiğin altında kaldı. Synology ayrıca Otomatik Engellemenin her IP’den gelen ilk birkaç başarısız denemeyi görmezden geldiğini belirtiyor. Otomatik Engellemeyi açık tutmak iyi, ancak bu dağıtılmış bir saldırıya karşı bir savunma değil ve burada bana yardımcı olmadı. Kapıyı kapatmak yaptı.

Sonrasında NAS’ımı nasıl güvenceye aldım

Bir güvenlik duvarı ve daha az açık kapı, zekice çözümlerden beter

İleri düzey kullanıcıyı sistemden uzaklaştırdıktan sonra QuickConnect’i kapattım ve DSM’in güvenlik duvarını açtım. İki kabul kuralı kurdum: biri yerel ağımdaki alt ağım için, diğeri ise Tailscale’in 100.64.0.0/10 aralığı için; ardından geri kalan her şeyi Erişimi reddet olarak ayarladım. Tüm kurulum buydu ve yine beklenenden daha uzun sürdü.

Synology işi kolaylaştırmıyor. Kurallar profillerin içinde yaşiyor, yalnızca Düzenle Kuralları düğmesi aracılığıyla erişilebiliyor ve Uygula‘ya tıklayana kadar hiçbir şey yürürlüğe girmiyor; bu da çok kolay kaçabiliyor. Ardından giriş sayfasının zaman aşımına uğrayıp uğramadığını doğrulamak için telefonundan LTE üzerinden test et.

İki faktörlü doğrulama tüm süre boyunca asıl güvenlik ağıydı

İyi haber, her iki Synology hesabımın da DSM hesabımın da zaten iki faktörlü doğrulamanın açık olmasıydı. Baktığım her deneme şifre aşamasında başarısız oldu, böylece ikinci faktör hiç devreye bile girmedi. Ancak bir bot şifremi tahmin etmiş olsaydı, yine geçemeyeceği bir isteme denk gelirdi.

Bir de bir püf noktası var. Yerel ağdan giriş yaparken “bir daha sorma” kutucuğunu işaretlemiştim, bu da şeyleri zayıflatma ihtimali olan bir şey gibi görünüyor. Ancak öyle değil, çünkü Synology’nin iki faktörlü doğrulama belgeleri, hatırlanan cihazların yalnızca aynı hesaba aynı tarayıcıdan giriş yapıldığında geçerli sayıldığını belirtiyor.

İnternet sağlayıcın bunu sen yapmadan önce port yönlendirmelerini kontrol et

Korkutucu olan kısım NAS’inime saldırılması değil. O yönlendirmeye dokunmamama rağmen, hattım CGNAT arkasında oturmayı bıraktığı anda yine de canlanmasıydı. Zararsız olarak görüp göz ardı ettiğim bir kural, tek bir uyarı bile olmadan canlı bir giriş sayfasına dönüştü.

O yüzden bugün router’ının port yönlendirmelerini kontrol et, benimkisi gibi cihaz rezervasyonlarının içinde gizlenenler de dahil. Ardından telefonundan LTE üzerinden halka açık IP’nizi kontrol edin ve hiçbir şeyin yanıt vermediğini kesinleştirin. NAS’inize dışarıdan erişmeniz gerekiyorsa, QuickConnect’i Tailscale ile değiştirmek sizi hiçbir şeyi ifşa etmeden oraya ulaştırır.