Какие алгоритмы хеширования поддерживает astra linux

Преимущества использования СЗИ в ОС Astra Linux Special Edition

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

Т.е. фактически всем владельцам или пользователям информационных систем важно обеспечить их защиту от трех классических угроз: конфиденциальности, целостности и доступности. Самой исследованной и обсуждаемой из них является первая угроза. Защита от нее необходима, начиная с обеспечения безопасности личных данных, далее к коммерческой тайне и вплоть до государственной тайны. На втором месте по важности, как правило, угроза целостности. И дело здесь не только в целостности или отсутствии искажений самой информации (какого-либо контента, документа, медиа). Защита от вирусов и закладок нужна всем – они тоже проявление угрозы целостности. Третья из классических угроз – угроза доступности – не всегда по важности на последнем месте, а в ряде случаев, например, для интернет-ресурсов она выходит на передний план. Но во многих информационных системах, в особенности операционных системах (ОС), защита от нее обеспечивается средствами, изначально предназначенными для защиты от угроз целостности и конфиденциальности информации.

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

Для начала заметим, что подавляющее большинство пользователей отечественных информационных систем много лет работало с иностранными решениями, например, ОС Microsoft Windows, в которых используются СЗИ часто более развитые по сравнению с имеющимися в ОС семейства Linux. Пользователи даже не осознавали и не замечали того, что каждый день используют инструменты мандатного контроля целостности или замкнутой программной среды (о которых речь пойдет дальше). Это было само собой разумеющимся – работать в системе, в которой за ее безопасностью следят соответствующие СЗИ.

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

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

Рис. 1. Компоненты и режимы функционирования СЗИ в ОС Astra Linux Special Edition

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

Поэтому часто в ОС семейства Linux используют дополнительные механизмы, позволяющие задавать сложные политики управления доступом, учитывающие особенности функционирования компонент ОС, их взаимодействия между собой. Примерами таких механизмов являются AppArmor и Security Enhanced Linux (SELinux). Первый из них расширяет дискреционное управление за счет возможности задания политик, ограничивающих доступ к компонентам ОС. Второй механизм помимо этого включает элементы типизированного, ролевого и мандатного управления доступом.

Казалось бы, всё уже есть, и не надо делать ничего своего. Так в чем проблема? А она, как обычно, кроется в фундаменте этих технологий и упирается в математику. Во-первых, несмотря на существующие исходные тексты программного кода AppArmor и SELinux, ввиду его значительного объема и сложности, это не оказывает значительного влияния на возможность проверки эффективности данных механизмов, их доработки, сопровождения, т. е. обеспечения доверия к ним. Во-вторых, собственно доверие к механизмам управления доступом, как правило, основывается на наличии для них формальной (выраженной на математическом языке) модели управления доступом. Без такой модели невозможна верификация как самих AppArmor и SELinux, так и всей системы защиты ОС.

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

Однако о существовании развитой модели управления доступом для AppArmor или SELinux авторам настоящей статьи ничего неизвестно. Разработанные в 70-е годы прошлого столетия модели Белла-ЛаПадулы или Биба, иногда упоминаемые в этом контексте, не заслуживают серьезного обсуждения как безнадежно устаревшие. В результате, использовать SELinux или AppArmor для управления доступом в ОС – это сродни созданию отечественного самолета с иностранными двигателями без тщательного тестирования, возможности технической поддержки и развития: летать будет, но долго ли или высоко ли – большой вопрос.

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

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

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

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

В целом СЗИ в ОС Astra Linux Special Edition, начиная с режима «Усиленный», формируют, как это говорится в нормативных документах ФСТЭК России, поверхность атаки (рис. 1) – основной рубеж обороны от нарушителя. При этом, в отличие от других российских ОС семейства Linux, в ОС Astra Linux Special Edition этот рубеж обороны реализуется СЗИ собственной разработки (не на базе заимствованных SELinux или AppArmor), построенных на основе развиваемых в ГК «Астра» научных подходов и применении технологий обеспечения доверия. Основные принципы этих подходов изложены в недавно опубликованной в журнале «Труды ИСП РАН» статье «Формирование методологии разработки безопасного системного программного обеспечения на примере операционных систем» .

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

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

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

Стоит отметить, что большинство пользователей информационных систем давно используют МКЦ. Связано это с тем, что данный вид управления доступом с 2007 г. был внедрен в ОС семейства Microsoft Windows на основе реализации двух механизмов MIC – Mandatory Integrity Control и UAC – User Account Control. 15 лет, прошедшие с того времени, показали высокую эффективность МКЦ для обеспечения контроля целостности программной среды ОС семейства Microsoft Windows, предотвращения заражения вирусами и внедрения программных закладок.

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

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

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

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

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

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

4. Изоляция приложений

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

Рис. 3. Безопасный запуск браузера в контейнере («песочнице») в ОС Astra Linux Special Edition

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

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

5. Мандатное управление доступом

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

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

Вывод:

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

�� Как хэшировать пароли в системах Linux

Мануал

Пароли никогда не следует хранить в виде обычного текста.

Независимо от того, идет ли речь о веб-приложении или операционной системе, они всегда должны быть в виде хэша (в Linux, например, хэшированные пароли хранятся в файле /etc/shadow).

Хеширование – это процесс, в ходе которого с помощью сложных алгоритмов пароль превращается в другую строку.

Такой процесс является односторонним: не существует способа вернуть хэшированный пароль к его первоначальному виду.

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

Эти случайные данные называются солью.

В этом уроке мы рассмотрим некоторые методы, которые можно использовать для хэширования паролей в Linux.

Хеширование пароля с помощью mkpasswd

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

Ранее мы уже рассматривали этот инструмент в статьях:

Приложение доступно в официальных репозиториях всех наиболее распространенных дистрибутивов Linux.

Для установки на Fedora необходимо выполнить следующую команду:

В Debian и его многочисленных производных приложение входит в пакет “whois” (он должен быть установлен по умолчанию):

На примере Kali Linux

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

Основной синтаксис следующий:

С помощью опции -m (сокращение от –method) мы указываем, какой алгоритм хэширования мы хотим использовать.

Чтобы получить список доступных алгоритмов, нужно просто передать “help” в качестве аргумента опции:

Рекомендуемый алгоритм – sha512crypt (именно он используется в Linux).

Как только мы запустим команду, нам будет предложено ввести пароль, который мы хотим хэшировать.

Программа работает в интерактивном режиме из соображений безопасности: если бы нам пришлось вводить пароль открытым текстом непосредственно в качестве аргумента какой-либо опции, он был бы виден в выводе ps как часть команды и в истории оболочки.

Хешированный пароль возвращается как вывод команды:

Соль генерируется случайным образом, но для передачи значения в явном виде мы можем использовать опцию -s (сокращение от –salt).

Если по какой-то причине мы все же хотим ввести хэшируемый пароль не интерактивным способом (опять же, это не рекомендуется), мы используем опцию –stdin и некоторую магию перенаправления:

Хеширование пароля с помощью Python

Другой метод, который мы можем использовать для генерации хэша пароля в Linux, – это использование Python и модуля crypt.

Первым делом мы импортируем модуль, а затем используем входящую в него функцию crypt.

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

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

crypt.METHOD_SHA512
crypt.METHOD_SHA256
crypt.METHOD_BLOWFISH
crypt.METHOD_MD5
crypt.METHOD_CRYPT

crypt.METHOD_SHA512 является самым сильным.

При его использовании пароль хэшируется функцией sha512 с солью из 16 символов.

Чтобы избежать передачи исходного пароля как части команды, который также будет запомнен в истории оболочки python, мы должны также импортировать модуль getpass и сделать так, чтобы пароль запрашивался интерактивно с помощью метода getpass(), включенного в него.

Чтобы сгенерировать наш хэшированный пароль, выполните следующие действия:

При работе из оболочки вышеприведенный пример можно выполнить как однострочный, вызвав интерпретатор Python с опцией -c, которая позволяет нам указать команду для непосредственного выполнения:

В примере, показанном выше вы можете заметить, что мы использовали функцию print() для вывода сгенерированного хэшированного пароля, чтобы он был использован в качестве результата подстановки команды и стал значением переменной hashed_password.

Хеширование пароля с помощью openssl

Третий и последний метод генерации хэша пароля, который мы рассмотрим в этой статье, заключается в использовании команды openssl passwd.

Ранее мы уже рассматривали этот инструмент в статьях:

По умолчанию команда использует алгоритм crypt для генерации хэша пароля.

Чтобы использовать алгоритм sha512, вместо него нужно использовать опцию -6.

Вот что мы напишем:

Это поведение можно отключить с помощью опции –noverify.

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

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

Какой алгоритм хеширования использует Linux?

В дистрибутивах Linux пароли для входа обычно хешируются и хранятся в файле / etc / shadow с использованием алгоритма MD5. Безопасность хеш-функции MD5 была серьезно подорвана из-за уязвимостей, связанных с коллизиями.

Какой алгоритм хеширования лучше всего использовать?

Google рекомендует использовать более сильные алгоритмы хеширования, такие как SHA-256 и SHA-3. Другие варианты, обычно используемые на практике, — это bcrypt, scrypt и многие другие, которые вы можете найти в этом списке криптографических алгоритмов.

Что такое хеш Linux?

hash — это команда в Unix и Unix-подобных операционных системах, которая выводит информацию о местоположении для найденных команд. Команда hash также была перенесена в операционную систему IBM i.

Каков алгоритм хеширования по умолчанию для современных дистрибутивов Linux?

Функция bcrypt — это алгоритм хеширования пароля по умолчанию для OpenBSD и других систем, включая некоторые дистрибутивы Linux, такие как SUSE Linux.

Какое шифрование использует Linux для паролей?

Шифрование очень полезно, возможно, даже необходимо в наши дни. Существуют всевозможные методы шифрования данных, каждый со своим набором характеристик. Большинство Unicies (и Linux не является исключением) в основном используют алгоритм одностороннего шифрования, называемый DES (стандарт шифрования данных), для шифрования ваших паролей.

Почему MD5 плохой?

Использовать соленый md5 для паролей — плохая идея. Не из-за криптографических слабостей MD5, а потому, что он быстрый. Это означает, что злоумышленник может пробовать миллиарды возможных паролей в секунду на одном графическом процессоре. Вам следует использовать преднамеренно медленные конструкции хеширования, такие как scrypt, bcrypt и PBKDF2.

Какой алгоритм хеширования используется для паролей?

Пароли должны быть хешированы с помощью PBKDF2, bcrypt или scrypt, MD-5 и SHA-3 никогда не должны использоваться для хеширования паролей, а SHA-1/2 (пароль + соль) также являются большим запретом. В настоящее время наиболее проверенным алгоритмом хеширования, обеспечивающим максимальную безопасность, является bcrypt. PBKDF2 тоже неплох, но если вы можете использовать bcrypt, вам следует.

Что такое хеш оболочки?

В UNIX-подобных операционных системах хеш — это встроенная команда оболочки bash, которая используется для перечисления хеш-таблицы недавно выполненных команд. Он используется для просмотра, сброса или ручного изменения хэша пути bash. Он сохраняет расположение недавно выполненных программ и показывает их, когда мы хотим это увидеть.

Какая польза от md5sum в Linux?

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

Где находится хеш-файл SHA1 в Linux?

Чтобы получить SHA-1 файла, передайте путь к файлу команде sha1sum. SHA-1 будет распечатан на стандартный вывод, сначала напечатав контрольную сумму SHA-1, а затем имя файла.

Какой алгоритм использует Bcrypt?

BCrypt основан на криптоматическом алгоритме блочного шифра Blowfish и имеет форму адаптивной хеш-функции.

Что значит хеширование?

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

Какой формат у sha512?

Файл, содержащий криптографический хэш SHA-0, SHA-1 или SHA-2 и использующий 512-битный блочный шифр; обычно это короткий текстовый файл, содержащий строку символов, представляющих 512 бит; используется в криптографии для проверки личности или конкретного файла.

Где хранится пароль в Linux?

/ Etc / passwd — это файл паролей, в котором хранится каждая учетная запись пользователя. Хранилища файлов / etc / shadow содержат информацию о пароле для учетной записи пользователя и дополнительную информацию о устаревании. Файл / etc / group — это текстовый файл, который определяет группы в системе.

Где в Linux хранятся зашифрованные пароли?

В операционной системе Linux файл теневых паролей — это системный файл, в котором хранятся шифрованные пароли пользователей, поэтому они недоступны для людей, пытающихся взломать систему. Обычно информация о пользователе, включая пароли, хранится в системном файле / etc / passwd.

Кто WC Linux?

Команда Wc в Linux (подсчет количества строк, слов и символов) В Linux и Unix-подобных операционных системах команда wc позволяет подсчитывать количество строк, слов, символов и байтов в каждом заданном файле или стандартном вводе и распечатать результат.

Astra Linux

Инновационная операционная система класса Linux обеспечивает защиту информации, содержащей сведения, составляющие государственную тайну с грифом не выше «совершенно секретно». Разработаны и включены в состав операционной системы программные компоненты, расширяющие её функциональность и повышающие уровень защищённости и удобства её использования.

Разработаный и сертифицированью в системах сертификации средств защиты информации ФСБ России, ФСТЭК России и Минобороны России релиз «Смоленск» операционной системы специального назначения ‘Astra Linux Special Edition’ предназначен для функционирования на средствах вычислительной техники с процессорной архитектурой х86-64.

ЕДИНАЯ ПЛАТФОРМА ДЛЯ ВСЕХ ТИПОВ УСТРОЙСТВ

3 группа Однопользовательская

Многопользовательская с равными полномочиями

Многопользовательская с разными полномочиями

Применение модулей доверенной загрузки

Класс межсетевых экранов

Уровень контроля отсутствия НДВ

///Л ОС CH .Astra Linux Special Edition. K1 АПМДЗ « Максим- М1.

Рис. 3.4. Класс защищённости автоматизированных систем

Операционная система специального назначения Astra Linux Special Edition предназначена для создания на её основе автоматизированных систем в защищённом исполнении, обрабатывающих информацию со степенью секретности «совершенно секретно» включительно (рис. 3.3, 3.4).

Виды защищаемой информации:

— коммерческая тайна;
— конфиденциальная информация;
— персональные данные;
— государственная тайна.

Основные компоненты операционной системы (табл. 3.16).

• Программный комплекс организации домена безопасности (единого пространства пользователей и ресурсов локальной вычислительной сети)
• Комплексная защита информации разграничения доступа
• Средства разработки
• Терминальный сервер
• Контроль целостности операционной системы
• Аудит и журналирование событий
• Система разграничения доступа к внешним устройствам
• Средства резервного копирования и восстановления
• FLY — графическая система и полнофункциональный рабочий стол

Название компонента

ASTRA’*: LINUX Версии ОС Astra Linux Special Edition («Смоленск»)

ASTRA^LINUX Версии ОС Astra Linux Common Edition («Орёл»)

Базовый репозиторий

Системная библиотека «С»

Компилятор, отладчик

Защищённая графическая система

Библиотека libqt3

Библиотека Iibqt4

Библиотека libqtS

Оконный менеджер

Защищенная система управления базами данных (СУБД)

Работа с документами. Пакет офисных программ

OpenOffice (текстовый редактор, табличный редактор, программа подготовки презентаций, механизм подключения к внешним СУБД, векторный графический редактор)

LibreOffice (текстовый редактор, табличный редактор, программа подготовки презентаций, механизм

подключения к внешним СУБД, векторный графический редактор, редактор формул)

Название компонента

ASTRA**LINUX Версии ОС Astra Linux Special Edition

ASTRA“^LINUX Версии ОС Astra Linux Common Edition («Орёл»)

Защищённый комплекс программ гипертекстовой обработки данных

Web-сервер Apache2

Браузер Firefox

Защищённые средства передачи электронной почты

Сервер электронной почты Exim4

Сервер электронной почты Dovecot

Почтовый клиент

Thunderbird

Редактор растровой графики

Воспроизведение мультимедиа

Библиотека периферии HP

Защищённый сервер печати. Обеспечивает маркировку и печать документов

Защищённый программный комплекс организации домена’.

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

Разграничение доступа’.

— дискреционное разграничение доступа;
— Access Control List или ACL — список контроля доступа для пользователей и файлов;
— мандатное разграничение доступа.

Работа с мультимедиа и изображениями’.

— набор программ для воспроизведения аудио- и видеофайлов VLC;

— редактор растровой графики;
— запись оптических дисков;
— программа сканирования;
— программа работы с web-камерой.

Средства разработки’.

— библиотеки;
— заголовочные файлы;
— компилятор GCC;
— отладчик GDB;
— среда разработки QT-Creator.

Терминальный сервер. Организация сетевой работы посредством размещения всех пользовательских приложений и данных в Едином пространстве пользователей, доступ к которому осуществляется с компьютеров-терминалов.

Контроль целостности операционной системы:

— проверка соответствия дистрибутива;
— контроль объектов файловой системы;
— контроль цифровой подписи исполняемых файлов, обеспечивающий проверку их неизменности и подлинности.

Аудит и журналирование событий. Централизованная система аудита событий безопасности для регистраций событий с выдачей на рабочее место администратора безопасности информации данных о попытках несанкционированного доступа (в версии 1.3 операционной системы).

Система разграничения доступа к внешним устройствам обеспечивает реализацию правил разрешения или блокирования доступа.

Средства резервного копирования и восстановления. Предназначены для резервирования средств защиты информации и обрабатываемых данных, а также для восстановления системы.

FLY — уникальная графическая система и полнофункциональный рабочий стол.

Ключевые особенности Astra Linux Special Edition по реализации требований безопасности информации заключаются в следующем.

В операционной системе реализован механизм мандатного разграничения доступа. При этом принятие решения о запрете или разрешении доступа субъекта к объекту принимается на основе типа операции (чтение/запись/исполнение), мандатного контекста безопасности, связанного с каждым субъектом, и мандатной метки, связанной с объектом. Для удобства работы пользователей и разработки прикладных программ разработана системная библиотека с удобным программным интерфейсом доступа к механизму мандатного разграничения доступа. Обеспечено взаимодействие входящих в состав операционной системы клиент-серверных компонент, а также файловых систем (ext3, CIFS) с механизмом мандатного разграничения доступа.

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

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

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

Реализована оригинальная подсистема протоколирования, интегрированная во все компоненты операционной системы и осуществляющая надёжную регистрацию событий с использованием специального сервиса.

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

Разработанный рабочий стол пользователя Fly тесным образом интегрирован с механизмами защиты информации. В нём реализованы следующие возможности:

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

Менеджер файлов позволяет видеть метки объектов файловой системы (файлов и каталогов) с текстовой и цветовой индикацией.

Режим ограничения действий пользователя (режим «киоск») служит для ограничения прав пользователей в системе.

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

Для установки прав доступа существует система профилей — файлы с готовыми наборами прав доступа для запуска каких-либо программ. Также есть средства создания таких профилей под любые пользовательские задачи.

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

Защита адресного пространства процессов. В операционной системе для исполняемых файлов используется формат, позволяющий установить режим доступа к сегментам в адресном пространстве процесса. Централизованная система сборки программного обеспечения гарантирует установку минимального режима, необходимого для функционирования программного обеспечения. Также существует возможность использования технологии NOT EXECUTE BIT, поддерживаемой современными процессорами.

Реализован механизм, обеспечивающий проверку неизменности и подлинности загружаемых исполняемых файлов в формате ELF. Проверка производится на основе проверки векторов аутентичности, рассчитанных в соответствии с ГОСТ Р 34.10-2001 и внедряемых в исполняемые файлы в процессе сборки.

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

Для решения задач контроля целостности применяется функция хеширования в соответствии с ГОСТ Р 34.11-94. Базовой утилитой контроля целостности является программное средство на основе открытого проекта Another File Integrity Checker.

Для организации доменной структуры разработана подсистема Astra Linux Directory (ALD) на базе открытых стандартов LDAP. Эта подсистема предоставляет средства для организации домена и единого пространства пользователей, которые обеспечивают:

— сквозную аутентификацию в сети;
— централизацию хранения информации об окружении пользователей;
— централизацию хранения настроек системы защиты информации на сервере;
— централизацию управления серверами DNS и DHCP;
— интеграцию в домен защищённых серверов СУБД, серверов печати, электронной почты, web-сервисов и др.;
— централизованный аудит событий безопасности в рамках домена.

В состав операционной системы входит объектно-реляционная СУБД PostgreSQL, в которой реализованы дискреционный и мандатный механизмы контроля доступа к защищаемым ресурсам БД.

В основе мандатного механизма разграничения доступа лежит управление доступом к защищаемым ресурсам БД на основе иерархических и неиерархических меток доступа. Это позволяет реализовать многоуровневую защиту с обеспечением разграничения доступа пользователей к защищаемым ресурсам БД и управление потоками информации. В качестве иерархических и неиерархических меток доступа при использовании СУБД используются метки конфиденциальности или метки безопасности операционной системы.

Проведены необходимые работы по интеграции СУБД с подсистемой аудита и средствами организации домена.

В состав защищённого комплекса программ электронной почты входят сервер электронной почты, состоящий из агента передачи электронной почты Exim и агента доставки электронной почты Dovecot, а также клиент электронной почты Mozilla Thunderbird, обеспечивающие следующие функциональные возможности:

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

Агент передачи электронной почты использует протокол SMTP и обеспечивает решение следующих задач:

— доставку исходящей почты от авторизованных клиентов до сервера, который является целевым для обработки почтового домена получателя;
— приём и обработку почтовых сообщений доменов, для которых он является целевым;
— передачу входящих почтовых сообщений для обработки агентом доставки электронной почты.

Агент доставки электронной почты Dovecot предназначен для решения задач по обслуживанию почтового каталога и предоставления удалённого доступа к почтовому ящику по протоколу IMAP. Протокол POP3 отключён.

В состав защищённого комплекса программ гипертекстовой обработки данных входят браузер Mozilla Firefox и web-сервер Apache, интегрированный со встроенными средствами защиты информации для обеспечения мандатного разграничения доступа при организации удалённого доступа к информационным ресурсам.

Какой алгоритм хеширования использует Linux?

Какой алгоритм хеширования лучше всего использовать?

Что такое хеш Linux?

Каков алгоритм хеширования по умолчанию для современных дистрибутивов Linux?

Какое шифрование использует Linux для паролей?

Почему MD5 плохой?

Какой алгоритм хеширования используется для паролей?

Что такое хеш оболочки?

Какая польза от md5sum в Linux?

Где находится хеш-файл SHA1 в Linux?

Какой алгоритм использует Bcrypt?

BCrypt основан на криптоматическом алгоритме блочного шифра Blowfish и имеет форму адаптивной хеш-функции.

Что значит хеширование?

Какой формат у sha512?

Где хранится пароль в Linux?

Где в Linux хранятся зашифрованные пароли?

Кто WC Linux?

Как настроить Linux для входа в домен с использованием алгоритмов ГОСТ

Протокол Kerberos 5 сейчас активно используется для аутентификации. Особенностью данного протокола является то, что он осуществляет аутентификацию, базируясь на четырех китах:

Симметричное шифрование;
Хеширование;
ЭЦП;
Третья доверенная сторона.

Начиная с пятой версии появилась возможность использовать еще асимметричное шифрование (для электронной подписи). Более подробно на работе протокола Kerberos останавливаться не имеет смысла, ибо описание алгоритма можно посмотреть тут.

К сожалению, количество алгоритмов шифрования, хеширования и ЭЦП, которые использует данный протокол, не настолько велико, насколько хотелось бы, поэтому в данной статье я хочу показать, как добавить легко и просто собственные алгоритмы в реализацию данного протокола MIT’ом. Добавлять же мы будем наши отечественные алгоритмы: ГОСТ 28147-89 (aka Магма), ГОСТ Р 34.11-2012 (aka Стрибог) и ГОСТ Р 34.10-2012 (хотелось бы тоже иметь для него aka, но я не знаю:(). Готовое решение для данных алгоритмов можно его найти в моем репозитории. На стороне клиента мы будем использовать аппаратные реализации алгоритмов ГОСТ в Рутокене ЭЦП 2.0 и их программные реализации в engine GOST для openssl. Но самый безопасный вариант хранения ключей – когда они генерируются непосредственно на Рутокене и никогда не покидают его память во время криптографических операций. Для такого варианта работы потребуется rtengine.

Перед тем, как приступить к внедрению алгоритмов, опишем основные места, где будут производится изменения. Внутри директории src/lib/crypto/ находятся реализации всех алгоритмов, отвечающих за симметричную криптографию и хеширование. В ней имеются 2 реализации этих криптографических алгоритмов: встроенная(builtin) и openssl. Дабы сэкономить время и место, мы, естественно, будем добавлять реализации алгоритмов с помощью openssl, в котором они уже есть (ну или почти есть, но об этом чуть позже). Для добавления же асимметричных алгоритмов, нужно будет подправить плагин src/plugins/preauth/pkinit

Если у вас еще не настроен Kerberos, то инструкцию по его первичной настройки и эксплуатации можно взять тут. В дальнейшем автор полагает, что вы работаете с доменом AKTIV-TEST.RU

Добавление алгоритмов хеширования и симметричного шифрования

Как уже было ранее озвучено, мы не будем писать алгоритмы шифрования и хеширования с нуля, а воспользуемся готовой реализацией данных алгоритмов в openssl. Напрямую openssl не поддерживает в себе реализацию отечественных алгоритмов, но обладает мобильностью в данном вопросе и позволяет добавлять новые алгоритмы, используя механизм engine GOST для работы с ключами в файловой системе и, хранящие на токене — rtengine.

Небольшое введение в механизм engine openssl и подключение engine GOST

Engine в openssl – это небольшая динамическая библиотека, которую openssl подгружает в runtime по требованию. Каждая такая библиотека, должна содержать в себе определенные символы (функции) для загрузки необходимых алгоритмов. В данной работе мы воспользуемся engine gost, который содержит в себе все необходимые отечественные криптографические алгоритмы.

Установка дичайше проста, например, и происходит следующим образом:

Выкачиваете из репозитория реализацию данного энджина.

собираете библиотеку с ним (mkdir build && cd build && cmake… && make):

В директории bin (КОТОРАЯ ПОЯВИТСЯ В КОРНЕВОМ КАТАЛОГЕ ПРОЕКТА. ) будет лежать динамическая библиотека gost.so – это и есть наш энджин. Его нужно будет перенести в директорию, где хранятся энджины openssl. Узнать месторасположение данной директории можно с помощью:

Дело за последним – нужно сказать openssl, где находится данный энджин и как он называется. Сделать можно это с помощью изменения файла конфигурации openssl.cnf. Месторасположение которого можно узнать с помощью:

В конец данного файла нужно будет внести следующее содержимое:

После этого данный энджин должен появится в openssl. Проверить его работоспособность можно заставив, например, сгенерировать приватный ключ в файле по ГОСТ Р 34.10-2012:

Флаг -engine как раз говорит о том, какой engine нужно подгрузить перед началом работы для того, чтобы стал виден алгоритм генерации ключей для ГОСТ Р 34.10-2012.

Реализация алгоритма хеширования

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

Т.к. нам понадобится уверенность в подключении в разных местах нашей программы, давайте создадим сначала небольшую библиотеку gost_helper, которая будет содержать в себе функцию инициализации энджина в openssl, а так же для удобства несколько функций, возвращающих контексты некоторых алгоритмов хеширования – нам это поможет в дальнейшем. Назовем эту библиотеку gost_helper и создадим для нее соответствующий заголовочник и исходный файл в директории src/lib/crypto/openssl/:

После добавления вспомогательной библиотеки необходимо будет объявить о ее существовании в Makefile и выписать ее зависимости от файлов. Для этого добавим следующее:

Стоит заметить, что в дальнейшем при подключении данной библиотеки, нам надо будет добавлять зависимости некоторых файлов от заголовочника данной библиотеки. Делается это очень просто – отыскивается цель, куда надо добавить зависимость в deps файле и записывается зависимость от rel/path/to/gost_helper.h. Например, в src/lib/crypto/openssl/hash_provider/deps нужно будет добавить следующее:

В целях экономии места в статье и чтобы размять ваши мозги, я больше не буду обращать на это внимание: будьте внимательны и осторожны!

Добавим теперь реализации функций хеширования, все их реализации у нас лежат в src/lib/crypto/openssl/hash_provider/hash_evp.c. Туда нужно будет дописать следующее:

Теперь надо объявить эти контексты во всей библиотеке. Для этого нужно создать их описание в файле src/lib/crypto/krb/crypto_int.h.

Объявим идентификатор связки Стрибог и AES, внедря макросы, которые мы назовем CKSUMTYPE_STRIBOG_256_AES256, CKSUMTYPE_STRIBOG_512_AES256, ENCTYPE_AES256_CTS_STRIBOG_256, ENCTYPE_AES256_CTS_STRIBOG_512. Их надо объявить в шаблоне заголовочного файла src/include/krb5/krb5.hin. Выглядеть это будет примерно так:

Теперь необходимо добавить две связки функции хеширования и шифрования и функции шифрования и хеширования. Зачем две, если они эквиваленты, спросите вы? Ответ: не знаю, или это исторический костыль или способ оптимизации. Тем не менее, давайте добавим в необходимые файлы новые структуры:

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

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

Теперь приступим к проверке. Для этого давайте выставим принудительное использование внедренных нами алгоритмов в файлы конфигурации Kerberos. Выполните следующее:

Подправим файл конфигурации kdc.conf (у меня это /usr/local/var/krb5kdc/kdc.conf). Выставим принудительное хеширование с помощью нововведенного алгоритма:

Аналогичные изменения в файле конфигурации всего протокола krb5.conf (у меня он находится по адресу /etc/krb5.conf):

Далее запустим krb5kdc т.к. изменился master_key, то возможно придется создать базу данных principals заново с помощью krb5_newrealm.

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

Проверим, что хеширование происходит по указанному алгоритму можно с
помощью klist -e.

Если сервис не запускается, то его можно запустить из-под рута с помощью src/kdc/krb5kdc. Если все запустилось, прошло гладко – поздравляю вас! Иначе – увы, панацею от всех проблем я не предлагаю, а лишь предлагаю «небольшую» инструкцию, содержащую основные шаги, которые вам придется совершить, дабы внедрить новый алгоритм в Kerberos. И если у вас ничего не вышло – берите в руки gdb и смотрите, где что выходит не так. Вам лишь могу дать несколько советов:

собирать проект в режиме отладки можно, если передать в ./configure CFLAGS=» -g -O0″;
запустить krb5kdc не в фоновом режиме можно с помощью флага -n;
надеюсь до этого не дойдет (хотя при реализации асимметричных алгоритмов у меня все-таки дошло) – возможно вам потребуются отладочные символы openssl – установите их или взяв из репозитория, или установив openssl из исходников с отладочными символами;
то же самое касается gost engine.

По идее этого набора советов вам должно хватить для того чтобы избавить себя от лишней траты времени в поисках «неизведанного».

Реализация алгоритма шифрования

В этом разделе я покажу, как можно добавить свой алгоритм шифрования данных в Kerberos, и мы попробуем создать связку Магмы и Стрибога, добавленного в прошлом разделе. Тут я уже предполагаю, что небольшая библиотека gost_helper уже была добавлена в прошлом разделе. Ну что же, разминаем пальцы и приступаем:

Сначала опишем алгоритм в нашей библиотеке libk5crypto описав их в заголовочном файле src/lib/crypto/krb/crypto_int.h.

В директории src/lib/crypto/openssl/enc_provider добавим исходник gost.c, содержащий в себе реализацию всех необходимых алгоритмов (за основу я взял исходник алгоритма des). Важно заметить, что мы реализуем только режим шифрования cbc, так что для самопроверки вы можете взять любой другой режим шифрования и добавить его:

В шаблоне src/lib/crypto/openssl/enc_provider/Makefile.in укажем, что появился новый исходник:

Не забываем про указание зависимостей в src/lib/crypto/openssl/enc_provider/deps:

Добавим идентификаторы связок к src/include/krb5/krb5.hin:

Опишем структуру связок функции хеширования и шифрования, как в прошлом разделе:

Добавим в список режимов шифрования по умолчанию в файле src/lib/krb5/krb/init_ctx.c:

После этих манипуляций можно попробовать протестировать нововведенный алгоритм. Тестирование происходит аналогичным образом, что и в прошлом разделе. Имя связки можно взять в виде алиаса (например, gost89-stribog512) или с помощью имени самого алгоритма (например, gost89-cbc-stribog-512). Надеюсь, что все заработает, иначе не забывайте о том, что я сказал ранее.

Добавление алгоритма цифровой подписи

Ура! Мы приступаем к финальному разделу данной статьи и попробуем добавить собственный алгоритм электронной подписи. Не стоит пугаться, его добавить проще чем что-либо еще, так что давайте поскорее приступим… Хотя нет, подождите, для начала небольшая ремарка.

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

Как-то так. Ну что же, если у вас хватило смелости приступить к этому, то давайте начнем. В данной статье я покажу вам два способа получения и хранения приватных ключей и сертификатов: в файловой системе и на токене. В сущности, для обоих применима Аксиома Эскобара, но для второго способа потребуется дополнительный энджин, так что если вы решитесь пойти путем шиноби, то милости просим в данный раздел, остальные могут его пропустить.

Настройка openssl для работы с токенами (на примере Рутокен)

Для работы с Рутокенами, аппаратно поддерживающими ГОСТ-криптографию, для openssl существует rtengine. Его установка достаточно проста и не сильно отличается от GOST, нужно только знать, что и где брать.

Скачиваете отсюда SDK rutoken разработчика и достаете из папки sdk/openssl/rtengine/bin/ собранную под вашу платформу библиотеку с энжином и помещаете в папку с engine.

Скачать и установить модуль librtpkcs11ecp.so. отсюда

Собирать утилиту из ветки master OpenSC взяв коммит 8cf1e6f

После того как мы все это сделали, осталось настроить конфигурационный файл openssl.cnf:

Работоспособность engine мы проверим на деле.

Создание приватного ключа и сертификата для принципала, KDC и УЦ

За основу данной инструкции была взята инструкция по настройке kerberos. Я лишь адаптировал ее для работы с русскими алгоритмами, так что частично заглядывайте туда.

Создадим приватный ключ и сертификат удостоверяющего центра, а также приватный ключ, запрос на сертификат и сам сертификат, подписанный УЦ для KDC:

Изменим конфигурационный файл kdc, чтобы он знал, откуда брать ключи и сертификаты:

[libdefaults]
spake_preauth_groups = edwards25519

Создадим приватный ключ и заявку на сертификат для нашего принципала. Тут будет развилка, и надо выполнить разные действия в зависимости от того, где мы будем хранить приватный ключ: на токене или в ФС:

Для создания ключа и заявки в ФС все делаем почти аналогично, как для KDC:

Для создания ключа на токене и подписания сертификата для него нужно выполнить следующее:

Теперь подпишем нашу заявку:

Теперь дело за малым: в первом случае загружаем сертификат в специальную директорию, во втором – на токен:

Настраиваем файл конфигурации клиента (у меня это /etc/krb5.conf):

Надеюсь, что на данном этапе проблем не возникнет. Мы совсем близко! Добавим реализацию новых алгоритмов.

Добавление нового алгоритма цифровой подписи

Алгоритмы ЭЦП добавить куда проще чем те, что рассматривались ранее – придется заменить всего-то 2 файли! src/plugins/preauth/pkinit/pkcs11.h и src/plugins/preauth/pkinit/pkinit_crypto_openssl.c

Начнем с добавления идентификаторов новых механизмов и ключей в заголовочник pkcs11.h. Идентификатор механизма – это название алгоритма, который подается токену для того, чтобы он его совершил. Все эти идентификаторы стандартизированы и их можно найти в интернете (хоть и с большим трудом). Наши я нашел здесь в sdk/pkcs11/include/rtpkcs11t.h. Добавим в заголовочник следующие идентификаторы ключей и механизмов:

Всеми ими мы не воспользуемся, но на будущее можно добавить.

В файле pkinit_crypto_openssl.c, в первую очередь, нужно добавить подгрузку энджинов перед началом работы. Вызов этой функции также нужно вставить перед get_key, т.к. эта функция почему-то вызывается перед подгрузкой энджинов:

После инициализации энджинов можно приступить к замене механизмов и электронной подписи. В данный момент жестко зашит только один алгоритм – RSA с хешом, полученным из sha1. Мы же встроим выбор между возможными режимами в зависимости от типа ключа, хранящегося на токене или в ФС. Для этого введем несколько функций, которые будут на вход получать контексты шифрования, а на выходе выдавать необходимые идентификаторы алгоритмов и механизмов. Также будет необходимо немного подправить функцию получения хендла приватного ключа с токена, т.к. она возвращает только RSA ключи:

Теперь лишь осталось в функциях создания цифровой подписи cms_signeddata_create и create_signature заменить жесткую установку алгоритма на выбор алгоритма в зависимости от контекста:

После всех этих манипуляций вы можете попробовать зайти, используя токен или сертификат в файловой системе (во втором случае, вероятно, потребуются права рута):

Если после запроса пароля токена не потребовалось вводить пароль user, значит, все отработало правильно.

Все замечания и вопросы вы можете писать в комментариях, а я постараюсь на них оперативно ответить.

Российская защищенная ОС «Astra Linux»

Разработку на базе ядра Linux начало в 2008 году АО «НПО РусБИТех». Система принята на снабжение Минобороны РФ приказом министра в 2013 году, министерство также приняло участие в доработке продукта[6]. Система внедряется во исполнение распоряжения Правительства РФ № 2299-р от 17 декабря 2010 г., утверждающего План перехода федеральных органов исполнительной власти и федеральных бюджетных учреждений на использование свободного программного обеспечения (! — из серии: война — это мир, ложь — это истина, свободное ПО — это свободно недоступная ОС АстраЛинух).

Производитель заявляет, что «лицензионные соглашения на операционные системы Astra Linux разработаны в строгом соответствии с положениями действующих правовых документов Российской Федерации, а также международных правовых актов», при этом они «не противоречат духу и требованиям лицензии GPL». Система работает с пакетами на базе .deb. Исходные тексты ядра доступны на сайте разработчика.

В состав дистрибутива входят такие пакеты с открытым исходным кодом, как офисный пакет LibreOffice, браузер Firefox, почтовый клиент Thunderbird, редактор растровой графики GIMP, проигрыватель мультимедиа VLC и другие, что делает эту ОС уязвимой от закладок в этом ПО.

В августе 2017 г. разработчики Astra Linux и пакета офисных приложений «МойОфис» сообщили о запуске совместного продукта — программной платформы, в состав которой входят Astra Linux и «МойОфис».

В феврале 2018 г. объявлено, что Astra Linux была адаптирована для российских микропроцессоров «Эльбрус».

Применение ОС АстраЛинух

Система применяется во многих государственных учреждениях. В частности, на ней построена информационная система Национального центра управления обороной РФ (по чему можно оценить реальный уроень его защищенности). В июле 2015 г. состоялись переговоры о переводе на Astra Linux госучреждений Республики Крым, в которой официальное использование популярных ОС затруднительно из-за антироссийских санкций. В ноябре 2015 года подписано соглашение о сотрудничестве[16] с производителем серверов Huawei, который начал тестировать свои серверы на совместимость с Astra Linux.

В январе 2018 года Минобороны РФ объявило, что полностью переводит все военные ПК на Astra Linux и отказывается от Microsoft Windows. После этого планируется перевод на Astra Linux военных смартфонов и планшетов.

Основные версии ОС АстраЛинух

Производителем разрабатывается базовая версии Astra Linux — Common Edition (общего назначения) и её модификация Special Edition (специального назначения):

— издание общего назначения — Common Edition — предназначено для среднего и малого бизнеса, образовательных учреждений;
— издание специального назначения — Special Edition — предназначено для автоматизированных систем в защищённом исполнении, обрабатывающих информацию со степенью секретности «совершенно секретно» включительно; новые версии выходят с периодичностью в 2 года.

Операционная система Astra Linux Special Edition основана на дистрибутиве Astra Linux Common Edition и включает в себя ряд принципиальных доработок для обеспечения соответствия требованиям руководящих российских документов по защите информации. Кроме того, в целях оптимизации из дистрибутива Astra Linux Special Edition исключён ряд дублирующих друг друга компонент, решающих сходные целевые задачи. Например, из двух СУБД MySQL и PostgreSQL, входящих в состав Astra Linux Common Edition, в дистрибутив операционной системы Astra Linux Special Edition включена СУБД PostgreSQL, доработанная по требованиям безопасности информации.

Выпускаемые релизы носят названия городов-героев России:

Релизы Astra Linux

Архитектура Common Edition Special Edition Сфера применения
x86-64 Орёл Смоленск рабочие станции и серверы
ARM — Новороссийск мобильные устройства и встраиваемые компьютеры
MIPS — Севастополь настольные и мобильные устройства, сетевое оборудование
POWER — Керчь высокопроизводительные серверы
IBM System z — Мурманск отказоустойчивые серверы (мейнфреймы)
Эльбрус 2000 — Ленинград[22] вычислительные комплексы «Эльбрус»

История версий ОС «Astra Linux»

Версии Astra Linux Special Edition (Смоленск)
Версия Название Дата выпуска Версия ядра Linux
1.2 Astra Linux Special Edition (Смоленск) 28 октября 2011 2.6.34
1.3 Astra Linux Special Edition (Смоленск) 26 апреля 2013 3.2.0[23]
1.4 Astra Linux Special Edition (Смоленск) 19 декабря 2014[24] 3.16.0
1.5 Astra Linux Special Edition (Смоленск) 08 апреля 2016[25] 4.2.0
Версии Astra Linux Сommon Edition (Орёл)
Версия Название Дата выпуска Версия ядра Linux
1.5 Astra Linux Сommon Edition (Орёл) конец 2009 2.6.31
1.6 Astra Linux Сommon Edition (Орёл) 23 ноября 2010
1.7 Astra Linux Сommon Edition (Орёл) 3 февраля 2011 2.6.34
1.9 Astra Linux Common Edition (Орёл) 12 февраля 2013 3.2.0
1.10 Astra Linux Common Edition (Орёл) 14 ноября 2014[26] 3.16.0[23]
1.11 Astra Linux Common Edition (Орёл) 17 марта 2016[27] 4.2.0[28]
2.11.3 Astra Linux Common Edition (Орёл) 29 марта 2018 4.15.3

Особенности версии ОС «Astra Linux» Special Edition

Идентификация и аутентификация в ОС «Astra Linux»

Функция идентификации и аутентификации пользователей в Astra Linux основывается на использовании механизма PAM. Кроме того, в состав операционной системы включены средства поддержки двухфакторной аутентификации.

Дискреционное разграничение доступа в ОС «Astra Linux»

В Astra Linux реализован механизм избирательного управления доступом, который заключается в том, что на защищаемые именованные объекты устанавливаются (автоматически при их создании) базовые правила разграничения доступа в виде идентификаторов номинальных субъектов (UID и GID), которые вправе распоряжаться доступом к данному объекту и прав доступа к объекту. Определяются три вида доступа: чтение (read, r), запись (write, w) и исполнение (execution, x).

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

Мандатное разграничение доступа в ОС «Astra Linux»

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

Механизм мандатного разграничения доступа затрагивает следующие подсистемы:

механизмы IPC;
стек TCP/IP (IPv4);
файловые системы Ext2/Ext3/Ext4;
сетевую файловую систему CIFS;
файловые системы proc, tmpfs.

В Astra Linux Special Edition существует 256 мандатных уровней доступа (от 0 до 255) и 64 мандатных категории доступа

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

Модель контроля и управления доступом в ОС «Astra Linux»

Вместо системы принудительного контроля доступа SELinux, в Astra Linux Special Edition используется запатентованная мандатная сущностно-ролевая ДП-модель управления доступом и информационными потокам (МРОСЛ ДП-модель), которая как бы лишена недостатков модели Белла — Лападулы (деклассификация, нарушение логики доступа к данным при обработке потока информации в распределённой среде) и содержит дополнительные способы разграничения доступа, например, два уровня целостности системы.

В отличие от классической модели мандатного управления доступом, в МРОСЛ ДП-модели дополнительно к мандатному управлению доступом реализован мандатный контроль целостности дистрибутива и файловой системы (препятствующий доступу к защищаемой информации скомпрометированными субъектами после перехвата управления и повышения привилегий (получения административных прав), предусмотрено ролевое управление доступом, наличие иерархии сущностей и применено противодействие запрещённым потокам по памяти и по времени.

Указанная математическая модель реализована в программном коде специалистами АО «НПО „РусБИТех“» и Академии ФСБ России и верифицирована Институтом Системного программирования Российской Академии Наук. В результате дедуктивной верификации модель была полностью формализована и верифицирована (что означает возможность ее вскрытия методом обхода дедуктивных схем).

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

Защита от эксплуатации уязвимостей ОС «Astra Linux»

В состав ядра операционной системы Astra Linux включён набор изменений PaX, обеспечивающий работу программного обеспечения в режиме наименьших привилегий и защиту от эксплуатации различных уязвимостей в программном обеспечении:

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

Другие функции ОС «Astra Linux»

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

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

Регистрация событий: расширенная подсистема протоколирования, интегрированная во все компоненты операционной системы и осуществляющая надёжную регистрацию событий с использованием специального сервиса parlogd.

Механизмы защиты информации в графической подсистеме: графическая подсистема включает в себя Х-сервер Xorg, пользовательский рабочий стол Fly, а также ряд программных средств, предназначенных как для пользователей, так и для администраторов системы. Проведена работа по созданию и встраиванию в графическую подсистему необходимых механизмов защиты информации, обеспечивающих выполнение мандатного разграничения доступа в графических приложениях, запущенных в собственном изолированном окружении.

Механизм контроля замкнутости программной среды: реализован механизм, обеспечивающий проверку неизменности и подлинности загружаемых исполняемых файлов в формате ELF. Проверка производится на основе проверки векторов аутентичности, рассчитанных в соответствии с ГОСТ Р 34.10-2012 и внедряемых в исполняемые файлы в процессе сборки.

Контроль целостности: для решения задач контроля целостности применяется функция хэширования в соответствии с ГОСТ Р 34.11-94.1

Какие алгоритмы хеширования поддерживает astra linux