Руководство по порту SFTP: безопасная передача файлов через SSH

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

Поскольку SFTP использует SSH, он получает преимущества от шифрования SSH, проверки ключа хоста и зрелых средств управления аутентификацией. Поэтому для большинства развертываний портом SFTP является TCP 22. Некоторые организации перемещают SSH и SFTP на другой порт, чтобы уменьшить шум фонового сканирования, но изменение порта не заменяет средства контроля аутентификации и авторизации.

Классический FTP обычно использует порт 21 для команд и отдельные порты данных для передачи. Это усложняет брандмауэр и NAT, а простой FTP отправляет учетные данные и данные без шифрования. FTPS добавляет TLS к FTP, но сохраняет модель FTP с каналами команд и данных.

SFTP использует одно соединение SSH, которое обычно легче пропускать через брандмауэры и легче проверять. SCP также использует SSH, но SFTP предлагает более широкие возможности управления файлами и является лучшим вариантом по умолчанию для интерактивной передачи, передачи файлов партнерам и автоматизированных рабочих процессов с файлами.

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

Не делайте широко открытым доступ к SFTP только потому, что он зашифрован. Служба SSH с выходом в Интернет привлекает атаки на учетные данные и автоматическое сканирование. Если доступ нужен только небольшой группе, ограничьте исходные IP-адреса, опубликуйте SFTP за VPN или частной сетью или используйте управляемый шлюз передачи с более строгими политиками контроля.

Прежде чем открыть порт 22 для SFTP, убедитесь, что сервер SSH установлен, запущен и настроен для работы подсистемы SFTP. Затем решите, какие пользователи или учетные записи служб должны подключаться, какие каталоги они могут видеть, разрешена ли аутентификация по паролю и как будут регистрироваться загрузки и скачивания.

Отдельная доступность сети от авторизации учетной записи. Средство проверки портов может показать, доступен ли TCP 22 из Интернета, но оно не может доказать, что конкретный пользователь может войти в систему или что каталог chroot правильный. Используйте SFTP-клиент или тесты командной строки ssh, чтобы проверить поведение на уровне приложения.

На Windows Server установите и включите сервер OpenSSH, разрешите входящий TCP 22 в брандмауэре Защитника Windows и убедитесь, что служба sshd запущена. Если сервер находится в облачной среде, также разрешите порт 22 в облачном брандмауэре или группе безопасности. Используйте выделенные учетные записи, а не широкий доступ администратора.

В Linux установите OpenSSH Server, убедитесь, что sshd прослушивает порт 22, и убедитесь, что подсистема SFTP включена в sshd_config. Для учетных записей с ограниченной передачей файлов настройте каталоги chroot, правила владения и внутренний sftp ForceCommand, чтобы пользователи не могли получить интерактивную оболочку.

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

Начните с проверки внешнего порта по общедоступному имени хоста или IP-адресу и порту 22. Если порт открыт, путь TCP к службе SSH доступен. Затем используйте SFTP-клиент или запустите sftp user@example.com, чтобы проверить аутентификацию, доверие к ключу хоста, доступ к каталогу и разрешения на загрузку.

Если вам нужны подробности более низкого уровня, проверьте подтверждение SSH с помощью ssh -vvv user@example.com или проверьте прослушиватели на сервере с помощью ss -tlnp, netstat или PowerShell. Для облачных серверов сравните правила брандмауэра хоста с группами облачной безопасности, поскольку оба уровня должны разрешать соединение.

Если порт SFTP закрыт, возможно, sshd не работает, прослушивает другой порт или заблокирован брандмауэром хоста. Если время проверки истекло, группа безопасности облака, правило NAT маршрутизатора, фильтр интернет-провайдера, политика VPN или список разрешенных IP-адресов источника могут отбрасывать пакеты до того, как они достигнут сервера.

Если порт открыт, но вход по SFTP невозможен, проверьте имя пользователя, разрешения ключа, политику паролей, требования MFA, разрешенных пользователей, владение chroot, правила ForceCommand и журналы сервера. Распространенной ошибкой является предоставление пользователю прав на запись в каталог chroot; OpenSSH требует определенных шаблонов владения и разрешений для безопасной работы chroot.

Предпочитайте ключи SSH или аутентификацию на основе сертификатов паролям. Отключите root-вход, ограничьте количество пользователей, которые могут подключаться, чередуйте ключи, удалите неиспользуемые учетные записи и защитите секретные ключи с помощью кодовых фраз или аппаратного хранилища. Для партнерского доступа создайте по одной учетной записи для каждого партнера, чтобы действия можно было легко приписать и отозвать.

Ограничивайте доступ к файловой системе с помощью chroot или каталогов с ограниченной областью действия, избегайте общих папок с возможностью записи, если они не требуются, и отслеживайте неудачные входы в систему и необычные тома передачи. Если SFTP подключен к Интернету, объедините ограничение скорости, списки разрешенных источников, обнаружение вторжений и регулярное исправление SSH-сервера.