Уязвимость sudo: как доступ к логам стал угрозой безопасности

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

Проблема: отказ в обслуживании на файловом сервере

Пользователи сообщили о невозможности открыть файлы на сетевом ресурсе. Ошибка «Сервер не отвечает. Повторите попытку позже» указывала на классический отказ в обслуживании. Базовые проверки исключили сетевые проблемы: пинг проходил, но SSH-сессии уходили в таймаут. Это означало зависание операционной системы или критической службы, когда процессы перестают выделять ресурсы на новые сетевые подключения.

Диагностика через консоль и первые находки

Физический доступ к консоли подтвердил полное зависание — интерфейс командной строки не реагировал на ввод. После принудительной перезагрузки доступ по SSH восстановился. Первичный анализ журналов через journalctl -xe не показал явных сбоев перед падением, что намекало на постепенную, накопительную проблему.

Утилита top выявила аномалию: загрузка CPU и памяти в норме, но показатель wait I/O для диска был чрезвычайно высоким. Это чёткий сигнал, что какой-то процесс создаёт лавину операций чтения или записи.

Поиск виновника высокой нагрузки на диск

Команда iotop указала на процесс rsyslogd. Активность демона системного логирования в таком объёме ненормальна. Стандартная проверка конфигурации в /etc/rsyslog.conf и /etc/rsyslog.d/ не выявила ошибок. Однако выяснилось, что служба была настроена на дублирование логов на удалённый syslog-сервер, который оказался временно недоступен.

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

[ИЗОБРАЖЕНИЕ: Схема работы rsyslog при недоступности удалённого сервера, показывающая заполнение in-memory буфера и последующий spillover на диск]

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

После устранения проблемы с производительностью началась рутинная проверка целостности логов в /var/log/. Попытка просмотреть файл /var/log/syslog через cat или текстовый редактор не потребовала ввода пароля суперпользователя, что противоречило базовым ожиданиям безопасности.

Проверка прав доступа к файлу показала стандартную для многих дистрибутивов картину:

$ ls -la /var/log/syslog
-rw-r----- 1 syslog adm 1234567 Feb 24 10:00 /var/log/syslog

Права rw-r----- разрешают чтение владельцу (syslog) и членам группы adm. Поскольку диагностику проводил пользователь не из группы adm, проблема лежала глубже — в механизме привилегированного выполнения команд.

Расследование настройки sudoers

Анализ файлов /etc/sudoers и /etc/sudoers.d/ выявил корень уязвимости:

%admin ALL=(ALL) NOPASSWD: /bin/cat /var/log/*, /usr/bin/tail /var/log/*

Эта директива позволяла любому пользователю группы admin выполнять команды cat и tail для любого файла в /var/log/ без ввода пароля. Она полностью обходила дискреционное управление доступом файловой системы, превращая рядового пользователя в «читателя» всех журналов.

Под удар попадали auth.log (история аутентификации), secure, логи веб-серверов и приложений. Это прямое нарушение принципа минимальных привилегий и создание канала для утечки конфиденциальных данных и рекогносцировки.

Риски и последствия уязвимой конфигурации

Такая настройка создавала многоуровневые угрозы:

Утечка чувствительной информации: В логах аутентификации — учётные записи, IP-адреса, время активности. В логах приложений — параметры запросов, внутренние ошибки, фрагменты данных.
Компрометация журналов аудита: Злоумышленник получает возможность отслеживать действия администраторов, подстраивая свою активность, чтобы оставаться незамеченным. Сами журналы аудита теряют доверие.
Подготовка к целевой атаке: Логи позволяют составить карту инфраструктуры: имена серверов, версии ПО, расписания задач, шаблоны поведения админов.
Несоответствие требованиям регуляторов: Для организаций, подпадающих под 152-ФЗ или требования ФСТЭК, неконтролируемый доступ к журналам событий является прямым нарушением требований к защите информации и разграничению доступа.

Особая опасность — отсутствие следов эксплуатации. Поскольку пароль не запрашивается (NOPASSWD), факт доступа не фиксируется в журнале использования sudo (/var/log/auth.log или /var/log/secure).

Устранение и корректная настройка доступа

Первым действием стала отмена опасной директивы. После этого чтение логов вновь потребовало полномочий root. Однако потребность администраторов в удобном доступе остаётся. Есть несколько корректных подходов:

Использование системных групп: Стандартный и наиболее чистый метод — добавление пользователей в группу adm. Это даёт права на чтение файлов в /var/log/ на уровне файловой системы, не затрагивая механизм sudo.
Централизованный сбор и анализ логов (SIEM): Современный подход, отвечающий требованиям регуляторики. Логи агрегируются на выделенный сервер (например, на базе ELK-стека или Graylog). Доступ предоставляется через веб-интерфейс с полноценной аутентификацией, авторизацией и учётом действий.
Точная, ограниченная настройка sudo (если необходимо): Если вариант с группой неприменим, можно создать строгую директиву, избегая wildcards и NOPASSWD.
```
# Более безопасный, но всё же компромиссный вариант
User_Alias LOG_VIEWERS = admin1, admin2
Cmnd_Alias LOG_CMDS = /bin/cat /var/log/syslog, /usr/bin/tail -n 50 /var/log/syslog
LOG_VIEWERS ALL=(ALL) LOG_CMDS
```
В этом случае выполнение команд будет фиксироваться в журнале, так как потребует ввода пароля.

[ИЗОБРАЖЕНИЕ: Таблица сравнения методов доступа к логам: через группу adm, через централизованный SIEM и через sudo. Колонки: Уровень безопасности, Соответствие 152-ФЗ/ФСТЭК, Удобство, Аудит действий]

Выводы для профилактики инцидентов

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

NOPASSWD — враг безопасности: Использование этой директивы должно быть исключительным и жёстко обоснованным, например, для служебных cron-задач. Никогда не применяйте её для команд, дающих доступ к данным.
Wildcards в sudoers — запрещённый приём: Шаблоны вроде /var/log/* размывают границы доступа. Всегда указывайте полные пути к конкретным файлам или командам.
Логи — актив, а не отходы: Относитесь к журналам как к конфиденциальным данным. Их целостность и конфиденциальность требуют той же защиты, что и другие информационные активы.
Диагностика как часть аудита: Расследование любого сбоя — повод для поверхностной проверки конфигурационной безопасности затронутых систем. Инструменты диагностики часто вскрывают побочные уязвимости.
Централизация логирования обязательна: Это не только удобство анализа, но и базовое требование для выполнения многих положений 152-ФЗ и документов ФСТЭК, таких как «Базовый набор мер по защите информации». Она снимает вопрос локального доступа к логам на каждой машине.

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