Как искать вредоносный код без антивирусов и сканеров. Как искать вредоносный код без антивирусов и сканеров Как искать вредоносный код на WordPress
1. Распаковать в папку сайта.
2. перейти по ссылке ваш_сайт/fscure/
3. все
1. Автоматический поиск вирусов по сигнатурам.
2. Поиск строки в файлах
3. Удаление файлов
4. Патч вредоносного кода при помощи регулярных выражений
Скрипт не сделает за вас всю работу и требует некоторых минимальных знаний. Перед работой рекомендуется сделать бекап сайта.
Как работает?При первом запуске составляет индекс файлов. Файл fscure.lst в папке. Выводит список файлов содержащих потенциально вредоносные сигнатуры
. "Потенциально вредоносные" это значит, что решать вирус это или не вирус, придется вам. Список сигнатур настраивается в файле config.php , константа SCAN_SIGN . При дефолтных настройках скрипт не проверяет js файлы и не содержит для них сигнатур.
1. не создает индекс fscure.lst . Может происходить если не хватает прав. Поставьте 777 на папку fscure
2. 5хх ошибка. Чаще всего "504 Gateway Time-out". Скрипт не успевает отработать и вылетает по таймауту. В этом случае есть несколько путей для ускорения его работы. Скорость в первую очередь зависит от размера индекса. Он в файле fscure.lst . Обычно файл до 5Мб в 90% случаев успевает обработать. Если не успевает, можно уменьшить "жадность" скрипта запретив сканировать *.jpg;*.png;*.css в конфиге.
В файле config.php .
// разделитель; define("FILES_EXCLUDE","*.js;*.jpg;*.png;*.css");
3. Хостинг выдает предупреждение вида
{HEX}base64.inject.unclassed.6: u56565656: /var/www/u65656565/data/www/34535335353.ru/fscure/index.php
Вируса в скрипте нет и не было. А {HEX}base64.inject.unclassed.6 это конструкция вида "echo base64_decode(" , которая часто встречается и сама по себе вполне безобидна. Тем не менее в последней версии, я этот код заменил.
Что делать если у вас не получилось найти вирус самостоятельно?Вы можете обратиться ко мне за помощью. Расценки у меня скромные. На работу даю гарантию 6 месяцев. Стоимость работы 800 р. для 1 сайта. Если на аккаунте несколько сайтов цена определяется индивидуально.
Если у вас все получилось сделать самостоятельно, буду благодарен за материальное вознаграждение или ссылку на мой сайт.
Мои реквизиты:
yandex
41001151597934
webmoney
Z959263622242
R356304765617
E172301357329
Необходимо выполнять совместно. Если устранить первоначальную причину взлома (например, уязвимость в расширении CMS), но не удалить все вредоносные файлы, злоумышленник сможет снова получить доступ к сайту, воспользовавшись одним из своих скриптов. Если же удалить все загруженные вредоносные скрипты, но не устранить причину взлома, злоумышленник сможет повторно взломать сайт и снова загрузить на него скрипты.
Выполнять работу по удалению вредоносных скриптов и проводить анализ причин взлома должен специалист с соответствующими знаниями и опытом :
- Для удаления вредоносных скриптов необходимо знание языка программирования PHP , а также знание «изнутри» популярных CMS (Joomla, WordPress и т. п.) и расширений для них. Эти знания требуются, чтобы отличить скрипты непосредственно CMS и ее расширений от посторонних файлов, а также чтобы при встрече с сомнительными скриптами иметь возможность однозначно определить, какие действия они выполняют.
- Для анализа причин взлома требуется опыт администрирования сервера . Это необходимо для анализа состояния файлов на аккаунте, времени их изменения, а также для сопоставления этих данных с журналами сервера для определения, какие именно действия злоумышленника привели к взлому сайтов.
Поэтому если ваш сайт оказался взломан, рекомендуется во избежание повторных взломов не выполнять работу самостоятельно, а обратиться к специалисту, который произведет необходимую диагностику и порекомендует или выполнит необходимые действия для решения проблемы, и который сможет дать гарантию качества полученного результата.
Тем не менее, существует ряд мер, которые в некоторых случаях помогают возобновить безопасную работу сайта без наличия специальных знаний . Ограничением приведенного ниже способа является то, что для возобновления работы сайта требуется наличие его резервной копии, созданной на момент до взлома. Если дата взлома неизвестна, можно попробовать применить этот способ, используя самую раннюю резервную копию из имеющихся. Вторым ограничением, как следствие из первого, является то, что после восстановления сайта будут потеряны данные, добавленные на сайт после создания восстанавливаемой резервной копии (например, новые статьи, изображения или документы). Если требуется восстановить работу сайта, сохранив при этом новые данные, необходимо обратиться к специалисту.
Эти меры не позволяют установить причину взлома сайта , однако каждая из них направлена на устранение одной из потенциальных причин проникновения. Так как точная причина взлома неизвестна, необходимо выполнить их все. Действия расположены в таком порядке, чтобы сначала полностью исключить возможность продолжения деятельности злоумышленника на сайте или аккаунте хостинга в настоящий момент, после чего предупредить проникновение злоумышленника на сайт в будущем.
Приведенные ниже действия предполагают, что на вашем аккаунте хостинга располагается только один сайт . Если на аккаунте располагается несколько сайтов, то они также могли подвергнуться взлому, и сайт мог быть взломан через них. Необходимо либо перенести сайт, с которым проводятся восстановительные работы, на отдельный аккаунт, либо проводить восстановление для всех сайтов, размещенных на аккаунте, одновременно.
Очередность действий важна, поэтому необходимо выполнять их именно в том порядке, в котором они расположены ниже.
Все указанные выше действия необходимо выполнять в соответствии с указанной очередностью, без пропусков и каких-либо изменений. Если действия выполнены неточно, на сайте могут остаться вредоносные скрипты или уязвимости, в результате чего через короткое время он может быть снова взломан злоумышленником . Если по каким-либо причинам выполнить перечисленные выше действия в том виде, в котором они указаны, возможности нет, обратитесь к специалисту для проведения работ по восстановлению сайта после взлома.
Чтобы защитить сайт от повторных взломов в будущем необходимо придерживаться следующих рекомендаций:Вредоносный код попадает на сайт по неосторожности или злому умыслу. Назначения вредоносного кода различны, но, по сути, он наносит вред или мешает нормальной работы сайта. Чтобы убрать вредоносный код на WordPress его нужно сначала, найти.
Что такое вредоносный код на сайте WordPressПо внешнему виду, чаще всего, вредоносный код это набор букв и символов латинского алфавита. На самом деле это зашифрованный код, по которому исполняется, то или иное действие. Действия могут быть самые различные, например, ваши новые посты, сразу публикуются на стороннем ресурсе. По сути это кража вашего контента. Есть у кодов и другие «задачи», например, размещение исходящих ссылок на страницах сайта. Задачи могут самые изощренные, но понятно одно, что за вредоносными кодами нужно охотиться и удалять.
Как попадают вредоносные коды на сайтЛазейки для попадания кодов на сайт, также множество.
Сразу замечу, борьба с такими вирусами трудная, а ручное удаление требует знаний. Есть три решения проблемы: первое решение – использовать плагины анитвирисники, например, плагин под названием BulletProof Security .
Такое решение дает хорошие результаты, но требует времени, хотя и небольшого. Есть более радикальное решение, избавления от вредоносных кодов, включая сложные вирусы, это восстановить сайт из заранее сделанных резервных копий сайта.
Так как, хороший веб-мастер делает периодически, то откатиться на не зараженную версию, получится без проблем. Третье решение для богатых и ленивых, просто обращаетесь в специализированную «контору» или специалисту индивидуалу.
Как искать вредоносный код на WordPressВажно понимать, что вредоносный код на WordPress может быть в любом файле сайта, и не обязательно в рабочей теме. Он может занестись с плагином, с темой, с «самодельным» кодом взятого из Интернет. Попробовать найти вредоносный код можно несколькими способами.
Способ 1. Вручную. Листаете все файлы сайта и сравниваете их с файлами незараженного бэкапа. Находите чужой код – удаляете.
Способ 2. С помощью плагинов безопасности WordPress. Например, . У этого плагина есть замечательная функция, сканирование файлов сайта на наличие чужого кода и плагин прекрасно справляется с этой задачей.
Способ 3. Если у вас, разумный support хостинга, и вам кажется, что на сайте «чужой», попросите их просканировать ваш сайт своим антивирусом. В их отчете будет указаны все зараженные файлы. Далее, открываете эти файлы в текстовом редакторе и удаляете вредоносный код.
Способ 4. Если вы можете работать с SSH доступом к каталогу сайта, то вперед, там своя кухня.
Важно! Каким бы способом вы не искали вредоносный код, перед поиском и последующим удалением кода, закройте доступ к файлам сайта (включите режим обслуживания). Помните про коды, которые сами восстанавливаются при их удалении.
Поиск вредоносных кодов по функции evalЕсть в php такая функция eval . Она позволяет исполнять любой код в ее строке. Причем код может быть закодирован. Именно из-за кодировки вредоносный код выглядит, как набор букв и символов. Популярны две кодировки:
Соответственно в этих кодировках функция eval выглядит так:
- eval (base64_decode (...))
- eval (str_rot13 (...)) //во внутренних кавычках, длинные не понятные наборы букв и символов..
Алгоритм поиска вредоносного кода по функции eval следующий (работаем из административной панели):
- идёте в редактор сайта (Внешний вид→Редактор).
- копируете файл functions.php .
- открываете его в текстовом редакторе (например, Notepad++) и по поиску ищите слово: eval .
- если нашли, не спешите ничего удалять. Нужно понять, что эта функция «просит» исполнить. Чтобы это понять код нужно раскодировать. Для раскодирования есть онлайн инструменты, называемые декодеры.
Работают декодеры просто. Копируете код, который нужно расшифровать, вставляете в поле декодера и декодируете.
На момент написания статьи я не нашел у себя ни одного зашифрованного кода найденного в WordPress. Нашел код с сайта Joomla. В принципе разницы для понимания раскодирования нет. Смотрим фото.
Как видите на фото, функция eval после раскодирования, вывела не страшный код, угрожающий безопасности сайта, а зашифрованную ссылку копирайта , автора шаблона. Его тоже можно удалить, но он вернется после обновления шаблона, если вы не используете .
В завершении замечу, чтобы не получить вирус на сайт:
- Вредоносный код на WordPress чаще приходит с темами и плагинами. Поэтому не ставьте шаблоны и плагины из «левых», не проверенных ресурсов, а если ставите, внимательно их прокачайте, на наличие ссылок и исполнительных функций php. После установки плагинов и тем с «незаконных» ресурсов, проверьте сайт антивирусами.
- Обязательно делайте периодические бэкапы и выполняйте другие .
Мое мнение, состоящее в том, что от внедряемых вредоносных браузерных скриптов (хранимые XSS-атаки) проще и эффективнее защищаться средствами браузеров, было изложено ранее: . Браузерная защита от JavaScript-а, состоящая в добавлении к html-страницам сайта фильтрующего кода, надо полагать, является надежной, тем не менее, наличие такой защиты не отменяет необходимости использовать еще и серверный фильтр. В отношении тех же XSS-атак на сервере можно организовать дополнительную линию обороны. Надо помнить и о возможности внедрения злоумышленником в html-сообщение, отправляемое с сайта, не браузерных, а серверных скриптов (php), в распознавании которых браузер будет не силен.
Атакующий скрипт, хоть браузерный, хоть серверный - это ведь программа, надо думать, что программа всегда будет иметь некоторые символьные отличия от "чистого" html. Попробуем найти такие отличия и использовать их для построения html-фильтра на сервере. Ниже - примеры вредоносного JavaScript.
XSS:Какой-то текст
Какой-то текст
Зашифрованный XSS:Какой-то текст
Браузеры восстанавливают текст из символьных примитивов не только находящийся внутри html-контейнеров (между открывающим и закрывающим тегом), но и внутри самих тегов (между < и >). В http-адресах допускается url-кодирование. Указанное осложняет распознавание вредоносного кода на стороне сервера, так как одна и та же символьная последовательность может быть представлена разными способами.
XSS-черви:"+innerHTML.slice(action=
(method="post")+".php",155)))">
alert("xss");with(new XMLHttpRequest)open("POST","post.php"),send("content="+_.outerHTML)
Вышеприведенные XSS-черви - всего лишь несколько из множества присланных на проводимый в январе 2008 года Робертом Хансеном (aka RSnake) конкурс на минимального (самого короткого) вредоносного JavaScript-червя (итоги конкурса ).
Признаки XSS-атакXSS-скрипт - это программа, обращающаяся к объектам DOM (Document Object Model) и их методам.
Иное едва ли будет сколько-нибудь вредоносным. Например, JavaScript-строка
onckick="var a = "xss""
не затрагивает объектную модель документа, поэтому, даже будучи внедренной в html-тег,
такая строка безвредна. Только манипулируя объектами html-документа и их методами,
хакер способен причинить заметный вред сайту. Например, строка
onmousemove="document.getElementsByTagName("body").innerHTML="XSS""
уже заменяет содержимое страницы.
Признак обращения к методам DOM - это круглые скобки, также точки, стоящие слева от знака равенства. Круглые скобки могут использоваться и в html - для задания цвета в формате rgb() , однако, цвет шрифта и фона в html задается, как минимум, еще тремя способами. Поэтому круглыми скобками можно пожертвовать без ущерба для выразительности html-текста. Необходимо принять правилом, что скобки внутри тега (то есть, между < и >) - это очень опасно, если мы получили на сервер сообщение от пользователя, в этом сообщении обнаруживаются скобки внутри тегов, то самое уместное, что мы должны сделать - это заблокировать такое сообщение.
Точка может содержаться в html-тегах: при задании адреса ссылки (тег
);
при задании размера html-элементов (style="height:1.5in; width:2.5in;"
). Но символьных
последовательностей вида
точка буквы равно
в html-тегах быть не может. При наличии указанной последовательности внутри html-тега,
сообщение от пользователя, с большой вероятностью, содержит скрипт и должно быть заблокировано.
Еще один очевидный признак опасности - это символ "+ " внутри тега. В бесскриптовом html такого нет. При обнаружении внутри тегов плюсов - безжалостно блокируем сообщение.
К шифрованию символьными примитивами внутри html-тегов добронамеренный пользователь сайта, добавляющий комментарий посредством визуального редактора, никогда не прибегнет. Никаких выгод в виде дополнительных выразительных средств использование символьных примитивов в тегах не дает, лишь требует дополнительных затрат времени на написание. В большинстве случаев, надо думать, добронамеренный пользователь даже и не знает, что существуют некие символьные примитивы в html. Отсюда правило: амперсанд внутри тега - доказательство атаки на сайт. Соответственно, если видим такое, то блокируем сообщение.
Аналогичное правило следует принять и в отношении символа "% ", который может быть применен в url-кодировании. Однако, проценты используются и в "чистом" html - для задания относительных размеров элементов. Опасными являются комбинации, в которых за знаком "% " непосредственно следуют буква или цифра.
Обезвреживание серверных скриптовВ отличие от JavaScript-интерпретаторов в браузерах, php-интерпретатор на сервере не позволяет вольностей при написании текста программы. Поэтому, для нейтрализации возможного серверного скрипта достаточно сделать сквозную замену в html-сообщении пользователя всех символов, существенных при написании php-программы, их html-примитивами. Замене подлежат, в первую очередь, знаки доллар и подчеркивание, точка, круглая, квадратная и фигурная скобки, знаки плюс и минус, знак обратный слэш.
PHP-фильтр для HTML-сообщений$message - это полученное из визуального редактора на сервер html-сообщение.
// запоминаем длину сообщения $lenmessage = strlen($message); // вырезаем тег комментария $message = preg_replace("//", "", $message); // вырезаем каждый тег, в котором атрибут "src" ссылается на внешний ресурс $message = preg_replace("/]+?src[\w\W]+\/\/[^>]+?>/i", "", $message); // вырезаем каждый тег, в котором есть любой символ кроме: - a-z 0-9 / . : ; " = % # пробел $message = preg_replace("/]+[^->a-z0-9\/\.\:\;\"\=\%\#\s]+[^>]+?>/i", "", $message); // вырезаем каждый тег, в котором есть последовательность ". a-z =" $message = preg_replace("/]+?\.+?\=[^>]+?>/i", "", $message); // вырезаем каждый тег, в котором есть последовательность "% a-z" или "% 0-9" $message = preg_replace("/]+?\%+?[^>]+?>/i", "", $message); // вырезаем каждый тег, в котором есть последовательность "script" или "js:" $message = preg_replace("/]*?script[^>]*?>/i", "", $message); $message = preg_replace("/]*?js:[^>]*?>/i", "", $message); // вырезаем каждый тег, который начинается на символ кроме "a-z" или "/" $message = preg_replace("/]*?>/i", "", $message); // проверка: если сообщение укоротилось, то завершаем программу $lenmessage2 = strlen($message); if ($lenmessage != $lenmessage2) { print "Сообщение не может быть добавлено"; exit; } // совершаем сквозную замену опасных символов соответствующими им примитивами $message = str_replace("$", "$", $message); $message = str_replace("_", "_", $message); $message = str_replace(".", ".", $message); $message = str_replace(chr(92), "\", $message); // \ $message = str_replace("(", "(", $message); $message = str_replace(")", ")", $message); $message = str_replace("[", "[", $message); $message = str_replace("]", "]", $message); $message = str_replace("{", "{", $message); $message = str_replace("}", "}", $message); $message = str_replace("?", "?", $message); // теперь сообщение проверено, скрипты в нем обезврежены
Следует заметить, что фильтр не удаляет парные теги. Допустим, мы получили
Click here!
Фильтр вырежет только
, но парный (закрывающий) тег
останется. Если отдавать сообщения, в которых есть теги без соответствующих
им пар, в браузер, возможна неприятность в виде "перекоса" сайта. Неизвестно ведь, какому
открывающему тегу браузер сопоставит оставшийся без пары закрывающий тег. Поэтому, а также
по соображения безопасности, сообщения, в которых фильтром что-то вырезано, вообще не стоит
отдавать в браузер. Лучше выводить что-то наподобие "Сообщение не может быть добавлено"
и завершать программу.
Предполагается, что сообщение будет записано в файл (не в базу данных).
ОбсуждениеБуду благодарен за критику. Пишите на форум поддержки, в раздел
