Мониторинг сервера и анализ логов: как обнаруживать атаки на ранней стадии

Что действительно нужно отслеживать

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

Согласно NIST Special Publication 800-92 (Guide to Computer Security Log Management), управление логами следует рассматривать как непрерывный операционный процесс, охватывающий формирование, передачу, хранение, анализ и удаление логов, а не как разовую настройку. Главный тезис руководства в том, что логи имеют ценность только при наличии определённого процесса их просмотра и реагирования на найденное; сервер, генерирующий гигабайты нетронутых лог-файлов, по сути не более защищён, чем сервер, который вообще их не генерирует.

Логи аутентификации

Логи аутентификации фиксируют каждую попытку входа, успешную или неудачную, и обычно именно там впервые появляются следы атаки. В системах Debian и Ubuntu это /var/log/auth.log; в RHEL, CentOS и похожих дистрибутивах — /var/log/secure.

Важны не просто неудачные попытки входа, а закономерности в них. Несколько неудачных попыток SSH с обычного «домашнего» IP — это фоновый интернет-шум; пять и более неудачных попыток с одного источника за короткое окно времени — уже сигнал, требующий реакции. Практичный подход к обнаружению — отслеживать неудачные попытки входа по исходному IP в скользящем временном окне, например помечать пять неудач за десять минут: этот порог часто используется в материалах по обнаружению брутфорса, поскольку отделяет опечатки от автоматизированных инструментов атаки. Такие инструменты, как fail2ban, напрямую следят за этими логами и автоматически добавляют правила межсетевого экрана для блокировки нарушающих IP при превышении порога, превращая пассивные данные логов в активную защиту. Наше руководство по настройке fail2ban рассказывает, как настроить это с нуля, включая тонкую настройку jail, чтобы блокировать реальных атакующих, не блокируя легитимных пользователей с общими или динамическими IP.

Помимо брутфорса, обращайте особое внимание на: успешные входы в необычное для данной учётной записи время, входы под учётными записями, которые никогда не должны использоваться интерактивно (сервисные аккаунты), и любое использование sudo или su, не соответствующее обычной админской активности вашей команды. Это менее частые, но более информативные события, чем простой подсчёт неудачных попыток.

Логи веб-сервера

Access- и error-логи веб-сервера фиксируют каждый запрос, который получают ваши публичные сервисы, и их анализ на предмет аномальных шаблонов запросов, всплесков ошибок и известных сигнатур атак — это способ обнаружить атаки на уровне веб-приложения, которые вообще не затрагивают SSH. Это отдельный источник данных, не связанный с логами аутентификации, и он охватывает совершенно другую поверхность атаки.

Обращайте внимание на повторяющиеся запросы к несуществующим на вашем сайте путям (признак автоматизированного сканирования уязвимостей), внезапные всплески кодов статуса 4xx или 5xx, необычно большое число запросов с одного IP или user agent, а также запросы с явными признаками инъекций в строке запроса. Добавление $request_time в формат логов nginx, наряду со стандартными полями, помогает, поскольку показывает время обработки каждого запроса, а поток запросов, каждый из которых дёшев, но которых очень много, может быть попыткой исчерпания ресурсов, даже если ни один отдельный запрос не выглядит вредоносным. Наше руководство по лучшим практикам безопасности nginx рассказывает, как настроить ориентированный на безопасность формат логов и ограничивать частоту запросов к этим эндпоинтам прямо на уровне веб-сервера.

Анализатор логов, такой как GoAccess, может превратить необработанные access-логи в дашборд в реальном времени, что значительно облегчает визуальное обнаружение аномалий по сравнению с прокруткой сырого текста, особенно в сочетании с базой GeoIP, показывающей, из каких стран реально приходит трафик и попытки атак.

Использование ресурсов

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

Аномалии использования ресурсов важны для безопасности, поскольку некоторые типы атак проявляются здесь раньше, чем где-либо ещё: майнинговое ПО вызывает устойчивую нагрузку на CPU, скомпрометированный сервер, используемый для рассылки спама или участия в DDoS-ботнете, вызывает необычный исходящий сетевой трафик, а атака с внедрением в логи или заполнением диска проявляется как быстрый рост использования диска. Для ручной проверки достаточно базовых инструментов вроде top, htop, vmstat и iftop; для постоянного мониторинга даже простой скрипт по расписанию, который записывает эти метрики и оповещает при превышении порогов, покрывает большую часть важного без необходимости полноценной платформы мониторинга.

Ключевая практика — сравнение с базовой картиной именно вашего сервера, а не с общим порогом. Сервер базы данных, легитимно работающий с загрузкой CPU 70% в рабочие часы, — это нормально; та же нагрузка на сервере, который обычно простаивает в это время, заслуживает внимания.

Прослушиваемые порты и сетевые соединения

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

Периодически выполняйте ss -tulpn (или netstat -tulpn в более старых системах) и сравнивайте вывод с тем, что вы ожидаете увидеть запущенным. Новый прослушиваемый порт, который вы не открывали, особенно с высоким или необычным номером, — один из наиболее надёжных индикаторов компрометации сервера, поскольку атакующие часто устанавливают слушатель-бэкдор для постоянного удалённого доступа. Эта проверка занимает меньше минуты и выявляет категорию компрометации, которую логи аутентификации и веб-сервера вообще не покажут.

Дополняйте это проверкой активных исходящих соединений, а не только прослушиваемых портов: скомпрометированный сервер, регулярно обращающийся к незнакомому внешнему IP через определённые интервалы, — классический признак связи с командным сервером (C2), и это вообще не отразится в логах аутентификации или веб-сервера.

Мониторинг целостности файлов

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

AIDE (Advanced Intrusion Detection Environment) — стандартный open-source инструмент FIM для Linux, выступающий бесплатной альтернативой более старому коммерческому продукту Tripwire. Он работает, сканируя указанные пути — обычно /etc, /bin, /sbin, /usr/bin и другие системные каталоги с бинарными файлами и конфигурацией, — и при каждом запуске сравнивает текущие атрибуты файлов с сохранённой базовой базой данных:

# Initialize the baseline (once, on a known-clean system)
aideinit

# Run a check against the baseline
aide --check --config=/etc/aide/aide.conf

Настройте это как регулярное задание cron или таймер systemd, чтобы проверки выполнялись автоматически, и направляйте вывод туда, где вы его реально увидите, поскольку отчёт FIM, который никто не читает, приносит ту же пользу, что и отсутствие мониторинга вообще. Когда вы намеренно обновляете системные пакеты, после этого пересоздавайте базовую базу, чтобы плановое обновление не генерировало постоянные ложные срабатывания; баланс между обнаружением реальных изменений и утоплением в ожидаемых — основная постоянная задача обслуживания инструментов FIM.

Отделение сигнала от шума

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

Практичный подход — разделить события на три уровня. Первый — немедленные оповещения по редким индикаторам с высокой степенью достоверности: новый прослушиваемый порт, новый SSH-ключ, добавленный в authorized_keys, вход root с незнакомого местоположения, оповещение FIM по ключевому системному бинарному файлу. Второй — ежедневная или еженедельная сводка по повышенным, но частым событиям: агрегированное число неудачных входов, необычные, но не экстремальные шаблоны трафика, растущее использование диска. Третий — хранение сырых логов без активных оповещений для рутинного, ожидаемого объёма, предназначенного для расследования постфактум, а не для постоянного просмотра.

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

Централизованный и коррелированный анализ логов

Централизация логов из нескольких источников в одном месте с возможностью поиска и корреляция событий между этими источниками позволяют выявить шаблоны атак, которые не раскроет ни один отдельный лог-файл сам по себе; это ключевая идея подхода SIEM (Security Information and Event Management), актуальная даже для организаций, слишком небольших для запуска полноценной SIEM-платформы.

Это различие имеет практическое значение. Базовое управление логами централизует и хранит данные логов, что является реальным улучшением по сравнению с логами, разбросанными по отдельным серверам с коротким локальным сроком хранения, но остаётся во многом пассивным: вам всё равно нужно знать, что именно искать. Система SIEM добавляет корреляцию в реальном времени и оповещения на основе правил по совокупности источников, поэтому она может связать такой шаблон, как «неудачные попытки входа по SSH с IP X, а спустя двадцать минут — новое исходящее соединение с того же сервера», в единый помеченный инцидент, тогда как каждая отдельная строка лога, рассмотренная изолированно, может не выглядеть достаточно срочной для расследования. Согласно отраслевым рекомендациям по SIEM для малого и среднего бизнеса, полноценное внедрение SIEM часто требует выделенного персонала и может создавать более тяжёлую операционную нагрузку, чем способна выдержать небольшая организация, тогда как решение для управления логами, дополненное базовыми функциями корреляции в стиле SIEM, способно дать значительную часть практической пользы без такой нагрузки.

Для большинства малых компаний реалистичный путь — не «купить SIEM», а «обеспечить, чтобы логи с каждого сервера и с каждого сервиса на этих серверах попадали в одно место, где реально может происходить корреляция и оповещение», будь то лёгкий самостоятельно размещённый стек или управляемый сервис мониторинга. Альтернатива — логи, локально лежащие на каждом сервере без перекрёстных ссылок, — означает, что атакующий, закрепившийся в одной системе и перешедший в другую, оставляет след, который существует, но который никто не в состоянии вовремя сопоставить, чтобы это имело значение.

Если мониторинг показывает, что инцидент уже произошёл, а не всё ещё разворачивается, процесс реагирования важен не меньше, чем само обнаружение; о том, что делать после подтверждения компрометации, читайте в нашем руководстве по реагированию на инциденты при взломе сервера. А если вы выстраиваете мониторинг как часть более широких мер по усилению защиты, чек-лист безопасности VPS рассказывает, как анализ логов вписывается в общую картину наряду с правилами межсетевого экрана, усилением защиты SSH и патчингом.