Практический разбор для начинающих специалистов Blue Team: где искать следы подозрительной активности, как читать записи SSH и веб-сервера и почему один странный запрос ещё не означает взлом.
Представим ситуацию: на сервере работает сайт, пользователи заходят на него, приложение обрабатывает запросы, а администратор занимается обычными задачами. В какой-то момент нагрузка растёт, в логах появляется множество ошибок, а SSH начинает регистрировать неудачные попытки входа.
Что произошло? Обычный сбой, автоматическое сканирование или кто-то пытается получить доступ к системе?
Без журналов событий ответить на этот вопрос сложно. Но если логи настроены правильно, они могут рассказать довольно много: какие действия выполнялись, когда они происходили, какие ресурсы запрашивались и чем закончились попытки доступа.
В этой статье разберём, как начать расследование подозрительной активности на Linux-сервере без сложных SIEM-систем и дорогостоящих инструментов.
Все IP-адреса и примеры событий в статье учебные. Они не относятся к реальному инциденту.
Какие логи нужны
Логи — это записи о событиях, которые происходят в операционной системе, приложениях и сетевых службах.
Для первичного расследования обычно полезны три источника.
Системные журналы Linux
В них можно искать события служб, ошибки и сообщения операционной системы. На системах с systemd для этого удобно использовать journalctl.
Журналы SSH и аутентификации
Они помогают увидеть успешные и неудачные попытки входа, неизвестные имена пользователей и другие события, связанные с доступом.
Логи веб-сервера и приложения
Они показывают HTTP-запросы, адреса запрашиваемых ресурсов, коды ответа и ошибки приложения.
На Debian и Ubuntu события аутентификации часто находятся в /var/log/auth.log, а на RHEL-подобных системах — в /var/log/secure. Точное расположение зависит от настроек системы.
Чтобы посмотреть события SSH за последний час, можно выполнить:
sudo journalctl -u ssh --since "1 hour ago"
На некоторых дистрибутивах служба называется sshd, поэтому команда будет выглядеть так:
sudo journalctl -u sshd --since "1 hour ago"
А последние записи журнала веб-сервера Nginx можно вывести командой:
sudo tail -n 100 /var/log/nginx/access.log
Если файла нет, стоит проверить конфигурацию Nginx и фактическое расположение журналов.
Неудачные попытки входа по SSH
Рассмотрим условные записи:
Oct 21 10:14:02 server sshd[1842]: Failed password for root from 192.0.2.45 port 50122 ssh2Oct 21 10:14:05 server sshd[1847]: Failed password for invalid user admin from 192.0.2.45 port 50126 ssh2Oct 21 10:14:09 server sshd[1851]: Failed password for invalid user test from 192.0.2.45 port 50131 ssh2Oct 21 10:14:13 server sshd[1858]: Failed password for invalid user deploy from 192.0.2.45 port 50139 ssh2
Что здесь можно заметить?
-
Попытки происходят с небольшими временными интервалами.
-
Используются разные имена пользователей.
-
Все события связаны с неудачной аутентификацией.
-
Источник запросов в этих примерах один и тот же.
Такой рисунок активности может указывать на автоматизированную проверку учётных записей или попытку подбора паролей.
Но важно не торопиться с выводами. Подобные записи могут появляться и из-за ошибочно настроенного автоматического подключения, старого скрипта или легитимного пользователя, который забыл обновить пароль.
Для быстрого поиска похожих событий в обычном текстовом журнале можно использовать:
sudo grep -E "Failed password|Invalid user" /var/log/auth.log
Если используется другая система логирования, путь к файлу нужно заменить соответствующим.
На что смотреть в первую очередь
Частота событий. Несколько неудачных попыток за минуту и сотни попыток за короткое время — разные ситуации.
Разнообразие имён пользователей. Последовательная проверка множества учётных записей может говорить об автоматизации.
Успешный вход после серии ошибок. Это не доказывает компрометацию, но требует дополнительной проверки: кому принадлежит учётная запись и соответствует ли вход обычному поведению пользователя.
Время события. Ночная активность сама по себе не является атакой. Важнее сравнить её с обычным расписанием работы системы и пользователей.
HTTP-запросы: что ищут на веб-сервере
Теперь посмотрим на журнал веб-сервера. Допустим, в нём встречаются следующие строки:
203.0.113.25 - - [21/Oct/2026:10:20:01 +0000] "GET / HTTP/1.1" 200 4210203.0.113.25 - - [21/Oct/2026:10:20:02 +0000] "GET /robots.txt HTTP/1.1" 200 318203.0.113.25 - - [21/Oct/2026:10:20:03 +0000] "GET /admin HTTP/1.1" 404 162203.0.113.25 - - [21/Oct/2026:10:20:04 +0000] "GET /backup.zip HTTP/1.1" 404 162203.0.113.25 - - [21/Oct/2026:10:20:05 +0000] "GET /.env HTTP/1.1" 404 162
Здесь используются адреса из диапазона, предназначенного для документационных примеров.
Что показывает журнал?
-
GET /— запрос главной страницы. -
GET /robots.txt— запрос файла с правилами для поисковых роботов. -
GET /admin— проверка наличия административного пути. -
GET /backup.zip— запрос возможного архива резервной копии. -
GET /.env— запрос файла конфигурации, который в некоторых проектах может содержать секреты.
Коды 200 и 404 показывают разные результаты обработки запросов: в первом случае сервер вернул успешный ответ, во втором — сообщил, что ресурс не найден. Однако сам по себе код ответа не всегда раскрывает полную картину: например, приложение может возвращать страницу с кодом 200, даже если нужный ресурс отсутствует.
Последовательная проверка множества типичных путей может указывать на автоматическое сканирование сайта. Но одиночный запрос к /admin не доказывает, что кто-то атакует сервер: этот адрес могут проверять легитимные пользователи, поисковые системы или системы мониторинга.
Главный принцип: анализировать нужно последовательность событий, контекст и результат, а не отдельную строку.
Как быстро найти наиболее активные IP-адреса
Когда журнал содержит тысячи строк, вручную просматривать его неудобно. Можно начать с простого подсчёта адресов в стандартном access log Nginx:
sudo awk '{print $1}' /var/log/nginx/access.log \ | sort \ | uniq -c \ | sort -nr \ | head -20
Команда выполняет несколько действий:
-
Извлекает первый столбец каждой строки — обычно это адрес клиента.
-
Сортирует значения, чтобы одинаковые адреса оказались рядом.
-
Подсчитывает количество повторений.
-
Сортирует результат по убыванию.
-
Выводит первые двадцать строк.
Пример результата:
842 203.0.113.25516 198.51.100.18203 192.0.2.45
Это не готовый список злоумышленников. Большое количество запросов может объясняться популярностью страницы, работой API, поисковым роботом, балансировщиком нагрузки или NAT, за которым находится много пользователей.
Кроме того, в стандартной конфигурации перед сервером может стоять обратный прокси. Тогда первый столбец будет содержать адрес прокси, а не исходного клиента. Заголовки вроде X-Forwarded-For нельзя считать достоверными без корректной настройки доверенных прокси.
Поэтому результат команды — только отправная точка для дальнейшего анализа.
Какие события стоит записывать в приложении
Системных логов и access log веб-сервера часто недостаточно. Они могут показывать, что запрос пришёл и какой код ответа был отправлен, но не всегда объясняют, почему приложение разрешило или запретило действие.
Например, веб-сервер может зарегистрировать запрос к API, однако только само приложение знает, какой пользователь был авторизован, какие права проверялись и почему операция завершилась ошибкой.
Для событий безопасности полезно сохранять:
-
дату и время;
-
тип события;
-
идентификатор пользователя или субъекта, если он известен;
-
действие и целевой ресурс;
-
результат операции;
-
причину отказа, если она доступна;
-
идентификатор запроса для сопоставления записей из разных компонентов.
Пример структурированного события в формате JSON:
{ "timestamp": "2026-10-21T10:25:30Z", "event": "authorization_denied", "request_id": "req-example-1042", "user_id": "user-123", "resource": "/api/admin/settings", "result": "denied", "reason": "insufficient_permissions"}
Это иллюстрация структуры записи, а не реальный лог приложения.
Подобный формат удобнее анализировать автоматически: поля имеют предсказуемые названия, а события можно фильтровать и сопоставлять между собой.
В рекомендациях OWASP по журналированию отдельно отмечается важность регистрации успешной и неуспешной аутентификации, отказов в контроле доступа, ошибок проверки входных данных и административных действий. https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
Чего в логах быть не должно
Логи тоже могут стать источником утечки. Не стоит записывать в открытом виде:
-
пароли;
-
токены доступа и секреты сессий;
-
приватные ключи;
-
строки подключения к базам данных с паролями;
-
ненужные персональные данные.
Также важно ограничивать доступ к журналам, защищать их от изменения и удаления, настраивать ротацию и следить за заполнением диска.
Ещё один нюанс — недоверенные данные. Пользователь может передать в поле ввода специальные символы или текст, который испортит структуру журнала. Поэтому значения нужно безопасно кодировать и обрабатывать перед записью, чтобы снизить риск log injection.
Почему логи не дают полной картины
Даже хорошо настроенные журналы не показывают абсолютно всё.
Часть событий может не записываться. Если логирование отключено или приложение не фиксирует определённый тип ошибок, расследователь не увидит этих событий.
Время может отличаться. Если часы серверов не синхронизированы, порядок событий между компонентами будет сложнее восстановить.
Адрес источника не всегда идентифицирует человека. За одним IP могут находиться десятки или сотни пользователей. Адрес также может принадлежать VPN, прокси, облачному сервису или NAT.
Один запрос не равен атаке. Проверка известного пути, ошибка авторизации или необычный User-Agent могут встречаться и в обычной работе.
Журналы могут быть изменены или удалены. Если злоумышленник получил высокие привилегии на сервере, локальные логи не обязательно останутся надёжным источником доказательств.
Поэтому в более зрелой инфраструктуре события отправляют на отдельный сервер логирования или в SIEM. Доступ к хранилищу ограничивают, события связывают идентификаторами запросов, а критичные изменения и отключение логирования отслеживают отдельно.
7. Минимальный план расследования подозрительной активности
Если в журналах обнаружена необычная последовательность событий, не стоит сразу блокировать всё подряд. Сначала нужно сохранить контекст и проверить гипотезу.
Практический порядок действий:
-
Зафиксировать временной диапазон. Записать, когда начались подозрительные события и когда они закончились.
-
Сохранить относящиеся к делу журналы. По возможности сохранить исходные файлы, время получения и сведения о системе, не редактируя оригиналы.
-
Сопоставить источники. Проверить события SSH, веб-сервера, приложения и системные журналы за один и тот же период.
-
Проверить успешные действия. После серии отказов выяснить, были ли успешные входы, изменения прав, конфигурации или учётных записей.
-
Сравнить с нормальной активностью. Учесть мониторинг, резервное копирование, плановые задания и известные интеграции.
-
Оценить влияние. Проверить, затронуты ли учётные записи, данные, сервисы или настройки системы.
-
Принять меры по результатам. Если есть признаки компрометации, действовать по плану реагирования: ограничить доступ, сохранить доказательства, устранить причину и проверить восстановление.
В рабочей среде такие действия должны соответствовать внутренним процедурам реагирования и полномочиям специалиста.
Вывод
Серверные логи — один из базовых инструментов Blue Team. Они помогают заметить массовые неудачные входы, автоматизированное сканирование веб-путей, ошибки приложения и подозрительные изменения в системе.
Но эффективность логирования определяется не количеством строк, а их качеством: события должны содержать полезный контекст, иметь согласованные временные метки, храниться безопасно и анализироваться вместе с другими источниками данных.
Начать можно с простых команд journalctl, grep, awk и sort. Следующий шаг — централизованное хранение, правила обнаружения и оповещения, которые помогают отличать обычные ошибки от событий, действительно требующих расследования.
Для дальнейшего изучения стоит обратиться к официальному руководству OWASP по логированию и мониторингу безопасности.
Мы в Telegram: https://t.me/+jAjZcfEdOx42NzRi
ссылка на оригинал статьи https://habr.com/ru/articles/1098060/