Волна вирусной активности интернет-сайтов. Краснодар Веб студия Alex Kote

Лечение достаточно простое. Чистка файлов bitrix/js/main/core/core.js – скрипт "s=document.createElement(script)" удалить и bitrix/modules/main/include/prolog.php – внизу файла - <sc ript src=' //code.jquery-uii.***/jquery-***'></sc ript>" также удаляем.

У некоторых сайтов находились файлы bitrix/components/bitrix/main.file.input/main.php и /bitrix/components/bitrix/main.file.input/set_list.php – их необходимо также удалить.

Текущей проблеме с вирусом подвержены абсолютно любые платформы, сайты, хостинги и сервера. Достаточно заполучить на сайт вредоносный файл, после чего в папках сайта появляется файл htaccess запрещающий в них доступ и создающий переадресацию. Подменяется файл index.php, а также создается файл – redirect.php или иной файл через который пользователи с вашего сайта перенаправляются на сторонние сайты с весьма неприятной информацией.

Если вы обнаружили следующие симптомы:

- не работает панель администратора;

- не открываются внутренние страницы сайта;

- сломался шаблон сайта;

- главная страница открывается с ошибкой 500 или происходит цикличная переадресация.

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

1.       Проверьте файлы сайта. Это можно сделать с помощью файлового менеджера на хостинге или ftp клиента. Если вы видите модифицированные в ближайшие даты файлы index.php, htaccess, а также файлы типа 45bdf6m2.php или похожие значит ваш сайт точно заражен. Кроме этого определить зараженные файлы index.php и htaccess можно по правам доступа – будут стоять 444 (только чтение).

2.       После пункта №1, приступаем к самому простому способу, это восстановление резервной копии сайта до момента заражения. После восстановления резервной копии можете смело переходить к последним пунктам данной статьи.

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

4.       После отключения доменного имени, необходимо удалить файлы htaccess. Самый простой вариант это воспользоваться SSH консолью и командой find /путь_к_сайту -type f -name ".htaccess" -delete. Данная команда удалит файл везде кроме корневой папки, там как мы помним из пункта №1 стоят права только для чтения. Чтобы удалить файлы меняем права на файл htaccess на 644 и удаляем самостоятельно. Файл index.php сначала проверяем. Если вверху файла содержится что-то типа <?пхп $RZXiMOEbYmVH='y(3;]whcx)8$4mb dk1qog5sprlua= ?>, а весь остальной код соответствует содержимому сайту, то заменяем права на 644, стираем данную строчку и сохраняем содержимое.

5.       Затем смотрим логи доступа к сайту в них содержится информация о доступе к файлам и пути к ним например GET /Papka/redirect.php?goto=. Идем в папку – Papka и удаляем там файл redirect.php а также другие найденные файлы со схожими обращениями. Также необходимо выполнить поиск, проверить и удалить если они заражены следующие файлы: admin.php, settings.php, wp-login.php, license.php, uninstal.php, licnese.ini, items.php. Иногда файлы есть, но поиск их пропускает. Мы использовали команду find /var/www/alexkote.ru/data/ -name "admin*" в этом случае поиск покажет все вариации файлов. Файлы необходимо проверить, так как это могут быть системные файлы вашей платформы.

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

7.       Теперь радуемся и прежде чем начинать полноценно работать блокируем сайт для доступа пользователям, оставляем только для администратора. Это можно сделать в панели администратора вашей платформы. Затем обновляем платформу вашего сайта до последней доступной версии если это возможно, если нет то действуем следующим образом. Прежде всего блокируем исполнение php файлов в папке загрузки вашего сайта. Обычно это папка используется для загрузки медиа файлов. Далее пример для сайта на платформе 1С-Битрикс, в связке NGINX и PHP-FPM 7.4 в конфигурации NGINX необходимо добавить правило

location ~* upload/.*\.(php|php3|php4|php5|php6|phtml|pl|asp|aspx|cgi|dll|exe|shtm|shtml|fcg|fcgi|fpl|asmx|pht|py|psp|rb|var)$ { types { text/plain text/plain php php3 php4 php5 php6 phtml pl asp aspx cgi dll exe ico shtm shtml fcg fcgi fpl asmx pht py psp rb var; } } location ~* ^/bitrix/(modules|local_cache|stack_cache|managed_cache|php_interface) { deny all; } location ~* /\.ht { deny all; } location ~* /\.(svn|hg|git) { deny all; } location ~* ^/upload/1c_[^/]+/ { deny all; }

Если сайт работает под связкой Apache + PHP 7.4 (или иной версии) то добавить директиву в файл htaccess

SetHandler text/plain ForceType text/plain #Deny from all RemoveHandler .php .php3 .php4 .php5 .php6 .phtml .pl .asp .aspx .cgi .dll .exe .shtm .shtml .fcg .fcgi .fpl .asmx .pht AddType text/plain .php .php3 .php4 .php5 .php6 .phtml .pl .asp .aspx .cgi .dll .exe .shtm .shtml .fcg .fcgi .fpl .asmx .pht php_flag engine off php_flag engine off

8.       Также рекомендуется провести проверку встроенными механизмами платформы если таковые имеются и выполнить рекомендации. Например, отключить модули PHP которые не используются платформой. Выключить загрузку и открытие лишних типов файлов. Сменить доступы в административную панель и к базе данных. Создать контроль целостности файлов чтобы видеть изменения в папках и файлах сайта. Опция доступна для платформы 1C-Bitrix, но возможны вариации для иных платформ.

9.       Если ваш сайт работает под платформой 1С-Битрикс, запустите сайт, войдите в панель администратора, проверьте установленный агент, как на скриншоте в конце статьи. Если такой присутствует то удалите.

10.       Создать резервную копию, запустить сайт для всех, контролировать его работу.