Бортовой журнал. Бортовой журнал Поиск вредоносных кодов по функции eval

Еще один очевидный признак опасности - это символ "+ " внутри тега. В бесскриптовом html такого нет. При обнаружении внутри тегов плюсов - безжалостно блокируем сообщение.

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

Аналогичное правило следует принять и в отношении символа "% ", который может быть применен в url-кодировании. Однако, проценты используются и в "чистом" html - для задания относительных размеров элементов. Опасными являются комбинации, в которых за знаком "% " непосредственно следуют буква или цифра.

В отличие от JavaScript-интерпретаторов в браузерах, 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!
Фильтр вырежет только , но парный (закрывающий) тег останется. Если отдавать сообщения, в которых есть теги без соответствующих им пар, в браузер, возможна неприятность в виде "перекоса" сайта. Неизвестно ведь, какому открывающему тегу браузер сопоставит оставшийся без пары закрывающий тег. Поэтому, а также по соображения безопасности, сообщения, в которых фильтром что-то вырезано, вообще не стоит отдавать в браузер. Лучше выводить что-то наподобие "Сообщение не может быть добавлено" и завершать программу.

Предполагается, что сообщение будет записано в файл (не в базу данных).

Буду благодарен за критику. Пишите на форум поддержки, в раздел

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.

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

Современные вредоносные и хакерские скрипты значительно отличаются от тех, что были 4-5 лет назад. Сейчас разработчики вредоносного кода комбинируют обфускацию, шифрование, декомпозицию, внешнюю подгрузку вредоносного кода и используют другие уловки для того, чтобы обманывать антивирусное ПО. Поэтому вероятность пропуска новых “вредоносов” значительно выше, чем раньше.

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

Вначале рассмотрим, что именно следует искать при взломе.

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

В unix сложно найти более ценную пару команд для поиска файлов и фрагментов, чем find / grep.

find . -name ‘*.ph*’ -mtime -7

найдет все файлы, которые были изменены за последнюю неделю. Иногда хакеры “скручивают” дату изменения у скриптов, чтобы таким образом не обнаружить новые скрипты. Тогда можно поискать файлы php/phtml, у которых менялись атрибуты

find . -name ‘*.ph*’ -сtime -7

Если нужно найти изменения в каком-то временном интервале, можно воспользоваться тем же find

find . -name ‘*.ph*’ -newermt 2015-01-25 ! -newermt 2015-01-30 -ls

Для поиска в файлах незаменим grep. Он может искать рекурсивно по файлам указанный фрагмент

grep -ril ‘stummann.net/steffen/google-analytics/jquery-1.6.5.min.js’ *

При взломе сервера полезно проанализировать файлы, у которых установлен guid/suid флаг

find / -perm -4000 -o -perm -2000

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

lsof +r 1 -p `ps axww | grep httpd | grep -v grep | awk ‘ { if(!str) { str= } else { str=str»,»}}END{print str}’` | grep vhosts | grep php

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

• Корреляция даты и времени отправки письма (которые можно узнать из лога почтового сервера или служебного заголовка спам-письма) с запросами из access_log помогают выявить способ рассылки спама или найти скрипт спам-рассыльщика.

• Анализ трансфер-лога FTP xferlog позволяет понять, какие файлы были загружены в момент взлома, какие изменены и кем.

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

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

• По access_log и error_log можно анализировать действия хакера, если известны имена скриптов, которые он вызывал, IP адрес или User Agent. В крайнем случае можно просмотреть POST запросы в день взлома и заражения сайта. Часто анализ позволяет найти другие хакерские скрипты, которые были загружены или уже находились на сервере в момент взлома.

Намного проще анализировать взлом и искать вредоносные скрипты на сайте, если заранее позаботить о его безопасности. Процедура контроля целостности (integrity check) помогает своевременно обнаруживать изменения на хостинге и определять факт взлом. Один из самых простых и эффективных способов – положить сайт под систему контроля версий (git, svn, cvs). Если грамотно настроить.gitignore, то процесс контроля за изменениями выглядит как вызов команды git status, а поиск вредоносных скриптов и измененных файлов – git diff.

Также у вас всегда будет резервная копия файлов, до которой можно «откатить» сайт в считанные секунды. Администраторам сервера и продвинутым веб-мастерам можно использовать inotify, tripwire, auditd и другие механизмы для отслеживания обращений к файлам и директориям, и контроля за изменениями в файловой системе.

К сожалению, не всегда есть возможность настроить систему контроля версий или сторонние сервисы на сервере. В случае shared-хостинга не получится установить систему контроля версий и системные сервисы. Но это не беда, есть достаточно много готовых решений для CMS. На сайте можно установить плагин или отдельный скрипт, который будет отслеживать изменения в файлах. В некоторых CMS уже реализован эффективный мониторинг изменений и механизм integrity check (Например, в Битрикс, DLE). В крайнем случае, если на хостинге есть ssh, можно сформировать эталонный слепок файловой системы командой

Акция действует до конца месяца.

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

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

Выполнять работу по удалению вредоносных скриптов и проводить анализ причин взлома должен специалист с соответствующими знаниями и опытом :

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

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

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

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

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

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