WebGuard.pro
Хостинг сайтов с защитой от вирусов
Время работы: круглосуточно
Россия, г. Краснодар

Как самостоятельно бесплатно удалить вирус с сайта (старая версия)

Статьи

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

Статья  актуальна для большинства систем управления сайтами (Joomla, Bitrix, DLE, Drupal, vbulletin, ipb, phpBB и т.д.). Перед тем как приступить к очистке сайта от вирусов, обязательно проверьте и очистьте свой компьютер от вирусов, а также все компьютеры с, которых вы имеете доступ к управлению сайтом. После очистки компьютера, нужно сменить все пароли доступа к сайту (ftp, баз данных mysql, пароли от административной части сайта и пароль от административного email ящика, указанного в настройках сайта, если такой имеется). Перед тем как начать работу с сайтом обязательно сделайте его резервную копию.

Внимание! Никогда не сохраняйте пароли в своих браузерах и настройках FTP клиентов!

Если Вы начинающий вебмастер, рекомендуем начать очистку с новой, упрощённой версии статьи: лечение сайта от вирусов бесплатно.

1. Диагностика.

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

1.1 Ищем в исходных кодах файлов и/или html страницах сайта  вхождения слов "iframe" и "javascript". Анализируем найденные участки кода и внешние ява-скрипты на предмет чужеродности. Особое внимание стоит уделить iframe нулевой или малой высоты и ширины, а также запутанным ява-скриптам в одну строку с использованием функций unescape, eval, String.fromCharCode. Также в вредоносных скриптах не редко встречаются конструкции document.write со вставкой другого iframe или javascript, или вставкой meta тега (или ява-скрипта) с редиректом. Если в ява-скрипте, iframe или редиректе присутствует любой чужой домен (не Ваш и не размещенный там Вами) - это сигнал тревоги, даже если на домене пусто или там нормальный сайт. Вирусы чаще всего распространяются "каскадом", когда вирусный код оказывается только на третьем - пятом фрейме или редиректе.

1.2 Проводим аналогичный анализ по подгружаемым внешним ява-скриптам. Во внешних css ищем behavior, содержащие чужеродный код.

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

1.4 Перечисленные в пп. 1.1-1.3 действия необходимо выполнить с запросом страницы и скриптов несколько раз, в идеале с разных ip, с разными cookies и разными user-agent (браузерами) поскольку вирусный кодможет выдаваться случайным образом либо только тем броузерам, которые уязвимы, либо только поисковику, либо по иному критерию.

1.5 Добавляем сайт в Яндекс-вебмастер и Google-вебмастер, в некоторых случаях эти сервисы дают указание конкретного вредоносного кода, либо доменов, с которых подгружается вирус.

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

1.7 Смотрим коды 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 ('HTTP_REFERRER','HTTP_USER_AGENT' и др.), обычно являющееся 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 через бесплатный wifi, зараженный похищающим пароли вирусом, или с компьютера в зараженной локальной сети. Чтобы избежать такой утечки паролей, целесообразно поверх бесплатного wifi илиподозрительной локальной сети использовать платный VPN с шифрованием.
  • похищение паролей из ftp-клиента (например, похищение файлa wcx_ftp.ini из Total Commander) с помощью сайтового вируса, вируса в пиратской программе или вируса на флешке.
  • pfishing ftp-паролей (при входе на сайт seo-утилит или иной подобный сервис предлагают ввести ftp логин и пароль, либо под видом представтелей хостера под разными предлогами просят посетить якобы страницу смены ftp-пароля).

 

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

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

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

3.4 Заражение от соседних сайтов на том же сервере.

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

 

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

 

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

 

Зачем все так сложно? Я вот просто убрал из шаблона сайта строчку с вирусом, и у меня теперь все хорошо.

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

 

Если самостоятельное удаление вируса не увенчалось успехом, значит заражение слишком серьёзное. К Вашим услугам очистка сайта от вирусов специалистами WebGuard.pro

Оставьте комментарий!