Planetahost VPS
Перейти к основному контенту

Сервер помнит всё: аудит действий в Linux

intro-Linux-Audit-Actions-planetahost.png

Введение

Представьте ситуацию. На сервере работало несколько администраторов. Утром оказывается, что:

  • пропал важный файл;

  • изменился конфигурационный файл;

  • перестал запускаться сервис;

  • появились неизвестные пользователи;

  • кто-то выполнил опасную команду.

Первый вопрос, который возникает:

Кто это сделал?

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

  • выполняемые команды;

  • время запуска;

  • пользователя;

  • изменения файлов;

  • попытки повышения привилегий;

  • использование sudo.

В этой статье рассмотрим два популярных инструмента:

  • auditd - встроенная система аудита Linux;

  • tlog - запись пользовательских терминальных сессий.

Зачем нужен аудит действий пользователей

Чаще всего аудит используется для:

  • расследования инцидентов;

  • контроля работы администраторов;

  • поиска причин ошибок;

  • выполнения требований информационной безопасности;

  • анализа подозрительной активности.

Например, если кто-то выполнил:

rm -rf /var/www/site

или:

systemctl stop nginx

вы сможете узнать:

  • кто это сделал;

  • когда это произошло;

  • с какого пользователя была выполнена команда.

Работа с auditd

Что такое auditd

auditd - это встроенная подсистема аудита Linux. Она работает на уровне ядра и способна регистрировать:

  • запуск программ;

  • изменения файлов;

  • использование системных вызовов;

  • попытки доступа к файлам;

  • изменение учётных записей;

  • использование sudo.

Фактически auditd может превратить Linux в систему "видеонаблюдения" за действиями пользователей.

Установка auditd

Debian и Ubuntu:

apt update
apt install auditd audispd-plugins

RHEL:

yum install audit

Проверяем состояние:

systemctl status auditd

Запуск:

systemctl enable --now auditd

изображение.png

Проверяем работу аудита

Посмотрим текущие правила:

auditctl -l

изображение.png

Если список пустой, то это нормально. По умолчанию аудит ещё ничего не отслеживает.

Логирование выполнения команд

Добавим правило:

auditctl -a exit,always -F arch=b64 -S execve

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

Например:

ls
cat /etc/passwd
systemctl restart nginx

После этого информация появится в журналах auditd.

Просмотр событий

Используем:

ausearch -m EXECVE

Пример вывода:

type=EXECVE
argc=2
a0="systemctl"
a1="restart"

изображение.png

Из записи видно, какая команда была выполнена.

Поиск действий конкретного пользователя

Например:

ausearch -ua 1000

где:

1000

идентификатор пользователя.

изображение.png

Посмотреть UID можно:

id username
Узнаём, кто использовал sudo

Поиск:

ausearch -m USER_CMD

или:

ausearch -m USER_AUTH

изображение.png

Это позволяет расследовать случаи повышения привилегий.

Отслеживание изменений файла

Допустим, нужно контролировать:

/etc/nginx/nginx.conf

Добавляем правило:

auditctl -w /etc/nginx/nginx.conf -p wa

Где:

  • w - запись;

  • a - изменение атрибутов.

Теперь любое изменение файла попадёт в журнал.

Проверяем результат

Открываем файл:

nano /etc/nginx/nginx.conf

После сохранения проверяем:

ausearch -f /etc/nginx/nginx.conf

изображение.png

В журнале будет видно:

  • кто изменил файл;

  • когда;

  • какой процесс выполнял действие.

Контроль каталога

Можно отслеживать не отдельный файл, а целую директорию.

Например:

auditctl -w /var/www

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

Проверить срабатывание можно так:

ausearch -f /var/www/

изображение.png

Разберем подробно каждый параметр на примере 1 записи журнала:

  • time->Fri Jun 12 00:47:02 2026 - дата и время события.
  • audit(1781214422.122:1732) - внутренний идентификатор события auditd.
  • 1732 - номер события в журнале аудита.

Блок PROCTITLE

  • proctitle - команда, которую запускал пользователь, записанная в шестнадцатеричном виде.
  • 6E616E6F00696E6465782E68746D6C - после декодирования соответствует команде nano index.html.

Блок PATH

  • item=0 - первый объект файла в событии.
  • name="index.html" - имя файла, к которому выполнялось обращение.
  • inode=136755 - уникальный идентификатор файла в файловой системе.
  • dev=fe:02 - устройство, на котором расположен файл.
  • mode=0100644 - права доступа файла (644: владелец может читать и записывать, остальные только читать).
  • ouid=0 - UID владельца файла (0 = root).
  • ogid=0 - GID владельца файла (0 = группа root).
  • rdev=00:00 - устройство для специальных файлов, для обычных файлов не используется.
  • nametype=NORMAL - тип объекта, обычный файл.

Блок CWD

  • cwd="/var/www/tex-lab" - текущий рабочий каталог процесса в момент выполнения операции.

Блок SYSCALL

  • arch=c000003e - архитектура системы x86_64.
  • syscall=257 - системный вызов openat(), используемый для открытия файла.
  • success=no - операция завершилась ошибкой.
  • exit=-13 - код ошибки EACCES (Permission denied), доступ запрещён.
  • a0=ffffffffffffff9c - первый аргумент системного вызова openat().
  • a1=5614a88ad3e0 - второй аргумент системного вызова openat().
  • a2=241 - флаги открытия файла.
  • a3=1b6 - режим доступа к файлу.
  • items=1 - в событии фигурирует один файл.

Информация о процессах

  • ppid=506740 - PID родительского процесса.
  • pid=507388 - PID процесса, выполнившего действие.

Информация о пользователе

  • auid=1000 - Audit User ID, пользователь, вошедший в систему.
  • uid=1000 - реальный UID процесса.
  • gid=1000 - реальная группа пользователя.
  • euid=1000 - эффективный UID процесса.
  • suid=1000 - сохранённый UID процесса.
  • fsuid=1000 - UID, используемый для проверки доступа к файлам.
  • egid=1000 - эффективная группа процесса.
  • sgid=1000 - сохранённая группа процесса.
  • fsgid=1000 - группа файловой системы.

Информация о сессии

  • tty=pts1 - терминал, из которого была выполнена команда.
  • ses=2626 - идентификатор пользовательской сессии.

Информация о программе

  • comm="nano" - имя процесса.
  • exe="/usr/bin/nano" - полный путь к исполняемому файлу.

Информация SELinux

  • subj=unconfined - процесс не ограничен специальной политикой SELinux.

Ключ правила

  • key=(null) - правило аудита было создано без ключа (-k).

Что произошло

  • Пользователь с UID 1000(zloi) из терминала pts1 запустил команду nano index.html.
  • Команда была выполнена из каталога /var/www/tex-lab.
  • Редактор попытался открыть файл index.html.
  • Операция завершилась ошибкой Permission denied.
  • Изменение файла выполнено не было из-за недостаточных прав доступа.
Как сделать правила постоянными

Правила, добавленные через auditctl, исчезают после перезагрузки.

Для постоянного хранения используем:

/etc/audit/rules.d/

Например:

nano /etc/audit/rules.d/custom.rules

Добавляем:

-w /etc/passwd -p wa
-w /etc/shadow -p wa

изображение.png

Перезапускаем:

augenrules --load

Теперь программа будет постоянно отслеживать 2 правила:

Правило

-w /etc/passwd -p wa

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

Правило

-w /etc/shadow -p wa

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

Работа с tlog

Что такое tlog

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

Для этого существует tlog. Он записывает:

  • команды;

  • вывод команд;

  • время выполнения;

  • пользователя;

  • терминальную сессию.

Установка tlog

На Debian 13 можно собрать tlog из исходников довольно просто.

Сначала ставим зависимости, которые указаны в проекте:

apt update
apt install -y \
    git gcc make pkg-config \
    autoconf automake libtool \
    libjson-c-dev \
    libsystemd-dev \
    libcurl4-gnutls-dev \
    libutempter-dev

Клонируем репозиторий:

git clone https://github.com/Scribery/tlog.git
cd tlog

Генерируем систему сборки:

autoreconf -i -f

Конфигурируем:

./configure \
    --prefix=/usr \
    --sysconfdir=/etc \
    --localstatedir=/var

Собираем:

make -j$(nproc)

Устанавливаем:

make install

После установки проверь:

which tlog-rec
which tlog-play
which tlog-rec-session

Должно появиться примерно:

/usr/bin/tlog-rec
/usr/bin/tlog-play
/usr/bin/tlog-rec-session

RHEL:

yum install tlog
Что фиксирует tlog

В журнал попадают:

  • введённые команды;

  • время выполнения;

  • пользователь;

  • имя хоста;

  • вывод команд;

  • действия в интерактивной оболочке.

Например, если пользователь выполнил:

rm important_file.txt

или:

nano nginx.conf

это действие будет присутствовать в записи терминальной сессии.

Настраиваем запись SSH-сессий через tlog

После установки необходимо настроить запись пользовательских сессий. В большинстве современных дистрибутивов достаточно включить запись через SSSD или PAM.

Проверяем наличие конфигурации:

ls /etc/tlog/

Обычно используется файл:

/etc/tlog/tlog-rec-session.conf

Простейшая конфигурация:

{
  "shell": "/bin/bash",
  "notice": "Session is being recorded"
}

изображение.png

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

Проверяем запись

Подключаемся по SSH:

ssh user@server

Выполняем несколько команд:

pwd
ls -la
cat /etc/os-release
systemctl status nginx

Затем завершаем сеанс:

exit

Теперь информация о сессии сохранена в системном журнале.

Просмотр записанных сессий

Посмотреть список записей можно через:

journalctl -t tlog-rec

или:

journalctl | grep tlog

Пример:

изображение.png

Воспроизведение терминальной сессии

Одно из главных преимуществ tlog - возможность увидеть всю историю работы пользователя.

Для просмотра используем:

tlog-play -r journal -M TLOG_REC=12cf3db970a842af87513fd77423f3f3-338-8d4a

изображение.png

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

Ограничения tlog

Важно понимать, что tlog работает на уровне терминальной сессии. Он отлично подходит для контроля SSH-доступа, но не заменяет auditd.

Например:

  • изменение файла через приложение может не попасть в tlog;

  • системные вызовы ядра tlog не отслеживает;

  • изменение файлов вне терминала может остаться незамеченным.

Поэтому для максимального контроля обычно используют связку: auditd и tlog.

Когда auditd лучше tlog

Используйте auditd если необходимо:

  • отслеживать изменение файлов;

  • контролировать системные вызовы;

  • расследовать инциденты;

  • выполнять требования безопасности.

Когда tlog лучше auditd

Используйте tlog если необходимо:

  • видеть реальные действия пользователя;

  • записывать SSH-сессии;

  • анализировать работу администраторов;

  • получать историю консольной активности.

Что выбрать

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

Важные замечания

Перед включением полного аудита необходимо учитывать:

  • журналы могут быстро расти;

  • требуется настройка ротации логов;

  • большое количество правил увеличивает нагрузку на систему;

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

Для большинства VPS влияние auditd на производительность практически незаметно.

Заключение

Когда на сервере работает несколько пользователей, вопрос "кто это сделал?" рано или поздно возникает у каждого администратора. Использование auditd и tlog позволяет не гадать, а получать точный ответ на основе журналов системы. Вы сможете отслеживать запуск программ, изменение файлов, использование sudo и даже полные терминальные сессии пользователей.

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

Наверх