Comments 32
Как только увидел список, сразу бросился искать свои сервера. Благо не нашел.
Но у меня регулярно заводиться подобная гадость. На серверах несколько старых Joomla 1.5 крутятся.
Уже позакрывал все что можно, пообновлял некоторые части движков. Все равно лезут откуда то, и каждый раз, заражаются то js то php файлы. Вычищаю парсерами, но каждый раз новые скрипты появляются. Иногда повторяются, но закономерности не нашел. Абсолютно разный код.
Но у меня регулярно заводиться подобная гадость. На серверах несколько старых Joomla 1.5 крутятся.
Уже позакрывал все что можно, пообновлял некоторые части движков. Все равно лезут откуда то, и каждый раз, заражаются то js то php файлы. Вычищаю парсерами, но каждый раз новые скрипты появляются. Иногда повторяются, но закономерности не нашел. Абсолютно разный код.
Все что могу посоветовать:
— Если сайты свои, старые и нет пока что времени разбираться, можете закрыть все ненужные для работы сайта папки (например: плагинов, кеша, дополнительных библиотек) паролем через htaccess файл с длинным и хорошим паролем. Для статики через файл htaccess можно и вовсе выключить обработку php скриптов (картинки, стили, html, кеш, файлы сессий и т. д.);
— Выставьте корректные права на чтение, запись и выполнение php файлов;
— Обратитесь за помощью к хорошему системному администратору, у них обычно есть пара проверенных решений по поиске webshell-ов в коде;
— На крайний случай поставьте новый чистый движок на новый хостинг, поставьте заново все модули, свои наработки перенесите руками проверяя каждый файл, а базу данных руками или скриптом перенести не проблема. Главное что бы и в базе было чисто и не записывалось в какой то исполняемый файл. Так же можно по базе данных поискать по слову eval.
— Если сайты свои, старые и нет пока что времени разбираться, можете закрыть все ненужные для работы сайта папки (например: плагинов, кеша, дополнительных библиотек) паролем через htaccess файл с длинным и хорошим паролем. Для статики через файл htaccess можно и вовсе выключить обработку php скриптов (картинки, стили, html, кеш, файлы сессий и т. д.);
— Выставьте корректные права на чтение, запись и выполнение php файлов;
— Обратитесь за помощью к хорошему системному администратору, у них обычно есть пара проверенных решений по поиске webshell-ов в коде;
— На крайний случай поставьте новый чистый движок на новый хостинг, поставьте заново все модули, свои наработки перенесите руками проверяя каждый файл, а базу данных руками или скриптом перенести не проблема. Главное что бы и в базе было чисто и не записывалось в какой то исполняемый файл. Так же можно по базе данных поискать по слову eval.
В Joomla как правило всякая дрянь лезет через кривые расширения (независимо от того, включены они или нет). Тут только садиться и все проверять.
Правильно ли я понимаю, что в сети очень много сильно модифицированных CMS которые обновить штатными средствами нельзя, и их наличие приводит к волне заражений.
Т.е. грубо говоря если я на WP блог сильно модифицированный заведу, где часть плагинов будет прибита к версии, я получу огромную дыру в безопасности?
Просто если это так, то скорее всего сайты бы ломали в десятки раз чаще. Или не все так просто?
Т.е. грубо говоря если я на WP блог сильно модифицированный заведу, где часть плагинов будет прибита к версии, я получу огромную дыру в безопасности?
Просто если это так, то скорее всего сайты бы ломали в десятки раз чаще. Или не все так просто?
Их и ломают. 1 дырявая джумла вполне даёт доступ в систему, а там пачка сайтов на пхп, туда тоже рассаживается подобная зараза.
Три месяца уже с 1.5 с переезжаю, проблема даже не в переносе, а в том чтобы вспомнить что и где нужно доделать.
>Или не все так просто?
Все всегда по разному. Бывает вылазит там где этого не ожидаешь. Нет 100% гарантии что следующая версия например Wordpress — идеально защищенная и без дырок. Можно использовать только свой 1 сервер для одного сайта, без соседей (не виртуальный хост, можно выделенный, или на виртуальной машине) и только свой самописный код или свою CMS, где полный код своей CMS можно вместить в голове и прокрутить несколько раз что бы не оставить уязвимых мест. И все равно, понимаете какая штука, не взломают код, взломают FTP, SSH, брутом подберут пароль, украдут пароль…
Все всегда по разному. Бывает вылазит там где этого не ожидаешь. Нет 100% гарантии что следующая версия например Wordpress — идеально защищенная и без дырок. Можно использовать только свой 1 сервер для одного сайта, без соседей (не виртуальный хост, можно выделенный, или на виртуальной машине) и только свой самописный код или свою CMS, где полный код своей CMS можно вместить в голове и прокрутить несколько раз что бы не оставить уязвимых мест. И все равно, понимаете какая штука, не взломают код, взломают FTP, SSH, брутом подберут пароль, украдут пароль…
Как-то у вас всё грустно… Брут легко пресекается. Если нужен конкретный сервер — могут и взломать, конечно. Штука, только, в том что таким вот злодеям конкретный сервер ни к чему — достаточно взять те что плохо лежат. Актуальная задача — не убежать от медведя, а быть лишь чуть быстрее последнего убегающего.
Была подобная бяка. Есть сайт, поставленный по приказу. Естественно, писан криво и на старую версию. На новой всё уплывает. Вот он и был дырой.
Стал искать и исследовать. Там всё 1 к 1, как в статье. И код обфусцированный. Через base64. Я озадачился, код развернул. Потом ещё раз развернул. Да, там, насколько помню было реализовано. Кусочек кода был дважды подвергнут запутыванию. После чего начала выстраиваться цепочка.
Функции тянулись из разных файлов, коих было вокруг много, скажем так. И вот после, уже очередной, декодировки я надыбал презанятное содержание в одном из файлов. А именно. Дурацкое слово admin, которое спалило функционал. Я не силён в веб-коде в целом и php в частности. Своё не напишу, но готовый код разберу нормально. Дык вот прикол заключался в том, что среди текста глаз цеплялся за этот «admin», а дальше шёл очередной кусок вложенного обфусцированного кода. Развернув эту мешанину увидел нечто, ну дико напоминающее по длине хэш.
Упоминания, что это хэш естественно не было. Деобфускация молчала. Стало интересно. Просмотрел открытый код ещё раз. Посмотрел. Увидел оканчивающееся нечто в стиле "?view=", поискал, по округам переменную, которая после равно торчала. Нашёл объявление этой переменной как integer. Дальше разбираться не стал, решил влоб попробовать, вдруг получится. Вбил в браузере адрес странички с параметром, перебрал числа от 0. На цифре 8 вдруг и получилось. В такой комбинации открылась белая страничка с двумя полями сверху по центру. Без опозновательных лэйблов. Тут стало вообще азартно интересно. Взял вбил палевный admin и пароль 0000. Снова оказался тут же на белой страничке.Полез до похожего на хэш значения. Точно не md5. Пересчитал все символы, прикинул. Оказалось sha1. Сделал хэш с пароля P@$$w0rD, заменил в коде. Вернулся на страничку, ввёл многострадально админа и новый пароль. Пустило. А что я дальше увидел…
А дальше я узрел полноценный файл-менеджер, писанный на php. Настолько полноценный, что:
1) он имел красивый тёмно-серый интерфейс с тёмно-зелёными буквами, местами перемежаемые серыми и жёлтыми;
2) он имел 2 панели. Привет far, nc, vc, и т.д.;
3) он имел разные режимы отображения. Списки, таблицы с перечислением свойств и прав;
4) он имел команды на копирование, перемещение, удаление, изменение прав;
5) он имел возможность просматривать и редактировать текст файлов;
6) он имел админские права на ОС.
Вот последнее меня повергло в шок. На сервере-то пользователя залогиненного не висит. Да и нигде, естественно, не сохранено. Как — не знаю.
Что примечательно. С админскими правами беда наблюдалась независимо от веб-сервера (и IIS, и Apache).
Дальше я совершил то, за что ругал себя некоторое время. Я почистил всё. Сделал бэкап с чистого сервера. И удалил бэкапы, в которых присутствовала зараза. На следующий день понял, что себе-то экземплярчика для изучения и не оставил :( Немного погуглил, не шибко нашёл чего. На том и бросил. Правда потом переписал сам кусочек в коде модуля для джумлы. Кстати говоря, из-за придурковатости модуля и получилась такая вот беда. Модуль требовал разрешения на запись в основной каталог сайта, куда он писал временные файлы. И даже не просто писал, а ещё и модифицировал уже существующие в рамках сессии. Имена, естественно условно случайно. Почему было не организовать работу во временной папке — непонятно. Подправил это, подправил ещё по мелочи. Всё нормально работало. Кажется, учителями некоторых наших писателей были индусы. После этого только настроил мониторинг на появление .bak.php, ну и иногда ручками проверяю. 1.5 джумле давно уж на покой пора бы. Но чудесные местные некроманты покоя платформе не дают.
Но, честно признаться, качество написания данной заразы меня удивило. Красиво сработано, в общем-то. Можно сказать, что качеством я дажы был пусть не восхищён, но где-то рядом. Даже не смотря на зловредность всего этого.
Стал искать и исследовать. Там всё 1 к 1, как в статье. И код обфусцированный. Через base64. Я озадачился, код развернул. Потом ещё раз развернул. Да, там, насколько помню было реализовано. Кусочек кода был дважды подвергнут запутыванию. После чего начала выстраиваться цепочка.
Функции тянулись из разных файлов, коих было вокруг много, скажем так. И вот после, уже очередной, декодировки я надыбал презанятное содержание в одном из файлов. А именно. Дурацкое слово admin, которое спалило функционал. Я не силён в веб-коде в целом и php в частности. Своё не напишу, но готовый код разберу нормально. Дык вот прикол заключался в том, что среди текста глаз цеплялся за этот «admin», а дальше шёл очередной кусок вложенного обфусцированного кода. Развернув эту мешанину увидел нечто, ну дико напоминающее по длине хэш.
Упоминания, что это хэш естественно не было. Деобфускация молчала. Стало интересно. Просмотрел открытый код ещё раз. Посмотрел. Увидел оканчивающееся нечто в стиле "?view=", поискал, по округам переменную, которая после равно торчала. Нашёл объявление этой переменной как integer. Дальше разбираться не стал, решил влоб попробовать, вдруг получится. Вбил в браузере адрес странички с параметром, перебрал числа от 0. На цифре 8 вдруг и получилось. В такой комбинации открылась белая страничка с двумя полями сверху по центру. Без опозновательных лэйблов. Тут стало вообще азартно интересно. Взял вбил палевный admin и пароль 0000. Снова оказался тут же на белой страничке.Полез до похожего на хэш значения. Точно не md5. Пересчитал все символы, прикинул. Оказалось sha1. Сделал хэш с пароля P@$$w0rD, заменил в коде. Вернулся на страничку, ввёл многострадально админа и новый пароль. Пустило. А что я дальше увидел…
А дальше я узрел полноценный файл-менеджер, писанный на php. Настолько полноценный, что:
1) он имел красивый тёмно-серый интерфейс с тёмно-зелёными буквами, местами перемежаемые серыми и жёлтыми;
2) он имел 2 панели. Привет far, nc, vc, и т.д.;
3) он имел разные режимы отображения. Списки, таблицы с перечислением свойств и прав;
4) он имел команды на копирование, перемещение, удаление, изменение прав;
5) он имел возможность просматривать и редактировать текст файлов;
6) он имел админские права на ОС.
Вот последнее меня повергло в шок. На сервере-то пользователя залогиненного не висит. Да и нигде, естественно, не сохранено. Как — не знаю.
Что примечательно. С админскими правами беда наблюдалась независимо от веб-сервера (и IIS, и Apache).
Дальше я совершил то, за что ругал себя некоторое время. Я почистил всё. Сделал бэкап с чистого сервера. И удалил бэкапы, в которых присутствовала зараза. На следующий день понял, что себе-то экземплярчика для изучения и не оставил :( Немного погуглил, не шибко нашёл чего. На том и бросил. Правда потом переписал сам кусочек в коде модуля для джумлы. Кстати говоря, из-за придурковатости модуля и получилась такая вот беда. Модуль требовал разрешения на запись в основной каталог сайта, куда он писал временные файлы. И даже не просто писал, а ещё и модифицировал уже существующие в рамках сессии. Имена, естественно условно случайно. Почему было не организовать работу во временной папке — непонятно. Подправил это, подправил ещё по мелочи. Всё нормально работало. Кажется, учителями некоторых наших писателей были индусы. После этого только настроил мониторинг на появление .bak.php, ну и иногда ручками проверяю. 1.5 джумле давно уж на покой пора бы. Но чудесные местные некроманты покоя платформе не дают.
Но, честно признаться, качество написания данной заразы меня удивило. Красиво сработано, в общем-то. Можно сказать, что качеством я дажы был пусть не восхищён, но где-то рядом. Даже не смотря на зловредность всего этого.
Update 1. Добавлена выборка всех зараженных сайтов из логов.
Подобные темы возникают регулярно. Может кому пригодится решение по оперативному обнаружению взлома — watcher4site — система бесплатная, open source (исходники можно скачать с github), ставится в любую директорию на сайте, нужен только PHP и MySQL.
В текущей обстановке дыры для проникновения будут всегда, но что бы помогло в данном случае — запрет
eval? (Которую нельзя запретить, но можно.)
> It is necessary to install the Suhosin hardened PHP patch to be able to disable «eval» in the php.ini file because technically «eval» is a language construct and not a function. Once the Suhosin hardened PHP patch is installed, «eval» can be disabled by using «suhosin.executor.disable_eval» and «suhosin.executor.disable_emodifier» directives.
Это печально, что в обычном PHP так не сделать.
Это печально, что в обычном PHP так не сделать.
Хотя, если посмотреть, вроде бы в php.ini просто подключается модуль extension=suhosin.so — надо попробовать будет.
При этом Создатели прекрасно осознают опасность эвала, о чем… предупреждают. Cover Your Ass Engineering в действии (-:
Печально, в списке jino.ru — довольно крупный хостер, а в списке целых 3 их сервера.
Отписался им, ответили, что следят за спамом. Хм, дай бог, чтоб было именно так.
Отписался им, ответили, что следят за спамом. Хм, дай бог, чтоб было именно так.
Пост ниочемо неправильно настроенном сервере (у Вас ведь дедик/VDS, как я понял? И не предусмотрено никаких ограничений на отправку, да?) и о том, что автору нечего делать, как заниматься всякой ерундойизучением чужого кода.
Вам не все равно какого рода гадость залили на север?
Если бы это был простейший скрипт вида mail($POST['to'],$POST['subj'],,$POST['body']), который долбили бы с сотни разных IP — Вам было бы легче?
Просите, но вместо того, чтобы разбираться в сути вредоноса, лучше залатайте дыры в CMS.
Масштаб бедствия заключается не в том, что «это офигеть какой крутой обфусцированный скрипт», а в том, что в сети туевы кучи дырявых CMS. И использовать их будут при необходимости для всего-чего-ни-попадя. Спама, DDOS и прочего-прочего-прочего.
Латайте дыры и настраивайте нормально серваки, господа.
Лечить надо причину, а не следствия.
Вам не все равно какого рода гадость залили на север?
Если бы это был простейший скрипт вида mail($POST['to'],$POST['subj'],,$POST['body']), который долбили бы с сотни разных IP — Вам было бы легче?
Просите, но вместо того, чтобы разбираться в сути вредоноса, лучше залатайте дыры в CMS.
Масштаб бедствия заключается не в том, что «это офигеть какой крутой обфусцированный скрипт», а в том, что в сети туевы кучи дырявых CMS. И использовать их будут при необходимости для всего-чего-ни-попадя. Спама, DDOS и прочего-прочего-прочего.
Латайте дыры и настраивайте нормально серваки, господа.
Лечить надо причину, а не следствия.
Извините, совсем не понимаю таких людей как вы, исходя из вашего написанного комментария. Ваш настрой не понятен. Ну почему же «неочем» и «заниматься всякой ерундой»? Вам разве не интересно было узнать того, что раньше вы не знали? Времени и так у всех программистов мало. Возможно однажды кому то это поможет решить проблему спама на своем сервере. Никто не говорил что это мега крутой вирусный скрипт, можно и лучше написать. «Правильно настроенный сервр» — это как? Откуда вы знаете какое назначение сервера и для чего он используется? Я так же могу поднять сервер на статике и закрыть наглуго все порты кроме 80 и сказать — пожалуйста ломайте. Если проект один, еще как то можно постоянно за ним следить, но если их очень много — это почти не реально.
Суть написания данного поста заключалась в донесении до владельцев серверов, что у них вот такая штука завелась. Ну не выложить же просто список IP адресов и сказать что вот — зараженные, правда? Хабр читает очень много людей. Думаю хоть кто то да и узнает свой IP из списка и исправит ситуацию. Вот я например не знаю что делать с таким списком зараженных IP, а вы? Просто полечить себя, забыть про остальных и ничего не делать? Мне так же интересно как заразили сайт на чистом Wordpress без экзотических плагинов и лично написанной темой, своими руками. И опыта много в программировании, а как то и заразили. В ближайшее свободное время все выясним и напишем об этом, если это проблема самого движка а не ошибка программиста.
Думаю, что стоит сообщать а не молчать. Что бы грамотно все настроить и поддерживать — нужно очень много свободного времи. По поводу сервера: один раз настроили — все супер, защищено, со временем нужно еще какую то «фичу» прикрутить. Что то забыли прикрыть, что то пропустили в конфиге и получаете… Согласен, если 1 раз настроить сервер для одного проекта и не трогать сервер годами то все будет защищено и боятся нужно будет только DDoS (И то, такое условие не всегда работает, например кто то нашел баг в коде OS или коде какого то демона, взломали сервер, если уязвимость позволяет. Просто так взломали, что бы сделать ваш сервер частью спам ботнета).
Суть написания данного поста заключалась в донесении до владельцев серверов, что у них вот такая штука завелась. Ну не выложить же просто список IP адресов и сказать что вот — зараженные, правда? Хабр читает очень много людей. Думаю хоть кто то да и узнает свой IP из списка и исправит ситуацию. Вот я например не знаю что делать с таким списком зараженных IP, а вы? Просто полечить себя, забыть про остальных и ничего не делать? Мне так же интересно как заразили сайт на чистом Wordpress без экзотических плагинов и лично написанной темой, своими руками. И опыта много в программировании, а как то и заразили. В ближайшее свободное время все выясним и напишем об этом, если это проблема самого движка а не ошибка программиста.
Думаю, что стоит сообщать а не молчать. Что бы грамотно все настроить и поддерживать — нужно очень много свободного времи. По поводу сервера: один раз настроили — все супер, защищено, со временем нужно еще какую то «фичу» прикрутить. Что то забыли прикрыть, что то пропустили в конфиге и получаете… Согласен, если 1 раз настроить сервер для одного проекта и не трогать сервер годами то все будет защищено и боятся нужно будет только DDoS (И то, такое условие не всегда работает, например кто то нашел баг в коде OS или коде какого то демона, взломали сервер, если уязвимость позволяет. Просто так взломали, что бы сделать ваш сервер частью спам ботнета).
Если Вам интересен reverse engineering — то это одно. Тогда, безусловно, можно заниматься разбором зловредов.
Если же речь о спасении себя и утопающих — ищите и латайте дыры. В первую очередь у себя.
От списка IP большого прока нет, на мой взгляд. Потому что в этот список надо сразу включить все сервера, где стоят дырявые CMS. Ну то есть, как минимум, весь шаред-хостинг ;)
Если уже Вы взялись за анализ IP, то пишите абузы их владельцам/маинтейнерам. Информация есть в whois. Это гораздо действеннее, чем писать список на Хабре (я, простите, вообще считаю, что наличие списка здесь вряд ли как-то поможет).
В подавляющем большинстве случаев загрузка зловредов идет через уязвимости, гораздо реже — через взлом/подбор паролей (админка или ftp).
При этом владельцам сайтов на это наплевать. Им проще скакать с одного хостинга на другой при получении абузы, чем обновить движок (может налеплено куча плагинов, что усложняет процесс, а может неохота платить программеру). Вот вам и ботнет. Про атаку на админки прошлым летом даже вспоминать не будем :)
Под неправильно настроенным сервером я подразумевал то, что Ваш сервер, как минимум, может неограниченно рассылать почтовый спам (о чем Вы и написали). Против такого, как минимум, надо устанавливать ограничения типа ratelimit.
И да, у меня в подчинении шаред, а не «настроенный под один проект сервер» ;) Поэтому о тоннах г.на, проплывающего через сайты пользователей, знаю не по наслышке :)
Если же речь о спасении себя и утопающих — ищите и латайте дыры. В первую очередь у себя.
От списка IP большого прока нет, на мой взгляд. Потому что в этот список надо сразу включить все сервера, где стоят дырявые CMS. Ну то есть, как минимум, весь шаред-хостинг ;)
Если уже Вы взялись за анализ IP, то пишите абузы их владельцам/маинтейнерам. Информация есть в whois. Это гораздо действеннее, чем писать список на Хабре (я, простите, вообще считаю, что наличие списка здесь вряд ли как-то поможет).
В подавляющем большинстве случаев загрузка зловредов идет через уязвимости, гораздо реже — через взлом/подбор паролей (админка или ftp).
При этом владельцам сайтов на это наплевать. Им проще скакать с одного хостинга на другой при получении абузы, чем обновить движок (может налеплено куча плагинов, что усложняет процесс, а может неохота платить программеру). Вот вам и ботнет. Про атаку на админки прошлым летом даже вспоминать не будем :)
Под неправильно настроенным сервером я подразумевал то, что Ваш сервер, как минимум, может неограниченно рассылать почтовый спам (о чем Вы и написали). Против такого, как минимум, надо устанавливать ограничения типа ratelimit.
И да, у меня в подчинении шаред, а не «настроенный под один проект сервер» ;) Поэтому о тоннах г.на, проплывающего через сайты пользователей, знаю не по наслышке :)
И еще, извините, либо «ты», либо «Вы» ;)
лучше залатайте дыры в CMS
Скорей всего проблема не в самих СMS, а в их кривой настройке.
Было бы любопытно узнать, как правильно настроить скрипт, у которого есть уязвимость, позволяющая загружать на акк произвольные скрипты? ;)
Например, как настройками вылечить хорошо известную уязвимость в timthumb? :)
Например, как настройками вылечить хорошо известную уязвимость в timthumb? :)
А зачем устанавливать заведомо дырявый скрипт? Настройка СMS включает в себя в том числе выбор и установку дополнительных модулей и плагинов.
Первый рандомно выбранный сайт из списка: www.move4u.com.au/
Возможность загрузки файлов прямо на главной странице. Шелл уже там www.move4u.com.au/b374k.php пароль b374k
Возможность загрузки файлов прямо на главной странице. Шелл уже там www.move4u.com.au/b374k.php пароль b374k
Может пора писать OpenSource антивирус, наполняя базы по мере нахождения новых зараз? Простой, без резидентных модулей и тд. На том же php спокойно. Просто сканить файлы и вырезать вредный код, точно так же, как вредный вирус, сканит и вставляет свой код :)
Понимаю что призыв очень смешной (на фоне всем известных мемов про «свой антивирус с блекджеком» или «нужно написать антивирус как касперский только лучше и за 10к рублей») и скорее всего меня могут заминусовать.
Но я уже написал такого рода скрипт, правда без БД с уязвимостями. Собственно, им и чищу сервер после каждого заражения
Понимаю что призыв очень смешной (на фоне всем известных мемов про «свой антивирус с блекджеком» или «нужно написать антивирус как касперский только лучше и за 10к рублей») и скорее всего меня могут заминусовать.
Но я уже написал такого рода скрипт, правда без БД с уязвимостями. Собственно, им и чищу сервер после каждого заражения
habrahabr.ru/post/194346/
habrahabr.ru/post/218723/
И ради любопытства: чистить сервер проще, чем залатать дыры в скриптах?
Или поясните, по какой причине Вам периодически приходится чисткой заниматься? (судя по тому, что Вы скрипт написали, то чистите весьма регулярно)
habrahabr.ru/post/218723/
И ради любопытства: чистить сервер проще, чем залатать дыры в скриптах?
Или поясните, по какой причине Вам периодически приходится чисткой заниматься? (судя по тому, что Вы скрипт написали, то чистите весьма регулярно)
За «Linux Malware Detect» спасибо. Надо попробовать, заинтересовал.
А по поводу «чистить или залатать» — я закрыл уже кучу дыр, но гадость все лезет и лезет. Чистить приходиться часто, после каждой чистки ищу новые дыры. Пользовался joomscan, он помог закрыть основные дыры в компонентах CMSок. Вручную ковырял и удалял шеллы.
Все равно лезет гадость.
Уже закрадываются мысли, что заражение идет с соседских серверов, но у меня VPS и я думаю, что если хост машина заражена, до моей виртуалки вирусу все же будет проблемно достучаться. К сожалению, никогда не поднимал виртуалок, кроме VMware, так что не знаю как они хранятся на хосте и как к ним получить доступ из скриптов.
А по поводу «чистить или залатать» — я закрыл уже кучу дыр, но гадость все лезет и лезет. Чистить приходиться часто, после каждой чистки ищу новые дыры. Пользовался joomscan, он помог закрыть основные дыры в компонентах CMSок. Вручную ковырял и удалял шеллы.
Все равно лезет гадость.
Уже закрадываются мысли, что заражение идет с соседских серверов, но у меня VPS и я думаю, что если хост машина заражена, до моей виртуалки вирусу все же будет проблемно достучаться. К сожалению, никогда не поднимал виртуалок, кроме VMware, так что не знаю как они хранятся на хосте и как к ним получить доступ из скриптов.
Sign up to leave a comment.
Спам-бот Stealrat