В данном случае проблема может быть связана со следующими факторами:
1. Флеш накопитель должен быть отформатирован в FAT 32
2. Флеш накопитель должен определяться системой как съемный диск (ни в коем случае не как жесткий диск)
3. На флеш накопителе записана неверная конфигурация
4. При получении флешки вместе с узлом клиент должен использовать её только для Континента, форматирование выполнять только с Flash_GUI. Для корректного использования флеш-накопитель должен быть отформатирован с partition 1
Для решения данной проблемы перезапишите конфигурацию в ПУ ЦУС для данного КШ на предварительно подготовленный флеш накопитель (согласно ранее описанных пунктов)
Не так давно на нас свалилась задачка: обновить криптошлюзы (КШ) «Континент» с версии 3.7.5 до версии 3.9.1 на всей VPN-сети довольно крупного клиента. Сеть географически распределена и охватывает все часовые пояса нашей необъятной Родины. Всего – порядка 120 центров управления сетью (ЦУС) с подчиненными КШ. В общей сложности нам предстояло обновить более 3500 «зелёных» устройств. Насколько нам известно, мы одни из первых выполнили обновление такого масштаба с версии 3.7.5 на 3.9.1 без замены железа и настройки сети «с нуля». То есть именно обновили существующую сеть со всеми ее текущими настройками и оборудованием. Но, как говорится, есть нюансы. Зная их заранее, вы наверняка сможете сэкономить свои ресурсы, если затеете нечто подобное.
Нюанс 1. Чтоб не запороли пароли
ЦУС как устройство централизованного управления криптосетью хранит все данные о ее настройках, и очень важно не потерять их перед обновлением. Это легко сделать, сохранив конфигурацию ЦУС из программы управления (ПУ ЦУС). При этом важно задать пароль на латинице, а лучше использовать цифровой пароль, чтобы при загрузке конфигурации точно быть уверенным, что она попадет на ЦУС версии 3.9.1. У нас был случай, когда мы задали пароль в русской раскладке, но при загрузке конфигурации на ЦУС ввести пароль в русской раскладке невозможно – будьте внимательны.
Нюанс 2. Не все флэшки одинаково полезны
Следующий очень важный аспект – носитель, с которого загружается конфигурация. Как выяснилось в процессе, не все флешки для этого подходят, даже если они были отформатированы в FAT32 или подготовлены с использованием ПО ServiceTool (входит в комплект установки ПУ ЦУС). Нам не удалось до конца понять причину такого поведения. В то же время флешка из комплекта ЦУС (зеленая в виде ключика с логотипом вендора) в 99,9% случаев с первого раза загружала конфигурацию корректно.
Нюанс 3. Обновление конфигураций
Дабы в дальнейшем вы не тратили уйму времени зря, поговорим о еще одной распространённой проблеме – некорректной загрузке конфигурации ЦУС в процессе обновления. Итак, если ЦУС после прошивки отказывается загружать конфигурацию (пробовали 4 разные флешки), то нужно всего лишь еще раз его перепрошить.
Следите за тем, чтобы все КШ при сохранении конфигурации ЦУС были в «спокойном состоянии», то есть чтобы на них были применены и обновлены все настройки с ЦУС. Например, на некоторых управляющих устройствах мы столкнулись с тем, что из-за большого количества объектов в группах и, как следствие, большого числа правил фильтрации в базе, криптошлюзам не удавалось загрузить с ЦУС соответствующие обновления конфигурации. КШ бесконечно пытались это сделать (в ПУ ЦУС напротив КШ постоянно висел значок обновления).
Решить эту проблему помогли отключение некоторых правил фильтрации, содержавших большое количество различных сервисов, или удаление сетевых объектов из управляющих центров (удалили 100 идентичных подсетей, заведенных по стандартной матрице на всех ЦУС). В одном случае нам пришлось проделать обе операции.
Нюанс 4. Сайзинг оборудования
Этот вопрос особенно актуален для проектировщиков и архитекторов со стороны эксплуатации. Для управления криптосетью из более чем 80 КШ лучше использовать как минимум IPC-500, а если подчиненных КШ более 150, то IPC-1000. Например, после обновления наш ЦУС IPC-100, управляющий 128 КШ, начал «засыпать», отклика в ПУ приходилось ждать по несколько часов. После подключения второго, более производительного резервного ЦУС (IPC-1000) и переключения на него управление вернулось, и работа ЦУС восстановилась.
Ещё одна рекомендация проектировщикам и архитекторам по КШ, а также инженерам, тестирующим ту или иную процедуру. КШ лучше использовать именно для шифрования и как можно реже возлагать на него дополнительные сетевые функции (SPAN, QoS и прочие). Например, после обновления с 3.7.5 на 3.9.1 производительность КШ сильно упала (не факт, что такая проблема будет у вас, так как она весьма специфична, но разговор не об этом). После разбора проблемы выяснилось, что функционал SPAN стал потреблять больше ресурсов. В том же ключе проявился нюанс, связанный с логированием сетевого трафика: включение всех параметров мониторинга заметно «съедало» процессорные мощности. Мораль сей басни: чем больше задействовано функционала, тем больше нюансов нужно учитывать при тестировании или планировании технических работ.
Нюанс 5. Резервное копирование
И пара слов про бэкап ЦУС. Если не обновить все до одного подчиненные КШ в ПУ ЦУС до текущей версии, то конфигурация ЦУС, которую вы сохраните, в дальнейшем не будет пригодна для восстановления. ЦУС ее просто не примет.
Мы рекомендуем обновляться сразу на версию 3.9.1, минуя 3.9.0 (в 3.9.0 изменена логика применения правил фильтрации и работы КШ в «мягком режиме», затруднена работа КШ в кластере, а также имеется ряд мелких багов).
В любом деле очень важна подготовка, и чем больше разных бэкапов вы сделаете перед обновлением, тем лучше. Например, на всякий случай сделайте скрины или выпишите на листочек настройки интерфейсов и маршрутизации – вдруг придется откатываться.
Нюанс 6. Заключительный
Отдельно скажем, что при обновлении такого количества ЦУС и подчиненных им КШ в распределённой сети не обойтись без помощи вендора. Хочется отметить коллег из «Кода Безопасности», которые оказывали своевременную и всестороннюю поддержку: диагностику по месту возникновения проблем, оперативное моделирование и выявление нюансов на своих стендах. В этой связи в крупных VPN-сетях порекомендуем приобретать техническое сопровождение в обязательном порядке.
На этом всё. Всем удачи в непростом деле сопровождения отечественных VPN-сетей. И помните: глаза боятся – руки делают.
Евгений Веретенников, инженер 2-й линии администрирования, «Ростелеком-Солар»
Михаил Данилов, администратор информационной безопасности, «Ростелеком-Солар»
2. Континент 4 Getting Started. Установка, инициализация
Приветствую читателей во второй статье цикла Континент Getting Started. Сегодня мы установим и настроим Континент 4.1 на виртуальную машину и познакомимся с интерфейсом управления. В прошлой статье мы предварительно показали настройку VMware Workstation, теперь перейдем к созданию ВМ Континент (УБ с ЦУС):
Указываем путь к ISO образу;
В качестве гостевой ОС указываем CentOS 4 (and later) x64;
CPU – 4, RAM – 10 ГБ, HDD – 100 ГБ;
Указываем сетевые интерфейсы.
VMnet1 – интерфейс подключения к DMZ (eth1).
VMnet2 – интерфейс подключения к LAN-сети (eth2).
NAT – интерфейс для подключения к сети Интернет (eth0).
Инициализация ЦУС
1.Запускаем виртуальную машину, выбираем язык установки и нажимаем «Установить Континент …». Тип платформы – «Настраиваемая» Начнется установка ОС Континент. После установки ОС необходимо проинициализировать ЦУС. В главном меню выбираем «Инициализация» – «Узел безопасности с центром управлению сетью»:
Запустится процесс инициализации сетевого устройства с последующим сообщением об успешной инициализации. После этого необходимо настроить:
Системное время. Необходимо для журналирования. «Настройки» – «Системное время»;
Создать и загрузить сертификаты. Необходимо создать корневой сертификат и сертификат управления ЦУС. Нажимаем в главном меню «Сертификаты». Для создания корневого сертификата необходимо выбрать «Сертификаты УЦ» нажать F2 и заполнить данные для сертификата.
Для создания сертификата управления ЦУС выбираем «Сертификаты» – «Сертификаты управления» – F2.
После создания сертификатов необходимо настроить ЦУС. В главном меню нажимаем «Настройка ЦУС» Выбираем ранее созданный сертификат управления и задаем пароль для учетной записи admin. После этого выбираем интерфейс управления.
Для управления ЦУС у нас используется интерфейс ge-2-0 (eth2). Задаем адрес интерфейса – 192.168.1.1/24. Поле «Шлюз» оставляем пустым. К этому адресу будет выполняться подключение для управления сетью Континент.
Применяем указанные настройки. ЦУС успешно настроен. Можем авторизоваться и просмотреть сведения об устройстве.
Менеджер конфигурации
После инициализации ЦУС необходимо установить Менеджер конфигурации (программа управления сетью Континент) и настроить АРМ администратора. С ВМ Администратора запускаем мастер установки Менеджера конфигурации и следуем инструкциям установки. После установки перезагрузим компьютер и запустим Менеджер конфигурации. При первом запуске программы потребуется инициализация биологического датчика случайных чисел. Следуя инструкции инициализируем ДСЧ.
Установим соединение с ЦУС, указав следующие параметры:
«Тип входа» – «С использованием пароля»;
«Сервер» – IP-адрес интерфейса управления ЦУС – 192.168.1.1;
«Учетная запись» – admin, «Пароль»
Выполнится подключение к ЦУС. Так выглядит окно управления сетью Континент.
В навигационном меню есть следующие вкладки:
Контроль доступа – настройка межсетевого экранирования.
Виртуальные частные сети – настройка VPN.
Система обнаружения вторжений – настройка функций компонента детектора атак.
Структура – содержит список узлов безопасности. Здесь производится настройка УБ и активация его компонентов.
Администрирование – содержит настройки администраторов комплекса, выпуск сертификатов, обновление комплекса, лицензии и резервные копии.
Необходимо произвести следующие настройки:
Добавить действующую лицензию на узел безопасности;
Выполнить сетевые настройки;
Настроить систему мониторинга.
Для добавления лицензии переходим «Администрирование» – «Лицензии». По умолчанию к шлюзу привязана демо лицензия с ограниченным набором компонентов и сроком 14 дней. Загрузим действующие лицензии в репозиторий.
Далее необходимо привязать на УБ действующую лицензию и отвязать демо лицензию.
Сохраним изменения, нажав на кнопку «Сохранить» в левом верхнем углу. Далее настроим сетевые параметры. «Структура» – ПКМ по УБ – «Свойства». Внутренний интерфейс управления у нас уже был задан при инициализации ЦУС. Теперь необходимо указать внешний интерфейс, интерфейс подключения к DMZ и задать маршрут по умолчанию в соответствии с макетом.
Во вкладке интерфейсы можно:
Указать тип назначения интерфейса: внешний, внутренний, мониторинг, порт коммутатора
Добавить VLAN и loopback интерфейсы
Создать Bridge-интерфейс, агрегацию
Для настройки маршрутизации перейдем в «Статические маршруты»
Стоит отметить, что Континент поддерживает работу по протоколам динамической маршрутизации OSPF и BGP.
Укажем часовой пояс для системы мониторинга. Сохраним настройки и установим политику на ЦУС.
Система мониторинга
Завершающая процедура подготовки рабочего места администратора – настройка подключения к подсистеме мониторинга по протоколу https. Защищенное соединение при подключении к системе мониторинга реализуется при помощи двух алгоритмов шифрования:
ГОСТ Р 34.11-2012 (Стрибог) – требует дополнительное ПО СКЗИ «Континент TLS VPN Клиент»
В рамках данного цикла выполним подключение, используя алгоритм RSA. Для этого потребуется выпустить корневой RSA сертификат и сертификат системы мониторинга. Переходим «Администрирование» – «Сертификаты» – «Корневые центры сертификации». В качестве алгоритма подписи указываем RSA.
Для сертификата системы мониторинга: «Сертификаты» – «Персональные сертификаты»
Название – используется для подключения по https
Типа сертификата – web-мониторинг
Корневой сертификат – созданный ранее корневой RSA сертификат
Привяжем созданные сертификаты к ЦУС. «Структура» – ПКМ по УБ – «Свойства» – «Сертификаты»
Сохраним настройки и установим политику на узел безопасности.
Для доступа к системе мониторинга указывается URL персонального сертификата мониторинга. В нашем случае это https://mon-aes. Для доступа к системе мониторинга необходимо соответствующим образом настроить DNS сервер или дополнить файл hosts.
Инициализация и настройка подчиненного узла безопасности
Инициализируем подчиненный узел, защищающий сеть филиала. Инициализация УБ идентична инициализации ЦУС. За исключением нескольких деталей:
1.При установке ОС выбираем язык установки и нажимаем «Установить Континент …». Тип платформы – «Настраиваемая»
2.Инициализируем устройство как «узел безопасности»
3.В ЦУСе мы выпускали сертификаты в локальном меню. Для того, чтобы выпустить сертификат управления подчиненным узлом, необходимо создать запрос на выпуск сертификата. Выбираем «Сертификаты» – «Запросы на выпуск сертификатов» – F4. Запрос записывает на USB-носитель и передается в Менеджер конфигурации.
4.В Менеджере конфигурации выпускаем сертификат на основании запроса. «Сертификаты» – «Персональные сертификаты» – Создать – «Загрузить данные из файла запроса»
5.Далее необходимо создать УБ: «Структура» – «Узел безопасности». Указываем идентификатор устройства и подгружаем созданный сертификат. Сохраняем изменения и привязываем лицензию на узел безопасности.
6.Экспортируем конфигурацию узла на usb-носитель. ПКМ по УБ – «Экспортировать конфигурацию узла». USB-носитель с конфигурацией подключаем к ВМ с подчиненным узлом и нажимаем «Подключиться к ЦУС».
7.Настраиваем интерфейс управления ge-0-0 (eth0). В нашем макете мы реализуем следующий сценарий: доступ из филиала в Интернет будет осуществляться через ЦУС, находящийся в центральном офисе. Поэтому, в качестве шлюза по умолчанию указывается IP-адрес ЦУСа.
8.Инициализация устройства закончена. Далее требуется подтвердить изменения в Менеджере конфигурации, настроить сетевые интерфейсы и указать часовой пояс.
Сохраняем и устанавливаем политику на узлы безопасности.
Отметим, что в комплексе Континент 4.1 есть возможность развертывания массива УБ. Для этого в Менеджере конфигурации в разделе «Структура» необходимо нажать «Мастер создания УБ». Далее необходимо выбрать количество УБ (максимум 50), указать путь для сохранения расширенных контейнеров (понадобятся для инициализации УБ) и настроить каждый из них.
Созданные узлы безопасности отобразятся в разделе «Структура». Далее в локальном меню необходимо инициализировать УБ с подключенным USB-носителем, на котором находятся расширенные контейнеры.
Заключение
На этом статья подошла к концу. Мы развернули узел безопасности с центром управлению сетью и подчиненный узел безопасности на виртуальные машины. Настроили АРМ администратора и систему мониторинга. В следующей статье рассмотрим компонент «Межсетевой экран» и настроим базовую политику.
Подробную информацию о продукте можно найти на странице Код Безопасности.
Как настроить апкш континент
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
АПКШ Континент поставляется с предустановленной текущей тиражируемой версией ПО. В некоторых случая может потребоваться ее переустановка (понижение или повышение версии, восстановление работоспособности, установка отладочной версии по и т.д.).
При инсталляции ПО на аппаратную платформу используются два источника инсталляции:
- CD-диск (входит в комплекте поставки оборудования)
- USB Flash drive (так же входит в состав поставки)
Самый распространенный способ — это установка через USB Flash drive. В этом случае на носитель необходимо записать образ USB Flash drive из комплекта поставки. Образы находятся на CD-диске в директории SetupContinentFLASHIMAGES, имеют расширение .flash и записываются на USB Flash drive при помощи таких утилит как:
- (Linux, BSD) (Windows) (Windows) (Windows, Linux, MacOS)
Для распознавания файла образа в balenaEtcher необходимо изменить расширение с .flash на .img (cgw_release.flash -> cgw_release.img)
По факту каждый образ это raw image жесткого диска с двумя разделами. Первый раздел FAT размером 8 МБ. Предназначен для сохранения ключей администратора ЦУС или же конфигурации и ключей КШ. Второй раздел UFS (FreeBSD). Содержит необходимые для установки ПО файлы. Созданный таким образом USB Flash drive будет являться загрузочным устройством и позволит произвести установку ПО на аппаратную платформу АПКШ.
Каждый образ установочного ПО содержит требуемый функционал для конкретной реализации ПО:
- arm_release.flash — АРМ ГК (Генерации Ключей)
- cgw.aserv_release.flash — КШ-СД
- cgw_release.flash — КШ
- csw_release.flash — КК
- ids_release.flash — ДА
- ncc.aserv_release.flash — ЦУС-СД
- ncc_release.flash — ЦУС
При переустановке ПО на аппаратную платформу АПМДЗ «Соболь» будет выдавать предупреждение о том, что изменился загрузочный диск, на запрос о изменении загрузочного диска следует ответить «НЕТ», в ином случае Соболь при загрузке уже с диска опять выдаст это предупреждение. Так же после переустановке ПО сбросится настройка «Время автоматического входа в систему», следует установить этот параметр в значение, отличное от 0, иначе устройство будет требовать предъявление iButton при каждой загрузке. Пункт «Время автоматического входа в систему» может быть недоступен для редактирования, в этом случае необходимо создать пользователя AUTOLOAD в меню управления пользователям АПМДЗ «Соболь».
Для того, чтобы установить ПО Континент на виртуальную машину используется специальный ISO-образ. Данный образ содержит в инсталляционных файлах все возможные компоненты комплекса (ЦУС, КШ, КК, ДА, ЦУС-СД, КШ-СД, АРМ ГК). Основное отличие данного ISO-образа это эмуляция Соболя, по факту же данный образ может использоваться для установки на x86-совместимое аппаратное обеспечение. Важно понимать, что в этом случае мы никогда не получим формальное соответствие формуляру (актуально для версии 3.7 и ниже). При установке на виртуальную платформу необходимо выбирать гостевую систему FreeBSD (32 bit) ниже 10 версии.
Для оптимизации потребления ресурсов гипервизора рекомендуется использовать следующие параметры в файле /boot/loader.rc:
- set hint.p4tcc.0.disabled=1
- set hint.acpi_throttle.0.disabled=1
- set hint.apic.0.clock=0
- set kern.hz=50
Начиная с версии 3.9 для установки на реальную платформу и на гипервизор используется один установочный диск, который самостоятельно определяет в каком режиме он будет работать.
Строка инициализации используется для создания устройства в ПУ ЦУС, это способ сообщить ПУ ЦУС идентификационный номер устройства, а так же количество и тип сетевых интерфейсов.
При ошибке в строке инициализации в дальнейшем будет невозможно загрузить конфигурацию на устройство, так что стоит быть предельно внимательным при ее вводе.
Строка инициализации для оборудования, поставляемого производителем приведена в Паспорте. Так же строку инициализации можно увидеть при инсталляции ПО (строка инициализации появляется после ввода идентификатора устройства. В некоторых случая строка инициализации может уйти за границы экрана, в этом случае необходимо нажать Scroll Lock и прокрутить экран вверх при помощи клавиш с указателями).
Следует быть внимательным, при установке на виртуальную машину, поскольку в некоторых гипервизорах могут использоваться различные типы интерфейсов! К примеру в VirtualBox используются интерфейсы le. Так же стоит обратить внимание, если количество интерфейсов в строке инициализации отличается от фактического количества интерфейсов на аппаратной платформе, это может быть признаком выхода интерфейса из строя, и как следствие ОС не может его обнаружить.
Строка инициализации имеет простой и понятный формат, например:
- 00002710 — идентификатор криптошлюза в HEX, длиной восемь символов, дополняется нулями в начале
- 3 — количество сетевых интерфейсов устройства, далее и до конца строки идет перечисление интерфейсов и их режимов работы
- igb0*02BDigb1*02BDigb2*02BD — наименование сетевых интерфейсов, как их определяет операционная система, режим работы (скорость, дуплекс), * отделяет интерфейсы
- ffff — признак окончания строки инициализации
Интерфейсы и режим работы:
- em0 (медь) — 02BD
- igb (оптика) — 3001
- igb (медь) — 02BD
- ix (оптика 10G) — 0001
- ixl (оптика криптоускоритель) — 2E801
Настройка L3 VPN между КШ это самая распространенная задача, выполняемая администратором комплекса. Для создания данного типа VPN необходимо выполнить следующие действия:
- создание сетевых объектов
- создание парных связей
- создание правил фильтрации
Шифрование трафика в комплексе возможно только между сетевыми объектами с типом Защищаемый.
Привязка сетевого объекта должна производится к внутреннему интерфейсу или к интерфейсу с типом «Любой» криптошлюза, за которым этот сетевой объект находится.
После создания сетевого объекта он может быть использован в правилах фильтрации. Подробнее о сетевых объектах и их типов читайте тут (link!).
Парные связи позволяют крипошлюзам узнавать о защищаемых сетевых объектах парных криптошлюзов.
При создании парной связи между криптошлюзами они строят между собой VPN по дефолтному порту UDP 10000 и начинают обмениваться keepalive-сообщениями. Если криптошлюз не получает данные сообщения от парного криптошлюза, то в ПУ ЦУС напротив него в колонке VPN будет отображаться восклицательный знак.
После того, как сетевые объекты и парные связи созданы единственное, что останавливает прохождение трафика по VPN-каналу это межсетевой экран криптошлюза.
Необходимо создать правила фильтрации на основе созданных межсетевых объектов описав в них требуемые разрешения для прохождения трафика. Подробнее о правилах фильтрации и управлении межсетевым экраном читайте тут (link!).
L2 VPN при использовании криптокоммутаторов позволяет прозрачно объединять физические порты криптокоммутатров в единый L2-сегмент. Для конфигурации L2 VPN необходимо выполнить следующие действия:
- настройки интерфейсов коммутации
- конфигурация виртуального коммутатора
Интерфейс коммутации — физический или логический интерфейс (VLAN) КК, который отправляет все присланные на него кадры в виртуальный коммутатор. Для задания интерфейса коммутации необходимо открыть свойства КК, перейти на вкладку Интерфейсы, выбрать нужный интерфейс и назначить ему тип «Порт криптокоммутатора». У КК должен так же быть минимум один внешний интерфейс, который используется для передачи VPN-трафика и управления устройством.
Для того, чтобы порты криптокоммутатора передавали трафик защищаемых хостов внутри VPN необходимо создать виртуальный криптокоммутатор. В общем случае можно сказать, что виртуальный коммутатор на логическом уровне объединяет все порты криптокоммутаторов, которые в него включены в единый L2-сегмент. Для создания виртуального коммутатора необходимо задать его имя и добавить из списка доступные порты необходимых КК. Если чекбокс Автоматически создавать парные связи активен, то с свойствах каждого КК не потребуется вручную указывать парные для него КК.
Для организации защищенного соединения удаленного пользователя и доступа его к защищенным ресурсам внутренней сети используется связка Континент АП и СД (Сервер доступа).
Не стоит забывать, что СД это дополнительный модуль, устанавливаемый на КШ и по факту он живет своей жизнью, не привязываясь к IP-адресам или идентификатору КШ.
Для организации удаленного доступа производятся действия на АРМ пользователя и на СД.
На АРМ пользователя:
- установка ПО «Континент АП»
- создание закрытого ключа пользователя (опционально)
- импорт сертификата пользователя (опционально с импортом закрытого ключа), выпущенный на СД
- создание соединения с СД
- создание объекта защищаемой сети
- создание правил межсетевого экрана
- создание пользователя и выпуск сертификата пользователя
- назначение пользователю правил межсетевого экрана
Более детально конфигурация данного типа VPN будет рассмотрена в соответствующем разделе.
Обзор АПКШ «Континент» 3.9 – многофункционального криптошлюза для защиты сетевого периметра
АПКШ «Континент» 3.9 — аппаратно-программный комплекс шифрования для обеспечения защиты информационных сетей, конфиденциальности при передаче информации по открытым каналам связи, организации безопасного удаленного доступа и защиты сетевого периметра. Решение построено на базе новых аппаратных платформ, что вместе с новым программным обеспечением позволяет добиться производительности до 13 Гбит/с в режиме межсетевого экранирования и до 20 Гбит/с в режиме шифрования канала по ГОСТ. Может использоваться для защиты каналов между ЦОД за счет применения аппаратного криптоускорителя.
Сертификат AM Test Lab
Номер сертификата: 239
Дата выдачи: 14.12.2018
Срок действия: 14.12.2023
- 2.1. Архитектура и производительность
- 2.2. Функциональные возможности
- 2.3. Типовые варианты внедрения
- 3.1. Практические примеры настройки «Континент» 3.9
- 3.1.1. Пример 1. Создание криптошлюза в топологии защищенной сети
- 3.1.2. Пример 2. Настройка DHCP- и NTP-сервера на криптошлюзе
- 3.1.3. Пример 3. Резервирование базы данных центра управления сетями
- 3.1.4. Пример 4. Агрегация интерфейсов
Введение
Развитие инфраструктуры в организациях, в том числе в государственном секторе, дает стимул вендорам и разработчикам средств защиты информации постоянно улучшать свои продукты.
Динамика развития сетей в госорганах до определенного момента значительно отставала от корпоративного сегмента. Сейчас разрыв уменьшился, и запросы в части производительности активного сетевого оборудования и применяемых технологий выросли. Поэтому все разработчики средств защиты информации стараются успевать за возрастающими потребностями заказчиков.
По данным исследовательской компании Gartner, за последние годы показатели продаж устройств с 40-гигабитными сетевыми картами сравнялась с показателями продаж 10-гигабитных карт из-за постоянно возрастающих требований к пропускной способности в сетях организаций. Однако обеспечить соответствие новым потребностям рынка способны не только зарубежные сетевые устройства.
Специфика российского рынка предполагает не только высокие требования к производительности: важными факторами являются тенденция импортозамещения и использования сертифицированных средств защиты информации.
С этим связано усиление требований со стороны регуляторов для решения различных отраслевых задач и потребностей:
- потребность в надежных средствах криптографической защиты информации объектов критической информационной инфраструктуры (в соответствии с Федеральным законом «О безопасности критической информационной инфраструктуры Российской Федерации» от 26.07.2017 N 187-ФЗ) для взаимодействия с государственными центрами реагирования на компьютерные инциденты;
- ГОСТ по защите информации для финансовых организаций (ГОСТ Р 57580.1-2017);
- повсеместность обработки персональных данных и необходимость их защиты при передаче по открытым каналам связи;
- требования ФСТЭК России по сертификации межсетевых экранов и средств технической защиты информации стали гораздо серьезнее в части необходимой функциональности и уровня доверия к программной среде, под которой работают устройства подобного класса.
Еще один мировой тренд в развитии концепции сетевой безопасности направлен в сторону централизации. В соответствии с этим уже сегодня заявлен высокий уровень защиты сети вне зависимости от среды и сценариев реализации систем защиты. Для удовлетворения потребностей заказчиков сейчас все мировые производители выпускают целую линейку продуктов, позволяющих покрыть все потребности заказчика.
АПКШ «Континент» — централизованный комплекс для защиты сетевой инфраструктуры и создания VPN-сетей с использованием алгоритмов ГОСТ. Он является частью большого комплексного решения для защиты сетевой инфраструктуры, в которое также входят:
- Персональный межсетевой экран из состава Secret Net Studio — он позволяет сегментировать сеть там, где нельзя установить аппаратный межсетевой экран;
- «Континент TLS», который обеспечивает защищенный удаленный доступ к web-ресурсам с использованием алгоритмов ГОСТ;
- vGate vFirewall — обеспечивает сегментацию виртуализованной сети без необходимости использовать виртуальные межсетевые экраны или использовать персональные межсетевые экраны на виртуальных машинах;
- «Континент WAF» обеспечивает защиту веб-приложений.
Ниже в качестве примера приведены высокопроизводительные модели линейки продуктов «Кода безопасности» (рисунок 1).
Таблица 1. Линейка высокопроизводительных АПКШ «Континент»
Характеристики АПКШ «Континент» 3.9
Архитектура и производительность
Новый «Континент» 3.9 стал значительно быстрее за счет перехода на 64-битную программную платформу (x86_64 FreeBSD). Проведена оптимизация программного обеспечения и исправлены ранее обнаруженные ошибки. Кроме того, был обновлен модельный ряд устройств. В результате, если старшее устройство АПКШ «Континент» 3.7 обладало пропускной способностью межсетевого экрана в 3,5 Гбит/с и пропускной способностью шифрования в 2,5 Гбит/с, то старшее устройство АПКШ «Континент» 3.9 обладает производительностью в 13 Гбит/с и 20 Гбит/с соответственно.
Также разработчики добились значительного увеличения производительности межсетевого экрана на устройствах предыдущего поколения (рисунок 2).
Рисунок 1. Сравнение производительности «Континент» 3.7 и «Континент» 3.9 (Мбит/с)
Стоит отметить, что для тестирования новой версии была произведена смена методики замеров производительности, основанная на методологии NSS Labs. Используя статистику о реальном трафике на стороне заказчика, можно проводить более точные и близкие к реальности замеры, о чем говорят результаты исследования.
При проведении тестов на производительность учитывался и тот факт, что системы могут генерировать трафик с большим количеством потоков (например, при работе по протоколу HTTP).
Применение различных подходов в изучении производительности позволяет доказать эффективность внедренных новшеств.
Теперь после того, как мы рассмотрели общие вопросы, связанные с архитектурой и методиками замера производительности АПКШ «Континент» 3.9, ознакомимся более детально с модельным рядом (рисунок 3).
Для начала разберемся с маркировкой, что означают цифры и литеры в названиях АПКШ:
- IPC — общепринятое обозначение платформы АПКШ;
- цифры указывают на относительную производительность платформы и классифицируют по уровням (до 100 — начального уровня, 100-1000 — среднего уровня производительности, 3000 — высокопроизводительные устройства);
- литера F означает наличие на платформе платы расширения с оптическими интерфейсами;
- литера C означает наличие криптоускорителя.
Таблица 2. Пропускная способность модельного ряда АПКШ «Континент» 3.9
Александр Александрович
unread,
Feb 8, 2017, 9:24:42 AM2/8/17
to Код Безопасности — Континент
После попытки ввода конфигурации с ЦУСа и далее ввода пароля появляется надпись: «Ошибка при разборе конфигурации». Причем старый файл конфигурации встает спокойно. Почитав на форумах, нашел ответ, что якобы такая ошибка встречается при разных версиях ПО ЦУС и КШ. Вот собственно такой вопрос, как избавиться мне от этой проблемы? Спасибо.
Кирилл
unread,
Feb 8, 2017, 10:22:46 AM2/8/17
to Код Безопасности — Континент
Александр, приветствую,
Уточните версию ЦУСа и версию КШ, у вас же просто КШ без Сервера доступа? Какая платформа на КШ (9830, 92D9, S115)?
Проблема
При загрузке конфигурации на КШ появляются следующие сообщения:
1) 3cgw_conf=: Ошибка чтения конфигурации
Ошибка: «Ошибка чтения конфигурации»;
2) [libsobold] Ошибка при обработке запроса: Ошибка чтения идентификатора
Ошибка
чтения файла конфигурации: Ошибка чтения идентификатора.
Решение
Обе ошибки возникают при попытке загрузки на КШ конфигурации с внешнего носителя. В первом случае можно отформатировать флешку и заново записать на нее конфигурационный файл.
Во втором случае, как следует из начала строки, ошибку в загрузке конфигурации возвращает ПАК Соболь. Если режим Соболя при этом «С», это говорит о том, что ранее Соболь был проинициализирован и переведен из автономного режима в режим совместимости. Однако в режим совместимости с Континентом («СК») Соболь перейдет только после повторной установки ОС и загрузки конфигурации.