Как понять, что ваш сайт взломали?

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



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

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

    Итак, куда смотреть?


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

    Настраиваем логи


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

    Рассмотрим возможную настройку логов. В приведенных ниже примерах в качестве ОС используется Linux, а в качестве сервера – nginx.

    Настройка logrotate для nginx не является чем-то особо сложным. Достаточно создать файл /etc/logrotate.d/nginx, содержащий следующий код:

    /opt/nginx/logs/*.log {
        daily                   # ротация осуществляется ежедневно
        missingok               # отсутствие файла не является ошибкой
        rotate 30               # хранить 30 дней
        compress                # сжимать файлы в ротации
        delaycompress           # текущий файл в ротации не сжимается 
        notifempty              # не обрабатывать пустые файлы
        create 640 user users   # create <права><владелец><группа>. 
                                # После ротации создает пустой log-файл. 
                                # Если атрибуты не предоставлены, то для нового файла будут использованы атрибуты,  что и у первоначального log-файла           
        postrotate              # Перезапуск nginx
                [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
        endscript
    }

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

    Смотрим внутрь


    Итак, логи у вас есть. Теперь стоить проверить серверные access логи на подозрительную активность. Приходило множество запросов с одного и того же IP? Множество запросов с разных IP, но сами запросы и интервалы между ними похожи? Все это еще один дополнительный повод проверить, не перехватил ли уже кто-нибудь доступ к сайту.

    Подобную проверку можно организовать через парсинг access логов с помощью awk. Вот несколько команд для awk, которые помогут проанализировать access логи для nginx:

    • IP-адреса, отсортированные по количеству запросов:

    awk '{print $1}' access.log | sort | uniq -c | sort -rn

    • 10 последних уникальных запросов, отсортированных по количеству:

    awk '{print $7}' access.log | sort | uniq -c | sort -rn | tail -n 10

    • Уникальные IP-адреса, отсортированные по количеству запросов к странице /administrator/ (сюда можно подставить любую вас интересующую — например, одну из тех, что вы получили с помощью предыдущей команды):

    awk '($7 ~ /administrator/)' access.log | awk '{print $1}' | sort | uniq -c | sort -rn

    • IP-адреса и страницы, к которым запрашивали доступ, отсортированные по количеству попыток

    awk '{print $1, $7}' access.log | sort | uniq -c | sort –r

    • Для мониторинга аномальной активности может помочь и отслеживание подозрительных юзерагентов. Например, написано просто «Google», указана очень старая версия «Internet Explorer», или браузером числится краткое «Mozilla», вместо полной строки с указанием версии и платфомы. Команда ниже выведет все уникальные юзерагенты, отсортированные по количеству обращений с их использованием:

    awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn

    Идем по «следам»


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

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

    «Присматриваем» за своим имуществом


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

    #!/bin/bash
    
    find ./ -iname '*.php' -cmin -1 > ./files.txt 
    [ -s ./files.txt ] && echo "Subject: static files changed!" | sendmail -v user@mail.com < ./files.txt

    ./ — текущая папка (необходимо указать нужную)
    '*.php' — любой файл с расширением .php (если у вас скрипты на Python, то ставим расширение .py и так далее)
    -1 — указание временного промежутка. Его стоит устанавливать в зависимости от того, как часто вы хотите проверять, не пытался ли кто-нибудь изменить ваш код. В данном примере выставлена одна минута.

    Если какие-то файлы были изменены, то имена этих файлов запишутся в файл files.txt и отправятся на почту. Вместо утилиты sendmail можете использовать любую, которая вам больше нравится (например, Postfix).

    Контролируем «прожорливость»


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

    Для отслеживания производительности очень удобно использовать утилиту sysstat.

    Настройка постоянного логирования осуществляется добавлением в файл /etc/cron.d/sysstat следующих строк:

    */15 * * * * root /usr/lib/sysstat/sa1 1 1
    55 23 * * * root /usr/local/lib/sa/sa2 -A

    Первая строка обозначает, что раз в 15 минут будут собираться данные системы. Храниться они будут в /var/log/sysstat/saDD, где DD — текущая дата. Вторая строка, что в 23:55 будет создан полный отчет за прошедший день. Лежать он будет в /var/log/sysstat/sarDD
    Посмотреть данные для CPU можно следующей командой:

    sar -P ALL -f /var/log/sysstat/saDD

    Данные по использованию памяти:

    sar -r -f /var/log/sysstat/saDD

    Полный список ключей для вывода можно найти на официальном сайте.

    А я на вас ссылался?


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

    Итак


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

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

    Похожие публикации

    Комментарии 17

      0
      А для IIS и ASP.NET будет продолжение?
        0
        Вообще не планировалось, но, если данная тема интересна, то, возможно, напишем.
        0
        Если какие-то файлы были изменены, то имена этих файлов запишутся в файл files.txt и отправятся на почту.
        Только не «были изменены», а «дата модификации была изменена», которую можно и подделать и скрипт уже не сработает.
          0
          Сработает, если использовать incrond
          В целом тема интересная.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Для ext4 можно проверять crtime метку (creation time). Если не ошибаюсь, подделать её можно только патчингом ядра, что как бы тот ещё геморрой на наломанной машинке.
              Если руками:
              $ sudo debugfs -R 'stat /var/www/index.php' /dev/sda1 2>/dev/null | grep crtime | cut -d ' ' -f4-9
              Tue Feb 13 11:34:47 2018
              

              Ну и да, это будет полезно только для поиска новых вредоносных файлов.
              +1
              А есть какие-то более «профессиональные» что-ли средства аудита изменения в сайтах, на разных CMS? Чтобы не только файлы шаблонов мониторило, но и в СУБД?
              У нас, например, не cron дергается каждую минуту, а ночью контентно сравниваются файлы в архивах бекапов с их предыдущими версиями и все это на стороннем сервере происходит.
              Такой подход не плох, но бекапы СУБД таким способом «в лоб» не сравнить, увы. Нужно знать архитектуру БД конкретной CMS.
                +1
                Очень странное послевкусие от прочитанного материала.

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

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

                  На мой взгляд триггеры, которые привлекают внимание к возможной проблеме, нужны независимо от контроля версий. Да и вопрос того, какие изменения были внесены, это уже больше к расследованию.
                    0
                    Я пытаюсь донести вот какую мысль:
                    Если у Вас 100 проектов, то Вам как администратору такого сервера нужно смотреть не в сторону таких скриптов, а подымать свой уровень администрирования. Изучать современные средства мониторинга работы подобных серверных систем. Если же у нас «сервер на коленке» для своих «пэт» проектов то применение таких скриптов оправдано в образовательных целях, и проигрывает той же системе контроля версий.
                      0
                      Ну SIEMкой то оно конечно удобнее :) В этом я с Вами согласен.
                      А я пытался донести ту мысль, что контроль версий и вот такие вот скрипты-триггеры для разных целей служат. Они вместе должны «играть». Ни кто ни кому не проигрывает.
                  +2
                  Статья о самых наивных способах узнать, что произошёл дефейс. Может стоит копнуть глубже?
                    0
                    Было бы очень интересно, копнуть поглубже.
                      0
                      Мы учтем ваши замечания и следующие темы раскроем шире.
                    0
                    #!/bin/bash
                    if (find ./ -name '*.php' -mmin -1)
                    	then find ./ -name '*.php' -mmin -1 > ./files.txt 
                    	echo "Subject: static files changed!" | sendmail -v user@mail.com < ./files.txt 
                    fi

                    а для чего find выполняется 2 раза, причём 1 раз вхолостую?
                    и да, атрибуту mtime верить нельзя, ибо даже старый как мир wso2 автоматически подменяет mtime при правке файла, при условии что мы владельцы файла
                    #!/bin/bash
                    
                    find ./ -iname '*.php' -cmin -1 > ./files.txt 
                    [ -s ./files.txt ] && echo "Subject: static files changed!" | sendmail -v user@mail.com < ./files.txt
                    
                      0
                      Спасибо, добавили в текст.
                      0
                      Я делаю надёжнее:
                      find "/path/to/files" -type f -exec sha1sum \{\} \; >>/root/sums-new.txt
                      diff /root/sums.txt /root/sums-new.txt
                      mv /root/sums-new.txt /root/sums.txt

                      И этот скрипт запускается в cron-е. Все изменения выдаются командой diff и cron их честно присылает на почту.

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

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