Secret net studio astra linux

RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

Здравствуйте!
Давно не обращался с вопросами подобного характера (с последней темы прошло, ужас, почти 6 лет: https://forum.rutoken.ru/topic/1947/), но время, видимо, пришло 🙂
Имеется связка:
— сервер под управлением Windows Server 2008/2012 R2 с поднятой службой терминалов;
— СЗИ НСД для сервера Secret Net 7 / Secret Net Studio 8.4;
— клиентский идентификатор Rutoken S с комплектом драйверов под Win и Lin из соответствующего раздела сайта;
— клиентская машина под управлением Linux Mint 19 x64, ядро 4.15;
— клиентская машина под управлением Astra Linux Special Edition 1.6, ядро 4.15;
— программный пакет freerdp-x11 для создания терминальной сессии.

Пытаюсь реализовать схему проброса аппаратного идентификатора (Rutoken S) в терминальную среду (Windows Server) с клиентской nix-машины (Mint / Astra).
На обеих машинах установлены свежие драйверы ifd-rutokens-1.0.4.deb для x64 архитектуры, а также необходимые зависимости: libccid, pcscd и libpcsclite1. С той лишь разницей, что под Linux Mint имеется пакет pcsc-tools для проверки работы Rutoken S, а под Astra Linux он отсутствует.
В Astra Linux специально отключена поддержка мандатного контроля целостности (МКЦ) через astra-mic-control disable и пользователю (user) превентивно выставлены права работы исключительно в 0 мандатной сессии.

Проблематика

• Если не устанавливать Secret Net (Secret Net Studio) в терминальную среду Windows Server, то и под Linux Mint, и под Astra Linux проброс Rutoken S через xfreerdp выполняется корректно. Панель управления Рутокен (Windows) «видит» проброшенный токен, позволяет к нему обратиться, отформатировать и т.д.
• Если установить Secret Net (Secret Net Studio), то из-под Astra Linux проброс «отваливается»: при создании терминальной сессии токен несколько раз мигает, но затем обращение к нему полностью прекращается. В результате, токен не видится ни средствами Secret Net (Secret Net Studio), ни средствами Панели управления (Windows) — выводится работы ошибка службы смарт-карт с предложением посетить страницу настройки Рутокена для RDP-сессии. Демон pcscd в свою очередь периодически уходит в inactive режим — приходится его рестартовать через systemctl.
• Из-под Linux Mint аналогичная связка полностью отрабатывает: токен «виден» и средствами Панели управления, и средствами Secret Net (Secret Net Studio).

Очевидно, что корень зла в компонентах Astra Linux Special Edition, однако никак не могу сообразить, в каких конкретно. Такое ощущение, что обращение к токену средствами Secret Net (Secret Net Studio) в RDP-сессии приводит к переполнению буфера или иной схожей проблеме демона pcscd или самого драйвера Rutoken S.

Собственно, хотел узнать:
— возможно, существует свежий драйвер, разработанный именно под Astra Linux Special Edition и новее 2014 г.в.?
— возможно, что проблема в демоне pcscd или зависимостях (libccid, libpcsclite1) из комплекта Astra Linux Special Edition?
— возможно, имеется определенная схема специальной настройки Astra Linux Special Edition для полной поддержки Rutoken S?

К сожалению, перейти на Рутокен ЭЦП 2.0 не получается — приходится использовать Rutoken S в связи с его сертификатом под «особые» АС.

#2 Ответ от oko 2019-07-17 11:44:25

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

UPDATE
Обнаружился любопытный факт утром на трезвую голову: при замене СЗИ НСД на Dallas Lock 8.0-C связка заработала без проблем и из-под Astra Linux Special Edition 1.6.
Вывод: Secret Net 7 и Secret Net Studio 8.4-C имеют одинаковую подсистему поддержки Rutoken S, которая некорректно работает в терминальной сессии в некоторых случаях. Точно не могу определить корни зла, но склоняюсь к мысли, что здесь ошибка таймингов обращения к Rutoken S по схеме «подсистема SN (SNS) -> драйвер Рутокен Windows -> подсистема pcscd в Astra Linux -> драйвер ifd-rutokens в Astra Linux». На каком этапе идет сбой самостоятельно пока выяснить не могу.

#3 Ответ от Ксения Шаврова 2019-07-30 10:12:55

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

Здравствуйте, oko.

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

#4 Ответ от Алексей Лазарев 2019-07-30 17:58:54 (2019-07-30 19:47:55 отредактировано Алексей Лазарев)

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

Здравствуйте, oko.

Скажите пожалуйста, а вы не пробовали провести следующий эксперимент: На терминальном сервере установить комплект драйверов с дистрибутивного диска Secret Net Studio 8.4, после чего проверить будет ли возникать проблема описанная в обращении. Суть проблемы в том, что SNS чувствителен к версии драйвера.

И еще момент, можете уточнить, какие защитные компоненты включены в Astra Linux SE 1.6?

UPD. Имеются ввиду драйверы Рутокен для Windows, которые шли на диске. Там должна быть версия 4.3.0.0

#5 Ответ от oko 2019-08-01 00:56:02 (2019-08-01 01:04:15 отредактировано oko)

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

to Ксения Шаврова
Благодарю! И сразу извиняюсь — не доглядел, что почтовый адрес в Профиле устарел и доступа к нему уже нет (давненько регистрировался, да). Просьба выслать инструкции повторно — e-mail в Профиле обновил на актуальный.

to Алексей Лазарев
Пробовал разные комбинации: брал драйвер для Win из дистрибутива SNS 8.4 (при использовании с SNS 8.4), из дистрибутива SN7 (при использовании с ним), последнюю версию с оф.сайта; также брал последнюю версию драйвера для Linux с оф.сайта и самую первую версию, которая заработала с Астрой 1.3 при прошлом обращении 6 лет назад (ifd. -1.0.1.deb). Результат всегда один (хотя со старым драйвером для Linux наблюдалось еще и постоянное мигание светодиода Рутокен S, но, думаю, это не критично):

• при подключении из-под Win 8.1 к Win Server 2008R2/2012R2 или из-под Linux Mint (не принципиально, как мне кажется) к Win Server 2008R2/2012R2 Rutoken S корректно пробрасывается RDP-клиентом, «виден» в Панели управления Рутокеном, а также «виден» всеми механизмами SNS (SN7);
• при подключении из-под Astra Linux SE 1.6 к Win Server 2008R2/2012R2 Rutoken S пару раз мигает (с последним драйвером для Linux), будто бы идет опрос, но в терминальной сессии ни Панель управления Рутокеном, ни SNS (SN7) его уже «не видят» (Панель выдает стандартную ошибку, будто бы не включена служба поддержки смарт-карт)

Проброс Rutoken S в терминальную среду делаю через:

/usr/bin/xfreerdp /sec:rdp /cert-ignore /smartcard:"0a89:0020" /v:192.168.1.1

Правила udev для Rutoken S:

SUBSYSTEM=="usb", ACTION=="add", ATTRS=="0a89", ATTRS=="0020", RUN+="/bin/systemctl start rutoken.service" SUBSYSTEM=="usb", ACTION=="remove", ENV=="0a89", ENV=="0020", RUN+="/bin/systemctl stop rutoken.service"

Systemd-сервис для Rutoken S:

[Unit] Description=Rutoken S (un)plug service [Service] Type=oneshot RemainAfterExit=true ExecStart=/usr/bin/RutokenS.sh plug ExecStop=/usr/bin/RutokenS.sh unplug

Впрочем, systemd-сервис и правила udev модифицированы под нужную задачу (скрипт RutokenS.sh выполняет доп.действия при подключении токена, но также выполняет chgrp для /dev/usb. как и в оригинале после установки драйвера). Если их оставить по умолчанию (после установки драйвера), все равно ничего принципиально не меняется.
В ходе ковыряния проблемы на стенде дошел до того, что отключил почти все защитные механизмы Astra Linux, до которых смог добраться: мандатный контроль целостности, модули Parsec для PAM, киоск, затирание, мандатные метки уровня файловой системы. Но проблема осталась.

К сожалению, в «репозитории» (диск установки) Astra Linux SE 1.6 отсутствует пакет pcsc-tools, поэтому непосредственную отладку через консоль не проводил. Если необходимо, могу встроить аналогичный пакет от Debian 9 и проверить вывод.
Любопытный факт: после пары-тройки подключений к терминальному серверу с подключенным Rutoken S, сервис pcscd переходит в состояние inactive и требует перезапуска. Почему и грешу на переполнение буфера.

ЗЫ Складывается ощущение (особенно после заработавшей связи с Dallas Lock 8.0-C), что SNS (SN7) производит слишком много «лишних» обращений к Rutoken S, в результате чего служба в Astra Linux не выдерживает и «отбивает».

#6 Ответ от Алексей Лазарев 2019-08-12 13:14:36

Re: RutokenS+AstraLinuxSE1.6+SecretNet(Studio)

Добрый день, разработчики SN провели исследование. Вот их вердикт:

«Описанная проблема заключается в используемом терминальном клиенте. В нём не в полной мере реализован стандартный интерфейс WinsCard. В частности, функция ScardLocateCardsByATR().
Можем рекомендовать сменить терминальный клиент или его версию. Мы учтем этот момент а будущих версиях и вероятно поддержим клиентов даже без этой функции. Но это не ошибка нашего продукта. Это недоработка используемого терминального клиента.»

С уважением, Алексей Лазарев

Источник

СЗИ Secret Net LSP версии 1.12 теперь работает под ОС Astra Linux

ГК «Астра» и российский разработчик средств защиты информации компания «Код Безопасности» успешно завершили сертификацию ПО Secret Net LSP версии 1.12 в рамках программы технологической кооперации ИТ-вендоров Ready for Astra. Для конечных заказчиков это означает, что ОС Astra Linux Special Edition 1.7 совместима с Secret Net LSP, и пользователям продуктового стека в полном объем доступен функционал обоих его компонентов. Secret Net LSP можно применять в информационных системах на базе ОС Astra Linux, подлежащих аттестации по требованиям безопасности.

Secret Net LSP —это комплекс средств защиты информации, предназначенный для ОС Linux. Продукт имеет сертификат ФСТЭК России, который подтверждает его соответствие требованиям регулятора по пятому классу защищенности средств вычислительной техники, по четвертому классу защиты средств контроля съемных машинных носителей и межсетевых экранов типа «В», а также требованиям к 4 уровню доверия к средствам обеспечения ИТ-безопасности. Среди преимуществ и возможностей продукта разработчик выделяет его мультиплатформенность, способность к интеграции с другими СЗИ и наличие единого контура управления для смешанных сред Windows-Linux: выбранная политика безопасности масштабируется на все конечные точки сети и при кибератаках уменьшается вероятность проблем, связанных с неправильной настройкой системы. Кроме того, в решении имеются средства фильтрации сетевых потоков, а механизмы, отвечающие за безопасность, реализованы в виде отдельного средства защиты, и это ощутимо облегчает эксплуатацию в средах с одновременным использованием различных дистрибутивов Linux ОС.

«Подтверждение совместимости с Astra Linux — важнейший компонент нашей стратегии по защите Linux-сред. Это платформа, на основе которой мы можем строить надежные и эффективные меры защиты от самых продвинутых угроз. Astra Linux — ключевой игрок рынка, и подтверждение совместимости поможет защитить инфраструктуру множества государственных заказчиков», — рассказывает Павел Коростелев, руководитель отдела продвижения продуктов компании «Код Безопасности».

Источник