— Практическое руководство для начинающих специалистов Blue Team: проверяем процессы, службы systemd, сетевые соединения и задания cron без установки дополнительных инструментов.

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

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

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

• Какой процесс выполняется и от имени какого пользователя?

• С какими адресами и портами он взаимодействует?

• Почему программа запускается автоматически?

Разберём базовый подход к такой проверке на Linux. Все команды предназначены для диагностики системы, к которой у вас есть разрешённый административный доступ.

1. Начинаем с процессов

Процесс — это выполняющийся экземпляр программы. В Linux каждому процессу присваивается PID — идентификатор, который помогает исследовать его состояние.

Для просмотра процессов вместе с пользователями и потреблением ресурсов можно выполнить:

ps aux --sort=-%cpu | head -20

Команда выведет двадцать первых строк после сортировки по использованию процессора.

Чтобы посмотреть процессы, которые потребляют больше всего оперативной памяти:

ps aux --sort=-%mem | head -20

Для интерактивного наблюдения подойдёт:

top

Если установлен htop, можно использовать и его.

Что выглядит подозрительно?

Допустим, среди процессов обнаружена следующая условная запись:

USER      PID  %CPU %MEM COMMAND
root     1842  72.4  8.1 /opt/unknown/worker
www-data 1921   3.2  1.4 nginx: worker process
postgres 2034   1.8  4.2 postgres

Высокая нагрузка у /opt/unknown/worker — повод проверить процесс, но не доказательство вредоносной активности.

Важнее выяснить:

• Кто запустил процесс?

• Относится ли программа к установленному приложению?

• Почему она потребляет столько ресурсов?

• Когда она появилась?

• Какая служба или родительский процесс её запустил?

Начать проверку конкретного процесса можно так:

ps -p 1842 -o pid,ppid,user,lstart,etime,cmd

Здесь отображаются PID, PPID (идентификатор родительского процесса), пользователь, время запуска, длительность работы и командная строка.

Если процесс уже завершился, команда может ничего не показать. Это нормально: PID не гарантирует, что процесс продолжает существовать.

2. Проверяем, какой файл выполняется

Название процесса не всегда соответствует имени файла. Поэтому полезно проверить путь к исполняемому файлу.

Для процесса с PID 1842:

readlink -f /proc/1842/exe

Посмотреть командную строку процесса можно командой:

ps -p 1842 -o args=

А информацию о пользователе и родительском процессе — так:

ps -p 1842 -o pid,ppid,user,group,cmd

Путь /proc/PID/ представляет информацию о процессе, пока он существует.

Почему путь имеет значение

Допустим, системная служба должна запускать приложение из /usr/bin/, но фактически запускается файл из неожиданного каталога пользовательского профиля или временной директории.

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

Полезно также проверить владельца и время изменения файла:

stat /путь/к/файлу

Если программа относится к установленному пакету, можно проверить её происхождение средствами пакетного менеджера. В Debian и Ubuntu, например:

dpkg -S /usr/bin/имя-программы

Команда покажет пакет, которому принадлежит файл, если он известен базе пакетного менеджера.

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

3. Изучаем сетевые соединения

Процесс может запускать локальную службу, подключаться к API, обращаться к базе данных или обмениваться данными с удалённым сервером.

Чтобы увидеть слушающие TCP‑ и UDP‑сокеты, можно использовать:

sudo ss -lntup

Для просмотра текущих TCP‑соединений:

sudo ss -tnp

В выводе ss можно увидеть локальные и удалённые адреса, порты, состояние соединения, а при наличии необходимых прав — сведения о процессе.

Для более подробного исследования открытых сетевых файлов можно использовать lsof, если он установлен:

sudo lsof -i

Как интерпретировать результат

Предположим, вы видите:

State       Local Address:Port   Peer Address:Port
LISTEN      0.0.0.0:22            0.0.0.0:*
LISTEN      127.0.0.1:5432        0.0.0.0:*
ESTAB       192.0.2.10:43120      198.51.100.20:443

Это иллюстративный пример. Адреса из диапазонов 192.0.2.0/24 и 198.51.100.0/24 зарезервированы для документации.

• LISTEN означает, что сокет ожидает входящих подключений.

• ESTAB обозначает установленное TCP‑соединение.

• Порт 22 часто используется SSH.

• Порт 5432 часто используется PostgreSQL.

• Порт 443 обычно используется HTTPS.

Но номер порта сам по себе не определяет назначение программы. Сервис может работать на нестандартном порту, а популярный порт может использоваться совсем другим приложением.

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

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

4. Проверяем службы systemd

Многие процессы Linux запускаются и контролируются через systemd. Служба может стартовать автоматически при загрузке системы, перезапускаться после сбоя или запускаться по запросу другой службы.

Список работающих служб:

systemctl list-units --type=service --state=running

Список установленных файлов служб:

systemctl list-unit-files --type=service

Список служб, которые завершились с ошибкой:

systemctl --failed

Если встретилась неизвестная служба, сначала стоит изучить её состояние:

systemctl status имя-службы

Затем посмотреть её конфигурацию:

systemctl cat имя-службы

В файле конфигурации особенно важен параметр ExecStart: он указывает, какую команду systemd запускает для этой службы.

На что обратить внимание

Проверяйте не только название службы, но и:

• путь к исполняемому файлу;

• пользователя, от имени которого работает процесс;

• дату появления или изменения конфигурации;

• описание службы и её назначение;

• наличие похожих служб на других аналогичных серверах;

• соответствие конфигурации документации проекта.

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

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

5. Ищем задания cron и таймеры systemd

Иногда процесс запускается не постоянно, а по расписанию. Например, раз в час выполняется резервное копирование, обновляется статистика или запускается задача обслуживания.

За расписание могут отвечать cron и таймеры systemd.

Посмотреть задания текущего пользователя:

crontab -l

Системные расписания можно проверить в стандартных местах:

ls -la /etc/cron.d/
ls -la /etc/cron.hourly/
ls -la /etc/cron.daily/

Список таймеров systemd:

systemctl list-timers --all

Если обнаружено незнакомое задание, выясните, какую команду оно запускает, кому принадлежит файл и соответствует ли задание назначению системы.

Для просмотра сведений о файле используйте:

stat /путь/к/файлу

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

Как отличить нормальную задачу от подозрительной

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

Проверьте:

1. Есть ли задача в документации системы?

2. Кто её создал и кто владеет файлом?

3. Какой исполняемый файл или скрипт вызывается?

4. Совпадает ли расписание с ожидаемым поведением приложения?

5. Есть ли связанные события в журналах?

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

6. Проверяем SSH‑ключи и учётные записи

Доступ к серверу может сохраняться через учётные записи и ключи, поэтому при расследовании полезно проверить и этот аспект.

Список локальных пользователей:

getent passwd

Пользователи с UID 0 — отдельный важный объект проверки, поскольку UID 0 обычно соответствует привилегиям суперпользователя:

awk -F: '$3 == 0 {print $1 ":" $3}' /etc/passwd

В типичной конфигурации ожидается одна учётная запись с UID 0, обычно root. Если их несколько, необходимо выяснить, зачем это сделано.

Для текущего пользователя список авторизованных SSH‑ключей обычно находится в файле:

~/.ssh/authorized_keys

Проверить его наличие и права доступа можно так:

ls -la ~/.ssh/

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

Для полноценного аудита проверьте соответствующие файлы и учётные записи всех пользователей, которым разрешён SSH‑доступ. Учитывайте, что фактическое расположение ключей и правила доступа могут быть изменены в конфигурации SSH.

7. Собираем признаки в единую картину

Главная ошибка при расследовании — делать вывод по одному индикатору.

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

Гораздо полезнее искать связи между событиями.

Например, условная последовательность:

Время

Событие

14:01

В журнале появляется необычный успешный SSH‑вход

14:03

У пользователя фиксируется административное действие

14:05

Обнаруживается новая конфигурация службы

14:06

Запущенный процесс устанавливает неожиданное соединение

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

Сопоставить события можно с помощью системных журналов:

sudo journalctl --since "today"

Для конкретной службы:

sudo journalctl -u имя-службы --since "today"

Если используется централизованная система логирования, сравните локальные события с данными из неё. Локальные журналы могут быть неполными, особенно если у предполагаемого нарушителя были высокие привилегии.

8. Что делать, если подозрения подтвердились

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

Безопасный базовый порядок действий:

1. Зафиксировать время обнаружения и исходные наблюдения.

2. Сохранить относящиеся к делу журналы, конфигурации, сведения о процессах и соединениях.

3. Проверить, затронуты ли другие серверы и учётные записи.

4. Следовать утверждённому плану реагирования и при необходимости ограничить доступ к затронутой системе.

5. После сохранения доказательств устранить причину инцидента и восстановить систему из доверенного состояния, если это необходимо.

6. Проверить, что не осталось неучтённых изменений конфигурации, учётных записей и средств автоматического запуска.

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

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

Вывод

Для первичной проверки Linux‑сервера не всегда нужны сложные инструменты. Команды ps, ss, systemctl, journalctl и stat позволяют начать исследование процессов, сетевых соединений, служб и файлов.

Но главное в работе Blue Team — не просто находить неизвестные элементы, а понимать, что они делают и почему появились.

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

Надёжный вывод строится на совокупности признаков, сравнении с нормальным состоянием системы и сохранении доказательств. Именно такой подход превращает набор команд в осмысленное расследование.

Мы в Telegram: https://t.me/+jAjZcfEdOx42NzRi