Защита общей настройки lighttpd

(Да, я знаю, что вопросы, касающиеся lighttpd, лучше подходят для SF, но я подумал, что их лучше задавать здесь, так как они в первую очередь связаны с политикой безопасности.)

Мы планируем установить небольшой веб-сервер в моем колледже, чтобы люди могли получить немного веб-пространства для размещения веб-страниц и тому подобного. Они также могли загружать PHP-страницы. Вся установка выполняется из chroot-тюрьмы.

Мы думаем о том, чтобы использовать ту же инфраструктуру для создания дополнительных сервисов, например дискуссионного форума. Моя проблема заключается в том, что размещение форума в том же корневом каталоге документа (или, на самом деле, в той же среде с chroot) практически позволяет любому пользователю размещать небольшие PHP-скрипты в своих каталогах, которые могут получить доступ к файлам конфигурации форума (используя , скажем, file_get_contents). Это огромный риск для безопасности! Есть ли способ решить эту проблему, за исключением отключения PHP для учетных записей пользователей и сохранения его включенным только для дискуссионного форума и т.п., или обслуживать форум в другом месте и проксировать его с помощью lighttpd?

Я сомневаюсь, что установка прав собственности/разрешений как-то поможет это исправить, поскольку, как мне кажется, процесс PHP FastCGI порождается веб-сервером и, следовательно, любая страница, к которой может получить доступ сервер (все они должны быть, видя, что в конечном итоге их должен обслуживать сервер) могут быть доступны с помощью PHP-скриптов, загруженных пользователем.

Любая помощь будет оценена по достоинству!


php security lighttpd
person susmits    schedule 06.07.2010    source источник
comment
Это должно быть при ошибке сервера.   -  person rook    schedule 06.07.2010

Ответы (2)


arrow_upward
2
arrow_downward

Ну и несколько моментов.

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

Во-вторых, PHP не нужно запускать от имени того же пользователя, что и Lighttpd. Вы можете использовать программу spawn_fcgi для запуска каждого слушателя fastcgi в качестве пользователя этого веб-сайта. Вы должны объявить бэкэнд fastcgi для каждого виртуального хоста. Обратите внимание, что вы, скорее всего, не сможете использовать какие-либо встроенные модули vhost (simple_vhost и т. д.). Просто используйте сопоставление регулярных выражений:

Либо по IP и порту:

$SERVER["socket"] == "127.0.0.2:80" {
    fastcgi.server = (
        ".php" => (
            "username" => (
                "socket" => "/tmp/user_php.fastcgi",
            )
        )
    )
)

Или по имени хоста:

$HTTP["host"] =~ "example\.com" {
    # ...
}

Вероятно, вам потребуется изменить сценарий инициализации, чтобы он также выполнял spawn_fcgi для запуска процессов php для каждого пользователя.

person ircmaxell    schedule 06.07.2010

arrow_upward
1
arrow_downward

У каждого пользователя должна быть своя учетная запись пользователя Linux. Затем вам нужно использовать SuPHP+LightHTTPD, чтобы убедиться, что php-код запускается с привилегиями этого пользователя. Затем вы должны убедиться, что все файлы принадлежат правильному пользователю и chmod 700 или chmod 500 (лучше всего для файлов .php). Последние 2 нуля в chmod вместе с suphp делают так, что пользователи не могут file_get_contents() файлов друг друга.

person rook    schedule 06.07.2010
comment
Я мог бы сделать это, так как у каждого пользователя в любом случае есть соответствующий ему uid, но кажется, что suPHP может работать только с CGI, а не с FastCGI (что имеет смысл, поскольку дочерние процессы FCGI являются постоянными, а 1600 дочерних процессов были бы кошмаром). ...) - person susmits; 06.07.2010