И снова возвращаемся к теме хранилища, ибо остался незакрытый вопрос. В прошлый раз речь шла про дисковый массив и доступ к общим папкам по локальной сети. В принципе, необходимый минимум был на этом выполнен и хранилищем можно пользоваться. Но что, если понадобился доступ снаружи? Из соседнего здания, или из другого города? Я уже заикался, что черкану отдельно про FTP. Пора взяться за это дело и вычеркнуть пункт из плана.
Установка
Начнем, естественно, с установки (в моем случае - на Mint). Протокол старый, серверов хватает - среди них выбрал vsftpd.
sudo apt install vsftpd
После этого проверяем, запустился ли он автоматически
systemctl status vsftpd
Если нет, даем ему пинка
systemctl start vsftpd
После всего этого уже можно попробовать зайти на FTP-сервер с другого компа в локальной сети, используя логин-пароль существующего на сервере пользователя. На винде в качестве клиента можно использовать, например, FileZilla или WinSCP. Результат действия? С дефолтными настройками вы должны получить доступ ко всей файловой системе сервера (с учетом прав пользователя, конечно). А еще есть вероятность, что русские имена файлов пойдут кракозябрами.
Примечание: обратите внимание на то, что именно пытается сделать FTP-клиент. WinSCP по умолчанию предлагает SFTP и порт 22 - это когда клиент прикидывается, что зашел на FTP, а это на самом деле SSH. И думаешь потом, почему на сервере настройки не применяются.
Вряд ли это то, чего вы добиваетесь. Поэтому...
Начинаем ковырять конфиг
Изначально я думал, что настройка vsftpd мало будет отличаться от самбы - указать папки, расписать права и готово. На практике процесс оказался чуть более... увлекательный.
Настройки vsftpd находятся в файле /etc/vsftpd.conf. Начнем с простого - починим кракозябры (если они, конечно, были). Для этого раскомментируем строку в конфиге либо пропишем параметр:
utf8_filesystem=YES
После этого WinSCP смог адекватно отобразить кириллицу в именах файлов.
От FTP мы обычно ждем отдельно огороженный аккуратный файлообменничек, а доступ сразу ко всем файлам не звучит как "практичность" и "безопасность". Так что далее попробуем урезать просторы.
chroot_local_user=YES
local_root=/home/user/ftp_test
#или любой другой произвольный путь
Если при заходе на сервер получаем ошибку...
OOPS: priv_sock_get_cmd
... то надо поправить права владения. Попробуйте в качестве владельца или группы назначить ftp или еще кого-то, от чьего имени vsftpd может действовать. Можно наткнуться на еще одну ошибку, тоже связанную с правами (но на этот раз - доступа):
OOPS: vsftpd: refusing to run with writable root inside chroot()
Она намекает, что у папки, указаной в local_root, не должно быть разрешений на запись. Они могут быть только у вложенных папок. Все это безопасности ради и для защиты от эксплоитов.
Виртуальные пользователи
Теперь FTP-сервер ограничивает нас в пределах указанной папки, к чему мы и стремились. Что еще можно настроить? Виртуальных пользователей, например. Идея заключается в том, что для входа используются отдельно выдуманные логины и пароли, никак не связанные с локальными пользователями. Опять таки, в основном ради безопасности, ну и может еще ради удобства настойки прав.
Прежде всего, для виртуальных пользователей надо завести отдельную базу данных. Функцию вахтера vsftpd возложил на PAM, что позволило людям напридумывать кучу рецептов с разными файлами паролей - есть варианты с мускулом, с апачем, с базой данных Беркли... Конкретно сейчас остановимся на последней (Berkeley DB).
Для этого дела нам понадобится инструмент, который может сделать файл БД
sudo apt install db-util
Создадим в папку для возни с виртуальными пользователями. Пусть это будет, к примеру, /etc/vsftpd
sudo su -
mkdir /etc/vsftpd
Затем создадим обычный текстовый файл (можно где угодно, но пусть тут же) с логинами и паролями такого вида
user1
pass123
user2
pass456
Потом сконвертируем этот текст в базу данных, и сделаем ее недоступной для посторонних
db_load -T -t hash -f virt_users.txt vsftpd-virt-users.db
chmod 600 vsftpd-virt-users.db
Текстовый файл после этого стоит удалить или надежно перепрятать, но это на ваше усмотрение.
Еще нам понадобится локальная учетка без привилегий и возможности войти в систему. По сути от ее лица и будут действовать виртуальные пользователи.
sudo useradd --home /home/vsftpd_guest --gid nogroup -m --shell /bin/false vsftpd_guest
Вернемся в старый добрый /etc/vsftpd.conf и пропишем там следующие параметры
anonymous_enable=NO
local_enable=YES
virtual_use_local_privs=YES
write_enable=YES
guest_username=vsftpd_guest
nopriv_user=vsftpd_guest
guest_enable=YES
pam_service_name=vsftpd.virt
user_config_dir=/etc/vsftp/virt-user-conf
Ну и не забываем перезапускать vsftpd после изменения конфига.
Большинство параметров говорят сами за себя, но некоторые надо отметить отдельно. Параметр guest_enable включает виртуальных пользователей, user_config_dir указывает на папку с их индивидуальными настройками - можно поправить им права, переопределив какие-то параметры из глобального конфига. Ну и расслабляться еще рано, потому что мы еще не разобрались с PAM! Параметр pam_service_name - это имя файла в папке /etc/pam.d/, в котором мы опишем, что PAM будет делать при попытках зайти на FTP-сервер. В нашем примере его содержимое будет такое
auth required pam_userdb.so db=/etc/vsftpd/vsftpd-virt-users
account required pam_userdb.so db=/etc/vsftpd/vsftpd-virt-users
Параметр db - имя файла базы данных, который мы до этого создали командой db_load. Что интересно, имя указывается без *.db в конце, его как бы допишут за нас. Если это не учесть, то работать не будет (и я это даже случайно проверил).
Полистав из любопытства документацию к PAM (а сделать это стоит), вы можете обнаружить, что db - не единственный параметр, который можно написать в этой строке. Например, чтобы убедиться, что базу подхватило, можно дописать слово dump. Тогда в /var/log/auth.log (или где оно у вас) при попытке зайти на сервер появятся строки с паролями в открытом виде. После прочтения сжечь, пепел съесть ;)
В большое плавание
К этому моменту все должно прекрасно работать в пределах локальной сети. Но для приема гостей извне нужно сделать еще кое-какие телодвижения.
Основное, что нужно сейчас сделать - разрешить пассивный режим. А все потому, что протокол FTP довольно странный. Во-первых, в нем используется два соединения - для команд и для данных. Во-вторых, в обычном (активном) режиме соединение для передачи данных открывается задом наперед - клиент отправляет команду PORT со своим адресом и портом, что как бы говорит серверу: "А давай лучше ты ко мне". Поскольку клиент скорее всего будет сидеть за NAT или фаерволлом, сервер не сможет до него достучаться и все, приехали.
В пассивном режиме оба соединения открываются в логичном направлении - от клиента к серверу. Клиент посылает команду PASV, в ответ сервер возращает номер непривилегированного порта, к которому клиент должен соединиться.
pasv_enable=YES
pasv_min_port=55000
pasv_max_port=55009
#или другой диапазон портов по желанию
Если сервер делается не для всех подряд, а только для узкого круга лиц, есть смысл поменять основной (командный) порт со стандартного 21 на что-то другое. Так себе защита, но совсем ленивых взломщиков должно отсеять.
listen_port=54321
В FTP все данные, включая логины и пароли, передаются в открытом виде. То есть, при большом желании кто-то может их подслушать. Усложнить жизнь таким желающим можно, если прикрутить к FTP шифрование.
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_cert=NO
ssl_request_cert=NO
require_ssl_reuse=NO
В данном примере в качестве rsa_cert_file и rsa_private_key_file выбраны файлы, которые уже были в системе. При желании можно сгенерировать сертификаты заново или даже заказать в специальной организации.
Отдельное внимание на параметр require_ssl_reuse. В документации сказано
Although this is a secure default, it may break many FTP clients, so you may want to disable it.
И действительно, с дефолтной настройкой через WinSCP не заработало.
Итог
В результате получился сервер без анонимного доступа, работающий с виртуальными пользователями, и доступный из интернета (порты на роутере не забыли перенаправить?).
Может возникнуть вопрос, мол, стоит ли вообще делать доступ снаружи к локальному домашнему хранилищу, на котором могут быть личные файлы? Ну, во-первых, гайд применим не только для домашних хранилищ :) А во-вторых, это уже каждый решает для себя, кому что нужно и кто чем рискует. Кто-то хочет заглядывать в свой уголок с работы или из гостиничного номера. Кому-то решительно не стоит поднимать свой FTP-сервер. Ну и есть средний вариант, в котором FTP нужен иногда. Можно же отключить автозапуск vsftpd или закрыть его порты с помощью iptables, а когда понадобится - растормошить все это дело. Вручную, по расписанию, простукиванием портов или через смс на короткий номер - как душе угодно. Но это уже выходит за рамки поста, поэтому буду закругляться.
Надеюсь, кому-то эта шпаргалка поможет :)