Gdzie kończy się ochrona VPN w drodze do serwera FTP

VPN chroni drogę, a każda droga ma koniec. Gdy tunel kończy się na bramie firmowej, transfer plików jest kontynuowany od tego miejsca pod ochroną, którą zapewnia jego własny protokół. Ta różnica decyduje, czy transfer jest chroniony od początku do końca, czy tylko do bramy. Wskaźnik Connected nie mówi nic o żadnym z nich.

Dwa umiejscowienia, dwie pozostałe drogi

Weź laptop, który łączy się z firmowym VPN, a następnie otwiera sesję FTP do odrębnego serwera wewnętrznego. Tunel zatrzymuje się na bramie, a odcinek od bramy do tego serwera znajduje się poza nim.

Zwykły FTP nie zyskuje szyfrowania tylko dlatego, że jego pakiety dotarły przez tunel. Na tym pozostałym odcinku polecenia, dane logowania i zawartość pliku podróżują dokładnie tak, jak definiuje to protokół, czyli otwarcie. Czy ma to znaczenie, zależy od topologii i od tego, co jeszcze chroni ten odcinek, a nazwanie adresu prywatnym nie odpowiada na pytanie. To samo rozumowanie działa też odwrotnie, gdy serwer znajduje się w sieci chmurowej, do której brama dociera jeszcze jednym skokiem.

Umieść punkt końcowy VPN i usługę FTP na jednej maszynie, a nie będzie kolejnego odcinka, o który trzeba się martwić. To inne umiejscowienie, a nie dowód, że procesy, pliki i dane logowania hosta są bezpieczne.

Zwykły FTP, FTPS i SFTP to trzy decyzje

Zwykły FTP nie szyfruje niczego, nawet hasła. FTPS dodaje TLS do FTP, więc kanał sterowania i, gdy zostanie to wynegocjowane, kanał danych są chronione. SFTP to inny protokół przenoszony wewnątrz SSH i nie jest to inny zapis FTPS.

Serwer musi obsługiwać ten wybór, ponieważ klient nie może wymyślić nasłuchu, którego nie ma. Wybór SFTP nie zamienia usługi działającej tylko po FTP w punkt końcowy SSH, a zmiana nazwy zakładki lub portu niczego nie dowodzi w kwestii tego, co zostało wynegocjowane. Potwierdź protokół zarówno po stronie serwera, jak i po stronie klienta. Kłódka w menedżerze plików jest twierdzeniem o sesji, a nie o nasłuchu za nią.

Czytaj ostatnią kolumnę, gdy transfer ma znaczenie, bo właśnie tam pojawia się nieoczekiwana zmiana tożsamości.

Połączenie danych to drugie połączenie

FTP otwiera połączenie sterowania, a następnie osobne połączenia danych dla list i transferów. Chronione logowanie nie mówi nic o tych późniejszych połączeniach, chyba że wdrożenie wymaga ochrony także dla nich.

W FTPS klient żąda chronionego kanału danych za pomocą konkretnego polecenia, a polityka serwera może odrzucić otwarty wariant. Sprawdź, czy polityka tego wymaga, zamiast zakładać, że domyślne ustawienie klienta wystarczy. Tryb pasywny dodaje drugą komplikację, ponieważ serwer ogłasza adres i port połączenia danych. Zapora lub urządzenie NAT, które przepisuje lub blokuje to ogłoszenie, tworzy sesję, która uwierzytelnia się, a następnie zawiesza na pierwszej liście.

curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'

Drugie polecenie pokazuje, co serwer prezentuje na kanale sterowania, zanim dotknie się jakiegokolwiek pliku. Trzecie pokazuje, czy połączenie danych w ogóle zostało nawiązane, co jest różnicą między błędem uwierzytelniania a błędem trybu pasywnego.

Kontrole tożsamości przetrwają tunel

Klient FTPS weryfikuje tożsamość serwera TLS, a klient SFTP weryfikuje klucz hosta SSH. Obie kontrole należą do protokołu transferu plików i żadnej nie wykonuje VPN.

To rozdzielenie ma znaczenie, gdy coś pośrodku chce zbadać sesję. Wyłączenie TLS, aby urządzenie sieciowe mogło odczytać polecenia, zmienia model ochrony zamiast go dopełniać, i to samo dotyczy przyjęcia niewyjaśnionego klucza hosta dlatego, że tunel się podniósł. Zachowaj zamierzoną konfigurację zaufania i pozyskaj właściwy materiał od operatora. Tunel, który się uwierzytelnia, nic nie mówi o serwerze na swoim dalekim końcu.

Materiał klucza prywatnego i certyfikatu dla tych protokołów to kolejny, trzeci sekret, oddzielony od danych logowania VPN.

Zapisz, co naprawdę zweryfikowałeś

Wybierz nieszkodliwy plik, który wolno ci przenieść, i zapisz cztery fakty o próbie: który protokół działał, jaka tożsamość drugiej strony została sprawdzona, jaka droga była zamierzona i czy transfer się zakończył.

lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]

Lista katalogu, logowanie do tunelu i zakończony transfer to trzy osobne obserwacje, a tylko ostatnia mówi, że droga działa dla plików. Jeśli projekt opiera poufność na pozostałym skoku wyłącznie na VPN, zapisz to jako decyzję, którą to jest. Notatka odbiorcza, która nazywa skok i jego założenie zaufania, jest warta więcej niż zrzut ekranu podłączonego klienta.