Закрываем FTP-серверы и переводим клиентов на SFTP с chroot-jail

FTP существует с 1971 года - и это чувствуется. Пароли в открытом виде, данные в открытом виде, никакого шифрования вообще. У нас на сопровождении к апрелю оставалось ещё несколько клиентов, которые гоняли файлы через vsftpd или IIS FTP. После того как в феврале вышел OpenSSH 4.3 с заметно подросшей SFTP-подсистемой, мы решили что момент подходящий - и начали последовательно закрывать эти серверы.

Почему именно сейчас

Раньше разговор об отказе от FTP упирался в практические возражения: клиентские программы для SFTP были либо неудобными, либо стоили денег, либо у части пользователей не работали без танцев. WinSCP к этому времени разошёлся достаточно широко, работает стабильно и бесплатен - возражение про «пользователи не умеют» снялось само собой. OpenSSH 4.3 со стороны сервера тоже подтянулся: SFTP-subsystem стал аккуратнее обрабатывать разные типы клиентов, меньше падать на нестандартные запросы.

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

Что делаем на сервере

Схема для файлового обменника - несколько пользователей, каждый видит только свою директорию, никто не лезет к соседу и тем более к системным файлам. Без chroot это технически решаемо через права, но с chroot - значительно чище: даже если пользователь попробует выйти за пределы своей директории через ../, он упрётся в стену.

OpenSSH 4.3 встроенного ChrootDirectory для SFTP-subsystem не предоставляет. Задачу решаем через jailkit - утилиту для создания chroot-окружений, которая собирается из исходников и нормально встаёт на CentOS 4. Альтернатива - scponly, оболочка-заглушка вместо bash, которая разрешает только SCP/SFTP-операции.

Конкретная схема:

• Создаём отдельную группу sftponly - все пользователи файлообменника попадают в неё.
• Для каждого пользователя - домашняя директория вида /srv/ftp/clients/clientname, владелец root, права 755. Это обязательно: если директория принадлежит самому пользователю, chroot не сработает - sshd откажется его принимать.
• Внутри директории создаём поддиректорию incoming с нужными правами для загрузки файлов - туда пользователь пишет, из корня chroot только читает.
• В /etc/ssh/sshd_config для группы sftponly переопределяем ForceCommand /usr/lib/openssh/sftp-server и выключаем AllowTcpForwarding, X11Forwarding, PermitTunnel. Пользователь получает ровно файловый доступ и ничего больше.

Для проверки после настройки - пробуем подключиться как ограниченный пользователь и попытаться выйти за пределы jail через cd /:

sftp> cd /
sftp> pwd
Remote working directory: /
sftp> ls -la
drwxr-xr-x    2 0        0            4096 Apr 18 11:24 incoming

Именно это и нужно: пользователь видит «корень», но этот корень - его /srv/ftp/clients/clientname. Выше - просто ничего нет.

SCP для внутренних задач

Параллельно с SFTP-обменниками для клиентов разбираемся с внутренними скриптами, которые гоняли файлы между серверами по FTP. Там замена проще - SCP. Ключи уже настроены для большинства серверов, скрипт меняется в одну строчку:

# было
ftp -n $HOST << EOF
user $USER $PASS
binary
put backup.tar.gz
bye
EOF

# стало
scp backup.tar.gz $USER@$HOST:/srv/backups/

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

Что с клиентами

Самая медленная часть - не техническая. Объяснить менеджеру, который привык к Total Commander с FTP-плагином, что теперь надо поставить WinSCP и нажимать другие кнопки - занимает больше времени, чем настройка сервера. Особенно когда человек спрашивает: «а чем это лучше, у нас и так всё работало».

Ответ честный: если вам не принципиально, что ваши файлы и пароль можно перехватить на любом транзитном узле между вами и сервером - тогда ничем. Если принципиально - вот WinSCP, вот инструкция на полстраницы, пять минут и вы переехали.

Из нескольких клиентов только у одного была нестандартная ситуация: их контрагент присылал файлы со старой системы, которая умела только FTP. Пришлось оставить FTP-порт в изолированном сегменте только для этого соединения с whitelisting по IP - не идеально, но лучше чем открытый для всех.

К концу апреля из списка на сопровождении открытых FTP-серверов, доступных снаружи, не осталось. Внутри сети - ещё пара, разбираем по ситуации.