Пришло письмо от хостера, что найдена вредятина на сайте:
This notice is to inform you that we have detected malicious code in your website files....
/public_html/weblm/include/keygen.inc.php
The malicious code detected is similar to: Files with the following contents or MD5SUMs, which contain malicious code:
\$default_action\s*=\s*['"]FilesMan['"]\s*
Нашел еще один "чужой" файл с кодом php в той же папке, замаскированный под те же имена файлов, что в этой папке(явно был доступ к именам файлов).
Темноват я в этих вопросах, кто силен поясните плиз, как защититься и что произошло ?
Шаред хостинг на cPanel, сайт статический html. Каталог с php, это каталог с генератором лицензий от VMProtect. Есть инфа как происходит подобное заражение и что предпринять, дабы защититься ?
Сейчас(хз как было на момент уязвимости) :
cPanel — 11.52.2
PHP — 5.4.24
Здравствуйте, dimario31, Вы писали:
D>Кроме паролей есть еще мысли ?
заражение может идти через формы аплоада (т.е. залили файл — запустили файл) — т.е. ищите известные уязвимости в том, что стоит, запрещайте с помощью .htaccess запуск php в тех директориях, где его не должно быть,
или через уязвимости в php-cgi (их несколько, суть в том, что навешивают входной поток, который пишется на файловую систему и который вызывается на исполнение) т.е. если админка хостера позволяет выбрать более новую версию php — выбирайте её.
ну и вообще, почитайте-посмотрите файлы, там обычно есть, что произошло (обычно есть eval, chmod, формы аплоада и т.п.)
почитайте лог, кто и как ломится, очень часто внедренный зловред управляется извне через tor, поэтому рекомендую скачать список ip-нод, с которых видно ваш сайт и занести его в раздел deny .htaccess
Здравствуйте, Matrix_Failure, Вы писали:
D>>Кроме паролей есть еще мысли ?
M_F>Может уязвимость самого хостинга?
Так вот как это узнать то ? Но мне кажется, раз они сами сканируют и находят это, то вряд ли. Гугл в основном говорит, что это связано с уязвимостью WP плагинов, я его не использую. Смущает, что это все обнаружилось в папке генератора лицензий, он внешний от VMProtect, может там какая уязвимость... Хотя даже предположить не могу. Может кто сталкивался или сам Иван(VMProtect) чего то знает об этом ?
Изучение логов показало, что тот самый "зловредный" файл, который удалил хостер был залит через FTP.
Интересно, можно ли считать, что замена пароля на данном этапе закрывает эту проблему ?
D>Изучение логов показало, что тот самый "зловредный" файл, который удалил хостер был залит через FTP. D>Интересно, можно ли считать, что замена пароля на данном этапе закрывает эту проблему ?
D>Изучение логов показало, что тот самый "зловредный" файл, который удалил хостер был залит через FTP. D>Интересно, можно ли считать, что замена пароля на данном этапе закрывает эту проблему ?
N лет назад был достаточно частен сценарий вирусни, которая сканировала сохраненные ftp-пароли в разных программах типа Total Commander чтобы засадить по ним вирусню на сайт.
Т.е. после смены пароля
1. хорошенько проверь антивирусом комп(ы), на которых когда-либо мог вводить этот пароль.
2. поменяй ftp-клиент, скажем, на wincsp и работай не по ftp, а по sftp.
D>Изучение логов показало, что тот самый "зловредный" файл, который удалил хостер был залит через FTP. D>Интересно, можно ли считать, что замена пароля на данном этапе закрывает эту проблему ?
FTP это самый худших из сценариев. Смена пароля FTP навряд ли поможет, сначала нужно проверить свою систему, а потом уже что-то менять. Да и под cPanel дофига эксплоитов, может каким-то 0-day поломали cPanel, и через нее залезли.
Здравствуйте, mtnl, Вы писали:
D>>Изучение логов показало, что тот самый "зловредный" файл, который удалил хостер был залит через FTP. D>>Интересно, можно ли считать, что замена пароля на данном этапе закрывает эту проблему ?
M>N лет назад был достаточно частен сценарий вирусни, которая сканировала сохраненные ftp-пароли в разных программах типа Total Commander чтобы засадить по ним вирусню на сайт. M>Т.е. после смены пароля M>1. хорошенько проверь антивирусом комп(ы), на которых когда-либо мог вводить этот пароль. M>2. поменяй ftp-клиент, скажем, на wincsp и работай не по ftp, а по sftp.
Антивирус то вроде в наличии, но очень похоже на вирус. Все руки не доходили перейти на sftp. Сейчас займусь. А разве sftp решит проблему того же самого сценария ? Когда сохранненый пароль в sftp клиенте будет прочитан и использован вирусней ?
Здравствуйте, dimario31, Вы писали:
D> А разве sftp решит проблему того же самого сценария ? Когда сохранненый пароль в sftp клиенте будет прочитан и использован вирусней ?
Очевидно же что нет, sftp используют для избежания атаки MITM (Man in the middle).
Здравствуйте, TheByteMan, Вы писали:
TBM>Здравствуйте, dimario31, Вы писали:
D>> А разве sftp решит проблему того же самого сценария ? Когда сохранненый пароль в sftp клиенте будет прочитан и использован вирусней ?
TBM>Очевидно же что нет, sftp используют для избежания атаки MITM (Man in the middle).
Вот и хрен то. Таковая атака мне кажется маловероятной для моего богом забытого сайта. Комп проверил через NIS, чистый, только куки левые удалил. Да и нет привычки у меня запускать, что то сомнительное. Только если какое то заражение через Web.
Здравствуйте, dimario31, Вы писали:
D>Вот и хрен то. Таковая атака мне кажется маловероятной для моего богом забытого сайта. Комп проверил через NIS, чистый, только куки левые удалил. Да и нет привычки у меня запускать, что то сомнительное. Только если какое то заражение через Web.
Вполне возможно что поломали хостера — с шаред серверами это не впервой как и с cPanel.
Еще как вариант — пароли от ftp случайно не лежали где-то в php скриптах? Может кто-то через LFI|RFI прочитал их и залил?
Здравствуйте, sharez, Вы писали:
S>Это просто азбука уязвимости веб-сайтов какая-то. S>Начните с понимания того, что PHP по своей архитектуре более уязвим. А уж с вашим стеком технологий... S>Замените на RoR/Python, SSH, VPS.
Возможно и азбука, но все было с таким же стеком гуд годами. Спасибо, я понял, что настала пора менять уровень безопасности. Однако от php отказаться концептуально сложно — бум думать.
Здравствуйте, TheByteMan, Вы писали:
TBM>Еще как вариант — пароли от ftp случайно не лежали где-то в php скриптах? Может кто-то через LFI|RFI прочитал их и залил?
Здравствуйте, dimario31, Вы писали:
D>Здравствуйте, Matrix_Failure, Вы писали:
D>>>Кроме паролей есть еще мысли ?
M_F>>Может уязвимость самого хостинга?
D>Так вот как это узнать то ? Но мне кажется, раз они сами сканируют и находят это, то вряд ли.
Оффтопик, но насчёт "врядли" — ничего не значит. Мне как-то чел из суппорта fastvps, пытаясь выяснить проблему с почтой, создал на дедике мэйл-ящик test@mydomain.com с паролем test. И не удалил потом.
Через некоторое время хостер присылает гневное письмо, что от меня рассылается мэйл-спам и вот они меня сейчас пинком под зад отседова, если немедля не решу проблему.
Пришлось копаться в логах, в которых было видно, как некий бот брутит десятки вариантов адресов на серваке и кучу паролей к ним. А потом рассылает спам с ящика test@mydomain.com.
А вот второй раз, когда на меня обратили внимание хакеры хостинг был уже не виноват. Хакеры нашли уязвимость в моем движке джумлы и стали дружно сливать базу из моих 50,000 пользователей. Я бы и не знал, но сайт стал дико тормозить (т.к. хакер явно был не один, налетело сразу много, видать я вылез в гугле по какому то свежему дорк-запросу).
И только после этого я избавился от ощущения "я неуловимый Джо, никому я не нужен чтобы меня хакать", т.к. все эти уязвимости явно ищут в автоматическом режиме, хакая кучу сайтов а не какой-то определенный. Умом то это понимал и до того, но принял как неизбежность только на собственном опыте.
Здравствуйте, dimario31, Вы писали:
D>Возможно и азбука, но все было с таким же стеком гуд годами. Спасибо, я понял, что настала пора менять уровень безопасности. Однако от php отказаться концептуально сложно — бум думать.
можно для начала просто отключать фтп юзера на все время пока вы не делаете что-то по фтп, включать только на время когда вы сами лично что-то заливаете и потом сразу юзера отключать.
сделать несколько фтп юзеров по необходимости к конкретным папкам без доступа к корню.
Здравствуйте, loginx, Вы писали:
D>>Возможно и азбука, но все было с таким же стеком гуд годами. Спасибо, я понял, что настала пора менять уровень безопасности. Однако от php отказаться концептуально сложно — бум думать.
L>можно для начала просто отключать фтп юзера на все время пока вы не делаете что-то по фтп, включать только на время когда вы сами лично что-то заливаете и потом сразу юзера отключать.
Здравствуйте, dimario31, Вы писали:
D>Возможно и азбука, но все было с таким же стеком гуд годами. Спасибо, я понял, что настала пора менять уровень безопасности. Однако от php отказаться концептуально сложно — бум думать.
Делается это так (по опыту). Переходите на нормальную технологию, а те части PHP, которые обслуживают legacy-продукты (ключи генерят или демки какие-то выводят, статистика и т. д.) — переносите на поддомен или просто на под-url так, чтобы они располагались на отдельном сервере, ограниченном в возможностях по самое не балуй — только под требуемый функционал. А сам сайт на к примеру Python/Django на VPS'e.
Можно даже админку не использовать — редактировать на локальной копии, и обновлять на сайте через сценарий DB dump -> rsync (files + DB) via SSH -> DB dump restore.
Кстати, про админку — только по httpS. Любая авторизация по HTTP без SSL перехватывается как минимум вашим провайдером. Плюс вариации с атакой MiTM (Man in the middle).
Комп проверил через NIS, чистый, только куки левые удалил. Да и нет привычки у меня запускать, что то сомнительное. Только если какое то заражение через Web.
