Как вести журналы sudo и root-команд на VPS: от простого к надёжному

ГлавнаяКак вести журналы sudo и root-команд на VPS: от простого к надёжному

Содержание

Когда я только начинала работать с VPS, было какое-то благоговение перед sudo. Я знала, что если что-то сломается — виновата буду я. Потому что root-доступ — это как штурвал самолёта: может привести к цели, а может и в стену.

Но только со временем я поняла, как важно вести логи всех sudo и root-команд, особенно если вы не единственная, кто работает с сервером. Или если вы — сами себе DevOps, и хотите спать спокойно, зная, что можно отследить, кто и когда что выполнял.


Зачем логировать sudo и команды от root?

Ответ простой: безопасность и аудит.
Если кто-то выполняет команды с sudo или заходит под root, вы должны иметь возможность увидеть:

  • когда это произошло,
  • что именно запускалось,
  • из-под какого пользователя,
  • с какого IP-адреса (если удалённый доступ).

Это особенно важно для:

  • команд с sudo правами;
  • автоматических скриптов, которые работают от имени root;
  • разборов «что пошло не так» после сбоя.

Где и как уже логируются команды sudo?

По умолчанию команды sudo логируются в /var/log/auth.log (на Ubuntu и Debian), либо в /var/log/secure (на CentOS/AlmaLinux/RHEL).

Попробуйте:

sudo cat /var/log/auth.log | grep sudo

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

Aug 14 15:03:22 vps sudo:   adminuser : TTY=pts/0 ; PWD=/home/adminuser ; USER=root ; COMMAND=/usr/bin/apt update

Но это лишь часть. Если вы хотите вести отдельный журнал или добавить детализацию, придётся настроить чуть глубже.


Настройка sudoers для ведения логов

Откройте конфигурационный файл sudo:

sudo visudo

Это безопасный способ редактировать /etc/sudoers, который проверяет синтаксис перед сохранением.

Добавьте в конец:

Defaults logfile="/var/log/sudo.log"

Теперь всё, что будет запускаться с sudo, будет сохраняться в отдельный файл /var/log/sudo.log.

📌 Важно: убедитесь, что logfile не дублирует системные логи, иначе у вас будут конфликты с rsyslog/journald.


Как логировать все команды root-пользователя

sudo — это полдела. Но если кто-то вошёл как root (через su - или напрямую по ключу/паролю), sudo уже не спасёт. Тут помогает auditd.

Установка:

sudo apt install auditd -y

Пример правила, логирующего запуск любых команд от root:

sudo auditctl -a always,exit -F arch=b64 -F uid=0 -S execve -k root_cmds

Проверка логов:

sudo ausearch -k root_cmds

Всё будет сохранено в /var/log/audit/audit.log.

💡 Советы:

  • добавьте правило в /etc/audit/rules.d/, чтобы оно сохранялось после перезагрузки;
  • убедитесь, что хватает места на диске под такие логи.

Как обезопасить sudoers файл от ошибок

Ошибки в /etc/sudoers могут полностью заблокировать возможность использовать sudo. Я однажды случайно поставила пробел не туда — и пришлось восстанавливать сервер через консоль провайдера.

🔐 Правило №1: редактируйте только через visudo.
🔐 Правило №2: не давайте NOPASSWD доступ без необходимости.

Вот пример строки, которую я добавляю:

adminuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

То есть пользователь adminuser может перезапускать nginx без пароля — и только его.

Также можно создать отдельный файл:

sudo nano /etc/sudoers.d/adminuser

И прописать туда доступ. Так безопаснее, чем лезть в основной /etc/sudoers.


Примеры из жизни

Была у меня ситуация: на одном из серверов начались сбои в nginx. Я полезла в /var/log/auth.log, увидела, что sudo запускался 3 раза подряд другим пользователем, явно не по инструкции. Благодаря логам я выяснила, что он случайно запустил nginx -s stop, вместо reload.

С тех пор я:

  • включаю отдельный лог-файл через sudoers;
  • логирую root-команды через auditd;
  • и стараюсь описывать в sudoers.d точные команды, а не «всё подряд».

Проверка и анализ sudo-логов

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

sudo grep "COMMAND=" /var/log/auth.log

Или если у вас включён отдельный файл:

tail -f /var/log/sudo.log

Можно даже настроить отправку алертов в Telegram, если кто-то запускает нестандартные команды — но это тема для отдельной статьи.


Итого

Если у вас VPS — вы за него отвечаете. И чем раньше вы начнёте вести учёт команд, тем спокойнее будете спать. У меня это стало стандартной практикой на каждом новом сервере: настройка sudoers, auditd, отдельные права и резервная копия sudo-файлов.

Пусть root больше не будет тенью, скрывающей ошибки, а станет прозрачным и контролируемым инструментом. Потому что логирование — это не только про контроль, но и про доверие к себе и своей инфраструктуре.