Практическая демонстрация эффективности СЗИ в ОС Astra Linux

В информационной безопасности или кибербезопасности как и во многих других сферах никогда не утихала дискуссия на предмет поиска «золотой середины» в применении, с одной стороны, основанных на научных теориях технологий, методик, инструментальных средств разработки, эксплуатации и обеспечения доверия к средствам защиты информации (СЗИ) в операционных системах (ОС), системам управления базами данных (СУБД), средствах контейнеризации, виртуализации и др., с другой стороны, базирующихся на использовании аналогичных подходов, но полученных из практического опыта, особенно на примерах эксплуатации уязвимостей или взлома СЗИ. Причём в рассматриваемой предметной области ситуация усугублена наличием еще «третьей точки зрения», исходящей из необходимости во многих случаях выполнения положений достаточно обширной нормативной базы (профильные национальные стандарты, методические документы и требования отечественных регуляторов, нормативные документы конкретных организаций или ведомств), без чего СЗИ не сертифицируешь, критическую информационную инфраструктуру или информационную систему персональных данных не построишь и не аттестуешь.

Поскольку теоретические знания бывают сложны для восприятия и требуют заметных усилий для изучения, а нормативная база объемна и содержит порой сотни и тысячи требований, овладеть которыми тоже непросто, у части специалистов-практиков в области информационной безопасности сложилось восприятие всего этого как некой далекой от реальной жизни «бумажной безопасности». Этой «радикальной» позиции способствовало также то обстоятельство, что сравнительно недавно – всего 15-20 лет назад, действительно, можно было говорить о существенном отставании теории информационной безопасности (к слову, как это часто бывало и с другими «молодыми» науками) от актуального уровня развития технологий, а лучшие практики разработки и обеспечения доверия к СЗИ, которые по сути должны являться источником для закрепления в соответствующих нормативных документах, еще не были накоплены и проанализированы. Кроме того, «ломать не строить» и наглядный пример взлома СЗИ убеждает многих гораздо лучше, чем доказанные теоремы или цитаты из нормативных документов.

Надо признать, что у себя в «Группе Астра» при разработке ОС Astra Linux мы часто сталкиваемся с такой же проблемой, причем не только при обсуждении СЗИ нашей ОС со специалистами из других организаций, но даже внутри самой нашей компании. Рассмотрим сложившуюся ситуацию подробней.

Как мы уже неоднократно рассказывали ранее (например, здесь «Преимущества использования СЗИ в ОС Astra Linux Special Edition» или здесь «Основы безопасности операционной системы Astra Linux Special Edition. Управление доступом»), ОС Astra Linux включает реализованные в ее подсистеме безопасности PARSEC ряд СЗИ собственной разработки. В первую очередь это функционирующий в ее режимах защищенности «Усиленный» («Воронеж») и «Максимальный» («Смоленск») механизм мандатного контроля целостности (МКЦ), который совместно с механизмами замкнутой программной среды (ЗПС),  блокировки интерпретаторов и рядом других призван обеспечивать целостность программной среды ОС, защиту ее привилегированного (высокоцелостного) системного или прикладного программного обеспечения (ПО) от несанкционированного изменения или захвата управления над ним со стороны непривилегированных низкоцелостных процессов нарушителей, даже от имени суперпользователя root. При необходимости защиты от утечки, как правило, конфиденциальных данных в режиме защищенности «Максимальный» («Смоленск») в дополнение к МКЦ работает механизм мандатного управления доступом (МРД).

Научной основой перечисленных СЗИ и механизмов защиты стала получившая начало более полувека назад (подробнее здесь «Формальные модели управления доступом») теория формальных моделей управления доступом, развитая и внедренная в ОС Astra Linux как мандатная сущностно-ролевая ДП-модель управления доступом и информационными потоками в ОС семейства Linux (МРОСЛ ДП-модель). Эта модель описывает ролевое управление доступом (представляющее штатное для ОС семейства Linux дискреционное управление доступом), МКЦ и МРД, отвечает критериям ГОСТ Р 59453.1-2021 «Защита информации. Формальная модель управления доступом. Часть 1. Общие положения», разработана в соответствии с рекомендациями ГОСТ Р 59453.3-2025 «Защита информации. Формальная модель управления доступом. Часть 3. Рекомендации по разработке». Кроме того, будучи представленной в классической математической нотации и в формализованной нотации на языке метода Event-B, модель полностью верифицирована согласно рекомендациям ГОСТ Р 59453.2-2021 «Защита информации. Формальная модель управления доступом. Часть 2. Рекомендации по верификации формальной модели управления доступом».

Сама ОС Astra Linux сертифицирована на соответствие самым высоким классам защиты (уровням доверия) согласно нормативным документам ФСТЭК России и других отечественных регуляторов. Выстроенные в «Группе Астра» процессы разработки ОС как безопасного ПО (РБПО), включая статический и динамический анализ программного кода, устранение уязвимостей и др., также сертифицированы ФСТЭК России на соответствие ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». С научной точки зрения вся эта деятельность ведется в рамках соответствующей методологии (подробнее здесь «Формирование методологии разработки безопасного системного программного обеспечения на примере операционных систем»).

Кроме того, развитие СЗИ в ОС Astra Linux и технологий РБПО никогда не останавливается. Сейчас мы активно проектируем облик СЗИ в перспективном релизе ОС 2027 г. (1.9), где планируем существенно усилить механизм МКЦ, в том числе в сетевой инфраструктуре, механизм контроля подключаемых устройств, и многое другое. Также рассматриваем возможность применения технологий машинного обучения или искусственного интеллекта (ИИ) для повышения эффективности наших СЗИ, например, для выявления вирусов-шифровальщиков в контексте МКЦ или скрытых каналов по времени в контексте МРД. В шутку прототип будущих СЗИ в ОС мы уже назвали «Astra Linux Scientific Edition» (подробнее о результатах прототипирования СЗИ можно прочитать в следующих наших статьях: «Проектирование и развитие механизма мандатного контроля целостности в операционной системе Astra Linux», «Тестирование подсистемы безопасности ОС Astra Linux на основе формализованного описания модели управления доступом», «Подход к применению мандатного контроля целостности в ОС Astra Linux для управления доступом к пользовательским данным»).

Однако все это хорошо, но, как было отмечено в начале статьи, «червь сомнения» может остаться — вдруг эта та самая «бумажная безопасность», а не реальная защищенность. И хотя владение научной теорией тем и полезно, что оно дает возможность заранее предсказывать, обосновывать и быть уверенным в свойствах безопасности создаваемых на ее основе СЗИ в ОС Astra Linux, тем не менее практическая демонстрация их эффективности при защите от актуальных атак на ОС семейства Linux в сравнении с другими дистрибутивами, несомненно, востребована.  Результаты нашего исследования мы представляем далее в статье (сразу отметим, что мы тестировали несколько дистрибутивов ОС семейства Linux, в том числе отечественных, и хотя результаты этого оказались вполне ожидаемыми, по понятным соображениям мы их не публикуем, т. к. желательно, чтобы такое исследование было проведено и представлено независимыми специалистами).

2. Используемый подход к анализу эффективности СЗИ в ОС Astra Linux

Число целевых атак на информационные системы стремительно растет, что подтверждается результатами многих исследований, например, Positive Technologies «От кибершпионажа до идеологически мотивированных атак: APT и хактивисты в 2025 году». В последние годы эти показатели усугубляются в связи с активным использованием хакерами технологий ИИ, что позволяет им обнаруживать новые методы атак или связывать в единый вектор атаки не самые критичные уязвимости, ошибки конфигурации или архитектурные особенности целевых систем. Одним словом, атаки становятся изощреннее, их целью все чаще выступают дистрибутивы ОС семейства Linux, а для российского сегмента это особенно актуально в связи с широким внедрением этих дистрибутивов, в первую очередь в сфере КИИ. 

Одним из наиболее эффективных методов оценки реального уровня защищенности систем является эмуляция противника (нарушителя). Применение такого подхода позволяет:

• Комплексно оценить возможности СЗИ по противодействию типовым техникам и тактикам реализации компьютерных атак;

• Выявлять уязвимые места и набирать базу для проектирования и развития передовых механизмов защиты, способных противодействовать как актуальным, так и перспективным компьютерным атакам.

Именно на основе эмуляции нарушителя мы проводим оценку эффективности собственных СЗИ в ОС Astra Linux, в первую очередь — ЗПС и МКЦ в режимах «Воронеж» и «Смоленск», т. к. именно они выполняют ключевую роль по защите от попыток компрометации ОС за счет повышения привилегий, закрепления и выполнения каких-либо деструктивных действий.

Весь процесс состоит из нескольких основных этапов:

1. Подготовка целевых стендов для тестирования. На этом этапе мы формируем стенды на базе виртуальных машин с актуальными версиями ОС Astra Linux, а также другими дистрибутивами, в частности Debian.

2. Сбор информации о компьютерных атаках. Для этих целей мы анализируем все типовые техники реализации основных этапов компьютерных атак на базе матрицы MITRE ATT&CK, выполняем непрерывный мониторинг информации о произошедших целевых атаках, разбираем отчеты профильных в информационной безопасности организаций,  проводим внутренний пентест ОС, а также сопровождаем программу BugBounty. 

3. Анализ актуальности конкретных техник для ОС Astra Linux. По результатам анализа полученных материалов определяем применяемые нарушителями техники, актуальные для дистрибутивов ОС семейства Linux в целом и ОС Astra Linux, в частности, с учетом особенностей ее архитектуры.

4. Адаптация шагов техник атак и/или PoC под ОС Astra Linux. В случае необходимости для актуальных техник выполняем адаптацию шагов реализации атаки, применяемых эксплойтов, PoC для их запуска в окружении целевой версии ОС. Обеспечиваем автоматизацию каждого из шагов.

5. Воспроизведение векторов атак на подготовленных стендах. Для каждого вектора атаки готовим независимый от конфигурации стенда тестовый шаблон для реализации отдельных шагов, формируем сценарии настройки образов ОС и автоматизируем процесс адаптации шаблонов под них. По мере изменения или наполнения базы тестовых сценариев атак или модификации/расширения тестируемых стендов запускаем прогон всех затронутых связок, в результате чего формируем отчёт с вердиктом об успешности эмуляции атаки и иными артефактами для последующего анализа. Такой подход позволяет нам в том числе отслеживать поведение системы на каждом из этапов реализации атак, гибко изменять конфигурацию СЗИ и определять эффективность как отдельных механизмов защиты, так и их совокупного применения.

6. Оценка результатов атак и формирование предложений по развитию СЗИ в ОС Astra Linux. Исходя из полученных результатов делаем выводы о текущем состоянии СЗИ, эффективности их применения для нейтрализации тех или иных видов угроз, тактик и техник атак, а также готовим предложения о способах минимизации поверхности атаки и путях развития собственных СЗИ в ОС Astra Linux.

В качестве основных стендов для тестирования нами используются следующие дистрибутивы ОС и их конфигурации:

• «Astra Linux SE (МКЦ)» - дистрибутив ОС Astra Linux (1.8.6), в котором механизм МКЦ включен в режиме по умолчанию;

• «Astra Linux SE (МКЦ+ЗПС+MDWE)» - дистрибутив ОС Astra Linux (1.8.6), в котором включены механизм МКЦ в режиме по умолчанию и механизм ЗПС в режиме проверки встроенной подписи ELF-файлов, а также включен механизм MDWE (Memory-Deny-Write-Execute) в режиме запрета маппинга страниц памяти для записи и исполнения;

• «Astra Linux Scientific Edition (Расширенный МКЦ)» - дистрибутив ОС Astra Linux (1.8.6), в котором механизм МКЦ включен в расширенном режиме (у нас он также называется «strict mode»). Данный дистрибутив содержит доработки СЗИ, в первую очередь МКЦ, осуществленные силами Департамента науки «Группы Астра» в рамках подготовки перспективного релиза ОС 2027 г. (1.9). При этом, чтобы протестировать защитные свойства именно доработанного МКЦ, в этом дистрибутиве специально выключен механизм ЗПС;

• «Debian (CIS Benchmarked)» - дистрибутив ОС Debian 12, настроенный в соответствии с рекомендациями по безопасной настройке CIS Benchmarked по 2 уровню.

Отдельно обратим внимание на важный момент: в большинстве проводимых экспериментов мы исходим из предположения, что нарушитель уже реализовал один или несколько начальных этапов компьютерной атаки, включая получение первичного доступа к целевой ОС (например, через эксплуатацию уязвимостей в веб-сервисе или другом прикладном ПО) с полномочиями непривилегированного пользователя, системной учетной записи или даже суперпользователя root (на уровне целостности «Низкий» или 0). Это весьма существенное допущение. Однако оно является ключевым в контексте оценки защищенности и эффективности СЗИ в ОС Astra Linux, т. к. они призваны обеспечивать дополнительную эшелонированную защиту и стойкость к атакам даже со стороны классического для дистрибутивов ОС семейства Linux суперпользователя root.

3. Пример отражения СЗИ в ОС Astra Linux атаки GoblinRAT

В рамках изложенного подхода оценим возможности рассматриваемых стендов по противодействию полной компрометации ОС на примере одной из нашумевших в 2025 г. целевых атак на информационные системы с применением бэкдора GoblinRAT. Разбор атаки мы проводили, опираясь на опубликованный отчет «Неуловимый GoblinRAT – история самого скрытного и загадочного бэкдора для Linux, обнаруженного в государственных инфраструктурах» Центра исследования киберугроз Solar 4RAYS, а также на ряд других источников.

Цепочка реализации атаки на основе GoblinRAT представлена на схеме:

Бэкдор GoblinRAT использовался в самых скрытных атаках, которые довелось расследовать Solar 4RAYS. Вредоносная активность длилась более двух лет, за этот период были заражены инфраструктуры нескольких российских компаний. Основная часть функциональности GoblinRAT решает единственную задачу – скрывать присутствие вредоносного программного обеспечения (ВПО) в ОС. Для коммуникации с С2-сервером (командным центром) GoblinRAT использовал взломанные сайты легитимных организаций и DDNS. При этом почти каждый найденный исполняемый файл содержал уникальный адрес. Создатели данного ВПО были весьма оригинальны: для каждого нового зараженного хоста атакующие применяли уникальные названия задач планировщика, файлов, библиотек и служб для закрепления в целевой ОС, а отличительной особенностью GoblinRAT являлось мимикрирование под ее процессы.

В проводимом нами исследовании для эмуляции функционала GoblinRAT мы использовали два типа закрепления с мимикрией под легитимный zabbix-агент:

• через cron путем добавления задачи zabbix_agent_cron.sh;

• через systemd путем создания поддельного сервиса zabbix-agentd.

Также нами был частично реализован функционал C2-сервера и клиента, использующих технологию Port Knocking, как это и было представлено в реализации GoblinRAT.

В результате тестирования вектора атаки GoblinRAT на подготовленных стендах можно сделать следующие выводы. ОС Debian без применения дополнительных СЗИ не обеспечивает возможность нейтрализации этой атаки, в то время как в ОС Astra Linux механизм ЗПС (в том числе в совокупности с механизмом блокировки интерпретаторов) обеспечивает невозможность запуска эксплойта нарушителем для повышения привилегий с целью последующего закрепления в системе, а механизм МКЦ не позволяет реализовать это закрепление в системе за счет того, что даже при успешной попытке «классического» повышения привилегий чаще всего нарушитель получает права лишь низкоцелостного суперпользователя root (с уровнем целостности 0), что не позволяет ему в дальнейшем разместить необходимые для закрепления файлы в высокоцелостных каталогах (с уровнем целостности max_ilev, который по умолчанию равен 63). Т. е. попытки закрепления в ОС как через cron-задачу, так и через systemd-сервис, успешно блокируются механизмом МКЦ:

В тех случаях, когда механизм МКЦ отключен или скомпрометирован, работу GoblinRAT на различных этапах парализует механизм ЗПС:

модуль безопасности digsig блокирует запуск ВПО, доставленного в целевую ОС:

механизм блокировки интерпретаторов исключает возможность сбора информации об ОС:

запрет на установку бита исполнения исключает возможность запуска в целевой ОС клиента ВПО (RAT-клиента):

Таким образом, на примере анализа и частичной эмуляции функционирования одного из самых скрытных и изощренных бэкдоров, нацеленных на компрометацию ОС семейства Linux, можно сделать вывод о том, что комплекс СЗИ в ОС Astra Linux способен успешно справляться с современными угрозами компрометации информационных систем.

4. Текущие результаты исследования

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

В результате проведенных исследований и экспериментов в каждом конкретном случае рассматривалась эффективность СЗИ в ОС Astra Linux при противодействии векторам атак. Обобщенные результаты представлены в таблице:

Более подробная информация о результатах исследования приведена в следующей таблице:

Исходя из результатов тестирования целесообразно отметить следующие выводы в части применения механизмов защиты ОС Astra Linux для борьбы с целевыми атаками на ОС семейства Linux:

• успешное проведение некоторых атак сейчас может предотвратить только механизм ЗПС;

• в большинстве случаев механизм ЗПС «рубит» атаку на корню, однако, если ЗПС выключен или скомпрометирован, то предотвратить дальнейшую реализацию атаки может механизм МКЦ;

• механизм ЗПС может предотвращать проведение нарушителем рекогносцировки в ОС, которая обычно не приводит к генерации никаких индикаторов компрометации, однако является важным шагом проведения атаки;

• механизм МКЦ нивелирует возможности классического закрепления через cron или systemd, а расширенный режим функционирования МКЦ («strict mode») в «Astra Linux Scientific Edition» позволяет предотвратить более изощренные методы закрепления в ОС.

Результаты исследования демонстрируют важность применения эшелонированной защиты, т. к. ряд механизмов либо имеет ограничения по их применению, либо, как и любое ПО, могут содержать уязвимости. Там, где ЗПС не обеспечивает защиту, например, от попыток компрометации уже запущенного процесса (из исполняемого файла с корректной цифровой подписью), свою роль выполняет МКЦ, задача которого и состоит в том, чтобы запретить процессам с низким уровнем целостности влиять (негативно воздействовать, модифицировать) на системные компоненты (процессы, файлы) ОС. При этом использование комплекса СЗИ позволяет предотвратить достижение целей нарушителей даже если первоначальные шаги целевой атаки удалось успешно реализовать.

Так, например, помимо приведенных выше стендов и векторов атак, мы тестируем сценарии, доработанные с учетом выявляемых проблем в реализации наших СЗИ в результате проведения внутреннего пентеста или программы BugBounty. Такой подход дает нам объективную оценку стойкости разрабатываемых СЗИ, позволяет наметить пути их развития, или спроектировать новые СЗИ для противодействия актуальным или перспективным компьютерным атакам. Примером этому служит как раз исследуемый стенд «Astra Linux Scientific Edition», в рамках которого с учетом проведенных испытаний были проведены доработки механизма МКЦ, что позволило обеспечить его дополнительную стойкость к 4 целевым атакам, предотвратить которые ранее можно было лишь в условиях одновременного применения МКЦ и ЗПС.

5. Направления дальнейших исследований

Следует отметить, что разработанный нами и описанный в статье комплекс стендов для тестирования может быть нацелен не только на исследования компьютерных атак на базовые системные компоненты ОС. Он позволяет проверять эффективность СЗИ для нейтрализации угроз безопасности, направленных на СУБД, средства контейнерной виртуализации, веб-серверы и др. Исходя из этого, мы считаем целесообразным пополнять комплекс стендов для тестирования новыми их конфигурациями, как на базе ОС Astra Linux в связке с другими продуктами «Группы Астра», так и с использованием других дистрибутивов ОС семейства Linux. Также в наших планах провести исследования эффективности СЗИ в ОС Astra Linux как доверенной агентной ОС, обеспечивающей безопасное функционирование, управление и изоляцию ИИ-агентов (а также ИИ-моделей, ИИ-инструментов), их данных и ресурсов на основе уровней доверия (целостности). Кроме того, мы хотим продолжить расширять перечень исследуемых векторов атак, проведя комплексное сопоставление возможностей СЗИ в ОС Astra Linux с тактиками и техниками атак по базе матрицы MITRE ATT&CK. По результатам этого предполагаем апробировать и проверять состоятельность новых идей по развитию применяемых в наших СЗИ технологий и научных теорий. Все перечисленное обеспечит объективность и прозрачность наших экспериментов, т. е., как мы рассчитываем, позволит окончательно избавиться от мифа о «бумажной безопасности», будет и далее демонстрировать реальную эффективность собственных СЗИ в ОС Astra Linux.