Блокировка интерпретаторов astra linux что это

Блокировка консоли astra-console-lock в Astra Linux. Разбор.

В предыдущей статье мы изучили на практике способ обхода блокировки консоли (astra-console-lock) операционной системы Astra Linux 1.7 для запуска произвольных shell-команд.

Сегодня я предлагаю разобрать данный механизм за пределами команды astra-console-lock, так как по сути это всего лишь вершина айсберга.

Итак, после запуска команды astra-console-lock enable автоматически производится несколько действий:

1. В каталоге /etc/systemd/system создаётся юнит systemd — astra-console-lock.service, его задача запускать astra-console-lock каждый раз после старта системы;

2. Если отсутствует, создаётся группа astra-console и в неё автоматически включаются члены группы astra-admin;

3. В файл /etc/security/access.conf добавляется строчка:

-:ALL EXCEPT astra-console :LOCAL

Собственно, в этой строчке «магия», которая не пускает Вас войти в учётную запись с использованием комбинаций клавиш F1-6 + Alt + Ctrl .

Изучив файл /etc/security/access.conf , Вы увидите подробное описание работы таблицы управления доступом входа в систему (Login access control table в оригинале). Если смотреть ещё глубже, указанная таблица — это часть механизма pam_access.so.

Итак, знак минус в начале строки — это «запретить», ALL — всем, EXCEPT кроме astra-console — группа -исключение, LOCAL — правило будет действовать только для локальных пользователей.

4. Оставшаяся часть «магии» ограничивается правами доступа — для всех терминалов и псевдотерминалов, размещённых в каталоге /dev/ , назначается группа astra-console, а каталог /dev/pts становится доступен только для владельца и группы astra-console.

Таким образом, после настройки пользователи не смогут использовать консоль ни в графическом режиме, ни с помощью комбинаций клавиш F1-6 + Alt + Ctrl.

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

Выводы:
Данный механизм создаёт группу astra-console, настраивает pam_access.so (изменяя его конфигурационный файл access.conf), ограничивает права доступа к терминалам и псевдотерминалам.
Указанную настройку возможно провести на любом другом дистрибутиве Linux и она будет работать аналогичным образом (что и рекомендую сделать).

Волшебная таблетка, или Централизованная настройка параметров безопасности ОС Astra Linux с помощью ALD Pro

Привет, Хабр! Я инженер в «Группе Астра» из команды ALD Pro. В статье расскажу, как мы создали расширенные групповые политики и инструмент для их применения на базе существующего механизма групповых политик ALD Pro. Благодаря этому получилось упростить настройку конечных рабочих мест и соблюсти требования по информационной безопасности.

Статья будет интересна системным администраторам или администраторам безопасности, которые работают с ОС Astra Linux SE и которым нужно привести доменные компьютеры в соответствие требованиям ФСТЭК России.

План хорош, но есть одно но

Как известно, не пускать нарушителя в инфраструктуру всегда проще, чем выгонять. Поэтому к государственным органам, организациям с госучастием, банкам, операторам связи, а также операторам персональных данных и другим подобным организациям со стороны ФСТЭК России предъявляются дополнительные требования по реализации мер защиты. Они регулируются нормативными актами.

«Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» (утв. приказом ФСТЭК России 11.02.2013 г. №17),
«Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» (утв. приказом ФСТЭК России от 18.02.2013 г. №21),
«Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» (утв. приказом ФСТЭК России от 25.12.2017 г. №239),
«Требования к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды» (утв. приказом ФСТЭК России от 14.03.2014 г. №31).

Несмотря на множество требований, в «Реестре российского программного обеспечения» Минцифры России есть продукты, которые им соответствуют. Одно из таких решений — операционная система Astra Linux Special Edition. Эта сертифицированная ОС со встроенными средствами защиты информации закрывает указанные потребности по защите от несанкционированного доступа, предлагая сотни параметров безопасности. С их помощью администраторы могут настроить окружение пользователей под любые потребности организаций. Чтобы ориентироваться в многообразии настроек, мы разработали методические рекомендации и поддерживаем в актуальном состоянии соответствующие разделы сайта wiki.astralinux.ru

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

Импортируем дополнительные параметры групповых политик по взмаху одного скрипта

Следуя поговорке «Критикуешь — предлагай, а предлагаешь — действуй», для решения задачи с централизованной настройкой рабочих мест сделали в службе каталога ALD Pro механизм групповых политик, который работает по модели «pull», как в Active Directory. Агентская часть сама извлекает из LDAP-каталога необходимые ей параметры в соответствии с положением компьютера и пользователя в иерархии структурных подразделений, выполняет суммирование параметров и применяет их с использованием системы управления конфигурациями SaltStack — такое архитектурное решение позволило существенно снизить нагрузку с сервера, обеспечило высокую масштабируемость и упростило расширение набора доступных параметров. Вместе с продуктом «из коробки» поставляются сотни параметров групповых политик для настройки всех ОС Astra Linux. Системным администраторам доступны также инструменты для разработки собственных параметров — с их помощью можно централизованно управлять любым ПО, в том числе и расширенными настройками безопасности.

Для того чтобы привести доменные компьютеры в соответствие требованиям ФСТЭК России, продуктовой командой были разработаны четыре десятка дополнительных параметров групповых политик. Их можно импортировать в систему выполнением всего одного bash-скрипта import.sh:

$ cat import.sh # Импорт групповых политик sh import_folder_common.sh sh import_folder_security.sh sh import_parameter_common_firefox_policy.sh sh import_parameter_common_source_list.sh sh import_parameter_common_packages.sh sh import_parameter_sec_auth_1_auto_login_enable.sh sh import_parameter_sec_auth_1_auto_re_login.sh sh import_parameter_sec_auth_1_no_pass_enable.sh sh import_parameter_sec_auth_1_preselect_user.sh sh import_parameter_sec_auth_5_max_logins.sh sh import_parameter_sec_auth_6_screen_lock_user.sh sh import_parameter_sec_auth_6_screen_lock.sh sh import_parameter_sec_auth_6_show_info_user.sh sh import_parameter_sec_auth_6_show_info.sh . 

Скрипт импорта каждого отдельного параметра является вызовом Python-утилиты policy.py, которая обращается к бэкенду ALD Pro через REST API. Скрипт позволяет задать имя параметра, место его расположения, подробное описание для справки, набор атрибутов, имя скрипта и комментарий:

python3 policy.py parameter add \ --host \ --id 'rbta_ldap_custom_gp_host_sec_auth_6_screen_lock' \ --name 'Блокировка экрана после бездействия' \ --parent-folder 'Авторизация' \ --description 'Позволяет централизованно настраивать блокировку экрана после бездействия, изменяя значения параметров секции [Variables] в файле /usr/share/fly-wm/theme/default.themerc Вручную режим можно изменить в окне «Пуск > Панель управления > Рабочий стол > Оформление Fly > Блокировка». Атрибут «Блокировать экран» устанавливает значение параметров LockerOnDPMS, LockerOnLid, LockerOnSleep и LockerOnSwitch. Допустимые значения: - true - экран блокируется (по умолчанию) - false - экран не блокируется Для всех классов защищенности информационной системы с К3 по К1 и всех уровней защищенности персональных данных с УЗ4 по УЗ1 рекомендуемым значением является: - Блокировать экран = true Атрибут «Время бездействия в секундах» устанавливает значение параметра ScreenSaverDelay, значение по умолчанию 300. Для классов защищенности информационной системы с К3 по К2 и уровней защищенности персональных данных с УЗ4 по УЗ2 рекомендуемым значением является 900 (15 минут). Для К1 и УЗ1 рекомендованным значением является 300 (5 минут).' \ --attr 'Блокировать экран':screen_lock:'' \ --attr 'Время бездействия в секундах':screen_saver_delay:'' \ --script 'import_parameter_sec_auth_6_screen_lock.sls' \ --script-comment 'Версия 1.0'

Скрипты параметров написаны с учетом особенностей реализации механизма групповых политик ALD Pro. Например, параметры скрипту передаются через Pillar. Для конфигурирования ini-файлов на целевых хостах SaltStack предоставляет очень удобный модуль состояний ini_manage, который в несколько строк позволяет задать набор необходимых параметров:

$ сat import_parameter_sec_auth_6_screen_lock.sls     >   >: ini.options_present: - name: /usr/share/fly-wm/theme/default.themerc - separator: '=' - strict: False - sections: 'Variables': LockerOnDPMS: '>' LockerOnLid: '>' LockerOnSleep: '>' LockerOnSwitch: '>' ScreenSaverDelay: '>'

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

Чтобы оставить администраторам полный контроль над работой этого инструмента, мы не стали создавать какой-то один «рубильник», задающий нужный уровень защищенности. Каждый параметр имеет один и более атрибутов, для которых системный администратор и/или администратор безопасности может выбрать желаемое значение. Но если значение не будет задано, то по умолчанию мы руководствуемся наиболее строгими требованиями.

Например, настройка параметра «Блокировка экрана после бездействия» по умолчанию имеет значение 300 секунд. Это соответствует методическому документу «Меры защиты информации в государственных информационных системах» (утв. ФСТЭК России от 11.02.2014) и закрывает одно из требований к усилению УПД.10 — о блокировке сеанса пользователя после установленного времени бездействия (неактивности).

Пошаговая настройка групповых политик

Настройка групповых политик с использованием дополнительных параметров ничем не отличается от использования параметров «из коробки» и организовано так же, как в Active Directory. Сначала нужно создать объект групповой политики, затем на вкладках «Параметры компьютеров» и «Параметры пользователей» включить необходимые параметры, задать значения их атрибутов и в самом конце этот объект нужно назначить на одно и более структурных подразделений.

На примере параметра «Блокировка экрана после бездействия» нам доступно два атрибута, как видно на рисунке 2. А для параметра «Блокировка интерпретаторов» атрибут только один (рисунок 3). Для получения дополнительной информации об атрибутах и их допустимых значениях можно обратиться к справке – нужно просто кликнуть по иконке вопроса в правом верхнему углу.

Вместо заключения

Набор предлагаемых дополнительных параметров поможет при настройке ОС и выполнении части требований, описанных в мерах защиты информации: ИАФ.1, ИАФ.3, ИАФ.4, УПД.1, УПД.6, УПД.13, УПД.10, УПД.14, УПД.15, ОПС.1, ОПС.2, ОПС.3, ОПС.4, РСБ.2, РСБ.3, РСБ.4, РСБ.6, РСБ.7, АНЗ.3, АНЗ.4, ОЦЛ.1, ОЦЛ.2, ОЦЛ.8, ЗИС.15, ЗИС.16, ЗИС.21 и др. При этом важно понимать, что требования приказов ФСТЭК России не регламентируют конкретные настройки средств защиты, а определяют базовый набор мер защиты. Перечень мер защиты должен уточняться в зависимости от структурно-функциональных характеристик и модели угроз конкретных объектов информатизации.

Учитывая это, данные в статье рекомендации могут оказаться неподходящими или недостаточными для предотвращения несанкционированного доступа к конкретной информационной системе. Решение о применении тех или иных настроек безопасности остается всегда за администратором этой ИС. Наша задача как продуктовой команды – следить за актуальностью инструкций и скриптов в личном кабинете и помогать в обеспечении информационной безопасности.

• системное администрирование
• информационная безопасность
• групповые политики
• централизованное управление
• it-инфраструктура

• Блог компании Группа Астра
• Информационная безопасность
• Системное администрирование
• IT-инфраструктура
• Законодательство в IT

Запрет консоли в Astra Linux. Как обойти и выполнить команды?

Здравствуйте, уважаемые читатели моего блога!
Сегодня мы поговорим о том, возможно ли обойти запрет консоли и исполняемого бита операционной системы Astra Linux 1.7.4 (максимальная защита) и выполнить произвольные команды.

Разумеется, эта информация предназначена для системных администраторов и специалистов по безопасности информации, и её использование в противоправных целях преследуется по закону. Информация, которая здесь изложена НЕ является уязвимостью операционной системы, так как при корректном использовании её защитных механизмов указанная ситуация не возникнет (собственно, чтобы она не возникла, я решил написать эту статью).

Для начала вспомним, как именно работают указанные механизмы и для чего они нужны.

Запрет исполняемого бита предназначен для того, чтобы предотвратить запуск скриптов и бинарных файлов (ранее мы говорили о способах обхода указанного механизма — перейти и ознакомиться).

Механизм запрета консоли предназначен для предотвращения запуска пользователем произвольных команд.

Активируется он следующим образом:

sudo astra-console-lock enable #включить запрет консоли sudo astra-console-lock disable #отключить запрет консоли

Но так ли это? Гарантирует ли указанный механизм запрет выполнения произвольных команд? И да, и нет.

Операционная система Astra linux 1.7 содержит множество различных механизмов защиты, но использовать их следует совместно, иначе появляются варианты их обхода.

Проведём эксперимент, активируем запрет исполняемого бита и запрет консоли:

sudo astra-console-lock enable sudo astra-nochmodx-lock enable

Создадим файл скрипта на рабочем столе, с командой на создание файла на рабочем столе

cat ~/Desktop/123.sh #!/bin/bash touch ~/Desktop/2222222 EOF

Попытаемся запустить его, но ничего не выйдет — логично, ведь исполняемый бит отсутствует. Как запустить указанный скрипт?
Используем ярлык, с указанием команды на исполнение.

Запустим ярлык и получим результат.

Как можно противодействовать запуску произвольных shell команд — используйте механизмы запрета использования интерпретаторов (включая bash), в этом случае указанный способ работать не будет.

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

Astra Linux Special Edition: обзор защищенной российской ОС

Вне зависимости от выбранной версии, компании получают систему с полным набором средств защиты информации (СЗИ), которые и составляют основное преимущество Astra Linux Special Edition.

Акцент на защите

Разработчики подчеркивают: максимальная защищенность — это ключевая особенность их системы. Она может прямо «из коробки» эффективно противостоять основным киберугрозам, снизить ущерб от вредоносной активности.

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

Кроме того, это единственная операционная система в России, которая полностью соответствует требованиям безопасности информации всех основных регуляторов страны. Разработчики опирались на актуальную законодательную базу, в том числе:

• Федеральные законы No 149-ФЗ, No 44-ФЗ и No 187-ФЗ;
• Постановления Правительства Российской Федерации No 1236 и No 325;
• Распоряжение Правительства Российской Федерации No 1588-р;
• Приказ Минцифры России No 334.

Это позволяет использовать Astra Linux для обработки информации с ограниченным доступом — от персональных данных до государственной тайны «особой важности». Все это возможно благодаря встроенным в Astra Linux средствам защиты информации. Поговорим о них подробнее.

Три режима защищенности

С 2021 г. в Astra Linux Special Edition предусмотрено три режима (или уровня) защищенности в зависимости от приобретенной лицензии СЗИ: «Усиленный» («Воронеж»), «Максимальный» («Смоленск»), а также «Базовый» («Орёл») несертифицированный режим.

Режимы защищенности Astra Linux Special Edition

«Воронеж». На этом уровне в системе работают СЗИ собственной разработки ГК «Астра», входящие в подсистему безопасности PARSEC. В первую очередь это механизмы мандатного контроля целостности и замкнутой программной среды, которые противостоят угрозе целостности информации.

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

«Смоленск». Максимальный уровень защищенности дополняет возможности «Усиленного» режима функциями мандатного управления доступом (МРД) для защиты от угрозы конфиденциальности информации. Суть этого принципа в распределении информации по явно заданным уровням конфиденциальности и выполнении следующих условий:

1. Читать данные из файла или каталога могут только те процессы и пользователи, которые обладают не меньшим уровнем конфиденциальности, чем у запрашиваемых данных.
2. Записывать данные в файл или каталог могут только те процессы с уровнем конфиденциальности, равным или меньшим, чем у этого файла или каталога.
3. Действия процессов в системе не приводят к явной или неявной утечке конфиденциальных данных «сверху-вниз» – с высокого уровня конфиденциальности на низкий (т. е. к созданию так называемых скрытых каналов).

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

Есть также базовый уровень защищённости «Орёл» (несертифицированной операционной системы), он не может применяться в корпоративных системах, системах критической информационной инфраструктуры, а также для обработки информации ограниченного доступа, к которой предъявляются требования по защите информации.

Мандатный контроль целостности

В Astra Linux в режимах «Воронеж» и «Смоленск» организован контроль целостности системы и ее компонентов. Файлы, процессы, учетные записи пользователей и прочие компоненты ОС Astra Linux Special Edition распределяются по уровням целостности, после чего штатными средствами безопасности можно защищать компоненты более высокого уровня целостности от несанкционированной записи из компонентов с меньшим уровнем.

Этот подход формализован в ГОСТ Р 59453.1-2021 «Защита информации. Формальная модель управления доступом. Часть 1. Общие положения», который создан ГК «Астра» совместно с ИСП РАН. Это первый случай в отечественной практике стандартизации, когда мандатный контроль целостности (МКЦ) получил официальное определение.

Безопасный запуск процессов в ОС Astra Linux Special Edition

Как отмечают разработчики, явно заданные уровни целостности, в отличие от предоставляемых прав доступа при штатном дискреционном управлении доступом ОС Linux делают администрирование и настройку защиты прозрачнее. Даже суперпользователь root, который в обычных ОС семейства Linux имеет практически полный набор прав, в ОС Astra Linux Special Edition по умолчанию работает на минимальном уровне целостности 0. Таким образом, перехват его полномочий не откроет злоумышленникам доступ к управлению всей системой.

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

Безопасный запуск приложений в Astra Linux

Замкнутая программная среда

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

Во-первых, внедрить нелегитимную ЭЦП может только пользователь с высоким уровнем целостности. Во-вторых, даже если «зараженный» файл удастся разместить в системе, а нарушитель смог проэксплуатировать заложенную в этом файле уязвимость и получил, например, root-привилегии, он продолжит работу на том же низком уровне целостности.

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

Подробнее обо всех технологиях безопасности в Astra Linux Special Edition можно узнать в библиотеке ГК «Астра».

Подведем итоги

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

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

erid: Kra248buo

* Реклама, Рекламодатель ООО «РусБИТех-Астра», ИНН 7726388700