Вопросы Теги

Методы защиты mod_php для общего хостинга (WAMP)? [дубликат]

На этот вопрос уже есть ответ:

Я настроил веб-сервер для производственного использования. ОС - это Windows Server, и она запускает Apache 2.0 и PHP 5.3 как модуль apache (и MySQL тоже ...). Он используется для размещения нескольких виртуальных хостов (Apache vhosts), принадлежащих разным клиентам.

На этом этапе PHP работает от имени системного пользователя. В будущем доступ по FTP может быть предоставлен клиентам, поэтому по умолчанию каждый клиент сможет получить доступ ко всей системе через PHP. Это явно недопустимо.

Я понимаю, что могу установить open_basedir в PHP, но не уверен, достаточно ли он всеобъемлющ и надежен, чтобы считаться решением - ограничивает ли он доступ ко всем функциям PHP, таким как include ...? Как насчет потоков PHP?

Я также знаю, что IIS предлагает решение этой проблемы, но я предпочитаю оставить Apache.

В идеале я бы хотел создать решение, которое удовлетворяло бы следующим требованиям (в основном):

  • Быть элегантным и каким-то образом автоматическим. Я вручную управляю сервером - я хочу, чтобы настройка каждого виртуального хоста включала как можно меньше операций по настройке и редактированию конфигурации.
  • Разрешить исключение. Большинство размещенных веб-сайтов разрабатываются мной, , и я хотел бы связать их все с одной папкой библиотеки, поэтому доступ только для чтения должен быть разрешен к этой папке, хотя она будет вне корень виртуального хоста.

Итак, какие варианты доступны, если они есть? Я уже провел некоторое исследование, и кажется, что большая часть работы в этой области была проделана в системах Linux.

-1
задан 25 February 2015 в 07:45
2 ответа

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

Вы можете (и, вероятно, должны) использовать функциональность IIS FTP для предоставления FTP-доступа к вашему серверу, запрещая пользователям доступ к таким вещам, как корневой том ( C : \ ) и каталог общей библиотеки.

Другая половина вашей проблемы с безопасностью - это сам PHP - mod_php не очень хорош для мультитенантной безопасности, а open_basedir не является всеобъемлющим решением (хотя это лучше, чем ничего).

  • Если вам нужна реальная безопасность, вам в значительной степени нужно предоставить каждому свой собственный Apache в chroot .
    Это неприятно (для вас как админа), но безопасно. Это также гибко, поскольку вы можете изменять php.ini для каждого сайта.

  • Ваш следующий лучший вариант - PHP как CGI .
    Вы можете вызвать интерпретатор CGI PHP как идентификатор пользователя владельца веб-сайта - это дает вам преимущество функциональных возможностей разрешения файлов операционной системы и позволяет избежать необходимости поддерживать отдельные экземпляры Apache / PHP для каждого сайта.
    Главный недостаток - PHP должен называться CGI, поэтому вы теряете все функции, которые полагаются на PHP как модуль веб-сервера.

  • Ваш третий лучший вариант - open_basedir и disable_functions ] / disable_classes .
    open_basedir на самом деле ничего не защищает, так как влияет только на PHP : ваши пользователи могут загружать / выполнять двоичный файл, чтобы получить доступ к другим людям данные.
    директивы disable_functions и disable_classes в php.ini позволяют отключить определенные небезопасные функции (список используемых классов можно получить самостоятельно).

    • Вот и загвоздка: это черные списки и черные списки для УЖАСНОЙ безопасности, потому что, если вы пропустите уязвимую / используемую функцию, вы все равно уязвимы для атаки.
      Таким образом вы можете закрыть очевидные дыры, но вы, по сути, маленький голландский мальчик с пальцем в дамбе . У вас так много пальцев, и всегда есть еще одна дыра ...

Вы определенно не должны запускать Apache как Local System (или любую учетную запись с повышенными привилегиями ).
Перед запуском этого сервера в производство убедитесь, что он настроен в соответствии с лучшими практиками документации Apache .

2
ответ дан 5 December 2019 в 19:30

Я решил эту проблему с помощью комбинации:

  • Установка open_basedir для каждого виртуального хоста с помощью apache_admin_value в Конфигурация Apache
  • Запуск Apache от имени обычного пользователя с ограниченными правами (@ voretaq7: спасибо за ссылку)
  • Отключение некоторых функций в php.ini: disable_functions = shell_exec, symlink, exec, system, passthu, popen, proc_open

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

Обновление (примерно год спустя): эта установка спасла меня - если можно так сказать что в этом контексте. Один из моих vhosts был заражен устаревшей установкой Wordpress. Я мог видеть странные временные файлы, создаваемые в журналах PHP. Виртуальный хост был ограничен через open_basedir, что, как я полагаю, содержало проблему - я боюсь, что все мои файлы, а не только файлы этого виртуального хоста, были бы скомпрометированы, если бы не это.

0
ответ дан 5 December 2019 в 19:30

Теги

Похожие вопросы