Глава 5. Проблемы с конфигурацией

Загляните в директорию примерные конфигурации (sample-configurations/) из вашего дистрибутивного tarball. В основном, вам необходимо создать еще одного пользователя в вашей системе для гостевого/анонимного ftp логина. По причинам сохранения безопасности, очень важно для вас проверить, что пользовательский аккаунт либо имеет пароль, либо имеет пароль, который невозможно подобрать. Корневая директория гостевого/анонимного аккаунта не обязательно должна быть директорией пользователя, но есть смысл сделать именно таким образом. После того, как вы создали аккаунт, запишите нечто подобное в свой файл /etc/proftpd.conf (учитывая то, что новое имя пользователя/группы - private/private):

<Anonymous ~private>
AnonRequirePassword off
User private
Group private
RequireValidShell off
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>
          

Это позволит клиентам ftp логиниться на вашем сайте с именем пользователя "private" и своим e-mail адресом в качестве пароля. Вы можете поменять AnonRequirePassword директиву на "on", если вы хотите, чтобы клиенты сообщали правильный пароль для "частного" аккаунта. Эта пробная конфигурация позволяет клиентам изменять info, просматривать и читать все директории, но запрещает любой доступ для записи.

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

Чтобы задействовать корень ftp, убедитесь в том, что директива "RootLogin on" включена в вашу конфигурацию.

Следующие отрывки из примерной файла конфигурации иллюстрируют, как защитить "загрузочную" ("upload") директорию (что очень эффективно, если вы не хотите, чтобы пользователи использовали ваш сайт в качестве материала для пиратства ("warez")) :

<Anonymous /home/ftp>
  # All files uploaded are set to username.usergroup ownership
  User username
  Group usergroup
  UserAlias ftp username
  AuthAliasOnly on
  RequireValidShell off

  <Directory pub/incoming/>
     <Limit STOR CWD>
        AllowAll
     </Limit>
     <Limit READ RMD DELE MKD>
        DenyAll
     </Limit>
  </Directory>
</Anonymous>
          

Это отменяет все письменные операции в анонимной корневой директории и под-директориях, за исключением директории "входящие" ("incoming/"), где как раз наоборот, клиент может хранить информацию, но ничего не считывать. Если вы воспользовались <Limit WRITE> вместо <Limit STOR> в <Directory incoming>, ftp клиентам будет разрешено выполнять все письменные операции в под-директории, включая удаление, переименование и создание директорий.

Вышеупомянутый фрагмент будет контролировать анонимных пользователей. Однако, если местный пользователь с полным аккаунтом, имеющий право на скачивание и закачивание, неверно использует пространство, то возможные меры против этого ограничены. Для начала хорошо бы использовать разумную системную квоту, при помощи mod_quota и mod_ratio модулей можно контролировать частотность и скорость скачиваний/закачиваний, что уменьшит значимость сайта для пиратов. В конечном итоге это приводит к мониторингу системы, верной политике допустимого использования (AUP) и контролю.

Да. Вам необходимо написать скрипт(программу) которая регулярно, через xyz секунд будет проверять изменение содержимого директории и перемещать-переименовывать содержимое в случае, если были изменения с момента предыдущей закачки. Либо нужен будет скрипт, который будет следить за логами (статистикой) закачки. Автоматического метода для выполнения ротации не существует.

Используйте HideUser или HideGroup директиву в комбинации с необходимым пользователем/группой. Например, если у вас есть следующая директория в вашем анонимном ftp дереве:

drwxrwxr-x 3 ftp staff 6144 Apr 21 16:40 private
          

то вы можете использовать такую директиву, как "HideGroup staff", для того, чтобы скрыть личную директорию от просмотра директорий (directory listing). Например:

<Anonymous ~ftp>
...
<Directory Private>
HideGroup staff
</Directory>
...
</Anonymous>
          

Вам необходимо убедиться, что группа, которую вы "прячете", не является изначально анонимной ftp группой, в этом случае HideGroup не сработает.

Вы можете либо изменить правила доступа к директории, чтобы предотвратить доступ к ней анонимных FTP пользователей, либо, если вы хотите сделать директорию абсолютно невидимой (как будто ее не существует), воспользуйтесь IgnoreHidden директивой внутри <Limit> блока для одной и более команд, которые должны игнорировать спрятанные разделы директории (игнорировать = действовать так, как будто данного раздела директории не существует).

Вам понадобится сконфигурировать ваш хост таким образом, чтобы он справлялся с наличием множества IP адресов. Это часто называется "совмещение имен" ("aliasing") и может быть сконфигурировано главным образом через IP псевдоним или фиктивный интерфейс. Чтобы узнать, как это делается, вам необходимо прочитать документацию к вашей оперативной системе. Как только ваш хост будет сконфигурирован для приема дополнительного IP адреса, на который вы хотите установить виртуальный FTP сервер, можете создавать виртуальный сервер при помощи директивы конфигурации <VirtualHost> :

<VirtualHost 10.0.0.1>
ServerName "My virtual FTP server"
</VirtualHost>
          

Вы можете добавлять дополнительные блоки директив в блок <VirtualHost> для того, чтобы создать анонимные/гостевые логины, логины ,которые доступны только на виртуальном хосте.

Воспользуйтесь блоком <Limit LOGIN> для закрытия доступа на верхнем уровне виртуального хоста, а затем снова используйте <Limit LOGIN> в своем <Anonymous> блоке для разрешения доступа к анонимному логину. Это дает возможность логиниться к анонимному серверу, и только к нему. Пример:

<VirtualHost 10.0.0.1>
ServerName "My virtual FTP server"
<Limit LOGIN>
DenyAll
</Limit>
<Anonymous /usr/local/private>
User private
Group private
<Limit LOGIN>
AllowAll
</Limit>
...
</Anonymous>
</VirtualHost>
          

Директива <LOGIN> используется для контроля соединения или доступа к определенному контексту (блок директивы, который его содержит). Когда клиент изначально подсоединяется к ProFTPD, демон (daemon) ищет на дереве конфигурации <Limit LOGIN> директивы и прилагающиеся параметры (такие как Allow, Deny, etc). Если оказывается, что клиент не может получить доступ по каким-либо причинам, появится сообщение "Deny from", без "Allow from" на нижнем уровне, что означает прерывание соединения с клиентом, который в этом случае не имеет возможности передавать имя пользователя и пароль.

Однако, если клиент все же имеет возможность доступа, ProFTPD продолжает работу как обычно, позволяя клиенту логиниться только при указании правильного <Limit LOGIN>. Обычно блоки директивы <Limit> допустимы в server config, <VirtualHost>, <Anonymous> и <Directory> контекстах. Однако, <Limit LOGIN> не должен использоваться в <Directory> контексте, поскольку клиенты не подсоединяются/логинятся к директории (и следовательно, это бесполезно).

В качестве примера, следующие отрывки конфигурации иллюстрируют <Limit LOGIN> ограничение, которое приведет к тому, что любые входящие соединения 10.1.1.x подсети будут немедленно прерваны без предупреждения:

...
<Limit LOGIN>
Order deny,allow
Deny from 10.1.1.
Allow from all
</Limit>
...
          

Затем приведем пример конфигурации с <Limit LOGIN>, при которой соединение не будет сразу же прервано, а сначала вы получите сообщение "Неправильный логин" ("Login invalid") при любой попытке залогиниться (кроме анонимного логина).

...
<Limit LOGIN>
DenyAll
</Limit>
<Anonymous ~ftp>
...
<Limit LOGIN>
AllowAll
</Limit>
...
          

Существует по крайней мере два способа. Во-первых, вы можете создать структуру директории внутри вашей анонимной корневой директории FTP, создав отдельную директорию для каждого пользователя и соответственно настроив право собственности/ другие права. Затем, либо создайте symlink из домашней директории каждого пользователя на сайт FTP, либо проинструктируйте ваших пользователей по поводу того, как получить доступ к этой директории.

Другой способ (кстати, более универсальный) создания анонимного FTP для каждого пользователя FTP - это использовать команду AnonymousGroup в сочетании с DefaultRoot директорией. Возможно, вам захочется сделать это внутри <VirtualHost>, в противном случае ни один из ваших пользователей не сможет получить доступ к вашей системе без зависания на своем FTP сайте. Вдобавок к этому, вам потребуется использовать задержанный блок <Directory>, чтобы ограничить доступ извне к сайту каждого пользователя.

1. Создайте в вашей системе новую unix группу под именем `anonftp". Пожалуйста, включите в эту группу всех пользователей, имеющих свой анонимный FTP.

2. Создайте директории `anon-ftp" и `anon-ftp/incoming" в домашней директории каждого пользователя.

3. Модифицируйте ваш /etc/proftpd.conf файл, чтобы он выглядел примерно следующим образом (возможно, вам захочется переделать его для ваших нужд):

    <VirtualHost my.per-user.virtual.host.address>
    
    # следующая строка ограничивает все логины к данному виртуальному хосту, чтобы могли коннектиться только anonftp пользователи 
    
    <Limit LOGIN>
    DenyGroup !anonftp
    </Limit>
    
    # ограничить доступ любому пользователю в корневую директорию анонимного пользователя (anon-ftp directory), мы хотим предоставить 
    только возможность чтения пользователям, зашедшим в архив анонимно, за исключением директории incoming
    
    <Directory ~/anon-ftp>
    
    <Limit WRITE>
    DenyAll
    </Limit>
    
    </Directory>
    
    # позволяет сохранить доступ к директории anon-ftp/incoming каждого пользователя, но запрещает все другие операции
    
    <Directory ~/anon-ftp/incoming>
    
    <Limit STOR>
    AllowAll
    </Limit>
    <Limit READ WRITE>
    DenyAll
    </Limit>
    
    </Directory>
    
    # предусматривает корень по умолчанию для всех логинов к этому виртуальному хосту.
    DefaultRoot ~/anon-ftp
    # И наконец, сделайте все логины анонимными для anonftp группы
    AnonymousGroup anonftp
    
    </VirtualHost>
                 

Вы можете использовать директиву AuthAliasOnly для того, чтобы контролировать, как и где определяются реальные имена пользователей (в отличие от псевдонимов, посредством директивы UserAlias). Обратите внимание, что все еще невозможно иметь два идентичных псевдонима для логина к разным анонимным сайтам; для чего вам понадобится <VirtualHost>.

Example:

...
<Anonymous ~jrluser>

 User jrluser
 Group jrluser
 UserAlias ftp jrluser
 UserAlias anonymous jrluser
 AuthAliasOnly on
 ...
 
</Anonymous>
          

Здесь, конфигурация <Anonymous> для ~jrluser настроена так, чтобы позволить только аутентификацию псевдонима. Таким образом, если клиент пытается идентифицироваться как "jrluser", анонимная конфигурация будет проигнорирована и клиент будет идентифицирован как обычный пользователь (естественно, `jrluser" сможет логиниться как обычный пользователь). Однако, если клиент использует псевдоним `ftp" или `anonymous", применяется блок anonymous.

Что проверить

Проверьте прежде всего следующее:

• Убедитесь в том, что пользователь/группа, которые вы указали в <Anonymous> блоке, действительно существует. Это должны быть реально существующие пользователь и группа, как это используется для контроля того, что запускает daemon и как это аутентифицируется

• Если RequireValidShell специально не выключен, убедитесь, что ваш "ftp user" (как указано в User директиве в <Anonymous> блоке), имеет верный командный процессор (shell), указанный в /etc/shells. Если вы не хотите выдавать пользователю верный shell, вы всегда можете воспользоваться "RequireValidShell off" для отключения данной проверки.

• Если UseFtpUsers специально не выключен, убедитесь, что ваш "ftp user" не указан в списке /etc/ftpusers.

Если все остальное не работает, вам необходимо проверить ваш системный журнал (syslog). Когда по какой-либо причине аутентификация не удастся, ProFTPD использует механизм syslog для того, чтобы зарегистрировать причину неполадки; это производится при помощи AUTH (или AUTHPRIV) функции. Если вам нужна дальнейшая помощь, вы можете послать email, включив в него syslog отрывки, связанные с интересующим вас вопросом, а также ваш файл конфигурации, на лист рассылки ProFTPD, указанный в данном FAQ.

Была сделана новая вставка с директивой TransferRate и включена в 1.2.8, что дает ограничения диапазона частот при каждом соединении с Class поддержкой. Ограничения более эффективны против скачиваний, чем закачиваний. Нет специального способа для контроля общего диапазона, который может использовать один VirtualHost.

AllowChmod очень часто критиковался, а потому был заменен на SITE_CHMOD расширение для контроля этой функции.

Как у 1.2.7r1, существует две новых директивы MaxRetrieveFileSize и MaxStoreFileSize для контроля максимального размера файлов, которые передаются от и к серверу.

просто удалите все <Anonymous> секции из вашего файла конфигурации и перегрузите daemon.

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

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

Чтобы позволить возобновление закачиваний, вам необходимо использовать как директиву AllowOverwrite, так и директиву AllowStoreRestart. Причина для разрешения закачиваний и скачиваний состоит в том, что возобновленное (restarted/resumed) закачивание - вид переписывания файла.

Также обратите внимание на то, что использование HiddenStor и AllowStoreRestart вместе невозможно, как это указано в документации для AllowStoreRestart и HiddenStor директив.