Артефакты Linux

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

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

Этот разбор — про легальную работу: анализ собственного сервера, разрешённого образа диска или учебного стенда (например, виртуальной машины TryHackMe). Реконструкция событий нужна не для атаки, а чтобы понять, как развивался инцидент, и закрыть дыру. Несанкционированный доступ к чужим системам наказуем (в РФ — ст. 272 УК РФ), поэтому всё ниже применяйте только к тому, что вам разрешено исследовать.

Зачем это знать защитнику

Когда сервер вёл себя странно, защитник не верит догадкам — он идёт к артефактам. Логи показывают неудачные входы и эскалацию прав, история команд — что именно набирал пользователь, cron и systemd — закрепился ли злоумышленник в системе. Без знания этих мест расследование превращается в гадание, а скрытая персистентность остаётся незамеченной и хост компрометируется снова после «очистки».

Системные логи: /var/log и journald

Исторически Linux пишет текстовые логи в каталог /var/log. Ключевые файлы: auth.log (в Debian/Ubuntu) или secure (в RHEL/CentOS) — аутентификация, sudo, SSH; syslog/messages — общесистемные события; dmesg — сообщения ядра. Запись о неуспешном входе по SSH выглядит так:

Failed password for invalid user admin from 203.0.113.10 port 51244 ssh2
Accepted publickey for deploy from 198.51.100.5 port 41888 ssh2

На современных системах с systemd центральный журнал ведёт journald в бинарном формате (/var/log/journal/). Читают его утилитой journalctl: следователь фильтрует по времени и службе, не открывая файл «глазами».

# Все события с момента загрузки
journalctl -b

# Только сообщения службы ssh за окно времени
journalctl -u ssh --since "2026-06-20 00:00" --until "2026-06-21 00:00"

# Приоритет «ошибка» и выше
journalctl -p err -b

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

История команд и сессии пользователя

Оболочка bash хранит набранные команды в ~/.bash_history у каждого пользователя (zsh — в ~/.zsh_history). Это один из самых ценных артефактов: он буквально показывает действия. Но относиться к нему надо критически — файл пишется только при корректном завершении сессии, легко редактируется, а переменная HISTFILE может быть отключена. Отсутствие истории — само по себе сигнал.

Кто и когда входил, показывают бинарные журналы учёта: wtmp (входы/выходы), btmp (неудачные попытки), lastlog (последний вход). Их читают штатными утилитами:

# Журнал входов/выходов
last -f /var/log/wtmp

# Неудачные попытки входа
lastb

# Когда каждый пользователь заходил в последний раз
lastlog

cron и systemd как точки персистентности

Злоумышленник, получивший доступ, стремится закрепиться, чтобы пережить перезагрузку. Классические места — планировщик cron и юниты systemd. Следователь обязательно проверяет:

/etc/crontab, каталоги /etc/cron.d/, /etc/cron.daily/ и пользовательские таблицы crontab -l -u имя;
юниты и таймеры systemd в /etc/systemd/system/ и ~/.config/systemd/user/ — подозрительный .service, запускающий скрипт из /tmp, это красный флаг;
файлы автозапуска оболочки: ~/.bashrc, ~/.profile, /etc/profile.d/.

# Активные таймеры systemd
systemctl list-timers --all

# Юниты, добавленные не пакетным менеджером, видны по пути и дате
ls -lat /etc/systemd/system/

/etc и учётные записи

Каталог /etc — это конфигурация всей системы, и здесь следователь ищет следы манипуляций с доступом. Файл /etc/passwd перечисляет учётные записи (хэши паролей лежат в /etc/shadow). Тревожные признаки: лишний пользователь с UID 0 (равноценен root), сервисная учётка с оболочкой /bin/bash вместо /usr/sbin/nologin, недавно изменённый /etc/sudoers или подкаталог /etc/sudoers.d/, добавленные ключи в ~/.ssh/authorized_keys.

# Подозрительно: вторая запись с UID 0
root:x:0:0:root:/root:/bin/bash
backup:x:0:0:backup:/home/backup:/bin/bash

Как это работает под капотом

Большинство артефактов опираются на метаданные файловой системы. Время изменения логов, владелец cron-файла, дата создания юнита — всё это атрибуты inode (подробно в следующем уроке). Поэтому золотое правило: исследуют не «живую» систему, а её образ, смонтированный только для чтения, иначе сам факт открытия файла обновит метки времени и исказит картину. Бинарные журналы (journald, wtmp) — это структурированные записи фиксированного формата, и их можно разбирать офлайн специализированными парсерами, не доверяя командам потенциально скомпрометированного хоста.

Как защититься

Те же знания работают на оборону:

Централизуйте логи. Пересылайте journald/syslog на отдельный защищённый сервер или в SIEM — тогда злоумышленник не сможет «почистить» /var/log локально.
Защитите от изменения. Атрибут chattr +a на лог-файлах разрешает только дозапись; auditd фиксирует доступ к чувствительным файлам.
Мониторьте персистентность. Регулярно сверяйте список cron-задач и systemd-юнитов с эталоном; алертите на новые записи с UID 0 в /etc/passwd.
Синхронизируйте время. Корректный NTP делает временную шкалу в логах доверенной — критично для таймлайна расследования.

Итоги

Текстовые логи живут в /var/log (auth.log/secure, syslog), а бинарный журнал systemd читают через journalctl.
История команд (~/.bash_history) и журналы учёта (wtmp/btmp/lastlog) показывают действия и входы, но их легко подделать — отсутствие данных тоже улика.
Персистентность ищут в cron, systemd-юнитах и файлах автозапуска оболочки.
/etc/passwd, sudoers и authorized_keys выдают манипуляции с учётными записями.
Анализируют образ только для чтения; защита — централизация логов, неизменяемость и мониторинг точек автозапуска.