Журнал LinuxFormat - перейти на главную

LXF132:DrBrown3

Материал из Linuxformat
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

Настраиваем ProFTPD

Установим профессиональный FTP-сервер и настроим анонимный или аутентифицированный доступ с полнофункциональным ProFTPD


На прошлой неделе меня поймал врасплох один из клиентов, просивший помочь в установке FTP-сервера. Я этим давно не занимался, и некогда тесное знакомство с FTP почти улетучилось из памяти. Подозреваю, что дни FTP сочтены, и HTTP более созвучен современности.

Однако недостатка FTP-серверов в обычных репозиториях нет: в Fedora их два (ProFTPD и vsftpd), а в Ubuntu – не менее четырех. Дальнейший поиск с помощью монеты и «звонка другу» помог остановить выбор на ProFTPD, и на данном уроке я опишу свой опыт по его установке и настройке. Я делал это в Fedora 12, но в других дистрибутивах все должно быть примерно так же.

ProFTPD – мощный полнофункциональный FTP-сервер. Он запускается как самостоятельная служба или через xinetd и поддерживает анонимный и аутентифицированный вход в систему, включая «виртуальных пользователей», учетные записи которых определены в каталогах LDAP или базах данных SQL. Он также допускает виртуальный хостинг – обслуживание нескольких FTP-сайтов с одного экземпляра FTP-сервера. Рассмотрим все эти возможности.

Сначала я установил сервер и настроил его запуск во время загрузки: 

# yum install proftpd
# chkconfig proftpd on

Сразу после установки сервера инстинкт погнал меня к файлу настройки (в данном случае /etc/proftpd.conf). Его структура с контейнерными XML-тэгами подобна файлу настройки Apache. В файле настройки по умолчанию, который поставляется с Fedora 12, находится рабочая конфигурация с рядом добавочных опций, которые закомментированы. На рис. 2 показан минимальный файл настройки. Он содран с поставляемого (урезан), но достаточен для поддержки аутентифицируемого входа по FTP.

Анонимный FTP

Анонимный FTP позволяет пользователю аутентифицироваться под именем «ftp» или «anonymous» и паролем, которым по традиции должен быть его e-mail адрес, но на практике это не проверяется. Анонимный FTP широко применяется для предоставления доступа к интернет-ресурсу только на чтение и на много лет предвосхитил использование для тех же целей HTTP и web-сайтов. Анонимный вход в систему снимает мои заботы по поводу безопасности FTP. Во-первых, по сети не передаются настоящие имя и пароль, которые могут перехватить плохие парни; во-вторых, факт отсутствия шифрования соединения не имеет значения, ведь содержимое сервера все равно публично!

В файле proftpd.conf, который по умолчанию поставляется с Fedora 12, также есть секция <Anonymous>, которая работает сразу же. Ну, почти. Мне понадобилось только добавить в файл /etc/sysconfig/proftpd следующую строку: 

PROFTPD_OPTIONS=”-DANONYMOUS_FTP”

и перезапустить ProFTPD командой: 

service proftpd restart

В конфигурации по умолчанию каталог ~ftp (которому соответствует /var/ftp) является каталогом home для анонимных пользователей. При установке пакета ProFTPD он создает каталоги /var/ftp/pub (куда нужно выкладывать контент) и /var/ftp/upload (куда могут выкладывать контент анонимные пользователи).

Конфигурация по умолчанию также поддерживает аутентификацию для пользователей, у которых на сервере есть обычные учетные записи. После входа по FTP вы попадаете в свой домашний каталог. Сначала мне это не удалось, и я некоторое времяискал причину, запустив ProFTPD не в режиме демона, со включенной отладкой: 

proftpd -n -d 5

и параллельно запустив tail -f на /var/log/messages. В итоге оказалось, что SELinux не давал демону зайти в домашний каталог, и я поступил, как всегда в таких ситуациях: перевел SELinux в разрешающий режим (permissive mode): 

setenforce permissive

после чего все заработало. На настоящем сервере относиться к уровню безопасности SELinux нужно более серьезно.

Виртуальный пользователь – пользователь, у которого нет обычной учетной записи Linux на сервере в /etc/passwd или где-либо еще. Понятие «виртуальный пользователь» вводит в заблуждение – некоторые из них вполне реальны: настоящее тепло, дышащие тела; виртуальны только их учетные записи. Эти записи могут храниться в AuthUserFiles, каталогах LDAP и базах данных SQL. Простейший механизм аутентификации виртуального пользователя – AuthUserFile, это простой текстовый файл в том же формате, что и /etc/passwd.

Виртуальный хостинг

А если нужно разместить несколько FTP-сайтов в одной системе? К сожалению, реализовать такой же виртуальный хостинг, как и для web-сайтов, когда записи нескольких узлов в DNS ссылаются на один и тот же IP-адрес, здесь не удастся. Это работает для HTTP, но не для FTP, потому что в HTTP-запросе есть поле «Host», поясняющее web-серверу, для какого сайта предназначен запрос, даже если все они приходят на один и тот же IP-адрес. В протоколе FTP такого поля нет, и в виртуальном хостинге FTP у каждого сайта должен быть собственный IP-адрес, по которому сервер мог бы понять, для какого сайта предназначен запрос.

Но даже если вы счастливый обладатель достаточного количества свободных IP-адресов, нужно сделать еще две вещи. Во-первых, определить «IP-алиас» на сетевой карте для всех адресов, которые будут использоваться. Во-вторых, создать для каждого сайта в файле proftpd.conf секцию <VirtualHost>.

В дистрибутивах на базе RedHat для каждого дополнительного IP-адреса, который нужно связать с сетевой картой, понадобится создать файл с именем вроде /etc/sysconfig/network-scripts/ifcfg-eth0:N, где N – номер алиаса (0, 1, 2, ...). Файл будет примерно таким: 


DEVICE=eth0:1
BOOTPROTO=static
IPADDR=192.168.1.69
ONBOOT=yes
HWADDR=00:0C:29:E1:E4:23

Замените значения DEVICE, IPADDR и HWADDR соответствующими в вашей системе. Для каждого IP-адреса понадобится отдельный файл. Насколько я знаю, сделать нечто вроде «Я хочу назначить все адреса из блока 10.1.0.0/24 этой сетевой карте» нельзя (если я неправ, сигнализируйте!).

После создания файлов выполните команду 

service network restart

чтобы подцепить новые адреса, и проверьте, что сетевые интерфейсы для всех адресов созданы, командой ifconfig.

Для каждого из сайтов в файле настройки необходима секция <VirtualHost>. Она должна выглядеть примерно так: 

<VirtualHost 144.16.44.5>
...
</VirtualHost>

или вместо IP-адреса можно использовать имя компьютера 

<VirtualHost foo.example.com>
...
</VirtualHost>

но это не должно ввести вас в заблуждение. Имя компьютера будет разрешено в IP-адрес, а он-то и определяет, какой FTP-сайт будет обслуживаться. Если у вас несколько имен компьютеров, которые DNS преобразует в один и тот же IP-адрес, и у каждого из них есть свой раздел <VirtualHost>, будет выбран первый из них. Если у нескольких хостов есть что-то общее, можно вынести это в раздел <Global> файла настройки.

Чтобы это доказать, я назначил второй IP-адрес (192.168.1.69) сетевой карте FTP-сервера и добавил раздел в proftpd.conf – вы можете найти ее на нашем DVD. «Второй» FTP-сервер предоставляет анонимный доступ к каталогу /var/ftp/secondary/pub. Я также создал файл /var/ftp/secondary/welcome.msg с приветствием.

Многие возможности ProFTPD остались за рамками нашего обзора – они включают управление доступом, ведение журналов и «песочницы» chroot.


Некролог для FTP?

FTP – протокол древний. Первые RFC датируются 1971 годом, а формально он был определенв RFC454 (1973) и RFC959 (1985). Приблизительный современник Telnet, FTP был изобретен задолго до брандмауэров, частных адресных пространств, NAT и прочих сомнительных удовольствий современного Интернета, и не очень хорошо с ними ладит. Начнем с того, что FTP использует два различных соединения – для данных и для управления. Он работает в «активном» или «пассивном» режимах. Эти термины описывают ситуацию с точки зрения сервера, отражая его роль: инициирует ли он канал данных с клиентом или пассивно принимает его от клиента (см. рис. 1). В активном режиме серверу почти наверняка не удастся сделать это из-за фильтрации и маскирования пакетов, выполняемых шлюзом, через который клиент подключен к Интернету. Пассивный режим проще, но ему все равно необходим отдельный порт (на сервере) для каждого клиента, и потенциально на брандмауэре сервера должно быть открыто множество портов.

В FTP нельзя задать полное имя (FQDN) сайта, с которым производится соединение, что делает невозможным виртуальный хостинг на основе имен. Механизм аутентификации, при котором имя и пароль (да и сами файлы) передаются в открытом виде, в нынешнем озабоченным безопасностью Интернете безнадежно устарел.

Часть этих трудностей можно обойти перенаправлением локального порта SSH для создания защищенного туннеля для FTP-траффика – и есть кое-какие удобные хитрости при отслеживании соединения, которые помогут брандмауэрам приспособиться к необычному использованию портов в FTP. Но все это напоминает мне Главный дуб в Шервудском лесу, давно уж навалившийся на ограду. При виде него я порываюсь из жалости выдернуть подпорки и дать почтенному дереву упасть и достойно умереть, чтобы по законам природы на его месте появился новый росток.

Где узнать больше

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF132:DrBrown3&oldid=12283»
Персональные инструменты
купить
подписаться
Яндекс.Метрика