Як перевірити, які команди виконували на сервері

Що насправді записує команди, які користувачі виконували на сервері

Щоб перевіряти, які команди користувачі виконували на сервері, потрібен запис, який користувач не може редагувати. Історія команд оболонки не є таким записом. Це службовий файл, власником якого є обліковий запис, що його створив. Будь-хто, хто може вводити команди в цю оболонку, може вимкнути або видалити цей файл.

Реальний запис забезпечують чотири рівні, і кожен має свою ціну. sudo записує один рядок для кожної команди в syslog. Журналювання введення-виведення sudo зберігає весь сеанс одного облікового запису. Хук оболонки, наприклад PROMPT_COMMAND, записує команди, які вводить користувач інтерактивного bash. Підсистема аудиту ядра записує сам системний виклик execve, тому це єдиний рівень, який бачить кожен процес. У цьому посібнику розглянуто ці рівні послідовно, описано обмеження кожного з них і пояснено головне: чи матимуть ці записи практичну цінність. Для цього їх потрібно передати з машини до того, як користувач, за діями якого ви стежите, отримає до них доступ.

Перед початком врахуйте одне обмеження. Підсистема аудиту працює на рівні ядра, тому її неможливо протестувати в контейнері, який використовує ядро хоста. Виконуйте ці команди на KVM VPS, де ядро належить вам.

Чому історія shell не є журналом аудиту

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

Вона належить користувачу. Файл має режим 600 і належить цьому обліковому запису, тому rm ~/.bash_history взагалі не потребує додаткових привілеїв. Так само не потрібні привілеї, щоб відкрити файл у редакторі та видалити двадцять важливих рядків.

Вона записується під час завершення shell. Сеанс, який завершується через kill -9 $$ або через розірване з’єднання, нічого не записує. history -c перед exit має такий самий ефект і виглядає так, ніби нічого не відбулося.

Її можна вимкнути одним словом. unset HISTFILE забороняє записувати файл для цього сеансу. set +o history негайно припиняє запис. HISTCONTROL=ignorespace приховує всі команди, введені з пробілом на початку. Усе це налаштовується в man bash, оскільки цей механізм має бути під контролем користувача.

Вона записує введений текст, а не виконану команду. Alias або shell-функція означає, що текст у файлі не є програмою, яку виконав kernel.

Міток часу також немає, якщо під час запису команди не було встановлено HISTTIMEFORMAT, оскільки bash записує рядки-маркери #1755043200 лише коли цю змінну встановлено.

У спільному вході до системи вона також не може показати, хто саме виконав дію. Троє людей, які використовують один обліковий запис deploy, створюють один об’єднаний файл з одним uid. Жоден рівень журналювання не може пов’язати дію з конкретною людиною, якщо двоє людей спільно використовують один uid. Саме це на практиці обґрунтовує окремий непривілейований обліковий запис для кожної людини замість спільного входу.

Історія shell добре виконує своє справжнє завдання: допомагає повторно ввести вчорашню команду. Використовуйте її як підказку. Ніколи не подавайте її як доказ.

Що журналює sudo і де журналювання припиняється

sudo надсилає рядок для кожної виконаної команди до засобу syslog authpriv.

sudo grep 'sudo:' /var/log/auth.log | tail -5
journalctl -t sudo -n 5

У кожному рядку зазначено користувача, термінал, робочий каталог, цільового користувача та команду:

sudo:    alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update

Якщо /var/log/auth.log не існує, rsyslog не встановлено в цьому образі, і ті самі записи зберігаються лише в журналі. Перш ніж покладатися на нього, перевірте, що журнал не є тимчасовим:

journalctl --list-boots

Якщо відображається лише поточне завантаження, це означає, що /var/log/journal не існує. Тому журнал зберігається в /run, а всі записи втрачаються під час наступного перезавантаження. Зробіть журнал постійним:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Тепер про обмеження. sudo журналює команду, яку йому доручили виконати. Воно не журналює дії, які ця команда виконує далі. Тому на цьому один рядок завершує весь ланцюжок:

sudo -i

У журналі з’являється лише один запис для оболонки. Усі команди, введені в цій root-оболонці, невидимі для sudo, оскільки sudo більше не бере участі в їхньому виконанні. sudo su -, sudo bash і sudo vim /etc/shadow з подальшим :!bash мають однакову структуру. Правило sudoers, яке дозволяє будь-яку програму з можливістю запуску оболонки, наприклад vim або find, фактично надає root-доступ без журналювання. Перш ніж довіряти записам журналу, перевірте, до яких ресурсів обліковий запис може отримати фактичний доступ:

sudo -l -U alice

Запис повного сеансу для одного облікового запису

Спочатку з’ясуйте, який sudo у вас встановлено, оскільки в Rust-реалізації цієї функції немає:

sudo --version | head -1

Якщо у виводі зазначено sudo-rs, пропустіть цей розділ і використайте підсистему аудиту. Власна документація Ubuntu для випусків 25.10 і 26.04 вказує, що журналювання вводу-виводу та sudoreplay не підтримуються. Станом на серпень 2026 року це все ще було актуально. Це важливо, оскільки sudo-rs є типовим sudo у цих випусках, тому оновлення може видалити засіб контролю, який, на вашу думку, у вас був. Перед плануванням журналювання на основі sudo варто прочитати повний список змін у поведінці sudo-rs.

В оригінальному sudo, який Ubuntu 24.04 LTS досі постачає, увімкніть журналювання вводу-виводу для одного облікового запису:

sudo visudo -f /etc/sudoers.d/iolog

Defaults:deploy log_output
Defaults!/usr/bin/sudoreplay !log_output

Використовуйте visudo замість редактора, оскільки ця команда відмовляється зберігати файл, який не вдається розібрати. Некоректний файл sudoers блокує доступ усіх користувачів до sudo. Потім відтворіть сеанс:

sudo sudoreplay -l user=deploy
sudo sudoreplay 000001

sudoreplay -l перелічує сеанси з їхніми ідентифікаторами й нічого не виводить, якщо log_output ніколи не застосовувався до цього користувача. Вартість: кожен байт, що проходить через термінал, зберігається в /var/log/sudo-io, тому докладний сеанс займає багато місця. Другий рядок sudoers не дає відтворенню записувати саме себе. Основна проблема — секрети, оскільки журнал вводу-виводу містить усе, що було введено й виведено, зокрема пароль, введений у запит усередині сеансу. Тому його потрібно захищати так само, як сховище паролів. Охоплення також обмежене. Журналювання бачить команди, запущені через sudo. Якщо користувач входить у систему й працює безпосередньо від свого імені, такий сеанс взагалі не записується.

Shell hooks і те, як саме їх обходять

Рецепт, який часто наводять для «журналювання кожної команди», — це hook PROMPT_COMMAND, доданий до /etc/profile.d/:

# /etc/profile.d/00-cmdlog.sh
PROMPT_COMMAND='logger -p local6.info -t cmdlog "$(whoami) $$ $(history 1 | sed "s/^ *[0-9]* *//")"'

bash запускає PROMPT_COMMAND перед відображенням кожного prompt, тому рядок потрапляє до syslog під час введення, а не після завершення сеансу. logger передає запис через системний log daemon, тому права доступу до власного файлу користувача не мають значення. Відкрийте новий login shell і перевірте результат за допомогою sudo tail -f /var/log/syslog або journalctl -t cmdlog -f на образі без rsyslog.

Потім це перестає працювати п’ятьма способами, кожен із яких можна відтворити за хвилину.

• Non-interactive shells не відображають prompt. ssh you@server 'id' виконує команду та завершує роботу, але нічого не записується, оскільки PROMPT_COMMAND не було обчислено.
• Це змінна. unset PROMPT_COMMAND вимикає її до кінця сеансу і не потребує привілеїв.
• Файл читають login shells. bash --noprofile --norc взагалі не підключає /etc/profile.d/.
• Це специфічно для bash. zsh, sh, python3 -c 'import os; os.system("id")' і :!id усередині vim запускають програми, які жоден hook prompt у bash не побачить.
• Рядок записується саме в тому вигляді, у якому його введено, тому alias або function приховує фактичну команду, яка виконалася.

Використовуйте shell hook як допоміжний засіб. Для користувачів, які співпрацюють, він відповідає на запитання «що я запускав минулого вівторка». Не покладайтеся на нього як на засіб контролю лише тому, що це зазначено в checklist.

Підсистема аудиту ядра бачить кожен execve

Підсистема аудиту Linux, якою керує демон auditd, є єдиним рівнем, який користувач не може обійти, оскільки запис створюється в ядрі в момент виконання системного виклику. Якщо процес запускає програму, виникає подія. Оболонка, мова програмування та наявність термінала не мають значення.

sudo apt update && sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd
sudo auditctl -s

auditctl -s виводить стан демона. enabled 1 із ненульовим значенням pid означає, що він працює, а lost 0 означає, що записи ще не втрачалися. Запам’ятайте лічильник lost: він з’явиться далі.

auid — це поле, заради якого варто налаштовувати аудит. PAM встановлює login uid під час початку сеансу, а ядро надалі передає його кожному дочірньому процесу. Перевірте своє значення:

cat /proc/self/loginuid

Інтерактивний SSH-сеанс виводить ваш uid, оскільки /etc/pam.d/sshd містить pam_loginuid.so. Значення 4294967295 означає, що loginuid ніколи не встановлювався. Це нормально для процесу, запущеного системним демоном під час завантаження. Важливо, що sudo -i не змінює це значення: root shell, відкритий користувачем alice, усе одно має auid 1000, тому кожна команда в ньому пов’язується з alice. Саме цю прогалину залишає sudo. Для зміни вже встановленого loginuid потрібен CAP_AUDIT_CONTROL, якого звичайні користувачі не мають, а sudo auditctl --loginuid-immutable також блокує цю зміну для root до наступного перезавантаження.

Переконайтеся, що /etc/pam.d/sshd, /etc/pam.d/login і /etc/pam.d/cron містять pam_loginuid.so. Інакше події надходитимуть без прив’язаного до них користувача. Це той самий список файлів, який ви змінюєте під час посилення захисту SSH-доступу до VPS, тому виконайте ці два завдання одночасно.

Початковий набір правил для auditd

Правила зберігаються в /etc/audit/rules.d/*.rules. augenrules об’єднує їх в один список у порядку імен файлів. Порядок визначає поведінку, оскільки kernel зупиняється на першому правилі, що відповідає умові. Перш ніж щось додавати, прочитайте наявні правила. -D у пізнішому файлі видаляє все, що було завантажено раніше.

ls /etc/audit/rules.d/
cat /etc/audit/rules.d/audit.rules

Потім створіть /etc/audit/rules.d/50-exec.rules:

## Suppressions first: the kernel takes the first matching rule.
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-deb
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-query
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-split
-a never,exit -F arch=b64 -S execve -F exe=/usr/bin/dpkg-trigger

## Every program started by a logged-in human.
-a always,exit -F arch=b64 -S execve,execveat -F auid>=1000 -F auid!=unset -k exec
-a always,exit -F arch=b32 -S execve,execveat -F auid>=1000 -F auid!=unset -k exec

## Changes to who may become root.
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity

## Changes to the audit configuration itself.
-w /etc/audit/ -p wa -k auditconfig

Завантажте правила та перевірте результат:

sudo augenrules --load
sudo auditctl -l

auditctl -l, який виводить правила повторно, означає, що вони активні. No rules означає, що завантаження завершилося помилкою. journalctl -u auditd -n 20 вказує файл і рядок, який відхилив parser. Старіші версії audit userspace не розуміють ключове слово unset. Якщо loader повідомляє про помилку в цьому полі, замість нього використайте -F auid!=4294967295. Це те саме значення, записане повністю.

Тепер прочитайте події:

sudo ausearch -k exec -ts recent -i | tail -40
sudo ausearch -ul 1000 -ts today -i
sudo aureport -k --summary -i

-i перетворює uid і номери syscall на імена. На практиці цей параметр обов’язковий. -ts recent охоплює останні десять хвилин. Кожне виконання надходить як група записів: запис SYSCALL містить uid, auid, статус завершення та key; запис EXECVE містить повний список аргументів; записи CWD і PATH містять контекст.

Є важливе обмеження. Воно часто спричиняє помилки під час налаштування. audit записує syscall, а вбудована команда shell не виконує власного syscall. cd /root не запускає жодної програми. echo evil >> /etc/passwd, введена в запрошенні bash, також не запускає програми, оскільки і echo, і перенаправлення виконуються всередині вже запущеного процесу shell. Тому правила execve бачать програми, а правила -w — операції запису. Жодного з цих наборів недостатньо окремо.

Насамкінець заблокуйте конфігурацію:

## /etc/audit/rules.d/99-finalize.rules
-e 2

-e 2 робить набір правил незмінним до наступного перезавантаження. Після завантаження auditctl -s повідомляє enabled 2, а будь-яка спроба додати або видалити правило завершується помилкою Operation not permitted, навіть для root. Додайте цей файл останнім і врахуйте, що для кожної зміни правила доведеться перезавантажувати систему. У цьому і полягає призначення такого обмеження: набір правил, який можна непомітно вимкнути, не є доказом.

Журнал аудиту, який ніхто не читає, — це артефакт для відповідності вимогам

Проблема auditd не в тому, що він щось пропускає. Проблема в тому, що він записує так багато, що ніхто не переглядає ці дані, а журнал існує лише для формального виконання пункту чекліста, а не для отримання відповіді на конкретне запитання.

Перш ніж щось оптимізувати, виконайте розрахунок на власному сервері:

sudo aureport -k --summary -i
sudo du -sh /var/log/audit

Один sudo apt upgrade запускає тисячі короткоживучих процесів, і кожен із них містить ваш auid. Тому одне оновлення пакета може дати більше записів, ніж тиждень роботи користувачів. Саме тому наведені вище винятки стосуються dpkg та його допоміжних компонентів. Виключайте за виконуваним файлом, а не за користувачем: виняток для /usr/bin/dpkg можна описати одним реченням, тоді як виняток для облікового запису створює прогалину, що точно відповідає об’єкту, який ви намагалися виявити.

Ключ -k у кожному правилі дає змогу виконувати пошук у журналі через місяць. ausearch -k sudoers — це запит, на який можна отримати відповідь. ausearch без фільтра — це суцільний масив тексту, який привчає вас припинити читання. Якщо ваш збирач журналів очікує JSON замість власного формату, laurel — це плагін auditd, який перетворює кожну подію на один JSON-об’єкт із декодованими аргументами. Він реєструється у /etc/audit/plugins.d/ так само, як і будь-який інший плагін, а auditd підхоплює зміни плагіна після sudo pkill -HUP auditd.

Що насправді коштує auditd

Кожен системний виклик, що відповідає правилу, стає записом, який ядро форматує та передає в userspace. Витрати виникають у двох місцях. Обидві можна виміряти на власному навантаженні, а не вгадувати за опублікованими кимось даними.

• CPU і затримки. Машина, на якій постійно створюються процеси, build host або CI runner, створює окремий запис для кожного exec. Коли backlog ядра заповнюється, --backlog_wait_time змушує ядро призупинити процес, який згенерував подію, доки не звільниться місце. Тому audit може проявлятися як повільні збірки, а не як певний відсоток використання CPU. Під реальним навантаженням стежте за backlog і lost у sudo auditctl -s. Зростання lost означає, що записи втрачалися. Журнал із непомітними пропусками гірший за відсутність журналу, оскільки ви все одно йому довірятимете.
• Диск. Перегляньте /etc/audit/auditd.conf і свідомо визначте, що має відбуватися після заповнення диска, оскільки стандартні значення є лише варіантами політики. max_log_file, num_logs і max_log_file_action керують ротацією. space_left_action, admin_space_left_action і disk_full_action керують аварійною поведінкою. Деякі доступні дії, зокрема halt і single, вимикають машину, щоб не втратити запис.

Рядок -f у /etc/audit/rules.d/audit.rules — це те саме рішення на рівні ядра: -f 1 передає повідомлення про помилку audit до syslog, а -f 2 спричиняє panic ядра. Обирайте 2 лише тоді, коли ви справді волієте втратити сервер, а не запис. На VPS, де працює сервіс, від якого залежать користувачі, натомість використовуйте ротацію та винесіть проблему зі сховищем за межі цього сервера.

Надсилайте журнали за межі сервера майже в реальному часі

Це підтверджують звіти про інциденти. Журнали, які залишаються на скомпрометованому хості, може редагувати той, хто його скомпрометував. root може перезаписати /var/log/auth.log, видалити /var/log/audit/audit.log і зупинити daemon. -e 2 не дає вивантажити правила. Але це не захищає rm. Кожен наступний рівень створює докази лише за умови, що їхня копія спочатку залишає машину.

Власний транспортний механізм Audit — це plugin audisp-remote із audispd-plugins. Увімкніть його в /etc/audit/plugins.d/au-remote.conf:

active = yes
direction = out
path = /usr/sbin/audisp-remote
type = always
format = string

Перед перезавантаженням перевірте path відповідно до command -v audisp-remote, оскільки неправильний шлях дає лише один рядок у журналі й не створює жодних даних. Установіть remote_server і port у /etc/audit/audisp-remote.conf, а на collector установіть tcp_listen_port = 60 у його власному auditd.conf. Перезавантажте конфігурацію за допомогою sudo pkill -HUP auditd. На багатьох образах systemctl restart auditd відхиляється, оскільки unit file задає RefuseManualStop=yes, тому надійніше використовувати цей спосіб передавання сигналу.

Інший варіант додає audit до потоку syslog, який ви вже пересилаєте. /etc/audit/plugins.d/syslog.conf постачається разом із active = no. Установіть значення yes, перезавантажте конфігурацію, і події audit приєднаються до рядків sudo та всіх інших повідомлень. Потім пересилайте весь потік через rsyslog із TLS (transport layer security), для чого потрібен пакет rsyslog-gnutls:

# /etc/rsyslog.d/60-forward.conf
*.* action(type="omfwd"
    target="logs.example.net" port="6514" protocol="tcp"
    StreamDriver="gtls" StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.net"
    action.resumeRetryCount="-1"
    queue.type="linkedList" queue.filename="fwd" queue.saveOnShutdown="on")

Найважливіші тут параметри черги. action.resumeRetryCount="-1" повторює спроби без кінцевого обмеження, а черга з підтримкою диска та параметром queue.saveOnShutdown="on" зберігає записи, доки collector недоступний, а потім надсилає їх після його відновлення. Без цих двох параметрів перезавантаження collector створює прогалину у ваших доказах, і ви не отримуєте жодної ознаки, що вона виникла. Застосуйте налаштування за допомогою sudo systemctl restart rsyslog, а потім переконайтеся, що записи справді надходять на collector, перш ніж покладатися на цю схему.

Залишився один цикл, який потрібно замкнути: collector має бути машиною, до якої перевірювані користувачі не можуть увійти. Якщо та сама група адміністраторів має root на сервері журналів, ви просто скопіювали файл, а не захистили його. Використовуйте окремі облікові дані, окремі ключі та, бажано, окремий обліковий запис у провайдера. Це та сама логіка, завдяки якій централізований спосіб керування багатьма Linux-серверами варто створити ще до того, як він знадобиться. Вона також визначає різницю між корисною та марною першою годиною, коли ви працюєте зі скомпрометованим VPS.

Перевірте, що звичайний користувач не може переписати записи

Перевірте це твердження, а не виходьте з припущення. Увійдіть зі звичайного облікового запису без sudo:

echo test >> /var/log/auth.log
cat /var/log/audit/audit.log
auditctl -D
id -nG

Очікуйте такі результати в зазначеному порядку: Permission denied, оскільки власником auth.log є syslog, групою-власником — adm, а режим доступу — 640; Permission denied ще раз, оскільки audit log має режим 600, а його власником є root; помилку про відмову у виконанні, оскільки для зміни audit rules потрібен CAP_AUDIT_CONTROL; і список груп, у якому немає ні adm, ні systemd-journal.

Саме на останній перевірці часто помиляються. Членство в adm надає доступ на читання до /var/log/auth.log, а членство в systemd-journal — доступ на читання до всього journal. Жодне з них не надає доступу на запис, тому жодне не дає змоги підробляти записи. Обидва варіанти дають змогу читати кожен рядок автентифікації на сервері. Це рішення потрібно приймати свідомо, а не копіювати рядок usermod -aG з відповіді на форумі.

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

sudo auditctl -s
systemctl is-enabled auditd

enabled 2 означає, що набір правил заблокований до наступного завантаження системи. enabled з другої команди означає, що auditd знову запуститься після цього завантаження. Набір правил, який діє лише до наступного оновлення kernel, також не є audit trail.

FAQ

Як переглянути всі команди, виконані певним користувачем?

Знайдіть його uid за допомогою id -u alice, а потім виконайте пошук у журналі аудиту за login uid: sudo ausearch -ul 1000 -ts today -i. Додайте -k exec, щоб обмежити пошук правилом execve. Login uid встановлюється під час входу в систему й зберігається під час su та sudo -i, тому цей спосіб також виявляє команди, виконані в root shell, який відкрив цей обліковий запис. Це працює лише для команд, виконаних після завантаження правил, оскільки audit не зберігає історію подій, запис яких не був налаштований. sudo aureport -k --summary -i показує кількість подій для кожного правила, якщо спочатку потрібно оцінити структуру даних.

Чи може користувач видалити історію bash, щоб приховати виконані команди?

Так, для цього не потрібні привілеї. ~/.bash_history належить цьому користувачеві й має режим 600, тому користувач може редагувати, очистити або видалити файл. Також можна заборонити його запис за допомогою unset HISTFILE, припинити запис посеред сеансу за допомогою set +o history або приховати окремі команди, вводячи їх із пробілом на початку, якщо встановлено HISTCONTROL=ignorespace. Bash записує файл під час завершення shell, тому сеанс, примусово завершений за допомогою kill -9 $$, нічого не запише. Вважайте історію shell підказкою, а не доказом.

Чи записує sudo дії всередині sudo -i?

Ні. sudo записує команду, яку його попросили виконати, тому sudo -i створює один рядок для shell і нічого не записує після цього. Кожна команда, введена в цьому root shell, невидима для sudo, оскільки sudo більше не бере участі у її виконанні. sudo su -, sudo bash та будь-яка дозволена програма з можливістю виходу в shell працюють так само. Розрив між цими подіями усувають два підходи: правила аудиту для execve, які записують кожну програму з початковим login uid, і правила sudoers, які взагалі не надають shell.

Чи сповільнить auditd роботу сервера?

Це повністю залежить від кількості процесів, які запускає ваше навантаження, тому вимірюйте вплив, а не покладайтеся на певне число. Сервер, який переважно обробляє запити, рідко виконує exec і не відчує сповільнення. Build host або CI runner постійно виконує exec і може суттєво сповільнюватися, оскільки після заповнення audit backlog ядро призупиняє процес, який згенерував подію, доки не звільниться місце. Запустіть sudo auditctl -s під реальним навантаженням і стежте за backlog та lost. Будь-яке lost, більше за нуль, означає, що записи було втрачено. Це найгірший результат, оскільки в журналі з’являються непомітні пропуски.

Де слід зберігати журнали аудиту?

На іншій машині з затримкою, вимірюваною секундами. Будь-хто, хто отримав root на хості, що аудитується, може видалити /var/log/audit/audit.log і переписати /var/log/auth.log, тому локальні копії дають відповіді лише щодо інцидентів, які ніхто не намагався приховати. Пересилайте дані за допомогою плагіна audisp-remote до центрального auditd або ввімкніть audit syslog plugin і пересилайте весь потік syslog через rsyslog із використанням TLS. Надайте collector окремі облікові дані та переконайтеся, що облікові записи, які проходять аудит, не мають до нього доступу.