Применение ViPNet PKI Client | ИнфоТеКС

(un)split tunneling

Еще один факт, который знают далеко не все: по умолчанию ViPNet-клиент работает в режиме split tunnel (когда можно указать, какой трафик заворачивать в туннель, а какой нет). У ViPNet существует технология «Открытого Интернета» (позже переименована в «Защищенный интернет-шлюз»).

Многие ошибочно приписывают этот функционал координатору, а не клиенту. На клиенте, который зарегистрирован за координатором с такой функцией, создается два набора предустановленных фильтров. Первый разрешает взаимодействие только с самим координатором и его туннелями, второй – с остальными объектами, но запрещает доступ к координатору ОИ и его туннелям.

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

Vipnet cryptoservice

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

Ключи и сертификаты пользователя используются криптографическими функциями, реализованными в криптопровайдере ViPNet CSP, входящим в состав ПО ViPNet Cryptoservice. Эти функции могут быть встроены в прикладное ПО сторонних производителей для создания различных защищенных информационных систем и сервисов (почтовые и банковские системы, системы юридически значимого документооборота, защиты информационных потоков и т.п.). Поставляемый криптопровайдер поддерживает стандартный интерфейс Microsoft Crypto API, высокоуровневый COM- и низкоуровневый C-интерфейсы.

Vipnet csp 4 | инфраструктура открытых ключей, шифрование | инфотекс

ИнфоТеКС оставляет за собой право без уведомления вносить изменения в поставляемую продукцию (характеристики, внешний вид, комплектность), не ухудшающие ее потребительских свойств.

Vipnet kc & ca

Главным компонентом любой PKI является удостоверяющий центр. Он заверяет подлинность открытых ключей пользователей, выпуская сертификаты открытых ключей, и осуществляет сопровождение выпущенных сертификатов в течение их жизненного цикла. Удостоверяющий центр реализуется на базе ПО ViPNet KC & CA (Удостоверяющий и ключевой центр, УКЦ).

ViPNet KC & CA реализует полный набор функций по управлению сертификатами открытых ключей:

• формирование пар открытый-закрытый ключ по запросам пользователей;

• изготовление сертификатов открытых ключей;

• приостановление и возобновление действия сертификатов, отзыв (аннулирование) сертификатов;

• ведение реестра (справочника) выпущенных сертификатов и списка отозванных сертификатов.

Vipnet pki продукты. клиентское по

Эффективное использование преимуществ и особенностей PKI, созданной на базе ПО ViPNet KC & CA, ViPNet Registration Point, ViPNet Publication Service, достигается с помощью клиентского ПО ViPNet CryptoService (Криптосервис) и ViPNet Client (Клиент).

Vipnet publication service

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

Для снижения нагрузки на УЦ, уменьшения расходов на его создание и эксплуатацию открытый справочник часто размещают на внешних по отношению к УЦ хранилищах (серверах), доступных по общедоступным протоколам. Использование общедоступных протоколов, кроме того, позволяет обеспечить совместимость с клиентскими приложениями различных производителей, а также облегчить взаимодействие с внешними УЦ при интеграции в масштабных PKI.

Публикация выпущенных УЦ сертификатов, кросс-сертификатов и списков отозванных сертификатов в хранилищах, а также загрузка списков отозванных сертификатов внешних УЦ из хранилищ организуются с помощью ПО ViPNet Publication Service (Сервис публикации). Поддерживаемые стандартные хранилища включают LDAP-серверы и WEB-серверы с загрузкой данных по FTP-протоколу.

Vipnet registration point

В крупных территориально распределенных PKI взаимодействие УЦ с пользователями обычно производится через пункты регистрации. Пункт регистрации, выступая в качестве филиала УЦ, проводит идентификацию пользователей, генерирует для них ключевые пары или устанавливает факт владения закрытым ключом по предъявленному открытому ключу, после чего формирует и передает запрос на сертификацию в УЦ. Также через пункт регистрации в УЦ передаются запросы пользователей на изменение статуса уже выпущенных сертификатов. Результаты обработки запросов из УЦ пользователи тоже получают в пункте регистрации.

Сеть пунктов регистрации позволяет создать более эффективную PKI. Для обеспечения высокого уровня безопасности операций по выпуску и обслуживанию сертификатов к УЦ предъявляются специальные требования по организационной, физической и информационной безопасности. Перенос части функций УЦ в пункт регистрации позволяет снизить эти требования, что уменьшает расходы на создание УЦ. Пункты регистрации снижают нагрузку на УЦ по обработке запросов пользователей, вплоть до полного исключения непосредственного взаимодействия пользователей и УЦ. Это также ведет к снижению эксплуатационных расходов на содержание УЦ. Кроме того, чем разветвленнее сеть пунктов регистрации, тем ниже расходы пользователей, связанные с процедурой регистрации.

Vipnet sies core | инфраструктура открытых ключей, шифрование, безопасные коммуникации | инфотекс

Программно-аппаратный комплекс (ПАК) ViPNet SIES Core — это компонент решения криптографической защиты информации в автоматизированных системах управления (АСУ) и системах межмашинного взаимодействия (М2М) ViPNet SIES, предназначенный для интеграции с такими защищаемыми устройствами, как программируемые логические контроллеры (PLC), промышленные контроллеры автоматизации (PAC), терминалы (RTU), интеллектуальные устройства (IED), оконечное оборудование (сенсоры, датчики, счетчики, различные исполнительные устройства).

ПАК ViPNet SIES Core является средством криптографической защиты информации, обеспечивающим выполнение криптографических операций по запросу защищаемого устройства, а также безопасное хранение, использование и поддержание жизненного цикла ключевой информации. Автоматизированное централизованное управление жизненным циклом ключевой информации осуществляется администратором безопасности из единого центра управления ViPNet SIES MC.

Принцип работы

ПАК ViPNet SIES Core интегрируется с защищаемыми устройствами через межплатные интерфейсы и в пассивном режиме выполняет их запросы на криптографические операции с данными. Защищаемое устройство обращается к ПАК ViPNet SIES Core через API-интерфейс напрямую или с использованием SIES Core SDK. Структуру и состав данных (команды управления, телеметрическая информация, сервисные команды) определяет разработчик АСУ или M2M.

Читайте также:  Установка и настройка КриптоПро в Ubuntu Linux 18.04

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

ИнфоТеКС оставляет за собой право без уведомления вносить изменения в поставляемую продукцию (характеристики, внешний вид, комплектность), не ухудшающие ее потребительских свойств.

Замена координатора

Рано или поздно встает вопрос о замене координатора на более производительный или временный вариант. Например, замена HW1000 на HW2000 или программного координатора – на ПАК и наоборот. Сложность заключается в том, что у каждого исполнения своя «роль» в ЦУС (Центре управления сетью).

Как правильно изменить роль, не потеряв связность? Сначала в ЦУС меняем роль на новую, формируем справочники, но не отправляем(!) их. Затем в УКЦ выпускаем новый DST-файл и проводим инициализацию нового Координатора. После производим замену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.

Кластеризация и сбой ноды

Горячий резерв – это must have для любой крупной площадки, поэтому на них всегда закупался кластер старших моделей (HW1000, HW2000, HW5000). Однако создание кластера из более компактных криптошлюзов (HW50 и HW100) было невозможно из-за лицензионной политики вендора.

В итоге владельцам небольших площадок приходилось серьезно переплачивать и покупать HW1000 (ну, или никакой отказоустойчивости). В этом году вендор, наконец, сделал дополнительные лицензии и для младших моделей координаторов. Так что с выходом версий 4.2.x появилась возможность собирать в кластер и их.

При первичной настройке кластера можно серьезно сэкономить время, не настраивая интерфейсы в режиме мастера или командами CLI. Можно сразу вписывать необходимые адреса в конфигурационный файл кластера (failover config edit), только не забудьте указать маски.

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

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

Если пинг проходит, то счетчик запускается заново, если не проходит, то регистрируется отказ интерфейса и активная нода уходит в перезагрузку. Пассивная нода при этом отправляет регулярные ARP-запросы на всех интерфейсах, описанных в failover.ini (конфигурационный файл кластера, где указаны адреса, которые принимает активная и пассивная ноды). Если ARP-запись хоть одного адреса пропадает, то пассивная нода переключается в активный режим.

Вернемся к кластерным проблемам. Начну с простого – неперключение в активный режим. В случае если активная нода отсутствует, но на пассивной в ARP-таблице (inet show mac-address-table) ее mac-адрес все еще присутствует, необходимо идти к администраторам коммутаторов (либо так настроен ARP-кэш, либо это какой-то сбой).

С циклической перезагрузкой пассивной ноды немного сложнее. Происходит это из-за того, что пассивная не видит ARP-записи активной, переходит в активный режим и (внимание!) по HB-линку опрашивает соседа. Но сосед-то у нас в активном режиме и аптайм у него больше.

В этот момент пассивная нода понимает, что что-то не так, раз возник конфликт состояний, и уходит в перезагрузку. Так продолжается до бесконечности. В случае возникновения данной проблемы необходимо проверить настройки IP-адресов в failover.ini и коммутацию. Если все настройки на координаторе верны, то пришло время подключить к вопросу сетевых инженеров.

Конверт не доставлен

Но журнал IP-пакетов, увы, бесполезен, когда речь заходит о конвертах. Они доставляются с помощью транспортного модуля (mftp), у которого есть свой журнал и своя очередь. Конверты по умолчанию передаются на «свой» координатор клиента (то есть тот, на котором зарегистрирован узел), и далее по межсерверным каналам, которые настроены между координаторами (то есть не напрямую по защищенному каналу).

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

Диагностировать прохождение конвертов межсерверным каналам или между клиентом и координатором в неочевидных случаях можно с помощью журнала и очереди конвертов, а также логов на координаторе. Также транспортный модуль ViPNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку или SMTP/POP3 (но это совсем экзотичный вариант). Погружаться в эти настройки мы не будем.

Координатор недоступен

«У нас недоступен координатор/клиент/туннель. Что делать?» – самый частый вопрос, с которым приходят новички при настройке ViPNet. Единственно верное действие в такой ситуации – включать регистрацию всего трафика на координаторах и смотреть в журнал IP-пакетов, который является важнейшим инструментом траблшутинга всевозможных сетевых проблем.

Не забываем про время

Тему блокировок продолжаем событием номер 4 – IP packet timeout. Тут все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени между узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW максимальная разница составляет 7200 секунд и задается в параметре «timediff» конфигурационного файла IPlir.

Я не рассматриваю в этой статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 – 50 секунд, и событие там может генерироваться не 4, а 112, что, возможно, собьет с толку инженера, привыкшего к «обычным» HW.

Невозможность работы gre

Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT.

Читайте также:  Установка электронной цифровой подписи на MacOS | by Airat Galiullin | Futureinapps | Medium

Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели также в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:

Поэтому, если вы используете множественные GRE-подключения, необходимо избегать применения NAT к этим подключениям. В крайнем случае выполнять трансляцию 1:1 (правда, при использовании публичных адресов это достаточно непрактичное решение).

Нешифрованный трафик вместо зашифрованного


Новичкам бывает сложно понять природу 22 события – Non-encrypted IP Packet from network node – в журнале IP-пакетов. Оно означает, что координатор ждал с этого IP-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:

Обработка прикладных протоколов (alg)

На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса – это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса.

Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:

  • при использовании NAT должен быть включен ALG;
  • при использовании виртуальной адресации ALG должен быть включен на обоих узлах, участвующих во взаимодействии (координатор-координатор, координатор-клиент), даже если виртуальная видимость установлена только с одной стороны;
  • при использовании реальной видимости и отсутствии NAT необходимо выключить ALG для того, чтобы он не вмешивался в работу SIP;
  • ALG-линейки 3.х и 4.х несовместимы (строго говоря, в линейке 3.х вообще не было возможности как-то им управлять). В таком сценарии гарантировать корректную работу SIP вендор не может.

Управляется модуль командами группы «alg module» из привилегированного режима (enable).

Общая информация

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

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

Двухключевые алгоритмы применяются и в других криптографических механизмах. Наиболее важный из них механизм электронной цифровой подписи (ЭЦП). Закрытый ключ ЭЦП используется его владельцем для вычисления подписи под электронным документом. Имея документ и подпись под ним, с помощью открытого ключа любой пользователь может проверить корректность подписи и установить подлинность документа.

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

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

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

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

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

Сертификат содержит открытый ключ пользователя и идентифицирующую этого пользователя информацию (а также другую служебную информацию). Сертификат заверяется ЭЦП удостоверяющего центра. Получаемый объект называется сертификатом открытого ключа пользователя.

Выпуская сертификат открытого ключа некоторого пользователя, УЦ подтверждает и берет на себя ответственность за то, что он установил принадлежность данного открытого ключа именно указанному в сертификате пользователю. 

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

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

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

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

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

Читайте также:  программа разблокировки PDF для снять защиту пдф файла в Win и Mac

Сложность и стоимость реализации и эксплуатации единого центра, отвечающего за все операции, может оказаться слишком высокой. Кроме того, это не всегда удобно, например из-за требований безопасности. Поэтому в современных инфокоммуникационных системах полноценная реализация концепции сертификации открытых ключей производится развертыванием инфраструктуры открытых ключей (или PKI — public key infrastructure — в англоязычной терминологии).

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

ОАО «ИнфоТеКС» производит линейку серверного (ViPNet KC & CA, ViPNet Registration Point, ViPNet Publication Service) и согласованного клиентского ПО (ViPNet Client, ViPNet CryptoService и ViPNet CSP), позволяющего развернуть и использовать собственную PKI, осуществить интеграцию со сторонними PKI и пользоваться услугами PKI.

Все ПО разработано с учетом положений Федерального закона № 1 от 10.01.2002 «Об электронной цифровой подписи». Инфраструктура и обслуживаемые сертификаты полностью соответствуют стандарту ITU-T X.509 версии 3, спецификациям IETF RFC 3280 и отраслевым де-факто стандартам PKCS.

Пересечения адресов


В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.

Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов.

Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual».

Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия.

Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС.

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

Последствия перепрошивки

Проблемной может оказаться перепрошивка на актуальную версию старых железок, которые долго лежали, например, в качестве ЗИП. В процессе может появиться ошибка «unsupported hardware», которая сообщает либо о том, что у вас действительно неподдерживаемая аппаратная платформа устаревшей линейки G1 (это HW100 E1/E2 и HW1000 Q1), либо о проблемах в настройке BIOS или в некорректной информации, зашитой в DMI.

Править ли самостоятельно DMI, каждый решает для себя сам, поскольку есть риск превратить оборудование в бесполезный «кирпич». С BIOS чуть проще: неверные настройки системы заключаются в выключенной функции HT (Hyper Threading) или выключенном режиме ACHI (Advanced Host Controller Interface) для HDD.

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

Например, ошибка cpu::Vendor(#3)==’GenuineIntel’ 24 times => [Failed], скорее всего, сообщает о выключенном HT. Кстати, перепрошивку часто путают с обновлением, но это разные процессы. При обновлении сохраняются все настройки, а параметры, о которых было написано выше, не проверяются. А при перепрошивке вы возвращаетесь к заводским параметрам.

Применение vipnet pki client | инфотекс

В разделе собраны наиболее распространенные и типовые решения, построенные с применением продуктов ViPNet. Здесь вы найдете как примеры общих решений по организации VPN и PKI, так и способы решения частных задач, например, задач по защите IP-телефонии.

Служебные порты и tcp-туннель

Однажды я столкнулся с приложением, которое ни в какую не хотело работать через координатор. Так я узнал, что у координатора есть служебные порты, по которым незашифрованный трафик блокируется без возможности какой-либо настройки. К ним относятся UDP/2046,2048,2050 (базовые службы ViPNet)

, TCP/2047,5100,10092 (для работы ViPNet Statewatcher) и TCP/5000-5003 (MFTP). Тут подвела функции TCP-туннеля. Не секрет, что провайдеры любят фильтровать высокие порты UDP, поэтому администраторы, стремясь улучшить доступность своих КШ, включают функцию TCP-туннеля.

Ресурсы в зоне DMZ (по порту TCP-туннеля) при этом становятся недоступны. Это происходит из-за того, что порт TCP-туннеля также становится служебным, и никакие правила межсетевых экранов и NAT (Network Address Translation) на него уже не действуют. Затрудняет диагностику тот факт, что данный трафик не регистрируется в журнале IP-пакетов, как будто его вовсе нет.

Уцку vipnet

Компоненты ViPNet KC & CA, ViPNet NCC и ViPNet CryptoService, являющиеся составной частью средства криптографической защиты информации «Домен-К», а также используемые при необходимости компоненты ViPNet Registration Point и ViPNet Publication Service образуют в совокупности программно-аппаратный комплекс Удостоверяющий центр корпоративного уровня ViPNet (УЦКУ).

УЦКУ ViPNet может применяться для организации и использования PKI практически любой архитектуры и степени сложности. На УЦКУ ViPNet в двух модификациях получены сертификаты соответствия ФСБ России №СФ/128-1777 и №СФ/128-1778 по требованиям к информационной безопасности удостоверяющих центров классов КС2 и КС3.

В заключение

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector