В настоящее время взломы сайтов становятся массовым, поставленным на поток процессом. Сайты могут взламывать ради использования их мощностей (популярный нынче майнинг, участие в ботнете и т.д.). Также злоумышленники могут быть заинтересованы в краже содержимого вашего ресурса или продвижении собственного контента (реклама, фишинг). В любом случае, злоумышленники постараются выжать максимум из успешного взлома, то есть остаться незамеченными как можно дольше, извлекая из взломанного сайта как можно больше выгоды.
Существуют очевидные признаки взлома: на страницах мелькает куча рекламы, которую вы не размещали, меняется вид страниц, вы не можете зайти в кабинет администратора, гугл и яндекс сообщают о том, что ваш сайт вредоносный, а IP появился в спам-базах.
Но зачастую сразу обнаружить, что сайт взломан, невозможно – ведь явных отклонений от обычной работы нет. Так какие признаки могут указать на то, что ваш сайт взломали?
В первую очередь обратите внимание на изменения в производительности сервера и посещаемости вашего сайта. Если страницы грузятся медленнее, а трафик отличается от того, какой у вас обычно был – время обеспокоиться.
Очень важным пунктом в обнаружении взлома являются логи сервера. Поэтому стоит удостовериться, что журналирование настроено правильно. Тогда, в случае чего, вы будите иметь все необходимые сведения касательно произошедших событий.
Рассмотрим возможную настройку логов. В приведенных ниже примерах в качестве ОС используется Linux, а в качестве сервера – nginx.
Настройка logrotate для nginx не является чем-то особо сложным. Достаточно создать файл /etc/logrotate.d/nginx, содержащий следующий код:
По возможности, лучше добавить автоматическое копирование логов в корпоративное облако или на другой сервер, дабы злоумышленник, если он решит почистить логи, не лишил бы вас их навсегда.
Итак, логи у вас есть. Теперь стоить проверить серверные access логи на подозрительную активность. Приходило множество запросов с одного и того же IP? Множество запросов с разных IP, но сами запросы и интервалы между ними похожи? Все это еще один дополнительный повод проверить, не перехватил ли уже кто-нибудь доступ к сайту.
Подобную проверку можно организовать через парсинг access логов с помощью awk. Вот несколько команд для awk, которые помогут проанализировать access логи для nginx:
• IP-адреса, отсортированные по количеству запросов:
• 10 последних уникальных запросов, отсортированных по количеству:
• Уникальные IP-адреса, отсортированные по количеству запросов к странице /administrator/ (сюда можно подставить любую вас интересующую — например, одну из тех, что вы получили с помощью предыдущей команды):
• IP-адреса и страницы, к которым запрашивали доступ, отсортированные по количеству попыток
• Для мониторинга аномальной активности может помочь и отслеживание подозрительных юзерагентов. Например, написано просто «Google», указана очень старая версия «Internet Explorer», или браузером числится краткое «Mozilla», вместо полной строки с указанием версии и платфомы. Команда ниже выведет все уникальные юзерагенты, отсортированные по количеству обращений с их использованием:
Также если вы заметили, что логи резко выросли в объеме или в access логе много раз обращаются к страницам, которых у вас не было – еще один повод насторожиться. Подобное изменение трафика может являться следствием различных причин. Одна из них может быть связана с тем, что ваш сайт стал медленнее грузиться (о чем речь пойдет позже), однако не все случаи столь тривиальны. Сегодня существует вредоносное ПО, которое будет просто перенаправлять пользователей на сайты, нужные злоумышленнику, причем оно может не влиять на авторизованных пользователей, что поможет дольше скрывать факт взлома.
Обычно встречающиеся вредоносы часто оставляют за собой и другие «следы». В панели администратора возникают новые пользователи, которых туда никто не добавлял (чаще всего со странными именами), на сервере появляются скрипты и файлы, взявшиеся непонятно откуда, а почтовый ящик может содержать подозрительные письма. Также стоит проверить, нет ли в запланированных задачах новых и неизвестных для вас.
А чтобы легко отслеживать, не изменял ли кто-либо ваши файлы, стоит добавить в cron простой скрипт, который будет это проверять:
./ — текущая папка (необходимо указать нужную)
'*.php' — любой файл с расширением .php (если у вас скрипты на Python, то ставим расширение .py и так далее)
-1 — указание временного промежутка. Его стоит устанавливать в зависимости от того, как часто вы хотите проверять, не пытался ли кто-нибудь изменить ваш код. В данном примере выставлена одна минута.
Если какие-то файлы были изменены, то имена этих файлов запишутся в файл files.txt и отправятся на почту. Вместо утилиты sendmail можете использовать любую, которая вам больше нравится (например, Postfix).
Если вы заметили, что сайт стал грузиться медленнее, хотя вы ничего не добавляли, это тоже повод проверить, на что же идут ресурсы. Сильно поможет, конечно, если у вас есть история/логи, касающиеся производительности. Таким образом можно будет посмотреть, не было ли внезапного роста нагрузки на сайт, хотя никаких обновлений и новых элементов вы не добавляли. Если производительность выше, чем вы ожидаете, то стоит задуматься, не взломали ли вас.
Для отслеживания производительности очень удобно использовать утилиту sysstat.
Настройка постоянного логирования осуществляется добавлением в файл /etc/cron.d/sysstat следующих строк:
Первая строка обозначает, что раз в 15 минут будут собираться данные системы. Храниться они будут в /var/log/sysstat/saDD, где DD — текущая дата. Вторая строка, что в 23:55 будет создан полный отчет за прошедший день. Лежать он будет в /var/log/sysstat/sarDD
Посмотреть данные для CPU можно следующей командой:
Данные по использованию памяти:
Полный список ключей для вывода можно найти на официальном сайте.
Стоит ещё проверить все исходящие ссылки с вашего сайта (например, с помощью данного сервиса или других подобных) – не появилось ли новых? Тех, что вы не добавляли? Вдобавок хорошо бы проверить, что отображается в поисковиках касательно вашего сайта и по каким фразам к вам попадают посетители. Посмотрите на всякий случай, как работает ваш сайт для разных платформ/стран/браузеров – вредоносы могут срабатывать только для какой-нибудь определенной категории пользователей, это делается с целью оставаться незамеченными.
Необходимо проверять указанные выше признаки и места по меньшей мере раз в неделю, дабы сильно не выпускать из рук ситуацию, если сайт все же был взломан. Отслеживание новых обновлений для используемого ПО и важных обновлений безопасности, наряду с планированием бэкапов и периодической сменой паролей, вообще должны быть частью стандартных периодических процедур.
О том, что делать, когда вас уже взломали, мы поговорим в одной из следующих статей.
Существуют очевидные признаки взлома: на страницах мелькает куча рекламы, которую вы не размещали, меняется вид страниц, вы не можете зайти в кабинет администратора, гугл и яндекс сообщают о том, что ваш сайт вредоносный, а 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Полный список ключей для вывода можно найти на официальном сайте.
А я на вас ссылался?
Стоит ещё проверить все исходящие ссылки с вашего сайта (например, с помощью данного сервиса или других подобных) – не появилось ли новых? Тех, что вы не добавляли? Вдобавок хорошо бы проверить, что отображается в поисковиках касательно вашего сайта и по каким фразам к вам попадают посетители. Посмотрите на всякий случай, как работает ваш сайт для разных платформ/стран/браузеров – вредоносы могут срабатывать только для какой-нибудь определенной категории пользователей, это делается с целью оставаться незамеченными.
Итак
Необходимо проверять указанные выше признаки и места по меньшей мере раз в неделю, дабы сильно не выпускать из рук ситуацию, если сайт все же был взломан. Отслеживание новых обновлений для используемого ПО и важных обновлений безопасности, наряду с планированием бэкапов и периодической сменой паролей, вообще должны быть частью стандартных периодических процедур.
О том, что делать, когда вас уже взломали, мы поговорим в одной из следующих статей.