Смоленск 1.4 Соответствие требованиям 1Б

kostia

New member
Сообщения
174
#1
В требованиях к АС класса защищенности 1Б есть такие:
- целостность СЗИ НСД проверяется по контрольным суммам всех компонент СЗИ как в процессе загрузки, так и динамически в процессе работы АС
- должно проводиться периодическое тестирование всех функций СЗИ НСД с помощью специальных программных средств не реже одного раза в квартал;
- должны быть в наличии средства восстановления СЗИ НСД, предусматривающие ведение двух копий программных средств СЗИ НСД и их периодическое обновление и контроль работоспособности, а также оперативное восстановление функций СЗИ НСД при сбоях;
Как это реализуется в Astra-Linux SE 1.4 ?
 

cogniter

Moderator
Team Astra Linux
Сообщения
159
#4
1. Динамический контроль целостности обеспечивается работой модуля ядра digsig в режиме замкнутой программной среды, который автоматически проверят целостность подписанных объектов.

2. Порядок периодического тестирования описан в руководстве по КСЗ, часть 2.

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

kostia

New member
Сообщения
174
#5
1. Динамический контроль целостности обеспечивается работой модуля ядра digsig в режиме замкнутой программной среды, который автоматически проверят целостность подписанных объектов.
Фокус!
cp /bin/rm /usr/bin/ls
-bash-4.2# bsign -w /bin/ls
version: 1
id: bsign v1.0
hash: bc66 b10f 947b 00a4 9cf6 4869 379b 98a6 ee47 295f ad31 8562 29d5 c3d2 5101 d832
signature_size: 96
signature:
88 5e 04 00 22 5e 00 06 05 02 54 3d 96 52 00 0a
09 10 09 4e 5b b1 07 8a c4 f1 79 ed 00 ff 6d 25
84 07 b6 b3 e4 25 b8 d6 02 1c e8 aa cf 99 de 90
37 b5 d4 6f b6 02 3d 0e 3b 1a 89 fd fa b7 00 ff
79 84 d5 35 91 16 b1 21 c9 e4 dc b2 97 04 4a b8
91 39 8c 3a dd 16 d5 0d 5e cf cc 73 70 1d 3e b9
signer: 078AC4F179ED00FF
timestamp: 15 Oct 2014 01:32:02 (1413322322)
bsign: good hash found in '/bin/ls'.
-bash-4.2#
-bash-4.2# bsign -w /usr/bin/ls
version: 1
id: bsign v1.0
hash: 410c 14e0 bfa7 cde0 a072 deda 96e0 6735 d167 b548 2a3b 4de7 8aef dd21 2c8d 91e0
signature_size: 96
signature:
88 5e 04 00 22 5e 00 06 05 02 54 3d 96 54 00 0a
09 10 09 4e 5b b1 07 8a c4 f1 80 5a 00 ff 7f 17
3f 68 7b 12 b2 1a 3d 92 32 2f 5f 6f 21 52 8b de
be 5e 5c 09 ba 7a 11 6d e9 3f e9 d2 25 d6 00 ff
40 c2 46 09 a1 0c 22 06 a6 32 fb 2b 17 67 1d fe
b9 45 13 45 a9 e6 e0 78 7d 59 a4 55 c2 a3 6a 10
signer: 078AC4F1805A00FF
timestamp: 15 Oct 2014 01:32:04 (1413322324)
bsign: good hash found in '/usr/bin/ls'.

Пояснения нужны?
 

kostia

New member
Сообщения
174
#6
2. Порядок периодического тестирования описан в руководстве по КСЗ, часть 2.
Вот за подсказку спасибо! Но тут же вопрос. Запустил тестирование parsec от рута, один тест не проходит. В лог файле:

mac set-get test: INFO: Начинаем тест: mac set-get test...
mac set-get test: INFO: Итерация 0.
PARSEC FMAC TEST: ERROR: test2: Отказано в доступе: ошибка вызова mac_set_file()
mac set-get test: INFO: mac set-get test провалился
mac access test: INFO: Начинаем тест: mac access test...
mac access test: INFO: Итерация 0.
mac access test: INFO: mac access test провалился
PARSEC FMAC TEST: INFO: ТЕСТ ПРОВАЛИЛСЯ!ОБЩИЙ СТАТУС = 2
[!] Test FAIL with code: 2


Не понятно в чем причина и как устранять?
 

ulv

Moderator
Team Astra Linux
Сообщения
26
#7
В требованиях к АС класса защищенности 1Б есть такие:
- целостность СЗИ НСД проверяется по контрольным суммам всех компонент СЗИ как в процессе загрузки, так и динамически в процессе работы АС
- должно проводиться периодическое тестирование всех функций СЗИ НСД с помощью специальных программных средств не реже одного раза в квартал;
- должны быть в наличии средства восстановления СЗИ НСД, предусматривающие ведение двух копий программных средств СЗИ НСД и их периодическое обновление и контроль работоспособности, а также оперативное восстановление функций СЗИ НСД при сбоях;
Как это реализуется в Astra-Linux SE 1.4 ?
К Астре не предъявляются требования к 1Б. 1Б - это класс автоматизированной системы, которую строят с использованием различных средств вычислительной техники (СВТ). К Астре предъявляются требования к СВТ. И сертификат был получен именно на это.
С использованием каких средств и механизмов закрывать требования к АС решает конструктор оной.
Обычно:
- целостность ядра и основных модулей из Астры проверяют в СДЗ (средстве доверенной загрузки), затем в самой ОС включают проверку подписи исполняемых файлов и периодически целостность файлов ФС через afick
- РУК_КСЗ2 описана вся процедура
- решается бэкапами, созданием единого образа с возможностью заливки, ведением типовой дублирующей конфигурации (стенда)

Вот за подсказку спасибо! Но тут же вопрос. Запустил тестирование parsec от рута, один тест не проходит. В лог файле:

mac set-get test: INFO: Начинаем тест: mac set-get test...
mac set-get test: INFO: Итерация 0.
PARSEC FMAC TEST: ERROR: test2: Отказано в доступе: ошибка вызова mac_set_file()
mac set-get test: INFO: mac set-get test провалился
mac access test: INFO: Начинаем тест: mac access test...
mac access test: INFO: Итерация 0.
mac access test: INFO: mac access test провалился
PARSEC FMAC TEST: INFO: ТЕСТ ПРОВАЛИЛСЯ!ОБЩИЙ СТАТУС = 2
[!] Test FAIL with code: 2


Не понятно в чем причина и как устранять?
Пытается создать тестовый файл 255 уровня, что нельзя сделать в контейнере более низкого уровня.
Чтобы не появлялась ошибка, надо выполнить:
Код:
pdp-flbl 255:0:-1:CCNRALL /
 

kostia

New member
Сообщения
174
#8
К Астре не предъявляются требования к 1Б. 1Б - это класс автоматизированной системы, которую строят с использованием различных средств вычислительной техники (СВТ). К Астре предъявляются требования к СВТ. И сертификат был получен именно на это.
С использованием каких средств и механизмов закрывать требования к АС решает конструктор оной.
Требования предъявляются к СЗИ НСД, которые являются частью ОС Astra-Linux, или вы предлагается в АС использовать еще и дополнительные средства защиты информации поверх СЗИ Астры?
Я не с целью критики любопытствую, я как раз и являюсь тем конструктором, который пытается собрать АС удовлетворяющую требованиям 1Б не формально, а на практике. И, честно говоря, получается это с трудом. Очень много не доработок куда ни ткни. Ну вот к примеру.
целостность ядра и основных модулей из Астры проверяют в СДЗ (средстве доверенной загрузки)
Это АПМДЗ Максим-М1. На бумаге гладко. По факту, с аппаратного RAID массива загрузить ОС не может (с этим хоть вывернулись переключив BIOS в UEFI и переинсталлировав операционку), проверить контрольные суммы на аппаратном RAID-e тоже не может. В документации об этом ни слова.
Про проверку подписи исполняемых файлов я написал выше. Это не защищает от подмены файлов. AFICK да, может быть решением, но тут спорный вопрос с "динамичностью".
РУК_КСЗ2 описана вся процедура
Это про периодическое тестирование функций СЗИ. Прекрасно что это есть, плохо что в описании "всей процедуры" не написано вот это
pdp-flbl 255:0:-1:CCNRALL /
и что нужно и как вернуть обратно мандатную метку на корень ФС тоже не написано. Не описано в документации, что после проведения тестов в корне ФС остается пайп testfifo (а может и еще где-то? где?). Не описано, что после проведения процедуры тестирования СЗИ afick даст срабатывание на изменение каталога. (Да можно исключить проверку mtime, но опять же в документации не говориться про это).
# max_checksum_size:=10000000
# dbm:=GDBM_File
# last run on 2018/06/04 16:47:59 with afick version 2.11-1
changed directory : /etc/security

# detailed changes
changed directory : /etc/security
mtime : Mon Jun 4 16:00:36 2018 Mon Jun 4 16:49:05 2018

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

Вот знаете, очень полезно было бы составить список файлов, относящихся именно к системе СЗИ НСД. И сделать для afick профиль тестирования соответствующий.
 

kostia

New member
Сообщения
174
#10
Злоумышленника с правами администратора системы. Контроль целостности для этого и нужен.
 

cogniter

Moderator
Team Astra Linux
Сообщения
159
#11
включите опцию "Запрет установки исполняемого бита", думаю, это решит вашу задачу с подменой (навскидку правда не помню, есть ли уже эта опция в 1.4)
 

kostia

New member
Сообщения
174
#12
включите опцию "Запрет установки исполняемого бита", думаю, это решит вашу задачу с подменой (навскидку правда не помню, есть ли уже эта опция в 1.4)
Ну вот как? Злодей просто переименовывает /bin/ls на /bin/rm запрет исполняемого бита здесь не поможет. Да и задача не с "подменой", а с корректной процедурой проверки целостности.
 

cogniter

Moderator
Team Astra Linux
Сообщения
159
#13
Ну вот как? Злодей просто переименовывает /bin/ls на /bin/rm запрет исполняемого бита здесь не поможет. Да и задача не с "подменой", а с корректной процедурой проверки целостности.
В примере выше вы копировали. А на переименование объектов можно повесить аудит событий.

1528123081292.png
 

kostia

New member
Сообщения
174
#14
Ну костыли же, которые возникают из-за неправильности реализации самой сути контроля целостности. Файл - объект проверки, который имеет ряд признаков. В том числе имя и место расположения. Имеется эталонная база значений, копия которой хранится на отчуждаемом носителе. При проведении проверки считываются все файлы из соответствующих каталогов и проверяются на соответствие базе эталонных значений обязательно с полными путями. В этом случае, если в каталоге изменился файл - аларм, если появился новый файл - аларм, если оперативная эталонная база не соответствует копии на внешнем носители - два раза аларм.
 

cogniter

Moderator
Team Astra Linux
Сообщения
159
#15
Afick вас не устроил, остальное - тоже. Не подскажете, как вы решали эту задачу в других Linux системах?
 

kostia

New member
Сообщения
174
#16
Ну к чему сарказм то? Это не меня текущая реализация не устраивает, это заказчик въедливый.
На МСВС-3.0 это решали с помощью сторонней СЗИ Ребус-М от ЦентрПрограммСистем. Тоже не идеал конечно, но в итоге заказчика все таки устроило.
А по началу проходили тот же вест с разработчиками, от неприятия запросов и формальных отписок до включения функционала в изделие.
У Астры прекрасные перспективы и хороший функционал, доточить бы вот такие детали. Реализовать по нормальному то, что заявлено и в соответствии с документацией.

Afick можно доточить до применимости, писал же, сделайте там профиль с названием "Компоненты СЗИ", и с правильными правилами проверки. Ну будем запускать раз минут в пять в десять, может прокатит как динамический контроль целостности. Блокировку АРМ по результатам работы афиска мы уже сделали.
 

ulv

Moderator
Team Astra Linux
Сообщения
26
#17
Требования предъявляются к СЗИ НСД, которые являются частью ОС Astra-Linux, или вы предлагается в АС использовать еще и дополнительные средства защиты информации поверх СЗИ Астры?
Не поверх, а работающих совместно и распознающих метки и другую информацию от СЗИ Астры.
Например: закрывает требования к централизованному аудиту событий

Это АПМДЗ Максим-М1. На бумаге гладко. По факту, с аппаратного RAID массива загрузить ОС не может (с этим хоть вывернулись переключив BIOS в UEFI и переинсталлировав операционку), проверить контрольные суммы на аппаратном RAID-e тоже не может. В документации об этом ни слова.
Аппаратный raid - это совсем не типичная конфигурация для апмдз. Все драйвера в прошивку не запихнешь никак.
Данная проблема решается использованием карты памяти. В нее устанавливается ядро и initrd с нужным драйвером. Контроль карты памяти осуществляется апмдз.

Я не с целью критики любопытствую, я как раз и являюсь тем конструктором, который пытается собрать АС удовлетворяющую требованиям 1Б не формально, а на практике. И, честно говоря, получается это с трудом. Очень много не доработок куда ни ткни.
В общем, при более менее строгом подходе к выполнению требований, возникает масса вопросов. А заказчик сейчас грамотный, на руководящие должности назначаются 30 летние офицеры, для которых Linux и компьютер это не черный ящик. Они знают куда и на что смотреть. Формальными отговорками не обойтись.
Вы поймите, закрывать все требования только ОС - это та еще задача. Мы решали их еще 4 года назад. На все грабли наступали и дорабатывали/добавляли функционал в последующие релизы. С ними мы проходили процедуру подтверждения сертификата. Таково законодательство.

Сейчас все активно меняется и думаю осенью будут уже сильные подвижки и в МО. Переход на профили защиты упрощает многое и дает более гибкие инструменты построения/поддержки СЗИ.

Злоумышленника с правами администратора системы. Контроль целостности для этого и нужен.
Получение прав администратора - есть событие НСД, о котором должно быть известно сразу. После его появления, вся система становится недоверенной, пока не докажут обратное.
 

cogniter

Moderator
Team Astra Linux
Сообщения
159
#18
Ну к чему сарказм то? Это не меня текущая реализация не устраивает, это заказчик въедливый.
На МСВС-3.0 это решали с помощью сторонней СЗИ Ребус-М от ЦентрПрограммСистем. Тоже не идеал конечно, но в итоге заказчика все таки устроило.
А по началу проходили тот же вест с разработчиками, от неприятия запросов и формальных отписок до включения функционала в изделие.
У Астры прекрасные перспективы и хороший функционал, доточить бы вот такие детали. Реализовать по нормальному то, что заявлено и в соответствии с документацией.


Afick можно доточить до применимости, писал же, сделайте там профиль с названием "Компоненты СЗИ", и с правильными правилами проверки. Ну будем запускать раз минут в пять в десять, может прокатит как динамический контроль целостности. Блокировку АРМ по результатам работы афиска мы уже сделали.
Есть мандантный контроль целостности, который не позволит обычному руту изменять системные каталоги, есть режим загрузки с апмдз Максим в режиме только чтения, есть контроль fly-admin-int-check с внешнего носителя, есть afick, не говоря о подписи бинарников. По моему с этими инструментами можно вообще что угодно сделать в рамках вашей задачи
 

ulv

Moderator
Team Astra Linux
Сообщения
26
#19
Файл - объект проверки, который имеет ряд признаков. В том числе имя и место расположения. Имеется эталонная база значений, копия которой хранится на отчуждаемом носителе.
Это есть в средстве соответствия дистрибутиву. fly-admin-int-check
Все файлы имеют свой уникальный хеш. База с этими хешами хранится на установочном диске.
 

kostia

New member
Сообщения
174
#20
Не корысти ради, а чисто в поисках истины продолжу.
Не поверх, а работающих совместно и распознающих метки и другую информацию от СЗИ Астры.

Например: закрывает требования к централизованному аудиту событий
Решение оверскилл конечно, но теперь буду знать что предложить заказчику по поводу аудита и индикации событий. Потому как, ну правда, работать с web интерфейсом к OSSEC ну очень неудобно. Спасибо! А ведь хотели уже свою систему сбора и индикации событий писать, потому и интересовался здесь насчет RabbitMQ.

Аппаратный raid - это совсем не типичная конфигурация для апмдз. Все драйвера в прошивку не запихнешь никак.
Данная проблема решается использованием карты памяти. В нее устанавливается ядро и initrd с нужным драйвером. Контроль карты памяти осуществляется апмдз.
Аппаратный райд это мегатипичное решение для сервера, защитить который и призвана АПМДЗ. Решение с картой памяти напрашивается само-собой, но вот беда, не работает. Все по документации, вынос каталога boot в ЭНП АПМДЗ - кернел паник при загрузке. Ваш суппорт признал проблему. Как решение предложили всю ОС ставить на SD карту. Но это такое лечение, которое хуже болезни. Не вариант.

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

Получение прав администратора - есть событие НСД, о котором должно быть известно сразу. После его появления, вся система становится недоверенной, пока не докажут обратное.
Нет. Получение прав администратора это штатное событие - sudo -i это разрешенное действие для пользователей из группы astra-admin. Да, это требует внимания, но еще не повод объявлять систему недоверенной. А вот как раз изменение контрольных сумм файлов СЗИ это однозначный повод для блокировки.
Это есть в средстве соответствия дистрибутиву. fly-admin-int-check
Все файлы имеют свой уникальный хеш. База с этими хешами хранится на установочном диске.
Ну не подходит по совокупности требований для проверки контроля целостности. Во первых графическая, не скриптуется. А одно из требований к СЗИ - контроль целостности СЗИ при загрузке ОС до логина пользователя. Во вторых - всё файлы ОС проверять очень долго, а профиля для файлов именно СЗИ нет. В третьих отсутствуем возможность блокировки СВТ в случае нарушения целостности. В третьих в работе программы есть ошибки. В четвертых отсутствует режим оповещения на АРМ ОБИ. В пятых, не понятно как актуализировать штатное изменение контрольных сумм. Ну к примеру, на контроль нужно ставить /etc/passwd ибо злостная правка UID пользователя на 0 даст ему рутовые права, или /etc/group где включение пользователя в группу astra-admin так же даст рутовые права, но включение в группу может быть и штатным событием. Все становится еще интереснее при работе в ALD. Вот в том числе и поэтому, для полноценного контроля целостности не получится использовать цифровую подпись бинарных исполняемых пакетов. Контролировать нужно не только исполняемые файлы. Повторюсь, наибольшие перспективы у afick, но нет авторитетного мнения производителя о том, какие файлы относятся к СЗИ.
Есть мандантный контроль целостности, который не позволит обычному руту изменять системные каталоги
Вот этот зверь для нас непонятный. Как его использовать, какие особенности эксплуатации, какие проблемы вылезут - непонятно.