Де закінчується захист 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 для конфіденційності на залишковому переході, запишіть це як те рішення, яким воно є. Нотатка про приймання, де названо перехід і його припущення про довіру, цінніша за знімок екрана підключеного клієнта.