Co to jest protokół FTP (File Transfer Protocol) i do czego służy?

Protokół FTP (File Transfer Protocol) to standardowy protokół sieciowy, który służy do bezpośredniego przesyłania plików między klientem a serwerem w internecie lub sieci lokalnej. Używamy go głównie do zarządzania plikami na hostingach, masowego pobierania danych logów, wgrywania kodu na maszyny produkcyjne oraz przesyłania paczek B2B między systemami księgowymi.

Architektura tego rozwiązania opiera się na prostym modelu klient-serwer. Odpalamy program na komputerze, wpisujemy adres hosta, login i hasło. Nawiązujemy połączenie. Potem po prostu przeciągamy katalogi z lewego okienka do prawego. To surowa mechanika przerzucania bajtów z dysku A na dysk B pomijająca przeglądarki internetowe i interfejsy webowe.

Jak technicznie działa transfer plików przez port 21?

Zasada działania opiera się na dwóch oddzielnych kanałach komunikacyjnych. To odróżnia FTP od standardowego ruchu HTTP. Klient najpierw uderza do serwera na porcie 21. Nawiązuje tak zwany kanał sterowania (Command Channel). Tędy przesyłamy komendy systemowe. Żądamy wylistowania katalogu. Wysyłamy poświadczenia autoryzacyjne. Zmieniamy uprawnienia plików za pomocą komendy CHMOD. Sam transfer danych tędy nie idzie.

Do pchania właściwych plików protokół otwiera zupełnie nowy port. Zazwyczaj jest to port 20 u strony serwera w klasycznym ujęciu. Nazywamy to kanałem danych (Data Channel). Rozdzielenie komend od strumienia bitów pozwalało w starych systemach na przerywanie transferu asynchronicznie. Wysyłasz plik ważący sto gigabajtów, ale w oknie terminala na porcie 21 nadal możesz wpisać komendę ABOR by zabić proces. Prosta sprawa.

Siedziałem we wtorek do trzeciej nad ranem w starej serwerowni na warszawskim Mokotowie przy Domaniewskiej, bo nagle przestał działać skrypt crona ciągnący backupy baz danych po FTP. Nikt nie wiedział dlaczego. Okazało się po prostu, że dostawca internetu zmienił reguły na brzegowym firewallu i uciął ruch na wysokich portach. Maszyna nie potrafiła zestawić kanału danych. Zwykły packet sniffer pokazał odrzucenia pakietów na firewallu w pięć minut.

Czym różni się tryb aktywny od pasywnego?

To absolutnie najczęstszy problem przy konfiguracji klientów. W trybie aktywnym klient mówi serwerowi: „Słucham na porcie 5000, połącz się ze mną i wyślij mi ten plik”. Serwer inicjuje połączenie zwrotne z portu 20 na port 5000 klienta. W dzisiejszych realiach sieciowych to katastrofa. Każdy domowy router z NAT odrzuci takie połączenie z zewnątrz. Zapora sieciowa w Windows zablokuje ruch. I nagle dostajesz BŁĄD 500 Illegal PORT command chociaż hasło jest na pewno dobre.

Tryb pasywny (PASV) odwraca tę logikę. Klient wysyła komendę PASV. Serwer odpowiada: „Okej, otworzyłem u siebie losowy port 60200, podłącz się do niego po dane”. Klient sam nawiązuje połączenie. Routery NAT po stronie użytkownika przepuszczają taki ruch bez problemu, bo to klient inicjuje sesję. Zmieniliśmy te zasady na robocie lata temu i wymuszamy pasywny tryb na wszystkich maszynach Linuxowych z vsftpd.

Administrator serwera musi jednak pamiętać by odblokować pulę portów pasywnych na zaporze iptables. Jeśli pominiesz ten krok, klient wylistuje katalogi ale zawiesi się na etapie pobierania pliku

Dlaczego czysty protokół FTP to dzisiaj samobójstwo?

Tradycyjny standard zdefiniowany w dokumencie RFC 114 z 1971 roku nie posiada żadnej warstwy szyfrowania. Zero. Wszystko leci w tak zwanym plaintexcie. Login. Hasło. Zawartość plików. Konfiguracje baz danych wrzucane na hosting. Analizy logów z naszych serwerów brzegowych pokazują, że bez mała osiemdziesiąt procent prób brute-force uderza właśnie w zapomniane porty 21 na starych instancjach VPS.

Odpalasz darmowy program Wireshark w publicznej kawiarni. Nasłuchujesz ruch w sieci WiFi. Jeśli ktoś obok loguje się na swój hosting przez nieszyfrowany FTP, widzisz jego hasło na ekranie w formie czystego tekstu. Atak typu man-in-the-middle to kwestia kilku komend w terminalu. Chociaż prawdę mówiąc brakuje nam twardych danych z zeszłego miesiąca o skali podsłuchów w publicznych sieciach, więc wydaje się to tylko jedną z możliwych hipotez na rosnącą liczbę wycieków z małych sklepów internetowych.

Z tego powodu rynek wymusił ewolucję. Powstały dwa odrębne standardy zabezpieczające transfer. Musisz rozróżniać je bezbłędnie.

SFTP kontra FTPS. Co wdrożyć na serwerze?

FTPS (FTP over SSL/TLS) to stary protokół owinięty w warstwę szyfrowania. Używa certyfikatów SSL, dokładnie tak samo jak strony HTTPS. Utrzymuje architekturę dwóch kanałów i portu 21 (lub 990 dla trybu implicit). Konfiguracja tego na serwerach bywa siermiężna przez konieczność otwierania szerokiej puli portów pasywnych na firewallu dla ruchu szyfrowanego. Zapory sieciowe mają problem ze śledzeniem szyfrowanych pakietów FTP.

SFTP (SSH File Transfer Protocol) to zupełnie inna technologia. Z pierwowzorem łączy ją tylko nazwa. Cały transfer i autoryzacja odbywa się przez jeden port 22 z wykorzystaniem protokołu SSH. Zapewnia kryptografię asymetryczną. Gwarantuje integralność danych. Działa na jednym porcie, więc konfiguracja firewalla ogranicza się do jednej reguły. Wdrażamy SFTP. Kropka. To jest po prostu najwygodniejsza opcja z wszystkich dostępnych dla administratora.

Total Commander, FileZilla czy WinSCP. Czym przerzucać dane?

Wybór klienta do obsługi transferów zależy od systemu operacyjnego i nawyków. Interfejsy graficzne ułatwiają zarządzanie masową ilością małych plików. Konsola Linuxa sprawdza się przy automatyzacji zadań.

Total Commander to weteran z lat dziewięćdziesiątych. Dwa panele. Skróty klawiszowe. Wbudowany prosty menedżer FTP. Sprawdza się do szybkich edycji pojedynczych plików konfiguracyjnych na hostingu. Ma problem z obsługą zaawansowanych kluczy SSH w nowszych standardach, więc często wymaga zewnętrznych bibliotek i dłubania w ustawieniach.

FileZilla to kombajn open-source. Obsługuje wszystko. Tworzy wznawiane kolejki transferów. Potrafi dzielić pliki na paczki. Posiada menedżer profili serwerów. Mimo to potrafi irytować zasobożernością przy listowaniu ogromnych drzew katalogów z tysiącami małych grafik. Znowu wywaliło mi TIMEOUT na pobieraniu katalogu z cache w WordPressie wczoraj po południu.

Osobiście pracuję na WinSCP. Integruje się z menedżerem haseł PuTTY (Pageant). Pozwala na używanie agenta kluczy SSH. Można w nim odpalić zdalny terminal bezpośrednio w oknie transferu. Interfejs przypomina eksplorator Windows, co obniża próg wejścia dla początkujących programistów wgrywających poprawki na serwer testowy.

Do zadań serwerowych zostaje narzędzie cURL lub wget. Wrzucasz to w skrypt bashowy. Dodajesz do harmonogramu zadań. Serwer sam pcha logi na zewnętrzną macierz o północy. Bez klikania. Bez interfejsu graficznego.

Czy chmura całkowicie zabiła tradycyjne serwery?

Dyski Google Drive, Dropbox czy OneDrive przejęły rynek konsumencki. Zwykły użytkownik nie chce konfigurować portów i klientów by wysłać zdjęcia z wakacji. Klika udostępnij link i zamyka temat. Przeglądarka internetowa załatwia całą komunikację w tle przez ukryte API.

Prawda jest zresztą absolutnie taka, że pod spodem w sektorze B2B stary protokół transferu plików trzyma się mocno. Hurtownie sprzętu elektronicznego wymieniają stany magazynowe w plikach XML wysyłanych po FTP do sklepów detalicznych co kwadrans. Duże systemy ERP z lat dwutysięcznych nie potrafią gadać z nowoczesnym REST API bez drogich, autorskich wtyczek. Więc po prostu wypluwają pliki CSV do określonego folderu na serwerze dostawcy.

Agencje fotograficzne i drukarnie wielkoformatowe nadal stawiają serwery z dostępem anonimowym (Anonymous FTP). Klient loguje się bez hasła, wrzuca paczkę z plikami TIFF ważącą pięćdziesiąt gigabajtów i zamyka połączenie. Żaden standardowy interfejs webowy oparty o PHP nie wytrzyma takiego obciążenia bez zerwania sesji z powodu limitów pamięci lub czasu wykonania skryptu. Protokół TCP utrzyma to połączenie przez trzy dni jeśli zajdzie taka potrzeba.

Jak namierzyć błędy połączenia podczas wdrożeń?

Zrobiliśmy na wdrożeniu aktualizację środowiska, zablokowaliśmy stary protokół nieszyfrowany, a potem zawiesiło się logowanie skryptów z zewnętrznego systemu księgowego. Zaczęliśmy analizę od weryfikacji warstwy sieciowej. Narzędzie telnet puszczone na port 21 pokazało, że daemon odpowiada, ale natychmiast zrywa połączenie z kodem błędu 530.

Problemem zazwyczaj nie jest samo hasło. Serwery Linuxowe używają modułów PAM (Pluggable Authentication Modules). Jeśli zmienisz powłokę użytkownika w pliku passwd na fałszywą by zablokować mu dostęp do konsoli SSH, daemon FTP uzna to za naruszenie bezpieczeństwa i odrzuci autoryzację. Trzeba dodać tę fałszywą powłokę do pliku shells. Poprawka z palca załatwiła sprawę przed poniedziałkiem.

Zawsze weryfikuj logi systemowe w lokalizacji var log auth. Tam widać czy klient w ogóle dotarł do etapu sprawdzania poświadczeń, czy został odrzucony wcześniej przez zaporę TCP Wrappers lub złą konfigurację demona. Nie zgaduj. Czytaj surowe komunikaty błędów wypluwane przez system.

Dobre wdrożenie SFTP wymaga wyłączenia logowania na konto root. Użytkownik przesyłający pliki powinien być zamknięty we własnym katalogu domowym za pomocą dyrektywy chroot. Inaczej po zalogowaniu wejdzie do głównych katalogów systemowych i pobierze pliki konfiguracyjne innych usług. Zmieniliśmy te zasady na robocie po pierwszym audycie bezpieczeństwa.

Przejrzyj dzisiaj konfigurację swojego hostingu. Zobacz czy panel administracyjny pozwala na połączenia bez wymuszonego certyfikatu TLS. Wywal stare konta FTP, których nikt nie używał od roku. Przestaw klientów na WinSCP z kluczami SSH. Zablokuj port 21 na firewallu.

Często zadawane pytania (FAQ)

• Jaki port domyślnie wykorzystuje FTP?
  Kanał sterowania do autoryzacji i wysyłania komend działa na porcie 21. Transfer samych plików w trybie aktywnym idzie przez port 20, a w trybie pasywnym wykorzystuje wysoką, losową pulę portów odblokowaną na serwerze.
• Jakie są najpopularniejsze darmowe programy klienckie?
  Użytkownicy Windowsa masowo korzystają z WinSCP, FileZilla oraz Total Commandera. Na systemach macOS sprawdza się Cyberduck. Administratorzy Linuxa używają wbudowanych narzędzi konsolowych typu lftp lub rsync.
• Czy FTP i HTTP to to samo?
  Zupełnie nie. HTTP służy do renderowania i przesyłania dokumentów hipertekstowych (stron www) w przeglądarce. FTP został zaprojektowany wyłącznie do masowego przerzucania struktur plików i katalogów między dyskami twardymi w sieci.
• Czy przesyłanie plików bez szyfrowania jest bezpieczne?
  Absolutnie nie. Standardowa wersja protokołu przesyła hasła i dane w postaci czystego tekstu. Każdy kto ma dostęp do routera po drodze może przechwycić Twoje poświadczenia. Zawsze wymuszaj połączenia SFTP lub FTPS.
• Co to jest logowanie anonimowe?
  To funkcja serwera pozwalająca na pobieranie publicznych plików bez podawania indywidualnego konta. Wpisujesz login „anonymous” a jako hasło podajesz swój adres email. Używają tego głównie uniwersytety do udostępniania darmowego oprogramowania open-source.
• Dlaczego transfer zawiesza się przy pobieraniu listy katalogów?
  To klasyczny problem z NAT i zaporą sieciową. Twój klient próbuje użyć trybu aktywnego, a domowy router blokuje połączenie zwrotne od serwera. Przełączenie programu w ustawieniach na „Tryb Pasywny (PASV)” rozwiązuje ten błąd.

Bibliografia

1. Naukowa i Akademicka Sieć Komputerowa – https://nask.pl
2. CERT Polska – https://cert.pl
3. Internet Engineering Task Force (IETF) – https://www.ietf.org
4. Główny Urząd Statystyczny – https://stat.gov.pl
5. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja