Это скорее всего не в CMS надо включать, а в панели управления хостингом. Например в ISPmanager настройки php можно менять из панели. Ну и вообще-то, массовый хостинг - это массовый хостинг. Если для одного движка надо включать magic_gpc, для второго безразлично, а для третьего выключение этой директивы обязательно - это не в зоне ответственности хостера. Хостер должен предоставить вам возможность менять эту директиву. Либо изменить настройку по вашему запросу. Либо заявить какие настройки есть и, что он их менять не собирается. Вот что находится в зоне ответственности хостера.
Раз пришло письмо о смене пароля, значит делалось все на стороне клиента. Если бы пароль меняли на уровне ДЦ, то ТС никакого письма бы не получил. Да и не было бы необходимости менять пароль, так как с уровня ДЦ можно форматнуть сервер и без ведома клиента. ТС проверить компьютер на наличие вирусов/троянов, если найдется что-то ничего не удалять и не лечить, а сохранить для уголовного дела. Написать заявление в полицию, а далее быть готовым тесно общаться с отделом "К" и достаточно долгому поиску злоумышленника. К заявлению подготовить список возможных конкурентов, которые могли заказать взлом.
К ДЦ предъявлять претензии пока рано так как в том, что сервер был отформатирован с уровня клиента, они не виноваты. Вероятно, можно было бы клиенту подумать о такой возможности и ограничить доступ к примеру сеткой своего провайдера но, как обычно, все задним умом сильны. Формат увы сделать несложно и достаточно быстро. Потенциал восстановления диска с жесткого диска достаточно неплохой, шансов много на полное восстановление данных.
И это правда :) В данный момент предстоит:
1) смена ай-пи в одном ДЦ
2) перенос хостинг клиентов от одного хостера
3) добиваем перенос из одного биллинга в другой
ну и примерно так каждый божий день, увы, реально некогда... Виртуально с вами, желаем всяческих успехов в этом начинании!
Гм, а разве нет на таймвебе какой нибудь статистики типа awstats или webalizer? В них наверняка можно увидеть самые посещаемые страницы. Если это окажется wp-login, administration/index.php, admin.php, то вы стали очередной жертвой брутфорс атаки. Для решения проблемы посмотрите посты здесь же или в администрировании серверов.
Ну уж вы придрались так придрались :) Вероятно, других поводов не нашлось? Тогда это большой плюс хостеру. Рекомендация бессмысленна, так как домен должен быть доступен как по www, так и по домену. Так уж исторически сложилось. При этом если последовать вашему совету, можно еще потерять в глазах ПС, так как вполне возможно что имеются проиндексированные ссылки на www. Если бы речь шла о свежезарегистрированном домене, еще можно было бы экспериментировать.
Посмотрите несколько тем открыто здесь и в разделе администрирование посвященные массовой брутфорс атаке на множество хостеров (приобрело фактически вид ддос атаки с уже более чем 41000 ай-пи адресов). Скорее всего поставили просто защиту. Другое дело почему вас держат в неведении, ведь легко можно предоставить вам доступ в админку добавив ваш ай-пи адрес в белый список.
Ну это вы так считаете, надеюсь что те, кто действительно заинтересованы в нахождении "надежного хостинга без ошибок 502, хамящей поддержки, отвечающей через 5 часов, падающих серверов и прочего" поймут о чем я писал. Засим удаляюсь.
Правда глаза колет? Тут уже насоветовали много чего, не кажется странным, что советчики одни хостеры?
Ну вот об том и речь, что с некоторыми этого делать не стоит. Но я думаю, также, что стоит всем тем, кто говорил о каких-то проблемах на стороне провайдера (типа похерили впску клиента и т.п.), извиниться за свои инсинуации. Потому что, подрыв доверия со стороны клиентов и так в наличии из-за массовой безграмотности населения в хостинге и в интернете вообще а также из-за огромного количества непрофессиональных профессионалов, а тут еще коллеги намекают на всякое разное.
А кто сказал, что тут была полиция? Вообще, это типичный случай когда добро возвращается злом:) Как обычно делается:
1) Информация дошла до провайдера (неважно как и от кого)
2) Провайдер рассмотрел проблему и сделал выводы (в данном случае сервер порутан и держать его в сети нельзя)
3) Сервер стопится насмерть (клиент его включить не может) клиенту посылается уведомление
Когда ответит клиент тогда и будут разбираться с тем что делать дальше. При этом вполне очевидно, что доступ на порутанный сервер и вообще запускать этот сервер никто не будет.
Единственное что было сделано не по этой схеме - сделали дамп (то есть заранее облегчили клиенту работу) + подготовили сервер для того, чтобы можно было быстро начать работу. + Предложили клиенту помощь с восстановлением. И получили что за это? Правильно, кучу дерьма да плюс комменты от коллег не на тему. Мораль басни каждый пусть для себя выведет сам. Я думаю, что ради одного неадекватного товарища, изменять свое отношение к делу не надо, но кто хочет, может думать иначе. Большинство все же сказало бы спасибо и принялось бы восстанавливать данные а не разводить публичный диспут о том, кто прав и кто виноват.
