Co to jest FTPS i jak zapewnia bezpieczny transfer plików?

FTPS (File Transfer Protocol Secure) to rozszerzenie standardowego protokołu FTP o warstwę szyfrowania TLS lub dawniej SSL. Zapewnia bezpieczny transfer plików poprzez kryptograficzne zabezpieczenie kanału sterowania i kanału przesyłu danych, co uniemożliwia podsłuchanie haseł oraz przechwycenie ładunku w sieci. Prawda jest zresztą absolutnie taka, że bez tej warstwy wysyłasz swoje pakiety otwartym tekstem prosto w ręce każdego, kto w danej chwili analizuje ruch na routerze brzegowym. To gigantyczny błąd.

W 2019 roku robiliśmy migrację starego serwera w małej, ciasnej serwerowni na krakowskim Kazimierzu. Stary demon FTP działał tam od dekady bez żadnej modyfikacji. Ktoś z zewnątrz po prostu podpiął prostego sniffera pod switcha wpiętego do głównej szafy rackowej w piwnicy budynku. Hasła administratorów latały jawnym tekstem przez wiele miesięcy. Wdrożyliśmy FTPS w trybie Explicit w jedno popołudnie. Problem zniknął natychmiast. Zmieniliśmy te zasady na robocie i zablokowaliśmy ruch nieszyfrowany. Nikt nie miał już wglądu w to, co dokładnie pobierają użytkownicy z zewnątrz.

Jakie są główne różnice między FTP a FTPS w praktyce?

Czysty protokół FTP zdefiniowano w czasach, gdy nikt nie myślał o złośliwych atakach w sieciach rozległych. Wysyła on komendy, loginy i same pliki jako zwykły ciąg znaków ASCII. FTPS nakłada na ten przestarzały mechanizm gruby pancerz w postaci protokołu Transport Layer Security (TLS). Kiedy twój klient nawiązuje połączenie, serwer najpierw przedstawia swój certyfikat tożsamości. Dopiero po matematycznym potwierdzeniu autentyczności obie strony ustalają wspólny klucz sesji. Od tego momentu każda ramka danych jest szyfrowana. Nawet jeśli dostawca internetu nagrywa twój ruch, zobaczy tylko niezrozumiały szum kryptograficzny.

Widziałem wiele wdrożeń, gdzie administratorzy zostawiali otwarty port 21 bez wymuszania szyfrowania. Użytkownik łączy się z serwerem, wklepuje swoje dane uwierzytelniające i nagle cały system upada pod kątem bezpieczeństwa. Uruchomienie FTPS wymaga wymuszenia komendy AUTH TLS na serwerze. Jeśli klient jej nie wyśle, serwer po prostu ODRZUCA połączenie z błędem autoryzacji. Odrzucamy bez mała dziewięćdziesiąt procent starych klientów FTP, którzy nie potrafią dogadać się po nowoczesnych protokołach z szyfrem.

Dlaczego porty 990 i 21 sprawiają tyle problemów administratorom sieci?

W świecie FTPS mamy dwa zupełnie odrębne tryby nawiązywania bezpiecznej sesji. Różnią się one mechaniką działania na samym początku negocjacji. To właśnie one powodują najwięcej frustracji u techników próbujących spinać to na firewallu firmowym o trzeciej nad ranem.

Tryb Implicit to obecnie relikt przeszłości, chociaż wiele starych systemów bankowych nadal go wymaga. IANA (Internet Assigned Numbers Authority) wycofała oficjalne wsparcie dla portu 990 lata temu. Tryb Explicit wygrywa, bo pozwala obsługiwać starych i nowych klientów na jednym, dobrze znanym porcie 21. A jednak to właśnie Explicit potrafi wywalić błąd na restrykcyjnych zaporach, które głęboko analizują pakiety (Deep Packet Inspection) i głupieją, gdy tekstowy protokół nagle zmienia się w zaszyfrowany strumień binarny.

Czy FTPS i SFTP to ta sama technologia do przesyłania plików?

Absolutnie nie. To dwa zupełnie inne protokoły komunikacyjne zbudowane na różnych fundamentach matematycznych i architektonicznych. (Pomiędzy nami mówiąc, to niesamowite jak wielu ludzi z branży z uporem maniaka wrzuca do jednego worka SFTP i FTPS, kłócąc się na forach o porty, podczas gdy to dwa różne światy, a tłumaczenie tego po raz setny klientowi na helpdesku powoduje fizyczny ból głowy i chęć rzucenia klawiaturą o ścianę). Pora to raz na zawsze rozdzielić.

• SFTP (SSH File Transfer Protocol) to tak naprawdę podsystem usługi Secure Shell. Działa w całości na jednym porcie TCP, najczęściej 22. Nie ma tu żadnego oddzielnego kanału sterowania i kanału danych. SFTP jest łatwy do przepuszczenia przez NAT i routery brzegowe, bo wymaga otwarcia zaledwie jednej dziury w zaporze. Używa zupełnie innych komend pod spodem i nie ma nic wspólnego z oryginalnym kodem FTP z lat siedemdziesiątych.
• FTPS Explicit wymaga otwarcia portu 21 do nasłuchu komend, a następnie wynegocjowania szyfrowania. Serwer FTP używa oddzielnych portów do przesyłania samych danych (tryb pasywny). Jeśli zapora sieciowa nie ma wprowadzonych reguł dla trybu pasywnego, klient po prostu utknie na próbie pobrania listy plików z katalogu. Wtedy musisz ręcznie deklarować szeroki zakres portów pasywnych na serwerze, na przykład od 50000 do 51000, i przekierować je wprost na maszynę w sieci lokalnej
• Zarządzanie użytkownikami w SFTP opiera się często na systemowych kontach Linuxa lub kluczach RSA, podczas gdy serwery FTPS mają własne, wirtualne bazy użytkowników odcięte od systemu operacyjnego
• SFTP jest wolniejszy przy transferze ogromnych plików z powodu specyfiki działania okien TCP w protokole SSH

Wybór między nimi zależy od infrastruktury. Jeśli masz serwer z Windowsem i usługę IIS, FTPS postawisz w piętnaście minut. Jeśli pracujesz na klastrze maszyn z Debianem, po prostu używasz wbudowanego demona OpenSSH i masz gotowe SFTP bez instalowania dodatkowego oprogramowania. Zawsze dobieraj narzędzie pod system, na którym pracujesz.

Jak poprawnie skonfigurować certyfikaty SSL/TLS dla serwera FTPS?

Certyfikat to dowód osobisty twojego serwera. Bez niego klient nie wie, czy łączy się z twoją maszyną, czy z routerem hakera podszywającego się pod twój adres IP. Zastanawiacie się pewnie, dlaczego certyfikaty typu self-signed wywalają wielkie czerwone komunikaty o błędach w programie FileZilla. Sam się z tym biłem we wtorek na testowym środowisku. Klient FTP widzi certyfikat wygenerowany samodzielnie przez serwer, ale nie potrafi zweryfikować jego podpisu u żadnego zewnętrznego urzędu certyfikacji (Certificate Authority).

Więc konfiguracja upada na poziomie zaufania. Użytkownik widzi ostrzeżenie, klika „ignoruj” i uczy się złego nawyku ignorowania alertów bezpieczeństwa. Żeby tego uniknąć, podpinamy serwer pod darmowe certyfikaty od Let’s Encrypt. Większość nowoczesnych serwerów FTP, takich jak FileZilla Server czy ProFTPD, pozwala na wskazanie ścieżki do plików fullchain.pem oraz privkey.pem. Proces odnawiania certyfikatu co 90 dni można oskryptować za pomocą narzędzia Certbot, a następnie automatycznie restartować usługę FTP, żeby załadowała nowe klucze do pamięci RAM.

Czy starsze wersje TLS są nadal akceptowalne w środowisku biznesowym?

Nie. Protokół SSL w wersjach 2.0 i 3.0 został złamany lata temu. TLS 1.0 i 1.1 to obecnie dziurawe sita podatne na ataki typu POODLE czy BEAST. Zdecydowana większość audytorów bezpieczeństwa odrzuca systemy, które pozwalają na negocjację szyfru poniżej wersji TLS 1.2. Dobrym pomysłem jest wymuszenie na serwerze obsługi wyłącznie TLS 1.2 oraz najnowszego TLS 1.3.

Wdrożenie TLS 1.3 z algorytmem TLS_AES_256_GCM_SHA384 na starszych procesorach z rodziny Xeon potrafi podnieść obciążenie rdzeni o prawie trzydzieści procent przy bardzo intensywnym transferze wielu małych plików logów. Nie wierz w bajki o sprzętowym szyfrowaniu za darmo. Procesor musi to policzyć. Zawsze monitoruj obciążenie maszyny (użyj komendy htop lub Menedżera zadań) przez kilka dni po wyłączeniu starych algorytmów na środowisku produkcyjnym.

W jaki sposób mechanizmy szyfrowania chronią dane przed atakiem man-in-the-middle?

Atak man-in-the-middle (MITM) polega na tym, że intruz wchodzi w środek komunikacji między klientem a serwerem. W klasycznym FTP intruz przechwytuje pakiety, czyta login, hasło i pobiera kopię plików, a potem puszcza ruch dalej. Użytkownik niczego nie zauważa. FTPS blokuje to zjawisko na poziomie matematyki asymetrycznej. Mechanizm wymiany kluczy Diffiego-Hellmana pozwala obu stronom na wygenerowanie identycznego klucza symetrycznego, mimo że przesyłają przez sieć tylko matematyczne półprodukty.

Gdy intruz próbuje wciąć się w proces negocjacji TLS, musi podmienić certyfikat serwera na własny. Twój klient FTP natychmiast zauważy, że podpis kryptograficzny na fałszywym certyfikacie nie zgadza się z kluczem publicznym głównego urzędu certyfikacji. Zwróci błąd i przerwie próbę logowania. Zaufanie opiera się na matematyce krzywych eliptycznych, której nie da się złamać siłowo (brute-force) przy użyciu współczesnych komputerów. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed nadejściem komputerów kwantowych, które mogą ten stan rzeczy zmienić w ciągu dekady.

Jak obejść problemy z NAT i zaporami sieciowymi przy FTPS?

To jest bez mała najgorsza opcja z wszystkich problemów technicznych związanych z protokołem FTP. Standardowy FTP używał dziwacznej mechaniki: klient łączył się z serwerem na port 21, wysyłał komendę PORT ze swoim adresem IP, a serwer… próbował nawiązać połączenie zwrotne z klientem na porcie 20, by wysłać mu dane. W erze maskowania adresów (NAT) i ruterów domowych, serwer po prostu uderza w mur zaporowy dostawcy internetu u klienta.

Wymyślono tryb pasywny (PASV). W tym trybie klient mówi do serwera: „daj mi adres IP i port, na który mam się połączyć, żeby odebrać plik”. Serwer odpowiada: „połącz się na port 50123”. I tu zaczynają się schody przy FTPS. Zapora sieciowa przed serwerem widzi zaszyfrowany ruch na porcie 21. Nie potrafi zajrzeć do środka i przeczytać, jaki port pasywny wynegocjował serwer. Klient próbuje uderzyć na port 50123, ale zapora brzegowa odrzuca ten pakiet, bo nikt jej nie powiedział, że to legalny ruch FTP.

Co zrobić, gdy FileZilla zawiesza się na poleceniu MLSD (listowanie katalogów)?

Zawieszenie na komendzie MLSD lub LIST to sztandarowy objaw uciętego kanału danych. Kanał sterowania na porcie 21 działa poprawnie, autoryzacja przeszła, ale połączenie pasywne zderzyło się ze ścianą. Rozwiązanie tej usterki wymaga wykonania dwóch precyzyjnych kroków po stronie administratora serwera.

Po pierwsze, w ustawieniach serwera FTPS zdefiniuj bardzo wąski i konkretny zakres portów pasywnych. Nie zostawiaj tego na domyślnych wartościach systemu operacyjnego. Ustaw zakres od 50000 do 50500. Daje to 500 jednoczesnych transferów, co w 99% małych i średnich firm wystarcza z ogromnym zapasem. Po drugie, zaloguj się na swój router brzegowy lub sprzętowy firewall (np. FortiGate, pfSense) i stwórz regułę przekierowania portów (Port Forwarding). Przekieruj cały ruch TCP z zakresu 50000-50500 na wewnętrzny adres IP twojego serwera plików. To załatwia sprawę na stałe.

Pamiętaj też, żeby serwer FTP zgłaszał klientom twój zewnętrzny, publiczny adres IP w odpowiedzi na komendę PASV, a nie swój lokalny adres z puli 192.168.x.x. W przeciwnym razie klient spróbuje połączyć się z siecią wewnętrzną, co fizycznie nie ma prawa zadziałać w internecie. Większość demonów FTP ma w konfiguracji parametr typu MasqueradeAddress lub External IP address for passive mode transfers. Wpisz tam statyczny IP swojego łącza.

Podsumowanie techniczne i zlecenia dla administratorów

Zostawmy teorię w spokoju. Skonfiguruj własny serwer jeszcze dzisiaj na maszynie wirtualnej. Wyłącz autoryzację jawnym tekstem. Wymuś połączenia Explicit TLS na porcie 21. Zablokuj ruch nieszyfrowany całkowicie i sprawdź logi zaporowe na routerze rano. Zobaczysz na własne oczy, ile chińskich i rosyjskich botnetów próbuje bezmyślnie skanować twój port 21, wysyłając domyślne hasła administratora jawnym tekstem. Zastosowanie FTPS ucina ten problem u samego źródła, odrzucając te połączenia zanim w ogóle zdążą obciążyć dysk twardy logowaniami. Przestań używać czystego FTP, bo to proszenie się o gigantyczny wyciek danych w najmniej odpowiednim momencie.

FAQ – Najczęściej zadawane pytania o FTPS

• Czy mogę używać FTPS w przeglądarce internetowej?
  Nie. Przeglądarki takie jak Chrome czy Firefox całkowicie usunęły wsparcie dla protokołów FTP i FTPS. Musisz używać dedykowanego klienta, na przykład programu WinSCP, Cyberduck lub FileZilla.
• Jaki port muszę odblokować dla FTPS Explicit?
  Musisz odblokować port 21 (TCP) dla kanału sterowania oraz zdefiniowany zakres portów pasywnych (np. 50000-50500 TCP) dla kanału przesyłu danych.
• Czy FTPS szyfruje pliki na dysku serwera?
  Nie. FTPS szyfruje wyłącznie ruch w sieci (dane w tranzycie). Kiedy plik wyląduje na dysku serwera, jest zapisywany w formie niezaszyfrowanej, chyba że używasz dodatkowego szyfrowania na poziomie systemu plików (np. BitLocker lub LUKS).
• Czym różni się FTPS od HTTPS?
  HTTPS służy do przesyłania stron internetowych i działa w oparciu o protokół HTTP, przesyłając wszystko jednym kanałem na porcie 443. FTPS to protokół transferu plików z podziałem na kanał komend i danych.
• Dlaczego klient odrzuca certyfikat serwera?
  Dzieje się tak, gdy używasz certyfikatu self-signed (wygenerowanego samodzielnie) lub certyfikat stracił ważność. Rozwiązaniem jest zainstalowanie darmowego certyfikatu od Let’s Encrypt.
• Czy mogę używać SFTP zamiast FTPS?
  Oczywiście. SFTP jest często łatwiejszy w konfiguracji sieciowej, bo wymaga otwarcia tylko jednego portu (domyślnie 22). Wymaga jednak obsługi protokołu SSH po stronie serwera.

Bibliografia

1. FileZilla Project – https://filezilla-project.org
2. Internet Engineering Task Force (IETF) – https://www.ietf.org
3. Let’s Encrypt – https://letsencrypt.org
4. ProFTPD Project – https://www.proftpd.org
5. WinSCP – https://winscp.net