Вот вы как-то по диагонали, давайте по пунктам для простоты:
Хостер заявляет что он в лидерах на рынке. И что? Это его к чему-то обязывает? Вовсе нет.
Происходит ЧП ( как сейчас ) - был такой фильм советский "ЧП районного масштаба". Так вот это даже не районный, даже не подъездный масштаб. Это масштаб вашей квартиры разве что. Её ограбили и это неприятно, но управляющей компании в общем-то на это наплевать.
Хостер забивает на клиентов. - почему? Вот чего-то делают, статью написали. А что ещё-то они могут сделать? Вести следствие у вас в квартире? Так они могут, но это уже не бесплатно, а вы всё хотите, чтобы они сами исследователи да еще и бесплатно нашли злоумышленников. Нет, если в договоре у вас так и сказано, что они должны и что бесплатно - тогда надо требовать соблюдения договора. А если не написано, тогда о чем мы говорим?
А должен же помочь ? Массовый взлом же Количество взломанных клиентов никак не соотносится с условиями договора. С чего хостер должен помогать клиенту, только потому, что он оказался в толпе людей, которые поимели проблемы? При том, что проблема не находится в зоне ответственности хостера. Вот смотрите, что есть ответственность хостера в случае ВПС:
а) доступность площадки.
б) клиентские данные размещенные у хостера.
Вот, пожалуй и все. Остальное внутри ВПС и к этому содержимому хостер доступа не имеет и ответственности за него не несет.
Вот, я скажу, не в обиду ферстдс и не в качестве рекламы нас, что сделали бы мы:
1) Предупредили бы клиента о том, что работы могут потребовать оплаты и что точного результата может и не быть получено.
2) Запросили бы у клиента доступы на сервер.
3) После быстрой диагностики озвучили бы примерную стоимость работ. Если клиент согласился с оценкой - начали бы работы.
4) По результатам дали бы выводы. Что было, в чем была причина и что нужно сделать, чтобы избежать повторения.
Уверен, что в этих шагах нет ничего уникального, это обычный порядок действий. И, также, даже если всё сделать тщательно, результат не гарантирован, так как умный хакер старается следов не оставлять. Поэтому вполне возможно, что источник взлома и не будет найден. Но по крайней мере будет проведен базовый аудит ПО и потенциальные дырки будут закрыты.
И ещё и ещё раз - это всё ВНУТРИ виртуальной машины клиента, в его зоне ответственности. Не СНАРУЖИ в зоне ответственности хостера.
Ну рядовому обывателю это приятно - как же, колбасы стало больше в два раза:) А то, что наполнение этой колбасы мясом стало одновременно в два раза меньше (Я утрирую, конечно, но близко это по смыслу) - он об этом не догадается никогда, хотя бы потому, что столько колбасы всё равно не сожрёт...
SeVlad
Ответ:
Hello,
My name is Michael and I am happy to assist. It is not possible to disable the subdomain creation as it is used in the configuration of Apache for the addon domain.
If the subdomain is deleted, Apache will have issues serving the content for the addon domain. It will also cause issues with cPanel when it comes to adding things such as email and FTP accounts as the internal information is stored against the subdomain in some places.
Please let us know if you have any additional questions or concerns.
И поэтому "ленивый хостер" - это ложь. Не ленивый, а не желающий вылечить одну проблему, создав с десяток других.
Я, лично Вам, ничего не навязываю и не собирался. Меня не интересуют ваши отношения с firstvds. Меня не интересуют ваши оценки моего мнения и, я вовсе не требую от вас, соглашаться с моим мнением. Мы с вами не знакомы, баттл с вами я не затевал и побеждать/проигрывать в нем не собирался.
Меня в этой теме интересовало только одно - вопрос об отношениях любого клиента с любым хостером и приведение этих отношений в цивилизованное русло, которое, как я считаю, определяется договорными отношениями и условиями в спорных ситуациях (когда споры выносятся на публику).---------- Добавлено 21.01.2018 в 10:09 ----------
Ну, дорогой мой, АНБ вот всех слушает, как Сноуден показал, и наша порнуха давно у них в бумажнике. И что? Дырки вот находятся 20 летней давности, позволяющие умелым ручкам получать доступ к серьезной информации. Мы давно живем в стеклянном доме, но должна присутствовать соразмерность инструмента и цели. Не будет никто юзать инструмент за ради скриптов майнинга. Ну не соразмерно это:)
Пруф где:)? Нету ж, зачем эти домыслы? То, что было показано - это не слив базы, а уязвимость раскрывшая часть данных - никакого отношения к данным об услугам не имевшая. Да, предположить можно и большее, но к чему? С таким же успехом можно вернуться и к теме топика - взлом серверов клиента от техподдержки. Ничуть не более осмысленная и правдивая. Мы же тут пытаемся типа истину какую-то найти.
Firstvds разродились статьей, в которой описали то, что они увидели. Под рутом не было ни одного файла заложено. На мой взгляд, их точка зрения о том, что они ни причём, ничем пока не опровергнута. В своё время крупнейшие американские хостеры имели проблемы с уязвимостями и речь шла о тысячах и десятках тысяч сайтов. Здесь же речь идёт в худшем случае о десятках. Почему именно у этой компании - хрен его знает. Да ведь тут и речь о другом шла - не понравилось не то, что взлом был, а подход хостера к решению проблемы (если она есть). И как-то публика всё никак не успокоится и последовательно намекает на то, что был взлом на уровне хостера. Если используется виртуализация квм - для нее нет известных уязвимостей на уровне ноды. Аналогично и про опенвз. Поэтому хостер и пишет, что он не причем. Мелтдаун и прочее - это пока только теория, к тому же и заплатки уже выпущены. Массового взлома и использования этой уязвимости пока нет. Безусловно, может быть, кто-то знает 0-дей, который позволяет взломать любую систему виртуализации - только этот кто-то не такой идиот, чтобы использовать ее для подкладки на 100 рублевые впс скрипты майнеров. Поэтому вся тема выглядит, как сплошная спекуляция и обсуждение подходов хостера к решению проблем у конкретных клиентов
PS. Да, и добавлю ещё про "слитую" базу. Слушайте, ну даже если допустить, что слили юзеров и их пароли на виртуалки. А что никто не знает, что пароли из письма об активации всегда нужно менять? Ведь об этом пишет любой хостер. А если пароли сменили - к хостеру какие уже претензии? Ведь пароли меняются не в биллинге, который теоретически можно было бы сломать, а на самом ВПС.
Ну так ставишь визуал редактор любой, закрываешь доступ хтакцессом к нему и все дела. Только смысла не вижу, какая разница внутри админки это делать или вне её. Всё равно авторизоваться нужно будет.
В том, что плодятся вот такие "технические" поддомены.
Это не вина хостера, а особенность конкретной спанели. В ИСП, в ДА - такого нет.
А когда юзер делает пароль "123456" - это тоже хостер виноват? Хостер выдал доступ клиенту к аккаунту и предоставил удобный инструмент для управления этим аккаунтом. Почитать справку и документацию о том, как пользоваться этим инструментом - об этом предупреждать надо?
То есть, чтобы любой посетитель сайта мог редактировать сайт? Есть, тот же TineMCE, но это как-то стрёмно же.
И в чём "криворукость" хостеров? Структура папок заложена в скелетоне от спанели исторически. Проблемы такая структура создаёт только в случае нескольких сайтов на одном аккаунте хостинга. Решается элементарно, как Вы правильно указали - просто левым доменом указанным в качестве главного.
