FTP vs SFTP: Güvenli dosya transferi için net rehber

Dosya transferi günlük bir ihtiyaç olsa da yöntem seçimi doğrudan güvenliğe etki eder. FTP şifresiz çalıştığı için veri yolunda dinlemeye açıktır; SFTP ise güvenli tünelleme mantığıyla istemci ile sunucu arasındaki aktarımı korur. Bu rehberde, FTP ve SFTP’yi yalnızca tanımlamak yerine pratikte hangi durumda hangisini seçeceğinizi, hangi ayarların kritik olduğunu ve nasıl test edeceğinizi net bir akışla göreceksiniz.

FTP mi SFTP mi? Temel farklar ve risk tablosu

FTP (File Transfer Protocol), kontrol kanalını ve kullanıcı parolasını genellikle şifrelemeden iletir. Bu yüzden ağ içinde paket yakalama (packet sniffing) ile kimlik bilgilerinin ve dosyaların ele geçirilmesi riski doğar. SFTP (SSH File Transfer Protocol) ise SSH üzerinden çalışır; aktarım sırasında veriler şifrelenir.

Aşağıdaki tablo karar verirken işinize yarayacak net kıyasları toplar:

Ne zaman FTP hâlâ görülür?

FTP; eski sistemler, belirli cihazlar veya otomasyonlar yüzünden karşınıza çıkabilir. Burada net yaklaşım şudur: FTP’yi yalnızca erişim katı şekilde kısıtlanmış (ör. sadece iç ağ/VPN) ortamlarda ve geçici geçiş sürecinde düşünün. Dışarıdan erişen, internet üzerinden çalışan veya kullanıcı parolalarını içeriden dışarıya taşıyan yapıların FTP ile tutulması güvenlik açısından uygun değildir.

Portlar, firewall ve bağlantı testleri: operasyonel farklar

SFTP ve FTP’nin pratik farkı sadece şifreleme değil; bağlantı kurulumu ve ağ cihazlarında oluşturduğu ihtiyacı da kapsar.

FTP’nin port davranışı (neden daha fazla sürpriz çıkarır?)

FTP iki yönlü çalıştığı için (kontrol + veri) çoğu senaryoda birden fazla port devreye girer: - Kontrol için 21 - Veri aktarımı için pasif (Passive) modda belirli bir port aralığı

Firewall’larda NAT (Network Address Translation) veya stateful kurallar yanlış yapılandırılırsa, istemci dosyayı alamaz; çoğu durumda “giriş yaptım ama listeleme/indirirken takılıyor” gibi bir semptom görürsünüz.

SFTP’nin port davranışı (daha deterministik)

SFTP genellikle 22 portunda çalışır. Bu, firewall ve erişim listelerini sadeleştirir. Ayrıca “pasif port aralığı” gibi FTP’nin getirdiği karmaşıklık azalır.

Net test: erişilebilirlik kontrolü

Sunucu tarafında şu kontrolleri uygulayın: - SFTP için: 22 portu hedef sunucuda açık mı? - FTP için: 21 açık mı ve pasif port aralığı doğru mu? - İnceleme için loglara bakın: “bağlantı kuruldu mu, kimlik doğrulama geldi mi, dosya aktarma denemesi var mı?”

Örnek bağlantı testleri (istemci tarafında): - SFTP: sftp user@sunucu-ip - Basit kontrol için SSH: ssh user@sunucu-ip

Not: Port testleri için isterseniz telnet kullanmak yerine güvenlik açığından nc (netcat) gibi araçlar daha doğru olur. Örneğin: nc -vz sunucu-ip 22.

Kimlik doğrulama güvenliği: parola mı anahtar mı?

Güvenli dosya transferinde asıl ayrım, yalnızca protokolün şifreli olması değil; kimlik doğrulamanın nasıl yapıldığıdır.

FTP’de parola yönetimi neyi değiştirir?

FTP’de parola, şifrelenmeden iletilebildiği için ağ trafiğini gören biri için risk oluşturur. Ek olarak FTP sunucuları çoğu zaman brute-force denemelerine karşı aynı sertlikte ayarlanmaz. Bu nedenle FTP’yi zorunlu tutmanız halinde dahi ağ erişimini (IP allowlist, VPN) ve hız limitlerini (rate limit) mutlaka uygulamanız gerekir.

SFTP’de SSH anahtarı neden net şekilde daha iyidir?

SFTP ile SSH key (anahtar) kullanmak parola yerine anahtar bazlı kimlik sağlar. Pratik avantajlar: - Parolanın ağ üzerinde ele geçirilmesi riskini büyük ölçüde azaltır - Anahtar rotasyonu ve erişim seviyeleri daha kontrollüdür - Otomasyonlarda tekrarlayan parola kullanımını azaltır

Sunucu ayarları: SFTP’yi “doğru” kurmak için kontrol listesi

SFTP’yi kurduğunuzda hedef, sadece bağlanabilmek değil; saldırı yüzeyini azaltmak ve hatalı yapılandırmayı engellemektir.

1) Kullanıcı izolasyonu ve dizin kısıtı

SFTP’de kullanıcıların yalnızca gerekli klasörleri görmesi gerekir. En sık kullanılan yaklaşım: - Kullanıcıyı ilgili home dizinine hapsedin (chroot mantığı veya benzeri) - Dosya ağacını “tam disk” yerine proje dizinine kilitleyin

Bu sayede yanlış yetkiyle tüm sunucu dosyaları üzerinde işlem riski düşer.

2) Yetkilendirme: least privilege (en düşük yetki)

• Gerekliyse yazma (write) izni verin
• Okuma (read) yeterliyse sadece okuma izinleri kullanın
• Sistem dizinlerine erişimi kapatın

3) Şifreleme algoritması ve oturum sertliği

SSH tarafında: - Eski algoritmaları devre dışı bırakın - Oturum tekrar denemeleri ve zaman aşımı politikalarını netleştirin

Bu adım, “SFTP var ama hâlâ zayıf ayarlarla korunmasız” senaryosunu engeller.

4) Loglama ve izleme

FTP ve SFTP’de loglar güvenliği ölçmenin tek yoludur. Net hedefler: - Kimlik doğrulama denemeleri (başarılı/başarısız) - IP bazlı deneme sayıları - Dosya yükleme/indirme olayları

FTP’de de loglar vardır; ancak FTP’nin riskli olması nedeniyle öncelik SFTP loglarını incelemektir.

5) Hız limitleri ve brute-force koruması

SFTP/SSH için mutlaka: - Fail2ban benzeri mekanizmaları değerlendirin - Yanlış şifre denemelerinde otomatik engelleme politikası tanımlayın

FTP’yi devrede tutmak zorunda kalırsanız: minimum güvenlik seti

FTP’yi tamamen kaldırmak pratikte her zaman hemen mümkün olmayabilir. Bu durumda amaç, FTP’nin riskini azaltmaktır.

Aşağıdaki “minimum güvenlik seti” net bir gereklilik listesi gibi düşünülmelidir: - İnternetten direkt erişimi kapatın; VPN veya allowlist ile sınırlayın - Parola denemeleri için brute-force koruması ekleyin - Pasif port aralığını daraltın (firewall’da port sayısını büyütmeyin) - Dosya izinlerini sadece gerekli kullanıcıya verin - Dönüşüm planı yapın: SFTP’ye geçiş tarihini ve adımlarını dokümante edin

Eğer FTP’nin yerine geçebilecek FTPS (TLS’li FTP) seçeneğiniz varsa, “şifreleme yok” riskini kaldırdığı için değerlendirme önceliği doğar. Ancak pratikte SFTP daha sade yönetilir.

SFTP nasıl daha “net” yönetilir? Performans ve hata senaryoları

SFTP’nin davranışı çoğu sistemde daha öngörülebilir olduğu için operasyon yönetimi kolaylaşır.

Yaygın hata: “Bağlandım ama dosya yüklenmiyor”

Bu durumda tipik kök nedenler şunlardır: - Hapsedilen dizinin dışında yazma izni yoktur - Kullanıcı için doğru izin verilmemiştir - Disk kotası dolmuştur - Hedef klasör yoktur veya yetkisi yoktur

Net kontrol akışı: 1) SFTP kullanıcısının home dizini ve chroot/haps profili 2) Hedef klasör izinleri (UID/GID) 3) Disk ve inode kotası 4) Sunucu loglarında “permission denied” kayıtları

Yaygın hata: “FTP’de liste var ama transfer kopuyor”

FTP’nin pasif port sorunları en sık nedendir. Net yaklaşım: - Pasif port aralığını firewall’da açtığınızdan emin olun - NAT arkasındaki sunucuda FTP’nin doğru dış IP bilgisini paylaştığından emin olun - İstemci modunu (passive/active) doğru seçin

NetKıyas bakışı: doğru protokol seçimi hangi kriterlerle yapılır?

Hosting/servis seçerken protokol desteği, sadece “var/yok” değil; yönetilebilirlik ve güvenlik seçenekleriyle ölçülür.

Aşağıdaki kriterler, VDS/VPS ya da web hosting seçiminde kararınızı netleştirir: - Sunucu üzerinde SFTP/SSH erişimi var mı? - Kullanıcı bazlı erişim kısıtı ve dizin hapsi (chroot benzeri) destekleniyor mu? - Loglar (kimlik doğrulama + dosya aktarımları) hangi seviyede tutuluyor? - Firewall yönetimi veya IP allowlist uygulanabiliyor mu? - Otomasyon için anahtar bazlı erişim mümkün mü?

Sonuç: FTP yerine SFTP’yi “varsayılan” yapın, riskli istisnaları planlayın

Güvenli dosya transferinde net sonuç şudur: İnternet üzerinden dosya aktarımı yapan her senaryoda SFTP varsayılan tercih olmalıdır. FTP yalnızca geçici, erişimi daraltılmış ve geçiş planı olan durumlarda kullanılmalıdır. Eğer hâlihazırda FTP kullanıyorsanız, sıradaki aksiyonunuz SFTP’ye geçişi planlamak (kullanıcı izolasyonu + anahtar bazlı kimlik + log kontrolü) ve FTP erişimini internetten kapatarak riski azaltmak olmalıdır.

İsterseniz bir sonraki adım olarak, kullandığınız istemci (FileZilla, WinSCP vb.) ve sunucu türünü (VPS/VDS/web hosting) söyleyin; ben de net bir geçiş kontrol listesi çıkarayım.