Добрый день, дорогие читатели!

В прошлой статье мы разбирали, как настраивать сканирование Windows-активов. Сегодня же мы разберемся с Linux-активами. Поговорим о вариантах настройки учетных записей для Аудита, о правах для сканера. И по традиции проведем эксперименты.

Да, для проведения Аудита Linux можно воспользоваться обычной УЗ без привилегий. Собственно, создаем локальную/доменную УЗ, и уже можно вытягивать базовые данные об активе. В MPVM задача на Аудит без привилегий выглядит так:

Идея в следующем: создается УЗ с пользовательскими правами. Для неё есть подготовленный .bash_profile. В домашнем каталоге создается каталог mpx, в него копируется каталог bin из комплекта поставки для конкретной ОС. В bin лежат подготовленные sh-скрипты для проведения аудита. Для УЗ прописываются алиасы команд в sudoers на выполнение без пароля (без пароля это важно, об этом в разделе su). Вендор не приводит в документации примеров скриптов, вот и я не буду, вдруг это ком.тайна.

В комплекте поставки предоставляются эти скрипты под каждую ОС. По идее, эти скрипты должны быть для каждой поддерживаемой ОС, но цитировать комплект поставки я, опять же, не буду. Читатели могут самостоятельно сравнить его со списком поддерживаемых ОС.

Спойлер: не для каждой Linux-ОС есть скрипты-обертки.

Вендор предлагает нам 3 варианта, как раскатить эти самые обертки:

1. Ansible playbook.

2. Автонастройка с помощью скрипта на Python.

3. Настройка вручную.

Лично для себя я выделяю следующие недостатки этого метода:

• Сложность раскатки. Все, кто хотя бы раз запускал Ansible-плейбук на инфру 1000+ разношерстных Linux-активов, меня поймут. Если в организации нет сотрудников, которые умеют в Ansible, либо же они, как обычно, смертельно заняты, то уровень головной (и на полметра ниже) боли стремится к бесконечности.

• Постоянный аудит и поиск активов, куда эти скрипты не доехали. Это тот самый метод аудита, который я называю «чудом», кто-то употребляет «случайно наткнулись», но обычно все говорят матом. Особенно актуально с Linux-АРМами.

• Убирают возможность использовать собственные скрипты расширения аудита.

• Вендор крайне редко их обновляет. А если обновит - раскатывайте заново, что логично. В 2026 году дата обновления этих скриптов - 2026 год. А в 2025 году - 2024 год.

В MPVM задача на сканирование будет выглядеть так же, как и для пользовательской УЗ. Если где-то на этапе раскатки скриптов что-то пошло не так, то возвращаемые данные = данные от Аудита под пользовательской УЗ.

В общем и целом - не рекомендую.

Здесь опять начинается диалог о предоставлении абсолютных прав сканеру. Мы это уже проходили в ч.2. Повторюсь только в моменте, что чем больше данных знает сканер->безопасник, тем лучше.

Если Ваш sudoers для сканирующей УЗ выглядит так:

<имя_УЗ/%имя_группы> ALL=(ALL:ALL) NOPASSWD: ALL

То для сканирования с повышением через sudo без пароля достаточно будет создать в MPVM УЗ типа «логин-пароль» или «сертификат». Задача в MPVM будет выглядеть так:

Если Ваш sudoers для сканирующей УЗ выглядит так:

<имя_УЗ/%имя_группы> ALL=(ALL:ALL) ALL

То для сканирования с повышением через sudo нужно создать в MPVM УЗ типа «логин-пароль» или «сертификат» и УЗ типа «пароль». Где в «пароль» нужно будет задублировать, собственно, сам пароль сканирующей УЗ. Почему нельзя при создании задачи выбрать ту же УЗ типа «логин-пароль», но просто взять от неё пароль, отбросив логин на уровне кода - вопрос к вендору.

Потом, когда будете пароли менять, нужно не забыть поменять и в дубле.

А в MPVM задача на Аудит будет выглядеть так:

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

Если вдруг, где-то права на sudo не назначены, то ищите запись в логах:

Произошла ошибка sudo. Не удалось запустить скрипт. Пожалуйста, обратитесь в службу технической поддержки.

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

• Переключение на УЗ, для которой настроено повышение привилегий через sudo без пароля, в частности на УЗ с sudo-обертками.

• Классическое переключение на УЗ root.

C переключением на УЗ, для которой настроены обертки, всё понятно - ещё бОльшее усложнение и так сложного механизма раскатки скриптов. А так идея, что под сканирующим пользователем явно не выполняется вход по ssh, - у неё ведь есть права на sudo. УЗ с правами на ssh выполняет команду «su - <сканирующая_УЗ>», и уже под этим пользователем выполняется Аудит с правами на sudo без пароля. sudo именно без пароля, т.к. у MPVM техническое ограничение на использование в модуле сканирования одновременно su и sudo.

Для sudo-оберток важно использовать именно «su_minus» (su - , su --login), т.к. нам нужно будет перечитать переменные окружения и .bash_profile. Не зря же мы его размещали в домашнем каталоге пользователя. Да и $HOME/mpx/bin нужно правильно найти.

А по поводу классического переключения на root… У Вас на всех серверах одинаковый пароль от root? Что будете делать, если пароль не совпадёт? Вы его вообще меняете? Может Вы еще под root по ssh ходите? Стоп-стоп, не рассказывайте, я не желаю это знать, я хочу жить в мире розовых пони и харденинга. Давайте вместе отвлечемся от плохих мыслей о бренности бытия и полюбуемся, как спит моя кошка:

Продолжаем любимую рубрику моего детства.

Сегодня мы эмпирическим путём выясним какой же метод дает нам наиболее полные данные по Аудиту из коробки (т.е. не берем в расчёт расширения аудита). Посмотрим какой объем данных нам приходит, и какое количество уязвимостей рассчитает сканер.

Проверяем 3 способа:

• без привилегий, т.е. обычная пользовательская УЗ;

• скрипты-обертки (sudo-обертки);

• повышение привилегий до root (sudo/su нам без разницы).

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

И так, по традиции берем случайно выбранный Linux-актив (мой), который я буду сканировать Аудитом. Важное замечание: для эксперимента я использую свежеустановленную, голую ОС, без какого-либо прикладного ПО. На продуктивных серверах количество блоков может быть больше. Результаты рубрики приведены в таблице:

Очень хочется увидеть подобную информацию от вендора.

И так, если Вы не используете MPVM для бесконечных ИТ-аудитов, не используете модуль HCC, то чтобы организовать базовый VM-менеджмент для Linux, достаточно УЗ без прав администратора. Но лично я всегда требую права администратора. Для нас очень критично из-под sudo вытягивать список служб. К примеру, могу поделиться запросом по контролю состояния служб АВПО Kaspersky на Linux:

select(@LinuxHost, LinuxHost.@AuditTime, LinuxHost.Daemons.Name, LinuxHost.Daemons.Autostart, LinuxHost.Daemons.StartedNow) | filter(LinuxHost.Daemons.Name in ['klnagent64','lightagent', 'kesl']) | calc(if LinuxHost.Daemons.StartedNow = True and LinuxHost.Daemons.Autostart = True then 'ОК' else 'Не ОК' as "Состояние службы") | filter("Состояние службы" = "Не ОК") | sort(@LinuxHost ASC)

Зачем мы туда полезли? Затем, что консоль KSC Вам не покажет, где и состояние какой службы disabled. А значит, после перезагрузки узла, служба не запустится. Да, саму службу АВПО можно запустить руками из консоли. А что будете делать, если не включится служба агента администрирования? Управление с KSC Вы потеряли, а логи в SIEM от auditd идут (пример). Как оперативно Вы это заметите? Уверены, что по этим службам есть алерты в Zabbix, и мониторинг их не игнорирует? Это вновь история про аудиты, которые я называю «чудом», кто-то употребляет «случайно наткнулись», но обычно все говорят матом. И службы АВПО всего лишь частный случай с полей войны за безопасность инфраструктуры.