На стандартной ресселерке есть WHM-панель и соответственно Сипанели для клиентов.

У одного из клиентов крутится CMS, и у другого точно такая.

Возникла следующая ситуация: CMS первого клиента заражается php- трояном, и в тот же день - CMS второго клиента.

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

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

Заразиться одна CMS от другой не может! но вообще все реально

Я вот ближе склонен к тому, что если одинаковые CMS то и дырки теже у них... сломал одну, сломаешь все такие же ... вот и сломали.

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

Согласны. Единственно что добавим, не обязательно именно CMS одинаковые, нередко ломают через модули, которые одинаковые могут быть. Мы бы смотрели на фотогалереи в первую очередь.
Что касается именно "реселлерки", то нам кажется что если ломают один аккаунт с другого, то в опасности весь сервер, а не только реселлерка.

Я имел в виду не взлом сипанельного акаунта пользователей (такого не было), а передачу зараженного эксплоита от одного акаунта к другому через сервер. Ведь есть же у них что-то общее, какая-то база? Например, Апач, Мускул, тот же php.ini, наконец.

К примеру, если эксплоит влетел к одному клиенту, может он заразить второго, например через общий Апач или ещё через что?
Возможно, что постановка вопроса звучит глупо, но хотелось бы выяснить, насколько надежно изолированы клиенты в ресселерке друг от друга и какой ущерб может нанести своими деструктивными действиями (пусть и нечаянно) один из них всем остальным.

Исходя из Вашей постановки вопроса, совершенно не имеет значения, реселлерка это или хостинг у вышестоящего хостера - обычно, защищены аккаунты "друг от друга" совершенно одинаково в обоих случаях.

А вот насколько они защищены - зависит от настроек конкретного сервера, где находятся аккаунты, а так же от прав chmod которые клиенты устанавливают на свои файлы.
В обычном случае, если сам клиент соблюдает меры предосторожности, не выставляя на файлы права chmod 777 - аккаунт клиента защищен от взлома или "заражения эксплоитом" с другого аккаунта достаточно надежно.
Вероятность взлома одного аккаунта с другого ниже, чем вероятность взлома, например через "дырявые" скрипты.

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

P.S. Заразить через apache, mysql или уж тем более php.ini (и другие общие сервисы) не представляется возможным, без взлома самого сервиса. Можно атаковать например через БД MySQL принадлежащую клиенту, но предварительно потребуется взломать саму БД - подобрать к ней пароль или получить доступ к ней иным способом, причем взломать сколь-нибудь пригодный для атаки на клиента сервис обычно сложнее, чем использовать существующие уязвимости скриптов клиента.

Многие скрипты (даже этот форум) требуют 777/666, хостеры знают об этом, и хостеры не запрещают ставить 777/666, да и даже предупреждение редко у кого увидишь, так что не считаем что можно сказать "клиенты открывают доступ". Кстати, мы пока не видели ни одного хостера к которому можно было бы закачивать файлы без 777/666 при пхп установленном как модуль апача.
А вот тут хотели бы задать вопрос. На многих ли хостингах БД одного клиента запрещена от подключения к ней других клиентов если знать логин/пароль? Т.е. то, что с удалённых хостов не подключиться по умолчанию - это у многих, а вот что бы с того же сервера, но с другого аккаунта, к соседней базе нельзя было подключиться - это у кого-нибудь реализовано?

Опять же зависит от конфигурации сервера. В зависимости от конфигурации, этот же самый форум (IPB), как и любые другие скрипты, корректно работает с правами 755 на директории и 644 на файлы.

Сама по себе идеология прав в ОС *nix предполагает что "третья цифра" в chmod определяет уровень публичного доступа. Можно конечно при помощи различных "примочек" идти против идеологии, но имхо это напоминает "поправки к законам", которые в итоге делают законы противоречивыми и практически бессмысленными.




Это не всегда удобно. Некоторые клиенты имеют по десять (а то и больше) хостинговых аккаунтах, причем с разных аккаунтов используют одну БД. Оптимальный вариант - сделать то, о чем Вы говорите в виде включаемой опции и отключать персонально по требованию. На вопрос могу ответить только применительно к WebXL - у нас в текущий момент этого не реализовано. За других говорить не могу

С другой стороны - брутить пароль от БД MySQL занятие весьма неблагодарное и если пароль не "123456", то велика вероятность что брут будет замечен до того, как будет подобран пароль, хотя бы в результате огромного лога ошибок.

+1
Ну, и всякие файловые архивы, папки upload и прочее, если всегда следить, то можно предотвратить взлом, т.к. не за 5 минут все ломается...