Ваш sudo не так безопасен, как вы думаете — вот где всё идёт не так

Руководство для системных администраторов по пониманию внутреннего устройства sudo, распространённых ошибок конфигурации и методов усиления безопасности.

Вы думаете, что ваша система защищена, потому что никто не использует root, а все работают только через sudo. Подумайте ещё раз!

Злоумышленникам не нужно взламывать sudo, чтобы получить доступ к root. Использовать sudo безопаснее, чем работать напрямую под root, но неправильная конфигурация всё равно может предоставить злоумышленникам те же самые возможности.

Большинство пользователей Linux воспринимают sudo как «слово, которое мы ставим перед командой, когда нам нужны права root». Но за кулисами sudo — это нечто большее. Понимание того, как работает sudo, помогает разобраться, как Linux контролирует выполнение привилегированных действий и как сохранить этот контроль безопасным.

В этой статье мы разберём, как sudo работает на самом деле, где он может стать небезопасным и как исправить распространённые ошибки конфигурации.

Что такое sudo?

sudo (Subuser Do) — это команда, которая позволяет обычному пользователю выполнять определённые команды с повышенными привилегиями (обычно от имени суперпользователя/root), не входя в систему под пользователем root.

sudo выполняет четыре действия в указанном порядке:

1. Аутентификация — подтверждает, кто мы есть.
2. Авторизация — проверяет, разрешено ли нам выполнять эту команду.
3. Повышение привилегий — запускает команду с временными правами администратора.
4. Аудит — записывает, что мы сделали (логи).

Такое разделение сделано намеренно и имеет критическое значение. Вместо того чтобы сразу предоставлять полные права root, sudo выполняет проверки одну за другой. Это снижает вероятность ошибок и усложняет получение административного доступа без соответствующего разрешения.

Аутентификация PAM

Первое, что делает команда sudo, — это проверяет, кто мы. Она задает простой вопрос:

«Действительно ли этот пользователь является тем, за кого себя выдаёт?»

Для решения этой задачи sudo использует PAM, что расшифровывается как Pluggable Authentication Modules.

Что такое PAM?

PAM — это система Linux, которая отвечает за аутентификацию. В зависимости от того, как настроена система, PAM может требовать:

• Наш пароль (не пароль root)
• Действительную учётную запись
• Доступ только в определённое время
• Многофакторную аутентификацию (OTP или аппаратный ключ)
• Корпоративные системы входа, такие как LDAP, Active Directory или Kerberos.

Файл конфигурации PAM

PAM использует файлы конфигурации, чтобы определить, как должна выполняться аутентификация для различных программ. Для каждого сервиса существует отдельный файл конфигурации, который хранится в:

/etc/pam.d/

Для sudo используется файл:

/etc/pam.d/sudo

Этот файл сообщает PAM, какие проверки необходимо выполнить, когда кто-то использует sudo. Можно представить его как контрольный список, которому следует PAM, когда sudo спрашивает: «Можешь подтвердить этого пользователя?»

# Example /etc/pam.d/sudo file
#%PAM-1.0
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth

# Allow users in the "wheel" group to execute sudo without a password
# auth       sufficient   pam_wheel.so trust group=wheel

• auth include system-auth — указывает PAM использовать правила аутентификации, определённые в /etc/pam.d/system-auth, для проверки пароля пользователя.
• account include system-auth — проверяет, является ли учётная запись пользователя действительной (например, не истёк ли срок её действия и не заблокирована ли она).
• password include system-auth — отвечает за смену пароля при необходимости (обычно sudo напрямую этот механизм не использует)
• session include system-auth — управляет созданием и завершением сеанса, например записью в логи момента начала и окончания сеанса.
• pam_wheel.so (опционально) — если не закомментировано, позволяет участникам определённой группы (например, wheel) выполнять sudo без ввода пароля.

Поведение аутентификации можно изменить, отредактировав файл конфигурации PAM, не изменяя сам sudo.

Авторизация через sudoers

PAM подтверждает, кто мы, но не принимает решение о том, что нам разрешено делать.

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

Политика Sudoers

Политика sudoers — это набор правил, который определяет, кому разрешено выполнять какие команды с повышенными привилегиями. Эти правила хранятся в:

/etc/sudoers      # main sudoers configuration
/etc/sudoers.d/   # extra rule files

Эти файлы определяют:

• Какие пользователи или группы могут использовать sudo
• Какие команды они могут выполнять
• От имени какого пользователя они могут выполнять команды (root или другой учётной записи)
• Требуется ли ввод пароля?
• Особые ограничения или лимиты

# Example of sudoers policy
# Allow a user full sudo access
alice ALL=(ALL) ALL 

# Allow a user to run only one command
bob ALL=(root) /usr/bin/systemctl restart nginx 

# Allow a group sudo access
%devops ALL=(ALL) ALL 

# No password required
carol ALL=(root) NOPASSWD: /usr/bin/docker ps

Логирование для обеспечения безопасности и расследования инцидентов

По умолчанию sudo записывает информацию в системный сервис логирования, что делает его безопаснее и удобнее для отслеживания действий, чем использование su или прямой вход под пользователем root. По умолчанию sudo записывает в логи:

• Кто выполнил sudo
• С какого терминала (TTY)
• Рабочий каталог пользователя
• Целевого пользователя
• Точную команду
• успешное или неуспешное выполнение
• временную метку.

# Log example
Feb 12 10:15:22 server1 sudo:  alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update

• alice — пользователь, запустивший команду sudo
• TTY=pts/0 — используемый терминал
• PWD=/home/alice — каталог, в котором была выполнена команда
• USER=root — команда была выполнена от имени root
• COMMAND=… — точная команда, которая была выполнена

Эти логи хранятся в системных файлах логов, например:

/var/log/auth.log    # Debian/Ubuntu
/var/log/secure      # RHEL/CentOS
journalctl -u sudo   # systemd

Почему логирование важно

Логирование создаёт чёткую историю административных действий. Когда sudo записывает команды в логи, мы можем точно увидеть, что было сделано и кем. Это помогает:

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

Расширенное логирование sudo: запись сеанса

По умолчанию sudo записывает в логи только информацию о том, какая команда была выполнена. Но он не записывает всё, что происходило во время выполнения этой команды.

Параметры log_input и log_output позволяют записывать весь сеанс sudo. Это означает, что мы можем увидеть:

• что вводил пользователь
• что система выводила в ответ
• работу интерактивных команд
• пошаговую терминальную активность

Это позволяет впоследствии воспроизвести весь сеанс для проведения аудитов и расследования инцидентов.

Defaults log_input, log_output # In sudoers
# or
user ALL = (ALL) LOG_INPUT: LOG_OUTPUT: /bin/bash # per command

Ошибки при использовании sudo, которые приводят к риску

sudo разработан так, чтобы быть безопаснее, чем использование учётной записи root, но неправильная конфигурация может превратить его в источник угрозы безопасности. Во многих реальных инцидентах проблема возникает не потому, что sudo имеет уязвимости, а потому, что его настройки выполнены неправильно.

1. Предоставление полного доступа через sudo слишком большому числу пользователей

%developers ALL=(ALL) ALL

Это предоставляет всем пользователям группы полные права root. Такая настройка практически сводит на нет ту защиту, которую должен обеспечивать sudo. Предоставляйте только те команды, которые действительно необходимы пользователям.

2. Разрешение на выполнение всех команд, когда нужна только одна

bob ALL=(ALL) ALL

Если пользователю требуется только перезапуск сервиса, не предоставляйте ему полный доступ. Ограничьте правило только этой командой.

3. Слишком широкое использование подстановочных символов

alice ALL=(root) /usr/bin/systemctl *

Подстановочные символы могут разрешить выполнение большего количества команд, чем мы ожидаем. Пользователь может использовать непредусмотренные параметры, которые приведут к злоупотреблению привилегиями. Используйте * в правилах команд с особой осторожностью.

# It opens a text editor (like vim or nano) to modify service files
sudo systemctl edit any-service.service        

# Run service that executes a reverse shell or adds a new admin user
sudo systemctl enable /home/alice/hack.service 
sudo systemctl start hack    

4. Использование NOPASSWD без серьёзной причины

carol ALL=(root) NOPASSWD: ALL

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

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

carol ALL=(root) NOPASSWD: /usr/bin/systemctl restart apache2

Установите небольшой таймаут sudo-ticket: Вместо полного отключения запроса пароля можно уменьшить время действия отметки аутентификации, чтобы sudo чаще запрашивал пароль.

Defaults timestamp_timeout=1

5. Разрешение запуска опасных программ с помощью sudo

Некоторые программы могут выйти в shell:

• редакторы (vim, nano)
• пейджеры (less, more)
• Инструменты для написания скриптов (Python, Perl, Bash)

bob ALL=(root) /usr/bin/vim

Из Vim пользователь может выполнить :!bash и получить root shell.

6. Отсутствие проверки логов sudo

Логирование sudo полезно только в том случае, если логи регулярно анализируются. Игнорирование логов означает пропущенные предупреждающие сигналы и задержку реагирования на инциденты.

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

7. Редактирование /etc/sudoers напрямую

Всегда используйте команду visudo для редактирования /etc/sudoers, так как она проверяет синтаксис перед сохранением. Поврежденный файл sudoers может заблокировать административный доступ.

visudo

8. Аутентификация PAM является слабой

Аутентификация PAM является слабой, когда система разрешает короткие, простые или легко угадываемые пароли, что делает её уязвимой для атак методом перебора или словарных атак. Во многих системах также отсутствуют дополнительные проверки, что означает, что одного действительного пароля может быть достаточно для получения доступа sudo в любое время и в любом месте.

Как обеспечить надежную аутентификацию и дополнительные меры защиты:

• Используйте надежные пароли (с помощью pam_pwquality)
• Блокируйте учетные записи после неудачных попыток входа (с помощью pam_faillock)
• Используйте более надежное хеширование (SHA-512 или yescrypt)
• Включите дополнительные проверки PAM, такие как многофакторная аутентификация (MFA) / одноразовый пароль (OTP) для дополнительного фактора аутентификации, аппаратные ключи безопасности (например, YubiKey), ограничения времени входа или ограничения сессий.

9. Дополнительные модули PAM

В конфигурации PAM каждое правило имеет управляющий флаг, например:

required
requisite
sufficient
optional

Если надежная проверка (например, многофакторная аутентификация) отмечена как optional, sudo все равно может разрешить доступ, даже если эта проверка не пройдена или была пропущена.

10. Неправильный порядок PAM

Правила PAM обрабатываются сверху вниз. Порядок имеет значение. Если более слабые проверки выполняются первыми и успешно, то более сильные проверки позже могут никогда не выполниться. Пример риска:

• Базовая проверка пароля пройдена успешно
• Проверка MFA выполняется слишком поздно
• Доступ предоставляется до того, как MFA будет проверена

11. Логи хранятся только локально

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

• удалить файлы логов
• изменить записи логов
• очистить логи
• отключить сервисы логирования
• выполнить ротацию логов раньше времени, чтобы скрыть активность

Отправляйте логи sudo на другой сервер в реальном времени (сервер syslog, SIEM или сборщик логов). Даже если локальная машина будет скомпрометирована, логи уже будут надежно сохранены в другом месте.

Заключительные мысли

sudo безопаснее, чем использовать учетную запись root напрямую, но это не гарантирует полной безопасности. Безопасность зависит от трех факторов:

• Надежная аутентификация PAM
• Строгие правила для sudoers
• Корректное логирование

Когда эти элементы работают вместе, sudo становится мощным механизмом обеспечения безопасности. Когда они настроены слишком свободно или игнорируются, они становятся скрытым риском.

В этой статье мы рассмотрели, как sudo создает уровень защиты с помощью PAM, правил sudoers и аудита логов. Мы также рассмотрели распространенные ошибки, которые могут ослабить эту защиту.

Спасибо за чтение! Надеюсь, эта статья поможет лучше понять, как работает sudo и как правильно обеспечить его безопасность. Учитесь, делитесь, вносите свой вклад!