Как это бывает со всем программным обеспечением, здесь был ряд проблем с системой безопасности во время работы проекта. Наиболее свежая информация всегда доступна на http://www.proftpd.org/security.html
Версии 1.2.0 и более ранние версии должны рассматриваться в качестве кода продукции, если какие-нибудь новые черты будут добавлены к коду для поддержания стабильности.
Как насчет использования Stackguard?
Stackguard (http://immunix.org/) - является вариантом gcc, который может защищать программы от stack-smashing атак, программы, скомпиллированные при помощи Stackguard перестают функционировать, не выполняя при этом stack код. Такой подход к данной проблеме - первый шаг к устранению возможных неприятностей в будущем, однако, это не панацея. Иногда переполнение буфера обнаруживаются в статичных переменных, которые не защищены механизмом stack-защиты.
Запуск ProFTPD в виде не-корневого пользователя дает лишь незначительное улучшение в системе безопасности в обычном случае и добавляет функциональных проблем. Например, такие, как невозможность связаться с портом 20 или 21, если только не прибегать к опции inetd.
ProFTPD выбирает промежуточный путь в области безопасности. Он пользуется только привилегиями корня, где это необходимо, и выходит в UID, указанный в файле конфигурации, во всех других случаях. Когда необходим корень, происходит связывание с портами < 1024, настройка ограничений источника, считывание конфигурационной информации и некоторых сетевых кодов.
Для Linux 2.2.x систем, имеющих ядро, существует POSIX mod_linuxprivs модуль, который позволяет иметь очень высокую степень контроля привилегий. Мы это очень рекомендуем для системных администраторов, заботящихся о безопасности.
Воспользуйтесь Allow/DenyFilter, данные директивы используют регулярные выражения для контроля всей информации, пересылаемой через панель управления. (Если кто-то может привести здесь хороший пример, пожалуйста, сообщите мне.)
Настройка SeverIdent на "off" должна отключить указание такой информации, как - сервер какого типа работает. Чтобы нам получить максимальный эффект, эта директива должна быть либо в Global контексте, либо должна быть включена в каждый виртуальный host блок и default блок.
ServerIdent On "Linux.co.uk server"
ServerIdent Off
Воспользуйтесь директивой DisplayConnect для указания файла, содержащего сообщение, которое должно быть показано перед логином.
DisplayConnect /ftp/ftp.virtualhost/login.msg
Воспользуйтесь директивой DisplayLogin, которая посылает указанный файл ASCII подсоединенному пользователю.
DisplayLogin /etc/proftp.msg
Воспользуйтесь директивой AccessGrantMsg, которая посылает сообщение в одну строку обратно пользователю после успешной аутентификации. Магические cookies очень помогают данной директиве.
AccessGrantMsg "Guest access granted for %u."
Обратите внимание, что эта директива имеет установку на игнорирование и необходимо вносить дополнения как в VirtualHost, так и в Anonymous блоках.
ProFTPD был разработан для работы в качестве безопасного ftp сервера, это значит, что он пытается держать как можно больше под своим контролем. Внешняя программа сама по себе уже представляет риск для системы безопасности, потому что ее очень трудно контролировать из ftpd кода.
Данное сообщение генерируется mod_tls, третьим модулем, который может быть использован для шифровки как control, так и data соединений с TLS (Transport Layer Security - безопасность транспортного уровня), следующим поколением SSL. Сертификаты используются для установления контекста безопасности для этого безопасного транспортного протокола.
Генерация сертификатов не входит в рамки данного документа; однако, более подробно об этом вы можете прочитать вот здесь:
ProPTPD следует правам пользования UNIX файлов, когда определение уровня доступа и/или контроля пользователя определяется при работе с файлом. Системы UNIX разделяют мир на три класса при определении прав пользования, которые получает пользователь на определенный файл:
Пользователь - владелец файла
Группа - собрание пользователей, указанных в /etc/group
Другие - не владельцы, не члены группы
Каждый файл в системе файлов Unix имеет описание прав на пользование им. По крайней мере, разрешения, установленные для пользования файлом, будут указывать, может ли конкретный пользователь читать (READ), писать (WRITE), или выполнять (EXECUTE) данный файл. Листинг директории покажет права пользования данным файлом в приведенном ниже формате:
rwx r-x r-x | | | | | |_____________ Others: READ/NO WRITE/EXECUTE | |__________________ Group: READ/NO WRITE/EXECUTE |_______________________ User: READ/WRITE/EXECUTE
В примере листинга директории, указанном ниже, READ/WRITE/EXECUTE привилегии даются владельцу директории, а привилегии READ/EXECUTE даются членам users группы и всем остальным. Обратите внимание, что буква "d" в начале каждой записи указывает на то, что запись на самом деле является директорией.
prince> ls -l /home/ftp total 8 drwxr-xr-x 2 andrea users 4096 May 3 00:40 andrea drwxr-xr-x 2 eve users 4096 May 3 00:40 eve prince> ls -l /home/ftp/andrea total 156 -rw-r--r-- 1 andrea users 85991 May 3 01:12 bland.txt -rwxr-xr-x 1 root root 65107 May 3 01:12 secret.txt
Ответ на этот вопрос дан в примере выше. При описании разрешений на пользование директорией, WRITE означает, что право пользования дается для того, чтобы изменять содержание директории, добавляя или удаляя файлы. Таким образом, пользователь andrea может удалить файл secret.txt, несмотря на то, что она не может изменить сам файл.
Обращайтесь к документации за IgnoreHidden и HideNoAccess директивами, чтобы найти способ сведения этой опасности к минимуму.