Модули доверенной загрузки. Преимущества и особенности
Статья кратко описывает современные проблемы информационной безопасности, связанные с первыми шагами функционирования компьютера — работой UEFI BIOS, и рассказывает о необходимости использования модулей доверенной загрузки, которые обеспечивают высокий уровень доверия и безопасности устройств.
Автор: Иван Кадыков, руководитель продуктового направления компании «ИнфоТеКС»
Введение
Производители средств информационной безопасности, разрабатывая свои системы защиты конечных точек, традиционно основное внимание уделяют программным продуктам, отвечающим за безопасность операционной системы (ОС). При этом часто упускается из вида ситуация, при которой угроза информационной безопасности может возникнуть еще до старта операционной системы, в процессе загрузки BIOS.
BIOS (Basic Input-Output system) и его современная «модификация», UEFI (Unified Extensible Firmware Interface), предназначены для корректной инициализации оборудования при включении устройства и передачи управления загрузчику или непосредственно ядру ОС.
Благодаря открытым спецификациям UEFI BIOS, любой разработчик может написать свой код для запуска в низкоуровневой среде. Необходимо отметить, что код могут создавать как производители компьютерного оборудования, которые адаптируют UEFI BIOS к конкретным аппаратным средствам или собственным задачам, так и злоумышленники, но уже с целью получения контроля над компьютером, например, путем создания bootkit. Размещаясь в BIOS bootkit способен внедряться в процесс загрузки ОС и запускать зловредный код. В последние годы случаи обнаружения подобных угроз учащаются и это становится серьезной проблемой:
- В 2020 году специалисты «Лаборатории Касперского» обнаружили UEFI-bootkit Mosaic Regressor. Он заставлял операционную систему запустить вредоносный файл, который далее связывался с сервером управления, архивировал и передавал на сервер документы, с которыми работали на зараженном компьютере.
- Другой bootkit, обнаруженный этой же компанией в 2021 году, получил название MoonBounce. Его отличительной особенностью было то, что вредонос внедрялся во флэш-память SPI (Serial Peripheral Interface), расположенную на материнской плате. Использовался bootkit для развертывания еще одного вредоносного кода в ОС, который обращался к командному серверу за инструкциями. Интересная особенность этой цепочки заключалась в том, что она не оставляла следов на жестком диске, а выполнялась только в оперативной памяти.
- В 2021 году специалистами ESET был обнаружен зловред — ESPecter, который давал возможность установить контроль над процессом загрузки ОС. Судя по всему, он был разработан с целью слежки за выводом данных, получения скриншотов с экрана компьютера и сигналов от клавиатуры (кейлогинга).
Основной особенностью UEFI-bootkit является тот факт, что он запускается до операционной системы и контролирует все процессы «на старте», его практически невозможно обнаружить штатными средствами ОС или антивирусными программами. И его практически невозможно удалить, не помогают ни переустановка операционной системы, ни даже замена жесткого диска. Единственный способ — обновление BIOS.
Помимо внедрения bootkit, злоумышленники научились успешно использовать уязвимости UEFI. Например, уязвимость BootHole была найдена в загрузчике GRUB 2 (GRand Unified Bootloader version 2) протокола Secure Boot. Данный протокол отвечает за проверку электронной цифровой подписи выполняемых EFI-приложений с помощью ключевой информации, хранящейся в системе. Если ключи не совпадают, Secure Boot отказывается от выполнения любой загрузки. Уязвимость BootHole дает возможность управлять процессами загрузки оборудования в обход Secure Boot. Использование данной уязвимости позволяет, например, внедрить bootkit в UEFI BIOS или загрузить любую ОС. Даже включение режима безопасной загрузки, который должен проверять все подозрительные действия загрузчика, не защищает от уязвимости BootHole.
Принимая во внимание все вышесказанное, можно заключить, что среда UEFI BIOS может таить угрозы, поэтому ей требуется дополнительная защита. Одним из инструментов защиты могут выступать модули доверенной загрузки (МДЗ), позволяющие решать следующие задачи:
- Предотвращать атаки на BIOS (в том числе нелегитимные обновления).
- Препятствовать нарушению целостности.
- Предотвращать нарушение процесса загрузки штатной ОС.
Рынок отечественных МДЗ
Рынок МДЗ в России формировался постепенно и при активном участии регуляторов сферы информационной безопасности. Первой требования к модулям доверенной загрузки выпустила ФСБ России, введя в том числе, определение аппаратно-программных модулей доверенной загрузки (АПМДЗ).
В 2013 году уже ФСТЭК России подготовила свои требования к средствам доверенной загрузки. В документе, опубликованном регулятором, появилось разделение на программные и аппаратно-программные средства доверенной загрузки.
Функционально программные и аппаратные модули доверенной загрузки схожи, многие механизмы защиты, предусмотренные в АПМДЗ, могут быть реализованы программно на уровне UEFI. Такое положение дел было зафиксировано в новых требованиях к модулям доверенной загрузки, выпущенных ФСБ России в 2020 году. Регулятор добавил в требования возможность сертификации не только аппаратно-программных, но и программных модулей.
Таким образом оба регулятора начали сертифицировать модули доверенной загрузки как в программном, так и в аппаратном исполнении.
Принимая во внимание дефицит комплектующих, с которым столкнулись российские производители аппаратных модулей в 2022 году, использование программных МДЗ может стать в ближайшем будущем единственным доступным вариантом.
Ниже мы подробнее рассмотрим особенности программных МДЗ на примере ViPNet SafeBoot от компании «ИнфоТеКС».
ViPNet SafeBoot
Сертифицированный высокотехнологичный программный модуль доверенной загрузки ViPNet SafeBoot, предназначенный для установки в UEFI BIOS различных производителей. Он обеспечивает защиту программных комплексов, мобильных устройств, серверов (в том числе и серверов виртуализации) от различных угроз несанкционированного доступа на этапе загрузки и от атак на BIOS.
ViPNet SafeBoot можно использовать для идентификации и аутентификации пользователей, разграничения доступа на основе ролей, а также организации доверенной загрузки операционной системы.
Программный модуль сертифицирован ФСТЭК России в соответствии с требованиями руководящих документов к средствам доверенной загрузки уровня базовой системы ввода-вывода 2 класса, что позволяет использовать продукт для защиты государственных информационных систем до класса защищенности К1 включительно, для обеспечения 1 и 2 уровня защищенности персональных данных и автоматизированных систем управления технологическим процессом до 1 класса защищенности.
В ViPNet SafeBoot 3.0 реализованы новые требования ФСБ России к механизмам доверенной загрузки ЭВМ, что значительно расширяет возможность применения данного продукта на российском рынке.
Преимущества программного МДЗ
Оперативность реагирования на угрозы
За счет того, что программные модули доверенной загрузки расположены внутри микросхемы BIOS, их запуск начинается раньше, чем запуск программного обеспечения из ROM плат расширения, это позволяет применять защиту от потенциального вредоносного программного обеспечения раньше, чем это можно было бы сделать с помощью АПМДЗ.
Защитный механизм от Malware в UEFI
ViPNet SafeBoot блокирует запись malware в UEFI BIOS, с последующим его размещением в WPBT (Windows Platform Binary Table ) во время загрузки ОС, тем самым предотвращая запись вредоносного кода в WPBT во время загрузки ОС.
Защита на уровне SMM
В ViPNet SafeBoot реализован механизм, который позволяет контролировать выполнение SMM (system management mode) и программных SMI (system management interrupt). Программный модуль может отслеживать эти прерывания и блокировать выполнение привилегированных команд.
Неизвлекаемость
Еще одним преимуществом программных замков является их неизвлекаемость, в отличие от аппаратных исполнений МДЗ.
Этот недостаток аппаратно-программных замков можно компенсировать за счет организационных мер, например, опечатывание корпуса автоматизированного рабочего места, но эта процедура несет дополнительные финансовые и временные затраты.
Аутентификация по сертификатам
Преимуществом программных МДЗ является возможность использования технологии единого входа (SSO) для аутентификации как в самом МДЗ, так и в операционных системах, LDAP или других продуктах. Более того, в ViPNet SafeBoot реализован вход по сертификату, записанному в память токена, защищенную пин-кодом и возможность работы как с российскими, так и западными сертификатами.
Стоимость владения
Последнее, но немаловажное преимущество — стоимость. Программные модули доверенной загрузки не требуют использования платы расширения, из-за отсутствия затрат на комплектующие, стоимость разработки и изготовления программного модуля, в том числе ViPNet SafeBoot, в разы ниже аппаратно-программных аналогов.
Это обусловлено тем, что отсутствуют затраты на покупку компонентной базы, логистику, как до места изготовления АПМЗД, так и до конечного потребителя. Отсутствует необходимость замены устройств по истечении срока службы. Программный МДЗ не имеет аппаратной составляющей, которая способна выйти из строя.
Подводя итоги вышесказанному, хочется отметить, что программные модули доверенной загрузки, не уступая по функциональности программно-аппаратным замкам, могут стать надежным, обладающим рядом преимуществ и более выгодным решением. А с учетом отсутствия комплектующих для АПМДЗ, в ближайшей перспективе, возможно и единственным.
Astra Linux и vipnet safeboot
Linux Astra
Добрый день, такой вопрос, хочу поставить linux astra, компьютер без видеокарты, только процессор.
Не выключается Astra Linux
Добрый день! Подскажите, пожалуйста, установил Astra Linux 1.6 SE. При выключении компьютера.
Access в Astra Linux
Следуя моде, направленной на импортозамещение, моя организация начала активный переход на.
Обзор программного модуля доверенной загрузки уровня UEFI BIOS ViPNet SafeBoot
Мы протестировали ViPNet SafeBoot — сертифицированный ФСТЭК России программный модуль доверенной загрузки (МДЗ), устанавливаемый в UEFI BIOS различных производителей. Продукт предназначен для идентификации и аутентификации пользователей, разграничения доступа на основе ролей, а также организации доверенной загрузки операционной системы. В статье расскажем о системных требованиях и функциональных возможностях продукта, рассмотрим процесс инициализации и конфигурирования, а также поделимся результатами реального тестирования на двух операционных системах — Windows 10 и Ubuntu 17.
Сертификат AM Test Lab
Номер сертификата: 219
Дата выдачи: 19.03.2018
Срок действия: 19.03.2023
- 5.1. Раздел «Параметры загрузки операционной системы»
- 5.2. Раздел «Контроль целостности»
- 5.3. Раздел «Пользователи»
- 5.4. Раздел «Журнал событий»
- 5.5. Разделы «Другие настройки»
Введение
В ходе создания комплексных систем защиты информации на этапе проектирования и моделирования угроз безопасности обычно основное внимание уделяется таким типам атак и нарушений, как взлом сетевого периметра, вирусные заражения файлов, утечка информации, хакерские и DDoS-атаки. Соответственно, в первую очередь речь идет о применении традиционных средств защиты, таких как антивирус, комплексные решения обеспечения сетевой безопасности (UTM), средства контроля внутренних потоков. Однако любые, даже самые навороченные next-generation-решения могут спасовать, когда злоумышленник осуществляет заражение на уровне BIOS или просто запускает вредоносную программу в обход штатной загрузки операционной системы компьютера, ноутбука или сервера. В наше время, когда новости о выявлении уязвимостей на аппаратном и микропрограммном уровнях появляются с завидной регулярностью (достаточно вспомнить нашумевшую историю с meltdown и spectre, обнаруженных в процессорах Intel и ARM, которые позволяют получить несанкционированный доступ к особым областям памяти), угрозы, связанные с недоверенной загрузкой, становятся особенно актуальными. Стоит отметить, что отечественному рынку модулей доверенной загрузки уже более 20 лет, однако большинство распространенных решений имеют исключительно аппаратное исполнение, что накладывает разного рода ограничения по их использованию. В этой связи перспективным направлением развития продуктов данного класса является программное исполнение, позволяющее интегрироваться непосредственно в BIOS. Именно к такому классу решений и относится ViPNet SafeBoot производства ОАО «ИнфоТеКС», обзору которого и посвящена данная публикация. Компания ИнфоТеКС — отечественный разработчик и производитель программных и программно-аппаратных средств защиты информации, один из лидеров рынка информационной безопасности в стране. Продукты ИнфоТеКС регулярно проходят сертификацию в ФСБ России и ФСТЭК России, а также в отраслевых системах сертификации, а сама компания имеет все необходимые лицензии ФСБ России, ФСТЭК России и Министерства обороны России.
Системные требования к ViPNet SafeBoot и соответствие нормативным требованиям
Программный комплекс ViPNet SafeBoot не может быть установлен обычным пользователем, его необходимо инсталлировать непосредственно в BIOS с помощью специально подготовленных сервисных инженеров, в качестве которых готовы выступить и непосредственно сотрудники компании-производителя.
К компьютеру, предназначенному для установки ViPNet SafeBoot, предъявляются следующие требования:
- процессор — X86-совместимый с поддержкой режима x86-64 (AMD64/Intel64), частота от 500 MГц, полный список поддерживаемых моделей процессоров приведен в документации на продукт;
- материнская плата — практически любая, совместимая с процессором, BIOS которой соответствует спецификации UEFI версий: 2.3.1, 2.4, 2.5, 2.6;
- видеокарта –– дискретная или встроенная;
- оперативная память — объем не менее 1 Гбайт;
- жесткий диск –– объем диска определяется требованиями установленной операционной системы.
Таким образом, ViPNet SafeBoot возможно установить практически на любой современный компьютер или сервер, при этом не нарушая аппаратную конфигурацию и без необходимости дополнительных вмешательств в операционную систему.
ViPNet SafeBoot сертифицирован ФСТЭК России на соответствие требованиям руководящих документов к средствам доверенной загрузки уровня базовой системы ввода-вывода 2 класса, что позволяет легитимно использовать продукт для построения ИСПДн до УЗ1 включительно, ГИС до 1 класса защищенности включительно, АСУ ТП до 1 класса защищенности включительно. Применение ViPNet SafeBoot также обеспечивает выполнение соответствующего набора требований приказов ФСТЭК №17 по защите государственных информационных систем, №21 по защите информационных систем персональных данных, №31 по защите автоматизированных систем управления технологическим процессом.
Установка ViPNet SafeBoot и комплект поставки
Еще раз подчеркнем, что МДЗ ViPNet SafeBoot — не коробочный продукт, его установку в UEFI BIOS компьютера или сервера рекомендуется выполнять, обратившись непосредственно к производителю — ОАО «ИнфоТЕКС», инженеры которого готовы произвести указанные работы. Также установку могут произвести специалисты компаний-партнеров, которые активно набирают в свой штат таких специалистов. В комплект поставки ViPNet SafeBoot помимо самого модуля входят:
- формуляр установленного образца с голограммой ФСТЭК России;
- копия сертификата соответствия ФСТЭК России;
- руководство пользователя и администратора в формате pdf.
Функциональные возможности ViPNet SafeBoot
С учетом современного ландшафта угроз информационной безопасности защита для компьютеров и серверов должна действовать с момента их включения, причем время до старта операционной системы является ключевым для доверия к информационной системе в целом. На самых ранних этапах загрузки существуют риски передачи управления нештатному загрузчику, эксплуатации вредоносного кода в BIOS, перехвата данных, отключения защитных механизмов. Все это может привести к обходу подключаемых позже средств защиты и краже данных. Защита от описанных выше угроз обеспечивается за счет следующих функциональных возможностей:
- строгой двухфакторной аутентификации пользователя. Осуществляется с помощью токена с сертификатом формата x.509, пароля или их сочетания. Поддерживаются популярные аппаратные идентификаторы: JaCarta PKI, Rutoken ЭЦП, Rutoken ЭЦП 2.0, Rutoken Lite, Guardant ID;
- реализации мандатной модели доступа с применением следующих ролей: пользователь, администратор, аудитор;
- осуществления контроля целостности следующих компонентов: всех ключевых модулей UEFI BIOS, загрузочных секторов жесткого диска, таблиц ACPI, SMBIOS, карты распределения памяти, файлов на дисках с различными файловыми системами независимо от операционки (поддерживаются FAT32, NTFS, EXT2, EXT3, EXT4), ресурсов конфигурационного пространства PCI/PCe, CMOS (содержимого энергонезависимой памяти), завершенности транзакций в файловых системах NTFS, EXT3, EXT4;
- ведения журнала событий безопасности — для удобства предусмотрены несколько режимов ведения журнала с разным уровнем детализации;
- настройки шаблонов администрирования, МДЗ поддерживает импорт и экспорт конфигураций, что ускоряет процессы настройки;
- реализации механизма самотестирования, МДЗ контролирует свое состояние и исключает возможность его обхода с целью несанкционированного доступа к системе, если его целостность нарушена;
- поддержки обновлений — имеется возможность доверенного обновления МДЗ администратором системы по мере их выпуска производителем;
- механизма запрета загрузки с внешних и нештатных носителей.
Учитывая богатый набор функций, встраивание модуля доверенной загрузки ViPNet SafeBoot непосредственно в BIOS позволяет повысить уровень доверия к системе за счет:
- авторизации на уровне BIOS, до загрузки основных компонентов операционной системы;
- контроля целостности BIOS, защищаемых компонентов операционной системы и аппаратного обеспечения;
- блокировки загрузки нештатной копии операционной системы, в том числе при подмене загрузочного носителя.
Работа с продуктом ViPNet SafeBoot
Для тестирования функциональности ViPNet SafeBoot производитель предоставил нам образ с предустановленным МДЗ в BIOS виртуальной машины. Поскольку вендор заявляет поддержку любых операционных систем, мы решили проверить это утверждение на практике, установив по очереди Windows 10 и Ubuntu 17. Сразу отметим, что обе операционные системы установились корректно и работали в обычном для пользователей режиме без нареканий, однако в процессе установки пришлось попотеть, постоянно меняя загрузочные области и пересчитывая контрольные суммы. Что ж, не такая уж это и высокая цена за должный уровень безопасности.
Запустив машину, первым делом предприняли попытку зайти в настройки BIOS штатным способом (клавиша F2 или Delete), однако отобразилось сообщение о запрете данного действия. Это говорит о том, что ViPNet SafeBoot начинает работу действительно сразу после нажатия кнопки включения. Забегая вперед, войти в стандартный BIOS Setup все-таки возможно, но пройдя успешную авторизацию в МДЗ в роли Администратора и выбрав в настройках соответствующую опцию «Разрешить однократный вход в BIOS Setup при следующей перезагрузке». Пользователю такая возможность не предоставляется.
Рисунок 1. Запрет доступа к настройкам BIOS традиционным способом
Далее ViPNet SafeBoot предлагает осуществить идентификацию и аутентификацию.
Рисунок 2. Вход в систему ViPNet SafeBoot
После корректного ввода учетных данных доступен режим настройки по нажатию F2, в противном случае происходит загрузка штатной операционной системы.
Кажущийся устаревшим интерфейс конфигурирования ViPNet SafeBoot предоставляет весьма широкие возможности по настройке продукта. Отметим, что в ближайшее время производитель планирует реализовать новый user friendly интерфейс.
Рисунок 3. Интерфейс настроек ViPNet SafeBoot
Раздел «Параметры загрузки операционной системы»
Наиболее важной опцией в этом разделе является жесткая установка устройства загрузки операционной системы, вплоть до указания физического адреса раздела диска, без какой-либо возможности изменения в ходе загрузки (например, по нажатию F10, F11 или F12, как это принято в большинстве современных BIOS). Именно этот параметр и обеспечивает важнейшую функциональность продукта — невозможность обхода запуска установленной штатной операционной системы.
Рисунок 4. Раздел «Параметры загрузки операционной системы» в ViPNet SafeBoot
Раздел «Контроль целостности»
Важно отметить, что ViPNet SafeBoot способен контролировать целостность не только файлов на диске (кстати, полезная опция «Автоопределение компонентов загрузки ОС» для постановки на контроль целостности доступна только для систем семейства Windows), но и отдельных низкоуровневых компонентов, таких как CMOS, таблицы ACPI и SMBIOS, карта распределения памяти и других. В качестве приятного бонуса — присутствует режим обучения, позволяющий исключить из контроля целостности отдельные элементы компонентов, изменяемых при нормальном функционировании системы (например, при контроле CMOS). Элементы, не прошедшие проверку целостности, снимаются с контроля целостности, что позволяет адаптировать систему к контролю определенного набора элементов. Кстати, еще одна отличительная особенность продукта — возможность хранения эталонов не только на диске, но и во внутренней базе данных МДЗ, расположенной в NVRAM.
Рисунок 5. Раздел «Параметры загрузки операционной системы» в ViPNet SafeBoot
Раздел «Пользователи»
В ViPNet SafeBoot реализована ролевая модель разграничения доступа, что позволяет ограничить избыточные функции конфигурирования при входе в качестве Пользователя только его персональными настройками, а при входе в роли Аудитора — дополнительно открывать Журнал событий в режиме «Только чтение». Примечательно, что среди способов аутентификации присутствует возможность доменной авторизации при настройке соответствующей синхронизации с LDAP.
Рисунок 6. Раздел «Пользователи» в ViPNet SafeBoot
Раздел «Журнал событий»
В ViPNet SafeBoot история событий привычно хранится в соответствующем журнале, интерфейс которого не выделяется оригинальностью. Для наглядности критичные инциденты помечаются красным. Эти сведения можно экспортировать, а также настроить гибкое хранение, разрешив при переполнении памяти NVRAM в BIOS записывать события на диск.
Рисунок 7. Раздел «Журнал событий» в ViPNet SafeBoot
Раздел «Другие настройки»
В этом разделе стоит отметить возможность разрешения однократного входа в штатный BIOS Setup, а также очень полезную функцию — импорт и экспорт настроек, что позволяет не только легко осуществлять настройку продукта на нескольких типовых машинах, но и восстанавливать конфигурацию, соответствующую принятым в организации политикам.
Рисунок 8. Раздел «Другие настройки» в ViPNet SafeBoot
Остальные разделы конфигурирования ViPNet SafeBoot представляют собой интуитивно понятные инструменты для настройки корневых сертификатов сети и, что приятно удивило, обновлений комплекса.
Выводы
В обзоре мы протестировали работу программного модуля доверенной загрузки ViPNet SafeBoot от отечественного производителя — компании ИнфоТеКС, одного из немногих на сегодняшний день продуктов на российском рынке в этом классе. Он позволяет защищать информационные системы, предназначенные для обработки информации ограниченного доступа, путем обеспечения доверенной загрузки операционной системы через установку непосредственно в UEFI BIOS. В ходе практического тестирования оказалось, что даже попасть в настройки BIOS штатными способами невозможно. Обе запланированные нами к установке операционные системы Windows 10 и Ubuntu 17 установились и функционировали без видимых проблем, абсолютно прозрачно для пользователей.
ИнфоТеКС пополняет свой портфель перспективными решениями, стремясь занять соседние продуктовые ниши, что гармонично укладывается в общее стратегическое развитие компании как отечественного вендора средств обеспечения информационной безопасности. На сегодняшний день вопросы доверия при загрузке операционных систем компьютеров и серверов не кажутся приоритетными при построении комплексных систем информационной безопасности, однако их игнорирование может привести к компрометации всего последующего выстроенного эшелона защиты от киберугроз.
Сказ о том, как мы отечественного производителя поддерживали
Сразу оговорюсь, что описанной ниже истории никогда не случалось. Все совпадения случайны, все персонажи вымышлены.
В силу своей профессиональной деятельности, нам приходится работать с разными операторами связи. Практически все они — федерального уровня, либо их «дочки» в странах СНГ. Одной из таких компаний является… Пусть он будет Z.
История взаимоотношений с ним давняя и коллеги, наверное, расскажут много интересного. Но это как-нибудь потом, а пока расскажу свою историю я.
Требования к безопасности в этой компании серьезные — положение обязывает (А еще 152-ФЗ «О защите персональных данных»). Причем если раньше требования были драконовские (в духе «Миссия невыполнима»: изолированное помещение, сканер сетчатки, автоматчики. ), то сейчас свелись к просто строгим: индивидуальные учетки и шифрованные каналы связи между нами и заказчиком. Шифрование — ГОСТовское, никакого вам буржуйского заграничного IPSec. Рынок таких решений мал, поставщиков — раз-два и кончились. Реализация… ну не Checkpoint и не Cisco, но терпимо.
Но это была присказка, а за сказкой прошу под кат!
1. Ты помнишь, как все начиналось?
Защищенная сеть партнера построена на базе решения ViPNet от отечественного производителя — компании Инфотекс. До недавнего времени использовались индивидуальные клиенты ViPNet client с именными ключами. Однако сотрудников у нас много, а ключей — всего десять, больше партнер не дает. Как-то справлялись, но было жутко неудобно, поэтому решили ставить выделенный шлюз.
После переговоров с менеджером Инфотекса и специалистами партнера остановились на ПАК ViPNet Coordinator HW1000 на базе сервера Aquarius. Импортозамещение же Внутри этого ПАК — обычный debian-based линукс с собственным шеллом (можно выйти в bash) и установленным софтом ViPNet Coordinator (тестовую версию можно скачать в виде пакета).
Т.к. рынок таких решений крайне небольшой, то стандартизацией там и не пахнет. Ты должен купить железку у того же производителя, что и твой партнер, иначе ничего не получится. Отсюда и уровень сервиса — никаких тебе NBD (хотя стоимость поддержки далеко не копеечная), хотя саппорт отвечает довольно оперативно, стоит отметить, чего, порой, не скажешь о менеджерах.
Первым «открытием» после получения оборудования было то, что управляющий софт требует для своей работы 16-bit MS-DOS подсистему (!). Учитывая, что программ две («Центр Управления Сетью» и «Удостоверяющий и Ключевой Центр»), используют они общие папки (хотя в документации описано их разнесение на разные АРМ), то наименее геморройным вариантом стала установка виртуалки с Win2003 x32. 2015й год говорите? x86-64? Не, не слышали. Версия софта, поддерживающего 64-битные ОС, в настоящий момент проходит сертификацию органами — был ответ саппорта.
Инструкция пользователя подробна и многостранична, а описание готовых схем занимает едва ли полтора десятка страниц и наполовину состоит из рисунков. Если бы не помощь коллег, которые уже запускали подобные ПАК (Саша, спасибо!), то процесс только настройки и освоения документации затянулся бы, думаю, на месяц-другой. Сам же Инфотекс настоятельно рекомендует пройти пятидневные курсы (разумеется, платные, но относительно дешевые), либо воспользоваться услугами интегратора. Но мы ведь не ищем легких путей, правда? 🙂 К слову, краткую инструкцию саппорт мне, все же, прислал.
2. Поехали!
Начинается все с установки ПО администратора: Центр Управления Сетью (ЦУС), Удостоверяющий и Ключевой Центр (УКЦ) и ViPNet Client, которым мы будем проверять наш канал. Для работы потребуется лицензия (идет вместе с ПАК). Клиент пока не запускаем, нам для него еще ключи надо сделать. Файлик лицензии копируем в C:\Program files\InfoTecs\
Запускаем ЦУС. 
Интерфейс ЦУС
Принимаем настройки по умолчанию. Открываем Службы -> адресная администрация -> Структура сети ViPNet.
Создаем сервер-маршрутизатор (СМ). В подавляющем большинстве случаев он понадобится один, даже если у вас кластерная конфигурация. В СМ создаем Абонентский Пункт (АП) admin.
Структура сети ViPNet
Проверяем командой «Выдать таблицы маршрутизации«.
Далее все в том же меню «Службы«:
Групповая регистрация узлов в задачах -> Coordinator -> добавляем наши СМ.
Индивидуальная регистрация в задачах -> admin -> добавляем галки ЦУС + УКЦ.
Регистрация типов коллективов — admin -> связи -> добавляем СМ.
Регистрация пользователей -> Добавляем еще одного пользователя в ТК admin и vpn1000
Групповая регистрация узлов в задачах -> Coordinator -> регистрация в задаче hw1000 -> выбираем нужный СМ -> ip адреса -> вводим IP-адреса. (См. в документации «ViPNet NCC» пп. 13.4.2.1 и 13.5). Здесь нужно указать внутренний и внешний адрес нашего координатора и туннелируемые сети.
Теперь проверяем:
Проверка конфигурации
Сформировать все справочники
С ЦУС пока закончили, запускаем наш УКЦ 
Внешний вид УКЦ
Первичная настройка происходит с помощью незамысловатого мастера. Описывать каждую кнопку не буду, пробегусь кратко.
Пользователь которого назначаем админом сети — admin, параметры по умолчанию не меняем. Отмечаем галкой «создать ассиметричный мастер ключ»
Задать пароль администратора для группы «Вся сеть» (в эту группу по умолчанию входят все сетевые узлы), который используется для входа в режим администратора на Сетевых Узлах (наших координаторах).
Созданные дистрибутивы будут отображены в УКЦ в разделе Ключевой центр > Своя сеть ViPNet > Ключи > Дистрибутивы ключей.
После этого перезапускаем УКЦ — он спросит пароль. Вводим тот самый пароль администратора, который только что сгенерировали.
Маленькая ремарка: если при первой установке какой-то из паролей вы вдруг забыли, то проще всего будет перенастроить все заново (удалить ЦУС и УКЦ, удалить папку InfoTecs) — со второго-третьего раза настройка занимает минут пятнадцать и идет почти на автомат).
Формируем экспорт для сети нашего партнера.
В ЦУС: Службы -> Экспорт. Т.к. у нас пока ничего нет, добавляем сеть для экспорта (это доверенная сеть вашего партнера). Добавляем туда все наши СУ и все ТК. Жмем Копировать.
Полученные файлики нужно будет забрать в папке NCC\EXPORT, запихнуть в зашифрованный архив и передать администратору сети-партнера.
Принимаем импорт. Копируем содержимое архива в папку IMPORT, перезпускаем ЦУС. Службы -> необработанный импорт.
Возвращаемся в УКЦ
Принимаем симметричный мастер-ключ (см. мануал по УКЦ) либо создаем свой — тут как договоритесь с партнером
Создаем ключи узлов (см. мануал по УКЦ)
Своя сеть -> Ключи -> Ключи узлов. На каждом узле ПКМ -> перенести в ЦУС
ЦУС
Сформировать все справочники, затем делаем повторный экспорт и отсылаем партнеру. Принимаем импорт.
Готовим дистрибутивы ключей
УКЦ -> КЦ -> СУ -> Открыть. Задаем пароль администратора.
ЦУС -> Службы -> Файлы для… УКЦ -> Дистрибутивов. (копируем оба СУ: VPN1000 и admin)
УКЦ -> Сервис -> Автоматически создать -> Дистрибутивы ключей
Переносим дистрибутивы (файлы *.dst) на съемный носитель (с помощью команды Перенести в папку в контекстном меню).
Копируем на этот же носитель пароли пользователей (меню Сервис > Сохранить пароли в файле > Пароли пользователей).
Импортируем сертификаты
УКЦ -> УЦ -> Доверенные сети -> Входящие. Импортируем все сертификаты
Наконец, добираемся, собственно, до железа
Импортируем ключи и справочники на HW. С помощью мастера настраиваем сетевые интерфейсы. Это можно будет сделать позже из консоли. Пароль по умолчанию для входа vipnet/vipnet
После установки ключей логин: vipnet, пароль: пароль от дистрибутива с ключами СМ, enable: пароль администратора СУ (тот что для УКЦ).
В ЦУС добавляем связи между импортированным ТК и своими. Снова делаем у себя экспорт и принимаем импорт. Импорт-экспорт повторяем, пока с обеих сторон не прекратятся аномалии.
После каждого импорта делаем «Сформировать все справочники», Управление -> Отправить измененные файлы -> Справочники узлов -> выбираем наши СУ (admin, vpn1000) и отправляем.
В ViPNet-клиенте при этом должно появиться сообщение об обновлении адресных справочников и появиться координатор, с которым мы связываемся.
ЦУС -> Управление -> Отправить измененные файлы -> Ключи узлов. Отправляем ключи на координатор и клиент.
Итак Номер вашей сети 1234
доверенная сеть 4321
В сети номер 1234 делаем следующее:
— Делаем резервную копию (архив)
— Формируем начальный экспорт как описано в документации
— Задаем шлюз для меж сеть
— Копируем начальный экспорт
— Генерируем ИСММК для сети 4321 в УКЦ
— Делаем экспорт для сети 4321
потом делаем следующее:
— Передаете начальный экспорт для сети 4321
— копируете начальный экспорт из сети 1234 в папки имопрта ЦУС и УКЦ сети 4321.
Теперь перейдем в сеть 4321:
— Делаем резервную копию (архив)
— Подключаем межсетевой канал
— Установить связи между ТК 2-х сетей 1234 и 4321
— Сформировать ответный экспорт для сети 1234
— Не забыть задать СМ_шлюз и скопировать ответный экспорт
— Так же не забыть проверить наличии аномальных ситуаций.
— Сформировать справочники
— Импортировать список сертификатов ЭЦП администраторов сети 1234 в УКЦ сети 4321
— Импорт ИСММК из сети 1234
— Сформировать новые КУ в ЦУС и перенести их в ЦУС
— Разослать обновления из ЦУС
Теперь перейдем к следующему этапу:
— Передать ответный экспорт для сети 1234. И далее все действия будет выполнять там.
— Провести импорт ответного экспорта в ЦУС и УКЦ и создать и создать заключительный экспорт.
— Подключить межсетевой канал. в ЦУС
— Посмотреть и проверить есть ли связь между ТК двух сетей 1234 и 4321.
— Проверить имеются ли аномалии
— Сформировать справочники.
— Сделать импорт списка сертификатов ЭП УЛ второй сети в УКЦ первой сети.
— Сформировать новые ключи узлов и перенести в ЦУС
— Рассослать обновления КУ и адресных справочников из ЦУС.
— Еще раз проверить правильность выполнения процедуры установки межсетевого взаимодействия
— Импортировать заключительный экспорт сети 4321
3. Бонус
Failover подразумевает, что железок у вас две, и они работают вместе, представляясь как один кластер. Работа основана на VRRP плюс синхронизация криптосессий.
###
eth1 — это линк в сторону наших внутренних сетей
192.168.1.3 — это внутренний IP кластера
192.168.1.1 — это внутренний IP ноды
192.168.1.4 — это IP-адрес шлюза, через который мы видим клиентские сети
eth2 — линк в сторону интернета
1.2.3.3 — это внешний IP кластера
1.2.3.1 — это внешний IP ноды
1.2.3.4 — это IP шлюза по-умолчанию
eth0 — это интерконнект между нодами кластера
192.168.2.2 — это IP-адрес второй ноды кластера
Обратите внимание на секцию [misc] и опцию «reboot = no». По умолчанию она установлена в yes, и если failover с первого раза не запустится, то вам придется переустанавливать ОС ПАК заново из образа. При этом в инструкции указано, что значение по умолчанию именно «no». Возможно, это уже пофиксили, но вы все равно имейте ввиду.
Проверяем, что и у вас и у партнера установлен одинаковый тип шифрования:
iplir set cipher-mode cfb
Еще из полезного, настройки модуля шифрования:
iplir show config
После всех импортов-экспортов тут должны быть ваши сети и сети партнера, между которым нужно настроить обмен. Ну и не забудьте правильно настроить маршрутизацию, чтобы трафик на узлы партнера заворачивался в координатор.
4. Через тернии — к звездам!
Итак, настройка завершена, но канал между нашим ПАК и сетью партнера не поднимается. И тут-то началось самое интересное.
Естественно, был заведен тикет в саппорте, были уточняющие вопросы, неоднократный сброс ПАК «в дефолт», перепроверка всех настроек, в т.ч. самим саппортом через удаленную сессию…
Через месяц стучания в бубен и копирования очередного файлика из одной папки в другую канал поднялся. Бинго? В общем, да, но осадочек-то остался немалый! Месяц, потраченный почти впустую, сотни писем в саппорт и администратору партнера, бесконечный обмен настройками (одна из фишек ViPNet — импорт-экспорт настроек между ПАК с ключевой информацией и настройками сетей) и письмо от руководства в сторону Инфотекс с предложением забрать глючную железку взад.
Были даже привлечены разработчики, ответ которых был, по-своему, гениален: «наверное, вы делали что-то не так». Ну разумеется, канал-то в итоге заработал. И работает до сих пор, тьфу-тьфу.
Коллеги подсказывают, что они мучались тоже с месяц, и оно, в итоге, «заработало само», когда подключилась техподдержка производителя.
Мистика, не иначе. А может, это, своего рода, посвящение — система покоряется только настойчивым.
В заключение хочу сказать, что не стремлюсь кого-то «полить грязью», просто описываю свой опыт. Особый диссонанс поначалу вызвала терминология, заточенная, как мне кажется, на специалистов ИБ, нежели на сетевиков: абонентские пункты, дистрибутивы ключей, коллективы пользователей, связи и прочее. Хотя, железо рассчитано на крупные компании, а в них, как правило, присутствуют айтишники-безопасники. С другой стороны, явная заточка под госструктуры (а кто еще в здравом уме будет пользовать ГОСТовское шифрование?) накладывает требования по локализации, ну а заодно и на терминологию, похоже.