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

Вы можете заказать удаление вирусов или удалить вирус самостоятельно, действуя по данной инструкции.

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

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

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

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

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

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

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

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 В ходе очистки сайта необходимо закрыть все уязвимости, описанные на сайте разработчика CMS, а также проверить движок на наличие уязвимостей, добавленных туда при установке модов или ином дополнении функционала. Как движок, не имеющий подобных явных проблем можно порекомендовать UMI CMS.

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

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

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

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

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

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

Вам повезло. Но нельзя считать хакера глупышом. Обычно если вирус не дотерт, он возвращается. И возвращается в значительно более хитром и зашифрованном виде, и его удаление становится на порядок более сложной задачей. Главная || || Sovet || Sovet1 || Sovet2 || Sovet3 || Sovet4 || Sovet5 || Sovet6 || Sovet7 ||

Rabotaite.io.ua - сайт о работе и карьере Бизнес и Работа