>> Как сказал smart2web только через open_basedir.
Я не буду с Вами спорить, но open_basedir абсолютно бесполезная штука, не кто не мешает вызвать любую функцию из семейства exec и запустить отдельный процесс без open_basedir, при этом не обязательно на php.
Можно запретить половину функций, но часть CMS при этом точно перестанет работать.
>> Но есть важное требование безопасности: некоторые движки старинные и уязвимые, как сделать чтобы в случае одного взлома не взломали другие сайты?
Среди популярных хостингов, насколько я знаю, изоляция сайтов в рамках одного провайдера реализована только у BeGet. Она реализована на базе изменений в рамках файловой системы и добавлением понятия подпользователя. То есть, фактически все файлы принадлежат основному пользователю аккаунта и через основной FTP/SSH аккаунт можно редактировать любой сайт. Но часть программ (apache, nginx, php и т.д.), которые работаю именно с сайтами используют альтернативных пользователей (у которых 32 бита из UUID совпадают с основным пользователем) и для них есть права только на текущий сайт.
Это фактически исключает оверхед на изоляцию сайтов и полностью решает задачу изоляции сайтов, и как дополнительный бонус можно смотреть нагрузку по отдельно взятому сайту.
Почему наши коллеги не водят подобную или другую систему изоляции для меня до сих пор остается загадкой, так как принцип работы нашей системы я уже описывал не раз.
Большинство тестов - достаточно субъективные и нужно проводить не один замер, а штук 100 с интервалом в несколько минут и брать среднее значение.
Опять же нужно исходить из конфигурации сервера (процессор, дисковая подсистема, память), а так же нагрузки на все эти компоненты.
E5-2630v3 будет хуже чем E5-2680v3 при одинаковом характере нагрузки. E3 будет показывать лучшие результаты за счет большей чистоты в случае одной либо нескольких задач (то есть при маленьком LA), но за счет количества ядер E5 при большой нагрузке ведет себя более стабильно.
Дисковая подсистема так же может различаться от севера к серверу, кто то использует HDD (как не странно до сих пор), кто то SSD (которые тоже сильно отличаются по производительности, надежности и цене), кто то дополнительно ставит еще PCI-SSD
Количество памяти на сервере напрямую влияет на производительность дисковой системы, так как кеш диска храниться в RAM и чем больше памяти тем лучше работает сервер при прочих равных. Так же не мало важно какая стоит память.
Последние 4 сервера мы сменили конфигурацию на:
Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz 2 процессора - 56 ядер
512 гигабайт памяти - ddr4
8 SSD (intel 35xx серии) под данные в raid10 через контролер LSI 9270 и 2 PCI-SSD под базы.
В любом случае все сильно зависит от нагрузки на сервер и стека используемого ПО.
Все очень просто - делать либо хорошо, либо не как. Наработки у нас есть, можно сказать готовые к релизу - но вот детали требуют огромного количества времени.---------- Добавлено 27.02.2017 в 16:50 ----------
В любом из вариантов будет негатив или отрицательные стороны. Либо будут блокировки партнеров с одним реффералом, либо нужно будет платить за хостинг либо ранжировать процент выплат. Я не в коем случае не спорю, что схема предложенная нами может подойти не всем - но факт в том, что она достаточно проста. Когда мы вводили эту схему процент отчислений, который мы платили был максимальный. Некоторые наши коллеги ранжировали его в зависимости от количества привлеченных клиентов.
Наверное стоит описать еще один нюанс нашей партнерской программы в сравнении с некоторыми аналогами - мы нацелены на долгосрочное и взаимовыгодное сотрудничество. Хостинг компании не могут отчислять 40% процентов за услуги которые они перепродают, такие как регистрация доменов, покупка CMS, покупка SSL. Одни из наших коллег по рынку хостинга решили эту проблему разделением платежей за хостинг и остальные услуги, при этом платеж за хостинг нельзя потратить на дополнительные услуги. Мы изначально зачисляем 40% платежей на партнерский баланс и уже если пользователь покупает домен с партнерского баланса списывается 40% от суммы покупки дополнительной услуги. В случае если партнер забирает средства до списания - его партнерский баланс уходит в минус, но мы заинтересованы в том, что бы все его приведенные пользователи оставались нашими клиентами и исходя из этого в последствии своими платежами нивелировали этот минус.
Отвечая на Ваш вопрос - да возможно схема с активным хостинговым аккаунтом не очень удобна для Вас, но она очень удобна нам и позволяет избежать множества проблем и ручной обработки, в 2010 году она позволили нам платить максимальный процент из всех участников рынка.
Я конечно понимаю, что эта беседа достаточно провокационная. Но все же mail.ru и Yandex - то же по Вашему не доплачивают по этой причине ? =)
Вы читали программы mail.ru, yandex, vk, amazon, google, facebook ?
Вот несколько подобных программ на русском языке в качестве примера, рекомендую ознакомиться.
https://bugbounty.mail.ru/
https://yandex.ru/bugbounty/
https://hackerone.com/vkcom---------- Добавлено 16.02.2017 в 17:19 ----------Так же добавлю - вот программа панели управления, хостинга который Вы рекламируете в подписи =)
https://www.ispsystem.com/bug-report
Это вполне адекватная стоимость за подобные уязвимости (посмотрите программы поиска уязвимостей в Facebook, Vk, Yandex, Mail, Amazon). Опять же если Вы внимательно прочитали - к сторонним компаниям мы обращаемся постоянно и свои специалисты у нас есть.
Я бы сказал так - безопасности много не бывает. И мы с радостью привлекаем всех, что бы сделать нашу панель и наши услуги более качественными, при этом делаем это открыто.
"не имеете в своем штате своих специалистов" - полагаю, что Вы не работали в сфере разработки ПО в больших компаниях, к сожалению найма пяти, десяти или ста специалистов (в большинстве случаев это называется отдел тестирования) будет не достаточно для гарантирования отсутствия уязвимостей в программных продуктах.
В то время некоторые наши коллеги включают SSH, блокируют аккаунт при подозрительной активности и уменьшают до минимума права пользователей в системе - мы на оборот проводим открытую политику - пробуйте, если у Вас получится найти уязвимость мы Вам еще и заплатим за это.
Я не думаю, что это плохо. В этом вопросе наши мнения видимо расходятся.
Продублирую интересную новость:
С каждым годом наши продукты становятся более качественными и функциональными. Мы всегда уделяли большое внимание безопасности данных и информации, которую нам доверили пользователи. Примерно раз в полгода заказываем аудит наших систем у сторонних организаций - данное сотрудничество всегда положительно сказывалось на наших продуктах.
А сейчас мы запускаем программу поиска уязвимостей и багов за вознаграждения для всего интернет-сообщества.
Описание программы
Для участия в программе принимаются уязвимости/ошибки в работе панели управления хостингом cp.beget.com, а также любые способы получения данных, располагающихся на хостинговых серверах. Текущие цены за найденные уязвимости актуальны до 15 апреля 2017 года.
Выплаты и размеры наград
Вознаграждение выплачивается в том случае, если Вы первый, кто сообщил о данной уязвимости, если вы не использовали её для причинения вреда нашей инфраструктуре или пользователям и не публиковали данные об этой уязвимости. До 15 апреля 2017 года предусмотрен следующий уровень вознаграждения за найденные уязвимости:
Но, безусловно, вы можете сообщать нам о любых других типах уязвимостей, и мы всегда найдём время рассмотреть их и способ отблагодарить вас.
Взаимодействие по найденным уязвимостям
Необходимо отправить отчет о найденной уязвимости по адресу bugbounty@beget.com или через тикет систему панели управления хостингом.
В отчете должно содержаться:
Срок рассмотрения уязвимости составляет 10 рабочих дней. В ходе оценки мы представляем себе наиболее худший сценарий эксплуатации уязвимости, и выплачиваем вознаграждение, исходя из этого.
.
Это ограничение накладывается протоколом через который работает файловый менеджер. В SSH - такого ограничения нет (если не считать chroot), в FTP оно есть. При локальном доступе используются права пользователя из под которого запущен процесс.
Насколько я помню, мы делали искусственное ограничение. Думаю этот вопрос лучше задать на github =)
С момента релиза добавилось функциональность:
- поддержка SFTP
- поддержка WebDav
- выбор языка
Так же проведена большая работа по внутренней оптимизации, исправлены некоторые баги.
В общем, работа над проектом идет.
