Где заканчивается защита VPN на пути к FTP-серверу

VPN защищает путь, а у любого пути есть конец. Когда туннель заканчивается на корпоративном шлюзе, передача файлов продолжается оттуда под защитой, которую даёт её собственный протокол. Это различие решает, защищена ли передача от начала до конца или только до шлюза. Индикатор Connected не говорит ни о том, ни о другом.

Два размещения, два оставшихся пути

Возьмите ноутбук, который подключается к корпоративному VPN, а затем открывает сеанс FTP к отдельному внутреннему серверу. Туннель заканчивается на шлюзе, а участок от шлюза до этого сервера остаётся вне его.

Обычный FTP не получает шифрование только потому, что его пакеты пришли через туннель. На этом оставшемся участке команды, учётные данные и содержимое файлов идут ровно так, как определяет протокол, то есть открыто. Важно ли это, зависит от топологии и от того, что ещё охраняет участок, а называть адрес частным не отвечает на вопрос. То же рассуждение работает и в обратную сторону, когда сервер находится в облачной сети, до которой шлюз добирается ещё одним переходом.

Поместите конечную точку VPN и службу FTP на одну машину, и следующего участка, о котором стоит беспокоиться, не останется. Это другое размещение, а не доказательство того, что процессы, файлы и учётные данные хоста в безопасности.

Обычный FTP, FTPS и SFTP — это три решения

Обычный FTP не шифрует ничего, включая пароль. FTPS добавляет TLS к FTP, поэтому канал управления и, если об этом договорились, канал данных защищены. SFTP — это другой протокол, передаваемый внутри SSH, и это не другое написание FTPS.

Сервер должен поддерживать этот выбор, потому что клиент не может придумать слушателя, которого нет. Выбор SFTP не превращает службу только с FTP в конечную точку SSH, а переименование закладки или смена порта ничего не доказывают о том, о чём договорились. Подтвердите протокол и со стороны сервера, и со стороны клиента. Замок в файловом менеджере — это утверждение о сеансе, а не о слушателе за ним.

Читайте последний столбец, когда передача важна, потому что именно там появляется неожиданное изменение подлинности.

Соединение данных — это второе соединение

FTP открывает соединение управления, а затем отдельные соединения данных для списков и передач. Защищённый вход ничего не говорит об этих последующих соединениях, если развёртывание не требует защиты и для них.

В FTPS клиент запрашивает защищённый канал данных отдельной командой, и политика сервера может отклонить открытую альтернативу. Проверьте, что политика этого требует, вместо того чтобы полагать, что настройки клиента по умолчанию достаточно. Пассивный режим добавляет вторую сложность, потому что сервер объявляет адрес и порт для соединения данных. Межсетевой экран или устройство NAT, которое переписывает или блокирует это объявление, создаёт сеанс, который проходит аутентификацию, а затем зависает на первом списке.

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'

Вторая команда показывает, что сервер предъявляет в канале управления до того, как коснуться любого файла. Третья показывает, было ли вообще установлено соединение данных, и это разница между сбоем аутентификации и сбоем пассивного режима.

Проверки подлинности переживают туннель

Клиент FTPS проверяет подлинность сервера TLS, а клиент SFTP проверяет ключ хоста SSH. Обе проверки относятся к протоколу передачи файлов, и ни одну из них не выполняет VPN.

Это разделение важно, когда что-то посередине хочет проверить сеанс. Отключение TLS, чтобы сетевое устройство могло читать команды, меняет модель защиты, а не дополняет её, и то же самое относится к принятию необъяснённого ключа хоста из-за того, что туннель поднялся. Сохраняйте предусмотренную конфигурацию доверия и получайте правильный материал у оператора. Туннель, который проходит аутентификацию, ничего не говорит о сервере на своём дальнем конце.

Материал закрытого ключа и сертификата для этих протоколов — ещё один, третий секрет, отдельный от учётных данных VPN.

Запишите, что вы действительно проверили

Выберите безобидный файл, который вам разрешено перемещать, и запишите четыре факта о попытке: какой протокол работал, какая подлинность второй стороны проверена, какой путь предполагался и завершилась ли передача.

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

Список каталога, вход в туннель и завершённая передача — это три отдельных наблюдения, и только последнее говорит, что путь работает для файлов. Если проект полагается только на VPN для конфиденциальности на оставшемся переходе, запишите это как то решение, которым оно является. Заметка о приёмке, где названы переход и его допущение о доверии, ценнее снимка экрана подключённого клиента.