 |
|
|
|
ProFTPD: мастер своего дела
ProFTPD: мастер своего дела Серверы FTP, несмотря на то, что они предоставляют один из старейших сервисов глобальной сети, по-прежнему остаются крайне популярными. Разработчики ПО постоянно стараются реализовать новые возможности в тесных рамках протокола FTP. И один из наиболее ярких представителей этой плеяды – проект ProFTPD При разработке FTP-сервера ProFTPD особое внимание уделялось безопасности и максимальной гибкости настроек. Практически во всём прослеживается влияние проекта Apache – от структуры конфигурации и файлов .ftpaccess до модульной архитектуры. Сервер полностью поддерживает базовый протокол FTP, определённый в RFC 959, а также многие функции, описанные в RFC 1123. Приставка «Pro», фигурирующая в названии, полностью оправдывает себя – это действительно профессиональный сервер, с помощью которого вы можете реализовать практически всё, что может потребоваться от FTP-сервера. Конечно, все его возможности в рамках одной статьи охватить неисполнимо, но наиболее важные моменты я постараюсь для вас осветить. Инсталляция Установка выполняется достаточно традиционно. Пользователи Linux наверняка (учитывая большую популярность данной программы) найдут предкомпилированный пакет для своего дистрибутива. Для FreeBSD стандартная рекомендация – установить сервер из коллекции портов. Ну и, естественно, вы всегда можете вручную собрать ProFTPD из исходных кодов. В дальнейшем все примеры будут относиться к FreeBSD (для конкретики), так что приступим к установке. Обновив коллекцию портов, даём команду: # /usr/local/sbin/portinstall proftpd Можно, конечно, и традиционно (cd /usr/ports/ftp/proftpd; make install), но утилита portupgrade предоставляет целый ряд дополнительных возможностей, так что от себя порекомендую установить её в любом случае. Запустив установку порта впервые, вы получите изображённое на рис. 1 диалоговое окно, где нужно будет отметить дополнительные модули, с которыми вы желаете собрать ProFTPD.
Рисунок 1. Диалог выбора дополнительных модулей ProFTPD Если коротко, то эти модули выполняют следующие функции:
О некоторых из них мы ещё поговорим, но вам уже сейчас нужно будет определиться с тем, какие модули вам понадобятся, так как при необходимости добавить что-то к уже работающему серверу вам придётся пересобирать ProFTPD с новыми параметрами. Но и включать всё, что есть, про запас, тоже не стоит – «меньше ставишь – лучше спишь».
Рисунок 2. Модульная архитектура ProFTPD (показаны не все модули) Кстати, запустив в следующий раз установку этого порта (например, чтобы изменить список модулей или обновить версию), вы уже не увидите этот диалог – ваш нынешний ответ будет сохранён в файле /var/db/ports/proftpd/options. Так что вам нужно будет либо удалить этот файл (вместе с каталогом proftpd), либо выполнить нужные правки прямо в нём. Пользователям Linux нужно будет подыскать подходящий пакет, собранный с нужными модулями, либо ставить из исходных кодов, указав нужные расширения с помощью параметра with-modules в команде ./configure, например, так: # ./configure --with-modules=mod_rewrite:mod_postgresql Более подробно о параметрах сборки можно, как обычно, узнать, введя команду: # ./configure --help Посмотреть полный список подключенных модулей (включая модули, собираемые по умолчанию) можно с помощью следующей команды (вводить её следует после инсталляции): $ /usr/local/sbin/proftpd –l
В зависимости от того, какой из способов установки вы выберете, вам может понадобиться выполнить вручную некоторые действия:
В случае FreeBSD от вас потребуется только подготовить рабочие каталоги и добавить в /etc/rc.conf строчку «proftpd_enable = YES», чтобы получить возможность управлять сервисом с помощью сценария /usr/local/etc/rc.d/proftpd.sh, который заодно обеспечивает и автозапуск демона при загрузке системы. Но прежде чем запускать наш FTP-сервер, проследуем в конфигурационный файл (/usr/local/etc/proftpd.conf) и посмотрим, нет ли в настройках по умолчанию чего-то такого, о чём мы могли бы пожалеть в дальнейшем. Структура конфигурационного файла Сразу же бросается в глаза его синтаксическая схожесть с httpd.conf – конфигурационным файлом Apache. В файле proftpd.conf можно выделить следующие секции (области действия директив):
Кроме конфигурационного файла, некоторые настройки могут быть выполнены в файлах .ftpaccess (если не запрещено переопределение параметров директивой «AllowOverride off»). Действие данного файла распространяется на каталог, в котором он размещён, и на все вложенные каталоги. Приоритетом будет пользоваться та директива, «вложенность» которой больше, т.е. та, действие которой охватывает меньшую область сервера. Директивы можно условно разделить на две категории: «параметрические», которые требуют указать некоторый параметр (например, IP-адрес), и «логические», которые в качестве параметра принимают ключевое слово «on» или «off», соответственно включая или отключая действие директивы. В дальнейшем в данной статье для параметрических директив будет приводиться синтаксис их параметров; логические директивы будут указаны без параметров (за исключением случаев, когда требуется подчеркнуть необходимость установить конкретное значение). Некоторые сведения о режимах работы В первую очередь нужно будет определиться с тем, как ваш сервер должен работать. Поддерживается два режима – inetd и standalone, что определяется параметром ServerType. В первом режиме, как следует из его названия, proftpd будет запускаться суперсервером inetd (это же относится и к xinetd, более популярному в современных дистрибутивах Linux). Это, может быть, разумно в том случае, если inetd у вас запущен (в последнее время хорошим тоном стало отказываться от его использования) и нагрузка на FTP крайне низка, что не оправдывает постоянное присутствие в памяти ещё одного демона. В данном случае управлять установлением соединений будет inetd (он прослушивает 21-й порт и принимает решение о том, принять или отклонить запрос на соединение, руководствуясь файлами /etc/hosts.allow и /etc/hosts.deny), однако возможности ProFTPD в этом режиме существенно ограничены (в частности, нельзя создавать виртуальные серверы). Помимо параметра «ServerType inetd» в файле /etc/inetd.conf следует закомментировать строки, относящиеся к «родному» серверу ftpd (чтобы не было конфликтов) и добавить строку для активации proftpd при получении запроса на 21-й порт (впрочем, вы можете использовать и нестандартный порт, если очень хочется): # ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Обязательно проверьте правильность пути к исполняемому файлу: на некоторых системах proftpd может быть установлен в /usr/sbin или в /usr/local/libexec. Автономный режим (standalone) оправдывает себя во всех остальных случаях. Теперь proftpd постоянно присутствует в памяти, самостоятельно прослушивая нужные адреса и порты и управляя всеми входящими соединениями. Кстати говоря, и время реакции на запрос пользователя в этом случае будет меньше, т.к. не придётся каждый раз считывать программу с диска и создавать новый процесс. Именно режим standalone используется по умолчанию, так что не будем ничего менять. Убедитесь, что в inetd.conf не активирован никакой сервис, обслуживающий порт, на котором будет работать proftpd, чтобы исключить конфликты. Ну и пока мы здесь, можно указать имя нашего сервера в параметре ServerName – оно будет выводиться в баннере приветствия при установке соединения. Управление соединениями ProFTPD предоставляет широчайшие возможности по управлению TCP-соединениями. Рассмотрим некоторые наиболее полезные параметры (напомню, что мы рассматриваем standalone-режим; в режиме inetd будет работать далеко не всё):
На самом деле параметров конфигурации значительно больше, ознакомиться со всем многообразием вы сможете в документах, ссылки на которые приведены в конце статьи. Здесь же рассмотрим два модуля: mod_wrap и mod_ratio. Модуль mod_wrap предназначен для обеспечения функциональности, которую в случае inetd реализует TCPWrapper. Собрав ProFTPD с поддержкой данного модуля, вы сможете указать файлы allow и deny, которыми сервер будет руководствоваться, принимая решение о том, обслуживать соединение с данного адреса или нет. Вы можете указывать эти файлы как для всех пользователей, так и для конкретных: TCPAccessFiles /etc/hosts.allow /etc/hosts.deny С помощью символа «~» вы можете подключить для каждого пользователя свои wrap-файлы, размещаемые в их домашних каталогах: TCPAccessFiles ~/.allow ~/.deny Формат файлов аналогичен /etc/allow.host, в качестве имени службы используется proftpd (можно задать другое с помощью TCPServiceName). Модуль mod_ratio позволяет вам устанавливать ограничения на соотношение скачиваемых файлов и загружаемых на сервер (грубо говоря, контролировать отношение исходящего трафика ко входящему). Рассмотрим следующую директиву: Ratios on Здесь мы для пользователя ftp ввели следующие ограничения:
Помимо этого вы можете устанавливать соотношения для хостов (HostRatio), групп (GroupRatio), анонимных пользователей (AnonRatio). Символ «*» можно использовать в значении «все» (например, все пользователи). Установка какого-либо параметра в 0 означает снятие ограничений. Права доступа и анонимные серверы Если сравнивать proftpd со стандартным ftpd, входящим в поставку FreeBSD, то в первую очередь следует отметить гораздо большие возможности первого в вопросах управления учётными записями и правами доступа. ProFTPD в полном объёме поддерживает стандартные средства управления доступом (авторизация по системному файлу паролей, использование файлов /etc/shells, чтобы предоставлять доступ только тем пользователям, которые имеют действительную командную оболочку, и т. п.). Помимо этого к вашим услугам ряд других замечательных возможностей, о которых и поговорим. Прежде всего отметим возможность использовать базу LDAP для аутентификации пользователей. Также вы можете вести базу виртуальных пользователей в обычном текстовом файле или в СУБД (поддерживаются MySQL и PostgreSQL). Для использования текстового файла, содержащего данные учётных записей, используются директивы AuthUserFile и AuthGroupFile. В этом случае ProFTPD будет руководствоваться данными этих файлов, как если бы пользователи, описанные в них, были обычными, зарегистрированными в системе. Формат файлов должен соответствовать системным, за исключением того, что пароль указывается в этом же файле (аналога shadow нет), так что предельно внимательно отнеситесь к ограничению прав доступа к этому файлу. Кроме того, вы можете указать требуемый логин и пароль непосредственно в конфигурационном файле proftpd с помощью директивы UserPassword. Как здесь, так и в файле, определенном директивой AuthUserFile, должны использоваться хешированные пароли (если верить ряду проведённых экспериментов, сервер самостоятельно определяет тип хеша по его виду; поддерживается DES и «стандартный» MD5, причём допускается их совмещение в одном файле). Для управления паролями можно использовать, например, входящую в состав Apache утилиту htpasswd (для формирования DES-паролей; то, что формирует эта утилита с ключом -m, сервером ProFTPD, не распознаётся как MD5-хеш). Также существует аналогичная утилита ftpasswd, разработанная специально для нужд ProFTPD, но в стандартную поставку, по крайней мере, во FreeBSD, она почему-то не включена. (Почитать про неё можно здесь:http://www.castaglia.org/proftpd/contrib/ftpasswd.html, а по этому адресу находится собственно текст данной утилиты, написанной на языке Perl: http://www.castaglia.org/proftpd/contrib/ftpasswd). Рассмотрим также хранение информации об учётных записях пользователей в базе данных на примере PostgreSQL. Прежде всего, убедитесь, что ваш proftpd собран с поддержкой модулей mod_sql и mod_sql_postgres. Теперь подготовим базу данных (назовём её proftpdb), в которой создадим две таблицы – users и groups: $ psql -U serg
# \c proftpdb serg
proftpdb=> create table users (username text, pass text, uid numeric,
proftpdb=> create table groups (groupname text, gid numeric, members text);
proftpdb=> insert into groups values('admins', 1000, 'admin');
proftpdb=> insert into users values ('admin', 'adminpassword', 1000,
proftpdb=> \q Как видите, структура таблиц очень напоминает структуру файла /etc/passwd. Вам следует соблюдать уникальность имён пользователя и группы, а также уникальность uid в файле users и gid в файле groups. Если пользователей предполагается не слишком много, то об этом можно заботиться и вручную. В противном случае следует установить на соответствующие поля признак UNIQUE, чтобы СУБД сама следила за их уникальностью. Последними двумя командами мы создаём группу «admins» и пользователя «admin». Теперь нужно указать ProFTPD, как использовать эти данные: ### Настройка авторизации в PostgreSQL # Поддерживаемые типы авторизации (в данном случае – открытый текст) # Имя таблицы пользователей и далее – имена полей # Имя таблицы групп и далее – имена полей # Сюда выводится отладочная информация (полезно на этапе настройки) Теперь вы можете входить на сервер под именем «admin», хотя такого системного пользователя и нет. Главное – чтобы его домашний каталог реально существовал, если вы используете директиву DefaultRoot ~. Обратите внимание, что после авторизации процесс, обслуживающий соединение, получит uid и gid, указанные в базе, так что вам следует позаботиться об отсутствии пересечений с системными пользователями. Также учитывайте этот факт в контексте прав доступа к тем или иным файлам (заметьте, что вы можете дать на любой файл или каталог права несуществующего пользователя, указав любые нужные вам идентификаторы, например, так: chown 9999:9999 /home/admin). Для организации анонимного доступа используется секция <Anonymous каталог>, где каталог – это имя каталога (абсолютный путь или с использованием символа ~), доступ в который будет осуществляться без обязательного знания пароля. Типичный пример приведён ниже: <Anonymous ~ftp> # Анонимный доступ в каталог ~ftp Если в секции <Anonymous> вы укажете директиву AnonRequirePassword off, то вход на сервер будет выполняться сразу после ввода имени пользователя (в нашем случае – ftp или anonymous). Если же использовать значение «on», то у пользователя будет запрошен адрес электронной почты в качестве пароля (хотя ввести он сможет там всё что угодно). Более подробного рассмотрения заслуживает упомянутая выше секция <Limit>. С её помощью вы можете вводить ограничения как для всех пользователей (как в приведённом выше примере), так и для конкретных пользователей или групп. Вы можете налагать ограничения на использование конкретных команд FTP-протокола (например, <Limit STOR> будет управлять использованием команды STOR). Существует несколько «макросов», охватывающих целые наборы FTP-команд (например, WRITE (группа команд записи), READ (группа команд чтения), DIRS (работа с каталогами). Секция <Limit LOGIN> определяет возможность выполнять процедуру входа на сервер. Также нужно сказать пару слов о директиве AllowOverwrite, с помощью которой вы можете полностью запрещать (off) или разрешать (on) перезапись существующих на сервере файлов (дополнительно пользователь, пытающийся выполнить такую перезапись, должен обладать достаточными системными правами). Ну и последнее, о чём следует упомянуть, говоря о процедуре входа в систему, это о приветственных сообщениях, которые будут выводиться пользователю в том или ином случае (при входе на сервер, при переходе в тот или иной каталог и т. д.). ProFTPD позволяет довольно гибко управлять этими сообщениями, благодаря чему вы сможете сделать работу на сервере достаточно простой и понятной. Конечно, большинство FTP-клиентов просто игнорируют подобные сообщения, но для работы с помощью консольного клиента они могут быть полезны. Если вам захочется изменить то или иное сообщение, обратитесь к документации (см. директивы AccessDenyMgs, AccessGrantMsg, группу опций Display*), и вы наверняка найдёте способ сделать это. Виртуальные серверы Виртуальный FTP-сервер? А почему бы, собственно, и нет! Конечно, это будет не то же самое, что мы привыкли видеть в Apache, когда на один IP-адрес «навешивается» несколько десятков, а то и тысяч «народных» сайтов. Всё дело в том, что в протоколе FTP нет того «волшебного» параметра заголовка – Host, – который позволяет веб-серверу, поддерживающему протокол HTTP версии 1.1, разобраться, что же на самом деле клиент желает увидеть на экране своего монитора. В случае FTP каждый виртуальный сервер всё же должен иметь свой собственный IP-адрес, по которому к нему будет осуществляться доступ. Для тех, кто испытывает дефицит адресного пространства (а разве бывает так, чтобы IP-адресов всегда хватало?), есть обходной маневр – то, что в Apache называют «port-based vhosts». Вы можете настроить ProFTPD таким образом, что каждый виртуальный сервер будет прослушивать свой порт. Очевидно, что это непригодно для коммерческого хостинга, когда каждый клиент ожидает получить «стандартный» сервер, который будет отвечать на запросы, адресованные на 21-й порт. Однако для личных нужд (например, когда FTP используется для доступа к корню веб-сервера) такой метод может оказаться вполне пригодным. Так что мы уделим внимание и ему. Итак, виртуальный сервер задаётся секцией <VirtualHost IP-адрес>. Вместо адреса можно указать и доменное имя. В данной секции допускаются очень многие директивы, управляющие работой сервера – вы можете задать отдельного пользователя, с чьими правами он будет работать; настраивать анонимный доступ; установить собственный способ авторизации; вводить различные ограничения. Общие для всех виртуальных хостов опции можно вынести в секцию <Global>. Пример конфигурации см. ниже, в решении задачи 5. Другие директивы, которые могут быть полезны Существует масса директив, которые отвечают за запись информации в лог-файлы, за фильтрацию запросов с помощью регулярных выражений (например, чтобы установить ограничения на файлы с определённым расширением), за специальную обработку файлов (например, можно автоматически добавлять префикс ко всем загружаемым на сервер файлам или управлять правами доступа с помощью Umask), и т. д. Вы можете управлять дисковыми квотами (модуль mod_quota, директивы DefaultQuota, QuotaType, UserQuota, GroupQuota и др.), скоростью скачивания, и проч. В общем, ознакомьтесь с документацией – там много интересного. Несколько практических примеров Для закрепления материала рассмотрим небольшие примеры, демонстрирующие решение некоторых задач, связанных с настройкой FTP-сервера. Пример 1. Конфигурация, близкая к стандартной Постановка задачи:
Решение: эту задачу можно решить в два этапа – во-первых, ограничим доступ домашними каталогами всем пользователям, кроме пользователя admin (первая строка примера). Поскольку пользователи dialup не имеют реальной командной оболочки, то второй строкой отключим проверку наличия shell пользователя в файле /etc/shells. Ну и, во-вторых, в секциях <Limit> «отсекаем» возможность входить на сервер (LOGIN) и писать в каталоги (WRITE) для всех, кто не входит в перечисленные в директиве AllowGroup группы: DefaultRoot ~ !admin Теперь admin будет свободно «бродить» по всему дереву каталогов, а члены групп wheel и dialup смогут работать в своих домашних каталогах. Заметьте, что пользователь admin должен быть членом одной из указанных групп (скорее всего, он уже входит в wheel), иначе ему не позволят авторизоваться. Пример 2. Несколько анонимных каталогов Постановка задачи: требуется настроить на одном FTP-сервере три анонимных каталога – для разработчиков, для тестеров и для пользователей. Решение: в данном случае проще всего создать три секции <Anonymous> для разных пользователей, имена которых должны вводиться при подключении. Для определенности разработчикам нужно будет входить под именем developer, тестерам – tester, остальным пользователям – под стандартными anonymous/ftp (ну и для общности добавим ещё один псевдоним – user): <Anonymous ~developer> <Anonymous ~tester> <Anonymous ~user> Заметьте, что имя каталога, указанного в теге <Anonymous>, не обязательно должно совпадать с именем пользователя – оно может указывать на любой существующий каталог. Имя же пользователя, при вводе которого осуществляется анонимный вход, задаётся директивой User, причём указанный пользователь должен существовать в системе (в случае виртуальных пользователей для них должны быть указаны uid и gid, под которыми будет запущен процесс). В последней секции мы указываем два псевдонима, чтобы в этот каталог можно было попасть не только под именем user, но и как ftp или anonymous. Пример 3. Общий каталог Постановка задачи: есть группа пользователей, которым нужно предоставить полный доступ каждому в свой домашний каталог, а также в общий для всех каталог только на чтение. Решение: сразу напрашивается идея использовать символьную ссылку на общий каталог из домашних каталогов пользователей, а затем «запереть» всех с помощью «DefaultRoot ~». Однако выход за пределы корневого (в данном случае – домашнего для пользователя) каталога по символьной ссылке запрещён. Так что нужно искать обходной путь, например, такой: DefaultRoot /home !admin Чтобы это сработало, должны выполняться некоторые ограничения – все домашние каталоги пользователей должны размещаться в /home, кроме того, на них должны быть выставлены права 0700 (доступ только владельцу каталога). Общий каталог также должен располагаться в /home, но с правами, позволяющими любому пользователю читать его содержимое. В этом случае события будут развиваться следующим образом:
Пример 4. Запись без права чтения Постановка задачи: разрешить анонимным пользователям загрузку файлов на сервер. Чтобы избежать злоупотреблений (когда ваш анонимный сервер превратится в средство обмена «пиратскими» файлами), чтение из данного каталога необходимо запретить (в дальнейшем администратор будет просматривать файлы и публиковать нужные в других каталогах). Решение: здесь всё достаточно просто – на рассматриваемый каталог нужно установить соответствующие ограничения (в секции LIMIT): <Anonymous ~ftp> То есть для каталога upload мы выставляем «инверсные» права – разрешаем запись, но запрещаем чтение. Пример 5. Виртуальные серверы Постановка задачи: есть два «очень важных» клиента, которым необходимо предоставить виртуальные FTP-серверы на стандартном порту (21), при этом администратор должен иметь возможность работать с сервером с помощью третьего FTP-сервера. При этом реальных адресов на сервере – всего два. Решение: поскольку «очень важных» клиентов ущемлять в правах нельзя, придется им давать «нормальный» хостинг на реальных IP-адресах. Страдать, как обычно, будет администратор, которому придётся довольствоваться работой через нестандартный порт (для красоты выберем порт 2121): DefaultAddress user1.mydomain.ru <VirtualHost user1.mydomain.ru> <VirtualHost user2.mydomain.ru> Что здесь нужно пояснить: вне секций мы описываем параметры «административного» сервера, который будет привязан к домену user1.mydomain.ru и порту 2121. Директива «SocketBindTight on» требует от ProFTPD «разумного» подхода к созданию сокетов, когда порты прослушиваются только на тех адресах, где это необходимо, а не на всех обнаруженных интерфейсах. Ну и секциями <VirtualHost> вводим наши пользовательские серверы (показаны только директивы, отвечающие за создание виртуальных серверов). Напутствие Пожалуй, приведённых сведений должно быть достаточно, чтобы начать работать с ProFTPD. Но, как вы можете увидеть в документации, существуют ещё десятки (если не сотни) опций, с помощью которых можно добиться от сервера почти всего, что вам может понадобиться. Как говорится, нет предела совершенству. Дополнительную информацию вы всегда можете получить по ссылкам, приведённым ниже. Удачи вам и настойчивости, чтобы преодолеть всё! Примечание Вспомогательные утилиты В составе пакета ProFTPD вы найдёте несколько утилит, которые могут быть весьма полезны для мониторинга работы вашего FTPсервера и поиска в его работе «узких мест»:
Для каждой команды есть подробная страница справки (man).
сЕРГЕЙ сУПРУНОВ |
СЕРГЕЙ СУПРУНОВ
| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
