CageFS в повседневной работе хостинга: изоляция файловых систем между учетными записями клиентов

Почему хостинг-аккаунтам нужна изоляция

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

При этом Видимость и права доступа Различные вопросы. Имя каталога может быть видимым, хотя доступ к его содержимому запрещён из-за прав доступа к файлам. И наоборот, ограниченный просмотр сам по себе не может заменить тщательно настроенные права доступа: то, что доступно в данной среде, по-прежнему должно быть надлежащим образом защищено.

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

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

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

Как CageFS организует представление файловой системы

CageFS предоставляет пользователям собственное представление файловой системы. В его основе лежит Скелетон: шаблон, содержащий файлы и каталоги, предоставляемые для конкретной среды. Необходимые компоненты подключаются; собственный домашний каталог пользователя также интегрируется в его среду. Таким образом, видимое дерево каталогов не является просто неизменённой копией представления хоста.

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

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

Die Настройка крепления определяет, какие части файловой системы отображаются в среде. Однако она не является единственным фактором, определяющим, может ли процесс читать, изменять или запускать видимый файл. Здесь, помимо прочего, важную роль играют владелец файла и права доступа. Таким образом, видимый путь не означает наличие разрешения на запись.

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

CageFS, LVE и общие риски

CageFS и LVE решают разные задачи. CageFS формирует представление файловой системы и контекст выполнения для пользователя; LVE служит для отслеживания и ограничения ресурсов, таких как ЦП, память, а также ввод и вывод. Процесс с ограниченным доступом к файловой системе может по-прежнему потреблять ресурсы. И наоборот, само по себе ограничение ресурсов не предотвращает доступ к файлам, предоставленным с нарушением правил.

Панель управления хостингом выполняет ещё одну задачу: она, в частности, управляет учетными записями и может интегрировать компоненты CloudLinux. Однако из одной лишь установки панели не следует, что каждый веб-процесс, каждый шелл и каждая запланированная задача будут выполняться в предусмотренном контексте CageFS. Операторы должны проверить, подходит ли данная интеграция для их конкретной платформы.

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

Даже в рамках правильно изолированной учетной записи риски остаются. Например, уязвимое приложение может раскрыть свои собственные данные; украденные учетные данные могут предоставить злоумышленнику доступ в рамках данного аккаунта. CageFS не исправляет ни небезопасный код приложения, ни чрезмерно широкие права доступа к файлам, доступным в пределах этого аккаунта.

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

Рассматривать счета и веб-сайты отдельно

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

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

Для более точной Разделение веб-сайтов CloudLinux с помощью CloudLinux Isolates обеспечивает дополнительную изоляцию файловой системы на уровне доменов. Возможность её использования зависит от конкретной доступности продукта, версии и интеграции с панелью управления. Проверьте эти требования для своего хостинг-стека, а не делайте выводы о разделении доменов, основываясь исключительно на активации CageFS.

Ограничения LVE для доменов также представляют собой отдельную функцию со своими собственными условиями. Поэтому наличие дополнительного ограничения на файловую систему не означает автоматически, что ресурсы ЦП или памяти ограничиваются отдельно для каждого домена. Статья о Изоляция сайтов CloudLinux подчеркивает различие между уровнем учетной записи и уровнем веб-сайта; при настройке определяющими остаются требования используемой версии продукта.

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

Проверить статус Pilot и CageFS

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

Начните с явно авторизованных тестовых учетных записей и ограниченного набора типичных приложений. Проверьте их домашние каталоги, необходимые программы и соответствующие пути запуска, прежде чем создавать новые учетные записи. Для внедрения вы можете использовать режим, в котором CageFS по умолчанию отключен, а отдельные учетные записи включаются вручную; в качестве альтернативы существует режим, в котором CageFS по умолчанию включен, но предусмотрены исключения.

Следующие команды чтения предназначены для администраторов, имеющих соответствующие права, в системе с установленным CageFS. TESTBENUTZER замени на существующую учетную запись, разрешенную для тестирования. Необходимые права и конкретный результат зависят от системы; команды не изменяют настройки.

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --display-user-mode
/usr/sbin/cagefsctl --user-status TESTBENUTZER

Первая команда отображает общее состояние CageFS, вторая — Режим работы. Третий запрос проверяет статус выбранной учетной записи. Режим и статус учетной записи следует рассматривать в совокупности: в режиме, активированном по умолчанию, могут быть исключения, тогда как в другом режиме отдельные учетные записи включаются явно.

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

Сравнение подходов к защите

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

Права доступа к файлам и ограниченный доступ — это не взаимозаменяемые понятия: даже видимый путь не обязательно должен быть доступен для чтения, а предоставленный путь должен быть надлежащим образом защищен. CageFS дополняет эти права специально спроектированной средой. LVE, в свою очередь, решает проблему потребления ресурсов; для совместного использования оба уровня должны быть соответствующим образом настроены.

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

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

Контролируемое тестирование путей выполнения

Наличие активированной учетной записи еще не означает, что каждый связанный с ней процесс действительно запускается в CageFS. Решающим фактором является соответствующий Путь выполнения: Для входа по SSH, веб-сервера и запланированных задач могут использоваться различные механизмы интеграции. Поэтому администраторам необходимо для каждой соответствующей службы проверить, как она сопоставляет процессы с учетной записью и её окружением.

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

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

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

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

Отсутствие инструментов и обслуживание Skeleton

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

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

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

На Техническое обслуживание скелетона Также необходимо учитывать изменения в системных пакетах и панели управления. В документации CloudLinux указано, что обновление происходит периодически; после определённых изменений может потребоваться принудительное обновление. Оно может понадобиться и после пересборки Apache. Однако это не означает, что после каждого обновления необходимо выполнять одну и ту же ручную команду.

Спланируйте обновление с учётом используемой платформы, а затем проверьте соответствующие приложения и инструменты. Если приложение ранее работало, но после изменения перестало функционировать, то время изменения пакета, затронутая служба и точное сообщение об ошибке помогут сузить круг поиска. Так можно отличить проблему с развертыванием от ошибки самого приложения.

Безопасная эксплуатация и осознанное принятие решений

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

Особого внимания заслуживают общие зоны и дополнительные монтирования. CloudLinux описывает для /dev/shm общий доступ и возможность изоляции для каждого пользователя. Какой вариант действительно применяется, необходимо проверить на основе конкретной конфигурации. Дополнительные монтирования должны предоставлять только то, что необходимо приложениям, поскольку они могут расширять видимую среду.

Ошибка при входе в CageFS также представляет угрозу безопасности. Начиная с версии CageFS 7.2.0-1, в документации CloudLinux описан параметр, позволяющий предотвратить запуск процессов в случае такой ошибки. Проверьте установленную версию и фактические настройки, вместо того чтобы делать выводы о поведении этой опции в конкретной хостинг-среде, исходя лишь из факта её наличия.

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

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