Анализ артефактов Linux

Этот урок — карта артефактов Linux: логи, история команд и планировщики, где живут следы инцидента.

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

Linux-серверы — частая цель атак, и они логируют многое. Преимущество для криминалиста — прозрачность: логи в основном текстовые, структура понятна. Разберём, куда смотреть. Как и в случае Windows, всё это делают на своей или корпоративной системе с правом доступа либо на учебном образе, по копии read-only, фиксируя хеши и документируя действия — иначе анализ не имеет юридической силы и сам может нарушить закон.

Логи /var/log

Главная сокровищница — каталог /var/log:

Например, неуспешные SSH-входы (брутфорс) видно так:

# Поиск неудачных входов по SSH
grep "Failed password" /var/log/auth.log

# Кто и когда повышал привилегии через sudo
grep "sudo" /var/log/auth.log | grep "COMMAND"

Помимо названных файлов полезны wtmp, btmp и lastlog — бинарные журналы входов, которые читают командами last, lastb и lastlog. Они показывают успешные и неуспешные сессии с адресами и временем — удобно для подтверждения того, что нашли в auth.log. Веб-серверы добавляют /var/log/nginx или /var/log/apache2: по их access-логам нередко виден первичный вектор — эксплойт уязвимости, заливка веб-шелла, подозрительный User-Agent или POST к странному скрипту.

История команд: bash_history

Файл ~/.bash_history хранит команды пользователя. При расследовании это прямой след действий: какие утилиты запускались, что скачивалось, какие файлы создавались. Важно: историю легко очистить или подделать, поэтому её сопоставляют с логами и временами файлов.

# Просмотр истории команд пользователя
cat /home/user/.bash_history

# Бывает информативно искать загрузки и доступ
grep -E "wget|curl|nc|chmod \+x" /home/user/.bash_history

Стоит помнить про детали поведения. Команды попадают в файл обычно при выходе из сессии, поэтому в активной (или резко оборванной) сессии их там может ещё не быть — зато они могут жить в памяти процесса bash, что возвращает нас к форензике RAM. По умолчанию история не хранит времени; но если задана переменная HISTTIMEFORMAT, рядом с командами появляются временные метки. Не забывайте проверять историю всех пользователей, включая root, а также истории других оболочек (.zsh_history) и интерпретаторов (Python, MySQL). Часто именно в истории видна вся «механика» компрометации: загрузка нагрузки через wget, выдача прав на исполнение через chmod +x, запуск, а затем попытка замести следы через history -c и удаление файлов — и эта попытка очистки сама по себе становится уликой намерения.

Планировщики: cron и systemd

Злоумышленники часто закрепляются через автозапуск. В Linux это задания cron (/etc/crontab, /var/spool/cron) и сервисы/таймеры systemd. Подозрительная запись в cron, запускающая скрипт из /tmp, — классическая закладка. Кроме cron и systemd-юнитов смотрят и другие точки персистентности: автозагружаемые профили оболочки (~/.bashrc, /etc/profile.d), добавленные ключи в ~/.ssh/authorized_keys, новые или изменённые учётные записи в /etc/passwd и /etc/shadow, а также подозрительные SUID-бинарники. Это типовой чек-лист «где мог окопаться нарушитель».

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

Логи пишет демон журналирования (rsyslog или journald). В современных дистрибутивах часть логов — бинарный journal (journalctl), часть — текст. Анализируют их на смонтированном RO-образе, обращая внимание на пробелы и обрывы: если в логах внезапная «дыра», возможно, их чистили (анти-форензика).

Точка входа (SSH brute) -> auth.log: Failed/Accepted
        |
  закрепление -> cron/systemd: подозрит. задание
        |
  действия -> bash_history: wget, chmod +x, ./malware
        |
  сводим всё в таймлайн

Полезно знать, что journald хранит данные в индексированном бинарном формате со встроенной (нестрогой) защитой целостности: грубое редактирование журнала ломает его структуру, и journalctl --verify это заметит. Поэтому продвинутые атакующие чаще удаляют отдельные файлы целиком или вычищают строки в текстовых логах — и тогда улика не в самих записях, а в их отсутствии: пропавший интервал времени или несоответствие между wtmp и auth.log.

Файловая система как улика

Логи и история — не единственные источники. Сама файловая система рассказывает многое. Команды поиска по времени изменения (find / -newermt) позволяют выделить файлы, появившиеся или изменённые в окно инцидента, — так находят сброшенные злоумышленником бинарники и веб-шеллы. Каталоги /tmp, /dev/shm и домашние папки сервисных учёток — типичные места, куда складывают нагрузку, рассчитывая, что туда редко заглядывают. Открытые, но уже удалённые файлы видны через /proc: процесс может работать из файла, которого формально на диске нет, и его содержимое восстанавливают прямо из /proc/PID/exe и /proc/PID/maps на живой системе.

# Файлы, изменённые за последние сутки
find / -xdev -newermt "-1 day" -type f 2>/dev/null

# Подозрительные исполняемые во временных каталогах
find /tmp /dev/shm -type f -perm -u+x 2>/dev/null

Отдельная ценность — метаданные inode: время изменения метаданных (ctime) трудно подделать обычными средствами, в отличие от mtime/atime, которые меняются командой touch. Если mtime файла «отмотан» в прошлое, а ctime указывает на недавнее время, это прямой признак того, что метку правили, — линукс-аналог timestomping из первого урока. Поэтому и здесь работает главное правило форензики: ни один источник не абсолютен, выводы строят на пересечении логов, истории, файловой системы и времён, а исследование ведут по копии read-only в правовой рамке.

Частые ошибки

• Доверять bash_history безоговорочно. Её легко очистить (history -c) или отключить; сверяют с логами.
• Забыть journald. Часть событий только в бинарном журнале (journalctl).
• Не проверить cron и systemd. Там частые механизмы закрепления.
• Игнорировать обрывы в логах. «Дыра» во времени — признак чистки.
• Смотреть историю только одного пользователя. Проверяют всех, включая root, и другие оболочки.

Итоги

• Главные источники: /var/log (auth, syslog, cron, веб-логи), wtmp/btmp, ~/.bash_history, задания cron и systemd, точки персистентности (authorized_keys, passwd, .bashrc).
• Логи в основном текстовые — удобно искать grep; часть — в journald, где помогает journalctl --verify.
• bash_history легко подделать, поэтому всё сопоставляют между источниками и сводят в таймлайн, работая по копии в правовой рамке.