воскресенье, 18 декабря 2011 г.

Конспект вебинара о веб-вирусах


-->
Здравствуйте. Готов конспект недавно прошедшего вебинара о веб-вирусах.
Его аудио-запись можно взять здесь.
Для большего удобства предлагаю прочесть конспект в PDF.
Сам он находится ниже.


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

1. Основные схемы заражения
1.1 Роботы заражают сайт через FTP. Самый распространённый вариант. Они различными методами получают пароли к FTP-серверам и с определённой периодичностью производят заражение файлов найденных на них. Пароли они получают по следующим схемам:
1.1.1 От вирусов запущенных на компьютерах веб-мастеров. Это встречается очень часто. Как привило веб-мастер сохраняет пароли прямо в FTP-менеджере и вирус берёт их уже оттуда.
1.1.2 Простым подбором. Кроме заражающих роботов в сети постоянно действуют машины осуществляющие подбор паролей к различным FTP. В качестве логинов они могут брать какие-нибудь стандартные слова типа admin, ftp, site или доменное имя атакуемого хоста и различные его модификации.
1.1.3 По средствам взлома хостинга. Тут всё просто. Хозяин робота взламывает хостинг (или заказывает взлом) и отдаёт роботу добытые пароли клиентов.
1.1.4 Через взлом сторонних сайтов. Часто веб-мастера используют один и тот же пароль на многих ресурсах, в т.ч. и на FTP-доступ к своему сайту. Взломав какую-нибудь площадку, и обнаружив там аккаунт пользователя с указанной домашней страницей, злоумышленники могут попробовать воспользоваться его паролем со взломанного сайта для доступа к FTP странички из профиля.
1.1.5 Через простую скупку. Хозяин робота по объявлениям покупает множество FTP-аккаутов чужих сайтов и отдаёт ему для заражения.
1.2 Заражение происходит изнутри через проблемы хостера. Это может быть неверная конфигурация ОС или отсутствие изоляции пользователей друг от друга.
1.3 Заражение может происходить автоматизированно извне, через проблемы какого-то конкретного веб-приложения. Как правило это происходит массово.
1.4 Через веб-шеллы. Злоумышленник может купить список ресурсов с установленными на них одинаковыми веб-шеллами и отправить им всем один и тот же запрос на заражение файлов сайта.
1.5 Через модуль веб-сервера. Злоумышленник, взломав сервер, устанавливает и прикрепляет к веб-серверу модуль, вставляющий вредоносный код в содержимое отдаваемых пользователям страниц. При этом часто создаётся ситуация когда администраторы хостинга, будучи уверенными в защите сервера, утверждают что проблема где-то у пользователей. А пользователи, наблюдая отсутствие вредоносных вставок у себя, говорят что проблема на сервере. Порой может пройти очень много времени пока реальная причина будет найдена и устранена.

2. Если заражение произошло и вирус находится в коде скриптов
2.1 Первым делом нужно заблокировать доступ к своему сайту. Так вы не будете ставить под удар посетителей. Чтоб на время лечения не терять позиции в поисковиках, желательно страницу о временной недоступности ресурса отдавать не с кодом 200 или 404. Если сайт на запросы будет отвечать кодом 500 или 503 поисковики, встретив такой ответ, просто решат зайти в другое время.
2.2 Если доступ по FTP всё ещё не ограничен по IP-адресам, сделайте это. Т.к. в большинстве случаев заражение происходит именно по FTP, данная мера с большой долей вероятности позволит вам предотвратить последующие заражения.
2.3 Поменяйте пароль FTP-пользователя, чей сайт был заражён.
2.4 Произведите автоматическую чистку вредоносных вставок. Как правило они статичны, и от файла к файлу не меняются. Для этого можете воспользоваться скриптом http://192.80.146.193/expressions.sh . Обратите внимание на то, что при поиске вредоносных кодов вы можете наткнуться на вполне безобидные зашифрованные вставки. Например многие темы для WordPress содержат подобный код, проверяющий не удалена ли авторская ссылка. Поэтому будьте внимательны. Вы также можете обратиться в тех. поддержку хостера и попросить автоматически почистить ваши скрипты. Иногда ТП может сделать это бесплатно если вы дадите ей сигнатуру вируса.
Кроме такой чистки вы можете накатить самую последнюю резервную копию или воспользоваться откатом изменений через систему контроля версий (если вы пользуетесь таковой).
2.5 Если вдруг у вас возникли затруднения с поиском заражённых файлов, вы можете найти всего один и по дате его изменения обнаружить другие. В *nix-системах для этого существует команда find и её параметры -mtime и -mmin. Первый параметр предоставляет пользователю очень гибкий механизм указания времени изменения, тогда как второй используется лишь для указания минут. Более подробную информацию вы можете получить в руководстве к этой команде (man find).2.6 Ещё одним способом поиска заражённых файлов является загрузках всех кодов сайта к себе на локальный компьютер и проверка их антивирусом. Если антивируса на локальной машине нет, вы можете запаковать коды в zip-архив и загрузить его на сервис онлайн проверки любой популярной антивирусной компании.2.7 Следующим шагом стоит проверить наличие обновлений ко всем веб-приложениям которые у вас установлены. Проверьте и форумы поддержки этих приложений. Вполне возможно что обновлений на данный момент нет, но на форуме имеются сообщения о неизвестной ранее уязвимости, случаях взлома свежих версий и т. д.2.8 Проверьте лог-файлы FTP-сервера. В большинстве случаев вы точно можете сказать сколько человек и с каких компьютеров получают доступ к FTP сайта. Поэтому проблем найти сторонние IP-адреса в лог-файлах быть не должно. Ищите любую подозрительную активность. Например, роботы могут раз в день изменять определённое количество файлов, или пробовать авторизоваться и сразу разрывать соединение (делается для проверки валидности пароля). Если вдруг вы обнаружили IP-адреса машин занимающихся заражением, вышлите их антивирусным компаниям. Кроме этого можете по WHOIS выяснить какой компании они принадлежат и написать туда жалобу. Возможно заражающий сервер будет блокирован. 2.9 Проверьте лог-файлы веб-сервера. Ищите любые странные запросы которые могут указывать на проведение атаки. Для экономии времени желательно пользоваться специализированными утилитами типа logwatch или соответствующими онлайн-сервисами.2.10 Проверьте не попал ли ваш сайт в чёрные списки Google и Yandex. Если да, нужно как можно скорее это исправить. Информация для Google - http://support.google.com/webmasters/bin/answer.py?hl=ru&answer=35843 , для Yandex - http://help.yandex.ru/webmaster/?id=1059440#1059449 .2.11 Установите и/или обновите антивирусы на тех машинах, с которых вы ведёте работу с сайтом. Желательно установить и настроить брандмауэр.2.12 Перестаньте хранить пароли в FTP-клиенте. Установите специальный менеджер паролей и храните всё в нём.3. Предотвращение заражения3.1 Можно воспользоваться скриптами проверки контрольных сумм (занести их запуск в режиме проверки в cron) файлов сайта http://192.80.146.193/md5-struct.php и http://192.80.146.193/md5-struct.py (одно и тоже, только реализовано на разных языках). Справку по их использованию можно прочесть в исходном коде или запустив скрипты без параметров. 3.2 Обратите внимание на сайт http://www.siteguard.ru/ . Этот сервис как раз занимается поиском вредоносных вставок на сайтах.3.3 Если у вас собственный сервер, обязательно разбейте все сайты по отдельным пользователям для локализации заражения если таковое вдруг произойдёт.3.4 Чаще делайте резервные копии. Если есть возможность — пользуйтесь системой контроля версий в процессе разработки сайта.3.5 Внимательно следите за обновлениями веб-приложений которыми вы пользуетесь. Если у производителей на форуме поддержки есть раздел посвящённый безопасности то обязательно подпишитесь на него.

За помощь в проведении вебинара благодарю Алексея Мещерякова (tank1st99@gmail.com) и хакера с ником beched.

6 комментариев:

  1. У меня что-то не срабатывает проверка контрольной суммы.
    /usr/local/bin/php
    /home/путь_к_файлу/md5-struct.php build|check

    Так или по-другому надо?

    ОтветитьУдалить
  2. Здравствуйте. Последним параметром указывается либо build (для построения структуры) либо check (для её проверки).

    ОтветитьУдалить
  3. Спасибо!

    Подскажите еще, пожалуйста, если я хочу исключить из проверки файлы изображений - это правильное выражение?
    $ignoreRegexprs = array("#(.*)\.(gif|jpg|png|pdf)$#");

    А файл проверяет все файлы, которые находятся в той же директории и ниже?

    Но письмо все равно не приходит... :(

    ОтветитьУдалить
  4. Выражение верное. Можно даже (.*) убрать из него. Оставить лишь точку и набор расширений.
    Обрабатывается всё содержимое указанной директории.
    Если переменная $sendOnOk = false, то письмо должно уходить когда текущие файлы толичаются от тех что заносились в сигнатуру. Если true - письмо уходит в любом случае.

    ОтветитьУдалить
  5. Вот у меня как раз true :)
    Как я поняла, надо один раз запустить на build, а потом уже поставить на check?
    Но все равно не приходит :)

    ОтветитьУдалить
  6. Верно. Посмотрите, не выключен ли вывод ошибок. Если так, то включите для проверки. Вполне возможно что просто не срабатывает функция mail(). Попробуйте для теста заменить оба её вызова на вызов print с каким-нибудь содержимым ("OK" или $message например).

    ОтветитьУдалить