TFTP Nedir? Port 69, Switch Yedeği ve PXE

TFTP (Trivial File Transfer Protocol), UDP üzerinde 69 numaralı portta çalışan, kimlik doğrulaması hiç bulunmayan ve tek bir iş için tasarlanmış çok küçük bir dosya aktarım protokolüdür: bir dosyayı bir yerden alıp bir yere koymak. Switch ve router yapılandırmalarının yedeklenmesi, cihaz yazılımının yüklenmesi ve ağ üzerinden işletim sistemi kurulumu bugün hâlâ büyük ölçüde bu protokolle yürür.

Her kurumda bir fotokopi odası vardır. Kapısında kilit yoktur, girerken kimse kimliğinizi sormaz, kimin ne çektiğinin kaydı tutulmaz. Bu bir ihmal değil, bilinçli bir tercihtir: her fotokopi için parola isteseydiniz kimse fotokopi çekmezdi. Odanın işe yaraması, tam olarak kimseyi sorgulamamasına bağlıdır.

TFTP o odadır ve makale boyunca aynı odaya döneceğiz. Çünkü protokolün hem neden bu kadar yaygın olduğu hem neden bu kadar tehlikeli olduğu aynı yerden, o kilitsiz kapıdan çıkıyor. Bu makale Kurumsal Network Kurulumu ana hizmetinin yönetim ve yedekleme koluna odaklanıyor ve kurumsal ağ protokolleri rehberimizde tek paragrafla geçilen TFTP başlığını açıyor. Protokolün komşularını, yani hangi işin hangi porta düştüğünü merak ediyorsanız önce oraya bakmanız işinizi kolaylaştırır; burada tek bir protokolün içine ineceğiz. Aşağıdaki bütün paket dökümleri, komut çıktıları ve hata mesajları kendi lab ağımdan, gerçek bir yönetilebilir switch ile bir Ubuntu sunucusu arasında alındı. Protokolün tanımını değil doğrudan sahadaki halini arıyorsanız, lab turuna atlayabilirsiniz: yedek alma denemesi orada başlıyor ve ilk denemede başarısız oluyor.

TFTP Nedir? Port 69’da Kimlik Sormayan Dosya Aktarımı

TFTP, bir dosyayı ağ üzerinden okumak ya da yazmak için gereken en küçük komut kümesini tanımlayan bir protokoldür ve UDP 69 portunda dinler. Adındaki trivial kelimesi bir aşağılama değil, tasarım hedefidir: protokol o kadar sade tutulmuştur ki bir cihazın açılış yazılımına, işletim sistemi henüz yüklenmemişken bile sığar.

Adı FTP’yi çağrıştırır ama akrabası değildir. FTP ayrı bir komut kanalı ile veri kanalı kurar, TCP kullanır, kullanıcı adı ve parola ister, dizin listeler, dosya siler, izin değiştirir. TFTP bunların hiçbirini yapmaz. İki protokolün ayrıntılı karşılaştırması ve güvenli dosya aktarımının seçim kararı FTP, FTPS ve SFTP farkı makalemizde duruyor; burada tek bir cümleyle sınırı çizip kendi konumuza dönelim: TFTP bir dosya paylaşım aracı değil, bir cihaz besleme aracıdır.

Fotokopi odası benzetmesinin karşılıkları şöyle oturuyor:

Benzetmenin koptuğu yer de önemli: fotokopi odasının kapısında kilit yoktur ama binanın kapısında vardır. TFTP’de o bina kapısını protokol değil siz koyarsınız, ve koymazsanız kimse sizi uyarmaz. Yönetim ağının nasıl ayrılacağı VLAN nedir makalemizde anlatılıyor.

Ağ Cihazları Neden Hâlâ TFTP Kullanıyor?

Ağ cihazlarının TFTP’yi bırakmamasının iki gerçek sebebi var ve ikisi de protokolün eksiklerinden doğuyor, onlara rağmen değil.

Birincisi boyut. Bir switch açılırken önce bootloader çalışır, işletim sistemi henüz yüklü değildir. O aşamada cihazın elinde TCP yığını, TLS kütüphanesi, sertifika deposu ya da SSH istemcisi yoktur. Birkaç kilobaytlık bir kod parçasına sığan tek dosya aktarım protokolü TFTP’dir. Cihaz kendi yazılımını ağdan çekecekse, o çekmeyi yapacak kodun yazılımın kendisinden önce var olması gerekir.

İkincisi, ve asıl ilginç olanı, kimlik bilgisinin yokluğu. Bir cihazın SFTP ile yedek alabilmesi için üzerinde saklanmış bir kullanıcı adı ve parola bulunması gerekir. Fabrika ayarlarındaki bir cihazda böyle bir bilgi yoktur ve olmaması iyidir: saklanan her kimlik bilgisi, cihaz çalındığında ya da ikinci el satıldığında sızacak bir kimlik bilgisidir. TFTP kimlik sormadığı için cihazda saklanacak bir şey de kalmaz.

Kolaylık ile açık aynı karardan geliyor. Bu cümle makalenin geri kalanının özeti sayılabilir.

Peki bu, “TFTP kullanmayın” demek mi? Hayır, ve burada net bir alt eşik var. Cihaz henüz kimlik bilgisi taşıyamıyorsa, ya da işlem yalnızca yönetim VLAN’ı içinde kalıyorsa TFTP meşrudur ve pratikte alternatifi yoktur. Yedekleme trafiği o VLAN’ın dışına çıkıyorsa, uzak bir ofise ya da internete uzanıyorsa meşru değildir. Ölçüt protokolün kendisi değil, dosyanın kimin görebileceği bir yoldan geçtiğidir.

TFTP Nasıl Çalışır? Beş Opcode, 512 Baytlık Blok, Tek ACK

TFTP’nin tamamı birkaç mesaj türünden oluşur ve her mesaj ilk iki baytında hangi türden olduğunu söyler. Bu iki bayta opcode denir. Aşağıdaki tabloda listelenenlerin hepsini kendi paket dökümümde yakaladım:

İlk beşi protokolün 1981 tarihli özgün tanımından gelir. Altıncısı, OACK, sonradan eklenen seçenek pazarlığının cevabıdır: istemci blok boyutu ya da zaman aşımı gibi bir tercih önerirse sunucu bu paketle karşılık verir.

Akışın kendisi tek bir kuralla özetlenebilir: gönderen taraf bir blok yollar ve karşıdan onayını almadan sıradakini yollamaz. Buna kilit adım denir ve şöyle işler:

1. İstemci RRQ ya da WRQ gönderir, içine dosya adını ve aktarım modunu yazar.
2. Karşı taraf kabul ederse ACK ile ya da doğrudan ilk DATA bloğuyla cevap verir.
3. Her DATA paketi en fazla 512 bayt veri taşır ve kendi blok numarasını içerir.
4. Alıcı her bloğa ayrı bir ACK döner. Onay gelmeden sonraki blok yola çıkmaz.
5. Gönderen 512 bayttan küçük bir blok yollayınca aktarım biter. Ayrı bir bitiş mesajı yoktur.

Son maddedeki incelik gözden kaçar ama protokolün bütün sadeliği oradadır: dosyanın bittiğini söyleyen ayrı bir işaret yoktur, kısa gelen blok bitişin kendisidir. Dosya tam olarak 512’nin katıysa gönderen sıfır baytlık bir blok yollamak zorundadır, yoksa alıcı beklemeye devam eder.

Fotokopi odasına dönersek: makineye tek sayfa koyup çıkmasını beklersiniz, çıkanı alırsınız, sonra bir sonrakini koyarsınız. Yığını bir kerede besleyip arkanızı dönemezsiniz. Bu yavaştır, ama belleği birkaç kilobayt olan bir bootloader için tam olarak doğru tasarımdır: aynı anda takip edilecek tek bir blok vardır.

İstek Port 69’a Gider, Cevap Başka Porttan Döner

TFTP’nin en çok yanlış bilinen tarafı burasıdır: aktarımın tamamı port 69 üzerinden yürümez. İstemci ilk isteğini 69’a gönderir, ama sunucu o isteği aldıktan sonra kendine yeni bir port açar ve cevabı oradan döner. Geri kalan bütün alışveriş, istemcinin kaynak portu ile sunucunun bu yeni portu arasında sürer. Port 69 her aktarımda tam olarak bir paket görür.

Kendi ölçümümden, yedek alırken çıkan ilk iki paket:

192.168.1.2.50687  > 192.168.1.46.69:     TFTP, length 27, WRQ "./sw01-running.cfg" octet
192.168.1.46.42295 > 192.168.1.2.50687:   UDP, length 19

Bu iki satırda bakılacak üç yer var:

• Birinci satırda hedef port 69. İstek doğru kapıya gitmiş.
• İkinci satırda kaynak port 42295. Cevap 69’dan gelmiyor.
• İkinci satırdaki paketi çözümleyici artık “TFTP” diye adlandıramıyor, düz “UDP” diyor. Çünkü alışveriş bilinen porttan ayrılmış durumda.

Peki sunucu neden 69’dan cevap vermiyor da yeni bir port açıyor? Çünkü 69 bir dinleme kapısıdır ve aynı anda birçok istemciye hizmet vermesi gerekir. Sunucu her isteğe ayrı bir port ayırarak oturumları birbirinden ayırır; ikinci istemci geldiğinde birincinin blokları karışmaz. Portların bu iş bölümü ve UDP’nin TCP’den farkı port nedir makalemizde ayrıntılı olarak duruyor.

Bu tasarım kararının bedelini durum tabanlı firewall’lar öder ve bedeli makalenin sonunda ölçeceğiz.

Lab: TFTP ile Switch Yedeği Alırken Ağda Ne Görünüyor?

Sahada bu işin standart tarifi tek cümledir: TFTP sunucusunu kur, cihazdan copy komutunu çalıştır, yedeğin gelsin. Tarifi bir Ubuntu sunucusunda birebir uyguladım ve ilk denemede yedek alınamadı. Sebebi de, sebebin nerede yazılı olduğu da bu bölümün konusu.

Toplayıcı olarak zaten merkezi syslog sunucusu rolündeki makineyi kullandım; switch ona zaten log gönderiyordu, yani yönetim trafiğinin doğal hedefi orasıydı. Sunucu tarafındaki kurulum tek paket:

sudo apt install tftpd-hpa

Paket kurulduğunda arkasında şu yapılandırmayı bırakıyor:

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure"

Bu dört satırda iki şey eksik ve ikisi de birazdan yedeği düşürecek. Şimdilik cihaz tarafına geçelim. Yönetilebilir switch’in konsolunda yedekleme komutu şu biçimde:

copy running-config tftp://192.168.1.46/sw01-running.cfg

Komut önce ne yapacağını özetliyor, sonra onay istiyor:

Transfer Mode.................................. TFTP
Server IP Address.............................. 192.168.1.46
Destination Filename........................... sw01-running.cfg
Source Filename................................ running-config

Management access will be blocked for the duration of the transfer
Are you sure you want to start? (y/n) y


File transfer failed!

Aktarım sırasında yönetim erişiminin kesileceği uyarısı gerçektir ve cihaza uzaktan bağlıysanız hesaba katılması gerekir. Ama asıl mesele son satır: File transfer failed! Cihaz başarısız olduğunu söylüyor, neden başarısız olduğunu söylemiyor.

TFTP Hatası Nerede Yazılı? Switch Susuyor, Sunucu da Susuyor

Böyle bir durumda refleks olarak sunucu kayıtlarına bakılır. Baktım:

sudo journalctl -t in.tftpd --since "-6 min"

-- No entries --

Sunucu da susuyor. Cihaz sebebi söylemiyor, sunucu kayıt tutmuyor. Geriye sebebin yazılı olduğu tek yer kalıyor, o da paketlerin kendisi. Aktarım sırasında toplayıcı üzerinde bir yakalama açıp aynı komutu tekrarladım ve sunucunun döndürdüğü 19 baytlık cevabın içine baktım:

0x0010:  c0a8 0102 a537 c5ff 001b 83ad 0005 0001
0x0020:  4669 6c65 206e 6f74 2066 6f75 6e64 00

Bu iki satır okunmadığında anlamsız görünür, okunduğunda teşhisin tamamını verir:

• 0005 paketin türünü söylüyor: opcode 5, yani ERROR.
• 0001 hata kodu: 1, yani “dosya bulunamadı”.
• Kalan baytlar hata metninin kendisi: File not found.

Bir yazma isteğine “dosya bulunamadı” cevabı ilk bakışta çelişkili görünür. Çelişki değil, güvenlik tercihi: yaygın TFTP sunucuları varsayılan olarak yalnızca var olan bir dosyanın üzerine yazar. Yeni dosya oluşturma yetkisi açıkça verilmemişse istek reddedilir, çünkü kimlik sormayan bir servise sınırsız dosya oluşturma hakkı vermek, diski dolduran ilk kişiye teslim etmek demektir. Fotokopi odasının kapısı kilitsizdir ama kâğıt dolabı kilitlidir.

Eksik iki şey buydu. Sunucuya dosya oluşturma yetkisini ve dizin sahipliğini vermek gerekiyor:

sudo sed -i 's|^TFTP_OPTIONS=.*|TFTP_OPTIONS="--secure --create"|' /etc/default/tftpd-hpa
sudo chown tftp:tftp /srv/tftp
sudo systemctl restart tftpd-hpa

Aynı komut, aynı cihaz, aynı ağ. Bu kez:

1972 bytes transferred

File transfer operation completed successfully.

Yedeğin İçinde Ne Var? SNMP Community Paket Dökümünde

Başarılı aktarımın tamamı on paketten ibaret ve akış, protokolün kilit adım kuralını ekrana çiziyor:

192.168.1.2.50001  > 192.168.1.46.69:     TFTP, length 27, WRQ "./sw01-running.cfg" octet
192.168.1.46.39668 > 192.168.1.2.50001:   UDP, length 4
192.168.1.2.50001  > 192.168.1.46.39668:  UDP, length 516
192.168.1.46.39668 > 192.168.1.2.50001:   UDP, length 4
192.168.1.2.50001  > 192.168.1.46.39668:  UDP, length 516
192.168.1.46.39668 > 192.168.1.2.50001:   UDP, length 4
192.168.1.2.50001  > 192.168.1.46.39668:  UDP, length 516
192.168.1.46.39668 > 192.168.1.2.50001:   UDP, length 4
192.168.1.2.50001  > 192.168.1.46.39668:  UDP, length 440
192.168.1.46.39668 > 192.168.1.2.50001:   UDP, length 4

Dökümde üç şey doğrulanıyor:

1. İlk satır dışında 69 hiç geçmiyor. Bütün alışveriş 39668 ile 50001 arasında yürüyor.
2. Her 516 baytlık veri paketini 4 baytlık bir onay izliyor. 516’nın 512’si veri, 4’ü başlık; onay paketi zaten yalnız opcode ile blok numarasından ibaret olduğu için 4 bayt.
3. Son veri paketi 440 bayt, yani 512’den küçük. Aktarımı bitiren işaret bu.

Aritmetik de kapanıyor: 3 × 512 + 436 = 1972, cihazın raporladığı bayt sayısıyla birebir aynı.

Şimdi asıl soruya gelelim. Bu paketlerin içinde ne taşındı? Yakalama dosyasında yapılandırmanın içinden bir dizgeyi aradım:

grep -a "serceizleme" 20-basarili-tur.pcap

Dizge bulundu, çünkü paketin gövdesi hex dökümünde çıplak gözle okunabiliyor:

0x00c0:  594f 4e45 5449 4d22 0a65 7869 740a 6970  YONETIM".exit.ip
0x00d0:  2074 656c 6e65 7420 7365 7276 6572 2064  .telnet.server.d
0x00e0:  6973 6162 6c65 0a73 6e6d 702d 7365 7276  isable.snmp-serv
0x00f0:  6572 206c 6f63 6174 696f 6e20 2253 6572  er.location."Ser

Taşınan dosyanın içinde ne olduğunu hatırlamakta fayda var. Bir switch yapılandırması cihazın kurulum tarifi değil, güvenlik mimarisinin tarifidir. Benim yedeğimde şu iki satır düz metin olarak geçti:

username "ilker" password d0a6f64de950243bf2f4cbd905fc5da8 privilege 15 encrypted
snmp-server community "serceizleme" ro

İkinci satırda parola özeti bile yok: SNMP community dizgesi olduğu gibi duruyor. O dizgeyi ele geçiren biri cihazın bütün sayaçlarını, arayüz listesini ve komşularını okuyabilir; community dizgesinin neden bir parola sayılması gerektiği SNMP nedir makalemizde anlatılıyor.

Kimlik doğrulamasının yokluğunu da ölçtüm. Ne switch üzerinde ne sunucuda hiçbir hesabı olmayan üçüncü bir makineden dosyayı istedim:

curl -o calinan.cfg tftp://192.168.1.46/sw01-running.cfg

Çıkış kodu 0, gelen dosya 1972 bayt, içeriği yedeğin aynısı. Hiçbir aşamada kimlik sorulmadı, çünkü protokolde soracak alan yok. Fotokopi odasına giren herkes tepsideki çıktıyı alabilir.

TFTP mi SFTP mi? Aynı Dosya, İki Yakalama

Bu sorunun cevabı tartışmalı görünür, ama ölçüldüğünde tartışma bitiyor. Aynı yapılandırma dosyasını aynı ağda bir de SSH üzerinden taşıdım ve her yakalamada aynı dizgeyi aradım:

Üç turda da taşınan dosya bayt bayt aynı. Fark tek bir şeyde: ikisinde içerik şifreli, birinde değil.

İkinci fark komut satırında görünüyor. Cihaz SFTP ile gönderirken parola istiyor:

Remote Password:********************

TFTP turunda böyle bir satır hiç çıkmadı. Bu, iki protokol arasındaki asıl ayrımın görünür hâli: SFTP’de saklanacak bir kimlik bilgisi vardır, TFTP’de yoktur. Aynı cümle hem SFTP’nin neden daha güvenli hem TFTP’nin neden daha kullanışlı olduğunu açıklıyor. SFTP’nin altında çalışan şifreli kanalın nasıl kurulduğu SSH nedir makalemizde, şifresiz yönetim protokollerinin ağda bıraktığı iz ise Telnet makalemizde duruyor.

Pratik hüküm şu: düzenli ve otomatik çalışan bir yedekleme kuruyorsanız, cihazınız SFTP destekliyorsa ve yedek yönetim ağının dışına çıkıyorsa, orada TFTP’yi savunacak bir gerekçe kalmıyor.

Ama hüküm bu kadarıyla sınırlı, ve TFTP’nin savunduğu bir alan var. O alan izole konsol ağıdır: yalnızca cihazın ve dizüstü bilgisayarınızın konuştuğu, başka kimsenin bulunmadığı geçici bir ağ. Yeni aldığınız bir firewall’u ilk kez yapılandırırken, bir switch’i sıfırdan kurarken ya da kritik bir cihazın yazılımını güncellerken kurduğunuz ağ tam olarak budur. Orada kimlik doğrulamasının yokluğu bir açık değil, kurulum süresini kısaltan bir kolaylıktır: karşınızda henüz hesap tanımlanmamış bir cihaz vardır.

İki protokolün işi burada net biçimde ayrışıyor. SFTP, ayakta duran bir sistemi düzenli olarak yedeklemeye yarar. TFTP’nin işi modern olmak değil: kriz anında, henüz hiçbir şey bilmeyen bir cihazı açılış ekranından ayağa kaldırmaktır. Biri çalışan sistemi korur, diğeri çalışmayanı geri getirir, ve ikincisi tam da kimlik sormadığı için işe yarar.

Ama SFTP’ye geçmek de tek başına yetmiyor, çünkü bir sonraki bölümdeki tuzak tam olarak SFTP turunda çıktı.

”Başarıyla Tamamlandı” Diyen Switch Yedeği Neden Boş Olabilir?

Yedekleme işinde en pahalı senaryo, yedeğin alınmaması değil, alındığının sanılmasıdır. Lab turunda bunun canlı bir örneği çıktı ve verdiği ders protokolden bağımsız.

Cihaza SFTP ile yedek gönderttim ve hedef yolu mutlak biçimde yazdım. Cihazın kendi özeti şuydu:

Destination File Path.......................... home/svc-cfgbak/
Destination Filename........................... sw01-sftp.cfg

1972 bytes transferred

File transfer operation completed successfully.

Sunucuda o dosya yoktu. Dosya sistemi baştan sona tarandığında hiçbir yerde bulunmadı. SSH tarafında ise oturum gerçekten açılmış ve kapanmıştı:

sshd[4247]: Accepted password for svc-cfgbak from 192.168.1.2 port 60778 ssh2
sshd[4247]: pam_unix(sshd:session): session closed for user svc-cfgbak

Sebep, özetin ilk satırında görünüyor: cihaz yolun başındaki eğik çizgiyi atmış ve home/svc-cfgbak/ diye göreli bir yol üretmişti. Oturumun başladığı dizinin altında öyle bir klasör olmadığı için dosya hiçbir yere yazılmadı. Ve cihaz bunu bir hata olarak bildirmedi.

Aynı komutu tek farkla tekrarladım, yolu sadeleştirdim:

copy running-config sftp://svc-cfgbak@192.168.1.46/sw01-sftp2.cfg

Bu kez dosya geldi ve özeti TFTP ile alınan kopyayla birebir aynı çıktı. Yani cihaz yalan söylemiyordu, kendi ürettiği yolu doğrulamıyordu.

Buradan çıkan kural kullandığınız protokolden bağımsızdır: yedekleme işinin son adımı, cihazın verdiği başarı mesajını okumak değil, dosyayı hedefte doğrulamaktır. Doğrulama üç adımlıdır ve otomatize edilebilir:

1. Dosya hedefte gerçekten oluştu mu, boyutu sıfırdan büyük mü.
2. Boyut cihazın raporladığı bayt sayısıyla uyuşuyor mu.
3. İçerik gerçekten yapılandırma mı, yoksa yarım kalmış bir aktarım mı.

Yedeğin geri yüklenebilir olduğunu da sınamak gerekir. Ben bunu canlı yapılandırmaya hiç dokunmadan, cihazın yedek yuvasına geri yazarak yaptım:

copy tftp://192.168.1.46/sw01-running.cfg backup-config

Validating configuration script...

Configuration script validated.
File transfer operation completed successfully.

Cihaz dosyayı geri aldı ve içeriğini satır satır doğruladı. Yedeğin işe yaradığını gösteren şey alınmış olması değil, geri okunabilmesidir. Switch ve router yapılandırmalarının bütün yönetim disiplini switch ve router kurulumu makalemizde ele alınıyor.

PXE Boot Nedir? TFTP’nin İkinci Hayatı

PXE (Preboot Execution Environment), bir bilgisayarın diskinde işletim sistemi olmadan, doğrudan ağ kartı üzerinden açılıp kurulum dosyalarını ağdan çekmesini sağlayan yöntemdir. Yüzlerce makineye tek tek USB takmak yerine hepsini ağdan kurmanın yolu budur ve o dosyaları taşıyan protokol TFTP’dir.

Akış, üç bileşenin sırayla devreye girmesiyle yürür:

1. Makine açılır, diskinde açılabilir bir sistem bulamaz ve ağ kartından yayın yapar.
2. DHCP sunucusu ona bir IP adresi verir, ama bu kez fazladan iki bilgi daha ekler: açılış dosyasının adı ve o dosyanın hangi sunucuda olduğu.
3. Makine belirtilen sunucuya TFTP ile bağlanır, açılış dosyasını çeker ve çalıştırır. Kurulumun geri kalanı genellikle daha yetenekli bir protokole devredilir.

Üçüncü adımda TFTP’nin seçilmiş olması tesadüf değil, ikinci bölümdeki gerekçenin aynısıdır: o anda makinede işletim sistemi yoktur, ağ kartının kendi belleğine sığan bir istemci gerekir. Fotokopi odası, binada elektrik henüz açılmadan çalışan tek odadır.

PXE’nin güvenlik tarafı da aynı kapıdan çıkıyor. Ağda ikinci bir DHCP sunucusu ile ikinci bir TFTP sunucusu kuran biri, açılan makinelere kendi açılış dosyasını verebilir. Bu, kimlik doğrulaması olmayan bir zincirin doğal sonucudur ve PXE’nin yalnızca kontrollü kurulum ağlarında açık tutulmasının sebebidir.

TFTP ile Firmware Yükleme: Geri Dönüşü Olmayan Aktarım

TFTP’nin ikinci ana kullanımı cihaz yazılımının yüklenmesidir ve mekanizma yedeklemeyle birebir aynıdır: cihaz bir RRQ gönderir, sunucu blokları yollar, cihaz her bloğu onaylar. Fark protokolde değil, bahiste. Yarım kalan bir yapılandırma yedeği yeniden alınır; yarım kalan bir yazılım yüklemesi cihazı açılmaz hâle getirebilir.

Bu sebeple pratikte üç önlem standarttır:

• Yükleme, cihazın aktif olmayan yazılım yuvasına yapılır; aktif yuva sağlam kalır ve bir sorun çıkarsa cihaz eski yazılımla açılır.
• Yükleme öncesinde yapılandırma yedeği alınır ve hedefte doğrulanır.
• Sunucu ile cihaz aynı yönetim ağında tutulur; aktarımın yönlendirici üzerinden geçmesi hata olasılığını artırır.

Bu bölümdeki adımları lab cihazımda çalıştırmadım. Lab tek switch üzerinde yürüyor ve yarıda kalan bir yazılım yüklemesinin geri dönüşü belirsiz. Buradaki akış, yedekleme turunda ölçtüğüm TFTP davranışına ve cihazın kendi komut listesine dayanıyor; ölçülmüş bir aktarım kaydı olarak sunulmuyor.

TFTP Sorun Giderme: Sunucu Ayakta, Dosya Gelmiyor

Bu tablo sahada en sık karşılaşılanıdır ve en çok yanıltanıdır: TFTP servisi çalışıyordur, port dinleniyordur, dosya yerindedir, ama istemci hiçbir şey alamaz. Lab turunda bunun tam olarak nasıl göründüğünü yakaladım.

Yedek dosyasını sıradan bir Windows iş istasyonundan çekmeye çalıştım ve istek hiç tamamlanmadı. Sunucu tarafındaki yakalama olayı adım adım anlatıyor:

192.168.1.115.61607 > 192.168.1.46.69:     RRQ "sw01-running.cfg" octet tsize 0 blksize 512 timeout 6
192.168.1.46.39415  > 192.168.1.115.61607: UDP, length 35
192.168.1.46.39415  > 192.168.1.115.61607: UDP, length 35
192.168.1.115.61607 > 192.168.1.46.69:     RRQ "sw01-running.cfg" octet tsize 0 blksize 512 timeout 6
192.168.1.46.51134  > 192.168.1.115.61607: UDP, length 35
192.168.1.46.51134  > 192.168.1.115.61607: UDP, length 35
192.168.1.115.61607 > 192.168.1.46.69:     RRQ "sw01-running.cfg" octet tsize 0 blksize 512 timeout 6
192.168.1.46.43358  > 192.168.1.115.61607: UDP, length 35

Dökümde dört şey oluyor:

1. İstemci isteğini gönderiyor ve sunucu cevap veriyor. Yani sunucu sağlam, dosya duruyor, izin sorunu yok.
2. Cevap 39415 numaralı yeni porttan dönüyor, dördüncü bölümde anlattığımız davranışın aynısı.
3. İstemci o cevabı hiç almıyor. Onay göndermediği için sunucu aynı paketi tekrar yolluyor.
4. İstemci isteği baştan yapıyor ve sunucu her seferinde yeni bir port açıyor: 39415, 51134, 43358. Sonunda birbirinden habersiz altı oturum aynı anda tekrar gönderim yapar hâle geldi.

Cevabı düşüren şey sunucu değil, istemcinin kendi güvenlik duvarıydı. Durum tabanlı bir firewall, giden 61607 ile 69 arasındaki akışı kaydeder ve cevabı 69’dan bekler; 39415’ten gelen paket kayıtlı hiçbir akışa uymadığı için düşürülür. Aynı isteği güvenlik duvarı devrede olmayan bir istemciden yaptığımda dosya sorunsuz geldi.

Buradaki ders protokolün kendisinden daha önemli: dosyayı koruyan şey TFTP’nin güvenliği değildi, bir yapılandırma kazasıydı. Kimlik doğrulaması olmayan servisi erişilemez kılan şey, tesadüfen doğru davranan bir güvenlik duvarıydı. Durum tabanlı denetimin nasıl çalıştığı firewall kurulumu makalemizde anlatılıyor.

Sunucu ayakta ama dosya gelmiyorsa, sırayla şu dört yere bakın:

• Geçici port engelleniyor mu. İstemci ile sunucu arasındaki her güvenlik duvarının TFTP’yi tanıması ya da ilgili yardımcı modülün açık olması gerekir. Belirtisi yukarıdaki tablodur: sunucu cevap verir, istemci hiç almaz.
• Sunucu yeni dosya oluşturabiliyor mu. Yazma yönünde en sık sebep budur ve cevabı ERROR paketinin içindedir.
• Dizin sahipliği doğru mu. Servis kendi kullanıcısıyla çalışır; hedef dizine yazma izni yoksa istek reddedilir.
• Servis doğru arayüzü dinliyor mu. Varsayılan kurulum çoğu zaman bütün arayüzleri dinler, kimlik sormayan bir servisi yalnızca yönetim arayüzüne bağlamak ilk sıkılaştırma adımıdır.

Sonuç: Kilitsiz Kapı Bir Kusur Değil, Bir Sınırdır

TFTP’nin tamamı birkaç mesaj türü, 512 baytlık bloklar ve her bloğa tek onaydan ibaret. Bu sadelik onu, bir cihazın işletim sistemi henüz yokken bile çalışabilen tek dosya aktarım aracı yapıyor; aynı sadelik yapılandırma dosyanızı ağda okunabilir hâlde taşıyor. İkisi aynı tasarım kararının iki yüzü.

Akılda tutulacak tek cümle şu olabilir: fotokopi odasının kapısı kilitsizdir, o yüzden binanın kapısı sizin sorumluluğunuzdadır. Yönetim ağını ayırın, servisi yalnızca o ağa bağlayın, cihaz destekliyorsa yedeği SFTP ile alın, ve en önemlisi cihazın “başarıyla tamamlandı” mesajını yedeğin kanıtı saymayın. Yedeğin kanıtı, hedefte duran ve geri okunabilen dosyadır.

Aynı yönetim ağında çalışan protokol ailesinin tamamı ve bu ailenin hangi üyesinin hangi işi üstlendiği ayrı bir rehberde duruyor; yönetim trafiğinin merkezi olarak nasıl toplanacağı ise syslog nedir makalemizde ele alınıyor.

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.