Как определить, есть ли пользователь с root-правами

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

Что такое root-права и зачем их проверять

Root — это суперпользователь в Unix-подобных операционных системах, обладающий неограниченным доступом ко всем ресурсам. Он может изменять системные файлы, устанавливать ПО, управлять процессами и настраивать права доступа. Наличие нескольких учётных записей с такими привилегиями увеличивает поверхность атаки и повышает риск инцидентов.
Проверка на наличие root-пользователей необходима при аудите безопасности, перед развёртыванием новых серверов или после подозрительной активности. Особенно важно это в корпоративных средах, где доступ должен быть строго контролируемым. Неучтённая учётная запись с UID 0 может означать бэкдор или ошибку администратора.
Каждый сервер должен иметь только одну легитимную точку доступа с максимальными правами — обычно это сам root или доверённый пользователь через sudo. Любое отклонение требует немедленного расследования. Современные стандарты безопасности, такие как CIS Benchmarks, прямо указывают на необходимость регулярного аудита учётных записей с повышенными привилегиями.

Как проверить наличие root-пользователей в системе

Первый шаг — анализ локальных учётных записей. Для этого используются базовые команды, доступные в любом дистрибутиве Linux. Основной источник информации — файл /etc/passwd, где хранятся данные о всех пользователях.
Чтобы найти всех пользователей с UID 0, выполните:

1. Откройте терминал с правами root или через sudo;
2. Выполните команду: awk -F: '($3 == 0) {print $1}' /etc/passwd;
3. Система вернёт список имён пользователей с правами суперпользователя.

Если вывод содержит более одного имени (например, root и admin), это тревожный сигнал. Также проверьте, какие пользователи входят в группу wheel (в RHEL/CentOS) или sudo (в Debian/Ubuntu):

• getent group wheel
• getent group sudo

Для проверки конкретного пользователя используйте команду id имя_пользователя. Если в выводе есть uid=0(root) или groups=... sudo, значит, он обладает расширенными правами.

Шаги для автоматизированной проверки

Для массового аудита можно создать простой скрипт:

1. Создайте файл check_root.sh;
2. Добавьте код:

   #!/bin/bash
   echo "=== Пользователи с UID 0 ==="
   awk -F: '($3 == 0) {print $1}' /etc/passwd
   echo "=== Члены группы sudo ==="
   getent group sudo 2>/dev/null || echo "Группа sudo не найдена"
   echo "=== Члены группы wheel ==="
   getent group wheel 2>/dev/null || echo "Группа wheel не найдена"
   

3. Запустите: bash check_root.sh.

Анализ удалённого доступа и привилегированных сессий

Наличие root-доступа не ограничивается локальными учётками. Важно проверить, кто может подключаться к системе удалённо с повышенными правами. Основной вектор — SSH-доступ, особенно когда разрешён вход напрямую под root.
Проверьте конфигурацию SSH-сервера:

• Файл: /etc/ssh/sshd_config;
• Параметр: PermitRootLogin.

Если значение yes или without-password, это означает, что root может входить по SSH. Рекомендуется установить no или prohibit-password.
Чтобы определить, кто сейчас активен в системе с высокими привилегиями:

• w — покажет активные сессии и команды;
• ps aux | grep sudo — процессы, запущенные через sudo;
• last | head -10 — последние 10 входов в систему.

Если вы видите входы с IP-адресов, не относящихся к вашей сети, или в нерабочее время — это повод для проверки. Также стоит проанализировать, кто из пользователей часто использует sudo su - — это может указывать на попытку постоянной работы от имени root.

Пример опасной конфигурации

Представьте: в системе создан пользователь deploy, добавленный в группу sudo, но при этом в /etc/ssh/sshd_config стоит PermitRootLogin yes. Злоумышленник, получивший пароль от root (например, через брутфорс), сможет войти напрямую. Даже если пароль сложный, это создаёт избыточный риск.

Проверка логов: как найти следы использования root-доступа

Логи — главный источник информации о том, кто и когда использовал привилегированные команды. В Linux основные события аутентификации фиксируются в файлах /var/log/auth.log (Debian/Ubuntu) или /var/log/secure (RHEL/CentOS).
Ключевые события для поиска:

• Успешный вход под root;
• Использование su или sudo;
• Смена пароля root;
• Подключение по SSH с привилегиями.

Команды для анализа:

1. Поиск входов под root: grep "Accepted.*root" /var/log/auth.log;
2. Поиск использования sudo: grep "sudo:" /var/log/auth.log;
3. Поиск смены пользователя: grep "su[" /var/log/auth.log;
4. Просмотр за последние 24 часа: journalctl --since "24 hours ago" | grep -i "root|sudo".

Обратите внимание на частоту событий. Например, десятки попыток входа с разных IP — признак брутфорса. Одиночные успешные входы в ночное время — возможный признак несанкционированного доступа.

Автоматический мониторинг с помощью auditd

Для глубокого аудита рекомендуется использовать auditd — систему аудита ядра Linux. Она позволяет отслеживать выполнение конкретных системных вызовов, включая действия от имени root.
Пример правила для отслеживания команд с UID 0:

-a always,exit -F euid=0 -F key=root_cmd

После настройки все действия будут логироваться и доступны через ausearch -k root_cmd. Это особенно полезно в средах, соответствующих стандартам PCI DSS или ISO 27001.

Риски и последствия наличия лишних учётных записей с правами root

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

• Случайное удаление системных файлов;
• Установка вредоносного ПО;
• Кража конфиденциальных данных (базы, ключи, сертификаты);
• Полная компрометация сервера и распространение атаки на другие узлы.

Статистика говорит сама за себя: по данным Verizon DBIR, более 80% инцидентов связаны с использованием привилегированных учётных записей. При этом среднее время обнаружения утечки — 207 дней.
Кроме того, множественные root-учётки нарушают требования многих стандартов:

• CIS Controls — требует минимизации привилегированных аккаунтов;
• PCI DSS — запрещает общие учётные записи с высокими правами;
• GDPR — обязывает контролировать доступ к персональным данным.

Случай из практики

В одном из проектов администратор создал учётную запись admin с UID 0 для удобства. Через месяц сервер был взломан — злоумышленник нашёл эту запись через утечку пароля на другом сервисе. Поскольку система не отличала admin от root, атакующий получил полный контроль. Восстановление заняло три дня, а ущерб превысил $50 000.

Рекомендации по безопасному управлению привилегированным доступом

Безопасность начинается с политики. Вот ключевые принципы, которые должны быть реализованы в любой организации:

• Принцип минимальных привилегий: предоставьте пользователю только те права, которые ему действительно нужны;
• Одна точка доступа: только один легитимный способ получения root-прав (например, через sudo);
• Аудит и мониторинг: все действия с повышенными правами должны логироваться и проверяться;
• Регулярные проверки: проводите аудит учётных записей не реже одного раза в месяц.

Для технической реализации:

1. Отключите прямой вход под root по SSH;
2. Настройте использование sudo с логированием;
3. Внедрите двухфакторную аутентификацию для привилегированных сессий;
4. Используйте PAM-модули для дополнительного контроля;
5. Централизуйте управление доступом через LDAP или IdM (FreeIPA).

Также рассмотрите внедрение Privileged Access Management (PAM) решений, таких как CyberArk, Thycotic или Hashicorp Vault. Они позволяют временно выдавать доступ, шифровать учётные данные и полностью контролировать сессии.

Чек-лист безопасности

• ☐ Проверены все пользователи с UID 0;
• ☐ Отключён вход под root по SSH;
• ☐ Настроено логирование sudo и su;
• ☐ Установлен и настроен auditd;
• ☐ Проведён анализ последних 7 дней логов;
• ☐ Удалены неиспользуемые учётные записи.

Экспертное мнение

Безопасность привилегированных учётных записей — один из самых уязвимых участков в инфраструктуре. Многие компании сосредотачиваются на защите периметра, забывая, что внутренние угрозы не менее опасны. Принцип «доверяй, но проверяй» должен применяться ко всем, включая администраторов.
Автоматизация аудита — ключ к эффективности. Ручные проверки легко пропустить или отложить. Лучше внедрить скрипты, которые ежедневно сканируют систему и отправляют отчёт. Интеграция с системами мониторинга (например, Zabbix или Prometheus) позволяет оперативно реагировать на изменения.
Также важно понимать, что безопасность — это процесс, а не разовое действие. Даже если сегодня всё в порядке, завтра может появиться новая учётная запись. Поэтому контроль должен быть непрерывным, а не эпизодическим.

Вопросы и ответы

Заключение

Определение наличия пользователей с root-правами — обязательная процедура для любого, кто отвечает за безопасность системы. Это не просто техническая проверка, а часть стратегии управления рисками. Используя комбинацию команд, анализа логов и автоматизации, можно своевременно выявлять угрозы и предотвращать инциденты.

• Проверяйте всех пользователей с UID 0 и членов групп sudo/wheel.
• Анализируйте логи аутентификации и активность в реальном времени.
• Отключайте прямой доступ под root, особенно по SSH.
• Автоматизируйте проверки и внедряйте централизованное логирование.
• Соблюдайте стандарты безопасности и проводите регулярные аудиты.