Передача файлов по сети - задача настолько обыденная, что про неё редко задумываются всерьёз. И зря. Старый добрый FTP, придуманный ещё в начале 70-х, изначально гонял логины и пароли в открытом виде, превращая любую перехваченную сессию в подарок злоумышленнику. Шли годы, сетевые угрозы росли как снежный ком, и появилась насущная потребность в инструменте, который сохранил бы привычное удобство FTP, но добавил бы к нему серьёзный замок на двери. Так на сцену вышел vSFTPd.
Аббревиатура расшифровывается как Very Secure FTP Daemon, и слово secure здесь не для красоты. Это свободное программное обеспечение под лицензией GNU GPL, разработанное специально для Unix-подобных систем. vSFTPd хвалят за быстроту, скромный аппетит к ресурсам и стабильность, проверенную годами эксплуатации. Доверие к проекту настолько велико, что его используют такие тяжеловесы, как RedHat, SUSE, Debian, Gnome и KDE.
Возможностей у демона предостаточно - работа с IPv6, поддержка виртуальных IP-адресов и виртуальных пользователей, запуск в режиме отдельного демона или через inetd. Каждый пользователь может иметь индивидуальную конфигурацию, ограничения по исходному IP, лимиты пропускной способности. Подключается аутентификация через PAM, есть встроенная интеграция с SSL/TLS. Получается универсальный швейцарский нож для передачи файлов с поправкой на серьёзность подхода к безопасности.
Ниже разобран весь путь от чистой системы до полностью рабочего FTP-сервера с шифрованием. Параллельно настраивается брандмауэр UFW, создаётся отдельный пользователь с собственным chroot-окружением и проверяется работа через клиентское приложение.
Подготовительные требования и базовая обстановка для развёртывания собственного FTP-узла
Чтобы пройти этот путь без сюрпризов, понадобится Ubuntu 22.04 - желательно свежая установка без хвостов от других экспериментов. Доступ к серверу должен быть с правами обычного пользователя, у которого есть возможность повышать привилегии через sudo. Работать постоянно из-под чистого root считается дурным тоном с давних времён, и привычка эта никуда не делась.
На локальной машине стоит заранее установить FTP-клиент. В качестве примера дальше будет фигурировать FileZilla - бесплатная программа с открытым исходным кодом, доступная для Linux, Windows и macOS. Подойдут и другие клиенты, главное чтобы они умели работать с явным TLS (FTPES). Простой ftp из терминала тоже сгодится для базовых проверок, но без поддержки шифрования он окажется бесполезен.
Установка пакета vSFTPd из стандартных репозиториев Ubuntu и первая проверка работоспособности службы
Хорошая новость - vSFTPd живёт в основных репозиториях Ubuntu и не требует подключения сторонних источников пакетов. Это упрощает жизнь администратору, поскольку обновления приходят вместе с системными и не нужно следить за совместимостью отдельных PPA.
Освежаем индекс пакетов перед установкой:
sudo apt update
Команда обращается к серверам репозитория и подтягивает актуальный список доступных версий. Без этого шага apt может ставить устаревший пакет или вообще не найти нужный. Привычка обновлять индекс перед установкой экономит часы будущих разбирательств.
Теперь сама установка:
sudo apt install vsftpd
При запросе подтверждения нажимаем Y и Enter. Менеджер пакетов выкачает демон со всеми зависимостями, развернёт начальные конфиги и сразу запустит службу.
Проверяем результат:
sudo systemctl is-enabled vsftpd
sudo systemctl status vsftpd
Первая команда показывает, включён ли автозапуск службы при загрузке системы. Ответ enabled означает, что vSFTPd будет стартовать автоматически после перезагрузки. Вторая команда выдаёт текущее состояние - в идеале active (running) зелёным шрифтом. Если вместо этого видна ошибка, журнал через journalctl -u vsftpd обычно подсказывает, в чём дело.
Создание самоподписанного сертификата TLS и тонкая настройка главного конфигурационного файла демона
Голый FTP без шифрования сегодня выглядит как открытая дверь в подъезде - вроде бы всё работает, но первый встречный увидит, что внутри. Поэтому первым делом генерируется SSL/TLS-сертификат, который будет использоваться для защиты как канала аутентификации, так и канала передачи данных.
Создаём самоподписанный сертификат сроком на 10 лет:
sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem
Разберём флаги по порядку. Параметр req запускает режим работы с запросами на сертификаты. Опция -x509 означает создание не запроса, а сразу готового самоподписанного сертификата. Флаг -nodes (читается как no DES) отключает шифрование закрытого ключа парольной фразой - иначе vSFTPd не сможет автоматически прочитать его при старте без интерактивного ввода пароля. Параметр -days 3650 задаёт срок действия в днях, то есть около десяти лет. Опция -newkey rsa:2048 создаёт новый ключ RSA длиной 2048 бит. Наконец, -keyout и -out указывают, куда сохранить ключ и сертификат - в нашем случае оба компонента складываются в один файл /etc/ssl/private/vsftpd.pem.
Команда задаст несколько вопросов про страну, регион, организацию и имя хоста. Для внутреннего сервера можно указать любые осмысленные значения, для публичного лучше прописать реальные данные - они будут видны клиентам при первом подключении.
Делаем резервную копию исходного конфига перед правкой:
sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.orig
Привычка сохранять оригинал перед серьёзными изменениями спасала уже не одно поколение администраторов. Когда что-то идёт не так, всегда можно сравнить через diff и понять, какая именно правка сломала систему.
Открываем конфигурацию для редактирования:
sudo nano /etc/vsftpd.conf
Первое, что нужно сделать - запретить анонимный доступ. Этот режим был задуман когда-то для публичных файловых архивов, но в современной защищённой инфраструктуре он смотрится анахронизмом:
anonymous_enable=NO
Дальше включаем работу локальных пользователей системы:
local_enable=YES
Без этого параметра ни один реальный пользователь не сможет подключиться к серверу - vSFTPd по умолчанию отвергает все локальные учётные записи. Раскомментируем разрешение на запись:
write_enable=YES
Иначе сервер будет работать только в режиме чтения, что превращает его в файлообменник одного направления.
Активируем chroot для локальных пользователей:
chroot_local_users=YES
Эта опция изолирует каждого пользователя в его домашнем каталоге, не давая ходить по чужим директориям и системным файлам. Получается что-то вроде гостиничного номера - человек заходит и видит только свою комнату, а не весь отель целиком. Без chroot любой авторизованный пользователь мог бы пройтись по корневой файловой системе.
Добавляем настройки персональных каталогов для каждого пользователя:
user_sub_token=$USER
local_root=/home/$USER/chroot
Переменная $USER подставляется автоматически - имя текущего пользователя. Каждый при входе попадает в /home/имя/chroot, и это становится для него корнем файлового пространства. Дальше задаём диапазон портов для пассивного режима:
pasv_min_port=40000
pasv_max_port=50000
Пассивный режим FTP открывает дополнительные порты для канала данных, и без явного указания диапазона они выбираются случайно во всём пространстве выше 1024. Для брандмауэра это головная боль, поэтому имеет смысл зафиксировать конкретный коридор - тогда правила firewall становятся предсказуемыми.
Включаем механизм списка пользователей:
userlist_enable=YES
userlist_file=/etc/vsftpd.userlist
userlist_deny=NO
Эта тройка работает в связке. Параметр userlist_enable активирует проверку списка, userlist_file указывает путь к файлу со списком, а userlist_deny=NO переворачивает логику - в файле перечислены те, кому подключение разрешено, а не запрещено. Получается белый список вместо чёрного.
Финальный блок отвечает за шифрование:
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YES
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH
Здесь указан путь к сертификату и ключу (тот самый pem-файл, который сгенерировали ранее). Параметры force_local_data_ssl и force_local_logins_ssl делают шифрование обязательным как для авторизации, так и для передачи данных. Без них клиент мог бы при желании подключиться без TLS, что обнуляет смысл всей затеи.
Включён только TLSv1, отключены устаревшие SSLv2 и SSLv3 - оба считаются небезопасными уже больше десяти лет. Параметр require_ssl_reuse=NO повышает совместимость с разными клиентами, поскольку требование переиспользования SSL-сессии иногда ломает подключения. Опция ssl_ciphers=HIGH разрешает только сильные шифры, отсекая слабые алгоритмы, которые могли бы быть взломаны современными методами.
Сохраняем файл и закрываем редактор. Создаём пустой файл для списка пользователей:
touch /etc/vsftpd.userlist
Перезапускаем службу для применения настроек:
sudo systemctl restart vsftpd
sudo systemctl status vsftpd
В выводе должно быть active (running). Если служба не стартует, журнал через journalctl покажет, на какой строке конфига споткнулся демон.
Открытие нужных портов в брандмауэре UFW для корректной работы FTP-канала и пассивного режима
Заблокированный брандмауэром FTP-сервер - это классика жанра. Полдня настраиваешь конфиг, проверяешь подключение, всё валится с таймаутом, а причина в том, что трафик до службы попросту не доходит. Чтобы избежать таких приключений, правила firewall настраиваются заранее.
Проверяем статус UFW:
sudo ufw status
Если в выводе виден список активных правил, значит брандмауэр уже работает. Если ответ inactive, надо его включить, не забыв предварительно открыть SSH, иначе можно потерять удалённый доступ к серверу:
sudo ufw allow "OpenSSH"
sudo ufw enable
Эта пара команд - спасательный круг для удалённого администратора. Сначала разрешается SSH, и только потом активируется фильтрация. Иначе после включения UFW сессия оборвётся, а зайти заново будет невозможно.
Открываем порты для FTP и для пассивного режима:
sudo ufw allow 20:21/tcp
sudo ufw allow 40000:50000/tcp
Порт 21 - управляющий канал FTP, через него передаются команды и ответы. Порт 20 используется для активного режима передачи данных. Диапазон 40000-50000 совпадает с тем, что мы прописали в pasv_min_port и pasv_max_port - это пассивный режим, в котором клиент сам подключается к серверу для приёма данных. Большинство современных клиентов работают именно в пассивном режиме, поскольку он лучше дружит с NAT и брандмауэрами.
Перезагружаем правила и проверяем:
sudo ufw reload
sudo ufw status
В выводе должны появиться добавленные диапазоны портов. Если правила видны, значит трафик до vSFTPd теперь дойдёт без препятствий.
Создание FTP-пользователя с фиктивной оболочкой и правильно выставленными правами на каталоги
Тут начинается тонкая часть. По умолчанию vSFTPd использует PAM для аутентификации, и пользователь обязан иметь валидную оболочку, прописанную в /etc/shells. Обычная практика безопасности - создавать FTP-пользователей с оболочкой /bin/false или /usr/sbin/nologin, чтобы они не могли войти по SSH. Но в случае с vSFTPd такой пользователь не сможет подключиться вообще никак, поскольку PAM посчитает его аккаунт неактивным.
Решение элегантное - создаётся фиктивная оболочка-заглушка, которая ничего полезного не делает, но числится валидной:
echo -e '#!/bin/sh\necho "Shell for FTP users only."' | sudo tee -a /bin/ftpdummy
sudo chmod a+x /bin/ftpdummy
Первая команда формирует крошечный shell-скрипт, который при запуске просто выводит сообщение про FTP-пользователей. Вторая делает его исполняемым. Если кто-то попробует залогиниться по SSH с такой оболочкой, он увидит надпись и тут же будет выкинут - а вот для FTP этого достаточно, чтобы PAM пропустил аутентификацию.
Регистрируем новую оболочку как разрешённую:
sudo echo "/bin/ftpdummy" >> /etc/shells
Файл /etc/shells содержит список оболочек, которые система признаёт допустимыми. Без этой записи useradd откажется создавать пользователя с такой оболочкой, ругнувшись на её невалидность.
Создаём пользователя alice (имя выбрано как пример, можно использовать любое):
sudo useradd -m -s /bin/ftpdummy alice
sudo passwd alice
Флаг -m создаёт домашний каталог автоматически, -s задаёт оболочку. Команда passwd запросит пароль и его подтверждение - стоит выбрать что-то длинное и сложное, поскольку FTP даже с TLS не любит словарных атак.
Создаём структуру каталогов внутри домашней директории:
mkdir -p /home/alice/chroot
Этот chroot станет тем самым изолированным пространством, в которое попадёт пользователь после входа. Внутри размещаем рабочие подкаталоги:
mkdir -p /home/alice/chroot/{data,upload}
Фигурные скобки в bash - синтаксический сахар для создания нескольких директорий одной командой. Сразу появляются /home/alice/chroot/data и /home/alice/chroot/upload.
Выставляем права:
sudo chown -R alice: /home/alice/chroot
sudo chmod 550 /home/alice/chroot
sudo chown -R alice: /home/alice/chroot/{data,upload}
sudo chmod 750 /home/alice/chroot/{data,upload}
Тут притаилась важная тонкость, на которой спотыкаются многие. vSFTPd требует, чтобы корневой chroot-каталог был доступен пользователю только на чтение и не имел прав на запись. Иначе демон откажется работать с сообщением о небезопасной конфигурации - 500 OOPS: vsftpd: refusing to run with writable root inside chroot(). Поэтому /home/alice/chroot получает права 550 (чтение и выполнение для владельца и группы). А вот вложенные data и upload получают 750 - там запись разрешена, и именно туда пользователь будет загружать свои файлы.
Добавляем пользователя в белый список vSFTPd и перезапускаем демон:
echo "alice" >> /etc/vsftpd.userlist
sudo systemctl restart vsftpd
После перезапуска новые правила вступают в силу, и alice может пробовать подключаться.
Проверка подключения через FTP-клиент с принятием самоподписанного сертификата и тестовая загрузка файлов
Финальный аккорд - реальное подключение к серверу. Запускаем FileZilla на локальной машине. В верхней панели быстрого подключения вводим адрес или IP-адрес FTP-сервера, имя пользователя alice, пароль и оставляем порт пустым (по умолчанию 21). Жмём Quick connect.
Поскольку сертификат самоподписанный, клиент покажет окно с предупреждением о неизвестном центре сертификации. Выбираем опцию доверия (Trust...) и подтверждаем. В корпоративной среде такое предупреждение можно убрать, импортировав сертификат сервера в доверенные на каждой клиентской машине - но для тестов и небольших инфраструктур достаточно одноразового подтверждения.
После успешной авторизации в правой панели FileZilla появятся два каталога - data и upload. Корень chroot будет доступен только на чтение, поэтому попытка загрузить файл прямо в него закончится отказом с правами доступа. А вот в data и upload файлы загружаются без проблем. Это и есть та самая изолированная среда, которая защищает остальную систему от любопытного или вредоносного пользователя.
Из терминала можно проверить подключение и через клиент lftp, который умеет работать с явным TLS:
lftp -u alice ftp://your-server-address
После ввода пароля окажешься в chroot-окружении. Команды ls, cd, put, get работают как обычно, но в пределах песочницы.
Распространённые подводные камни и практические советы из опыта эксплуатации vSFTPd в реальных условиях
В копилку наблюдений из практики стоит добавить несколько моментов, на которых нередко спотыкаются те, кто впервые поднимает vSFTPd. Самая частая проблема - сообщение про 500 OOPS: vsftpd: refusing to run with writable root inside chroot(). Это значит, что корневой каталог пользователя имеет права на запись для владельца. Лекарство простое - выставить chmod 550 на корневой chroot и создать внутри отдельные подкаталоги для записи. Именно поэтому в нашей схеме появилась разница между /home/alice/chroot (550) и /home/alice/chroot/{data,upload} (750).
Вторая популярная грабля - проблема с пассивным режимом за NAT. Если сервер стоит за маршрутизатором с NAT, в конфиг нужно добавить параметры pasv_address с публичным IP и pasv_addr_resolve=YES, иначе клиент будет получать в ответ внутренний адрес и пытаться соединиться с ним, что в принципе невозможно. Также не забыть пробросить весь диапазон 40000-50000 на роутере.
Третья история связана с правами на сертификат. Файл /etc/ssl/private/vsftpd.pem должен быть доступен пользователю root и иметь права 600 - иначе любой локальный пользователь сможет утащить закрытый ключ. Утилита openssl выставляет правильные права автоматически, но при ручном копировании об этом легко забыть.
Где такая связка пригодится в реальной жизни? Сценариев множество. Передача отчётов от подрядчиков на корпоративный сервер с разделением по проектам и пользователям. Загрузка резервных копий с удалённых филиалов в центральное хранилище. Хостинг исходников веб-сайтов для команды дизайнеров, которые не работают с git и привыкли к классическому FTP. Старые промышленные устройства - принтеры, контроллеры, MES-системы - которые умеют только FTP и никогда не получат поддержку SFTP или SCP.
Освоение vSFTPd даёт инженеру не просто навык настройки одного демона, а понимание того, как устроена аутентификация через PAM, как работает chroot-изоляция, как взаимодействуют правила брандмауэра с активным и пассивным режимами FTP, как генерировать и применять TLS-сертификаты. Эти знания переносимы на любые другие службы Unix-мира - те же концепции встретятся при работе с ProFTPd, Pure-FTPd, OpenSSH и многими другими сервисами. Тот, кто разобрался с vSFTPd, без труда настроит и любой из конкурентов, поскольку отличия будут лишь в синтаксисе конфигурации, а не в принципах. Потому-то этот демон уже больше двадцати лет остаётся одним из стандартных выборов для тех, кому нужен надёжный, лёгкий и проверенный временем FTP-сервер.
Канал сайта в Telegram
Канал сайта на YouTube