Прошу прощения
---------- Добавлено 04.04.2017 в 23:24 ----------
Пример сервера для free хостинга
ну как сказать не вызывает, конечно проблем было много, но все они решаемы. Внедряли мы эту систему более полугода и в процессе внедрения было очень много проблем =)---------- Добавлено 04.04.2017 в 23:28 ----------
не кто не мешает создавать отдельного пользователя ftp/ssh для каждого сайта. то есть это выбор каждого пользователя. Так же не нужно забывать про многосайтовые системы или сайты которым нужны общие данные. Вопрос исключительно в гибкости и удобстве.
Повторюсь, если у Вас свой VPS - это одно дело, если Вы клиент шаред хостинга - изоляция сайтов среди ТОП10 хостингов есть только у нас.---------- Добавлено 04.04.2017 в 23:57 ----------тест прикрепления картинки
Прошу прощения, я обычно писал только технические статьи. К сожалению сложно написать статью которая будет одинакова понятна и полезна всем.
Когда я в соседних темах писал - "у реализована изоляция сайтов и скрипты сайта не могут выйти за пределы директории сайта", меня просили более подробно об этом рассказать.
Написать хорошую статью - не так просто. Описал со стороны пользователя как это выглядит /ru/forum/961280
Как это работает со стороны ядра - постараюсь написать на хабр. Лично в моем случае каждая статья на хабр занимает от дня до трех. Не хватает времени.
Описал это нечто /ru/forum/961280, со стороны пользователя это выглядит именно так.
Добрый день, клиенты, коллеги.
В последнее время начали появляться посты с вопросами - нужна изоляция сайтов, как защитить сайты, хостинг с разделением пользователей - примеры можно посмотреть тут:
/ru/forum/961280
/ru/forum/960421
При этом часть комментариев в этих постах не просто лишена смысла, а, наоборот - может сделать только хуже. По факту из ТОП10 Российских хостингов только у нас есть изоляция сайтов в рамках аккаунта, может быть и из ТОП50, но дальше ТОП10 я не анализировал. В свое время мы словили много проблем, багов и сбоев (и, конечно, сломанных сайтов =), вводя эту систему, хотя внешне она максимально проста. В этом посте я бы хотел рассказать, как она работает с точки зрения пользователя.
Для начала я бы хотел немного пояснить - в нашей системе под сайтом подразумевается директория на диске, под доменом - доменное имя (будь то домен или поддомен, не важно). Например /test.ru/public_html - это сайт, а http://test.ru - это домен.
Теперь, собственно, про изоляцию.
При создании акаунта у нас создаётся основной пользователь на сервере, по умолчании его логин и пароль совпадает с логином и паролем для входа в панель управления
Все файлы принадлежат этому пользователю, за исключением директорий сайтов - владельцем их является root. Это сделано для того что бы пользователь не мог удалить директорию сайта
Пример сайта в данном случае - alexeyxt.beget.tech. Опять же обычные права "владелец, группа, остальные" в данном контексте не совсем правильны, ну и "+" в конце прав намекает на posix acl. В директории сайта файлы так же принадлежат основному пользователю:
Но все процессы этого сайта работают не из под основного пользователя (под процессами сайта я подразумеваю, например, apache, php, python, nginx, отдельный ftp доступ, отдельный ssh доступ и так далее). Для этого сайта был создан отдельный пользователь:
Более внимательный читатель заметит, что ID это пользователя не совсем случайная величина =). Если посмотреть vhost apache для alexeyxt.beget.tech, там будет секция:
То есть все процессы этого пользователя, запущенные через Apache, а также порожденные от них, будут работать от пользователя alexeyxt__alexeyxtjbegetjtec__yq. Со стороны пользователя это выглядит так:
Если посмотреть posix acl, можно увидеть:
То есть этот пользователь имеет права на запись и чтение из директории сайта, но не из общей директории и не из директории других сайтов. Основной пользователь нужен в основном для:
Опять же схема разделения с разными пользователями позволяет определять нагрузку каждого сайта в отдельности.
Это то, что можно назвать простой частью. Так как возможностей posix acl нам не хватало, мы сделали beget acl - набор патчей на ядро, которые реализуют наши потребности.
Тут нужно также отметить некоторые дополнительные методы защиты - все процессы Apache запускаются в отдельных docker контейнерах, что даёт дополнительную изоляцию от основной системы. Помещаются в определенные группы в зависимости от параметров и много другое. Но думаю основной принцип работы изоляции сайтов в данном посте я изложил.
smart2web, видимо мои доводы о бесполезности open_basedir не являются авторитетными или хотя бы убедительными. Думаю по этому вопросу Вам стоит обратиться к Григорию Земскому (Revisium) - он сможет рассказать и о способах заражения самого сайта и о способах заражения соседних сайтов. Так же полагаю его мнение об изоляции сайтов можно считать самым авторитетным среди Российского сегмента сети.
>> У вирусов уже искусственный интеллект появился?
Опять же, о каком искусственном интеллекте Вы говорите, если даже в webshell скриптах обычно есть строки на подобии https://github.com/tennc/webshell/blob/master/php/12309/12309.php.txt#L402. А вот злые хакеры додумались как найти другие сайты на аккаунте, написали парсинг директорий, определения домена, но не добавили строку ini_set('open_basedir', '/');
Зачем вводить в заблуждение пользователей которые будут читать форум, что добавление open_basedir им поможет. С другой стороны хуже им от этого конечно не будет, но и не защитит их не как. Под защитой я имею в виду ситуацию, когда Вы можете в рамках одного аккаунта залить любые скрипты/программы, выполнить их и не как не сможете навредить другому сайту на аккаунте. Даже дав человеку SSH к одному сайту он не сможет навредить другим сайтам на аккаунте.
Я заранее приношу извинения, если немного резок, но либо мы говорим о разных вещих, либо Вы не понимаете сути проблемы.
пс. по поводу ссылки - предлагаю сделать проще, на следующей недели постараюсь подробно описать на форуме как это работает у нас в системе.
Вы мои сообщения читаете ? Это только в том случае если у ваз заблокированы все функции аля exec - что фактически причиняет боль пользователям. И это работает только в случае PHP.
А если посмотреть более внимательно http://php.net/manual/ru/ini.core.php open_basedir изменяется PHP_INI_ALL после версии 5.3 что означает http://php.net/manual/ru/configuration.changes.modes.php "Значение может быть установлено отовсюду" - ну кто мешает получив доступ к файлу, изменить .htaccess ?
При этом Вы продолжаете уверять меня, что open_basedir защитит сайты пользователей ?
То есть предполагается выключать функции exec ? Насколько я знаю у Bitrix долгие операции реализованы в том числе через exec (хотя могу ошибаться). Так же бывает нужно вызывать ffmpeg, curl - года 3-4 назад мы собирали статистику по вызовам этих функций и как не странно они используются.
Мы как раз и рассматриваем php как модуль apache, но при этом он работает из под разных пользователей. Но тут проблема даже не в PHP... Ок может пользователь будет использовать python, node.js или perl не дай бог. То есть данный вопрос надо решать комплексно, не на уровне отдельно взятого языка с его костылями - а на уровне операционной системы. ---------- Добавлено 24.03.2017 в 16:29 ---------- >> Какие еще отдельные процессы?
Не могу не задать вопрос - а как по вашему работает php как модуль apache ? Обрабатывает все запросы в рамках одного процесса ? =) Или же все таки apache, например создает несколько потомков - передает им обработку запроса, далее в зависимости от сайта потомок суидится в пользователя и уже потом вызывает php в рамках своего процесса для обработки запроса =)
>> Как сказал smart2web только через open_basedir.
Я не буду с Вами спорить, но open_basedir абсолютно бесполезная штука, не кто не мешает вызвать любую функцию из семейства exec и запустить отдельный процесс без open_basedir, при этом не обязательно на php.
Можно запретить половину функций, но часть CMS при этом точно перестанет работать.
>> Но есть важное требование безопасности: некоторые движки старинные и уязвимые, как сделать чтобы в случае одного взлома не взломали другие сайты?
Среди популярных хостингов, насколько я знаю, изоляция сайтов в рамках одного провайдера реализована только у BeGet. Она реализована на базе изменений в рамках файловой системы и добавлением понятия подпользователя. То есть, фактически все файлы принадлежат основному пользователю аккаунта и через основной FTP/SSH аккаунт можно редактировать любой сайт. Но часть программ (apache, nginx, php и т.д.), которые работаю именно с сайтами используют альтернативных пользователей (у которых 32 бита из UUID совпадают с основным пользователем) и для них есть права только на текущий сайт.
Это фактически исключает оверхед на изоляцию сайтов и полностью решает задачу изоляции сайтов, и как дополнительный бонус можно смотреть нагрузку по отдельно взятому сайту.
Почему наши коллеги не водят подобную или другую систему изоляции для меня до сих пор остается загадкой, так как принцип работы нашей системы я уже описывал не раз.
