Защита от php вирусов

Как зловредный код попадает на сайт?

Как правило в этом виноваты уязвимости в CMS, но чаще виноваты уязвимости в плагинах и расширениях для CMS. Чаще всего под удар попадают распространённые системы управления контентом с открытым исходным кодом такие как Joomla или WordPress. Так как мне приходилось обслуживать большое количество сайтов (это 300+ и для меня это большое количество) я убедился что чаще всего взламывают сайты на Joomla. Это не камень в огород Joomla (я уважаю данную CMS), а скорее камень в огород вебмастеров, которые бездумно ставят расширения откуда попало.

Я считаю что главная уязвимость Joomla заключается в том что файлы доступны по прямому вызову. Да, файлы дистрибутива обеспечены некой примитивной защитой против прямого вызова в виде проверки существования константы установленной в индексном файле и этого вполне хватает, но вот разработчики расширений не часто придерживаются этого правила. Это создаёт благоприятную обстановку для комнатных хакеров, которые прогуливая уроки в школе внимательно изучают код часто-используемых расширений. Бывает это делается с помощью специальных инструментов которые пишут уже не школьники но профессиональные взломщики которые щедро делятся наработками на тематических форумах.

Для осуществления атаки конечно же не достаточно иметь незащищённый от прямого вызова файл. В таком файле также должны присутствовать уязвимости в виде незащищённых переменных, отсутствие проверки вводимых данных и так далее. Одним словом они ищут результаты некомпетентности разработчика. И тут стоит заметить что PHP это тот самый язык программирования, который позволяет создавать приложения уже на третий час его изучения. Стоит ли объяснять почему рынок в сфере php-софта просто переполнен дилетантами чуть более чем полностью? Я бы даже сказал что это давно приняло катастрофические масштабы, за что почему-то принято ругать PHP. Так вот программных решений написанных дилетантами на PHP, навскидку две трети. Так что поиск уязвимостей в php-скриптах известных решений давно стало излюбленным занятием вставших на тёмную сторону силы программистов.

Зачем взламывают и заражают сайты?

Так зачем же это всё-таки надо? Кому нужны взломанные сайты? Отвечу так: Взломанные сайты, это довольно востребованный продукт на чёрном it-рынке (даркнете), применения им масса: Перенаправление трафика (редиректы ну другие ресурсы), организация ботнетов для ddos-атак (ddos-атаки могут стоить очень дорого, так что владельцы ботнетов неплохо зарабатывают), это вредоносные javascript заражающие компьютеры посетителей с любой целью, это сбор информации любого рода, это кластерные вычисления (от каждого заражённого сайта по n% процессорного времени, и если их достаточно много то можно производить серьёзные операции). Конечно всё что я тут описал, это только для примера, чтобы хотя бы дать направление вашим мыслям в понимании того, для чего взламывают сайты. В реалиях ситуация намного сложнее и масштабнее, и есть такие причины для взлома, что не в сказке сказать не в блоге написать…

Как узнать что сайт взломали?

Как защитить свой сайт от взлома?

Существует не так много способов защитить свой сайт. Конечно же, методы защиты больше всего зависят от защищаемой CMS, но также они зависят и от хостинга. Я не буду пиарить или антипиарить и называть конкретных имён, могу сказать только, что даже самые топовые хостеры могут быть очень дырявыми и шеллы будут засовывать даже на html-сайты (то есть сайты на которых вообще нет не одного исполняемого скрипта).

И так в файле php.ini должна быть строчка:

Если данной строчки у вас в конфиге не будет, смена прав на папки вашей CMS что мёртвому припарки, ибо эти самые права лихо сменят снаружи обратно на 777. В тоже время, CMS скорее всего будет ругаться на то что у вас эта функция запрещена, потому что она сама хочет иметь возможность изменять права, но эта сама возможность ей необходима крайне редко (в основном при обновлении или установке новых плагинов), по этому при обновлении самой CMS или установки или обновлении плагинов, данную строчку в php.ini придётся комментировать.

Далее нужно запретить интерпретацию php-скриптов сервером в папках, где это не нужно. Например в Joomla это папки cache, images, logs, tmp ибо они становятся в основном пристанищем шеллов и бекдоров. Сделать это очень просто, нужно в каждую из этих папок закинуть файл .htaccess с вот таким кодом:

Здравствуйте читатели seoslim.ru! Проблема защиты сайтов всегда была актуальна для всех вебмастеров, потому что никто не застрахован, что в один прекрасный день какой-либо из файлов проекта будет заражен вредоносным кодом.

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

В Яндексе такие проекты выделены другим цветом (серым) с предупреждением, что скачивать файлы с сайта небезопасно.

Зато Гугл не перестает развивать собственный интернет-браузер Хром, который на раз блокирует вредоносные сайты специальной заглушкой.

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

В самом начале ведения блога я уже сталкивался с подобного рода проблемой, когда у меня были похищены доступы ко всем сайтам из FTP-клиента и тогда трафик из Гугла сошел на нет, только благодаря предупреждению в выдаче.

В любом случае надо искать заразу (вирус) в недрах сайта или компьютера, удалять и менять все доступы к админке, ftp и почте.

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

Новая атака на блог - PHP.Hide

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

Но увы ошибся

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

Перейдя в отчет, я ужаснулся, так как мой блог находится под угрозой не известного для меня ранее вируса с пометкой PHP.Hide.

PHP.Hide — это разновидность вируса (закодированный вредоносный код), который призван рассылать спам сообщения. В большинстве случаев им страдают сайты на движке Joomla.

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

Но у меня ведь блог на WordPress, неужели ко мне тоже пробралась эта зараза через дыру движка?

Возможно, так как я уже длительное время не обновлял файлы CMS из-за того что версия 4.0 и выше не понравилась в плане юзабилити, можете прочитать статью как откатить движок сайта.

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

Как видно на фото выше по неизвестным мне причинам на сайт были закачены подозрительные файлы, замаскированные под картинки.

Из этих файлов и был тот, который хостер пометил как вирус PHP.Hide.

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

Все подозрительные файлы были выкачены с сайта и добавлены в сервис анализа и вот какие результаты были получены:

Из 53 антивирусов 4 определило файл как вредоносный.

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

Только после положительного ответа, что вируса больше нет я перестал беспокоиться, но все равно каждый день мониторю файлы блога, на предмет появления левых.

Как защитить файлы сайта

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

1) Проверьте файлы компьютера. В большинстве случаев корень зла исходит именно из железа, на котором мы привыкли работать.

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

Я специально скачал популярный софт CureIt , который бесплатно распространяет лаборатория Dr. Web взамен о предоставлении отчета о проверке.

После запуска он мне нашел пару троянов в системе, хотя ESET никогда на них не ругался.

2) Проверьте файлы сайта скриптом. Если не уверены, что окончательно победили вирус, можете воспользоваться:

RWP Checker — бесплатный скрипт, для проверки WordPress шаблонов.
AI-Bolit — сканер файлов хостинга.
Manul — антивирус для сайта от Яндекс.

Отзывы только положительные.

3) Меняем логины и пароли. Обязательно стоит сменить все логины и пароли для доступа к сайту:

в админку (панель управления)
к файлам по FTP
к почтовому ящику (там могут быть пароли для доступа к хостингу)

4) Обновляем CMS и Plugins. Я в большей мере уверен, что дыра к сайту был в старой версии Вордпресс, так как я ее не обновлял длительное время.

Поэтому идем в административную панель блога и обновляем CMS до последней версии.

То же самое касается и плагинов, а если какие-то из них вы не используете или они лишние, то лучше их тоже удалить.

5) Не размещайте JS или Iframe баннеры. Есть такие хитрые рекламодатели, которые по разным причинам хотят купить у вас баннер, даже не в основном содержании статьи, но выводится он не как GIF или PNG картинка, а с помощью JS или Iframe кода.

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

На этом у меня все, буду рад узнать от своих читателей в комментариях, сталкивался ли кто с подобной заразой на подобии закодированного вредоносного код в php файлах.

И какими еще способами можно обезопасить сайт от постороннего посягательства, чтобы предотвратить заражение файлов?

Что такое MODX?

MODX (Модэкс или Модикс) — это бесплатная система управления содержимым (CMS) с элементами фреймворка для разработки веб-приложений.

Есть 2 версии CMS: актуальная MODX Revo и динозавр MODX Evo. Настоятельно рекомендуется использовать именно MODX Revolution.

ТОП-3 уязвимости MODX

Своего врага нужно знать в лицо. Поэтому рассказываем по-порядку о последних официально зафиксированных уязвимостях.

3 место. 11 июля 2018

Один из массовых взломов MODX был зафиксирован летом 2018-го.

Кодовые названия вирусных атак CVE-2018-1000207 и CVE-2018-1000208.

Взлом проходит по 2-3 классическим сценариям. Вирус выдает себя наличием файлов с подозрительными именами: dbs.php и cache.php в корне сайта (а еще бывает там майнер лежит).

Избежать заражения MODX можно при соблюдении двух условий:

если папка connectors переименована и закрыт к ней доступ;
переименована папка assets (при использовании компонента gallery).

Проблема в следующем. MODX передает пользовательские параметры в класс phpthumb без необходимой фильтрации. Для заражения сайта используются скрипт /connectors/system/phpthumb.php или любой другой передающий параметры в класс modphpthumb.class.php. Вредоносный скрипт получает на вход имена функций и параметры через куки. С помощью полученных данных происходит косвенный вызов этих функций. Например, если у вас установлен плагин Gallery (классика жанра), то атака может происходить через скрипт: /assets/components/gallery/connector.php.

Если сайт размещен на аккаунте виртуального хостинга без изоляции сайтов, то данный backdoor позволяет заразить не только хакнутый сайт, но и его “соседей”.

Найти и удалить вирусные файлы, обновить CMS до последней версии.

2 место. 27 октября 2018

Уже через три месяца после предыдущей атаки, была зафиксирована новая уязвимость. На этот раз в сниппете AjaxSearch.

Найти и удалить вирусные файлы, обновить сниппет до последний версии.

1 место. 24 апреля 2019

Самая свежая угроза MODX зафиксирована весной 2019-го.

Проверить свой сайт на такую уязвимость можно следующим образом. Введите в строку любого браузера адрес вашего домена + /setup.

Зайти через SSH или FTP на свой сервер и удалить этот каталог.

Обнаружение вирусов на живых примерах

Теперь на наглядных примерах рассказываю, как может проявлять себя вирус. Под уязвимость попал сайт на системе MODX Revolution 2.6.5-pl. Сразу стоит отметить, что внешне вирус себя особо не выдавал. Т.е. сайт не падал, не было редиректов на странные страницы, картинки отображались корректно и так далее.

Над сайтом проводились работы по сео-оптимизации, в том числе оптимизировалась карта сайта. В один не очень прекрасный день, был скачан файл sitemap.xml, для анализа его корректности. Открыв карту сайта, увидел такую картину:

В хвост url-адресов сайта прописался мусор, сгенерированный вирусом. Проверив в админке правила заполнения карты, я не нашел никаких следов деятельности паразита. Оказалось, что карту просто подменили. Первым делом вернул корректный сайтмап, а потом сразу “побежал” в Google Search Console и Яндекс.Вебмастер за письмами счастья. Пришло уведомление только от гугла, он оказался очень шустрым, когда не надо. В личном кабинете ожидало сообщение о нарушении безопасности.

Понятно. Далее проверил, что творится в индексе гугла и ужаснулся. Японская вакханалия! Как я дальше узнал, это японский SEO-спам.

С этим все понятно, а что думает на этот счет Яндекс? Да ничего. Вирус, как оказалось, чисто гугловый. Хоть одна хорошая новость. Почему так? Есть отличный сервис, который позволяет смотреть на сайт глазами поискового робота.

Выбираем в параметрах просмотра GoogleBot, пишем в строку адрес любой страницы и получаем результат. Японские иероглифы повсюду. Выбираем робота Яндекса — код выглядит естественным образом. Вот так гугл кроулер видит страницы сайта, хотя внешне (для человеческого глаза) они никак не изменились.

Контент зараженной страницы в глазах поисковика именно таков. По сути это японский дорвей. То есть под видом качественной страницы распространяется вирусная информация. Наш сайт находят по релевантному запросу в поиске (как и должно быть), но поверх качественного контента отображается вредоносная информация. В данном случае, как я уже говорил, это видит только гугловый бот. Для человека и бота яндекса страницы выглядят как обычные.

Этот японский вирус был удален из MODX с помощью утилиты ai-bolit. О работе с данной программой написано далее.

Базовые советы, как предупредить заражение сайта на MODX

Делать резервные копии содержимого сайта.
Следить за подсказками в Яндекс вебмастере и Гугл серч консоли о состоянии безопасности сайта.
Проверять регулярно сайт на наличии вирусов скриптом ai-bolit.
Использовать последние версии патчей для админки и модулей (плагинов).
Следить за новостями безопасности из официального блога.

Меня заразили. Что делать?

Элементарно. Как можно скорее заняться удалением зловредов. Для SEO-продвижения важно устранить проблему до того, как ее обнаружат гугл или яндекс боты. Если вы опередили ботов, то уже хорошо, но времени на исправление все равно немного.

Как мы убедились ранее, процесс лечения сайта сводится к 2-3 шагам.

Поиск и удаление вирусов.
Установка обновлений (патчей), закрывающих уязвимости.
Смена паролей, но в этом не всегда есть необходимость. Зачастую цель вирусных атак — заражение сайта для собственной выгоды, а не для кражи паролей.

Поиск и удаление вирусов. Как лечить?

Выделим 2 самых популярных способа лечения сайта от вирусов. Эти методы рабочие не только для сайтов, построенных на Модиксе, но и для всех остальных.

Скачиваем антивирус ai-bolit для сайтов здесь.
Распаковываем скачанный архив.
Если у вас есть доступ к серверу через SSH:

В отчете могут быть и чистые системные файлы MODX, будьте внимательны

2) Заходим на сервер через ftp по известным ip, login и password при помощи FTP клиента (WinSCP или Filezilla).

Cначала редактировать и только потом копировать файл ai-bolit.php, т.к. после копирования хостинг может заблокировать изменение файла

где сайт - название вашего домена,

пароль - ранее прописанный в файл ai-bolit.php.

5) При успешном переходе по вышеупомянутому адресу начнется сканирование сайта, по окончании которого генерируется отчет. Но скрипт может не выполнить полное сканирование, из-за стандартных ограничений PHP, установленных хостером и вы увидите на экране ошибку с кодом 50x. В этом случае надо найти в панели управления хостингом, где изменить параметры php и расширить параметры memory_limit до 512mb и max_execution_time до 600 сек, при необходимости и возможности ресурсов вашего хостинга задайте большие значения параметров.

6) Также хостер может заблокировать и запись файлов на вашей площадке, т.к. обнаружит активность вредоносных программ. В этом случае обратитесь в техподдержку с подробным описанием проблемы.

После завершения проверки в корне сайта появится файл-отчет вида: AI-BOLIT-REPORT- - .html. Этот файл нужно скачать и открыть в браузере. В этом отчете будут указаны пути ко всем подозрительным файлам, например:
- После очистки следов вируса могут пострадать системные файлы. Это решается установкой свежей версии MODX и затем всех дополнений.
- Если сайт после очистки работает нормально, все равно обновите MODX!
- Не забываем чистить кеш в папке /core/cache/.

Читайте также: