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

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

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

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

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

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

„SELinux“ gali būti naudinga naudojant mod_selinux . Čia pateikiama greita instrukcija:

Kaip naudoti „SELinux“ norint apriboti PHP scenarijus?

Kadangi instrukcijos šiek tiek pasenusios, patikrinau, ar tai veikia „RHEL 7.1“:

Aš naudojau „Fedora 19“ versija ir sudaryta su pašaipa prieš RHEL 7.1 + EPEL.

YMMV, jei naudojate pagrindinį „epel“ konfigūracijos pokštą su:

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

Pirmiausia atnaujinkite savo tikslinę sistemą, kad įsitikintumėte, jog selinux-policy yra aktuali.

Įdiekite tiksliniame laukelyje (arba įdėkite į jį pirmiausia turite priskirti kategoriją kiekvienam virtualiam kompiuteriui apache. Tai yra daroma pridedant eilutę, pvz., žemiau pateiktame pavyzdyje selinuxDomainVal .

 
  „DocumentRoot“ / var / www / vhosts / host1
  ServerName host1.virtual
  selinuxDomainVal *: s0: c0
 

 
  „DocumentRoot“ / var / www / vhosts / host2
  ServerName host2.virtual
  selinuxDomainVal *: s0: c1
 
 

Toliau kiekvieno kompiuterio dokumento šaknyje pažymėkite jų šaknis į tą pačią kategoriją, kuri pažymėta httpd konfigūracijoje.

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

Jei norite, kad ženklinimas būtų pagerbtas, jei atliksite sistemą pažymėkite, geriau atnaujinkite ir vietinę politiką!

 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».

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

1. Прежде всего, не забывайте, что безопасность - это процесс и, в частности, о "Планируй-Выполняй-Проверяю-Действуй "цикл, рекомендованный многими стандартами, включая ISO 27001 ( http://www.isaca.org/Journal/archives/2011/Volume-4/Pages/Planning-for-and-Implementing-ISO27001.aspx ). По сути, это означает, что вам необходимо регулярно пересматривать меры безопасности, обновлять и тестировать их .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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