Я настраиваю веб-сервер, на котором будет размещаться ряд различных веб-сайтов, таких как Apache VirtualHosts, каждый из которых будет иметь возможность запускать сценарии (в первую очередь PHP, возможно другие).
У меня вопрос: как изолировать каждый из этих VirtualHosts друг от друга и от остальной системы? Я не хочу например веб-сайт X, чтобы прочитать конфигурацию веб-сайта Y или любого из «частных» файлов сервера.
На данный момент я настроил VirtualHosts с FastCGI, PHP и SUExec, как описано здесь (http://x10hosting.com/forums/vps-tutorials/148894-debian-apache-2-2-fastcgi-php-5-suexec-easy-way.html), но SUExec только запрещает пользователям редактировать / запускать файлы, кроме их собственных - пользователи по-прежнему могут читать конфиденциальную информацию, такую как файлы конфигурации.
Я подумал об удалении глобального разрешения на чтение UNIX для всех файлов на сервере, так как это решит указанную выше проблему, но я не уверен, что смогу сделать это безопасно, не нарушая работу сервера.
Я также изучал использование chroot, но похоже, что это можно сделать только для каждого сервера, а не для каждого виртуального хоста.
Я ищу любые предложения, которые позволят изолировать мои VirtualHosts от остальной системы.
PS Я запускаю сервер Ubuntu 12.04
Мой ответ: Я закончил тем, что почти следовал моей текущей конфигурации, но сделал chroot-тюрьму для всех виртуальных хостов, например иметь chroot тюрьму в /var/www а затем сохраните данные всех пользователей в подпапках, в каждой из которых отключены разрешения group / others r / w / x. Этот вариант был желателен тем более, что все это возможно без каких-либо изменений исходного кода.
Я выбрал ответ @Chris, потому что он был тщательно написан, а также учитывал FTP и SELinux
Предлагаю взглянуть на suphp или PHP-FPM.
Это в основном позволит интерпретатору PHP «su» определенному пользователю, настроенному для этого VirtualHost. Это позволит вам использовать общие разрешения файловой системы для изоляции каждого VirtualHost.
Я бы порекомендовал FPM по соображениям производительности. На главной странице это то, что вас больше всего интересует:
Также интересны параметры пользователя и группы для каждого пула, которые позволяют запускать этот конкретный пул fpm под заданными uid и gid; до свидания, suphp!
Смотреть в chroot.
Некоторые отправные точки:
Создание root-прав Apache стало проще
Это можно сделать, включив модуль mod_users в Apache.
Вам нужно будет настроить UserDir в конфигурации apache. Я предлагаю вам сделать это в отдельном файле конфигурации и включить его. Оберните включение в
<IfModule mod_users.c>
Include conf/extra/userdir.conf
</IfModule>
Я могу дать вам весь учебник, но это должно помочь вам начать настройку Apache: http://www.techytalk.info/enable-userdir-apache-module-ubuntu-debian-based-linux-distributions/
Подсказка, если вы используете SELinux (а вы должны это сделать), вам придется предоставить Apache доступ для чтения к домам пользователей. Вы можете сделать это, установив:
sudo setsebool -P httpd_enable_homedirs=On
Ему также требуются права доступа к файлам для каталога user dirs public_html и разрешения r-x для родительских каталогов до root.
Очевидно, вам нужно настроить chroot для пользователей, например, в vsftpd. Установить:
apt-get vsftpd
Чтобы настроить chroot, откройте /etc/vsftpd/vsftpd.conf с помощью vi или nano. Найдите и раскомментируйте или добавьте: chroot_local_user = yes
Вы можете получить то же поведение для sftp, которое я рекомендую через FTP, откройте / etc / ssh / sshd_config и добавьте блок Match и эту строку:
Subsystem sftp internal-sftp
Match Group web_users
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
Match
Это приведет к удалению любого пользователя в группе web_users. Также вам нужно будет запретить доступ к оболочке, установив для него / sbin / nologin:
useradd -G "web_users" -s /sbin/nologin new_user
Если это будет общедоступный производственный сервер, я также настоятельно рекомендую вам применить некоторое усиление защиты ОС, OpenSSH, Apache, PHP, vsftpd и применить некоторые строгие iptables и TCP-оболочки. Я рекомендую вам также оставить SELinux на месте.