Как Host-tracker помог оперативно обнаруживать вредоносный код

    Наш сервис мониторинга сайтов, помимо доступности серверов, позволяет также мониторить контент сайта. К примеру, если необходимо получать уведомления о том, что на сайте появилось определенное ключевое слова, или наоборот при его отсутствии.
    Сегодня хотим рассказать, как с помощью Host-tracker наш клиент боролся с обнаружением вредоносного кода, чтобы не попадать в бан Яндекса.
    image

    Изложение от лица клиента:

    Сайт попал в бан Яндекса

    В один прекрасный день при попытке зайти на сайт mysite***.com появилось предупреждение о том, что сайт может угрожать безопасности компьютера.
    А также пришло письмо от Яндекс: На сайте обнаружен потенциально опасный код:
    На страницах вашего сайта mysite***.com обнаружен код, который может быть опасен для посетителей. Выполнение этого кода при посещении сайта может привести к нежелательным для пользователя последствиям: заражению компьютера вредоносными программами, несанкционированному использованию его ресурсов, порче или краже личных данных.
    В настоящий момент сайт выводится в результатах поиска с пометкой «Этот сайт может угрожать безопасности вашего компьютера».
    Яндекс никак не оценивает содержание сайта и предупреждает пользователей о том, что сайт мог быть заражен без ведома его владельцев.
    Пожалуйста, удалите вредоносный код. Если при новой проверке код не будет обнаружен, пометка в результатах поиска будет снята. Для того чтобы снять пометку как можно быстрее, сразу после удаления кода вы можете запросить перепроверку сайта.


    В панели Яндекс вебмастер было сообщение:
    Результат выборочной проверки
    Дата последней проверки 19.08.2013
    Страница mysite***.html
    Вердикт Поведенческий анализ.


    Обнаружение вредоносного кода

    Сайт естественно сразу же был проверен различными онлайн антивирусами, но никаких угроз обнаружено не было. После этого я подумал, что это какое-то недоразумение и написал письмо в поддержку Яндекса, с просьбой прояснить ситуацию, указав что онлайн антивирусы не нашли никаких угроз. Они ответили, что на сайте заражен один из файлов — common.js. Еще я обратил внимание, что с главной страницы появились ссылки на какие-то «левые» сайты. Предполагаю, какая-то биржа ссылок нашла неплохой метод продавать ссылки ничего не подозревающих владельцев. Открыв файл, я действительно обнаружил в нем вредоносный код:
    />...

    Борьба с вредоносным кодом

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

    Решил также проверить соседей по IP. Наугад открыл 5 сайтов, и ни сколько не удивился, что у них с главной присутствуют тоже внешние ссылки, с использованием iframe. Естественно сразу написал хостеру об этом, и получил ответ, что все ОК, заражено не более 5% клиентских аккаунтов и проблем якобы нет. Ответил им, что за чушь и привел доводы о существовании проблемы, тогда они дали уже более развернутый ответ с предложением восстановить бекап. Также рекомендовали поставить доступ на файлы 444 и на каталоги 555, что я и сделал. Но прошел буквально день, доступ возвращен на 644 и 755 соответственно и в файле вредоносный код.

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

    Сроков решения проблемы не было озвучено, и сайт постоянно попадал в бан Яндекса и соответственно за это время уже потерял позиции в выдаче.

    Поиск по контенту

    К конкретным файлам, которые знал, что заражаются чуть ли не каждые пару часов использовал функцию Host- tracker – поиск по контенту. Выбрал Http проверку, прописал URL: путь к файлу mysite***/common.js, который постоянно заражался, прописал мониторить по ключевому слову «iframe», которое присутствовало во вражеском коде, выбрал: все ключевые слова должны отсутствовать на проверяемой странице. Теперь, когда вражеский код появлялся, мне приходило SMS и уведомление на e-mail буквально через минуту (выбрал интервал опроса 1 мин).

    Поначалу приходилось самостоятельно оперативно исправлять, чтобы Яндекс не банил. Потом обратил внимание, что приходит уведомление, что common.js содержит вредоносный код, и буквально через пару минут файлы уже без вредоносного кода. Хостер наконец-то стал самостоятельно лечить файлы. Это продолжалось еще пару дней, пока сообщения о заражении не перестали приходить.

    Проверка контрольной суммы

    Для себя дополнительно реализовал простой метод контроля изменения файлов *.js:
    Файлы должны быть всякого вражеского кода. Сохраняем, например, утром контрольную сумму файлов с нужным расширением .js, .php и т.д.
    find . -type f -name "*.js" -exec md5sum {} \; > file-js1.txt
    и повторяем процедуру вечером
    find . -type f -name "*.js" -exec md5sum {} \; > file-js2.txt
    потом сверяю два этих файла на расхождение в контрольных суммах:
    diff -u file-js1.txt file-js2.txt.
    Если что-то поменялось, проверяю причину изменения файлов.

    После это случая я нашел несколько автоматизированных решений, которые позволяют отслеживать изменения по определенным типам файлов, и пользуюсь ими.
    Метки:
    ХостТрекер 58,69
    Сервис мониторинга доступности сайтов
    Поделиться публикацией
    Комментарии 30
    • +13
      Не лучше ли сменить хостера было?..
      • –7
        Не согласен, смена хостера у высоконагруженного проекта, на который льется трафик — тот еще геморрой.
        • +1
          Клиент по факту потом таки и сменил хостера
          • +17
            Собственно и история о том как человек лечил следствие, а не причину до тех пор пока «само не прошло».

            Можно было бы рассказать так:
            Однажды я простудился и начал чихать.
            Вместо того чтобы идти к врачу, я нанял гастербайтера, который зажимал мне рот платком, когда замечал, что я хочу чихнуть.
            Было неудобно.
            Так же было неприятно и сыро в ботинках, но я не обращал на это внимания.
            Через полгода простуда прошла (после небольшого воспаления лёгких, которое я тоже не стал лечить).
            А ещё через полгода я купил новые ботинки.
            С тех пор живу долго и счастливо, не болею. Но с гастербайтером тем не расстаюсь — он стал моим лучшим другом. Я его пою, кормлю, читаю ему книжки на ночь, а он взамен следит не захочу ли я чихнуть. И если я захочу — он заткнёт мне рот.
            Конец.

          • +3
            А откуда вредоносный код то? Если так часто меняется файл, то значит у кого то полный доступ, причем даже после смены пароля.
            • +1
              Полный доступ есть у хостера, очевидно же.
              • +2
                Поламали сервер хостера. Скорей всего контрольную панель. Пока хостер искал кудой его ломали, а клиент искал нового хостера, пришлось придумывать костыли с мониторингом на вредоносный код.
              • +4
                Мне кажется, было бы не лишним озвучить хостера. В группе риска не только вы, но и все его пользователи.

                P.S. Забыл, что повествование не от пострадавшего лица, извините. Но, если есть такая информация, то озвучить в любом случае не помешало бы.
                • +6
                  Основная проблема тут — ужасающие технологии. shared hosting вообще не даёт возможности понять, что происходит.

                  Потому что если бы такое произошло у меня, то если бы канонические методы анализа не сработали бы, то я бы просто пустил tcpdump на всё с отсылкой данных на соседний сервер. А потом бы под микроскопом изучал пакеты и момент появления файла.

                  Но без root-доступа (точнее, без cap networking) это невозможно.

                  Переползайте на vds'ы.
                  • +4
                    Если был более-менее полноценный доступ до файлов, то достаточно было поставить immutable флаг на фаил/каталог. Большинство гадостей (вернее, все, которые я видел) не умеют обрабатывать такую ситуацию

                    или говоря другими словами, chattr +i js/common.js из под root
                    • –6
                      В линуксе появился флаг read-only?.. Почему же тогда samba до сих пор его виндовым клиентам передавать не умеет?..
                      • +4
                        Этот флаг отвечает за запрет изменений с объектом. То есть нельзя будет его удалить, сменить ему дату, сменить набор флагов и так далее. Флагу этому почти столько же, сколько и файловой системе.

                        Про samba не знаю (давно не ставил), но раньше отсутствие флага w говорило виндам, что файлик read-only и они вполне себе были этим фактом довольны.
                        • 0
                          В линуксе есть флаг «разрешить запись», а отсутствие его = «запретить запись» = «read only». Samba транслирует это в отсутствие права записи у соответствующего пользователя, то есть, получается то же самое.

                          Флаг read only как отдельный, не в рамках acl — отсутствует, но он вообще бесполезен при наличии acl, которые позволяют делать то же самое, но гибче.
                          • 0
                            Чем по поведению chattr +i отличается от виндового attrib +r? И почему команда chattr держится в секрете и я про нее первый раз слышу?..
                            • +1
                              chattr +i более навороченная вещь — после этого даже root не сможет удалить или что-то сделать с файлом. Это уже расширения классической системы безопасности UNIX. Есть ACL, обычные «классические» атрибуты, расширенные атрибуты и вдобавок SELinux — можно вообще закрыться наглухо. По понятным причинам хостеры не заморачиваются с безопасностью.

                              Естественно, рут может и снять этот атрибут.
                              • 0
                                Повторяю вопрос: чем это отличается от поведения на винде? Там точно так же ридонли файлы нельзя трогать, не сняв сначала этот атрибут.
                                • +1
                                  Никто не гарантирует вам наличие расширенных атрибутов в линуксе. Может, ФС не поддерживает их; может, ядро, или просто ФС смотнирована без «acl,user_xattr».

                                  А вот почему вам неизвестна эта команда — это вопрос не к нам, согласитесь.
                                  • 0
                                    Конечно. Это вопрос к авторам книжек, которые я читал…
                                    • +1
                                      Начитаться книжек — не значит быть уверенным в собственной образованности. Надо ещё руками щупать всё, с чем работаете, залезать в неположенные места… хм, о чём это я… Флаг immutable — штатная в Linux, давно известная вещь (по крайней мере мною), но стрёмная, т.к. в будущем может вводить в заблуждение ошибками стороннего ПО типа «нет доступа» — и гадай, что «держит».
                                      • 0
                                        Чтобы щупать руками разные места, надо знать хотя бы про существование этих самых мест.
                                        • 0
                                          ls /sbin; ls /usr/bin + man каждое_увиденное. Это, когда заняться нечем, полностью убивает всяческую депрессию и скуку :-)
                                          • 0
                                            У меня нет столько времени для убийства… :-)
                                            • 0
                                              У меня тоже его не 100%. Но за годы, потихоньку, изучаю… Собственно, из-за куда-то почти сразу затерянного учебника по Linux я так и изучал данное семейство ОС, когда только начинал работать с ним. Главное — знать английский, и не так много времени всё занимает.
                                            • +1
                                              man --path | tr : "\n" | xargs -I{} find {} -type f

                                              Как-то так:)
                                            • +1
                                              Щупайте man, там всё есть. Да и что у вас были за книжки такие, в хороших книгах вроде Linux in a Nutshell всё это написано очень подробно. Да и мне кажется для администратора достаточно только этой книги в 90% случаев.
                                      • 0
                                        Он не отображается в выводе ls, он запрещает вам пользоваться chmod (даже если вы root), он поддерживается не во всех файловых системах (из того, что у меня: XFS поддерживает, старая ReiserFS нет, про FAT на флэшках вы, наверное, уже догадались) и о нём знает меньше людей. Кроме того, вы не избавитесь от +i, будь вы хоть трижды владелец файла, тогда как chmod владелец может применить всегда, даже если все атрибуты доступа сброшены.
                                        • 0
                                          Виндовые атрибуты точно так же не отображаются в выводе dir.

                                          Вот тот факт, что его не может поставить или снять владелец файла, только root — уже интереснее, это действительно отличие. Заодно это объясняет, почему его не отображает на read-only флаг samba, и почему его нет на флэшках с фатом.
                                          • +1
                                            Не только root: в соответствии с документацией это может сделать root или любой процесс, которому предоставлена возможность CAP_LINUX_IMMUTABLE (в 99 % случаях это действительно означает «только root»).
                            • 0
                              Это борьба с симптомом, но не болезнью. С моей точки зрения, нужно провести проверку всех исполняемых файлов, в особенности обратить внимание на инструкции вроде eval (у знакомого вебмастера злодеи вшили подобное в его файлы). Затем сменить хостера и залить туда проверенные файлы.
                              • +1
                                Я бы сделал так
                                — настучать в арбуз хостинга вирусодержателя (куда ведёт iframe)
                                — порыться в логах ftp, ssh, — если вирусатор доступается извне (просто украл пароли), то настучать в арбуз его провайдера
                                — изменить common.js так, чтобы он сам дезактивировал этот iframe
                                — прописать в кронтаб восстановление common.js из бэкапа

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

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

                                Самое читаемое