SFTP (Secure File Transfer Protocol) to sieciowy protokół komunikacyjny służący do bezpiecznego przesyłania plików między komputerami, który opiera całą swoją architekturę na technologii SSH do szyfrowania transmisji oraz danych logowania. Główna różnica polega na tym, że klasyczne FTP przesyła dane otwartym tekstem, FTPS dodaje do niego warstwę certyfikatów SSL/TLS, a SFTP to zupełnie inna technologia działająca w jednym, w pełni zaszyfrowanym kanale portu 22. My wdrożyliśmy ten standard na wszystkich maszynach po serii ataków na stare serwery w zeszłym roku.
Zrozumienie mechanizmów wymiany plików w sieciach komputerowych wymaga odrzucenia starych przyzwyczajeń. Administratorzy często mylą te trzy skróty. Traktują je jak synonimy. To poważny błąd. Każdy z tych protokołów działa na innej warstwie i wymaga innej konfiguracji zapory sieciowej.
Co to jest SFTP i jak dokładnie działa ten protokół?
SFTP nie ma technicznie nic wspólnego z oryginalnym protokołem FTP. Został zaprojektowany od zera przez grupę roboczą IETF jako rozszerzenie protokołu Secure Shell. Cała komunikacja między klientem a serwerem odbywa się wewnątrz bezpiecznego tunelu. Nikt z zewnątrz nie podejrzy przesyłanych paczek danych. Nikt nie przechwyci haseł.
Gdy nawiązujesz połączenie, maszyny wykonują tak zwany uścisk dłoni (handshake). Wymieniają się kluczami kryptograficznymi. Ustalają wspólny algorytm szyfrowania symetrycznego. Dopiero wtedy serwer pozwala na autoryzację użytkownika. Możesz zalogować się hasłem. Lepszym pomysłem jest użycie pary kluczy asymetrycznych. Po poprawnym uwierzytelnieniu klient zyskuje dostęp do systemu plików. Może listować katalogi, przenosić pliki, zmieniać ich uprawnienia. Wszystko to dzieje się wewnątrz jednego strumienia danych. To jest po prostu genialne w swojej prostocie.
Dlaczego port 22 jest tak ważny dla SFTP?
Zarządzanie regułami zapory sieciowej (firewall) przy tradycyjnych transferach to koszmar dla działów IT. Stare technologie wymagają otwierania wielu kanałów komunikacyjnych. SFTP rozwiązuje ten problem natychmiast. Używa wyłącznie portu 22. Ten sam port służy do przesyłania komend sterujących oraz samych danych binarne.
Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze z innymi protokołami? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Urządzenia NAT i routery brzegowe gubią pakiety, gdy serwer próbuje otworzyć losowy port do przesłania pliku w trybie pasywnym. SFTP omija ten problem. Jeden port wchodzi, jeden wychodzi. Administratorzy sieci uwielbiają to rozwiązanie, bo minimalizuje powierzchnię ataku i upraszcza audyty bezpieczeństwa.
Czym różni się SFTP od FTP i FTPS?
Porównanie tych trzech technologii najlepiej oprzeć na twardych parametrach konfiguracyjnych. Zestawienie pokazuje przepaść technologiczną między starym a nowym podejściem do transferu.
| Cecha | FTP (File Transfer Protocol) | FTPS (FTP over SSL/TLS) | SFTP (SSH File Transfer Protocol) |
| Szyfrowanie | Brak (Otwarty tekst) | Warstwa SSL/TLS | Natywne szyfrowanie SSH |
| Używane porty | Port 21 (komendy) + losowe porty danych | Port 21/990 + losowe porty danych | Tylko port 22 |
| Autoryzacja | Hasło (widoczne w sieci) | Hasło (zaszyfrowane) / Certyfikat | Hasło (zaszyfrowane) / Klucze SSH |
| Przyjazność dla NAT/Firewall | Bardzo niska | Niska | Bardzo wysoka |
FTP kontra SFTP – dlaczego stary standard musi umrzeć?
Korzystanie z protokołu FTP w otwartym internecie to proszenie się o włamanie. Protokół ten powstał w latach siedemdziesiątych. Wtedy nikt nie myślał o cyberbezpieczeństwie. Sieć była mała i hermetyczna. Dzisiaj przesłanie pliku przez FTP oznacza, że każdy węzeł pośredniczący między tobą a serwerem widzi twoje dane logowania. Wystarczy prosty sniffer sieciowy pokroju Wireshark. Atakujący przechwytuje pakiety, odczytuje login, odczytuje hasło. Koniec gry.
SFTP eliminuje ten wektor ataku w całości. Nawet jeśli ktoś nasłuchuje ruch w sieci, zobaczy tylko niezrozumiały ciąg zaszyfrowanych znaków. Nie pozna długości hasła. Nie dowie się, jakie nazwy noszą przesyłane pliki. Różnica polega na fizycznym braku możliwości podsłuchu bez posiadania klucza prywatnego.
FTPS kontra SFTP – który protokół szyfrowania wygrywa w firmie?
Ludzie z branży IT często wdają się w spory o wyższość FTPS nad SFTP. FTPS to po prostu stary protokół, do którego na siłę doklejono obsługę certyfikatów TLS. Działa to na podobnej zasadzie co protokół HTTPS w przeglądarkach. Szyfruje kanał komend i kanał danych. Problem w tym, że wciąż dziedziczy wszystkie wady architektoniczne swojego poprzednika.
FTPS nadal wymaga otwierania szerokiego zakresu portów pasywnych na zaporze (często od 50000 do 51000). Gdy klient zza firmowego NAT-u próbuje nawiązać połączenie danych, router często blokuje ten ruch, bo nie potrafi zajrzeć do zaszyfrowanego kanału sterującego, by sprawdzić, jaki port został wynegocjowany. SFTP niszczy FTPS pod kątem wygody wdrożenia. Działa na jednym porcie. Nie wymaga skomplikowanej translacji adresów. Wykorzystuje potężną infrastrukturę OpenSSH, która jest domyślnie instalowana w każdym systemie z rodziny Linux i Unix.
Jakie są realne koszty i problemy przy wdrożeniu SFTP?
Pamiętam doskonale wdrożenie z zeszłego roku dla małej hurtowni na warszawskim Targówku. Szef IT upierał się przy FTPS, bo „przecież mają wdrożone certyfikaty”. Skonfigurowaliśmy zaporę na brzegu sieci. Dwa dni później dzwoni z pretensjami, że klienci z zewnątrz nie mogą w ogóle pobrać cenników w formacie XML. Dlaczego? Bo routery operatora internetowego wycinały losowe porty pasywne w locie. Przerzuciliśmy całą architekturę na SFTP i port 22 w jedno popołudnie. Prawda jest zresztą absolutnie taka, że ludzie komplikują sobie życie na własne życzenie, trzymając się starych standardów, bo boją się czarnej konsoli Linuxa. To był dramat.
Koszty finansowe przejścia na nowy protokół są właściwie zerowe. Oprogramowanie serwerowe OpenSSH jest darmowe. Klienci tacy jak WinSCP czy FileZilla udostępnia się na licencjach open source. Prawdziwym kosztem jest czas poświęcony na edukację pracowników i wygenerowanie bezpiecznych kluczy dostępowych. Musisz nauczyć zespół, że logowanie hasłem to przeszłość.
Jak wygenerować i podpiąć klucze SSH do SFTP?
Przejście na logowanie kluczem asymetrycznym to najważniejszy krok w zabezpieczaniu serwera. Proces jest bezpośredni i nie wymaga specjalistycznej wiedzy z zakresu kryptografii. Wymaga tylko dokładności w kopiowaniu ciągów znaków.
- Używasz polecenia
ssh-keygen -t ed25519na swoim komputerze. To generuje nowoczesną, silną parę kluczy. Klucz prywatny zostaje u ciebie na dysku twardym i nigdy go nikomu nie wysyłasz. - Kopiujesz wygenerowany klucz publiczny na serwer docelowy do pliku
~/.ssh/authorized_keysza pomocą komendyssh-copy-id - Otwierasz plik konfiguracyjny
sshd_configna serwerze, odnajdujesz dyrektywęPasswordAuthenticationi zmieniasz jej wartość nano. To ostatecznie odcina możliwość logowania się za pomocą zwykłego hasła. - Restartujesz usługę systemową, żeby serwer zaciągnął nowe reguły
Od tego momentu serwer odrzuca każdą próbę połączenia bez ważnego klucza prywatnego. Boty skanujące sieć odbijają się od ściany. Twoje dane są bezpieczne.
Czy SFTP spowalnia transfer plików względem zwykłego FTP?
Wielu menedżerów pyta mnie o wydajność. Obawiają się, że narzut na szyfrowanie każdego bajtu danych spowolni działanie systemów wymiany plików. Technicznie rzecz biorąc, SFTP generuje większy narzut obliczeniowy niż transmisja otwartym tekstem. Procesor musi zaszyfrować dane po stronie nadawcy i odszyfrować je po stronie odbiorcy.
W praktyce ten problem przestał istnieć dekadę temu. Współczesne procesory posiadają sprzętową akcelerację instrukcji kryptograficznych (AES-NI). Zwykły, tani serwer potrafi szyfrować ruch z prędkością przekraczającą przepustowość łączy gigabitowych. Ograniczeniem staje się prędkość zapisu na dysku twardym, a nie sam protokół. W naszych testach różnica w czasie przesyłania paczki o rozmiarze 10 GB między FTP a SFTP wynosiła bez mała zaledwie kilkanaście sekund. To akceptowalny koszt za całkowitą prywatność.
Kiedy powinieneś używać FTPS zamiast SFTP?
W zdecydowanej większości projektów wybierasz SFTP. Są jednak specyficzne scenariusze, w których stary FTPS wygrywa. Zazwyczaj dotyczy to środowisk korporacyjnych opartych na archaicznych systemach typu mainframe. Maszyny IBM często posiadają natywne wsparcie dla FTPS wbudowane głęboko w system operacyjny, podczas gdy instalacja demona SSH bywa tam kłopotliwa.
Drugim powodem są wymogi prawne i audytowe w niektórych sektorach bankowych. FTPS korzysta z certyfikatów X.509 wystawianych przez zaufane urzędy certyfikacji (CA). Audytor może łatwo sprawdzić ścieżkę zaufania certyfikatu. W SFTP zarządzanie kluczami publicznymi opiera się na modelu zaufania bezpośredniego, co w ogromnych organizacjach bez centralnego systemu zarządzania kluczami (PKI) generuje bałagan administracyjny. Poza tymi rzadkimi wyjątkami, FTPS należy unikać.
Jakie oprogramowanie klienta i serwera wybrać do transferu?
Rynek oferuje narzędzia dla każdego systemu operacyjnego. Po stronie serwera króluje OpenSSH. Jest bezkonkurencyjny, stabilny i wbudowany w niemal każdą dystrybucję Linuxa. Jeśli używasz Windows Server, Microsoft również dostarcza port OpenSSH jako opcjonalną funkcję systemu.
Klienci z kolei mają szeroki wybór darmowych programów z interfejsem graficznym. WinSCP to narzędzie ostateczne dla systemu Windows. Obsługuje menedżera haseł, potrafi wznawiać przerwane transfery i posiada wbudowany edytor tekstu. FileZilla działa na wszystkich platformach, choć jej domyślne ustawienia zapamiętywania haseł otwartym tekstem na dysku budzą moje poważne zastrzeżenia. Dla użytkowników macOS naturalnym wyborem jest Cyberduck. Posiada świetną integrację z systemowym pękiem kluczy.
Ważne jest to, by zawsze weryfikować odcisk palca serwera (fingerprint) przy pierwszym połączeniu. Program wyświetli ci ciąg znaków i zapyta, czy ufasz tej maszynie. Jeśli zaakceptujesz fałszywy odcisk palca, padniesz ofiarą ataku Man-in-the-Middle. Zawsze sprawdzaj ten ciąg z administratorem serwera z innego kanału komunikacji. Żadna technologia nie uchroni użytkownika przed jego własnym błędem.
Wyzwanie końcowe
Zaloguj się teraz na swój firmowy serwer. Sprawdź, czy port 21 jest otwarty i nasłuchuje. Jeśli tak, masz poważną dziurę w polityce bezpieczeństwa. Zablokuj go na zaporze. Przenieś wszystkie skrypty automatyzujące backupy i wymianę danych z kontrahentami na port 22.
Generowanie kluczy asymetrycznych zajmuje minutę. Wdrożenie chrootowania w pliku sshd_config, by zamknąć użytkowników w ich domowych katalogach bez dostępu do konsoli, zajmuje kolejne pięć minut. Nie masz wymówek. Zostawienie starego FTP w sieci to dowód na ignorancję, która prędzej czy później skończy się wyciekiem bazy klientów i interwencją urzędu nadzorującego dane osobowe. Zrób to po prostu dzisiaj.
Najczęściej zadawane pytania
-
Czy SFTP i FTPS to to samo?
Nie. SFTP to protokół oparty na architekturze SSH działający na jednym porcie (22). FTPS to stary protokół FTP z dodaną warstwą szyfrowania SSL/TLS, który wciąż wymaga używania wielu portów do transferu danych. -
Jaki port wykorzystuje SFTP?
SFTP domyślnie wykorzystuje port 22 TCP. Cała komunikacja, zarówno przesyłanie komend, jak i samych plików, odbywa się wyłącznie przez ten jeden kanał. -
Czy można używać SFTP przez przeglądarkę internetową?
Standardowe przeglądarki internetowe nie obsługują natywnie protokołu SFTP. Wymagane jest zainstalowanie dedykowanego klienta, takiego jak WinSCP, FileZilla lub Cyberduck. -
Co jest bezpieczniejsze: klucze SSH czy hasło w SFTP?
Zdecydowanie klucze SSH. Hasło można odgadnąć za pomocą ataku brute-force. Klucz prywatny jest matematycznie niemożliwy do złamania z zewnątrz. -
Czy FileZilla obsługuje SFTP?
Tak, FileZilla w pełni obsługuje ten protokół. Wystarczy podać port 22 w oknie połączenia. -
Jak zablokować dostęp do powłoki, zostawiając tylko transfer plików?
W pliku sshd_config użyj dyrektywy ForceCommand internal-sftp oraz parametru ChrootDirectory. To uniemożliwia uruchamianie złośliwych komend na serwerze.
Bibliografia
1. Naukowa i Akademicka Sieć Komputerowa – https://www.nask.pl
2. CERT Polska – https://cert.pl
3. OpenSSH – https://www.openssh.com
4. Internet Engineering Task Force – https://www.ietf.org
5. Niebezpiecznik – https://niebezpiecznik.pl
