Telnet Nedir? Şifresiz Yönetim Protokolü ve Riskleri

Telnet, bir cihaza ağ üzerinden komut satırı erişimi veren ilk protokollerden biridir ve bugün hâlâ sahada açık bulunur. Sorun ne yaptığında değil, nasıl yaptığındadır: kullanıcı adını ve parolayı ağda düz metin olarak taşır. Bu yazı protokolün nasıl çalıştığını ve ne işe yaradığını anlatıyor, ama tanımla bırakmıyor. Gerçek bir yönetilebilir switch’e Telnet ile bağlanıp aynı girişi paket düzeyinde yakaladık: ekranda parola yıldızlarla gizleniyor, kabloda olduğu gibi okunuyor. Aşağıda o dökümü, aynı girişin SSH ile alınmış halini ve açık bulduğunuz bir cihazda ne yapmanız gerektiğini bulacaksınız.

Telnet Nedir ve Nasıl Çalışır?

Telnet, uzaktaki bir cihazın komut satırını kendi ekranınıza getiren bir protokoldür. Kökleri ARPANET’in ilk yıllarına uzanır, yani internetin kendisiyle yaşıttır; bugün hâlâ geçerli olan tanımı ise RFC 854 ile 1983’te yazılmış ve protokolü “iki yönlü, sekiz bitlik bayt yönelimli bir iletişim olanağı” diye tarif ediyor. Tasarlandığı dünyada ağa bağlı makineler birbirini tanıyan kurumların elindeydi ve kimsenin dinlemediği varsayımı makuldü.

Bir telsiz düşünün. Mikrofonun düğmesine basıp konuşursunuz, sesiniz karşı istasyona gider ve iş görülür. Ama kanal açıktır: aynı frekansta duran herkes, siz farkında olmadan, söylediğiniz her şeyi duyar. Telnet tam olarak budur. Cihazla konuşursunuz, iş görülür, ve konuşmanın kendisi havada durur. Bu yazının tamamı o açık kanal üzerine: kimlerin duyduğu, kanalı nasıl kapatacağınız, ve kapatırken kendinizi nasıl dışarıda bırakmayacağınız.

Teknik olarak Telnet, TCP üzerinde çift yönlü bir karakter akışıdır. Yazdığınız her tuş karşıya gider, cihazın ürettiği her karakter size döner. Arada şifreleme yoktur, sıkıştırma yoktur, kimlik doğrulama katmanı da yoktur; kimlik doğrulama karşıdaki cihazın kendi işidir ve Telnet yalnızca harfleri taşır.

Yaygın olarak “Telnet şifreleme bilmez” denir ve bu tam doğru değil. Protokolün bir şifreleme uzantısı var: RFC 2946, ENCRYPT seçeneği. Üstelik modern istemciler bağlantının başında onu teklif ediyor. Lab ortamımızdaki yönetilebilir switch’e bağlanırken alınan ilk pakette istemci açıkça DO ENCRYPT ve WILL ENCRYPT gönderiyor. Cihazın cevabı ise tek kelime:

03:16:12.238480 IP 192.168.1.15.46158 > 192.168.1.2.23: Flags [P.], length 30
  [telnet DO ENCRYPT, WILL ENCRYPT, DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, ...]
03:16:12.036348 IP 192.168.1.2.23 > 192.168.1.15.46158: Flags [P.], length 3
  [telnet WONT ENCRYPT]

WONT ENCRYPT, yani “şifrelemeyeceğim”. Sorun protokolün yapamaması değil, tarafların yapmaması.

Uzantının tarihi bu ilgisizliği zaten açıklıyor. Temel protokol 1983’te yazılmış, şifreleme seçeneği ise 2000 yılında, on yedi yıl sonra eklenmiş. O tarihe gelindiğinde SSH çoktan vardı ve şifreli yönetim ihtiyacını baştan tasarlanmış bir protokolle karşılıyordu; sonradan iliştirilen bir seçeneğin yaygınlaşması için sebep kalmamıştı. Pratik sonucu şu: karşınıza “şifreli Telnet” diye bir çözüm çıkarsa, onun neden hiçbir yerde varsayılan olmadığını sormanız gerekir.

Port 23: Bağlantı Nasıl Kurulur?

Telnet TCP’nin 23 numaralı portunu kullanır ve bu numara keyfi değil: 0-1023 aralığındaki iyi bilinen portlardan biridir, yani IANA tarafından tahsis edilmiş ve onlarca yıldır değişmemiştir. Bu aralığın pratik bir sonucu daha var: Unix türevi sistemlerde yalnızca ayrıcalıklı bir süreç bu portlarda dinleyebilir.

Sahada işinize yarayacak yanı şu: 23 numaralı portun açık görünmesi neredeyse tek anlama gelir. Başka hiçbir yaygın servis orayı kullanmaz, dolayısıyla bir tarama sonucunda ya da güvenlik duvarı kaydında karşınıza çıkan açık bir 23, yorum gerektirmeyen bir bulgudur. Bu, aşağıdaki tarama bölümünün de dayandığı nokta.

Bağlantı sıradan bir TCP el sıkışmasıyla başlar, ardından iki taraf seçenek anlaşması yapar: kim satır kipinde çalışacak, terminal tipi ne, pencere boyutu kaç, ekoyu kim basacak. Bu anlaşma yukarıdaki dökümde gördüğünüz DO, WILL, DONT, WONT sözcükleriyle yürür ve saniyenin küçük bir kesrinde biter.

Anlaşma bittiğinde cihaz giriş istemini gönderir ve o andan itibaren bağlantı düz bir karakter borusudur.

Bu bölümde bir ayrıntı, ölçerken karşıma çıktığı için buraya giriyor. Telnet istemcisi gerçek bir terminal ister. Girişi bir betikten borulayarak otomatikleştirmeye çalıştığımda oturum kurulduktan sonra otuz iki milisaniyede kapandı; istemci seçenek anlaşmasını gönderip hemen bağlantıyı sonlandırdı. Paket dökümünde bu net görünüyor: 30 baytlık anlaşma paketinin hemen ardından FIN geliyor. Çözüm istemciye sözde terminal vermek oldu (script ya da expect ile). Cihaz yapılandırmasını betikle otomatikleştiren herkesin er geç çarpacağı bir duvar bu, ve belirtisi “bağlanamıyorum” değil “bağlandı ve hemen düştü” olduğu için ilk bakışta ağ sorunu gibi görünüyor.

Telnet Komutuyla Port Testi: Protokol Değil, Araç

Bugün telnet yazan çoğu sistem yöneticisi aslında bir cihaz yönetmiyor. Bambaşka bir şey soruyor: şu porta ulaşabiliyor muyum?

telnet mail.sirket.local 25

Cevap üç şekilde gelir ve üçü ayrı şey söyler:

• Ekran temizlenir ya da karşınıza bir karşılama satırı gelir. Port açık, karşı taraf dinliyor ve bağlantı kuruldu.
• Connection refused. Adrese ulaştınız, makine oradaydı, ama o portta dinleyen bir şey yok. Bu iyi haberdir: ağ yolu çalışıyor demektir, sorun servistedir.
• Uzun bir bekleyiş ve zaman aşımı. Cevap veren olmadı. Genellikle araya giren bir güvenlik duvarı sessizce paketi düşürüyordur, ya da adres hiç ayakta değildir.

İkinci ile üçüncü arasındaki fark, arıza aramanın en çok zaman kazandıran ayrımlarından biri. Reddedilen bir bağlantı sizi servise, zaman aşımına uğrayan bir bağlantı ise ağa ve güvenlik duvarına yönlendirir.

İşin ilginci, bunu yaparken Telnet protokolünü konuşuyor bile değilsiniz. İstemci yalnızca ham bir TCP bağlantısı açıyor ve yazdıklarınızı olduğu gibi karşıya geçiriyor. Karşı taraf 25 numaralı portta bir posta sunucusuysa, o SMTP konuşur; siz de klavyeden SMTP yazarsınız. Telnet burada bir protokol değil, çıplak bir kablo.

Windows’ta bu istemci varsayılan olarak kurulu gelmez, isteğe bağlı özellik olarak eklenir. Aynı işi kurulum gerektirmeden yapmak isterseniz PowerShell’in kendi aracı da var:

Test-NetConnection mail.sirket.local -Port 25

Buradan makalenin asıl konusuna geçelim, çünkü aradaki ayrım tam olarak burada duruyor. Emekliye ayrılması gereken şey telnet aracı değil, Telnet protokolü. Araç bir teşhis aleti olarak kalabilir; protokol ise bir cihazı gerçekten yönetmek için kullanıldığında ne oluyor, şimdi ona bakalım.

Parola Neden Düz Metin Gider?

Şimdi asıl mesele. Aşağıdaki iki kutu, aynı saniyenin iki farklı görüntüsü.

Birincisi, ekranda ne gördüğünüz. Lab switch’ine Telnet ile bağlanıp giriş yaptığımızda oturum kaydı şöyle:

User:serce-telnet
Password:**********
console>

Parola yıldızlarla maskeli. Omzunuzun üstünden bakan biri onu okuyamaz ve bu, korunduğunuz hissini veren şeydir.

İkincisi, aynı anda kablonun üstünde ne olduğu. Aynı girişin tcpdump ile alınmış dökümünde, istemciden cihaza giden pakette:

03:16:12.240684 IP 192.168.1.15.46158 > 192.168.1.2.23: Flags [P.], length 34
E..V.n@.@."..........N..;6.....p....6{.....
+.l.....serce-telnet
...Telnet123!
exit

Kullanıcı adı ve parola, hiçbir çözümleme gerektirmeden, olduğu gibi okunuyor. Ekranda gizlenen tek şey ekranda gördüğünüzdü.

Dürüst bir not: bu yakalamada üç satır tek pakete sığdı, çünkü girişi otomasyonla gönderdim ve karakterler tamponda biriktikten sonra hep birlikte çıktı. Klavyeyle yazdığınız gerçek bir oturumda Telnet karakter kipinde çalışır ve her tuş vuruşu ayrı bir pakete düşer. Bu, parolayı daha güvenli yapmaz; yalnızca dökümü okurken harfleri sırayla birleştirmeniz gerekir, ki bunu her paket çözümleyicisi zaten kendiliğinden yapar.

”Aynı ağdaki herkes okur” cümlesi eksik

Bu konudaki rehberlerin neredeyse tamamı “aynı ağdaki herkes parolanızı görebilir” der. Cümle niyetini anlatıyor ama modern bir ağda olduğu gibi doğru değil, ve yanlış tarafı işinize yarayabilecek bir bilgiyi gizliyor.

Anahtarlamalı bir ağda switch, her çerçeveyi yalnızca hedef portuna gönderir. Yani rastgele bir masaüstünde oturan biri, komşusunun trafiğini kendiliğinden görmez. Parolayı okuyabilmek için saldırganın trafiğin geçtiği yolda olması gerekir ve bunun gerçekçi yolları şunlardır: yönetim trafiğinin kullanıcı ağıyla aynı yerden akması, cihazda yapılandırılmış bir port yansıtması, ağın kablosuz bir bölümünden geçmesi, ya da doğrudan uçlardan birinin ele geçirilmiş olması.

Sonuncusu en sık olanıdır ve tam da bu yüzden risk azalmaz. Saldırgan ağı dinlemek zorunda değildir; yöneticinin bilgisayarında olması yeterlidir. Aynı mantığı LDAP ve HTTP tarafında da ölçtük, üçünde de soru aynı: bu kimlik nereden geçiyor ve yolda kim durabiliyor?

Dosya aktarımı tarafında ise kayıp bir adım daha ileri gidiyor. FTP ile yaptığımız aynı ölçümde yalnız parola değil, aktarılan dosyanın içeriği de düz metin okundu. Buradaki fark önemli: Telnet’te parolasını kaptıran kişi erişimini kaybeder ve parolayı değiştirerek kapıyı kapatabilir, aktarılan dosyayı kaptıran kişi ise veriyi kaybeder ve onu geri alamaz.

Telnet ve SSH Arasındaki Fark

Farkı tartışmak yerine ölçtük. Aynı switch, aynı hesap, aynı parola, aynı ağ. Değişen tek şey protokol. Önce Telnet ile giriş yapılıp yakalandı, sonra SSH ile. Ardından her iki dökümde de aynı iki dizge arandı:

grep -ac "Telnet123!"  telnet-giris.pcap    # 1
grep -ac "serce-telnet" telnet-giris.pcap   # 1

grep -ac "Telnet123!"  ssh-giris.pcap       # 0
grep -ac "serce-telnet" ssh-giris.pcap      # 0

Telnet dökümünde ikisi de var, SSH dökümünde ikisi de yok. Ama asıl fark arama sonucunda değil, dökümün kendisinde görünüyor. Yukarıda Telnet paketinde kullanıcı adını ve parolayı okumuştunuz; aynı cihaza, aynı hesapla yapılan SSH girişinde istemciden çıkan paket şöyle görünüyor:

03:20:45.550885 IP 192.168.1.15.46766 > 192.168.1.2.22: Flags [P.], length 44
E..`.@@.@...........................FA.....
+..>.....Jf0. I...-.).Lz1..'..@.5.,	...oa.x.&. .....

Burada arayacağınız bir şey yok. Görünen baytlar bozuk bir metin değil, şifrelenmiş yükün kendisi. Ve şifrelemenin gizlediği şey yalnız içerik de değil: anahtarı olmayan biri için bu dizinin bir parola mı, bir komut mu, yoksa tek bir tuş vuruşu mu taşıdığı belli değildir. Telnet dökümünde ise satırın nerede bittiği bile okunuyordu.

Şifreleme en görünür fark ama tek fark değil. SSH ayrıca cihazın kimliğini doğrular: ilk bağlantıda sunucunun anahtar parmak izini kaydeder ve sonraki bağlantılarda değişip değişmediğine bakar. Telnet’te böyle bir kontrol yoktur, yani doğru adrese bağlandığınızı varsaymaktan başka yapabileceğiniz bir şey yoktur. Üstüne SSH, parola yerine anahtarla kimlik doğrulamayı destekler; parolayı hiç yazmazsanız çalınacak bir parola da kalmaz.

Telnet Hâlâ Nerelerde Açık Bulunur?

Bu protokolün emekli olması gerektiğini herkes biliyor, ama saha başka türlü çalışıyor. Telnet, bir kez yapılandırılıp bir daha dokunulmamış cihazlarda yaşamaya devam ediyor: yönetilebilir switch’ler, konsol sunucuları, kesintisiz güç kaynakları, endüstriyel denetleyiciler, eski IP kameralar.

Lab ortamımızdaki yönetilebilir switch bunun iyi bir örneği. Cihazda Telnet sunucusu kapalı, ama kimlik doğrulama listelerinde Telnet hâlâ tanımlı bir giriş yolu olarak duruyor; yani üretici onu kaldırmamış, yalnızca kapalı gelmesini sağlamış. Bir sonraki sürümde değil, bir sonraki yapılandırma hatasında geri gelebilecek kadar yakın duruyor.

Ben işe yeni başladığım bir yerde tüm switch’lerde Telnet açık buldum. Ortam devralınmıştı ve devralınan ortamların ortak özelliği budur: kimse kötü niyetli değildir, sadece kimse geri dönüp kapatmamıştır. Sahada stajyerin ya da işe yeni başlamış birinin yarım bıraktığı yapılandırmaya çok rastlıyorum; deneyimli olan ya kurumdan ayrılmış oluyor, ya da bu tür şeyler kurumun gündeminde hiç yer bulmuyor.

İkinci bir hikayeyi de aktarayım ama kaynağını açıkça belirterek: bir ISP geçişinde lokasyona yeni hattın yönlendiricisini takan bir saha elemanı, gittiği bir kurumda Telnet bağlantısı yüzünden ciddi zarar oluştuğunu anlatmıştı. Ayrıntısını doğrulayamadığım için buradaki nedensel zinciri iddia etmiyorum; aktarıyorum, çünkü bu tür hikayelerin sahada dolaşıyor olması başlı başına bir gösterge.

Kendi gördüğüm ise şu. Kendi şirketimde, işim olmadığı halde bir personelin ricası üzerine yardım masasına destek olmaya gitmiştim. Çalıştır kutusunu açıp basit bir teşhis yapayım derken, kutunun geçmişinde kullanıcının indirdiği bir dosya yüzünden bırakılmış zararlı bir PowerShell komutu buldum. Bizim çalıştırma ilkemiz o komuta izin vermiyordu ve bir şey olmadı. Ama o an anlaşılan şey şuydu: saldırı gürültülü değil, sessiz ve sabırlı olabiliyor ve tam olarak yöneticinin oturduğu yerden ilerlemeyi bekliyor.

Bu, konuyu doğrudan yönetim disiplinine bağlıyor. Böyle bir makinede kullanıcı bir yükseltme penceresiyle karşılaştığında oraya kendi domain yönetici hesabınızı yazmamanızın sebebi tam budur; o kimlik artık o makineden geçmiştir. Yönetimi kullanıcı makinelerinden ve sunucudan ayrı tutmanın nasıl kurulduğunu RSAT ve yönetim konsolları rehberimizde ele aldık. Telnet’i kapatmak o disiplinin ağ cihazları tarafındaki karşılığıdır.

Ağınızda Açık Telnet Nasıl Bulunur?

“Telnet’i kapatın” tavsiyesinin pratikte tökezlediği yer şu: çoğu kurum onun nerede açık olduğunu bilmiyor. Envanterde görünmeyen bir konsol sunucusu, kimsenin dokunmadığı bir kesintisiz güç kaynağı, depoda unutulmuş bir switch. Kapatmadan önce bulmak gerekiyor.

En basit yol tek bir portu taramaktır ve bunun için özel bir araç kurmanız da gerekmez. Aşağıdaki döngü, hiçbir paket kurulumu istemeden çalışır:

for i in $(seq 1 60); do
  ip="192.168.1.$i"
  timeout 1 bash -c "echo > /dev/tcp/$ip/23" 2>/dev/null && echo "$ip  23/tcp ACIK"
done

nmap kurabiliyorsanız aynı işi nmap -p 23 --open 192.168.1.0/24 ile daha hızlı yaparsınız. Yöntem önemli değil, disiplin önemli: yalnızca kendi sorumluluğunuzdaki adres aralıklarını tarayın ve taramayı yönetim ağınızdan çalıştırın.

Lab ortamımızda bu taramayı Telnet’i kapattıktan sonra çalıştırdığımızda sonuç boş döndü, aynı aralıkta 22 sorulduğunda ise beklenen iki cihaz göründü:

=== PORT 23 TARAMASI ===
--- tarama bitti ---
=== KARSILASTIRMA: ayni aralikta 22 ===
192.168.1.2   22/tcp ACIK
192.168.1.15  22/tcp ACIK

Bu, taramanın “hiçbir şey bulamadı” hali. Aynı komut yakalamayı aldığımız sırada çalıştırılsaydı 192.168.1.2 port 23 ile listede olurdu. Taramanın değeri bulduğunda değil, düzenli tekrarlandığında ortaya çıkar: bir cihaz değiştirildiğinde ya da fabrika ayarlarına döndürüldüğünde Telnet çoğu markada kendiliğinden geri gelir.

SSH’a Geçiş: Cihaz Tarafında Ne Yapılır?

Telnet’i kapatmadan önce yerine geçecek şeyin çalışıyor olması gerekiyor. Cihaz tarafında bu üç adımdır ve sırası önemlidir.

Birincisi anahtar üretimi. SSH sunucusu, kendini istemciye tanıtacak bir ana bilgisayar anahtarı olmadan çalışmaz. Lab switch’inde bu komutun kabul ettiği iki tür var:

console(config)#crypto key generate ?
dsa                      Generate DSA key pairs.
rsa                      Generate RSA key pairs.

RSA üretin. DSA bu cihazlarda tarihsel bir kalıntıdır ve modern istemciler onu zaten reddeder.

Burada ürettiğiniz şeyin ne olduğu sık karıştırılır: bu, cihazın kendi kimliğidir, sizin giriş anahtarınız değil. Cihaz özel anahtarını hiç dışarı vermeden imza atar, istemci de açık anahtarla o imzayı doğrular ve “bağlandığım şey gerçekten bu cihaz mı” sorusunu cevaplar. Telnet’te bu sorunun cevabı yoktur. Açık ve özel anahtarın neden bu şekilde çalıştığını, imzanın neden taklit edilemediğini sertifika otoritesi yazımızın anahtar çifti bölümünde ele aldık; aynı matematik burada da geçerli, yalnız ortada bir sertifika otoritesi yok, cihaz kendi kefili.

İkincisi servisi açmak. Aynı cihazda SSH ayarlarının tamamı tek bir dal altında toplanıyor:

console(config)#ip ssh ?
port                     Specify the port to be used by the SSH server.
protocol                 Configure SSH protocol level (version).
pubkey-auth              To enable public key authentication for incoming SSH sessions.
server                   Enable the device to be accessed via SSH.

Üçüncüsü, ve en çok atlanan: sürümü sınırlamak. Servisi açtınız, anahtarı ürettiniz, giriş de çalışıyor. Peki cihaz hangi protokol sürümlerini kabul ediyor? Lab switch’ine bunu sorduğumuzda, kriptografik olarak kırık kabul edilen SSH Version 1’in hâlâ kabul edildiğini ve üstelik anahtar tabanlı kimlik doğrulamanın kapalı olduğunu gördük. Kimse bunları açmamıştı; varsayılan öyle geliyordu.

Bu, makalenin sınırını da çiziyor. Telnet’i kapatmak bu yazının konusu ve orada iş biter; ama SSH’ı açmakla SSH’ı güvenli kılmak aynı şey değildir. Kabul edilen sürümü yalnız SSH Version 2 ile sınırlamak, parola yerine anahtara geçmek, ana bilgisayar anahtarının parmak izini doğrulamak ve oturum zaman aşımını ayarlamak ayrı bir konudur; hepsini SSH rehberimizde ele alıyoruz. Linux sunucularda aynı geçişin nasıl yapıldığını, yani sshd_config üzerinden parolayla girişi kapatıp kullanıcının açık anahtarını tanıtmayı Ubuntu Server rehberimizin anahtar tabanlı kimlik doğrulama bölümünde ele aldık.

Buradaki asıl mesaj şu: Telnet’i kapattığınızda bir şeyi bitirmiş olursunuz, her şeyi değil.

Kapatma ve Geçiş: Sahada Ne Yapılmalı?

Şimdi işin en çok zarar veren kısmına geldik, çünkü burada yapılan hata protokolün kendisinden daha hızlı vuruyor: Telnet’i kapatırken kendinizi cihazın dışında bırakabilirsiniz.

Bunu ben yaşadım. Az önce bahsettiğim, tüm switch’lerde Telnet açık bulduğum yerde, cihaz envanteri daha önce hiç kullanmadığım bir markaydı ve komut setine hakim değildim. Önceki ağ yöneticisinden bana konsol parolaları da kalmamıştı, o yüzden işe önce konsol parolalarını değiştirerek başladım. Switch’lerin birinde bunu atladım ve tam o cihazda hem SSH hem konsol erişimi gitti. Çözüm cihazın fişini çekip takmak oldu.

Bu neden işe yarıyor? Çünkü ağ cihazlarında çalışan yapılandırma ile açılışta okunan yapılandırma iki ayrı şeydir. Değişiklikleriniz siz kalıcı belleğe yazana kadar yalnızca çalışan kopyada durur.

Bunu bir amatörlük hikayesi olarak anlatmıyorum, çünkü değil. Fazla mesai ve yoğun çalışma sonrası odak kaybı herkesin başına gelir ve bir adımı atlamak için deneyimsiz olmanız gerekmez. Buradan çıkan şey suçlama değil, iki tane meslek kası:

Birinci kas: emin olmadan kaydetme. Yeni erişim yolunun çalıştığını kendi gözünüzle görmeden yapılandırmayı kalıcı belleğe yazmayın. Bu tek alışkanlık, yukarıdaki hikayeyi bir kesintiden fiş çekmeye indiriyor.

İkinci kas: çalışıyorken kaydetmeyi unutma. Bu birincinin tersi gibi görünür ama değil, sırası farklıdır. Doğrulama bittiğinde kaydedeceksiniz. Bunu atlamanın bedelini de ödedim: ilk elektrik kesintisinde yapılandırmaların tamamı gitti. O deneyim, sık kesinti yaşayan bir ortamda kablosuz altyapının üç lokasyonda yenilenmesi projesine giden yolun başlangıcı oldu.

Sıra, tartışmaya açık değil:

1. Konsol erişimini garantiye alın. Kabloyu takın, girin, parolayı bildiğinizden emin olun. Bu sizin son çıkış kapınız.
2. SSH’ı yapılandırın. Anahtar üretin, servisi açın, kullanıcıyı tanımlayın.
3. SSH ile gerçekten girin. Mevcut oturumunuzu kapatmadan, ayrı bir pencereden bağlanın ve komut çalıştırın. Yapılandırmanın doğru görünmesi yeterli değil, girişin çalışması gerekir.
4. Telnet’i kapatın.
5. Yeniden SSH ile girin, hâlâ çalıştığını doğrulayın.
6. Şimdi kaydedin.

Kapatma komutu cihaza göre değişir. Lab’daki yönetilebilir switch’te yapılandırma kipinde tek satır:

console(config)#ip telnet server disable

Ve doğrulaması:

Telnet Server is Disabled.  Port :  23

Kapatamıyorsanız: Yönetim Ağına Alın

Bazen kapatamazsınız. Telnet’ten başka yönetim yolu olmayan eski bir denetleyici, üreticisi kalmamış bir cihaz, ya da dokunulması için önce üretim durdurulması gereken bir sistem. Bu durumda hedef değişir: protokolü ortadan kaldıramıyorsanız, onu duyabilecek kişi sayısını azaltırsınız.

Bunun adı yönetim ağıdır ve fikri basittir. Cihazların yönetim arayüzleri, kullanıcıların günlük trafiğinin aktığı ağdan ayrı bir VLAN’a alınır; o VLAN’a kimlerin girebildiği ise erişim listeleriyle sınırlandırılır. Böylece “aynı ağdaki herkes” cümlesindeki “herkes” kümesi, tüm çalışanlardan yönetim yetkisi olan birkaç makineye iner.

Lab switch’imizde bu ayrım fiilen kurulu. Cihazın VLAN tablosu şöyle görünüyor:

VLAN   Name                             Ports          Type
-----  ---------------                  -------------  --------------
1      default                          Po1-64, Gi1/0/25-48, Te1/0/1-4   Default
5      YONETIM                          Gi1/0/1-24                       Static

Yönetim adresi YONETIM VLAN’ının sanal arayüzü üzerinde duruyor, kullanıcı portlarıyla aynı yerde değil. Bu tek başına şifrelemenin yerini tutmaz ve tutmamalıdır; kapatabiliyorsanız kapatın. Ama kapatamadığınız cihaz için elinizdeki en iyi ikinci hamledir, ve kapattığınız cihazlar için de fazladan bir katman olarak kalır.

Switch ve yönlendirici tarafındaki yönetim erişimini nasıl kurguladığımızı switch ve router kurulumu yazımızda ele alıyoruz. Protokolün kurumsal ağdaki komşularına ve hangi işi hangisinin yaptığına ise ağ protokolleri rehberimizden bakabilirsiniz.

Kapatma kararını verirken yukarıdaki ayrımı hatırlayın: kapattığınız şey protokol, telnet aracı alet çantanızda kalmaya devam ediyor. Cihazlarda 23 numaralı portu kapatmanız, o araçla başka portları test etmenizi hiçbir şekilde engellemez.

Sonuç

Telnet kötü tasarlanmış bir protokol değil, farklı bir dünya için tasarlanmış bir protokol. O dünyada ağdaki herkes tanıdıktı ve açık kanaldan konuşmak makuldü. Bugün ağdaki hiç kimse tanıdık değil ve aynı kanal hâlâ açık duruyor.

Kapatmak teknik olarak tek satır. Zor olan kısım kapatırken kendinizi dışarıda bırakmamak, ve o da bir komut değil bir sıra meselesi: önce konsol, sonra SSH, sonra doğrulama, en son kaydetme. Bu sırayı bir kez kas hafızasına aldığınızda, cihaz markası değişse de sıra değişmez.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.