SFTP

SFTP (SSH File Transfer Protocol) to protokół przesyłania plików działający wewnątrz połączenia SSH. Specyfikacja IETF opisuje go jako standardowy protokół przesyłania plików dla protokołu SSH2, uruchamiany jako podsystem o nazwie sftp ^[1]. Protokół zakłada, że działa w bezpiecznym kanale, a serwer uwierzytelnił już użytkownika ^[1]. Dzięki temu login, hasło i zawartość plików są szyfrowane, czego nie zapewnia klasyczny FTP.

Jak działa

SFTP nie jest odrębną usługą sieciową, tylko częścią SSH. Klient najpierw zestawia połączenie SSH, domyślnie na porcie 22 zarejestrowanym w IANA ^[2], uwierzytelnia się hasłem albo kluczem, a potem prosi serwer o uruchomienie podsystemu sftp ^[1]. Wszystkie polecenia, takie jak listowanie katalogu, odczyt, zapis czy zmiana nazwy pliku, płyną potem przez ten sam zaszyfrowany kanał. Wersja protokołu opisana w szkicu IETF z października 2001 roku ma numer 3 ^[1].

Przebieg sesji pokazuje schemat poniżej.

RYS. 1Sesja SFTP

Po stronie serwera OpenSSH podsystem obsługuje program sftp-server albo wbudowany wariant internal-sftp ^[6]. Domyślnie żaden podsystem nie jest skonfigurowany, więc administrator musi go włączyć dyrektywą Subsystem ^[6].

Subsystem sftp internal-sftp

SFTP a inne sposoby przesyłania plików

Nazwy są podobne, ale protokoły różne. Klasyczny FTP według RFC 2577 wysyła hasło tekstem jawnym w poleceniu PASS, a wszystkie dane i informacje sterujące, łącznie z hasłami, przechodzą przez sieć bez szyfrowania ^[3].

FTPS to jeszcze inny wariant: klasyczny FTP zabezpieczony protokołem TLS według RFC 4217 z października 2005 roku ^[7]. Nie ma związku z SSH i korzysta z innych portów oraz certyfikatów serwera, więc „bezpieczny FTP” w ofercie hostingu warto sprawdzić, zanim skonfiguruje się klienta.

W WordPressie

Podręcznik utwardzania WordPressa zaleca łączenie się z serwerem przez SFTP, jeśli hosting to umożliwia; szyfrowane są wtedy hasło i inne dane przesyłane między komputerem a witryną ^[4]. Dotyczy to wgrywania motywów, ręcznej edycji plików i przywracania kopii.

WordPress sam też korzysta z przesyłania plików, gdy nie może zapisywać bezpośrednio na dysku. Stała FS_METHOD w pliku wp-config.php wybiera metodę: direct, ssh2, ftpext albo ftpsockets ^[5]. Metoda ssh2 używa rozszerzenia SSH dla PHP, a ftpext i ftpsockets klasycznego FTP ^[5]. Dane dostępowe można podać w stałych FTP_USER, FTP_PASS, FTP_PUBKEY i FTP_PRIKEY ^[5]; wtedy plik konfiguracyjny zawiera kolejny sekret, co wzmacnia potrzebę utwardzania pliku wp-config.php (wp-config hardening).

Na hostingu współdzielonym konto SFTP ma zwykle dostęp do wszystkich plików strony, w tym do konfiguracji z hasłem do bazy. Przejęte dane uwierzytelniające SFTP dają więc atakującemu to samo, co pełny dostęp do serwera plików: możliwość wgrania webshell albo tylnej furtki (backdoor) z pominięciem panelu WordPressa.

Zagrożenia i skutki

SFTP chroni transmisję, ale nie konto. Główne ryzyka to:

• Odgadnięte hasło. Serwer OpenSSH domyślnie dopuszcza logowanie hasłem ^[6], więc otwarty port 22 jest celem ataków siłowych (brute force). Automatyczną blokadę adresów po nieudanych próbach zapewnia na przykład fail2ban.
• Wyciek danych dostępowych z komputera, na którym zapisano je w kliencie SFTP.
• Zbyt szerokie uprawnienia. Konto, które widzi cały serwer, zamienia jedną kradzież hasła w przejęcie wszystkich stron na koncie.
• Brak weryfikacji klucza hosta. RFC 4253 dopuszcza przyjęcie klucza serwera bez sprawdzenia, ale zaznacza, że protokół staje się wtedy niebezpieczny wobec aktywnych ataków ^[2], czyli ataku man-in-the-middle (MITM). Komunikat klienta o zmianie klucza hosta należy więc wyjaśnić, zanim połączenie zostanie zaakceptowane.

Historia

FTP powstał długo przed powszechnym szyfrowaniem w sieci. Już RFC 2577 z maja 1999 roku, poświęcony bezpieczeństwu FTP, wskazywał, że standardowy FTP przesyła hasła tekstem jawnym ^[3]. Odpowiedzią były dwa kierunki. Pierwszy to FTPS, opisany w RFC 4217 z października 2005 roku, który dodaje do FTP protokół TLS ^[7]. Drugi to przesyłanie plików wewnątrz SSH.

Szkic SSH File Transfer Protocol w wersji 3 pochodzi z października 2001 roku ^[1]. Przewidywał on działanie na dowolnym niezawodnym strumieniu danych, ale jako podstawowe zastosowanie wskazywał pracę w roli podsystemu protokołu połączeń SSH ^[1]. Architekturę transportu SSH opisuje RFC 4253 ze stycznia 2006 roku ^[2]. Podręcznik WordPressa zaleca SFTP wprost, jeśli dostawca hostingu go udostępnia ^[4].

Dobre praktyki

Klucze zamiast haseł. Logowanie kluczem SSH eliminuje odgadywanie hasła; po jego wdrożeniu logowanie hasłem można wyłączyć w sshd_config ^[6].

Zamknięcie w katalogu. Sekurak zwraca uwagę, że użytkowników z dostępem SFTP można ograniczyć do katalogu domowego i odebrać im możliwość uruchamiania innych poleceń, konfigurując środowisko chroot ^[8]. W OpenSSH służy do tego ChrootDirectory; wszystkie składniki ścieżki muszą należeć do roota i nie mogą być zapisywalne dla grupy ani innych ^[6]. Wariant internal-sftp nie potrzebuje w takim katalogu żadnych plików pomocniczych ^[6].

Match User wdrozenie
    ChrootDirectory /srv/sftp/example.com
    ForceCommand internal-sftp

Właściciel plików ustawiony przez SFTP ma znaczenie dla WordPressa. Podręcznik utwardzania zaleca, aby katalog główny, wp-admin, wp-includes i katalog wtyczek były zapisywalne tylko przez konto użytkownika, a wp-content także przez serwer WWW ^[4]. Pliki wgrane przez konto SFTP należą do tego konta, więc serwer WWW, a razem z nim ewentualny złośliwy skrypt, nie może ich nadpisać.

Całość realizuje zasada najmniejszych uprawnień: osobne konto dla każdej osoby i każdej strony, z dostępem tylko do potrzebnych katalogów i z uprawnieniami plików ustawionymi tak, by serwer WWW nie mógł nadpisywać kodu.