Введение
Часто можно увидеть в сети: сайт работал нормально и вдруг начал работать, как дворник с похмелья, хостер пишет гневные письма, поисковики обходят сайт стороной, а браузеры блокируют предупреждением «Имеется информация, что этот сайт атакует компьютеры!»
Откуда же берутся вирусы?
Самая распространённая на сегодня причина — это использование quickstart (quickstart это установочный архив, позволяющий в несколько минут развернуть точную копию сайта, со всеми расширениями), как правило, скачанного с варезных ресурсов; квикстарта, купленного у разработчика, разумеется, можно не бояться. Очень удобно, не нужно мучатся с дизайном, установкой расширений, настройкой сайта. Правда, зачастую вместе с сайтом можно получить набор скриптов, дающих контроль над вашим ресурсом, таких как рассылка спама, «раздача» вирусов или размещение невидимых ссылок на сторонние ресурсы (черный SEO).
Для чего варезные ресурсы включают backdoor (от англ. back door — «чёрный ход») в архив? Как правило, варезные ресурсы живут за счет отчислений за каждое скачивание от файлообменников, а те, в свою очередь, показом рекламы и платными подписками, позволяющими увеличить скорость загрузки, которая для простых пользователей обычно ограничена. Но многим этого кажется мало, тем более когда есть возможность управлять сотнями и даже тысячами сайтов. Если уж хотите использовать quickstart, то купите его у разработчика, тем более его стоимость в среднем составляет 30-50 долларов, что, в общем, недорого даже при нынешнем курсе.
На второе место можно поставить взлом CMS через уязвимости, причем с защищённостью движков все в порядке, причина банальна – пользователи не устанавливают обновления. Кто-то боится, что после обновления «слетит» сайт, кому-то просто лень, или студия разработала сайт и передала его заказчику. Заказчик поручил вести сайт одному из сотрудников, и тот исправно наполняет его по инструкции, а обновление в его функции не входит…
Так одной из возможных причин утечки «Панамского архива» специалисты называют устаревшие CMS - Drupal, содержавший на момент взлома не менее 25 уязвимостей, и WordPress 4.1 с уязвимым плагином.
Ищем черный ход
Можно встретить рекомендации, что вылечить сайт можно, если загрузить копию сайта себе на компьютер и проверить обычным антивирусом. К сожалению, этот метод малоэффективен.
Во-первых, антивирус ищет вредоносы именно для ПК, сколько бы Вы не размещали на своем компьютере backdoor на php, заразить его (ПК) не удастся.
Во-вторых, это может быть короткий кусочек кода (обычно зашифрованный), который подгружает вредоносные скрипты с другого ресурса, а раз так, то искать его у себя бесполезно.
Можно пойти разными путями.
Первый вариант
Поскольку сайт содержит несколько тысяч файлов, то поиск измененных или «лишних» может занять довольно много времени, а результат неутешительным – после лечения на ресурсе через некоторое время снова появляются «левые» ссылки.
Ставим чистую Joomla (или другую CMS), устанавливаем шаблон, все компоненты, модули, плагины, что стояли на вашем сайте. Переносим все изображения со старого сайта, директория images, предварительно проверив, чтобы в ней не оставалось никаких файлов, кроме изображений, в том числе и во внутренних директориях. В случае если у вас установлен компонент K2, то изображения будут находиться в директории media/k2/items/cache/.
Внимание! Не лишним будет проверить наличие изображений с явно рандомным названием, как i2495mg.gif, обычно в таких изображениях прячется исполняемый код.
Подключаем старую базу. Вредоносные скрипты практически никогда ничего не пишут в базу, и даже если это не так, то скрипты для доступа к базе сейчас отсутствуют, также по названию таблиц можно определить, к чему они относятся, и вручную удалить лишние.
Подключаем базу со старого сайта
Экспортируем базу. Заходим на хостинге в phpmyadmin, выбираем в столбце слева нужную базу и переходим во вкладку «Экспорт». Нажимаем «Выделить все», можно поставить сжатие zip, и в самом низу страницы нажимаем «Ок». Сохраняем базу на свой ПК. Заходим в phpmyadmin, создаем новую базу, переходим в нее, открываем вкладку импорт и указываем путь к скачанному дампу. Теперь осталось подправить configuration.php, который находится в корне каталога, открываем его любым редактором. Например, Notepad++.
public $db = 'base'; - вместо base указываем свое имя базы;
public $user = 'root'; - если вы не меняли имя пользователя на локальном сервере, то оставляем как есть;
public $password = ''; - на локальном сервере обычно стоит пустой пароль, тоже оставляем.
Сохраняем изменения, проверяем работу сайта.
Второй вариант
Если у вас достаточно опыта, то можно включить просмотр исходного кода и посмотреть, присутствует ли «чужие» ссылки, далее посмотреть, например через firebug, откуда они берутся. Как правило, они зашифрованы и, как правило, алгоритмом base64.
Если опыта не хватает, то можно воспользоваться онлайн-сервисом, самый простой вариант – в кабинете вебмастера Яндекс или Гугл либо веб-сканер https://rescan.pro/. Я больше склоняюсь к ручному просмотру кода страницы, хотя, конечно, стоит признать, что всевозможные скрипты и сканеры заметно ускоряют работу.
Пример по поиску «левых» ссылок
Для примера я взял квикстарт с одного из варезных ресурсов. Нажимаем Ctrl+F5 для просмотра исходного кода, даже при беглом просмотре сразу находим:
Переключаем в административной панели шаблон сайта на стандартный, ссылки исчезли, значит, код прописан в варезном шаблоне, там и будем искать.
Открываем Notepad++, нажимаем Ctrl+F, переходим во вкладку «Найти в файлах», указываем директорию шаблона, а в строке поиска искомое, в данном случае "sa_wqngs". Нажимаем «Найти все». Поиск находит два совпадения.
Удаляем строки, обновляем страницу, строки с ссылками не исчезли, а поскольку я раньше не нашел прямых ссылок, значит, код зашифрован.
Запускаем новый поиск, теперь по «base64» и видим в коде шаблона:
Удаляем строки 174, 184, 186 (код комментировать не буду, кто хочет, может найти описание в сети). Снова обновляем страницу с исходным кодом, ссылки исчезли. Также проходим все результаты поиска с «base64», к слову, подобных вставок в шаблоне нашлось с десяток. Тут хорошо помогает сортировка по времени, так если большинство файлов шаблона датированы, предположим, 1 мая 2014 года, то файлы, изменённые, скажем, восемь месяцев спустя по меньшей мере подозрительны.
Для чего обновлять сайт?
В наше время «злобные хакеры» не ломают сайты вручную, если, конечно, это не крупный портал или база конфиденциальной информации. Взломы давно поставлены на конвейер. Для этого написаны боты (скрипты), которые перебирают в сети все сайты на популярных CMS, после чего пытаются применить библиотеку уязвимостей, удачное внедрение отправляется в отчет. Соответственно, как только появляется новая уязвимость, она сразу же добавляется в библиотеку.
Вроде бы элементарно, все современные CMS прямо в административной панели сообщают – вышли новые версии и нужно обновить, но очень часто приходится встречать сайты, которые не обновлялись больше года.
Используем сканер
Конечно, вручную не всегда удается найти некоторые «сюрпризы», так, возможно, вы вовремя не обновили систему или расширения, и на сайт был установлен backdoor... Сейчас существует множество сканеров, один из них AI-Bolit. К тому же он бесплатен для некоммерческого использования.
Используем его для «экспериментального» сайта, где я искал «лишние» ссылки. Как им пользоваться, хорошо документировано на официальном ресурсе, поэтому не буду дублировать информацию.
По результатам экспресс-проверки я получил сообщение о двух уязвимостях. Первая сообщала об устаревшей версии движка, это, в общем, я и так знал.
Вторая говорила об уязвимости в administrator/components/com_k2/lib/elfinder/elFinder.class.php - AFU : elFinder. Возможно, причина в том, что компонент тоже устарел.
На всякий случай я скачал последнюю версию компонента с официального сайта и сравнил версию, на который жаловался сканер, со свежескачанной. Для этого удобно использовать плагин для Notepad++, Compare. Как и предполагалось, отличие состояло только в версиях.
Сидим в засаде
На этом проверку можно было бы и завершить, но на всякий случай я решил почувствовать себя параноиком. Один из верных способов - посмотреть, какие пакеты ваш сайт засылает в сеть. Ставим Wireshark, он также хорошо задокументирован на сайте разработчика. Переходим по страницам сайта, действительно, сайт обращается к сети, но тут ничего страшного. Идет подгрузка шрифтов с Google Fonts, видео с YouTube…
Занавес
Этот материал, конечно, не подробная инструкция по «лечению» сайтов, а лишь небольшое руководство к действию. Дорогу осилит идущий...
Конечно, неплохо поставить элементарные средства защиты, но об этом уже в следующей части.
Комментарии