FTP, FTPS ve SFTP Nedir? Aralarındaki Fark

FTP, FTPS ve SFTP arasındaki fark bir şifreleme farkından ibaret değildir: SFTP, FTP’nin şifreli hali değildir, onunla akrabalığı olmayan ayrı bir protokoldür. Bu üç adın karıştırılması sahada gerçek bir yapılandırma hatasıdır ve sonucu genellikle şu olur: güvenli bir aktarım kurulduğu sanılır, oysa kurulan şey başka bir yerdedir.

Bu yazı üçünün nasıl çalıştığını anlatıyor, ama tanımla bırakmıyor. Aynı dosyayı laboratuvarda üç protokolle de aktarıp trafiği yakaladım. Aşağıda hangi bilginin ağda açıkta kaldığını, bir aktarımın firewall arkasında tam olarak nasıl öldüğünü ve yeni bir kurulumda hangisini seçmeniz gerektiğini bulacaksınız.

Bu makale kurumsal ağ protokolleri rehberimizin dosya aktarımı koluna odaklanır.

Konuyu tek bir yerden anlatacağım: bir toptancı deposu. Deponun önünde bir sipariş masası vardır, arkasında yükleme rampaları. Ne istediğinizi masada söylersiniz, mal rampadan çıkar. FTP’nin bugün anlaşılmayan yanlarının neredeyse tamamı, bu ikiliğin protokole birebir kazınmış olmasından doğuyor.

FTP Nedir ve Neden Hâlâ Karşınıza Çıkıyor?

FTP (File Transfer Protocol), dosyaların bir makineden diğerine kopyalanması için tasarlanmış bir aktarım protokolüdür ve internetin en eski protokollerinden biridir. Bugün geçerli tanımı RFC 959 ile 1985’te yazıldı, yani web’den de eskidir. Tasarlandığı dünyada ağa bağlı makineler birbirini tanıyan kurumların elindeydi ve kimsenin dinlemediği varsayımı makuldü.

Bugün o varsayım geçerli değil. Buna rağmen FTP ortadan kalkmadı ve kalkmamasının somut sebepleri var:

• Kurumsal yazıcılar, tarayıcılar ve kamera kayıt cihazları taradıkları dosyayı çoğunlukla FTP ile bir paylaşıma bırakır.
• Tedarikçilerin ve bayilerin yıllardır çalışan entegrasyonları FTP üzerine kuruludur; karşı taraf değiştirmeye yanaşmaz.
• Hosting paketlerinin neredeyse tamamı hâlâ FTP erişimi verir.
• Ağ cihazlarının yapılandırma yedeği ve yazılım güncellemesi FTP ya da onun sadeleştirilmiş akrabası TFTP ile taşınır.

Yani FTP’yi bilmek nostalji değil, envanter meselesidir. Ağınızda çalışan bir FTP aktarımı büyük olasılıkla vardır ve onu bulmadan kapatamazsınız.

Bir de protokolün kendi içinde taşıdığı, çoğu kurulumda unutulan bir kapı var: anonim erişim. FTP, kullanıcı adı olarak anonymous kabul eden ve parola yerine herhangi bir metni geçerli sayan bir kip destekler. Kamuya açık yazılım arşivlerinin dağıtım yöntemi olarak tasarlandı, ama bugün sahada karşınıza çoğunlukla iki şekilde çıkar: bir cihazın varsayılan yapılandırmasında açık unutulmuş olarak, ya da “sadece dosya bırakacaklar, parola uğraştırmasın” denip bilinçli açılmış olarak.

İkisinin sonucu aynıdır: o dizine erişebilen herkes, kim olduğunu hiç söylemeden dosya okuyabilir. Yazma izni de verilmişse dosya bırakabilir de. Envanter çıkarırken ilk bakılacak ayar budur; modern sunucu yazılımları anonim erişimi varsayılan olarak kapalı getirir, ama devraldığınız bir sistemde bu varsayımı doğrulamadan kabul etmeyin.

Dosya Paylaşımı ile Dosya Aktarımı Aynı Şey Değil

Bu ayrım FTP’yi anlamanın ön koşuludur ve sürekli karıştırılır. İkisi farklı problemleri çözer, farklı protokoller ister.

Paylaşımda dosya olduğu yerde durur. Siz uzaktan üzerinde çalışırsınız, kaydettiğinizde değişiklik doğrudan oradaki dosyaya işlenir ve yetkiyi dizin belirler. Ağ sürücüsü açtığınızda olan budur; Windows tarafında SMB, Linux ve sanallaştırma tarafında NFS bu işi yapar.

Aktarımda ise dosyanın bir kopyası çıkar ve başka bir yere gider, genellikle kurum sınırının dışına. Kaynak dosya yerinde kalır, hedefte ikinci bir nüsha oluşur. FTP, FTPS ve SFTP bu işi yapar.

Depo benzetmesinde fark şudur: paylaşım, deponun içindeki rafa gidip malı orada saymanızdır. Aktarım, malın kamyona yüklenip kapıdan çıkmasıdır.

Ayrımı bilmek doğrudan işinize yarar, çünkü yanlış aracı seçmenin bedeli hemen görünmez. Bir ekip aynı belge üzerinde çalışacaksa aktarım protokolü seçmek, herkesin elinde ayrı bir kopya oluşması demektir ve iki gün sonra hangisinin güncel olduğu kimse bilmez. Tersi de geçerli: kurum dışına düzenli dosya gönderiyorsanız, karşı tarafa ağ sürücüsü açmak paylaşım izinlerini kurum sınırının dışına taşımak anlamına gelir.

FTP’nin İki Kanalı: Komut ve Veri

FTP’yi diğer protokollerden ayıran ve bugünkü sorunlarının kaynağı olan özellik şudur: tek bir bağlantı kullanmaz, iki ayrı TCP bağlantısı açar.

Birincisi komut kanalıdır ve 21 numaralı porttan geçer. Oturum boyunca açık kalır. Kullanıcı adı, parola, dizin değiştirme, dosya listeleme, “şu dosyayı istiyorum” talebi hep buradan gider. Deponun sipariş masasıdır: konuşma burada olur, ama mal buradan çıkmaz.

İkincisi veri kanalıdır ve her transfer için ayrı açılır, iş bitince kapanır. Dosyanın kendisi ve dizin listesi buradan akar. Yükleme rampasıdır.

Bu ayrımın protokole neden konduğunu anlamak, sonraki her şeyi kolaylaştırır: 1970’lerde tasarlanırken amaç, uzun bir dosya transferi sürerken kullanıcının komut satırının kilitlenmemesiydi. Konuşma ile taşıma ayrı hatlarda olsun ki transfer devam ederken iptal edebilesiniz. Kendi bağlamında akıllıca bir çözümdü.

Sorun, aradan geçen kırk yılda ağların değişmesi oldu. Firewall diye bir şey yoktu, NAT diye bir şey yoktu. Her ikisi de bağlantıları tek tek denetler ve FTP’nin ikinci kanalı, denetlenmesi en zor bağlantı türüdür: portu önceden belli değildir.

Aktif Mod ve Pasif Mod Nedir?

İki kanal olunca kaçınılmaz bir soru doğar: veri kanalını kim açacak? FTP’nin buna iki cevabı var ve aralarındaki fark, dosya aktarım arızalarının birinci sebebidir.

Aktif modda istemci komut kanalından “ben şu adreste, şu portu dinliyorum, veriyi oraya gönder” der. Sunucu bu bilgiyi alır ve istemciye doğru yeni bir bağlantı açar. Depoda müşterinin “kamyonum üç numaralı rampada bekliyor” demesi ve deponun mal yüklemek için oraya gitmesidir.

Pasif modda yön terse döner. İstemci “sen bir rampa aç, numarasını söyle” der; sunucu bir port belirler ve numarasını bildirir, bağlantıyı yine istemci açar. Yani her iki bağlantı da istemciden sunucuya doğrudur.

Farkın neden önemli olduğunu görmek için gerçek bir oturumun komut kanalını okumak yeterli. Laboratuvarda Windows’un yerleşik ftp istemcisiyle bir dosya istedim ve trafiği sunucu tarafında yakaladım. Dökümde şu satırlar geçiyor:

USER serce-ftp
331 Please specify the password.
PASS Ftp123#
230 Login successful.
PORT 192,168,1,115,245,65
200 PORT command successful. Consider using PASV.
RETR tedarikci-fiyat-listesi.txt

Bu dökümde üç şeye bakın:

1. PORT komutu aktif modun ta kendisidir. İstemci kendi adresini ve dinlediği portu sunucuya bildiriyor.
2. Port numarası iki parçaya bölünmüş halde gider: son iki sayı çarpılıp toplanır, yani 245 × 256 + 65 işleminden 62785 çıkar. İstemcinin veri için beklediği port budur.
3. Sunucunun cevabındaki uyarıyı atlamayın: Consider using PASV. Protokolün kendi sunucusu, kullandığınız modun sorun çıkaracağını size söylüyor.

Üçüncü madde bir kenara yazılmayı hak ediyor. Windows’un yerleşik ftp istemcisi yalnızca aktif modda çalışır, pasif moda geçemez. Yani elinizdeki en yaygın FTP aracı, sunucunun bile önermediği modu kullanır.

Bu Üç Haneli Sayılar HTTP Durum Kodu Değil

Dökümdeki 331, 230 ve 200 gibi sayılar FTP’nin kendi yanıt kodlarıdır, HTTP durum kodları değil. Karıştırmak kolay, çünkü ikisi de üç hanelidir ve bazıları birebir aynı görünür. Anlamları ise aynı değil: HTTP’de 200 “istek tamam, yanıt gövdesi geliyor” demektir, FTP’de “komut kabul edildi” demektir. 3xx grubu HTTP’de yönlendirmedir, FTP’de ise “kabul ettim ama işlem bitmedi, devamını bekliyorum” anlamına gelir. Nitekim 331 Please specify the password cümlesi tam olarak bunu söylüyor: kullanıcı adını aldım, şimdi parolayı ver.

Kodun ilk hanesi, cevabın hangi sınıfa girdiğini söyler ve teşhiste doğrudan işinize yarar:

• 1 ile başlıyorsa işlem başladı ama bitmedi, ikinci bir cevap gelecek.
• 2 ile başlıyorsa işlem başarıyla tamamlandı.
• 3 ile başlıyorsa sunucu sizden bir şey daha bekliyor.
• 4 ile başlıyorsa geçici bir hata var, aynı komut sonra çalışabilir.
• 5 ile başlıyorsa hata kalıcıdır, aynı komutu tekrarlamanın anlamı yok.

Bu ayrımın en öğretici örneği bir dosya transferinin iki kod almasıdır: veri kanalı açılırken 150 Opening BINARY mode data connection, kapanırken 226 Transfer complete. HTTP’de böyle bir şey yoktur, orada bir isteğe bir yanıt kodu düşer. FTP’nin ikisini birden vermesi tesadüf değil, iki kanallı olmasının doğrudan sonucudur: birinci kod “rampayı açıyorum” der, ikincisi “yükleme bitti” der. Teşhiste 150 görüp 226 görmüyorsanız, sorunun tam olarak nerede olduğunu zaten biliyorsunuz demektir.

Sıra da sandığınızın tersidir: üç haneli yanıt kodu fikri FTP’de HTTP’den on yıllar önce vardı. HTTP tarafındaki sınıflandırmayı ve hangi kodun ne anlattığını HTTP ve HTTPS rehberimizde ayrıca ele alıyoruz.

Aynı şemayı posta tarafı da devraldı, ve orada bir tuzak daha var: HTTP’de 4xx ile 5xx ayrımı suçu paylaştırır (istemci hatası, sunucu hatası), SMTP’de ise tekrar denenip denenmeyeceğini belirler. Yani HTTP alışkanlığıyla okunan bir posta hata kodu, insanı yanlış tarafta arama yapmaya götürür. Bu ayrımı SMTP kodları ile HTTP durum kodlarının farkında ele alıyoruz.

Pasif Mod Firewall Arkasında Neden Kırılır?

Bu bölüm makalenin en çok işinize yarayacak yeri, çünkü anlattığı arıza teşhis edilmesi en sinir bozucu olanlardan biridir: oturum açılır, giriş başarılı olur, sonra hiçbir şey olmaz.

Sahada bu duruma verilen standart cevap “sunucu kapalıdır” ya da “parola yanlıştır” olur. İkisi de değil. Yukarıdaki oturumun devamını ölçtüm: giriş başarılıydı, dosya talebi sunucuya ulaşmıştı. Sonra sunucu veri kanalını açmayı denedi ve şu oldu:

192.168.1.15.20 > 192.168.1.115.62785: Flags [S], length 0
192.168.1.15.20 > 192.168.1.115.62785: Flags [S], length 0
192.168.1.15.20 > 192.168.1.115.62785: Flags [S], length 0
192.168.1.15.20 > 192.168.1.115.62785: Flags [S], length 0

Dökümde okunacak üç şey var:

1. Bağlantının yönü sunucudan istemciye doğrudur. Aktif modun tanımı budur ve sorunun kaynağı da budur: istemcinin firewall’u kendisine gelen bir bağlantı görüyor.
2. Flags [S] bir bağlantı açma talebidir. On kez tekrarlandı, aralar giderek açılarak toplam otuz saniyeyi aştı.
3. Hiçbirine cevap yok. Reddedilme bile yok: firewall paketi sessizce düşürdü. Reddetseydi karşı taraf hemen “kapalı” cevabını alır ve hata verirdi. Sessiz düşürmede ise sunucu cevap bekler, istemci ekranda bekler, kullanıcı bekler.

Sonuç şuydu: istemci altmış saniye boyunca donup kaldı ve dosya hiç inmedi. Ekranda ne bir hata mesajı çıktı ne de bir uyarı. Reddedilme ile sessiz düşürme arasındaki bu fark, dosya aktarımına özgü değil; ağdaki bütün bağlantı arızalarının okunma biçimini belirler ve port kavramını ele aldığımız rehberde ayrıntısıyla anlatılıyor.

Peki pasif moda geçmek bu sorunu çözer mi? Kısmen. Pasif modda her iki bağlantıyı da istemci açtığı için istemci tarafındaki firewall rahatlar, ama sorun bu sefer sunucu tarafına geçer: sunucu her transferde farklı bir yüksek port açar ve sunucunun firewall’unun o aralığa izin vermesi gerekir. Laboratuvardaki pasif mod turunda sunucunun seçtiği port 23733 idi; bir sonraki transferde bambaşka bir sayı olacaktı.

İşte “pasif mod port aralığı” ayarı buradan çıkar. Sunucuya “yalnız şu aralıktan port seç” dersiniz, firewall’da o aralığı açarsınız. Aralığı açmayı unutmak, “içeriden çalışıyor, dışarıdan çalışmıyor” arızasının bir numaralı sebebidir: iç ağda genellikle firewall yoktur, dışarıdan gelen bağlantı ise o aralığa takılır.

FTP Parolayı da Dosyayı da Açıkta Taşır

Şimdi mimariden güvenliğe geçiyoruz, ve buradaki kayıp sandığınızdan büyük.

FTP’nin parolayı düz metin taşıdığı yaygın olarak bilinir. Bu doğru ve yukarıdaki dökümde PASS Ftp123# satırı olduğu gibi okunuyordu. Ama asıl mesele bu değil. Telnet tarafında da aynı şeyi ölçmüştüm ve orada kaybedilen şey yönetim erişimiydi: saldırgan parolayı okur, cihaza girer.

FTP’de bir katman daha var. Aynı dosyayı pasif modla indirdim ve bu kez veri kanalını yakaladım:

TEDARIKCI FIYAT LISTESI - 2026 3. CEYREK
Gizlilik: Kurum ici. Ucuncu taraflarla paylasilmaz.
Kalem 1 ................ 14.500 TL / adet
Kalem 2 ................ 22.750 TL / adet
Yillik anlasma iskontosu: %18
Yetkili: satinalma@ornek-tedarikci.local

Bu, paket dökümünden hiçbir çözümleme yapılmadan çıkan ham metindir. Dosyanın kendisi, üzerindeki gizlilik ibaresi dahil, ağda olduğu gibi taşınıyor.

Farkı net söylemek gerekiyor: Telnet’te parolayı kaptıran kişi erişimini kaybeder ve parolayı değiştirerek kapıyı kapatabilir. FTP’de dosyayı kaptıran kişi veriyi kaybeder ve onu geri alamaz. Fiyat listesi okunduysa okunmuştur; parola değiştirmek bunu geri almaz.

Peki bu risk gerçekten sizin ağınızda var mı? Trafiği okuyabilmek için saldırganın internete değil, o dosyanın geçtiği yola erişmesi gerekir: aktarımın kablosuz bir bölümden geçmesi, cihazda yapılandırılmış bir port yansıtması ya da uçlardan birinin ele geçirilmiş olması yeterlidir. Sonuncusu en sık olanıdır ve tam da bu yüzden “iç ağdayız” cümlesi bir savunma değildir.

FTPS Nedir? FTP’ye TLS Eklemek

Açıkta giden bir protokolün ilk akla gelen çözümü onu şifrelemektir ve FTPS tam olarak budur: FTP’nin üzerine TLS eklenmiş hali. HTTP’nin HTTPS’e dönüşmesiyle aynı mantık, aynı şifreleme katmanı. TLS el sıkışmasının nasıl işlediği ve sertifikanın ne doğruladığı HTTP ve HTTPS rehberimizde anlatılıyor; burada önemli olan, eklemenin FTP’nin neyini değiştirdiği ve neyini değiştirmediğidir.

Laboratuvarda sunucuda TLS’i açıp aynı dosyayı bir kez de böyle çektim. Komut kanalının başında şunlar okunuyor:

220 (vsFTPd 3.0.5)
AUTH SSL
234 Proceed with negotiation.

Bu üç satırdan sonrası şifreli. Parola, dosya adı ve içerik için dökümde arama yaptım, hiçbiri bulunamadı. Yani FTPS vaadini yerine getiriyor.

Ortadaki satır aslında bir kalıbın adıdır ve aynı kalıp başka protokollerde de karşınıza çıkar. Bağlantı düz başlar, istemci bir komutla “şifrelemeye geçelim” der, ve aynı bağlantı yeni bir port açılmadan şifreliye yükseltilir. Komutun adı protokolden protokole değişiyor: dosya aktarımında AUTH TLS (eski sunucularda AUTH SSL), posta protokollerinde STARTTLS, dizinde StartTLS. Kalıbın neden icat edildiğini, adım adım nasıl işlediğini ve baştan şifreli bir porta göre nerede zayıf kaldığını TLS bağlantıya nereden giriyor bölümünde topluca ele alıyoruz.

Ama iki şey değişmedi ve ikisi de önemli.

Birincisi, şifreleme başlamadan önce ağda görünen bir aralık var: sunucunun sürüm bilgisi (vsFTPd 3.0.5) ve bağlantının FTPS olduğu bilgisi açıkta. Bu bir felaket değil, fakat bir sunucunun tam sürümünü dışarıya ilan etmesi tercih edilen bir durum da değildir.

İkincisi ve asıl olanı: iki kanal mimarisi aynen duruyor. Aynı yakalamada, veri için 31700 numaralı porta ikinci bir TCP bağlantısı açıldı. Yani pasif mod port aralığı derdi, firewall kuralları, “içeriden çalışıyor dışarıdan çalışmıyor” arızası, hepsi olduğu gibi devam ediyor. FTPS içeriği gizler, mimariyi değiştirmez.

FTPS’in ikinci kanalı beklenmedik bir yerde tökezledi

Bu bölümü eklememizin sebebi, laboratuvarda planlanmamış bir şeyin çıkması. İlk FTPS denememiz başarısız oldu: bağlantı kuruldu, giriş yapıldı, dosya talebi gitti, sonra transfer yarıda koptu. İstemcinin verdiği hata transfer closed with 299 bytes remaining to read idi, yani “dosyayı alacaktım, alamadım”.

Cevap sunucunun kendi kaydındaydı:

DEBUG: Client "::ffff:192.168.1.115", "No SSL session reuse on data channel."

Mekanizma şu: veri kanalı ayrı bir TCP bağlantısı olduğu için sunucu haklı bir soru soruyor. Bu yeni bağlantıyı açan taraf, az önce kimlik doğrulayan taraf mı, yoksa araya giren başka biri mi? Cevabı garantilemek için sunucu, veri bağlantısının komut kanalındaki TLS oturumunu yeniden kullanmasını şart koşuyor. İstemcimiz bunu yapamadı ve sunucu transferi kesti.

Çalıştırmak için sunucuda o kontrolü kapatmak gerekti. Kapattım, dosya indi.

Buradaki dersi kaçırmayın: FTPS’in iki kanallı yapısı, güvenliği sağlamak için fazladan bir kontrol icat etmeye zorluyor ve o kontrol yaygın istemcilerle uyuşmadığında sahada yapılan şey kontrolü gevşetmek oluyor. Yani ikinci kanal yalnızca firewall’da değil, güvenlik tarafında da bedel ödetiyor. SFTP’de bu soru hiç sorulmaz, çünkü sorulacak ikinci bir bağlantı yoktur.

SFTP Nedir? FTP ile Hiçbir Akrabalığı Yok

SFTP (SSH File Transfer Protocol), SSH oturumunun içinde çalışan bir dosya aktarım protokolüdür ve bu makalenin düzeltmek için yazıldığı yanılgı tam burada: adındaki benzerliğe rağmen FTP ile ortak bir kodu, ortak bir tasarımı ya da ortak bir geçmişi yoktur. FTPS, FTP’nin şifreli halidir. SFTP ise bambaşka bir protokoldür ve SSH’ın bir alt sistemi olarak doğmuştur.

Farkın pratikteki karşılığı şudur:

• Tek bağlantı kullanır. Komut da veri de aynı şifreli oturumun içinden akar. Ayrı bir veri kanalı yoktur.
• 22 numaralı porttan geçer, yani sunucunuzda SSH açıksa SFTP zaten çalışıyordur. Ek port açmanız gerekmez.
• Aktif ve pasif mod diye bir kavramı yoktur. İkinci bağlantı olmadığı için yön sorusu hiç doğmaz.
• SSH’ın kimlik doğrulama altyapısını olduğu gibi devralır, yani parola yerine anahtar tabanlı girişi doğrudan kullanabilirsiniz.

Depo benzetmesinde SFTP, sipariş masası ile rampanın aynı kapıda olduğu bir depodur. Konuşma da taşıma da tek kapıdan geçer, dolayısıyla açılacak ikinci bir kapı yoktur.

Benzetmenin koptuğu yeri de söyleyelim, çünkü bu fark önemli. Depodan çıkan mal gerçekten yer değiştirir: rafta artık yoktur. Dosya aktarımında ise kaynak dosya olduğu yerde kalır, hedefte ikinci bir kopya oluşur. Bu yüzden bir aktarımın “başarılı” olması dosyanın taşındığı anlamına gelmez, çoğaldığı anlamına gelir. Kurum dışına giden her aktarım, o dosyanın artık iki yerde durduğu bir karardır ve geri alınamaz.

SFTP, SSH’ın içinde nasıl çalışıyor?

Bunu açmaya değer, çünkü “SSH’ın içinde” ifadesi somut bir mekanizmaya karşılık geliyor ve mekanizmayı bilmek yukarıdaki tablonun neden öyle olduğunu açıklıyor.

SSH bağlantısı kurulduğunda ortaya tek bir şifreli boru çıkmaz; kanallara ayrılabilen bir taşıyıcı çıkar. Aynı oturumun içinde birden fazla mantıksal kanal açılabilir ve her biri farklı bir iş yapar: biri size kabuk verir, biri port yönlendirir, biri dosya aktarır. Bunlar ayrı TCP bağlantıları değildir, hepsi aynı şifreli oturumun içinde numaralandırılmış akışlardır.

SFTP işte böyle bir kanaldır. İstemci bağlandığında SSH’a “bana kabuk verme, sftp alt sistemini çalıştır” der; sunucu o kanalda dosya işlemlerini anlayan bir süreç başlatır. Sıra şudur:

1. TCP bağlantısı 22 numaralı porta kurulur ve taraflar anahtar değişimini yapar.
2. Şifreleme kimlik doğrulamadan önce devreye girer, yani parola ya da anahtar zaten kapalı kanalın içinde gider.
3. Kimlik doğrulandıktan sonra istemci sftp alt sistemini talep eder.
4. Dosya listeleme, indirme ve yükleme komutları o kanalın içinden akar.

İkinci maddedeki sıra, yakalamada dosya adının bile görünmemesinin sebebidir: oturumun şifresiz kaldığı tek an, henüz hiçbir bilginin konuşulmadığı sürüm değişimi anıdır. SSH’ın anahtar değişimi, ana bilgisayar anahtarı ve parmak izi doğrulaması SSH rehberimizde ayrıntılı anlatılıyor.

Buradan pratik bir sonuç çıkıyor: SFTP’yi ayrıca kurmazsınız. Sunucuda SSH çalışıyorsa alt sistem zaten tanımlıdır. Aynı sebeple, SSH erişimini sıkılaştırdığınızda SFTP’yi de sıkılaştırmış olursunuz; ikisi ayrı yapılandırmalar değildir.

Windows’ta SFTP’yi Rol Listesinde Aramayın

Yukarıdaki cümlenin bir istisnası var ve sahada en çok orada tökezleniyor: Linux sunucularda SSH zaten açıktır, Windows sunucularda değildir. Windows’ta SFTP’yi veren bileşen OpenSSH Server’dır ve o bir rol değil, bir isteğe bağlı özelliktir (İsteğe Bağlı Özellikler ekranından ya da Add-WindowsCapability ile eklenir). İstemci tarafı, yani ssh ve sftp komutları, Windows 10 ve 11’de zaten kuruludur; eksik olan yalnızca sunucu tarafıdır.

Karışıklık şuradan çıkıyor: sunucu rollerinin listesinde “SFTP” diye bir kalem yoktur. Orada duran şey FTP Server’dır ve o rol, adı çağrıştırsa da SFTP konuşmaz; FTP ve TLS eklendiğinde FTPS sunar. Yani rol ağacında arayan kişi, aradığını bulamadığı için en yakın duranı seçer ve bu makalenin başından beri anlattığımız yanlış yapılandırmayı, bu kez bir kurulum sihirbazının içinde tekrar eder.

Kurulu olanı tek turda görmek isterseniz, iki komut iki soruyu birden cevaplar:

Get-WindowsCapability -Online -Name OpenSSH.Server*
Get-WindowsFeature Web-Ftp-Server

Birincisi Installed diyorsa sunucunuz SFTP konuşuyordur, ikincisi Installed diyorsa konuşulan şey FTP ya da FTPS’tir.

Bu yüzden ağ cihazlarında otomatik yedeklemenin protokolü pazarlık konusu değildir: SFTP kullanın. Cihazların geleneksel tercihi olan TFTP burada özellikle kötü bir seçimdir, çünkü şifreleme bir yana kimlik doğrulaması bile yoktur; hedefe ulaşabilen herkes o dizinden okuyabilir; bunu yetkisiz bir makineden yedeği çekerek ölçtüm. Düz FTP de aynı kapıya çıkar, üstelik yanında bir de aktarım hesabının parolasını ağda açık taşır.

Bir switch’in yedeğini SFTP ile, yalnız yedek için açılmış ve tek bir dizine hapsedilmiş bir hesaba her gece gönderen kurulumu switch yapılandırma yedeği yazımızda adım adım anlattık.

Bugün aynı yapıyı kuracak olsam yine SFTP tarafında kurardım, ve ikinci sebebi sadelik: hedef bir Windows sunucu olsa bile tek bir özellik eklemek, bir rol servisi kurup TLS sertifikası yönetmekten ve pasif mod port aralığı açmaktan daha az hareketli parça içerir.

Aynı dosyayı üçüncü kez, bu sefer SFTP ile aktardım ve aynı yakalamayı yaptım. Doksan sekiz paket toplandı. Dökümde okunabilen tek şey açılıştaki sürüm satırlarıydı:

SSH-2.0-OpenSSH_for_Windows_9.5
SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18

Sonrasında dokuz ayrı dize arattım: kullanıcı adı, parola, dosyanın adı, içindeki fiyatlar, gizlilik ibaresi. Hiçbiri bulunamadı. Dikkat çeken nokta şu: FTP dökümünde RETR tedarikci-fiyat-listesi.txt satırı dosyanın adını açıkça veriyordu. SFTP’de dosyanın adı bile görünmüyor, çünkü şifreleme kimlik doğrulamadan önce başlıyor ve o noktadan sonra oturumun tamamı kapalı.

FTPS ve SFTP Farkı: Hangisini Seçmelisiniz?

Üç protokolü aynı ölçütlerle yan yana koyalım. Tablodaki her satır yukarıdaki turlarda fiilen ölçüldü.

Karar sadeleşiyor: yeni bir kurulumda varsayılan tercihiniz SFTP olmalı. Tek portla çalışır, ek kural istemez, mimarisi basittir ve sunucularınızda SSH zaten açıktır.

Gerçek senaryolara indirgeyelim:

• Tedarikçiye ya da bayiye düzenli dosya bırakacaksınız. SFTP kurun, karşı tarafa anahtar tabanlı erişim verin. Hesabı yalnızca kendi dizinine erişebilecek şekilde kısıtlayın.
• Muhasebeye ya da mali müşavire aylık dosya gidecek. SFTP kurun. Karşı taraf teknik değilse grafik arayüzlü bir istemci verin; SFTP’yi destekleyen ücretsiz istemciler yaygın.
• Ağ cihazlarının yapılandırma yedeği otomatik olarak bir sunucuya akacak. SFTP kurun, ve bunu bir tercih değil kural sayın: taşınan dosya güvenlik mimarinizin tarifidir, üstelik iş otomatik olduğu için kimse başında durmaz. Cihaz tarafında TFTP kolay göründüğü için sık seçilir; kimlik doğrulaması olmadığından burada en kötü seçenektir. Aktarım hesabını yalnız yedek klasörüne yazabilecek şekilde kısıtlayın.
• Karşı taraf yalnızca FTPS konuşuyor. FTPS kullanın, ama pasif mod port aralığını sunucuda sabitleyin ve firewall’da yalnızca o aralığı açın. Aralığı geniş bırakmayın.
• Eski bir cihaz yalnızca FTP destekliyor. Protokolü değiştiremiyorsanız yolu daraltın: cihazı ayrı bir segmente alın, firewall’da yalnızca o iki adres arasındaki trafiğe izin verin. Taşınan veri hassassa dosyayı göndermeden önce şifreleyin, böylece kanal açık olsa bile içerik okunamaz.

Bir de sıkça sorulan komşu var: TFTP (69), adı benzese de bambaşka bir iştedir. Kimlik doğrulaması yoktur ve ağ cihazlarının yapılandırma yedeği ile yazılım yüklemesi için kullanılır. Dosya alışverişi için bir seçenek değildir; ağ cihazları bağlamındaki yeri, beş opcode’luk mekanizması ve bir switch yedeğinin ağda neye benzediği TFTP makalemizde ölçümle anlatılıyor.

Dosya Aktarımı Teşhisi: Bağlanıyor Ama Aktarmıyor

Hangisini seçeceğinizi biliyorsunuz, ama elinizde zaten çalışmayan bir FTP kurulumu varsa sıra teşhise geliyor. Bu arızanın en tipik hali şudur: bağlantı kuruluyor, giriş başarılı, sonra dizin listesi bile gelmiyor ya da transfer ortasında donuyor.

Bu tabloyu gördüğünüzde parolayı ve sunucunun ayakta olup olmadığını kontrol etmek zaman kaybıdır; ikisi de çalışıyor. Sırayla şuraya bakın:

1. Girişin gerçekten başarılı olduğunu doğrulayın. İstemci 230 Login successful cevabını aldıysa komut kanalı sağlamdır. Sorun veri kanalındadır ve aşağıdaki adımlar geçerlidir. Bu cevabı almadıysanız sorun bambaşkadır, kimlik doğrulamaya bakın.

2. Modu belirleyin. Oturum kaydında PORT görüyorsanız aktif, PASV ya da EPSV görüyorsanız pasif moddasınız. Windows’un yerleşik ftp istemcisi yalnız aktif mod yapar, dolayısıyla test aracınız sonucu değiştirir. Komut kanalını görmek için istemciyi ayrıntılı kipte çalıştırın:

   CMD

   ftp -d 192.168.1.15
   curl -v --ftp-pasv -u kullanici ftp://192.168.1.15/dosya.txt -o dosya.txt

   İlki Windows’un yerleşik istemcisini hata ayıklama kipinde açar ve gidip gelen her komutu ekrana basar. İkincisi pasif mod dener; curl Windows 10 ve 11’de yerleşiktir, yani ek kurulum gerektirmez. İki çıktıyı yan yana koymak modun sonucu nasıl değiştirdiğini tek bakışta gösterir.

3. Aktif moddaysanız istemci tarafındaki firewall’a bakın. Bağlantı sunucudan istemciye doğru açılıyor, yani engelleyen taraf çoğunlukla kullanıcının kendi makinesidir. Hızlı doğrulama: aynı transferi pasif mod destekleyen bir istemciyle deneyin, çalışıyorsa teşhis kesindir.

4. Pasif moddaysanız sunucudaki port aralığına bakın. Sunucuda pasif mod aralığı sabitlenmiş mi, firewall’da o aralık açık mı? Aralık tanımlı değilse sunucu her transferde rastgele bir yüksek port seçer ve hiçbir firewall kuralı ona yetişemez.

5. Arada NAT varsa çeviriyi kontrol edin. Pasif modda sunucu, istemciye bağlanacağı adresi kendi bildiği haliyle söyler. Sunucu NAT arkasındaysa bu adres iç ağ adresi olur ve istemci ulaşamayacağı bir yere bağlanmaya çalışır. Çözüm sunucuya dışarıdan görünen adresini açıkça bildirmektir; NAT rehberimizde çevirinin neden bu davranışı ürettiği anlatılıyor.

6. Hiçbiri değilse aktarımı SFTP’ye taşımayı deneyin. Aynı iki makine arasında SFTP çalışıyorsa sorunun ağda değil FTP’nin ikinci kanalında olduğu kanıtlanmış olur.

Teşhiste en çok vakit kaybettiren nokta üçüncü ve dördüncü maddelerin karıştırılmasıdır: aktif modda suçlu istemci tarafı, pasif modda sunucu tarafıdır. Modu belirlemeden firewall kuralı yazmak, çoğu zaman yanlış makinede kural açmak demektir.

Sonuç: Fark Şifrelemede Değil, Mimaride

Bu üç protokolü ayıran şey basit bir “şifreli mi değil mi?” sorusu değildir. FTP dosyayı da parolayı da açıkta taşır ve bunu ölçtüm. FTPS bu açığı kapatır, ama FTP’nin iki kanallı yapısını devraldığı için firewall karmaşasını ve yanında beklenmedik uyumluluk sorunlarını da devralır. SFTP ise sorunu kaynağında çözer, çünkü çözmesi gereken ikinci bir kanal yoktur.

Pratik özet üç cümledir. Yeni kurulumlarda SFTP seçin. FTPS’i yalnız karşı taraf başka bir şey konuşmuyorsa kullanın ve pasif mod aralığını mutlaka sabitleyin. Açık FTP’yi ise önce bulun: ağınızda çalışan bir FTP aktarımı büyük olasılıkla vardır ve envanterini çıkarmadan kapatamazsınız.

Aktarımın kendisi kadar üzerinden geçtiği yol da önemlidir; kuralların nasıl yazılacağı firewall kurulumu ve yönetimi tarafında, protokollerin birbirine nasıl bağlandığı ise kurumsal ağ protokolleri rehberinde 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ürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn