Üç kıtada reklamı yapılmamış sunucular ilk tarayıcıyı 48 saniye içinde çekti

Bir geliştirici üç cloud sunucusu kiraladı — Frankfurt, New York ve Singapur'da — adreslerini kesinlikle kimseye söylemedi ve internetin yine de onları buluşunu izledi. dev.to'daki bir yazıya göre ilk istenmeyen bağlantı, Singapur makinesi açıldıktan 48 saniye sonra geldi. Yaklaşık kırk beş dakikalık süre boyunca üç makine, 860 farklı adresten gelen 3.480 bağlantı denemesi kaydetti; bunların arasında gerçek şifre taşıyan 1.085 oturum açma denemesi de vardı.

Üç tek kullanımlık honeypot

Yazıya göre adresler hiçbir DNS kaydında, sertifikada veya repository'de görünmüyordu; makinelerin varlığını yalnızca cloud sağlayıcılarının kendisi biliyordu. Her makinede, tarayıcıların gerçekten kapısını çaldığı servisleri taklit eden küçük bir Python programı çalışıyordu: 23 portunda telnet, 80 ve 8080 portlarında HTTP, 443 portunda TLS; ayrıca makinenin gerçek SSH'u yönetim için 22 portunu tutabilsin diye 2222 portuna bir SSH honeypot yerleştirilmişti. Her listener bir yemdi — telnet servisi bir Ubuntu giriş prompt'u gösteriyor ve tüm şifreleri reddediyordu, HTTP servisi ise istekleri kaydedip 404 döndürüyordu. Bir tcpdump kaydı her gelen TCP SYN paketini sayıyordu, böylece üzerinde hiçbir şey dinlemeyen portlara yapılan probelar da hesaba katılıyordu. Her bölge yaklaşık 45 dakika çalıştı ve kurulum kendini imha etti; deneyin toplam maliyeti üç sentin altındaydı.

Saat yönlendirilebilirlikten başlar

İlk temas süreleri Singapur'da 48 saniye, Frankfurt'ta 107, New York'ta 324 oldu. Yazarın çıkarımı şu: adres alanı sürekli ve ayrım gözetmeksizin taranıyor, dolayısıyla maruz kalma, bir uygulama deploy edildiğinde veya duyurulduğunda değil, bir IP yönlendirilebilir olduğu anda başlıyor.

Bölgesel ham toplamlar çarpık görünüyor — Frankfurt'ta 2.325 deneme, Singapur'da 516 — ama Korea Telecom ağındaki tek bir host kendi başına Frankfurt'a 1.663 paket gönderdi, neredeyse hepsi telnet'e yönelikti. En yoğun kaynak hariç tutulduğunda bölgeler saatte 829, 759 ve 677 denemede yakınsadı; yazar bunu, her yeni genel IP için saatte kabaca 700 ila 800 istenmeyen bağlantılı bir taban değer, üstüne de ara sıra bir hedefe takıntı kuran bir host olarak okuyor. Kalabalığın kendisi sığdı: 860 kaynak adresin 672'si, yani yaklaşık %78'i, tüm pencere boyunca tam olarak bir paket gönderdi.

Telnet, mail portları ve fabrika varsayılanları

Üç makinedeki bağlantı denemelerine göre sıralandığında en çok istenen portlar şunlardı: 23 (telnet; Korea Telecom hostu sayıldığında baskın konumda — IoT botnetlerinin üzerinde çalışmayı hiç bırakmadığı router, kamera ve DVR bölgesi), 8088 (Hadoop YARN ve çeşitli admin panelleri), 22 (SSH), 587 ve 465 (mail gönderimi; bir New York hostu her birini 50 kez probeladı, bu da henüz kimse tarafından raporlanmamış bir cloud IP'nin spam gönderme değeriyle açıklanıyor) ve 5555, yani Android Debug Bridge portu. HTTP isteklerinin neredeyse tamamı, Host header'ı olmadan kök yola yapılan yalın probelardı — tarayıcılar değil, herhangi bir şeyin cevap verip vermediğine bakan tarayıcı yazılımları.

Telnet yemi, 107 farklı kullanıcı adı ve şifre çiftine yayılan 1.085 şifreli oturum açma denemesi topladı. En sık görülen şifreler şunlardı: annie2015 (43 deneme), OxhlwSG8 (42), S2fGqNFs (40), annie2014 (40), annie2016 (39), motorola (39), tlJwpbo6 (39), 7ujMko0admin (37), epicrouter (34) ve 123456 (33). Yazar, bunların tanıdık Mirai tarzı listeleri izlediğine dikkat çekiyor: 7ujMko0admin bir Dahua kamera arka kapısı, epicrouter bir Conexant DSL varsayılanı, daha aşağı sıralarda olan Zte521 ise bir ZTE router varsayılanı. Eleştirel olan eksiklik — makul insan şifrelerine yönelik neredeyse hiç sözlük denemesi yok. Trafik, bireysel bir hesabı kırmak için değil, seri üretilmiş cihazların fabrika varsayılanlarının makine hızında sayımı. Şifrelerin hiç yakalanabilmesi tek bir ayrıntıya bağlıydı: botlar şifre göndermeden önce sunucunun telnet seçeneklerini müzakere etmesini bekliyor, dolayısıyla yem, kullanıcı adlarından öte bir şey görünmeden önce bu müzakerere gerçek bir daemon gibi cevap vermek zorundaydı.

Ölçüm aracınız size yalan söylediğinde

Yazı iki hatayı da itiraf ediyor. Makinenin gerçek SSH'unu sshd_config dosyasını düzenleyerek 22 portundan taşımak Ubuntu 24.04'te hiçbir işe yaramadı, çünkü systemd socket activation yapılandırmadaki Port satırını yok sayıyor; systemd socket üzerinden düzeltme girişimi makineyi ağdan tamamen kesti ve ikinci deneme de aynı başarısızlığı tekrarladı. Otomatik yıkım (teardown), ölü makinelerin gece boyunca fatura üretmesini engelledi. Ayrı olarak, bir TLS parser hatası — geniş bir exception handler'a sarılı bir IDNA decode — her handshake'te sunucu adı raporlamadı ve neredeyse istemcilerin çıplak bir IP'ye asla SNI göndermediği yönünde yanlış bir bulgu üretiyordu. Çare, sıfıra güvenmeden önce aracın bilinen bir pozitif örnek against test edilmesiydi.

Neden önemli

Deney, savunmacıların genellikle kulaktan kulağa aktardığı bir şeye somut sayılar koyuyor: yönlendirilebilir her adres, çevrimiçi olduğu ilk saniyeden itibaren sürekli probelanıyor; bunu yapanlar da ezici çoğunlukla IoT dönemi protokolleri üzerinden varsayılan kimlik bilgilerini madenleyen otomatik kampanyalar. Pratik sonuçlar kesin — sertleştirme, maruz kalmadan önce gelmeli, sonra değil; hâlâ fabrika varsayılanı kullanan erişilebilir her servis fiilen kilitsizdir; ve yeni kiralanmış, temiz cloud IP'ler bile spam aktarma potansiyeli için avlanıyor. Kendi ölçümünü yapan herkes içinse şu: inandırıcı bir sıfır, sadece bozuk bir alet olabilir — o yüzden bildiğiniz bir çalışanınla doğrulayın.