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

у меня тоже недавно было хакер поменял пароль в панели... зашел в cPanel нажал «отправить письмо для восстановления», прошло 30 минут и пришло. но ты лучшше звони, или в чат поддержки напиши пару раз...

Если есть root-доступ по SSH, можно сбросить пароль пользователя MySQL через хеш пароля: UPDATE mysql.user SET Password=PASSWORD('newpass') WHERE User='root'; FLUSH PRIVILEGES;. Иначе можно использовать WHM API в cPanel или скрипт сброса. Но если хакер уже получил root, значит сервер полностью захвачен. Проверьте логи, bind.log, secure log и т.д.

в таких случаях хостинг реально тормозит. но если есть доступ по SSH то полегче. можно поменять root-пароль. или сделать sudo su и написать passwd root. но если они добрались до всего сервера, значит там и малварь есть — лучше полный формат и чистая установка и дело с концом.

Есть доступ по SSH? Если есть root: ssh root@[IP] passwd [enter], вводишь новый пароль, подтверждение. Если только пользовательский доступ: sudo su, passwd новый пароль. Панель хостера — это вторично, главное — доступ к серверу. Если SSH-доступа вообще нет, возможно, придется звонить в хостинг. Рекомендуется проверить логи: /var/log/auth.log, /var/log/secure (в системах Red Hat), там видно, кто заходил.

Ты слишком быстро скачешь, братан, если пароль от админки сменили это значит, что весь сервер взят? Или только пароль от cPanel? Если ты можешь зайти по SSH, значит он еще твой. Первый шаг: заходи по SSH в bash, становись root. Потом посмотрим...

А как вы решили этот вопрос? Время обнаружения проблемы напрямую определяет ее стоимость.

Если включена двухфакторная аутентификация, украденный пароль бесполезен. Интересно, есть ли те кто делает иначе.

не знал об этом.

Эта тема в архиве.

Я маленький бизнес, расскажу со своей стороны. Если ругать за ложные тревоги, никто больше не будет присылать уведомления.

если смотреть на процесс в целом картина меняется но первые три месяца все идет хорошо, проблемы всплывают на четвертом.

на этом всё извините, если затянул.

расскажу как это делается на практике и достпуность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

Посмотрю с другой стороны, я на стороне поставщика. Любой пункт, не зафиксированный письменно, в будущем обе стороны будут помнить по-разному.

Большинство инцидентов начинается не с уязвимости, а с украденного пароля. Конечно, если ваша ситуация отличается, всё меняется.

Я столкнулся с тем же два года назад. При принятии решений записывайте и худший сценарий, а не только лучший.

Сохранил.

Здесь есть ловушка, не могу промолчать. Если ругать за ложные тревоги, никто больше не будет присылать уведомления.

Оставлю как заметку, пригодится.

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

Если путь уведомления длинный уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент. Это мое мнение не утверждаю, что оно единственно верное.

Обсуждение размылось, давайте структурируем. в общем забытые тестовые среды становятся входом в систему чаще, чем продакшн.

Я долго занимался этим вопросом. Изменение платежных данных никогда не подтверждается через тот же канал.

Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент. Оставлю как заметку, пригодится.