•  
  •  
  •  
  •  
1 1 1 1 1 1 1 1 1 1 Рейтинг 5.00 (3 Голосов)
Каким образом самостоятельно провести удаление вируса с сайта - 5.0 out of 5 based on 3 votes

Очистка сайта от вируса данным методом может проводиться на DLE, Bitrix, Drupal, Joomla, ipb, vbulletin, phpBB и прочих движках. Инструкция позволит увидеть, как проводится чистка сайта от вирусов при помощи LAMP (самой распространенной технологии). Следует помнить, что рабочий процесс на сайтах ASP.NET и с другими технологиями отличается схожестью с приведенным примером.

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

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

1. Диагностический процесс.

Диагностику следует проводить, используя следующую схему, от простых элементов к сложным:

1.1 Занимаемся скачиванием файлов сайта на собственный ПК. Приступаем к проверке их при помощи своего обычного локального антивируса, к примеру, Касперского. Удаляем подозрительные участки кода и те файлы, которые оказываются выделенными антивирусом. Важно не забыть о создании резервных копий для любого изменяемого вами файла и всего ресурса в целом!

1.2 Исходный код html должен быть проверен на вхождение слов "iframe" и "javascript". Переходим к проверке найденных фреймов и внешних скриптов на чужеродность, то есть, на не принадлежность к нашему ресурсу. Особую подозрительность должны представлять iframe, имеющие малую или нулевую ширину и высоту, и javascript, в котором используется eval, unescape. В javascript особенно внимательно следует проверять document.write с вписанным другим javascript или iframe, либо вписанным meta-редиректом, а также javascript-редиректом. Иногда вирусным кодом используется маскировка под счетчики посещений.

Если в iframe, javascript или в редиректе вы нашли информацию о любом чужом домене (не вашем и не размещенном там вами) – это можно причислять к тревожному сигналу, даже если домен пуст или является нормальным сайтом. Для вирусов весьма часто используется принцип "матрешки", когда с реальным вредоносным содержимом можно столкнуться лишь при третьем или шестом редиректе.

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

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

1.5 Перечисленными в пп. 1.1-1.3 действиями следует воспользоваться не менее 3-4 раз. Лучше всего для этого использовать разные ip, с разные cookies и разные user-agent (браузеры). Это связано с тем, что вирусному коду присуща выдача в случайном порядке либо только для тех браузеров, которым свойственно отличаться уязвимостью, либо лишь поисковикам, либо с использованием иного критерия.

1.6 Следует добавить сайт к Яндекс-вебмастеру и Google-вебмастеру. При определенных обстоятельствах этими сервисами предоставляются указания о конкретном вредоносном коде, либо домене, который используется для включения вируса.

1.7 Если вами произведено посещение зараженного сайта при включенном javascript в браузере (чего всегда старайтесь избегать), то от вашей антивирусной программы можно ожидать выдачу списка угроз, которыми может обладать посещенный сайт. Эти данные позволяют выделить список с вирусными доменами.

1.8 Занимаемся проверкой кодов http-ответов от серверов, в которых могут находится редиректы разные user-agentы и разные ip адреса. Это связано с тем, что адрес редиректом выдается в случайном порядке либо с использованием клоакинга. В редких случаях вирусом ведется дневник и выдается редирект лишь единожды для каждого посетителя.

2. Процесс удаления вирусов.

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

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

2.2 Переходим к полнотекстовому поиску (используем сами файлы, не только их заголовки). Исследование преследует цель нахождения вхождений найденных в пп. 1.1-1.3 и найденного в пп. 1.5 и 1.6. Альтернативным вариантом будет ведение поиска непосредственно на сервере с использованием специального серверного скрипта.

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

  • include файлами с вирусного домена (вне зависимости от того, разрешено ли использование удаленного include в данных phpinfo);
  • eval, полученного от другого сайта данных;
  • eval, декодированного с применением функции base64_decode данных;
  • обфусцированным php-кодом;
  • переопределенными функциями;
  • include или eval внешних данных, передаваемыми скрипту с помощью глобальных массивов GET, POST, COOKIE, SERVER. Они чаще всего являются backdoor;
  • посторонними кодами с ссылочной биржи (распространенная цель взлома представлена продажей с него ссылок);
  • http-заголовками с редиректом на вирусный домен, отправляемыми функцией header;
  • exec, system, popen, passthru и другими функциями, выполняющими обращение к программе, если они не предусмотрены cms. Если cms не пользуется данными функциями, а также функцией eval, то займитесь их отключением в php.ini;
  • бэкдорами в триггерах mysql;
  • auto_prepend_file или auto_append_file в php, с бэкдорами или вирусными кодами;
  • Иногда командами запуска вирусного файла, который находится в tmp. Они запускаются пользовательскими crontab.

Когда анализируются нежелательные дополнения можно воспользоваться знанием кода, который выяснен в процессе диагностики (п.1).

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

2.4 Занимаемся дампом базы данных, и изучаем аналогично п.1.1, но с учетом того, что в базе код может быть преобразован в мнемоники и вместо <iframe> будет &lt;iframe&gt;

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

2.6 Занимаемся проверкой работоспособности сайта, его функционалом. Иногда вирусом затирается часть важных файлов, либо вносятся нарушения в синтаксисе. Это значит, что проведя очистку, следует заняться их восстановлением. В наиболее редко встречающихся случаях вирусом затирается все до такой степени, что файлы уже не могут быть восстановлены. Хорошо, если копию имеют хостеров или вы пользуетесь услугой резервного копирования.

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

3. Находим причину и переходим к ее ликвидации.

3.1 На этом этапе важно сосредоточится на анализе лог веб-серверов и лога ftp, найти в них время, предшествующее заражению. Если вы располагаете логом ошибок php и логом командного интерпретатора, то их использование отличается полезностью. Иногда логи содержат достаточное количество данных, которые потребуются для определения источников заражения сайта. Не следует завершать работу после закрытия первоначальных проблем, следует воспользоваться комплексным подходом.

Приводим список самых распространенных путей заражения:

  • кража ftp паролей;
  • уязвимость движка (cms);
  • заражение благодаря соседним сайтам, для которых используется тот же сервер;
  • уязвимости утилит на ресурсе либо сервере.

3.2 Кража ftp паролей. Список причин отличается разнообразием:

  • применение ftp посредством бесплатного wi-fi, зараженного экспроприирующим пароли вирусом. Либо компьютер, который входит в зараженную локальную сеть. Во избежание подобных утечек паролей, следует поверх бесплатной wi-fi-точки или зараженной локальной сети воспользоваться платным VPN с шифрованием;
  • похищение паролей из ftp-клиентов при помощи сайтовых вирусов, вирусов, которые вносит пиратская программа или носитель;
  • pfishing ftp-паролей.

3.3 Уязвимость движка (CMS).

Многим CMS все ещё свойственно отличаться уязвимостями типа SQL injection, source include, xss и прочими. Сообщение о выявлении подобной уязвимости можно найти на сайте техподдержки данных CMS. Очистка предполагает закрытие всех уязвимостей, описанных на сайте разработчиков CMS, а также проверку движка на возможные уязвимости, добавленные в него в процессе установки мода или иного дополнения функционала. В качестве движка, не имеющего похожих явных трудностей, следует использовать, к примеру, UMI CMS.

Кроме собственного наличия дыр, движок может отличаться наличием уязвимостей, связанных с сочетанием определенного типа настроек движка и/или определенной настройки сервера. Примером можно назвать случай, когда настройками сайта разрешается посетителям постить на сайте изображение с другого сайта, это автоматически повышает вероятность угрозы, рассмотренной в п.1.3. Некоторыми CMS не имеются явные уязвимости, но при несоответствии настроек сервера и системных требований эти CMS может отличаться высоким уровнем уязвимости. Очистка должна проходит с уточнением соответствия сервера с требованиями безопасности, которые выставляет конкретная CMS.

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

Если подключение к вашему сайту предполагает использование  ftp и вам не видны другие сайты, кроме вашего - это не является гарантией того, что от вас не предоставляется доступ к соседям и от них не предоставляется доступа к вашему ресурсу. Следует использовать подключение по ssh (если хостером предоставляются подобные возможности) и заняться проверкой, не видите ли вы файлы, принадлежащие другим пользователям. Если вы обладаете возможностью подняться выше, а также переходом к папкам других пользователей, то следует задуматься о смене хостинга, так как проведение очистки на отдельно взятом сайте при этом является невозможной.

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

4. Переходим к смене всех паролей: ftp, ssh, mysql, паролей для администрирования сайта (паролей cms).

Зачем впадать в такие крайности? Мне лишь понадобилось убрать из шаблона сайта строку с вирусным кодом, и теперь все как раньше.

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

Другие статьи

  • Услуги по технической поддержке сайта
    24.07.2013
  • Основы адаптивного веб-дизайна (Responsive). Каким образом сделать простой шаблон адаптивным
    12.11.2013
  • Статья-шпаргалка для запоминания размеров графических компонентов из соцсетей (Часть 1)
    13.05.2013
  • Часто задаваемые вопросы
    06.07.2015
  • Статья-шпаргалка для запоминания размеров графических компонентов из соц. сетей (Часть 2)
    19.07.2013
Портфолио
Память о Вас и Ваших близких на многие поколения
Подробнее
Прокат металла
Подробнее
Интернет-магазин кожи и меха
Подробнее
100% оригинальная парфюмерия в Москве
Подробнее
Вьетнамский ресторан премиум класса
Подробнее
Внедрение информационных систем
Подробнее
Организация международных конференций
Подробнее
Производство молочной продукции
Подробнее
Спортивный сайт
Подробнее
Интернет-магазин мебели и аксессуаров
Подробнее
Интернет-магазин электротранспорта
Подробнее
Сайт института актуальной экономики
Подробнее