Pull to refresh

Comments 20

Скоро выйдут требования к разным классам и типам МЭ и профилями защиты по 15408.
И как эти требования будут коррелировать с действующими РД?
Пока неизвестно, все выпущенные до этого требования+ПЗ покрывали те классы СЗИ, по которым не было РД. Я думаю, что РД МЭ просто отменят. На замену РД СВТ тоже делается целый набор требований к средствам разных классов.
Вот скажите, есть такая штука — ViPnet. У меня есть серьёзные сомнения относительно корректности его исполнения.

Во-первых, случается, что он отказывает. Не знаю, была ли это ошибка пользователя, или же ошибка в ПО, но я наблюдал на пограничном шлюзе пакеты (незашифрованные) с «виртуальными адресами» вместо пакетов с портом назначения udp 55777. Их заблокировано (файерволл знал, что наружу не могут выходить пакеты с тамики адресами назначения), но если бы это был просто NAT без фильтра — он их выпустил бы.

Во-вторых, сами эти виртуальные адреса — 11.x.x.x. Вообще-то, согласно IANA, данный блок адресов выдан Минобороны США (DoD). Как минимум, здесь происходит некорректное использование глобально-уникальных адресов — видимо, какая-то светлая, но недоученная голова в Инфотексе решила, что раз 10… можно, то и за 11… тоже сойдёт.
Но это само по себе не так страшно, как в комбинации с предыдущим. Если бы пакеты не были остановлены файерволлом, данные, которые мы так хотели надёжно зашифровать, отправлялись бы открытым текстом прямо как по заказу. Другими словами, некорректный «захват» блока — не мелочь, а грубейшее нарушение дизайна системы.

Куда можно пожаловаться, чтобы сертификаты у них отобрали (желательно, навсегда)?
Во-первых, случается, что он отказывает. Не знаю, была ли это ошибка пользователя, или же ошибка в ПО, но я наблюдал на пограничном шлюзе пакеты (незашифрованные) с «виртуальными адресами» вместо пакетов с портом назначения udp 55777

Это и есть не шифрованный трафик. Не знаю какие там были настройки у вас, но то, что вы видели на фаерволе — это трафик к узлам без випнет клиентов. Он по идеологии не может быть шифрован, клиент тогда не получит данные, если оно будет шифровано. Тут вопрос к настройки координатора. Если там туннели типо permit any ip, что вы хотите?

Во-вторых, сами эти виртуальные адреса — 11.x.x.x.

Этот диапазон настраивается на координаторах и на клиентах. По моей практике, обычно это зона из локальной сети предприятия в котором стоит крипошлюз. Ведь по сути, координатор выступает VPN сервером и его клиенты получают адреса. В терминологии випнета — это «виртуальные адреса»
Это и есть не шифрованный трафик.

Vipnet… я хоть и не спец в нём (да и давно это было), но как мне помниться, это как раз шифрованный трафик, инкапсулированный в UPD 55777, который передается между координаторами для «своих» клиентов, у которых vipnet клиента нет.
Это же випнет. Как и все прочее сертифицированное.
Вам же написали в посте, что производитель, а особенно регулятор ни в чем не виноват:
В случае сбоя функционирования МЭ или его неэффективности, что произошло по причине отсутствия нужных функций, вопросы возникнут не к разработчику брандмауэра, а к администратору МЭ или покупателю продукта, вовремя не проверившему его подлинность.
udp 55777, кстати порт тоже может быть изменен — да, шифрованный трафик между узлами сети Випнет.
Но товарищ merlin-vrn, писал о другом. Об открытом трафике с внутреними адресами координатора.

я хоть и не спец в нём (да и давно это было)

Ну наверное так. :)
Именно так. Вместо зашифрованных пакетов с персональными данными людей, инкапсулированных в udp с портом 55777, я видел то, что должно было быть зашифровано и инкапсулировано, с адресами назначения 11...., т.е. для АНБ США.
Это был трафик к т.н. «виртуальным адресам».
Вы бы документацию випнета почитали, что ли.

Это адреса, которые назначаются конечным клиентам, и по которым эти клиенты внутри системы идентифицируются. Трафик с такими адресами — открытый. При передаче пакеты с такими адресами шифруются, инкапсулируются в пакеты udp с портом назначения 55777 и реальными адресами, возможно, серыми — через NAT это тоже работает, и передаётся другой ноде через открытую сеть. Другими словами, vipnet — это велосипед на тему ipsec tunnel mode с nat-t. (У него есть и другой режим — не udp, так же как и у ipsec — без nat-t).

Так вот, на шлюзе я видел незашифрованные пакеты, вместо зашифрованных, инкапсулированных в транспортные udp. Явно отказ vpn при передаче.

Если диапазон виртуальных адресов настраивается, два вопроса: почему у него заведомо некорректное значение по умолчанию, и почему как-то вообще ни разу не доводилось видеть его замены, вплоть до сети масштаба 200 аппаратных шлюзов випнет и отказоустойчивым кластером из двух координаторов в центре, которую проектировала известная московская фирма (которая, кстати, есть на Хабре)?
Это был трафик к т.н. «виртуальным адресам».

такое используется, при доступе с открытой сети к защищенным узлам, либо с ПО випнет, либо просто в DMZ за координатором.

Вы бы документацию випнета почитали, что ли.

Судя по нижеизложенному, вы не понимаете как работает випнет.

Это адреса, которые назначаются конечным клиентам, и по которым эти клиенты внутри системы идентифицируются.

Именно внутри системы, т.е. внутри каждого узала. Вы же вкурсе надеюсь, что виртуальные адреса одного и того же узла(АП1) на двух других узлах(АП2 и АП3) различаются?

Явно отказ vpn при передаче.

Прям явный? в пакетых были данные? Может это был поиск узла по всем известным адресам?

почему у него заведомо некорректное значение по умолчанию,

С вашей точки зрения? Какие должны быть? Что бы сразу работало по умолчанию?
Я их не оправдываю с выбором. 11.0.0.0/8. Но имхо — это наименьшее зло.

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

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

не надо пытаться воздействовать на других как политическая… Троцкий.
Для не знающих напомню, что обычные изделия одной мягкой фирмы тоже сертифицированы.
Не знаю, что там сертифицировано, но например система безопасности домена Windows не сертифицирована как система предотвращения несанкционированного доступа. Зато сертифицирован Dallas Lock. То есть, вы делаете домен, а потом ставите Dallas Lock и он заменяет окошки входа в систему и некоторые другие, также заменяет функции управления безопасностью. На конечной рабочей станции, судя по всему, он представляет из собой GINA-библиотеку вместо MS GINA (см. в technet, что это такое и как в винде устроен вход в систему).

И конечно Dallas Lock — так себе по функционалу управления и возможностям, особенно — по сравнению с AD. Кое-что в нём удивляет. Но он хотя бы на первый взгляд работает как заявлено.
А уж если у вас более одного домена (дерево, лес) — готовтесь плясать с бубном. Техподдержка не смогла ответить на вопросы, предложили экспериментировать самим.
Мне интересно, вот мы, как интегратор, часто продаём МЭ, например Cisco ASA. Причём можно продать её просто так, а можно (если заказчик требует) ещё заплатить конторе, которая сертифицирует железки. Так эта контора реально что-то тестирует, или производит обмен бумажек на деньги?
Обмен. Была где-то статья про сертификацию.
Если коротко: все как обычно.
Насколько мне известно, контора заливает сертифицированную прошивку.
Процедура сертификации достаточно строго регламентирована. К тому же результаты испытаний проверяются органом по сертификации, и при выявлении несоответствия действующего функционала заявленным требованиям — никто «обмен бумажек на деньги» не произведет — изделие будет отправлено обратно на доработку. Испытательных лабораторий в РФ не так много — никто не станет портить себе репутацию и отношения со ФСТЭК/ФСБ/МО, чтобы просто срубить по-быстрому деньжат.
Странно, что в статье ничего не сказано про сертификацию ФСБ для МЭ. Сертификация ФСТЭК и ФСБ — разные вещи, но многие заказчики не хотят в это вникать, для них обычно подойдет «любая бумажка». Тем временем, МЭ с сертификатами ФСБ стоят дороже, но требуются только в серьезных госорганах, например Администрация Президента, ФСБ, МВД и тд. Интеграторы часто пользуются блаженным неведением заказчика и «толкают» более дорогую, но ненужную железку.
Only those users with full accounts are able to leave comments. Log in, please.