Когда я только начинала работать с 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 больше не будет тенью, скрывающей ошибки, а станет прозрачным и контролируемым инструментом. Потому что логирование — это не только про контроль, но и про доверие к себе и своей инфраструктуре.