Насколько защищена ресселерка, Влияние соседних акаунтов друг на друга |
Здравствуйте, гость ( Вход | Регистрация )
Настоящие Правила Раздела являются дополннением к Общим Правилам Конференции. В случаях противоречий отдельных пунктов, действуют Правила Раздела.
Насколько защищена ресселерка, Влияние соседних акаунтов друг на друга |
Mimino |
25.12.2006, 14:07
Сообщение
#1
|
Группа: Старые пользователи Сообщений: 32 Регистрация: 26.05.2006 Пользователь №: 2,813 Репутация: 209 |
На стандартной ресселерке есть WHM-панель и соответственно Сипанели для клиентов.
У одного из клиентов крутится CMS, и у другого точно такая. Возникла следующая ситуация: CMS первого клиента заражается php- трояном, и в тот же день - CMS второго клиента. Возникает вопрос - мог ли второй клиент заразиться через ресселелерку, через общий хост? Поскольку не знаю, насколько ресурсы одного клиента при такой структуре ресселерки разделены, защищены от влияния другого клиента, возможно ли взаимное заражение через хост? |
Dimon |
25.12.2006, 17:03
Сообщение
#2
|
Группа: Старые пользователи Сообщений: 1,004 Регистрация: 23.02.2006 Из: Provisov.net Пользователь №: 2,212 Репутация: 218 |
Заразиться одна CMS от другой не может! но вообще все реально (IMG:style_emoticons/default/smile.gif)
Я вот ближе склонен к тому, что если одинаковые CMS то и дырки теже у них... сломал одну, сломаешь все такие же ... вот и сломали. К примеру когда был бум взломов phpbb форумов, у нас в день по 5 жалоб было ... ломали эти форумы по одной и тойже дырки... Пришлось даже рассылку делать для скачивания заплатки... |
edogs |
25.12.2006, 17:30
Сообщение
#3
|
php(zce)/mysql Группа: Старые пользователи Сообщений: 3,576 Регистрация: 15.08.2003 Из: Санкт-Петербург Пользователь №: 249 Репутация: 246 |
Я вот ближе склонен к тому, что если одинаковые CMS то и дырки теже у них... сломал одну, сломаешь все такие же ... вот и сломали. Согласны. Единственно что добавим, не обязательно именно CMS одинаковые, нередко ломают через модули, которые одинаковые могут быть. Мы бы смотрели на фотогалереи в первую очередь. Что касается именно "реселлерки", то нам кажется что если ломают один аккаунт с другого, то в опасности весь сервер, а не только реселлерка. |
Mimino |
25.12.2006, 19:37
Сообщение
#4
|
Группа: Старые пользователи Сообщений: 32 Регистрация: 26.05.2006 Пользователь №: 2,813 Репутация: 209 |
Я имел в виду не взлом сипанельного акаунта пользователей (такого не было), а передачу зараженного эксплоита от одного акаунта к другому через сервер. Ведь есть же у них что-то общее, какая-то база? Например, Апач, Мускул, тот же php.ini, наконец.
К примеру, если эксплоит влетел к одному клиенту, может он заразить второго, например через общий Апач или ещё через что? Возможно, что постановка вопроса звучит глупо, но хотелось бы выяснить, насколько надежно изолированы клиенты в ресселерке друг от друга и какой ущерб может нанести своими деструктивными действиями (пусть и нечаянно) один из них всем остальным. Сообщение отредактировал Mimino - 25.12.2006, 19:53 |
WebXL |
25.12.2006, 23:52
Сообщение
#5
|
Группа: Старые пользователи Сообщений: 1,354 Регистрация: 25.04.2005 Из: WebXL, Нижний Новгород Пользователь №: 1,222 Репутация: 251 |
Я имел в виду не взлом сипанельного акаунта пользователей (такого не было), а передачу зараженного эксплоита от одного акаунта к другому через сервер. Ведь есть же у них что-то общее, какая-то база? Например, Апач, Мускул, тот же php.ini, наконец. К примеру, если эксплоит влетел к одному клиенту, может он заразить второго, например через общий Апач или ещё через что? Возможно, что постановка вопроса звучит глупо, но хотелось бы выяснить, насколько надежно изолированы клиенты в ресселерке друг от друга и какой ущерб может нанести своими деструктивными действиями (пусть и нечаянно) один из них всем остальным. Исходя из Вашей постановки вопроса, совершенно не имеет значения, реселлерка это или хостинг у вышестоящего хостера - обычно, защищены аккаунты "друг от друга" совершенно одинаково в обоих случаях. А вот насколько они защищены - зависит от настроек конкретного сервера, где находятся аккаунты, а так же от прав chmod которые клиенты устанавливают на свои файлы. В обычном случае, если сам клиент соблюдает меры предосторожности, не выставляя на файлы права chmod 777 - аккаунт клиента защищен от взлома или "заражения эксплоитом" с другого аккаунта достаточно надежно. Вероятность взлома одного аккаунта с другого ниже, чем вероятность взлома, например через "дырявые" скрипты. Но вообще очень много любителей выставлять на файлы права chmod 777 - можно сказать они сами открывают доступ злоумышленнику, выставляя такие права. P.S. Заразить через apache, mysql или уж тем более php.ini (и другие общие сервисы) не представляется возможным, без взлома самого сервиса. Можно атаковать например через БД MySQL принадлежащую клиенту, но предварительно потребуется взломать саму БД - подобрать к ней пароль или получить доступ к ней иным способом, причем взломать сколь-нибудь пригодный для атаки на клиента сервис обычно сложнее, чем использовать существующие уязвимости скриптов клиента. Сообщение отредактировал WebXL - 26.12.2006, 00:02 |
edogs |
26.12.2006, 00:23
Сообщение
#6
|
php(zce)/mysql Группа: Старые пользователи Сообщений: 3,576 Регистрация: 15.08.2003 Из: Санкт-Петербург Пользователь №: 249 Репутация: 246 |
Но вообще очень много любителей выставлять на файлы права chmod 777 - можно сказать они сами открывают доступ злоумышленнику, выставляя такие права. Многие скрипты (даже этот форум) требуют 777/666, хостеры знают об этом, и хостеры не запрещают ставить 777/666, да и даже предупреждение редко у кого увидишь, так что не считаем что можно сказать "клиенты открывают доступ". Кстати, мы пока не видели ни одного хостера к которому можно было бы закачивать файлы без 777/666 при пхп установленном как модуль апача. Можно атаковать например через БД MySQL принадлежащую клиенту, но предварительно потребуется взломать саму БД - подобрать к ней пароль или получить доступ к ней иным способом... А вот тут хотели бы задать вопрос. На многих ли хостингах БД одного клиента запрещена от подключения к ней других клиентов если знать логин/пароль? Т.е. то, что с удалённых хостов не подключиться по умолчанию - это у многих, а вот что бы с того же сервера, но с другого аккаунта, к соседней базе нельзя было подключиться - это у кого-нибудь реализовано? |
WebXL |
26.12.2006, 01:12
Сообщение
#7
|
Группа: Старые пользователи Сообщений: 1,354 Регистрация: 25.04.2005 Из: WebXL, Нижний Новгород Пользователь №: 1,222 Репутация: 251 |
Многие скрипты (даже этот форум) требуют 777/666, хостеры знают об этом, и хостеры не запрещают ставить 777/666, да и даже предупреждение редко у кого увидишь, так что не считаем что можно сказать "клиенты открывают доступ". Кстати, мы пока не видели ни одного хостера к которому можно было бы закачивать файлы без 777/666 при пхп установленном как модуль апача. Опять же зависит от конфигурации сервера. В зависимости от конфигурации, этот же самый форум (IPB), как и любые другие скрипты, корректно работает с правами 755 на директории и 644 на файлы. Сама по себе идеология прав в ОС *nix предполагает что "третья цифра" в chmod определяет уровень публичного доступа. Можно конечно при помощи различных "примочек" идти против идеологии, но имхо это напоминает "поправки к законам", которые в итоге делают законы противоречивыми и практически бессмысленными. А вот тут хотели бы задать вопрос. На многих ли хостингах БД одного клиента запрещена от подключения к ней других клиентов если знать логин/пароль? Т.е. то, что с удалённых хостов не подключиться по умолчанию - это у многих, а вот что бы с того же сервера, но с другого аккаунта, к соседней базе нельзя было подключиться - это у кого-нибудь реализовано? Это не всегда удобно. Некоторые клиенты имеют по десять (а то и больше) хостинговых аккаунтах, причем с разных аккаунтов используют одну БД. Оптимальный вариант - сделать то, о чем Вы говорите в виде включаемой опции и отключать персонально по требованию. На вопрос могу ответить только применительно к WebXL - у нас в текущий момент этого не реализовано. За других говорить не могу (IMG:style_emoticons/default/smile.gif) С другой стороны - брутить пароль от БД MySQL занятие весьма неблагодарное и если пароль не "123456", то велика вероятность что брут будет замечен до того, как будет подобран пароль, хотя бы в результате огромного лога ошибок. |
Lord Daedra |
26.12.2006, 07:48
Сообщение
#8
|
Группа: Старые пользователи Сообщений: 746 Регистрация: 11.05.2005 Из: Entropia Пользователь №: 1,273 Репутация: 222 |
Цитата Мы бы смотрели на фотогалереи в первую очередь. +1 Ну, и всякие файловые архивы, папки upload и прочее, если всегда следить, то можно предотвратить взлом, т.к. не за 5 минут все ломается... |
Текстовая версия | Сейчас: 28.05.2024, 18:13 |