Как отслеживать использование sudo и root-доступа в Linux

• Контролируйте использование sudo через системные журналы: /var/log/auth.log на старых дистрибутивах и journalctl на systemd-системах.
• Фильтруйте по пользователю, по исполняемому файлу или по временным интервалам; используйте grep, journalctl и графические утилиты GNOME Logs.
• Заводите SOP для расследований, ограничивайте доступ и настраивайте расширённое логирование при необходимости.

Зачем следить за sudo и root-доступом

Sudo даёт временные полномочия суперпользователя. Это удобно, но рискованно: ошибка или необдуманная команда под root может повредить систему. Мониторинг позволяет быстро выявить неправильное или неожиданное использование привилегий и вовремя отреагировать.

Краткое определение: sudo — инструмент, который позволяет пользователю выполнять команды от имени другого пользователя (по умолчанию — root).

Важно: журналы содержат данные о действиях людей. Обращайтесь с ними осторожно и в соответствии с политиками конфиденциальности.

Команда sudo — что именно логируется

По умолчанию sudo записывает в системные журналы информацию о факте вызова: кто, когда и какую команду запустил (в большинстве конфигураций виден путь к исполняемому файлу и аргументы). Детальный захват ввода/вывода требует дополнительной настройки (плагин log_input/log_output или session-recording).

Совет: перед расследованием проверьте /etc/sudoers и файлы в /etc/sudoers.d, чтобы понять, какие пользователи или группы имеют привилегии и есть ли у них ограничения.

Файл auth.log — где искать на старых дистрибутивах

Некоторые системы продолжают писать аутентификационные события в /var/log/auth.log или в /var/log/audit/audit.log. Если он присутствует, можно просмотреть его напрямую.

Пример открытия файла (Ubuntu 22.04 пример):

less /var/log/auth.log

Чтобы отфильтровать все строки с sudo и затем конкретного пользователя (например, mary):

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

Этот простой приём даёт строки с упоминаниями sudo и «mary», но может пропустить распределённые/архивные логи или записи в системный журнал systemd.

journalctl — предпочтённый метод на systemd

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

Основные полезные приёмы:

• Показать записи, связанные с sudo (исполняемый файл):

sudo journalctl -e _EXE=/usr/bin/sudo

• Фильтровать по имени команды (COMM):

sudo journalctl -e _COMM=sudo

• Отобразить записи за определённый период:

sudo journalctl _COMM=sudo --since "2 days ago" --until "now"

• Показать записи конкретного пользователя (ряд методов):
  • Через UID:

sudo journalctl _EXE=/usr/bin/sudo _UID=$(id -u mary) --since "2025-01-01"

• Или сначала посмотреть вызовы sudo, а затем сузить поиск по имени пользователя в выводе.

Примечание: конструкции с _EXE и _COMM могут отличаться в зависимости от версии systemd и способа запуска sudo — если команда не даёт ожидаемых результатов, попробуйте оба варианта.

Подсказка: в less можно использовать стрелки вправо/влево, чтобы увидеть длинные команды и аргументы.

GNOME Logs — графический способ

Если вы работаете в GNOME, встроенное приложение Logs (Журналы) позволяет искать и фильтровать события через GUI.

Как открыть: нажмите клавишу «Super», введите «Logs» (Журналы) и откройте приложение. Затем выберите «All» и нажмите значок увеличительного стекла для поиска по слову sudo.

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

Что искать: практические индикаторы подозрительной активности

• Внезапный рост числа вызовов sudo от одного пользователя.
• Непривычные команды (редактирование /etc/fstab, изменение конфигураций сети, изменение sudoers).
• Использование текстовых редакторов с привилегиями (vim, nano, ed) — это может быть оправдано, но требует проверки.
• Попытки сменить владельцев/права на чувствительные каталоги.

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

Что делать при подозрительных вызовах sudo — пошаговый план (SOP)

1. Сохраните журналы текущего дня (экспорт):

sudo journalctl _EXE=/usr/bin/sudo --since "today" > /tmp/sudo-investigation-$(date +%F).log

2. Найдите все записи конкретного пользователя в логах и отметьте временные метки.
3. Проверьте, какие команды запускал пользователь (именно команды и аргументы).
4. Свяжитесь с пользователем: попросите объяснить причину и контекст.
5. Если есть риск компрометации — временно отозвать sudo-привилегии и начать инцидент-расследование.
6. Восстановите систему из резервной копии, если обнаружена вредоносная модификация.

Критерии приёмки

• Журналы собраны и сохранены в защищённом месте;
• Владелец, время и команды установлены;
• Проведено интервью с пользователем;
• Решение принято (обучение, отзыв прав, расследование дальше).

Расширенные методы логирования и контроль целостности

• Включите системный аудит (auditd) для записи execve и других системных вызовов. auditd позволяет захватывать подробные события, но требует внимания к объёму логов и политике ротации.
• Настройте sudo для более подробного логирования (например, session recording через плагин log_input/log_output), если политика безопасности требует полного захвата сессий.
• Централизуйте логи (rsyslog/remote journal) на отдельный лог-сервер — это сильно помогает при расследовании и предотвращает удаление локальных следов.

Важно: расширенное логирование повышает объём данных и может содержать конфиденциальную информацию — продумайте хранение и доступ.

Когда журналы не дают полной картины — типичные причины и обходные пути

• Пользователь мог получить root-доступ не через sudo (su, прямой вход под root, эксплойт).
• Логи могли быть очищены или подменены локально — проверяйте удалённые копии и резервные сервера.
• Некоторая деятельность внутри привилегированной сессии (например, редактирование файла в интерактивном редакторе) не покажет каждый ввод в стандартных логах; для этого нужен session recording.

Альтернатива: используйте PAM-модули для аудита tty-сессий или специализированные средства EDR/IDS.

Ролевая проверка: чеклист для админа и для руководителя

Чеклист для администратора

• Проверить /etc/sudoers и /etc/sudoers.d на нештатные записи.
• Выполнить фильтрацию логов по пользователю и по интервалу.
• Экспортировать подозрительные записи и создать инцидент-тикет.
• При необходимости временно отозвать права и провести форензик.

Чеклист для менеджера/владельца сервиса

• Иметь политику выдачи sudo и процесс одобрения.
• Запрашивать отчёт о проведённой проверке и о мерах по предотвращению повторений.
• Убедиться, что доступы ревьюятся регулярно.

Безопасность и конфиденциальность логов

• Логи содержат персональные идентификаторы (имена пользователей, IP). Обрабатывайте в соответствии с политикой конфиденциальности и требованиями законодательства.
• Ограничьте доступ к логам минимумом необходимого.
• Настройте ротацию и срок хранения логов: храните достаточно для расследований, но не дольше, чем нужно.

Совместимость и особенности разных дистрибутивов

• systemd-ориентированные дистрибутивы (Ubuntu, Fedora, Debian recent) используют journalctl.
• Некоторые серверные окружения всё ещё используют rsyslog и /var/log/auth.log.
• В дистрибутивах с SELinux/auditd подробные события обычно доступнее через audit.log и ausearch.

Совет по миграции: при переходе на systemd проверьте, что сбор и хранение журналов настроены так, чтобы старые политики rsyslog не терялись.

Быстрые команды и шпаргалка

• Показать последние 200 записей sudo:

sudo journalctl _COMM=sudo -n 200

• Показать записи sudo за последние 7 дней:

sudo journalctl _COMM=sudo --since "7 days ago"

• Поиск по конкретной сессии или строке в экспортированном логе:

grep -n "mary" /tmp/sudo-investigation-2025-01-01.log

• Экспортировать локальный auth.log за месяц:

sudo cp /var/log/auth.log /tmp/auth.log.$(date +%F)

Шаблон предварительного расследования (короткий)

1. Собрать логи за временной диапазон.
2. Выделить записи пользователя и команды.
3. Проверить наличие изменений в конфигурациях/критичных файлах.
4. Интервьюировать пользователя.
5. Принять решение: обучение / отзыв прав / полное расследование.

Решение: когда давать sudo и когда ограничивать

Давайте sudo тогда, когда пользователю действительно нужны привилегии для работы на регулярной основе. Где можно — применяйте принцип наименьших прав: выдавайте узкие права на команды, а не полный root-доступ. Регулярно пересматривайте выданные полномочия.

Простая модель зрелости контроля доступа (уровни)

• Уровень 0 — нет контроля: root-доступ повсеместно.
• Уровень 1 — базовый sudo: несколько администраторов с полными правами и минимальным логированием.
• Уровень 2 — аудит и SOP: централизованные логи, регулярные проверки.
• Уровень 3 — полный контроль: session recording, централизованный SIEM, автоматические алерты.

Decision flow (Mermaid)

flowchart TD
  A[Наблюдаем необычные вызовы sudo] --> B{Проверен лог}
  B -- Да --> C[Собрать контекст и экспортировать логи]
  B -- Нет --> D[Использовать journalctl/rsyslog/auditd]
  C --> E{Активность объяснима}
  E -- Да --> F[Документировать и закрыть инцидент]
  E -- Нет --> G[Отозвать привилегии и начать полное расследование]
  D --> C

Заключение

Мониторинг использования sudo — не только вопрос безопасности, но и хорошая практика управления изменениями. Комбинация простых команд (grep, journalctl), политики выдачи прав и SOP для расследований даёт баланс между оперативностью и контролем.

Ключевые выводы

• Используйте journalctl на systemd-системах и /var/log/auth.log там, где он есть.
• Централизуйте логи и настроьте ротацию.
• Внедрите процедуры расследования и отзыв прав при подозрениях.

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