Telnet'in Sessizliğe Gömüldüğü Gün

 (labs.greynoise.io)
4 puan yazan GN⁺ 2026-02-12 | 1 yorum | WhatsApp'ta paylaş
  • 14 Ocak 2026 saat 21:00'de (UTC) dünya genelindeki Telnet trafiği aniden çöktü; gözlem ağında kalıcı olarak %59 düşüş doğrulandı
  • 18 ASN tamamen sustu ve 5 ülkenin (Zimbabve, Ukrayna, Kanada, Polonya, Mısır) trafiği tamamen ortadan kayboldu
  • Büyük bulut sağlayıcılarında (AWS, Contabo vb.) ise aksine artış görüldü; buna karşılık Kuzey Amerika'daki ISP'lerde büyük çaplı düşüş yaşandı
  • 6 gün sonra GNU Inetutils telnetd kimlik doğrulama atlatma zafiyeti (CVE-2026-24061) açıklandı; bunun root yetkisi elde etmeye imkân veren kritik bir açık olduğu doğrulandı
  • Sektör, omurga seviyesinde port 23 filtrelemesinin önceden yapılan bildirim üzerine alınmış bir önlem olabileceğine dikkat çekiyor ve bunu Telnet'in sonunu simgeleyen bir olay olarak değerlendiriyor

Dünya genelinde Telnet trafiği çöktü

  • 14 Ocak 2026 saat 21:00'de (UTC), GreyNoise Global Observation Grid Telnet trafiğinde ani bir çöküş tespit etti
    • Yaklaşık 74.000 oturum olan seviye bir saat sonra 22.000 oturuma inerek %65 düştü
    • İki saat sonra ise %83 azalarak 11.000 oturum seviyesine geriledi ve burada kaldı
  • Aralık 2025 ile Ocak 2026'nın başı arasındaki günlük ortalama 910 bin oturum seviyesine kıyasla, sonrasında 370 bin seviyesine inerek %59 azaldı
  • Değişim, kademeli bir gerileme değil, tek bir anda yaşanan keskin bir kopuştu (step function tipi değişim); bu da yönlendirme altyapısı yapılandırmasında değişiklik ihtimaline işaret ediyor

Sessizliğe bürünen ağlar ve ülkeler

  • 18 ASN, 15 Ocak'tan sonra Telnet trafiğinde 0 seviyesine geçti
    • Vultr (AS20473) 380 bin → 0, Cox Communications (AS22773) 150 bin → 0
    • Charter/Spectrum (AS20115), BT/British Telecom (AS2856) da bunlar arasında
  • 5 ülkenin (Zimbabve, Ukrayna, Kanada, Polonya, Mısır) trafiği tamamen ortadan kayboldu
  • Buna karşılık AWS %78 arttı, Contabo %90 arttı, DigitalOcean ise +%3 ile korundu
    • Bulut sağlayıcıları, özel peering ağları üzerinden omurga filtrelemesinin etkisinden kaçındı

Port 23 filtreleme ihtimali

  • Desene bakıldığında, Kuzey Amerika'daki Tier 1 transit sağlayıcılarının port 23 filtrelemesi uyguladığına dair işaretler var
    • Zamanlama ABD Doğu saatiyle 16:00'ya denk geliyor; bu da ABD'deki bakım saatleriyle örtüşüyor
    • Cox, Charter, Comcast (-%74) gibi ABD'li ISP'ler ağır darbe aldı
    • Verizon/UUNET (AS701) %79 düştü; büyük bir omurga sağlayıcısı olarak filtrelemeyi yapan taraf ya da üst rota olabilir
  • Doğrudan Avrupa peering'ine sahip ülkelerde (Fransa +%18, Almanya -%1) etki sınırlı kaldı
  • Çinli operatörlerde (China Telecom, China Unicom) de her ikisinde %59 düşüş görüldü
    • Eşit düşüş oranı, ABD tarafındaki Pasifik aşırı bağlantılarda filtreleme ihtimaline işaret ediyor

CVE-2026-24061 zafiyetinin açıklanması

  • GNU Inetutils telnetd'de kimlik doğrulama atlatma zafiyeti, CVSS 9.8 seviyesinde
    • USER ortam değişkeni işlenirken argüman enjeksiyonu ile -f root geçirilirse, kimlik doğrulaması olmadan root shell elde etmek mümkün
    • 2015 tarihli bir commit ile eklenmiş ve yaklaşık 11 yıl boyunca fark edilmemiş
  • Başlıca tarihler
    • 14 Ocak: Telnet trafiğindeki çöküş başladı
    • 20 Ocak: CVE açıklandı
    • 21 Ocak: NVD kaydı yapıldı ve ilk kötüye kullanım gözlendi
    • 26 Ocak: CISA KEV listesine eklendi
  • Trafik çöküşünün CVE açıklanmadan 6 gün önce başlamış olması, basit bir rastlantıdan fazlası olabilecek bir ilişki ihtimalini gündeme getiriyor

Ön bildirim ve altyapı tepkisi hipotezi

  • Zafiyeti bildiren kişinin Kyu Neushwaistein / Carlos Cortes Alvarez olduğu ve bildirimin 19 Ocak'ta yapıldığı belirtiliyor
  • Yama hazırlığı ve CISA yanıtının açıklamadan bir gün sonra gerçekleşmiş olması, önceden koordinasyon ihtimalini düşündürüyor
  • GreyNoise şu senaryoyu öne sürüyor
    • Büyük altyapı operatörleri önceden bilgilendirilip port 23 filtrelemesini proaktif olarak uygulamış olabilir
    • 14 Ocak'ta filtreleme devreye alındı → 20 Ocak'ta açıklama yapıldı → 26 Ocak'ta CISA kaydı geldi
  • Bunu doğrulayan net bir kanıt yok; bunun yalnızca zamanlamaya dayalı bir çakışma olabileceği de belirtiliyor

Sonrasındaki Telnet trafiği deseni

  • 14 Ocak sonrasında testere dişi bir desen sürdü
    • Örnek: 28 Ocak'ta 800 bin oturum → 30 Ocak'ta 190 bin oturum
    • Aralıklı filtreleme, yönlendirme değişiklikleri veya belirli tarayıcı kampanyaları mümkün
  • Haftalık ortalamalar
    • 19 Ocak haftası: 360 bin oturum (baz seviyenin %40'ı)
    • 2 Şubat haftası: 320 bin oturum (baz seviyenin %35'i)
  • Baz seviyenin yaklaşık üçte birinde dengelendi ve düşüş eğilimi devam ediyor

Güvenlik ve operasyon açısından çıkarımlar

  • GNU Inetutils telnetd kullanıcılarının derhâl 2.7-2 veya üstüne güncellemesi ya da hizmeti devre dışı bırakması gerekiyor
    • CISA, 16 Şubat 2026'ya kadar federal kurumlar için yama süresi verdi
    • Açıklamadan hemen sonra birkaç saat içinde kötüye kullanım girişimleri gözlendi; Şubat başında günlük 2.600 oturuma kadar çıkıp sonra düştü
  • Ağ operatörlerinin port 23 filtrelemesini değerlendirmesi gerekiyor
    • Omurga seviyesinde filtreleme zaten ilerliyor ve Telnet trafiği artık değeri kalmamış bir protokol olarak görülüyor
  • GreyNoise, “birilerinin internetin önemli bir bölümünde Telnet'i kestiğini” kayda geçiriyor ve bunu
    Telnet çağının sonunu simgeleyen bir olay olarak değerlendiriyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-12
Hacker News görüşleri

  • telnetd'den daha ciddi olan şey, Tier 1 transit sağlayıcılarının port filtrelemeye başlamış olması
    Bu, internetin parçalanması demek ve artık otomatik yönlendirmeyle (BGP) bile etrafından dolaşılamayan bir yapıya dönüşmüş durumda

    • Eskiden küçük bir ISP'de çalışırken Blaster solucanı patlamıştı; 139 gibi portları engellemek en hızlı müdahaleydi
      O zaman çoğu ISP portları kapattı ve sonuçta ortam daha güvenli hale geldi
      Eğer gerçekten telnet gerekiyorsa başka bir porta taşınabilir ya da tünellenebilir
      Hâlâ varsayılan 23 portunda telnet çalıştıran var mı, merak ediyorum
    • Sansür riski bir mesele ama hastane, banka, nükleer gibi sistemlerin hacklenip insan hayatını tehlikeye atması da ciddi bir sorun
      Bu kararları verenler aynı anda hem yetkiyi hem sorumluluğu taşıyor
    • 23 numaralı port zaten onlarca yıldır çoğu sağlayıcı tarafından filtreleniyordu
      Bu yüzden her şey TLS 443 portuna yığılıyor
      Buna sansür diye bağırmanın anlamı yok; gerçek sansürü FOSTA/SESTA gibi yasalarda aramak gerekir
    • Port engellemenin sonuçta sansürden farkı olmadığını düşünüyorum
    • Spectrum ISP üzerinden GNU telnet istemcisiyle Seattle'daki ve Hollanda'daki sunuculara bağlanabildim

  • Gerçekten şaşırtıcı bir bug
    İnternetin ilk 10 yılı neredeyse tamamen telnet kullanılan bir dönemdi
    O zaman Ethernet trafiğine bakınca parolalar düz metin olarak görünüyordu ve çoğu sistem çok kullanıcılı ortamlardı
    telnet -l 'root -f' server.test gibi bir komutun 11 yıl boyunca hayatta kalmış olmasına inanmak zor

    • Yazılım işinde ne kadar uzun süre kalırsam, dünyanın bu şekilde çalışıyor olması bana o kadar tuhaf geliyor
      Muhtemelen hâlâ dalından koparılması kolay meyve türü çok sayıda zafiyet vardır
    • Root olarak giriş yapmıyordum ama okul AIX hesabımla lynx üzerinden web'de gezindiğim zamanlar oldu
      O zaman trafiğin izlendiğini hiç düşünmüyorduk; daha özgür bir dönemdi
      Telnet ile posta (pine), web (lynx), hatta IRC bile kullanıyordum
    • Telnet kullanmayı ne zaman bıraktığımı bile hatırlamıyorum
      Bir sürü sunucu root telnet erişimine açıktı ama hiçbiri hacklenmedi
      Gerçekten o günleri özlüyorum
    • Eskiden rlogin -l '-froot' gibi zafiyetler de vardı, onu hatırladım
      O dönemde bunlar yaygındı
    • Giriş için kullanmıyordum ama debug aracı olarak hâlâ faydalıydı
      Konteynerler arası trafiğin geçip geçmediğini kontrol ederken sık kullanıyordum

  • Telnet istemcisinin kendisi henüz ölmedi
    Eskiden SMTP sunucularına (25 portu) telnet ile bağlanıp spoof edilmiş e-postalar gönderirdik
    Ama güvenlik gerekçesiyle port engellemeleri arttıkça sonunda tüm servislerin 443 portuna yığılacağını düşünüyorum

    • Bugünlerde netcat, socat, openssl s_client gibi araçlar çok daha iyi alternatifler
      Telnet'ten çok daha güçlüler
    • Küçükken telnet ile SMS gönderdiğim olmuştu
      Alıcıya resmi operatör hesabından gelmiş gibi görünüyordu; o zaman masumdu ama şimdi düşününce tehlikeli bir şakaymış
    • Telnet istemcisi ya da telnetd hâlâ kullanılabilir
      Sadece küresel yönlendirme düzeyinde varsayılan port engellenmiş gibi görünüyor
      Güvenliği olmayan eski sistemleri korumaya yönelik bir önlem gibi duruyor

  • Hâlâ telnet'in internette neden kullanıldığını anlamıyorum
    Trafiğin çoğu saldırı trafiği değil mi?

    • Bazıları tarihî sistemleri korumak için çalıştırıyor
    • Aslında ASCII Star Wars izlemek için
      telnet towel.blinkenlights.nl
      YouTube video bağlantısı
    • Legacy, IoT ve endüstriyel ekipmanlarda telnet hâlâ kullanılıyor
      SSH bile pratikte çoğu zaman gevşek güvenlikle kullanılıyor
      Örneğin host key doğrulaması kapatılıyor ya da parolasız anahtarlar kullanılıyor
      Bu yüzden pratikte telnet + HTTPS websocket + OAuth birleşimi daha güvenli bile olabilir
    • Amatör telsizde (HAM) şifreleme yasak olduğu için telnet kullanılıyor
      Bunun yerine imzalı veri aktarımına izin verildiğinden, böyle alternatif bir protokol gerekiyor
    • MUD ve MOO gibi metin tabanlı oyun sunucularının çoğu hâlâ telnet kullanıyor

  • Bu CVE, gömülü cihaz hackleme topluluğu için iyi haber
    telnetd açık olan cihazlarda root yetkisi alma ihtimali büyüdü

    • Doğrudan bir Zyxel WiFi AP üzerinde denedim; busybox tabanlı telnetd kullandığı için muhtemelen etkilenmiyordu

  • Söz konusu CVE, bu commit'ten kaynaklanıyor
    Ana nokta user_name'in uname olarak değiştirilmesi; böyle bir isim değişikliğinin neden gerekli olduğunu merak etmiştim

    • ChangeLog'a bakınca, user_name adının global değişkenle isim çakışması (shadowing) yarattığı için değiştirildiği anlaşılıyor
    • Ama bence böyle bir düzeltmeden daha önemli olan şey getenv() çağrılarını gözden geçirmek
      Çünkü girdi ayrıştırma zordur ve bu yüzden sık sık zafiyet çıkar

  • İnternet transit altyapısının üst katmanlarında birilerinin telnet trafiğini düşürmeye karar vermiş olması ilginç
    Muhtemelen doğru karar da olabilir
    Bunun MUD trafiğini etkileyip etkilemeyeceğini merak ediyorum

    • MUD'ların çoğu Telnet protokolünü doğrudan kullanmaz
      Basit TCP tabanlıdırlar ve özel istemciler tercih edilir
      23 numaralı port IANA tarafından Telnet için ayrılmıştır ama MUD'lar genelde yüksek dört haneli portlar kullanır
      Hatta bugün 23 numaralı portta çalıştırılırsa erişmek daha zor olurdu
    • Yazıda açıkça söylenmiyor ama muhtemelen sadece saldırı trafiği filtreleniyor
      Telnet düz metin olduğu için örüntü analizi ile kolayca ayırt edilebilir
    • Muhtemelen SMTP port engellemesi gibi port tabanlı bir blok söz konusu
      Bugünlerde açık ağda duran bir sunucuysa SSH kullanılması gerekir

  • Bu CVE ve buna verilen tepki gerçekten tarihî bir olay
    Tek bir kişinin fiilen telnet çağını bitirmiş olmasına inanmak zor

    • Aslında PR'ı açan ve onaylayan iki kişi vardı
      Güvenlik araştırmacısının suçu değil

  • Stajyerken masamdaki VoIP telefona telnet ile bağlanılabildiğini fark ettiğimde gerçekten büyülenmiştim

    • Ben de stajyerken Perl CGI script'lerini telnet ile test ederdim
      Hayes komutlarına alışık olduğum için HTTP isteklerini elle yazmak doğal geliyordu
    • Ben de öyleydim, eğlenceli bir anı

  • Yakın zamanda telnet sunucumun istatistiklerine baktım; ortalama 2000 IP bağlanıyor
    Ocak ortasında sayı 7500'e kadar sıçradı, sonra tekrar düştü; Şubat'ta ise 1000 seviyesine indi