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

Когда я только начинала работать с VPS, было какое-то благоговение перед

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

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

---

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

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

или заходит под, вы должны иметь возможность увидеть:

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

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

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

---

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

По умолчанию команды

логируются в (на Ubuntu и Debian), либо в (на 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

Это безопасный способ редактировать

, который проверяет синтаксис перед сохранением.

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

КопироватьDefaults logfile="/var/log/sudo.log"

Теперь всё, что будет запускаться с

, будет сохраняться в отдельный файл.

📌 Важно: убедитесь, что

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

---

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

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

Установка:

Копировать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

Всё будет сохранено в

.

💡 Советы:

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

---

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

Ошибки в

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

🔐 Правило №1: редактируйте только через

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

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

Копироватьadminuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

То есть пользователь

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

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

Копироватьsudo nano /etc/sudoers.d/adminuser

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

.

---

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

Была у меня ситуация: на одном из серверов начались сбои в

. Я полезла в, увидела, что запускался 3 раза подряд другим пользователем, явно не по инструкции. Благодаря логам я выяснила, что он случайно запустил, вместо.

С тех пор я:

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

---

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

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

Копироватьsudo grep "COMMAND=" /var/log/auth.log

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

Копироватьtail -f /var/log/sudo.log

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

---

Итого

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

,, отдельные права и резервная копия sudo-файлов.

Пусть

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

[elementor-template id="3573"]