Хостинг на нескольких сайтах - упускается ли важная уязвимость для защиты сайтов друг от друга?

РЕДАКТИРОВАНИЕ № 2 23 июля 2015 г .: Ищите новый ответ, который идентифицирует важный элемент безопасности, пропущенный в приведенной ниже настройке, или может дать основания полагать, что все покрыто.

РЕДАКТИРОВАНИЕ № 3 29 июля 2015 г. Я особенно ищу возможную неправильную конфигурацию, например, непреднамеренное разрешение чего-либо, что может быть использовано для обхода ограничений безопасности или еще хуже, оставляя что-то широко открытым.

Это настройка многосайтового / общего хостинга, и мы хотим использовать общий экземпляр Apache (то есть работает под одной учетной записью пользователя), но с PHP / CGI, работающим как пользователь каждого сайта, чтобы гарантировать, что ни один сайт не сможет получить доступ к файлам другого сайта, и мы хотим убедитесь, что ничего не пропущено (например, если мы не знали о предотвращении атак по символическим ссылкам).

Вот что у меня так далеко:

• Убедитесь, что PHP-скрипты выполняются как учетная запись пользователя и группа Linux на веб-сайте и либо находятся в тюрьме (например, с использованием CageFS), либо, по крайней мере, должным образом ограничены с помощью разрешений файловой системы Linux.
• Используйте suexec, чтобы гарантировать, что CGI-скрипты не могут быть запущены как пользователь Apache.
• Если вам нужна поддержка включения на стороне сервера (например, в файлах shtml), используйте Options IncludesNOEXECдля предотвращения возможности запуска CGI, когда вы этого не ожидаете (хотя это не должно вызывать особых опасений при использовании suexec).
• Обеспечьте защиту от атак по символическим ссылкам, чтобы хакер не смог обмануть Apache, предоставив файлы другого веб-сайта в виде открытого текста и раскрывая доступную для использования информацию, такую ​​как пароли БД.
• Настройте AllowOverride/, AllowOverrideListчтобы разрешить только те директивы, которые хакер не мог использовать. Я думаю, что это меньше беспокоит, если вышеуказанные пункты выполнены правильно.

Я бы пошел с MPM ITK, если бы он не был таким медленным и не работал от имени root, но мы специально хотим использовать общий Apache, но убедитесь, что это сделано безопасно.

Я нашел http://httpd.apache.org/docs/2.4/misc/security_tips.html , но он не был исчерпывающим по этой теме.

Если это полезно знать, мы планируем использовать CloudLinux с CageFS и mod_lsapi.

Есть ли что-нибудь еще, чтобы убедиться, что делать или знать?

РЕДАКТИРОВАТЬ 20 июля 2015: Люди представили несколько хороших альтернативных решений, которые в целом ценны, но, пожалуйста, обратите внимание, что этот вопрос нацелен только на безопасность общей установки Apache. В частности, есть ли что-то, что не было рассмотрено выше, что могло бы позволить одному сайту получить доступ к файлам другого сайта или как-то скомпрометировать другие сайты?

Спасибо!

Я полностью согласен с тем, что у вас есть.

Я имел обыкновение запускать такую ​​многопользовательскую установку несколько лет назад, и я в основном нашел тот же компромисс: mod_php быстр (отчасти потому, что все выполняется внутри одного и того же процесса), а suexec медленен, но безопасен (потому что каждый запрос создает новый обработать). Я пошел с suexec, потому что требуется изоляция пользователя.

В настоящее время вы можете рассмотреть третий вариант: дать каждому пользователю свой собственный демон php-fpm. Осуществимость этого зависит от количества пользователей, потому что каждый из них должен получить хотя бы один процесс php-fpm, используя свою учетную запись пользователя (затем демон использует механизм, подобный prefork, для масштабирования запросов, поэтому количество процессов и их использование памяти может быть ограничивающим фактором). Вам также понадобится автоматическая генерация конфигурации, но это можно сделать с помощью нескольких сценариев оболочки.

Я не использовал этот метод в больших средах, но, по-моему, это хорошее решение для обеспечения хорошей производительности веб-сайта PHP и при этом изоляция пользователей на уровне процессов.

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

Я бы предложил использовать какое-то программное обеспечение для виртуальных машин (VMware, VirtualBox, Qemu и т. Д.), Чтобы каждый сайт имел собственную ОС-тюрьму. Это позволяет вам, как системному администратору, не беспокоиться об одном взломанном сайте. Если хакер получит root, используя php (или любое другое программное обеспечение) на виртуальной машине сайта, просто приостановите работу виртуальной машины и разберите ее позже, примените исправления или откатитесь до непрерывного состояния. Это также позволяет администраторам сайта применять определенное программное обеспечение или настройки безопасности к их конкретной среде сайта (которая может нарушить работу другого сайта).

Единственным ограничением является ваше аппаратное обеспечение, но с достойным сервером и правильными расширениями ядра, с которыми легко иметь дело. Я успешно запустил этот тип установки на Linode, при условии, что и Хост, и Гость были очень очень редкими. Если вы чувствуете себя комфортно с командной строкой, которая, как я полагаю, у вас, у вас не должно возникнуть никаких проблем.

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

Я бы посоветовал запускать каждый сайт под своим собственным демоном Apache и привязывать к нему Apache. Все системные функции php не будут работать, поскольку среда chroot Apache не будет иметь доступа к / bin / sh. Это также означает, что функция php mail () также не будет работать, но если вы используете внешнего почтового провайдера для отправки почты из вашего почтового приложения, это не должно быть проблемой для вас.

SELinux может быть полезным с mod_selinux. Краткое руководство показано здесь:

Как я могу использовать SELinux для ограничения скриптов PHP?

Поскольку инструкции немного устарели, я проверил, работает ли это на RHEL 7.1:

Я использовал версию Fedora 19 и скомпилировал макет против RHEL 7.1 + EPEL.

YMMV, если вы используете базовый конфиг epel, поставляется с:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

Сначала обновите целевую систему, чтобы убедиться в selinux-policyее актуальности.

Установите на целевой ящик (или вставьте сначала в локальное зеркало):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Теперь вы должны назначить каждому виртуальному хосту в apache категорию. Это делается путем добавления строки, например, в приведенном ниже примере selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

Затем, в корне документа для каждого хоста, пометьте их корни документа в той же категории, что и в конфигурации httpd.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Если вы хотите, чтобы маркировка была принята, если вы выполняете системную перемаркировку, вам лучше обновить и локальную политику!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Уже дано много хороших технических ответов (также посмотрите здесь: https://security.stackexchange.com/q/77/52572 и Советы по защите сервера LAMP ), но я все же хотел бы упомянуть здесь важный момент (с еще одной точки зрения) о безопасности: безопасность - это процесс . Я уверен, что вы уже рассмотрели это, но я все еще надеюсь, что было бы полезно (также для других читателей) иногда переосмыслить это.

Например, в вашем вопросе вы концентрируетесь в основном на технических мерах: «этот вопрос нацелен только на безопасность совместно используемой установки Apache. В частности, есть ли какие-либо меры безопасности, которые важно предпринять, но которые отсутствуют в списке выше при запуске разделяемого Apache и PHP. "

Почти все ответы здесь и на другие 2 вопроса, которые я упомянул, также кажутся чисто техническими (за исключением рекомендации оставаться в курсе). И, с моей точки зрения, это может создать у некоторых читателей ложное впечатление, что если вы однажды сконфигурируете свой сервер в соответствии с передовой практикой, вы останетесь в безопасности навсегда. Поэтому, пожалуйста, не забывайте о моментах, которые я упускаю в ответах:

1. Прежде всего, не забывайте, что безопасность - это процесс и, в частности, цикл «Plan-Do-Check-Act», как это рекомендовано многими стандартами, включая ISO 27001 ( http://www.isaca.org/ Журнал / архив / 2011 / Том-4 / Страницы / Планирование-для-реализации-ISO27001.aspx ). По сути, это означает, что вам необходимо регулярно пересматривать свои меры безопасности, обновлять и тестировать их .

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

3. Контролируйте свою систему. Я действительно пропускаю этот момент в ответах. С моей точки зрения, крайне важно как можно раньше получить уведомление о проблеме с вашей системой.

   Вот что говорит об этом статистика: «Среднее время от проникновения до обнаружения составляет 173,5 дня» ( http://www.triumfant.com/detection.html ), «Среднее число дней до обнаружения 205» ( https: // www2 .fireeye.com / rs / fireye / images / rpt-m-trend-2015.pdf ). И я надеюсь, что эти цифры не то, что мы все хотим иметь.

   Существует множество решений (в том числе бесплатных) не только для мониторинга состояния службы (например, Nagios), но также систем обнаружения вторжений (OSSEC, Snort) и систем SIEM (OSSIM, Splunk). Если это становится слишком сложным, вы можете, по крайней мере, включить что-то вроде 'fail2ban' и / или переслать свои журналы на отдельный сервер системного журнала и получать по электронной почте уведомления о важных событиях.

   Опять же, самым важным моментом здесь является не то, какую систему мониторинга вы выбираете, а самое важное, что вы проводите мониторинг и регулярно его пересматриваете в соответствии с вашим циклом «Plan-Do-Check-Act» .

4. Будьте в курсе уязвимостей. То же, что и мониторинг. Просто подпишитесь на какой-нибудь список уязвимостей, чтобы получать уведомления, когда обнаружена критическая уязвимость для Apache или другого сервиса, важного для вашей установки. Цель состоит в том, чтобы получать уведомления о наиболее важных вещах, которые появятся до вашего следующего запланированного обновления.

5. Составьте план действий в случае инцидента (и регулярно обновляйте и пересматривайте его в соответствии с вашим циклом «Планируй-делай-проверяй-действуй»). Если вы задаете вопросы о безопасной конфигурации, это означает, что безопасность вашей системы становится важной для вас. Однако что делать в случае взлома вашей системы, несмотря на все меры безопасности? Опять же, я имею в виду не только технические меры, такие как «переустановка ОС»: куда следует сообщать об аварии в соответствии с действующим законодательством? Вам разрешено немедленно отключить / отключить сервер (сколько это стоит для вашей компании)? С кем следует связаться, если главный ответственный человек находится в отпуске / болен?

6. Наличие сервера резервного копирования, архивирования и / или замены / репликации. Безопасность также означает доступность вашего сервиса. Регулярно проверяйте свою резервную копию / архив / репликацию, а также регулярно проверяйте процедуры восстановления.

7. Проверка на проницаемость? (опять же, см. цикл «Планируй-делай-проверяй-действуй») :) Если вам кажется, что это слишком много, вы можете хотя бы попробовать бесплатные онлайн-инструменты, которые сканируют ваши веб-сервисы на наличие вредоносных программ и проблем безопасности.

Ваш вариант использования идеально подходит для док-контейнеров.

Каждый контейнер может представлять клиента или клиента с уникальными идентификаторами пользователей, назначенными каждой группе контейнеров Apache в качестве дополнительной защиты. Ключ должен был бы удалить привилегии root при запуске контейнера, прежде чем запускать ваш стек apache. Каждый клиент получает свою собственную службу БД со своими уникальными паролями, без головной боли стоящего десятка виртуальных машин, каждая из которых требует своих собственных специальных ядер-снежинок и других накладных расходов. Ведь в основе докера лежит chroot. При правильном управлении я бы взял это за типичный виртуальный кластер в любой день.

Здесь уже много хороших предложений. Есть вещи, которые были упущены в обсуждении до сих пор, хотя.

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

По моему опыту, такие вещи, как анализ журналов, когда они предоставляются службой хостинга, запускаются с правами root почти так же часто, как и программное обеспечение для анализа журналов, которое не подвергается такому аудиту безопасности, как хотелось бы. Делать это хорошо немного сложнее и зависит от настроек. С одной стороны, вы не хотите, чтобы ваш процесс Apache, принадлежащий корню (то есть родительский процесс), записывал в любой каталог, который пользователь может скомпрометировать. Это, вероятно, означает, что не нужно писать в тюрьму напрямую. С другой стороны, вам нужно сделать эти файлы доступными для процессов в тюрьме для анализа, и вы хотели бы, чтобы это было как можно ближе к реальному времени. Если вы можете предоставить своим тюрьмам доступ к монтируемому только для чтения монтированию файловой системы с журналами, это должно быть хорошо.

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

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

Менее очевидно, как apache решает, что такое статический файл. Например, что это делает с файлом *.php.gifили *.php.en? Если этот механизм или другой вводит в заблуждение различие в том, что такое статический файл, может ли Apache вообще запускать php из-за пределов тюрьмы? Я бы настроил отдельный легкий веб-сервер для статического контента, который не настроен ни на какие модули для выполнения динамического контента, и чтобы балансировщик нагрузки решал, какие запросы отправлять статическому серверу, а какие - динамическому.

Что касается предположения Стефана о Docker, можно иметь один веб-сервер, который находится вне контейнера и который взаимодействует с php-демонами в каждом контейнере для динамического содержимого, а также иметь второй веб-сервер, который находится в контейнере docker, и который разделяет тома, которые каждый использует для своего контента, и, таким образом, способен обслуживать статический контент, который почти такой же, как в предыдущем абзаце. Я рекомендую докер среди различных подходов типа тюрьмы, но с этим или другими подходами типа тюрьмы у вас будет куча других проблем, над которыми нужно разобраться. Как работает загрузка файла? Вы помещаете демоны передачи файлов в каждый контейнер? Принимаете ли вы подход PAAS в стиле git? Как сделать журналы, созданные внутри контейнера, доступными, и перевернуть их? Как вы управляете и выполняете задания cron? Собираетесь ли вы предоставить пользователям какой-либо доступ к оболочке, и если да, то это еще один демон внутри контейнера? и т. д.

Первое, что я не вижу, это управление процессами, поэтому один процесс не может остановить процесс ЦП или ОЗУ (или, если на то пошло, ввод / вывод, хотя ваша файловая система может быть спроектирована таким образом, чтобы этого не было). Одним из основных преимуществ подхода «контейнеры» к вашим экземплярам PHP по сравнению с попыткой запустить их все на одном образе «ОС» является то, что вы можете таким образом лучше ограничить использование ресурсов. Я знаю, что это не ваш дизайн, но это то, что нужно учитывать.

В любом случае, вернемся к случаю использования PHP, работающего за Apache, в основном функционирующего как прокси. suexec не запрещает запускать что-либо от имени пользователя Apache - он предоставляет возможность работать от имени другого пользователя. Поэтому одной из проблем будет обеспечение того, чтобы все было сделано правильно - на этой странице документа выявляется эта потенциальная опасность: https://httpd.apache.org/docs/2.2/suexec.html . Итак, вы знаете, зерно соли и все такое.

С точки зрения безопасности это может быть полезно иметь ограниченный набор пользовательских двоичных файлов для работы с (что cagefs поставки), особенно , если они составлены по- разному или против другой библиотеки (например , тот , который не включает в себя возможности , которые являются нежелательными) , но Опасность заключается в том, что в этот момент вы больше не следуете за известным дистрибутивом обновлений, вы следуете за другим дистрибутивом (cagefs) для ваших установок PHP (по крайней мере, в отношении инструментов пользовательского пространства). Хотя, поскольку вы, вероятно, уже следите за конкретным дистрибутивом с cloudlinux, это дополнительный риск, не обязательно интересный сам по себе.

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

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

Это моя мозговая свалка. Надеюсь, там есть что-то неопределенно полезное. :)